Port of FUZIX for the CPC6128

[ajcasado]

Hi,

I have ported FUZIX to the CPC6128, the port is awaiting to be merged to the oficial repository. Is available on my github account: https://github.com/ajcasado/FUZIX . The build target for make is cpc6128.

I have uploaded the files to boot FUZIX to: https://www.dropbox.com/scl/fi/e6p75grzm4meb8g3gugrw/cpc6128.zip?rlkey=5jtjegadbxry8xk0qyadcofo3&st=qryffpb1&dl=0

 Here is a description of the status of the port:

Video mode 2 is used. The video driver configures the CRTC in 64x32 characters to do easy hardware scroll and use the whole video memory bank.

Trying to mount the floppy hangs the machine, and may do nasty things to the floppy and the drive, don't try on a real machine!!

The IDE driver that is supposed to work with the symbiface and xmass fails to initialize.

The USB mass storage of the Albiero works using the ch375 driver used in other platforms. It should be easy to get it working with the Usifac/Ulifac.

There isn't a proper loader, for now a snapshot is generated.

To test it burn disk.img on a spare usb pendrive and put it on the albireo. Load an run the snapshot.

[ajcasado]

Here is an image:

[ajcasado]

Here is the image.

[PulkoMandy]

Great! One less thing on my TODO list, as I was thinking about it 

Do you plan to support more than 128K of RAM?

It should be possible to keep mostly the same banking scheme but use more 64K memory pages for apps.

So, some apps could be in C2, and then more could be in CA, D2, DA, ...
They could access the kernel (in main RAM) using C9, D1, D9, ... banking (which is like C1, but with a different memory page at C000-FFFF)

[ajcasado]

Great! One less thing on my TODO list, as I was thinking about it 
Do you plan to support more than 128K of RAM?

Thanks, anyway any help is welcome.
Yes, but first i'd like to fix bugs, speed up several things and support more hardware.

It should be possible to keep mostly the same banking scheme but use more 64K memory pages for apps.

The problem with this is that you need a commom memory (in this case bank 7 is used) visible all the time to the Z80 at the same adresses.

So, some apps could be in C2, and then more could be in CA, D2, DA, ...
They could access the kernel (in main RAM) using C9, D1, D9, ... banking (which is like C1, but with a different memory page at C000-FFFF)

To achieve this the contents of bank 7 have to be mirrored in every 64k block used (CA, D2, etc). Every write to common memory has to be repeated in all the 64k blocks. In the Cromemco, for example,  this is not a big problem as there is a mode to write to the same address in all the banks at the same time. In the CPC a write loop must be used.
This is possible, but for the same cost a better  banking scheme can be used, the same that is used in the Cromemco port. The basic idea is that all the maps correspond to C2, CA, D2, etc. The first, C2, is used for kernel, and the rest for user processes. This gives about 60k for user processes. As a drawback the first 64k are only used for video, making possible the use of overscan resolutions, more than one TTY, keep the firmware freezed for making calls when needed and maybe run normal 64k apps patching the interrupt vectors that they use.

[m_dr_m]

Wow! That's Unix on the CPC?!? Are there some examples of working programs?

[ajcasado]

As a drawback the first 64k are only used for video, making possible the use of overscan resolutions, more than one TTY, keep the firmware freezed for making calls when needed and maybe run normal 64k apps patching the interrupt vectors that they use.

My english is sometimes very rusty. I don't see this as a drawback, it's an advantage.

[Devlin]

Oh wow. I will have to try this.

[Prodatron]

The IDE driver that is supposed to work with the symbiface and xmass fails to initialize.

The USB mass storage of the Albiero works using the ch375 driver used in other platforms. It should be easy to get it working with the Usifac/Ulifac.

If you need low level 512b sector read/write routines for the SF2 or XMass or M4Board, just contact me.

I guess Fuzix is still implementing the filesystem by itself, without the need to use high level stuff of very modern hardware, or I am wrong?

When talking about CPC bank switching, does every Fuzix applications requires a full 64K ram bank for itself (on the CPC)? Or do they use relocator tables for putting multiple apps in the same area?

[ajcasado]

Wow! That's Unix on the CPC?!? Are there some examples of working programs?

This is a list of included packages in the built image:

basefs, netd-base, netd-lwwire, ld09, ccp, cursesgames, adventure, flashrom, assembler, ue, games, MWC-cmd, V7-games, V7-games-man, V7-cmd-micro, V7-cmd, V7-cmd-man, V7-sh, V7-fsh, V7-sh-man, util-mini, util, drivewire, libs, includes

You can see the apps included in this packages here: https://github.com/EtchedPixels/FUZIX/tree/master/Applications

I have tested some utils as banner, mount, dd, ls, find, grep, fsck, df and they work. Also some games as startrek, cowsay, hamurabi, dopewars, and also work.

[ajcasado]

If you need low level 512b sector read/write routines for the SF2 or XMass or M4Board, just contact me.

For the IDE adapters I configured the ports as shown in: https://www.cpcwiki.eu/index.php/SYMBiFACE_II:IDE_registers.
Its coded here: https://github.com/ajcasado/FUZIX/blob/master/Kernel/platform/platform-cpc6128/platform_ide.h
The low level transfer functions are based on the code from: https://www.cpcwiki.eu/index.php/SYMBiFACE_II:IDE_routines
And is coded here: https://github.com/ajcasado/FUZIX/blob/master/Kernel/dev/cpc/cpcide.c
The initialization fails in this function:

Code Select Expand

static int ide_wait_op(uint8_t mask, uint8_t val)
{
uint_fast8_t st = ide_read(status);
/* 0x78 is the bus float for many systems with CMOS Z80 and nothing pulling the idle bus. It's
  also conveniently a nonsense IDE status */
if (st == 0x00 || st == 0xFF || st == 0x78) {
kputs(" - absent\n");
return -1;
}

while((ide_read(status) & mask) != val) {
if (timer_expired(giveup)) {
kprintf(" - no response\nstatus=%u, mask=%u, val=%u\n", status, mask, val);
return -1;
}
}
return 0;
}
From this file: https://github.com/ajcasado/FUZIX/blob/master/Kernel/dev/tinydisk_discard.c
The output is in the image attached. I guess that I have to dive into the IDE protocol to debug this.

I guess Fuzix is still implementing the filesystem by itself, without the need to use high level stuff of very modern hardware, or I am wrong?

You are right,

When talking about CPC bank switching, does every Fuzix applications requires a full 64K ram bank for itself (on the CPC)? Or do they use relocator tables for putting multiple apps in the same area?

Fuzix applications are relocatable, you can have multiple apps in the same 64K block, It also uses a swap mechanism so you can have more applications running than the user RAM can hold, but the maximun size  of a user process is limited to one 64K block minus the common memory.
One posible use of the expansion RAM without changing the current banking scheme is using a RAM disk as swap partition.

[ajcasado]

From this file: https://github.com/ajcasado/FUZIX/blob/master/Kernel/dev/tinydisk_discard.c

The link is wrong, the correct one is:
https://github.com/ajcasado/FUZIX/blob/master/Kernel/dev/tinyide_discard.c

[GUNHED]

Hi,

I have ported FUZIX to the CPC6128, the port is awaiting to be merged to the oficial repository. Is available on my github account: https://github.com/ajcasado/FUZIX . The build target for make is cpc6128.

I have uploaded the files to boot FUZIX to: https://www.dropbox.com/scl/fi/e6p75grzm4meb8g3gugrw/cpc6128.zip?rlkey=5jtjegadbxry8xk0qyadcofo3&st=qryffpb1&dl=0

 Here is a description of the status of the port:

Video mode 2 is used. The video driver configures the CRTC in 64x32 characters to do easy hardware scroll and use the whole video memory bank.

Trying to mount the floppy hangs the machine, and may do nasty things to the floppy and the drive, don't try on a real machine!!

The IDE driver that is supposed to work with the symbiface and xmass fails to initialize.

The USB mass storage of the Albiero works using the ch375 driver used in other platforms. It should be easy to get it working with the Usifac/Ulifac.

There isn't a proper loader, for now a snapshot is generated.

To test it burn disk.img on a spare usb pendrive and put it on the albireo. Load an run the snapshot.

This is an amazing piece of work! It would be nice if it could be implemented for SymbOS and FutureOS too.

Advantages for SymbOS:
- Support of lots of mass storage devices
- anything else Prodatron can tell

Support for FutureOS:
- Mass storage management (M4 SD card, few others)
- floppy disc access (at every level)
- memory management up to 4 MB
- screen management
- support of lots of expansions
- Free RAM from 0 to &B7FF
- Quickest OS functions in CPC world

I could program the connective layer between your FUZIX implementation and FutureOS. 

[ajcasado]

This is an amazing piece of work!

Thanks GUNHED!!

It would be nice if it could be implemented for SymbOS and FutureOS too.

Yes, probably, but that's a task that is beyond me for now, and honestly, I have no plans for it. In any case, if anyone is interested, I can contribute to the extent of my abilities.

I've been thinking about the idea of making a port for the CPC for some time, and I'm surprised it doesn't already exist. According to Alan Cox, handling the extended RAM makes its use in FUZIX difficult. I started considering taking advantage of the implementation in the Cromemco, which does full 64k bank switches and doesn't have a proper common memory; it simulates it by copying the contents of the common memory between all 64k banks, with the advantage that you can write to all banks with a single instruction. While trying to build the Cromemco port, I encountered an issue during boot and contacted him on GitHub. He suggested that it would be better to start by leveraging the ZX+3 port since the memory maps used were analogous to three possible CPC maps (C1, C2, and C3), and I followed his advice, so this port is just another Speccy port on the CPC . Honestly, it was easier than I expected; I only had to adapt the basic keyboard and screen handling functions, change a few values in the configuration file, the memory map switching instructions, the access ports to the IDE interface and the Albireo's CH376 chip, and write the low-level functions for reading and writing sectors on disk and floppy. That being said, the IDE interface and the floppy don't work, the screen handling has issues, and the final goal is to change the memory bank scheme, so I guess I still have a lot to learn and work to do on this port before thinking about future implementations.

[Prodatron]

It would be nice if it could be implemented for SymbOS and FutureOS too.

Fuzix is an own operating system, not a programming language or whatever

[ajcasado]

It would be nice if it could be implemented for SymbOS and FutureOS too.

Fuzix is an own operating system, not a programming language or whatever

Yes, that's the point. Maybe it would be possible to do something similar with FUZIX, like what has been done with cpmvm in Symbos, but it might only make sense to run it within SymbosVM (FUZIX is slow in its current state, and I don't know to what extent its speed will improve). I haven't really given that much thought to the matter, to be honest.

[GUNHED]

It would be nice if it could be implemented for SymbOS and FutureOS too.

Fuzix is an own operating system, not a programming language or whatever

Sure, but what 'BIOS' does is use? The native OS? That would be slow.

CP/M for example is as quick as its BIOS (just compare different CP/M computers).

If you don't want an implementation for SymbOS, I do understand that, because your OS already works in multitasking mode only.

On the other side FutureOS can provide a quick kind of 'BIOS' for it. More RAM for FUZIX and more power, since the 2nd register set can be use too. While the native OS doesn't allow to use the 2nd register set of the Z80 (or only in a very time wasting way: PUSH/POP everything).

Fuzix could have an real advantage in speed, depending on the implementation of 'BIOS' like features. And why to invent the wheel again? 

[GUNHED]

This is an amazing piece of work!

Thanks GUNHED!!

It would be nice if it could be implemented for SymbOS and FutureOS too.

Yes, probably, but that's a task that is beyond me for now, and honestly, I have no plans for it. In any case, if anyone is interested, I can contribute to the extent of my abilities.

No problem, whenever you feel ready and well with your implementation I can do the changes to let it run with FutureOS together. 

BTW: Can you use the 2nd register set of the Z80 already?

[GUNHED]

This is an amazing piece of work!

Thanks GUNHED!!

It would be nice if it could be implemented for SymbOS and FutureOS too.

Yes, probably, but that's a task that is beyond me for now, and honestly, I have no plans for it. In any case, if anyone is interested, I can contribute to the extent of my abilities.

No problem, whenever you feel ready and well with your implementation I can do the changes to let it run with FutureOS together. 

BTW: Can you use the 2nd register set of the Z80 already?

Great!

All that I need to do is to have a look at your source code and add pseudocodes like "IF" and "ENDIF". That way your source will generate code for different OS.

Yes, you can use all Z80 registers already and all space from &0000 to &AFFF (including all RST entry points). In addition &B000 to &B7FF can be used for buffers (but this is also used as buffer for floppy I/O).

We can wait a bit, until you are fine with your code and till some bug-reports come in (hard to tell how long it will take, depends on users communication).

I'm really looking forward to this!!! 

[ajcasado]

BTW: Can you use the 2nd register set of the Z80 already?

As far as I know, there is no restriction. I've seen them used on other platforms, but I haven't taken advantage of it (yet).

On the other side FutureOS can provide a quick kind of 'BIOS' for it. More RAM for FUZIX and more power, since the 2nd register set can be use too. While the native OS doesn't allow to use the 2nd register set of the Z80 (or only in a very time wasting way: PUSH/POP everything).

Yes, you can use all Z80 registers already and all space from &0000 to &AFFF (including all RST entry points). In addition &B000 to &B7FF can be used for buffers (but this is also used as buffer for floppy I/O).

Due to the architecture of FUZIX, having a large amount of RAM is not enough. While having more RAM allows you to run multiple processes simultaneously, for the implementation to be functional, it requires a TPA (Transient Program Area) of approximately 64k for the kernel (to explain it using CP/M terminology).

All that I need to do is to have a look at your source code and add pseudocodes like "IF" and "ENDIF". That way your source will generate code for different OS.

It doesn't seem that simple to me. My contribution to the FUZIX code is, at most, irrelevant if the goal is to use it as a base to run within another operating system. If that's your aim, you would need to patch quite a few things in the kernel written by Alan Cox. You might want to base your work on a FUZIX port for a specific type of machine running CP/M 2.2 (spoiler: the CPC is not among them): https://github.com/EtchedPixels/FUZIX/tree/master/Kernel/platform/platform-cpm22.

We can wait a bit, until you are fine with your code and till some bug-reports come in (hard to tell how long it will take, depends on users communication).

I'm really looking forward to this!!! 

Please don't misunderstand me, I think FutureOS is great, but I hope you're not getting your hopes up too much about that actually happening.

[GUNHED]

Usage of 2nd register set can be added step by step later on, this can speed up functions and routines a lot. 

No problem to switch to 64 KB banking. Then there is one system bank (of few) and program banks.
As alternative virtual memory could be used, by smart programming this wouldn't take too much CPU time.

Well, my idea was not to run Fuzix "under" FutureOS. The idea is to provide the functions of FutureOS for Fuzix. To speed it up and make it more powerful. 

One additional idea: Since FutureOS is already in ROM (no boot from disc like old fashioned OS needed, more safety, etc...) some pars of Fuzix could be put into ROM in addition. This will also save RAM.   

[Poliander]

I have ported FUZIX to the CPC6128, the port is awaiting to be merged to the oficial repository. Is available on my github account: https://github.com/ajcasado/FUZIX . The build target for make is cpc6128.

That is so awesome. I was hoping someone would do this one day!

[ajcasado]

That is so awesome. I was hoping someone would do this one day!

Thank you, I'm glad you liked it. It has been a very interesting project, and I'm happy it's finally out. If you get a chance to try it, any feedback or suggestions would be more than welcome. I hope you enjoy it!

[ajcasado]

Usage of 2nd register set can be added step by step later on, this can speed up functions and routines a lot. 

I'd like to explore that possibility, but I'm still taking my first steps with assembly language. Could you point me to some usage examples to get started with it?

No problem to switch to 64 KB banking. Then there is one system bank (of few) and program banks.
As alternative virtual memory could be used, by smart programming this wouldn't take too much CPU time.

Ok. I thought that &AFFF was the limits. Regarding the RSTs, Fuzix uses them for its syscalls and system interrupts. Some patching here and there would be needed for FutureOS and Fuzix to coexist. In the README of the Fuzix port for CP/M 2.2, which I linked in the previous post, it discusses how to handle interrupts.

Well, my idea was not to run Fuzix "under" FutureOS. The idea is to provide the functions of FutureOS for Fuzix. To speed it up and make it more powerful. 

Yes, I understand your point of view, although using your low-level routines for the implementation of FUZIX wouldn't be a bad idea and would save a lot of work.

One additional idea: Since FutureOS is already in ROM (no boot from disc like old fashioned OS needed, more safety, etc...) some pars of Fuzix could be put into ROM in addition. This will also save RAM.   

There are FUZIX ports implemented in ROM, such as the MSX1, but the memory model of the CPC is different. For the CPC, it might be possible to put part of the kernel in ROM and other in  RAM, perhaps based on the ZX128 (toastrack) where most of kernel resides in banks mapped between c000 and ffff: https://github.com/EtchedPixels/FUZIX/blob/master/Kernel/platform/platform-zx128/README .

[ajcasado]

It seems that the IDE driver might not be broken after all. The issue is that I don't have one on hand to test it on my 664, so I'm relying on incomplete emulation. Is anyone willing to test it on a real machine?