Here it is, a new serial card specifically designed for the Minstrel 4th and the RC2014 bus.
It may look like there is something missing. Let's just check.
- No UART
- No ACIA
- No DART
- No SIO
- No microcontroller
- No Raspberry Pi
So how is it doing it?
Read on.
There is a lot of backstory to get to this point, I covered in a separate post:
The essential part is I wanted a card that used all new parts, but there was no serial chip in production that I thought was suitable (the W65C51N is in production, but some unfortunate flaws make it unsuitable).
I had tried to create a "pseudo 6850" card many times, in many different ways, but none of them were 100%.
It all seemed to come down to communication between the Z80 and the serial chip. These simple chips can only deal with one byte at a time, so the timing of the RTS signal and getting that one byte read is quite important, and I kept getting into a situation where it worked "most" of the time.
(N.B. as I have been working on this, I have concluded that the 68B50 also works only "most" of the time, and suffers from missing bytes when they are sent too fast, but I still wanted to do better, and I think I have)
The 68B50 only has a single byte buffer, so has to receive a character, wait for it to be read by the Z80, receive the next character, wait for that to be read etc.
The way the software driving the 68B50 works is it set RTS briefly to indicate it is ready to receive a byte. It then checks to see if a byte has been received and reads that byte of data if there is one. If there isn't, it pulses RTS again and repeats.
The calling code then checks if a byte was received, and if not, go back and calls it again.
One day I was looking at the traces and I noticed that the RTS pulses were only slightly longer than the actual data bits......
A dangerous thought occurred to me.
Can I bit-bash RS232?
The answer is yes, of course I can, that was actually one of the first projects I did with the early microcontrollers back in the 1990s (see a previous post), although that was a PIC with something like 4MHz clock and the serial was probably 9600 baud or something like that.
This is a Z80 with no single cycle IO instructions (very far from it), and also the serial is 115200 baud.
They both can run at up to 10MHz, but the Z80 instruction takes 12 times as many cycles, and the baud rate is 12 x what it was. I am 144 times the programmer I was 30 years ago?
Looking at the traces, it became apparent, that all the bits of the serial data were 28 clock cycles long, confirmed by checking the whole bytes from start bit to stop bit with 8 data bits in between were all 280 cycles long.
Just out of academic interest, I had a look to see how close 28 cycles per bit at 3.25MHz would be.
116071 baud
OK, that's not bad, fairly close to 115200 isn't it?
Well, it turns out to be 0.76% fast, and the tolerance is something like 5% on some older systems, so maybe it is viable to bit-bash RS232 at 115200 baud (or near offer).
Ah, but do I have enough cycles?
Software Alarmingly, the OUT instruction is 11 or 12 cycles depending on which version I use. Ouch, that's almost half of the time I have.
After a bit of juggling around, I managed to make it work in 28 cycles.
I added that to my rebuilt Minstrel 4th Enhanced ROM (now you see why I needed to be able to rebuild it)
That looks like RS232 to me.
The logic analyser was happy enough with it, as was a serial terminal. Using the TEE command, I was able to VLIST over serial!
Transmitting was possible, but the next bit with going to be more complicated - was I going to be able to get the receive code into just 28 cycles?
Yes I was, in fact, I even had cycles to spare, so used the 8 cycle version of RL A instead of the 4 cycle RLA. Such luxury.
But, as usual, it wasn't 100%.
The problem is with detecting the start bit, to know when the start sampling the incoming data.
Most of the time, it would hit it fine, and sample all the bits in the right place and decode the data.
However, sometimes it would have been busy setting RTS again and by the time it sampled the start bit, it was a little too late and was off by a whole bit in this case.
I tried a few variations, including turning RTS on and off around each sample point, and turning it on at the start and one turning it off then the stop bit was detected, but none of those options were 100%.
Yay, yet another "not quite good enough serial card replacement".
Plan B
(are we really only onto B? maybe it has looped around?)
I had one ace up my sleeve that I was holding back, time to play it.
The plan had been to use the 28 cycle version at 3.25MHz to generate 115200 baud, to match the original used in the Grant Searle system, the RC2014 and Minstrel 4th enhanced ROM.
This is all based on clock cycles, so when that same code runs at 6.5MHz, it would generate 230400 baud, which is also a standard rate, although not as commonly used as 115200.
I knew I had a fallback that I if I doubled it to 56 cycles per bit, that would give me 57600 baud at 3.25MHz, and would now give 115200 baud at 6.5MHz. 57600 is also a standard rate, more so that 115200, but it felt like a little bit of a cheat, I would have liked to do the 28 cycle version if I could.
Yes, I know I said in a previous post that the modern get-out-clause for lazy programming was to specify a faster processor, but in this case I tried really hard to avoid that.
It just means the baud rate of the serial terminal or serial server Python code would need to be selected based on the clock frequency of the Minstrel 4th, not too much of a problem,
The main receive and transmit code just needed padding out to 56 cycles.
I later changed that from 7x NOP (4 cycles) to 4x LDA (7 cycles).
N.B. I later changed it again to load A with $FF as that value is written to the upper address bus during the IN and OUT instructions and that will disable the keyboard matrix
This was all padding, other than around the code which detected the start bit.
With that now in place, I was able to tweak things again.
Now it is checking more regularly, the data samples fit neatly into the middle of the transmitted bits.
Here I have tried to show the range by overlaying the worse case (in pink) where the start bit appears just after it has been sampled, and the best case (in purple), where the start bit appears just before it is sampled.
That seems to be working well, no bad characters.
I still got the occasional double character when RTS was active just a little too long and a second byte was sent immediately after the first.
To get around that, I tried just a single short RTS pulse at the start, and then a run of samples.
That worked nicely.
I couldn't find any definition of how long the RTS line needs to be asserted to be valid. RS232 is one of the "standards" that is anything but standardised, having evolved over the incredible 65 years it has been around.
Most of the time, this will be used with an FTDI type serial module, so I checked the datasheet for that, but again, nothing specific about RTS/CTS timing.
It appears to work fine with the brief pulses, maybe it's edge triggered?
Because this is very much one byte at a time, it needs RTS/CTS to be used, so I decided to remove the connections to the RX and TX pins on RC2014 bus, as receive would not work without hardware flow control.
I am not sure how much those are used, they were originally there to connect the serial from the 68B50 card to the Raspberry Pi video terminal board - is that still a thing?
I later relented and put solder blob jumpers so you can reconnect them if you really want.
Coding Transmit
Transmit works out fairly straightforward. Toggle the TX line up and down to generate the bits and the return.
As with the 68B50 bards, CTS is not checked, so transmission is never blocked. I have made that pin readable with a CTS word, so you could write code to check that before transmit if you had an application the required it, or roll it into a blocking TX function. Generally an FTDI USB cable to a PC would never need to assert CTS as it can read as many bytes as you can throw at it.
Coding Receive
There are three ways you can deal with reading characters over serial.
Polling
This is usually done as part of a loop, or on a timer interrupt, for example on the vertical refresh on the Minstrel 4th.
The implementation here toggles RTS and waits about a character length before giving up if it does not see a start bit.
This is the equivalent of periodically opening the front door shouting "anyone got any parcels for me?", but is slightly better than it sounds because with the RTS control, they won't attempt to deliver parcels when your door is closed.
Blocking
This is where you want input from the user, and don't have anything else to do. You call the function and it will wait until a character has been received before returning.
Here it repeats the sequence of toggle RTS, wait for a start bit, toggle RTS, wait for a start bit etc. until a character has been received (currently this returns after 1000 tries so as not to lock the machine up)
This is like standing at the front door, waiting for the courier to arrive and only going back inside when you have the parcel.
Interrupt
Here you keep running your code until you get an interrupt telling you a character has been received.
This is the equivalent of working away on other things, and when you hear the doorbell, going to the door and receiving the parcel, assuming you get there in time before the courier gives up and goes back in their van.
That mode is not supported on this new card, the main reason is the interrupt pin is used by the video circuitry on the Minstrel boards, so is not easily available for other purposes.
I did consider having a non-maskable interrupt triggered by the start bit, but the time between the interrupt being raised and the interrupt handler getting started is non consistent, and depends on the instruction being executed when the interrupt occurs, and if you need to preserve registers and machine state, you quickly run out of cycles (the driver is back in the van and on their way back to the depot by the time you get to the door).
The Minstrel 4th Enhanced ROM
The main intended use of this card is with the Minstrel 4th Enhanced ROM, this uses serial in a few ways, all of which this card can be used for.
TEE and TTY
The TEE command can be used to send the screen output to the serial port. This involves transmitting characters as they are printed to the screen, that is fine.
Transmit is called whenever a character is to be printed to the screen.
TTY can be used to allow typing in commands over serial, and using TEE to send the responses back via serial.
Receive is called as part of the keyboard scan routine, using the "polling" method above. If there is a character received, it is handled in the same way as a key press.
I spent quite a while tweaking things to avoid missing characters. It turns out when I went back to get some more sample traces for comparison that the 68B50 version wasn't very good at dealing with that either, and would sometimes miss characters itself.
The new one seems pretty solid and certainly with the FTDI (or clone) USB serial adapters I have tested with, it is using RTS to effectively stop more than one character at a time.
Serial Server
There is a Python script which runs on the PC end with a folder of TAP files, the user can use the LS, TAPIN and TAPOUT commands, along with versions of LOAD and SAVE adapted to use serial.
This uses serial TX and blocking serial RX, so works fine with this card taking only a few seconds to load 3D Monster Maze at 57600 BAUD.
I am sure you know my criteria for something working is "can it run (or in this case load) 3D Monster Maze".
Well, yes, it can.
It seems to spend most of the time toggling RTS, waiting for the next bytes, so the dropping to half the baud rate has not made much of a difference.
Typing in code over serial
One of the features I had on the Minstrel 4D was being able to type in some forth source code, I have added that here with a new TYPEIN command, so it will type in the contents of a .fs or .txt file.
Pasting a file into a terminal is also an option, but I need to work on adding some punctuation characters that are missing.
I also noticed it missed the ; at the end of a statement, when pasted as a bunch of lines. It seemed to successfully read the character, but then ignores it.
One neat thing about software serial is you aren't limited to just one RX and TX. For testing purposes, I added an echo of the character received using the RX_LED pin, and that confirmed the ; is received correctly. Needs more investigation.
Implementation
I have tried to keep things neat and simple. Four main ICs, but which one is the UART?
I did start off needing to add only one 74HC74. My initial plan was to integrate this into the Minstrel 4th, and use the $FE I/O ports already present. Only 6 bits are used on the input port, and one on the output port.
This worked, but unfortunately it triggers the speaker which toggles on and off with reads and writes, so it buzzes when sending or receiving data. I could call that a "feature", or add a jumper to disable the speaker, but I'd rather not.
I didn't have space for four chips, so I went back to an external card.
Address decoding
I went through a few variations on the way. I was initially looking at a 688 and a 138, or a pair of 138s.
I decided I would prefer to go for the simplicity of plain logic gates. I went for address $FF, since I could do that with just two ICs, a 20 and a 32. I decided not to give the option of changing the address, since that would need different versions of the ROM. I don't think $FF is used by other devices, so should be available.
I reordered the pins to make the layout easier. It makes me happy to know the layout is completed with no vias, I like the challenge of laying a board out like that. I'm sure no one else cares one jot.
LEDs
One thing I disliked on the 68B50 card I made was the TX and RX LEDs, these were buffered versions of the RX and TX lines (since there were spare gates on the 04 chip used for the clock). The bits were not very long, so unless you were sending lots of data, you wouldn't see them flash very easily.
One of the things that I spent too much time on with the failed AVR microcontroller version was getting the LEDs to flash for a minimum period, so you got a visible blink, even if it was only a single character.
If I could, I wanted to do something in hardware to make the LEDs persist long enough to see.
Input
The obvious choice for something like this would be a 245 or a 365 / 367, since all of those are already on the Minstrel 4th BOM. Those are 8 or 6 way input buffers, and I only really need one input for RX data. I may as well add a second for CTS input, although that will probably not be used most of the time.
In the end I went for a 74HC125, this is four way, but they are individually controlled, and I have another use for the two spare gates.
Output
Again there are various choices, I need two outputs, TX and RTS so an eight way 574 would be overkill. I could use a 74, that is a logical choice, but I have a use for two more outputs.
My thinking was I could control the TX and RX LEDs separately, but as I found with the AVR version, it is easy to find a place to turn the LED on, but it is difficult to arrange for it to be turned off tens of milliseconds after the byte has finished transmission, long enough for the flash to be visible.
Analogue electronics to the rescue!
This is what I came up with. The two spare 125 gates act as buffers for the RC time delay time delay circuit. The RX LED version is identical.
It is setup so when the TX_LED_Pulse signal goes low during transmission, it is only low for 150µs, but that is long enough to discharge the 100nF capacitor C5 via diode D1 so the input to the buffer goes low and the LED turns on.
Approximately 50ms later, C5 has charged up enough via the 1MΩ resistor R1 to count as a logic 1, so the LED goes off again. This is retriggerable as every transmitted byte will discharge C5 again, so the LED will remain on until 50ms after the last byte was transmitted.
The latch has a reset input, so would set all the outputs to 0V at power on. That would keep C5 permanently discharged via D1 and the LED would be on until the port was written to. I would rather not have to clear the LEDs at power on, as that would mean any code running would need to know about the card, and I wanted to keep the option of using unmodified original ROMs.
I did try inverting the logic and wiring it the other way up, with the capacitor to the 5V rail, reset by a positive pulse. But I had to double think everything, and the negative trigger just made more sense to me.
The extended pulse LEDs adds 8 passive components, (ok 6 passives and 2 semi-conductor diodes if you want to be pedantic), but I think it's useful to have the LEDs there to know things are working.
Getting back to which chip to use, I could use two 74 chips, to give me the four outputs I need, and the /Q output which would reset high and so the LEDs would flash once at power on themselves whist the capacitor was charging for the first time, which is a nice effect.
Then I remembered the 175, this is a four way latch with reset and Q and /Q outputs. It's not a widely used chip, I had to hunt around and the only one I found was from 1980!
I probably desoldered that from some scrap board about 30 years ago. I knew it would come in handy one day. My hoarding habit totally vindicated.
Given the way technology moves these days, it blows my mind that this is still in production 45 years later, in an almost identical form. Long may that continue. (yes, I know that is a 74HC on the right, you can still get 74LS versions as well)
I also wired up the transmit and RTS outputs to the inverted versions, so they will reset to high (inactive), which is ideal, the card needs no software initialisation after a reset.
I have added copious arrows to the schematic to keep reminding me of the signal direction and avoid getting TX and RX swapped.
I added 2K2 resistors in all the signals to the FTDI connector for protection in case of such a swap. The Grant Searle Z80 SBC design did that, and it seems to make sense, so I have been using it every where I add an FTDI port. I also have a jumper to power the RC2014 bus from the FTDI cable 5V if you wanted to.
I was changing things a lot, so did all the initial tested on breadboard until the PCBs arrived.
Once everything was finalised, it was time to move to a PCB. Here is the first off the line.
I have been moving towards labelling things as "Tynemouth" recently, rather than "Tynemouth Software", so this is the "Tynemouth" "Software Serial Card", rather than the "Tynemouth Software" "Serial Card". And never the "Tynemouth Software" "Software Serial Card".
What it can do
- Bit bash serial transmit at the following rates
- 57600 BAUD (3.25MHz clock)
- 115200 BAUD (6.5MHz clock)
- 115200 BAUD (7.3738MHz clock with extra padding for 64 cycles per bit)
- Other BAUD rates with more padding code
- Bit bash protocols other than RS232 8N1 if you want to write the code
- Blocking and polled serial receive
- Load TAP files over serial
- Save TAP files over serial
- Type FS files over serial
- Echo screen to serial
- Remote typing via serial
- Report CTS status
What it can't do
- Change BAUD rates on the fly
- Interrupt driven RX or TX
- This means currently the MS BASIC and CP/M ROMs for RC2014 will not work
- Operate with only TX and RX, it needs RTS and CTS for hardware flow control
- Make tea (working on it, for a future revision)
What next?
I have listed these on Tindie, as usual in kit or assembled form, with optional IC sockets if you want.
I am still working on tidying up the changes to the enhanced ROM for the Minstrel 4th, so will offer that as a download or an optional programmed ROM.
I would like to get this working with Grant Searle's modified Microsoft BASIC ROM, so it could be used on standard RC2014 systems. That uses the interrupts, so need more than a trivial change to make it work. It should be OK as it polls the status register to check for a byte, I should be able to change that to do the quick "toggle RTS and wait briefly to see if there is a start bit received".
I am hoping this will be seen as a neat idea and a good companion board to the Minstrel 4th, and not "some idiot thinks he can bit-bash high baud rate RS232 on a Z80......"
Adverts
The new Software Serial card is available from Tindie,as a kit or assembled, and with an optional replacement ROM if you don't want to burn your own.
The Minstrel 4th is also available form my Tindie store, optionally with a Software Serial card included:
Shipping
I can still ship worldwide.
Currently shipping Royal Mail to the US is working. You pay the 10% tariff upfront (as part of the postage), so that should be plain sailing and no problems with customs. We're all pawns in a petulant child's political games, but we've got to just keep going and try to make this stuff work.
I have also built some more Mini PET 40/80 Internal boards, since the Mini PET II is still in development but people keep asking, so here they are.
Patreon
You can support me via Patreon, and get access to advance previews of posts like this and development logs on new projects like the Mini PET II and Mini VIC and other behind the scenes updates. This also includes access to my Patreon only Discord server for even more regular updates.
