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.
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!
The Big Bake
The next morning comes – round about 5:45am and the dough has risen!
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.
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.
What next – it never stops here… I think the wholemeals might be ready to go into the oven.
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.
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)
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.
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.
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 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.
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!
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…
This is just a short follow-up to the last post; Comparing BASICs… There, I talked about the differences between BBC Basic and what was effectively a Microsoft BASIC (EhBASIC), however I decided to take a few moments and have a proper look at the published MSBASIC sources to see if I could make it work on Ruby.
And an hour or 4 later – yes. Success with the Commodore version 2.0 – obviously without the “KERNAL” part which is the Commodore equivalent of the Apple II Monitor or the Acorn MOS – what we might call a BIOS today.
The main thing that KERNAL gives a Commodore system (PET, Vic20, C64) is the screen handling – this lets you cursor up to a line, edit the line on-screen and simply hit the return key to (re) enter it into your program.
The MS sources have a simple line entry system with conditional assembly for the many different systems MS sold their BASIC to – some vendors changed it, some were supported directly. I changed it to use the RubyOS standard “getline” code which gives me line editing, history and easy access to the RubyOS star commands.
Character output was similarly changed to point to the RubyOS routines, however there appears to be some issues regarding CR+LF handling that I couldn’t quite get right, so I just edited the code to make it work.
This is MSBASIC level 2, assembled for a Commodore system running on Ruby displaying the MS “Easter Egg”:
Microsoft added a little “Easter egg” into the BASIC 2.0 for Commodore – if you enter
then it would print MICROSOFT! on the screen. This didn’t work initially, then after wondering why it was crashing and after looking at the code I found that it poked the characters directly into screen memory – which is at $8000 in a PET, etc. … This is where I assembled the BASIC to load and run, so I decided to change the easter egg code to simply print it to the screen. A small complication is that it uses “PETSCI” codes which are obscured in the code to make it not obvious that it was there – I ‘fixed’ that for Ruby too. the ‘a’ at the end would be an exclamation mark on a real PET/C64.
Microsoft Source code
The sources for the 6502 version of Microsoft BASIC have been published for a number of years now and it seems that Microsoft aren’t doing anything about it, however that doesn’t mean it’s in the public domain, free to use and sell. Microsoft still holds the copyright to it so while I feel it’s fine for me to use it, adapt it for my own personal use, I’m fairly sure that if I tried to sell it I’d be in a somewhat sticky position, however if anyone else wants to have a look at the sources, then I suggest starting here:
I created a new target for it, but used the CBM2 target as a template for everything to try to keep all the Commodore changes and features. (Such as the Easter egg) The one thing I’ve not looked at is the file handling and while I’m sure I could make it work with the Ruby Filing System, I’m not sure it’s really worth it for now. (And also, perhaps selfishly I am wondering why I want to use such a relatively primitive BASIC compared to BBC Basic)
Ruby 6502 has been running well on it’s PCB for some time now and interestingly enough (and curiously!) during the past few months other 8-bit projects have sprung up…
This started probably about a year back when Dave, the 8-bit guy made a video talking about what his ideal 8-bit micro might look like – which in summary is essentially a slightly better Commodore C64 with possibly a 16-bit processor (The 65C816 rather than the 65C02)
Since then, there are three project that I know of in the public eye making just such a thing. The Foenix C256, The Commander X16 and the Neon816. I’ve been following these projects and in particular te Foenix one was really interesting to me early on as I had been looking for a 65816 platform to do something for myself, but in the time it’s come to alpha board testing, I’ve gone down my own route, however…
Anyway, in the Commander X16 group (on Facebook), I had a brief discussion about BASICs and offered to do a brief video on BBC Basic vs. a typical Microsoft Basic. C64 BASIC is Microsoft BASIC 2… MS wrote 2 BASICs for the 6502, both were used at the same time with the level 2 BASIC having a higher precision floating point and a few other things. From a published version of the source code:
; These are the first eight (known) versions of Microsoft BASIC for 6502: ; ; Name Release MS Version ROM 9digit INPUTBUFFER extensions .define ;--------------------------------------------------------------------------------------------------- ; Commodore BASIC 1 1977 Y Y ZP CBM ; OSI BASIC 1977 1.0 REV 3.2 Y N ZP - CONFIG_10A ; AppleSoft I 1977 1.1 N Y $0200 Apple CONFIG_11 ; KIM BASIC 1977 1.1 N Y ZP - CONFIG_11A ; AppleSoft II 1978 Y Y $0200 Apple CONFIG_2 ; Commodore BASIC 2 1979 Y Y $0200 CBM CONFIG_2A ; KBD BASIC 1982 Y N $0700 KBD CONFIG_2B ; MicroTAN 1980 Y Y ZP - CONFIG_2C
BBC Basic was first sold in 1981 on the early BBC Micros with the latest version (v4) being in-use in 1984. The main differences are that it’s much faster (almost twice as fast), integer variables are 4 bytes long and was designed to run on a more sophisticated operating system than the typical simple monitors of early systems. (There are many more differences than that though)
So back to the Commander X16 group – I made the video and it’s about 16 minutes long and here it is:
Just an update: After 4 weeks, my post was removed from the Commander X16 group because
Keep it relevant
Posts not specifically related to the Commander X16 project will be removed, even if they’re CBM etc. Please keep all posts relevant to the X16. This group is not intended for general retro tech.
I’ve not done too much with Ruby 6502 in the past few months, however I decided to get a PCB made up for it and I’m happy to say it’s working fine. Well, almost.
- It’s Red. Ruby is Red…
- The clip and wire carries the 16Mhz signal from the 65C02 side to the ATmega side (Yes, I’ve still not bought another 16Mhz crystal!)
- I’m using same 64K memory module I used in the stripboard version – the yellow wire is the chip-select of the top chip.
- The SD card is on a level-shifter breakout board – which I had to extend as I oopsed the location of the ICSP header pins…
- A 65C22 VIA which has 8 LEDs connected to which replaces the single 8-bit latch that I had on the last revision of the stripboard version.
- The grey ribbon cable is the ICSP programming cable for the ATmega and the black cable is the same power and serial cable as before.
I decided to give-up with the video output from the ATmega. Several reasons – one I made a simple mistake on the PCB – easy to fix with a single bodge-wire, however the main reason is that generating video took up about 70% of the CPU cycles of the ATmega so things like it’s serial port and the SD card based filing system went relatively slow. I have a plan B for video – more on that later. Not using video from the ATmega has given me 2 spare IO pins – one I’m using for the SD card “activity” LED, so I can see when the SD card is being accessed.
This has been improved and speeded up a little. A simple block-level read only cache for some operations really helps, as did filling in some little bits like actually validating a filename… That came after a program crash left me with a file I could not delete with anything other than a disk block level editor … (so another utility needed to be written!)
The file system has a fairly standard unixy style open/read/write/close interface, so an interface shim was needed for the RubyOS/6502 side of things. It now supports most Acorn style MOS commands – OSFILE, OSFIND, OSGBPB and so on and translates these as required.
It’s not a BBC Micro!
However… What’s happened is that more or less without really intending this to happen, Ruby has become more and more BBC Micro compatible by the day. This has had some advantages, and some frustrations – I really wanted something new, however I’ve realised that writing something completely new from scratch as a little hobby project is a somewhat bigger challenge than I have the capacity for. The advantages are that I can run a lot of existing BBC Micro software – almost…
The boffins in Acorn HQ made some brilliant decisions back then and the best one is that they separated the operating system from the “language”. The language being BASIC, Pascal, Logo, Comal, Forth and so on. These were normally in a 16K ROM and the BBC Micro had space for up to 4 ROMs plus the operating system ROM. The language (and subsequently utility and filing system ROMs) all occupied the same address space and the hardware and OS would page each ROM in as required. The term “sideways ROM” was used, and it wasn’t long before 3rd partys produced boards that could take more ROMs and even RAM which allowed loading of a ROM from disk so making it easier to load more ROMs without taking the lid off.
So a BBC Micro has 32K of RAM, 16K of paged (sideways) language or utility ROM then 12K of operating system ROM with the hardware IO tucked in there too.
Ruby currently has 64K of RAM with a small 256 byte region for hardware IO and another 256 byte region for communications with the host ATmega processor, however it works with the same memory splits and currently has space for 24K of language ROM, and just under 8K of operating system. I have assembled ehBasic to look like an Acorn language ROM image, also Applesoft and Tali Forth (which is a 24K application) The various BBC Basic ROM images “just work” completely unchanged.
Booting Ruby and entering BASIC now looks like:
Initialising Host processor systems ruFs: Filesystem initialisation  ram: nvr: sd0: sd1: sd2: sd3: [OK] Ruby: Host ready Press SPACE to boot 6502 or the ENTER key for interactive debug: Booting 6502 ====================================================================== Ruby 65C02 running. Loading RubyOS: OK Ruby 6502 By Gordon Henderson, 2018-2019 Ruby OS 64K * help RubyOS Commands: LS CAT DIR CD RM MV SPOOL EXEC LOAD SAVE RUN INFO UPDATE TYPE DUMP FTP MD FILL FX MODE KEY TV GO HELP BASIC ROM LARSON MEMTEST REBOOT EXIT No application loaded * basic BBC Basic ... Loading @ $8000. OK: End @ $C000 >*fx 0 Ruby 6502 2.0 >*help RubyOS Commands: LS CAT DIR CD RM MV SPOOL EXEC LOAD SAVE RUN INFO UPDATE TYPE DUMP FTP MD FILL FX MODE KEY TV GO HELP BASIC ROM LARSON MEMTEST REBOOT EXIT Application loaded: BASIC  (C)1984 Acorn >*cat sd0: ehBasic applesoft test >*cd /sd3 >*cat sd3: bcplRom basicRom applesoft taliForth b4 fforth120 rhBasicz ROBOT-L ROBOT bcpl.r b1 b2 basic3 ehBasic edit110 M1 mandel.txt sieve.b foo.b MOIRE mandel.bas maze.bas maze2.bas ktest.bas forth M2 M3 MANDEL.BB MANDEL-G.BB m2.txt mandelx foo >
This has been copy/pasted from a serial terminal (minicom) connected to Ruby. If you’re familiar with the BBC Micro then you may recognise some of the commands. Lines above the ==== line are generated by the ATmega and those below by the 65C02. (Note the command-list – some e.g. TV do nothing but are there because some BBC Basic programs use it)
Without the ATmega generating graphics what do we do?
Well… Due to the above mentioned separation of operating system and language, it’s easy to isolate the screen handling calls and emulate them over a serial interface. In other 8-bit system in the late 70’s and early 80’s “poking the screen” was a popular way to put characters and graphics on the display, but before memory mapped displays there were serial terminals. The DEC VT series, Wyse, Televideo, ADM3a and so on… And before them? We had thundering mechanical monstrosities – the TTY33 and many others.
Poking the screen on the BBC Micro, while possible, it was generally frowned on – you were supposed to use the operating system (Some games did poke the screen for speed though) What was even better was that the communication between the language and operation system for graphics was for the most part done using character based control codes. This was not new then – serial terminals had their codes to move the cursor, clear the screen and so on, and advanced graphics terminals (e.g. Tektronix) could draw lines, shapes and so-on, just by sending control codes. This was the approach taken by the BBC Micro. You want to clear the screen? Print a Control-L (decimal 12). Move the cursor? Print code 31, (control underscore) followed by the X and Y character positions and so on.
So commands in BBC Basic like CLS (clear screen) were relatively simple – in this case all it had to do was send Ctrl-L (decimal 12) to the output and the screen would be cleared. not only in BBC Basic, but other languages too. Pascal, forth and so on – clear the screen? Send Control-L and the operating system did the rest.
This has proven to be very easy to implement in Ruby – the actual 6502 side really doesn’t do anything other than pass the data up to the ATmega which then interprets it and either gathers more characters or passes it up the serial line to the minicom terminal running on my Linux desktop. I have currently hard-wired the generic ANSI terminal codes into the ATmega, so when it gets a Control-L to clear the screen it sends up the relevant codes (which happen to be ESC ] 2J in this case) and the screen clears. Similarly for other codes to move the cursor (e.g. PRINT TAB(X,Y); ) and so on.
Just doing this has allowed some text based games and utilities to work with relative ease.
Graphics on the BBC Micro followed the same format – send control codes to the display to change colour, plot a point, line, triangle or other shapes. It may seem inefficient, but remember that in a BBC Micro this was all done in-memory rather than over a serial line, however when translated into serial commands, it’s still not that slow. There is a slight down-side though – minicom – the text-based terminal program I’m using doesn’t support graphics. It’s text only… The solution? Write a new minicom using a graphics based back-end.
Fortunately, some years back I wrote my own BASIC interpreter… For that I needed graphics and I used the SDL library to give me easy access to graphics on a Linux PC, so I used the graphical back-end to this as the basis for my new “RubyTerm” program and off I went. I made some minor changes to the ATmega code to make it recognise either an ordinary ANSI text terminal or RubyTerm so it could pass the codes transparently to RubyTerm and let that handle the decoding.
This result is quite nice and although not complete is providing a good basis for something to work on:
That demonstrates simple text output, then GCOL 0,13 selects colour 13 (Bright Magenta). The MOVE and DRAW commands draw the first line from 0,0 to 100,100 and the next MOVE and PLOT commands draw the filled triangle.
The 65C22 Versatile Interface Adapter is a standard peripheral found in many 6502 systems (And there were 2 in the BBC Micro). It has 2 x 8-bit IO ports with handshake lines, 2 timers which can interrupt the 6502, a shift register and various other modes to make communications possible. I’m just using one port here for test it and to use it as debugging (when all else fails, light an LED!) but I have plans for some GPIO facilities using it and possibly some sort of IO backplane with I2C and SPI as well as parallel interfacing.
And that’s about all for now – I’m slowly working through and improving the graphics side and the filing system still has some work to finish it off, although it has been remarkably robust so-far.