Page 1 of 5

Poll: CPU choice

Posted: Sun Mar 10, 2019 7:12 pm
by Dave
This is a (not quick) poll to find out what CPU people want. It's not quick because there's background info to why I am asking the question. Please read and understand the background info.

Please only answer the poll if you still use an original BBQL, no matter how much upgraded, and you'd consider an upgraded board to fit inside your BBQL, OR if you use an emulator/Q68 etc but would consider running a BBQL again if an upgraded board was available.

Design goal: The last 100% QL compatible mainboard with upgrades. Designed for long lifetime of serviceability. All chips socketed. Everything kept to the original design intent - same memory map, physical connector positions etc. Only changes are modernisation of some subsystems, eg: DRAM, power supply, video output, serial and joystick sockets. Best quality caps. Designed to run cool, with very clean signals and no ground bounce.

My goal with this board is you can take a QL, remove the original board and replace it with this one. You move the socketed chips across from the old board and it just works. It would be a 1:1 fit for European QLs. UK QLers would need to remove a little bit of plastic from around the serial and joystick ports so the German QL DB9 D-sub ports will fit properly. It's a very simple change.

Issue 5 owners would see an immediate slight performance increase to match Issue 6/7 boards. All owners would see a much improved power supply configuration, video output quality, and a lot of component protection build in. This especially applies to the 8301 - which are in short supply and too easy blown up on older boards.

The new board has an internal expansion area so it could take an SRAM-based full speed memory board. The DIP-48 68008P8 CPU can address 1MB of RAM. The PLCC-52 version, however, can address 4MB of RAM and the TQFP (surface mount) 68000 in 8-bit mode can address 16MB. Given this is supposed to be a "pure" QL, do I keep the original CPU, or.... Note that the largest amount of usable RAM that could be fitted is less than the address space - for 4MB it would likely be 3.5MB, and for 16MB it would likely be 12 or 14MB. The memory card would be available at the same time.

Either of the options that are NOT the original CPU involve a small extra cost - probably around £4 or £5 at the most. But I can only do one option for everyone, though, so it's a straight up popularity contest.

Anyhow, which is more important? Keeping it all original, or making a small change to a different CPU?
OMG! Lolwut!
OMG! Lolwut!

Re: Poll: CPU choice

Posted: Sun Mar 10, 2019 9:34 pm
by SinclairSociety
For a newbie to QL, is there any Pros and Cons for the 3 CPU options you make note of?

TJ

Re: Poll: CPU choice

Posted: Sun Mar 10, 2019 9:40 pm
by mk79
Hm, interesting, still not sure if I wanted one or not. Maybe yes, probably depends on the price. In any case, I think it makes sense to upgrade the CPU, 1MB is very limiting. But more than 4MB doesn't make much sense either at the original QL speed. More RAM makes QDOS slower. The effect is so noticeable that QPC employs a traditional 1MB address space layout and has the rest of the RAM as a separate extended area. But this needs to be designed into the OS, which is not easily possible with QDOS.

Re: Poll: CPU choice

Posted: Mon Mar 11, 2019 2:33 am
by Dave
SinclairSociety wrote:For a newbie to QL, is there any Pros and Cons for the 3 CPU options you make note of?
The only differences between the CPUs are having 20, 22 or 24 address pins. This gives 1, 4 or 16MB address range. There's not really any cons, but there are obvious pros to having more memory - at least as an option.
mk79 wrote:Hm, interesting, still not sure if I wanted one or not. Maybe yes, probably depends on the price. In any case, I think it makes sense to upgrade the CPU, 1MB is very limiting. But more than 4MB doesn't make much sense either at the original QL speed. More RAM makes QDOS slower. The effect is so noticeable that QPC employs a traditional 1MB address space layout and has the rest of the RAM as a separate extended area. But this needs to be designed into the OS, which is not easily possible with QDOS.
It'll come with Minerva. That can be replaced by anything you want.

The circuitry that generates DTACKL will be replaced, so the traditional obstacle to faster CPUs will be lifted. I can provide for a separate clock for the CPU so it can be ran faster. The 68008FN is available as a 10MHz part. The 68SEC000 is available as a 20MHz part, though with a heatsink stuck on it it will happily do 25, 30MHz all day long. A lot of people get 40MHz. I understand the active cooling record is 56MHz. Personally, I'd happily run it at 25MHz. The limitation is that the RAM I've bought is 60ns, which indicates 17.5MHz is safe. The CPU could go faster, but you might end up introducing wait states.

This board is aimed at people who want to maintain their current systems and hardware investment with a new PCB. If they want something faster than that, really, they should look at other options like the very able Q68.

Re: Poll: CPU choice

Posted: Mon Mar 11, 2019 3:15 am
by SinclairSociety
I went with 68008FN keeping it in the same 68008 family. TJ

Re: Poll: CPU choice

Posted: Mon Mar 11, 2019 11:45 am
by Cristian
mk79 wrote:More RAM makes QDOS slower.
So a 4MB S-Goldcard makes the QDOS slower??? Am I misunderstanding?

Re: Poll: CPU choice

Posted: Mon Mar 11, 2019 11:48 am
by mk79
SGC comes with a faster CPU.

Re: Poll: CPU choice

Posted: Mon Mar 11, 2019 12:49 pm
by Cristian
mk79 wrote:SGC comes with a faster CPU.
Yes obviously I know. The sense of my question was slightly different.
So, SGC doesn't adoopt any trick to fix this issue, but simply uses the "brute force" of its faster CPU

Re: Poll: CPU choice

Posted: Mon Mar 11, 2019 1:58 pm
by mk79
Cristian wrote:
mk79 wrote:SGC comes with a faster CPU.
Yes obviously I know. The sense of my question was slightly different.
So, SGC doesn't adoopt any trick to fix this issue, but simply uses the "brute force" of its faster CPU
As I said, 4MB is still ok one way or the other. 16MB will probably be noticeable. QPC and probably other later SMSQ/E platforms are the only ones that address this issue, but are regularly used with 16MB or more.

Re: Poll: CPU choice

Posted: Mon Mar 11, 2019 2:45 pm
by Dave
The SGC increases speed by increasing clock rate from 7.5MHz to 24 MHz, AND by using 32-bit wide expansion memory instead of 8-bit wide internal memory. So apart from about 3.2x the clock speed it also gains from having 4x the memory bandwidth.

What I'm proposing (for now) is still an 8-bit data bus. The only thing that is changed is the amount of memory.

On the 68008FN10 which can address 4MB, I'd personally map in 3.5MB of it, including shadowing video RAM for read accesses, so the CPU is only slowed when it hits IO space or does writes to the video area. That will help reduce the approximately 60% RAM contention for drawing video.

On the 68SEC000 in 8-bit mode, it could be fitted with 4, 8 or 12MB very easily. If people wanted the 16MB then probably only 14MB would be available, with the same trickery above. Aliases of the internal address space of the QL would sit on top of that... But nothing unusual or dramatically different.

Because of the different handling of DTACKL, it WILL be possible to run the CPUs faster, but the timing gets complex very quickly - which is why the SGC's CPU is hooked up to that state machine that acts as an intermediary to the QL IO area and video. That is why a fair proportion of my efforts are work on replacing the 8301 with new memory manager logic and a frame buffer system based on commodity parts, plus a complete replacement and upgrade of the 8302/8049 in a register-compatible way. However, that does mean dealing with the OS (not my favorite) and doing programming (not my strong point, but I get there eventually.)

For the future, one path open to me is to use an 020 or 030 at moderate clock speed, without the benefit of the 'ingot' state machine. The address decoder and refresh controller can manage the RAM as a 32-bit wide array, and the replacement video system could also have reads and writes as the full 32-bits. This would dramatically increase the feel of speed, without having the same raw throughput of the SGC. It would also support extended modes that could be software defined. Finally, a lot of window handling could be refined *greatly* if the window manager were rewritten slightly to not brute force copy/save huge areas of screen but to give instructions to the frame buffer to do that instead.

But that's the future, and this board is now.