Port of FUZIX for the CPC6128

[GUNHED]

Looking forward to your work. You did an amazing job already! 

[zhulien]

I'm wondering the use case that requires some memory to be paged in always, you can disable interrupts and swap memory out and when you want it back, re-enable interrupts.

Do you have an example fuzix memory map and how this common memory is used and why it must be mapped in always?

[ajcasado]

In the Fuzix repository, you have a lot of documentation and examples of implementations on various machines with different memory management.

https://github.com/EtchedPixels/FUZIX

[zhulien]

Looking at the code what they have done is put the function implementations in the shared memory instead of in a bank, so they are really wasting an opportunity.  I think they should have put small stubs at worst there which ba k switch to the implementations.  Maybe it is a hangover from UZI or the c compiler they use requires too much trickery to build in multiple banks.  If they had a single entry point they could have avery tiny memory footprint in user area. I'm not sure whst unix norms are but you could also argue unix norms are on z80s, so why try conform in other ways.

If I tried to tackle this I would create a globalstub namespace to replace the current global one and put the global one into another bank. At least try to.

[ajcasado]

Honestly, I haven't delved deeply enough into the handling of banked memory in this context, and my understanding of its technical intricacies remains quite limited. However, this is something I plan to tackle when implementing a memory model based on the Cromemco port for the CPC port, if possible. As I mentioned in previous posts, this is a goal I have in mind, and I believe that implementation could offer an interesting foundation to explore possible improvements in memory management and footprint optimization in the user area.

[Poliander]

@ajcasado

I was able to test Fuzix using a CPC 664 with a X-MEM/X-MASS connected to it. After writing the image to the DiskOnModule using "dd" in Linux, I verified the transfer using fdisk, which showed me four partitions of unknown type. After "|cpm", Fuzix booted up and also detected the DiskOnModule, but then it failed to mount the partition:

[ajcasado]

Thank you very much for the test @Poliander .

It seems it hasn't parsed the MBR correctly to read the partition table information. More work for the to-do list.

[Poliander]

@ajcasado 

I am happy to help with testing where I can. SymbOS is an amazing GUI operating system, which would be perfectly complemented by Fuzix as a server operating system. Imagine this combination.

[ajcasado]

I've managed to get the IDE driver working in the ACE-DL emulator; it looks like the x-mass support is complete enough for FUZIX's generic driver to run (nice job @roudoudou !!). I had tried testing the IDE support in ACE-DL before, but I guess my clumsiness kept me from setting up the x-mass properly in the emulator, and I thought the emulation wasn't fully complete.

I only had to implement the low-level read and write routines for a single disk sector. Based on @Poliander's test results, I initially thought the issue was with interpreting the MBR, but after digging through the code, I found that it uses the same routines as the CH376 driver from the Albireo to read the partition table, and these work correctly. So, by elimination, I figured out the problem was in the low-level routines I had written earlier. You can download the IDE device or albireo USB device image, a snapshot, and a dsk for booting at the following link (to boot from the dsk, you need to run |cpm, while with the sna, you can just load it) FUZIX_CPC . First and second partitions on the HD image can be used as bootdevice, the third is the swap partition an the fourth is unformated and can be used to play with the FUZIX tools as mkfs, etc.

Now that FUZIX can run in the emulator, I hope it'll be easier to fix the floppy driver. The support for debugging the disk controller with ACE-DL is fantastic; it's already been a huge help in writing the FUZIX floppy loader.

@Poliander, it would be great if you could confirm that it also works on a real x-mass. If any other volunteers could test it with a Symbiface, that would be even better!

[Poliander]

@ajcasado

I can confirm it does work! (Tested on a CPC 664 / X-MASS / X-MEM) Should the X-MEM already be supported or is this a work-in-progress?

[ajcasado]

Thanks a lot for the confirmation!! @Poliander.

Should the X-MEM already be supported or is this a work-in-progress?

In your case (very similar to mine, as I have a 664 expanded with @TotO 's Z-MEM), FUZIX uses 64K of the expanded RAM, so it's already partially supported. I have two ideas in mind to fully support all the expanded RAM. One is to use it as a RAM disk for swap space, and the other is to switch to a memory management model based on the Cromemco port (I'm currently using the model from the Spectrum +3). Implementing either approach isn't straightforward for me, so I'll need to study them carefully before diving into the implementation.

[d_kef]

Ha! It works with my Cyboard!
At last a dream comes true! I have Unix running on my CPC!
Very very well done @ajcasado !!!

You cannot view this attachment.

d_kef

[ajcasado]

Ha! It works with my Cyboard!
At last a dream comes true! I have Unix running on my CPC!
Very very well done ajcasado !!!

Thank you for confirming that it works, and thanks for the kind words. Making CPC users happy by bringing their unusual dreams to life is the best reward!!!

Anyway, most of the credit should go to Alan Cox; the value of my contribution is really small in comparison to his.

[ajcasado]

I've updated the boot floppy image with a bugfix in the video driver: FUZIX_CPC

[ajcasado]

I've updated the Dropbox downloads folder FUZIX_CPC with the following changes to the boot files and the root filesystem disk image:

• The system beep now works.
• The default shell is now fsh, which allows you to edit the command line and navigate the command history using the arrow keys.

[BSC]

That's really some impressive work! Nice to see that we now have another serious operating system, after SymbOS.

[genesis8]

Could you also put the files on your Github as new releases ? It's nice to watch for releases of a project.

[ajcasado]

Alright, I'll try to keep the latest usable build in the releases section of my FUZIX fork, even if it's not an official FUZIX release.

[roudoudou]

small question, will the OS fit on a single floppy?

[ajcasado]

In theory, the mini version of the root filesystem fits on a 720k floppy, but I haven't been able to test the image yet since the floppy driver isn't finished.
EDIT: The attached dsk is a raw image, not a standard cpcemu dsk image, and is in the FUZIX filesystem format.

[Prodatron]

In theory, the mini version of the root filesystem fits on a 720k floppy, but I haven't been able to test the image yet since the floppy driver isn't finished.
EDIT: The attached dsk is a raw image, not a standard cpcemu dsk image, and is in the FUZIX filesystem format.

That's interesting, I never made any thoughts about it, but what filesystem is Fuzix using?

Usually you would think, that Fuzix runs on a 128K CPC, and a CPC Floppy has 178K, so why should it not fit on a single floppy, when you only talk about the booting process.
But maybe the used filesystem has so much overhead even on small storages, what there is no place left for 128K or more file data?

[ajcasado]

That's interesting, I never made any thoughts about it, but what filesystem is Fuzix using?

In the case of Fuzix, it inherits its file system from UZI, which is an implementation of Unix V7 but with 16-bit inodes. Anyway, I haven't delved deeply into the implementation, and my knowledge of Unix file systems is limited. So, I guess for a more satisfying answer, perhaps someone in the forum with a deeper understanding of this topic could share their expertise here.

Usually you would think, that Fuzix runs on a 128K CPC, and a CPC Floppy has 178K, so why should it not fit on a single floppy, when you only talk about the booting process.

The boot image is actually a .DSK file formatted with the CPC's system format, but the information on this disk is not readable in AMSDOS or CP/M. The first 512 bytes contain the loader, which is executed with |CPM, and following that, the FUZIX binary is stored sequentially. The loader then loads this binary into RAM.
However, the FUZIX file system is not on the boot disk. To complete the boot process, the root file system must be mounted after the FUZIX binary is loaded into RAM and takes control of the CPC.
In Unix, the file system is an integral part of the operating system. For example, access to hardware devices is managed through the elements contained in the /dev directory.

[ajcasado]

Alright, I'll try to keep the latest usable build in the releases section of my FUZIX fork, even if it's not an official FUZIX release.

Here is a link to the pre-release: https://github.com/ajcasado/FUZIX/releases/tag/v0.5.0-alpha

[EtchedPixels]

That's interesting, I never made any thoughts about it, but what filesystem is Fuzix using?

Usually you would think, that Fuzix runs on a 128K CPC, and a CPC Floppy has 178K, so why should it not fit on a single floppy, when you only talk about the booting process.
But maybe the used filesystem has so much overhead even on small storages, what there is no place left for 128K or more file data

It's a fairly traditional Unix style file system with a superblock, inode table and data blocks. Directory entries are a bit larger to allow System 5 style 30 char names.

There's not a lot of overhead but a reasonable sized setup with tools is about 3.5MB of software on Z80 builds, and once all the native C compiler stuff is properly included probably will grow a bit more. In theory nothing stops someone building an exomizer or similar for it or doing some kind of runtime library binding to squash it down a bit but a full Unix system includes a lot of tools even before you get to the important stuff like being able to play Zork or Startrek

[Prodatron]

Hi Alan, nice to see you here again, and thanks a lot for the clarification!