USB to IEEE-488 for Commodore Disk Drives

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

Here are the details of the USB to IEEE-488 / GPIB adapter I have been using to test the Commodore PET IEEE-488 disk drives.

Like the USB to IEC adapter I build last year for testing Commodore 1541 disk drives, this one is based on xum1541 firmware. That needs to run on an ATmega32U2, and as before I adapted one of my USB keyboard PCBs for the purpose. The latest PCB for the ZX81 adds a sounder to click on each keypress (which makes typing easier), and a mode switch. That leaves a pile of the old style PCBs for tasks like this.

I've added a piece of padboard to add the additional circuitry, held in place with a couple of cable ties and by the resistors which bridge the boards.

There are 8 grounds, 8 data lines and 8 handshaking lines on the 24 pin connectors, I've wired all those to short lengths of wire.

The two LEDs for power and activity fit in the lid.

The rest of the circuit (a 7406 hex invertor) also goes on the padboard, and it is all wired together.

That just fits in the box.

The circuit is actually the same as the IEC version, so I could have added a 6 pin DIN socket, but there wasn't space. Once complete, the unit plugs into the back of the disk drive.

I had forgotten the 8250 drives have the connector mounted upside down, so the LEDs are pointing downwards. I should be able to turn the connector round later on, although it is the right way around if testing with the board loose though.

However it's connected, the drive can be accessed using the xum1541 versions of the opencbm command line apps.

The CMBXfer GUI also works with this

It also works with the 1541 disk drive converted to a 2031.

I don't think anyone expected these two things to be connected together, so it is not recognized by the detect command.

I'm having a few problems with the 2031 clone responding intermittently. I'm seeing the same problems talking to the drive from real Commodore PET computers, so I don't think it's this adapter at fault. As a test, I went back to the 8250 disk drive, I tried copying a .d82 disk image to a real floppy disk.

Don't be fooled by the progress bar, that's only the first track of many.

It took almost half an hour to copy the whole image, certainly a good test of the adapter and the drive.

Once complete, a directory showed just how little was actually on the disk image, but still it had been a useful test, and I now have an 8250 demo disk to test the drive out.

Checking the disk on a real computer, the files have transferred correctly. Another useful bit of kit to add to the collection.

As ever, credit to those who created the xum1541, opencbm, CBMxfer and other tools I have used.

Two very different PCs - Custom built vs HP

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

I have two very different PCs on the bench today, and it's interesting to see just how different. The one on the left is one of my custom built PCs I'm just putting together. The one on the right is a generic off the shelf HP unit. Prices for the custom ones start around £400, The HP one would cost around £300. So what do you get for the difference in price, which one would you like?

From the front, the two look fairly similar, smart black cases, one badged Fractal, and one HP. One matt, one shiny (both with finger marks). Both have DVD RW drives, the one on the HP is hidden behind a flap. They both have two audio jacks, and two USB, the custom one has one USB 3.0 and one USB 2.0, the HP has both USB 2.0. It also has an SD card slot.

From the back, the difference is a lot more noticeable. There seems to be a lot of sheet metal on the HP on the right, and lots of mesh on the custom one on the left.

Looking at the custom built one in detail, on the rear is the mains input and power switch, then an I/O plate with a PS/2 port for anyone planning to keep an older style keyboard, four USB 2.0, two USB 3.0, gigabit LAN, SPDIF, four display options: HDMI, Display Port, VGA, and DVI, and six audio jacks. There are also four expansion slots, and there will also be a Windows 7 licence sticker going on there.

Inside, there is lots of opportunity for expansion, PCI express 3.0x16 slot, two PCI express 2.0 x1 and one PCI express 2.0 x8 slot. There are also a lot of additional power supply cables hidden in the spare drive bay, and the 430 Watt supply has much extra capacity. The processor is a Haswell i5, these are very solid chips with build in memory controllers and fairly decent on board video. The storage is a 250GB SSD, making full use of the SATA 3.0 on the mainboard at up to 560MB/s. Two of the four RAM slots are filled with 4GB DDR3-1600 sticks, these run in dual channel mode, so I'm getting a memory access speed of 18391 MB/s in memtest.

There are headers for additional SATA 3 hard drives, and header for extra USB ports, even parallel and serial if required. Cooling is via the intel stock cooler, which is fine for these modern intel processors as they just don't get that hot even at full pelt. There is also a 120mm case fan balancing the air flow with the 120mm fan on the PSU, giving neutral pressure in the case, reducing dust build up.

Looking in detail at the HP, it's a little different. No mains input, as it actually uses a 90W laptop style power brick. That does get a bit warm as it was drawing about 80W in use. It may be the mechanical hard drive making the difference, the custom one draws about 40W.

The other connections on there are two video options (DVI and VGA), four USB 2.0, gigabit LAN and three audio ports. Inside, it is fairly empty, although the case looked like it could accommodate a standard power supply and PCI expansion cards, inside it is clear it doesn't.

There is a mini PCI Express socket, with a WiFi adapter installed, but other than that, no opportunity to expand. The processor is the older Ivy Bridge i3, but at least it is an intel, most of the cheaper units use AMD chips, and I see lots of dead AMD laptops, so I'm not a fan. There is a single stick of DDR3-1600 RAM running in single channel mode, so it scores 9425 MB/s in memtest (half the speed of the custom one in dual channel mode).

The hard drive is mechanical 1TB drive, reading at about 80 MB/s. Most people seem to only use a few hundred GB at most, so the money would be better spent on a smaller but considerably faster SSD (about 560MB/s). HP have used their traditional slightly rotated Cooler Master heatsink and fan, and a rear 120mm fan. This arrangement pulls air into the case where ever it can, which is why you get dust build ups around any gaps or holes in the case.

Printers have become pretty much disposable items, this looks like they want PCs to go the same way. The HP board is non standard style, so it will be difficult to replace in the future. The case has 'security' screws in case you wanted to go inside, but they are just T15 and there is usually a full set of TORX bits in all these 101 bit screwdriver sets these days. So it seems to be designed to be plugged in and used and then thrown away in a couple of years time without ever being opened. That may be what people want?

When I build a custom PC, it has thumbscrews on the case, feel free to look inside. I like to do a proper job of cable management and a tidy case makes for better air flow. I use good quality, reliable parts, these all have at least three year warranties, and are standard sizes and easy to replace or upgrade in the future and to should last a long time. The system runs cool and quiet, and with the lots of RAM in dual channel mode and an SSD, very fast.

The HP is in for repair two months after the 30 day Argos warranty expired.

So which one do you want?

2022 Update: I wonder if either of these is still in use. I know which one my money would be on 

Commodore 8032 and 4032 GPIB IEEE-4888 Repair

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

This is a follow up to the previous post about the fun I've been having with Commodore disk drives using GPIB or IEEE-488. The problem was I'd been restoring an 8250 dual disk drive, and couldn't tell if the lack of response was due to the 8250, the cabling or the computers I was plugging it into. I had thought the issue would be the drive, since I wasn't getting a response from three different computers (two 8032's and a 4032).

In the previous article, I'd tried to convert a 1541 IEC disk drive into a 2031 IEEE-488 disk drive. That didn't work either, so I suspected the Pets. I then built a USB to IEEE-488 interface and found that actually, the 8250 was working but everything else wasn't. To rule it out, and since I will need one anyway, I built a second Pet to IEEE-488 cable, that didn't make a difference.

So now I know the issue is actually three Commodore PET computers that have a faulty IEEE-488 port. There are a few parts to the interface, the IEEE-488 bus is attached via three MC3446N quadruple bus transceivers, and one gate of a 7417 open collector buffer. Each of the 4 channels on the MC3446N has a bus pin and a read output and a data input. This means each of the 8 data pins and the 5 handshaking lines used actually need 2 I/O pins each. The 8 data line reads and writes are provided by the top 6520 PIA, and the handshaking lines by spare pins on the lower 6520 PIA and the 6522 VIA.

I had already tried replacing the VIA and the PIAs, and had ruled them out, so it was down to the three bus transceivers or the buffer. It's difficult to check three pins for each line on the scope or logic analyser, although it looked like most of the pins were doing something. The MC3446N is no longer manufactured, and I couldn't find a drop in alternative, I did have some chips removed from a spare board, but didn't know if they worked either. I could try swapping them around until something worked, but I wasn't happy with that idea. My EPROM programmer can test certain chips, and I did use it on the 7417, which passed, but it didn't have a mode to test the MC3446N. So I tried something else.

I took one of the spare MC3446N chips, wired it up to an Arduino and wrote a little test program to test each gate by writing high and low and reading back from the bus and the read inputs. The results were written to the serial monitor (b=bus r/w pin, r=read pin, d=data write pin). This worked very well and the spares were all working. It's by no means a complete test, but should identify major failures.

Testing channel 1
b=0, r=0
b=1, r=1
d=0, b=0, r=0
d=1, b=1, r=1
-----------
Testing channel 2
b=0, r=0
b=1, r=1
d=0, b=0, r=0
d=1, b=1, r=1
-----------
Testing channel 3
b=0, r=0
b=1, r=1
d=0, b=0, r=0
d=1, b=1, r=1
-----------
Testing channel 4
b=0, r=0
b=1, r=1
d=0, b=0, r=0
d=1, b=1, r=1
-----------
0 errors - PASS
===============================

I removed and socketed one of the chips and tested that. On this one, the second channel repeatedly failed to pull the bus low. This is the D3 line.

Testing channel 1
b=0, r=0
b=1, r=1
d=0, b=0, r=0
d=1, b=1, r=1
-----------
Testing channel 2
b=0, r=0
b=1, r=1
d=0, b=1 - ERROR, r=1 - ERROR
d=1, b=1, r=1
-----------
Testing channel 3
b=0, r=0
b=1, r=1
d=0, b=0, r=0
d=1, b=1, r=1
-----------
Testing channel 4
b=0, r=0
b=1, r=1
d=0, b=0, r=0
d=1, b=1, r=1
-----------
2 errors - FAIL
===============================

Excellent, I like to be able to point at something and say it's definitely faulty. I replaced that with one of the spares and tried it out. I started getting responses from the drive, but they weren't right. This is the result of DIRECTORY

Everything was on a separate line, and it wouldn't load anything. So I removed the other two chips and found another was faulty as well, failing on channel 4, that was D6. Once that was replaced, I started getting proper responses.

That's what it's meant to look like, all on the same line.

I found one bad chip on the 8032 (I think it was D2) and now that was working as well. The third Pet, another 8032 was showing 'device not present' errors, rather than 'file not found', so I suspect it will be the left hand MC3446N, the one that does the handshaking. I'll check that later.

With both machines now accessing the drive, I was able to test it further. Formatting a disk took a while, as this is uses 2.12MB disks (both sides as a single volume), compared to the 340K per side of the 1541.

These are 5.25" quad density disks, DS/4D, not very common, but I did find a box.
.

Loading back also worked fine with the simple 'Hello World' test, but further testing showed there were some problems with the 8250.

I did load some games (the monitor on the 8032 is playing up a bit, probably a dry joint on the video connector), but that was nothing to do with the disk drive. Some of the files didn't load, and at one stage the disk got corrupted. The 8250 needs further work, but that is only to be expected, after fixing the power supply issues, the rest is untested and their may be further problems (memory perhaps?).

Commodore IEEE-488 Disk Drives

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

I've been working on some Commodore PET disk drives recently. These differ from the Commodore 64 era drives in that they have a parallel interface, conforming to the IEEE-488 / GPIB standard. The later drives have a slower serial version of this on the 6 pin IEC connector.

I have a Commodore PET 8032 connecting to a Commodore 8250 dual disk drive. I haven't had much success here, and it's one of those situations where when it's all put together, it doesn't work. No response from the drive. I tried the standard LOAD "$",8, the DIRECTORY command and shift + run/stop.

I get just get device not present errors. So it could be the drive or the computer. The drive does do it's power on seek and the LED does go green, so the drive seem OK. The Pet is also otherwise OK.

I normally approach those sort of things with a divide and conquer approach and try to split the problem down each time, so is it the drive or the computer? Both started in poor condition, the PET's have been restored, but the 8250 is in progress, so it could be either. I don't have another drive to test, so lets try with a different PET. This is the 4032 I restored last year.

The 4032 gives different errors, and the drive seems to respond. The activity LED does light go red, but it still gives errors. It also response to ID=8, but not others.

So what next? Well since the 4032 got a response and the 8032 didn't, I guess there is a problem with the GPIB port on the 8032. I tried different 6522 / 6520s in the interface chip, but that didn't make any difference. There are three MC3446 buffers, but there aren't socketed and I don't have any spares to hand. I also didn't have another drive in any better condition to try, but I did remember reading about a way to convert a 1541 serial drive into a GPIB drive, similar to the 2031 LP.

The 2031 LP was basically a 1541 with a different board. It is possible to adapt the 1541 with a plug in board and a patched ROM. This was documented in a German C64 magazine in the 1980s. I'll go into more details at a later date.

The board I made plugs into the socket for the 6522 that handles I/O and bypasses the connections to the IEC ports. These are buffered by 75160 and 75161 chips and connect to the GPIB port. The upper ROM of the 1541 is modified. Here I've temporarily used a 24-28 pin adapter and a 2764 EPROM. I've used a GPIB connector on a ribbon cable, so that once it's sorted, I can desolder the two 6 pin DIN connectors and enlarge the holes on the case slightly to take the new connector. I have a drive which has had a bodged repair on the 7406 that buffers the IEC, so that will be the final target. For the moment I'm using a known working drive.

The modified 1541 powers up and spins the drive, more briefly than it used to, but otherwise looks ready to go. Unfortunately, I got no response from the 8032 and the light flashing, but no response on the 4032, exactly the same as with the 8250.

So either both drives are faulty, or both Pets, or something else. The cable is a bit of a bodge, using the extender cable from an 8032-SK, but seems to be fine. I will get around to making up a better one, but I think it's ok.I don't have much else that uses GPIB, various bits of test equipment, but nothing that I could use in this system.

Previously, I build a USB-IEC adapter to connect to serial drives from a PC. That was based on xum1541, and that does have the option to connect to GPIB drives. Rather than modify the previous one, I built a new USB to IEEE-4888 adapter.

I built that with the connector on the box, so it plugs directly into the connector on the back of the drive. Testing with the modified 1541 returned success, giving the model as 2031, which is what the 1541 has become.

Testing with CBMXfer, I did get a full directory listing, so there cannot be much wrong with the setup.

However, it was intermittent, it would work once then lock up. Going back to the command line CBMCtrl, I get various responses to DIR, but it's not consistent. Resetting the drive helps, but then fails again - not sure what's the problem here.

OK, so it's the drives then? I tried various options, another known working 1541 and a ROM/RAM board to rule out my EPROM adapter and the onboard RAM.

That made no difference. This was getting annoying. Nothing seemed to be working properly.

I thought I may as well try the 8250 as well, and rather unexpectedly, it worked, and continued to work.

I was able to format a disk and transfer some files back and forth using CBMXfer. So at last I have a working combination.

Going back to the PETs with the formatted and populated disk and the now known working drive still gave a fail. So both PETs and the modified 1541 are not working, but the USB - IEEE488 adapter and the 8250 are working, at least well enough to talk to each other. At least that's a start and with those working, I can get on with fixing the others.