-
Notifications
You must be signed in to change notification settings - Fork 281
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
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 ?)
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)
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: Low (once the Cromemco port is done it will be worth looking how to build from there)
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
Priority: High (in order to get 32K/32K supported and debugged)
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.
Firstly this would need a new compiler (probably a port of pcc or cc65) to generate 6801 code. Secondly 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.
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.
The bigger systems in this range have a lot of memory and a considerable number of peripherals suitable for storage. The main problem is the memory subsystem. There are two 16K windows to access the RAM banks at 0000-3FFF and A000-DFFF. High space (E000-FFFF) is I/O and ROM. The remaining space is split between a fixed 16K of RAM (6000-9FFF) and two 8K pages at 4000-5FFF. Unless the kernel can be made to fit in 24K, this would require banked 6809 code, which gcc doesn't support in the way we need. The video framebuffer can be moved to bank 2 or 3, getting it out of the central memory space.
Another problem is that the system ROMs are hardwired in the high space, making it impossible to directly handle interrupts (they jump to some ROM code, which does some processing before calling an user routine in RAM). The only way around this would be to replace the ROM inside the machine, which is what the OS/9 for Thomson project went with.
The MO6 has a different memory map, but the same problems.
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
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.
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).
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