New Hard Drives for Old Computers

After a certain age, computers start to show signs that they might need to be replaced or upgraded. After even more time, it starts getting hard to find parts to replace the failing components. And, as the sands slip through the hourglass, the standards used to design and build the computer start going obsolete. That’s the situation that [Drygol] found himself in when he was asked to build a SD-card hard drive for an Atari.

The 8-bit Atari in question was a fixture of home computing in the 80s. In fact, if you weren’t on the Commodore train, it’s likely that your computer of choice was an Atari. For the nostalgic among us, a new hard drive for these pieces of history is a great way to relive some of the past. Working off of information from the SIO2SD Wiki page, [Drygol] used the toner transfer method to build a PCB, 3D printed a case, and got to work on his decades-old computer.

Resurrecting old hardware is a great way to get into retrocomputing. Old protocols and standards are worth investigating because they’re from a time where programmers had to make every bit count, and there are some gems of genius hidden everywhere. Whether you’re reworking SIO from an old Atari, or building a disk emulator for an Apple ][, there are lots of options.

33 thoughts on “New Hard Drives for Old Computers

  1. I am/was trying to build something like this.

    But first, I had a Vic20 made by Commodore. I think it was before the C64 but I am not really sure where it fits in. It had less RAM and simpler graphics compared to the C64.

    After that I bought a Amstrad CPC6128 which was more popular where I live. I don’t remember seeing an Atari computer.

    Today, I have a working CPC6128 and that is what I was making storage for. It has tape interface but no drive and an internal 3 inch floppy that I swapped for a 3.5 inch. I has no SIO like the Commodore.

    There are floppy emulators but they are cumbersome so I wanted something that could plug into the CPC and also plug into a standard PC.

    I tried to make a Compact Flash card interface that presented to the CPU as 8 mapped IO ports on it’s internal bus.

    I chose Compact Flash because it has an IDE mode that suites 8 bit ports. Unfortunately, in this mode the CF needs Vih of 4.7 Volts and I was using a 3.3 CPLD with LVTTL so I added a voltage translator. Anyway it didn’t work so I am going to try a Disk on Module (DoM) as others have successfully used these. They are natively IDE and I assume they are TTL. I can get a USB to IDE bridge for the standard PC.

    The biggest problem is getting old 5Volt stuff to work with modern 3v3 chips. It works well in theory until you find that – even though there is 5.0Volts going into the unit, you’re only seeing 4.7Volts on the expansion port … so much for your calculations.

    Anyway, things took a turn and my PC died. I found a replacement main board that had a on-board floppy controller and I am currently using this setup. A USB floppy wont work on the PC with CPC disks as they’re not compatible so I will eventually have to solve the problem anyway. The disks are 40 track 9 sector single sided so I need an actual onboard FDC on the PC mainboard so that I can directly access the chips registers.

    Any I am still going to go the path of a simple interface unit with no CPU or anything like that. you know, like it’s made for the Amstard.

      1. If that satisfied my requirements then I wouldn’t be up to revision 2 building my own! My system will present on the CPU bus directly and not a FDD port.

        In the one you linked the files on the SD are propriety disk images something like an ISO that needs an application for adding deleting and moving files.

        What I am building will have full FAT32 / FAT32ex / exFAT support on both the PC and retro computer.

        There are also lots of other unacceptable (to me) limitations to a Floppy emulator like disk size.

        In any case, I already have a SD card interface working through the printer port of the retro computer and it useless unless I write some retrocode for it.

        1. Hi, The HXC floppy emulator has a direct mode, where you can read the sd card. Might be able to write but I have not checked/test myself. For DOS and Amiga there is a manager program that can be used to select a different image right from the retro computer.

          Building your own solution sounds more interesting.

          1. The floppy emulators don’t really offer me anything that I don’t have. The retro computer has been converted to 3.5 inch floppy and a I have a desktop PC that also has 3.5 inch floppy so I *can* transfer data / programs that way. At least until I get a *mold event* that wrecks the whole setup lol.

            It’s the long term storage and size limitations of the floppy that I want to get around. I considered putting a 2.5 inch IDE hard drive in the retro-computer as well and I may do this anyway. For me IDE looks like it has more options (HDD, CF card) and there is less code to write as the unit already supports the basics of disk data transfer in Cylinders/heads/Sectors (CHS).

            Adding SD is easy to do with the hardware but not so easy with the software and that is why SD like interfaces have there own micro-controller.

      2. Sure, the HxC’s work well (and we also use the HxC firmware for the cheap Gotek devices you can get on Ebay), but it has limitations.

        The Amstrad CPC’s having a bit of a hardware renaissance at the moment; I’ve got six new add-on cards for it in the past couple of years, and another few are just coming out. That includes SD card, USB drive and IDE drive interfaces, and disk image emulation as well.

    1. If you men something that plugs into an old 8086 computer then it’s out there and uses a Compact Flash card because compact flash has an 8 bit IDE mode. there are also version 4 boards on ebay at times.

      I am not sure what you mean by original IBM PC. There was an IBM PC Jr. that uses a 8088 CPU but I am not sure is the bus was ISA, it would have been 8 bit in any case. Then there was the more commonly known IBM XT that was 8 bit, had ISA bus and used the 8086 and was the birth of IDE. The 8086 architecture is what became x86 or the ‘normal’ desktop PC today. After that was the IBM AT. It was 16 bit, had 16 bit EISA bus and a 80286 CPU.

      1. No, the PC XT was powered by an 8088. The 8088 was an 8086 with an 8 bit data bus, but was 16 bit internally. ISA cards were therefore 8 bit compatible, with extensions for the 16 bit bus of the 80286 when it was added to the range.

        1. I did a quick wikipedia and it says the original PC and the PCJr *AND* the XT all used an 8088 and I know for a fact that that is wrong. My memory tells me the PCJr was 8088, the XT was 8086 and the other I have never herd of.

          You say – ISA cards were therefore 8 bit compatible, with extensions for the 16 bit bus of the 80286 when it was added to the range.

          The 80286 was the AT and had a 16 bit EISA bus instead of the 8 bit ISA bus??

          I distinctly remember changing CPUs when I repaired these. Both the 8086 and 8088 were 40 pin dip. The 80286 was PLCC or Quadpack. I worked on XT’s and AT’s onwards. On the XT the most common (non RAM) fault was the fast parity generator. By the time of the AT we didn’t bother changing chips except for RAM / CPU.

          1. I fear your memory is not correct, and Wikipedia is correct. The 8086 was used in the systems coming out of Austin, TX like DisplayWriter, but Boca wanted an 8-bit data bus to cut down the costs of adapters. If you look at the schematics of the PC and PC/XT, you will find that they are a close copy of the ‘minimum mode’ example in the Intel data book on the 8086/8088.

            Interestingly, there was a camp of people who desperately wanted to adopt the 68000, but Motorola’s 68008 8-bit (40-pin) variant was three months too late, and the 68000 was in a 64-pin ceramic package that was too expensive.

          2. Both were 40 pin packages, but they required an external demultiplexor as the address and data pins were shared. The 8088 only shared A0-A7. Intel have a long history of requiring external support for their CPUs (see the 8080 for example).
            The PC/AT saw the EISA extension to cards. The PC and PC/XT were both 8 bit data only, though some clones used the full 8086.

          3. I’m with other Rob on this one. I had a PCJr and and XT when I first got into computers (and I spent *a lot* of time inside them), and I can confirm that the PCJr had an 8088 and the XT had an 8086. Of course, it’s possible that the prior owner had swapped out the XT mobo (or just the CPU itself) for one with an 8086 (I wouldn’t have been able to tell back then), but that seems quite unlikely.

          4. Any XT with an 8086 has had the motherboard swapped. The PC and XT were both 8088 machines.
            Also, the AT used a 16 bit extension to ISA, EISA was something else entirely.

          5. [Rob] and [Sweeney] nailed it for me.

            The systems I was working on were mostly clones and were obviously different. From memory the most common XT clone was a CCS, by the time of AT, everyone was cloning.

  2. Man, that case is ugly. And that LCD hole is stupidly huge. It should be as small as actual display, so the metal frame is hidden, thus adding some measure of protection to electronics inside. Instead we have hole big enough to fly Boeing through it. This is just bad design.
    This rant would sound so much better with [Dave’s Jones] voice…

    1. Build a better one or shut it. Holly hell are you ever an arrogant one. Even if his reasoning is nothing other than skimping on filament or he likes it that way, it’s probably not meant for mass production.

    1. ??? I don’t recall this to be true (but I don’t have numbers to back my claims). in the US, for the home user it was Apple (mostly schools), Commodore, Atari and then everyone else. This was before the IBM PC and it’s clones.

      1. Learned something new (old?) ;-)

        I didn’t use the CoCo but I did love OS9 (not the Mac stuff). I wasn’t as impressed with OS-68K. I have a couple of St2900 (6809 boards) that used the CoCo OS9 Level I (think) software and a few drivers to get it to boot (ss first sector and dd the rest, I think). Someday I might try to get ti to boot.

        1. I think there was a split, lots of families bought the CoCo for the games. I never saw a lot of CoCos at garage or rummage sales, but when I did, it was just the CoCo, no accessories. For a while, there were three or four magazines for the computer, and the split was there, endless BASIC listings that would take forever to type in, but did very little.

          Then in the back there were the articles for the more serious users, of varying levels. If you had a floppy drive, you were up there, if you ran OS-9 you were further up there, etc.

          I don’t know the sales figures, but it’s probably apples and oranges. The Apple II sold well, but it was expensive, and probably a decent percentage were to small businesses (that market where people bought the computer to run VisiCalc). The CoCo was relatively cheap, and sold “everywhere”, but probably not so much to the more “technical” user. On the other hand, it was the cheapest computer for running OS-9, which did bring in some users. I bought my first one in 1984 for that, actually buying OS-9 a couple of days before I bought the floppy drive. Though, it got better when Radio Shack released the CoCo III, a better keyboard, 80×24 screen, and more ram and a pager to run the better version of OS-9. I really would have liked to keep using OS-9 with a 68000, but the hardware was more expensive, and without Radio Shack interest, the 68000 version of OS-9 was more expensive.


  3. There’s also PBI/ECI bus IDE (which support CF cards) and SCSI controllers available for the Atari 600/800XL and 130XE. They integrate nicely with Atari ROM OS as well. As a game machine, the C64 was neat, as a computer the Atari machines kicked it’s ass. No contest there.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.