New bounties, additions?
|
@ Alan
AFAIK:
There might be other systems that have Flash, but, IMHO, this doesn’t collide with my reply to Stewart, I think it’s better that , on the long term, RISC OS moves more towards a disk load based boot for as much components as possible. |
|
Yeah, but you know what RISC OS users are like ;-) “I copied my HD image to another system and it didn’t work. Baah!” |
|
:D |
|
Amusingly, I find the opposite to be true for me. My (as yet un-chainsawed) RISC PC won’t generate video output that’s stable on my monitor with RO 4.xx but the monitor is very happy with RO 5.28, so that’s what I use, being uninterested in the RISC PC-as-retro arena. I swap to a soft-load RO 4.39 for occasional testing (and even that’s mostly on RPCEmu these days). |
|
Interestingly, RPCEmu doesn’t have that much of a limit: “This directory needs to contain the RISC OS ROMs. All files that don’t start with a “.” or have the extension “txt” will be joined together in alphabetical order to make up the ROM that RPCEmu uses. The total length of the ROM files must be 2, 4, 6, or 8MiB long." |
|
That must be a different page to “The only acceptable sizes for ROM images (in total) are 2MB, 4MB and 6MB.” https://www.marutan.net/rpcemu/manual/romimage.html |
|
A direct lift from the text file in the ROMS directory of RPCEmu. One clearly isn’t accurate. PS. Although for the purposes of establishing what the limitations might be it does describe a more flexible state than the device being emulated. |
|
RPCemu would be by far the easiest to fix. |
|
Though of course the Risc PC can map pages of RAM over the ROM space (down in ye olde 26-bit address space at 03800000..03FFFFFF) to provide more ‘ROM’ than the physical ROMs in a Risc PC could (4MB). Though even that mechanism would run up against a hard limit of 8MB wouldn’t it. |