Tynemouth Software: July 2023

Continuing the looks at VIC20 multipart tape game conversion for the Penultimate +2 Cartridge

Snake

This is another snake game, a bit of a slow one, probably because it is written in BASIC. Well, almost all in BASIC, there are a few short machine code routines poke into RAM in the 1Dxx range, after the BASIC program. These are stored in DATA statements in the BASIC, so there is nothing magic (like some of the others).

As is common with all of these things, it is in multiple parts. The first prints up these instructions, pokes some character graphics and the machine code into RAM, then loads part 2.

I was going to do this the same way I have done several of the others, load part 1, and have it jump back to the cartridge to load and run part 2.

But since this was all BASIC I thought I would try something different.

This was designed to run on an unexpanded VIC20, so there is space for BASIC code from 1000 to 1DFF, and the screen is at 1E00 to 1FFF.

With a 3K expansion, there is space for BASIC code from 0400 to 1DFF and the screen is still at 1E00-1FFF.

(it all goes wrong with 8K plus when that gets reversed and the screen is at 1000 to 11FF and the code from 1200 upwards).

So I wondered if I could combine the two BASIC programs into one that would run on a VIC20 with a 3K expansion (since I am free to control the amount of memory a game is given).

Using C64 PRG Studio, it is easy to edit BASIC programs (that is what I have been using for most of the other smaller changes), and you can renumber and cut and paste etc.

It was just a case of removing the lines which did the LOAD and RUN of part2, and inserting the part 2 code there, suitable renumbered.

The final code loaded at 0401 as normal, and ended lower in RAM than either of the two part version, so there was no problem with the code which was poked into RAM at 1Dxx, and also the screen was in the same position, so nothing to change there.

That worked rather well.

Super Breakout

Super Breakout is like Breakout, but I guess it's Super.

It's quite a nice title screen where the blue line scrolls along and the breakout ball wipes out the titles whilst waiting for you to press the space bar.

Would have been even more "super" if it had supported joystick, but never mind.

This is another one with two BASIC programs. Ooh, I can do the "combine those into a single program for a 3K expanded VIC20" trick again.

So I set about the about the same process, just a case of removing the "NOW LOADING" screen.

And also, the rather unusual "PRESS STOP ON RECORDER". I wondered if that was left over if this was ported from another machine? (it is not, there is a reason, see a future post on the autofire in Bandits)

That all seemed to be going to plan, until I hit a couple of snags.

Firstly both parts used DATA statements, not in itself a problem, just need to get them in the correct order in the merged file. But both parts also use RESTORE. This command resets where data is read from. Other versions of BASIC let you set a line number, so RESTORE 1000 resets the reads to line 1000, but it appears Commodore BASIC does not.

I had found a way around that (by adding dummy reads to one part to skip over the data used by the other), but as soon as the game started, it went back to the good old READY prompt?

Looking through the code again, I found a little snipped I had overlooked.

73 open1,1,0," ":fori=0to34:input#1,b$:poke7628+i,val(b$):next:close1

That is reading 34 bytes of data from the tape after the second program. Here we go again with the magic.

The same code also POKEs data into RAM from some DATA statements, so I guess that is some form of copy protection.

I looked at converting that to DATA statements, but that would confuse the RESTORE situation further as I couldn't work out how often the second RESTORE was being called, and how that would affect this version that only needed to be read once.

I decided to give in with single version, and went back to the previous approach of modifying part 1 to jump back to the cartridge to load part 2. I still had to deal with the extra magic bit of code, so I just copied that into RAM at that address before loading part 2 and deleted that line of code.

Not as easy as I would have hoped, but that's another one done.

Penultimate +2 Cartridge

The Penultimate +2 Cartridge, containing these and many other games in stock at The Future Was 8 bit:

https://tfw8b.com/product/vic20-penultimate-plus-two/ (new site)
https://www.thefuturewas8bit.com/vic20-penultimate-plus-two.html (old site)

Patreon

You can support me via Patreon, and get access to advance previews of posts like this and behind the scenes updates. These are often in more detail than I can fit in here. This also includes access to my Patreon only Discord server for even more regular updates.

https://www.patreon.com/tynemouthsoftware

I am sure you know the story of Tut-Tut by now. It started as a type-in listing for the ZX Spectrum by David Stephenson, who then evolved that into a ZX81 version, then a fuller Spectrum version, then there was a version for the Jupiter Ace by George Beckett, then my version for the Commodore PET. More info on the evolution in my previous post on the PET version (more details of the history in the post about the PET version)

http://blog.tynemouthsoftware.co.uk/2022/09/tut-tut-for-commodore-pet.html

I was talking to David about that PET version and he raised the question

That set in motion a discussion about fitting the map into the available screen on the VIC20, or making the VIC20 screen wider (which was the final decision). The PET version would not require much modification, but the VIC20 would need new colour graphics, which was beyond my abilities, but well within those of David.

So, less than a quarter of an hour after the original question, we had agreed to start a joint development of a VIC20 version.

David set off looking into the VIC20's multicolour graphics modes, and I set about making the PET version run on a VIC20.

OK, so good start, it's running. The screen size is wrong, but that can be adjusted.

It works for PAL, but NTSC doesn't fit.

But will fit if nudged to the left so half of the edge characters are cut off, but the inside is still visible.

With a bit of shuffling things around to fit with the reduced screen size of 26x23, I was able to get a playable version of the PET version on the VIC20. (of course I made it green)

Now that we had the screen size sorted, we could continue with the game. The PET is almost the same speed as the VIC20, so there was no need to adjust the timing etc. The screen was oversize, and overwrote the start of the code space, so a quick bodge at this stage was to start the code with 80 NOP statements.

With that version as a starting point, work began.

The sounds translated well from the PET version (which was based on the Spectrum version). Most of the code remained the same, I just needed to change the "beep" function to poke the VIC chip rather than the 6522.

http://blog.tynemouthsoftware.co.uk/2022/05/pet-sounds.html

David was trying out graphics and colours.

And the character set

Ah, a custom character set. That complicates things, the character font now conflicts with the code and the overlapping video RAM. The VIC20 memory map can be a nightmare at times.

http://blog.tynemouthsoftware.co.uk/2019/09/how-the-vic20-works.html

After a bit of rearrangement, it looks good (even though I still have it set to all green from the PET demo).

You might notice the date is listed as MMXXI (2021), that is not a typo, it was indeed August 2021 when we were doing this.

Looking rather good already.

The NTSC was also fitting nicely, with only the edges of the borders cut off.

Testing on real hardware proved some of the colour combinations didn't work.

It was difficult to see some of the symbols, particularly the red and pink.

David tried alternating colour blocks, but it looked a bit too busy.

Nice new corner graphics though.

This still work on NTSC, although the status lines below will need to be reduce by 1 character each side.

With the new levels and further updates to the graphics, it was looking rather good.

Versions went back and forth between us, adding new features and tidying things up all the time.

I added joystick support, complicated as ever by the unusual choice to have three directions and fire on one input port and the last direction on an entirely different port.

David added a new bold font to make the title stand out.

And again more graphical tweaks, looking better all the time.

Up to this point, we were using the same levels from the PET version (which were originally from the ZX81 version). However, David had improved on that for the Spectrum version, so I adapted the code to use the new level format, since it had more levels and the collected level data was actually smaller than the ZX81 version.

And so, about a week after than initial conversation, we had a pretty decent version of the game running on a real VIC20.

But we weren't going to stop there. This was already the best looking version. Let's make this the best version.

David set off adding new levels, and I started working on some new functionality.

I remember spending ages trying to complete this new level.

Agghh, so close.

Finally!

Although David had a much faster solution (but he's sort of cheating since he created all these levels).

Other ones just blew my mind.

Whilst all these new levels are great, it is a shame that people won't get to see them that often. I wondered if we could have something like Lemmings or Repton where you get a level password when you complete a level so you never have to go through that torture again and can restart another day at the next level?

I know some numpty will post a list of them on the internet at some point, but that's not actually a bad thing as more people will get to try more levels rather than getting stuck on level 3 and never getting further than that, or not having 24 hours straight to go through all the levels in one go.

We went through a few variations options, and ended up with a 6 character code the user had to enter, later reduced to 4.

Rather than letters and numbers, I looked at various options for combinations of symbols, with symbol and colour being used.

I then realised I could just use some of the symbols already in the game, the Ankh, the key, the jewel etc.

The plan was there would be four symbols in the top right of the screen, different for each level. If you wanted to get back to that level, you had to enter those symbols into a special screen.

However, it was proving difficult to tell them apart on a real VIC.

NTSC was also having problems.

On some levels, you ended up with "four coloured blobs".

Here is a video showing TFW8b going through a preview version at around this point:

https://www.youtube.com/watch?v=tSMMDXFSP08

It was clear after this that the "fire to pause" was not going to be helpful as Rod kept clicking fire and pausing the game.

I also removed different pause messages each time, as that seemed to confuse things.

But the main take up was yes, the colours and symbols thing wasn't working.

After going around a few more variations, I went to a simpler option and just used numbers, in a more readable colour.

That makes it easier to see and also when entering a code.

Rather than using a letter to get to the code screen, I decided to go all "VIC20" and change them all to the function keys.

Things were getting close. David created a new "widescreen" painting to use for a cartridge sleeve

Which came out looking great

I mocked up a cartridge sleeve.

All was looking quite good, and this was the "definitive edition".

There were plans for this to be a splash screen.

I wasn't able to get this into the cartridge version, but it will be there as a loading screen for a tape version.

Then, well, time passed.

TFW8b put cartridge and tape releases on hold for a while, and so Tut-Tut got put on a shelf.

Roll on 2023, and the Penultimate +2 is an ideal place to put the VIC20 Version of Tut-Tut, so in it went.

I went back through and made a few tweaks and tidied a few things up. I wanted to get rid of the NOP instructions at the start to get around the various video memory regions interfering with the code, and decided to convert it to a full cartridge built (rather than a PRG file in a cartridge).

The meant moving the code around to run from a cartridge in the A000 region, also using blocks of code and data in 2000 - 7FFF. That left the 1000-1FFF region free for the video RAM and character RAM, so fixed all of the overlap issues.

One almost slipped through, although not visible on the PAL version, the NTSC version had a row of pixel at the bottom of the screen?

It turns out that those pixels are actually displaying variables at the start of the working RAM. I adjusted the working RAM to be a bit higher up in RAM, and extended the clearing routine to write an extra row of blank / black characters and it was fixed.

I don't know if/when the separate cartridge or tape versions will be released, to be decided. Likewise a digital download (although that and the tape version will require refactoring the code back into a PRG again).

Read more about Tut-Tut for the VIC20 in David's own post:

https://www.zx81keyboardadventure.com/2023/07/tut-tut-tomb-raiding-on-vic-20.html