Port of FUZIX for the CPC6128

[ajcasado]

Hi,
I've managed to get the floppy driver working. The code is hardcoded to assume two floppy drives: the first one (drive A  - /dev/fd0) is single-sided, and the second one (drive B - /dev/fd1) is double-sided. The format is fixed to 9 sectors of 512 bytes per track, numbered from 1 to 9, with a GAP3 value of &2A. The number of tracks isn't predefined, but if the range allowed by the drive is exceeded, an I/O error occurs.

I've added a function to the Makefile to generate a DSK file with a minimal 720k root filesystem for drive B, which can be selected as fd1 at the bootdev: prompt during boot. However, it's not very practical (yet) since it still needs either an IDE device or the Albireo's USB storage for swap space.

You can download it from: https://github.com/ajcasado/FUZIX/releases/tag/v0.5.0-alpha2

There is also a dsk image of a 40 tracks single sided floppy that can be formatted using mkfs from FUZIX

[ajcasado]

I've tested the FUZIX utilities dosdir, dosread, doswrite, and dosdel, and they work with a FAT12 720k formatted disk on /dev/fd1.

[ajcasado]

Hi,
I've managed to add support for standard RAM expansions to be used as RAM disk for swap space in FUZIX. For this purpose, I created a new platform in the FUZIX platform tree called CPC6128-SME.

The size of the RAM expansion isn't automatically detected; it needs to be set in the config.h file before compilation.

Two expansion sizes are supported: 512k and 1024k. I've uploaded the corresponding builds for both sizes to https://github.com/ajcasado/FUZIX/releases.

With this version, you can run FUZIX using only a floppy drive, as long as you have a standard RAM expansion of at least 512k and a 3.5" floppy disk drive or a device capable of emulating one well enough.

[ajcasado]

With this version, you can run FUZIX using only a floppy drive, as long as you have a standard RAM expansion of at least 512k and a 3.5" floppy disk drive or a device capable of emulating one well enough.

Whether this is actually useful is pretty debatable, but at the very least, it's definitely a challenge!

[ajcasado]

Following the guidance of @EtchedPixels (Alan Cox), I've merged both CPC6128 ports and documented the use of extended RAM as swap space, as well as how to build the port with the desired swap option, in the README file in https://github.com/ajcasado/FUZIX/tree/master/Kernel/platform/platform-cpc6128

[ajcasado]

I've tested the 512k RAM disk version with the root filesystem image for floppy disk using the Usifac II floppy disk emulation by @ikonsgr , and it seems to work. The corresponding fuzix.dsk is loaded with |mg, and root.dsk with |mg2. Then, the emulation is activated with |fdc, and FUZIX is loaded using |cpm. After that, the image change button is pressed, and at the bootdev prompt, fd1 is inserted as boot device.

[ajcasado]

Hi,
I've released a new version with support for the Usifac serial port, assigned to the tty2 device. You can use it as a system console, for example, by connecting a PC to the Usifac on the CPC via a serial port and using PuTTY or similar serial terminal applicaton. It can also be used with the native FUZIX network driver, which runs in user space, using the SLIP protocol. However, due to the way this FUZIX port handles memory for user applications —where task switching relies on swap— running the netd-slip driver slows everything down significantly. More details here: cpc6128 README

The video driver has been modified to use character fonts directly from the firmware ROM instead of copying them into the kernel's RAM space. This frees up 2048 bytes of memory for the kernel. Cursor handling has also been improved: now, when the cursor is drawn, the overlapped byte is saved and restored when the cursor is removed. Since video is managed in RAM mode C3, I had to implement a workaround for the CPC 464, 472, and 664, where reading from the RAM block at &4000-&7FFF in C3 mode actually reads from the ROM. A dedicated driver for the 6128 could be made to be faster, but this one works fine on the 6128 as well.

I've also modified the dosread, doswrite, dosdir, and dosdel applications to support FAT16 partitions on fixed disks, in addition to floppy drives. In the root system image for fixed disks, I've included a FAT16 partition that can be accessed with these utilities. Be careful with dosdir, as it has a bug that causes the recursive directory listing to loop endlessly on the root directory of the selected media. You can simply press Ctrl+C to stop the process, as usual.

For now, I'm putting this port on hold to focus on a new port using the thunked memory model: Z80Thunked.md This will involve switching memory in 64K blocks using modes &C2, &CA, &D2, &DA, etc. I'm planning to start by using the Cromemco port as a base. As previously discussed in this thread, this memory management model should allow multiple user processes to be loaded in RAM simultaneously and also that processes take up more than 48K, probably at least 60K.. Given that I plan to reserve the first 64K block for video RAM and the second for the kernel, the number of processes that can be loaded in RAM will depend on how many additional 64K blocks are available beyond the first 128K installed. Additionally, I expect to increase the number of managed processes by using swap on disk.

By reserving the first 64K for video RAM, it will be possible to have up to four local video terminals open at the same time (at least three, unless I can prevent the RST jump table from interfering with a terminal that uses the lower 16K). Overscan can also be used for video terminals, though this will reduce the maximum number of terminals that can be open simultaneously.

Another possible use for the first 64K block could be to load a patched firmware and run native applications that use the firmware from FUZIX. I haven't fully thought this through yet, but it's on my list of future experiments.

In the meantime, you can grab the latest release of this port here: https://github.com/ajcasado/FUZIX/releases/tag/v0.5.0-alpha4

[zhulien]

If you consider terminals being text only, then you can use a buffer for the terminals in their residing banks and only when necessary to render the display, copy them to video ram. You can do the same with gfx screens too but of course a terminal takes a lot less ram.

[ajcasado]

If you consider terminals being text only, then you can use a buffer for the terminals in their residing banks and only when necessary to render the display, copy them to video ram. You can do the same with gfx screens too but of course a terminal takes a lot less ram.

Thanks for the suggestion @zhulien , that's something I had in mind for the existing 128K port, for now, I don't expect to work on it, but if you want to experiment with this idea i'll be glad to assist you in anything you need, the sources are on FUZIX github repository: https://github.com/EtchedPixels/FUZIX/tree/master , also on my fork, where you can download precompiled releases of the 128k port: https://github.com/ajcasado/FUZIX/releases/tag/v0.5.0-alpha4 .

Terminals (TTY's) are managed in the kernel memory space, so the buffer should be in that space, where there's not much room left. An alternative would be using RAM disk or even a fixed disk, which isn't much slower than a RAM disk which code is not very optimized. The RAM disk driver rd_cpcsme.c could be optimized quite a bit by replacing LDIR with POP-PUSH approach, interleaving bank switches between the source and destination banks, without relying on a pivot buffer. I've seen this technique used in the Cromemco port, specifically in bankfork function, which I've already adapted for the CPC.

If using disk or RAM disk, space is not as limited, and given that text rendering isn't very fast, storing the video memory in raw format might be better—perhaps with a compression algorithm that works well on the Z80.

Right now, I'm adapting the Cromemco port into something functional on the CPC, as I mentioned in my previous post. In this case, since the first 64K (visible to the CRTC) currently have no other use, I'll try using four terminals, each occupying one of the four 16K blocks as video memory. If I manage to implement overscan and find that the resulting number of terminals are not enough for a satisfactory OS experience, I'll probably implement the buffer you suggested to increase the number of terminals. This could even allow for a virtual terminal size larger than the rendered area, using a combination of cursor + shift or cursor + control to move the rendered window over the terminal buffer. I'll see how far I can take it.

[zhulien]

I will see if i can make sense of it.

[ajcasado]

Hi everyone,
I've just uploaded to GitHub the new port of FUZIX for the Amstrad CPC with standard memory expansion. As I mentioned earlier, this port uses a more advanced memory model, which I explain here: README

The port is still in an early and not very mature state, but in my humble opinion, it's enough to show that this is the right path to keep developing FUZIX for our beloved machines.

For now, it supports 512K RAM expansions, allowing up to 7 user processes to run simultaneously in memory, with a size limit of 60K per process. It also implements two simultaneous terminals, and you can switch between them using CTRL+SHIFT+F1 and CTRL+SHIFT+F2.

For more info check the previous link to the README file or feel free to ask anything here.

You can download it from:FUZIX CPC SME

[ajcasado]

By the way, a very good reference for a UNIX version very similar to FUZIX can be found here: UNIX V7 Manuals

[d_kef]

Hi everyone,
I've just uploaded to GitHub the new port of FUZIX for the Amstrad CPC with standard memory expansion. As I mentioned earlier, this port uses a more advanced memory model, which I explain here: README

The port is still in an early and not very mature state, but in my humble opinion, it's enough to show that this is the right path to keep developing FUZIX for our beloved machines.

For now, it supports 512K RAM expansions, allowing up to 7 user processes to run simultaneously in memory, with a size limit of 60K per process. It also implements two simultaneous terminals, and you can switch between them using CTRL+SHIFT+F1 and CTRL+SHIFT+F2.

For more info check the previous link to the README file or feel free to ask anything here.

You can download it from:FUZIX CPC SME

Excellent!!!
If you consider to implement Ethernet connectivity, Net4CPC is a good candidate given the fact that there is already support for Wiznet W5100/W5300 in the FUZIX project.

d_kef

[ajcasado]

Hi everyone,
I've just uploaded to GitHub the new port of FUZIX for the Amstrad CPC with standard memory expansion. As I mentioned earlier, this port uses a more advanced memory model, which I explain here: README

The port is still in an early and not very mature state, but in my humble opinion, it's enough to show that this is the right path to keep developing FUZIX for our beloved machines.

For now, it supports 512K RAM expansions, allowing up to 7 user processes to run simultaneously in memory, with a size limit of 60K per process. It also implements two simultaneous terminals, and you can switch between them using CTRL+SHIFT+F1 and CTRL+SHIFT+F2.

For more info check the previous link to the README file or feel free to ask anything here.

You can download it from:FUZIX CPC SME

Excellent!!!
If you consider to implement Ethernet connectivity, Net4CPC is a good candidate given the fact that there is already support for Wiznet W5100/W5300 in the FUZIX project.

d_ke

Yes, I had taken that into account; in fact, the support seems very mature. The case is that it might take me a while to get a Net4CPC to debug, as it currently only seems available in DIY mode and I'm short on time. Anyway, I can make a preliminary attempt if someone is willing to try it out with their own Net4CPC.

[d_kef]

Hi everyone,
I've just uploaded to GitHub the new port of FUZIX for the Amstrad CPC with standard memory expansion. As I mentioned earlier, this port uses a more advanced memory model, which I explain here: README

The port is still in an early and not very mature state, but in my humble opinion, it's enough to show that this is the right path to keep developing FUZIX for our beloved machines.

For now, it supports 512K RAM expansions, allowing up to 7 user processes to run simultaneously in memory, with a size limit of 60K per process. It also implements two simultaneous terminals, and you can switch between them using CTRL+SHIFT+F1 and CTRL+SHIFT+F2.

For more info check the previous link to the README file or feel free to ask anything here.

You can download it from:FUZIX CPC SME

Excellent!!!
If you consider to implement Ethernet connectivity, Net4CPC is a good candidate given the fact that there is already support for Wiznet W5100/W5300 in the FUZIX project.

d_ke

Yes, I had taken that into account; in fact, the support seems very mature. The case is that it might take me a while to get a Net4CPC to debug, as it currently only seems available in DIY mode and I'm short on time. Anyway, I can make a preliminary attempt if someone is willing to try it out with their own Net4CPC.

That's great news!!!
I'm more than willing to test it out of course. Also, I have a spare Net4CPC if you are interested.

d_kef

[ajcasado]

Glad to have you as tester, also eager to have a Net4CPC.

[ajcasado]

Hi everyone,
A new release of FUZIX for the Amstrad CPC is now available!
https://github.com/ajcasado/FUZIX/releases/tag/v0.5.1-alpha2

From the release notes:

"This release is the first for this platform using the thunked memory model that appears somewhat stable.
It supports up to 1024 KB of expanded RAM, automatically detecting the installed memory size.
Verified to work with 512 KB and 1024 KB of expanded RAM. It should work with any size between those two values; below 512 KB, operation is not guaranteed. Any feedback is welcome.
It is compiled with support for the Net4CPC expansion of  @d_kef  , although this feature is a work in progress and therefore experimental.
The fuzix.dsk image is used to load Fuzix from basic with run"fuzix". The root.dsk image is the root filesystem with a minimal layout for a 3.5" external floppy drive (enter fd1 at the boot prompt). disk.img is a mass storage image with four partitions: hda1 and hda2 contain a full root system, hda3 is a swap partition (a feature not yet implemented), and hda4 is a FAT16 partition that can be accessed with dosdir, dosread, doswrite, and dosdel.
fuzixcpc.sna is an alternative loading snapshot for fuzix.dsk.
For more information https://github.com/ajcasado/FUZIX/tree/master/Kernel/platform/platform-cpcsme#readme "

[Prodatron]

Thanks for the update!
Very interesting, I'm a little curious, what is the reason for the maximum memory size of 1024 KB?

[ajcasado]

For several reasons. First, the default maximum number of processes is 15, as explained here: https://github.com/EtchedPixels/FUZIX/blob/master/docs/Process.rst (look for PTABSIZE explanation). With the memory model used, each process needs a 64KiB block, and with 1024KiB of RAM we get exactly 15 processes — so supporting more RAM wouldn't bring much benefit initially.
Second, much of the reused code uses 8-bit integers to store the 64K page ID. On the CPC, this ID must be converted to 16 bits to select the memory page via register BC executing out (c),c, varying B between &7C and &7F and C between &C2 and &FA to access up to 2MiB (which seems to be the standard and common maximum). By using only 1MiB, I can rely on this simpler routine (any suggestions to improve it are welcome):

Code Select Expand

a_map_to_bc: ; set BC for page ID in A
    bit 6, a
    jr nz, lower_512
    set 6, a
    ld b, #0x7e
    jr ld_ca_and_ret
lower_512:
    ld b, #0x7f
ld_ca_and_ret:
    ld c, a
    ret
This works with page IDs from the set {&82, &8a, &92, &9a, ..., &e2, &ea, &f2, &fa} (&c2 is not in this set as is reserved for Kernel).
Supporting more memory would require expanding the page ID range and complicating a_map_to_bc, but that's doable if someone really needs more than 1MiB.
Third, memory expansions larger than 1MiB are rare and lastly, I plan to implement disk swapping to increase the number of simultaneous processes even on machines with less than 1MiB of RAM — which will allow going beyond the 15-process limit.

[pollito]

@ajcasado would you consider supporting 2MB in a future release to run 30 processes? I've got a 2MB Gemini RAM expansion for my 6128, and it would be great to have something that actually takes advantage of it.

By the way, disk swapping in FUZIX on the Z80-MBC2 is horribly slow. The OS generally doesn't run well on the platform, but the 128KB of RAM and swapping really kills it.

[ajcasado]

As I mentioned earlier, adding support for up to 2 MiB isn't particularly complex. What gives me pause is whether the user experience with FUZIX will really benefit from it—at least for now. One trade-off not mentioned in the previous post is that the kernel RAM area must reserve space for the process table: increasing from 15 to 30 processes adds 1125 bytes. For now, there's enough room by reducing the number of buffers, but once I add support for the M4 board, things may get tight—or even break.
Of course, space can always be freed by removing drivers. I expect that, as more device support is added, advanced users will want to compile their own custom kernel, tailored to their hardware and tuned parameters like the number of mounts, buffers, open files, etc.
That said, the FUZIX application ecosystem is still quite immature, so it's unlikely that one could currently make real use of 2 MiB and 30 processes. But if you have a concrete use case where it's needed, I'll be happy to support it in a future release.
Regarding swap: yes, it's quite poor—especially on systems that can only hold one user process in RAM (e.g. my earlier CPC6128 port without RAM expansion), so all multitasking relies on swap. Still, I think it's worthwhile to support swapping for configurations with <1 MiB of expansion where users may want to run up to 15 processes. For instance, there are 256 KiB systems where the max number of processes doesn't even allow FUZIX to boot.

[pollito]

Would it be possible for FUSIX to detect the current hardware configuration, and then load the relevant drivers based on probing, or is that beyond 8-bit platforms? For example, detecting and using the M4, or detecting the total amount of memory, and utilising it efficiently? If not then, yes, definitely custom kernels are definitely the answer. I've been using FreeBSD for around 25 years now, and remember when compiling a custom kernel was more or less the norm!

Agreed about the swap for machines with lower memory; it's better that it works slowly than not at all. If it piques people's interest then maybe they will be more inclined to buy a RAM expansion for the complete experience.

I haven't tried FUZIX on the CPC yet, but am hoping I will have time to try out your latest release this weekend. Thank you for making it possible! 

[Prodatron]

For several reasons. [...]

Thanks a lot for the explanation!

Regarding (re)setting this 16bit port address bit for the bank switching it's very similiar to what is currently happening in SymbOS CPC, if the system has >576KB (for systems with <=576K it is patching the routines, so they run in a faster way).
For sure we could even use the 7th bit for 2MB support, which will slow down bankswitching again a little bit more, but not so much that it will really slow down the complete system.

In SymbOS I have the problem that several functions only accept 20bit addresses (4+16bits), which is 1MB, as they only use nibbles for the upper part of the address. That's currently the main reason for the 1MB limitation. No idea how this is working in Fuzix?

If I remember correctly 64K is just maximum, not the minimum for one process? (that was a shit thing in MP/M...) So you could also have 15 processes in one single 64K bank, if each is only using 4K or so, right? (like in SymbOS)

so supporting more RAM wouldn't bring much benefit initially.

Isn't it possible for one process to reserve additional memory outside of its primary 64K bank?

Thanks a lot for your work on Fuzix and sharing all the insights! For me this is always very very interesting!