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

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

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

Post by Peter »

tofro wrote:
janbredenbeek wrote: The idea that the designers probably had in mind was to use SER1 to drive the printer and SER2 for modems or other communication.
And that wasn't too much of a bad idea when the QL was designed.
It appears to me that one parallel port instead of the second serial was a much better idea, even at design time.
I remember to have tinkered a parallel port for the Spectrum back then - much easier than a second UART.


User avatar
bwinkel67
QL Wafer Drive
Posts: 1187
Joined: Thu Oct 03, 2019 2:09 am

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

Post by bwinkel67 »

Brane2 wrote: It would be interesting to see what exactly did Clive actually design by himself.
I think he did early miniature electronics design work with Sinclair Radionics when it was selling tiny audio amps, etc... I would expect, similar to Steve Jobs, that Clive's role was less hands on and more direction/vision of his company during his time with Sinclair Research.
Brane2 wrote: Microdrive was designed by Acorn or Commodore at some point IIRC.
Excerpt quote by author Dr. Ian Logan, from his 1983 Spectrum Micorodive Book: "...work on Microdrives was done by Martin Brennan and Ben Cheese of Sinclair Research."


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

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

Post by Peter »

Nasta wrote:The 16550 was an 'improvement' which actually had a set of it's own problems but the main star of the show was a 16-byte receive and transmit FIFO.
That's mildly put. If I remember correctly, the 16550 was so buggy that the FIFO could not be used at all. National Semiconductor later released the 16550A for that reason.
Nasta wrote:An alternative would be to use one of the 68k or Z80 derived serial chips, the down side on some is limited baud rate support and much smaller input FIFOs but the up side is that all of them implement proper hardware handshake.
On the Q68, I had to omit hardware handshake because there was absolutely no FPGA pin left. Not nice in theory, but worked perfectly up to 115200 Baud, e.g. massively tested with SERNET.
It is easy to increase FIFO size from the 16 Bytes of the Q68 to several Kilobytes for a slower CPU. Wouldn't a simple, no handshake FPGA UART with a huge FIFO be all a QL needs?
Or does it have to be an old UART chip for the retro feeling?


User avatar
Andrew
Aurora
Posts: 786
Joined: Tue Jul 17, 2018 9:10 pm

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

Post by Andrew »

bwinkel67 wrote:
Brane2 wrote: Microdrive was designed by Acorn or Commodore at some point IIRC.
Excerpt quote by author Dr. Ian Logan, from his 1983 Spectrum Micorodive Book: "...work on Microdrives was done by Martin Brennan and Ben Cheese of Sinclair Research."
In his 1985 book, The Sinclair Story, Rodney Dale, a one-time Sinclair Research employee, claims Sinclair product head, Jim Westwood, and Sinclair’s Chief Engineer, David Southward, jointly conceived the Microdrive in 1982. But the original idea might have been Andrew Grillet's.
Sinclair had an early introduction to the notion of tape-loop storage in the summer of 1974. A young engineer called Andrew Grillet, who had indirectly done some work for Sinclair Radionics through a stint at one of its sub-contractors, was interviewed for a job with the company. According to Grillet, when told that Sinclair was “going to build a computer” and asked what he ideas might bring to the project, he proposed a data-storage system based on the eight-track music cartridge popular in the early 1970s before Philips’ Compact Cassette format took hold.

“This would be an ideal thing,” Grillet recalls telling the Sinclair staffers, “because you could do roll-out, roll-in swapping. You’d need to have the tape shortened so you had two 64KB memory images on the track only, so you dump one and read the other, or at least if you had to wait for it to go round and switch to another track you wouldn’t have to wait too long.

“And that’s basically what the Microdrive was, except the eight-track cartridges were enormous and they shrunk the cartridge down a bit.”

Speaking to The Register nearly 40 years on, Grillet doesn’t remember who he was interviewed by at Sinclair, but they were impressed by his abilities and ideas: he was subsequently offered a job, “but Xerox offered me twice as much money, so I went to work for Xerox”. He thought no more about the tape storage system until April 1982 when Sinclair Research announced the Microdrive. In his 1985 book, The Sinclair Story, Rodney Dale, a one-time Sinclair Research employee, claims Sinclair product head, Jim Westwood, and Sinclair’s Chief Engineer, David Southward, jointly conceived the Microdrive in 1982. That was eight years after Grillet’s interview. Were these men his two interviewers, and had his notion remained hidden in the back of one or the other’s mind until a new need to deliver a better-than-tape, cheaper-than-diskette format arrived? We will probably never know.

Grillet wasn’t the only one to come up with the notion of looped tape storage. In 1979, Sunnyvale, California-based Exatron began pitching what it called the “Stringy Floppy”, a $100 device which took its own endless-tape cartridges, which Exatron called “Wafers”. Each wafer could hold 70KB of data on a loop of 1/60-inch tape. The company claimed 16KB programs would load “in less than 20 seconds”. Exatron launched the Stringy Floppy system for Tandy’s TRS-80 micro.
Back at Sinclair, David Southward, who oversaw Sinclair Research’s work on peripheral devices, took overall control of the Microdrive project in 1982, and put the analogue electronics work in the hands of Ben Cheese, an Electronic Design Engineer.
Meanwhile, over at Sinclair’s King’s Parade office in Cambridge, the company’s industrial designer, Rick Dickinson, worked on the look of the drives and the cartridges.
The ZX Interface 1, which would connect the Microdrive to the Spectrum, was engineered by Martin Brennan, who came to Sinclair Research in late 1982, having been offered an open-ended engineering role with an emphasis on artificial intelligence design by Nigel Searle on the back of his work on games software. This was seven or eight months after the drive had been announced.


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 »

Brane2 wrote:
Nasta wrote: Before I move on to the 8302 ULA, a new build based on the old components should definitely also incorporate the following:
IS it worth it, though ?

This means heaps of work to reimplement somewhat less broken form of half-assed solutions, just so that the user can choose to change ULA2 or IPC separately...
...
But, if you ask me, I'd go one step further and lump ULA1 into the upgrade kit.
And EPROMs.
Yes, one would replace most of the chips.

But s/he would keep the form as it was meant to be used at the time.
Minerva isn't that new and it was meant as a QDOS as is it shoudl have been implemented.

Since we have source avaialble, it shoulnd't be a problme to change/expand it for extra goodies.
Agreed in principle but at the moment this is out of the scope of this thread. I would much welcome opening a new one that discusses a possible IPC+8302 replacement.
8301 upgrade is practically a must. While stuff connected to the IPC/8302 combo mostly came with the machine, or is still some sort of a standard and available, the video monitor never did and these days finding one that works, and this includes LCD TV sets with compatible inputs, is a real problem - and one which is only going to get worse.

All that being said 'relatively simple' is just what it says, 'relative'. If it was that simple to re-create the 8302 and IPC, I am sure it would have been done already. Even doing Hermes is a feat, and I know for a fact how difficult it was to do superHermes as I was involved with some of it's hardware aspects and just from the little feedback I got from Lau and Tony... it was anything but simple. To make it worse, some aspects of ULA2 internal workings are not known and still need to be reverse-engineered, specifically how it serializes and deserializes the data from the microdrives.
8301 ULA is almost the opposite, quasi low hanging fruit one could say as man different implementations are possible as long as the memory map and the few bits in the one control register are there.
One can certainly argue that it may be a far better idea to re-implement high level functionality, preferably with more added in, and then circumvent the need to reproduce a possibly flawed circuit 100% compatible by patching the OS. There is certainly merit to this and I will get to that approach too, BUT:

The point of the thread (so far, and it was stipulated in the text as I went along) is, lets first make it a 'mind experiment' assuming the original chipset, but then let's see what can be fixed having many years of hindsight. In other words, at the moment this may be considered a primer on how to do a QL motherbard 're-boot', rather than just making a copy with all the same problems.

Feel free to quote anything from here and starting a new thread on some of the aspects of this thread. Some, like 8302/IPC replacement were already discussed in various threads, and also there are others with info on how the 8302 and IPC work, I would certainly very much welcome gathering all the data and ideas in a dedicated thread.
Last edited by Nasta on Fri Sep 10, 2021 5:14 pm, edited 1 time in total.


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 »

Peter wrote:
Nasta wrote:The 16550 was an 'improvement' which actually had a set of it's own problems but the main star of the show was a 16-byte receive and transmit FIFO.
That's mildly put. If I remember correctly, the 16550 was so buggy that the FIFO could not be used at all. National Semiconductor later released the 16550A for that reason.
Exactly correct. Fortunately the development did continue and there are dual and quad UART chips based on the 16550 that have fairly large FIFOs and hardware handshake, and they could indeed be used on a QL and retain the 'retro' feeling.
On the Q68, I had to omit hardware handshake because there was absolutely no FPGA pin left. Not nice in theory, but worked perfectly up to 115200 Baud, e.g. massively tested with SERNET.
It is easy to increase FIFO size from the 16 Bytes of the Q68 to several Kilobytes for a slower CPU. Wouldn't a simple, no handshake FPGA UART with a huge FIFO be all a QL needs?
Or does it have to be an old UART chip for the retro feeling?
Well, there is always handshake on the transmit side which has to happen regardless of FIFO size, even though it might be entirely automatic as far as the QL is concerned. On the input, as long as some polling routine or similar can empty the FIFO fast enough given the serial link speed, it's fine.
But honestly, if I was doing it today, either it would be a real ('retro' :) ) UART or more likely a MCU implementation. But more on that idea later or - if it gets started - in a separate thread on that topic.


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 »

Pr0f wrote:Going back to the original post

Would it make sense to have all RAM in low memory (with the QL I/O area blocked out and better decoded) and have ROM overlayed at startup for the first 2 vectors. The ROM can then be anywhere in memory map that's convenient, and some part of it could be copied back into the low RAM for original QL ROM compatability if that was required...
Yes, and I will discuss that option as well as several ways to do it along with one proposed Minerva change (Marcel will kill me :P ). Displacing the IO area somewhere else might be even more interesting.


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 »

The 8302 ULA

As was mentioned before, the 8302 ULA is the main CPU's gateway to all of the I/O devices on the QL motherboard. This consists of the IPC link, serial transmit, net I/O and microdrives. In addition, the ULA implements a reset circuit, interrupt logic, and a real time clock, with a (not very successful) battery backup.

Let me say that right out the gate I am not going to discuss the hot mess that are the microdrives. While there are things that can be done, there are also fundamental limitations on the implementation. Since that part is fairly niche and would be part of a truly die-hard retro re-implementation, I may put some effort in this in a separate thread.
There are also some odd things going on inside the 8302, and some are buggy (like the RTC set procedure) but that's baked into the design and not much can be done about it. Let's rather see what can... where were we... at 5j) I believe... so:

5j) Proper implementation of decoding in the 8301 ULA would have saved a pin on the 8302 ULA. While this is not strictly a 8302 ULA problem, we are back to implementing the decoder in the HAL chip (which is what it really does, albeit not as good as it could). The 8302 has an output called PCENL (/PCEN) and an input called DSMCL (/DSMCL). The input is the /DS input from the CPU and /PCEN is the decoded address output to enable the 8302 ULA. The strange thing is, it is not gated with /DSMCL, which is REALLY easy to do in the ULA. So, as a result, the 8302 needs to have a /DSMC input and a /PCEN input to internally AND then together, which is a trivial function the 8301 could have done for it, and saved a whole pin for more clever stuff. As a result, when it is properly decoded independently of the 8301, the 8302 ULA's /PCEN pin can actually be grounded.

5k) The NET I/O is not protected from static discharge. Fortunately this problem is not too difficult to fix, it's a similar problem to the joystick one, but simpler. One could argue that one problem is that the net port is not galvanically insulated, but the original QL was. The problem with galvanic insulation may present itself once the QL is powered from a PC power supply, but here I would be getting out of the scope of this thread. In any case, the problem is worth fixing with a few passive components, and if there are some actives left, one can implement an activity LED on the side.

Now we get into more complex problems, where the solutions can be varied. The remaining problems have to do with the way reset is generated, and connected to that, protecting the clock from corruption on power-down and power-up.
In order to properly start, and also properly STOP the computer, it is necessary to provide a stable power supply, and then release the reset signal, as well as provide an early detect of the power going out and generating the reset the computer, to prevent the CPU operating erratically as the power goes out, which may corrupt anything which must remain non-volatile or operational under battery power. There are several ways to do this, in fact there are multiple components specifically designed for this.
The other part of this is extra protection for the non-volatile devices like the RTC or perhaps some non-volatile memory for the system to store operating parameters. In this case, the various chip select and read/write signals are specially managed to prevent the protected device from interpreting erratic operation of the system as the power goes down as potentially corrupting accesses to it's internal registers or memory.
Of course, it should be noted that if the power goes out while the system is adjusting the RTC, unless there is a way to provide early power fail indication and a power reserve to let the CPU finish it's current operation, there is no way to prevent RTC corruption.
It should also be noted that other solutions are possible, like providing an alternative RTC. There are many solutions out there that are independently battery powered and have built-in power brown-out and access protection.
At this point, it's a good question how much effort (if any) should be invested in making right a system that may be unfixable. So, I am going to mention the remaining two points, and they can be implemented at least as place holders for components.

5l) There are better RTC power supplies than batteries. These days, no-one in their right mind would use standard NiCd or NiMH rechargeable cells for battery backup if it can be avoided. There is a replacement, and if the voltage levels are OK, there are small form factor LiION batteries that can be float charged. Their main advantage is longer life and not leaking EVER. However, they are expensive. One could make a good argument that providing an alkaline cell would be plenty good enough, and in fact, someone theorized a long time ago that the space to the top left of the motherboard above the edge of an expansion card wa sintended as a space for the battery. Incedentally, that's where other products that provided RTC functionality would actually put one.
The other prevalent technology is of course classic Lithium cells, the problem here being that the circuits inside the 8302 ULA are not that low power, so they would drain a small CR type coin cell very quickly, so that gets expensive again. In other words, we can't really expect a long operation time for the RTC when power is off, but that being said, the ability to retain the RTC was designed with power off times on the order of days - the QL was supposed to be a business computer, which would spend a large part of each day powered on, and the most down time would be from Friday 5PM to Monday 8AM. So, the point here would be to provide something on the order of a week (or more of course) of backup, but reliably. The best device for this is still a supercapacitor. The 8302 has an extra pin for the backup supply and it is a fairly simple thing to hook up a supercap to it, through a schottky diode.

5m) No proper early power fail detect is implemented. As it happens, this is not THAT difficult to implement but Sinclair did not even try, although they do have a separate reset in pin on the 8302, not just a RC power on reset bodge on the CPU reset input(s) like on the Z80 based machines. What is missing is a circuit that looks at the 9V supply and not the 5V supply to detect a power fail. It is a matter of a few resistors, a diode and a transistor added to the already present reset circuit. An even better solution is to use one of the many power supervisor chips, even an ancient and cheap TL7705 would do great here, since it's really running against something made to a very low standard. Detecting a power fail on the 9V input line provides an early detect, which can then stop the CPU while the power supply for it is within normal operational limits and prevent the CPU from producing erratic signals as the power goes out.

5n) Chip select protection for the RTC has not been implemented. Owners of QIMI or clones know that it provided an extra circuit to make the RTC contents more reliable and it actually implements the function of protecting the RTC from spurious accesses when the power supply drops below the battery supply (a battery is also provided with the original QIMI). There are a number of solutions to this, the QIMI one is VERY clever but relies on the battery having at least a semblance of proper voltage, and if it did not, the QL would not start at all. Again, there are a number of discrete and integrated solutions. A combined reset/chip select protect chip is perhaps the best way to do this, there are many available on the market. There have also been several discrete solutions done apart from QIMI, though in my opinion, using a dedicated chip makes it much easier and cheaper. In case I was not clear, the same chip can solve both this issue and the previous one (5m).


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 »

Now that I have thoroughly thrashed the 8302-IPC combo :) it is time to shortly return to the 8301. There are two aspects of the 8301 which need to be considered and they are to an extent dependent on each other.

The 8301 plays two roles in the QL, and that is the main decoder that maps the ROM, RAM and I/O into the CPU address space, and video interface.
As the decoder, it only uses the lowest 18 out of 20 address lines to do this, so the entire address space it covers is 256k. The actual way it does this has already been touched upon in the very first posts in this thread. The 8301 has pins for address lines A17 and A16, but not A15, A14 and A6 which it needs to properly decode the I/O area. It gets those through the address multiplexers for the DRAM chips. This is where we get into a different aspect of the 8301, and that is that the two ULA chips were most probably originally conceived as a single larger chip.

I will try to shortly note a few oddities about the 8301, but as most of them are not externally correctable, it's more as a reference.

A) At least one control line for the address multiplexers, data buffer, 8302 select and /DTACK may have been omitted. There are strong indications that the 8301 and 8302 ULAs were originally a single chip design, that got split into two chips at the 11th hour. As a result there are a number of signals that could have been executed differently with a possible saving of at least one pin on the 8301 ULA and as mentioned certainly one pin on the 8302 ULA, if the latter was connected directly to the CPU from the start, rather than from iss6 motherboards and the introduction of the HAL chip.
This is something that has already been implicitly addressed in the previous posts, where an 'advanced HAL' is proposed to solve several inherent problems of the motherboard circuits. This can simply be done as a modern device these days is easily fast enough, while the HAL would have been marginal at the given speed grade. The HAL chip is actually a 'hardwired' PAL device, an early programmable logic device (PLD) which is why an appropriately programmed GAL can be used to replace it, given that GAL chips were made to replace many types of PAL devices.
When complex logic is integrated into chips like the ULA, it is always a trade-of between the features you need to integrate to make the production of your computer simple and cheap enough, and the features that you get with a couple of really cheap standard components, or even a smaller ULA type chip. In this case I think there were some serious missed opportunities.

B) Simple logic changes would increase RAM access speed by 15% and provide more robust refresh. The 8301 significantly slows down CPU access to the RAM due to a lot of bandwidth being used to display the screen. Even a few tweaks could have made this non-trivially faster. The standard ULA reduces the available bandwidth to the CPU to only 46.66% of theoretical, and that will be slightly less for writing. A very simple tweak would have brought that up to 53.85%, a 15.4%% increase in speed - not trivial in benchmarks of the day! There is also a small problem with refresh due to the way addresses are multiplexed into rows and columns, that would also easily have been corrected by a minor change.

C) The 8301 addresses two banks of 64k RAM but can only display video from the first bank. Oddly, the later revisions of the ULA did include an extra video control bit to select NTSC video timing (bit 6 in the control register), but not a control bit that would simply use CAS1L instead of CAS0L to read video data and display it from the second RAM bank. Since the addresses used by screen 1 are normally used for system data structures, having the option to use a screen 2 and 3 may have resulted in far more use of multiple screen areas - alas, this was never done so it is what it is and here we are. On the other hand, it is actually possible to add externally with a bit of logic, but that would not be the first thing I'd do if I was extending the design.

D) 16 colors instead of (or as an alternative to) flash. One could argue that adding 16 colors would require adding an intensity bit, which would require an extra pin (see (A)!), there are ways to do this without adding a pin and still have the output pins be pure TTL logic, no analog circuitry. This could have been done by leveraging the mode 4 circuitry by using pairs of pixels in various ways. As there are 4 bits per pixel in mode 8, 3 are used directly as the RGB output, which gives us 8 combinations and the 8 basic color combinations including black and white. When the 4th bit is set, the pixel can be split to two (as in mode 4) and different combinations of RGB could be displayed in the 'half pixels' to get an illusion of more colors. One could argue the logic for that is simpler than the one used for flashing. Another possibility would have been modifying the flash bit not to flash! That would make it possible to generate filled areas dynamically by setting the bit to start and end a filled part of a horizontal line. That being said the sub-pixel idea might have been abandoned due to TV mode. Sub pixels in mode 8 are equivalent to mode 4 stipples, and these cause interference problems through the TV or composite output.

What needs to be decided if an advanced QL is to be re-created with the old chipset, if the 8301 is to be used at all, and I would argue that the answer, if possible, is no. The reason has been stated before - it is becoming near impossible to get a compatible display, and this includes TVs, due to the over-scan timing the 8301 generates. While one could implement hardware around the original 8301, when the cost and space calculation is done, it can't be justified compared to re-implementing the video circuits from scratch, even using some fairly expensive parts.

But, let's assume for the moment that the 8301 is used, at which point we have to decide how to circumvent some of it's quirks as well as problematic aspects of the actual implementation on the motherboard.

The first and biggest design choice is if the 8301 is actually used to control the motherboard RAM at all, and also what kind of RAM is it going to be. The next decision that follows automatically, is how much RAM should be on board. And, if this is more than the original 128k, should (some of) the extra be used as a ROM shadow, so that the OS code can be alterable?

Old style 8301 implementation, but better

Let's first start from an improved QL implementation, like previously with the IPC and 8302. So, the 8301 is used and controls the 128k on-board RAM, but, as we established before, let's assume a 'superHAL' that does all the necessary decoding, so this is out of the hands of the 8301. This means the /PCEN and ROMOE pins are not used, and the /DSMCL pin on the 8301 is not directly connected to the CPU but rather generated by the 'superHAL' decoder. There are a number of advantages doing it this way as changing the superHAL makes it easy to implement more advanced ideas. So, here are a few suggestions for other changes:

6a)The original RAM chips are not recommended. These are now almost impossible to get, and they also use quite a lot of power. There are several other solutions to consider, here are some highlights:
- 61464 64k x 4 chips: these are 4 bit wide rather than single bit like the original so only 4 are needed to implement the entire 128k RAM. They are also not that easy to get, but need significantly less power - the power per chip remains near constant so these need only 1/4 of the power the originals did
- 64k x 16 or 256x16 dual CAS chip. The smaller 64k x 16 variants were often used on old IDE hard disk and CD ROM drives, and the larger 256k x 16 variants were common on old PC ISA, VLB and PCI VGA graphics cards. These can still be found at low prices. The 256k x 16 one is actually 512k bytes total RAM but for that in has one more multiplexed address line. One might be tempted to get the 8301 to address the full size and implement 512k bytes of total RAM, but since the 8301 does not have an extra address line, nor is there a reliable way to provide proper refresh, it's better not to use the extra line. This reduces the capacity back to 64k x 16, the original 128k. The opportunity here is to drastically reduce the RAM chip count - from 16 to just 1. These are 16 bit wide devices but have separate CAS lines for the upper and lower byte in a 16-bit word, which makes them behave like two 8-bit wide banks with all the address, write and RAS lines in parallel - just like the original RAM. What remains is to connect the high and low byte together into a single 8-bit bus and use the separate /CAS pins just as the 8301 ULA does, to implement two banks of 64k bytes.
- 128k x 8 static RAM chip. The static RAM has a non-multiplexed address bus and slightly different control signals so driving it from a multiplexed address bus requires demultiplexing. Now one could say, hold on, there are two TTL multiplexer chips (74LS257) on the motherboard that are used to multiplex the non-multiplexed address bus of the CPU, why use them only to demultiplex the addresses back to the SRAM format? Well, the 8301 expects a multiplexed bus, not only for the RAM but also to get to the address lines A5, A14 and A6 (and possibly A5) to decode it's internal screen mode control register. Granted, there are several ways the logic can be done, but when calculating the number of chips, PCB real-estate and extra logic, the simplest way to do it is to de-multiplex the row address back into a latch chip. A single gate is needed to generate the chip select for the SRAM. The advantage of this approach is a completely standard and easy to find SRAM chip and the lowest power consumption, with about the same PCB footprint and 4 64k x 4 DRAM chips.

6b) Unbuffered RGB and synch outputs MUST be buffered. Since 8301s are getting short in supply, and one getting zapped by static through the monitor lines is quite common, having those lines properly buffered is an absolute must, also a set of a few strategically positioned passive components will help to protect the buffered outputs as well. It is quite shocking to me that Sinclair did not even include low resistance series resistors as the most basic protection method. The protection diodes that came later are really almost useless without the resistors. Besides, providing a cheap buffer chip as a 'sacrificial component' is a much better deal than sacrificing an ULA. The buffer itself could just as well be an 8-wide one, which leaves us 3 unused buffer channels to buffer, say, the speaker output. With a DC blocking capacitor in series :P

6c) The 8301 uses the /DS signal on the CPU to detect when the CPU wants to access the RAM. Although this is actually correct in principle, because /DS becomes active ne full CPU clock later in an access cycle, writing to RAM is always penalized by at least one wait cycle. It is possible to use the /AS signal instead, which is not used on the motherboard at all. That being said, using /AS on a write cycle does require some care as the data from the CPU does indeed appear after the address appears, which is why /DS, which signals that stable data is present on the data bus, gets activated later in the cycle. When DRAM chips are used to implement RAM, care has to be taken as there are interactions between the address strobes /RAS and /CAS and data to be written. In the particular case of the 8301, the timing of the signals implies that the data to be written is expected to be stable when the /RAS signal goes low, because it will not only latch the row address into the DRAM chip but also the data to be written. In DRAM terms this is called 'early write'. Since faster or different chips could be used in a motherboard 'reboot' as mentioned in 6a), a small amount of signal delay added in the right place may make it possible to cut the 1 wait state penalty. However, I mention this only for completeness, this is not the best strategy to get the QL a bit faster without actually breaking anything critical, because on a long term basis, the ratio of data writes to data reads is quite a lot less than 1, remember, for any data the CPU needs to write, it had to read instructions to do so and also previously read data and process it to get some sort of result to be written. Given that the 1 cycle penalty occurs only during the 46.666% of the time when the CPU is given full access to the RAM, and write cycles are comparatively rare, the difference in speed is not going to be that big.


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 »

At this point, we have almost defined a full 'to do' list on reconstructing the original QL motherboard. Only a few things remain:

1) Expansion port and ROM port enhancements
Some signals on the expansion port were never used and some can be re-defined. This is especially pertinent regarding signal integrity, added address lines and changes to some control lines to the CPU as well as interrupt lines. The ROM slot has one extra line which should be used in some creative way. I will get to this later, before I do a complete summary of everything in this thread.

2) Power supply
This is an easy one. A switching power supply would be used on the board for sure, to power everything but the microdrives. The +12V and -12V supplies can actually be omitted. This means pretty much any 'power brick' from 9-20V will work.

3) I/O ports (physical connectors) and microdrives
This largely depends on how much of the old QL we want to keep and if the new board is mechanically compatible with the old case and keyboard. My opinion on this is that the board could be compatible with the old QL case, but some things should really be changed, such as the 'BT' style serial port and joystick connectors. For now, we could leave everything else more or less the same.

Given some more or less clever and lucid solutions to the considerations above, we get a pretty good version of the original motherboard, probably that alone would be worth the effort. It could also have a slightly different shape which may enable some extra expansion inside the case.

Extra addressing, extra RAM and compatibility

We started with the idea of at least having the option of adding significant extra RAM to the system, certainly more than was possible with the original motherboard. Because of this, the decision has to be made if the added RAM is all included (more on this below) on the motherboard (either from the start or as an upgrade option), or there is extra address space which can then be populated as needed. In the latter case, the extra addressing capability needs extra address lines on the expansion bus.

1) Adding extra address lines to the expansion connector

The logical place to put these extra signals is where other signals were that were never used. Perhaps not obvious but also logical candidates would be the FC0, FC1 and FC2 pins. These are actually notionally extra address lines but intended to delineate different logical address spaces. Since the QL does not use this distinction (normally it is used to implement virtual memory systems using a Memory Management Unit - MMU) the FC lines are only used to signal CPU space, which in turn is used for interrupt acknowledge as was mentioned before in the thread. So, the FC lines are only used for internal motherboard logic, and thus 3 pins on the expansion connector are freed up for other uses, for instance address lines A20, A21 and A22 (FC0, 1 and 2 respectively). The 68008FN only has A20 and A21 so FC2, while replaced by A22, remains unused, and probably tied to logical zero.
The problem here is that old peripherals don't see these extra lines so there is going to be aliasing. Since the 68008FN adds two extra address lines, and can address 4M bytes rather than 1M bytes of the original QL, aliasing will mean that the 1M byte of the QL address space will simply appear as 4 copies, once in each of the 4 Mbytes. This is going to be fine as long as old peripherals are not to be used with a new ones that are aware of the extra address lines. If the latter is necessary, then the new peripheral has to have a through-connector and provide a modified version of various signals to prevent the old peripherals from wrongly recognizing addresses not intended for them, AND a rule has to be established that 'extra addressing aware' peripherals must plug into the motherboard first. This approach does not support backplanes, unless the backplane has the same 'signal modifying' circuits and has separate connectors for old and new peripherals. All in all not a very clean and practical solution.

2) Including all functionality that uses extended addressing on board
This makes things much cleaner as far as old add-on cards are concerned, but also adds some manipulation logic to signals going from the CPU to the expansion connector. There are several approaches to handling this, with variations available:

2a) Show only part of the address map on the expansion connector, and insure that is compatible with old style peripherals. The underlying principle is that the expansion cards never get to see addresses not intended for them. This also implies that there is no need to add any more address lines to the expansion connector, although it is still possible to do so since they would be using pins previously carrying signals that were never used on add-on cards.
This is in fact what the Miracle SuperGoldCard uses. The only addresses seen on the expansion bus are the ROM area, the motherboard I/O area and the expansion IO, but the latter is located at $CC0000 as seen by the CPU on the SGC. It still looks like $C0000 on the expansion bus because there are no address lines higher than A19, so A20-23 needed to decode that first C in $CC0000 don't get to the bus, and any peripheral on it is blissfully unaware of the address relocation.
Something similar could be done in our case - for instance the first 256k bytes from $000000 to $03FFFF appear unchanged on the expansion bus (the first 256k) and the top 256k $3C0000 to $3FFFFF, but given the lack of the top 2 address lines would appear as $C0000 to $FFFFF. This excludes all addresses that would normally be used as the 512k expansion RAM, which would not really be a problem if a good amount of RAM is already on the board.

2b) Assuming extra RAM capability is provided on board, but no actual extra RAM is installed, the address availability on the bus van be changed so that adding an older RAM card makes the address map sufficiently compatible for the system to use the RAM card as normal. In this case, we could also extend the addresses that appear on the bus up to $0BFFFF, which would add the original 512k area intended for RAM expansion appearing on the bus at $40000 to $BFFFF just like on the standard QL. Adding a 512k RAM expansion would then map it at the beginning of the address area available for memory expansion, and the system would see the extra 512k normally, plus an IO area all the way up at $3C0000. Minerva will completely normally initialize and use such a setup. The problem here would be that a Trump Card would only be seen as a 512k expansion as the top 256k of it's 768k RAM would appear in the new I/O area at said $3C0000 to $3FFFFF. Since RAM is required to be contiguous, the OS would not see that part. Of course, some sort of option could be included to change what actual address appears as $C0000 to $FFFFF on the bus to get the TC to work, but then we have again used up all the available 1M byte addressing space on the bus and would need to cater for extra addressing in some different manner. In my opinion, it would be better to simply include a nice amount of RAM on board to begin with and keep the decoding and expansion capability nice and clean.

2c) Given sufficient extra pins on the bus that could be used for addresses, two parallel addressing systems could be used. Both previous options partially disable a very nice feature of the QL expansion bus that makes it possible for a peripheral to disable anything on the motherboard and impose itself instead. This is something that would be nice to retain, as it makes almost any upgrade possible.
This mechanism functions using the DSMCL pin on the expansion bus. When an external device sees an address that it wishes to use, it must as quickly as possible pull DSMCL high. This prevents any existing decoders on the motherboard from decoding and activating anything so the external device effectively replaces the internal one. There are no limits to how specific the external device can be in selecting the address(es) it wants to use - it may be anything from a single address and only for one data direction (eg. read) to the entire address space, and anything between. If an external device takes over a part of the address space for itself, it then has to react appropriately to address and data qualifying signals /AS and /DS, and provide a data transfer acknowledge signal, either /DTACK or /VPA (more on the latter in subsequent posts).
The only way to reliably prevent an external device from pulling DSMCL high if it sees an address it needs, is to never generate one, and this is the approach used in the two previous variations. Alternatively, the logic on the motherboard can chose to ignore the DSMCL signal for addresses it does not want to relinquish, and prevent generation of the /DS signal on the expansion bus so that even if an external device recognizes and attempts to take over an address, it will not actually be able to transfer any data as the relevant address and data strobes will never be generated so data will be transferred on the data bus even if the add-on device attempts to use that particular address.
Providing an alternative /DS and /DSMCL which is never ignored provides a mechanism for 'extended addressing aware' to use any address and provide a wider range of expansion options.

Unfortunately, there are some outliers amongst various expansion boards that were produced since the QL came around. In principle, no hardware should use the /AS signal from the CPU (ASL on the expansion bus), but some does - so this may collide with the ideal signal on the old expansion bus that could be repurposed for the /DS version that is always present, for the extended addressing aware peripherals.
Some expansions that use a buffer on the data bus which is activated on the basis of just the address on the bus and the read/write signal. This is not good practise but it is out there. When the CPU attempts to read from such an address, two devices will respond (something on the motherboard plus the data buffer on the expansion device) which means an electrical contention will occur and data will be corrupt.
Fortunately these are truly outliers and could probably simply not be supported. There are more considerations that have to do with 6800 compatible peripheral chips and bus signals E and /VPA. We will get back to this.

If I was implementing a new machine, given that we started with the idea of more available address space, is to actually populate most of this address space with RAM, as this is what nearly any other add-on will need or will generate a need for. The expansion bus would then show a total of 1M byte of address space, carefully selected so that useful old peripherals can be connected without conflict, and some extra options can be added that are aware of the addressing behind the 1M of addresses visible on the expansion bus. Since there is a total of 4M of address space available, 1M being seen on the expansion bus, pretty much means that the remaining 3M are some form of memory, and that would mostly be RAM. So if RAM is included, we are back to the question of how much and what kind.


Post Reply