Concentrate for the unexpanded VIC

[thegg]

After a very long time (35+ years), I have finally written my first VIC-20 game.

Concentrate is a numeric puzzle game and a full description is provided in the attached zip file. Basically, the challenge is to fill in the hidden numbers in a 7 by 7 grid so that each diagonal, row and column sum to a given target number: simple addition and subtraction is all that is required.

If this genre interests you, please give it a try and let me know what you think. Also, I would be pleased to hear if it runs ok on real hardware. It should work on both PAL and NTSC machines. I have put in quite a few hours testing that it works as I wanted, but bugs and things always seem to creep in. Any noticed would be gratefully received.

[chysn]

So... what's the intention here? It seems to be written for unexpanded VIC, with all the memory hallmarks; but it's about 70 bytes too big for unexpanded VIC and runs into unexpanded screen memory. It runs but eventually crashes. What's up with that?

It looks promising, though. I like this type of game.

[thegg]

Hi chysn
Thanks for taking a look.
I was running out of space so I decided to move some of the preset data down to the rs232 buffer at run time. So when the program starts the first thing it does is to move the data that loads into the screen area down to $0293, after which it gets deleted. Thats why the program seems longer than it should be.

I am not seeing any crashing, but I only have access to the Vice emulator. I assume you are running on your real hardware. Can you give me some idea of when it is crashing. Is it on the options screen or the puzzle screen.

[Mike]

Just to set straight the terminology used here:

I was running out of space so I decided to move some of the preset data down to the rs232 buffer at run time. So when the program starts the first thing it does is to move the data that loads into the screen area down to $0293, after which it gets deleted. [...]

$0293..$029E are not the "RS232 buffer", rather these are the pseudo registers of the 6551 ACIA emulation built into the KERNAL. The actual RS232 transmit and receive buffers are allocated on demand at the end of BASIC memory, when a RS232 channel is opened.

Edit: $029F/$02A0 hold a copy of the IRQ vector during tape operations.

Then follow the so-called program indirects in $02A1..$02FF. These are unused by BASIC and KERNAL, but some cartridges (most notably, Super Expander) use these to hold workspace data.

That being said, loading into screen and copying the data/code there elsewhere after program start is not very robust: any screen changes before execution of RUN will thrash whatever you wanted to copy away.

At ~3.5 KB length, you are likely to find lots of opportunities to shorten/size-optimize the program code by those ~100 bytes you currently decided to handle this way, making that construct redundant.

[chysn]

Ah, okay. The screen portion was absolutely corrupted at the time I ran the program. I’ll try again.

[thegg]

Mike
Of course you are right. A poor choice of words on my part.

Using the screen memory as a temporary store is clearly not sensible. One of the problems of cross development to an emulator is that some things are not immediately obvious. When chysn made his observation, I put the program on a disk and loaded it more realistically. The potential for problems then became clear.

I'll follow your advice and look to find the space in some other way.

Many thanks for taking the time to respond.

[chysn]

Once I knew that the screen had to be left alone, it works just fine on a real VIC. It's a high-quality execution of the concept, with a nice Sudoku-like feel during play. I think the hex option is innovative, although I haven't tried it yet.

It would be worth your time to find optimizations. You're 69 bytes over, and you probably use 11 bytes for the memory move code, so you need to find 58 bytes. The low-hanging fruit here is the instruction/setup screen and in-game text:

* You don't need to specify "OPTIONS".

* You could accept numbers to set the level and use "LEVEL 1-3" instead of "E - EASY", "D - DIFFICULT", "H - HARD".

* Pressing 1, 2, or 3 could immediately begin the game, rather than requiring a separate key press. You save the extra CMP/BEQ, as well as the instruction text for Start.

* You can replace "ROW", "COL", "DIAG (LR)", and "DIAG (RL)" with the graphics "-", "|", "/", and "\", respectively.

* I don't think the word "TARGETS" is necessary during play.

* There's no need for a "QUIT" option in a VIC-20 game. You turn it off when you're done.

From what I can see, you can make up all the extra space with more concise text, and have memory to spare, with no impact on understanding. You don't even need to do a code optimization pass. Just the suggestions above come to about 80 bytes.

In my unexpanded games, the instruction screen is the thing I'm tweaking right up to the last byte.

[thegg]

Chysn,
Thanks for the words of encouragement and taking the time to come up with some options to save some memory. I'll certainly be considering your suggestions when I look at optimising the code. I think I may be able to recover enough space within the screen drawing, but if I come up short I'll be using some of your ideas.

[nbla000]

Another option could be to leave things as they are and use exomizer/pucrunch to compress the program, in this way when you load it, you do not corrupt screen memory that will be corrupted just for a while after the RUN like on VICE.

[chysn]

Another option could be to leave things as they are and use exomizer/pucrunch to compress the program, in this way when you load it, you do not corrupt screen memory that will be corrupted just for a while after the RUN like on VICE.

How does this work?

[thegg]

Another option could be to leave things as they are and use exomizer/pucrunch to compress the program, in this way when you load it, you do not corrupt screen memory that will be corrupted just for a while after the RUN like on VICE.

I have crunched the PRG file with Exomizer and it is about 25% smaller (see attachment). The program data in the screen shows only briefly when the program is run. So it is better in that respect. Thanks for the suggestion.

I think I will go through an optimisation exercise to see if I can get to the normal program size while still retaining my user layout.

concentratec.zip

(2.98 KiB) Downloaded 50 times

[thegg]

The program has been optimised to release enough memory so that preset data can be stored in the normal unexpanded memory. Please find an update in the attachment.

Thank you to those who found time to look at the game and suggest improvements. Any further input would be much appreciated.

concentrate.zip

(3.95 KiB) Downloaded 59 times