Tuesday, 19 May 2015

Commodore 64 USB keyboard kits

I get a lot of requests asking for kits to convert computers into USB keyboards. I normally only sell the converted units, but I've started rolling these outs as kits. The Spectrum and Spectrum+ kits complete with custom keyboard membranes are already available, and this is the version for Commodore keyboards.
I designed the controller board specifically for this task, so there is a connector where the keyboard cable from a Commodore 64, Commodore 64C, Commodore VIC20 or Commodore 16 can plug in directly, as can the original power LED.
It is also available in a version with a mode switch to change mappings between normal use and the vice commodore emulator, This version of the kit also includes a replacement power LED which will light up red for emulator mode and green for normal mode.
The controller can be mounted on the back of the keyboard, and the cable fed out of an existing hole in the case.
Alternatively, it can be mounted at the back of the case, so the USB socket (and optional mode switch) can be accessed with the IEC and Video connector holes.
These kits are available to buy now from my Etsy store, or contact me directly. If you don't want to convert the Commodore yourself, you can send it to me to be converted, or buy one of the already converted units.
Please be respectful of the original computers, and only use unrepairable computers, or at least pass on usable parts to someone that will be able to make use of them.
I'm working on a version which includes two joystick ports, and fits in the existing holes in the sides of the case. That should be available soon.
Also coming up, a version which will work with the original Commodore 64, so it can be used as a USB keyboard when the Commodore 64 is off, and a Commodore 64 when it is switched on.

Saturday, 16 May 2015

Commodore Pet 4032 Repair - only 16K reported

I have repaired and restored several 4032 and 8032 boards in the past, and here we have another Commodore Pet 4032 main board for repair.
This is one of the later Universal Dynamic Pet boards (8032089). It looks to have always been a 4032 as the extra screen RAM and associated buffers and links that would be required for 80 column mode are untouched. It also has 16 matching 4116 DRAMs (Commodore's own MOSTEK brandered MK4217N-3 / 4116N-S), so should be a 32K machine.
The problem is, it is showing 15359 bytes free, so is only detecting 16K RAM. I quick first check would be jumpers Y and Z. Z should be set for 32K and Y for 16K, But the board was correctly set for 32K mode with link Z fitted.
As usual, it's good to check the voltages first of all. I found the 7905 voltage regulator was outputting -6.5v, rather than -5v. Replacing that the rail now measured -5v as it should, but it didn't resolve the memory problem. As the -5v rail is only used by the DRAM chips, and they are sensitive to voltage problems, it may explain if any of the DRAM chips are damaged.
A good diagnostic tool at this point is a ROM/RAM replacement board, I've had a few requests for the 6502 ROM/RAM boards I built previously, and have now run out. I've designed a new version with a few changes, these will be available soon. Installing one of those in the processor socket and enabling it's RAM, The pet boots and detects 32K, so there appears to be a fault in the upper bank of RAM.
A fault in the upper bank still leaves the system usable, using just the lower 16K. If the fault had been in the lower 16K, it wouldn't have booted up. With a non booting system, it is sometimes worth swapping the ends of resistors R10 and R11 (as I did in the DRAM repair on my 4032). This is all that is required to swap the upper and lower banks. In this case, with the banks swapped, the machine did not boot. This pretty much confirms there is a fault in the upper bank. If there is only a fault in the lower bank, this is an easy way to get the machine to boot.
If you have the lower 16K bank working, and the machine is running, you can still access the top 16K of RAM, it just won't be used by BASIC. A quick way to check which of the 8 DRAM chips in the upper bank are at fault, is to poke a number to an address in the upper bank and read it back. So for example, the first address in the upper bank is 16384, so poke 0 there and read it back, it should be 0.
POKE 16384,0
PRINT PEEK(16384)
Then try poking 255 there and read that back, and you should get 255.
POKE 16384,255
PRINT PEEK(16384)
If either or these responses are wrong, you can work out which chip is stuck high or low by converting to binary, so for example if the response is 8 and 255, one bit is stuck high. That is 0x08 in hex, 0000 1000 in binary. So it looks like bit 3 is stuck high. You would get 252 rather than 255 if it were stuck low. From the schematics at zimmers.net archive (pages 5 and 6), you will see that bit each bit is provided by a single chip, the 4116 being 16K x 1 bit. In this case, bit 3 is UA12.
Value
Bit
Lower bank
Upper bank
1
0
UA19
UA18
2
1
UA17
UA16
4
2
UA15
UA14
8
3
UA13
UA12
16
4
UA11
UA10
32
5
UA9
UA8
64
6
UA7
UA6
128
7
UA5
UA4
Once the chip is identified, remove it and replace it and see try again. I've talked a few people through this process, including in the comments on one of my previous RAM repairs, Dave Stevenson wrote up the repair of his 8096. In the case of this 4032 board, it's going to be more complicated as this initially showed no errors. Checking other addresses, I got an error at address 16420 (0x4024 hex).
Further testing with my memtest program showed a pattern, with multiple bits failing at addresses in hex always ending in 2 or A then 4 or C.

  • 0x4024
  • 0x402C
  • 0x40A4
  • 0x40AC
  • 0x4124
  • 0x412C
  • 0x41A4
  • 0x41AC
  • etc.

This repeated all the way up to 0x7FAC. It seemed unlikely that the entire bank of upper RAM was faulty, so I spent a while looking at various addressing issues that could case this, but given the bank swap had shown there was a fault, and that only the DRAM chips are involved after those resistors, it had to be the RAM chips. The error pattern had only bits 3 and 7 changing, so I took a punt on bit 3, since I'd already seen it appeared to be stuck high at some location. That reduced the number of errors, so I replaced bit 7 as well. Replacing those two DRAM chips and the Pet booted up and reported 31743 bytes free, as it should be. It appears the addressing was being messed up by UA4, and there were some faults in UA12.
I managed to find some spare 4116 chips which were a good match for the originals, the same make and model and the date code 6 weeks later. If I was keeping this board, I would have been tempted to remove the sockets and solder the two replacement chips to the board, but I've left the sockets in place in case the board's owner has any problems in future.
With the new RAM in place, the system was up and running and detected 31743 bytes free as normal. Running memtest again, it passed with no problems.
It's a hard life for me, I had to test this again thoroughly with things like space invaders and down.
Also, at the request of the owner, I tested Colossal Caves adventure. We had spoken about this a while ago, he had remembered playing this on a Pet, but couldn't find a version of it. I finally located a D64 disk image of Colossal Cave, this was actually a port to the pet by Jim Butterfield.
To load the D64 disk image, I used my prototype pet microSD drive - this will soon be available, register your interest now if you want one of the first batch.

Monday, 11 May 2015

Pet microSD - Commodore Pet SD card disk drive

There has been a lot going on in the world of Commodore Pet disk drive replacements, following a number of years where there were no options currently available, soon there should be a number of new products on the market. In the absence of anything currently in production, I had looked at the petdisk design and built a board with an improved processor and SD card interface, but which could still run petdisk firmware. I wasn't keen of the use of diode droppers to attach the 3.3V SD card to the 5V microcontroller, so I had used a 3v3 regulator and a level shifter. I made a few of these and they worked, but the petdisk firmware limited what it could do, so I started writing new firmware for it.
In the comments on my posts about the PCB version of this, several people suggested I look into PetSD. Pet SD is no longer in production, but was a SD storage system based on SD2IEC, the SD card IEC disk drives that are very popular on the Commodore 64. This gives it support for various commands and file types not supported on the petdisk, and .d64 disk images etc. The original Pet SD had proper IEEE-488 bus drivers, an ethernet interface, USB-serial interface, real time clock, LCD display etc., I had ruled that out when looking around initially, and started instead with the simpler solution. It seems several people were interested in bringing that back, and had been working on new versions. PetSD+, a respin of this, without the ethernet and USB, and PetSD duo, an even more ambitious version with a larger LCD display and an IEC interface for Commodore 64 computers. So I'm now looking and producing a cut down version of Pet SD, in a similar form factor that the ones I've previously built.
Announcing the Pet microSD. I wanted to keep it the same sort of size as my previous board and also attached directly to the edge connector. The new design does have a lot more going on, and the original board is considerably larger. I've replaced the components with surface mount version, which reduces the size quite a bit, but I have had to go for a double sided load, and moved some of the parts to the back of the board. This has got it down to a similar size, the final version being 50mmx35mm.
The pet microSD does not have the ethernet or USB interface, although serial is there for debugging and possible future use. There is no display or real time clock, but it does have the level shifter SD card interface and proper IEEE-488 bus drivers, so can be used with other IEEE-488 disk drives attached. There is a pin header which can be used for internal mounting in 8296 and early 4000 and 8000 series computer which have a 24 pin IEEE-488 header on the board.
I've also designed a riser board which will allow this to be installed inside an 8032-SK or an 8096-SK. This will plug into the pet motherboard, the Pet microSD will plug into that, and the original IEEE-488 edge connector will plug into the top. There is also a version with the drive connector reversed which will allow a passthrough on the rear or a 4000 or 8000 series. These can also be used to mount the Pet microSD vertically on the rear of a Pet, rather than sticking out horizontally. I'm also trying to source connectors that will allow you mount the pet microSD on the back of any thing with an IEEE-488/GPIB connector, rather than an edge connector.
The prototype is built and tested and is working well, so the boards have been ordered and I'll be building up the first versions later in the month.
Dave Stevenson has product a chart showing the range of Pet SD card products currently planned, and which features they support. It is expected that all the new PetSD based products will be able to tick all the boxes on his CBM DOS compatibility chart. Also on the list is an updated version of the boards I original built with my own firmware, now called TS-SD to avoid any confusion.

Sunday, 26 April 2015

ZX Spectrum USB keyboard conversion kits

I've been asked many times for kit to convert a ZX Spectrum into a USB keyboard, so here it is.
This is a new replacement membrane I have designed. It does not have the traditional pair of 5 way and 8 way 0.1" pitch tails as the original membrane,
The new membrane has a single short 14 way 1mm pitch tail. The keys are now arranged in a 4x10 matrix, rather than the original 8x5.
With the original membrane, the controller board had to be the full width of the case, and so took up a lot of the space inside.
The new controller board is a lot smaller. This leaves more room in the case, should you wish to add a raspberry pi or other system.
The membrane tail fits directly into a flat flex connector on the board, so no more long flapping tails.
The red button is the mode switch to alternate between mapping modes. The start mode has each key mapped according to what is printed on it. Caps shift and Symbol shift are used to get additional functions and punctuation (see full mappings).
Press the button and it switches to a mode where each key is mapped directly to a key on a normal keyboard (for use with emulators or if you wish to map yourself in your OS). Press again and it goes back to the remapped mode. The buzzer on there beeps where you change mode, and in remapped mode, it makes a 'tick' sound when you press the keys to give you positive feedback.
There are two options for the controller board, it can either have a microUSB port that sticks out of the 'EAR' socket, or a 4 pin header for a captive cable (if you prefer that), or for connection to a pi etc.
The kit is available form my Etsy store: ZX Spectrum USB keyboard conversion kit, with either the micro USB version shown above, or the internal connector version.
I will be using these on my ZX Spectrum USB keyboards and ZX Spectrum USB Keyboard with Raspberry Pi, both available from my Etsy store.
I've also listed the ZX Spectrum+ USB keyboard conversion kits, see the blog article on those for more info.
Coming soon: an updated Raspberry Pi 2 build using one of these kits, and another new board for power and USB connections:


Saturday, 18 April 2015

Petdisk clone

A few weeks ago, I wrote about building a prototype version of Bitfixer's Petdisk, an IEEE-488 disk drive for Commodore Pet computers, using an SD card for storage. Credit again to Bitfixer, the creator of the original Petdisk. This was the first stage of a plan to build my own Pet disk drive emulator, recreate what has already been done to prove the principle.
That version was built on an Arduino UNO, using the same pins to connect to the IEEE-488 port as the original version of Petdisk. This allowed me to load the original firmware in to check everything was working.
I did get some way along the road writing a version in the Arduino environment. I started from scratch, but followed the general lines of the Petdisk firmware. I was hoping this might come out to be a some nice short simple Arduino code using the SD libraries etc. However testing showed the I/O operations needs to be fast, so I had to replace all the nicely wrapped Arduino DigialRead and DigitalWrite calls with direct PORT and DDR access. I ended up removing most of the serial debug I had added as well. But it did work. I started with an empty directory and a simple hard coded 48 byte test program.
Whatever filename was requested, it would return the same 48 bytes. With that working, I started using the Arduino  SD library to load files. That is working, but is unfortunately limited to 8.3 filenames. I didn't get around to writing the directory listing bit, but that should be possible. So, the new firmware can be written, but probably best not in the Arduino environment.
The next step was making a PCB version of the SD card version. This would again use the same connections to the IEEE-488 port as Petdisk, so it could use that firmware. As with the Arduino UNO, I used the ATmega328P. Not the actual chip used on the Petdisk (that was the ATmega168), but similar enough to allow the firmware to be used.
Rather than the diode / resistor level conversion used on Petdisk, I went for a 3.3V LDO regulator, and a 4050 hex buffer working as a level shifter. I also went for a microSD card socket rather than full size SD. I added a power LED and using a spare gate of the buffer, an activity LED.
The board slides into the pins of IEEE-488 24 way 0.156" edge connector and it is soldered down on both sides. I missed out the pass-through connector and the USB power connector and went for a simple two pin header for the power. OK, it's sounding less and less like a clone now, not quite an emulator, but the only thing in common between this and the Petdisk now are the edge connector and the microSD card.
The pins at the back are the power in, the 6 pin Atmel programming header and the three jumpers. Two for the address setting, one can be used for serial out.
I built a few for my machines and a few friends who have also tried but been unable to buy a Petdisk. I have a few boards left if anyone else is in the same position.
With the Petdisk v2.0 beta firmware loaded, that is working nicely. I am in the process of writing some new replacement firmware, I've gone back to plain C in Atmel studio, rather than in the Arduino environment.
In my version, I'd like to add some new features, BASIC 4.0 disk commands like 'DIRECTORY' and DLOAD, shift + RUN/STOP support, non- PRG files and file OPEN commands.
One of the things I've been looking at is an old text adventure game. I've found a D64 image, which contains a .PRG file and many .SEQ data files. With those transferred to an 8250 disk, it loads and runs. With the Petdisk firmware it gets so far but cannot load the instructions or start the game as these use OPEN and INPUT# commands. The aim is to get that working.