Thursday, 25 February 2016

Commodore 64 Pseudo Stereo Dual SID Questions

This is an old post, preserved for reference.
The products and services mentioned within are no longer available.

Just a quick update on the Commodore 64 Psuedo Stereo Dual SID boards, see the previous article for more info and the buy it now links. This is to answer a selection of questions along the lines of 'will it work with...'.

Will it work in a Commodore 128?

Yes, it will. The Commodore 128 has a 6581 or 8580, driven in a similar way to a Commodore 64. When ordering, go for the normal height (i.e. raised up by one socket height) version.
The C128 does have a metal shield which will no longer fit if the board is installed, so you would need to cut out a section, or remove it. If you remove it, may be an idea to fit heatsinks on some of the chips which use to sink to the metal cover. The C128D and DCR should both be fine, as long as there is space enough for the board to fit.
Power isn't as easy to tap as the C64, the best place I found was on pin 1 of the 7812 regulator. Be careful when clipping on there to avoid touching the centre pin. Maybe add a drop of hot melt glue or bluetak to hold it in place and away from the other pins.

Will it work with a Commodore 64 Reloaded?

Sort of. The power input to the Reloaded boards is 12V. This is filtered and fed to the SID, or can be fed via a 3V zener diode to give 9V for an 8581 SID. The normal dual SID boards have onboard voltage regulators to generate 9V and / or 12V for an unregulated DC of 15V or more, which is present inside the original Commodore machines.
This will need a special build of the dual SID board without the regulators. There is a jumper on the Reloaded board which shorts out the 3V zener to select 9V or 12V. I think I can remove the jumper and connect a 2 wire lead there to tap off the 12V and 9V. This is currently untested, but it should work.

Will it work with a Nano SwinSID?

Yes. The Nano SwinSID can be used, but with a few caveats. Firstly, the board is a bit higher than a standard SID, so will cause height issues in a C64C. I could solder the Nano SwinSID directly to the board and reduce the height if required.
The sound level output seems to be lower than a normal SID, so bear that in mind; you may need to adjust the levels on whatever you connect to.

Can it be used as dual individual SIDs?

Yes. The default setting is both SIDs are fed the same inputs and generate pseudo stereo effect. But, remove the CS#2 jumper and connect to one of the decoded IO lines on the cartridge port and if your software supports it, you can drive the two SID independently.

If you have any further questions, let me know, or see the previous article for more info and the buy it now links.

Thursday, 11 February 2016

IBM Model M Keyboard Restoration

This is an old post, preserved for reference.
The products and services mentioned within are no longer available.

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.

Update:
The donor is now also back up and running, I ordered the missing keys and cable from a website in the US (clickykeyboards.com)

Monday, 8 February 2016

VIC20 Penultimate Cartridge Part 3 - No more DIP switches

This is an old post, preserved for reference.
The products and services mentioned within are no longer available.

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....

Update:
The new boards are here, the software is taking a bit longer to write.
My VIC-20 coding is a bit rusty. I have a very basic BASIC version, but I am looking to write a better version in C.

Update 2:
I have some simple single ROM cartridge PCBs, if you only want to replace a single game.

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:

Update 3:
The menu software has been rewritten in C.
Initial testing is underway, so far, so good.

Update 4Penultimate Cartridge V4.3 available now, all menu driven, no DIP switches.

2022 Update: The production version of the Penultimate Cartridge is now available from  The Future Was 8 bit

Thursday, 4 February 2016

VIC20 IEEE-488 Cartridge

This is an old post, preserved for reference.
The products and services mentioned within are no longer available.

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.

2022 Update: I gave up with the IEEE-488 cartridge in the end, the requirement for a ROM means it is always going to take up space that might be needed for the programs you want to load, so best just stick with an SD2IEC for the moment.