Game#10 : Sabre Wulf

So, after a quiet day or two, more work on the new game. This is still all in BASIC.

Ganes do look very Spectrum-like I think, mainly because of the single colour sprites. The sprites are all done in software and are part of the kernel ROM, so there's no actual reason why they have to be single colour. At present, they just are.

Game#10a :Atac Atic (no relation)

This game is not slightly based on "Sabre Wulf"

So this is coming along okay though I haven't done a huge amount on it yet. It's still all done in BASIC (the text on the right isn't a bug and I do write comments in the source but they're filtered out in cross development usually).

However, I did find a bug this morning. I have a command SPRITE 1 END which kills Sprite 1. Which didn't actually work. So the completely original non derivative game shot the spell out but didn't actually remove the spell graphic when it had finished.

So fixed that.

One of the things I've considered, which I first saw on STOS I think, was the idea of being able to attach a background program to a sprite. Simple sequences - move here, change to this graphic, fade out. I'm very tempted to implement this (will finish this game first). It wouldn't be much use here, because it wouldn't be able to bounce of the walls, but it'd be quite handy for simple things ; like in arcade games where you shoot something and it puts up a little "100" in colour which disappears, or explosions. To do those requires the use of timers/events or AFTER. Could use a syntax like SPRITE 4 RUN "xxxxx" though you'd probably need some way of stopping it, and testing status as well.

True story. I've actually visited Ultimate, when they were in Ashby de la Zouch (ACG = Ashby Computers and Graphics) and I was at Keele University (both in central England). I pulled this trick on more than on occasion ; if some game is unavailable due to demand (in the case, the BBC Micro version of "Alien 8") I managed to sort of buy it direct. I tried it with Revs at Acornsoft's HQ in Wellingborough, as well. They think you're mad, but it worked :)

Spent a whole day removing the copy protection to put it on disk. You had to , because it was XORed with the free running timer in the 6522, so you either had to do cycle perfect emulation (non starter in 1985) or add in code and add in enough dummy code so the counter looped back round back to where it would have been anyway. This worked fine, but of course introduced a slow down factor of 65,536, which meant the second or so it spent unscrambling it padded out to about 20 hours. I didn't distribute it though :)

Game # 10a ... quiz of the week.

As I got fed up just porting someone else's work, this game is under way. This weeks CoronaQuiz is "guess what it is ?" (modelled on). Nearly as hard as those phone in quizzes which charge £2 / minute when you enter.

It's not the derivativeness (real word ?) that's the problem, it's the tedium of line by line translation. If you've ever read a Jilly Cooper book (it was the only thing left) you'll have some idea.

Confession time. I've done this before. I wrote this 35 years ago and it was published in the "BBC Micro User" as a type in. I found it poking round the BBC Micro archives a few days ago.  I've never been able to draw. I still can't. I think it's why I liked coding for the RCA Studio 2 ; at 64x32 resolution you can't actually do much with graphics.

Annoyingly when ever so slightly derivative game was published they got my name wrong ; I became "Hobson" :(


Not the best thing I ever wrote for the BBC Micro. My favourite thing was a derivative of Galaxians that was a multiprocessing tutorial (or just fun). Every enemy was a process running its own script, but it was massively accessible.  Learning through play. I also wrote a hacking game (I got the idea from a Spectrum game System 15000) where my pupils had to use various systems (no internet then) to change the exam results on exam board computers to all A's. It was a simulation, of course, but probably some idiot from OFSTED would accuse me of teaching them to be criminals these days.

Game # 10 : On hold

I'm quite surprised. I actually am finding doing this rather, well, boring.

It's a bit like manually translating a foreign language using an encylopaedia. It's not particularly difficult, it won't come out that well, and in this situation I don't think it's really worth it.

So Game#10, which is basically a Port of the game, is being dropped. Not quite sure what I'm doing yet, but I might actually produce something which is a homage to it or similar ARPGs, but not actually the same game literally. Either way, it's time for a rethink.

The one upside is that as you can probably guess, this is produced randomly. And I hadn't realised quite how dreadful the LFSR based random number generator I was using is. So that's been thrown away and replaced by one I found on the net based on shift-XOR ing which seems way way better. The Random generator is actually part of the Kernel, so this is not a big deal.

Game #10 : Sword of Fargoal

Game#10 is going to be Sword of Fargoal, which is a C64 classic from 1982.

This is chosen largely because I already have reverse engineered it, so I know exactly how it works.

It's an early wander through the dungeons action RPG.

This is assuming I can find the reverse engineered version and it's not lost on a damaged CD or something like that.

Compiler

So, I've fixed SYS to work better. I've also made a tweak involving program line zero.

I didn't even realise that you could have a program line zero, but you can. Program line zero has one huge advantage, it is always in the same place.

So this is now hidden (lines 32768-65535 are also hidden). The idea behind this is if I ever get round to writing programming tutorials for it, support routines can be placed in higher line numbers (Basic) or line 0 (Machine code) and effectively hidden. This allows effective libraries, or code to be written that allows a tutorial to experiment with simple programs without having to have all the confusing visible boilerplate.

Line zero was prompted because I'm planning a compiler. A fairly simple one, called ECPL (not like BCPL). I'm a great believer in that you should tailor your compiler to your hardware, where possible - (so running C on a 6502 isn't a good idea for example) and it will pinch some ideas from a Z80 compiler I wrote called SCPL.  But I had to find somewhere to put the code. Basically there are three options. One is to move PAGE up (so that BASIC runs up at &5000 and &4300-&4FFF is code, say). Another is to move Himem down, which is messier, but could be done as part of CLEAR perhaps, though there are processor stack issues. Relocatable code isn't practical, so that leaves loading it in as line zero. Because it's a 16 bit machine, the offset to next line is 16 bits, so you can have one line with 10k of code in it. It should work. (I haven't actually tried this). The only problem with entering a 10 line BASIC competition is that PROCedures have to be at the start of the line. It won't do anything except occupy space, editing/running won't be affected at all. It's not listed so it really is almost irrelevant what's there. The only problem with it might be OLD. OLD recovers a program that's been NEWed but it does so by scanning forward, so this may well involve the creation of a new token type which allocates data randomly. I'll have to think about it a bit.

Connectivity II

So, after rewriting it twice (!) I finally got the HTTP download working reliably. It's fairly simple ; it just downloads a file from a URL and stores it in SPIFFS on an ESP32. This can be done programatically.

Another issue, again specific with the ESP32 is transmission the other way. I don't know if anyone will ever actually write any code on the machine itself for real, as opposed to cross development, but if so a form of backup is required.

I've added (another) hack which allows data to be sent back via the serial debugging port. A BASIC program reads the directory and then sends the data back through that port in a text format, a bit like Intel's Hex format, which can be captured and converted back to the actual files.

I've also decided that SYS should be redesigned. At present it just passes the address of variable A in R0 (as well as the RPL stack pointer in R8). I found that accessing routines using RPL is messy - it works fine RPL(#file$ 7 2 &10 sys ^size) but it's not that clear. and I'd like to be able to do SYS &10,7,@file$ . I haven't written any code that uses the A passing and RPL makes it a moot point anyway. ($0010 is the File handler vector). The idea being that &10 is the call address, R0 = 7, R1 = address of file$. The RPL does the same thing (the 2 is a parameter count).

Though there will have to be two forms of SYS, because it quite often returns a value in R0. So there'll be a Unary call =SYS(&10,7,@file$) which uses the same code.