There's been a balance of "regular" players and power players, and in those power players is where the game got some more much needed play testing.

The one thing that I had designed into the game was the unlimited undo. The side effect was that, technically, there's infinite ability to make your way through the game so long as you had time and patience - a lot of patience!

The knock on problem with infinite moves is that the score really isn't infinite. In fact, I alluded to that in a previous devlog because the score is a 16bit value, it has a max range.

So with that, this new release adds a penalty to using the undo. I went through a lot of different ideas and tested them out to see how they affected the score. Here's just a few that I tried:

• Subtracting 100 points per undo
• Halving the score per undo
• Subtracting the number of blocks restored
• Using the undo depth as a multiplier - as in: if you undo twice, the penalty is greater

These had either drastic effects on the score, which made it pointless, or very subtle effects which rendered the penalty ineffective.

What I settled on was using your progress as the multiplier. So, undo costs 25 points per undo on level 1. On level 2, it costs 50 points, level 3 75 points and so on.

This changes the dynamic of the game in a really interesting way. You start to consider the impact on your decisions against your score: do I continue with undo and risk it, or do I accept the fate of stable score and hope it's good enough for a highscore?

There was also some fixes for the custom themes - around the palette because I require a custom palette for the game's main tiles, but when you add your own custom tiles the game switches to the default Layer 2 palette - so there were fixes around that too. And here's Gaz Mashall's own custom theme in action behind a new user interface change:

Originally published on Remy Sharp's b:log

After nearly ten months of tinkering in the evening, the Marbles Squared ZX Spectrum Next port is going live this weekend.

It's not that it actually took 10 months to develop, it's just along the way I learnt and wrote the code grid handling in assembly, and then I wrote an assembly based dot command that handles HTTP requests both getting and posting data to web servers - and this is now part of the official spectrum core code (which will ship in future machines) - so that's a nice bonus.

I'm fairly confident there's no lurking bugs, though I am trying to squash one non blocking issue where the game can't get the high scores from the web (though oddly the game was able to post the high score for the player in question 🤔). Still, I think it's looking pretty snazzy:

All the same, the itch download page is primed and ready for release on Saturday. There's two downloads available: the game and the game with fully documented source code and PDF overview article.

In lieu of the release, I've been looking back at the original version I wrote in the early 2000s and found a web based Palm Pilot emulator that let me actually play and capture screenshots of the original game (I even managed to recover the source code and published it on github). So I present to you - the old version:

Once the game is live for the Spectrum I'll release the web version and if I planned the code right, we'll all be able to contribute to the high score leader board!

Originally published on Remy Sharp's b:log

But right up to the last moments I'm still making significant changes that I won't be able to change later once it's released: the scoring system.

Originally the scoring was based on the same system as the original Palm Pilot version. Specifically, the scoring was n * (5 + n) where n is the blocks selected.

When I've been testing the game I hadn't noticed any particular issues. But once I set into actually playing the game, and thinking about the moves I'm placing and making good use of the undo feature (which on the Spectrum is unlimited and on the Palm Pilot was limited to a single undo per move) - suddenly I had racked up a pretty good score very quickly.

I was only on level 6, but I'd managed a score of 7,468 (using seed #1F16 if you're interested). That's not a particularly high score, but looking back at some of the original high scores on the Palm Pilot, there were a handful of dedicated players that got close or even beyond a score of 65,535. Why is 65,535 important? Well, it's the max 16 bit value, and since I'm only storing the score as 16 bit and this version of the game takes the undo much further it's quite feasible that those higher levels are reachable.

Now the flip side of this is that the Palm Pilot was portable and when you turned it off, it suspended it state - i.e. if you were playing a long game of Marbles, you could play on the commute to work, switch off when you arrived, and on the way back home, switch on and pick up where you left off.

The Spectrum doesn't have a) the state suspension, but moreover b) it's not (that) portable! (In fact, what's really nice about the Speccy is I have to go the room with the computer in it to use it, instead of being able to simply reach for it any time I so wish).

Still, I didn't want to be making post-release changes to the scoring system, so it makes sense that I try to scale it back - albeit a little.

So now the multiplier is 1 + n which doesn't have the same profile in the scoring. I've looked at tables with potential scoring when the block count is 2 to 100 - and comparing 5 + n to 1 + n doesn't look that much different, but it's because at the larger clearings it doesn't make much difference. i.e. if the player clears 30 blocks in one go, it's 1,050 points vs. 930 points - not a big difference.

When the scoring change has a real impact is in the lower block counts. 5 touching blocks is worth 50 points vs. 30 points, and anything below is less than half the original scoring system. Most of the game points are accrued around these values, so the long run it'll make a decent difference.

What I don't want is to lose real scores - I can't be having a score in the 100,000s and losing that original data.

Thankfully I have a backup if there ever comes the day. The level gives a hint of how many times we might have overflowed. I can't imagine there will ever be a score of over 130,000 (two times 16 bit) (though I kinda don't want to jinx it), but if the level is greater than some arbitrary value and the score (overflowed) is under some other value, then it makes sense (sort of!) to take the score and add 65,535 when displaying - not that I know how to display 32bit numbers in NextBASIC yet!

Originally published on Remy Sharp's b:log

There's no falling effect, no selection effect, just - vanish.

NextBASIC doesn't have much bandwidth (compared to assembly) but it does leverage hardware sprites via a handful of NextBASIC (software) routines (AKA the Sprite System), which translates to: do a bit more for a bit less.

So I've added this animation when you select a block in the game. It's a bit of a fiddle, mostly because I'm working within the constraints of NextBASIC but I think it does the trick:

The animation above plays the selection in slow motion (around 10% speed), then repeats the animation (for demonstration purposes) faster and faster until it's 100% speed.

What's nice is that the animation works for all the different block themes I've designed. It's an animating layer over the top of each of the blocks settling on a solid black, as seen below in the four frames (note that the white is actually transparent):

So what are you actually seeing with respect to layers and sprites?

All of the blocks for the game are sprites (rather than tiles which might be a more traditional approach). This is a bit of a cheap move on my part, but it let's me do "low cost" collision testing. I can also address each block from an index which happens to be the block index in memory.

When you select a block (a collision is detected between the pointer sprite and the block), underneath the block sprite a 16x16 tile is painted (so if I removed the sprite, it would look like the block was still there).

Then the sprite block's pattern (the image in the sprite) is changed to transparent. So you're seeing through the sprite to the tile underneath.

Now a sprite pattern sequence is run using SPRITE CONTINUE running through the frames you saw earlier. The effect is that the black border closes in on the block making it look like it's shrinking. Once the sequence has come to it's end (something I have to check in the code), the tiles are removed by painting the entire layer with black - and the "layer" is under the sprites so this doesn't change any appearance.

Each block that matches the block type/pattern has the following code applied:

SPRITE CONTINUE %k, STOP , STOP ,51 TO 54, BIN 01100000,10,0

Pages 9 and 10 of the NextBASIC new commands and features shows how BIN 0110000 works:

• Bit 6: update pattern even when sprite is stationary
• Bit 5: sprite is disabled when pattern reaches limits

Though I didn't find bit 5 actually useful, because I needed a way to know when the animation had completed, so I could then make the blocks fall.

To solve that, I run a loop - which is required to get the animation to update anyway - and I check the pattern state of just one of the sprites:

REPEAT
  SPRITE MOVE
  ; %k is the last sprite id, 2 means "test pattern value"
  %i=% SPRITE AT (k,2)
REPEAT UNTIL %i=54 :; 54 is the final pattern in the animation

With those small bits working together, I get a little animation. It's not quite perfect, because during that REPEAT the whole interface is locked - specifically the player's cursor can't move, and adding a call to update it's position significantly slows the animation, so there's no point.

Originally published on Remy Sharp's b:log

Having coded this game a number of times over the last 20 years and actually having played it a lot, I was finding that the spectrum flavour was somewhat harder than I would like.

I would vary rarely manage to clear an entire board and though a challenge is fun, too difficult and being stuck in the same score range is not.

One approach I started to consider was whether I can write software to run through generated boards and work out which ones can be completed (at least one way) and which can't.

The seed is a 16 bit integer (but excludes 0) so there's 65,534 possible boards. That combined with the starting brick could be any one of 100 positions, and then as the blocks cascade the number of new choices increases - it quickly becomes some very big numbers.

It is however PRNG - a pseudorandom number generator - specifically deterministic. That means that there's a finite number of options. It's just a massive headache to process them all.

Then I re-played the original Palm Pilot version and remembered it had undo functionality, and in fact technically not that difficult to add undo and infinite undo to boot.

Shifting the problem solving away from computing to the human mind has completely unlocked the game now. I'm able to progress reasonably easily to level 3 gaining a much better score with some careful planning and course correction using the new undo feature.

This pretty much completes the game play mechanics and I'm now on the (long) home stretch whereby I need to add the landing screen, options, high score tables (though I have that working and more later on that). I also need to test many many games to see if it breaks at all!

Here's the undo in action:

Originally published on Remy Sharp's b:log

What's nice about Marbles is that because the game is so familiar to me, it let's me spend time experimenting in areas that are typically out of reach.

The bulk of the work I've done over the last few months has been all in assembly. The performance of the logic and maths work in NextBASIC was too slow, so I moved it all into a machine code library that I can call from NextBASIC.

I was able to use the excellent Dezog VS Code extension to debug, step and make the code do what I needed. I even went so far to including a test mode where the generated test .SNA file would load in a 48K emulator and allow me to select blocks (using the keyboard) and clear the grid:

Coding for the web

Having flexed some assembly skills I moved my sights over to the internet connectivity. I had a working solution using NextBASIC but had hit a problem with the driver I was using (either through my own unknown error or a bug in the actual driver it wasn't clear).

Also my previous solution relied on a bespoke socket based server and I really felt like there was legs in this to open it up to other developers wanting to add internet connectivity. … Plus, I'd seen a number of open source projects that did a bit of wifi hacking and I convinced myself it was possible for me to get there.

After an initial fast development and a much slower bug tracking and fixing over a period of a couple of months (mostly late at night), I produced httpbank and project that massively simplifies the process of getting data from a Spectrum Next memory bank to the web and visa versa.

One constraint I hit in the cspect emulator is that it only talks 7-bit over the web, which for the most part is fine, but if you want to send binary it's not fine. Took me a while to realise that bytes were being truncated to 0x3F when they were too high, i.e. greater than 0x7F.

So I also added base64 encode and decoding which all happens in 4 bytes of memory. I'm rather pleased with that.

So now that I've built these extra building blocks there's been some fun experiments from other folks and it's let me connect my game pretty quickly to the web.

What's outstanding isn't game logic, it's the parts of that surrounds the game like entering your name for a high score and screens with instructions.

Below is a screenshot showing how the high scores, that automatically are sent and validated through the web, are delivered over the web:

Originally published on Remy Sharp's b:log

There's a number problems presented with this. First of all, to share a high score requires some kind of validation. Since the game will be in NextBASIC this means there can't be some hidden encryption key that I can verify when it's been sent to me. So the next option is to send the sequence of game play and verify it on the server for the score.

This then means that high scores can be verified and attributed properly. However, the bigger problem is: internet (or even web) + spectrum = mixed bag.

To say that internet connectivity from the Spectrum is tricky is doing the headache an injustice. There's a lot of async communication between multiple modules before it gets from the client to the server and back. I'm being exposed to the entire stack that I normally don't think two moments about during web development.

Ideally I want the Spectrum to perform a POST request to my server. Most servers I can launch quickly are forced in to using TLS over HTTP - i.e. HTTPS - and the Spectrum's modules doesn't have anything written that (I know of that) can deal with encryption - let alone doing it from the NextBASIC end, not only will it be tremendously slow, but it'll likely hose the memory, let alone actually complete.

Then there's the POST over the web. I'd rather use the web because it's a common communication method, and one that I understand well, but there's an overhead in talking HTTP and doing proper POSTs. I need the Spectrum to do the bare minimum from NextBASIC partly for speed, but partly to reduce the potential for errors.

In the end, I decided to write a simple custom socket server that could receive comma separate values (16 bit values) and once it had an empty line, it would assume the message had ended and close out the connection (though it'll eventually send a yay/nay on whether the values were good).

After a few weeks of stolen hours here and there, I've finally got something that works … some of the time?!

The process is this:

1. Clear communication channels
2. Test if the Spectrum can talk to the driver that talks to UART
3. If it can't, install the drivers
4. Then attempt to initialise the drivers - all three of these steps can error but in general are fairly stable
5. Attempt to connect via TCP to the server - this can fail - a lot, so I try this 3 times before bailing
6. Then, if we have a connection, read a memory bank and send chunks of 63 values 16 bit values at a time (as strings) then finally close out the connection

At this stage I had a lot of problems that were all intermittent. It turned out (I think) that my local test environment was too quick - i.e. the server was responding and closing before the Spectrum had a chances to switch from writing the socket to reading - and it seemed like when it tried to read (the acknowledgement message) the connection had close already and the Spectrum would throw another error (or… something 🤷‍♀).

It was also mega important that the response from the server socket was formed "correctly" so that the Spectrum knew when the message ended. This isn't a great surprise but it definitely took me a while to get the full combination of things in the right place.

My server needed to close out using this:

socket.write("ACK\r\n", "utf-8", reportErrors)

Without the line feed things would go weirdly wrong.

So now I've got code that can, most of the time, send the contents of a memory bank to a remote server. The remote server will likely be running on AWS as I need to expose a custom port - though I'd probably just shunt that data across to a new service that I can run under something like Vercel or Netlify so I can marry it up to some kind of database and a web presence (especially since I've got the domain).

Now my job is to integrate this code into the game code and actually capture a game sequence and deliver to the server. Since the PRNG is written in assembly and originated from C, I've already ported it to JavaScript so that I can replicate the game play sequence and random number generation from my web service - which means I can actually validate scores.

So next the game needs some UI elements. Not fun bits of code at all, but necessary.

Originally published on Remy Sharp's b:log

Since the game is (currently) written in NextBASIC the maths and logic to check which blocks to drop and how far is pretty intensive even when running at full tilt at 28Mhz.

If you watch the video below you'll notice when I'm selecting the blocks on the far right of the grid, the time it takes to clear out the blocks increases giving the impression of a hang:

So I've been focusing on how to improve perceived performance.

• Instead of scanning the whole grid, I capture the range of min-x, max-x and min-y (which is inverted) - so this speeds up the scanning process
• During the scanning and clearing process, I'm repeatedly calling the readInput so that the pointer can still move whilst the work is being done - this reduces the feeling that the game has hung during larger scans
• During the scan process (the tag routine), if there's more than one block tagged, I immediately start removing these blocks from the display, this allows for large clearings to give visual feedback that there's work being done, and so far has visually tricked me into thinking I can't play until the animation is complete

With the fundamental game play mechanics in place, I'm now adding the details to the game like the "next stage" overlays, buttons to quit or retry, an interface to change the game seed - and, if technology permits, a way of submitting high scores online, via the spectrum…

Originally published on Remy Sharp's b:log

So I'm beginning Marbles2 (or Marbles Squared) in NextBASIC.

I've started with the random algorithm and I wanted a simple routine that I could repeat in other languages. I found a reasonably simple XOR shift algorithm which is written in assembly but simple enough that I could port it to JavaScript (for testing).

This routine is then encoded into bytes (decimal) and used in my NextBASIC - again, only because I want to control the RNG. So I get to do confusing things like this:

#autoline 10

PROC init()
PROC pickRandom() TO %a

PRINT %a
STOP

DEFPROC init()
  %i=0
  REPEAT
    READ %o
    BANK 17 POKE %i,%o
    %i=%i+1
  REPEAT UNTIL %o=201
ENDPROC

DEFPROC pickRandom()
  ; default seed is 1 - to change this we need to BANK 17 DPOKE %1, %<16-bit> - but only during start game
  %r=% BANK 17 USR 0
  BANK 17 DPOKE %1,%r
ENDPROC =%r&3

DATA 1,1,0,120,31,121,31,168,71,120,31,169,79,168,71,201: ; length: 16

The code above lets me generate a random number from 0-3. Bit overkill, but works nicely.

Then right on cue, Paulo Silva released an input driver which simplifies reading from joystick and keyboard and separately I can use the mouse driver as a third input option. Took me about 10 minutes to have all those input methods available and suddenly some of the core requirements (being able to move around) are solved and I can focus on the problem solving.

Originally published on Remy Sharp's b:log

After some 4 months of lockdown and side project tinkering, Go Mummy! (renamed from Oh Mummy!) is complete and done.

I released it on the 14-August 2020 through itch.io and I've had some lovely feedback.

Planning for a Friday afternoon release, I asked the NextBASIC community if anyone would want to do some game testing - and I'm so glad I did. For all the testing that I had done along with Julie and the kids, I'd missed a couple of key issues (mostly around the high score wasn't saving properly). I also had some great feedback from one individual and his 10 year old son which let me make some minor playback tweaks that I think really improved the game.

A couple of the last minute changes include:

• As soon as you reveal the archaeologist, it's added to the right hand sidebar
• When you complete a level, the player is locked for 3 game cycles before it can move out - which avoids accidentally running right into a baddie
• Now there's a gate on the exit that's down when you start the game, and animates to unlock once you've got the archaeologist and the key - which gives a good visual cue that this where you need to head
• I made use of the shadow layer to make screen transitions slicker - this means the screen isn't built up in front of the player, but instead snaps into view
• When a player gets kicked, I intentionally halt the game with a border flash to give a strong notification of something bad happening

I also then wrote detailed comments through the code so that anyone wanting to learn from the code might get a few tips here and there.

I know it's no great feat but for a little side project I was able to create a game that was inspired by my own childhood gaming, and it's been received really well (for a small community) with something like a 2:1 view to download ratio.

Here's the final version:

Originally published on Remy Sharp's b:log

I've been wanting to bring a bit more visual interest to the screens I had though I'm limited in the game itself, the main options screen could do with some love.

The screen initially I'd picked Papyrus, albeit at random for it's oldworldly feel and the screen looked like this:

But I wanted something that harked back a little to the original game roots and give it a bit of an egyptian feel (or certainly what I imagine that would feel like).

I ran through a number iterations until I found a font and some border images that started to bring it together:

The first was a little too streetwise and the second looked like it would suit a shooting game of some sort. I liked the third, but the fourth felt a little more dynamic which is how I think of the game - a bit frantic.

To get this to load into NextBASIC, I have three options:

1. I can export as an 8-bit BMP and load on the machine using .bmpload - which is probably fine, but has a little more latency that I'd like.
2. I can convert the file first to an BMP and then to an SL2 file - which is a pure dump of the screen layer. Then easily loaded back in using LAYER 2,1: LOAD "screen.sl2" LAYER. This is quick (there's no calculation to be done as it represents a memory dump) but it does read of the SD card. This would be fine if I was showing this screen once, but I show it many times, particularly through the option screens.
3. Generate the SL2 file, and load individual thirds into banks - this is the method I used since the data is loaded in memory for quick copying back into the screen memory.

I made another online tool that lets me upload any file format, and so long as it's 256x192 (or not wider than 256) then my code will translate the data to both an 8-bit BMP (with the default Spectrum Next palette) and an SL2 file (which is very similar to a BMP, just ordered slightly differently).

Once I have the SL2 file, I need to break it into 3 equal parts of 16K (the size of a memory bank) and for the final touch, the last third of the screen is solid black for 16 lines - which I can do at the same time.

A unix tool called dd can be used to split the file up:

$ dd if=screen.sl2 of=screen1.bin bs=16k count=1 skip=0
$ dd if=screen.sl2 of=screen2.bin bs=16k count=1 skip=1
$ dd if=screen.sl2 of=screen3.bin bs=16k count=1 skip=2

This will create 3 files of 16K blocks each (based on screen.sl2).

The final task is to block out the last 16 lines in black pixels - 0x00 which conveniently is what comes out of /dev/zero, so I can source that stream and use dd to write it into the screen3.bin file:

$ dd if=/dev/zero bs=4k count=1 oseek=3 of=screen3.bin

Now the binary files can be reploaded into banks then loaded into the LAYER on demand:

LOAD "screen1.bin" BANK 20
LOAD "screen2.bin" BANK 21
LOAD "screen3.bin" BANK 22
; later in the code
BANK 20 COPY TO 9   ; bank 9 is the start of LAYER 2
BANK 21 COPY TO 10
BANK 22 COPY TO 11

So the state of play on Sunday 9 August is that all the (known) bugs are fixed, the new music and sound effects are in place, high scores are updating and saving. I'm investigating a couple of performance tweaks (that aren't required, but will be nice if I can it off) which leaves me with one last problem to solve.

Do I keep the name "Oh Mummy!"? There's other clones of Amsoft's Oh Mummy, some have a different name, some reuse the name, but there is a question over copyright. I'd hope that copyright holders would see this as a hat-tip to old but it bears considering.

So, so far there's some ideas:

• Mummy Mummy!
• Return of Oh Mummy!
• Oh Daddy!
• Go Mummy!
• (and) Oh Remmmy!

Although the last one is rather self serving, I quite like it - just trying to work out how it fits in the story line… (I also prefer titles that are approximately the same length as the original).

So close…

Originally published on Remy Sharp's b:log

I knew the game played better with some audible feedback and I also knew that the only way I could pull it off in NextBASIC was to use the interrupt handler at the machine code level. I'd previously tried and failed with im 2 but this time I looked at the native DRIVER support that NextOS offers a hook in to the im 1 interrupt.

The short version is, once I groked the border example I managed to port the AYFX player from Shiru to a driver.

The bulk of my code involved handling the driver calls and make sure to swap in the user bank during the routines and swap back to the original bank into the slot I was using.

I made some silly mistakes in the code, but managed to debug successfully using Cspect, things like ld a, (addr) must be read (and thought of) as "load a with addr" (and not "load a into addr"!).

My bank swapping code looks like this:

MMU6_C000_NR_56		equ $56

; ************************************************
; backup_bank
; Take the current bank in MMU 6 and store the value
; in (active_bank) for later restore.
; ************************************************
backup_bank:
  push      af        ; make a backup of A
  ld        bc, $243b ; select NEXT register
  in        a,(c)     ; save register state
  ld        (saved_reg), a
  ld        a, MMU6_C000_NR_56
  out       (c),a
  inc       b             ; $253b to access (read or write) value
  in        a,(c)
  ld        (active_bank),a
  dec       b         ; $243B
  ld        a,2
saved_reg equ $-1     ; this points saved_reg to the `2` above
  out       (c),a     ; just in case IRQ was in between registry work
  pop       af
  ret

; ************************************************
; activate_user_bank
; Switches in a user defined bank into MMU6
; ************************************************
activate_user_bank:
  call      backup_bank
  ld        a, (ayfx_bank)
  nextreg   MMU6_C000_NR_56, a
  ret

; ************************************************
; restore_bank
; Returns the bank slot to it's original setting
; ************************************************
restore_bank:
  ld        a, (active_bank)
  nextreg   MMU6_C000_NR_56, a
  ret

The result: uninterrupted game play with sound effects 🎉

Now the bug list is looking pretty small, the priority is a graphics glitch on level 4 (which can also be seen at the end of the game over on the letter "E"), then the scoring system (with high scores) and then… and then we're there.

Originally published on Remy Sharp's b:log

Since I'm writing this game in NextBASIC I'm abstracted much higher up that machine code (which has it's obvious benefit to my programming experience). The downside is control over the machine.

Currently Oh Mummy has (really cool) music thanks to Richard Faulkner (from the Spectrum Next facebook forum). To play sound effects poses a number of problems, and ultimately I've had to park the idea entirely.

Since my game is pretty high speed and involves constant movement, any sound effect is going to have to run along side the rendering. The way BASIC is wired up doesn't really allow this. When I'm calling the BEEP function (for instance) I can't be moving my sprite.

In machine code it doesn't work like this anyway, so it's useful to think in machine code context. The way it works at the lowest level is that the user code changes the interrupt routine (in web language this would be akin to request animation frame) and then tones would be adjusted at this point.

Without knowing the details, I'm fairly confident that this is how the audio DRIVER call works to play the NextDAW music.

So the BEEP function is pretty much out of the window. Not only because it'll pause the runtime enough to make playing uncomfortable, but also I can't design a beeper based sound to sound decent enough. Though it might be worth my looking at Beepola.

NextBASIC also comes with a powerful PLAY function which sends commands to the AY-8-3912 chips. This does sound great (assuming I can construct the right string to send to the PLAY command) but it also suffers from locking up the play back.

I also looked at Beepfx which is Windows specific but does generate machine code that I can call from BASIC using RANDOMIZE USR 60000. This works pretty well for sounds and includes a very useful demo library of sound effects. The problem is that a) it also locks up until complete - which could be mitigated with extremely short sounds, but most importantly b) it's configured to run on a 3.5Mhz spectrum not one running at 28Mhz which is the speed I'm using to get the game to feel quick and responsive. The beepfx sounds are more like a crazed mouse on acid.

Sadly, I can't get my head around the sound engineering maths required to modify the beepfx values, and switching down to 3.5Mhz, calling the routine, then speeding back up to 28Mhz has the same (if not worse) slow down.

One novel approach that Dave Clarke (also of Spectrum Next facebook forum) uses is to enable the AY chips via the OUT function in BASIC, set the volume to zero, then adjust the volume on demand in his game loop. The same technique can be used to adjust the tones on demand to create effects.

I also experimented with working through a string of toggles during the game loop and it kinda half works but the sounds I'm making are quite terrible and I'm competing with the background music for the AY chips (which in reality just doesn't let me play back).

So, for the time being, this game will have to be sans sound effect. Which is a bit of shame. I think the only reasonable solution will be some machine code that hooks the interrupt and checks a queue for sound effects to play, but I've had limited success with the im 2 opcode.

That said, I did a bit of graphics tinkering and a small change is looking really nice now.

Originally published on Remy Sharp's b:log

What's particularly fun about NextBASIC is that it's so close to the metal (as it were) - NextBASIC -> interpreter -> machine code - that it has a heavy hand in the code design that I work with.

I'm used to JavaScript which goes through part compile, part interpreted along with a lot of JIT'ting and hot path optimisation. No such pleasantries with NextBASIC.

A simple example is that in modern high level languages, I'd reduce my code reuse and refactor based on the rule that if a value or expression is used more than once, then it belongs in it's own variable or routine.

Using that approach with NextBASIC comes at a cost, a cost that is immediately visible in the execution. Multiple routine calls slows down the runtime speed. Inlining code will always speed execution up (and this is also true of languages like JS).

There's also the aspect of finding the absolute perfect fit of code for the problem - which again in JavaScript (or other languages) the perfect fit isn't always necessary (and sometimes discouraged and it makes it harder to read later). But this approach makes me think carefully about how the system works at it's lowest level.

A recent change is that I removed all the CLS calls from my game. This clears the screen. But the ROM routine does a lot more than "just clearing the screen".

Instead, now I'm writing bytes directly to the screen memory which has a near instant effect and there's no longer a wipe-and-wait delay:

; bank 9-11 is the thirds of the screen memory in layer 2
; bank 25 contains 1/3 of a screen header
BANK 25 COPY TO 9 :; "Oh Mummy header"
BANK 10 ERASE 252 :; Set the middle third to yellow
BANK 11 ERASE %0,%$3000,252 :; REM 0-0x3000 as yellow
BANK 11 ERASE %$3000,%$1000,0: ; last 4k is black

The bugs I've been squashing have been mostly been subtle issues that (hopefully) make the difference between "okay cool" and "oh, that's odd".

Here's a fun bit of debugging to make sure the footsteps are positioned correctly:

The most recent fix I was most proud of is a control hack. If the player tries to move right, but there's a wall in the way, it'll continue moving in the direction they were previously facing until they're free to move right. This hack means skimming around corners is much more natural - an invisible change to the player, but it felt sticky (or broken) when the player would be stuck hitting wall before a corner.

The outstanding tasks before the game is in a (first draft) complete state are:

• (required) Game over - Win state
• (required) Hi-score table
• (feat) Change colours of tombs between each level
• (feat) "Get outta there" / "now find the archaeologist" / "find that key!" marquee

Which doesn't feel too far away!

Originally published on Remy Sharp's b:log

This last weekend saw music being generously written and composed by a member of a NextBASIC group called Richard Faulkner. With the spec of "something like The Streets of Cairo" (a bit of music from the mid-1800s that was used in the original Oh Mummy) he put together something that's really great. Music is definitely my weak/no-skill-at-all spot.

So now the game has music (which you can turn on and off at your leisure).

I've also been tweaking some of the game play decisions, one in particular is that as you rescue each archaeologist and move to the next level, you get more baddies and so on until level 5 where you have the potential for up to 6 baddies (5 for 5 levels plus 1 hidden baddie in a tomb).

I also need to think about what points mean and whether a) I bother with points and whether survival is enough and b) if I keep points I'll need a high score board.

There's also a few minor bugs that need fixing (that my kids keep pointing out!), like the top right corner of the game doesn't have any footprints when going in a specific direction. I'm trying to capture these as a I go along in my github repo - which makes me wonder how on earth developers in the 80s managed to code both on a single process system (i.e. no multi-tasking) and without any code control. Yoinks.

Here's a demo of where the game is up to:

As further procrastination I've been looking at whether I can bundle all the game assets (currently 8 additional files excluding the main NextBASIC) into a single .TAP file. I've managed to create a tool that lets me bundle, but there's some technical constraints on the machine the code is running on, specifically I can't install the music player using this method, nor can I use any of the Next OS command line tools (dot commands).

But then, being told that it's not possible has only spurred me on to new investigations, and this evening I've been looking at whether I can write my own assembly and trigger it directly from my NextBASIC to avoid using any of the OS commands… trippy.

So this is the code I've got at the moment, and yep, it's pretty senseless!

DATA 17,40,41,33,0,1,205,0,192,195,6,192,201

It does something but instead of music, I get noise on the screen!

Back to the drawing board, eh?

Originally published on Remy Sharp's b:log

Up until now I was (attempting to) faithfully recreate the Amsoft Oh Mummy game from 1984, but it seemed like a waste of the new graphics capabilities of the Spectrum Next - in particular 256 colours and no attribute clash. I do love the original game, but I'd also let my kids draw a main player and a baddie and they did a surprisingly good job (with a bit of pixel tweaking from dad).

Then after coming across an (incredible) VR walk through Ramesses VI's tomb I started to consider that the original game's premise was to plunder the tombs of ancient Egypt and, effectively steal, the artifacts for British museums - which has lead me to a story for this new Oh Mummy adventure (which gives me license now to use the new designs my kids did).

You've been assigned the task of rescuing the archaeologists from their failed plunder back in 1984 - instead of revealing pharaohs you find and reveal the lost archaeologists and rescue them from being entombed themselves.

With that, I've added some story to the game (there's really not much space in what, 30 odd character width) and new images for the collectables through the game.

Now I just, "just", need to fix a few bugs and add the game control over how fast the player is and how smart the guardians are.

Originally published on Remy Sharp's b:log

My last entry I talked about potential optimisations in reading the mummy position out of a BANK but didn't work out.

The next item to try was to switch from calling SPRITE continuously (which prints the sprite to screen) to using SPRITE CONTINUE which lets the hardware animate between points - in my case, the crossroads in the game.

The video below shows before and after (around the 15 second mark). Before, the game play is sluggish as I hit around 4 mummy's and becomes unplayable after that. After, I'm easily able to get to 11 mummy's and they're still running around at breakneck speed!

Next I want to work on the controls. I've noticed that when I play, sometimes I get stuck trying to turn a corner and the player just sits trying to move when they can't.

So my idea to solve this is: if the player tries to move left before they're able to, continue them moving in the direction they were going before. i.e. if they were going up, and try to move left but hit a wall, keep going up (which is usually just one tick) then the left movement will kick in.

The trick, I think, will be ensuring that this method can only occur during movement and not as the first movement…whatever that's supposed to mean.

Originally published on Remy Sharp's b:log

I was testing with 9 mummies, and even inlined the code (removing the PROC calls), but it still went too slowly. So back to the drawing board.

This work makes me also think about my day-to-day (paying) work, in how can I simplify my code either to optimise for maintenance or optimise for browser speed (and thus, a better user experience).

It really doesn't matter how the code looks under the hood, so long as it's good for the user, the player, the visitor, the person who actually uses the final product.

Originally published on Remy Sharp's b:log

I did however manage to get the mummy's to bounce off each other, but good lord making that anywhere near usable was a massive pain in the arse.

I originally went with a sprite collision function, but the point that the mummy's have collided is too late to turn around - so they just ended up overlapping then bouncing back and forth like some crazed yellow blobs.

In the end I track the position of the mummy's in a BANK (effectively 16K of swappable RAM), and in each movement, I check the position I'm about to move to for another baddie, and if there is, flip my direction and bail the function.

If not, I remove the current position and update with it's new position. Originally I wrote this code as a group of functions (as I would do normally), reducing the amount of code reuse which made everything readable. This is a snippet:

#autoline 10
DEFPROC getIndexForXY(%x,%y)
ENDPROC =%(32*(y/8))+(x/8)
;
DEFPROC getBaddieBankIndex(%i)
  LOCAL %j
  PROC getIndexForXY(%A[i*6],%A[(i*6)+1]) TO %j
ENDPROC =%j
;
DEFPROC clearBaddie(%a)
  BANK %e POKE %(32*(A[(b)+1]/8))+(A[b]/8),%0
ENDPROC
;
DEFPROC setBaddie(%a)
  BANK %e POKE %(32*(A[(b)+1]/8))+(A[b]/8),%b
ENDPROC
;
DEFPROC setBaddieInBank(%a,%b)
  LOCAL %j
  PROC getBaddieBankIndex(%a) TO %j
  BANK %e POKE %j,%b
ENDPROC

But good lord did that hose the performance - the mummy's were going through sludge.

In the end I inlined every call, which is horrid to look at, but the performance went right back up again. The lesson: no functions.

…which makes me thing I need some kind of compiler to inline everything, but that might be for another day.

I also got the tomb open visuals working, and next need to add the graphics for the scroll, pharaoh, key and treasure:

One growing concern is that the game is playable with 3 baddies, but at 9 (which isn't a stretch to have going on in the original game), it gets very clunky, and I'm wondering if I can optimise the code further by throwing away the mummy array (that holds each mummy data) and move to first class variables for each iteration, ie. %x becomes the mummy's x position - and I back the data into memory using PEEK and POKE.

It would reduce the number of array lookups and would reduce/remove a lot of maths that goes on during the mummy logic.

It's just a rather large change…and a headache.

Originally published on Remy Sharp's b:log

However, I also want to prevent my game from being repeatable so I use RANDOMIZE as a standalone call which is supposed randomly seed the random functions:

RANDOMIZE on its own (and RANDOMIZE 0 has the same effect) is different, because it really does randomise RND and % RND

And with any basic understanding of random numbers, they have to be seeded from something in the real world, so time is used:

RANDOMIZE uses the time since the computer was switched on. Since this has gone up by the same amount each time RANDOMIZE is executed, the next % RND does more or less the same. You would get better randomness by replacing GO TO 10 by GO TO 20.

…and of course, when Cspect launches into my code to immediately run it, the time is exactly the same on each start up, so the seed, is also exactly the same! 🤦

I've been avoiding the details of gameplay until I got some of the core basics working - specifically the status of the tombs and when they were open or not.

But now I've got that working, I decided to revisit the game and play it looking at how the mummy's behaviour works.

A few observations that I'll need to add:

1. Mummy's can't walk past each other (currently mine can slide under each other)
2. The level difficulty applies to the AI in the mummy - current mine are turning entirely random. I suspect if I want to add AI, I'll need to decrease the random effect as difficulty increases
3. Mummy's revealed in a tomb follow you to the next level, and if you don't lose a life from a mummy (or kill a mummy using a scroll), the in game mummy number increases quickly, so the game needs to work with 5+ mummy's in play (currently adding mummy's has a direct impact on game speed)

I've also been reviewing how I'll unveil the tombs. Currently I'm throwing on a LAYER ERASE (which has glitches in Cspect) but this won't fly when I want to draw on the scroll etc. So it's likely I'll create a tile map for these areas at some point soon.

Originally published on Remy Sharp's b:log

#autoline 10,10
%N=20: ; select from 0-20 (excluding 20)
%P=4: ; pick 4 numbers
; init the 0-N array
REPEAT
  %S(i)=%i
  %i=%i+1
REPEAT UNTIL %i=N
REPEAT
  %T=% RND i
  %W(N-i)=%S(T)
  %i=%i-1
  %S(T)=%S(i)
REPEAT UNTIL %i=(N-P)
; the picked results are stored in W

Now I need to check this array when the tomb is surrounded. I could check the whole of this array each time the tomb is surrounded, but it makes more sense to add which are the "winning" tombs to the tomb array(20) I already have.

The tomb array itself holds it's state in bit values. As such, the current line of code for marking one side of a tomb as "completed" looks like this (horribly):

IF %k THEN %T[g]=%T[g]&@11111101:%T[h]=%T[h]&@11110111: ; new line for readability
ELSE %T[g]=%T[g]&@11111011:%T[h]=%T[h]&@11111110

The low nibble represent the side of the tomb that has been completed, and the high nibble for whether the tomb has been unlocked already:

0x01=top
0x02=right
0x04=bottom
0x08=left
0xF0=tomb has been unlocked

So the IF statement from earlier is always run and always applies the logical & but this is to create consistent timings. Normally, in modern coding, I'd avoid unnecessary code execution, but with NextBASIC to get the game to run at a consistent speed, I'm making sure that each loop does roughly the same amount of work.

Thus far I'm only using 8 bits of the value to indicate the status of the tomb and I need to be able to flag the tomb to say what's contained inside of it, either a scroll, a mummy, a key, a tomb or nothing at all. I could keep all this data inside a single byte, but the integers in NextBASIC as 16bit so I could also expand out to the high byte to store the value of the tomb.

Meh. I prefer to be efficient, so how about this:

0x00-0x04=tomb contents
0x08=tomb has been unlocked
0x10=top
0x20=right
0x40=bottom
0x80=left

This shifts around where the data is stored, but I put the wall status on the high nibble for simplicity, so that I can then do something like %T = %T + INT (key) and set key = 3 somewhere as a constant (though in reality I'll stick to integer expressions).

Originally published on Remy Sharp's b:log