I've successfully migrated my 6502 Ruby project through a few different iterations now - that process started when I wrote it's operating system on the 6502 to mimic a lot of the functions of the Acorn BBC Micro so I could run BBC Basic.

(BBC Basic is 16KB of code, the OS is another 14KB on top of that - quite a rich environment with the language being very decoupled from the OS which then enabled many other languages to run on the Beeb such as Comal, Pascal, BCPL, etc.)

Once I had BBC Basic going, I looked at the others - Comal and BCPL. I'd used BCPL a lot in the 80s on the Beeb, so it wasn't that new to me.

Then, wanting bigger, better, faster (as we all wanted back then) I looked at the '816. Figuring that 16-bit BCPL ran well on the 6502, so 32-bit BCPL would run well on the '816.

In hindsight I wish I'd not bothered and just migrated to another CPU. I've really not enjoyed the '816 and now feel that horse is well and truly flogged and ought to be left to history.

However on the '816 I wrote the BCPL bytecode interpreter/vm and got BCPL going, and once that was working I could subsequently ignore the underlying CPU and concentrate on the high level (retro) language. I wrote a nice little retro style multi-tasking operating system with it and got it to the stage of being completely self-supporting and it was good.

Now, again, with bigger, better faster thoughts I wanted to migrate again... But to what? I did try RISC-V - and I got my entire OS working by writing a RISC-V emulator in BCPL, then re-writing the bytecode interpreter in RV assembler and booted the existing OS under it... and then on real RISC-V hardware.

Many issues though - one being lack of suitable hardware in the range I wanted. RISC-V is not readily hobby friendly either - unless you're good at rolling your own in an FPGA - which I tried and didn't get very far. Systems are typically small microcontrollers with KB of RAM or the other end, 64-bit, multi core, GB of RAM for Linux. ESP32-c3 is almost good enough, but only 400KB RAM. My Ruby '816 has 512KB.

So when next? Some might say ARM is the successor to the 6502 - and I'm inclined to agree. There are many similarities.

Hobby friendly ARM hardware has the same issues as RISC-V though, however there is the Raspberry Pi and the original v1 boards are plentiful on ebay. Some 2-3 years back I did write a bare-metal system for them too, so I hacked that about, wrote the required bytecode interpreter in ARM assembler copied the binaries of my OS over to it and booted it up. Power on to BCPL is under 5 seconds. (faster than an Apple II when booting DOS but not faster than a BBC Micro running entirely from ROM)

And that's where it is today.

The questions I have are...

• What Now?
• Do I talk about it here?
• Does anyone here care or are interested? (ie. do I write about it here, or somewhere else?)

(and for various reasons I want to avoid the Raspberry Pi forums as while I'm using Pi hardware it might as well be any old 32-bit ARM system)

Future plans are to implement a 65c02 emulator under it so I can carry on with some 6502 work. I'm going to ignore the '816 though - that really is dead-end for me. I'm also in the slow process of re-writing my existing Basic interpreter in BCPL (currently C) as one of my desires is the whole old-school "turn it on and it's running BASIC" thing.

Thoughts, comments, etc.?

Cheers,

-Gordon

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

It occurs to me that the obvious next step is to design and build your own processor... something I'm considering myself at the moment though I have 6502 projects to complete first (I've done a handful of designs, most several times - and the one thing I have learned is that trying to copy an existing design is generally a headache).

Do I want to read about it? Yes.

Here? That's a question for the forum moderators, I suppose, but I wouldn't be averse to it - perhaps we need an 'anything else' section?

The snag with building systems around existing vintage processors is basically that it's all been done before... for me the challenge is in either making my own old-school system, or something completely new.

Neil

Yes surely discuss it here! We’re really not in danger of any kind of overwhelming amount of not-6502 conversation. Indeed we already have off topic digressions.

_________________
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?

Curiously, I have gone down this route. And stalled.

The bytecode "CPU" that the BCPL compiler produces code for has relatively complex instructions. E.g. there are 2 different instructions to deal with SWITCH statements in the high level language. Also various 2-level indirection instructions - e.g. an instruction that says; Use the next byte as an offset to a halfword which has the relative target where the data is. (there are many such instructions from branches to subroutine calls and data fetches). So putting that inside an FPGA is way above my ken right now.

However... Going back to 6502 land...

In particular the 6502 based BBC Micro... It was designed to host a 2nd processor from day 1 and today there is still a thriving community out there and a project called the PiTubeDirect - this takes a Raspberry Pi and some level shifters and interfaces it directly to the Beebs "Tube" interface - which is essentially a 2Mhz 6502 bus with a small decoded address range. The original Tube interface was a ULA (Uncommitted Logic Array) which had a bunch of FIFOs to enable bi-directional communication. These chips are virtually unobtainium, so the Pi emulates this and emulates the processor(s) on the other side of the Tube. It emulates the original 6502 CPUs in a few forms (up to almost 300Mhz!) as well as the original ARM designed by Acorn, Z80, 80186, 32016, PDP11, 6809, 65816 and whatever else you care to write the emulator for.

This is a planned target for me - and one reason I went down the ARM route - it should not be a big task to re-implement my ARM code as a virtual CPU inside the Pi connected to the Beeb, select it as a 2nd processor and reboot the Beeb... then to all intents and purposes I have a Beeb front-end to what appears to be a real CPU that then runs compiled BCPL code natively.

The downside is that I'm then limited to the Beebs graphics and keyboard and filing system, but the upside is that that's already a done thing.

Accessing peripherals on the Pi is truly horrible - it's just far too complex to fully understand so you end up relying on other libraries and so-far the quality of code I've seen here (outside the Linux world) is shockingly poor. I suspect the same can be said for other ARM/RISC-V/etc. SBCs and you end up using the manufacturers "binary blob" which isn't a bad thing when it works and is documented well.



Part of my early thoughts were to see what I could do with todays knowledge with yesterdays hardware. (The conclusion I'm coming to is essentially 'very little')

So BCPL on the 6502 was 'done', but on the 816 it wasn't. However it might have been any other CPU and I really did look at the 68000 rather than the 65816 at the time - like the '02 and '816 you can still buy them new (in the form of the Coldfire embedded device) Apple did go down that route, as well as Sun, etc. but I tried to stick to the 65xx systems. the early Amiga OS was written in BCPL too.

So I'm just sort of trying to get ideas and thoughts - while I look at my BCPL Bubble Universe running on a 900Mhz Pi at about 10-15 fps while the poor '816 takes 2.5 minutes per frame... It's hard to not succumb to the temptation of the faster and more efficient CPU...

-Gordon

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

It really surprises me that people have said they'd leave. Really.

There are things here I don't care for but not enough to actually leave. Forth for example - I just don't even bother to open that forum anymore. Almost the same for EhBasic but neither these are reason to leave here.

And yes, I know the anycpu forum well, but really not sure about it - maybe this isn't about a cpu, but a software idea.

So I'll leave it for now.

-Gordon

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

I was in a similar position. The 6502 is too constraining, the 65816 is both too constraining and a dead end design, microcontrollers of any reasonable capability seem to require reading 500 pages of documentation and linking opaque binaries just to get them to the point of booting. Old-fashioned hobbyist microprocessors don't seem to exist any more.

I wanted a system like the Commodore 64 that I grew up with, that I had full control over and could understand every part, only bigger and better. I ended up getting an FPGA development board and have had a lot of fun making the system of my dreams. If you want to try that route, I can help with Xilinx FPGAs and VHDL. There's nothing wrong with other FPGAs or Verilog - I just don't know enough about them.

Even that route is getting harder. Most FPGA development boards either have only the tiny internal RAM or a massive external SDRAM. I only found one that had a decent amount of SRAM and was still available. And that's going to need an adapter board so I can plug in the keyboard, monitor, and so on.

If there is a microprocessor out there with the old 6502 simplicity but slightly more modern capabilities, I'd love to hear about it. (edit after reading posts made after I started typing: I had assumed the 68000 was long gone. I'm glad it isn't. Going to have to have another look at it)

I think it was a mistake to create AnyCPU, even though I use it (and help moderate it.) It's just a balkanisation of what is already quite a small community.

A few people threatened to leave? I'd like to know more. What's the net benefit of restricting our enjoyable conversations? Would they really have left? Were they great contributors? Being held to ransom doesn't sit comfortably with me.

If, in some parallel universe, this forum was about to be overwhelmed by x86 projects, I can see that there would be something to address. But that was never the case.

As Gordon notes, we have sub-forums here, to help keep different flavours of interests separate. That's a tool we should continue to use.

This forum already has a reputation for being negative and unwelcoming - we don't need to help that along.

I looked long and hard... And yes, basically this. There are some still in DIP format, but limiting in other ways. the ESP32 range of microcontrollers come close - they still have some closed libraries but this can be worked round if you need to.



I looked at the Tang Nano 9K - mostly as it already had RISC-V cores for it, and HDMI (DVI) video output as well as more than enough RAM. I just couldn't get all the bits to bolt together in a sensible way, even though they had a GUI based tool to help build it. I did a few simple projects, counters, latches, etc. with it but other things got in the way, so temporarily left it. For now.



For me... It's ARM. At least 32-bit ARM. Even so, getting a development platform going is the hard part. There is an ARM in a DIP package, but it's has limited SRAM - my case could be solved by using SPI RAM but that felt a bit weird. I have plenty of old Pi v1s about and they're cheap enough (Pi 1, Zero, etc. on ebay) and with on-board graphics was relatively easy.

ARM code vs. 6502... Remember the ARM designers had already built several 6502 projects, (Acorn System 1/2/3, Atom, BBC Micro, ...) even visiting Bill Mensch at one point. Acorn did make a 65816 system too - released just before the IIgs, but targetted at a different audience...

On programming: Mostly 3 letter mnemonics which are similar to the 6502 but changed to cope with e.g. more registers.

LDA #42 becomes: LDR r0,#42

LoaD Register r0 with the immediate value 42.

TYA, etc. is MOV (again because there are 16 registers, not just A,X,Y and S. (The ARM stack pointer and PC are 2 of those 16 registers)

Indexed addressing: LDA (zp),y might be LDR r0, [r1] but there are variants where you can auto-increment or add one register to another, so one register the base (like (zp)) and the other the index (like ,y)

I did feel it was tricky at first, but soon got the hang of it. There were a few "lightbulb" moments too when realising that register to register moves go via the ALU and the barrel shifter - So the ALU can be used to add/subtract and the shifter to multiply. The 'core' of my bytecode interpreter is just 2 ARM instructions compared to 9 '816 instructions.



The first, LoaD Register from the byte at [regPC] then increment regPC by 1. (regPC is an alias for one of the other registers). The word formed in r0 has the top 24-bits set to zero - unlike the '816 which loads a 16-bit value into A then if you want the byte you need to mask it out.

The second LoaD Register pc with the address created by shifting r0 to the left by 2 places, then adding this into the contents of ptrJ. (an alias for one of the other registers) This takes the byte loaded into r0, multiplies it by 4 to form a 32-bit word index into the jump table which has its base address held in register ptrJ.

There are similar condition flags too, but setting them isn't automatic - you use the CMP instruction or tag an opcode with a flag to say "set the codes".

Compare '816 with RISC-V and ARM here:

https://unicorn.drogon.net/nextOpcode.txt

Once I got the hang of tricks like that a whole load of optimisations opened up - You don't need to do it like that, and I didn't on day 1, but as I learned more I found I could condense things more.

I'll leave it at that, lest I dilute the 6502 content any more..

-Gordon

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

Unlike you, my hobby hasn't yet outgrown the 6502. I have a backburner project for a custom design in the spirit of ARM, but it is currently on an extended vacation to make way for my 8-bit interpreter projects, exploring the space between the tiny stuff and the MS offerings. 24-bit floats, anyone?

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

I’m genuinely interested in knowing what the thoughts are about the 816 being a ‘dead end’ chip?

I’ve only used it so far as in a 64K environment, but taking advantage of some of the new opcodes, so my experience is still very limited with it. I’d love to know more about the caveats you have come across.

I'm guessing everyone in this thread has already read Garth's article on The 65816 microprocessor: Common Misunderstandings, Plus Attractions; but just in case there's anyone new to the forum reading this I've included the link. And that at the end of that article are links to additional writings on the 65816, including BDD's article WDC’s 65C816 Microprocessor Facts, Myths and why you should use it.

Personally I have entirely thrown in with the '816 and cannot see myself going back to the '02 now.

But where to go after the '816? I don't know. There are still a few ARM processes that are available in LQFP but even the smallest has 100+ pins and a 400+Mhz clock speed. When I started my "Imma build a computer" project I originally looked at RISK V but, sadly, nothing hobbyist friendly has come of out of that stable. Not that I've found anyway.

I also looked at the 386 and 486 - two processors I'm reasonably familiar with - and found that the 486SX (?) was still pretty available. Though I ultimately decided it was to expensive and to complicated. I wouldn't consider it nowadays given the overclockabilty and general simplicity of the '816. [Yup, looks like the FA80486SXSF33 is still available and not as expensive as I remember]

Like (everyone else on this forum) I have an idea or at least a dream of what a hobbyist successor to the '816 should look like but unless I suddenly and unexpectedly become a multi-millionaire, well, it's just so many thoughts in my head.

My hobby hasn't outgrown the 6502 either, so I hope its not me you mean here. My latest 6502 (actually 6507) project is still on-going and once I can source a good supply of ICs I have a good number of folks who've expressed an interest in a kit.

This project, however, has outgrown it. My aims now are looking at a progression in the same way the computers of the 70s/80s progressed. 6502 to - 65C02 to ... Well, the '816 but that's going no-where for me, so on to the next logical CPU which is ARM.

Mid 80s alternatives? The M68K series or MIPS or 80286. Where would you go? The ARM was designed by people who'd used the 6502 for 5+ years. It's a bit of a no-brainer for me, although I did try to not go that way - I got my entire OS running under another system based on the Barkley RISC ideas of the early 80s. But needs must and it's now ARM.

-Gordon

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

That has been my issue too - for various reasons I initially wanted to avoid ARM and did go down the RISC-V route. Initially by using my existing system to write an emulator for it - and successfully bring-up my OS under the emulator, then I moved to real hardware - the best fit was the ESP32-C3. It ran well - to the point where I'd need to start writing a filing system interface then VGA controller for it. However it didn't have quite enough RAM for what I wanted - 400KB and I really was after 1MB.

There really are no hobby friendly modern CPUs anymore. The closest is to use old/recovered stock of e.g. 68K CPUs, although you can get these new in the Coldfire microcontroller format.

Or is there... It's possible to get an FPGA to run a RISC-V core relatively easily. I looked at the Tang Nano 9K. It can easily run a RISC-V core (32IM) and graphics and have a good number of usable GPIO pins, SPI, I2C and so on. I just did not have the knowledge or time at the time to make it work in the way I wanted.

There is a 28-pin DIP ARM microcontroller though. It has only a few KB of RAM, so that's a bit of a non-starter. There are also many (100s) of ARM CPUs in LQFP packages, even SOIP/SSOC/TQFP which are very hobby friendly (for todays hobbyist who can hand solder such things)

The issue, as I see it, is computer vs. microcontroller.



You can overclock an '816 as much as you want and the original 8Mhz ARM will still be faster and the code density better. I was sceptical of this at first, but now I've ported my application from '816 assembler to ARM assembler I can see it with my own eyes. (16KB of '816 code vs 10KB of ARM code which includes the basic floating point code that's handled externally in the '816 code)

And that's the reality. I've been through the whole thought process of getting an existing '816 system (and there are only 2; the Apple IIgs or the Acorn communicator) and using it, but at 2.8Mhz they would simply be far too slow to make my OS usable. The Foenix is limited to 14Mhz so would be viable, but I simply can't justify the cost of importing one to the UK.

Could I write my OS entirely in '816 assembler? Sure - but how long have I got. Apple and Acorn ported their OS and Basics to their '816 platforms then the team(s) wrote the GUI - they key to making them usable was the dedicated team of people writing the good bits in assembler. I don't want to do that and when I started didn't find a good C compiler for the '816 so my compromise was BCPL - and that almost by accident made it very portable to new systems and (important to me) self hosting.



You don't need money - just time. A usable FPGA and dev. kit is under $15 now.

-Gordon

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

Gordon-

I've also been contemplating my future direction with the 6502 environment. My own project, the AppleIIPi, was an attempt to integrate the Apple II and 6502 into a modern Linux environment. I still use this everyday and it satisfied that itch, but skipped the in-between stage of a modern equivalent of a retro 6502 platform.

I think we both appreciate abstracting the 6502 through techniques such as bytecode VMs, so the idea of abstracting 6502 constructs to modern RISC CPUs would be a logical step. I'm intrigued by your experiments with porting the BCPL interpreter to ARM and RISC-V and the lessons learned. I think what I'd like to investigate are extensions of the 6502 into the 32 bit realm. Not exactly the 65832 discussion (which didn't seem to drive all the 8 bit diehards away), but something along the lines of 6502 inspired macros that would expand to native 32 bit (perhaps even 64 bit) ARM/RISC-V code. I've also recently enjoyed playing with the lib6502 simulator that could easily be employed to provide 8 bit binary compatibility for 6502 code. I used this exact concept to implement a PLASMA testing platform under Linux, sans the ability to run native 32 bit code. lib6502 could easily be modified to allow jumping into the native 32 bit code environment that in turn could provide basic I/O and filesystem capabilities for whatever environment *it* was running under - from bare metal to Linux.

Would it be possible to create a subform, something like "6502 and Beyond" to explore such possibilities without polluting the true nature of this site?