Thursday, 11 February 2016

IBM Model M Keyboard Restoration

I've been asked a few times recently about the IBM Model M keyboard I use, so here are some photos I took when I restored it. I use this daily as my main keyboard, seen here with my other favourite and slightly out of date input device, the Microsoft Wheel Mouse Optical. I'd be very reluctant to change either of those.
It looks very nice now, almost like new, but that's not how it looked when it arrived. It wasn't a very promising start, but it appeared basically intact. There was one key missing (the number 1 on the top row), and no cable - the cable on the Model M was detachable, and this one had been detached and lost or sold separately. It also needed a serious clean. You could probably work out the previous owners password from looking at the clean keys.
I stripped it down to clean it and looked around for the missing parts. I found a cable, but when I tried the keyboard, it didn't work. It powered on correctly, the caps lock, scroll lock and num lock LEDs flashed on, and then off, and they could be toggled using the appropriate keys, so all looked promising. However, as soon as the PC booted, it stopped responding, the LEDs no longer changed and nothing was sent to the PC. I checked continuity and the cable was fine, so I suspect this was due to the 7406 buffer on either the clock or data line.
I did considered making a USB keyboard controller to fit in place of this board. Before I got around to fixing or replacing it, a second Model M arrived. I had found this one when looking for replacement keys. This one had been described as incomplete, not working and for parts. It was missing several keys, the cable and the screws. I guessed it was the remaining bits after someone had made one good keyboard out of bits of two.
I don't know how bad it was before it was posted, but it was much worse when it got here. It arrived worse for wear, having been badly packed and then thrown about by the courier. Many of the keys were loose in the bottom, and some had fallen out of gaps in the box, thankfully the one keycap I needed was still present. If the seller had actually put the keyboard on one of these bags I might not have lost the keycaps. I don't think anyone would package one like this today, at 5p per bag, there was about £1 worth of bags in there.
When I tested it, not all the keys worked, but most did, so I could conclude the controller board was probably OK. The problem in this case was due to the Achilles heel of the Model M, the plastic rivets that hold the backplate on. These can snap off, and many had, maybe made worse in transit. These are worth repairing, you drill them out and bolt the two halves together. Some of the springs were damaged or missing, so it's going need a bit of work.
However, I now had a working controller and a full set of key caps. Putting those together with the original keyboard and the cable, I had enough bits for a complete keyboard. Time to put it back together.
The model M has quite a unique construction, and is what makes it such a nice keyboard to type on. The keys use a buckling spring, when the key is pressed down so far, the spring buckles and forces down the plunger onto the membrane below, giving clear tactile feedback and making a clicking sound. The sort of haptics they try to recreate today on touchscreens. Yes, it is just a membrane keyboard, but the springs are the secret of it's success.
Most of the keys are an unusual two part construction, a blank key with a little cap that clips over the top. I suppose that made it easier to product regional variations? The larger keys are solid parts, with either have a dummy plunger on one side (the white insert on the bottom left), or a metal bar support (fitting into the green clips on the right).
Having restored many types of keyboard over the years, these bars are often used on space bars and can be very fiddly to fit. These ones just slide in really easily, a very nice design. This one had metal bars on the Enter key, and the numeric keypad + and Enter. The second keyboard was the same, but the keycap for numeric keypad enter it came with didn't have a bar, that seems to have come from a third keyboard which had the white insert on Enter, like on the 0 key. This supports the previous assumption it was the bits left over from a merger.
The white key in the centre of the numeric keypad may look wrong, and I initially thought it was, and was going to replace it was a grey one from the other keyboard. But I think it is meant to be like that. The F and J keys are also white. These are the three keys that have a slightly raised bar at the bottom of the keycap to aid locating your fingers when touch typing. These are also useful when putting back the keycaps as you can locate the key in relation to F or J rather than having to count from the edges.
With all the keys replaced, the keyboard slides into the base board. Nice solid plastic, just needed a good clean. The controller fits into a slot in the base, the with the LED board and earth strap connected to it. Earth strap! how many keyboards these days have an earth strap, or indeed a large lump of metal that would need earthing. They really don't make them like this any more.
The cover, again, just needed a good clean. It bolts together with unusual hex head bolts, a bit like the original IBM PC.
Finally clip in the keyboard cable, coiled of course. These came in various versions, an RJ45 for some industrial terminals, I think there was a 5 pin DIN for older computers, but this would have come with an IBM PS/2 computer. That range of computers introduced the new 6 pin mini DIN PS/2 keyboard and mouse connectors. These are still used today, there is still a PS/2 port on my main PC, even though it was built more than a quarter of a century after the keyboard.
The same is true of the keyboard layout. This keyboard introduced what is still pretty much the standard layout today. The only thing missing is the Windows key, which was slotted in between Ctrl and Alt later on. Other than that, the mapping is exactly as it should be. I have the right Alt key (marked Alt Gr here) mapped as the Windows key, as I use shortcuts like Windows + E to open explorer, Windows + L to lock the screen etc. I've also got the Pause/Break key mapped as the pause button on my mp3 player (good old Winamp).
The only anomaly I have found is the key on the top left is labelled `¬| and the key between Z and Shift is marked .  On a modern keyboard they would be `¬¦ and \| . It seems the pipe and broken bar ( | and ¦ ) have changed place at some point. The keys act as you would expect on a modern keyboard, shift \ gives | which is fine by me. The pipe character | is used in many programming languages and on the linux command line.
I'm not sure I've ever used the broken bar ¦ other than in writing this paragraph. I suppose you could use it to make an ASCII art picture of the strain relief on a DIN plug |¦|¦|¦|¦| ? In case you were wondering, hold down right Alt (Alt Gr) or Ctrl and Alt together and press the top left key. You know, the one above tab with the wrong apostrophe ( ` ) and the weird line with a bit at the end ( ¬ ) that I think is meant to be 'not', although tilde (~) is more often used. OK, you can now forget about that key again.
There is a date code on the back, 21-09-1988. I have friends who weren't born when this keyboard was built and now have kids of their own. All in all, a great keyboard. It wipes the floor with modern soft membrane keyboards, and stands up well to modern mechanical gaming keyboards. I do have just about enough bits to make up the second one, once I fix the controller and replace the plastic rivets. I'm sure I'll get around to that one day as these are such nice keyboards to use, I wouldn't change it.

Monday, 8 February 2016

VIC20 Penultimate Cartridge Part 3 - No more DIP switches

The last version of the VIC20 Penultimate Cartridge I'm currently working on expanded the ROM and RAM capabilities, but at the cost of increasing complexity. There were now 9 DIP switches (soon to be 10), 4 to select the ROM and RAM mode, and the rest to select a ROM image set. This came with a long table of the ROM and RAM setting required for each ROM set. For example, you would need to set mode 1 and ROM image 0 for Avenger, and mode 9 and ROM image 8 for the diagnostics cart etc. This worked fine, but would be a bit annoying to use, keep having to refer back to the settings list, which was too large to print on the cartridge case.
To make this easier I wanted to automate the switching, using a menu program on the VIC20 to the set the mode and ROM image, and then reset itself to start the selected ROM. I started looking at the options for this and designed a new version of the board. It started to get complicated quickly with multiple latches to hold the mode, and the ROM address, and also something to generate a delayed reset pulse. There was also the issue of getting it into a start mode.
To simplify things, I went for a microcontroller, this would do all the latching, and generate the reset pulse. It could have a set starting state, and also would allow the mode and address to be preset, but not changed until the reset pulse, so as not to mess up the menu code which was currently running. This was fitted dead bug style on one of the previous boards, to test this out properly. The LEDs show the ROM/RAM mode being set. The cable at the top is connected to a programming header, from a bit of another board glued onto this one.
The VIC20 has some helpfully address decoded signals on the cartridge connection, for IO chips. I found when testing this that just triggering on the IO2 signal was a problem. It seems the normal operation of the OS reads from addresses in the IO2 range at about 60Hz, so I used some spare gates in the GAL chip to generate an IO2 and write signal to trigger the latches.
I've added an LED bargraph for testing, I don't think the final version needs that, as much as I like flashing LEDs, it's not really necessary. With the additional write gated logic, and the microcontroller code written, the LEDs were all being set correctly. The idea of operation would be as follows, when the VIC20 is powered on, a default mode is selected which runs a menu program from ROM. The menu will have a choice of options, all of which will lead to setting the mode and ROM address and resetting the VIC20. When the VIC20 resets, the selected game or whatever will run. There is a button on the cartridge which when pressed will bring the menu back up. It does this by resetting the VIC20 and setting the mode back to the initial state - the mode changes happen whilst reset is held down so it is never in an inconsistent state.
I've setup 4 commands:

  • POKE 38928,X - change to mode X imediately
  • POKE 38929,X - change to ROM address X imediately
  • POKE 38930,X - change to mode X, apply pending ROM change and reset
  • POKE 38931,X - preset ROM address for above

This should cover most of the options required. The menu should be able to offer things like

  • Run a game cartridge from ROM (8K/16K/Atari 16K/Scott Adams 16K)
  • Run the VIC20 diagnostics software (which needs ROM and RAM)
  • Run Super Expander or other BASIC with up to 27K RAM
  • Exit to BASIC with 3K-35K RAM

But also I think I should be able to get it to run some commands on reset,

  • Exit to BASIC with 3K-35K of RAM and execute LOAD "*",8
  • Exit to BASIC with 11K-35K of RAM and execute LOAD "FB20-8K",8 
  • Select a Scott Adams adventure and execute SYS 32592

Being able to autostart a diskimage or the file browser on an SD2IEC (or a 1541 if you like), would be a nice feature to have, and avoiding typing SYS 32592 makes the Scott Adams adventures easier to use.
The new board is now designed and ordered, and will still fit in an original cartridge case. Whilst I'm waiting for those to arrive, I need to write the menu program.
There has been a lot of interest so far, I think this has the potential to be a very useful product. I'm thinking in future I could remove the large (and expensive) EPROM and use a larger micrcontroller to load the ROM images into RAM from a small serial EEPROM. The whole thing could then go surface mount and once the board is smaller, maybe even a custom cartridge case....

If you like DIP switches, I still have some of the current version of the PCB available, built and tested with up to 35K RAM and 32 ROM images:

VIC20 Penultimate Cartridge V2.2

Saturday, 6 February 2016

Amstrad CPC6128 USB keyboard

Following on from the Amstrad CPC464 USB keyboard I recently added to the range, I have been asked to do a CPC6128.
The CPC6128 looks quite different, with a different arrangement of keys, but the keyboard connection is the same.
I thought it would be worth a try seeing how similar it was, so I built up the keyboard controller and loaded in the same firmware I used for the CPC464. Yes, that's another revision of the USB keyboard controller, now on V3.5.
Most of the keys matched correctly, the main differences were the key markings. There were a few keys with additional shift functions, \ + shift gives  ` [ + shift is {, and ] + shift is }. On the CPC464, there is a large blue Enter key on the right, and a smaller one on the bottom right of the numeric keypad, also marked Enter. The CPC6128 has a large Return key and an Enter key half an inch away. Not sure why they changed the naming between two quite similar machines.
The main difference though is the numeric keypad is numbered 0-9 on the CPC464, but f0-f9 on the CPC6128. These are in the same position in the key matrix, so I have setup the CPC6128 as a separate mapping.
The copy key is now left of the space bar, so I have set that to be the Windows / GUI key as that is where it would be (on the CPC464 this was mapped as Control+C). I also mapped the lower Enter key as Alt. This gives the full compliment of Shift, Control, Alt and Gui, all in reasonable places. Esc, Tab and Caps Lock are also normally situated, making this quite a familiar keyboard layout to use.
Other than those, the rest of the key mappings were the same. The LED is fitted with a plug on the CPC6128, so just plugs onto a header on the keyboard controller so it lights up where powered on.

The CPC464 and CPC6128 USB keyboard kits are available to buy below. Note the CPC464 version is only for keyboard with membranes, as shown - see the original article for more info.

USB keyboard kit

Thursday, 4 February 2016

VIC20 IEEE-488 Cartridge

I have been working on various VIC20 cartridges recently. One that I was interested in building was an IEEE-488 cartridge. I had previously tried out the PET microSD with a VIC20 IEEE-488 cartridge, and found it worked well.
I was using the Stack Computer Products IEEE-488 Cartridge, a fairly simple design, more straightforward than the official Commodore one, but not as minimal as the MSD one. I haven't been able to find any more info on that, other than a single photo, so I'm sticking with the stack for the moment.
The Stack cartridge has an usual driver arrangement for the IEEE-488 bus, with standard TTL chips rather than dedicated IEEE-488 drivers like the MC3446 or 75160/161.
I reverse engineered this design to see what was going on. There is a 2716 2K ROM and a 6522 VIA. The 6522 is connected to the IO2 address range (9600-9BFF). Port A was wired to the eight data lines on the IEEE-488 bus, via a 74LS642, an inverting octal bus transceiver with open collector outputs (n.b. note that says, 'inverting', may be important later).
Port B of the 6522 was taken up with the control lines, driven via 7438 2 input NAND gates with open collector outputs and read via 74LS125 bus buffers. A 74LS00 was used to limit the ROM address range to A000-AFFF (the bottom of block 5). There was also a diode OR gate feeding CB0 from the DAV & IFC signals.
I've been considering trying to fit a PET microSD, a version of this IEEE-488 cartridge and also a set of ROM and RAM into a single cartridge.  I've been doing that bit by bit, trying different options and the ROM and RAM versions are working well, with the new menu driven no DIP switch version coming on well.
Rather than duplicate the design, I decided to reduce it down and use standard 75160/161 IEEE-488 bus drivers as things like the 74LS642 are difficult to get hold of (and more than double the price of the 75161).
I also added 32K of RAM under the ROM chip to make this more useful, since without it you can only load programs into the internal RAM.
Testing the new cartridge. The RAM was fine. The ROM was fine. Talking to the 6522 was working fine. Talking to the IEEE-488 bus wasn't.
Testing with my IEEE-488 diagnostics board confirmed the problem, comparing the outputs on the LEDs when sending the same commands to the 6522 on the Stack and my new board showed the outputs were inverted. Sending 00 turned all the LEDs on the databus off on the my board. Sending FF turned them all on.
On the Stack board, 00 was all on, FF was all off. I'm allowed one mistake, right? a 'Partial Success' as a colleague of mine used to say. This is something that could be fixed in hardware, add some inverters (or even revert to the original design). It could also be fixed in software by inverting (or removing inversion if already there). I was trying to avoid modifying the original code, although it's only 2K, so I had considered relocating it to live in the 3K gap in block 0 that is generally unused when 8K or more RAM is added. Back to the drawing board.

Saturday, 23 January 2016

VIC20 - The Penultimate Cartridge - Part 2 Multi ROM and RAM

Here is the next step in the evolution of my VIC20 Penultimate Cartridge.
This version expands on the previous version by adding 4 pins to each of the chips. The RAM is upgraded from a 62256 (32Kx8) to a 621024 (128Kx8), and the ROM from 27C512 (64Kx8) to 27C040 (512Kx8). To control this, the GAL has been upgraded from a 16V8 to a 22V10.
I've upgraded the PCB to have gold plated edge connectors, for better contact and I've added some large holes to the board (can you add a hole? OK, I've removed some hole shaped sections). This makes the routing the tracks more a challenge, but fits around the pillars in some cartridge cases. This allows the board to fit into an original cartridge case with no modification.
Here it's installed in a nicely yellowed spare Pirates Cove. The lack of the apostrophe is annoying, I guess they couldn't decided if it should that be Pirate's Cove (the Cove of a Pirate) or Pirates' Cove (the Cove of the Pirates). The game itself says 'Pirate Adventure', I guess that was too many letters to fit on. (Update: the box says Pirate Cove). Note the 'Don't forget' label on the top of the original label, you'll need that later.
The DIP switches to control the mode and the reset switch poke out the top of the cartridge. You can change mode and press reset without removing the cartridge or powering off the VIC20.
There's 9 DIP switches there, quite a lot of modes. This is due to the very odd way the VIC20 addresses the cartridge slot. It's quite clever in many ways, as little or no address decoding is required for most cartridges. Decoded select lines are available for the various blocks of memory and I/O:

  • RAM1 0400-07FF (1K)
  • RAM2 0800-0BFF (1K)
  • RAM3 0C00-0FFF (1K)
  • BLK1 2000-3FFF (8K)
  • BLK2 4000-5FFF (8K)
  • BLK3 6000-7FFF (8K)
  • BLK5 A000-BFFF (8K)
  • IO2  9600-9BFF
  • IO3  9C00-9FFF

That was designed so you could use up to 3 pairs of 2114 chips controlled by RAM1,2 and 3 to give a 3K expansion. This fits into a gap in the internal memory in what would be block 0 (0000-1FFF). If you add RAM here, the VIC20 shows 6655 bytes available. If you add any more RAM, this 3K isn't counted any more. If you add RAM to blocks 1, 2 and 3, you can add up 24K of RAM, and the VIC will show it's maximum of 28159 bytes available. You can add RAM in block 5, but the VIC won't count this, but it can be used to load in cartridge ROM images from disk. Here is a memory test program I think I got from an ebay listing (?) which tests which blocks are present.
The first version of this board had a 32K RAM chip, with this I could add 3K + 8K +8K + 8K, or 8K + 8K + 8K + 8K, but I couldn't have all the blocks filled, 3K + 8K +8K + 8K + 8K. I didn't think anything would need this, but it turns out the VIC20 port of Doom does, so I have upgraded the RAM chip to be able to do this. The extra 3K means I had to switch to a 128K chip, even through almost 3/4 of it won't be used. I could have achieved this with a 32K chip and an 8K chip (or even 6 2114's), but aesthetically, it balances the larger 32 pin ROM chip, and it turns out the 128K chips is not only cheaper than the 32K chip + the 8K chip, it is actually cheaper than either of them individually. Now you can play Doom if you like.
The RAM is complicated then, but the ROM side must be easier? Well, sort of. If there is a ROM in block 5, the VIC will run it. On the first revision of the board, I had a choice of 16 8K ROM images that would appear in block 5 and run. This was great, but limited the choice of cartridges. Many games needed more than 8K of ROM, so installed a ROM chip in one of the other blocks. With many of the Commodore cartridges, such as Defender and Robotron, this was 8K on block 5 and 8K in block 3. Now you can play Ms. Pac Man if you like.
The great thing about standard is there are so many to choose from. Atari decided they would do things differently, and when they released Centipede and Dig Dug etc. they had ROMs in block 5 and block 1. I support that as well, so you can play Donkey Kong if you like.
That's three different ROM configurations, 5, 3+5, 1+5. Any more? Well, yes, for the five Scott Adams text adventure cartridges, they went for ROMs in blocks 1 and 2. Why? - who knows. (Update: apparently this was due to lack of space, no autostart saved 128 bytes - see an interview with Scott Adams). With no ROM in block 5, these do not automatically start, hence the 'Remember to type SYS 32592' label on the cartridge. I've supported those as well. Adventureland anyone?
I'm not sure if I've shot myself in the foot adding all these modes. it does make for a lot of DIP switches. The first 4 control the ROM and RAM mapping modes,

    0   0   0   0   -    -    -    -    -      0K
    0   0   0   1   -   RAM   -    -    -      8K
    0   0   1   0   -   RAM  RAM  RAM   -      24K
    0   0   1   1   -   RAM  RAM  RAM  RAM     32K

    0   1   0   0  RAM   -    -    -    -      3K 
    0   1   0   1  RAM  RAM   -    -    -      11K
    0   1   1   0  RAM  RAM  RAM  RAM   -      27K
    0   1   1   1  RAM  RAM  RAM  RAM  RAM     35K

    1   0   0   0   -    -    -    -   ROM     0K
    1   0   0   1   -    -    -   ROM  ROM     0K
    1   0   1   0   -   ROM   -    -   ROM     0K
    1   0   1   1   -   ROM  ROM   -    -      0K

    1   1   0   0  RAM  RAM  RAM  RAM  ROM     27K
    1   1   0   1  RAM  RAM  RAM  ROM  ROM     19K
    1   1   1   0  RAM  ROM  RAM  RAM  ROM     19K
    1   1   1   1  RAM  ROM  ROM  RAM  RAM     19K

Those are split into 4, the first is 8K blocks, the second is 8K blocks plus the initial 3K. Thirst comes just ROMs and finally ROMs with RAM in the gaps. Yes, another configuration, the Super Expander and Diagnostics cartridges have ROM in block 5 and 3K RAM.
The last 5 DIP switches select which ROM images to load, the high bits of the ROM. The ROM socket can take 28 or 32 pin ROMs, anything from a single ROM image in a 27C64 through to 32 ROM images in a 27C040. When testing this, I was using an EEPROM, a 29C040, unfortunately as will all these 'standards', the pinout is slightly different to the 27C040, so I've had to make a small modification to my test board. I will fit a jumper in future revisions. I've also bolted this to a base without a lid, useful for testing as it still holds in place.
This is how I've loaded my test ROM image, I've split the cartridges up by type, although there is no need to do this. The settings show the mode selection and then the ROM address.

1234 56789
0100 xxxxx - 3K RAM only
0001 xxxxx - 8K RAM only
0010 xxxxx - 24K RAM only
0011 xxxxx - 32K RAM only
0111 xxxxx - 35K RAM only

1000 00000 - Avenger
1000 10000 - Choplifter
1000 01000 - Frogger
1000 11000 - Gorf
1000 00100 - Jelly Monsters
1000 10100 - Omega Rat Race
1000 01100 - Radar Rat Race

1100 11100 - Diagnostics (with 3K RAM)

1001 00010 - Defender
1001 10010 - Ms Pac Man
1001 01010 - Pole Position
1001 11010 - Robotron
1001 00110 - Submarine Commander
     10110 - 
     01110 - 
     11110 - 

1010 00001 - Centipede
1010 10001 - Dig Dug
1010 01001 - Donkey Kong
     11001 - 
     00101 - 
     10101 - 
     01101 - 
     11101 - 

1011 00011 - Adventure Land
1011 10011 - Pirate's Pirates' Pirates Cove Pirate Adventure
1011 01011 - Mission Impossible
1011 11011 - Voodoo Castle
1011 00111 - The Count
     10111 - 
     01111 - 
     11111 - 

This leads me to think it would be easier to come up with some sort of menu driven system which writes out to an I/O latch to set these options then reset the system. I suspect that will be the next stage of evolution.
I have some of this revision available if anyone would like one of these multi RAM / multi ROM cartridge boards. This will come with programmed GAL, RAM and ROM chips fitted, just add an old cartridge case:
VIC20 Penultimate Cartridge V2.2

In parallel with this, I am also working on the IEEE-488 interface side of what may become 'the penultimate cartridge'. So far I have reverse engineered the Stack IEEE-488 board and built a simplified replacement. 
Currently I have a strange totem pole arrangement out of the back of the VIC20.
More on that once I get it working.

Update: Spot the deliberate mistake in the VIC20 IEEE-488 cartridge

Update2: New version of the Penultimate Cart with no DIP switches in development.