drogon wrote:
What's your definition of an actual OS?
i'd say something like MS-DOS 2.0 or above. a simple commandline interface where you can run internal commands or external programs. with driver support of course!
drivers would be IMO the most important part as they shift the hardware dependent parts of code away from the OS and user programs.
sadly implementing drivers is really damn difficult and while i want to try myself at making an OS with driver support, i'm still in the "writing down all my ideas and concepts to solve weird edge cases before even writing a single line of code" phase of the project, which is very difficult to break out of.
drogon wrote:
Acorn did it way back with a port of their Acorn MOS in their Communicator, then Apple did their thing on the //gs ...
main issues with porting Operating systems of older hardware like that is the hardware dependence, sometimes missing source code, and any kind of limitations that you wouldn't have on a more modern system (like the amount of RAM available).
i have been sort of thinking about porting something like GEOS, which seems similar enough to GS/OS, except GEOS has source code. but both are graphical OSes which would be amazing to have, but also seem more error prone compared to simple terminal based OSes.
drogon wrote:
... Fast forward to a year or 2 back and I have my RubyOS'816 going - which is a command-line sort of thing that supports multi-tasking running on my '816 board at 16Mhz - all written in BCPL....
which is pretty damn impressive!
drogon wrote:
Under which I wrote a RISC-V 32IM emulator (in BCPL) which runs at about 2000 RV instructions/sec, so not going to win any speed records, but if I added the bare minimal MMU support then could it run Linux? Sure - it's a little RAM limited right now though (Has about 350KB free) but in a larger memory system then yes - but as above, slowly...
So it's a good academic/fun exercise but not really usable...
well again, you don't need an MMU for linux, just a seperation between User and System mode. and even that
might be optional.
if i had an actual C compiler for my SW32VM i could try stuff like this myself. it would likely run as slowly as a RISC-V emulator, but atleast instructions are only 16-bits wide instead of 32-bits like on RISC-V.... but i don't know if that makes up for much in terms of performance, something to test i guess.