Tynemouth Software: July 2025

Sunday, 27 July 2025

3D Monster Maze Repair

When I am testing a Minstrel 2 or 3, or the new Minstrel 4th ZX80 and ZX81 modes, I try to load from various sources.

Sometimes ZXpand, sometimes a tzxduino based player, sometimes tape, sometimes vintage tapes.

When testing the Minstrel 4th ZX81 mode, I tried various of my original 1980s tapes as well as ones I have picked up since.

It's good to see a game loading from tape like that, the same tape I used to load the game 40+ years ago.

I used to quite like "Perilous Swamp". I managed to rescue the princess.

But was beaten at the last step. (this is all written in BASIC, and I remember I spent a lot of time in my youth looking through games like this to see how they worked and making my own versions. Must resist looking to see what the algorithm for "fight" is, presumably relative strength plus some random element?)

One tape I can't load like that is unfortunately 3D Monster Maze.

I do have _a_ 3D Monster Maze tape, but it's not _my_ 3D Monster Maze tape, that is in a safe place.

Somewhere.

The problem is that one does not load. It always seems to fail at the same point, it fails to load one way or another on a ZX81. It is easier to see that with the load countdown on the Minstrel 4th.

When I modified ZX81 BASIC for the Minstrel 4th, I ended up writing a whole new LOAD routine, which seem to perform better than the original one with some tapes, but not in this case.

http://blog.tynemouthsoftware.co.uk/2025/05/zx81-basic-on-minstrel-4th.html

I tried sampling the waveform, and you can see it dips to almost nothing at one point.

I wondered if I could re-record it.

It felt wrong, but I guess that tape is never going to load as it was.

Those who did not grow up with tapes may not recognise the significance of the tape, there are holes in to the of the case that stop it being recorded on. Add tape and then you can. Normally sellotape would be used, I have used brown parcel tape to make it more obvious.

It is an old tape, so I blanked it several times first to make sure it was a good starting point.

OK, no going back now.

I used my "master tape creator", which is a Spectrum +2 with a tzxduino "temporarily" installed in it (since 2017).

http://blog.tynemouthsoftware.co.uk/2019/12/tzxduino-master-tape-creator-update.html

Time to write the tape.

I played it back, but unfortunately, it also dipped in the same place.

OK, plan B. Next level of wrongness.

I decided to replace the tape. The case was unfortunately sealed on both side, no screws, so I had to splice in a new section between the two sections of red leader tape.

I took a "new" C15 tape and recorded 3D Monster Maze onto it.

This one looks like the label was applied by the same person that used to put the labels onto Dragon 32s.

The sampled version also looked a lot more consistent.

I tried loading it, and it loaded fine.

(I had made sure to get the right version with the J.K.Greye copyright, and not the reissue by New Generation Software)

OK, there we go, I cut the tape out of the original 3D Monster Maze tape and then spliced in the new C15 tape.

I used my incredibly expensive professionally calibrated tape winding device....

And wound the new tape carefully into the shell. Once it had all gone it, I cut the end from the C15 spool and spliced it to the other end of the 3DMM tape.

OK, time to give it a go.

Great, it's nice to be able to load 3D Monster Maze from tape again.

I was concentrating on getting the tape to lay flat for the photos and ended up with the splicing tape on the wrong side, I will need to go back and redo that, but it works fine.

Adverts

The Minstrel 2, 3 and 4th is all included in the 15% off everything in my Tindie store for the whole of July.

https://www.tindie.com/stores/tynemouth/

Be quick, there is not long left to take advantage of that offer.

Patreon

You can support me via Patreon, and get access to advance previews of things going on behind the scenes updates, currently working on the Mini VIC and Mini PET II. This also includes access to my Patreon only Discord server for even more regular updates.

https://www.patreon.com/tynemouthsoftware

Sunday, 20 July 2025

Multi part VIC20 game conversions part 9 million and 12

Seems like I have done a lot of these, but not for a while, so here are three more.

We were almost at the release state for the Penultimate +3 DCR when TFW8b suggested a few more games to add following one of his "5 random games" videos (link at the end).

Out of the ones suggested, three of them looked promising, and of course it's never as easy as a single PRG or a cartridge that I can just add straight in.

These games were typically designed to run on an expanded VIC20 and would load in multiple parts. The first would show a title and maybe some instructions, and often setups some game code or character graphics.

They would then load the second part, the game itself, which would overwrite the previously loaded program as there wasn't space to keep both in RAM at the same time.

My tactic for conversions like this is to make a cartridge ROM with a routine to copy a block of code (the first program) into RAM and run it as if it had just been loaded

I then change the code which would load the second part from disk or tape to be a SYS call to jump back to the cartridge ROM to copy the second block of code into RAM and run that.

Diamond Hunt

This one is nice and obvious. The first part prints up some instructions and then sets up some thing into RAM at $0298 and $0338 (I think it is graphics data, it does not look like code).

And then it prints out a LOAD command, and then a few pokes to put "RETURN" into the keyboard buffer

The disk drive device number is correctly set using PEEK(186), which stores the last one used. That is a nice touch that a lot of these loader miss and just hard code device ID 8.

When the program ends, the RETURN in the keyboard buffer is processed and the LOAD command is run, the second half is loaded and you get the game.

It's a sort of Boulder Dash without the boulders with a hint of Centipede.

Every level is choose different colours and characters for the items, so you can sometimes get caught by the baddies before you have adjusted.

One thing that threw me with this one was there are four files in the D64 image.

"DIAMOND HUNT" and "C/DIAMOND V1.29" are used, but the other two do not appear to be referenced anywhere. Not sure what happened there. They appear to contain similar code. I suspect they may be left over from the conversion to D64 as this was probably originally a cassette game.

Mission Mercury

This is another two-parter. The first part puts up a title screen.

It scrolls up from the bottom of the screen.

Then it is rolled off to the left (reducing the screen size character by character).

Leaving a blank screen whilst the second half is loaded.

And then you get the actual game.

It's quite a nice little game, sort of upside down Frogger meets Jupiter Lander.

Your landing craft starts off in the mothership that moves across the top

When you press fire, you need to navigate to one of the bases, avoiding the floating aliens.

I was expecting to need to land another two crafts, but the next stage is to take off and go back to the mothership.

The first part is mostly the title screen, and some code which is POKEd into RAM at 700 ($02BC).

This is the usual setup and call to SETLFS, SETNAM and LOADSP to load the second half, and then a jump into the code.

Here I just changed the call to runs that code to a call back into the cartridge ROM to load the second half and that's another one done.

Android Attack

The last of these there Android Attack.

Another animated title.

This time with optional instructions.

The first page is oddly short - has something been cut?

The rest of the pages are full.

Quite a lot of text to basically say "shoot the aliens".

We then get a blank screen whilst part 2 is loaded.

And finally, the game.

It is a sort of Space Invaders meets Blitz.

You need to shoot the invaders, but unusually, you rotate rather than move left or right.

Even diagonally.

This one had an interesting loading mechanism, there was some extra code at the end, after the BASIC program.

This code copies itself into a safe place in memory ($0140), then jumps to the copy. The code there is the usual KERNAL calls to LOAD the program and then jump to $1000 to run the game.

Like the previous title, the game code fills the full 4K of RAM from $1000 to $1FFF, including the screen, which is why the screen is reduced to 0x0 characters and you get the blank screen during loading.