Sunday, 25 November 2018

Commodore 16 internal SD2IEC SD card disk drive

I have fitted several of these SD2IEC modules inside machines before (see posts on the VIC20 and C64). This one is the SD2IEC Classic from The Future Was 8 bit.
This time, one is going inside a Commodore 16.
There is loads of space inside the C16, so this shouldn't be a problem.
There is even space on the back edge, so you could cut a slot and have the SD card sticking out of the back of the case. I'm not doing that here, just fitting it internally. It's only three screws to open the case if I need to change the contents of the SD card, new C16 software is not coming out that often these days.*
The connections required are three IEC bus pins (ATN, Clock, Data), 5V power and ground. These can be found on the ferrite beads below the IEC socket, as follows.

Pickup point
Wire colour

I did try desoldering the lead on the ferrite bead and fitting the wire back into the same hole with the bead. That had worked with diodes on the other machines (there are no protection diodes on the C16....), but there wasn't enough space. I instead soldered the wires on the bottom of the PCB.
Red and black go to 5V and ground respectively. There are a number of sets of holes on the side of the board, apparently designed for decoupling capacitors that weren't fitted. I cleared a set of these for the power wires to attach.
The wires could be soldered directly to the SD2IEC classic board, but I went for the same option I had previously used, fitting a 6 pin header and matching socket.
The board was attached to the case using two foam pads.
That all fits quite neatly in the space at the side of the case.
The pinouts of the SD2IEC board are shown below (taken from the TFW8b info page). This is the top
And the underside.
You could leave it there, and it works fine, but you don't have the buttons or LEDs. I don't think there is much software for the C16 that requires multi-disk swapping, so I'll not bother with the buttons, but the activity and error LEDs would be nice.
I don't want to drill extra holes in the case, so I have modified the power LED to show the status of the SD2IEC as well. To do this, I have removed the standard 5mm red power LED, and replaced it with a tricolour LED.
The wiring of this is a little convoluted. I wanted it to be able to show access and error, but also function as a power LED. I went through quite a few ideas on paper to get this to show red for one thing, green for another, amber a third etc. several of which would have required additional logic gates or transistors.
I finally went for a circuit which required a common cathode LED with three resistors and a diode. I loosely taked the parts together for testing (as shown below). The final version was tidied up a lot. The two central wires attach to the normal LED connector, these pick up 0V directly on the black wire, and the red wire is connected to 5V via a 470R resistor on the C16 board. There is now an additional 1K resistor in that lead. This means the LED lights red, but slightly dimmer than normal (it is actually about the same brightness when dim as the original LED, as technology has improved since the days of the old GaAs LEDs.).
The two outer wires connect to the SD2IEC. Green is connected to activity via a 330R resistor, this means the LED changes to amber when the SD2IEC is being accessed. The red wire on the right is connected to the error LED output, via a 100R resistor. This means the LED flashes a brighter red if there is a problem. There is also a diode in series to stop the LED turning off when the error output of the SD2IEC goes low.
The red and green wires attach to the two pin header I added to the SD2IEC classic board.
The red and black wires plug into the normal power LED connector on the C16. Note the heatsinks on the CPU and TED chips, these are difficult chips to replace, and they do run hot, so heatsinking should help extend their short lives.
Time to test it out. The C16 has BASIC V4, so I can use some of the additional commands I am used to for the PET that the C64 and VIC20 don't have.
PRINT DS$ shows the last response string from the drive, immediately after power on. this will give a firmware version number. DLOAD "filename" is the same as LOAD "filename",8 (in general terms anyway).
DIRECTORY can be used to do the same as LOAD "$",8 and LIST, but without clearing the program. (although it does it in a horribly inefficient way at the protocol level). In BASIC you can just press F3 and it will type DIRECTORY for you and press enter.
SHIFT and RUN/STOP also follows the PET BASIC 4.0 style, and will load the default program from the SD card.
And we're in, the filebrowser showing the disk contents,
Of course, the first thing I loaded was RodMan, you get a free digial download version when you buy the tape set. (* what was I saying before about the lack of new games for the C16....)
I tried out various other titles, and the activity LED was doing it's thing nicely on loads and saves.
The C16 is a little limited with it's 16K RAM, so some of the games I tried to load must have been designed for the plus/4. I might have to address the RAM next..... (update, I did - C16 64K RAM upgrade)


Sunday, 18 November 2018

PET IEEE-448 port faults

All of the Commodore PET series of computers have an IEEE-488 port, used for disk drives and printers. (I checked all of my PETs, and none of them seem to be labelled, but imagine it says IEEE-488 over that port)
There are quite a lot of elements that go to making up the port on the, and thus many things that can go wrong. It is a parallel 24 pin bus, with 8 data pins, and 8 handshaking lines, and 8 ground pins.
Close by the port, there are three MC3446 buffer chips, and next to that a 6520 PIA. You might think that with more than 16 IO pins, that 6520 would be enough to drive the port, but that's not the case. It is arranged so that each pin on the IEEE-488 port is connected to two IO pins, one to drive the pin, one to read the values, so as well as all the pins on that 6520, it also uses a number of IO pins on the other 6520 (near the keyboard connector) and the 6522.  REN is not used, the PET is always going to be the bus master, and IFC is only an output, SRQ only an input.
Reset buffered through 7417
Tied low
In the above table, there are three main chips referred to PIA#2 is the 6520 nearest the keyboard connector, PIA#1 is the other 6520, nearest the IEEE-488 port, VIA is the 6522, usually between those two. The IEEE-488 bus is one part of the PET which didn't change from the 2001 up to the 8032, and with a few minor changes onto the later CBM-II machines.
This two way circuitry does make it possible to do quite a lot of testing from the machine itself. If you read back the value of a pin, then change the machine output and read it back again, you can see if it has changed. The 8 data bits are the easiest to start with, whatever value you write to address 59426 is written to the port, so
POKE 59426,0
will set all the outputs low. A word on states and levels here. Writing 0 to one of these outputs pulls the bus line low, this is the 'asserted' signal, and means it is active. When no device is asserted, the signal is pulled high by pull up resistors, 'released' to high. Nothing will ever drive the bus high, all they do is let it float or pull it low. To read it back, type
That should show 0. If it does not, there is a problem with PIA#1 or one of the MC3446 buffers. You can then try various other values up to 255 which should have all the output lines high. Testing other pins is a little more complicated, this table shows the values to poke and peek at.

Write 0 (Assert)
Write 1 (Release)
Read value
POKE 59426,0
POKE 59426,255
POKE 59409,52
POKE 59409,60
POKE 59427,52
POKE 59427,60
POKE 59456,255
POKE 59409,253
POKE 59425,52
POKE 59425,60
POKE 59456,251
POKE 59456,255

This can be useful to identify which pins are working, and any at fault, but it doesn't show if the problem is the output pin (or it's associated buffer) failing to drive the output low, or the input pin (or it's associated buffer) failing to read back the state correctly. You can check this with a multimeter on the pins of the port, but I have built a board to make that easier.
This board plugs into the IEEE-488 port and has 16 LEDs which light to show the state of the bus pins. The LEDs reflect the voltage level on the pins, so when everything is released and all lines float high, the LEDs will all be on. If any lines that are asserted, the LED for that line will be off.
When doing the POKE and PEEK tests above, if the LEDs change when you POKE the pins, then the output side is working, and the input drivers are at fault. If the LEDs do not change, then the output side is at fault.
You could make something like this to take power from the bus, but to limit loading on the bus, I have used buffers to minimise load on the bus, so the board needs 5V power, and for that I use the same datasette power pass through boards I used to use with the PET microSD disk drives.
There is a pass through for the IEEE-488 as well, so you can monitor activity during normal operation on the bus. Who doesn't like blinkenlights?
I have listed these on my Tindie store, as PCBs, kits or assembled units.


Sunday, 11 November 2018

Atari 400 48K RAM boards

In the last blog post, I upgraded the RAM in an Atari 400 from 16K to 48K. Here are the new boards to make that process easier.
On that first 400, I tried soldering a 32K RAM chip under the board, and reassigning the original 16K RAM card to sit after that giving 48K of RAM.
That worked nicely, but wasn't as neat as original planned, as I needed to add a NAND gate, and two OR gates to complete the circuit, so I went back to the idea of replacing the original 16K RAM card with a new one.
The new RAM card is a lot smaller than the original 16K card, but fits in the same slot.
The problem with that approach, is the cartridge is only wired for a maximum of 32K RAM. The card can be used like that, without any modification to the Atari 400, this will give 32K of RAM.
However, to get the full 48K, the missing signals can be connected to some unused pins on the connector.
Four links in total are required, connecting from the cartridge port to the RAM card slot, as follows:
  • RAM slot M → Cart slot A (pulled high by cartridge when S4 area in use)
  • RAM slot N → Cart slot 1 (/S4 signal)
  • RAM slot R → Cart slot 14 (pulled high by cartridge when S5 area in use)
  • RAM slot T → Cart slot 12 (/S5 signal)
With those modifications, you get 48K, which can be used when loading from disk or tape.
In BASIC, as with any Atari, 8K of that is hidden behind the ROM cartridge, so the maximum BASIC sees is 40K.
The labelling is slightly unusual, as one side is number 1-22, the other is A-Z (missing out G, I, O and Q). The cartridge is port is 1-14, A-S.
The sides facing the front is the letters, with pins 1 and A on the right hand side. The chips on both cards face the back of the unit.
The 48K RAM card is available now from my Tindie store, either as an assembled unit, ready to go.
Or as a kit, complete with ready programmed GAL chip.
Once that is installed and the Atari 400 is reassembled, it's pretty much an Atari 800, certainly in terms of software compatibility.


I am now shipping V2 boards. These use a different GAL chip, the 16V8, as I have been having trouble with the 22V10s recently, so I am phasing them out of all my designs.
The timing of the read and write cycles have been tweaked slightly, following some testing on a 400 with an early 6502 CPU board (rather than the normal 6502C version). These are available to order from my Tindie Store:


Sunday, 4 November 2018

Atari 400 48K internal RAM upgrade

In the previous blog post, I started upgrading an Atari 400 by fitting a composite video modification.
That was all working nicely, but was a little limited when it came to tape based software, due to only having 16K.
On the Atari, PRINT FRE(0) will show how many bytes are free, here showing 13596 bytes, the 16K less memory used by BASIC and the OS.
The Atari is a multi board system, the base board mainly handles IO, and there are two plug in cards permanently installed.
The first is the CPU board, this contains the 6502C, GTIA and ANTIC. On this particular board, I had to replace the GTIA chip on the left as it seemed to have issues with sprites. It was otherwise fine, but when a sprite like the hammer on Donkey Kong was used, there would be vertical interference around that area, which would follow the sprite around.
The second board is the 16K RAM.
This is made up of 8x4116 chips. I beleive there was also an 8K version with 4108 chips, but the 16K version is most common.
The Atari 800 is the bigger brother of the 400, but shared many parts, including these two boards. The 800 was designed to be upgraded, so the boards are in cases, and the slots are accessible by lifting up the lid. This didn't get used much, as most 800s had the full 48K installed from new when the price of RAM fell sufficiently.
The 800 had three slots for RAM cartridges, so could support up to 48K, as demonstrated by the handy guide on the back of the RAM cartridges.
The Atari address space is organised into eight 8K blocks, as follows.

Atari 400
Atari 800
Right Cart or RAM
Left Cart
Left Cart or RAM
I/O + OS
I/O + OS

The RAM from 8000-BFFF is shared with the cartridge slot. When the cartridge is plugged in, the RAM is disabled. It should be possible to upgrade the 400 to work like that, and with this upgrade, the two machines should be functionally identical. The main address decoding on the Atari 400 uses a 74LS42 chip, a 4-10 decoder, a slightly unusual choice over the ususal 74LS138 3-8 decoder, especially as there is already a 138 on the BOM, so it would surely have been cheaper to use two of those instead?
This generates eight active low select lines, S0-S7. S0-S3 represent the lower 32K of RAM, and all four of these are connected to the RAM slot on the 400. Lines S4 and S5 go to the cartridge slot. S6 and S7 go to the ROM chips and on to the IO decoding (using the 74LS138). Based on that, it should be possible to create a 32K RAM cartridge that would replace the 16K one, but there is no access to the S4 and S5 lines, so that's not ideal as it wouldn't be possible to use this as well as the original 16K cart to get 48K.
My first plan was to use one of my PET ROM/RAM boards to add the extra RAM, but the position of the CPU board precludes the use of a plug in daughter board as it is too close to the edge of the metalwork. I then briefly considered a replacement CPU card which included RAM, but there's a bit too much stuff going on. Also the schematic I had for the CPU card doesn't match the boards I have (they appear to include 245 buffers on the address bus which are not necessary with the 6502C version of the CPU that has the additional halt pin).
So, what next? Well a plan was starting to develop here. The control lines we need are not on the cartridge port, so it's not going to be possible to create a 48K RAM board, at least not without modifying the 400 main board as well.
There are three ROM chips on the 400 main board. These are 24 pin ROMs, the pinout of which is a reasonable match to the lower 24 pins of a 32K RAM chip.
A chip such as this, the IDT 71256, which is a narrow version of the standard 62256 32K x 8 SRAM chip. My thinking was to use wire this chip to most of the lines on the 24 pin ROM, and then connect the rest as appropriate.
That looked like it was going to work. The RAM chip here is facing into the board, so it is the same orientation as the ROM chip.
The only lines not soldered directly to the board were A13 and A14 on the top right, 5V on the top left, then the /WE pin, which was connected to R/W Early (more on that later), A12 and the /OE and /CS lines. I could have generated the enable for the RAM by ANDing S0,S1,S2 and S3, but in the end it is just the A15 line. Low for 0000-7FFF, high for 8000-FFFF, which is exactly what we need.
That didn't work as expected, so I spent a while working out the way the timing worked on the Atari. The standard 6502 R/W line isn't passed on from the CPU card, instead there are R/W Early and R/W Late lines. Early is close to the standard line, and Late is delayed to be the second half of the write cycle, by which time the data should have settled.
After trying various things, it seemed to the problem was on the read side, and I mimicked the original RAM board by generating the /OE signal from /REFRESH and R/W LATE. That means adding a little 5 pin single gate NAND gate chip to the side. Not the neatest solution.
But it worked. The Atari was now reporting 29710 bytes free, so the 32K was recognised, and I was also able to load various things from tape that hadn't worked with 16K.
Such a Rodman. This should be a 16K game, and it will run in 16K on the emulator, but unfortunatley the loader takes it just over 16K and so won't run on a standard Atari 400. It now runs fine on this newly modified 32K Atari 400.
So that is 32K, what about the next 16K to make it the full 48K machine?
On the Atari 800, the lower 32K go to two of the slots, and there are two OR gates controlling the next 16K. Pin 14 on the cartridge is connected to 5V by the cartridge PCB, so that when the cartridge is plugged in, the OR gate will disable that section of RAM. The 680R resistor pulls this line low when a cartridge is not installed and enables the RAM. Pin A does the same for the right cartridge.
There is a slightly confusing arrangement of control lines going on, you can see on the rear of the RAM cartridge PCB that pin T is connected to S, N to M and R-P. This is different on the 8K version (N-P, R-S, T-U), to allow different combinations of 8K and 16K RAM modules to be used in the correct order.
What this boils down to is there are two inputs, 18 and U either of which will enable the RAM when low. On the Atari 400, those are connected to S0 and S1, so the RAM is mapped from 0000-3FFF. On the Atari 800, when you have two 16K boards installed, those two enable lines on the third card end up connected to the two OR gates. That means that we can copy part of the Atari 800 design, and fit OR gates to check the S4 and S5 lines, and the cartridge present lines to generate enable lines for the 8000-BFFF range, and those can be connected to the two pins on the original unmodified 16K RAM board.
Again, not the prettiest modification, a 74LS32 OR gate soldered upside down to the bottom of the board. I've implemented both gates, as although the 400 does not have a right cartridge slot like the 800, the right cart address range is also present on the left cartridge slot.
The output of the two OR gates connect to the PCB pads where the S0 and S1 signals would normally come out of the 74LS42 chip, but I have bent up the legs instead of cutting the tracks, so there is no clash, and so this can be reversed.
With that, Atari BASIC is now reporting 37902 bytes free, the maximum you will get as it's actually only 40K as the BASIC cartridge takes 8K out of that.
Without the BASIC cartridge, the full 48K should be available, and I have tested that with some large (must be, based on loading time) games, including my favourite Spellbound which got a lot of play on my Atari 800XL back in the day.
I also found a demo tape, showing off the capabilities of the Atari.
Those all seem to be working well, I think we have a 48K Atari here. It's not very neat though, I probably wouldn't recommend anyone actually do it like this.
It's all hidden out of the way, and there was a cardboard separator between the board and the metal case, so it is protected from shorts and will not been seen in normal operation.
I've been looking at alternative options, and I've designed a 48K RAM cartridge. This will not work on an unmodified Atari 400, but all it will take is four wires to be soldered between the cartridge port and the RAM slot, but it should be acceptable.
The logic in the cartridge is slightly different that implemented on the hard wired upgrade, there the A14 and A15 lines are not present, so the RAM /CS line has to be generated from the S0-S3 signals. It would be possible I suppose to go for bank switching like the 130XE. This has a bank switching register to allocate 4 additional banks of RAM to the 4000-7FFF range. Not sure that extra complexity would be of much benefit, was there much 130XE only software, and how much of it would you really want to run on your souped up Atari 400?
At the last minute, I decided to play it safe and redesigned the board to use a GAL chip, so I could tinker with the logic equations if necessary. There will be a follow up blog post when the PCBs arrive, showing a much neater version of the mod. In the mean time, more change to try out some of my Atari tapes from the 80s.
Just one addendum (as if this blog post wasn't already long enough). I found a game I remember I could never get to load.
It would always get to 1 block from the end, then fail.
Unfortunately, this was already the other side as that same damage stopped the first side loading as well. I decided to see if modern technology could save this (ignoring the easier option of buying another copy of the tape, creating one from an online copy of the game, or just loading it with an SIO2SD).

You can clearly see the damage at the start of side 1 and the end of side 2. So I spliced the start of side 2 with the end of side 1 and created a new wav file.
I wrote this to tape and tried loading it. It got all the way to the last block...
and then, 30 years after I got this tape, I finally got it to load.
Was it worth the wait. Probably not.


See the following blog post for more info, 48K RAM upgrades are now available from my Tindie store.
