Moved platform

 Well, I spent a fair amount of time on Lock'n'Chase Aquarius with graphics and so on, and it looked just *awful*. 

 So I'm going to shift the platform to the Jupiter Ace and try that instead.

I think the Aquarius is one of those platforms that rather than try to produce something that looks like the real game, you work within the limitations of the graphics hardware to produce something that plays similarly. 

So anyway, the code has been converted and hacked up yesterday and now works very nicely, though there's some optimisations to do. One of the things you can do with the Ace is because it is FORTH, and most 8 bit CPUs can't do FORTH well, it has routines to do things like push DE on its internal stack. 

This is called by RST 10h (or 18h, I forget). Rather than simply execute the code, I can replace this with C which is functionally equivalent and get a speed boost for fast mode on the ESP32.

Sprite routines

 So, I'm writing stuff to do stuff still rather than an actual game. I now have a Sprite system for the Aquarius, which is a bit strange, but it allows sprites built from multiple characters and colours to behave like sprites, in that you can move them about and they restore the background.

This editor is f--- awful. I'd be ashamed if I'd written something like this. It's slow and bug ridden.

So you can see two sprites, the two triangular things, slightly different graphics and they whiz about very happily and quickly. M7 is very fast, if a bit greedy with memory.

The code is below. The eccentric format is because it's like Color Forth , except my text editor doesn't do colour. So :xxx is a definition (red), anything in [ ] is an execute (yellow) and the rest would be compile (green). White is comment but I've filtered that out.

So it defines two graphics, two sprites, executes the clear screen function and set speed to normal function (it's mad fast anyway). It defines an area for a sprite group (up to 15 here) and 2 areas for sprites, which contain location data, new location data and storage space for the background.

 RFill fills the screen with the text. Pause is a loop to slow it down so I can see it.

Test initialises a group and adds two empty sprites, sets the image and the inital position, fills the screen, and then 10000 times sets the sprite positions to things derived from the index, draws the sprite group, pauses so you can see it, then erases the sprite group.

M7 actually runs on the Aquarius as a cartridge, and you could use it for a development environment, but it doesn't actually have an editor. You can sit at the console and bash commands out like on a Jupiter Ace. 4 space 5 space + con.sprint (console - signed - print). The console is execute only for technical reasons, you would edit definitions in a screen and reload them.

It's not FORTH. You can't tell from this, but it doesn't have a stack. Well, you could argue it has a two-entry stack - A & B which are actually the HL and DE registers. So a>b in RFILL actually copies HL to DE. c is BC which isn't part of the stack but can be used as a temporary register.

I got the idea from the HP machines which have very small stacks. It gets round the problem of processors with only one stack. 

Which in 8 bit land is pretty much all of them, except the 6809 to some extend. Obviously you can fudge a stack, but it's slow. Not having a stack means you generate a lot of Z80 code. So + is just ADD HL,DE, and it's a macro that generates that in line, no NEXT or ENTRY or EXIT or anything, which is why it is so fast.

Part of me thinks you could do it pretty well by having the list of address as you have in non-STC FORTHs and have your cake and eat it, because it's really not that efficient.

require stdlib,console,interface,sprites

:graphic data [ $22 c, 192 c, $30 c, 193 c, $30 c, 20 c, $50 c, 20 c, $50 c,]
:graphic2 data [ $22 c, 192 c, $30 c, 193 c, $30 c, 20 c, $60 c, 20 c, $60 c,]
[con.clear]
[slow]

:group [32] array
:spr1 [22] array
:spr2 [22] array

:rfill 960 times $3028 + a>b c! tend ;
:pause 1000 times tend ;

:test
    group sg.init
    spr1 group  sg.add
    spr2 group  sg.add
    graphic spr1 sp.image!
    graphic2 spr2 sp.image!
    4 spr1 sp.x! 6 spr1 sp.y!
    24 spr2 sp.x! 7 spr2 sp.y!
    rfill
    10000 times
        a>c 21 mod spr1 sp.y!
        c>a 39 mod spr2 sp.x!
        c>a 7 mod 4 + spr1 sp.x!
        group sg.draw
        pause
        group sg.erase
    tend
;

[test]

Progress 2

So I'm happy enough with the "hardware" and software versions of the emulator. and I've been working on a version of my stackless FORTH for the Aquarius, this language is very Z80 specific (it just doesn't work on a 6502).

Surprisingly removing the stack doesn't actually change a lot. When I started with stackless FORTHs I thought that you'd end up with shedloads of extra variables to make up for the thing stored on the stack, but in practice it doesn't seem to happen.

As it's an Aquarius I thought I'd write a version of the game Lock'n'Chase as that was announced for it, but never delivered.

Also, there's now a link the the actual code up. It will build both versions on Linux, it should build on Windows but I haven't actually tried to do it yet. I'll sort that out today.

Progress

 I haven't written for a few days, however I have been getting somewhere. I have a working emulator that runs on PC (should run on anything) and ESP32. See picture (not great quality) of AD&D Tarmin running on the ESP32 board.

I've tweaked the cassette format slightly, just by allowing CAQ files (effectively dumps of what is sent to/from the cassette port to be concatenated.

Some hacks to the ROM have removed a lot of annoying "press any key" type messages and you can now just CLOAD "<whatever>". CLOAD without a filename will load a directory a bit like on the CBM machines.

This also works for cartridges so you can CLOAD "TARMIN" and it will load the cartridge, detect it is a cartridge and then reset the computer automatically.

Also gone are the irritating beeps on key press, the start up press any key screen, the limitation on PEEK and POKE and the Printing is disabled, for now anyway. 

I had hoped to produce a quicker version, something that you can turn on a high speed version. This is easy enough for the PC, but the ESP32 appears to be running near flat out. Doing an empty 10,000 for/next loop takes about 10s or so, I've got that down to just under 8 after a bit of optimising. Not bad, but I'd hoped for closer to 6Mhz equivalent. 

Sound works, but it doesn't do any fancy PCM tricks, it just averages out the pitch over a frame, which gives it a slightly static sound effect. Might fix this, difficult to know. I want it to be runnable on a TTGO-VGA Board (the one pictured) which is about £10 or so and Fabgl compatible out of the box, so piling in too much will take from that.

There's a link to the github on the top left (probably)

Today's fiddling about.

 So I've been doing more work on the emulator. Fixed a couple of minor bugs (most ridiculously, I'd forgotten to implement RRD and RLD which Astrosmash and Snafu had problems with !).

More work on formats and tapes. The Aquarius has a tape format (CAQ) which is just a binary dump, and a ROM format (BIN) which is an encrypted binary dump. 

I've combined these into a single format CQC, which is either a binary ROM or a series of concatenated tape files ; it looks for the standard ROM markers to decide if it is a ROM or not. There is a very low possibility a tape file will have the same markers in the same places. Very low.

Having hacked the ROM a bit , got rid of a few annoyances, fixed the keyboard up, and so on, the cassette system now works like a disk system. You can "CLOAD" a CQC file by name (this limits it to six characters because that's all the Aquarius can have), and then it just works for multi load files. I've removed all the "Press Play and type CR" messages, and the beep (because I don't like it).

You can just CLOAD "ALIENS" from the BASIC command line and it loads the files in automatically. You can also CLOAD ROM cartridges, which is slightly odd, but works well enough. CLOAD "TRON" will load in tron.cqc, it realises it is a ROM cartridge and resets the machine.

All the ROMs seem to mostly work. Not seen any obvious glitches, but you never know. 

Sound now works (couldn't find out what the actual calculation was, so worked it out logically ; it's CPU Clock / 64 / SOUND parameter in Hz.

Next up is to check RLD and RRD work properly, to build the various cassette files into CQC files, and then see if I can port it to the ESP32 board.

Plan 9 is to produce a tiny Aquarius hardware copy in the same mode as FabGL's VIC20 an Altair and I've also seen Speccies using it. I reckon, guesstimate, that it could run at 6-7Mhz equivalent on a FabGL.

Working on an emulator

Actually, not a huge amount of work. I already had a Z80 emulator which I knew worked pretty much properly, so an Aquarius emulator isn't a significant amount of work. This now has a working keyboard, display and runs at the correct speed, within about 1% (I'm not going for cycle accuracy here).

(I would add at this point that this new Blogger editor is the biggest piece of absolute **** I have ever come across.)

So I need to add sound and make cassettes and cartridges work properly, and fix the keyboard so it generates the right shift characters (I'll probably hack the ROM to do this)

(This is dreadful. Did anyone actually bother to, you know, test this on Firefox, one of the most popular browsers out there ? Did Microsoft pay you to produce an editor that would only run on Edge ? Is it a push for the mega irritating Chrome ? Why does the text insert from the right on a new paragraph ? Why do images jump about like a demented llama ?)