OK, let me slowly wrap this up...
Here is a schematic symbol of the 8301 with correct pin-out:
- 8301.gif (7 KiB) Viewed 3690 times
So, here is formal description of the pin functions:
RAM signals:
DB0..DB7 - input - RAM (and in most cases 8302) data bus, connects to the CPU data bus using a 74LS245 bus buffer.
DA0..DA7 - input/output* - multiplexed RAM data bus, the CPU address bus connect to these via a pair of 74LS257 multiplexers, more below.
/RAS - output - RAM /RAS signal (row address select), latches the row address into the RAM roughly on it's falling edge.
/CAS0 - output - RAM /CAS signal for the low 64k of RAM (RAM bank 0), latches the column address into the RAM
/CAS1 - output - RAM /CAS signal for the high 64k of RAM (RAM bank 1), latches the column address into the RAM
/WE - output - RAM /WE, write enable signal (latches the write dada if low when either /CAS goes low). Remains high to read data.
CPU-RAM bridge control:
VDA - output - Video Display Address, when high it disables the multiplexed CPU address provided from the pair of 74LS257, and makes it possible for DA0..DA7 to drive the RAM address bus.
/ROW - output - Selects the row (low) or (column) part of the CPU address bus using the pair of 74LS257 multiplexers.
/TXOE - enables the bus buffer between the RAM and CPU data bus, so the CPU can pass data to and from the RAM and 8301.
Monitor signals:
R, G, B - output - pixel color components (digital), encodes one out of 8 colors.
/CSYNCH - output - composite synch (active low). This generates a low pulse once every display line (horizontal synch), but also encodes vertical synch by changing polarity when VSYNCH (below) is active. Horizontal synch pulses can be separated out of /CSYNCH by feeding /CSYNCH and VSYNCH into an EXOR gate.
VSYNCH - output - Vertical synch (active high) outputs a high pulse for a few display lines to re-trace the CRT to the top of the screen and start a new frame. It also generates an interrupt to the CPU.
CPU/System interface signals:
A16..A17 - input - CPU address lines A16, A17 which decode the basic 4 blocks of 64k containing the ROM, IO, RAM bank 0, RAM bank 1.
/DSMC - input - essentially the master chip select of the 8301 (and thus the QL motherboard), connected to the CPU /DS signal (which goes low when the CPU provides or expects data, and thus signals that an access is in progress). The QL does not use /AS, and assumes that the address bus is stable whenever /DS is low (which it is). More below.
/WR (RDWL) - input - Signals the direction of data transfer, low = write (CPU provides data), high = read (CPU expects data).
/DTACK - output - Data Transfer ACKnowledge, goes low when the 8301 signals that the operation requested by the CPU has been completed. It also uses it to extend the cycle while it's reading RAM to generate the display. As mentioned before, the 8301 expects the CPU to use the clock the 8301 supplies it so that it can work in lockstep with the CPU, to anticipate what the CPU will do, so it actually supplies the signal before the data is ready when RAM is being read. When the ROM is being read (or write cycles are generated to it's addresses), it goes low with /DSMC.
CLK (CPUCLK) - output - 7.5MHz clock generated by dividing the 15MHz 8301 clock by 2. It is expected to drive the CPU clock input.
/PCEN - output - goes low when the 8302 is to be selected, the basic condition is A17=0, A16=1, A6=0, /DSMCL=0. This may be an open drain signal since it is pulled up by a 2.2k resistor, however I have not checked this. The decoding mechanism in the 8301 expects the 8302 data bus to be connected to the RAM data bus so /PCEN is also only low when VDA is low.
ROMOE - output - goes high when the ROM is to be selected, the basic condition is A17=0, A16=0, /WR=1, /DSMCL=0.
Clock signals:
XTAL1 - input - crystal oscillator amplifier input (non-TTL), connects to XTAL2 through a 15MHz crystal and 1M resistor, also to ground via 22pF cap.
XTAL2 - output - crystal oscillator amplifier output (non-TTL), see above. It is possible to get a 15MHz clock by connecting a HCMOS buffer input to this pin and buffering the signal.
Still, there are a few things left unexplained, so let me explain
1) How are the RAM address lines multiplexed?
We can get this from the wiring of the 74LS257 multiplexers. So here's how it's done:
RAM DA0 = A2 (Row), A0 (Column)
RAM DA1 = A3 (Row), A1 (Column)
RAM DA2 = A4 (Row), A5 (Column)
RAM DA3 = A7 (Row), A6 (Column)
RAM DA4 = A8 (Row), A12 (Column)
RAM DA5 = A9 (Row), A13 (Column)
RAM DA6 = A10 (Row), A14 (Column)
RAM DA7 = A11 (Row), A15 (Column)
Just for reference, the RAM data bus (and the 8301 data bus) DB0..DB7 maps directly to the CPU data bus D0..D7.
It may be a bit odd that the address lines are somewhat 'mixed up', considering the RAM is organized in rows and then the bit is selected out of a row, one could expect to see the CPU high address lines in the row address and low address lines for the column address. However, this 'strangely' mixed up organization does make some sense.
First, one has to note that RAM address and data lines can be premutated. What this means is that you can connect any address line of the CPU to any address line of a RAM in any order, and the same for data lines - the labeling does not have to be strictly followed - A76543210 xan be passed as eg. A03257614 to the RAM. Any permutation will actually work because although this changes the actual address inside the RAM the data is stored, it is always a one-to-one mapping, and the data is always read from the place it is written as long as the address is the same. The same is true for data lines - the data bits may be scrambled on write, but they are de-scrambled right back on read. It works as long as only one thing writes and reads data, such as the CPU. If there is another device reading from the RAM and expecting a certain layout of the data, the permutation has to be equally applied, so the 'scrambling' of data bits and addresses is the same.
One might as why this would be useful, and one obvious answer is to simplify PCB routing - note that even just on the 8301 the data and address pins do not go strictly in sequence. However, it is sometimes useful when it is known that data may be regularly read is sequence, as it is in the case of refreshing the display.
I have mentioned the need of the DRAM (which is what the RAM type in the QL is) to be periodically refreshed. This is actually done by reading, either explicitly (data is used for something) or implicitly (only the /RAS signal goes low internally reading data but it is never output to the pins, instead only written back when /RAS goes high again). The latter is called a '/RAS only refresh', not very creatively but to the point
.
* Aside: it is of course the write-back that does the actual refresh of the DRAM data, and it happens regardless of what kind of access is performed, including of course write, which does write new data to some part of a previously read row (depending on the column address) but for all other parts existing data is written back. When read, the data just read is written back. On the QL this is not relevant but in some applications data can also be sequentially written, and this can also be used as a refresh mechanism.
The refresh requirement is that all 256 rows must be accessed at least once within 2ms (Newer RAMs are much better and even 16ms figures are fairly common, but the capacity is higher so there are more rows to refresh ecen if the time limit has been improved). Since the 8301 reads data sequentially, it uses the fact that the address it reads increments sequentially and tries to map appropriate display RAM address bits to row address bits to satisfy the refresh timing.
It has to keep A0 and A1 as a column address as cycling these through the 4 possible combinations of 00..11 addresses 4 consecutive bytes (one long word) and this is used to change the column address inside the same RAM access cycle to exploit faster access times and get 4 sequential bytes out of the RAM in time it would normally take for 2 random bytes.
The 8301 also outputs the entire screen worth of data (32k) in 16.384ms, which means it goes through 8k long words within that period of time. Remember, we must look at long words as this is what the 8301 actually reads (as 4 consecutive bytes) so out of the 15 total bits (A0..A14, which is what we need to describe one out of 32k addresses), the bottom 2 must be used as a column address, therefore we are left with the top 13 bits, which effectively address long words within the screen RAM. If we look at how often the address bits change state when we count up from 0 to 32768 (or 32k), we can start with the obvious - the very top one, A14 goes through both states once in the whole 16.384ms cycle. The next one down, once in 8.192ms, the next one down in 4.096ms, and again the next one down, bit A11, once in 2.048ms - which is JUST shy of the 2ms requirement but is actually enough as the spec is given under absolute worse conditions of temperature and operating voltage. So, this gives us the top address bit we can use as a row address, and all the others have to be of lower significance, if we want to be sure that reading the screen data will absolutely go through all the 256 rows at least once in, in our case, 2.048ms.
All the higher bits, A12 up to A15(*) must be used as a column address (along with the already established A0 and A1), so bits A2..A11 can be freely distributed to the row or column address without breaking the refresh requirement.
* Small aside: 2.048ms rather than 2ms or slightly below might be another subtle clue that the design may have originally been intended to run the CPU at 8MHz, i.e. run the logic at 16MHz. Calculations would show that this precisely meets the requirement to fit the visible pixels of a display line into a 48ms period, which is a pretty major clue.
As we can see in the above mapping table, the row address bits map to CPU/8301 internal address bits A11, A10, A9, A8, A7, A4, A3, A2. That being said, it's quite obvious that we can chose 8 out of 10 bits, so whichever combination we chose, any 8 bits out of 10 will cycle 4 times within the chosen 2.048ms interval (as the extra 2 bits have to go through 4 states without that being reflected in the row address, but rather in the column address). So, in fact, every row is refreshed 4 times - hence the refresh requirement is not only satisfied, but the RAM is 'over-refreshed' by a factor of 4. This could have been used to some advantage, but more on that later.
2) How does the 8301 know to select the 8302 inside the IO area but only when A6=0, when there is no A6 pin?
Well, this is a 'tricky' one which might have cost the designers one extra pin. The clue is in the state of the /ROW pin when A17=0 and A16=1, i.e. the IO area is accessed. If we look at the first signal trace, when the 8301 reads the screen and the CPU writes it, we can see /ROW is used to switch over the CPU address multiplexers from row to column address, the determining factor being address line A17, which is 1 if RAM is being accessed.
However in the second trace, A17 is zero and /ROW is high, meaning the column address, or rather, as explained above, CPU addresses A15, A14, A13, A12, A6, A5, A1, A0 are present on the RAM address bus. Well, when A17 is 0, the DA0..7 lines of the 8301 become inputs and are used as inputs to a decoder that further decodes /PCEN to only be active when A6=0. There are some differences on what other lines are used depending on ULA version, so in some cases A15 and A14 are required to be 1 and 0 respectively for the 8302 and for that matter 8301 to be selected. On others, only A15 must be 1, on yet others A15 and A14 are don't care. There is more to be said on this subject, see below.
What is not obvious here is that this is a very strong clue the 8301 and 8302 started life as a single design. Astute enough readers might just have realized that the 8302 'incidentally' uses address bits A0, A1 and A5 to do it's internal decoding, and lo and behold exactly those bits (out of many possible combinations that could have been used) appear in the column address for the RAM bus, and are passed to the 8301. If you connect the 8302 entirely onto the RAM data and address bus knowing about this (not using the HAL chip logic), and tie /DS on it low, it works just fine.
* Aside: this choice of address lines comes with a price, which is not obvious - one extra pin, namely /ROW is needed. This is to differentiate it's function from /RAS, which is often used to switch over the DRAM address multiplexer, along with doing it's standard DRAM function - because the multiplexers are not infinitely fast, the row address is presented when /RAS is high and will reman a bit after /RAS goes low, which is long enough to satisfy the row address hold time for the DRAM (the time the row address has to stay on the address bus once /RAS went low - this is actually usually zero for most DRAMs so that's easy to satisfy
). With this arrangement /ROW is needed to present the column address without /RAS going low. The irony is, this pin could have probably been avoided anyway as only /RAS going low will just refresh an address in RAM (no harm done except a bit of power usage) and there is more than enough time for either the 8301 or 8302 to be accessed during /RAS being low and abiding to DRAM timing.
Alternatively, as was shown under (1) other address line mappings to row and column addresses could have been used. It seems, however, that the designers got stuck on using A0, A1 to select internal 8302 registers which are part of the column address. Ironically the only time they are used is to read the real time clock seconds counter as a long word, which is REALLY not something that happens often - it could have just as well be read as a sequence of bytes from other addresses. This would have made it possible to use the row address bits to transmit the required address bits for decoding so /RAS could remain high if it was also used to select the row/column address.
3) How does the 8301 decode and use it's one and only control register?
Well, the display control register (usually referred to as MCR, master chip control register) is a write only register that actually has only 3 bits. It is normally accessed at $18063 (hex address, to make it clear) but has many aliases inside the IO area. As was already mentioned, depending on 8301 version, these aliases may take either the entire 64k block starting at $10000, 32k, or 16k starting at $18000. The aliases happen because not all address bits are used for decoding the actual hardware register so all addresses where only the used bits are taken into the decoder will access the same hardware.
A lot of this has already been said above, so essentially the 8301 looks for /DS=0, /WR=0, (A17=0, A16=1), optionally (A15=1;A14=0), A6=1, optionally A5=1) and A0,A1=1. Using $18063 satisfies all of these conditions including the options. The register is write only and attempting to read should be considered to produce random data. From this it also follows that the RAM data bus pins on the 8301 are always inputs as it only ever gets data either from RAM (when generating the display) or from the CPU via the bus buffer, when MCR bits are being written.
Only bits 1, 3 and 7 are implemented:
Bit 7 selects the screen area, known as screen 0 (when 0) and screen 1 (when 1) - this actually appears as address bit A15 in the multiplexing scheme when the 8301 is supplying the multiplexed RAM address.
Bit 3 selects the resolution. Plenty has been said about this elsewhere. Suffice to say that if it is 1, it concatenates two successive mode 4 pixels into a 4-bit pixel with 3 bits used for the RGB components and one as a flash toggle. The hardware does this after RAM data has been serialized into mode 4 pixels.
Bit 1 blanks the display when 1, but, as has been shown, this does not stop the 8301 from 'reading' the screen RAM even if it is disregarding any actual data. I would consider this a missed opportunity, even though it would be reminiscent of the ZX81's 'fast' mode
- more about this in the final installment.
So... next and finally: how could it have been improved without significant complications, and perhaps guidelines for a re-implementation