Saturday, 29 July 2017

ZX Spectrum tape master creator

The Future Was 8 Bit has recently begun releasing software on cassette. The first was Pentagorat for the VIC20, which with then followed by Pilot Attack for the ZX Spectrum, both by Misfit.
These are producing using a cassette duplicate, such as this one and a larger bank of Sony units.
This takes one master tape and duplicates it onto multiple copies. This of course requires a master tape, a clean copy of the game files on tape. The are a few options for producing those.
The master tapes for the first Spectrum release were written using an MP3 player board, as used in the DivMMC programmer. There is some extra circuitry added to that to get the level right. The level is always a tricky thing with the Spectrum, unless you are using a Spectrum +2 where the level are preset with the built in tape deck.
A new master tape is required, so I have been tasked with producing a new 'master tape creator' box. I've been looking at using the +2 tape drive to write master tapes, given a TLL level signal from the ULA, it sets the level correctly and writes to the tape. It is also mono which is ideal for this application.
I've also been looking into the TZXduino recently, an Arduino based project which can be used to load files into a Spectrum. However my plan was to use it to write to tapes instead. It didn't take long to build a test version, I built this up whilst discussing the idea on the phone. It's an Arduino UNO, with 5 buttons wired up, and an Adadfruit microSD board which has level shifters and a voltage regulator to run the card correctly at 3.3V.
There are two bundles of wires coming out of that . One is connected to an I2C LCD display, the second plugs into the cassette connector on the +2.
That seems to work, I tried writing a few .tzx and .tap files out to tape and loading them back and had no problems.
That looks promising, but is a bit impractical, time to build a permanent version. I started with a +2 from the 'broken' pile.
This one is particularly discoloured, where as beige plastics go yellow, grey plastic appears to go green. It's also missing various bits inside, so is an ideal candidate to start with. Now I needed an Arduino board (or just an ATmega328P or similar microcontroller), and an SD card with level shifters on.
Searching through the junk pile, I found some boards for an early version of the PET microSD. This had the requisite microcontroller and microSD card with voltage regulator and level shifters. Most of the rest of the IO pins were taken out to the edge connector, which would have plugged into the Commodore PET.
With a load of wires attached, and a few minor pin changes, that is ready to mount in the case. I said there were some bits missing inside.
I found a board that I built for testing something else years ago that has six buttons on, so I used that and wired the sixth switch as reset.
I also found a power and USB input board with a 5V regulator on from my USB keyboard parts bin. That will allow this to be powered from USB or from a 9V DC supply, gives a bit of flexibility.
With the keyboard removed, the case lid goes back on and the buttons and display are accessible through the hole where the keyboard was. The microSD can also be accessed from here.
I added some labels below the buttons, root folder, move up, move down, play/pause, stop, and reset. Time for some more testing.
You can certainly see how 'greened' that case was compared to the +2 at the back I was using for testing the tapes. I had some initial problems with this version, which was down to a duff tape deck, so I replaced that with another spare unit and that worked fine.
We have been putting multiple copies of the games saved on each side of the tape, so I added a feature to the TZXduino V1.5 code to allow selection of the number of copies by pressing the stop button when not playing.
It then plays the same file multiple times with a few seconds gap in between. I also fixed a buffer overflow that was causing random characters to appear on the top line when scrolling.
I've written a few tapes and various files of different types and they are all loading first time without any problem. Job done. Game over.

Update:

This turned out to be quite a useful thing to have, so after I shipped that one off to the TFW8B Mansion, I decided to build another one for myself. I'll probably do a PCB for this in slow time, but for the moment, I went for a quick solution, I chose an Arduino Ethernet board I had lying around. That was bought for a project a while ago that went in a different direction.
The Arduino Ethernet has a built in SPI Ethernet chip (which I am not using here), but more importantly, an onboard microSD socket and level shifters. The only issue with this was the CS pin for the SD card was hard wired to pin 4, so I needed to change the code (which used the default pin 10).
The other issue was the I2C LCD module. I bought two at the same time, but when I assembled this second, apparently identical, module, it didn't work. It turned out this one used a different I2C address (0x3F instead of 0x27). Another code change and it was working.
This time I used a spare +2A case, one that had all the plastic pillars cracked off in transit. Thank you ebay seller who thought a black binbag was sufficient packaging.
Currently testing V1.1 of Pilot Attack using the tape I have just written.


Update # 2

We found that we had some issues with the tapes duplicated from the mater tape on the tape duplicator machines. These are designed for audio tapes, so have some additional processing in there to low pass filter the audio and automatically level things down, which degrades the quality of the data on there. I have sketched out some ideas to modify those units to work better with data, but for the moment, the master tape generator has turned into the production tape generator.
In order to speed things up, The Future Was 8 bit has added a second drive to the unit, wired in parallel to the first, so that two tapes can be created at a time. This fitted back into the original case, with the second drive on the left hand side.
This is now in service generating the Spectrum (and Amstrad) versions of Rodman.
These are available to pre-order now from The Future Was 8 bit.

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

Thursday, 27 July 2017

Commodore PET 2001 Repair - Garbage screen with noise

Here we have a Commodore PET 2001 board in for repair.
A common fault with the Commodore PET series of computers is a screen full or garbage, a random assortment of characters. This is normally perfectly static and stable, and is usually caused by a ROM or RAM fault. The PETs video circuitry runs independent of the CPU and displays on the screen whatever is in the first 1000 bytes of video RAM from 0x8000 to 0x83E7. At power on, this is random, and on most early PETs, you get a brief flash of that at power on. Once the CPU starts running code, the video RAM is filled with the space character and the screen is cleared. If the CPU cannot run due to a ROM or RAM fault, the screen remains full of garbage.
This board has an unusual fault, it is showing a screen full of random characters but with snow or noise. This noise happens on the 2001 when the screen RAM is being updated at the same time as it is being read. Later PETs got around this by adding latches into the circuit.
In this case it appeared the CPU was running, and the snow, the moving pattern of white dots over the screen indicated something was up with the logic that writes to the display RAM. If the video RAM is socketed, a quick test you can do is to run it without video RAM. If all is well with the circuitry for reading the video RAM, you will get a chequer board effect, as the data lines float high and all characters are read as 0xFF (displayed as ▞ - a black and white photograph of a slice of Battenberg cake).
I temporarily installed a ROM/RAM board set to the PET test ROM. This alternates between displaying a screen showing the full character set, and a screen full of G or B characters (based on testing the first 1K of RAM, G for good, B for bad for each byte). This changes every couple of seconds, so it a good test here as I can probe for a signal which pulses every couple of seconds.
Tracing through the switching logic the signal was there up until one of the 74LS157 multiplexors. Here the output was stuck high, so was stuck in read mode. Write mode is controlled separately, and was being enabled correctly, so it was trying to read and write and the same time.
I noticed one of the three multiplexors had already been replaced. These do have a habit of failing, so since two out of three had now failed, I took the precaution of replacing the third as well.
With the 157s replaced, power back on and we have a boot screen.
1102 bytes free isn't ideal. Looks like it's got 2K of RAM, so there is a fault in the third pair of RAM chips. These are the original MOS 6550 RAM. Not particularly reliable, neither is the 6540 ROM. These chips have lots of enable lines, which means by a clever arrangement of which address lines go to the enable pins, you can setup a bank of 16 chips in parallel without any other logic, although all it would have needed was a 74LS138.
The problem is these enables often fail, and the RAM gets enabled over more of the address space than it is meant to. The same RAM is used as the video RAM, and here they are enabled all the time, so you can get away with using RAM with faulty enable lines as video RAM. Here I was lucky and was able to swap those over and get the full 8K working.
I ran the RAM test several time, and left it running for a while and repeated it, and it's passing all the tests. It's not a permanent solution, but I will leave it to the owner,  by the looks of the writing on the top of all the chips, he has already been swapping chips around.
My advice of 6540 and 6550 chips remains the same. If you plan to use the machine a lot, and you have a working set of chips, remove them and put them away safely for Sunday best. For general use, get a ROM/RAM board - now available from my Tindie Store.
Not only does it save wear on those chips, it reduces power consumption (from 3A down to 1A), and you get to select the RAM size up to the full 32K and the BASIC version, 1, 2 or 4.

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

Thursday, 20 July 2017

Commodore Amiga 600 and 1200 USB keyboard kit

I have had few requests for USB keyboard kits for Amiga 600s and 1200s, so here they are.
The A600 and A1200 are very different from the Amiga 500. The A500 had a keyboard controller board on the back of the keyboard, and a serial interface to the mainboard. The Amiga 500 USB keyboard controller I built for that was a lot simpler in hardware terms, but a bit more effort to implement the serial protocol in the microcontroller.
The A600 and A1200 have no keyboard controller, and just a simple membrane connection to the mainboard. These have more connections and a smaller pitch than any of my previous USB keyboard controllers, so I have made a custom board.
The A600 cable is 30 way and the A1200 is 31 way, with a slightly different pinout. I found matching 30 way sockets for the A600, but I have not been able to get 31 way sockets, so I have used 32 way sockets for the A1200, just make sure the cable is aligned to the left of the connector.
The board mounts on the back of the keyboard using some self adhesive pillars. The cable on the LED board is not long enough to reach, so I supply a short extension cable.
The power LED is lit whenever the keyboard is plugged in. I have set the floppy and disk activity LEDs to act as scroll lock and num lock. You could drive these from software if you wanted to use them for another purpose.
They keyboard has a built in caps lock LED which shows the current state.
As usual the kit does not include an Amiga or keyboard, you need to provide those yourself, and please try to use a broken one.
The kit does include the USB keyboard controller, the LED cable, mounting pillars and a USB lead, and is available to buy from my Tindie Store.

I also have various single and dual 9 way D to USB joystick adapters that would fit nicely in the A600 or A1200 cases. These allow you to use original 9 way D joysticks (like Zip Stik or Competition Pro etc.) as USB joystick devices, contact me for more info.
Or if you are short of space inside an A600 with a Raspberry Pi and associated items, you can go for a single or dual port USB joystick adapter which sits externally to the case.

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