Got to agree CPM was a OS, even though some look down their noses at it as junk. At the time people ran their businesses with it. Heck CPM - the 68K variant became the basis for Atari ST OS and still exists today in enhanced form running on FPGA's and Coldfires.
Hey hey hey, I'm not knocking CPM per se, but the truth is that the COM applications and overlays did all the work, and all CPM basically did was the disk operating system, loading them up and copying. I know that you couldn't just use a copy of CPM on any machine, it was machine specific, both in terms of disk format, and in terms of drivers as there was no standard or BIOS ROMs even. So of course it can be viewed as an O/S but to me it was incomplete, but that's my opinion.
I like CP/M and I used to work a bit with MS-DOS at the time. And other DOS, e.g. DOS 3.3 (Apple). But technically these are more like file launchers than operating systems - there's nothing running in the background, there's only the program start functionality and a set of library hooks for basic I/O etc. Quite unlike the operating systems of the minis and mainframes that came before the first microcomputers, or the operating systems that came after. They actively manage the running applications, the operating system is always there - unlike CP/M and MS-DOS, when your program is running it is the "whole computer" so to speak. Mind, I like CP/M as I said. But it's not really an OS. And there's nothing wrong with that. Being able to run an application on the bare metal is what we wanted to do, a lot of the time.
Maybe I'm late to the discussion but the things that make a particular black box project a good candidate for an OS as such also make it lousy for the kind of I/O flexibility and strict timing control required for any particular black box.
Operating systems are messy sometimes with respect to timing issues, and machine control demands better control of the pins- that's why in most machine controllers, the slave is a microcontroller and not a full-blown microprocessor.
My version of a Propeller OS doesn't exist, but if it did, it would be more along the lines of a token interpreter not entire unlike the stuff Jonny has been doing since forever and Parallax has been doing even longer.
I guess I just don't see any need for it other than to write objects that are *easily* reusable, and that's kind of the beauty of it for me. Not just fanboi stuff, I really like the entire Propeller concept.
I like CP/M and I used to work a bit with MS-DOS at the time. And other DOS, e.g. DOS 3.3 (Apple). But technically these are more like file launchers than operating systems - there's nothing running in the background, there's only the program start functionality and a set of library hooks for basic I/O etc. Quite unlike the operating systems of the minis and mainframes that came before the first microcomputers, or the operating systems that came after. They actively manage the running applications, the operating system is always there - unlike CP/M and MS-DOS, when your program is running it is the "whole computer" so to speak. Mind, I like CP/M as I said. But it's not really an OS. And there's nothing wrong with that. Being able to run an application on the bare metal is what we wanted to do, a lot of the time.
-Tor
There were background programs of a sort running on CPM. They were called TSR's and sat in memory waiting some condition and ran when it was met.
Maybe I'm late to the discussion but the things that make a particular black box project a good candidate for an OS as such also make it lousy for the kind of I/O flexibility and strict timing control required for any particular black box.
Operating systems are messy sometimes with respect to timing issues, and machine control demands better control of the pins- that's why in most machine controllers, the slave is a microcontroller and not a full-blown microprocessor.
My version of a Propeller OS doesn't exist, but if it did, it would be more along the lines of a token interpreter not entire unlike the stuff Jonny has been doing since forever and Parallax has been doing even longer.
I guess I just don't see any need for it other than to write objects that are *easily* reusable, and that's kind of the beauty of it for me. Not just fanboi stuff, I really like the entire Propeller concept.
+1, although there are times when a small monitor program that lets you look at and modify memory, run bits of code, etc. comes in very handy. That's why I will download Tachyon Forth and try it out starting this weekend.
@Peter, I didn't think you were knocking CPM. Just not showing it the respect it deserves. Basically it was just a file system, program loader, and console interface, but it launched the personal computer industry. Yes, Apple, Atari, Commodore, and other systems also had a part in the launch but the 8080/Z80, S100 bus, and CPM were the dominant player in the early days.
Maybe I'm late to the discussion but the things that make a particular black box project a good candidate for an OS as such also make it lousy for the kind of I/O flexibility and strict timing control required for any particular black box.
Operating systems are messy sometimes with respect to timing issues, and machine control demands better control of the pins- that's why in most machine controllers, the slave is a microcontroller and not a full-blown microprocessor.
My version of a Propeller OS doesn't exist, but if it did, it would be more along the lines of a token interpreter not entire unlike the stuff Jonny has been doing since forever and Parallax has been doing even longer.
I guess I just don't see any need for it other than to write objects that are *easily* reusable, and that's kind of the beauty of it for me. Not just fanboi stuff, I really like the entire Propeller concept.
But we are talking about a Propeller O/S, and the Prop just ain't any other chip. We have eight 32-bit CPUs at our disposal which makes the Prop an excellent real-time controller as you can just dedicate a cog to a real-time task, no nasty interrupts to deal with or multi-threading etc. As for a "token interpreter" that is basically what Tachyon does although unlike the other token interpreters, the Tachyon bytecode is barely interpreted as each byte represents an address in the first 256 longs of the Tachyon VM cog, so it doesn't waste time figuring out what the bytecode is, it just "runs" it. Minimum bytecode execution time is 400ns at 80MHz system clock so it's darn snappy for an "interpreter"!
@Kwinn, CP/M had plenty of respect because there wasn't much around but it pales in comparison to other O/Ss and as mentioned it was basically a file launcher. The TSRs were little bits of code to compensate for the lack of real O/S support. So I'm not knocking it for what it was, if I am knocking it then it's for anyone pushing it as a candidate for an O/S in the 21st century AND expecting to run it in a slow pokey emulated environment too!
But we are talking about a Propeller O/S, and the Prop just ain't any other chip. We have eight 32-bit CPUs at our disposal which makes the Prop an excellent real-time controller as you can just dedicate a cog to a real-time task, no nasty interrupts to deal with or multi-threading etc. As for a "token interpreter" that is basically what Tachyon does although unlike the other token interpreters, the Tachyon bytecode is barely interpreted as each byte represents an address in the first 256 longs of the Tachyon VM cog, so it doesn't waste time figuring out what the bytecode is, it just "runs" it. Minimum bytecode execution time is 400ns at 80MHz system clock so it's darn snappy for an "interpreter"!
@Kwinn, CP/M had plenty of respect because there wasn't much around but it pales in comparison to other O/Ss and as mentioned it was basically a file launcher. The TSRs were little bits of code to compensate for the lack of real O/S support. So I'm not knocking it for what it was, if I am knocking it then it's for anyone pushing it as a candidate for an O/S in the 21st century AND expecting to run it in a slow pokey emulated environment too!
Good points and basically I agree with both of them. Except for it's nostalgia value CPM is obsolete. If there is to be a propeller OS it should be one that is written for the propeller, takes advantage of it's unique architecture, and provides functionality aimed at the area it serves.
Spinix is based on the position-independence of Spin bytecodes. It uses this feature to relocate a Spin program to anywhere in cog RAM and execute it in-place. Spinix programs are compiled and built to run at location zero, but they are easily relocated by adding an offset to the Spin binary header. This feature allows multiple Spin programs to run at the same time from different locations in memory.
Spinix originally consisted of a kernel, shell and separate utilities. The kernel was a special process that provided file and system services. This made the user programs quite small, which allowed for loading multiple programs into hub RAM. However, when running a single large program the use of a kernel was less memory-efficient than just including the kernel functions within the program. Communication with the kernel also slowed things down. So I eliminated the kernel.
Spinix programs use a C-library API, and pass command-line arguments using argc and argv. Spin programs written for Spinix use the CLIB objects to provide this API. This makes it easy to take advantage of standard I/O and file redirection.
One really has to divide the whole concept of a Propeller OS into at least two different purposes.
A. A generalized OS, similar to what a PC does
B. An RTOS or Real Time OS.
For a generalized OS, I find Spinx delights me.
For an RTOS, Tachyon, pfth, or PropForth will all do.
++++++++++++++++++
I suppose there are other ways to go about this, but Forth manages to do for me personally.
And I feel that many people are misguided. You don't always have to have an OS to operate a computer. In fact, it may be easier to learn programing by cross-compiling to a target device that tasked with specific functionality than to get involved with a Beagle Bone or Raspberry Pi device. Must as I like Linux, I enjoy programming microcontrollers without the overburden of OS.
A RTOS may even get in the way of optimal deterministic programming.
I often think that coding "the hard way" so to speak, is real good mental floss.
Almost all of my projects so far have been to replace obsolete boards or systems that could not be repaired and it has been deterministic programming without an OS (which I don't find to be too hard) for them. Now I am looking at a couple of projects that would benefit from the things an OS could provide. The nice thing about the prop is I don't have to give up deterministic timing to have an OS, assuming I can find one that is suitable.
So, it seems after 5 years or so we still haven't agreed on what an "operating system" is.
Should it be portable, should it have it's own drivers, should it handle threads, or virtual memory, or inter process communication, should this should that...
Well, who cares anyway?
I'm going to offer a new definition: An "operating system" is a system that operates. As opposed to systems that do not operate:)
I'm not sure CP/M ever called itself an OS much. CP/M is "Control Program for Micro-processors". That is pretty straight forward and to the point.
Contrary to some statement here CP/M was indeed portable, among 8080/Z80 based machines, it introduced the idea of the BIOS that could be reconfigured or rewritten to handle all kind of different devices. From Floppy drives, to Hard Drives, to modern SD cards for example. No you could not boot a copy of CP/M on a machine it was not built for. So what? Until Linux got loadable modules that was mostly true for that OS. Windows won't even let you boot your image up on some other hardware, a deliberate feature to stop piracy. Mac operating systems, sorry Mac hardware only.
CP/M was a wonderful thing in it's day. It provided a means of getting code running on your machine. Editing, compiling, running. It did that in a very compact way so as to fit in the available memory. A great piece of engineering for the resources available.
Also contrary to statements here emulations do indeed run CP/M at or close to the speed of original machines. Perhaps a bit slower on execution but made up for by media access speed.
I don't think anyone ever seriously suggested that CP/M be a contender for a practical Prop OS. It's just a curio, a bit of fun.
I'm going to offer a new definition: An "operating system" is a system that operates. As opposed to systems that do not operate:)
LOL +1
Also contrary to statements here emulations do indeed run CP/M at or close to the speed of original machines. Perhaps a bit slower on execution but made up for by media access speed.
Yeah, and those original machines weren't all that fast either, and being 8-bits they were fine for anything character based and somehow after many slow n noisy passes the compilers managed to produce an object file
I don't think anyone ever seriously suggested that CP/M be a contender for a practical Prop OS. It's just a curio, a bit of fun.
I see, so you guys were just joking ...... but I certainly got CPM Kwinn riled
But as for emulation it uses up a lot of resources for a processor that doesn't have that much in the first place, only to emulate a slow 8-bit processor. Kinda fun but beyond that kinda sad.
I see, so you guys were just joking ...... but I certainly got CPM Kwinn riled
But as for emulation it uses up a lot of resources for a processor that doesn't have that much in the first place, only to emulate a slow 8-bit processor. Kinda fun but beyond that kinda sad.
No, not riled up. Just wanted to point out it's place in computing history and as Heater pointed out, the feat of software engineering it was. I have no interest in running CPM on a Z80/8080 or propeller emulation, even as a hobby. On the other hand adapting how CPM did things to a propeller using native code might not be a bad approach to a propeller OS. The CPM Bios approach to interfacing hardware was very flexible.
Ah! the good old days of "many slow n noisy passes the compilers managed to produce an object file" On one project I had three Intel Intelec MDS boxes with a total of nine 8" floppy drives. Not CP/M machines but similar. A complete build of the project would have all those drives "werrr-clunking" all day. Sometimes it managed to produce an object file, often something failed, floppy error or whatever.
No we were not joking. We take our historic curios and fun very seriously
"Kinda sad"? Nah what? My 8080/Z80 emulation was my first ever Spin/PASM code and a micro-controller achitecture the likes of which I had never seen before. A great learning exercise and generally fun all round.
> A great learning exercise and generally fun all around.
Yes. Nothing sad about it. Writing emulators is something I really enjoy. And it kind of has to be emulation of old machines, otherwise the emulation will run sloooow.. and not really emulate anything. Besides the learning exercise, there's also this fundamental magic: You don't write a compiler, or a text editor, or a space war game. Instead you start with a lump of some binary code which does nothing. Then you (or at least, that's what I've been doing) implement the very first few instructions and run the binary blob through your emulator. Halt when there's something unknown. Implement that instruction. Occasionally there'll be a bit of hardware or something else to implement. As the time passes the binary blob executes for longer and longer until one day you have implemented enough of just really low-level, simple stuff like 'add' or 'jsr' or whatever. And out of that - suddenly on your screen a text editor appears, or a game start running. You didn't write any of that, you just implemented some low-level CPU instructions, and out of that arrives this truly emergent property - a real program which does things, which you didn't write. But which came out of the small bits you made, somehow.
Yes, that is pretty much how my 8080 emulator was created. Magic. The first time I saw the CP/M prompt appear on the screen I nearly jumped out of the window with awe and excitement.
Ah! the good old days of "many slow n noisy passes the compilers managed to produce an object file" On one project I had three Intel Intelec MDS boxes with a total of nine 8" floppy drives. Not CP/M machines but similar. A complete build of the project would have all those drives "werrr-clunking" all day. Sometimes it managed to produce an object file, often something failed, floppy error or whatever.
No we were not joking. We take our historic curios and fun very seriously
"Kinda sad"? Nah what? My 8080/Z80 emulation was my first ever Spin/PASM code and a micro-controller achitecture the likes of which I had never seen before. A great learning exercise and generally fun all round.
The kinda sad bit is more in reference to attempting to go beyond the fun stage, because I have written emulators, both for fun and for debugging (they are a great learning exercise), but never seriously considering using any old stuff on resource limited microcontrollers, which is what the Prop is.
As for the whirr-clunk sound of the 8" drives perhaps we could "emulate" that with the SD card, just need a wave file that can be played back and maybe perhaps a solenoid for that solid clunk! I'm sure we could also throw in some disk errors too!
Ah yes, it's just that I have yet to find anyone here sad enough to be "attempting to go beyond the fun stage,.." and "...seriously considering using any old stuff on resource limited microcontrollers,..".
Hey, but don't forget, the first ever C compiler to generate code that was run on a Propeller was BDSC on CP/M. Not only that BDSC is still the only C compiler that can be run on the Propeller itself. If you were serious about a self-hosting C development system on the Prop there is still only one way to do it.
Please no.. emulating the whirr-clunk sound is an emulation to far!
I'm writing an OS to run on almost every board ever released for the Prop. This OS, which is currently going under the title 'uOS', will provide a standardized way to access pheripheral, graphics devices, storage devices, and extension cards. Plus, it's going to provide an interpreter for a language which I'm developing.
I've done the math, and I'm convinced that it IS possible, even with the Prop 1.
When I have a decent chunk of code, I'll post it to the Object Exchange.
I'm writing an OS to run on almost every board ever released for the Prop. This OS, which is currently going under the title 'uOS', will provide a standardized way to access pheripheral, graphics devices, storage devices, and extension cards. Plus, it's going to provide an interpreter for a language which I'm developing.
I've done the math, and I'm convinced that it IS possible, even with the Prop 1.
When I have a decent chunk of code, I'll post it to the Object Exchange.
All this from scratch, both in terms of software and in Propeller (non)experience, and fits into 32K including buffers to run on almost every Prop board etc? Plus it will provide a "standardized way" for access? Standardized for Spin or C or Basic or Forth?
PropellerGuy, you are not the first to come along new to the forum and make similar huge claims and "gunna do's", but don't expect any fanfare or people jumping up and down all excited, most of the guys here are seasoned and might maybe be impressed if they can see it, definitely not if it's vaporware or if you have not established any credibility. If you are serious and have a "decent chunk of code" or any snippet of code in fact, then post it rather than talk about it, although I think it might be awhile before it's obex worthy, if ever.
Good luck.
(basically saying, just enjoy the forum and working with the Prop, you don't have to try to impress us, just do)
I'm writing an OS to run on almost every board ever released for the Prop. This OS, which is currently going under the title 'uOS', will provide a standardized way to access pheripheral, graphics devices, storage devices, and extension cards. Plus, it's going to provide an interpreter for a language which I'm developing.
I'm curious what the minimum HW requirement will be for your OS. To run on every board you would need a minimum of a Prop, 32K EEProm and a serial link. However, the OS won't do much with just that hardware. Are you thinking that the minimum HW would also include an SD card? That's fairly easy to add to boards that don't have it, and it would greatly expand your OS.
I'm writing an OS to run on almost every board ever released for the Prop. This OS, which is currently going under the title 'uOS', will provide a standardized way to access pheripheral, graphics devices, storage devices, and extension cards. Plus, it's going to provide an interpreter for a language which I'm developing.
I've done the math, and I'm convinced that it IS possible, even with the Prop 1.
When I have a decent chunk of code, I'll post it to the Object Exchange.
A little more info would be much appreciated..........Maybe if you could start a thread and just write out what you have so far? I would love to see how this works, especially since I am pretty new to learning about operating systems, and a simple one would be a great place to start ( not only for me, other beginners might want to take a look too ).
Pete: Howly Cow!!! The code for EVERY board isn't going to fit in 32K! The code for any SPECIFIC board can fit in 32K.
Furthermore, the OS doesn't natively provide:
- Multiple filesystem support
- Desktop interfaces
- Things like that
Those are handles by 'utilities' (somewhat like DOSs TSRs.)
Also, NOT from scratch. I'm modifying the existing drivers to make them go along with a standard which I have already developed.
Lastly: Hooo boy, I know I'm not the first 'great' 'gunna do' guy on the forums. I just have this idea for a teensy weensy OS, which I'd like to share.
Dave Hein:
Minimum requirements for version 0.2.12 (where I am now):
- 32KB EEPROM (obviously)
- Serial connection OR GPU
- SD or microSD card
- 8 spare I/Os (for extension cards; I have a standard worked out for them)
Optional:
- Up to 256 Props per computer (I know, that's a crazy limit, but hey, what the heck.)
- Up to 16MB of XRAM (external RAM) per CPU.
- Mouse.
I'm still documenting and cleaning up code, so it'll be a little bit before I start my own thread.
Pete: Howly Cow!!! The code for EVERY board isn't going to fit in 32K! The code for any SPECIFIC board can fit in 32K.
Furthermore, the OS doesn't natively provide:
- Multiple filesystem support
- Desktop interfaces
- Things like that
Those are handles by 'utilities' (somewhat like DOSs TSRs.)
Also, NOT from scratch. I'm modifying the existing drivers to make them go along with a standard which I have already developed.
Lastly: Hooo boy, I know I'm not the first 'great' 'gunna do' guy on the forums. I just have this idea for a teensy weensy OS, which I'd like to share.
.
Don't get me wrong, I'm just talking straight as we have heard many of these claims before and I want to know if you are serious or just like attention. So you had it coming, and as I said you were making big claims out of nowhere. I would have thought that if you were even a tiny bit serious you would have shared some of the mystery "maths" involved, what your expectations were for it, how it would be used, just going into a bit of detail, because when we have these great ideas we like to talk about them.
Now I see that this all encompassing OS is a "teensy weensy OS" which is fine but perhaps you should outline what it could do, what you would like it to do, so as to invite some feedback. The other thing that would help especially seeing that you are brand new to the forum and perhaps the Prop (btw, a belated "welcome") is to give us forumistas (yeah, that's us) a bit of background and your motivation for doing this and why and how you are using the Prop. That gets our interest.
But it begs the question, if say for instance CPM and DOS are all centered around the filesystem then what sort of an OS are you proposing that doesn't natively support a filesystem or "things like that"? Is this some kind of RTOS?, which for a single core makes sense but not so much on an eight core Prop.
BTW, the fact that you fronted me is in your favor so far
You may want to use a 64K eeprom instead of a 32K. Not much difference in price, and the extra space for code gives you some added flexibility.
I have often wondered (usually while waiting for Windows to boot) if it would be practical to write a program that scans and identifies the hardware and peripherals of a PC, SBC, or Microcontroller, then selects the appropriate kernel and drivers to create a binary of an OS for that specific system. IOW an OS compiler that produces an image of the code that gets loaded into memory.
Minimum requirements for version 0.2.12 (where I am now):
- 32KB EEPROM (obviously)
- Serial connection OR GPU
- SD or microSD card
- 8 spare I/Os (for extension cards; I have a standard worked out for them)
Optional:
- Up to 256 Props per computer (I know, that's a crazy limit, but hey, what the heck.)
- Up to 16MB of XRAM (external RAM) per CPU.
- Mouse.
I don't think a minimum requirement for a 32KB EEPROM is obvious. With a teensy weensy OS you could require a minimum of 64KB, and not require an SD card. However, I do think that 32K EEPROM plus an SD card makes sense. Using a standard I/O interface makes sense. This will reduce the amount of code that the OS needs to support various I/O devices.
The multi-Prop option and XRAM are interesting. I'm looking forward to seeing how you implement this.
I'm a little confused, you said it was an OS but it would not include file system, yet this document is about a file system and not an OS, although it is not compatible with anything but itself.
Furthermore, the OS doesn't natively provide:
- Multiple filesystem support
The "document" could just as easily have been pasted into your post.
EDIT: MY BAD AGAIN, there is the uOS document that I didn't catch. But these are still only plans of mice and men, there must be some code that you used to confirm your ideas?
PFS(3) Filesystem
Thomas M. Doylend
Propeller File System (version 3), or PFS(3), provides a simple way to store files on any storage media. It is the native filesystem for uOS.
PFS(3) divides each drive into 4KB sectors. Sector 0 is referred to as the Master Sector. It contains the following data:
16 bytes drive name
1 long magic number (always $55AAFF66)
1 long number of sectors
1 long pointer to occupation map
1 unused long
1016 longs for boot code
Sector 1 contains the root directory. Each sector of a directory contains 1 long pointer to the parent directory, 1 long pointer to the next sector of the directory (1 if this is the last sector), and 73 14-long records of the form:
12 bytes name (0-terminated)
4 bytes extension (0-terminated)
1 long pointer to first sector
1 long file length (in bytes)
1 long flags
2 longs data/time modified (currently unused)
1 long user (unused)
* 4 unused longs *
The flag bits are:
bit 0: Does file exist? (If 0, ignore entry.)
bit 1: Is it a file? (If 0, it’s a directory.)
bit 2: Write-protected? (currently unused)
The occupation map consists of a number of longs, one for each sector. Each long indicates the state of the sector:
If 0, the sector is empty.
If 1, the sector is the last sector of a file.
If anything else, the sector is part of a file, and this entry points to the next sector.
Comments
-Tor
Operating systems are messy sometimes with respect to timing issues, and machine control demands better control of the pins- that's why in most machine controllers, the slave is a microcontroller and not a full-blown microprocessor.
My version of a Propeller OS doesn't exist, but if it did, it would be more along the lines of a token interpreter not entire unlike the stuff Jonny has been doing since forever and Parallax has been doing even longer.
I guess I just don't see any need for it other than to write objects that are *easily* reusable, and that's kind of the beauty of it for me. Not just fanboi stuff, I really like the entire Propeller concept.
There were background programs of a sort running on CPM. They were called TSR's and sat in memory waiting some condition and ran when it was met.
+1, although there are times when a small monitor program that lets you look at and modify memory, run bits of code, etc. comes in very handy. That's why I will download Tachyon Forth and try it out starting this weekend.
@Peter, I didn't think you were knocking CPM. Just not showing it the respect it deserves. Basically it was just a file system, program loader, and console interface, but it launched the personal computer industry. Yes, Apple, Atari, Commodore, and other systems also had a part in the launch but the 8080/Z80, S100 bus, and CPM were the dominant player in the early days.
But we are talking about a Propeller O/S, and the Prop just ain't any other chip. We have eight 32-bit CPUs at our disposal which makes the Prop an excellent real-time controller as you can just dedicate a cog to a real-time task, no nasty interrupts to deal with or multi-threading etc. As for a "token interpreter" that is basically what Tachyon does although unlike the other token interpreters, the Tachyon bytecode is barely interpreted as each byte represents an address in the first 256 longs of the Tachyon VM cog, so it doesn't waste time figuring out what the bytecode is, it just "runs" it. Minimum bytecode execution time is 400ns at 80MHz system clock so it's darn snappy for an "interpreter"!
@Kwinn, CP/M had plenty of respect because there wasn't much around but it pales in comparison to other O/Ss and as mentioned it was basically a file launcher. The TSRs were little bits of code to compensate for the lack of real O/S support. So I'm not knocking it for what it was, if I am knocking it then it's for anyone pushing it as a candidate for an O/S in the 21st century AND expecting to run it in a slow pokey emulated environment too!
Good points and basically I agree with both of them. Except for it's nostalgia value CPM is obsolete. If there is to be a propeller OS it should be one that is written for the propeller, takes advantage of it's unique architecture, and provides functionality aimed at the area it serves.
Spinix originally consisted of a kernel, shell and separate utilities. The kernel was a special process that provided file and system services. This made the user programs quite small, which allowed for loading multiple programs into hub RAM. However, when running a single large program the use of a kernel was less memory-efficient than just including the kernel functions within the program. Communication with the kernel also slowed things down. So I eliminated the kernel.
Spinix programs use a C-library API, and pass command-line arguments using argc and argv. Spin programs written for Spinix use the CLIB objects to provide this API. This makes it easy to take advantage of standard I/O and file redirection.
A. A generalized OS, similar to what a PC does
B. An RTOS or Real Time OS.
For a generalized OS, I find Spinx delights me.
For an RTOS, Tachyon, pfth, or PropForth will all do.
++++++++++++++++++
I suppose there are other ways to go about this, but Forth manages to do for me personally.
And I feel that many people are misguided. You don't always have to have an OS to operate a computer. In fact, it may be easier to learn programing by cross-compiling to a target device that tasked with specific functionality than to get involved with a Beagle Bone or Raspberry Pi device. Must as I like Linux, I enjoy programming microcontrollers without the overburden of OS.
A RTOS may even get in the way of optimal deterministic programming.
I often think that coding "the hard way" so to speak, is real good mental floss.
Almost all of my projects so far have been to replace obsolete boards or systems that could not be repaired and it has been deterministic programming without an OS (which I don't find to be too hard) for them. Now I am looking at a couple of projects that would benefit from the things an OS could provide. The nice thing about the prop is I don't have to give up deterministic timing to have an OS, assuming I can find one that is suitable.
Should it be portable, should it have it's own drivers, should it handle threads, or virtual memory, or inter process communication, should this should that...
Well, who cares anyway?
I'm going to offer a new definition: An "operating system" is a system that operates. As opposed to systems that do not operate:)
I'm not sure CP/M ever called itself an OS much. CP/M is "Control Program for Micro-processors". That is pretty straight forward and to the point.
Contrary to some statement here CP/M was indeed portable, among 8080/Z80 based machines, it introduced the idea of the BIOS that could be reconfigured or rewritten to handle all kind of different devices. From Floppy drives, to Hard Drives, to modern SD cards for example. No you could not boot a copy of CP/M on a machine it was not built for. So what? Until Linux got loadable modules that was mostly true for that OS. Windows won't even let you boot your image up on some other hardware, a deliberate feature to stop piracy. Mac operating systems, sorry Mac hardware only.
CP/M was a wonderful thing in it's day. It provided a means of getting code running on your machine. Editing, compiling, running. It did that in a very compact way so as to fit in the available memory. A great piece of engineering for the resources available.
Also contrary to statements here emulations do indeed run CP/M at or close to the speed of original machines. Perhaps a bit slower on execution but made up for by media access speed.
I don't think anyone ever seriously suggested that CP/M be a contender for a practical Prop OS. It's just a curio, a bit of fun.
LOL +1
Yeah, and those original machines weren't all that fast either, and being 8-bits they were fine for anything character based and somehow after many slow n noisy passes the compilers managed to produce an object file
I see, so you guys were just joking ...... but I certainly got CPM Kwinn riled
But as for emulation it uses up a lot of resources for a processor that doesn't have that much in the first place, only to emulate a slow 8-bit processor. Kinda fun but beyond that kinda sad.
No, not riled up. Just wanted to point out it's place in computing history and as Heater pointed out, the feat of software engineering it was. I have no interest in running CPM on a Z80/8080 or propeller emulation, even as a hobby. On the other hand adapting how CPM did things to a propeller using native code might not be a bad approach to a propeller OS. The CPM Bios approach to interfacing hardware was very flexible.
Ah! the good old days of "many slow n noisy passes the compilers managed to produce an object file" On one project I had three Intel Intelec MDS boxes with a total of nine 8" floppy drives. Not CP/M machines but similar. A complete build of the project would have all those drives "werrr-clunking" all day. Sometimes it managed to produce an object file, often something failed, floppy error or whatever.
No we were not joking. We take our historic curios and fun very seriously
"Kinda sad"? Nah what? My 8080/Z80 emulation was my first ever Spin/PASM code and a micro-controller achitecture the likes of which I had never seen before. A great learning exercise and generally fun all round.
Yes. Nothing sad about it. Writing emulators is something I really enjoy. And it kind of has to be emulation of old machines, otherwise the emulation will run sloooow.. and not really emulate anything. Besides the learning exercise, there's also this fundamental magic: You don't write a compiler, or a text editor, or a space war game. Instead you start with a lump of some binary code which does nothing. Then you (or at least, that's what I've been doing) implement the very first few instructions and run the binary blob through your emulator. Halt when there's something unknown. Implement that instruction. Occasionally there'll be a bit of hardware or something else to implement. As the time passes the binary blob executes for longer and longer until one day you have implemented enough of just really low-level, simple stuff like 'add' or 'jsr' or whatever. And out of that - suddenly on your screen a text editor appears, or a game start running. You didn't write any of that, you just implemented some low-level CPU instructions, and out of that arrives this truly emergent property - a real program which does things, which you didn't write. But which came out of the small bits you made, somehow.
Yes, that is pretty much how my 8080 emulator was created. Magic. The first time I saw the CP/M prompt appear on the screen I nearly jumped out of the window with awe and excitement.
The kinda sad bit is more in reference to attempting to go beyond the fun stage, because I have written emulators, both for fun and for debugging (they are a great learning exercise), but never seriously considering using any old stuff on resource limited microcontrollers, which is what the Prop is.
As for the whirr-clunk sound of the 8" drives perhaps we could "emulate" that with the SD card, just need a wave file that can be played back and maybe perhaps a solenoid for that solid clunk! I'm sure we could also throw in some disk errors too!
Hey, but don't forget, the first ever C compiler to generate code that was run on a Propeller was BDSC on CP/M. Not only that BDSC is still the only C compiler that can be run on the Propeller itself. If you were serious about a self-hosting C development system on the Prop there is still only one way to do it.
Please no.. emulating the whirr-clunk sound is an emulation to far!
I'm writing an OS to run on almost every board ever released for the Prop. This OS, which is currently going under the title 'uOS', will provide a standardized way to access pheripheral, graphics devices, storage devices, and extension cards. Plus, it's going to provide an interpreter for a language which I'm developing.
I've done the math, and I'm convinced that it IS possible, even with the Prop 1.
When I have a decent chunk of code, I'll post it to the Object Exchange.
All this from scratch, both in terms of software and in Propeller (non)experience, and fits into 32K including buffers to run on almost every Prop board etc? Plus it will provide a "standardized way" for access? Standardized for Spin or C or Basic or Forth?
PropellerGuy, you are not the first to come along new to the forum and make similar huge claims and "gunna do's", but don't expect any fanfare or people jumping up and down all excited, most of the guys here are seasoned and might maybe be impressed if they can see it, definitely not if it's vaporware or if you have not established any credibility. If you are serious and have a "decent chunk of code" or any snippet of code in fact, then post it rather than talk about it, although I think it might be awhile before it's obex worthy, if ever.
Good luck.
(basically saying, just enjoy the forum and working with the Prop, you don't have to try to impress us, just do)
A little more info would be much appreciated..........Maybe if you could start a thread and just write out what you have so far? I would love to see how this works, especially since I am pretty new to learning about operating systems, and a simple one would be a great place to start ( not only for me, other beginners might want to take a look too ).
Thanks,
ValeT
Furthermore, the OS doesn't natively provide:
- Multiple filesystem support
- Desktop interfaces
- Things like that
Those are handles by 'utilities' (somewhat like DOSs TSRs.)
Also, NOT from scratch. I'm modifying the existing drivers to make them go along with a standard which I have already developed.
Lastly: Hooo boy, I know I'm not the first 'great' 'gunna do' guy on the forums. I just have this idea for a teensy weensy OS, which I'd like to share.
Dave Hein:
Minimum requirements for version 0.2.12 (where I am now):
- 32KB EEPROM (obviously)
- Serial connection OR GPU
- SD or microSD card
- 8 spare I/Os (for extension cards; I have a standard worked out for them)
Optional:
- Up to 256 Props per computer (I know, that's a crazy limit, but hey, what the heck.)
- Up to 16MB of XRAM (external RAM) per CPU.
- Mouse.
I'm still documenting and cleaning up code, so it'll be a little bit before I start my own thread.
Don't get me wrong, I'm just talking straight as we have heard many of these claims before and I want to know if you are serious or just like attention. So you had it coming, and as I said you were making big claims out of nowhere. I would have thought that if you were even a tiny bit serious you would have shared some of the mystery "maths" involved, what your expectations were for it, how it would be used, just going into a bit of detail, because when we have these great ideas we like to talk about them.
Now I see that this all encompassing OS is a "teensy weensy OS" which is fine but perhaps you should outline what it could do, what you would like it to do, so as to invite some feedback. The other thing that would help especially seeing that you are brand new to the forum and perhaps the Prop (btw, a belated "welcome") is to give us forumistas (yeah, that's us) a bit of background and your motivation for doing this and why and how you are using the Prop. That gets our interest.
But it begs the question, if say for instance CPM and DOS are all centered around the filesystem then what sort of an OS are you proposing that doesn't natively support a filesystem or "things like that"? Is this some kind of RTOS?, which for a single core makes sense but not so much on an eight core Prop.
BTW, the fact that you fronted me is in your favor so far
You may want to use a 64K eeprom instead of a 32K. Not much difference in price, and the extra space for code gives you some added flexibility.
I have often wondered (usually while waiting for Windows to boot) if it would be practical to write a program that scans and identifies the hardware and peripherals of a PC, SBC, or Microcontroller, then selects the appropriate kernel and drivers to create a binary of an OS for that specific system. IOW an OS compiler that produces an image of the code that gets loaded into memory.
The multi-Prop option and XRAM are interesting. I'm looking forward to seeing how you implement this.
Here is some documentation I'be created, which should show how it's possible to create a tiny yet adaptable OS.
The math details are coming soon.
uOS.docPFS(3).doc
That should show up as attachments.
I'm a little confused, you said it was an OS but it would not include file system, yet this document is about a file system and not an OS, although it is not compatible with anything but itself.
The "document" could just as easily have been pasted into your post.
EDIT: MY BAD AGAIN, there is the uOS document that I didn't catch. But these are still only plans of mice and men, there must be some code that you used to confirm your ideas?
PFS(3) Filesystem
Thomas M. Doylend
Propeller File System (version 3), or PFS(3), provides a simple way to store files on any storage media. It is the native filesystem for uOS.
PFS(3) divides each drive into 4KB sectors. Sector 0 is referred to as the Master Sector. It contains the following data:
16 bytes drive name
1 long magic number (always $55AAFF66)
1 long number of sectors
1 long pointer to occupation map
1 unused long
1016 longs for boot code
Sector 1 contains the root directory. Each sector of a directory contains 1 long pointer to the parent directory, 1 long pointer to the next sector of the directory (1 if this is the last sector), and 73 14-long records of the form:
12 bytes name (0-terminated)
4 bytes extension (0-terminated)
1 long pointer to first sector
1 long file length (in bytes)
1 long flags
2 longs data/time modified (currently unused)
1 long user (unused)
* 4 unused longs *
The flag bits are:
bit 0: Does file exist? (If 0, ignore entry.)
bit 1: Is it a file? (If 0, it’s a directory.)
bit 2: Write-protected? (currently unused)
The occupation map consists of a number of longs, one for each sector. Each long indicates the state of the sector:
If 0, the sector is empty.
If 1, the sector is the last sector of a file.
If anything else, the sector is part of a file, and this entry points to the next sector.