Retro

While cleaning up the cellar, I found my Amiga 500 and also a GVP Impact Series II SCSI host adapter. Inside, there was a Fujitsu M2611SA harddisk. After about 25 years, I had totally forgotten about it, and I wondered what was stored on it. So let me take you on the adventure trip of how to salvage old Amiga harddisks on modern Linux machines.

The Amiga ecosystem has always been very SCSI friendly. Commodore broke this tradition only with the final AGA models, where they switched to the IDE bus to reduce costs. The Amiga community never approved this change, and many accelerator cards that were sold for these machines also came with a SCSI host adapter. The SCSI bus was a lot faster than the IDE bus. Also a single ribbon cable could connect up to seven SCSI devices, where the IDE bus only permitted two devices.

Today this SCSI affinity turns out to be a problem though. SCSI was never a topic on consumer PCs, so there are no SCSI-to-USB adapters on the market (I wish they were), and SCSI cards for the PCIe bus are very expensive. I'm still having an Adaptec SCSI card in my cupboard that I bought many years ago, but it is for the old-style PCI bus. Luckily there are PCI-to-PCIe adapters available on the market, so I could reuse this old card in my computer. The card stack looks adventurous, but it will do for a few hours of operation to backup the data.

The big question is: Can a modern Linux machine even read Amiga formatted harddisks?

Mounting Amiga Harddisks

Yes, it can. It seems that there are a lot of Amiga fans among the Linux kernel developers. The Amiga uses a different partition table scheme than PCs, but if you're lucky, your Linux will still detect the Amiga partitions and offer them as e.g. /dev/sdg1. Then all you need to do is to mount the partition via mount.

It didn't work on Fedora though, so I had to do some more typing. First I had to find out the offsets of the individual partitions. GNU Parted can be used for that, as it is able to decode Amiga partition tables:

# parted /dev/sdg
GNU Parted 3.3
Using /dev/sdg
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) u
Unit?  [compact]? b
(parted) p
Model: FUJITSU M2611S (scsi)
Disk /dev/sdg: 45078528B
Sector size (logical/physical): 512B/512B
Partition Table: amiga
Disk Flags:

Number  Start   End        Size       File system  Name  Flags
 1      52224B  45078015B  45025792B  affs1        DH0   boot

(parted) q

So there is only one partition on the HD. It starts at offset 52224 and is Amiga FFS formatted. Luckily most Linux distributions are able to mount this file system out of the box. The start offset is needed to mount the partition. I also mount it read-only to make sure that I won't accidentally change or delete my precious old data.

mount -o ro,offset=52224 -t affs /dev/sdg /mnt/

Et voilà:

# ll /mnt/
drwx------. 1 root root    0 Apr 16  1997 C
drwx------. 1 root root    0 Jun 11  1994 Devs
-rw-------. 1 root root 1233 Apr 16  1997 Devs.info
drwx------. 1 root root    0 Apr 16  1997 Fonts
drwx------. 1 root root    0 Apr 16  1997 L
drwx------. 1 root root    0 Apr 16  1997 Libs
drwx------. 1 root root    0 Feb 27  1992 Locale
drwx------. 1 root root    0 Apr 16  1997 Prefs
-rw-------. 1 root root 1238 Apr 16  1997 Prefs.info
drwx------. 1 root root    0 Apr 16  1997 S
drwx------. 1 root root    0 Apr 16  1997 Storage
-rw-------. 1 root root 1233 Apr 16  1997 Storage.info
drwx------. 1 root root    0 Jan  4  1992 System
-rw-------. 1 root root 1233 Apr 16  1997 System.info
drwx------. 1 root root    0 Feb 27  1992 Tools
-rw-------. 1 root root 1233 Apr 16  1997 Tools.info
drwx------. 1 root root    0 Jan  4  1992 Trashcan
-rw-------. 1 root root 1588 Apr 16  1997 Trashcan.info
drwx------. 1 root root    0 Feb  3  1992 Utilities
-rw-------. 1 root root 1233 Apr 16  1997 Utilities.info
drwx------. 1 root root    0 Apr 16  1997 WBStartup
-rw-------. 1 root root 1233 Apr 16  1997 WBStartup.info

Disk Dumps

As old harddisks are quite noisy, it might be a good idea to dump the entire content first, and salvage the partitions later. dd is the classic tool for creating a dump:

dd if=/dev/sdg of=amiga-hd.dd bs=512 status=progress

Later a loop device will simulate a real harddisk device:

losetup /dev/loop1 amiga-hd.dd

/dev/loop1 can now be used for parted and for mount.

To remove the loop device again:

losetup -d /dev/loop1

Smart File System

Back in the Amiga days, the Smart File System was very popular as an alternative to the original Fast File System. It was freeware, it was a lot faster than FFS, and it even had a stateless defragmentation that ran in the background.

The Linux kernel does not support SFS out of the box. However, Marek Szyprowski implemented a kernel module in 2003, which (sadly) never left the experimental stage and thus never found its way into the official set of supported Linux file systems.

To use it, you first need to set up a Linux with a 2.6.27 kernel, for example Fedora 10. After that, download the kernel patch and compile it to a kernel module. If you managed that, you can also mount Amiga SFS partitions. I was able to recover all files from an SFS partition that way, though it wasn't much fun.

PS: Sadly the harddisk I've found didn't contain forgotten source codes or other secrets. It just had a standard Amiga Workbench on it, and a copy of the game Scorched Tanks.

In the first part, we have replaced the old Li-Po battery by a new one. In this part, we will replace the mechanical hard disk by a modern (and much larger) MicroSD card. Both parts are independent, this is, you could also replace the HDD but keep the old battery.

First of all, you need to install Rockbox on your player. This is an alternate firmware that will not only make your iRiver experience more enjoyable, but will also support larger hard disk sizes. The installation procedure is out of scope of this article, but Rockbox is providing a great installer tool that does most of the work for you.

You must install Rockbox before replacing the harddisk. The reason is that the original iRiver firmware won't boot from larger harddisks, but you need a running player to install a patched Rockbox bootloader via firmware update.

Your shopping list:

• Toshiba 50-pin to CF card adapter – I use an HXSP-09CF69 adapter. I have tried an Adaptare 48012 adapater first, but always got ATA errors with that one. The adapter must be set to "Master" mode, usually by a switch or a jumper.
• CF card to MicroSD card adapter – I use a DeLock adapter, but any other brand should work as well. You can also just use a CF memory card, but the combination of MicroSD cards and CF card adapaters is cheaper than CF cards of equal size.
• MicroSD card – I use a 128 GB SanDisk Ultra MicroSDXC card, but any other brand should work as well. The card speed is not really a factor here. I couldn't find a maximum size that is supported by Rockbox, so maybe even larger cards will work.

As there are a lot of different adapters and MicroSD cards on the market, there is no guarantee that your combination will work. Remember that you use parts that have been totally utopian back in 2003. Also be warned that your hardware can be damaged by this modification. You do it at your own risk.

Before you move on, make sure that Rockbox is properly installed and started. Then connect your player to your computer via USB, and backup the .rockbox directory, and any other stuff on the old harddisk that you want to keep.

Also, please read the entire article first, before you start with the modification.

Prepare the MicroSD card on your PC. It must be FAT32 formatted and should be named like your player model (e.g. IHP-120). Copy the .rockbox directory from your backup to the MicroSD card. And while you're at it, use the chance and copy your music collection to the card. The access speed will be much slower once the card is in your player.

Now turn off your player, and open it again (as described in part 1). You only need to remove the back cover this time. No more disassembling is necessary.

Remove the harddisk by gently lifting it and pulling it out of the connector. Now try to insert the 50-pin adapter. For many adapters, a plastic nose on the connector will keep you from inserting it, so you may need to remove protruding parts of the adapter with a file.

It is normal that the connector has more holes than the header has pins. Just make sure that the position marked as "PIN 1" is properly aligned with the first pin of the header. This is what it looks like when the adapter and the CF card is correctly mounted.

The next step is important. The adapter might have a jumper for mode selection. If it sticks out, it may punctuate the battery when the casing is closed later, so bend it away (like in the photo) or just unsolder it and replace it with a wire bridge.

Now make sure that the CF card stays in place and won't touch the PCB even when the player is carried around. You can use some isolating tape, or a silicone mat cut to size. I constructed a small 3D printed piece that fills the space and keeps the CF card from loosening. You can put back the original silicone HDD frame on top of that, to keep the construction from vibrating or touching the battery.

It is a good idea to do a short test drive of your modified player now. It should boot up and start Rockbox. In the Rockbox file manager, you should see all the files on your MicroSD card.

You can close your player now. Be careful and don't use force if the back cover cannot be closed, but locate and remove the obstacle. Remember that the Li-Po battery on the back cover must not be damaged or punctuated.

Enjoy your new retro mp3 player!

Troubleshooting

If you should get ATA or "check HDD" errors, it can have a lot of different causes:

• Make sure that your MicroSD card has a single primary partition, which must be FAT32 formatted. Other file systems (e.g. FAT16, NTFS) are not supported. Try a different formatter tool.
• Check all the connections. Is the adapter properly aligned and connected to the header? Is it switched to "Master" mode? Is a header pin bent or broken? (A few pins may be a bit longer or shorter than the other pins though, that's normal.)
• Remove the adapter and insert the original HDD. If your player still shows an error, the daugherboard may have been dislocated. Gently press it to the main board and try again.
• Your combination of adapters and MicroSD card brands may be incompatible. Try to boot from a real CF memory card. Try other adapter or MicroSD card brands.

If you happen to have an iHP with a broken original hard disk, you can start with the replacement right away, but use a FAT32 formatted 16 GB or 32 GB MicroSD card first. The original firmware should start in this configuration, and allow you to install the Rockbox firmware, but this is untested. After the Rockbox firmware has been installed, you can use larger MicroSD cards.

Final words…

• You do this modification at your own risk. It might not work, damage your hardware, and turn out to be an utter waste of money.
• I cannot help you if your modification won't boot or won't run stable. I have already said all I know about it in this article. Maybe you can find help in the Rockbox forum.
• I cannot print the 3D printed part for you. The stl file is available for free and can be printed by commercial print services.

In a time before smartphones, people used so called "digital music players" for portable music. One of them was the iRiver iHP-100 series, which came to the market in October 2003. It had up to 40 GB of storage, which was really a lot these days. It had a playback time of up to 16 hours. It had a remote control with a separate display. And it is the only pocket-size player I know that is also equipped with an optical line-in and line-out.

I got my player in 2004, and I used it for many years, until the hard disk started to show first signs of failing. Then I stored it away to save it for "special occasions" that never came. Many years later, I did not dare to charge it again, as I distrust over-aged Li-Po batteries that have been discharged for a long time. So my player became a Sleeping Beauty, waiting for the day it would be rediscovered and properly restored. The day was now.

In this first part, I will replace the original battery. In a second part, I will replace the 20 GB hard disk with a modern 128 GB MicroSD card, which is a lot more than the size of my entire music collection. After more than 16 years, it will be a modern portable music player again. (Well, sort of… I know it's still inferior to a smartphone.)

Before we start: Li-Po batteries are delicate. A damaged battery can cause severe damage to your home and your health. Please be very careful. If you're not confident enough for the operation, please ask someone for help.

The player is opened by removing the eight screws from the top and the bottom cap with a T6 screwdriver. The caps are glued in place, but can be pulled off with a bit of force. After that, the back cover can just be lifted off. The attached battery cable is very short, so be careful when lifting.

This is a photo of the inside. To the left is the battery pack that we are going to replace. To the right, we see the 1.8" HDD. Yes, the iHP uses an actual hard disk, with spinning platters and arms and all. In part 2, it will be replaced by a MicroSD card.

The battery connector is on the other side of the PCB, so we have to disassemble more. First we remove the HDD, it just needs to be gently lifted and then pulled out of the connector. There is a screw on each of the two side panels, they need to be removed as well. Then we remove all visible screws on the PCB.

The display frame is glued to the front cover, so we need to use a bit of force to remove the PCB. Be careful, the display is very sensitive to scratches. Also we don't want to have hairs and dust caught between the display and the front cover when we reassemble the device, so make sure you work in a clean and dust-free room.

Now we can disconnect the battery from the main PCB. Sadly, the power connector is in the way, so we need to twiddle with the connector and use a bit of force to get it removed. If you use a screwdriver, take care not to slip off and damage the PCB. Also, take care not short circuit the battery cable.

In the next step, we can remove the old battery pack. It is glued to the back cover, so we need a lever tool (e.g. a plastic opening tool) and some patience to gently remove it.

Be very careful when you remove the old battery pack. Do not use blades or pointy tools, and do not use force. The battery pack may burn if bent, damaged, or punctured.

You got the old battery removed now? Please don't just throw it away, but make sure it is properly recycled.

Before we insert the new battery, we should have a look at the cable first. On my replacement, the cable was considerably longer than the original one, so I decided to align it with the other corner of the back cover. If your cable is shorter, or if you are not sure, use the same corner as the original battery. In any case make sure that the cable is at the bottom edge of the back cover. If there is some of the glue tape left, it will firmly hold the new battery in its place.

If you think it was difficult to disconnect the old battery, you will find out that it is even more difficult to connect the new one. Check that the polarity of the connector is correct, the black wire must be closer to the USB connector than the red wire. Take care not to cut or break the wires while inserting the connector. If there is absolutely no way to push the connector into the socket, you need to remove the USB daughterboard. It can be unplugged after unsoldering the wires on its four corners.

I was lucky. After a few attempts and some frustration, I finally got the new battery connected.

When reassembling, make sure the battery cable is correctly routed like in the next photo. It must not be pinched anywhere. Now the PCB can be placed back onto the top cover again.

This is the right moment to check if there are visible dust particles or hairs caught between the display and the front cover. If so, use a photo lens brush to gently brush them away. Do not use a cloth, as it may cause tiny scratches.

Now close the bottom cover for a test. The battery cable should fit properly and should be tension-free.

After that, you can reassemble the device in the opposite order. Congratulations, you have given a new life to this amazing piece of hardware!

In the next part, we will replace the HDD with a MicroSD card. It will not just conserve some battery power, make your player faster and keep it cooler, but also greatly extend hard disk space for your music.

In the first part I showed how the Sinclair ZX Spectrum stored data on tape. This second part explains what is stored, and what causes a tape loading error.

The ZX Spectrum BASIC offers a SAVE command for saving all kind of data. It can be used to save a BASIC program, variable arrays, but also arbitrary parts of memory. These files are always saved in two separate blocks. The first block is called header. It contains the file name, data type, and other meta information. The second block follows about a second later and contains the data itself.

The internal structure of each block is identical. The first byte distinguishes between header ($00) and data blocks ($FF). The final byte is a parity checksum. Everything between these two bytes is the payload.

A header block always contains a payload of 17 bytes. The first byte identifies the file type, followed by the file name (10 characters), followed by the length of the data block, and closed by two optional parameters that have different meanings depending on the file type. The length and the two parameters consume two bytes each, with the lower byte coming first because the Z80 CPU is little endian.

This is an example header block of a screenshot:

A screenshot is actually just a memory dump that starts at address $4000 (which is the starting address of the screen buffer) and is exactly 6912 bytes long (the ZX Spectrum has a resolution of 256×192 monochrome pixels plus 32×24 bytes color attributes, giving a screen buffer size of 6912 bytes).

For other file types, the two optional parameters have different meanings. For example, a BASIC program file stores the line number to start at after loading.

The final byte is the parity. It is used for error detection, and computed just by XOR-ing all the bytes that have been read. The result must be $00, otherwise a "R Tape loading error" is reported.

This kind of error detection is rather weak. Due to the nature of the XOR operation, two wrongs give a right. This means that when the block contains an even number of bad bits at the same position, they will be undetected. It is also not possible to correct reading errors, as the XOR operation only allows to identify the position of the bad bit, but not the actual byte that contained the error. More sophisticated error correction algorithms would have slowed down the loading process, though.

The parity is checked as a final step, after all the bytes have been read from the block on tape. For that reason, the loader can only decide at the end of the recording whether the loading was successful or not.

But then, why does the tape loading error sometimes appear while the block is still loading? Well, in the first part I have explained that the loading routine just reads an unknown number of bytes. It ends when waiting for a pulse change took too long. Now, if there is an audio gap on tape, the signal seems to end just in the middle of the block. It is then very likely that the parity checksum is wrong because there are still bytes missing.

Some simple copy protections made use of the way the Spectrum loads data from tape. A very common way were “headerless” files, where the header block was left out and only the data block was recorded on tape. The BASIC LOAD command was unable to read those files because of the missing header.

In the early time of home computers, at the beginning of the 1980's, hard disks and even floppy disks were too expensive for home use. The cheapest way for storing large amounts of data was the cassette tape. Cassettes and tape recorders were affordable and available in almost any household.

In this blog article, I'm going to explain how the Sinclair ZX Spectrum stored programs on cassette tapes. Other home computers of that time, like the Commodore 64 or Amstrad CPC, worked in a similar fashion.

Cassette tapes were designed to store audio signals like voice or music, so the inventors of the home computers had to find a way to convert data to audio signals. The easiest way is to serialize the data to a bit stream of 1's and 0's, and generate a long rectangular wave cycle for "1" and a short rectangular wave cycle for "0". This is what the ZX Spectrum actually does!

A short wave cycle is generated by giving power to the audio output for 855 so called T-states, and then turning off the power for another 855 T-states. A "T-state" is the time of a single clock pulse of the Z80-A CPU. As the CPU of a classic ZX Spectrum is clocked with 3.5 MHz, a T-state has a duration of 286 ns. The duration of a short wave cycle is thus 489 µs, giving an audio frequency of about 2,045 Hz. The long wave cycle is just twice as long.

Due to all kind of filters in the analog audio path, the rectangular signal is smoothed to a sinusoidal signal when played back. A Schmitt trigger inside the ZX Spectrum's hardware converts the audio signal back to a rectangular shape. Since the audio signal can have different amplitudes or could even be inverted, the hardware only cares for signal edges, not for levels. All that the loader routine now has to do is to measure the duration of the pulses, regenerate the bit stream, and put the bytes back together.

If you think that things cannot be that easy, you are right. 😄 The most difficult part for the loader is to find the start of the bit stream. If it is off by only one cycle (or even just a pulse), all the bytes are shifted by one bit, and the result is useless. All kind of noise on the tape makes it impossible to just wait for the signal to start, though.

For this reason, the recording starts with a leader signal, followed by a sync wave cycle, followed by the bit stream itself. The leader signal is just a continuous wave with a pulse length of 2,168 T-states, giving an 806 Hz tone that is displayed by red and cyan border colors on the TV. The sync wave cycle is a pulse of 667 T-States "on", followed by 735 T-states "off". After that, the actual data stream begins, which is displayed in blue and yellow border colors. When the last bit was transmitted, the data stream just ends.

So when the ZX Spectrum loads a file from tape, it first waits for the 806 Hz leader signal. If it was detected for at least 317 ms, it waits for the sync pulses, then it starts reading the bit sequence until there is a timeout while waiting for the next pulse.

It is a very simple way to store data on tape. And still, it is surprisingly reliable. After 30 years, I could recover almost all files from my old cassette tapes. Some of them were of the cheapest brands I could get my hands on back in 1987.

The only disadvantage is that this method is very slow. With 489 µs for a "0" and 978 µs for a "1", saving just 48 KBytes of data can take up to 6 minutes, giving an average bit rate of 1,363 bps (yes, bits per second). If we were to save a single 3 MBytes mp3 file that way, it would take almost 5 hours (and 5 cassettes with 60 minutes recording time each).

Some commercial games used speed loaders and copy protections. Speed loaders just reduced the number of T-states for the pulses, which increased the bit rate. Some copy protections used a "clicking" leader tone, where the leader signal was interrupted before the minimal detection time of 317 ms was reached. The original loader routine could not synchronize to these kind of signals, so it was impossible to read those files into copy programs. Those protection measures could still be circumvented by copying directly from tape to tape, but this only worked a few times due to increasing audio noise.

In the next article, I will take a deeper look at the bit stream contents, and I will also explain where the dreaded "R Tape loading error" comes from.