Q68 Hardware issues

The Thor, Aurora, Q40, Q60 & Q68 etc. are discussed here.
Post Reply
User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Q68 Hardware issues

Post 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"?
Last edited by Peter on Mon Mar 20, 2017 6:29 pm, edited 1 time in total.


User avatar
vanpeebles
Commissario Pebbli
Posts: 2815
Joined: Sat Nov 20, 2010 7:13 pm
Location: North East UK

Re: Q68 Hardware issues

Post by vanpeebles »

Peter wrote:BTW are Q68 hardware issues better discussed in "Compatibles corner" or "Hardware"?
Here would be fine :)


Nasta
Gold Card
Posts: 443
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: Q68 Hardware issues

Post 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 :)


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

Re: Q68 Hardware issues

Post 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.


Silvester
Gold Card
Posts: 436
Joined: Thu Dec 12, 2013 10:14 am
Location: UK

Re: Q68 Hardware issues

Post 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.


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

Re: Q68 Hardware issues

Post 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. ;)


Silvester
Gold Card
Posts: 436
Joined: Thu Dec 12, 2013 10:14 am
Location: UK

Re: Q68 Hardware issues

Post 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.


David
Post Reply