-
Notifications
You must be signed in to change notification settings - Fork 278
Platform Notes
Current development platform. Boots to userspace and runs applications although far from stable.
Test code replaces the ROM images for the xroar Dragon64 emulator and gets to the point of wanting to mount a file system. Support should work for single memory bank systems, MMU style and also SAM style with no common RAM (ick).
Standalone tools have been updated to support both big and little endian file systems.
Next stop is a disk driver.
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. Somewhat tested.
This configuration works but requires some udata copying on process switching. Minimally tested.
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. Tested.
This works like a 32K banked system but the upper chunks of "large" programs are copied (lazily) on taskswitch to and from blocks of the upper memory. Might be needed for the uBee, Memotech MTX and N8VEM mark 2. The C128 roughly fits this pattern. Test code is written but currently binman can't handle the kernel images with a giant hole in the middle that this produces.
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. Not yet tested.
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. Some tricky bits in the interrupt and IRQ paths but this model is now supported.
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