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.

IEC Pin	Signal	Pickup point	Wire colour
1	SRQ	-	-
2	GND	-	-
3	ATN	FB5	White
4	Clock	FB4	Green
5	Data	FB3	Blue
6	Reset	-	-

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)

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.

Signal	Read	Write
DIO1-DIO8	PIA#1 PA0-PA7	PIA#1 PB0-PB7
EOI	PIA#2 PA6	PIA#2 CA2
DAV	VIA PB7	PIA#1 CB2
NRFD	VIA PB6	VIA PB1
NDAC	VIA PB0	PIA#1 CA2
IFC	N/C	Reset buffered through 7417
SRQ	PIA#1 CB1	N/C
ATN	PIA#2 CA1	VIA PB2
REN	N/C	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

PRINT PEEK(59424)

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.

Pin	Write 0 (Assert)	Write 1 (Release)	Read value
DIO1-DIO8	POKE 59426,0	POKE 59426,255	PRINT PEEK(59424)
EOI	POKE 59409,52	POKE 59409,60	PRINT PEEK(59408)
DAV	POKE 59427,52	POKE 59427,60	PRINT PEEK(59456)
NRFD	POKE 59456,255	POKE 59409,253	PRINT PEEK(59456)
NDAC	POKE 59425,52	POKE 59425,60	PRINT PEEK(59456)
ATN	POKE 59456,251	POKE 59456,255	PRINT PEEK(59425)

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.

---

2023 Update

There is a new version of the PET IEEE-488 diagnostics.

http://blog.tynemouthsoftware.co.uk/2023/10/pet-ieee-488-diagnostics-updated-version.html