-
Notifications
You must be signed in to change notification settings - Fork 271
Platform Notes
Fairly stable. Boots to userspace and runs applications.
Fairly stable. Boots to userspace and runs applications.
Basic support is there, no real fleshed out platform
Fairly stable. Boots to userspace and runs applications.
Fairly stable. Boots to userspace and runs applications.
Early work only - compiler debug required
Mostly working - runnable user space but some compile related bugs remain
Fairly stable. Boots to userspace and runs applications.
Fairly stable. Boots to userspace and runs applications.
Fairly stable. Boots to userspace and runs applications.
Stable but needs banked memory due to compiler limits
Fairly stable. Boots to userspace and runs applications.
Starting to come together
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. Complete for most processors.
This configuration works but requires some udata copying on process switching. This configuration is hard to get right as the kernel map contains no user pages. Requires special bank handling code.
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. Stable and 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 better 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 ZX Spectrum128, 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).
Implemented, but not yet working reliably when swapping , on the ZX Spectrum 128K
Systems with a tiny bit of common memory or no common memory except some kind of way to move bytes from bank to bank. For example the Cromemco. These systems are now supported by the Z80 -thunked implementation but are tricky to get right.
For example the Tatung Einsten 256 which has 192Kb 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.
This divides into two cases. Platforms with a linear addressable space (eg the 68000) and platforms with a linear segmented space (8086, Z180). The current Z180 ports use fixed banks and cheat somewhat.
For the Z180 and 8086 case the hole needs code finishing and debugging as well as relocatable binaries. Z180 currently uses fixed sized banks, and 8086 could do likewise in the short term if needed and anyone cared.
The flat linear map layer is under development and intended to handle 68000 and similar systems. Given the core assumptions of the kernel probably not useful beyond Atari ST, Sinclair QL, Early Mac.
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. The core 6502 code is written to support this model.
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.
32K banks but with 16K granularity. We don't make use of the extra 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. They cannot however be RAM as the R/W select line is not routed to the cartridge. Requires a banked SDCC setup and is currently rather silly. Supported only for systems with DivIDE/DivMMC adapters that allow RAM in the low 16K.
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 four 32K banks but weird rules about only being allowed one extended bank mapped at a time.
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