Suggested memory model for a new port?

[hpax]

Hi,

I am thinking it would be fun to port Fuzix to the Swedish Z80-based ABC80 computer, for which I have designed a small memory expansion + MMU board.

The MMU is a bit quirky, a result of board space limitations (and a few other limits that imposed on myself in the design), but I think it is more than plenty -- in fact, I'm having a bit of a hard time to figure out which memory model to pick.

The board carries 1024K RAM + 512K flash. It has 16 memory maps (+ 16 in flash for booting) which can be switched between "instantly" (just one OUT). The memory maps can be programmed in pages of 8K, but at a 512-byte granularity. Thus, in the simple banked model I could program 16 maps and have a cutoff between banked and common at any 512-byte mark.

The downside with the 512-byte granularity is that to program the MMU with arbitrary 8K pages requires looping over all 16 subpages.

However, before I dig into this much deeper, I'm wondering if there is a better way to do it as far as Fuzix is concerned. One thing in particular I have wrecked my brain over is the uarea; it seems to be copied on context switch in pretty much all the ports that I can see, which would be kind of nice to avoid?

Also, hello :)

[hpax]

A translation of the documentation for the MMU/memory card, courtesy of the bots at Google:

https://www-abc80-org.translate.goog/meg80/doc/?_x_tr_sl=sv&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp

[EtchedPixels]

A lot of the ports are to memory models that have fixed upper common space so it's usually cheaper to copy on the (quite rare for single user) actual switches. Some swap the upper block. If you can set up a large low base area, a small fixed common and a switchable 512 byte block for the udata you are well set.

The udata thing may change now I am porting it all to my new C compiler (hence the current mess with the Z80 ports). Teaching the compiler some kind of notation for IY is a global register pointer perhaps: which is how 68K works, within the kernel one address register is permanently the udata.

There is 8K bank code in mm but it's not yet been used/tested properly as the port it's meant for hasn't yet been migrated, and the other port that would use it (Z280) is bogged down in hardware and CPU bugs.

[hpax]

On November 6, 2023 2:02:13 AM PST, EtchedPixels @.***> wrote:

A lot of the ports are to memory models that have fixed upper common space so it's usually cheaper to copy on the (quite rare for single user) actual switches. Some swap the upper block. If you can set up a large low base area, a small fixed common and a switchable 512 byte block for the udata you are well set.

The udata thing may change now I am porting it all to my new C compiler (hence the current mess with the Z80 ports). Teaching the compiler some kind of notation for IY is a global register pointer perhaps: which is how 68K works, within the kernel one address register is permanently the udata.

There is 8K bank code in mm but it's not yet been used/tested properly as the port it's meant for hasn't yet been migrated, and the other port that would use it (Z280) is bogged down in hardware and CPU bugs.

I haven't really figured out where the udata area actually sits? The native ABC80 OS does use IY as a global pointer in much the way you describe, too.

It sounds like the straightforward thing is simply to use the memory as 16 banks; then I can configure any arbitrary 512-byte memory regions as common or banked.

[EtchedPixels]

udata can sit anywhere you want it to. It's usually at the bottom of the common space because the standard set up it contains the per process kernel stack and that is much easier to switch to if it's common space. The Z80 tree supports it being otherwise (-thunked) and can in fact run with no common RAM at all to deal with some of the more dysfunctional devices.