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.
Here is an image:(about:invalid)
:picard:
Here is the image.
Great! One less thing on my TODO list, as I was thinking about it :D
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)
Quote from: PulkoMandy on 11:02, 13 October 24Great! One less thing on my TODO list, as I was thinking about it :D
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.
Quote from: PulkoMandy on 11:02, 13 October 24It 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.
Quote from: PulkoMandy on 11:02, 13 October 24So, 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.
Wow! That's Unix on the CPC?!? Are there some examples of working programs?
Quote from: ajcasado on 14:46, 13 October 24As 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.
Oh wow. I will have to try this.
Quote from: ajcasado on 00:07, 13 October 24The 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?
Quote from: m_dr_m on 18:12, 13 October 24Wow! 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.
Quote from: Prodatron on 20:17, 13 October 24If 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:
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.
Quote from: Prodatron on 20:17, 13 October 24I 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,
Quote from: Prodatron on 20:17, 13 October 24When 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.
Quote from: ajcasado on 23:31, 13 October 24From this file: https://github.com/ajcasado/FUZIX/blob/master/Kernel/dev/tinydisk_discard.c (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
Quote from: ajcasado on 00:07, 13 October 24Hi,
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. :) :) :)
Quote from: GUNHED on 23:34, 14 October 24This is an amazing piece of work!
Thanks GUNHED!!
Quote from: GUNHED on 23:34, 14 October 24It 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.
Quote from: GUNHED on 23:34, 14 October 24It 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 ;)
Quote from: Prodatron on 10:19, 15 October 24Quote from: GUNHED on 23:34, 14 October 24It 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.
Quote from: Prodatron on 10:19, 15 October 24Quote from: GUNHED on 23:34, 14 October 24It 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? :) :) :)
Quote from: ajcasado on 09:03, 15 October 24Quote from: GUNHED on 23:34, 14 October 24This is an amazing piece of work!
Thanks GUNHED!!
Quote from: GUNHED on 23:34, 14 October 24It 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?
Quote from: GUNHED on 17:18, 15 October 24Quote from: ajcasado on 09:03, 15 October 24Quote from: GUNHED on 23:34, 14 October 24This is an amazing piece of work!
Thanks GUNHED!!
Quote from: GUNHED on 23:34, 14 October 24It 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!!! :) :) :)
Quote from: GUNHED on 17:18, 15 October 24BTW: 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).
Quote from: GUNHED on 17:14, 15 October 24On 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).
Quote from: GUNHED on 17:43, 15 October 24Yes, 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).
Quote from: GUNHED on 17:43, 15 October 24All 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.
Quote from: GUNHED on 17:43, 15 October 24We 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.
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. :)
Quote from: ajcasado on 00:07, 13 October 24I 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!
Quote from: Poliander on 17:14, 16 October 24That 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!
Quote from: GUNHED on 22:56, 15 October 24Usage 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?
Quote from: GUNHED on 22:56, 15 October 24No 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.
Quote from: GUNHED on 22:56, 15 October 24Well, 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. :P
Quote from: GUNHED on 22:56, 15 October 24One 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 .
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?
Quote from: ajcasado on 19:57, 16 October 24It 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?
I would love to, but I have no idea how to load a snapshot with an Albireo...
:-[
Quote from: Poliander on 20:43, 16 October 24I would love to, but I have no idea how to load a snapshot with an Albireo...
Me neither, it would be a good feature to implement in Unidos. I'll see if I can make progress on a loader to boot from a file on disk.
Quote from: Poliander on 20:43, 16 October 24Quote from: ajcasado on 19:57, 16 October 24It 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?
I would love to, but I have no idea how to load a snapshot with an Albireo...
:-[
If you are able to run SymbOS and have 320K or more you can use this:
http://www.symbos.de/appinfo.htm?00012
Currently SymbOS is using the Albireo only for the mouse, but if you can boot it with another device (while the Albireo is still connected) it should work.
About 2nd register set usage: Well, the topic is pretty pleiotopic... Instead of having variables into ROM they can be in alternate registers. Also if a routine need more registers they can be used.
Providing examples is a bit hard, it really depends on what you do. Here is one of my code examples...
loop EXX
LD A,(HL) ;source
LDI ;to screen
EXX
LD (HL),A:INC L ;to buffer
OR A,C
LD (DE),A:INC E ;masked to buffer
DJNZ loop
Without 2nd register set, there would be the need of two 16 bit RAM variables and at least one 8 bit variable.
Unroll loops is also a big gain of speed of course. :)
Quote from: Poliander on 20:43, 16 October 24I would love to, but I have no idea how to load a snapshot with an Albireo...
In the following link (fuzix) (https://www.dropbox.com/scl/fo/mgl30he0cxm1g9kywr5b4/ABMpk7uBBzD0AWUE7aj5uwY?rlkey=98zim3g88nhxot73dlio21w7f&st=ssmaaa6j&dl=0), I have uploaded a floppy image to boot FUZIX with the |cpm command from BASIC and a compressed disk image to write to the device of your choice after decompressing, whether it's a USB pendrive for Albireo or the media connected to your IDE adapter. It's a raw image, if you have Linux, you can use the dd command. What I use is:
sudo dd if=disk.img of=/dev/sdX bs=512 conv=notrunc status=progressAlso there is a snapshot to boot.
I hope it works and that you can test if it's able to correctly initialize the IDE interface.
A couple of warnings:
The first is that you should not try to mount the floppy drive once FUZIX finishes booting, as the controller is very broken, and I don't know what it might do to the disk or the drive.
And the second, I'm not sure if this needs to be mentioned, but obviously, writing the compressed 64M image to your chosen media will destroy all the content previously stored on it, so use a backup or a spare disk. Also, it's worth mentioning that the name of the dd command is often humorously referred to as 'disk destroyer' for a good reason, so it should be used carefully.
Lastly, I can't be held responsible if your Amstrad explodes—I don't have the money to buy a new one. :P
Quote from: ajcasado on 16:49, 18 October 24A couple of warnings:
One more thing: before exiting FUZIX, run: shutdown , or the file system will become corrupted, and fsck will run on the next boot, which is painfully slow.
Quote from: ajcasado on 16:49, 18 October 24Lastly, I can't be held responsible if your Amstrad explodes—I don't have the money to buy a new one. :P
I might have a spare one to risk
:D
I'll use the Albireo. Will also try the X-MASS, but probably next weekend.
That's so awesome,
@ajcasado (https://i.ibb.co/NsSjLXT/IMG-4033.jpg)
(https://i.ibb.co/Cw4VYzr/IMG-4034.jpg)
I have a frickin' Unix running on my CPC :o
Very cool! :o
Quote from: Poliander on 12:55, 19 October 24That's so awesome, ajcasado (https://www.cpcwiki.eu/forum/profile/?u=1987)
Thanks!!
Quote from: Poliander on 12:55, 19 October 24I have a frickin' Unix running on my CPC :o
Me too!!
20241020_204031.jpg
Would be time for 'Someone' ;) :) to do some cool video about it! ;D
I have fixed the hardware scrolling issues and made some optimizations to certain video routines, although I believe there is still a lot to optimize and features to add in this area, it seems to be working correctly now. I have updated the snapshot file and the floppy image at the link: FUZIX_CPC (https://www.dropbox.com/scl/fo/mgl30he0cxm1g9kywr5b4/ABMpk7uBBzD0AWUE7aj5uwY?rlkey=2cdosjugw14vp1xzyg8ok0s31&st=dz2nts6b&dl=0)
I think I'm going to focus on fixing the floppy support now, to see if it's possible to create a minimal working distribution with the root system on a 3.5" disk, and use 3" disks for applications that don't fit on the 3.5" one.
The official FUZIX repository has now added the port for the Amstrad CPC, it's official!!
There are quite a few banking schemes you can use on cpc, I am sure one could potentially suit fuzix.
There is the common one of keeping main memory everywhere except between 4000 and 8000 where you can page 16kb blocks.
There is the scheme where you can page full 64kb banks with a single instruction. Only note in doing this the bank being switched in must have been pre setup with instructions following the bank swap, this method can be used for full 64kb round Robin pre emptive multitasking with very little overhead in the context switch.
There are a couple of block arrangements to facilitate copying in bulk (16kb is easiest) between 64kb banks
Its also possible to use full overscan and have full round robin multitasking with complete 64kb bank swaps... for programs, but alternative arrangements when making os calls that could be in rom, or main bank or even another bank excluded from the round Robin.
For fuzix, why does it need the common memory always paged in? Can it be common but paged in on demand? How much memory does it need to be common? If existing cpc schemes are slightly difficult, maybe... a 32kb ram expansion mapped in like a novaram could be made for those that want to run fuzix, but ideally still allowing a full 64kb application ram almost per bank. A lot of ram available if you have 4mb...
He already did the work. :)
Quote from: zhulien on 12:27, 23 October 24There are quite a few banking schemes you can use on cpc, I am sure one could potentially suit fuzix.
There is the common one of keeping main memory everywhere except between 4000 and 8000 where you can page 16kb blocks.
There is the scheme where you can page full 64kb banks with a single instruction. Only note in doing this the bank being switched in must have been pre setup with instructions following the bank swap, this method can be used for full 64kb round Robin pre emptive multitasking with very little overhead in the context switch.
There are a couple of block arrangements to facilitate copying in bulk (16kb is easiest) between 64kb banks
Its also possible to use full overscan and have full round robin multitasking with complete 64kb bank swaps... for programs, but alternative arrangements when making os calls that could be in rom, or main bank or even another bank excluded from the round Robin.
Quote from: zhulien on 12:27, 23 October 24If existing cpc schemes are slightly difficult, maybe... a 32kb ram expansion mapped in like a novaram could be made for those that want to run fuzix, but ideally still allowing a full 64kb application ram almost per bank. A lot of ram available if you have 4mb...
Well, I think I've already discussed all of this in previous posts in this topic.
Quote from: zhulien on 12:27, 23 October 24For fuzix, why does it need the common memory always paged in? Can it be common but paged in on demand?
I suppose the idea is that user processes don't need to know anything about the implementation of the operating system on the specific hardware they're running on, which is why part of the kernel (common memory) must be visible in the memory map used by user processes. In the case of the FUZIX implementation on platforms with the Z80 CPU, a good reference is this document: https://github.com/EtchedPixels/FUZIX/blob/3d0f3374d60516caeb6481a60d5556efff032232/docs/BankedZ80.md (https://github.com/EtchedPixels/FUZIX/blob/3d0f3374d60516caeb6481a60d5556efff032232/docs/BankedZ80.md)
Quote from: zhulien on 12:27, 23 October 24How much memory does it need to be common?
Well, in the case of the CPC, this is how things stand for now:
ASxxxx Linker V03.00 + NoICE + sdld, page 18.
Hexadecimal [32-Bits]
Area Addr Size Decimal Bytes (Attributes)
-------------------------------- ---- ---- ------- ----- ------------
_COMMONMEM 0000F000 00000FC3 = 4035. bytes (REL,CON)
Value Global Global Defined In Module
----- -------------------------------- ------------------------
0000F000 _ub commonmem
0000F000 _udata commonmem
0000F200 kstack_top commonmem
0000F2FE istack_switched_sp commonmem
0000F2FE istack_top commonmem
0000F300 _plt_monitor cpc6128
0000F328 _plt_reboot cpc6128
0000F335 plt_interrupt_all cpc6128
0000F336 _int_disabled cpc6128
0000F337 _vtborder cpc6128
0000F374 _program_vectors cpc6128
0000F375 map_proc cpc6128
0000F379 map_for_swap cpc6128
0000F379 map_proc_always cpc6128
0000F379 map_proc_always_di cpc6128
0000F37E map_save_kernel cpc6128
0000F386 map_kernel cpc6128
0000F386 map_kernel_di cpc6128
0000F386 map_kernel_restore cpc6128
0000F395 map_video cpc6128
0000F39A map_restore cpc6128
0000F3A0 outchar cpc6128
0000F3BC current_map cpc6128
0000F3BE _need_resched cpc6128
0000F3BF diskmotor cpc6128
0000F3EC _plot_char cpcvideo
0000F3EC cpc_plot_char cpcvideo
0000F420 _clear_lines cpcvideo
0000F420 cpc_clear_lines cpcvideo
0000F43A _clear_across cpcvideo
0000F43A cpc_clear_across cpcvideo
0000F480 _scroll_up cpcvideo
0000F480 cpc_scroll_up cpcvideo
0000F490 _scroll_down cpcvideo
0000F490 cpc_scroll_down cpcvideo
0000F4A3 _cursor_on cpcvideo
0000F4A3 cpc_cursor_on cpcvideo
0000F4BC _cursor_disable cpcvideo
0000F4BC _cursor_off cpcvideo
0000F4BC cpc_cursor_disable cpcvideo
0000F4BC cpc_cursor_off cpcvideo
0000F4CF _do_beep cpcvideo
0000F4CF cpc_do_beep cpcvideo
0000F519 _curattr cpcvideo
0000F55C unix_syscall_entry lowlevel
0000F5D0 _doexec lowlevel
0000F5E4 null_handler lowlevel
0000F5F6 synchronous_fault lowlevel
0000F61D nmi_handler lowlevel
0000F625 interrupt_handler lowlevel
0000F635 mmu_irq_ret lowlevel
0000F6A2 preemption lowlevel
0000F6EC outstring lowlevel
0000F6F5 outstringhex lowlevel
0000F703 outnewline lowlevel
0000F70D outhl lowlevel
0000F718 outbc lowlevel
0000F723 outde lowlevel
0000F72E outcharhex lowlevel
0000F73F outnibble lowlevel
0000F74C _out lowlevel
0000F752 _out16 lowlevel
0000F75A _in16 lowlevel
0000F75B _in lowlevel
0000F75F ___hard_ei lowlevel
0000F765 ___hard_di lowlevel
0000F76E ___hard_irqrestore lowlevel
0000F798 __uputc usermem
0000F7A5 __uputw usermem
0000F7B4 __ugetc usermem
0000F7BD __ugetw usermem
0000F7C7 __uput usermem
0000F7E9 __uget usermem
0000F807 __uzero usermem
0000F823 _plt_switchout tricks
0000F861 _switchin tricks
0000F8D0 _dofork tricks
0000F9B1 _devide_read_data cpcide
0000FAB8 _devide_write_data cpcide
0000FBC2 _fd765_do_nudge_tc fdc765
0000FBF3 _fd765_status fdc765
0000FC04 _fd765_do_recalibrate fdc765
0000FC11 _fd765_do_seek fdc765
0000FC21 _fd765_track fdc765
0000FC22 _fd765_sector fdc765
0000FC23 _fd765_head fdc765
0000FC24 _fd765_drive fdc765
0000FC63 _fd765_motor_off fdc765
0000FC6F _fd765_motor_on fdc765
0000FC8E _fd765_do_read fdc765
0000FD1F _fd765_do_write fdc765
0000FDC9 _fd765_buffer fdc765
0000FDCB _fd765_is_user fdc765
0000FDCC _fd765_sectors fdc765
0000FDCD _fd765_do_read_id fdc765
0000FDD8 _ch375_rblock albireo
0000FECC _ch375_wblock albireo
Does it have dozens of OS entry points spread across a huge amount of memory? Or does it have a single or very few entry points?
If 1 or a few, it can page in the OS as called and page it out before returning. If many spread across a huge amount of address space unfortunately not a lot can be done.
Just for clarification, the application isn't doing the paging, its the os upon being called. Cpm plus on cpc works like this to take almost none of the 64k but have the implementation in another bank.
Maybe fuzix is putting such things as buffers in shared space and giving direct access to them rather than a handle?
From the reference link in the previous post:
Common: This holds code and data that must remain mapped at all times, including bank switching code, functions that copy memory to user banks and the data transfer routines for disk I/O. If you are familiar with CP/M 3 common memory the approach is similar except that less needs to be in common space. The common space for the banked model starts with 768 bytes of udata and stack. This holds data specific to the current process that can be swapped out with that process, and which is only needed when that process is running.
i noticed there was a CPM2.2 version of fuzix....
..im wondering if that would have been a better starting point... apparently its very basic but not hard to implement the extras...
id also love to see this on a M4 board.. anyone tried?.. im guessing it would need dedicated code to access the M4 and the SD card..
Quote from: Brocky on 05:10, 24 October 24i noticed there was a CPM2.2 version of fuzix....
..im wondering if that would have been a better starting point... apparently its very basic but not hard to implement the extras...
It's interesting that you mention CP/M 2.2, but after reading Alan Cox's README for this port, it seems like it wouldn't be the best starting point for the Amstrad. The document specifies the following requirements:
A system with CP/M 2.2 support, at least three memory banks that can be mapped into the lower address space, and common space above that. The memory banks need to be at least 32K in size. In other words, a typical MP/M capable platform.Unfortunately, none of the Amstrad's memory maps meet these conditions, so while it might seem like an option, it wouldn't be a practical fit for this platform.
Quote from: ajcasado on 20:53, 24 October 24Quote from: Brocky on 05:10, 24 October 24i noticed there was a CPM2.2 version of fuzix....
..im wondering if that would have been a better starting point... apparently its very basic but not hard to implement the extras...
It's interesting that you mention CP/M 2.2, but after reading Alan Cox's README for this port, it seems like it wouldn't be the best starting point for the Amstrad. The document specifies the following requirements:
A system with CP/M 2.2 support, at least three memory banks that can be mapped into the lower address space, and common space above that. The memory banks need to be at least 32K in size. In other words, a typical MP/M capable platform.
Unfortunately, none of the Amstrad's memory maps meet these conditions, so while it might seem like an option, it wouldn't be a practical fit for this platform.
ahh yes... i remember reading that now you mention it!...
i was looking to port fuzix myself about a month before you posted your port, but i honestly had no clue how to do it! LOL
i was also thinking about porting CollapseOS..just need to read some more to work out how!
Quote from: ajcasado on 20:53, 24 October 24Quote from: Brocky on 05:10, 24 October 24i noticed there was a CPM2.2 version of fuzix....
..im wondering if that would have been a better starting point... apparently its very basic but not hard to implement the extras...
It's interesting that you mention CP/M 2.2, but after reading Alan Cox's README for this port, it seems like it wouldn't be the best starting point for the Amstrad. The document specifies the following requirements:
A system with CP/M 2.2 support, at least three memory banks that can be mapped into the lower address space, and common space above that. The memory banks need to be at least 32K in size. In other words, a typical MP/M capable platform.
Unfortunately, none of the Amstrad's memory maps meet these conditions, so while it might seem like an option, it wouldn't be a practical fit for this platform.
You could use RAM configurations &C2, &CA, &D2, &DA etc...
And for switching between them use &C1, &C9, &D1, &D9 etc...
But probably you do that already. :) :) :)
Quote from: GUNHED on 09:52, 25 October 24You could use RAM configurations &C2, &CA, &D2, &DA etc...
And for switching between them use &C1, &C9, &D1, &D9 etc...
But probably you do that already. :) :) :)
Yes, I use &c1 for the kernel map, &c2 for the user map, and &c3 for the video output routines, so the 16k page #7 acts as common memory. However, when switching between 64k banks with maps >=&ca and >=&c9, page #7 is taken out of the map, access to common memory is lost, and everything stops working.
Yes, they need memory expansions. But I guess with 512KB or better 4 MB Fuzix will just start to be really useful. More 64 KB banks, more applications in RAM. :) :) :)
Yes, of course, but I mean that when using a memory expansion, if maps with values higher than &c7 for the MMR register of the GA are used, the common kernel memory area (the upper 16k of the second 64k) is removed from the visible map for the CPU. So, with the current setup, the expansions can only be used as RAM disk for the swap area. It's not a bad solution, but it's not the best.
Looking forward to your work. You did an amazing job already! :) :) :)
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?
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
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.
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.
@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:
(https://i.ibb.co/qnnt8Lj/IMG-4043.jpg)
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.
@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.
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 (https://www.dropbox.com/scl/fo/mgl30he0cxm1g9kywr5b4/ABMpk7uBBzD0AWUE7aj5uwY?rlkey=98zim3g88nhxot73dlio21w7f&st=a8ic3ngb&dl=0) . 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!
@ajcasado I can confirm it does work! :D (Tested on a CPC 664 / X-MASS / X-MEM) Should the X-MEM already be supported or is this a work-in-progress?
(https://imguploader.de/images/2024/11/10/IMG_4047.jpg)
(https://imguploader.de/images/2024/11/10/IMG_4048.jpg)
Thanks a lot for the confirmation!!
@Poliander.
Quote from: Poliander on 09:53, 10 November 24Should 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.
Ha! It works with my Cyboard!
At last a dream comes true! I have Unix running on my CPC! :D :D :D
Very very well done
@ajcasado !!!
fuzix1.png
d_kef
Quote from: d_kef on 20:16, 12 November 24Ha! It works with my Cyboard!
At last a dream comes true! I have Unix running on my CPC! :D :D :D
Very very well done ajcasado (https://www.cpcwiki.eu/forum/profile/?u=1987) !!!
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!!! :laugh:
Anyway, most of the credit should go to Alan Cox; the value of my contribution is really small in comparison to his.
I've updated the boot floppy image with a bugfix in the video driver: FUZIX_CPC (https://www.dropbox.com/scl/fo/mgl30he0cxm1g9kywr5b4/ABMpk7uBBzD0AWUE7aj5uwY?rlkey=98zim3g88nhxot73dlio21w7f&st=p7py8vay&dl=0)
I've updated the Dropbox downloads folder FUZIX_CPC (https://www.dropbox.com/scl/fo/mgl30he0cxm1g9kywr5b4/ABMpk7uBBzD0AWUE7aj5uwY?rlkey=98zim3g88nhxot73dlio21w7f&st=qcswhpvw&dl=0) 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.
That's really some impressive work! Nice to see that we now have another serious operating system, after SymbOS.
Could you also put the files on your Github as new releases ? It's nice to watch for releases of a project.
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.
small question, will the OS fit on a single floppy?
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.
Quote from: ajcasado on 21:10, 02 December 24In 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?
Quote from: Prodatron on 22:00, 02 December 24That'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.
Quote from: Prodatron on 22:00, 02 December 24Usually 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.
Quote from: ajcasado on 14:48, 02 December 24Alright, 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
Quote from: Prodatron on 22:00, 02 December 24That'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
Hi Alan, nice to see you here again, and thanks a lot for the clarification!
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
I've tested the FUZIX utilities dosdir, dosread, doswrite, and dosdel, and they work with a FAT12 720k formatted disk on /dev/fd1.
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.
Quote from: ajcasado on 23:26, 15 January 25With 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!
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
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.
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 (https://github.com/ajcasado/FUZIX/tree/master/Kernel/platform/platform-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 (https://github.com/EtchedPixels/FUZIX/blob/master/docs/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
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.
Quote from: zhulien on 12:46, 18 March 25If 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 (https://github.com/ajcasado/FUZIX/blob/master/Kernel/platform/platform-cpc6128/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 (https://github.com/EtchedPixels/FUZIX/blob/master/Kernel/platform/platform-cromemco/tricks.s#L319), 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.
I will see if i can make sense of it.
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 (https://github.com/ajcasado/FUZIX/tree/master/Kernel/platform/platform-cpcsme#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 (https://github.com/ajcasado/FUZIX/releases/tag/v0.5.1-alpha)
By the way, a very good reference for a UNIX version very similar to FUZIX can be found here: UNIX V7 Manuals (http://web.archive.org/web/20201112034807/http://a.papnet.eu/UNIX/v7/files/doc/)
Quote from: ajcasado on 13:28, 11 April 25Hi 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 (https://github.com/ajcasado/FUZIX/tree/master/Kernel/platform/platform-cpcsme#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 (https://github.com/ajcasado/FUZIX/releases/tag/v0.5.1-alpha)
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
Quote from: d_kef on 13:55, 11 April 25Quote from: ajcasado on 13:28, 11 April 25Hi 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 (https://github.com/ajcasado/FUZIX/tree/master/Kernel/platform/platform-cpcsme#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 (https://github.com/ajcasado/FUZIX/releases/tag/v0.5.1-alpha)
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.
Quote from: ajcasado on 14:22, 11 April 25Quote from: d_kef on 13:55, 11 April 25Quote from: ajcasado on 13:28, 11 April 25Hi 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 (https://github.com/ajcasado/FUZIX/tree/master/Kernel/platform/platform-cpcsme#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 (https://github.com/ajcasado/FUZIX/releases/tag/v0.5.1-alpha)
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
Glad to have you as tester, also eager to have a Net4CPC.
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 (https://github.com/ajcasado/FUZIX/tree/master/Kernel/platform/platform-cpcsme#readme) "
Thanks for the update!
Very interesting, I'm a little curious, what is the reason for the maximum memory size of 1024 KB?
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 (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):
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.
@ajcasado would you consider supporting 2MB in a future release to run 30 processes? I've got a 2MB Gemini RAM expansion (https://pulkomandy.github.io/shinra.github.io/gemini.html) 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 (https://github.com/EtchedPixels/FUZIX/issues/1167), but the 128KB of RAM and swapping really kills it.
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.
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! :D
Quote from: ajcasado on 17:19, 04 June 25For 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)
Quote from: ajcasado on 17:19, 04 June 25so 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!
I wonder with such addressing schemes whether you could adopt something like this. That is let's say you have 2mb ram, there shouldn't be any reason the processes can't be e.g. in the upper 1mb, then allow thr heap to be in the lower 1mb. This could effectively double the amount of ram assuming processes don't need to directly read from each others ram. Now for reading from their own ram... maybe it can be 1mb - 64kb for the heap space, and the processes own 64kb is also accessible. 64kb lost from processes but... use it for fuzix kernel buffers or something... like text screens.
Quote from: pollito on 21:41, 05 June 25Would 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!
It looks like this is planned, there's already some code to support dynamic kernel module loading, with a config option (CONFIG_KMOD) to enable it. However, it doesn't seem to be functional yet: I haven't seen this option enabled on any platform, and there are no working examples of it in use.
Quote from: Prodatron on 22:21, 05 June 25Regarding (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).
The patching approach sounds like an elegant and clever solution—I hadn't thought of that. I'll definitely keep it in mind for the future.
Quote from: Prodatron on 22:21, 05 June 25In 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?
There is support for function calls across kernels distributed in different banks using more than 16-bit addressing, but I haven't looked into that in detail, since the ports I've worked on use a single 64 KiB kernel bank. As for user processes, only 16-bit addressing is used.
Quote from: Prodatron on 22:21, 05 June 25If 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)
As far as I know, on platforms with banked memory where address spaces overlap, only one process runs per user memory map—in this case, per 64K bank.
Quote from: Prodatron on 22:21, 05 June 25Isn't it possible for one process to reserve additional memory outside of its primary 64K bank?
In our case, that's not supported.
Quote from: Prodatron on 22:21, 05 June 25Thanks a lot for your work on Fuzix and sharing all the insights! For me this is always very very interesting!
You're welcome! I'm happy to clarify anything about the implementation I'm working on. As for deeper questions about the inner workings of Fuzix, my understanding is limited—I try to answer as best I can, but I think
@EtchedPixels could shed much more light on these topics with real authority.
Quote from: zhulien on 18:01, 07 June 25I wonder with such addressing schemes whether you could adopt something like this. That is let's say you have 2mb ram, there shouldn't be any reason the processes can't be e.g. in the upper 1mb, then allow thr heap to be in the lower 1mb. This could effectively double the amount of ram assuming processes don't need to directly read from each others ram. Now for reading from their own ram... maybe it can be 1mb - 64kb for the heap space, and the processes own 64kb is also accessible. 64kb lost from processes but... use it for fuzix kernel buffers or something... like text screens.
I don't see a straightforward way for code running in a 64K bank—which doesn't share a common area with other banks—to efficiently work with data located in other banks. The lack of a shared memory region between banks makes inter-bank data access complex and slow, especially on 8-bit platforms.
The Fuzix memory manager is designed to let you plug anything into it because machines are so weird and wonderful (or not) and because of course a 68000 is quite different to a Raspberry Pi Pico or a classic banked Z80 box.
I think the theoretical limit for 8bit is 65535 64K processes but the rest of the OS would break rather sooner. The largest box it runs on is a 16MB 68000 and to be honest quite what to do with most of that RAM is a mystery.
There's no provision for RAM from other banks. It doesn't fit the unix model and the goal is to be portable so we also have to run on systems that have really crude memory management options. Also the logic is that copying to or from other banks is really a ram disc and a ram disc is just a bad cache so just use files. In fact of course with a current CF card interface the ram disc is often slower than the CF anyway 8) . Fuzix does go to the trouble of being clever with direct block aligned copies going between disk and user memory without buffering and that's sufficient that you can happily play infocom games, quill stuff, level 9 games and a load more things without problems, and is plenty fast enough for the C compiler to use between passes.
I finally received the Net4CPC kindly donated to me by
@d_kef , and the Fuzix driver seems to work partially—ping doesn't work, nor does IP resolution via DNS, but using the servers' IP addresses, telnet does work.
Here are some images of a session using a PuTTY client on a PC connected via serial port to a CPC with USIfAC running Fuzix:
That's the most interesting and maybe the most strange thing: a PC used as a terminal for an Amstrad CPC server connected to BBS through the internet!!!
Try to explain this to a teenager. :laugh:
d_kef
Indeed, when I first saw the second screenshot, I actually thought there was a BBS server for Fuzix running there on the CPC :D
Very nice! Eventually an useful usage for a PC. :P
Hi everyone,
I'm happy to announce a new release of the Fuzix build for Amstrad CPC, featuring several improvements—most notably, enhanced support for USB mass storage devices.
The CH376 driver has been significantly improved and now supports up to three USB mass storage devices at the same time. Two of them can be connected via the Albireo expansion, with one using the alternative I/O address. The third can be connected through the Usifac or Ulifac interface, as the driver is now capable of handling both parallel and serial CH376 modules.
In addition, the low-level I/O routines for IDE and CH376 devices have been merged, which saves some valuable bytes in the common memory area.
The compiled binary includes support for a wide range of devices: IDE interfaces like X-Mass, Symbiface, and Cyboard; internal 3" and external 3.5" floppy drives; the Net4CPC network interface; USB storage via Usifac or Ulifac; two USB devices via Albireo; and two simultaneous TTY consoles. Please note that serial TTY over Usifac is not included in this build, as it conflicts with the CH376 USB support.
As always, your feedback and testing are very welcome!
The downloasd link is: https://github.com/ajcasado/FUZIX/releases/tag/v0.5.1-alpha3
Sounds like a lot of hard work!!! Well done!!! :) :) :)