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.