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

Nagging hardware related question? Post here!
User avatar
Pr0f
QL Wafer Drive
Posts: 1298
Joined: Thu Oct 12, 2017 9:54 am

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

Post by Pr0f »

In any event, if you are recreating hardware - the serial port should probably be implemented using one of newer duarts that has a 68K bus, and offers a lot of the hardware handshaking built in, even xon/xoff with selectable characters in some chips - plus plenty of buffer space (64 bytes, more in some cases). That would relieve the whole serial burden from the 8302/IPC. At that point the IPC is simply doing keyboard and sound, and the ZX8302 looking after the IPC, Microdrives (if you still wanted to implement them, the RTC and the bit banged QL network.

I am sure it must be possible to lift the QL network away from being bit banged, and have it implemented in silicon. That would lift at least one of the timing constrictions on the QL.


User avatar
janbredenbeek
Super Gold Card
Posts: 629
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

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

Post by janbredenbeek »

Brane2 wrote: But QL was to be prioced fgar higher and marketed to businesses, at least that was how tit was to be marketed.
The IBM PC had a price tag far above the initial $399 for the QL, and used a single-byte buffered UART.
had SInclair been honest about it, QL should have one SER port.
Remember there were no serial mice at the time of the QL launch (two weeks before the Mac!). And the main idea was probably to drive a serial printer, which only need to receive data from the QL.
The idea that the designers probably had in mind was to use SER1 to drive the printer and SER2 for modems or other communication.


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

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

Post by tofro »

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. Other than that, the QL designers' crystal balls weren't too fine-tuned, apparently. Hindsight is always easy.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
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 »

@Janbredenbeek
The 16450 was the principle UART used in the PC and it has a... sort of 1.5 byte receive buffer, actually one byte for the received byte while the next byte is still in the reception process. It's little more than a serial to parallel and parallel to serial converter, ALL the handshake is handled using software under interrupt control.
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. It should be noted that no hardware handshake was implemented at all and it was all driven bz software again. The input FIFO made it possible for the receive interrupt latency from generation (once a certain FIFO fullness threshold was reached) to servicing (which includes generating the appropriate handshake to stop the connected transmitter to stop transmitting before FIFO overflow occurs) longer. However, the transmit FIFO is utterly useless in general serial communication as the transmit handshake still remains software generated. It-s use is only in XON-XOFF operation assuming there is another 16550 on the other end and the message transmitted is always up to 15 bytes long. In all other cases handshake is violated as the UART continues sending data until the driver recognises the change in handshake line status and stops the transmitter, again generated via interrupt and subject to latency. This was still tolerable while the internet was still in the modem era as receive rate was (and still is) higher than transmit, and there was a modem present which had it's own input buffer and a tolerant input handshake implementation.
It is only after serial ports almost got out of fashion that compatible UARTs with even larger FIFOs AND hardware handshake became available and these are worth considering.
Sadly, most combined IO chips used in older PCs that implement a bunch of PC standard I/O functions contain the flawed 16550 UART.
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.

@Brane2
You are entirely correct that in actuality, it would be most fair to have implemented only one decent port. The 'two port' scheme would still hold assuming one printer and one modem, as the printer is transmit only from the standpoint of the QL and unlikely to be printing while the modem was on (such was the usage case for modems back then). But that soon changed and here we are. I would even go so far, if I was building a clone using the old chipset, to only implement one port and modify Minerva accordingly.

@all
In general I think Hermes is a must. It is a great pity someone like Lau Reeves or indeed Lau himself did not program the IPC as the number of fixes and options it would have opened for other hardware (see my next post) is everything but trivial.
I would LOVE to see that code and I hope Lau does find the sources, otherwise it would have to be re/created from the binary. One thing I am almost certain could be done is proper serial port multiplexing so that serial port chatter does not spill over to the other port. That in turn would make it possible to implement two real serial input ports, though I would not bother with that, rather implement one decent one and one with no handshake that can be used for a serial mouse, which is really the only 'semi modern' use case these days.
Also, that source (knowing how well Lau explains what he does in the comments) would be a perfect base for porting and extending the code to a different and more modern MCU.


User avatar
Pr0f
QL Wafer Drive
Posts: 1298
Joined: Thu Oct 12, 2017 9:54 am

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

Post by Pr0f »

RS-232 defined a whole raft of things - including physical connectors, voltage levels, pin configurations - I suspect that it would be hard to argue that the QL's BT style ports could come close on any of those - although they did use industry recognized transceivers for the job :-)


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 »

Hermes deserves a much closer look because it has a couple of features which make it potentially more usable when it is not plugged into a regular IPC socket on the QL motherboard, in addition to all the corrections to the original IPC functionality. The most interesting are probably the pins it does not use like the original IPC, that can then be used for other functions. The Hermes manual is a very interesting read in general, but at the moment I will concentrate on the extra pins it mentions. In total there are 5 extra pins, two of which have also previously been unused:

P2.0
This can be set to low or high Z, or it's state can be read. This is normally directly connected with the /INT pin which is still used as serial input on Hermes, so it must not be forced to low as this will produce an error condition on both serial ports. Of course, on new hardware it could separated and doing something else.

P2.3
This can be set to low or high Z, or it's state can be read. This is normally connected to /IPL1 on the CPU and is best not used in this manner and bent out of the socket, or, on a new board, connected to something useful.

P2.6
can be set low or high and was intended to control the read signal gain on microdrives but was never used, instead it was used as a caps lock LED driver (but for some reason not active low which would not need any other hardware except the LED itself and a single resistor).

T1
State can be tested, but cannot be used as an output. It is connected to the BAUDx4 output pin on the 8302 ULA and was used as the input to the internal counter/timers to further divide the signal down and generate receive baud rates. On new hardware it need not be connected as originally and could be used as a testable input.

T0
State can be tested, or a permanent IPC clock /3 signal can be output on it (11MHz/3=3.666666.. MHz), this can actually be used by an external serial adapter to generate baud rates. This pin is not connected anywhere on the original motherboard.

Regarding T0 and T1, there is an additional strange quirk, or one might even say architectural blunder present in the original QL design. Since T0 was never used, but could supply an 3.666666MHz clock, or even better, if a 11.0592MHz crystal is used on the IPS rather than 11MHz, a 3.6864MHz clock, this could have been used to derive the various bit rates inside of the 8302 ULA instead of the 7.5MHz clock. This is the only use of the 7.5MHz clock inside the 8302 ULA. Such a configuration would have simplified the 8302 internal baud rate generator dividing chain. Getting to 19200Hz (which is the highest transmit baud rate) from 7.5MHz requires division by 390.625, the closest integer would be 391. This is not a straight-forward divider, it requires a 9-bit counter with a number of logic gates to skip some of the possible 512 states so that 391 states remain. On the other hand, 3.686400MHz requires dividing by 192, which is 3x64. Dividing by 3 requires a simple two bit counter and one and gate, and the remaining division by 64 is 6 flip-flops connected in series. In terms of digital circuit build, it is a much simplified circuit. So:

5h) Using T0 set up as IPC crystal/3 instead of the 7.5MHz input simplifies 8302 ULA internals
This could have been done with the original IPC at no cost, as per explanation above.

5i) 'Fake' RTS and DSR on serial ports should have been supplied from the input 9V power supply.
One pin on each serial port is connected via a common 680 ohm resistor to the +12V power line, named RTS or DSR respectively. These are output handshake lines that the receiving part of the port generates to tell the transmitter on the other end of the line that a receive capable device is connected and powered on. The line was included so that it is easy to make an adapter for dual handshake ports but it cannot be controlled by the machine and is always high when the QL is powered up, so it 'sort of' behaves along the lines of the definitions for those signals.
This also makes it possible t use it to supply power to very low power devices, such as serial to parallel converter cables or serial mice. However, the available power from this pin is very low, due to the low current available from the internal +12V regulator. In order to save on each resistor, both ports use a common one, so at the very least a nice upgrade would be for each to have their own. The proper solution would have been be to power this line from the 9V input voltage, using something like a current limiter or soft fuse, then a decent amount of current could be made available for potentially more interesting devices. It makes sense to incorporate the fix into 'new' hardware.

Before I move on to the 8302 ULA, a new build based on the old components should definitely also incorporate the following:

The serial port driver/receiver chip(s) would almost certainly be driven only by the 5V power supply. Even though RS232C works typically at much higher voltages (the spec is +-3V to +-15V), it can even work at regular TTL voltages, though this is not recommended. The higher voltages are intended to overcome long maximum wire lengths specified for RS232C. The salient point here is that the +-12V power supply on the motherboard is solely used to supply the RS232 line driver chips. Today's standard RS232C driver and receiver chips integrate a pair of voltage converters which makes it possible for them to work from a single 5V supply, which would eliminate the need for the +-12V supply and by extension, the AC power line from the QL power supply, as that is used to generate the +-12V.

Finally, one should really use the DB9 connector wired to the PC standard. One could argue that it's time has passed but if you do find a serial port nowadays, that's what it's going to look like. The confusion around directions of the RX and TX signals and the associated handshake signals should really be retired once and for all.
Last edited by Nasta on Thu Sep 09, 2021 8:03 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 »

Brane2 wrote:
Nasta wrote: @all
In general I think Hermes is a must. It is a great pity someone like Lau Reeves or indeed Lau himself did not program the IPC as the number of fixes and options it would have opened for other hardware (see my next post) is everything but trivial.
Is this really so dire ? methinks there are more than a couple of old PICs that could implement ULA2 as well as IPC functionality ( and then some) while still being semi-retro.
Sure, but as stated earlier in the thread, I am at the moment analysing a system that uses the original ULAs and available IPCs. Rebuilding the system with more ambitious hardware and discussion around it will come later.


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

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

Post by NormanDunbar »

Brane2 wrote:Actually, he shhouldn't even mention RS-232 compliance.
As Prof says, RS232 defines a whole pile of "stuff"!

In my day job, I work with databases. All of those declare themselves to be "SQL Standards compliant". And they are -- to a degree. The full SQL standard has no databases full complient. Most databases are compliant to a certain extent -- which is allowed.

I suspect Clive had the same options in claiming complience with RS232.

Cheers,
Norm.


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

No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
User avatar
Pr0f
QL Wafer Drive
Posts: 1298
Joined: Thu Oct 12, 2017 9:54 am

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

Post by Pr0f »

Clive produced many interesting inventions over the years - with some notable highlights:

10W PWM Class D amp back in the 60's/70's
Black watch
Pocket Calculator
Pocket TV
The Z88 - which is still one of the most inventive machines of it's time
:ugeek: :ugeek: :ugeek:


User avatar
Pr0f
QL Wafer Drive
Posts: 1298
Joined: Thu Oct 12, 2017 9:54 am

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

Post by Pr0f »

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


Post Reply