8301 (ZX8301, the QL's Master Chip MC) - facts and figures

Nagging hardware related question? Post here!
User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: 8301

Post by Peter »

Nasta wrote:For sure - although you then still have a big heap of inactive hardware that never the less consumes power and influences signal integrity. But that is a story for a later post.
Don't you think that keeping RAS and CAS quiet would have a great impact? (No need to answer seperately if that's part of your upcoming post.)


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

Re: 8301

Post by Nasta »

In the previous long post, a signal trace was shown of some CPU and 8301 signals, and this trace shows one of the 40 timing chunks the 8301 generates for each line of display it sends to the screen. In actual fact, it shows one of the 32 'active' chunks during which the 8301 is reading data from RAM that will be output as visible pixels.
The next picture shows a trace of one of the equivalent timing chunks that happens when the 8301 is generating completely blank lines, in our case lines 256 to 311 out of the (0 to 311) that make the whole screen. And, it's actually a very interesting one as will be shown soon.
8301_write_8302.gif
Just for a minute, let us loom at the first picture, namely at the state of the address lines shown on the trace.
There are only 4, because this is basically enough to figure out what part of the motherboard hardware is being addressed.

* Note, the traces were taken on a 'bare' QL.

So, the 8301 disregards A18 and A19 from the CPU which means it reduces the address map to 256k and this is then repeated 4 times within the 1M total.
The decoding table is actually very simple:
A17:A16=00 and /WR=1 decodes the ROM. ROMOEH goes high and /DTACK is a copy of /DS which makes the CPU perform the fastest possible access in ROM.
A17:A16=00 and /WR=0 just generates /DTACK as a copy of /DS which makes the CPU perform a write cycle that effectively does nothing.
A17:A16=01 accesses the IO area. There are some differences between ULA versions it seems. There are only a few addresses used but the OS will use $18000 as the base address so, for this one also A15=1. It also uses A6 (and on some ULA versions A5) to select control registers within 8302 (A6=0), or 8301 (A6=1 or A6:A5=11).
When the 8302 is selected, the pin /PCENL on the 8301 also goes low, this is the chip select output that drives the equally named input pin on the 8301.
A17=1 accesses the RAM, and when A17=1 and A16=0, /CAS0 will be activated, when A16=1, /CAS1 will be activated, i.e. A16 selects the RAM bank.

If we look at the previous trace, we can see that the CPU is addressing the first 32k of the RAM (A17:A15=100), i.e. screen 0.
In the picture above, we see something curious - it is addressing the IO area with A6=0, which are the registers inside the 8302, and the /WR signal being low tells us that it is writing data.
Also, we can see CSYNCH is high and an even more curious thing within the portion of the access chunk that is normally used to read screen data - there only /RAS goes low, but there is no /CAS signal and in fact if we look into the /RAM datasheet, this means no data is transferred at all (which is OK since there is nothing to display, these lines are all black) and the RAM is actually being refreshed. So, the CPU is writing a value into the 8302 on an idle QL during vertical retrace - what it is actually doing is serving the frame interrupt - which occurs every time a vertical retrace begins, and it is generated from the VSYNCH signal.

The trace however immediately poses two questions:

1) Why is the 8301 using 8 clock cycles just to refresh the RAM when it could use just 4, freeing twice the usual time for CPU access? And, further (though not shown in the diagram) why does it do it for every one of the 32 chunks that would normally be used for visible pixels in a line?

2) What does the 8302 have to do with this, as the 8301 is obviously letting data on the RAM data bus (/TXOE=0) even though the RAM is not using it?

Well, let us start with the easy one first - and that's question (2).
If I could have squeezed the signal /PCEN (or PCENL as it is written on the QL schematic) into the trace, it would be shown going low at the same time /TXOE goes low, and going back high a bit before /TXOE goes high. In other words, the 8302 is being selected.
Well, the explanation is that the 8302 was connected to the RAM data bus on all issues of the QL motherboard up to 5 (or in any case up to whichever one has the HAL chip on it). The 8301 represents one more small load on the bus along with 16 already existing loads on it. On the CPU side, there are two ROMs and the data buffer chip on the data bus so connectiong the 8302 there would really have made no problem at all. However, it appears that the logic inside the 8301 counts on the 8302 being connected to it's side of the data bus, and the only logical explanation is that these two started as a single design, with a single internal data bus - and the logic was just split without correcting it for the new situation.
And yes - this implies that accessing the 8302 in this case does incur the same slowdown as accessing RAM.
In later versions the 8302 data bus was connected directly to the CPU data bus, but the internal decoding logic of the 8301 had to be circumvented by a piece of decoding logic inside the HAL chip.

Now, question (1) has an easy and a more complex answer.
The easy part is that the logic was made the simplest possible, though... I think Albert Einstein is credited with a saying that goes like this: things should be as simple as possible but not simpler than that. And this may be an example of 'simple than that', but without knowing how complicated the logic inside of the 8301 is, it is difficult to say for sure. If it was a CPLD or FPGA it would have needed very little added logic to free 8 out of 12 total cycles during vertical retrace, so the access to RAM would have been twice as fast. In the grand scheme of things, the difference is not massive, but a small calculation will reveal it is still just a bit more than what one would get by upping the CPU clock to the full 8MHz.
The more complex part has to do with refreshing of the RAM. As I mentioned before, QL uses DRAM and it requires refresh. The requirement is that all 256 rows should be refreshed (by one of several methods on offer) or at least guaranteed to be read, every 2ms. In other words, the complete set of row addresses must be cycled through tat least once every 2ms. Rather than perform explicit refresh, the 8301 relies on the sequential reading of the RAM when it's doing screen data reads, to go through all of the row addresses often enough. In the previous long post I have shown that there are a total of 56 unused lines, and since all 312 take roughly 20ms (19.96 to be exact), 56 take just about 3.5ms is longer than 2ms, so reading or explicit refresh must not stop during the invisible lines or the RAM will lose data.


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

Re: 8301

Post by Nasta »

Peter wrote:
Nasta wrote:For sure - although you then still have a big heap of inactive hardware that never the less consumes power and influences signal integrity. But that is a story for a later post.
Don't you think that keeping RAS and CAS quiet would have a great impact? (No need to answer separately if that's part of your upcoming post.)
You can keep CAS quiet but RAS should probably be cycled at some minimal frequency because it is used for the internal charge pump that biases the substrate, I am not sure these old RAMs can work without that. The power consumption would surely be much lower but since it's NMOS there is a rather high quiescent current draw. Also, the address multiplexer would have to be enabled which means they would at least have to constantly drive the address bus.
To be honest, if something like a 8301 replacement was designed, it would probably be a VERY good idea to include it on a re-designed (and at least partially form factor) compatible motherboard.


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

Re: 8301

Post by mk79 »

Nasta wrote:You can keep CAS quiet but RAS should probably be cycled at some minimal frequency because it is used for the internal charge pump that biases the substrate, I am not sure these old RAMs can work without that.
But wasn’t the point that these would not be needed anymore anyway if all RAM was on the 8301 replacement?
To be honest, if something like a 8301 replacement was designed, it would probably be a VERY good idea to include it on a re-designed (and at least partially form factor) compatible motherboard.
From a technical standpoint that is certainly true, from a retro-computer view I‘m not sure this is the case. The point there is to alter the hardware as little as possible, I think.

I‘d like a minimal replacement that doesn‘t do more than the original ZX8301 except outputting the screen as VGA 1024x512 with pixel doubling and line trippling, for example. Technically inferior but a cool way to keep the old machines working.

By the way, thanks so much for your texts, this is pure nerd porn. I think I must collect them one day in one big volume Image

Cheers, Marcel


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

Re: 8301

Post by Nasta »

mk79 wrote:
Nasta wrote: You can keep CAS quiet but RAS should probably be cycled at some minimal frequency because it is used for the internal charge pump that biases the substrate, I am not sure these old RAMs can work without that.
But wasn’t the point that these would not be needed anymore anyway if all RAM was on the 8301 replacement?
They are not needed but still on nearly all motherboards RAM is soldered on-board so not easy to remove. If they could be removed, sure, there would be no point in even putting any sort of signal on those pins. But since the RAM is there, as I said, I am not sure they like working powered up with no RAS cycling, yet signals present (again, no choice here as RAM is soldered on board and signals we would otherwise need are also connected to them). Of course I could be wrong, but the only thing it does say about this in the datasheet is that before the RAM will work as specified a few 'dummy' RAS cycles have to be performed.
To be honest, if something like a 8301 replacement was designed, it would probably be a VERY good idea to include it on a re-designed (and at least partially form factor) compatible motherboard.
From a technical standpoint that is certainly true, from a retro-computer view I‘m not sure this is the case. The point there is to alter the hardware as little as possible, I think.
I‘d like a minimal replacement that doesn‘t do more than the original ZX8301 except outputting the screen as VGA 1024x512 with pixel doubling and line trippling, for example. Technically inferior but a cool way to keep the old machines working.
You certainly have a point there. Also, for sure displaying the standard screen as a VESA compatible version would be foremost on the implementation list, and in fact that could be done even by adding line buffers to a clone of the existing logic - even with overscan correction. Lesser improvements: Optimized RAM access to get that few % of speed improvement, possibly two more screen areas (using /CAS1 - dead easy really) and perhaps a sort of packed pixel mode 16 (no extra video pins needed :P ).
By the way, thanks so much for your texts, this is pure nerd porn. I think I must collect them one day in one big volume Image
Cheers, Marcel
Always a pleasure :)


User avatar
NormanDunbar
Forum Moderator
Posts: 2251
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: 8301

Post by NormanDunbar »

By the way, thanks so much for your texts, this is pure nerd porn. I think I must collect them one day in one big volume
Or, on the QL Wiki? ;)


Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts

No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: 8301

Post by mk79 »

NormanDunbar wrote:Or, on the QL Wiki? ;)
I was more thinking about a bible so you can quote verses, like "Third Book of Zeljko, 5 to 10" :-D


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

Re: 8301

Post by Peter »

mk79 wrote:I‘d like a minimal replacement that doesn‘t do more than the original ZX8301 except outputting the screen as VGA 1024x512 with pixel doubling and line trippling, for example.
Most likely you mean 1024x768... and yes I would also just like a minimal replacement, so there is a decent video signal.

As soon as one starts to design a new motherboard, the temptation to put a full Q68-style system into the FPGA is just too big. ;)


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

Re: 8301

Post by mk79 »

Nasta wrote:* Small aside: depending on the version of the motherboard, the companion 8302 (and the IPC that communicates through it) can be on the RAM bus side or the CPU bus side. For instance, on ISS5 boards the 8302 is on the RAM side which means accessing the IO registers within it was subject to the same wait while the 8301 is accessing RAM. This changed on the latter boards with the HAL chip.
I don't quite see it. I'm looking at an issue 6 schematic with the HAL16 on the right side, but the ZX8302 DB0..DB7 lines are still connected to the RAM chips? Are there even later revisions (only got Issue 5 and Issue 6 schematics here).

Cheers, Marcel


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

Re: 8301

Post by Nasta »

mk79 wrote:
Nasta wrote:* Small aside: depending on the version of the motherboard, the companion 8302 (and the IPC that communicates through it) can be on the RAM bus side or the CPU bus side. For instance, on ISS5 boards the 8302 is on the RAM side which means accessing the IO registers within it was subject to the same wait while the 8301 is accessing RAM. This changed on the latter boards with the HAL chip.
I don't quite see it. I'm looking at an issue 6 schematic with the HAL16 on the right side, but the ZX8302 DB0..DB7 lines are still connected to the RAM chips? Are there even later revisions (only got Issue 5 and Issue 6 schematics here).

Cheers, Marcel
Yes, same here, but I remember tracing this (not sure... Samsung motherboard?) when I was designing Aurora. On it the 8301 is directly on the bus. Also, there is a GAL replacement of the HAL with equations, which also suggest the same thing. There is really no reason for it to be on the RAM side, nor for using the 8301 /PCEN decode, since the HAL does it all over again (and uses, or I guess CAN use the 8301 PCENL pin as well).
BTW there are other quirks to do with how PCENL is decoded - it is generated inside the 8301 using DSMCL (which is actually DSL from the CPU) and also uses DSL on the 8302. I remember being quite puzzled by this and tried just pulling DSL on the 8302 low, and guess what, it worked just fine (though I cannot guarantee it will work on every motherboard and every 8301 version, though). So in essence there is a redundant pin on the 8302... and, for that matter on the 8301 (though it's not obvious).
BTW 8302 bus logic is completely asynchronous and it can work with a much faster 68008 bus, no problem.

In any case, if the 8301 DSMCL signal is used to decode 8302, then it MUST be on the RAM side of the bus because 8301 enables the bus buffer via /TXOE when PCENL goes low. On write it would not make a difference, but if the 8302 was on the CPU side, on read the 8301 would enable the buffer expecting data to go from the RAM side bus (expecting 8302 to supply data there) to the CPU bus.
It's a little bit odd, given that they could have put almost any logic into the HAL given the few input and output signals and their simple relationship to clean up the design, but failed to do it on the first revision that had the HAL.


Post Reply