Mine Sweep Mini RC1

[Shaun.Bebbington]

Hi,

Here's Mine Sweep Mini RC1.

One may select a skill level on starting, which will determine the number of flags that you are able to place. When you have placed all of your flags, the program will auto-check whether you are a winner or not, but as the game now allows more than 10 flags, I've added the ability for the player to check on easier levels by pressing F7.

As the listing is a little on the messy side, I've left out the logic for the joystick reader so unfortunately it's manual typing. However, if I get the time, I will do a re-factor as I also want to make a bigger mine field of up to 15 x 15 as well.

If anyone has a nice tune in BASIC that I could use then please contact me and I'll cello tape it in to the listing and try to get it to play during the start screen. There's about 1K of RAM according to FRE(0).

There may be bugs in there so please report them back here.

Edit: Found the first bug - there is screen creep upwards after the explosion. Should now be fixed. Please download RC1-1

Many thanks,

Shaun.

[Shaun.Bebbington]

RC1-1 seems stable so it is released.

If I do another version, it'll include joystick controls, a 15 x 15 area and some other things.

Regards,

Shaun.

[joshuadenmark]

Hi Shaun

Missed this game post, looks very appealing will give it a run after work, great job!

[Shaun.Bebbington]

Hi Joshua,

There is a version coming soon from Cronosoft as well which will work on unexpanded and +3K machines. If the extra RAM is detected, a custom character set is loaded in, and a few other tweaks.

I made the tape and disk images earlier this week and sent them to Simon, expect the Cronosoft version to be under £5 inc. postage and packaging. This won't be free to download (at least not from me) just in case someone actually pays for it.

Regards,

Shaun.

[joshuadenmark]

Hi Joshua,

There is a version coming soon from Cronosoft as well which will work on unexpanded and +3K machines. If the extra RAM is detected, a custom character set is loaded in, and a few other tweaks.

I made the tape and disk images earlier this week and sent them to Simon, expect the Cronosoft version to be under £5 inc. postage and packaging. This won't be free to download (at least not from me) just in case someone actually pays for it.

Regards,

Shaun.

Looks like a great christmas gift for myself, great

[Shaun.Bebbington]

I wrote another game yesterday, though it's not Battleships. PM me if you'd like to test the current release candidate

Regards,

Shaun.

[wimoos]

What I found in your code is that you're using line 0 to hold the contents of the hidden mine-field. That is a little tricky (as a mine-field is ).

Since there's only a few states that a location in the mine-field can have, it is maybe a suggestion to use the (4-bit wide) memory locations at $9400-$95FF.

Regards,

Wim.

[Shaun.Bebbington]

What I found in your code is that you're using line 0 to hold the contents of the hidden mine-field. That is a little tricky (as a mine-field is ).

Since there's only a few states that a location in the mine-field can have, it is maybe a suggestion to use the (4-bit wide) memory locations at $9400-$95FF.

Regards,

Wim.

Thanks for the feedback and hints. Unfortunately, as I don't like touching 'working code' (simply because I'll never get anything finished), the game has already been packaged up in .d64 and .tap, and sent for evaluation to Cronosoft and Psytronik. Hopefully it will be released, although the paid version does have some improvements. There's a +3K RAM Pack detector which will load in a custom char set and zero or more obscure bugs have been fixed.

Using the second example here, I've thought of a way to simulate C-alike bitwise operators to get a whole 10 x 10 minefield into 100 bits, which is ~12 times smaller than my method of POKEing the REM statement at line 0. I may try this to see if I can get it to work, although it'll be much slower. So it'll be a case of balancing performance with memory.

You say $9400 is free, what area of the RAMs is this?

Regards,

Shaun.

[Shaun.Bebbington]

Here is a quick example of using 16 bytes to represent 128 flags, ie, 1 could be "a ship is here"

Code: Select all

0 gosub 1000:rem put bits into ram at 820
10 for i=0 to 15:poke 820+i,0:next i: rem clear the bits first
20 for i=0 to 15
30 y=128
40 for a=7 to 0 step -1
50 poke 820+i,peek(820+i) or (y*(int(2*rnd(.))))
60 y=y*.5: rem same as y=y/2
70 next a, i
80 for a=0 to 15: rem let's investigate the memory
90 y=820+a: gosub 500
100 next a
110 end: rem fin
500 x=128:print y;: rem print current location
510 for i=0 to 7: rem show as binary
520 print b$(sgn(peek(y) and x));
530 x=x*.5
540 next i
550 print peek(y):return: rem show contents of byte and return
1000 rem variables and constants:
1010 dim b$(1), i, x, y, a
1020 b$(0)="0": b$(1)="1"
1050 return

It seems that location 820 is just below the cassette buffer and is free to use up to location 1023. And yes, I know assembly or machine code would be much quicker, but I don't have time for that as it's also too difficult.

Regards,

Shaun.

[Mike]

All those savings in variable space need to be weighted against what is necessary as extra code to decode the bit array. In most cases, using an integer array instead of a float array already leads to substantial savings, reducing the necessary memory down from 500 to 200 bytes in case of a 10x10 array.

If you want to use a really *huge* bit array, it is possible to store 16 bits into a single integer number. This is done using the following preparatory statements:

Code: Select all

DIMBI(15):BI(0)=1:FORT=1TO15:BI(T)=2*BI(T-1):NEXT:BI(15)=-BI(15):Q=1/16
DIMF%(19):REM ** ALLOCATE 16*(19+1)=320 BITS, CUSTOMIZE AS NEEDED

The first line sets up powers of 2 in the array BI(). It is deliberately left as float so calculations are not slowed down too much (all integer numbers are internally processed as float numbers, adding extra cost for conversions). BI(15) is made negative to account for that F%() stores signed integers. Q stores the reciprocal of 16 to avoid the costly division 'N/16' to access the array elements.

Now, these two statements set or reset bit n:

Code: Select all

F%(N*Q)=F%(N*Q)ORBI(NAND15):REM ** SET BIT N

F%(N*Q)=F%(N*Q)ANDNOTBI(NAND15):REM ** RESET BIT N

... and the following expression (here used as argument for PRINT) returns 1 if bit n is set, otherwise it returns 0. It can be simplified for use as conditional in an IF .. THEN statement (for that use only =0 or <>0 are relevant):

Code: Select all

PRINT (F%(N*Q)ANDBI(NAND15))/BI(NAND15)

IF F%(N*Q)ANDBI(NAND15) THEN [...] : REM ** EXECUTE IF SET

IF (F%(N*Q)ANDBI(NAND15))=0 THEN [...] : REM ** EXECUTE IF NOT SET

Of course, your program can use other names for F%() and N, as long as they're used consistently.

I used a variant of this method in my maze program to store a big array of 80x96 2-bit numbers.

The canonic show case for a bit array of course is the Sieve of Eratosthenes, which goes like this:

Code: Select all

1 INPUT"PRIMES UP TO";M
2 DIMBI(15):BI(0)=1:FORT=1TO15:BI(T)=2*BI(T-1):NEXT:BI(15)=-BI(15):Q=1/16
3 DIMP%(M*Q):N=1
4 N=N+1:IFN*N>MTHEN7
5 IFP%(N*Q)ANDBI(NAND15)THEN4
6 FORS=N*NTOMSTEPN:P%(S*Q)=P%(S*Q)ORBI(SAND15):NEXT:GOTO4
7 FORN=2TOM:IF0=(P%(N*Q)ANDBI(NAND15))THENPRINTMID$(STR$(N),2)" ";
8 NEXT

On an unexpanded VIC-20, this one easily manages primes up to, say, 25000. With a standard integer array, that would normally require 50000 bytes and wouldn't even fit into the memory available for BASIC on a C64!

The storage requirements of the array can be cut by (yet another) half by storing only the odd numbers, how to implement that variant is left as exercise to the reader.

[wimoos]

Shaun,

At address locations $9400 - $97FF there is 1K *4 bits of RAM, used by the VIC-chip for the foreground colors of the screencharacters.
Actually, of these 1K, in a default screenlayout of 22x23 only 506 locations are used: starting at $9400 or at $9600. This depends on where the screenmemory is set.
In an unexpanded or a +3K config screenmemory starts at $1E00: then the colors start at $9600. In +8K, +16K or +24K config screenmemory starts a $1000: the colors then start at $9400.

The other half of the 1K is then free for other uses and can hold (for example) a hidden minefield. Mind you, they are only 4 bits wide, so you need to: PEEK(x) AND 15.

Regards,

Wim.

[Shaun.Bebbington]

Out of curiosity, does declaring your variables with a % specifically tell CBM BASIC that the range of this number can only be -32768 to +32767 (or is it -32767 to +32768)?? If so, this is very useful to know.

Regards,

Shaun.

[wimoos]

Integer variables are declared with a %. The variable value takes up two bytes and is signed. This means that the values can be from -32768 to +32767.

The memory footprint of any simple variable (not in an array) is seven bytes. Two for the variable name and five for the contents.
For a simple integer variable, three of those five are allocated but not used. For a simple string variable, two of those five are allocated but not used.
For a simple float variable, all five are allocated and used.

In an array, allocations are more memory efficiently.

Regards,

Wim.

[Shaun.Bebbington]

It felt like a year since I started messing around with Commodore BASIC again, and actually it's closer to 2! Where does the time go?

Anyway, the Cronosoft version was rejected due to the colour scheme so I decided to release it into the public domain, as you will now see.

Thanks,

Shaun.