A "modern retro" 6502 system in the making


Thought I’d make a brief posts here - as the retro-new thing has been mentioned a few times recently.

So, like some others (many others over on http://6502.org/ !) I’m making my own little 6502 system which will soon be a 65C816 system. I decided to start with the 65C02 as I’ve experience building them in the past - well, 30+ years back. The 6502 is alo the first CPU I did any assembler on, and last year was my 40th anniversary as a programmer, so it’s called Ruby.

I’m slowly blogging most of it in more detail over at https://projects.drogon.net/6502-ruby but thought I’d post a brief page here for any interested.

But before that - one thing that may be relevant is that in the UK (at least) there was a “holy war” between the 6502 and the Z80 - much like Vi vs. Emacs today (and, er, for the past 30years!) The truth was that the Z80 systems were cheap - ZX80/81, spectrum and the 6502 ones not as cheap - Apple, BBC Micro and so on. I feel into the 6502 camp because I started on an Apple II, continued with some own-built 6502 systems loosely based on the Acorn system 1 and elektor Junior computer, then the BBC Micro. 6502 systems did get cheap though - the Vic20 and C64…

Unlike the other 6502/65816 projects, I have no real tie to the C64 - I was probably in my early 20’s when these hit the UK, and from my point of view, just fancy colour versions of the Commodore PET - cheap games systems, but I was studying/researching at uni by then with interests in other things as well as computers - not really into games systems… So fast forward 40 years and I wanted to see what I could do for myself.

I had this idea of “re-imagining” one of those old systems using some modern thinking - what would a 6502 system look like with a modern CLI or GIU? The answer is … slow and un-usable, but maybe there is a compromise… So this is what I’m doing with my system - seeing what I can do, what works and what dosn’t. Having a bit of fun along the way.

A proof of concept was needed to start - and working out the compromise between “just sticking it on a Pi” or in an FPGA vs. “the real thing”. I’ve settled on a hybrid, using a separate “host processor” which is an ATmega 1284p and a real 65C02 (for now, '816 soon) and 64K of RAM. There is a GAL as some glue and it’s all through-hole for ease of soldering it up and testing.

With the Apple II being the first 6502 computer I used, it was easy to get something that looked Apple-like. Wozmon, and so on, but then there was the BBC Micro with it’s fancy BASIC and well defined API into it’s “operating system” and hardware.

What have I come up with so-far? Well - it’s more BBC Micro-like than Apple-like, although it can still run Applesoft as well as BBC Basic. I’m still working on some of it’s operating system, but I’ve found it hard to come up with something that’s better than the BBC Micro. I will expand the CLI interface though - possibly some simple IO redirection to the filing system (SD card and RAM/ROM - hosted via the ATmega) maybe a hardware layer abstraction (think Arduino, pins, wiringPi, etc.) who knows.

The filingsystem is controlled by the ATmega host - and here, for those who know, if you think about it in terms of a BBC Micro plus 2nd processor - where the 6502 here is the 2nd processor, then you’re not a million miles away. The actual filing system is based on Apple ProDOS - hierarchical, 20 characters per file path/name using forward slashes as directory separators. No $, : or anything else in the path, but keeping it easy with /sd0/path/to/file or /mem/path/to/file and so on - the first element of the path being the physical device. It’s limited to 32MB volumes right now because I felt that’s a good trade-off for an 8-bit system. That’s similar to Apple ProDOS8. It’s a huge waste of the 8GB SD card I have right now, but it does have 4 partitions - mostly because it’s using a standard DOS/MBR partition table. If I make the effort, it could be much more, but it’s good enough for now.

It’s pure ascii terminal for now - although the ATmega can generate video. My plans for future video involve a simple peripheral bus system and a $5 ARM based board that can generate HDMI video and sound in software.

My blog goes up to the stripboard version, but the current version is on a PCB:

And so there you go - a little personal “vanity” project to satisfy my old 8-bit cravings :slight_smile:


Just updated my blog with some thoughts on software and what might by my own “ideal” 8-bit computer.

The summary is: A BBC Micro with nicer command-line interface. (for now, anyway - it’s easy to get carried away)


Incidentally, for those not in the UK, Ed did a good write-up on the BBC Micro over on the 6502.org site here:




You wonder in your blog what where you’d go next, which makes me wonder whether a simple MMU or an 816 would be better. I’m inclined to think the MMU might be better - for example you could port Fuzix to the machine. I find the 816 is a combination of different ideas which isn’t fully coherent. If there were a good (free) HLL compiler for it that might make the difference, but lacking that I think I’d be looking for different kinds of enhancements.

That said, there is John Kortink’s large-memory-model Basic which at least serves as a proof of concept. There’s also Acorn’s own Basic 128 which fits a 64k data space into the 16k paged ROM area.


Thanks for reading!

I have a head-full of ideas - it’s a matter of picking the ones that work and that I like. So right now, I know what I want in the way of graphics & sound - right now I’m happy without, but I have a cunning plan - and while I’m not aiming this to be a game/console type system (unlike the current '816 systems) I do feel it will be more than capable. (Because I’ve already written all the graphics/sound code on my chosen graphics chip for another project)

Hm. MMU for the 65C02 or jump to 65C816 - I’m going 816 there. Fuzix? It’s a bit too modern :wink: I think I’m with you on the 816 though - it is somewhat quirky and fiddly especially when it comes to mixing 8 and 16-bit data when e.g. reading an interpreted byte-code VM thing. it is tempting to do something like banked/paged regions of RAM and stick with the 65C02 though.

I’m working on the filesystem right now. Today, it’s usable and I can save/load BBC Basic programs. Media is the 4K of on-board NVRAM inside the ATmega, 6K of RAM and 4 x 32MB partitions on the SD card. It’s sort of unixy in the API, however the Acorn MOS isn’t quite Unixy open/read/write/close, so I have a conversion layer that lives in the 65C02 side that talks Acorn MOS on one side and the filing system on the other and keeps it mostly sane. (If I carry on supporting Applesoft and ehBASIC, then I may resort to a star command or 2 just to dump the Applesoft tokenised image).

As for higher level languages … My aim is for it to be self-supporting and capable of compiling it’s own code. Options there are limited, so I don’t think I’ll get a C compiler going, however there are many “Language ROMS” for the BBC Micro, Pascal, comal, and a good few more, so there is plenty of scope for self-hosting higher level languages - I have my eye on one of them - one I used extensively in the mid-80’s on the Beeb, so watch this space :wink:



1 Like

Oh, yes, self-hosting is a nice goal!

split this topic #6

A post was split to a new topic: Hackaday article on a 6502 smartwatch


Just posted another update on the project so-far. The filing system. It’s now at the stage where I can save/load BBC Basic programs (I’ve temporarily ignored Applesoft and ehBasic for now) and I can also run some other BBC/Acorn stuff on it. Like BCPL.


I made mention in that post about the admiration I have for the folks back in the late 70’s and early 80’s developing all that in the first place - I sit here in a nice environment with a very fast development system. I’m sure it wasn’t like that back then… Even going to BCPL and waiting 10 seconds for it to compile HelloWorld is somewhat frustrating at times, even on my 16Mhz Ruby system. I spent a few years cranking out BCPL back in the mid-80’s but really don’t have much memory of how long it all took to compile…



Someone has a PDP 11/45 available on the world internet that you can telnet to. It’s running RSTS/E, and has (among other things) both BASIC and a C compiler.

I played with it for an evening. Took a crash course in TECO (crash being the defining word), and managed to get Hello World compiled.

What an excruciating experience. I don’t know if all 11/45s were this slow, just this one, or what, but it was awful. It took minutes and minutes to compile Hello World.

Back in college, on an 11/70, it most certainly was not as bad as that thing was. But, that was no rocketship either. We had 3 terminals logged in, hogging a corner of the computer lab, developing our illicit game.

One terminal had the source loaded in to TECO (which has the VTEDIT macro package). This was remarkable, as it commented “Loading file slowly…” when we started it up. We had to manually page the file in, this is why we never exited the editor.

The next terminal was constantly compiling the program. We strived to make changes or fix bugs while the program was compiling.

Finally, we had one that was just running the program.

I look back and marvel that we were ever able to accomplish anything at all. (I should note that our program was in Pascal (first version was in BASIC, but we ran out of memory), and the source file was an egregious 35K in size.)

Honestly, it was this experience with the 11/45 that gave me new found appreciation of BASIC, knowing full well how dreadful the environment for developing code was back then, and what a boon having something like BASIC was at letting folks just get some real work done.

1 Like

My first PDP11 experience was an 11/40 in 1980. Pretty much the same as the 11/45 by all accounts (although the 45 was faster). It ran Unix v6. It compiled hw.c fairly quickly from what I recall - seconds. I have here an Altos 386 Unix system (intel 386, 4MB RAM @ 12Mhz) so I’ll give that a test when I next fire it up…

I’ll put up a little video of my 6502 compilng later today, if I can work out how. Trying to get some benchmarks together to compare BCPL with BBC Basic, but discovered that the BCPL system now wants more Acorn MOS/filing system calls implemented which I’d not previously done (to get the TIME function and make the BCPL ‘linker’ work)