Pico bug

Well I am trying to get an old programme working on the Pico build.

If I do a *con.spritesize 32k and (after CTRL-BREAK) try a *SLOAD Sprites command, I get an AODT at &FC1A2C10. Checking *status and the spritesize (the system sprite area size) is correctly set to 32k.

Not sure what is wrong…

What happens if you try the same on a RISC OS Pi?

Good question. Using NOOBS V 1.3.7 (which is RC12, I think) it just works correctly.

Hmm!!

When I first tried the above on the Pico the *sload sprite worked without any error and *sinfo showed the sprite had been loaded.

Next there was something of a diversion as I found the Pi in full RISC OS mode would not write to the Pico card in its USB card reader. I reformatted the card both on the Mac and in the Pi, reinstalled Pico, and on both set-ups the error appeared, abort at &FC19C5E8 which *where gives as offset &4FC0 in DOSFS. A penny was thinking of dropping at this point. As the working card had been formatted by GParted on Ubuntu, I inspected the ‘broken’ card with GParted which showed it to be Fat16. It was then reformatted to Fat32 by GParted and the error went away again. (The write problem seems to be card reader weirdness.)

Hmm!!

The card used is 2GB, do some formatters vary the format with card size?

The 1988 programme I have tried to get working does now sort of work. It is here but it still gives an error (AODT) on the Pico build, now when it tries to do a SCREENLOAD command. Curses!
Edit:Now working correctly..

The card used is 2GB, do some formatters vary the format with card size?

Yes.
Or, at least, they used to.

The maximum valid size of an SD card is 2GB¹. The maximum size of a FAT16 partition is 2GB. Some simpler embedded devices would prefer to support FAT16 as it is simpler, and Windows can read it. Typically these devices would stick to the 8.3 filename conventions as well (simplicity).
So, yes. There was a case for <= 2GB being FAT16. I guess your formatter is still applying that on the basis that choosing such a small SD card is for a reason…

That said, I can’t imagine DOSFS failing to support FAT16 – the old !PC partition files were formatted FAT16.

¹ Anything over 2GB is, strictly speaking, an SDHC card² which is accessed differently (and not backwardly compatible) and is likely to cause SD-only hardware to freeze, crash, etc. I have a cheap little digital camera that crashes with SDHC media.
There is a later version – SDXC – for really big sizes. Unfortunately the SD people have made exFAT the mandatory file system. exFAT is proprietary (Microsoft), so accordingly the industry is generally pretending like the largest commonly available size of SD-like device is 64GB and that SDXC pretty much doesn’t exist.

² I believe there were some non-standard 4GB SD cards made. Non-standard being the key.