It's basically a micro Unix implementation aimed at old and resource constrained systems. I've been following it for a few years. The documentation is terrible, there are hardy any updates, but it does seem to be making slows, steady progress behind the scenes. I think it just needs to reach a critical mass of functionality and we'll see it popping up on raspberry pi picos, 8-bit micros etc. Definitely needs some TLC in the comms department though. Oh, and don/t be fooled by the archived status - it moved to https://codeberg.org/EtchedPixels/FUZIX
> FUZIX is a fusion of various elements from the assorted UZI forks and branches beaten together into some kind of semi-coherent platform and then extended from V7 to somewhere in the SYS3 to SYS5.x world with bits of POSIX thrown in for good measure. Various learnings and tricks from ELKS and from OMU also got blended in
This README reads like a blog post.
Is this intended for some kind of professional purpose? Because I could see this being amusing for hobby purposes but I have no idea what I'd do with it at work.
I've seen cases where documentation is seriously lacking but this project is quite something.
Was reading the comments, was able to learn more. So I assume it provides a command line interface.
Question: Can it run binaries compiled for the platform/OS?
This has been a limitation since forever on ESP microcontrollers because they basically have the power of computers and yet the flashing limitation of calculators. Would be good to finally be able to launch arbitrary binaries without flashing. (I know there are tricks right now, just looking for a proper OS-approach).
Yes. It has Unix style processes. The basic memory model is similar to ancient Unix on the PDP-11 without paging. A process gets a flat memory space. Processes are swapped out in the background as necessary.
How it is implemented varies by platform. On the 8-bit micros it takes advantage of bank-switching memory hardware if there is any. On the MMUless 68K a flat single address space can be used with position-independent code for the processes. On platforms with paging or relocation hardware that is used. Most of the host platforms do not have hardware memory protection, but there's room in the design to support it.
It has been ported to the Raspberry Pi Pico [1] (ARM Cortex-m0+ based) and could be ported to other microcontrollers which have enough RAM.
Toolchain is the biggest problem. It's hard to get a good cross toolchain that works. FUZIX's creator has been writing a portable C compiler but it's not done yet. The code does compile with Clang and GCC but a working toolchain is a steep knowledge cliff to climb.
I have got the kernel to build and link for a riscv32i target. Just need some real riscv32 hardware to test it on. And free time.
Thank you, that fully answers the question. I suppose for the moment there is then a limitation for the size of processes to be run and we need to be generous on reserving the memory depending on the device.
True, though some old processors would be able to implement pretty impressive tricks. A Z80 with an 8 bit latch can bank switch 8MB of SRAM with 32KB chunks.
> FUZIX is a fusion of various elements from the assorted UZI forks and branches beaten together into some kind of semi-coherent platform and then extended from V7 to somewhere in the SYS3 to SYS5.x world with bits of POSIX thrown in for good measure. Various learnings and tricks from ELKS and from OMU also got blended in
I'm sorry but the landing page at fuzix.org (the top page nonetheless) is terrible as it does not even try to explain what FUZIX even IS. I went to the GitHub project page, which contains some more details, but it still doesn't answer the question and only talks about how FUZIX differs from UZI.
To be honest, I still have no idea what I'm looking at.
"Munitions"? "Intelligent distribution panel"? Look, the UNIX part might not be obvious at all, but if you somehow didn't have enough of a rough idea after seeing that many retro CPUs and systems listed below, that might say more about you than the author.
That wasn't ever in doubt. That's also not the relevant piece of information - people looking for a summary want to know why the thing is worth paying spending time on, not random attributes
You do realize when you say that you do assume they know it's an OS and by that you effectively have to regress into using the same level of argument as me just like how I assume they don't know it's an OS, right?
Alan's currently putting most of his energy into the compiler. It's a C compiler in C which can compile itself, and compile FUZIX, for 8080 and Z80 targets. The goal is to make it compile itself on all the platforms it can run on eventually. :)
It's basically a micro Unix implementation aimed at old and resource constrained systems. I've been following it for a few years. The documentation is terrible, there are hardy any updates, but it does seem to be making slows, steady progress behind the scenes. I think it just needs to reach a critical mass of functionality and we'll see it popping up on raspberry pi picos, 8-bit micros etc. Definitely needs some TLC in the comms department though. Oh, and don/t be fooled by the archived status - it moved to https://codeberg.org/EtchedPixels/FUZIX
> FUZIX is a fusion of various elements from the assorted UZI forks and branches beaten together into some kind of semi-coherent platform and then extended from V7 to somewhere in the SYS3 to SYS5.x world with bits of POSIX thrown in for good measure. Various learnings and tricks from ELKS and from OMU also got blended in
This README reads like a blog post.
Is this intended for some kind of professional purpose? Because I could see this being amusing for hobby purposes but I have no idea what I'd do with it at work.
> Is this intended for some kind of professional purpose?
No. Retrocomputing. Fun. Learning.
I've seen cases where documentation is seriously lacking but this project is quite something.
Was reading the comments, was able to learn more. So I assume it provides a command line interface.
Question: Can it run binaries compiled for the platform/OS?
This has been a limitation since forever on ESP microcontrollers because they basically have the power of computers and yet the flashing limitation of calculators. Would be good to finally be able to launch arbitrary binaries without flashing. (I know there are tricks right now, just looking for a proper OS-approach).
Yes. It has Unix style processes. The basic memory model is similar to ancient Unix on the PDP-11 without paging. A process gets a flat memory space. Processes are swapped out in the background as necessary.
How it is implemented varies by platform. On the 8-bit micros it takes advantage of bank-switching memory hardware if there is any. On the MMUless 68K a flat single address space can be used with position-independent code for the processes. On platforms with paging or relocation hardware that is used. Most of the host platforms do not have hardware memory protection, but there's room in the design to support it.
It has been ported to the Raspberry Pi Pico [1] (ARM Cortex-m0+ based) and could be ported to other microcontrollers which have enough RAM.
Toolchain is the biggest problem. It's hard to get a good cross toolchain that works. FUZIX's creator has been writing a portable C compiler but it's not done yet. The code does compile with Clang and GCC but a working toolchain is a steep knowledge cliff to climb.
I have got the kernel to build and link for a riscv32i target. Just need some real riscv32 hardware to test it on. And free time.
[1] https://cowlark.com/2021-02-16-fuzix-pi-pico/index.html
Thank you, that fully answers the question. I suppose for the moment there is then a limitation for the size of processes to be run and we need to be generous on reserving the memory depending on the device.
True, though some old processors would be able to implement pretty impressive tricks. A Z80 with an 8 bit latch can bank switch 8MB of SRAM with 32KB chunks.
So it's you to thank for porting Fuzix to Raspberry Pi Pico.
>Toolchain is the biggest problem. It's hard to get a good cross toolchain that works.
So is it possible to compile programs for Fuzix on a PC?
> So it's you to thank for porting Fuzix to Raspberry Pi Pico.
No not me it was David Given over at the link I gave (not my blog).
I have poked around Fuzix but I am not a major contributor.
> So is it possible to compile programs for Fuzix on a PC?
Most of the development is cross-devel from PC.
Isn't creating a Docker image containing the right version of GCC or Clang a solution to the toolchain problem?
> FUZIX is a fusion of various elements from the assorted UZI forks and branches beaten together into some kind of semi-coherent platform and then extended from V7 to somewhere in the SYS3 to SYS5.x world with bits of POSIX thrown in for good measure. Various learnings and tricks from ELKS and from OMU also got blended in
https://github.com/EtchedPixels/FUZIX#what-does-fuzix-have-o...
I'm sorry but the landing page at fuzix.org (the top page nonetheless) is terrible as it does not even try to explain what FUZIX even IS. I went to the GitHub project page, which contains some more details, but it still doesn't answer the question and only talks about how FUZIX differs from UZI.
To be honest, I still have no idea what I'm looking at.
>it does not even try to explain what FUZIX even IS
Fuzix is a very simple UNIX clone (and a for of UZI) started by Alan Cox, an ex-Linux kernel developer) as his retirement project.
It aims to run on old CPUs like Z80 and on microcontrollers. I found it when searching what OS can I run on the $4 Raspberry Pi Pico.
announce discussion https://news.ycombinator.com/item?id=8548429
The GitHub repo also seems to be archived.
To quote the comment from higher on the page – https://news.ycombinator.com/item?id=47818363 –
« Oh, and don't be fooled by the archived status - it moved to
https://codeberg.org/EtchedPixels/FUZIX »
[flagged]
An operating system for munitions? An intelligent distribution panel?
Seriously, it's not that hard for the maintainer to write one sentence describing what the project does.
"Munitions"? "Intelligent distribution panel"? Look, the UNIX part might not be obvious at all, but if you somehow didn't have enough of a rough idea after seeing that many retro CPUs and systems listed below, that might say more about you than the author.
[flagged]
I thought it was pretty obvious what it was by applying my social intelligence while reading the landing page.
[flagged]
> It lists platforms so it's an OS that runs on these platforms
That doesn't tell me what it is in a concrete sense. Must be hundreds of OS that run on similar hardware - what makes this one different?
Ah, but at least you do know it's an OS, yes?
That wasn't ever in doubt. That's also not the relevant piece of information - people looking for a summary want to know why the thing is worth paying spending time on, not random attributes
You do realize when you say that you do assume they know it's an OS and by that you effectively have to regress into using the same level of argument as me just like how I assume they don't know it's an OS, right?
[dead]
you are not only rude but you are also unhelpful
If this one sentence is rude in your opinion then I have very bad news for you
For 8086 there's ELKS with networking support and it might run biggie stuff as Nethack/Slashem.
Frotz, vi, and the rest run OFC.
Networking sshot: https://raw.githubusercontent.com/ghaerr/elks/master/Screens...
Telnetting to a BBS: https://raw.githubusercontent.com/ghaerr/elks/master/Screens...
Oh yes there's been some ELKS activity lately.
Does it support the 286's 16-bit protected mode at all?
286 protected mode has the 8086-style 16-bit addresses and segmentation. But with virtualization and protection.
Not very many operating systems made use of it. The x86 world skipped over it directly from 8086 real mode to 32-bit paging.
Edit: to answer my own question it seems the recent branch dropped 286 protected mode support
https://github.com/ghaerr/elks/pull/235
Windows 3.0 and 3.1 were very popular and made use of the 286's protected mode.
Tandy CoCo 3 reference spotted
Looks like the project is dead.
No I think Alan just moved where it's hosted:
https://codeberg.org/EtchedPixels/FUZIX last updated 4 days ago
Alan's currently putting most of his energy into the compiler. It's a C compiler in C which can compile itself, and compile FUZIX, for 8080 and Z80 targets. The goal is to make it compile itself on all the platforms it can run on eventually. :)
https://codeberg.org/EtchedPixels/Fuzix-Compiler-Kit
Except it’s not…
https://codeberg.org/EtchedPixels/FUZIX