Just to add to the recent discussion threads of Coherent, Minix, Fuzeix and what not, I'll just mention mine; RubyOS/BCPL

My Ruby 6502 board has a low-level OS that supports program development in BBC Basic - so BASIC + built in assembler that's capable of creating stand-alone ASM programs that can then be loaded from the SD card based filing system. it's ~90% compatible with the Acorn MOS as used in the (6502 based) BBC Micros in the early 1980's, and supports IRQ chaining for your own hardware, a 100Hz ticker (1000Hz in the '816 version) which with a little effort can be used to schedule interrupt driven "ISR" type code snippets in the same way you do it on the BBC Micro (I've not had a use for it, so not implemented it yet)

This OS provides a standard terminal IO subsystem for doing stuff like screen clearing, cursor movement, graphics and sound - this is identical to the Acorn MOS.

I also have a cc65 target for the board, so C development can happen, although you need to cross compile on a separate Linux system (or Win/Mac if someone can do the cc65 platform integration which needs a re-compile to support a new platform - I'm Linux only here). This can be used to generate programs of up to 16KB object code running at $8000 with ~24KB of data space. This isn't as bad as it might seem as I managed to get the C version of my editor compiled - a nano-like editor in about 1.5K LoC. It can easily be reconfigured for different load addresses, so > 16KB programs starting at $0E00 extending all the way to $BFFF for code + data. There is a Posix-like interface to the filing system, or you can use the standard Acorn MOS filing system interface (Which is actually a wrapper round the Pozix style interface)

On-top of RubyOS, on the '816 is an OS written in BCPL. The BCPL run-time system is ~16KB of '816 ASM that provides a virtual machine/environment for compiled BCPL programs. It's capable of self-hosting in that you can run the BCPL compiler directly on the system. My editor which I re-wrote in BCPL compiles to about 6KB of object code (vs. 16KB for the C version) is very usable.

There is no on-board video, however a serial interface is there that can talk to an ANSI type terminal or a "smart" terminal which is a C program that uses the SDL libraries to give a graphical output capable of 24-bit colour, sprites, sound and even mouse input. I have plans for a Mk 2 terminal (aka 'graphics card'), but that's later this year. Programs are agnostic to the output device - the same program will run using cursor movements, etc. on an ANSI terminal as on the smart (RubyTerm) terminal.

The BCPL OS - doesn't really have a name but it's currently sort of unix shell like and I plan to implement IO redirection and pipes - trouble then, it just becomes another unix-like interface. Is this what I want? I don't really know!

A demo I did last year of it in operation on a serial terminal that I did as a challenge:

https://www.youtube.com/watch?v=Bg-DcjrJ8g0

The underlying VM that runs that BCPL system is capable of multi-threading. This doesn't rely on an interrupt driven scheduler but after a time-slice, then VM will perform a thread switch when it executes certain instructions. This is essentially the same as the Inmos Transputer microcode engine - it's just a lot slower - the Transputer ran a a clock speed of 25Mhz, my VM has an effective clock speed of somewhere between 0.2 and 0.5Mhz. The VM is an "ideal" target for the BCPL compiler though, so code generation is very efficient and the opcodes in the (bytecode) VM are quite complex in their own right while being very compact.

On the history of operating systems written in BCPL: There were many. OS6 on the Modular One in the early 70's (a mini computer that may have been the forerunner to the Transputer), The early Amiga OS (68000) based on the Cambridge TRIPOS and probably many many others lost to history. BCPL was also used to bootstrap not only B then C, but a language called Imp which was another Algol-like language that could have been another C it it hadn't been a UK university project (Imp went on to be the language to write some very efficient operating systems in the 70's and early 80's, (EMAS, Mouses), but yet another one lost to history, although preserved, so one day...)

What my VM doesn't have is memory management - but neither does the 68000. There are versions of Linux that do run without an MMU though - look at ucLinux for example. I could implement a crude memory manager to no map memory but to offer segment protection, however that would make it run even slower, so not worth it - defensive coding rules...

So where is it going? I really don't know. Right now I've had some health issues (nothing life threatening), and am in the middle of a somewhat large house move/relocation - moving 20 years of living isn't easy, however hopefully the dust will have settled by the end of April and I'll know where I'm going.

I'm open to suggestions/opinions but no guarantees at all that I'll implement them...

(Also on the open source thing - not right now, so please don't ask - I've been badly bitten in the past trying to maintain open source code, had it stolen, manipulated, had demands and threats for support, so no. Not going there for now)

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Great project!

Thanks for opening this thread. Better to talk about this here than in the Minix one.

First of all, all my compliments for people like you and others in this forum, that have the abilities to create both hardware and software.

My own project is currently apart from other life things, because once I end the hardware design phase, I won't be able to program a single line of code for it.

It uses no FPGA, even being that the trend due to the scarcity of discrete chips for certain tasks. But scarcity doesn't mean "lack of". I searched for options for graphics chips and found several interesting chips from EPSON that even feature hardware sprites. Chips available today.

But it seems people like more to have their own FPGA based graphics chip with the features they would want instead of adapting existing chips by widening the data or address bus with a latch, a thing it seems more difficult than programming an FPGA. And maybe it is...

Some random thoughts trying to connect operating systems, shells, and high level languages...

From a user perspective, an OS is interesting because of the interface (the shell) and the applications. From a programmer perspective, it's interesting because of the facilities (the API) and the language(s). So that's four angles to use, to see what might work well (be possible to make, be popular for collaborators and users.)

We have unix-like OSes, which tend to be built with, come with, and favour a C compiler. Linux is perhaps a big one, and Minix (recently mentioned) is a small one. Coherent, as recently mentioned, was a unix-a-like too. (Fuzix is small too.)

And we have BCPL - what kind of OS does that best support? There's the original Tripos, and AmigaDos which developed from it. (And RubyOS, which I can't say anything useful about!)

There's also Oberon, both a language and an OS - also with a windowing system and a CPU. I wonder if Oberon would be good on the '816? There was a 6502 port, of sorts - but it might have only been a cross-compiler.

The thing with being *nix like is that once you have a kernel that answers to standard calls, and a compiler that compiles standard code, then the rest is easy.

I'm no programmer at all but have been able to compile many programs not available in binary form, because there were both the tools and the source code available.

In my opinion, between the regular user that just want to browse or play, and the developer or hacker, there is a community of advanced users that rely on what you programmers are able to provided them with.

And that's where a "standards compliant" operating system, *nix like, comes handy.

My Coherent or Minix suggestions has been done in that way. To have a operating system "standards compliant". But maybe FUZI or RubyOS or Contiki, ucLinux, or whatever, could fulfill that purpose:

that people like me could turn on the computer, have a command line with well known utilities, and a compiler or scripts that would allow to install new software. At least that's my experience with Linux, and I'd like to be able to have it done in a 65816.

Why the 65816? Because it is so easy to build a computer from it that it should be matter of secondary school teachings. And that would mean that many could have their own designs where they could build their own computers from scratch - the PCB I mean - and then from there make it grow by adding the hardware they need. And then just install an operating system to make it run. A operating system that like yours, would have enough for run with a CPU, some RAM, a ROM and a serial comms chip. And from there, expand and learn, or write drivers or something.

Today it's all about programming over SoCs with predefined hardware designs that you can't usually expand, and have everything included but have the machine itself locked down.

Do RubyOS allow for that? Can I (figuratively) install RubyOS and have a console to begin to compile and install software from? Can I take software written in C and have standard utilities or shells running on RubyOS? Then there is nothing to ask Minix or Coherent for.

About FUZIX...

"The current port for 65x02 and 65C816 uses the 8bit modes and also makes some fairly careful choices in order for swapping and task switching to work wel. In particular it never uses mvn/mvp in user space, never pushes and restores a bank number, and never assumes the stack and data are in the same segment, or in segment 0 or that banks will not change mid execution.

I would be very surprised therefore if you could use the WDC compiler. and as it's a closed product there's no real way to fix that."

Personally, I very much like the idea of a native compiler (for whichever language) but of course it's optional.

(I might have characterised CP/M, and indeed DOS, as being most strongly associated with assembly language rather than any high level language. Not sure if it helps. It might help a bit, because the same is true for most 6502 systems. Even though, in both cases, compilers were available.)

The low-level RubyOS has a simple command-line interface with editing and history recall (up/down/left/right arrows and a few more).

Behind this is code that provides a set of jump-points to do stuff like print a character, read a character from the keyboard, open/read/write/close a file. There are 2 other OS level entrys - one is OsByte - which, as its name suggests is an extra set of commands numbered from 0 through 255, so one byte which optionally take (and return) arguments in the X and Y registers (also byte wide). An example is osByte 131 which returns the start of user memory in the X and Y registers (a 16-bit value). This is known as PAGE in the BBC Micro world. Another set of OS entrys is called osWord - this has the code in A and a pointer in XY to a parameter block in RAM. osWord 0 is "read a line of text", osWord 1 is "read the clock" and so on.

There are a whole host of "indirection vectors" so that if desired you can expand these calls (and many others) by patching your code into the indirection vector then ending your code with a JMP (oldVector).

This is all documented in the BBC Micro advanced user guide.

So this level is a low level, but it enables the BBC Micro BASIC ROM (and some others) to work unchanged in the 6502 board or the '816 board in emulation mode.

The OS has a notion of a "Language ROM". This is code starting at $8000 extending up to $BFFF, so a 16K block. This is where BBC Basic would live and where the normal target for C programs is, so you can run a C program from the filing system by typing RUN programname The RUN command can be abbreviated with a /, so /edit <filename> and so on. Inside a Language - e.g. BASIC you use a star prefix to execute OS commands. My OS has an easy way to add more commands into the OS ROM if required.

On the '816, one application is my BCPL VM. This is a "Language ROM" in that it occupies memory from $8000 through $BFFF and contains the interpreter for the BCPL CINTCODE Virtual Machine. When run, it loads some compiled BCPL libraries then jumps into CINTCODE code execution mode with the VM's PC pointing to a compiled BCPL program. This program then initialises memory - all 512KB of it for use with the getvec() function (BCPL's malloc) then loads a pre-defined set of shared libraries and finally loads the command line interpreter which is just a normal BCPL program. The CLI uses the library functions to read and parse commands as you'd expect. Commands are compiled BCPL programs which can be any size and allocate data arrays of any size until you run out of RAM. Loaded programs share the libraries which minimises memory usage.

At this point, it's more or less the same as the BCPL environment I'd run on my Linux desktop - just 1000 times slower with less RAM. I can run the BCPL compiler and my editor for program development. What I don't yet have is an '816 assembler. One day.

If I were to port RubyOS to e.g. Foenx then it would require re-writing some of the low-level stuff to handle the devices and screen - Ruby does not have screen RAM as everything goes down a serial line. There may also be some issues with the memory map, but I've not looked too deeply at it. RubyOS also assumes that all natively executable code resides in bank 0. Compiled BCPL code can be in any bank although it's all in Banks 1+ apart from the low-level libraries needed to actually bootstrap the system. RAM in Bank 0 is precious and is used for the CINTCODE stacks and global vectors (one stack and gv per process)

It has proven to be fairly robust in operation - the getvec/freevec use guard words to check for heap corruption and using a copy of the global vector per process can stop a process accidentally (or sometimes deliberately) overwriting an entry. It won't stop a program simply zeroing memory from 0 upwards only an MMU would help there.

For C programs, assuming you have cc65 configured for the 6502 board then - mostly you can run existing C programs. Basic getchar/putchar is there as is simple file operations - open/read/write/close. What's not there is fork/exec and so on. however - my C editor is just under 1500 lines of code and compiles to just under 16KB of 65C02... This is going to be the biggest limitation. Would a native '816 C compiler help here? I've no idea because I don't have one and have no desire to create an environment to support one either. Also bear in mind that 'int' is 16-bits with cc65. You need to code/re-code when targetting 8-bit micros as they all have their tips, tricks an shortcuts - knowing their calling convention if/when the compiler needs a hint is also handy although it may be that some of the newer C compilers are better at this than the traditional ones.

The 6502 has traditionally not been a good target for C for many reasons, however progress has been made (not just for the 6502) and there are now new algorithms and techniques for dealing with e.g. local variables, recursion and so on that have very much improved things in that past few years alone and it looks like cc65 is being left behind in that respect but who knows what it's future will be.

Compiling C natively on the 6502 or '816 is a holy-grail for some and I have done it myself in the past - Aztec C worked on the Apple II, but was very slow. I suspect that trying to get a modern C compiler to run on the 6502 or 816 would be almost impossible. The BCPL compiler can run although I've not yet managed to get it to compile itself. I think that there isn't enough RAM although I have some other issues to do with floating point that will have to wait. The BCPL compiler is about 45KB of compiled code but it wants to read in all the source code and built up the parse tree in RAM and that's optimised for speed, not space...

The '816 will not be the final CPU for my BCPL system but it will do for now. I'm more or less at its limit with what I can do - however who knows and even if I had a 4MB system what would I do? It would be nice, but I'd just write bigger programs which would be slower... I will expand Ruby to 1MB at some point though.

If you want a demo of a C program running on the Ruby 6502 board, then:

https://youtu.be/rPGCT0lah4Q

The source code is

https://unicorn.drogon.net/circles.c.txt

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I am hugely concerned by your crisis of confidence. I hope that it is only related to moving home which can perturb the hardiest of souls.

I share your despair that everything looks like Unix. However, if you make legacy ABI wrappers to a Unix kernel then, yes, everything looks like Unix. However, if a Unix wrapper is an equal peer with your Commodore and Acorn wrappers then you have much more freedom. It is trite to say that the limitation is your imagination but I find pre-Unix systems such as Data General Nova and Hewlett-Packard 2116 inspire me as much as Ruby, Commander X16 or Foenix C256.

I find your software particularly inspiring. Among all of the projects described on the 6502 forum, I look towards Ruby as the best template for software. You have shown empirically that Acorn BASIC remains relevant as a shell, assembler and bytecode interpreter. Indeed, all of my doodles which fall short of this criteria are discarded. In particular, I hope that all of my hardware choices will run your software environment with very little modification. Actually, your awesome success gives me a crisis of confidence. Where I would make different design decisions, I am left doubtful that my vaporware my not achieve feature parity with your implementation.

If you want ideas for future development, I suggest:-

• Applications which require minimal processing power, such as home security, medical diagnosis, audio or CAD. I would be particularly interested in circuit CAD.
• Look to systems which were destroyed by Unix and Windows, such as CP/M, VMS and Tandem.
• Look to other hypothetical forks of technology, such as Commander X16 and Foenix C256.

I find your work to be a unique and intriguing transatlantic blend of technology which could have occurred if Commodore, Apple, Atari and Acorn worked more closely. I am disappointed to see you take a route towards Unix. A very anti-Unix path wo0uld be support for typed filing systems. These were common on mini-computers. Furthermore, Apple and Commodore systems have binary, text and/or fixed length records. I'd like to see a special type to implement line based deduplication. This would allow endless revisions of assembly to be held compactly. This would aid bootstrap of a self-hosting system (able to produce its own Gerber files). I've had success with multiple directory types. Specifically, an abbreviated directory type with a fixed number of entries, short compressed names and no time-stamp meta-data. This works very well for core branches of a filing system.

One of the newbies suggested audio as ADSR envelopes. I believe this would work particularly well with remote desktop. Indeed, I suggest a large extension to POSIX stdin, stdout and stderr to include an audit log, multi-user multi-touch GUI, ADSR/PCM audio and 2D rendering. In particular, none of this requires piping or I/O redirection. However, if you want to implement redirection, please provide a mechanism to construct a meaningful progress bar. For inspiration, note where AmigaOS diverges from POSIX. For example, Amiga binaries are able to determine CLI or GUI invocation. This could be extended to cover console, text windowing or bitmap windowing. This is in opposition to Unix derivatives, such as Plan9, which attempt to eliminate the distinction between text and graphic windows.

I would strongly suggest a "yield processing time" system call. In the trivial case, it would do nothing and return immediately. However, this hook provides enough upward compatibility for all applications to migrate to their own 16 bit address-space, with or without pre-emptive multi-tasking. In particular, this eliminates several horrible heuristics to guess if a process is busy or idling. Trivial environments may otherwise be single user, single tasking, single core, single threading similar to CP/M, Commodore, Acorn or other systems.

I recommend a key/value store. This allows all applications to use buddy allocation within a 16 bit address-space and for all applications to share one instance of a slab allocator. It also allows applications to share data. The most obvious benefit is that text editing is not limited by an application's address-space nor any particular bank switching scheme.

A system call for key/value store check-point would allow applications to be mirrored and implement hot fail-over in the manner of Enterprise Java. Indeed, a carefully crafted API and filing system would allow seamless file, program and desktop migration; possibly via virtual machine containers running on commodity hardware. A key/value store with nested transaction isolation has separate merit. In particular, it offers a convenient interface for shared-nothing parallel processing. This eliminates most of the deficiencies around POSIX threading in combination with POSIX mmap().

I have many issues with POSIX but the sprawling API is an increasingly large attack surface with decreasingly freedom of choice for implementation. In particular, it is an increasingly thin veneer over an MMU with TLB. It also requires single cycle privilege violation detection. 6502 can be extended to compete in this field. However, without economies of scale and access to contemporary fabrication facilities, it is almost guaranteed to fail. I am also concerned that it is a lost battle. Android and iOS are deprecating virtual memory and instead rely upon journal state to implement fast re-start. A key/value store may hold the necessary state. This would allow operating system development to entirely skip any phases requiring virtual memory.

Separately, I have found that 6502 is highly suited to run WebAssembly which is already supported by 40 languages. In particular, it makes no assumption about FPU support and only requires little-endian representation. In this regard, 6502 competes equally with x86. JavaScript implementations are increasingly migrating to WebAssembly as an intermediate representation. This works in a manner which is compatible with Forth, Pascal, C and Java.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

Thanks for the concern. Today we knock a wall down. It's a wall supporting some building on the floor above, so only mildly concerning ... I'm also struggling with getting my home office going - it's a low priority to getting a working kitchen going (then bathroom, livingroom, etc... !!!)




Things I have in the back of my mind are other OSs - or papers describing other OSs. One is just called OS6 - and you won't find much about it - I've found just 2 papers. It's written in BCPL and ran on something called a Modular One at (I think) Oxford University.

Another 2 similar are Mouses and EMAS. To find more you'll need to search for the archives of Edinburgh University.

However having a subset of Posix style "system calls" isn't that bad, plus the Acorn MOS style interface for "machine control" is, for now, working on Ruby. What these don't give me is multi-tasking, but that's OK. I am currently doing that inside the BCPL VM. That effectively gives me "hardware multitasking" (probably more correctly multi-threading). The global linkage area in BCPL is not a million miles from EMAS either (at a glance, anyway) so there are some interesting parallels.

The unixy-like thing I might have been thinking of is more the actualy shell or command-line interface. Without going full-on GUI what do you do? A unix shell is a powerful and easy to use thing. It's possible I've been spoiled though - the concept of std IO redirection and pipes is something I want (but is there a better alternative?) Also the concept of "do one thing well" is what I also want, although even there, my "ls" command has sort built in (although the sort functions are part of the run-time shared library, but even so, it makes "ls" a few lines longer that it needs to be - at the convenience of not having to do what I remember under Unix v6, e.g. ls | sort | pr -4 -l1 or some-such.



I've never been a fan of a typed fileing system - I can see its advantaged, but at the lower level a string of bytes can be read by anything. Fixed length records are implemented with seek (and more efficiently with a filing system that supports sparse files) One of the first filing systems I used was Apple DOS and 31 character filenames (with spaces). I was somewhat dismayed with MS DOS when I used it latterly and it's 8.3 limits - right out of CP/M. The Ruby filing system has 21 character filename support.

But things like long filenames, file types, record lengths, and de-duplication need more CPU cycles, more RAM and more lines of code. The Apple binary or text based files were merely an operating system convention - the on-disk format is the same. Commodore used another CPU to handle it's filing system. As for the Acorn ones - I can only wonder at what they were smoking when they came up with that format. It must have made sense to someone at the time, but I never got the hang of it. Ruby supports a 32-bit timestamp, 32-bit load address, 32-bit execution address and a 32-bit 'flags' field - one bit of which is used to denote 'locked'. These are enough attributes to satisfy most Acorn MOS and Apple DOS/ProDOS requirements but does leave room for expansion.



On the ADSR front - take a look at the Acorn "envelope" command and sound system. Ruby supports this by sending the data over the serial line to the "smart terminal". (Supported, but not currently implemented - the smart terminal is based on my RTB BASIC interpreter which does support it, so it's only an hour or 2's work to carry it into Ruby)

And on "smart terminals" the fore-runner to X windows worked as a multiplexor on the host sending a serial stream to it's smart terminal to make sure the right characters went to the right windows. This is potentially feasible but long down the to-do list.



That's only going to work on well written applications. However it's similar to the BCPL coroutine mechanism and the early Acorm ARM OS which was co-operative multi-tasking.

The multi-tasking/threading I have in my BCPL VM works similar to the way the Transputer did (does) it - after a fixed timeslice, the next key instruction will force a task switch. In the Transputer it's a jump instruction - it's similar in my BCPL VM, only I have to do extra to preserve the VMs registers for that task - the transputer just trashed them, so the compiler writer was expected to generate code that did not rely on the register contents after a jmp instruction (only 3 registers so not the end of the world) I could do this in my VM, but I don't have control over the code the compiler generates (yet - for no reason that I don't yet want to dive into the source code of the compiler)



In the BCPL system there is no bank-switching. It's also a 32-bit system. My text editor, written in BCPL can edit files up to about 400KB in size in a 512KB RAM system. Sharing data - well with no MMU, the possibilities are endless However I'm looking at the CSP model - transputer links and channels, so a program can open a channel, write data to it - which will stall, then another program can read from that channel and so on. With clever coding then a channel can be a hardware link to another system.... That's for the future though.



Where do you draw the line though? This is a hobby retro project (for me, but there are other systems out there) - it's do-able, but more code, more debugging, more to go wrong.



Personally, I don't think there is anything to compete with - it's a hobby level project - which isn't to say this isn't possible, but be realistic. I did plan early on to treat this as a "what if" - meaning "what if I applied what I know today to something I used 40 years ago". I came up with a poor mans BBC Micro because that for me was the pinnacle of the 8-bit micro world at the time - and while there were 6502 systems with getter graphics and sound, the BBC Micro was the ultimate programmers and hardware engineers 8-bit micro. I ran a complete factory automation system on a network (yes, network - Econet) of BBC Micros in the early 80's. We had automated loaders, CNC machines to control, AGVs and a large materials transport system - all controled by BBC Micros in "islands of autonomy" using the network for job control and routing. (All coded in BCPL)

I'll re-read this later - that wall isn't going to knock down itself ...

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

(OS6 sounds interesting! I followed some breadcrumbs and posted over here.)

Thanks for the link. Good tutorial. Some of the concepts described in the tutorial apply to architectures like the 6502/65816, and other memory-mapped I/O processors.

_________________
Michael A.

Following up my own post, I remembered this project:

Called The Blit in 1982: http://doc.cat-v.org/bell_labs/blit/

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/