Commodore 1541 disk drive to 2031 conversion

When I was finishing off the restoration of my first PET, I didn't have much luck with IEEE-488 drives for it. This was before the PET microSD, and I didn't have a disk drive I could get working with the PET. Before I go any further, here's a quick recap on Commodore disk drives and formats:

Model	Drives	Sides	Media Density	Capacity	Connection
2040/3040/4040	Dual Drive	Single Sided	Single Density	170K	IEEE-488
2031/2031LP	Single Drive	Single Sided	Single Density	170K	IEEE-488
8050	Dual Drive	Single Sided	Quad Density	521K	IEEE-488
8250/8250LP	Dual Drive	Double Sided	Quad Density	1042K	IEEE-488
SFD-1001	Single Drive	Double Sided	Quad Density	1042K	IEEE-488
1540/1541/1541II	Single Drive	Single Sided	Single Density	170K	IEC
1570	Single Drive	Single Sided	Single Density	170K	IEC
1571	Single Drive	Double Sided	Single Density	340K	IEC

As you can see, quite a variety of single and double drive, single and double sided, single and quad density. Drives with the same capacity were generally compatible with each other for reading, but not writing. Double sided drives could read single sided disks, but you still had to flip them over if you had used both sides in a single sided drive. So it's often difficult to work out what drive a disk was written in. When I was looking for a working drive for my PET, I found a scan of a German Commodore 64 magazine from the 1980s which had an article about converting a 1541 disk drive into a 2031 clone. (Update, it was 64'er magazine, see the last entry on this page at zimmers.net)  Narrowing it down, you can see the 2031 and 1541 have similar specifications, other than the connection type.

Drive	No. Drives	No. Sides	Media Density	Capacity	Connection
2031	Single Drive	Single Sided	Single Density	170K	IEEE-488
1541	Single Drive	Single Sided	Single Density	170K	IEC

The 2031 used parallel IEEE-488, the 1541 used the serial version of the same protocol. 1541's were the most common disk drive used with the Commodore 64, and VIC20, so there are a lot of them around, unlike the 2031 and the other IEEE-488 drives. The 2031 originally came in a large black metal case, using the same drive mechanisms as the 4040 drives. Later the 2031-LP was produced, using the case and drive mechanism from a 1541. Since the schematics of the 1541 and 2031-LP were very similar, the idea was to take a 1541 drive and modify it to match the 2031-LP schematic. The ROM would be replaced with the 2031 ROM (actually a patched ROM to make the 1541 act like a 2031). All the changes were to the IO pins of one of the 6522 chips, so this could be achieved with an add on board which connected one of the 6522's to some IEEE-488 buffers rather than the IEC ports on the drive.

I built this up on a bit of pad board and it sort of worked. The problems I now know were two fold. Firstly, I didn't want to mess up a good drive, so I had started with a 1541 which wasn't working properly in IEC mode, and unsurprisingly, it didn't work too well in IEEE-488 mode. Secondly, there were problems with the IEEE-488 port on both the PETs I was using at the time. Hence the confusion. I later reverted that drive back to IEC mode and fixed the problems with it, but by then I'd built the first version of the PET microSD disk drive replacements and fixed the IEEE-488 ports on my PETs, so I didn't need the drive.

I've decided to revisit this and see if I can get it working, this time starting with a 1541 drive I have already repaired first. It's made up of bits of several drives, but is working via IEC.

The first task is to replace the ROM. I've used an adaptor board and a 2764 EPROM to replace the original 8K mask ROM. There should be just enough space for it.

The second part is the interface board. This time I designed a PCB. It plugs into the 6522 socket, and the 6522 chip plugs into the board. The data and control lines pass through, but most of the I/O pins are not connected to the 1541 board. They are wired to a set of 75160 and 75161 IEEE-488 buffers to drive the IEEE-488 bus.

I used the same connection as my first attempt, a 24 pin IDC header and IDC 24 way GPIB connector. This extends over the neighbouring chips, so is raised up on an additional IC socket.

It's tight, but it all fits in place. The jumpers are for drive ID selection, both on for 8, right only for 9, left only for 10, both off for 11.

When I built the first version, I had started with a case that had arrived with some holes drilled into it presumably from drive ID or ROM switches, so didn't mind modifying it further to add the IEEE-488 Connector. I may fit switches for drive ID into the holes in the case at some point, but they are badly position if you want to stack things.

The original 1541 drive had two holes for two 6 pin DIN IEC connectors, which lined up with sockets on the PCB.

I filed these out to be able to fit the new connector.

The two DIN connectors on the 1541 board need to be desoldered to leave space for the GPIB connector, the cable runs over the top of the capacitor.

That all fits back together neatly.

OK, time to test it out. The drive powers on, the disk spins and the red light goes out. Good start. Lets see what the PET says.

Marvellous, seems to be alive. I found a 2031 test program in the PET archives, so gave that a go.

After lots of activity, that also passed, so it looks like it's working. Like the IEC bus, these devices are designed to be chained together, I can use this to transfer from disk to disk. I've tried reading and writing disks and disks full of content to the drive, and all seems to be working.

It's quite a neat modification inside as well. Note, this board is only suitable for the 'medium size' 1541 boards, such as the one I used. It will not fit the later very short boards, or the original long boards.

The original 2031LP would have had a PCB mount GPIB connector, and some additional filtering on the signal lines but this does the job quite neatly. (Update: here's a galley of nice pictures of a real 2031LP from xAD nIGHTFALL) Just needs a label for the front. I was going to copy a 2031LP label, but the drive cases I used has the embossed C= logo, so it wouldn't fit.

I can now use this to read disks from 2040, 3040, 4040, 2031 and 4031 disk drives, and the 8250 below can deal with the 8050, 8250 and 8296D disks. Now all I need is one of the 8060 series 8 inch drives.

The PCBs are available from my Tindie store. The most difficult parts to locate are the IEEE-488 connections. You can try to find something similar to the arrangement I used above, or solder a cable directly and run a long lead to an edge connector on the PET.

---

2023 Update

The PCBs are now available from my SellMyRetro store - https://www.sellmyretro.com/offer/details/61998

Patreon

You can support me via Patreon, and get access to advance previews of posts like this and behind the scenes updates. These are often in more detail than I can fit in here. This also includes access to my Patreon only Discord server for even more regular updates.

https://www.patreon.com/tynemouthsoftware

6502 Diagnostics Tester

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

I've been building a few more of the 6502 Diagnostics boards to run the PET diagnostics firmware.
It's a fairly simple build, but the microcontroller package is quite small and can be difficult to solder.
Before putting one of these anywhere near a PET, I want to make sure that all the pins are connected, and there are no shorts etc.

Most of the times I use a microcontroller, I would use the internal RC oscillator, or more often a crystal or ceramic resonator. In this case, the microcontroller is driven from the system clock, so it needs an external 1MHz clock fed to one of the pins. Once the configuration fuses are set to use an external clock, it is no longer possible to program it without that external clock being present. In order to program and test the boards, I need a clock and some way to monitor the pins. When testing the first ones, I used a signal generator and logic analyser, but that's not really practical to setup each time I built a batch.

I can't use the built in clock generator, so it needs an external clock. I looked at a few options, using a similar style to the PET, using a crystal and a couple of logic gates to form an oscillator, but I would need to add some more to divide that down to 1MHz. I also considered just using a 555 times, but that wouldn't be fast enough, I think a few hundred KHz is the limit there.

I then had a look around at self contained 4 pin crystal oscillator modules, I had a few, but they were all too high frequency. After looking at various options that were too fast, or too slow, and all involved a few too many parts, I went for an easier option.

This is an ATtiny45, a small cheap (<£1) 8 pin microcontroller. This has an internal RC oscillator and can be set to feed this to one of the output pins. The RC oscillator is 8MHz, but it can be set to divide by 8 internally, giving 1MHz. Perfect. In the end, I didn't actually write any code for this microcontroller. It was all done with the fuses. Set it to RC oscillator, divide by 8, clock out on PB4. For those playing along at home, this was all it took:

avrdude -v -pattiny45 -cusbtiny -e
        -U lfuse:w:0x22:m -U hfuse:w:0xdf:m -U efuse:w:0xff:m

With the clock sorted, I needed to add some way to test the output, lets face it, it was always going to be flashing LEDs. I had some 20 way LED bar modules I use for the IEEE-488 diagnostics board, so I used a couple of those. Nice and simple one LED per pin, LED on if the pin is high.

That fitted neatly on a small prototyping board, but there wasn't space for the usual SIL resistor arrays, I also didn't have enough of those at hand, so I went for adding those resistors on the back, using 1206 surface mount resistors soldered to a common ground wire.

That all worked out very neatly. The microcontroller is hidden under the socket, only three pins are connected, 0V, 5V and PB4 which is clock out that goes straight to the clock in pin of the IC socket.

There are two 0V and one 5V connection on the 6502 socket, these are wired so they will always be lit. The clock output will always show as half brightness as it is a 50% duty cycle square wave. It's a buffered output from the microcontroller, so is more than capable of driving an LED. Time for some testing.

I added various test patterns to the software to check for missing connections, shorted pins etc. Here it spotted two shorted pins on another board, you can just see the two faint LEDs on together. in the middle of the bottom row.

With all that verified and the normal firmware loaded, time to test the newly built 6502 diagnostics model on a real PET.

Working nicely (once I set the DIP switches correctly).

A useful bit of test kit for when I build these boards, and it should be useful for the future USB serial driven versions as well.

If you would like one of the 6502 diagnostics boards (not the LED tester board!) with PET diagnostics software, you can order one below.

VIC20 Penultimate Cartridge Preorder

I'm pleased to announce the VIC20 Penultimate Cartridge I have been working on is now going into production by www.thefuturewas8bit.com. Like the nicely cased SD2IEC they produce, the VIC20 Penultimate Cartridge is also going to have a custom case.

Taking styling cues from both the VIC20 and later Commodore 64 cartridge designs, it's going to look fantastic. The label is only on the top half of the case, so you can read it when it is inserted, unlike the original VIC20 cartridges, where you have to remove them to read the title. And let's face it, when this is installed, you're never going to want to remove it.

The colour should be close to that of the brown VIC20 utility cartridges, the thinking being that although VIC20 cases vary from bleached retrobrite white through to smokers teeth yellow, the keyboards are all still brown.

This case has been designed to accept standard VIC20 boards, including my current Penultimate Cartridge boards.

There are two buttons on the new case, so a new space invader shaped board has been designed. Rather than the section sticking out of the top, there are wings on the side with buttons for 'menu' and 'reset' in the corners.

The firmware is now at revision 5.0a, and includes 43 ROM titles, selectable via keyboard or joystick.

Included on there are text adventure cartridges which used to need the user to type 'SYS 32592' to start them. This has been automated, so they will run automatically.

From this menu you can also set common RAM sizes to exit to BASIC, or load a file browser from disk, ideally suited to loading FB20-8K from an SD2IEC. Block 5 RAM is cleared whenever it is used, to avoid auto starting anything you had previously loaded into there.

There is also an advanced menu where you can select which blocks of RAM to populate to suit any programs with particular requirements from 0K through to 35K.

The VIC20 Penultimate Cartridge is available to pre-order now from www.thefuturewas8bit.com. Or if you prefer, buy an uncased version now (while stocks last).

UPDATE

I've updated the firmware to V5.0c, and added a user guide and a few more ROMs

UPDATE 2

Great video review from GadgetUK164

Penultimate Update:

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

VIC20 Internal SD2IEC

If you've got a VIC20 or a Commodore 64 and you want a simple disk drive replacement, the solution is fairly straight forward, you get an SD2IEC.

These are some very nicely packaged versions from The Future Was 8 bit, in a variety of shades to suit a range of Commodore machines.

These work well with the new VIC20 Penultimate Cartridge, which can automatically start the file browser from its menu.

During the development I have been borrowing a clear SD2IEC from my clear cased C64C.

And also a nice VIC20 coloured one on my main VIC20, made out of recycled VIC20 cases.

The VIC20 I was using for development wasn't one of my best. It arrived with one of those Commodore power supplies where the 5V was more like 7.5V, and many of the chips on the board had been fried. I had to replace most of the chips to get it running, but it's been a useful test machine since most of those chips were now socketed.

Something I've been meaning to do for a while was try out the idea of an internal SD2IEC, so I thought this would be a good candidate.

The internal SD2IEC boards (the SD2IEC Classic V1.0) are similar to those used inside the normal SD2IEC units, but without the buttons. There are additional contacts at the edge of the board to fit buttons and duplicates of the onboard LEDs.

The only pins needed for the IEC bus are 6 at one end, so I fitted a 6 pin 0.1" header, soldered to each side of the board. You could just solder the wires directly, but I thought this would be neater and would allow it to be removed easily if necessary.

There are various points at which the wires can be attached, I chose a set of vias just before the 6pin DIN socket. These were a bit tarnished, but with some desolder braid and extra flux they cleaned up nicely.

I've marked the connection points, these are relevant to this revision of the board, the VIC20-CR 250403 / 251040-01 Rev D. Always a good idea to check continuity to the socket to make sure you have the right pins.

I've tapped 5V and ground at nearby vias and attached five wires to these five vias.

On the end I've fitted a 6 pin connector suitable to fit the 6 pin header (Harwin M20), and plugged this into the SD2IEC board.

I was initially thinking of resting this between the DIN sockets and the VIC shielding, but in the end I've gone for attaching it to the lid of the VIC shield with foam pads. Making sure the contacts are clear of the metalwork.

Testing this, the lights flash reassuringly and the file browser appears. If I were planning to close the case up, I think I would look at changing the VIC20's power LED for a tricolour one, red for power on and then amber for disk access.

This one, however, runs mainly without a lid, with the prototype Penultimate Cartridge installed, so the onboard LEDs are fine. My bench is now a little tidier.

Update: an internal SD2IEC for a C64C.