Toshiba FlashAir enabled Commodore Amiga CD32

6 min readOct 18, 2019

--

Many years ago, my brother gave me a Commodore Amiga CD32 + SX-1 Expansion. I never got around doing anything with it, but recently, I decided to get it recapped and see if I could do something hacky with it.

Here are some pictures of the hardware

Connecting the SX-1 to the backside expansion port of the Amiga CD32 makes it possible to attach RGB monitor, AT-101 keyboard, modem, etc. - and also connect an internal IDE hard disk drive (HDD).

At present time (2019), a lot of options are available for connecting other things than actual hard disk drives to IDE-controllers. You can buy a SD-Card adaptor with IDE-interface and use this together with a SD-Card you provisioned with lots of programs, and have your Amiga use this as a HDD, even boot from it.

I bought a 2.5" 44-pins interface to SD-Card adaptor which looks like this

I had a 4GB SD-Card available, so I used AmiTools to prepare the card on my PC, and I got it to boot on the Amiga.

I used this card, which I refer to as Amiga SD-Card.

Booting the Amiga from a provisioned SD-Card feels über cool, but I often want to run new demos and games on it, which is cumbersome because the Amiga don’t have any builtin network connection (if you ignore serial and parallel interfaces). I used floppy disc back in the 80s and 90s, but nowadays floppies are not easy to buy, and the floppy disk drives I have are very unstable, so every time I wanted to move new files to the Amiga, I ended up doing

Open SX-1 case
Pop SD-Card out of the SD-Adaptor
Plug SD-Card into the PC
Copy files to SD-Card with AmiTools
Pull SD-Card out of the PC
Plug SD-Card back in SD-Adaptor
Close SX-1 case

While thinking about how to simplify this, I became aware of SD-Cards with built-in WiFi.

What if I could use such a card to boot the Amiga? - and connect directly to it from a PC? This would make it super simple to move data to/from the Amiga.

Toshiba seems to offer the best product, so I bought one like this

https://www.toshiba-memory.com/products/toshiba-wireless-sd-cards-flashair-w-04/

To get this to work, we need to know that the Amiga (Kickstart) looks for partition information (RDB-structure) within the first 16 blocks of the boot device. AmiTools write a RDB-structure to the first block, which get in conflict with FlashAirs requirements to find a MBR-structure there. To make this work we must move the RDB-structures one sector forward.
To make it easy to merge the two SD-Cards, we will place the FAT-partition after the Amiga SD-Card (4GB).

Before changing the FlashAir SD-Card, let’s make a backup

Backup the FlashAir SD-Card (directories and files) to local PC HDD. The card was FAT32 formatted (de-facto), but it also works, when being FAT16 formatted.

With a backup, let’s repartition and erase the FlashAir SD-Card.

After repartition and FAT16 formatting, Block 1 (512 bytes) on the FlashAir SD-CARD now has these values

I copied the FlashAir backup directories back to the FlashAir SD-Card to verify it still works.

Executing **FlashAirTool** is one method that can be used to verify FlashAir SD-Card is accessible and configurable. On my PC it’s attached on /dev/disk2 and mounted as /Volumes/FAT

Now the FlashAir SD-Card is ready to be merged with the Amiga SD-Card.

With AmiTools, I chose to create two partitions (HD0 & HD1) on the Amiga SD-CARD, and AmiTools wrote this the RDB structure into the first sector.

Offset 28/1c (00 00 00 01) is a pointer to PartitionList, and because 16/10 (00 00 02 00) define block size to be 512/200 the offset is 00 00 00 01 * 00 00 02 00 = 512/200

And this was written into the next two sectors, which contain the PartitionList

HD0 partition. Offset 16/10 is a pointer to the next PartionBlock. In this case, HD1.

HD1 partition. Offset 16/10 is a pointer to the next PartionBlock. In this case, ff ff ff ff which is a constant that define this is the last one.

To get the 4GB Amiga SD-Card into the First 4GB of the FlashAir SD-Card, we need to move the first three blocks one block forward, to make room for the MBR-block.

Let’s read-out the 4GB Amiga SD-Card to a file, so it can be edited. I used HexFiend

The result of editing the 4GB Amiga SD-Card file

A few things needed patching. The RDB structure has a pointer to the PartitionList and the first PartitionBlock (HD0) has a pointer to HD1.
For that reason, Offset 540/21c has been incremented from 00 00 00 01 to
00 00 00 02 and 1040/410 has been incremented from 00 00 00 02 to
00 00 00 03.

Commodore used a classic checksum method, but with a twist, that I have not seen anywhere. In random source code (found on the internet), it is referred to as Classic Rootblock Algorithm and it is calculated like this

#define Short(p) ((p)[0]<<8 | (p)[1])
#define Long(p) (Short(p)<<16 | Short(p+2))

unsigned long newsum;
unsigned char buf[BSIZE];	/* contains rootblock */
int i;

memset(buf+20,0,4);		/* clear old checksum */
newsum=0L;
for(i=0; i<(BSIZE/4); i++)
	newsum+=Long(buf+i*4);
newsum=-newsum;			/* negation */

If you know what extra security or optimization we get from negating the sum, please share 🤔

Because we have changed data in two blocks, we need to update their checksum, which is why offset 520/208 is decremented from 40 4b 98 46 f6 to 40 4b 98 46 f5 and 1032/408 is decremented from 40 e7 29 3a c0 to
40 e7 29 3a bf

After patching the Amiga SD-Card file, we can merge it with the FlashAir SD Card file, using the Data modification part of dd (conv=notrunc)