Gordon Hendersons Projects pages

Retro BASIC and BCPL Benchmarks

Posted on March 24, 2023 by Gordon

Doing some tinkering with my retro BCPL system recently and while I’ve always though it was faster than BASIC on the same hardware, I never really worked out just how much faster it really was…

So as it was a retro system, I ran up some properly retro benchmarks (and a few new ones) just to test.

The TL;DR

The good news? Yes! It’s faster! The less good news – it’s not as fast as I feel it could be. It may also seem that some of the benchmarks “cheat”. See the bit below about floating point.

Benchmarking

So lets look at the benchmarks and talk about benchmarking in general.

Benchmarking is not something I’m unfamiliar with – I’ve been involved in the field of supercomputing in the past and there we had a whole suite of tests to do – as well as some people employed just to run (and tweak) those benchmarks, so having seen that tweaking in the past I’ve tried hard to keep the benchmarks fair over the different versions of BASIC I have used, as well as the compiled BCPL.

Remember too that these benchmarks are synthetic benchmarks – meaning that they may not represent the real-life programs we want to run. Would blisteringly fast floating point performance affect an editor or compiler for example?

The Benchmarks

The benchmarks I’ve used are not the ones aimed at “power” users, but a mix of the old ones that appeared in various magazines of the time which are suitable for those computers – that’s the late 1970s to the mid 1980s and a few newer ones which are still suitable for those old systems.

The Rugg/Feldman benchmarks -1977: Wikipedia
The Byte Sieve benchmark – 1981: Wikipedia
Interface Ages Prime Cruncher benchmark – 1980 : Archive.Org
Noels Retro Lab BASIC benchmark – 2020 (ish)
My own Text/ASCII Mandelbrot. (2019-2023)

Hardware

The hardware I’m using is my own designed Ruby 816 system – it has a WDC 65C816 CPU, 512KB of RAM and runs at 16Mhz. The ‘816 is the so-called 16-bit 6502. For the BASIC benchmark runs the CPU is running in 65C02 emulation mode so it’s essentially the same old 6502 that was in the Commodore PET, Apple II, BBC Micro and so on. The 65C02 was used in the BBC Master and BBC Basic version 4 takes advantage of the extra instructions this CPU offers.

The BCPL tests run the CPU in native 16-bit mode. The BCPL environment is actually a 32-bit one, so to make that work there is a bytecode interpreter at its heart. This is written in hand-coded 816 assembler.

BASICs and BCPL

The BASICs I’ve tested are:

BBC Basic – Versions 1,2,3 and 4. Note that version 4 requires the 65C02 which is what the 65816 actually emulates at power-on time.
EhBASIC – This is a BASIC written by the late Lee Davidson which is based on a disassembly of a Microsoft 6502 BASIC. It’s a version that has been tweaked to use some 65C02 features.
CMB2 BASIC – The same BASIC that runs on the Commodore PET, VIC-20 and C64 computers. It was assembled from source and tweaked to run on the Ruby hardware system.

The BCPL is Martin Richards 32-bit 2014 compiler running on the same hardware with the CPU running in native 16-bit mode. The compiler outputs a bytecode (called CINTCODE) for a 32-bit virtual machine which is subsequently interpreted by hand written 65816 assembly code.

The tests were edited and run directly on the Ruby816 system.

And then there’s floating point

After a few runs and tests it became apparent that BCPL as going to win but not for the reason that might initially be obvious… BASIC uses floating point numbers more or less by default. BCPL is more or less integer by default. Some BASICs can use integers but the older, Microsoft variants do this very inefficiently. BBC Basic is the exception here but even then, trying to make sure everything is worked out as an integer can be tricky.

So… What I’ve done is tried to do 2 versions of the BCPL benchmarks. It’s not perfect as things like FOR loops in BCPL are implicitly integers but most of the Rugg/Fielding benchmarks are essentially WHILE loops, so that works out OK.

One just didn’t work well though – the Byte Sieve simply wasn’t appropriate for conversion to floating point, so it’s not included (An integer version is). Noels Retro Lab benchmark was converted using a WHILE loop in the same way the Rugg/Fielding ones were. The floating point Mandelbrot is a line for line translation of the BASIC source (with GOTOs and all) but I added in a scaled integer version – it’s not quite identical, but close enough to be representative.

And in a somewhat surprising twist of fate, there are some occasions where BBC Basic 4 was FASTER than BCPL at floating point. Why? Well… Rather than hand-code IEEE754 floating point in 65C816 assembler, I arranged for BCPL to use the on-board ATmega as a floating point co-processor, so it should be fast? well it is, but due to the way the 2 processors talk to each other the latency is somewhat high. The net result is that doing a lot of trivial calculations (like add/subtract) takes longer in BCPL than in BBC Basic4. Is it worth doing anything about it? Maybe, but not right now…

Timings

Rather than try to use a stopwatch, I have used the timing facilities provided by the RubyOS.

When running in 6502 emulation mode, RubyOS provides a 100Hz ticker to make the BBC Basics the built-in TIME function works as it ought. The other BASICs use their PEEK and POKE commands to access the memory locations that the ticker uses. There is the potential for a mis-read, but I feel this would not happen often enough to be an issue and if it did then the results would be obvious, so a simple re-run would give the true result.

The BCPL system running in native CPU mode has a 1000Hz ticker and this is used when running the BCPL benchmarks.

I ran each test a minimum of three times and picked the time that was the same over 2 runs. So e.g. if I saw 1.24, 1.24 and 1.23 then I picked 1.24. When I got 3 results that were very close but different, I ran it a few times more until I got 2 the same. Might be marginally scientific, but it’s good enough.

The results:

BCPL is generally faster, but it’s easier to gain speed by use of integer loop counters in FOR loops and so on, however even when using floating point there are gains to be had as the compiler makes a good job of turning the text program into something much more compact and easier to execute – even if it’s is still being run inside an interpreted virtual machine.

BBC Basic improved from version 1 to version 4 – in particular the floating point code was extensively optimised to use the 65C02 instruction set in Basic4.

EhBASIC is a fraction slower than CBM Basic 2 but both come from the same Microsoft background. BBC Basic is much faster in all cases, but it is a larger BASIC and was written some years after Microsoft BASIC.

Source Code?

If you want it, it’s here

Conclusion

The world doesn’t need another retro computer benchmark – mostly because we’re not running into shops in the early 80’s and seeing who has the fastest BASIC. The BBC Micro won that war for something vaguely affordable (back then, anyway).
Compiled languages are faster.
BBC Basic4 is almost twice as fast as Microsoft Basics.
BCPL can be up to 8 times faster when you cheat and re-write the benchmark to use integers, but even with floating point it’s still mostly 2 to 3 times faster.
My Ruby816 board has performed remarkably well. allowing me to edit and test all the code in these benchmarks. The BCPL compile runs directly on it and while not the fastest thing, wasn’t that slow to make it unusable. Compiling the integer point Mandelbrot takes about 4.5 seconds.

The Humble “Glass Teletype” and the Lazy Programmer…

Posted on June 24, 2020 by Gordon

Way back we had mechanical output devices for our computers. These were big, slow, noisy and really a spill-over from the days of the telegraph, but they fulfilled their purpose and much code, including early Unix was written using them. Teletype Corporation are possibly the most well known ones of the time, although there were many other manufacturers, but when you see a picture of a mechanical printer it’s almost always a “Teletype” (And even when not, it’s almost become a generic word anyway).

Teletype ASR-33

Fast forward to today and we have big, fast screens and editors that do much much more than the old line-oriented editors of yester-year.

But what happens when you build a retro-style computer, running at retro speeds and you want a screen orientated editor?

Well, in the first instance, you write it, test it, use it and it’s great. In my case it’s talking to my desktop PC at 115200 baud (that’s just over 10,000 characters a second, so to fill a typical 80×25 character display takes about a fifth of a second. Acceptable. I’m also using a custom terminal program of my own making and while it’s a relatively “dumb” terminal its clever enough to only update the screen when needed, and as that update is not constrained by the speed of a serial connection it appears to be really smooth and fast, but naturally, I wanted to see what it would be like on a real (or emulated) terminal…

The 1970’s

But lets wind back some years to the mid 1970’s. Computers were still relatively slow but advances were being made in the terminal department. Mechanical printers were now up to about 30 characters per second (from the original 10) and were quieter, but were slowly being deprecated in favour of the new “Glass Teletypes”.

Glass Teletypes?

These fully electronic devices were initially limited in what they could do. Print from top to bottom, scroll upwards and… Well, that’s about it. The limitation was mostly due to the electronics at the time – Memory was still expensive, logic circuits (rather than a microprocessor) were still in-use, so it was not uncommon to see a rather large board stuffed full of TTL ICs driving the CRT (Cathode Ray Tube, often just called a “Tube” in some cultures) typically green phosphors on a black background. If you were very lucky you might have one with Orange phosphors.

Time marches on…

But nothing stays still for very long and terminals (as they were now being called) were becoming more sophisticated – under program control, the location of the cursor could be changed – some could scroll down as well as up. Partial screen clears (say from the current line to the bottom of the screen, or cursor position to the end of the current line). The net result was that “Screen Editors” could now be a thing and while programmers (initially) still used older line-orientated editors for code, ordinary users now had things like “word processors” which used the whole screen and allowed for easier editing of text for documents, letters and so on. WordStar one of those and that was first published in 1978 and relied on these new smart terminals to work.

1978 also saw the introduction of “personal computing” as we might know it today. Relatively affordable computers with screen, keyboard and storage – aimed at small businesses and serious (as they were expensive!) home users and education. The Apple II, Commodore PET and the Tandy/Radio Shack TRS-80 were the three main contenders then.

But what about the old “Glass Teletype”? They were still in-use for a long time – they were an economical device to connect to larger multi-user time sharing systems and so they lived on for quite a few years. Today they may be considered a bit of a relic. An anachronism or just something for the new kids to laugh at… (imagine a screen and keyboard with no computer!)

Retro (and vintage) Computers…

In the world of vintage or retro computers the Glass TTY is still very much a thing, so for my Ruby project I decided to see how it would work with one – although I do have a real terminal, I chose to use an emulator on my Linux desktop using the PuTTY software.

Lazy programmer…

And what I found was that over the years I’d obviously become quite lazy when it comes to screen handling. Ruby was intended to be vaguely Acorn/BBC Micro compatible when it came to screen handling – and it is, but the Acorn MOS screen handling is very much lacking in facilities required to drive a serial terminal, so while it has cursor move screen clear and scroll facilities, that’s just about it. And although there are text window facilities (to define an area not a modern “window” in a big graphical user interface) you still need to do a lot to e.g. insert a line or character or clear to the end of the line or page.. The net result was that my editor while ran quite well with my own terminal program ran rather poorly when used on a real (or emulated) ANSI terminal.

So back to the drawing board and the old days of working out screen codes, ESC [ then the magic codes. fortunately a standard had emerged which most people just refer to as ANSI. The hardest part? Making the arrow keys and command keys (Home, End, etc.) and even worse the Function keys work. It may be a standard, but there are many interpretations of that standard…

However some work on the VDU handling code in my RubyOS and in my own SDL based RubyTerm and of-course in my editor and other home grown utilities that run on the Ruby board and it’s now running as well as it might have done back in the early 80’s on a real terminal.

Ruby816 – Solving the bootstrap paradox

Posted on June 16, 2020 by Gordon

Previously I wrote about the issues bootstrapping BCPL on my Ruby board and I was moaning about needing a C front-end or “shim” to get BCPL going.

So I engaged the little grey cells and worked out a strategy…

What I’ve done is to write sufficient ‘816 assembler code to initialise the BCPL global vector and create a stack, then to point the cintcode program counter to some embedded cintcode (embedded into the ASM program as a binary blob), and call the cintcode interpreter.

At this point the bootstrap program can call local functions but not global ones. The “blob” is actually the bare minimum in terms of library calls to get BCPL fully going. I created it by simply concatenating the files (sections) and turning them into a form I can include in-line with the assembler source for the cintcode interpreter.

The BCPL bootstrap fixes-up the global vector by scanning the concatenated section images and working out the correct offsets to populate the global vector with. The first call I then make is the getvec setup call to initialise the memory for subsequent allocations, then I call the loadseg() function to load the rest of the library files into RAM as before with the C front-end. It’s already running BCPL at that point, so the last file it loads is the command line interpreter which is loaded and called and the system is ready. This is slightly quicker than the C front-end too as some of the library routines are loaded with the interpreter and remain there for the rest of time.

And so the paradox is no more!

Ruby BCPL Bootstrap

My Ruby 816 project

Posted on May 28, 2020 by Gordon

Brief post to say that I’ve now gotten round to writing up my Ruby 65816 SBC system. Hardware is working well and the software is slowly progressing.

Details here

A Day at the Races

Posted on January 19, 2020 by Gordon

We have a nice point to point racetrack in (near) Buckfastleigh, so today we went over for the first race of the season.

One of the horses that is stabled/trains at the yard where I ride out from was racing today, so it was really nice to see her in action. She didn’t win but was the best turned out for he race thanks to the hard work of Trudi in the stables.

I made a very little video from the clips and pictures I took. Enjoy!

Home Artisan Microbakery – 3/3

Posted on September 27, 2019 by Gordon

Stage 3, but if you missed it, then back to the mix and knead step… or back to the preparation step…

The Big Bake

The next morning comes – round about 5:45am and the dough has risen!

Hooray and up she rises… early in the morning!

The task now is to do the usual clean and sanitise, get the ovens on and get the dough scaled (measured) out and into proving baskets, tins and so on. Additionally, on this particular day I have the added pressure of sticky buns… These are made in the morning from scratch using a fairly standard enriched dough recipe (with eggs, sugar and milk), filled, baked, glazed and sold… Todays were cardamom and cinnamon.

Starting with the sourdough:

The dough is tipped onto the counter and weighed out into the size I’m after. These are medium (600g) loaves so the dough is a rather generous 740g. After scaling, the lumps are shaped into boulles before final shaping.

These are just rough rounds. I then get the proofing baskets and couch ready

and do the final shaping and leave them covered to rest and rise a little more. This is being done against the clock, so that’s 24 (actually 25 as there was a bit of spare multiseed dough) loaves and I aim to have this all done inside half an hour.

Meanwhile the Lincat oven is up to 200°C and the rye loaves which I’d gotten out of the fridge earlier can go in with a big blast of steam…Not forgetting to set a timer!

These are the wholemeal and cheese breads scaled and pre-shaped… There will be 2 cheese loaves, a batch of cheese sticks and 2 cheese rolls for the lovely staff in the cheese shop in Totnes…

The wholemeals are in tins.

The cheese loaves are roughly shaped, filled with cheese cubes and rolled into a log.

These are left to rise in these baskets along with the cheese rolls which I’ve also stuffed with cheese…

Meanwhile, I’ve made up the sticky bun dough – threw it all in the mixer, let it knead and transfer it to a bowl to rise.

This is the start of the cheese sticks. Pull the dough out into a rough rectangle, 2/3 cover in grated cheese then fold, roll, turn and repeat another3-4 times…

Getting there..

Done – for now. It’s covered with the (recycled) cling film and put in the fridge for an hour or so to relax.

The rye breads are usually done by now, so they come out and are left covered in their tins for another 10 minutes or so.

And now it’s about 7:45 or so – I’ve had to do a round of washing up/cleaning and lifted the risen dough to the silicone sheets that go into the Rofco oven and attacked them with a razor…

This is a closer view of one of them – I’m using a large plywood sheet that has been cut to the exact width of the Rofco to load them into the oven.

After loading the Rofco, I’ve more to go into the Lincat. These are transferred directly onto the board with a bit of flour then into the Lincat.

This is the Lincat loaded with the dough – there’s that extra loaf at the bottom (the bakers own!)

Meanwhile the bun dough has risen and we need to tip it out, roll it into a rectangle, cover it with the filling mix (butter, sugar, cardamom), fold and cut, twist and knot…

They’re all the same size… honest!

Left to rise…

What next – it never stops here… I think the wholemeals might be ready to go into the oven.

Or maybe this was when they were done…

This is the breads inside the Rofco oven. After 12-15 minutes, I open the door and whip out the silicone sheets to let them bake the rest of the time directly on the stones.

And here they are…

The cheese loaves and rolls are ready to go into the Lincat oven…

As are the buns…

Timing is key here…

The wholemeals are out …

And don’t forget the cheese sticks – this is the cheesy dough out of the fridge…

Rolled and cut …

and in the oven.

The cheese loaves and rolls are baked…

As are the buns (covered in honey sticky glaze now)

The cheese sticks are baked too.

And finally it all needs to be packed up into boxes and taken to the shops and it’s in the shops by 10am while it’s still warm…

Home Artisan Microbakery – 2/3

Posted on September 26, 2019 by Gordon

Stage 2, but if you missed it, then back to the preparation step…

The Big Mix

Preparation takes place usually at about 3-4pm. A few hours later round about 7:30 to 8pm, it’s time to mix and knead up the doughs which are then left to ferment overnight.

These are the sourdoughs after 4 to 5 hours. They’re nice and bubbly and ready to use.

Now, it’s mostly a matter of weighing up the water and sourdough, tipping that into the mixer, then the flour – giving it a good mix, finally adding in the salt for a few minutes more, lifting it out the mixer and repeat the process…

This is the spiral mixer. It’s single speed with a fixed head, so getting the dough out requires a certain knack, as does cleaning it. Spiral mixers are very common – this is an Italian make and you’ll find these used in pizza parlours the world over.

The rye is mixed by hand – only a few loaves usually and it’s a very wet and sticky dough. Gluten doesn’t develop in rye the same way as wheat, so there’s no point trying to knead it really. Keep it wet with a sourdough starter and it’ll be just fine. I add caraway seeds, malt and molasses to mine.

The overnight white dough that I use for the cheese breads is an olive oil based dough with just a fraction of the normal yeast added (it’s not a sourdough). This is mixed in a small stand mixer that I was able to get a nice dough spiral hook for. These are much better than the usual hook you get with them.

After that, it’s just a matter of getting the liquid ready for the next mix/knead in the spiral, emptying it, dividing the dough into lumps that will fit the containers, splitting up the rye into tins and trying to keep sane…

This is a lump of dough taken out of the spiral mixer and left to rest on the bench while I load it up with the next batch. I try to keep the mixer going all the time so I make sure I have everything ready to load it with as soon as I take one batch out. I also try to plan the loads to avoid too much of one type of dough getting into the next batch, so the seedy ones are often last with the plain white (when I do them) first. This day I had 3 lots through the spiral mixer – my usual sourdough which is a mix of white, wholemeal and rye, then a seeded mix, then the 100% wholemeal. I’m not overly concerned if a few seeds get into the wholemeal – I stopped using the main allergen one a long time ago (sesame seeds)

This is a load from the mixer that I’ve weighed and divided into two – the smaller on the left will make exactly 5 loaves and the larger on the right will make 7. My largest tub will only take dough for 10 loaves, so the split is needed.

Here is some multiseed in the mixer. I get the dough formed first, then add in the seed mix – I make it up myself and is a mix of poppy, linseed (brown and golden), pumpkin and sunflower seeds. I used to buy a commercial mix that included sesame but even though my labels were clear on what was in them, I decided to drop sesame a while back due to some very public issues involving a fatality due to a mis-labeled product. (Pret a Manger)

Last through the mixer is the wholemeal. Here it’s had the initial mix and I’ve just thrown the salt into it. (It’s a bit of a wet mix, but not as wet as the rye!)

While all the machine mixing is going in, I find a few moments to scale out the rye into tins. These stay in the fridge overnight and rise slowly there and are first in the oven in the morning.

The dough is moved into the tubs as it’s mixed and kneaded and gets left there overnight. Now it’s clean and tidy the place up, have some supper and off to bed!

This picture really belongs in the next post as it’s tomorrow morning, but I’ve put it here to compare with the one above. You can see how much it’s all risen. The left 2 tubs are the white olive oil dough and the wholemeal dough – these are both made with dried yeast, although only a fraction of what you’d typically use for a standard 1-2 hour process.

On to page 3, the bake!

Home Artisan Microbakery – 1/3

Posted on September 25, 2019 by Gordon

A few of you may know that I do the home artisan microbakery thing. My pages for that are over here: http://moorbakes.co.uk/ but in these posts I thought I’d show you a day in the life …

I make mostly sourdough breads for sale directly and in a few local community shops. It all started as a hobby, then developed a bit more as a sort of therapy to help with some health issues, then it got out of hand and I was doing afternoon teas for weddings, office party buffets, local farmers markets and I ventured into the lovely world of patisserie, however that all got too much and today I’ve scaled it back down a little so I can concentrate on other things – notably some IT projects, weight loss consultancy (to help others undo all those years of eating too much bakery goodness!) and give a little time to an older passion; horse riding (and perhaps more on that later)

All in a days work

A bake is split into three parts over two days – preparation of the sourdough starters, mixing the dough, then (the next day) the final shape/proof/bake.

Preparation

This starts mid-afternoon the day before the breads are baked. Clean and sanitise the work area and fetch the starters from the fridge.

Sourdough?

Sourdough is just a fancy name for a natural yeast culture. Some may suggest the name refers to the old “Sourdough Joes” who roamed the wild west, some may suggest it’s due to the presence of lactic and acetic (and maybe other) bacterias that come along for the ride giving it a midly sour taste and some may think it refers to a particular style of bread – whatever – to me, it’s just a natural, slow acting yeast.

I keep 2 different types in my fridge: A white wheat based one and a wholemeal rye based one. They don’t have names – they’re just my starters.

I measure them out into big bowls and add flour and water to make enough starter for that evenings dough mix. The jars are then topped up and left out with the big bowls until later that evening. This gives the left-over starter in the jars a chance to start again and get active and bubbly before being consigned to the dark recesses of the fridge until they’re needed again.

As I type this my starters are about 8 years old. Maybe older. I got the rye starter from someone who’d had it for 5 years and they got it from someone who’d had it for 20 years. What does that mean? Nothing really, only that we’ve been able to keep something going for all that time. I know that some people are proud of how long their starters have been living, but the reality is that it’s really “triggers broom” syndrome. All the living stuff reproduces and dies off in a matter of weeks, so it’s really unlikely that what’s in the jar today contains not a single molecule of what was in the jar when I started them. (And every now and then, I transfer some to a new, clean jar and the old ones go into the dishwasher)

That’s the rye on the left and wheat on the right. The bowls are covered and left for a few hours and I get on with more preparation which involves weighing out the flour mixes for the mixing that evening.

That’s most of what I need for that particular evening. A batch of multiseed loaves, some white dough,wholemeals wheat and my Moorbakes Sourdough. The rye flour, etc. is on-top of the rye starter bowl and I use shower caps for the other starter.

Speaking of rye… I mill my own, and wheat sometimes too. I get organic rye (and some wheat) directly from local farms wherever possible. I use organic ingredients wherever possible, although thanks to a cartel of half a dozen or so “certifying agencies” in the UK I am unable to call my breads organic unless I pay them a lot more money than I’ll ever make from selling my breads, sadly.

So that’s about it, however on that particular day (it was a Wednesday) I also chop and grate some extra strong cheddar cheese for the cheese breads I make on Thursdays. Total time is about an hour, so now I clean any mess and get on with other stuff until later in the day.

On to page 2, the evenings mix and knead

Video Demos..

Posted on August 18, 2019 by Gordon

I’ve just watched Dave Murrays demo of his “Vera” video card moving some balls round the screen. Initially confused by how it was working, but now understand that it’s to do with the way the colour works in text-mode, so there is a separate “shadow” block of memory that controls the foreground and background colour for each character position.

So in an otherwise idle 10 minutes, for a bit of fun, I paused his video, looked at his code and re-write it to work in BBC Basic and ran it on my Ruby board:

I did it more out of curiosity and a bit of fun than anything else – I’m also experimenting with screen capture software, rather than point a camera at the screen.

the graphics are still generated here by sending commands from the Ruby board via the serial interface to the graphical terminal on my desktop (The ‘terminal’ is a C program using the SDL librarys running under Linux – it listens to the serial port and interprets the usual BBC Micro/Acorn MOS VDU commands)

You can see my source here: https://unicorn.drogon.net/balls.txt it should run on any BBC Micro. (and it’s not the best, but was done quickly – remember the fun part!)

Ps. If anyone knows anything better than “RecordMyDesktop” that runs under Devuan Linux then do let me know, thanks!

Pps. Yes, this is on my new 65816 board – more on that in a later post!

Ruby 6502 becomes Ruby 65816

Posted on July 21, 2019 by Gordon

Ultimately I wanted a 65C816 system but initially settled on the 65C02 for many reasons. One was that round about the same time another ‘816 project was announced (and subsequently a 2nd, and as of today a 3rd!) so I felt that getting back into the 6502 via my own board then buy into one of the ‘816 projects would be the way to go…

But things change. The first ‘816 system (Stefany’s Foenix) wasn’t to my liking, then the next one – Dave Murray’s Commander X16 has been changed to a 65C02 system. The last ‘816 system – Neon816 is somewhat curios, so I’ve decided to go with my own board for now, so to kick that off, I replaced the 65C02 with a 65C816 on my Ruby board. At the same time, I took the opportunity to make a few optimisations (ie. I removed some resistors that I don’t need because the ATmega host processor has internal pull-ups and with a few software tweaks there can eliminate some unneeded components.

Here’s a photo:

The Yellow LED is the E output from the 65C816 – On is Native mode, off is “Emulation” mode – which is how the ‘816 comes up at power on, so it can run all 6502 code at power up. (This is the default for all 65C816 systems)

Other than a few resistors I’ve removed – I had to add one resistor which goes on pin 3 which is the phase 1 clock output on the 6502 (which is never used in new designs), but is the /ABORT input on the 65C816 which needs to be pulled high. (That resistor is under the board, along with the LED current limiting resistor)

The flying wire is taking the 16Mhz clock from the 65C816 side into the ATmega side and one day I’ll buy more 16Mhz crystals!

(And yes, I’m running the 65C816 at 16Mhz)

So I’m now in the process of laying out my 65C816 board – it’ll be essentially the same as this, but with 512KB of RAM rather than 64K. It will take a 65C02, but that will only be able to see the first 64K of RAM. The ‘816 will be able to see the full 512KB. I have a new bus/IO system planned which I’m testing on the current Ruby board – watch this space, as they say…

Back to the main Ruby 6502 Index page

Gordons Projects

Projects, Fun and Games from Gordon @ Drogon