Pretty much since the launch of the Minstrel Issue 2 ZX80 clone, people have been asking for this to be ZX81 compatible. It's taken quite a while to get there and beyond, but the
Minstrel Issue 3 has now been released.
I went through quite a number of revisions and design changes, so here it what went on behind the scenes.
First a quick recap.
Minstrel Issue 1
This was the first attempt at a ZX80 clone. It was pretty much the ZX80 schematic. The only changes at that point were the replacement of the 2532 ROM chip with a 27C64 EPROM, and the two 2114 RAM chips were replaced by a single 62256 chip. No extra address decoding was added, so the RAM was limited to 16K. The video modulator was replaced by a simple transistor buffer to give a composite video output.
The worked, but the video output suffered from the same issue as the ZX80 (and the ZX81 with all but the last revision of the ZX81 ULA). It lacked the back porch section of the composite video waveform. This should follow the horizontal sync pulse and sets the black level for the waveform. Without it, modern TV sets misinterpret the video and it looks very light and washed out without it. I added an extra chip to the design, a few logic gates to add a the missing backporch.
Minstrel Issue 2
The Issue 2 followed on shortly afterwards, and was the first that was widely available. Minstrel 1 boards must surely now be worth a least £1M each.
This added the expansion edge connector, the backporch circuit and a reset button. It also went blue part way through the run, and that sort of stuck. Other than a few minor teaks to the layout, that is still the version available today if you want a ZX80 clone.
Minstrel Issue 3
In order to move on, the next version had to be ZX81 compatible, but I had built up quite a list of requirements beyond being about to run 3D Monster Maze.
- ZX81 compatible slow mode
- It had to still be usable as a ZX80 (but not necessarily 100% compatible)
- Use the full 32K RAM chip
- Improve the composite video output levels / structure
- Improve character pixel output (make synchronous)
- Remove the less common parts (e.g. 74LS05, 74LS93, 74LS365 etc.)
- Reduce the overall chip count if possible (e.g. 2x74LS05 replaced by 1x74LS244)
- Remove some of the more 'analogue' parts of the circuit
- Still fit within the ZX81 board form factor
- Resolve issues with height of 7805 switching regulators (move part or add second set of pads)
- Reduce reliance on chip quality (i.e problems with old 74LS08 chips not working)
- Remove jumpers, replace with DIP switches
- Add turbo mode (a faster slow mode)
Minstrel Issue 3 V3.1
The first attempt at a replacement came with the Issue 3 V3.1 boards. These were red to match the back of the ZX81 issue 3 PCBs, although the red soldermask didn't match the original, and ZX81 Issue 3 boards had no soldermask on the top side anyway, so it wasn't really a match at all.
This had lots of things changed, I tried to address everything on the list, and it was too much, too many changes, and it didn't work.
I spent a while going through trying to track down the problems. I now know what most of the causes were, some of the things were dead ends, I didn't like the DIP switches, I didn't like the idea of putting the narrow RAM chip under the ROM chip, and I didn't like the use of 245 chips, and it just didn't look like a Minstrel.
Minstrel add on board
Lots of things were going on at the time, so I left this for quite a while. I did look at doing a more controlled step by step change, and also the possibility of doing this as an add on board. I designed this board, I think I even ordered the PCBs, but I don't think I ever built any up. It was going to require too many track cuts and wires between the boards, it wasn't really viable.
This had most of the replacement circuitry, and a few new things, including the unusual idea of adding a Commodore datasette connector for loading and saving. Not sure how that would have gone down with the Sinclair community. I forget which way it is, but load or save would need to be inverted to use it, and it would need some sort of motor control. That didn't go any further. Maybe one day...
Minstrel Issue 3 V3.2
After another long gap, I went back to the Issue 2 Minstrel design and took things a bit slower. First off, this one looked like a Minstrel, so I was happier and stuck with that layout. This had
Grant Searle's ZX81 slow mode design, with a bit of optimisation, removing some things no longer required, such as the old HSync flip flops.
Jumpers were used to control the slow mode and the ROM image, and also to enable the extra 16K of RAM mapped to 48K-64K. A transistor circuit was used as the T-state synchroniser as in the original ZX81 schematic.
This board didn't tick all of the boxes, but it was a start. It's always good to be greeted by the inverse K. Lots of things need to be working for that to appear, so it's a very good sign.
Well, that's one thing ticked off, 3D Monster Maze was one of the first games I played on my ZX81 back in 1981 (or maybe it was 1982), and has been a favourite ever since.
I could have released this at the time. I did consider it, but I knew it could be made better, and didn't want to release something then come out with a better version a month or two later. The video output on this board was the same as the Minstrel V2.7. There was a backporch signal generated using an RC pulse extender circuit. This had caused some issues with some out of spec 74LS08 chips that led to odd effects particularly on the line below the last character line (from the blog post on
Minstrel Troubleshooting).
According to the composite video standard, the backporch pulse should be 5.8uS, and should follow the 4.7uS horizontal sync pulse. The V2.7 Minstrel generates a pulse which is dependent on the tolerances of the R and C used in the circuit, and the analogue properties of the 74LS08 AND gate, so varies a bit.
The sync pulse is generated from the a free running timer which resets every 207 counts. When the count is between 16 and 31, the horizontal sync pulse is generated. This works out as 16 cycles of the 3.25MHz clock, 4.92uS. It seemed like best option was to digitally generate a second pulse and to use that for the backproch signal. That could also be 16 cycles for simplicity, also 4.92uS, both close enough to the standard to work out.
Another issue to address is that the pixel data part of the video signal was taken directly from the output of the 74LS165 shift register and was not synchronous, the pixels were not necessarily the same width.
This was normally not an issue with text, but was visible in when graphics characters were used next to each other, such as the scene above from Paul Farrow's Pacman, where there are noticeable gaps between the characters.
Zooming in closer, you can see the pixels to the right of the gap are thinner than the rest. If they were the same width, the gap would not be there. One way around this is to change the 74LS165 for a 74LS166. The output of the 166 is synchronous with the main clock, so the output pixels would all be the same size. The pinout is unfortunately very different, so I had to manufacture an adapter to try it out.
However, the input is not triggered on an edge as it is on the 165, it is latched when the enable is low and there is a clock edge. This doesn't quite fit with the timing, the following from my blog post on '
How the ZX80 works' (you can also see the first pixel of the second T1 is thinner due to the LOADSR pulse above). I tried various options to find a suitable way to latch the data at the end of T4 / start of the next T1, but I couldn't get it to work.
I did think about adding in a separate 373 latch to store the data on the LOADSR signal, for it to be later latched into the 166, but that was getting too complicated. The alternative I went for was to feed the output of the 165 through a D type flip flop, clocked by the 6.5MHz clock. This will means it will changes once each clock cycle, on the clock edge, so all the pixels will be the same size.
There was also a clear input which could be driven by the backporch signal to set the black level on the output, saving an AND gate.
During this time, I knocked up a little modification to generate a border to the screen, this was useful to see what was going on and was quite handy for my 'How the ZX80 works' blog post.
I had planned to use this to generate a valid composite screen with just the grey crosshatch pattern on when no video was being generated. This would help when fast mode was active and no signal was fed to the TV. I didn't manage to find a way to detect the lack of vertical sync signals sufficiently well to not be also triggered by some high resolution graphics modes or file save / load etc. So that was never completed. However, it did hang around to generate a screen border in normal mode, and it sort of grew on me so I have left it in as an optional feature.
Minstrel Issue 3 V3.3
With the changes above, and a few more, board version 3.3 arrived.
This version removed the 16K/32K jumper (which didn't seem to be necessary), and also rearranged some of the logic to reduce chip count. The pixel synchronisation and back porch modifications appeared to be working, but I was noticing an occasional thin faint black line down the left of the screen. This photo shows it from later on when I managed to make it worse.
Looking at the video signal, it appeared to be a dip in the video signal around 16 cycles after the backporch signal.
This one took a lot of head scratching, but it seemed to be a glitch in the decoding logic which generates the horizontal sync and backporch signals from the counter outputs.
I tried a few different arrangements of decoding logic, including using a 74LS138 to generate the HSync and Backporch signals. That was even worse, and gave the solid black line seen in the earlier photo.
Looking at this on the logic analyser, the glitch was there, and the clue was, it happened when lots of bits of the counter changed at the same time.
This turned out to be an issue with the 74LS393 counters. The outputs of which do not all change at the same time. I managed to catch one of them where it registered on the logic analyser (I was only running at 12MHz capture at the time, so the dots show the sample points). But you can see the Q6 does not go high at the same time as Q4 and Q5 go low.
To test this, I setup a simple 4 bit counter with one half of a 393. Although it appears to count 0,1,2,3,4,5,6,7 etc. if you look closely at the point they change something different is going on.
Here it can be seen that between 3 and 4, it briefly registers as 2 and 0.
It's not a massive delay, but it means any decoding logic looking for a 2 or a 0 will misfire during the 30nS period between 3 and 4. This is what was happening here, the backporch condition appeared again briefly 16 cycles later. I think I worked out that according to the datasheet the worse case was 84nS between Q0 changing and Q7 catching up. More than enough time for the line to be visible (that's about half a pixel width).
Time for a change of plan. There are synchronous counters (with buffered outputs that all change together), but nothing that appeared suitable for this situation. I'll save you too many of the intermediate stages, but this it where I ended up. To test this in isolation, I went back and applied this modification to the V3.2 prototype board.
A flipflop on the left generates a single pulse every 207 cycle period. This pulse is clocked through by the Q3 output of the first stage of the counter at 3.25MHz/16. The flip flop is reset after the first Q3 pulse and stays off until the reset pulse at the end of the cycle. The two D type flips flops clock this single pulse through, generating first the horizontal sync pulse, then the backporch. A little over complicated maybe, but it generates nice clean signals and there are no glitches.
Back to Pacman and the vertical gaps are gone, all the pixels are nice and evenly sized and evenly spaced.
When zoomed in, you can't see the joins between the greyscale characters.
That's all looking good. I tried out quite a few ZX81 titles at this point, and all were working well. No gaps, no lines.
Tut-Tut is looking good.
No visible gaps there.
Some 'pseudo high resolution' titles, such as a 1980s version of Manic Miner worked.
However, some of the more modern titles did not look quite right, such as the 1K HiRes games.
This came down to two things. Firstly the main 'High resolution graphics enabling device' was a 10K resistor pulling the R/W line on the RAM high.
That was easy. It just means the RAM will default to 'read' mode when not being driven by the Z80, so it can be used for pixel data during the screen drawing routines.
That didn't fix all the issues, I think it was the 25th Anniversary demo that kept me looking to solve this, I kept getting more and more of it working, and finally got all the elements working, I was happy to call it finished.
I think it came down to the memory map, and I tried various memory configurations. The 74LS138 again almost made it into the design, I had it decoding the address range and some AND gates generating the ROM and RAM selects. I found some articles about Hi Res graphics on the ZX81, and they showed an example for a ZX81 RAM expansion that used a 251 to achieve the same thing, sort of in reverse, but without the need for decoding logic
It's quite a clever use of a chip, it has two output, one the inverse of the other, so when RAM is selected, ROM is not and vice versa. These are connected to one of eight inputs based on the upper three address lines. The output enable pin input disables both outputs when not in a memory request cycle or refresh cycle (i.e. drawing the screen), and the 2K2 resistors pull those output high to disable the ROM and RAM. The 680Ω resistors allow the RAM_CS and ROM_CS lines to be overridden from the expansion port.
This was again prototyped with all the maze of blue wires on the V3.3. board, and tested more tidily on the V3.2 one.
Address Range
|
Use
|
0000-1FFF
|
ROM
|
2000-3FFF
|
RAM
|
4000-5FFF
|
RAM
|
6000-7FFF
|
RAM
|
8000-9FFF
|
RAM
|
A000-BFFF
|
ROM
|
C000-DFFF
|
RAM (during refresh cycle)
|
E000-FFFF
|
RAM (during refresh cycle)
|
The final memory map has RAM from 8K to 40K, with 16K-32K mirrored at 48K-64K for display use (active during the refresh cycle).
The 25th Anniversary demo was quite impressive when I got it all working, particularly given the lashup it was running from.
Minstrel Issue 3 V3.4
The V3.4 board was produced to implement all of those changes, again I tried to reduce the chip count a bit, this mean swapping gates around, a bit of De Morgan's law to minimise the number of gates used. It did leave the occasional oddity, such as the 'invert this character' flip flop.
Originally implemented with four NAND gates, I swapped the 74LS93 counter used in the original ZX80 design for another 74LS393 which was a dual counter as I was already using one of those in the horizontal sync counter circuit. That left one spare half which I was able use with some other left over gates to make this version of the 'flip flop'.
I also managed to cheat a couple of logic gates out of spare elements in one of the multiplexors. It was switched on the /Refresh signal, so the signal that should be low if /MReq is low or /Refresh is low is generated here, also LatchEnable which was previously a three input NAND gate.
Even with those savings, this version of the board was very full, more so if you look under the main chips, where I had hidden a load of resistors.
The board worked, with one minor issue. It initially looked OK, but there were some oddities with certain characters.
Further investigation showed there was a problem with the polarity of the clock signal fed to the line counter, so it was counting from one ahead, 1-7, then going back to 0, rather than going 0-7, so it was displaying the wrong rows. A small bodge wire on the back resolved that.
So this board is now 'feature complete' and working, but I wasn't really expecting it to be the final revision. I had not bothered to manually route the board, as I wasn't happy with how many chips where on there and with having to hide resistors under the chip. So with the schematic logic sorted out, it was time for some more optimisation. Some other chips in line for replacement were the 74LS05, open collector buffers used mainly for the NOP generator, and the 74LS365, an input buffer used for the keyboard input port. I had looked at replacing both of those with 74LS244 or 74LS245 buffers, but it didn't look quite right when I had tried that on the red V3.1 boards, so came up with the idea of using 74LS257s.
These are quad multiplexors, which will select one of two inputs, like a 74LS157, but also have a tri-state output, so they can do three things, input 1 -> output, input 2-> output, output disconnected. That meant one input could all be tied to 0V for the NOP generator, and the other to the keyboard inputs. The output was the CPU databus, and in the third state, nothing would be connected to it. I could also replace the three existing 157s with 257s, just leaving the output enable permanently active.
Those changes got rid of some of the less common chips from the old ZX80 design, and used more easily available replacements, and also saved me a few chips from the chip count. I did take advantage of a spare XOR gate and added the 'mists of time' circuit back in to generate the grey crosshatch border, and added that as a jumper selectable option.
One thing I had been trying out was different positions for the 5V regulator. I wanted to keep the option of a 7805 (I'm pleased I did - more later), but also the Recom 7805 replacement switching regulators I had been using on the Minstrel 2. They are slightly taller, so will not quite fit in a ZX81 case. There is a flat version of the Recom regulator, but it's more than twice the price. On the V3.4 boards, I had tried adding two sets of pads, so the switching regulator could be mounted further back (and thus fit in the ZX81 case).
I didn't like the look of that, and I wasn't happy to lose the 7805 completely as I had in V3.2 and V3.3, which only had pads rotated 90 degrees to fit only a Recom regulator.
Minstrel Issue 3 V3.5
OK, here we go. This is hopefully the final revision. This time, I wanted to fully manually route the board. The previous revisions I had expected would probably not be the final versions, so had done the important routing by hand then autorouted the rest and tidies up the most egregious autorouting inefficiencies.
Here, I started with the important ones, then kept going. Keeping all the traces short and direct, all the vertical lines on the back, horizontal lines on the front, but still trying to reduce the number of vias.
It was a slow process, I think it took about a week on an off, doing bits here and there whilst taking a break from other things. I find it quite relaxing, a bit of a mental puzzle. Some people play patience, some solitaire, some Sudoku. I route PCBs.
It was then just a case or ordering the PCBs. Whilst waiting for those, I updated the manual for the Minstrel 3.
I tried to get the schematic to fit on a single page, but in the end I gave up as it would be too small and difficult to follow. I left it split into logical blocks and with some description text, it ended up taking not one page but six.
When the PCBs arrived, I built up a board with all sockets and gave it a go.
Everything seemed to be working. In this state, I often miss the regulator off and feed the board 5V DC direct from a bench power supply, to check current consumption.
The consumption at 5V with 74LS series chips was around 200mA.
One of the aims was to reduce reliance on the analogue properties of the chips, and remove the more esoteric chips from the parts list. That meant I could try something that I had been considering, which was moving to 74HC series logic. Normally this stuff shouldn't be within a hundred yards of a vintage computer as it does not cooperate well with TTL logic, and hadn't been possible before as not all the chips were available in HC versions, and it wouldn't work with a mix. Since this was pretty much a closed system, I could take advantage of HC and produce a fully CMOS system.
Moving to CMOS reduced the current consumption to around a third, quite a difference. There were two issues with using HC. First, was a little odd. All the keys on the keyboard worked, except shift + anything. This means I could type PRINT, but not PRINT "".
After a bit of poking around, I found that changing the 257s on the keyboard / NOP section to LS made it work. Going back to HC, it stopped working again. I traced this down to the pullup resistors on the input port. 47K resistors were used on the original, and I had seen no reason to change, but here, they were giving the wrong results, I think due to the lower input current and more sensitive inputs of the HC chips? Changing these to 10K solved the problem.
This just means the first batch of boards come marked up for 47K resistors with instructions saying to fit 10Ks in place of the 47Ks. I'm sure these will become valuable collectors items in the future.
The only other issue with HC logic was for some unknown reason, the SN74HC02 chips were all different shapes to all the rest. I ordered more from different suppliers, but they all looked like that. I like to try to keep the board looking neat, and that was a deal breaker for me.
Luckily the day was saved by the CD74HC02, also from Texas Instruments, but the same shape as the other chips on the board and all was right in the world again.
Another oddity I noticed was the 7805 regulators I ordered appeared notably thinner than the standard ones.
Turned out to be the difference between the KCT suffix and the KCS. When I got some of the correct KCS package type, I tried these out and at 64mA draw, they didn't even get warm after several hours use (9V-5V = 4V, P=4*0.064 = 256mW). So that's decided then, we can just use standard 7805s with no heatsink required, and no need for the switching regulators any more (unless you plan to hang loads of 5V hungry devices out of the expansion port, which was never a good idea with a real ZX81 anyway).
And why not rivet them in place, seems sort of fitting. Something Commodore did with the transistors on most of the PETs until about 1982.
Looking back over the original list of requirements, I think I achieved most of the things on there, including a few new ones such as changing to 74HC series logic and adding an extra mounting hole to make the board more stable on the baseplate and placing the nylon screws away from the heatsink area (even though it runs cold anyway).
I didn't go for the DIP switch configuration, that didn't seem right, so I stuck with jumpers or wire links. I also didn't look again at the turbo mode. This was an idea from an old webpage which suggested adding an extra transistor to the T-State syncrhoniser to create a latch that would allow code to run at the end of the scan lines as well. I didn't think the claimed 10% speed increase in slow mode was worth it, against the potential issues it may cause for game timing etc.
So that's about it, I'm sure I've missed out some bits and a few more blind alleys I wandered down during the design process, but here it is, a fully working ZX81 compatible computer with 32K of RAM, high resolution graphics support, improved composite video output and reduced current consumption. Not bad at only four chips and a handful of decoupling capacitors more than the Minstrel 2. This is now a viable replacement for a faulty ZX81 board, it will fit in the original case and picks up on the same mounting holes (the two screws you fit before the lid are ringed in white on the silkscreen on the back of the PCB to help installation).
Of course, you can also use it as a standalone machine, on a baseplate with a ZX81 replacement membrane.
Or with a
tactile switch keyboard with overlay PCB.
The Minstrel 3 PCB is available from My Tindie Store as either a PCB, or as a kit or fully assembled.
2022 Update: At the time of writing, there are still a few Minstrel 2 (ZX80) and Minstrel 3 (ZX81) kits available from The Future Was 8 bit but those are the Final Edition kits, there are unlikely to be any more.
Patreon
You can support me via Patreon, and get access to advance previews of posts like this and behind the scenes updates. These are often in more detail than I can fit in here, and some of these posts contain bits from several Patreon posts. This also includes access to my Patreon only Discord server for even more regular updates.
https://www.patreon.com/tynemouthsoftware
