I have added a new option to the Minstrel ZX80 Clone kits and builds, it's own keyboard.
This has been designed to match up with the Minstrel board, so it makes it almost a single board computer.
The Minstrel board itself remains ZX81 sized, the keyboard plugs into the keyboard connector on the bottom right.
These are mounted under the board. I am using 0.1" pin headers and sockets, and these will be supplied in the kits. You could use wire links, or even add cables and run the keyboard a short distance from the main PCB, a Minstrel-SK if you like.
There are a couple of unusual things with this PCB, both of which were done for aesthetic reasons. Firstly, there are no tracks on the top layer of the PCB.
The traces are all on the bottom. The keyboard is a matrix, the whole point of which is a set of rows cut across a set of columns with switches where they cross, you can see that here in the underside of a ZX81 keyboard membrane.
The obvious choice then is to draw the rows on one side and the columns on the other. Instead, I used a trick that used to be very common on matrix keyboards, but you don't see very often these days.
The tactile switches used have 4 pins, two sets of contacts wired in parallel, so in the above photo, the top two pins are actually the two ends of the same bit of metal. This means you can pass the signal through that wire link, and run another track underneath.
The green trace is on the PCB, the red is via the switches. You can see the blue column traces pass beneath the red lines.
This means you can lay the matrix out quite neatly on a single layer. This was done a lot in the 1980s when for large boards such as a keyboard, they could use a cheaper single sided PCB.
These days that is less of an issue, with the availability of cheap PCB production in small quantities, with boards coming in double sided with plated through holes, solder mask and silkscreen printing. The only slight problem I have is due to the volume of boards they produce like this, there is often a small code added to the silkscreen by the PCB manufacturer.
Sometimes they are kind enough to add these under a socket or an IC. But sometimes they end up in a really annoying place in full view on the assembled product.
I had an idea a while ago, but I had not had the right board to try it out on. My theory was they always put the code on the top of the board, so why not design it upside down? So it did.
This is actually the top of the keyboard PCB in the design files, and there they have stuck their code number. But when I get the board, I simply flip it upside down and have no annoying code number.
All I need to do now is design all my PCBs upside down. That can be quite challenging as it is mirrored, but in this case it was quite easy. This was my view in the PCB software.
However with anything more complicated, the mirroring would be confusing. I haven't looking into the format of the gerber files, but I presume it should be possible to write a bit of code to flip an existing board over. There's a coding challenge if anyone fancies it.
The new keyboard is available separately as a PCB or kit from my Tindie Store.
This is the ZX Max 48, a Sinclair ZX Spectrum 48K clone by Superfo (who also designed the Harlequin). Real Z80, ROM and RAM, and all the logic of the ULA in a CPLD.
It's a new product, I think still in development. I was contacted be a member of the Sinclair ZX World forum and asked to produce some keyboard overlays, in the same style as the ones ZX80 style overlays I do for my Minstrel ZX80 clones. He kindly sent a PCB and CPLD so I could build one.
Like the Minstrel, the ZX Max 48 board is designed to be the same footprint as the ZX81 (apart from the slightly larger edge connector and joystick port at the back).
This means it lines up nicely with the Minstrel keyboard (available from my Tindie store).
However, it was a keyboard overlay they wanted.
I designed this to fit over the ZX81 membrane, but with the ZX Spectrum keywords, symbols, colours and even the rainbow stripe.
Surprising how much smaller than a Spectrum it is, seems closer to the Horizons tape.
If you are using a ZX81 case which has a working membrane, you can stick the overlay directly over that.
You then get a ZX Spectrum style membrane, which can be installed in a ZX81 case.
Either way, you get a ZX81 with a ZX Spectrum style keyboard.
The ZX Max 48 board will fit inside, although you would need to modify the back of the case if you wanted to use the edge connector or fit a joystick port connector.
It's a sort of slightly smaller, slightly deeper Spectrum with a less rubbery keyboard.
You don't have to use a ZX81 case, you can just mount it on a board, or a sheet of perspex.
To do this, I fit the membrane connectors under the board, so the membrane tail is hidden under the board.
It's almost worth doing this just to admire the underside of the ZX81 membrane (this version designed and produced for me by RWAP).
It's not bad from the top side either.
So a complete new Spectrum, with mainly new bits (the NEC ROM chip in the above photo is original, as is AY-3 sound chip).
Well, I suppose I should fire it up now.
It almost worked first time. I got a result with the test ROM, but in monochrome. There are two oscillator circuits, one 14MHz which is divided down by the CPLD to generate the main Z80 clock, and also 4.43MHz which is for the PAL colour burst, but that wasn't running.
I found a similar problem on a Harlequin board I repaired. That had a dodgy 74HC04 chip. I tried a few others here, including the unbuffered version, the 74HCU04 (as used on the Spectrum +2). That didn't help, so I wasn't sure what the issue was. Might have been something up with the crystals I bought. I looked at other series resonant oscillators, and the capacitor value was generally larger, so I swapped out the 100pF for 100nF on the 4.43MHz side and it came to life.
The diagnostics was now in colour and all tests passed.
Back to the original ROM, and we appear to have a Spectrum.
10 PRINT 20 GOTO 10 had to be done.
Time for a bit more testing. Yes, that is a normal sized Zip Stik. And yes, that is a divMMC future.
This is a ZX Max 48 issue 2 board, which has a Kempston joystick port build in (and an AY-3 sound chip). The divMMC future also has a Kempston joystick, so I removed the 74HC366 chip to avoid any conflicts).
Only slight issue was the divMMC future board was a little high, luckily I had the perfect thing, not the usual sort of rubber feet, but it did the job.
Jet Pac ran nicely as did most of the other things I tested. There were shimmering lines in the graphics on a couple of games, I am told there is some updated firmware, so I'll give that a go.
The overlays, membranes, Minstrel ZX80 clones and keyboards are all available from my Tindie store.
Today, a couple of PET 8032 boards in for repair. The first is one of those where I get worried as soon as I see the board.
This one has had a lot of work done to it already. That's usually not a good sign. Many chips have been replaced, others show signs of corrosion and water damage. This one's had a hard life.
The ROMs have all been socketed and some replaced, as has the video RAM and most of the 244 buffers.
This one's not booting, black screen, no sync, so the 6545 hasn't been initialised. You rarely see the garbage screen on these later PETs as the 6545 generates the video sync, so it only works when the PET has started to boot. Early PETs had a series of counters fed from the system clock, so they would generate a video output with no ROM or RAM and even with no CPU.
It looks like this has already been replaced (by a 6845 which is backwardly compatible), as has the 6502, a Rockwell from 1980 rather than a MOS from 1982 as it would have been. Over to the PET diagnostics, and yes we are getting video out, so the 6545 is OK.
Oh dear, that doesn't look good. It is showing 12 of the 16 RAM chips have failed, one of the video RAM is bad, and only two of the ROM chips are reading correctly. Since some of the RAM is reading correctly, it's probably not going to be the RAM address buffering or refresh counters. Power supply is often the cause of such a wide ranging failure, the -5V and 12V rail both only being required by the RAM. The supply rails were all reading correctly, but maybe a previous power problem had taken out the RAM. There are also signs of corrosion, had this thing been running whilst submerged?
This era of boards had a very annoying construction technique, all the chip legs seem to be cut short and bent over. This makes desoldering them a real pain, and so although removing and replacing all the RAM would probably be the best option, it would be rather expensive in terms of time as well as the limited availability of new-old-stock 4116 chips.
A ROM/RAM board seemed an easier option at this point, and it did resolve the issues of both the faulty RAM and the partly faulty ROMs. The only thing it can't address is the video RAM, but that just needed a replacement 2114 RAM and that fixed the issue.
A quick test and the keyboard was working, and it was loading from tape. I try not to put things back in the box as soon as I see signs of life, as it's not always that simple. And indeed in this case, it wasn't. After a while it appeared to lock up, and when reset, it started showing random keypresses from the keyboard. I checked nothing was leaning on the keys, and even unplugged the keyboard. Hmm, looks like the 6520 has failed.
I replaced that, and it was working again, keyboard reading correctly. I started further testing, the IEEE-488 port wasn't working, showing errors on both data (the rear 6520) and NDAC and ATN (the 6522). Then it locked up again. And this time when I reset it, the beep noise was wrong. Oh great, the 6522 has gone as well. I removed and socketed both of those. The beep was now right, but the keyboard was messed up again, so I fitted second new keyboard 6520.
Once again, the keyboard was back to working, and the IEEE-488 was almost there, still a fault on NDAC, which looked to be more likely a 3446 buffer. Before I got around to fixing that. It locked up and the keyboard went funny again. OK, at this point, all three 6520/6522 chips had been replaced, and were working, but I was reluctant to fit another. Time for a different approach. It seems something on the databus must have a faulty enable line and is enabling itself, or is being enabled at the wrong time, and is causing a bus conflict, as this thing appears to be killing chips.
One of the likely causes of things being enabled at the wrong time is the 74154 which provides 16 enable lines, one for each block of 4K in the system, but I see that has already been replaced. All the ROMs, and the 244 buffers which provide the buffered databus for the video circuitry had already been removed, socketed and replaced, so I removed those, and also took out all the 40 pin chips.
I was going to start testing with a NOP generator, but first I thought I'd check that there was nothing untoward with the clock and control signals and nothing pulling the busses high or low.
Then I looked at the D6 line. Hmm, that's not right. It was a regular pulse permanently on the D6 line at about 15.6KHz (1MHz/64 ?). All the others were floating as expected, but this was being actively driven. The only thing left connected to D6 at this point was the RAM. Even with no CPU, that was being refreshed, and although I couldn't see any of the address lines at that sort of speed, they were all faster as part of the refresh cycles. I did find a 15.625KHz pulse on one of the outputs of the refresh address counter, so it was presumably a multiple of the update rate, pulling high for 63 of every 64 refresh cycles or something like that. So it looks like one of the RAM chips was indeed faulty and without being asked was constantly writing to the databus, fighting with anything else trying to drive the bus. This being a CMOS device, it would have been a FET pulling it high to 5V, not just a weak resistor like a TTL output, so this thing could have been responsible for damaging half the chips on the board.
Removing the two 4116 RAM chips attached to the D6 line, the 15KHz signal had gone and all looked well. I put the new chips back in place and retested. I had replaced the 3446 buffer, and now the IEEE-488 was working as well. I went back and retried all the previous 6520 and 6522 chips, and unfortunately, all apart from one 6520 were showing faults now. Whilst the system hadn't been booting, they hadn't been writing to the bus, but as soon as it booted and they started writing to the databus and fighting with the RAM chip, their outputs drivers must have been damaged.
The board has now been running all morning, no signs of any further problems, I think the culprits have been found.
The second one also showed signs of previous work, although I was less worried on this occasion, as I had done the work. This was from an 8096, but is the same board as the 8032, the 64K RAM board having been removed.
This board had previously had a couple of unusual RAM faults, including some unusual ones which led to me writing more and more RAM testing routines until I traced that down.
Now it was showing various errors which pointed to the 6520 or 6522, including sometimes not booting, some random keyboard activity, and jumping to the machine code monitor. Could it be that, or given this machines history, could it be RAM again?
The chips weren't socketed, so I didn't want to go straight for changing them. I did some testing with PET diagnostics again (this time on the LCD version as my screenshots from the previous board were so awful). Some of the time it was reading ok, but I was seeing some occasional errors. One bit in the lower bank of RAM would occasionally fail on power on, but was otherwise fine. The other occasionally failed after running for a while.
Two intermittent RAM chips. Possibly doing the same thing as on the previous board, but not easy to see here as I couldn't remove the other chips to check.
It was clear the RAM was faulty, so I removed the two fault chips and fitted some new (well, new old stock) 4116s chips. It's a judgement call at this point, 7 of 16 RAM chips have now failed, is it time to remove them all and replace the full set? or remove them and fit a ROM/RAM board? For the moment, I replaced the new newly faulty chips. With those replaced, the symptoms all seem to have gone, a long soak test with the 8296 diagnostics program showed no more errors.