Port of FUZIX for the CPC6128

[ajcasado]

Regarding (re)setting this 16bit port address bit for the bank switching it's very similiar to what is currently happening in SymbOS CPC, if the system has >576KB (for systems with <=576K it is patching the routines, so they run in a faster way).

The patching approach sounds like an elegant and clever solution—I hadn't thought of that. I'll definitely keep it in mind for the future.

In SymbOS I have the problem that several functions only accept 20bit addresses (4+16bits), which is 1MB, as they only use nibbles for the upper part of the address. That's currently the main reason for the 1MB limitation. No idea how this is working in Fuzix?

There is support for function calls across kernels distributed in different banks using more than 16-bit addressing, but I haven't looked into that in detail, since the ports I've worked on use a single 64 KiB kernel bank. As for user processes, only 16-bit addressing is used.

If I remember correctly 64K is just maximum, not the minimum for one process? (that was a shit thing in MP/M...) So you could also have 15 processes in one single 64K bank, if each is only using 4K or so, right? (like in SymbOS)

As far as I know, on platforms with banked memory where address spaces overlap, only one process runs per user memory map—in this case, per 64K bank.

Isn't it possible for one process to reserve additional memory outside of its primary 64K bank?

In our case, that's not supported.

Thanks a lot for your work on Fuzix and sharing all the insights! For me this is always very very interesting!

You're welcome! I'm happy to clarify anything about the implementation I'm working on. As for deeper questions about the inner workings of Fuzix, my understanding is limited—I try to answer as best I can, but I think @EtchedPixels  could shed much more light on these topics with real authority.

[ajcasado]

I wonder with such addressing schemes whether you could adopt something like this.  That is let's say you have 2mb ram, there shouldn't be any reason the processes can't be e.g. in the upper 1mb, then allow thr heap to be in the lower 1mb. This could effectively double the amount of ram assuming processes don't need to directly read from each others ram.  Now for reading from their own ram... maybe it can be 1mb - 64kb for the heap space, and the processes own 64kb is also accessible. 64kb lost from processes but... use it for fuzix kernel buffers or something... like text screens.

I don't see a straightforward way for code running in a 64K bank—which doesn't share a common area with other banks—to efficiently work with data located in other banks. The lack of a shared memory region between banks makes inter-bank data access complex and slow, especially on 8-bit platforms.

[EtchedPixels]

The Fuzix memory manager is designed to let you plug anything into it because machines are so weird and wonderful (or not) and because of course a 68000 is quite different to a Raspberry Pi Pico or a classic banked Z80 box.

I think the theoretical limit for 8bit is 65535 64K processes but the rest of the OS would break rather sooner. The largest box it runs on is a 16MB 68000 and to be honest quite what to do with most of that RAM is a mystery.

There's no provision for RAM from other banks. It doesn't fit the unix model and the goal is to be portable so we also have to run on systems that have really crude memory management options. Also the logic is that copying to or from other banks is really a ram disc and a ram disc is just a bad cache so just use files. In fact of course with a current CF card interface the ram disc is often slower than the CF anyway . Fuzix does go to the trouble of being clever with direct block aligned copies going between disk and user memory without buffering and that's sufficient that you can happily play infocom games, quill stuff, level 9 games and a load more things without problems, and is plenty fast enough for the C compiler to use between passes.