The trick, which is valid in my book, is to emulate a more powerful micro:
Of course, performance suffers, but here in retrocomputing land I don’t think we worry too much about performance.
Here’s a way, then, or a glimpse of a way, to run RISC OS on a 6502, or Amiga DOS on a z80…
via a tip from @drogon
I found this some time back and mentioned it to someone in another forum, but while it’s an interesting case it’s vaguely relevant to something I’m working on - which is (now) more of a retro software project than it’s original hardware…
The back-story is that the 6502 was the first microprocessor I used back in '78… Fast forward 40 years and I made my “Ruby” 65C02 system and had it run a lot of the old software I used - Applesoft BASIC then BBC Basic and then (as some of us do) I wondered “what if” … So I moved on to the 65c816 CPU and set about implementing a properly retro language for it; BCPL.
I’d already used BCPL on the BBC Micro back in the 80’s and had it running on my Ruby 65c02 board, so it seemed like a natural thing to do, so I implemented the interpreter for the 32-bit Cintcode VM - which is one of several output formats that the BCPL compiler can generate - it’s a “Compact INTermediate CODE” and it’s essentially a bytecode with a 2-deep register stack.
Moving on and I wrote a little operating system in BCPL (a somewhat grand title if nothing else) which has a command-line environment that lets me edit, compile and run BCPL programs directly on my hardware.
But it’s slow, so I’ve been looking at other options and one is fast forward to the future and use a relatively new CPU; RISC-V but re-target my existing Cintcode environment at which point all the code (even at the binary level) ought to “just work”.
So to get a better understanding on RISC-V I’m in the process of writing an emulator for it in BCPL to run on my Ruby’816 board then I can cross assemble some tests on my Linux desktop, run them on my existing Ruby board, even make a good (or almost complete?) attempt with the new Cintcode interpreter before moving to real RISC-V hardware.
And at this point the above bubbled up in my memory - with some little effort I feel I could actually have it support larger C programs and I jokingly suggested maybe even ucLinux - which would be an interesting retro challenge, running a Linux kernel compiled into a RISC-V binary, running on a RISC-V emulator written in BCPL running inside an interpreted bytecode system on a 16Mhz 65816…
It won’t be fast, that’s for sure!
Cheers,
-Gordon
There was ELKS at one time: Embeded linux kernal Source.
http://elks.sourceforge.net/ Since it used BCC , that compiled to 6809 or the 8088/86 it may have had 6809 version of the linux with orginal web site. I am assuming this
is a 16 bit linux but who knows for sure.
I never heard from ELKS in non-x86-contexts, but I haven’t looked around a lot. It could be nice on e.g. on 68k with its linear unsegmented memory.
Looks very alive! Last commit yesterday… \o/
I just threw hd32mbr-minix.bin at
and it looks … let’s say ‘cooperative’.
With Qemu it probably will even have networking, but my day already is far too long… :.(
From another point of view this is essentially a microcoded ARM processor running Linux. Much like, say, the IBM 360 model 30 which had an 8-bit ALU.
