Poll: CPU choice

Nagging hardware related question? Post here!

Which CPU would you like the next QL to have?

Poll ended at Sun Mar 17, 2019 7:12 pm

The original! 68008 and 1MB all the way
3
12%
Update! 68008FN square chip in a socket, with the option for up to 4MB
8
32%
Update++ 68SEC000 SMD chip, up to 16MB possible
14
56%
 
Total votes: 25

User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: Poll: CPU choice

Post by mk79 »

Nasta wrote:But then, if extended to 4M, it could run SMSQ/E?
No, current code base needs the shadow RAM to overwrite the vectors etc.


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: Poll: CPU choice

Post by Peter »

Dave wrote:This board has a really precise target. People who have and use a BBQL with maybe a (S)GC and a couple of extras like QubIDEs, etc. It's just a board to allow a person to keep their original case, keyboard and expansions hooked up to a "true" QL. Issue 5 owners would see some performance benefits, but Issue 6 and 7 owners would just see the passive improvements: RGB quality, reduced heat output, and everything being 'new'...
I think this is a very good idea.
Dave wrote:I think a Q68 on an adapter board inside the QL would definitely be interesting, and have put some thought into it.
An unchanged Q68 could be held by a bracket (non-UK back only) plus a set of adaptors and cables. Main work would be a matrix to PS/2 (or whatever) converter. But somehow this solution is not 100% my taste. I have a tendency to prefer a "real" QL mainboard inside the black case (either original or your board as proposed here) and place SGC-like upgrades (even if Q68-based) at the extension slot.


User avatar
Cristian
Aurora
Posts: 960
Joined: Mon Feb 16, 2015 1:40 pm
Location: Veneto

Re: Poll: CPU choice

Post by Cristian »

Also a shortened QL motherboard would be interesting, to make room for large expansion cards such as Trumpcard and Tetroid disk interface


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Poll: CPU choice

Post by Dave »

mk79 wrote:No, current code base needs the shadow RAM to overwrite the vectors etc.
So if we include shadow RAM for a given address range, it becomes possible?

Not on this board, but on a future board we've worked on, there is shadow RAM. The presumption that on startup a boot ROM copies an image into RAM starting at $0 then... well... magic...

Would you be willing to post a general description of the boot process and hardware requirements, for the general interest and education of the forum? I would certainly get something from it.


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Poll: CPU choice

Post by Dave »

Cristian wrote:Also a shortened QL motherboard would be interesting, to make room for large expansion cards such as Trumpcard and Tetroid disk interface
In theory, the entire QL could fit behind the QL-SD slots ;) It would just need a thin strip to carry the expansion port DIN connector. That would leave 29 or 30cm for completely internal expansion. That said, it would be nice to drop that connector to have something with many more pins, to support a 32-bit data bus and a few more address lines.

I'm open to suggestions.

My current preference is to move to a micro-ITX or micro-ATX board. All IO would be through the ATX standard gasket area. Expansion would be using commonly available PCI slots, mounted in reverse, using a custom pinout. It would make expansion cards a lot more economical to manufacture and a lot easier to support. I would also enforce the proper use of SP0..3 too. Cards should know where they're plugged in. Given the huge address space on the higher CPUs, I would change things so each card had a large address space... 512K? Enough for the largest frame buffer we might need, so that a video card could be memory mapped.

In this imaginary system, there would be up to 7 expansion slots, matching up with ATX slot positions. Decoding would be as simple as comparing 4 address lines to SP0..3. The base QL would be the 8th slot, RAM would be outside of that. The trumpcard would be redundant due to onboard RAM and storage. The QubIDE (it's not a Tetroid disk interface, it's a QubIDE cloned very nicely by Tetroid) would be redundant due to onboard IDE (and maybe SATA if the chipsets work). The video system would be put on a card, so it would be supremely upgradeable. Likewise, the CPU might be on a small card, a bit like the Pi Compute Module uses a standard 200-pin DIMM slot - which I also considered, but it's too small for most interesting uses and not very mechanically stable.

Keyboard/mouse would be PS/2. No Sinclair ALUs *at all*...

At which point, just as you were settling in with your new systems, I'd announce a custom PS/2 keyboard with the exact QL layout ;)


User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: Poll: CPU choice

Post by mk79 »

Dave wrote:So if we include shadow RAM for a given address range, it becomes possible?
Yes, that is basically all that is needed. I've implemented just this a few weeks ago on an FPGA and it worked.
Would you be willing to post a general description of the boot process and hardware requirements, for the general interest and education of the forum? I would certainly get something from it.
The boot process is pretty similar to the Q40 that I have already described in depth https://www.kilgus.net/2016/03/17/smsqe-boot-sequence/. There are no hardware requirements besides maybe 2MB of RAM and the shadow RAM for the first 4kb or so of ROM (4kb is an educated guess, usual implementations shadow the whole 48kb of ROM).


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Poll: CPU choice

Post by Dave »

mk79 wrote:There are no hardware requirements besides maybe 2MB of RAM and the shadow RAM for the first 4kb or so of ROM (4kb is an educated guess, usual implementations shadow the whole 48kb of ROM).
Thanks for the link.

I'll get with Nasta and we'll see if we can make that happen. Of course, once we're shadowing that we're also shadowing video RAM and whatever else Nasta can find to shadow.

If memory ain't shadowed, Nasta ain't happy. :P


User avatar
Cristian
Aurora
Posts: 960
Joined: Mon Feb 16, 2015 1:40 pm
Location: Veneto

Re: Poll: CPU choice

Post by Cristian »

Also a 5+ year battery backed clock would be really appreciated


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Poll: CPU choice

Post by Dave »

I have been struggling with the battery backed clock.

There's a reset generator circuit that protects the 8302 clock, but it still corrupts about 1 reset in 50. That's enough to make it useless. I did put on a rechargeable battery, but it needs a proper Li-Ion charge circuit. If the reset generator doesn't reserve the clock, then a Minerva-style RTC is needed instead, and if that happens then a Li-Ion battery is massive overkill and a supercapacitor would be enough.


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Poll: CPU choice

Post by Dave »

I am having some quandries.

It does look like the 68SEC000 is the winner. People who voted for the 68008FN10 would be happy with the 68SEC000 also. The original 68008P8 was defeated 19 votes to three, so there's a definite desire for improvement there.

One thing the 68SEC000 brings is huge clock potential. Most non-FU-marked chips will do 50MHz. The ULAs in the QL, however, never will. The 8302 seems to handle faster CPUs quite well, and works fully asynchronously. The 8301 though is the problem child. The smart play here is to forcibly replace its logic - particularly DTACKL generation. I have previously had an 11MHz QL, running the CPU off the 8302's clock, and that machine was quite useful, with a modest speed-up. The weakness was that it was pushing the limits of the RAM access time.

So what I am looking at for this machine is either running it at stock 7.5MHz and you can plug your (S)GC into it for higher speeds, or possibly just testing what speeds the prototype board will reliably run at, and just releasing that fixed speed, or even the option of having the clock divider be configurable by DIP switches, within sane limits. With the RAM I have, 15 or 17.5MHz would be possible without wait states. If I get much faster SRAM, 30, 40 or even 50MHz would be possible for most things, but when it was writing to the video RAM it would be slowed considerably, waiting for DTACKL. Remember, this would still be an 8-bit system, so a 30MHz system would be about equivalent to a Gold Card.

So the debate is currently whether or not it would be possible to test that out fully within the 3 month timeframe. Luckily, this can be incorporated to the board using a GAL, but not used, and later a GAL update would be able to enable it once the testing was complete. One upside of this would be having 2M of 10ns SRAM on every board. One downside is that this is obviously MUCh faster than the DRAM I have on hand, so it would make RAM expansions a bit more expensive (chip cost is almost $8 per 2Mx8, so 14MB could be almost $60 in SRAMs alone.)

It's almost certainly not possible to have the 68SEC000 start in 16-bit bus mode within my target design timeframe.


Post Reply