bloodline wrote:
That's not quite true, great care has been taken to make sure that the AROS code rommable, in fact this requirement has (and still is) causing quite a few headaches :-D
I suggest you look at the x86 Native flavour as that has the AROS kernel loaded into RAM which is then protected and treated as ROM.
-Edit- Porting Openfirmware to the Amiga would be a brilliant and very popular idea though!!!
Rommable yes... but what size ROM and on what hardware? You've been working without space limitations and initial hardware testing/setup issues at the lowest level. You also operate on the assumption you have some sort of output device.
I suggest you look at the liberal use of kprintf (for starters) for error reporting when no device may be available from printing.
The messages you have in kprintf statements may be easier to follow than guru numbers but they suck ROM space and you can't assume you have hardware to display them when bootstrapping hardware from scratch.
PC motherboards now have LEDS that display different patterns as the PC goes through the startup and it beeps patterns to diagnose problems.
On the AmigaOS, it flashes the LED and displays different screen colors and uses guru numbers if possible (they can be found in memory if they aren't displayable).
Notice on these that only errors are reported... if everythings fine the OS just goes about it's business and you don't really notice.
What about if I want to use AROS for an MP3 player? An embedded OS can't make assumptions about the availability of a display (let alone the size of it) or even a serial port for messages. The error messages don't have a corresponding code.subcode where code is lib or device and subcode is section that can be used to flash an LED or be placed at a reserved address and they can't be turned off in the compile so they take up space even if you can't use them. They aren't even stored in a packed byte or compressed form to save space.
My suggestion would be to change the messages to codes or change kprintfs to have text AND code and use a macro or template for kprintf so that you could select which to include at compile time. And the kprintf routine could be adjusted accordingly to the host it works on.
At the very least the number of messages requires some sort of way to compress them conserve space. Possibly storing them 4 bits / character.
If you want to build an AmigaOS 3.1 like ROM you have to design it that way from the start. The AROS team didn't set the same design restrictions Amiga did and it shows. Amiga Inc. origianally only had 256K for their ROM and that included a lot of stuff! But they didn't waste it either.