-
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 and the kernel can mount and being file system processing. The usermode library and tools have yet to be re-targetted to gcc 6809.
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, 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. In the simple case this is not supported because you really want 32K of program memory.
In the case where you have only 16K bankable memory but have either a 6809 CPU (where the kernel fits in 32K including data if you squeeze hard) or some other banking option (eg MSX1 cartridge ROM of the OS), then it becomes more practical and larger programs can lazy copy from a 16K bank into a common block for the other half of the 32K (and also run banked with their own common in theory).
Thus it should be possible to support the Spectrum 128K using a banked interface 2 cartridge. Some other platforms may work if they also have switchable ROM/RAM mappings and you can put the core kernel into ROM as the kernel requirements for RAM are under 10K.
For example the Tatung Einsten 256 which has 192 of GPU memory much of which can simply be re-purposed. This can be implemented as a pure swap based with a ramdisc driver for the swap. However given the presence of a suitable real swap device it may be better to implement the copier in switchin/switchout, so that you can also use real media as swap. It should also be faster that way - but this hasn't been benchmarked.
Sufficient real RAM or banked RAM is needed to hold the kernel and user process in memory.
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.
The 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 via the Interface 2 expansion. The cannot however be RAM as the R/W select line is not routed to the cartridge. Any port would probably need to use banked interface II cartridges and be extremely silly.
The Spectrum +2A/B and +3 extend the Sinclair Spectrum 128K bank model, adding a few new patterns. Unlike the older models it can run CP/M. It adds a new paging mode which permits one of four fixed combinations to be used. In theory its sufficient as the kernel can sit in banks 6,3 + the non screen part of bank 7, while user processes can live in 0/1/2 (for 48K) and 4/5 (allowing a second 32K resident task). Slightly tricky as part of bank 7 and bank 3 needs to be made to match up as the "common" area.
The Pentagon, Scorpion, Sprinter and others, extend the 128K bank model with extra bits to handle extra banks. Also some models, could bank extra RAM where there would normally be ROM. More info about the Spectrum banking on the different models : http://zx-pk.ru/archive/index.php/t-11490.html
The Super upgrade for the original ZX Spectrum, adds the same ram bank model of the Pentagon and the +2, plus the +2A/B +3 ROM pages and additional ROM pager that access a 512KiB flash memory on 32 banks of 16KiB. In other words, converts a ZX Spectrum on a Spectrum 128KiB with extended rom/ram banks, but without shadow video screen.
The ZX Spectrum 128 had no official floppy disk controller. Third-party hardware (like the Betadisk interfaces popular in Eastern Europe) was designed to be compatible with old software, so contains some problematic features like the FDC port only being accessible by code within a 256-bytes long area of ROM. Outside this area any requests to FDC ports are ignored. This makes any disk driver implementation very tricky until we have a smarter linker.
These are the "most" popular options :
- Disciple and +D interface : Based on a WDC1772 , like the SAM Coupe
- Beta disk : Based on WD1793 . Pretty common on the Russian clones.
- Spectrum +3 floppy interface : Based on uPD765 (I8272), and nearly identical to Amstrad CPC floppy interface. Could be added to +2A/B models and perhaps to the Super Upgrade
- Opus Discovery: more common in the UK and Europe but still quite unusual
None of these are period but are more common with retro fans today
- DivIDE : IDE adapters for the Spectrum. 16bit registers are presented via latched low/high pairs and data can be block copied using INIR/OTIR
- ZXATAsp : Combo IDE, CF, memory adapter for up to 512KB
- ZXCF+: CF and memory adapter for up to 1MB
At least on the ZXCF/ZXMatrix variant the banks can be used for swap or disk, however they are limited to the low 16K so not directly usable for all process RAM.
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