Expanding the QL's address space beyond 1M (+primer on building QL compatible machines)

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

Re: Expanding the QL's address space beyond 1M (+primer on building QL compatible machines)

Post by Nasta »

Added RAM

Once the idea of extra RAM included on the motherboard is on the table, two obvious questions arise, which are what kind of RAM and how much. These are actually connected because of the available packaging and price the RAM comes in.
In general, we are dealing with two types of RAM chips:

1) Static RAM (SRAM)
When the QL was introduced, this type was mostly limited to small amounts of fast and/or very low power RAM, with a rather prohibitive price per bit of storage. Things have changed since, because the amount of storage a given unit of price buys has grown larger, due to the memory density of the chips increasing rather dramatically. These days it's rare to even think in terms of less than a single 512k byte chip.
The great advantage of static RAM is that it is almost trivial to interface with the CPU, it is generally quite fast and also low power. One problem in implementing a larger size memory is that the number of chips needed, while not too expensive, might require buffering, or, if higher density chips are used to lower the number of chips needed to avoid buffering, increases the price. One limiting factor regarding SRAM density is the chip's power supply voltage. Given that the rest of the QL circuits function with 5V supply and the signals also use that voltage, interfacing with high density, 3.3V powered SRAM chips requires extra parts, possibly negating the savings on price. At the moment 5V power SRAM chips are manufactured with a capacity of 1 Mbyte, or, less often, 2 Mbytes.
Even the slowest SRAM chips with sensible density are a LOT faster than needed to support the 68008FN CPU at the standard 7.5MHz frequency.

2) Dynamic RAM (DRAM)
This is the original RAM type used in the QL and almost all other computers, vintage or otherwise. Compared to what was available back then, todays DRAM densities are staggering, but interfacing is not at all trivial, and possibly even not compatible. That being said, there were many steps in DRAM development and 5V powered parts of appropriate capacity can still be found. In fact, the most logical path would be to simply implement a full 4Mbyte of RAM if DRAM is to be used as this is only two chips, even though that covers the entire address space. That being said, they are not trivial to interface, and extra parts are needed, plus power drain is far higher than comparable SRAM - but not at all excessive, since only two chips are needed - these would need about the same power or less than two of the original QL RAM chips - and there were 16 RAM chips in the original computer.
The (slight) disadvantage of suitable DRAM chips is the need to have multiplexed address lines, so some multiplexer chips are needed. The up side of that is the multiplexers are also buffers so no problem with adding more chips, although in the design being considered, this advantage is not used given there are only two DRAM chips.
The bigger disadvantage is the requirement to refresh the DRAM content periodically. This means the RAM is periodically not available for a very short time, while refresh is performed, which requires extra logic to interface with the CPU, that 'steals' the CPU's bus to refresh the RAM. Doing this efficiently in essence means some sort of small programmable logic device - which may not be such a problem given that we already need something of the sort to implement the 'superHAL' decoder. When all the circuitry is considered, the actual RAM chips are a small part of the total cost.

Given the above, it s obvious that the DRAM solution easily supports RAM size equal to the entire address range. In that case, the decoding scheme could be viewed as exactly the opposite of what one would normally expect - instead of the decoder decoding where the RAM is in the address map, it decodes where it isn't and where something else is instead. Since by default it covers all addresses, advanced features such as ROM and RAM shadowing come to mind.

ROM shadowing

This concept is better illustrated by the complete name: RAM with shadow ROM. What this does is emulates RM using a ROM copy in RAM, at the same address. As we know, no two devices that can be read should ever occupy the same addresses because they will both attempt to output data what the CPU accesses that address for reading, causing data bus contention and data corruption. Which is why this never happens - the idea is to copy contents of a ROM to RAM which will at some point reside at the same addresses as the ROM initially did. There are many ways to do this, depending on the specifics of the situation. In our case, it is interesting t have the ROM mapped at the lowest addresses to start up the machine and then copy the ROM to 'shadow' RAM, and then replace the ROM with RAM holding a copy of the data from the ROM, which is also write protected. One way to do this is to map the ROM at it's usual addresses, and have it respond only to reading, while at the same time mapping the RAM to the same addresses, but only for writing. Since the CPU can only either read or write, the ROM and RAM are never really selected together even though they occupy the same address. To copy the ROM to RAM, one reads every ROM address only to write the data back to the same address, until the entire ROM is thus processed. At this point, the decoding is changed so that the ROM is never selected any more and instead the RAM is now read from the addresses rather than written (the latter to protect the contents). There is a small problem, and that is the RAM where the ROM also needs to be tested before data is written to it to insure it actually retains the data. There are various ways to do this but let's for a moment put this t the side. When the ROM is exchanged to it's copy to RAM, the CPU is none the wiser. Of course, before this switch is done, patches can be applied, and of course, it may be possible to also temporarily disable write protect so the the contents of the emulated 'ROM' can be changed.

RAM shadowing

This concept is to an extent almost exactly the opposite of the previous one. In this case, data is written to two RAM devices that are mapped to the same address for writing, but is read only from one. As was said, itćs only reading that can cause contention if two devices occupy the same address, and since only one 'copy' of RAM is read, there is no danger of that at all.
There are various reasons why one would want to do that, but one is extremely pertinent to our proposed design, and it's goal is higher speed. Particularly it has to do with screen RAM. This is normally controlled by the 8301 ULA and as already mentioned, there is a large speed penalty involved in accessing it. RAM shadowing can get around this to a large extent by adding fast 'shadow' RAM at the same address as the screen RAM, the idea being that data is written to both - at which point the slower one determines the writing speed - but read only from the shadow RAM which is much faster.
As was already mentioned, the CPU spends in general much more time reading than writing, so statistically there is a good chance of a significant speed-up even if only reading is performed at full speed.
In fact, if this is implemented, and there is sufficient RAM available, the second bank of 64k RAM normally controlled by the 8301 should not be used at all, i.e. the 8301 should not be selected for those addresses, instead only the fast extra RAM should be mapped there. Reason being, the only function we need from the 8301 once sufficient extra RAM is available, is displaying the screen, for which it needs data to be written to the relevant RAM addresses, so it can read it and output it to the screen. It does not care where the CPU reads it from :P


Post Reply