Many of you will be familiar with the 5th Column ROM socket. As it happens, the Podule module (the part of RISC OS which handles Podules and extension ROMs) scans the entire MEMC ROM are for 5th Column ROMs. You'll also know that the ARM250 machines don't have one, which rules out adding Wizzo to the RISC OS ROM. Because of the ">2MB checksum issue", the RISC OS ROM has to stay below 2MB (until the bug is fixed).
Or does it?
Let's take a look at the 5th Column ROM documentation... (https://www.chiark.greenend.org.uk/~the ... Column.txt)
The eagle-eyed among you will have noticed what I noticed: the RISC OS ROM is normally mapped in between &03800000 and 0x39FFFFF, if we have a standard 2MB ROM set fitted. But the ARM250 machines (and probably others) can accept a pair of 16Mbit 16-bit EPROMs, giving a total of 4MBytes of ROM space. That means you can have a ROM which looks like this:Extension ROMs appear in the ROM area of the memory map, ie between &03400000 and &03FFFFFF. An extension ROM set must end on a 64K boundary or at the start of another extension ROM. This is normally not a problem as it is unlikely you would want to use a ROM smaller than a 27128 (16K), and the normal way of addressing this would mean that the ROM would be visible in 1 byte out of each word, ie within a 64K addressable area.
Code: Select all
+------------+ &38000000 | RISC OS | | 2Meg | | | +------------+ &3A000000 | filler | | &FFFFFFFF | +------------+ &3C000000 less 64k | 5th Column | | ROM | | (64k) | +------------+ &3C000000
We need to do a few slightly special things. First, each module needs to be prefixed with its length, a bit like the "module chain" in the RISC OS ROM. Second, each module must begin on a multiple of 4 bytes (the two least significant address bits must be zero). If you breach the second condition, RISC OS will start booting, but throw an Address Exception when it starts to load your module. Unaligned accesses aren't allowed for program code.
Some of you might remember my project to rebuild an Acorn A4 version of Wizzo, with the A4's I2C and Portable ROMs included. I updated the 5th Column ROM tools from that project to account for the 32-bit requirements. The result is on Github: https://github.com/philpem/riscos-romtools/ (5thColumn directory).
So how do we use this?
- Get the modules you need together. I grabbed Wizzo 3V15's IDEFS and IDEFSFiler.
- Edit config.yml to list the ROMs in the order you'd like them included.
- Run mkrom.py to create a 5th Column ROM. You'll get a 64kbyte "rom.bin" as output.
- Run 'dd if=/dev/null of=padding.bin bs=65536 count=31' -- this produces a 2MB-less-64k padding image. (Ideally you'd pad with 0xFF)
- Use stripe.py to split the ROM into Low and High words.
- Program some EPROMs!
Code: Select all
srec_cat \ RO311 -Binary \ -fill 0x00 0 0x3F0000 \ 5thcolumn/rom.bin -Binary -Offset=0x3F0000 \ -Output EXT -Binary
You'll still need to use other tools (like qUE and Flibble's "Roll your own RISC OS" from viewtopic.php?f=29&t=14164) if you want to remove or replace RISC OS core modules like ADFS, but this is a great option for adding new things to the ROM. Especially as it nicely sidesteps the ROM checksum bug.
If you want to add things to ResourceFS, you don't need to patch the Messages module. All you need is a simple module which contains a resource file block (see https://www.riscosopen.org/wiki/documen ... isterFiles) and some ResourceFS calls.
The RISC OS 3.60 "Messages" module is a nice simple example: https://gitlab.riscosopen.org/RiscOS/So ... e/RO_3_60/
Obviously this only applies if you want to add things to ResourceFS. If you want to remove them, you'll need to patch the Messages module.
I'm also not entirely sure whether ResourceFS will access the files in-place in ROM, or if it will copy them to RAM. I'm sure someone here knows which option ResourceFS takes... but for now, it might be an idea not to bake a copy of ArcElite or SparkFS into the ROM...