When I originally wrote this post for Patreon back in September, it was going to be called "When to give up on a project because it is just not possible". However, as I was writing it, I kept thinking of new ways that it might work, so suggested that it may end up being called "Wow, look at my fantastic new product!". Place your bets now, which way it is going to go?
I don't normally push the Patreon, but if you enjoy posts like these, I would encourage you to give it a look. It starts at $1, but you can pay as much as you think it is worth. My Patreon supporters are great, and I thank them for sticking with me. The more support I get on there, and the more sales on Tindie, the longer I can keep this going. It's been a tough few years, not sure I can weather too many more if things don't pick up soon.
Thank you, now back to your normally scheduled programming.
A post 5 years in the making, let's go back and see how this journey began....
Back in 2020, when I was first working on the Minstrel 4th, I wanted to add a serial card, but had limited options available.
The "standard" RC2014 serial card at the time used an Motorola MC68C50 ACIA in an arrangement that was based on Grant Searle's Z80 SBC design.
I built one of these as part of my first RC2014 setup, using what is now the "classic" shape - the long and thin version, rather than the now standard punched card shape. (what do you mean you didn't know it was the shape of a punched card?)
This was intended to be used with a Z80 clock of 7.3728MHz, that may seem unusual, but the 68B50 divides that down to set it's baud rate, and if you divide that by 64, you get 115,200 which is a standard baud rate.
The Minstrel 4th needed to run at 3.25MHz to be compatible with the Jupiter Ace, although it could be jumpered to run at 6.5MHz or one of the clocks from the RC2014 bus.
To get around that, I designed a 68B50 card with a built in clock oscillator and a 7.3728MHz crystal. That was used to drive the ACIA and get the 115,200 baud rate, whilst the Z80 could run from a separate clock at 3.25MHz.
That worked well, and that was available as an option from my Tindie store when the RC2014 was first sold.
The 68B50 was discontinued many years ago, so is only available as "New Old Stock" (i.e. some actual NOS, some rejects, some pulls, some desoldered, some remarked, some fakes).
I never have much luck with NOS parts, so I like to use only new chips if at all possible. When I was selling those, I was going through tubes of NOS chips, testing them and only shipping the ones that actually worked. The yield varied, but once I had got a total of three working chips from two full tubes, I decided to call it a day and discontinued that.
Spencer who designed the RC2014 system seems to have better luck than me (or maybe a better supplier than me), and sells various versions of the RC2014 serial card and all-in-one RC2014 systems with the 68B50 on them. We came to an arrangement, and he now makes my serial card with clock kits under license and sells those on Z80kits.com.
There should have been another way.....
I decided I needed an alternate serial card. I looked at two options that were still in production (at the time), the Z80 SIO and the W65C51.
Z80 SIO
The Z80 SIO is a larger, more capable, dual UART designed for Z80 systems, so seemingly perfect, if a little expensive.
I did design a board for that, similar to the ones already on sale, but with the separate clock oscillator.
It seemed there were a few different designs in use with different addressing (hence the B/A and C/D jumpers). It also needed different driver code writing, potentially for two or three addressing options. There were already existing libraries with 68B50 support.
The Z80 SIO has now been discontinued, so no point in pursuing that any further.
I still have the PCBs and a tube of SIO/2 chips (which must be worth $1M each by now) if anyone is interested in such a card.
W65C51
The 6551 ACIA is a similar to the 68B50, but with some additional features, including a baud rate generator which needs a 1.8432MHz crystal to generate the baud rates, again chosen to divide down neatly (÷16 gives 115,200 baud).
The Commodore version of that, the MOS 8551 was used in the Commodore plus/4, complete with a massive 1.8432MHz crystal. A rare case of a proper serial chip in a Commodore product, sadly let down by the connector (that's the plus/4 story in a nutshell) as it pins were scattered around the userport. A built in terminal might have helped it as well?
There is a version of that in production now. The W65C51N from WDC, who also make the W65C02S, W65C21N and W65C22N chips I use on the Mini PETs.
This chip has, or rather had*, a problem. There is a bit in the status register that (TDRE, Transmit Data Register Empty) that is broken and always reads 0**.
* it is now a feature
** later chips now always read 1
It is meant to be normally 1 and is set to 0 when a byte is written to it from the Z80 side. After the byte has been read and transmitted, it should return to 1. The Z80 code polls this and waits until it returns to 0 before loading the next byte (or uses an interrupt based on the same bit).
When this chip was first launched this was in described as "an issue".
Later, they suggested using interrupts to get around that.
The datasheet has since been updated, I think they tried to fix it, but somehow managed to not fix it and it now always reads 1.
Oh, and they appear to have broken the interrupts in the process, so now recommend a delay loop.
What you have to do is send a byte and then wait a while and then send the next one. How long you wait is based on the BAUD rate, so you have to remember that and work out how long you should wait, plus a bit of leeway, and then just blindly hope it is gone before you upload the next byte.
Too fast and you can overwrite the currently transmitting byte.
Oh, and you need to check CTS isn't stopping it being sent, but you might have missed a brief moment when CTS was clear and it was sent and you think it still hasn't gone.
You can wait a long time to be safe, but that slows everything down.
Oh, and the latest datasheet seems to imply parity is now broken also.
I did design a board, but I don't think I actually got any made, due to those issues and also needing a different version of the driver software.
It's a real shame, if they could fix the issues features, the W65C51N would be the go-to chip for any of these 8 bit projects.
(I did consider a version which generated a valid TDRE flag by counting clock cycles of the RxC output after data had been latched and with CTS low, but that looked a bit over complicated, so I didn't bother finishing it. Maybe I should have spent more time of that option, but I thought they might just discontinue it)
Pseudo 68B50
Hang on, I thought to myself, the 68B50 isn't that complicated, why can't I just get a microcontroller to replace it?
How hard can it be?
(as I write this, I feel I maybe should have looked at the problems WDC had.......)
Well....... five years later, I think I might have finally given up.
I have been through various different iterations, all of which worked "most" of the time, but none of which were good enough for me.
V1
The first version used an Arduino Pro Micro module, an ATmega32U4 microcontroller with a USB socket and some IO pins around the side. (essentially a shrunken Arduino Leonardo)
My thinking was I could set that up as a USB serial port and then just mimic the four registers in the 68B50 to transfer the data from the USB.
Easy, right?
The 68B50 has four registers, two read, to write.
- Transmit data (write only)
- Control register (write only)
- Received data (read only)
- Status register (read only)
The problem I had was one of timing. Ideally, I need to support the Z80 running at up to 10MHz. They did make a 20MHz version, but that wasn't used much. It is more likely to be on a Minstrel 4th at 3.25MHz or 6.5MHz, or maybe used on an RC2014 system with an existing 7.3728MHz clock etc. so it could be anything up to about 8MHz.
That gives quite a small window to detect an IO Read, prepare the response, write it to the data port, enable the data port and then wait for the end of the read operation to disable the port again.
Write operations were a little easier, just detect the write operation, and read the data from the port in time.
But there just weren't enough cycles to make it work reliably, it kept missing things.
V2
OK, why don't I make the registers hardware and keep them topped up with current data whenever it changes?
I designed another board, not a very elegant solution, but maybe a solution.
This had four 574 latches for the registers, so they could be read from, and written to, at Z80 bus speeds without affecting the microcontroller, which could then deal with things in it's own time. Sort of like two bytes of dual port RAM.
It was very close to being released. I found I had actually written the blog post about it, 31st of March 2020, covering the new cards to be launched for sale in time for the Minstrel 4th release on May the 4th 2020.
That almost worked, but there was a race condition that the TDRE bit could occasionally get read before the microcontroller had a chance to set it, so if the code was fast, it could think it had been sent before it had even started.
V3
After a lot of testing, I concluded I needed an extra flip flop so the TDRE bit was automatically cleared when a byte was written, and I think I also automated the receive equivalent.
Again, that just about worked, but I don't think I can ship them like that.
Time for another PCB.
And a lot more testing. In both the Minstrel 4th
and an RC2014 system.
That was useful for running things like the RC2014 demo of a Mandlebrot set.
Again, it was almost right, but it kept skipping a beat every now and then. I think it was down to some timing condition around USB interrupts?
I couldn't get it to 100%, and I wasn't happy to sell something that only worked most of the time.
It also seemed a bit silly having all those chips on the board.
I concluded that wasn't going to work, so put it aside.
V4
Sometime later, I did wonder if it would be easier if I forgot about the USB side of things and I tried going back to a 5V serial port using an FTDI USB to serial cable and the standard 6 pin header, just like the other RC2014 serial cards.
That didn't really get off the ground, I can't remember why, I think it was the timing again.
I was considering pairing that with the Microchip MCP2221A USB to serial device, which was available as a through hole part. The earlier MCP2200 would have been better as that had RTS and CTS, but that was only available surface mount.
I tried that on a few things, including a C64/VIC20/PET board, but unfortunately I couldn't get hardware flow control to work with that, it doesn't seem to have a way to add byte level RTS/CTS control, it also had a limited buffer and would simply overflow on long lines.
V5
When I was looking at bringing back the Minstrel 4th earlier this year, it seemed like it would be good to have a serial card option.
Here we go again
I was investigating the newer AVR microcontrollers, and it seemed like they could breeze through something as simple as this.
My thinking was a Z80 OUT instruction is 12 Z80 cycles, say at 8MHz. That would mean the AVR at 24MHz would have 3 x 12 = 36 cycles to deal with it, and with mostly single cycle instructions, that should be easy.....
Well, no it wasn't.
Turns out my thinking was flawed, and the actual IO read part is 3 Z80 cycles at most, with the actual IORQ line only going low for about 5 cycles on the microcontroller, and that wasn't quite enough.
(I can't find any photos of the board I built to test this, but I did find the PCB design shown above, and also a version with an external clock that I had forgotten about)
V6
Recently, I decided to revisit this, and with a bit of shuffling around, I was able to reduce the number of cycles I needed to read the port by moving all the relevant pins onto one port and doing a single read.
I rewired one of the previous boards to give that a go.
But again, it just wasn't enough, and it would occasionally miss a byte depending on exactly when it sampled things.
I did nail one thing that had been annoying me with my standard serial module. The LEDs show activity on the RX and TX lines and they aren't very visible when you are just sending a few characters.
Using a convoluted combination of various timers and the CCL and event systems I was able to extended the pulses so the LEDs were always on for long enough to be visible even with single characters.
(this is the example I am working through on part 2 of the New Microcontroller Features post, but I really need to go back to an empty project and start again and get new screenshots for that)
Time to throw in the towel?
After many, many attempts and various different architectures, I finally concluded that such a thing was virtually impossible.
One night, a student left to clean up after a particularly unsuccessful party, found himself reasoning as follows: if such a machine is a virtual impossibility, it must be a finite improbability. So all I’d need to do is work out exactly how improbable it is, feed that number into the finite improbability generator, give it a fresh cup of really hot tea, and turn it on! - Douglas Adams
Tune in next week to see if the Bambleweeny 57 sub-meson Brain and atomic vector plotter I ordered off ebay arrive in time to make this a finite possibility.
Spoiler
Now I have all the issues resolved and a working solution, I have listed the new card on Tindie. A full post on that will follow next week, look away now if you don't want to see the solution.
Adverts
The Minstrel 4th is available form my Tindie store, optionally with a Software Serial card included:
The Software Serial card is also available separately, as a kit or assembled, and with an optional replacement ROM if you don't want to burn your own.
Shipping
I can still ship worldwide.
Currently shipping Royal Mail to the US is working. I can 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.
