8301

Nagging hardware related question? Post here!
Nasta
Gold Card
Posts: 265
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: 8301

Postby Nasta » Wed Aug 08, 2018 1:42 am

Peter wrote:
mk79 wrote:I‘d like a minimal replacement that doesn‘t do more than the original ZX8301 except outputting the screen as VGA...

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


Hehe yes, that is true, but then if you look at what people have been doing with Spectrum clones, it comes down to what path you want to take. For instance, if a FPGA replacement was made I would not be against, say, implementing faster RAM access, modern monitor compatibility and perhaps some minor improvements which could be argued to have been easily possible when the QL was originally made.
My gripe with the motherboard would be components that are problematic to replace or remove when they fail (in this case it would be RAM), and signal integrity. After all I just re-used the 8302 and IPC on the Aurora :P


Derek_Stewart
QL Wafer Drive
Posts: 1139
Joined: Mon Dec 20, 2010 11:40 am
Location: Runcorn, Cheshire, UK

Re: 8301

Postby Derek_Stewart » Wed Aug 08, 2018 8:57 am

Hi Nasta,

Wold it be possible to design a replacement 8301 that does exactly performs the current 8301.

I ask this mainly due there maybe a problem sourcing working 8301 chips. Since there are still many people using a BBQL that relies on the 8301.


Regards,

Derek
User avatar
Peter
Super Gold Card
Posts: 727
Joined: Sat Jan 22, 2011 8:47 am

Re: 8301

Postby Peter » Wed Aug 08, 2018 10:11 am

Nasta wrote:My gripe with the motherboard would be components that are problematic to replace or remove when they fail (in this case it would be RAM), and signal integrity. After all I just re-used the 8302 and IPC on the Aurora :P

Yes, a QL motherboard replacement for obsolecence, signal quality and repair reasons could make more sense than I first thought.

Probably there are a lot of non-working QLs with intact black box, CPU and microdrives. If I one can buy a replacement motherboard, simply re-seat the 68008 and voila, system works, this could sell well. However, I think that success would depend on a strict "retro" approach, i.e.

- Easily and directly fit original case and mebrane keyboard
- Ability to run with 68008 and 128 K RAM
- Support microdrives
- Keep external connectors where they were

This could distinguish it sufficiently from the Q68 approach. Still it would be a huge amount of work, bringing back the idea of a 8301 replacement as a more straightforward solution. If I could get a 8301 replacement with modern video, I would immediately buy it! :D


Derek_Stewart
QL Wafer Drive
Posts: 1139
Joined: Mon Dec 20, 2010 11:40 am
Location: Runcorn, Cheshire, UK

Re: 8301

Postby Derek_Stewart » Wed Aug 08, 2018 10:32 am

HI Peter,

A many years ago a friend fitted his Aurora and Super Gold Card into a BBQL Case and made a Membrane connector to the QL keyboard.

I was going to make some Auora board and produce a Schon style keyboard to connect to the Aurora and use a Super/Gold Card.

But never quite around tthis.

I have 2 x Auroa boards to repair, so, maybe I will make a protype.

I would also like to see a replacement 8301, that can plu directly into the QL board and produce the same video display, with possible future enhancements to modern display modes.


Regards,

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

Re: 8301

Postby Nasta » Wed Aug 08, 2018 11:01 am

The thing with the 8301 is that it is not that fragile itself, but other components and situations not really under it's control WILL kill it. For instance, RAM problems such as shorted address and control pins or dead chips that internally short pins will kill the RAM address/control pins. They are quite robust but also the highest current thing on that chip (RGB and the synch signals may be of the same size, not absolutely sure though) - abuse them long enough and the chip will die a heat death.
And then there is the classic static discharge to any of the monitor signals.
I did consider a replacement motherboard, actually made a wire wrapped one a long time ago using a 68008FN.
The idea would be of course to fit it into the original case, with the usual connectors in their familiar places, with some minimal exceptions (like original 'mirrored BT' joystick and serial ports... really??? I hated those with passion), or external MDV connector.
BUT - absolutely it would have some improvements, like proper buffering on the monitor lines, and joystick ports. Old chips that can be safely replaced would be - use a 67008FN and good socket for the ROM(s) or EPROM, and even a flash chip on board. Optimize the 8301 using 128k SRAM (which in today's context costs ~nothing) for shadowing and one single RAM chip (yes there is a nice one that fits just right, and it can actually be used to implement the entire 128k). This would also make it possible to implement a 'turbo mode' with 68008 running completely asynchronously clocked from the 8301 and with potentially a higher clock rate.
Make it low power, i.e. HCMOS logic where needed, and include a switching regulator that can run the whole thing off of 9V only, with power for serial port(s) being generated on board.
Place things so that the keyboard membrane fits as usual. If I could get Lau to release the Hermes code to the public domain, even using a PLCC 8749 chip for the IPC would be interesting.
The reason behind this would be that the board can be made VERY small, though somewhat odd shaped, but it makes it possible to retract the expansion connector quite a bit further inside so some expansions would fit inside entirely and keep it all neat.
The one thing I would make optional are microdrives, though.
Dave did design a MDV replacement board that makes it much more reliable WRT signal integrity but the only way to use this is to unsolder and then re-solder two critical components, the ULA and the R/W head, and neither is an operation guaranteed to work :(


User avatar
Peter
Super Gold Card
Posts: 727
Joined: Sat Jan 22, 2011 8:47 am

Re: 8301

Postby Peter » Wed Aug 08, 2018 1:00 pm

Nasta wrote:The one thing I would make optional are microdrives, though.

While the rest sounds good, I'm a bit sceptical to remove microdrive support. The demand will mainly come from people who want the possibility of full "retro" usage.
Even I keep at least one microdrive intact in my original QLs, and have a collection of cartridges. Not that I use them much, but I'd like the option.


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

Re: 8301

Postby Nasta » Thu Aug 09, 2018 10:39 pm

OK, let me slowly wrap this up...

Here is a schematic symbol of the 8301 with correct pin-out:
8301.gif
8301.gif (7 KiB) Viewed 369 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 :P ). 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 :)
Last edited by Nasta on Fri Aug 10, 2018 3:21 pm, edited 1 time in total.


User avatar
mk79
Trump Card
Posts: 233
Joined: Sun Feb 02, 2014 10:54 am

Re: 8301

Postby mk79 » Fri Aug 10, 2018 12:31 am

Nasta wrote:
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.
You remember correctly :) I checked with my QLs, all Samsung (un)fortunately, and they all have the ZX8302 on the CPU data bus. So at least for that generation the schematics is wrong. But there are other faults, too, like still referring to IC27 even though it doesn't exist on Issue 6 anymore. I noticed this and other things are fixed in the re-drawnPDF schematics (the style looks like Tetroid?) but that still has the ZX8302 on the RAM bus.

Cheers, Marcel


User avatar
Peter
Super Gold Card
Posts: 727
Joined: Sat Jan 22, 2011 8:47 am

Re: 8301

Postby Peter » Fri Aug 10, 2018 9:52 am

Nasta wrote:DB0..DB7 - input - RAM (and in most cases 8302) data bus, connects to the CPU data bus using a 74LS245 bus buffer.

In case of a "modern" FPGA 8301 replacement with sufficient RAM, I would make DB0..DB7 bidirectional, not input.
Keeping /RAS, /CAS0, /CAS1 and /WE inactive should be sufficient to keep the QL DRAMs at lowest possible power and off the data lines (except pin capacities).
Quotes 4164 data sheet:
"The data output is in the high−impedance (floating) state until CAS is brought low."
"RAS is similar to a chip enable in that it activates the sense amplifiers as well as the row decoder."

/TXOE would only control data buffer direction between CPU and 8301 replacement.
DA0..DA7 would only be used by the FPGA to read the CPU address bus, selecting upper or lower part by /ROW.

Biggest question for me would be if the QL monitor signal pins should be implemented at all, or only a separate VGA signal path.
Second biggest question whether to use FPGA internal PCI clamp diodes plus series resistors, or level shifters.

Signal quality issues would likely come up, but I'm relatively confident that digital filters on the FPGA inputs would be sufficient to deal with them.

Quite tempting to do it, if there wasn't unfinished Q68 ethernet and cache work, etc.


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

Re: 8301

Postby Nasta » Fri Aug 10, 2018 3:27 pm

mk79 wrote:
Nasta wrote:...I remember tracing this (not sure... Samsung motherboard?) when I was designing Aurora. On it the 8301 is directly on the bus.

You remember correctly :) I checked with my QLs, all Samsung (un)fortunately, and they all have the ZX8302 on the CPU data bus. So at least for that generation the schematics is wrong. But there are other faults, too, like still referring to IC27 even though it doesn't exist on Issue 6 anymore. I noticed this and other things are fixed in the re-drawnPDF schematics (the style looks like Tetroid?) but that still has the ZX8302 on the RAM bus.
Cheers, Marcel


Yes and there are some discrepancies regarding the HAL chip as some signals are unused on the ISS6 board, but would have to be on the Samsung board for the 8302 to be on the CPU bus side (like gating off /TXOE when the 8301 detects the 8302 Io addresses). I did not go tracing those as it is obvious from the logic what it's supposed to do, an it does actually work, so I guess it's also doing it :)



Return to “Hardware”

Who is online

Users browsing this forum: No registered users and 3 guests