Setting up the SDBox V2 on an Amiga A500

Notes on getting an SDBox V2 working on an A500. The mountfile that ships with the SDBox drivers works unmodified — what actually matters is how the card is partitioned and formatted.

What you need

• SDBox V2 on the parallel port (jbilander/SDBox-v2 — the V2 is mainly a hardware revision; the mountfile comes from the original SDBox repo).I bought mine from AmigaStore.eu
• spisd.device from the amiga-par-to-spi-adapter releases
• fat95 3.18 from Aminet
• A microSD card of appropriate size — see the formatting section below, it matters more than you’d think

My machine is an A500 with 8MB RAM. I transferred the driver files across on an ADF image packed with xdftool.

Installation

Three files, three places:

• fat95 → L:
• spisd.device → DEVS:
• SD0 → DEVS:DOSDrivers/

The upstream README offers a choice for the SD0 mountfile: DEVS: if you want to mount on demand by double-clicking its icon, or DEVS:DOSDrivers/ for an automatic mount at boot. I use DOSDrivers.

To mount from a shell:

Mount SD0:

Note that Mount returning silently doesn’t mean the card is ready — it means the DOS entry has been created. fat95 doesn’t load and spisd.device doesn’t touch the card until something accesses the volume, so SD0: won’t appear in info yet. Run dir SD0: and you should see the SDBox’s activity LED start flashing.

The mountfile

This is the stock SD0 from the amiga/ folder of the SDBox repo, unmodified. It’s what I use and it needs no changes:

FileSystem     = l:fat95
Device         = spisd.device
Unit           = 0
Flags          = 0
LowCyl         = 0
HighCyl        = 0
Surfaces       = 1
BlocksPerTrack = 1
BlockSize      = 512
Reserved       = 0
Buffers        = 20
BufMemType     = 1
BootPri        = 0
StackSize      = 4096
Priority       = 5
GlobVec        = -1
DosType        = 0x46415401

A few notes on it:

• DosType = 0x46415401 is required. That value is FAT\1 in ASCII and it’s what ties the mount to the fat95 handler. It looks like boilerplate but the mount won’t work without it.
• LowCyl and HighCyl at 0 hand the whole device to fat95, which reads the partition table and boot sector to work out FAT type, cluster size and geometry for itself. That’s why the same file works for any card you put in.
• No #? terminator. That belongs to named entries inside a mountlist file used with Mount SD0: FROM <file>. A file in DEVS:DOSDrivers/ takes its device name from the filename, so it needs no header and no terminator.
• Don’t add a Control line. The fat95 readme documents Control = "-D" to stop last-accessed dates being written, which is appealing on flash. Adding it stopped the volume mounting on my setup. Removing it fixes that, but it’s not a drop-in.
• Raising Buffers doesn’t help the mount. The value is a count of 512-byte buffers, so 200 is about 100KB — nothing on an 8MB machine, but it made no perceptible difference. Nothing is cached when the initial scan starts, so there’s nothing for the buffers to do.

Card formatting: this is what matters

Use FAT32 with 4K clusters on a 1GB partition. Everything below is why.

FAT32, not FAT16

fat95’s feature list claims FAT12, FAT16 and FAT32 support with format-type autosense, so I expected FAT16 to be fine. It wasn’t. One 1GB card, single partition, in the slot from a cold boot:

• FAT16 (16K clusters — Windows offers nothing smaller at that capacity): Not a DOS disk in SD0:
• FAT32, 4K clusters, same card, same slot: mounts and reads perfectly

Two things changed together there and I can’t separate them: FAT16 tops out at 65,525 clusters, so a 1GB partition is forced to 16K allocation units — that’s arithmetic, not a limitation of the formatting dialog. So the failing card was FAT16 and 16K-clustered. A 256MB FAT16 partition would get 4K clusters and would settle the question; I haven’t tried it.

Either way: if a card won’t mount, reformat it FAT32 before you touch anything else.

Partition small, clusters not too small

The first access after mounting triggers a scan of the file allocation table, and this is where the slow link shows. Two cards, both FAT32, same machine, same mountfile:

Partition	Cluster size	Approx. FAT entries	First dir SD0:
4GB (on a 32GB card)	1K	~4,000,000	over two minutes
1GB	4K	~250,000	a few seconds

The cost tracks the number of FAT entries, which is capacity divided by cluster size — not partition size alone. The 4GB card had four times the capacity and a quarter of the cluster size, so roughly sixteen times the entries to read over a bit-banged, half-duplex SPI link with no DMA. A 4GB partition at 4K clusters would land somewhere in between; I haven’t measured one.

The slow mount isn’t a one-off cost either. On the 4GB/1K card Workbench stayed sluggish in ordinary use, locking up for long stretches whenever it touched the volume. The 1GB/4K card is comfortable — subjectively, file access feels roughly like a floppy drive, maybe slightly quicker. Nobody will mistake it for a hard disk, but it’s perfectly pleasant for moving files about.

Windows won’t always offer FAT32 in the standard format dialog. From an admin prompt:

format X: /FS:FAT32 /A:4096

A note on the documented 4GB limit

The SDBox documentation says to use a FAT or FAT32 card with a maximum 4GB partition, and the V2 vendor’s notes stress that the card should carry only a FAT partition, warning that not every brand and type of microSD behaves. That 4GB figure comes from fat95 rather than the hardware — its feature list gives 4GB as the ceiling for FAT16 specifically. In practice the scan times make it moot: you can run a 4GB partition, you just won’t enjoy it.

Hot-swapping

Cards can be changed while the machine is running. Eject one, insert another, and fat95 rescans automatically — the new volume comes up with the correct contents, no reboot, no remount. Works in both directions.

One caveat worth knowing. If you insert a card fat95 can’t read, the handler is left in a state that a subsequent good card won’t rescue — you’ll get Not a DOS disk in SD0: even from a card you know works, and neither a second Mount nor Assign SD0: REMOVE and remount will clear it. Reboot and it’s fine. So: swap freely, but if something unreadable has been in the slot, restart before drawing conclusions about anything that follows.

The vendors’ warning about never connecting or disconnecting the SDBox itself while the Amiga is powered still applies. That’s about the parallel port, not the card slot.

Working with it

This changes how you get software onto a floppy-only A500. Previously that meant building an ADF on the PC and walking 880K across at a time. Now it’s download, drag onto the card, move the card — which makes browsing Aminet and just trying things actually practical.

Copy .lha archives across intact and unpack them on the Amiga. AmigaDOS stores per-file protection bits — s (script), e (executable), p (pure), a (archived) — and a FAT filesystem has no equivalent, so nowhere to record them. The bits are preserved inside the archive, but extract it on a PC and they’re lost: you end up with scripts Workbench won’t execute and executables that misbehave, for reasons that aren’t obvious afterwards. lha x on the Amiga preserves everything.

It’s also far less work for the SDBox. One archive is a handful of large sequential reads; the same archive unpacked into several hundred small files is several hundred separate reads over a slow link, plus the directory listing to match. Unpacking to RAM: where the contents allow is quicker still.

If it won’t mount

Not a DOS disk in SD0: is the message you’ll see for almost any failure, so it doesn’t narrow things down much on its own. Check, roughly in this order:

1. Is the card FAT32? Reformat it if not.
2. Is DosType = 0x46415401 present in the mountfile?
3. Have you added anything to the stock mountfile? Take it back out.
4. Has an unreadable card been in the slot this session? Reboot before testing further.

Change one thing at a time — several different causes produce that same message, and it’s easy to chase the wrong one.