-
Notifications
You must be signed in to change notification settings - Fork 271
Platform Review Notes
A curious system with a 16bit WD16 processor, lots of expansions including hard disks and banked memory.
Priority: very low (someone would need to write a C compiler for it...)
Only has 64K of RAM but allows for 16K of cartridges as well. Might just about fit but would probably be a very sucky port even though for once it's a machine that actually has a DMA controller!
Priority: very low
Requires the OS is banked in 16K chunks, possibly in ROM for best results. Otherwise it's got the same floppy drive as the Spectrum +3 / PCW8256 and many other similarities, just a differently demented memory banking scheme. No core changes needed to Fuzix beyond the Spectrum needs. One problem is that a 6128/+ want a different memory model to machines that have expanded RAM. Putting the kernel in ROM catridge also changes the model somewhat.
Priority: Low (best assembled out of PCW, Spectrum and TRS80 code once those platforms are done)
Essentially a banked Z80 setup nailed onto a PC style ISA SuperIO. No real core changes needed but quite a lot of driver work. Reasonably well documented hardware. The supplied firmware OS is awkward but there is a reference CP/M port sufficient to work out how to bootstrap the Fuzix image and take over.
Priority: Low
The difficulty of the port depends a lot upon the cards fitted. With a 64K 80column card the machine has enough memory but the memory map is a little odd. There are also banked cards like the Ramworks that would fit the job nicely. Additional memory cards in other slots however only act as RAMdisc so are less useful. Other challenges include the demented floppy disk drivers, but these are well documented. The standard Apple IIe has no timer interrupts so a mouse card or similar, or a IIc would be needed.
6502 support is (in general) harder, but looks doable given memory expansions.
Priority: medium (looks a sensible platform but needs a lot of work). Some early bits sketched out to explore
The BBC master has a rather complicated mess of sideways RAM in a 16K window, extra mappable holes and two banks between 0x3000-0x7FFF one of which intended to shadow video memory. It can also map RAM over half of the MOS ROM which is just about sufficient to make things work out. Any port would need banking support in cc65, and probably relocatable 6502 binaries combined with some special case magic to handle the fact video is stuck at 0x7C00-0x7FE7 in one bank or the other.
Priority: low (very complicated and lots of pre-requisites)
In Z80 mode this acts much like a normal 128K Z80 platform except that several instructions (INDR/INIR/OTDR/OTIR) are broken, the CPU is horribly waitstated and the disk subsystem is relatively slow. There is actually anther 16-64K for the 80 column video so 80 column mode plus some switching space is potentially doable. The kernel would probably need to be banked and the arrangement of common space is awkward. The system is well documented and the CP/M BIOS source is available for reference. Hard disk options are very limited but there are a few RAM disc type devices. It's thus unlikely ever to be a particularly good port.
6502 mode is a different matter. Possibly it will make sense to flip a few routines into 6502 mode where there is a speed benefit. 6502 applications and Z80 kernel would be an amusing drunken hack.
Priority: Medium
In its base form this machine doesn't have a lot going for it but there are banked memory extenders and some of them permit swapping all but a low 4K of common space and also can handle up to 1MB. Unfortunately while the disk I/O sucks less than a Commodore 64/128 it still sucks and there is also no real hard disk option. The disk interface is difficult to write to, and the disk drive has a mind of its own so needs a lot of coaxing to handle "normal" disk.
Priority: Low
Fastish Z80 machine with co-processors and 16K banked memory for up to 1MB or so memory. Floppy disk but limited hard disk options.
Priority: low
The later 80-bus system after the Nascom. Early setups have the same page mode as the Nascom did but the later hardware (GM813) includes quite a sophisticated setup for paging up to 512K (later 1MB) of memory into banks of address space. The biggest challenge may well be the SASI/SCSI controller as the emulators don't support it fully and the SASI is nothing more than direct access to the bus signals with support for a read/write generating the relevant strobes. The optional high resolution video card is also seriously weird.
Priority: low
What the TI99/4A should have been. 512K-2MB RAM, floppy and hard disks, nice graphics. There is a gcc target for this CPU but it's junk grade. Working on a pcc for this and the rc2014-tms9995.
Priority: in progress
Although the base system has little RAM a lot could be added in memory packs. Some of the interfaces are a little weird but it's basically yet another CP/M Z80 system with optional banked memory.
Priority: very low (no open emulator ?)
Another TRS80-ish system but actually a lot more powerful and disk based. The core system has TRS80 model 1 lookalike video, keyboard and floppy but the I/O can be paged out to run CP/M. The video is actually 6845 based and as well as being configured to look like a TRS80 model one actually has 2K of video RAM plus 2K attribute RAM which also provides for colour.
Hard disk and memory banking for the top 32K were supported with add on cards but it's not clear how they worked at this point.
Priority: very low (no open emulator, very obscure but interesting machine)
East German highly expandable and modular machine based around a U880 (Z80 clone) along with CTC and PIO. The memory map is weird as different modules can be mapped into different spaces - 16K ones into any 16K bank, 64K ones across the whole of memory in 16K chunks, but big ones are stuck at 8000-BFFF. The second complication is that the disk I/O (including modern GIDE add ons) lives on the disk interface which is a separate Z80 faster Z80 clone with a 64K linear memory and which talks to the main machine via a shared memory window.
Priority: very low (probably needs to be done by someone who understands the architecture)
Has only a 16K banking window for memory so as well as being an obscure homebrew system would also be difficult to support sensibly.
Done
Start with a TRS80 model 1 compatible system and add much of what the model 4 can do - but differently.
Priority: low
The base Nascom is a fairly conventional early home computer however the 80-bus expansions included floppy, SASI and SCSI disks as well as banked memory (4 x 64K) and in CP/M mode the memory map is quite sane. There is no useful timer on the base system so you'd also need a suitable I/O card with a CTC on it. There's also the MAP-80 card for it which has it's own slightly more flexible banking arrangement. (xbeaver provides some of the needed emulations for 80-bus systems)
Priority: low
Contrary to the name these are Z80 based boxes. The platform has 64K of main RAM with the low 32K bankable up to five ways selected between system memory or four different "ext" RAM banks. The top 16K is banked between the main RAM, 3 16K banks holding R G and B data respectively and up to 32 different ROM cartridge blocks. It's thus a fairly classic banked memory system with separate video memory space. One additional oddity is that a 1K window at 0x8000 can be mapped as a window into a separate block of "high memory" for use as a RAM disc. The first 4K of high RAM is also switchable into 0xF000.
There are lots of complicated ROM mapping modes that basically don't matter (short of Fuzix on cartridge).
Priority: Low (the biggest problem is that most information is in Japanese)
The basic system doesn't support enough memory to be interesting and also lacks timers. There is now a 512K card with 32K paging, and there are CF and IDE cards. There is still no generally available timer with interrupts so that makes supporting RC2014 as it now stands less interesting. There are designs kicking around for Z180 and Z280 boards that might make it more interesting too. There is an older 3rd party port to a variant RC2014.
Done
S100 is a bus not a system. It's a big challenge to deal with because in the S100 era 'compatible' was at the CP/M BIOS level and it was normal to hack together BIOS customisations to match the cards installed. In other words S.100 doesn't actually have an 'architecture' as a system.
It isn't clear what the right approach is given that S.100 systems differ on memory management, CPU features, I/O devices and just about everything else imaginable.
Priority: sort of Done. There is now a target that sits over a CP/M 2.2 BIOS + some additional code. Not enough to address graphics cards and some other bits.
Lot of documentation gaps, and a rather awkward 32Kish banking system. The 32K/32K split requires core Fuzix kernel work to enable, although a simple 32K banked mode could probably be brought up today with no changes
Done.
Tons of memory, sensible memory management, SD card and more.
Priority: low (maybe when it's generally available)
Eighteen bit system with 9bit characters. The 15 is probably the first 18bit PDP that is just about smart enough to support a C environment. It would need quite a hairy toolchain writing and probably a combined optimising assembler/linker in order to put it together because of the way it addresses in 4K pages.
Demented it would certainly be. Maybe a 10 would be more sensible 8)
This calculator does actually have a Z80 processor and can be expanded with RAM and ROM cartridges to sufficient size. However the cartridges are rare and the memory map means that you would pretty much need to have a ROM cartridge for the OS and a RAM cartridge and the optional serial floppy drive. Aside from the need to produce the right cartridges there doesn't seem to be any other specific impossibility. Emulators and sufficient documentation exist.
In theory this is doable using a microdrive as swap and putting a banked kernel in a paged interface 2 cartridge.
The MCX128 doesn't have an I/O device attached so some kind of add on disk interface might be needed. The CPU is also very slow and may not be up to bitbanging SD at a useful rate. Would need a combo an MCX128 and a proper (not bitbang) SD or IDE device.
This is not quite the same hardware as the Amstrad NC100. In particular it doesn't use PCMCIA cards and it has less flexible memory banking. The upper 32K can switch through internal RAM (up to 128K with some fudging) and memory cards for another 128K. Some of the RAM is swallowed for the LCD.
Unfortunately the lower 32K consists of ROM banks so the kernel would pretty much have to be on a ROM cartridge so you'd have to make an IC card flash cartridge or similar and use a 128K RAM in the system to provide 3 process banks and kernel data. The rest would need to use serial floppy.
Thomson TO8/TO9+ and MO6 (mostly sold in France). This would be a difficult port due to the non-contiguous banked zones and interrupt vectors being hardwired to the system ROM, which performs some internal processing before jumping to some location in RAM.
The bankable memory spaces are 0000-3FFF and A000-DFFF. Each can point to any of the 32 RAM banks. At 4000-9FFF we have a contiguous 24K space, non-bankable.
Video RAM can be either at 4000-5FFF, or in one of the banked pages. This would allow to map it out when application code is executing.
From E000 to FFFF it's all I/O devices and ROMs.
For the MO6, the addresses are different, but the problems are mostly the same. For the TO8/9+ it looks just about doable, for the MO6 even as a cartridge may not. Would however need a lot of info on boot disks etc which appears to only be in French.
Status: Basic design put together, doesn't appear to be a way to set the RAM up so it works out
This has no timer interrupt. It could however support single tasking mode easily enough and in theory it has an RTC and serial interrupts with a serial TX FIFO so keeping it sending NUL's would allow a timer tick calibrated with the RTC and probably ok with most terminals
Done (with better hacks than the FIFO one)
There is no real open source 65c816 compiler option. That is probably the single sole barrier. There is now a 65C816 port to a simple simulation platform, but it uses cc65 so isn't optimized in any way for the processor and the compiler generate code that only works in bank 0.
The top 16K is fixed as MOS and while you can get a lot of memory in the 16K 'sideways' window, you would have to get the kernel banked into sideways ROM with its common and data in the low 32K and get all the bits MOS demands and apps in the low 32K and 16K of sideways. Task switching would involve a lot of copying with a 6502 processor at quite low clock rate. Worse yet the video is stuck in the middle of memory so you'd have to teach cc65 to link applications with a 1K hole in them !
This has no timer. Might be usable in single user mode. (Could be supported fairly easily plugged into a backplane that contained a timer source or with one added to the board itself).
Done now we have tickless support.
The machine has 192K attached to the graphics chip and only 64K to the CPU. It's probably sufficient to run the original UZI but not FUZIX as we need genuinely banked memory.
Fuzix: because small is beautiful