This is a sort of spin-off from my recent post where i benchmarked my BCPL system against C... It's a bit rambling - grab a coffee!

Read here if interested: viewtopic.php?f=1&t=8140

As is often the case, the subject drifted to languages and systems I didn't mention, so I thought I'd start afresh.

My interest today is in self-hosted/hosting retro style systems. Along the lines of "what can we do with todays knowledge that we couldn't do back then".

Spoiler: Not a lot.

One issue appears to be the sheer diversity of 65xx systems. Kim/Sym/Aim, Apple 1, II (e and c), ///, gs. OSI/UK101, Acorn (System 1/2/3/4/5, Atom, BBC Micro/Master/Electron), Tangerine (MicroTan, Oric), Atari, Commodore (PET, VIC20, C64) and I'm sure a few more...

What did they all have in common? Well, apart from the CPU really nothing. Maybe a Microsoft derived BASIC is most (but not all) with a company supplied "monitor" or Operating System.

Compare to the Z80 - Just as much diversity but also a lot of commonality in the OS, or ability to run an OS; CP/M.

And that OS lead to maybe more "grown up" software - compilers, business applications and so on - but the important bit is that it generally wasn't tied to a particular hardware platform. You can run Wordstar on many different CP/M systems - can you do that with Appleworks or Wordwise? (BBC Micro)

OK, that maybe a bit of a sweeping generalisation, but you get the idea - there really isn't a common OS base for the 6502.

My idea was to see what I could do in the self-hosting world. I was after a system with a compiler for a high level language with an operating to support it. Good terminal support, graphics optional.

And it's not been easy.

Everyone wants C - because everyone knows C or knows that is where it's at - it's been popularised over the Arduino microcontrollers (and others) mostly in the form of C++ but most Arduino code I see is more or less C. C is what Unix is traditionally written in - basically its everywhere. The original Arduino while being an 8-bit micro at heart has a plethora of 8, 16 and 32-bit registers and other features which makes it a very good target for C.

Putting together a 6502 system to run BASIC is relatively easy though, so that's what most of us do - and what I did initially. There are dozens of little SBCs out there that all run WozMon and EhBasic...

I wrote my own version of the 2K woz-mon (Apple II variant) and got Applesoft going to a degree, but decided I wanted something better and went on to write my own implementation of Acorns operating system so I could run the much better and faster BBC Basic. That was fine - I could write BASIC and assembler (BBC Basic has one built-in) I had a filing system with an interface to suit BBC Basic, and a graphics terminal but it didn't really satisfy the desire for a C or C like language.

A quick search found that there wasn't really any native C compilers for the 6502. Well, there are - Aztec C runs on the Apple II. Orca C (written in Orca Pascal also support Modula 2) runs on the Apple //gs. There are 2 variants of SmallC that run on the BBC Micro, but finding one that was general purpose enough to port to my system was seemingly not possible.

There was C in the form of cc65 and I had already used the ca65 assembler from that package. It wasn't hard to write a new target for it and implement it on my Ruby system.

But it was still cross-compiled.

And that may be good enough for most - e.g. the Arduino folks who are used to cross compiling but it wasn't what I was after.

I looked at other languages - Forth - used it, not a fan. Same for Lisp and then remembered something I'd used on the old BBC Micro back in the early 80s: BCPL. Dug out my old books, got the Acornsoft ROM image and utilities and it ran beautifully on my Ruby 6502 system.

That all started 6 years ago - what now? Well, we do have better C compilers but they're still cross compilers.

I also wanted to know more about the 65c816 so looked for systems - found none other than the Apple IIgs but they're silly expensive in the UK and the Acorn Communicator is as rare as a rare thing. The 8-bit guy was talking about his ideal micro, Stefany Allaire made the Foenix 816 system (stupidly expensive to get in the UK) so I stuck an '816 in my 6502 board - it worked - then made a new board with the '816 and 512KB of RAM. It worked and I ported my OS to it, got everything working as before but wondered how to use all that extra RAM - No C compiler at the time supported it. Bother.

So, back to BCPL and I figured along the lines: "Well, Acornsoft BCPL is a 16-bit system in an 8-bit CPU, so how hard can it be to implement a 32-bit BCPL in a 16-bit CPU". Turned out to be harder than I thought and I've grown to dislike the '816 or at least not enjoy writing code for it any more. It's not as easy to write assembly code for as the '02 - it does require a different mind-set to utilise the banked memory system efficiently and effectively and remember the mode/width of the registers. A high level language compiler using its native stack should be possible to generate good code though, but what did a few years back? I'm not sure anything did....

However, once I had the bytecode interpreter going I could concentrate on the high level stuff and very quickly I implemented the run-time libraries (memory allocator, interface to filing systems, termina IO, graphics and so on) wrote a CLI and had the compiler running natively and had re-written my editor in BCPL so I had achieved the goal of self hosting. (Almost - I've yet to write an assembler - small detail!)

What other languages?

In my other thread there was mention of Plasma - which does indeed look good, but just how portable is it?

viewtopic.php?p=109005#p109005

It currently runs on an Apple II with ProDOS. It may be portable, but has it been tried?

The same might apply to other Apple languages UCSD Pascal (Does run on other systems, but porting doesn't appear easy) their Logo, Lisp,

Another that's not been mentioned for a while is CowGol.

http://cowlark.com/cowgol/index.html

it's currently based round the BBC Micro and might be somewhat tricky to port too.

A solution would of-course be for me to write a C compiler in BCPL - after all, C originated from BCPL (via B) so it's been done before... I'm not a great compiler writer though.

And then portability... The current BCPL compiler can output a few different binary formats - one is called cintcode - it's a Compact Intermediate Code - a bytecode representing a sort of ideal cpu - for BCPL anyway.

Could my system be ported to another '816 system? Very probably, but - just how many are there out there and who might actually want it?

What about other systems? Well, actually, yes. And it's turned out to be much easier than I thought. Just re-write the bytecode interpreter and filing system/terminal interface and off you go. I have done this twice now - once to RISC-V and currently to ARM. The beauty of that was that it was portable at the binary level. I did not have to even re-compile the utilities or even the base operating system. Just the slog of writing the bytecode interpreter and run-time...

Anyway, here we are - I'd still like to pursue the idea of another self-hosting high level language on the 6502, but I suspect what it would really need is a common OS to run it on. Currently there are 2 different CP/M type OSs for the 6502 that I know of, but really, it's 2024 and I do not want the CP/M filing system and its 128 byte blocks with no real idea of file length. That might have been good enough for 1978 but also in 1978 I had the Apple II and it's DOS which gave me a good filing system - maybe I've been spoilt since them... And of-course theres the issue of memory - 64K in the 6502 - with various banking schemes to extend it - it does make it fiddly though - the best I know about is that in the BBC Micro but even then the most contiguous RAM you have is some 36KB with the top 16KB of that being switchable ($8000-$BFFF, it's ROM from $C000-$FFFF minus the IO area)

The only other "generic" OS I know about is Fuzix: https://fuzix.org/ it still needs a cross compiler for the 6502 and mentions:



I think we're stuck in the 6502 world and it's every one for themselves and https://xkcd.com/927/ be damned!

-Gordon

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

If I were more of a software person (and if I had any productivity) I think I'd be inclined to try to port or extend either Plasma or Cowgol - in part because they are active, and could benefit from a bit of take-up.

Having said which, I would support any other self-hosted language adventure! (Moral support only, in all probability!)

One of my oneathesedays projects which I haven't touched in a million years is to come up with some kind of uber-simplified object-oriented system (ala Smalltalk, but CLI-oriented - so, ala GNU Smalltalk, I guess) which could run on a reasonably-specced 8-bitter. I really like the design of ST as a language - it combines the "everything is built from the same stuff" aspect of Forth or Lisp* with a more familiar syntax (block structures, infix notation) in a really natural way, and is the only OOP system I've ever used where it felt like a natural design choice rather than a bolt-on to some pre-existing system; but it's always been oriented toward higher-end hardware, and the way the interface has evolved in modern variants is so over-featured as to be confusing. It'd be fun to strip it down to the bare bones and build something that could be self-hosting on a small system...

* (With the usual "...except a handful of necessary magic" caveat, of course.)

You remind me - Oberon is another system which might be very interesting to port. Perhaps to a VM rather than to 6502, but hopefully it could be native. A VM could of course have a much larger address space than the 6502 (it can have extended pointers and know about memory mapping.)

I've been working on my own pseudo C/Pascal like language for the 65xx that I'd like to use. I've gotten the basics of a boot strap compiler written in C# working; I just need to make a few more tweaks and then I think it will be close enough to begin self hosting.

Ultimately I'd like to see if I can get to the point where it can compile itself on a 6502, and then do some work on my monitor with it.

Edit:
Here's a sample of what I have working so far (working name of the language is Orange Soda):

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Sorry for hijacking that thread - didn't really intend to.

Aaannnddd, grab another coffee...

PLASMA currently runs on a few 8 bit Apple computers: The Apple || series, of course- one VM for 64K machines, another for 128K machines. The Apple ///, which uses a completely incompatible yet sophisticated extended memory management system and running SOS, the big brother to ProDOS. The Apple 1, if it has the CFFA1 storage/RAM hardware card (but has very simple file I/O - see next paragraph). The 8 bit 6502, 65C02, and 16 bit 65802 (or an Apple IIGS in //e compatible memory mode) are supported in different VMs. There has been work to port it to the Acorn by Steve Flintham. The JIT compilers support 8 and 16 bit machine code generation.

So yes, portability to platforms other than the Apple II has been achieved. However, a big caveat is that a fairly sophisticated filesystem is needed to get the most out of it. Many 6502 systems have a rudimentary filesystem at best, if they even have one. This, to me, is the single greatest hurdle to self-hosting a reasonable build environment. Sure, you can have an assembler with a couple of include files and call it good. However, once you start introducing lots of libraries with their associated include files, sample code, editors and compilers, it all gets crowded very quickly on a flat filesystem. A hierarchical filesystem, which is definitely *not* the norm for 6502 systems, goes a long way to making PLASMA a more pleasant development environment. I'm guessing this is the biggest impediment to porting. I started a C64 port, but the floppy disk access and file structure was so painful I just couldn't take it. Apple's ProDOS and SOS support a clean device driver model that provides a path to larger hard drives and even modern storage options without hackery.

Here is a description of just some of the libraries PLASMA includes (mostly Apple II and /// versions): https://github.com/dschmenk/PLASMA/wiki

In my effort to create a comprehensive environment, maybe it has exceeded what most 6502 computers can provide to self-host builds. Probably why assembly, BASIC and Forth are the most popular languages for 6502 self-hosted development. Anyone who has used the Apple UCSD Pascal system for development on a single floppy system knows what I'm talking about.

Inspired by Gordon's *other* thread about post 6502 development, I've been investigating a hybrid approach using a PLASMA VM running on a 32/64 bit CPU (even though PLASMA is a 16 bit VM) and employing a simulator for the 8 bit 6502 parts. The PLASMA modules would run without change on the 6502, 65802, and modern CPUs. Self hosted development could occur on everything from Linux to a Raspberry Pi Pico to a 64K Apple II.

So that's where PLASMA currently sits, and where it is likely to remain until I finish playing with LISP and a hundred other projects.

Just noting what might be one relatively minor point... I have posted elsewhere (or it might have been here, it was a while back) looking for non-unix/unix-like ideas for an operating system interface...

... and basically it went nowhere.

If you have a CLI interface, then it's hard to make it something that's not ultimately familiar - DOS, CP/M and several other derived from the PDP11 all have enough similarities, even Primos and VMS - once you've done one CLI, then there aren't really many differences - you can add bells & whitsles like Unix pipes and re-direction though so it seemed to me that all paths led to Unix - or at least "the shell" with a Posix like interface to a filing system underneath (open/read/write/close/seek). Maybe it's just too hard-wired in my head.

The alternative might be to go pure GUI - as Apple did early on with the Macintosh, but I'm just one person with limited time, so ...

The next step up might be something like the P system - essentially a fairly rigid menu-driven thing. It worked and did what it needed to, but even though I used it on the Apple II for some time I never really felt it was the best thing it might have been...

And it's not hard to put a GUI wrapper on-top of well written command line applications if you (maybe artificially) stick to a base set of rules for a particular system...

-Gordon

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

I'm not sure how much you'll like it, but you could try to port to lib6502, and then only this needs to be ported to other platforms. Yes, another abstraction level...
Currently runs on GeckOS only though.
Details see here : http://6502.org/users/andre/lib6502/
(Which reminds me it needs a github repo...)

André

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Another system - not originally by, but currently maintained by the same author as Cowgol is the Amsterdam Compiler Kit.

I have looked at it with a view to trying to get it going, but gave up early on due to other more pressing things I had to do, however it may well be a candidate as it encompasses C, B, Pascal, Modula 2 and Basic compilers.

There is support for the Z80, so 8-bit support seems possible so just (famous last words) write a back-end code generator and off you go ...

https://github.com/davidgiven/ack

-Gordon

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

I think that would be quite the challenge to run self-hosted. But didn't someone boot Linux from a 6502 with a large external RAM, emulating x86 code?

It was from an AVR microcontroller with (I think) 32MB of DRAM emulating ARM...

https://hackaday.com/2012/03/28/buildin ... x-pc-ever/

Looks like someone has done it again, this time emulating RISC-V...
https://hackaday.com/2023/10/13/because ... duino-uno/

Now... As part of porting my BCPL OS to RISC-V, I wrote a RISC-V emulator in BCPL to test it on - it runs at about 2000 RV instructions/second.... So Could I then run Linux on it? Maybe, but very very slowly...

-Gordon

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

When I was a kid, I wrote myself a Pascal compiler for my BBC Micro. It used the exceptional structured programming features of BBC Basic to implement a recursive descent compiler producing an intermediate p-code, which was then executed by a runtime virtual machine interpreter. (I don't remember whether I also wrote a translater for the p-code to native code.) Sadly, the disks that held that code have (at best) been stuck in my parents' attic for decades and are surely lost to the ravages of bit-rot.

On my own homebrew, I did start writing the lexer and runtime for a Pascal in assembler -- just another project that is lying around waiting for me to get back to it again. I do most of my own stuff in Forth but, yes, natively. I should try writing a BCPL or C some time -- both easier than Pascal, for sure.

--p.

_________________
Mite 6502: http://www.dourish.com/projects/mite.html

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

As an addenda: I'm still working on my latest Neolithic with an intent to (probably, if I ever find time!) include a compiler of some flavour (probably C-ish, perhaps somewhat restricted) and use that to generate a usable text editor.

It strikes me that most first-systems as pointed out earlier have a big issue: 6502, [check], serial i/o, [check], video of some flavour, [maybe], keyboard input [maybe], file storage, [um]... for my mind a system needs three of those four components (serial i/o is nice to have but not absolutely necessary if the others are there).

And if you're going to have a file system, then it seems that FAT16 is probably your friend. Which in turn depends on how small the binary of FatFS ends up... It'll be the first thing I'm working on once I have the hardware working. Not particularly liking the need to bit-bang SPI interfaces, I've rejected SDcards and instead chosen the parallel Compact Flash. Both have the advantage that with FAT16 they can be easily read/written (and formatted, if necessary) on an external computer, providing mechanisms both to get material on and off the Neolithic in a straightforward way - including debugging log files...

Neil