Tuesday, 11 April 2017

Minstrel ZX80 Clone and the ZXpand

This is the ZXpand. A great addon for a ZX81 which allows you to easily load files from an SD card.
It also has 32K of RAM, the option to add a joystick and (on some boards) an AY3 sound module (as used in the 128K Spectrums). A few people have asked if this will work with the Minstrel ZX80 clone. Well, it should do.
Originally the ZXpand required some modifications to work with the Sinclair ZX80. You needed to modify the ROM enable line to work like the ZX81 does, and wire it to the pin on the edge connector (which is not connected on a ZX80). I had already done that as part of the Minstrel design.
The second change was to use the ZX81 style 8K BASIC ROM. Again that was already available on the Minstrel. So, I plugged it in and tried it out.
Nothing. black screen. I went back to a real ZX81 and the ZXpand was still working fine. The Minstrel was also still working fine. I tested that again with some RAM expansions.
Those were working fine, although pointless as the board already has 16K RAM which the RAM pack disables and replaces with it's own RAM, but that is working, and you can remove the RAM chip from the Minstrel.
Looking through various pages on the internet from 2011 when the ZXpand was released showed some alternative firmware was written. There is also mention in the user manual about a ZX80 jumper. I don't know if my board is an earlier or later version, but there is no jumper as far as I can see.
Meanwhile, I was making some minor modifications to the Minstrel PCB, getting ready to send off the design for the V2.4 boards. I thought it would be useful to just double check the edge connector pinout.
Well, what can I say. Looks like I made a mistake with the edge connector. Starting from the left, it should be D7, RAMCS, D0, D1, D2, D6, D5 etc. Don't know why Sinclair didn't put these in a sensible order, maybe to make routing the original ZX80 PCB easier. Checking my edge connector, I had wired D7, RAMCS, D1, D0, D2, D6, D5. Ooops, D0 and D1 are reversed.
A quick mod to the board, triple check with as various schematics and a ZX81 board and it now seems to be in the right order. Will the ZXpand work now?
Success, The first thing I tried was CAT (which replaces COPY on the Z key). That just gave a white screen. Pressing a key brought up the first page, pressing break brought up the last. I think it may be using SLOW mode here and not returning. Like a ZX80, the Minstrel does not (currently) support NMI slow mode, so remains in FAST mode until you press break. A minor issue that may have been resolved with the ZX80 mode jumper or alternate firmware?
Let's trying loading something, ZX80 Invaders I think.
Great, that works. Now something a bit more taxing.
No problems there either, and it is very fast at loading. So far everything that can run on the 8K BASIC ROM on the ZX80 seems to be working. I don't think this is an option for the 4K ROM version, but there isn't much software available for that anyway.
So the answer is yes, the Minstrel ZX80 clone works with the ZXpand, but owners of V2.3 and earlier Minstrel boards will need to make a minor modification. I think due to the address decoding, the RAM in the ZXpand has to be mapped as a block from 16K-48K, which is the default.
The modification to swap D0 and D1 on the edge connector it is probably easiest done on the back of the board, cutting the tracks at convenient points and wiring the vias to pins on the RAM socket.
Minstrel V2.5 boards will be available soon, these have the datalines in the correct order, there is now also support for the original ZX81 24 pin ROM on the board rather than a modern 28 pin EPROM. More on that when the boards arrive.
You may be asking 'Ah!, but what about the RAM pack, Dave. How did the RAM pack work, Dave?'. Well, the external RAM just reads back whatever gets written to it, do having D0 and D1 transposed made no difference. Would have been the same with the lower address lines, swap any of those around and it would still have worked.

Minstrels boards, kits and fully assembled units can be bought from my Tindie Store.

Saturday, 1 April 2017

DivMMC Programmer

Since it's Arduino day, here's a recent project where the Arduino came in very useful.
I posted that picture on twitter and had many suggestions as to what it could be, including:

  • Arcade button controller of some sort?
  • Electric shock russian roulette version of the popular Simon memory game
  • Some sort of video mux 
  • CBM serial port network?
  • For testing cables?
  • Quiz buzzer system?
  • Bespoke Track and Field controller?
  • Three-player controller for Flappy Bird!
  • RGB pattern generator?
  • MIDI? Is it a MIDI thing?

And several people who had presumably been watching the IT Crowd, suggested that it was 'The Internet'. Well, no, as much as I would like to announce that this is 'The Internet - Mark 2", where you can safely type google into google without destroying the universe, it is not.
With the labels on, it may make more sense. This is a programmer and tester.
And that is what it programs and tests, the new DivMMC Future from The Future Was 8 Bit. With lots of orders for this coming it, programming each one individually takes a long time, so this will automate this process and program 4 units in parallel. Not directly, but via a number of remote controlled ZX Spectrums.
The Spectrums are connected via the 4 cables on the bottom. The cable on the side controls an ATX power supply to power the Spectrums and monitors.
That worked out very nicely, the 5V standby supply powers the programmer, and power to the main 5V and 12V can be controlled by the Arduino to turn them on or off. The Spectrums are powered by 5V and 12V from the accessory power connectors (normally used for disk drives etc.). These adapter plug into the 3 pin connector where the 7805 regulator would have connected and feed both 5V and 12V into the board.
The programmer needed to automate the process of powering on the units, loading the programming software, programming the units and then power cycling them and testing them out. The power control was already sorted. Next was loading the programming software. This is a one off project, so I went for an Arduino as a base for the project to get something up and running quickly without a custom PCB or too much handwired prototyping.
I did think about loading the .tap or .tzx file from SD card and getting the Arduino to generate the appropriate tones, but I went for a simpler option and used a Sparkfun MP3 player shield to play an MP3 into the tape port of the Spectrum.
The Spectrums we were using for this were Grey 128K +2 units, which have a built in cassette drive, which includes some signal processing, and feeds the Spectrum with a TTL level signal. I built a simple transistor buffer to generate a TTL level signal from the MP3 player output.
The signal goes through some RC filtering inside the Spectrum, so to avoid any interaction between multiple inputs in parallel, I buffered this signal via a gate in a 74LC04 inverter and then inverted it again via one inverter gate per output.
The system is controller via three large, friendly, illuminated arcade buttons on the top, all wired up to headers on the middle board. These light up to indicate which mode it is in. The software is a state machine which progresses through the steps required for 'Program' and 'Test. The blue and green buttons light up to show the current mode, and turn off when complete. The red buttons always shows if the power status, and pressing it turns the power on or off in any mode.
At the bottom of the board stack is the Arduino. I tried various different boards here. The one on the left is an Atmel ATmega328PB Xplained Mini. This has 'Ardunio compatible' headers on the board, and some extra pads where I planned to attach the cables for the buttons and the connectors.
I was hoping it would be possible to flash this with an Arduino compatible boot loader, but didn't get that working. Instead I use Arduino to build the code, and then programmed the board with the hex file via Atmel Studo. Unfortunately, I couldn't get that to work with the Sparkfun MP3 shield, I think due to an issue with the SPI bus.
I looked around an dug out an old 'Arduino compatible' Lenoardo clone. That also had extra pads for headers. That also didn't work - the SPI pins are in different locations on the Leonardo. Finally, I went back to the Arduino UNO I had been using for development, since that was working.
So we have power and audio, the next was controlling the Spectrum. To do that, I had 4 spare outputs from the Arduino, wired in parallel and fed to each Spectrum. Each one of these would attach to a gate of a 4066 quad analogue switch which would be wired into the keyboard matrix to mimic pressing a key. This is designed to be reversible, so the 4066 is only tacked onto the chip below to steal 0V and 5V. The rest is just pushed into the membrane connectors.
I wired up 4 control lines in case the requirements changed. There needed to be the enter key to start the tape loader (easier on the +2 than J symbol shift+P symbol shift+P on a 48K), space to start the programmer, then arrow keys to navigate the DivMMC menu to load a test program.
During the testing, I found I could narrow this down to enter and 6. 6 was both the down arrow for navigation, and 'any key' to start the programmer.
I'll add some photos of the programmer in use and the 4 Spectrums, once they have been assembled in their new home.

If you want to support this blog, you can donate via Patreon or Paypal, or buy something from my store.

Thursday, 30 March 2017

Commodore 8096 Mainboard Repair

The Commodore PET 8096 and 8096-SK were unusual machines. They were basically standard 8032 or 8032-SK machines with an add on 64K RAM board.
The confusing thing is this extra RAM rarely gets used. It can only be accessed by programs which were designed to use the paging mechanism, and so far I have not found any software which actually uses it. I think Edilbert Kirk's Z-Machine-Interpreter can use it, so you can speed up Infocom text adventures such as Zork and HHGTG. It is not recognised by BASIC, so you still get the traditional 31473 bytes free message on power up. Many people would be expecting to see 96K
With the 64K RAM board removed, you have a standard 8032 board. The one in question here has a memory fault, and was previously only showing 16K. It has now stopped showing anything. and is now just showing a blank screen and no boot up chirp.
A quick test with my prototype PET LCD diagnostics board (more on that in a later blog post), shows the problem is bit 0 in both banks has completely failed. Since it is the same bit on both banks, it could point to an external problem with a ROM of data bus buffer pulling the D0 line up or down.
I checked that by enabling the RAM replacement and the system ran fine with the RAM replaced and the oboard ROMs, so the problem does appear to be both D0 RAM chips. It is possible one failed a while ago and has damaged the other, causing that to fail also as they are effectively in parallel.
This particular era of PET boards can be frustrating to work on. The pins on the back are cut very short, so it's not as easy as it normally is to desolder the chips, even with a decent vacuum desoldering station. The RAM in particular has all the tracks going between chips on the top of the board, so it is very easy to lift a pad a break the circuit when removing these.
After the first one, which took a few goes to get it clear I switched to cutting the legs of the chips and removing them separately. I don't often do this, as it is good to be able to test the chip that has been removed to ensure it's bad, but it comes down to which is more important, preserving the chip or avoiding damaging the board.
With those replaced, time to retest and all RAM passed.
Great, 31743 bytes free. Back into the box and return to the customer. Job done.
Well, no. When I tried to load programs, I was getting unusual errors. I asked it to load 80xxtest, and it says it is searching for 84xxteqt? maze leads to a search for maxe? I managed to load some programs by renaming them to a single letter, and ran some more tests.
Most of the test programs I ran passed, so I was starting to think it might be something up with the IEEE-488 hardware, but I when I tried with a ROM/RAM board installed replacing the lower RAM, it had loaded fine and not shown any of those file name mangling problems. This is why it is sometimes good to stop and walk away from a job for a while and think things through. I could have ripped out and replaced all the IEEE-488 chips in an attempt to get this working, when in fact it was fine.
I have an old BASIC RAM test program I use as a bit of a burn in test as it takes a while to run, and repeats the RAM test in a few different ways. This passed all of the lower bank tests, and the initial tests on the upper bank data bus, but failed about 75% of the RAM on address bus tests.
What is going on here is simple tests just write the same value into each address of the RAM and then read back and check if each ones matches. This is fine in many cases, but doesn't test if you write 42 to address 12, does it appear at address 12? it could have been written to address 13, and vice versa, but the simple data test would pass either way. The address bus tests white different values into each address, 0 into address 0, 1 into address 1, and so on cycling 0-255.
32752 7FF0 0111 1111 1111 0000
32753 7FF1 0111 1111 1111 0001
32756 7FF4 0111 1111 1111 0100
32757 7FF5 0111 1111 1111 0101
32760 7FF8 0111 1111 1111 1000
32761 7FF9 0111 1111 1111 1001
32764 7FFC 0111 1111 1111 1100
32765 7FFD 0111 1111 1111 1101
Looking at those last few errors, out of 16 addresses from 7FF0 to 7FFF, 8 failed, all the ones with bit 1 low. All the addresses with bit 1 high passed. This pointed towards D1 being at fault. Here again, step back and think it through. I could rip out the address buffers and multiplexors which work on D1, but this is only affecting the upper RAM bank, the lower one was fine. Only the RAM chips themselves are split between banks, all the rest is ruled out as the lower bank is working fine. Removing the D0 chip from the upper bank turned this into a 16K machine, and that worked fine, so the problem is pointly sqarely to the D1 chip in the upper RAM bank.
With the D1 RAM chip in the upper bank replaced, the error count was reduced to 50% of the upper bank, and now only in the high bits of the address bus (i.e. write 0 to addresses 0-255, 1 to addresses 256-511, and so on).
31740 7BFC 0111 1011 1111 1100
31741 7BFD 0111 1011 1111 1101
31742 7BFE 0111 1011 1111 1110
31743 7BFF 0111 1011 1111 1111
Picking a few more addresses out that had failed, they all had 0 at bit 10, or bit 2 of the upper address. These errors pointed to D2, all the addresses which failed had D2 as 0, all the ones with D2 as 1 passed. Rather than work all those out, I thought I had a computer here, so why not use it. I modified the program to print up the difference between the value it read and the value it expected to read.
Yes, that's fairly clear, the value of 4 indicates bit D2 is faulty (wrote 254, read 250 etc.). If I had tried this previously, it would have shown a mixture of 2 and 4 (and maybe 6). Here it would have been interesting to check that, but again I had resorted to cutting chip legs to reduce the chance of damaging the board.
One more RAM chip replaced and those tests now all passed.
Files were now loading properly and no other issues were found after a long soak test and multiple runs of various test programs.
Quite an unusual fault that one, but all sorted and back with it's owner. I'll be adding address bus testing to the next version of my PET diagnostics boards. Meanwhile, more testing.

If you want to support this blog, you can donate via Patreon or Paypal, or buy something from my store.