Tweaking the Emulator

When I wrote the original emulator, it was meant to be just that ; and it is actually the basis for all implementations. Some things are just inconsistent, e.g. Ctrl+Escape doesn't work across platforms. So I've been tinkering with that this morning - the Javascript version no longer has the debugger code, and Ctrl+Esc should reset everywhere.

I built it on an emulator framework that's at least six years old and has been used for several emulators of various types, which doesn't help either.

On a related matter, the six function keys which you can program with the fkey BASIC command (e.g. fkey 1,"Hello world"+chr$(13) ) won't work on many implementations because F1-F6 are coopted for something else in the browser or whatever. It is a system standard that these can be done with Ctrl+1 .. Ctrl+6 as well as F1-F6.

Game #2 : Breakout

Gotta start somewhere.

So I decided with a very simple game which doesn't need anything difficult - Breakout. It's modelled on the "Video Pinball" machine's version, which is fairly close to the original arcade.

It's entirely BASIC. The only change I made to the BASIC interpreter/Kernel is to allow the text drawer to scale, so I can do big letters easily .... admittedly they look a little blocky.

I did find a bug though, not fixed yet. You can't use Ctrl+Space , which is the break combination, to break out of a get$() (and probably not WAIT, INPUT, GET() as well).

I'm going to build and upload at the end of the day, UK time, as there are now four versions ; Windows, Linux, ESP32, emscripten . Most of the work is actually done on Linux and the other two are just built occasionally.

A game and some progress.

So, a game does finally exist and works, but it's just a basic squash. It yielded an actual bug, a dumb one. The sound channels have a queue of sound events, you can queue up to 32 sounds or slides. These go in the tail of the queue, and are popped from the head of the queue. Unfortunately the head of the queue wasn't wrapping round (careless), so on the 32nd beep the sound stopped working.

It also now runs in Javascript. Quite well, seemingly, though I don't know how it works on a slower PC yet. Anyway, you can run the Javascript port here.

Still no games.

Didn't work on it much yesterday, and fixed a few bugs. One was to do with rounding and conversion in the SDL tone generator code ; I was using (int) as a cast but casting it too early, and the consequence was that sound stopped playing after about 3 seconds on the tone channels. Another was the latency of sound, it was starting after a slight pause, so if you say hit something and had a sound effect it was slightly too late. I wrote this beeper code something like ten years ago and never noticed this before, probably because it was barely used.

Having been experimenting though I'm quite pleased. I made some mistakes, mostly due to language switching, so I'd write a != 3 rather than a <> 3 and it would barf. I thought I'd discovered half a dozen bugs when writing test code, but it turns out all of them were errors on my part, and the interpreter was doing exactly what it should, even when it crashed. One advantage of the VM design is it's almost uncrashable - some of these retro designs write the code in the target machines compiler, which means bugs can appear there. I'd forgotten that in SAVE "filename",a,b the second b was a length not an address, so I was writing out a 35k data file not a 5k one in the file I/O testing code. So when it was loaded back in - I can't check the size because it's perfectly legitimate to load into some areas - it overwrote the return stack and gave unmatched loop errors.

There is one log term bug. If I power up the ESP32 and leave it overnight it starts keyboard repeating at some point - it's after several hours. It starts typing on its own, and only a reset of the ESP32 itself fixes it. I'll code read the ESP32 interface code, but it's so simple I think it might be a fabgl bug, memory leakage maybe ?

A couple of minor tweaks to be added today ; I want to write a couple of functions to get sprite information, and add a command to kill a Sprite. Then it will be 0.61 which will hopefully be fairly stable. The token table has been changed rather a lot, which gives odd results if you load an old tokenised program in. But I reserved a group for extensions - case , input/output ports and so on, so it should now be fairly static. Being slightly pedantic I liked to keep them in order, although apart from the first 16 which are the assembler mnemonics it doesn't matter.

How to work it

As the github is actually just a live build tree, it's not obvious how to make it work. The executables are in the emulator directory ; they should work straight off (they're built on Windows 8.1 in Virtualbox) and they store their files in the storage directory.

Building requires SDL2, Python and command line Zip, and either gcc or mingw. On Windows I recommend chocolatey which does all of them and sets them up, except SDL2 which you can download (the mingw development one), extract it and put the x64 directory in C:\ renamed SDL2.

You don't need to do this to run it. It should just run. If not, let me know :)

When you run it what happens depends on what I was working on. If there's a program "autoexec.prg" in storage it auto runs this. At the time of writing it shows two overlapping rectangles in purple.

If it's running a program and doesn't seem to stop (you can tell when it's stopped by the flashing cursor) then either press Ctrl+Space to break it, or reset it while holding shift down.

Reset is Ctrl+Escape on the hardware, and F1 on the emulator. This will boot it in normal mode displaying Basic/Kernel versions and playing its startup beep, half inched from my much loved BBC Micro.

Tile mapping working

So you can now do tilemaps from BASIC ; the picture shows a testing tilemap.

It's quite efficient, this tilemap goes at 28fps on the ESP32, and it's doing quite a lot of work on repainting the screen.

The downside is the borders ; the purple bars are covering them up :) This is because to scroll a tilemap at pixel level you have to draw it back a bit. My blitter only draws in 16x16 chunks. I could theoretically process every tile to clip it, but this would be very slow. Or I could uprate the blitter, but I really didn't want to cheat by producing something that was 2020 technology, say a hardware clip. Of course, one way to clip it is to tile the whole screen. Also, the simpler the hardware the easier it is to implement.

Also fixed a bug in the palette code which was a hangover from the original which emulate a real hardware palette. It actually now does it, but it's really slow, because hardware palettes are not a feature of the blitter driver - so changing a palette involves repainting the whole of the display. This actually is fairly quick on the ESP32 , but not enough to use palette effects in games.

No actual Retrochallenge work done today. I have one more thing I want to do, though this isn't necessary initially. The graphics is a bitplane design, and the blitter basically selectively writes bitmaps into planes. So you can say have 2 sprite planes, and 2 background planes, giving 3 sprite colours and 4 background colours (one sprite colour is for transparent), or you can have 3 sprite planes, or 1, or none at all, or no background if you really want (There is only enough memory in an ESP32 for 4 320x240 bit planes). It would be handy though to be able to draw on the sprite plane, and it isn't difficult to change the graphics routines to do this, as they all use the same routine anyway. I drew the purple bars in the picture using the BLIT command, which directly hits the blitter, whereas it would be much easier to do RECT/FRAME/ELLIPSE/CURVE/LINE etc.

Retrochallenge 2020/04

Running on ESP32

Hi. This is my entry for Retrochallenge April 2020. It isn't actually Eris itself, as you can see from the pictures, that's actually fairly advanced.

The R/C will be to implement some BASIC games on it, in a "Game a day" format. This is partly to check the BASIC interpreter works. It take pretty much everything I've thrown at it so far, but there's bound to be some small bugs in there. Day 1 is not going to have a game, probably, because the BASIC TILE command (which draws scrolling tilemaps) is the last thing on the TODO list.

So, what is Eris ? Well it was originally going to be called Pluto, but there's a SPARC machine called that, so ... Eris instead. Eris is also the God of Chaos and Discord, so that's ... saying something about the project.

It came out of a dissatisfaction with the Retro Computer projects that are out there. They either tended to be too complex or wildly expensive, or have other faults which appear to be plain idiocy. I also wanted to produce a learning tool - I plan to write some tutorial stuff to go with it.

Running on a PC

So the design is a bit of a compromise. The full description is on the github ; but in outline it's a 16 bit CPU which is 100% orthogonal and RISC like, that runs at about 1 MIPS on the reference (which is the ESP32 design) ; it has a 320x240x8 colour display, 2 square wave tone channels, 1 noise channel, uses appropriate backup storage. It has a 64k x 16 memory space, which is currently 16k ROM and 20k RAM (this is because of SRAM on the ESP32). It runs at present on the ESP32, emulation on PC/Linux and Raspbian. I haven't tried a Pi Zero because I don't have one. It's very easy to port. The ESP32 is built ontop of the fabgl library and the glue logic is straightforward.

It has a Kernel/OS ROM and a structured BASIC. Yes, it does have line numbers but these are used for editing (at the moment), it has named procedures, while loops, locals, parameters and so on. There is an inline assembler which is what's running in both pictures. Editing is like the Commodore machines, you can edit in situ.

To give some idea of speed I ran the old PCW benchmarks on it, and it came out at about 12 to 13 times faster than a C64

It's also cheap. The board you can see at the bottom of the picture is a TTGO VGA32 1.2 board (the 1.1 doesn't have sound but works fine), they're less than £10/$10 each, and apart from a keyboard and cables you don't need anything else. The Raspi Zero version will end up the same sort of cost. It runs fine on an old Raspi, and comfortably on PCs. I'll probably do an emscripten port when I figure it out.

It's not running BASIC in 'C'. The interpreter is actually written in the assembler of the machine, so it's a simple virtual machine. This has the advantage that porting the virtual machine is almost bulletproof - the CPU is so orthogonal it's comical - things you can see on the screen like jmp #loop3 skz r5 and clr r1 are actually syntactic sugar by the assembler - every instruction either has the form <operation> <reg>,<reg>,<short constant> or <operation> <reg>,<constant>. It also means an FPGA version would be fairly easy to do.

The other thing is that I'll probably write some variant of Chuck Moore's Color Forth for it. Which is great, even if he can't spell "colour".