Wanted - small capacity micro SD card

Sorry to post so late in this process.
An alternative is to use any size of SD card (1,2,4,8,16 . . Gb) and format it to, let’s say, 256 Mb. 8 heads, 63 sectors, 1024 cylinders for instance. Then add the Loader directory (if you need that one) by means of !Systemdisc. Copy the desired files onto the card, then start up !Zap. Iconbarmenu, Create, Read disc, choose SCSIFS (as you probably have the SD card in a cardreader) and disc number; click Read disc. Save the file that’s appearing inside !Zap as xxx/img (where xxx is the name of the imagefile), optionally compress it and you’re ready. If e.g. Fat32Format afterwards refuses to reformat the SD card to full capacity, try gparted (Linux) or Hform (Riscos) and then again fat32format. I found that disc image writer (Linux) hangs because the image is too small (??), but dd does the trick.
To make an image that is directly readable under Riscos, do not use Hform (and optionally Systemdisc) but format a small partition with gparted to Fat16. With Riscos, put this card in a cardreader, open the ‘disc’ by right-clicking in order not to awaken Fat32FS, add the files, then do a disc read with !Zap and save the resulting file as xxx/img, filetype it as dosdisc. Under Riscos this is directly readable (DosFS) and still you can use it to write to a card using dd, imagewriter etc.
When it has to be a Riscos distribution SD card, add !Boot.Loader using !Systemdisc and add its contents (bootcode/bin etc) there on the SDFS-formatted disc; or alternatively on the Fat16-formatted disc, put these bootcode/bin, cmdline/txt etc files in the root directory next to !Boot, Apps etc. Make sure that Hform and !Systemdisc are also on these cards. Riscos starts from such a Fat16 card. Instruct the recipient to copy everything to a large RAM disc, start !Systemdisc once to load its discbased modules before they are overwritten, apply Hform on the SD-card, then restart !Systemdisc. Fill sdfs::!Boot.Loader with the appropriate files and the rest from RAM::0 to sdfs::0. Restart. Thus, the entire capacity of the SD-card can be used.

Thanks for that, too, Jan :)

For reference, many of the higher-end ARM boards don’t use the systemdisc/fat partition approach, as they native-boot direct into RISC OS. However, the advice is still really useful, thanks.

To be clearer, there’s no need for small cards to create small images; any size of SD card will do. Just Hform and Zap. (I used the method for the harddisc images in my emulator, all < 500 Mb).

Thanks Jan – do you know if Zap will attempt to read mapped out “defect” sectors as dd would?

Tried it on a floppy with mapped-out defects – Zap immediately abandoned the reading process, without creating an image. I have not seen an SD card with a defect yet; no idea what happens with that.

Thanks Jan – do you know if Zap will attempt to read mapped out “defect” sectors as dd would?

I have not seen an SD card with a defect yet

I don’t think it’s possible for an SD card to present defective blocks to the user.

I don’t think it’s possible for an SD card to present defective blocks to the user.

SD card sectors are virtual, due to things being shifted around by the wear leveling mechanism. That is to say, what you see as a continual series of blocks may in fact be completely different on the media surface.
If SD cards present something akin to SMART, it might be possible to retrieve some sort of status codes to indicate the health of the card. However if you are coming across defective blocks, then there’s a pretty good chance that your card is toast and the SD controller has run out of backup blocks to map in (as with a modern harddisc, there are a few additional sectors for situations like this).
I have a defective 32GB card in my phone. I have a backup from before, however the interesting thing is that when I was using the card as read write, the defective block would be used in wear leveling, so errors would propagate and corrupt random files as the SD controller shuffled things around. I treat it as read only these days. I did buy another 32GB card to restore from backup, but… Well… It was a high speed card so I used it with the satellite receiver. ;-)

At any rate, head zero track three sector seven of a floppy disc is a defined and specific location. However the same location on an SD card will be wherever the block allocation puts it, and if the device is used heavily (like, of that’s the free space map or something), then it may indeed be in a different place each time.

I don’t know if it’s even possible to read low level blocks from an SD card.