MOS modules?

[stevesims]

MOS is currently a monolith. The only concession to this is support for executable commands as files stored inside the mos folder at the root of the SD card.

The Acorn MOS of the BBC Micro supported additional ROMs that could add additional functionality.

Arthur, and later RISC OS, included support for "Relocatable Modules" which could be soft-loaded from disc or present in ROM as an equivalent mechanism for extending the OS.

Ideally MOS should support a module system to allow it to be extended.

[stevesims]

A module mechanism like this could be used to allow for joystick port support.

Different joystick interfaces could provide modules supporting the same software API, allowing software to be written that can easily target all types of joystick interface.

[sijnstra]

Interesting idea although I'm not sure of the extent of modularity and what that would mean. As a design principle, I'm not keen on losing memory space for additional modules as the default mode of operation. If the devices are interrupt driven then you could just update the interrupt vector for the respective driver? Is that the level you are looking for - a known API to select specific interrupt so that they can move around between MOS versions without needing to know the exact location of the driver code? Does that meet the driver requirement?
In a way, I see the MOS more as a monitor than an OS - a boot strap to get you off the ground, but if you want OS functionality, there are options to load on top like CP/M, TRS-OS and ZealOS (8 bit).

[stevesims]

yup - it's all tricky, and knowing how best to deal with this kind of thing is hard 😁

My (incomplete) understanding of how Acorn did this kind of thing was thru "vectors" which were kinda like interrupts, but not necessarily always interrupt driven. The mechanism they used feels sensible. At this time I'm not quite sure how to bring that kind of functionality to the agon-mos, and need to do some research and experimentation to work that out.

I'm not keen on losing memory either. I wonder if it's possible to have such driver modules optionally stored in flash on the eZ80, and thus not taking up RAM space.

As I see it, MOS needs to be more than just a BIOS or HAL, and I can't envisage a time when to actually use your Agon you'll need to load an OS on top of it. Sure, you can run a more fully featured OS on top of it, but to me that is akin to running Windows or GEM on top of DOS. I think it's an important feature of the Agon platform that you can plug in an Agon machine and actually use it without having to load anything else in.

[sijnstra]

One way to do it is an extensible device control table (DCT), which of course takes up some memory and needs laying out properly (TRS-DOS/LS-DOS for the TRS-80 model 4 is a good example), but if you have enough of the drivers in flash with some other kind of de-referenced hook, you could point to them by something like "request location of built-in mouse driver 2" (allowing to BYO if you want), then "do action on the generic mouse driver" which in this case would be "install address I just received as a mouse driver", could be get coordinates etc - the driver would need to play nice and hook in to interrupts if desired or not in the case of joystick . Wouldn't take up too much memory I guess? Could allow for testing as well?

[stevesims]

This idea was also posted as an issue to Quark MOS here breakintoprogram/agon-mos#91

There is some interesting (further) discussion about the idea there, including an example of code relocation from MSXDOS in Z80 mode from @S0urceror