Page 1 of 1

Q68 Hardware issues

Posted: Mon Mar 20, 2017 9:48 am
by Peter
In the "MC68EC020" hardware thread, I mentioned that 16 bit color in high resolution slows down the Q68 considerably.
Here is the technical explanation:

For the given timings of the 40 MHz CPU it is best to clock SDRAM with 80 MHz, giving 160 MB/s memory throughput.
In QL mode the Q68 needs 1.8 MB/s for screen refresh at 60 Hz, which is 1% of this. Neglegible.
In 16 bit highcolor at 1024x512, 60 MB/s are needed for screen refresh, consuming 37% of the available memory throughput. Terrible.
I did implement this mode for Q40 compatibility, but it will require fat warning in the manual, not to use for speed critical software.

Since there is no cache, the CPU slows down almost linear to the bandwidth consumed by video.

So for 1024x768, 8 bit color is a good compromise, slowing down the system "only" by 16%.
I also want to implement 1024x768 in mode 4, in case full CPU speed is needed, or for QDOS/Minerva.
Alternative OS like uClinux will also call for a non-Aurora 8 Bit mode, with a straightforward bit pattern.

BTW are Q68 hardware issues better discussed in "Compatibles corner" or "Hardware"?

Re: Q68 Hardware issues

Posted: Mon Mar 20, 2017 10:48 am
by vanpeebles
Peter wrote:BTW are Q68 hardware issues better discussed in "Compatibles corner" or "Hardware"?


Here would be fine :)

Re: Q68 Hardware issues

Posted: Mon Mar 20, 2017 1:04 pm
by Nasta
1024x768 in 4 colors was the most requested mode when I was developing Aurora :) and probably most used too on LCD monitors. I suppose it would take about 5% of the available bandwidth which is negligible.

I suppose you use page mode to access and then FIFO buffer the video data since these are strictly sequential accesses.
Is there any pre-fetch or using page mode for the CPU? Even though (depending on how the SDRAM banking is handled) refresh and video access periodically require re-opening the page, it occurs to me it would significantly increase the bandwidth available to the CPU?
This reminds me of a NXP CPU/video controller combo I used a while ago (it is normally used for high-end on-screen and teletext displays) which used a single SDRAM, it deliberately partitioned the RAM into 1/4th RAM size banks rather than interleaved, which would be the usual way it's used for CPU access. The reason was to have the screen portion in one bank (1M) so page mode, which is handled independently per bank, would remain independent for the CPU and video. It's not actually documented, but the fact that code would execute at about half speed in the last 1M of RAM where the screen memory was, is a clue :)

Re: Q68 Hardware issues

Posted: Mon Mar 20, 2017 3:31 pm
by Peter
Nasta wrote:I suppose you use page mode to access and then FIFO buffer the video data since these are strictly sequential accesses.

It is called "read burst" on SDRAM, but yes.

Nasta wrote:Is there any pre-fetch or using page mode for the CPU?

I tried it out, but the additional logic then required a lower clock rate. I achieved better performance by running at higher clock and using less complex "random access only" logic for CPU side access - while optimizing SDRAM statemachine, clock rate and phase for the setup/hold requirements of the CPU.

For cache, I would consider lowering the clock rate somewhat, because that's a real game changer. At some time I was already close to a write-through cache implementation. Then, as usual, life caused a long break, and I forget so much that it seemed better to concentrate on the remaining more trivial work.

Nasta wrote:Even though (depending on how the SDRAM banking is handled) refresh and video access periodically require re-opening the page, it occurs to me it would significantly increase the bandwidth available to the CPU?

IIRC refresh and video burst occured seldom enough so the overhead for re-opening bank/row did not make much difference. It was a decade ago, so don't ask me details ;)

By the way, my personal goal in terms of speed was only to be faster than SGC, which seems achieved. To get more performance, the first thing would be to use higher speed grade chips - far easier than logic optimization.

Re: Q68 Hardware issues

Posted: Thu Apr 20, 2017 11:51 am
by Silvester
Peter wrote:
In 16 bit highcolor at 1024x512, 60 MB/s are needed for screen refresh, consuming 37% of the available memory throughput. Terrible.

Perhaps you could supply Q68 with FAST/SLOW keywords for retro ZX81 look. :lol:

I jest.

Re: Q68 Hardware issues

Posted: Thu Apr 20, 2017 12:27 pm
by Peter
Highcolor would also speed up simply using a lower framerate. I just didn't do that because some might still have a CRT monitor.

As for ZX81: That was my first computer, the second a ZX Spectrum. On a very rainy day I might even implement one of them on the same board. ;)

Re: Q68 Hardware issues

Posted: Thu Apr 20, 2017 12:42 pm
by Silvester
Peter wrote: I just didn't do that because some might still have a CRT monitor.

Ah I do, for my Q40: Gateway vivitron 1572 (Sony chassis). Despite being 23 years old still works as new.Though I did have to solve a few problems (RGB drive transistors on common heatsink eventually cause fractured solder joints, also had an intermittent HT problem (usually sign of HT coil demise in other makes) until I went over all HT joints and re-soldered them). Sadly I think a lot of valuable multisync Sony monitors must have been thrown away just for the sake of a bit of soldering.