Saturday, 25 July 2015

Commodore 64 Shared USB keyboard

I've been making Commodore 64 USB keyboards for quite a while now, they have been very popular. The Commodore's of this era came with very nice mechanical keyboards, which are still very nice to use, although they often need a thorough refurbishment to get the best out of them.
You can still use the keyboard almost as a Commodore 64 by running a Commodore 64 emulator on a PC or Raspberry Pi. With the mode switch, the keyboard can be used as if it were a Commodore 64.
I've had requests for various combinations (can you add a Raspberry Pi, can you add a PC etc.). I've also been thinking about another idea for a while, could the Commodore 64 bit be kept intact, but still used as a USB keyboard? Then I got a request asking for just that, so I had to do it.
This is the new Commodore 64 Shared USB keyboard. OK, I'm still looking for a better name. The right hand side of the board is the same as my standard Commodore 64 USB keyboard controller, with the keyboard connector in the middle.
The left hand side is new, you can see if more clearly on the picture above, before I changed the keyboard headers for right angle ones to fit in the case. At the edge is 20 pin header that plugs onto the original keyboard header. In between are some bidirectional buffers. The circuitry on the right there generates a 5V supply if either the USB or the C64 is plugged in. This is used to drive the switching circuits, and can also power the case LED, although I prefer to leave that so it is only on when the C64 is on. When there is no power from the C64 side, the switches are disabled, isolating the C64 from the keyboard, and the USB keyboard microcontroller takes control and scans the keyboard and talks to the PC.
When power is detected from the C64, the USB microcontroller is held in reset mode, so it does nothing. All it's pins become inputs, and so are not driving the keyboard. At the same time, the switchhes are enabled, connecting the C64 to the keyboard and allowing it to take control of scanning the keyboard and work as normal without interference from the USB keyboard microcontroller.
The idea is to take a working Commodore 64, and open it up. Unplug the keyboard connector and plug in this new board. Then plug the keyboard into the new board. Finally, take a USB lead and feed it through a gap in the case, the datasette port seems to best option. Plug the other end of the USB lead into a PC. The PC will recognise a new USB device as usual and the Commodore 64 will function as a USB keyboard, just like any of my other USB keyboards.
Where this differs is that if you power up the Commodore 64, you will hear the 'disconnect' sound from the PC as the USB keyboard appears to be disconnected. The Commodore 64 will have started up and the keyboard can now be used with the Commodore 64 as normal. No keys will be sent to the PC, as the PC thinks the USB keyboard has been disconnected. When the C64 is turned off, the PC will make the sound as if the keyboard had just been plugged in and the keyboard will start to function as a USB keyboard again.
So this is the best of both worlds, have you cake and eat it solution. If you want to use the C64 for real, just switch in on and away you go. When you're not using it, you can use it as a USB keyboard on your PC. You could also load up a Commodore 64 emulator such as Vice on the PC if you wanted.
I'll be selling these as just the board, ready to install in your own C64, or I can repair or refurbish your C64 and fit one of these and return it. Or, the final option, I have a limited number of refurbished Commodore 64's already fitted with these boards, which work as Commodore 64's and as USB keyboards. It will also work on the VIC20, if you prefer, as the keyboard is identical. It could also be used with a C64C, but would need an extension cable as there is insufficient height where the keyboard connector is placed.

Saturday, 18 July 2015

Commodore Pet 3032 Mainboard Repair

These Commodore Pet repairs are coming in thick and fast. This time it's a 3032 board. These were sometimes sold with 3032 on the front and 2001-32N on the back. This sits in the timeline between the original 2001 and the later 4032.
The earlier pets had discrete video circuits and difficult to find 6540 and 6550 memory chips. For the 3032, they switched to using 4116 DRAM and 2532 compatiple 24 pin ROMS. Later boards kept this memory arrangement, but switched to using the 6545 CRTC to drive the screen. The later boards also moved the datasette connector to the side. The 3032 still has this inside, where it used to connect to the internal drive on the 2001, but is a bit redundant on the 3032. Other than that, the Pet doesn't change much over the years. Things like the I/O ports and the IEEE-488 interface are pretty much unchanged from 1977 to 1984.
This one has apparently been to a number of 'vintage computer repair experts', who have concluded it is a ROM or RAM problem. However, their efforts have left it a little worse for wear. I try not to be critical of other people's work, but this time I have to make an exception. Before I start on the actual faults, I need to undo some of the previous 'repairs'. First comes the oddest repair I've ever seen on a Pet. Or any computer for that matter. There is a thick black wire soldered to a pin on the back of the board.
Following this around the board, it goes to the same pin on the ROM in the socket above. One of the ROM chips appears to have a damaged leg, and this has been 'repaired' with the wire.
I don't even know where to start with the reasons why this is not a good idea. It's too long, too thick, will affect timing, will pick up interference, the fact it can be easily fixed in many other ways, the fact that pin is in parallel with all the other ROM sockets in the same row and also present in many other places closer by. Let's just say it's wrong. Also the ROMs are in the wrong sockets anyway, so it wasn't going to work. As it arrived, they were as follows:
  • UD9 - 901465-22
  • UD8 - 901447-29
  • UD7 - 901465-23
  • UD6 - 901465-20 (with the wire)
  • UD5 - empty
  • UD4 - 901465-21
  • UD3 - empty
I don't think that is ever going to work. The editor ROM (UD8) is original, and dated the same as the rest of the board (early 1980), but the rest are a set of BASIC 4 ROMs are dated late 1981. I had thought this must have been upgraded from BASIC 2, but the editor wouldn't have worked with BASIC 2, so I'm not sure why but all the other chips date to late 79, early 80, apart from the 4 ROMS. I've heard mention of BASIC 3, but never seen a set of ROMs - was this originally BASIC 3?
The correct order of the BASIC 4 ROMs should be:
  • UD9 - 901465-22
  • UD8 - 901447-29
  • UD7 - 901465-21
  • UD6 - 901465-20 (without the wire)
  • UD5 - 901465-23
  • UD4 - empty
  • UD3 - empty
I've returned them to the correct sockets. Next, some of the capacitors have been replaced. Most are fine, but two large axial capacitors have been replaced with radial ones at some point. The legs aren't long enough, so they have been joined above the board, and I'm not to happy with that. Apart from the aesthetics, there is a chance that the leads could short out to other tracks on the board.
I've replaced those with axial ones, as they would have originally been, with the largest one held down with a cable tie through the holes provided.
Finally, it looks like someone started to repair the problems, two of the DRAM chips are missing
The appear to have been removed with a claw hammer.
I've cleaned the pads up, repaired the damaged tracks and fitted two sockets.
I've used lots of flux and what would normally be a bit too much solder on these sockets as the some of the through hole plating has been damaged so I've lets the solder go through to reconnect the two sides. Continuity tests to the pins and the other DRAMs are fine.
OK, so that's all the previous repairs undone, time to fix the actual original problems. As usual, I've started with a ROM/RAM board in place.
That is a good start, but can you spot the deliberate mistake? I'm using the monitor on the 4032, as I often do, for testing. The later Pets use different sync polarity to the older ones. In cases where I have an older Pet board and a later Pet monitor (or the reverse), I made a little board to selectively invert the video and sync signals.
This uses a quad XOR gate, so there is the same latency on the inverted and non inverted signals. The dip switches select which signals to invert. Normally this is video and vertical sync. With that in place, the monitor is now displaying correctly.
So, back to the good start, it's basically running, albeit with the help of the ROM/RAM board. The lines on the screen are caused by bad video RAM. I removed the two chips - notice it is possible to do that cleanly and without damaging the board.
I started with two new 2114 chips, later testing found one of the originals was working OK, so I put that one back. With the video fixed, I tried the ROMs and found it wouldn't work using the onboard ROMs. Selectively replacing them one by one using the DIP switches on the ROM/RAM board, I found that one of the ROMs was not working.
With an EPROM, it's back to booting up again. With two 4116's in the two new DRAM sockets, the onboard RAM now passed, and I was able to remove the ROM/RAM board.
I didn't get any response from either datasette port or the IEEE-488 bus, I also noticed the screen was sometimes starting in lower case. It is normal for 80 column Pets with the business keyboard to start in lower case, and on the 80 column Pets, the shift changes from upper to lower case. This was happening here.
That is what it should look like, all the 40 column Pets with graphic keyboard should start in upper case, and shift should change between upper case characters and graphic symbols. You should be able to change between these modes using
  • PRINT CHR$(14) 
or
  • PRINT CHR$(142)
Neither of these was having any effect. This should change the output of pin 39 of the 6522, which drives one of the address lines on the character ROM and selects the alternate character sets. This line wasn't changing. This and the lack of datasette and IEEE-488 IO pointed to the 6522. I replaced that and it appeared to work for a while, The datasette and IEEE-488 was also working. Problem solved.
But no, it didn't, it continued to be intermittent and went back to lower case and no IO.
I retested the replacement 6522 in another Pet, and it seemed fine. I also tried the original 6522, and that too seemed fine. I then suspected the socket. The white sockets used in these early Pets are known for bad contacts, but in this case, all the pins were buzzing through correctly, even with a bit of wiggling. I eventually traced this back to one of the enable lines, it never seemed to change. I checked the connection and it seemed fine, so I went back to the source IC F1, a 74LS08 quad AND gate. The inputs to that were changing, but the output never went low.
I removed that and tested it, and the one gate used to drive the 6522 enable pin was indeed faulty. Replacing that with a good 74LS08 and the original 6522 and everything was back in business.
The boot screen was back in lower case, and the print statements could change mode. The datasette ports were now both working. Testing with the new blue pet microSD drive found everything working on the IEEE-488 bus side.
The connector in the middle is a piezo speaker connected to CB2. Can't play Space Invaders without the sound, and the onboard piezo didn't appear until the 4032.
Soak testing showed up a problem with another of the ROM chips, so that was replaced with an EPROM as well,
I left it running various tests, games and demos for most of the day. The temperatures were fine and no errors were reported.
All done and ready to go back. Another pet back in the land of the living. The final tally of faults was:
  • RAM - 2 chips had been removed, damaged tracks repaired, sockets and replacement DRAM chips fitted..
  • Video RAM - there were some faults in one of the video RAM chips. Both have been socketed, and one replaced.
  • ROM - Two chips were in the wrong sockets, damage to a pin and the long wire mod on another chip. Two ROMs found faulty and replaced with EPROMs.
  • I/O - Faults traced back to faulty AND gate. Replaced and now both datasettes, user port and IEEE-488 working.
  • Capacitors - two radial capacitors removed and replaced by axial versions.
How much of that is the actual original fault, and how much is due to later repair attempts, I don't know. The two missing DRAM chips may have been faulty, or just they may have been fine and just happened to be the first in line.
There are a few more Pet and Pet related repairs to come, and if you have anything that needs repairing, you can contact me.

Wednesday, 15 July 2015

New pet microSD boards

The latest batch of pet microSD boards are ready, and they have changed a bit, they've gone blue!
There are also a few other minor mods, most notably the package of the 74LVC125A buffer has been changed to give more room around the other components. The power LED is also now blue to match, green for activity, red for error.
To go with this, there is now a board which taps the power from the datasette connector, and now includes a pass through to allow the datasette to be used at the same time.
I said there was a lot going on in the world of IEEE-488 drive replacements, here is a selection of them. The first two boards on the back row are ATmega328P based boards. At the left is the first prototype, and in the centre, a new version with a better microSD interface, the same as the pet microSD.
Both of these are meant as low cost drives. They do have a full microSD card interface, with voltage regulator and levels shifters, but they lack IEEE-488 bus drivers, so shouldn't really be used with other IEEE-488 devices. The smaller processor somewhat limits functionality, so there is no disk image support. These can run petdisk firmware or my own custom firmware, which is still in development.
The rest are ATmega1284P based boards. These all run Nils Eilers NODISKEMU firmware. The right most on the back row is the prototype pet microSD - I tend to use green connectors on the prototypes, so I can tell them apart. On the front row at the left with the large LCD display is the petSD+, available from Dave Stevenson. Here it is without the display:
Although it may not look it, hardware wise, it's very similar to the pet microSD, the same chips just with smaller packages. Where it differs is the full size IEEE-488 / GPIB connector, the same used on Commodore's disk drivers. There is also a battery backed real time clock on board, so files are written with the correct date and time, and this can be used by software running on the pet. It is designed to be used with the display and buttons, although this is yet to be implemented.
The final board in the family group is the new pet microSD.
Here shown plugged into a 4032, with the passthrough connector used to connect a datasette.
And here testing a 3032 board, it's quite useful for this as it lays flat on the bench.
The pet microSD is available for £50 + postage, and includes the datasette power board and a microSD card with a selection of software. There are various other options including one that can mount internally in a 8032-SK or 8096-SK.

Sunday, 12 July 2015

Commodore Pet text adventures

OK, so you've got your Commodore Pet running, and you've got an IEEE-488 disk drive, or a modern replacement like a pet microSD. But, what are you going to run on it? 
One of the things that suit the Pet's text based display is text adventure games, and there are many available, mainly ported from other systems. I had a pet 8032 board in for repair last year from Bill Bright. He was looking forward to playing a particular adventure game he remembered playing on a Pet, many years ago, and he's recently been able to play it again. The following is from Bill:
As a young computer user in the early 1980s, I found a game called Adventure.  It was originally a game written by Willie Crowthers and Don Woods for a DEC mainframe.  The game I played, and loved, was a port of the original that was “abridged” for the PET by Jim Butterfield.
So my latest adventure started when I bought a PET 8032 on eBay.  Dave was kind enough to fix the motherboard for me and he also supplied me with a petdiskTS.  I thought my next step would be a simple Google search to find the Butterfield version of Adventure.  I was sadly mistaken.
Dave helped look for the files and the best we came up with were several incomplete versions or some that appeared to be complete but were on disks mixed with various other files.  It took some time, and a read through the code, but I finally managed to piece together what I believe to be the most complete version of Butterfield’s port. 
That version was written for a 40 column PET.  I had resigned myself to the fact that all of the software I wanted to play was designed for 40 column, so I tracked down a 4032 motherboard and replaced my 8032 board.  Then came the pet microSD and a visit to petSD.net.  There I found the Zork page and discovered there was a host of Infocom programs available for the 80 column PET.  This inspired me to attempt to compile an 80 column version of Adventure.
First I found that some unknown person had started the process, apparently in 1981.  I found several of the SEQ files already partially edited and some older versions of the PRG written for 80 column.  I decided to use what I could of the SEQ files but edit the 40 column version of the PRG that I was already using.  This version is indentified in the code as Version 4.  It is the same as earlier versions but has two additional sections of code that allow a player to save and load a game.  Handy, I thought.

So, armed with the PET, Vice, and Windows Notepad, I started editing Version 4 of the PRG and reformatting all of the text SEQ files.  (NOTE - There are probably still errors in the text, but playing the game is the best way to sort those out.)  At the end of this process, I had separate 40 column and 80 column versions of Adventure.  It was suggested that I put both on one disk and create a loader to auto-detect screen width to load the proper version.  Though in the same disk, each version can easily be separated.
The last hurdle that I faced was the subroutines for save and load that I had decided were worth including in the code were not working consistently.  They both used  the Basic 4 commands DOPEN and DCLOSE.  For some reason those commands worked on the native PET but not in a D64 file.  I rewrote those pieces to use the standard OPEN and CLOSE commands and all worked well. Unfortunately, having two sets of files left little room for saved games on a D64, so I moved the files to a D80 format.
Thanks to Bill for the 'guest blog'. I've added ccadventure.d80 to the sample files I provide with the pet microSD. Nils has also added it to petSD.net, there are a good selection of text adventures on there, mainly based on Edilbert Kirk's Z-Machine-Interpreter for Infocom Z-files. I've submitted my favourite Infocom text adventure, Douglas Adams' Hitchhikers Guide to the Galaxy game to that list. How many hours did I spend on that on my IBM PC back in the 80s? Nice to be able to use the Pet 8032 instead.
These sort of adventure games are a good test as there is a lot of disk activity involved. Loading it is fairly simple (see the pet microSD user guide for more info), thanks to Nils Eilers DOS Wedge on there, just press SHIFT and RUN/STOP to load the DOS wedge, then type

  • @CD:ccadventure.d80
  • or
  • @CD:hhgtg.d64

Then SHIFT and RUN/STOP again to start the loader.
This will select the appropriate version and load that. As you can see, the 80 column version has been much tidied up to make better use of the 80x25 screen.
You can now begin the adventure......
And just keep telling yourself, it's only a game....isn't it?

Thursday, 2 July 2015

pet microSD user guide

Here are some general instructions for using the pet microSD. To start with you need a pet microSD, a Commodore Pet IEEE-488 drive replacement which uses a microSD card.
This plugs into the back of a Commdore Pet 2001 / 30xx / 40xx / 80xx, power is supplied by clips or a datasette power connector, or see fitting instructions for 80xx-SK models.
With that, you need a standard microSD card. Nothing particularly special, I now supply the pet microSD with a 2GB microSD card with some software on. The microSD card should be formatted FAT or FAT32. If the card has been used elsewhere first, and the best option is to use the proper SD card format utility. Then copy on any .prg or .d64 files you want to use.
There are various ways to access the disk drive, some of which depend on the version of BASIC installed in your Pet. If you have an original 2001 series pets with BASIC 1, I'm afraid that doesn't support IEEE-488 disk drives.
You could upgrade it to the BASIC 2 'NEW ROMS' using one of my 6502 ROM/RAM boards (which could also be used to give you an upgrade to 32K RAM as well).
All other Pets can use the standard disk commands, similar to those used on the Commodore 64. These are variations on the LOAD and SAVE commands used for tape, but with ,8 on the end to specify the drive - the default address of the pet microSD is 8, as with most Commodore disk drives.
  • LOAD "test",8
  • LOAD "$",8
  • LOAD "*",8
  • LOAD "inv*",8
  • SAVE "hello",8
"*" refers to the first file on the disk, this can be useful for loaders or menus. Wildcards can also be used, so use "inv*" would save typing "invaders" if that was the first match for the pattern. The standard Commodore BASIC 2 file listing command is via LOAD "$",8
Note these screenshots are from the VICE Pet emulator, and the files are shown with extensions hidden. This option is not enabled by default on the pet microSD, so that will show "MAZE.PRG" rather than "MAZE".  See later for instructions on changing this.
40xx and 80xx series Pets have BASIC 4, which alongside the existing BASIC 2 commands, also introduced some new commands:
  • DIRECTORY
  • DLOAD "filename"
  • DSAVE "filename"
You do not add ,8 on the end of these commands, you can also miss off the closing quotes if you're feeling lazy. With BASIC 4, you can also load and run the first program on the disk by pressing SHIFT and RUN/STOP. On earlier BASICs, this loads from the cassette. DIRECTORY now also displays the listing without needing to do a load and list, and does not affect the current program.
Further commands are given to the pet microSD via the standard Commodore command mechanism, although this can be a bit longwinded. The format is
  • OPEN 1,8,15,"command" : CLOSE 1
The fill list of commands can be found in the NODISKEMU readme. The main use here being to change directory or load a disk image using the CD command.
To change directories on the microSD card use
  • OPEN 1,8,15,"CD/games" : CLOSE 1
To open a d64 disk image, use
  • OPEN 1,8,15,"CD:image.d64" : CLOSE 1
To close the disk image, or go back to the parent directory, use
  • OPEN 1,8,15,"CD" : CLOSE 1
That can be a bit tedious to type, so I use Nils Eilers DOS Wedge to make things easier. I normally place this as the first program on the microSD card, so it can be loaded quickly, with LOAD"*",8 and RUN on BASIC 2.
And on BASIC 4 machines, you just need to press SHIFT and RUN/STOP to load and run it.
Once that is loaded, you can do things like
  • @  - get status
  • @$ - get directory listing
  • @command - run a command
  • @cd/directory - change directory
  • @cd:image.d64 - load a D64 image
  • @cd← - return to parent directory / close disk image
  • /filename - load a program
  • ↑filename - load and run a program
  • # - show the current device number (default is 8)
  • #9 - change the device number (8-11)
This means there is a lot less to type, @$ shows a directory, as with the BASIC 4 DIRECTORY, this does not affect the currently loaded program.
You can load with just /filename. Wildcards can be used, so /inv* could load invaders etc.
You can also skip the extra step and load and run in a single command with ↑filename
Where you save most typing is with commands, so the image loading is now just @cd:adv.d64
Once the disk image is loaded, you can then run the appropriate program, SHIFT+RUN/STOP or ↑* will load the first file on the disk, or use ↑filename to load a file. In this example, ADV.D64 is a disk image containing Colossal Cave adventure, a (possibly incomplete) port for the pet. To start this, use ↑svntr
This is soon to be replaced by a version in development by Bill Bright which is a fuller version and has support for 40 and 80 columns Pets.
As mentioned earlier, the .prg extensions can be hidden using an option. Without the dos wedge, the command you need is
  • OPEN 1,8,15,"XE+" : CLOSE 1
With the dos wedge, this is just
  • @XE+
There are many other things you can do, this is just an introduction to the most used features. However, you could just put whatever game you want (e.g. Down from Revival Studios) as the first program on the microSD card and then SHIFT+RUN/STOP and you're straight into the game.
The new blue pet microSD with improved datasette power connectors will be available soon, but I still have a few of the original green board versions.