-
Notifications
You must be signed in to change notification settings - Fork 278
Platform Notes
Current development platform.
Some code written and built no actual complete platform yet, lots to flesh out
Proof of concept compile of the core code only
This is the ideal arrangement and is found on MSX, Amstrad PCW and some other systems. Higher end 6809 systems generally implement 8K banks but these can be used in pairs with the 16K bank code.
This configuration works but requires some udata copying on process switching.
Systems with a common and multiple banks that sit below or above the fixed common. This model is used for systems that have a fixed banking setup (eg Z80Pack) and also for those where there is paging but a given page can only occupying a fixed address range. Some systems have the top 32K fixed which is a bit limiting for process space size. Possibly the kernel could in future be packed in a low 32K block and the top of the bank in such cases and "large" program would need the top section copying to/from another page on task switch. Might be needed for the uBee, Memotech MTX and N8VEM mark 2. The C128 roughly fits this pattern
Common on 6502 boxes in particular. Good model for single process, large memory, useless model for multi-process. Not supported.
Needs the hole code finishing and debugging as well as relocatable binaries. Could then probably support M68K if some of the 16bitisms were cleaned up. Given the core assumptions of the kernel probably not useful beyond Atari ST, Sinclair QL, Early Mac. In fact a RetroBSD port would probably be better even then.
The 6509 is a 6502 with banking, however the banking is for the full address space - no common, and the only operations you get for out of bank access are "far write", "far read". Needs some very different syscall and irq paths.
ROM is bankable in 16K with a lot of ROM space available. RAM is split into 16K banks but which blocks can go in which bank is at best described as "convoluted". There are allocation models that work.
Tandy COCO, Dragon64 etc. These have cartridge and system ROMs in a 32K bank plus two 32K banks of RAM. Either RAM bank can be mapped low, or they can be mapped low and high together but only in one layout. Needs the OS in cartridge and probably due to the layout limits a 6509 type approach
32K banks but with 16K granularity. 32K banking should work but there may be tricks we can pull with the better granularity.
Top 16K is bankable but not the rest. Video placement is quite restricted. Low 16K is always ROM. Strictly speaking the low 16K ROM can also be banked as ROM cartridges but cannot have RAM in it. Any port would probably need to use banked interface II cartridges and be extremely silly.
Only allows a few patterns but sufficient we get a user space map, and a kernel map. Would still need a hard disk for swapping
FPGA T80 based platform. Has a 4K paging MMU with caches and including R/O page support. We handle this with 16K pages. Our page banking will be slower than some platforms but at 128MHz who cares. A 4K banking implementation could be done but it's got loads of RAM. The Papilio Duo has static RAM so while its down to 2MB a simple 16K bank implementation can replace the MMU.
Later models have two 32K banks but weird rules about only being allowed one extended bank mapped at a time. Not clear if Supermem/Megamem boards would address this
Two base/limit pairs giving three memory regions, each of which can be zero sized. The lowest bank is a physical map from physical zero and is followed by two offset ranges in the address space.
Fuzix: because small is beautiful