Alan Cox releases "Fusix", SYS5 UNIX in 40k - initial target platform... Z80.
__red__
Posts: 470
So, those who thought that getting a UNIX running on the propeller was a hard job... may now have a significantly shorter path :cool:
"Just Because We Can"[tm].
Not looked at the sources yet, but I was tickled...
https://plus.google.com/+AlanCoxLinux/posts/a2jAP7Pz1gj
Red
"Just Because We Can"[tm].
Not looked at the sources yet, but I was tickled...
https://plus.google.com/+AlanCoxLinux/posts/a2jAP7Pz1gj
Red
Comments
From what I understand Fusix already takes > 40k of RAM, so in fact wouldn't really be feasible with the P1 without some funky memory techniques that would slow it down.
Still totally cool though.
R
And then there's the issue of trying to fit the kernel plus multiple processes into 32K of memory. The early versions of spinix had a kernel that took slightly less than 16K of memory, with applications that required 5K to 10K. The applications were written in Spin so that they could be easily relocated in memory by adding an offset to the Spin header. However, this approach was somewhat inefficient because the user programs had to communicate to the kernel whenever it needed to do an I/O operation. The available data space was also limited. With a single process running the available data space was 10K or less.
The current version of spinix doesn't use a kernel, but uses device drivers running entirely in cogs with some space in hub RAM for mailboxes and buffer storage. This improves execution speed and allows for more data space for user programs.
Of course, all of this could change if and when the P2 is available. It will have much more hub RAM and will run much faster than the P1.
Given that we have Z80 emulators for the P1 already and memory bank switching has been done in the ZiCog emulator in order to run MPM, (multi-user CP/M) this all sounds quite doable.
I can't imagine how Fusix gets on without an MMU but didn't things like One Man Unix (OMU) on the 6809/68000 do just that?
OS/9 and Nitros both run on the 6809 and they are Unix like. I've been meaning to learn more about them because I wonder how they can run on such limited hardware.
One obvious target for Fusix would be the eZ80, which comes at 50Mhz and with 256k flash. ( $4~$7)
Zilog also do modules with 128 or 512k or SRAM added, and some have 8MB of Flash ( $50~$80 region)
Original version of Unix by Thompson etc. was written on/for PDP-7 with 64k of memory.
http://www.linfo.org/pdp-7.html
So should be entirely feasible, though I'm not clear if those PDPs had MMU etc.
I don't think any of the PDP models had an MMU. I did work on a PDP-15, which allowed running a foreground task along with a background task, and it may have had some form of memory protection. I don't think an MMU was fully supported until the VAX came out, which allowed for virtual memory.
As far as I know, the Motorola 6809 was the first microprocessor to support position independent code. It was a big sales pitch by Motorola at the time. And we loved it because we were compiling/assembling code by hand at the time. It was nice to be able to move the work you had done around in memory without having to recalculate all the memory references.
It is possible that this position independence can be done with Spin at the byte code level. But I can't imagine how that helps with Unix on the Prop. Until such time that someone has made a C compiler that generates Spin byte code. Which itself is an idea proposed some years ago by Parallax and rejected as hard and pointless.
As far as I remember you are right. Virtual memory is not required for Unix. The VAX was the first DEC machine to have virtual memory.
Remember that Xenix, Unix licensed by Microsoft, ran on Intel x86 machines long before the 286 with virtual memory arrived.
Surely that only makes sense if there is silicon that executes Spin bytes codes directly in silicon ?
Otherwise C is better off targeting PASM and LMM etc ?
Of course, with P1V it is not impossible to craft something that does execute at least some Spin Byte codes in silicon.
Did I see some mention before that Spin also has an upper memory limit (aside from the obvious P1 RAM ceiling) ?
There is silicon that executes Spin byte codes. It's the Propeller!
I know what you mean but seriously, you cannot even start the LMM or COG code produced by propgcc without some Spin byte codes that get run at boot time. Those initial Spin byte codes have to be there to load the code generated by propgccc into a COG and started.
A C compiler that compiled to Spin byte codes was a serious proposal a couple of years back. It was realized that such a compiler would have a hard time implementing C properly, or if it did it would be terrible slow. So the idea was to create only a subset of C. Luckily that idea was eventually dropped.
that would be interpreted today as, well a will be positive 3, instead of adding 3 to a. And it has loads of "pointer mis-use"... it seems that the language at the time was even weaker typed that it is today, and that feature was... over-used. It needs a rewrite for a newer compiler... something I started but didn't finish yet
[code]
I just found all my ColorComputer2 and 3 parts with the OS/9 floppies. Wonder if they still work?
"a=+3;"
Are you saying the += operator used to be =+ ?
Do you have a sample source file with such stuff you can post for historical interest?
"pointer mis-use". Oh yeah, I seem to recall that early C would compile all kinds of dangerous things without flinching. Still, that is nice because you don't have to write all those verbose and ugly casts everywhere
-Tor
There's still an active Color Computer community, and they created Nitros which is an open source version of OS/9. So undoubtedly there the information out there to get that coco working again.
I try to keep up with the CoCo forums, but this on is so active, it's hard to keep up.
comments in the code are the exception
sureg() { register *up, *rp, a; a = u.u_procp->p_addr; up = &u.u_uisa[0]; rp = &UISA->r[0]; while(rp < &UISA->r[8]) *rp++ = *up++ + a; if((up=u.u_procp->p_textp) != NULL) a =- up->x_caddr; up = &u.u_uisd[0]; rp = &UISD->r[0]; while(rp < &UISD->r[8]) { *rp = *up++; if((*rp++ & WO) == 0) rp[(UISA-UISD)/2-1] =- a; } }Yes. The time line has gone all weird here. Back in the day we had Unix on DEC and other minicomputers. Well, when I say "we" I mean "they", I just missed that scene.
Then along came the 8 bit microprocessors.
They were too small for Unix so other operating systems were created. Intel had ISSIS and RMX on their 8080/8085/8086 development systems for example. You could never by that as a hobbyist. It came with the dev box which was ten thousand dollars a pop.
Gary Kildall created CP/M for those the same machines and had a hit on his hands as there was nothing much else. 8 bit machines like that were booting up into a BASIC interpreter at the time.
Meanwhile Unix languished and declined as mini-computers and then workstations were decimate by the arrival of the IBM-PC.
Until we got Linux. A recreation of Unix on the modern PC class machines.
So now Alan Cox, a famous Linux developer has put a Unix like OS onto the Z80.
We are back to the future, in a past that never existed.
Or something like that:)
I suspect Alan feels a bit of the same and that's why he created FUSIX. The same has been done before (going *nix-style on micros), and several of those earlier projects have been mentioned in this thread already. FUSIX incorporates parts of some of that (at least on the conceptual level), e.g. UZI180. I have great confidence in this project getting there, because Alan Cox is behind it. He doesn't leave stuff unfinished. So now I'll dig through my pile of old hardware to see what could make use of this initial FUSIX version.
And to think I just threw out the xinu books as I needed the space:(
I feel much the same about all you have written there.
Strangely I pretty much missed the 8 bit home PC days. C64, Spectrum, CP/M and so on. When I first started with 8 bit microprocessors there pretty much were no such machines. We had heard rumours of Altairs and IMSAI etc. All far too remote and expensive for us.
No we just had the chips. No dev boards no compilers and assemblers. We had to start with the wire wrap or soldering iron and create HEX files for an EPROM programmer to get any kind of software into the finished computer. Later I worked with 8085/8086 systems programmed via Intel development machines. We worked in assembler or PL/M so I never had the urge to get into BASIC on a consumer 8 bitter. BASIC was that terrible thing I was introduced to computing with, on a mainframe, some years before.
Looking back though, that boot to BASIC thing on the early 8 bitters had a remarkable effect. It meant the machine was a brick until you figured out how to type something useful into it. It was inviting kids to program from the very start. Most of them never got past creating loops to print out rude messages and then loading games to play. But some tried to actually program something. Soon hit the limits of BASIC and then discovered PEEK POKE and how to get stunning performance in machine code, wow!
There are a lot of famous names in programming who got their start that way. Including our own Chip Gracey I believe.
It was the loss of that invitation to program by the machine, with the coming of MSDOS and Windows and piles of ready made applications and games, that cased a dip in the programming skills of entrants to university CS programs. The new generations just never had the chance as kids.
It was the observation of that phenomena that inspired the Raspberry Pi....
Things are looking up. Kids today have Propellers and Arduinos and Raspberry Pis. Or they can start programming in JavaScript on their PC's out of the box. They have toys we could only have dreamed of.
Yep. I have faith that Allen Cox will do a good job of Fusix. I'm just wondering what it will take to get it running on a Propeller with a Z80 emulator....
* Hook a Raspberry Pi or Beaglebone Black up to a very accessible monitor, keyboard, mouse.
* Have said running a simple baremetal OS which boots to a READY. prompt that accepts Lua or something similar. Just minimal graphics and sound primitives and a REPL loop to enter programs and a simple ability to SAVE and LOAD programmes.
* Let them use it whenever they want, no restrictions except for chores/homework/meals/outdoor activity time.
* Restrict access to all other computing devices in the house.
I'm curious what the results would be.
Should be worth tracking.
There was also Rabbit Semi, who seem to have faded from chip-pitching, to module supplier, but I notice they got up to a Rabbit 6000, (which will still have a subset Z80 in there, I guess)
Clock speed up to 200 MHz
On-board 802.11 a/b/g and 10/100 Ethernet
64 I/O and up to 6 serial ports (4 as SPI)
1 MB internal DRAM and 32K battery backable SRAM
USB 2.0 full speed host