Thursday, 3 September 2015

Upcoming Commodore 64 projects

Here's a quick preview of a couple of upcoming Commodore 64 projects.

Commodore 64 pseudo stereo dual SID
This was inspired by a video from GadgetUK, where he modified a dual SID board to run two SIDs in parallel. Normally the dual SID board is used to add a second SID and a different address, to generate actual stereo from suitable software. The idea with this mod was to place two at the same address, so they could be driven from normal software. You may think that there is no point in doing that, they will both sound the same? Well, there is quite a variation in the sound produced by different SIDs, and the idea here is to exaggerate that by using a 6581 from a C64, and a much later 8580 from a C64C.
I raised the issue of a possible problem with two parallel SIDs when it comes to reading, as both devices will be selected, and both would try to write back to the databus. I suggested adding an OR gate to the chip select of the second device, so it would only be selected when the chip was selected and it was in read mode (or since it's all negative logic, it would NOT be selected if either the chip was NOT selected OR it was NOT in read mode). I said this could be implemented with a simple diode OR, and in the followup video, that seemed to be working nicely once the pull down resistor value was sorted out. To avoid any issues with that, I've used a single gate OR gate here, rather than a diode OR.
There are a few differences between the 6581 and the 8580. The power supply, filter capacitors and audio output amplifier circuit are all different. So what I've done here is to ignore the C64's filter caps and fit these onboard. I also ignore the power supply and have onboard 9V and 12V regulators, with the power to be tapped from the main power supply filter capacitor. I've left the audio from the main SID going to the C64, but both audio signals are also buffered onboard and fed to the audio output jack.

Commodore 64 PLA replacement with EPROM
Replacing the commonly faulty Commodore 64 PLA with an EPROM is something I tried a few years ago, with mixed results. I also tried to make a replacement using two GAL chips, but didn't get very far with that.
Following another video from GadgetUK, he seemed to have more success using the EPROM method and adding a 68pF capacitor to the /CASRAM line. The issue here is that due to what could be considered a design flaw in the C64, the /CASRAM line needs to be delayed by about 25nS to allow the addresses to be ready in the multiplexer before they are loaded into RAM.
I've updated my board to have space to add a suitable capacitor. These probably needs to be tuned to each board, depending on the type of RAM used.
To make this more repeatable, I've added a quad OR gate to add a configurable delay. Each gate has a propagation delay of around 9nS, so with the jumper you can select to tap the signal after 1, 2, 3 or 4 gate delays. This will add 9nS, 18nS, 27nS or 36nS delay to the signal .These timings are approximate, but are typical values. I can also shorten or extend this by using a different logic family chip.

Tuesday, 1 September 2015

PET microSD V2.0

I've designed some new revisions of the PET microSD, taking onboard some feedback from the original version. One user had a problem with power supply. The PET's 5V rail is a little overloaded on earlier boards at best, and sometimes when the capacitors dry up a bit the rails can take a little long to rise to the appropriate levels. Upping the brownout protection on the microcontroller helped in this case. I've never been happy tapping the 5V rail, so I've added a switch mode 5V regulator to the board, so this can now run on anything from 7V to 22V, which with come from the main reservoir capacitor, which is around 9V DC, or the 18V rail which feeds the 12V regulator.
There are two new form factors, the original stuck out the back of the PET, and to reduce the size, I had parts on both sides. This was quite lot of effort both to design and to build. For these new versions, the size is not as critical, so I've also moved everything onto the same side, so it will be easier to construct than the previous double-sided load board.
The first new version is a vertical board. All on one side, and with the new switching regulator, this plugs into the back like a ZX81 RAM pack. This will take up less space than the previous version, and should be easier to construct.
I've had a few requests for an internal mounting version. Whilst I did have one for an 8032-SK, the 8032 and it's predecessors if more of a challenge. It's not 100% internal, there needs to be a small loopback plug on the back. This has an edge connector to allow connection to external drives as well.
Inside a flat board plugs into the pin header on that board. Again, this is now single sided, and using a switching 5V regulator. It's difficult to picture how this will fit, this boar will sit flat on the inside of the case, just above the IEEE-488 driver chips. It should fit 2001-8032 boards, and also the 8032-SK.
These new versions should be available from the end of the month.
Finally, I've built up a litlle IEEE-488 extender with LED indicators showing the status of the various lines. This is mainly to help my testing, and save wear on the IEEE-488 port of my poor 4032, but if anyone else wants one, let me know.

Tuesday, 18 August 2015

Atari ST USB keyboard

I worked out the circuit for this a long time ago, but I've never actually built an Atari ST USB keyboard before. The main reason being the size of the case. If you have an ST case with only the keyboard and a USB keyboard controller in, it still takes up quite a bit of desk space, so I presumed no one would want one. The same with the Commodore Amiga.
Then someone asked for one, so here it is. The request was for a 1040ST, and I found a suitable candidate, this one looked quite nice, but actually appeared to be a 520STFM with a 1040STE badge? It also had a memory fault, and will serve as a supply of spares for another 1040STE I'm currently repairing.
The Atari ST keyboard has an integrated keyboard controller and two 9 way D joystick ports. This connects to the main board via a serial connection.
These are accessed from under the keyboard. A common source of faults on ST's is bad contacts on these, and this is caused by cracked solder joints due to mechanical damage. If you've ever had to wiggle a plug to get something like this to work, it's probably because of cracked joints like this. Wiggling the plugs just makes it worse as it stresses the other pins and can cause problems with them as well eventually.
So first task was to strip down the keyboard, clean all the contacts and fix the cracked joints on those connectors. I find the best way to deal with those is to effectively desolder them, removing all the existing solder, then resolder them with fresh solder.
The cable from the keyboard has an 8 way 0.1" on the end. To make wiring to the controller easier, I made a mating cable with the pin version of the Harwin M20 connectors.
The connections on that cable are as follows, the baud rate looks odd (7812.5), but this is a direct divisor of 1MHz (7812.5*128=1MHz), and also the 16MHz clock I was using.
  1. Ground
  2. Not connected (polarising pin)
  3. Floppy LED (active low)
  4. +5V power to keyboard
  5. Serial data from the keyboard (7812.5 baud, 8N1)
  6. Serial data to the keyboard
  7. Reset (active low)
  8. Ground
The cable was wired to a suitable USB keyboard controller, one of my smaller ones as few pins were required. This may have been a slight mistake as the ATmega8U2 on there ended up 98% full. I almost had to swap it out for an ATmega16U2.
The USB keyboard controller was fixed in the case so the connector could be accessed through an existing hole.
With that in place, it was just a case of writing the software. There are various documents online referring to the keyboard protocol. It turned out to be reasonably simple, Start by pulsing the reset line low, then there was an initial bit of communication to tell it to switch into a mode where it would report all keypresses and joystick movements. It is possible to configure it to work with one joystick and one mouse, rather than two joysticks, but I thought this would be more useful. Leave the ST mice for use with STs.
It was then just a case of reverse engineering what came back from the keyboard, each keypress and key release are sent as single bytes, and joystick movement is two bytes. These were translated into USB keyboard keypresses. I had to create a matrix of currently pressed keys and update that whenever anything came from the keyboard. There are two LEDs, one power which I left as that, and the other showed disk access, this now shows caps lock status.
When plugged into a PC or Mac or tablet, this appears as a USB keyboard and two USB joysticks, so can be used anywhere those could be used, including of course Atari ST emulators.
There is quite a lot of space left inside, enough for a Raspberry Pi or something like the Intel NUC I used in the Atari 800XL PC,
Other similar USB keyboards are available from my Etsy store. I haven't listed the Atari ST or Commodore Amiga USB keyboards, but if anyone wants one, just request a custom order.

Friday, 7 August 2015

Commodore Pet 2001-8 Repair - Part 1

Look what's just arrived, my latest acquisition, a Commodore PET 2001-8.
Looks in very good condition so far, and quite a low serial number 8411?
It still has the screws holding the lid closed, they often tend to be missing.
I've been after one of these for a while, quite an iconic piece of kit. The design dates back to 1977, although this one is from late 1978.
One of the earliest home computers, fighting for it's place with the TRS80 - both of which seem to have been forgotten by Apple fans. But neither of those have bonet props, so the PET wins for me.
These first PETs have chiclet style keyboards, the same layout as the later graphic keyboards, and the built in datasette drive.
Inside it was very dusty, doesn't look to have been touched for a while. The gap in the dust is where the keyboard cable was resting.
The large number of chips at the bottom show this is an early one. The 2001-8 comes with 8K of RAM and 7K of ROM. There were a few different versions of the 2001-8, some had 6550 RAM, some had 2114 RAM. Some had 6540 ROMs, and some 2716 compatible ROMs. This is the earlier combination, 6550s and 6540s.
That's going to be fun as replacements for these are very difficult to find, as I think they were only used in the PET.
The rest of the board has the CPU, I/O and video circuits, along with another 6540 character ROM and two more 6550s as the screen RAM. This looks rather random compared to the later more regimented board designs. All looks reasonable inside, time to turn it on.
It does a few different things on power on. Most of the time it boot up, then locks up, often with a few characters appearing on the screen first. And no, there isn't a key stuck down, it does the same with the keyboard unplugged, but thanks for the suggestion.
Other times you get the traditional garbage on the screen. This is sometimes misunderstood. When the system powers on, the contents of the screen RAM is random, and before the software in ROM is running, the video circuits do their job and show this on the CRT. It is always there, but usually disappears before the monitor warms up. Once the editor ROM starts up, it clears the screen and puts up the traditional '*** COMMODORE BASIC ***' prompt. So in this case, it hasn't run long enough to clear the screen.
Time for one of my ROM/RAM boards, but the 2001 boards have unusual chip sockets. They have extended sides so the make contact with the pins all the way up side. This means the usual turned pin headers I use on the ROM/RAM board do not fit very well.
I've built up a special ROM/RAM board with different pins, using the bottom half of some stackable headers.
This make good contact with the socket. I've loaded this up with various versions of BASIC suitable for non CRTC PETs like this 2001.
With the ROM/RAM board taking over, everything seems to be fine.
This ran various memory and system tests for several hours and all was well, so all the rest of the board is OK, the problem is the ROM or the RAM.
Leaving the replacement ROM enabled, but boing back to the original RAM, also ran for an hour or so with no problems. That's a relief, all the 6550s are OK.
So the RAM is OK, but to help isolate the issue, I've switched back to the replacement RAM and then enabled the original ROMs. That failed straight away with the original problem.
So the issue is the ROM, one or more of 7 6540s. Oh dear, however, the ROM contains the original buggy BASIC. You can tell the version from the header line. I count the points at the top of the first symbols. BASIC 1 has asterisks, *** COMMODORE BASIC ***, and BASIC 2 has hash signs ### COMMODORE BASIC ### is basic 2. (BASIC 4 says it is BASIC 4 *** COMMODORE BASIC 4.0 ***).
So for the moment, I'd be happy to leave the ROM/RAM board in place. I'll probably remove the precious working 6550s and the suspect 6540s. This will also significantly reduce the power consumption, so it should run cooler. The ROM/RAM board can be set to the upgraded 32K and BASIC 4, or can match the original 8K and BASIC 1.
Either way, it can play Space Invaders.
Although if I want to use the pet microSD disk drive to load it, I need BASIC 2 or BASIC 4. But first I will need to fix the IEEE-488 port, as that doesn't appear to be working.
I see a sticker above the datasette port, looks like someone was trying to tap power off it. 5V is still OK, but the transistor is probably gone on the switched 9V as the external datasettee port isn't working. So, lots still to do on the 2001. It needs a full strip down and clean up.
The internal datasette drive is basically a normal datasette bolted to the underside of the line. That is not working, it also needs a clean up and a new belt.
The monitor seems fine, and seeing the PET tester cycle through on the black and white display on this PET reminds me of a project I'm currently working on, here is a sneak peak.
This will be a plug in board which will replace the onboard video circuits to test PETs with display problems. This scans screen RAM to show an exact duplicate of the PETs screen on a 2.2" 240x320 TFT display, even if there is a problem with the onboard video circuits.
That's still a prototype, but I hope to make that available soon as a companion to the ROM/RAM boards.