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.


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.

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.

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

Sunday, 16 July 2017

RC2014 Modular Z80 System

I'm sure you've all heard of the RC2014, it's a modular Z80 computer system available from seller 'Semachthemonkey' on Tindie. A great little system that makes it easy to build and expand a Z80 based system. (or even a 6502 system as the base is very adaptable).
I've just bought some new boards to add to my RC2014 system, so I thought it would be a good time to revisit the current system and go through all the boards on there before I add the new ones.


The system is based on a backplane with a common bus, 40 pins wide, carrying most of the Z80 lines. It uses 40 way 0.1" sockets for the modules to plug into. This is the 'back plane - 8' model where slots 1 and 2 and slots 7 and 8 can have their address and databusses isolated from the main slots, 3-6. This will allow some protection on the bus via resistors or to use split address and databusses for some cards to create ZX81 or ZX Spectrum type systems where the busses are isolated to simplify the screen generation process.
Into the backplane plug a selection of modules. Most are less than the full 40 pin width, and all align with the top of the backplane, pin 1, with the exception of the clock / reset module which hovers around the middle. Full details of the backplane and other modules can be found on the website.

Z80 CPU Module

The heart of the system is the Z80 CPU board. This has little else on there, other than a pullup resistor on the INT line. This is an older board, with inputs not passed to the backplane such as NMI, WAIT and BUSRQ tied high, the later versions have an option to tap these off or tie them high. Full details here. Like all of the other modules here, there is no decoupling on the boards, only on the backplane. I'd like to see the traditional 100nF on each chip, I think that has happened on the later modules.

Clock Module

The clock generator comes on a small separate board. This generates a buffered 7.3728MHz clock. I would have thought it logical to place this on the Z80 board, but I guess there are reasons to separate them. There is also a position for a reset switch, but I deviated from the normal build here and added instead an RC circuit to give a power on reset. There is a reset button on the backplane anyway. Here I found a 74LS04 wasn't up to the job, but a 74HCT04 was fine. Full details here.

8K ROM Module

The Z80 needs some code to run, so it gets that from the 8K ROM module. This has a 27C512 EPROM split into 8 banks of 8K, selected by jumpers. Full details here. As supplied, it came with a version of BASIC adapted from the NASCOM computer by Grant Searle - more details on his site. This is fixed 8K ROM decoded to the address range 0x0000 - 1FFF. There is a later module which allows bank paging, which is one of the new ones I have ready to install.

32K RAM Module

BASIC needs some RAM to run in, so here is 32K of RAM, mapped as 0x8000-FFFF. Again, this is a fixed mapping and a newer board has up to 64K and paging capabilities. Full details of the 32K RAM board here. If I remember correctly, this is another one of the boards where I started with a 74LS32 and changed to a 74HCT32 as I found some RAM chips (the Alliance AS6C62256 shown) didn't work with the LS chip, but other 62256 chips were fine.

Serial IO Module

This final module for the BASIC system provides serial IO. This is based on the 6850 (although the 6350 can be used, as can 6xA50 and 6xB50 variants). These are the only part in this system that are out of production, so are old parts, the 68B50 I got didn't work, but I had a 6850 and that worked correctly. The system 7.3728MHz clock is divided down to get the serial baud rate. Divide by 64 gives 115200 baud. There is space to install a MAX232 and a 9 way D connector for an RS232 compatible port, but the easiest option is to use the FTDI header to connect to a PC via a USB serial adapter. The jumper above also allows the RC2014 to be powered via this connector. The 6850 is accessed at address 0x80 and 0x81 (but is also mirrored from 0x80 through to 0xBF) . Full details here.

The RC2014 in use

With all of those plugged in, you can see that two face in the opposite direction to the others. This means the central modules are close, so I have some plastic feet stuck on the back of the RAM card to stop it touching the CPU card. Since all my FTDI cables were bricked by FTDI last year, I am using an Arduino module which does the same job, and that is set to power the whole unit (current consumption is under 200mA, and the USB port can in theory supply up to 500mA).
Connecting up via a serial terminal and switching on, we're into BASIC and away. Without adding any storage, the easy way to get programs onto the system is to paste into the terminal Window. I have had mixed results and usually need to get the terminal program to add a 10mS line delay or a 1mS character delay to avoid corruption when transferring large programs, as there is no flow control in place.
You can then transfer some BASIC programs over to test. It is a pretty generic Microsoft BASIC with most of the usual commands supported. The great thing with a system like this is that if you find there is something missing, go and grab the source for the BASIC interpretor and add your own commands.

RC2014 Mini

Something else I should probably mention at this point is the RC2014 Mini. This is basically all of the above on a single board. It can be used standalone, of there is space to fit a 40 pin connector on the side to add a single module, or a backplane full of modules. This one is also driven via FTDI serial cable, or you can use the RC2014 Universal Micro Keyboard.
That is what that keyboard is meant to be used for, even though I keep using them on my Minstrel ZX80 clones.
So that's the existing modules I have covered, next time I'll be replacing several of those with new ones.

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