something interesting I found....

[RaVeN72]

while looking through some versions of the C64 Boulderdash IV / Construction Kit in CSDB I found one that also includes a game module file that appears to have been patched to not require a GAM file to load the levels....Instead it loads the CAV files in sequential order (they must be named 01.CAV, 02.CAV, 03.CAV) - this seems a pretty neat way to make a 'standalone' game without extra editors, compressors, etc....

[LogicDeLuxe]

Sounds like a hacked tape version to me. Can it be restarted with SYS22969? Then it certainly is.
The tape version just loads the caves as they are present on the tape, which is sequential by nature. Since floppy disks are not, they specifically designed the gam files for that kind of media, but not used it on tape.
Oddly enough, they included the same construction kit with disk and tape versions, which can be confusing, if you don't know the differences.

[RaVeN72]

Sounds like a hacked tape version to me. Can it be restarted with SYS22969? Then it certainly is.
The tape version just loads the caves as they are present on the tape, which is sequential by nature. Since floppy disks are not, they specifically designed the gam files for that kind of media, but not used it on tape.
Oddly enough, they included the same construction kit with disk and tape versions, which can be confusing, if you don't know the differences.

nice dectective work - SYS22969 does indeed restart the game - and the intro/docs specifies 15 caves, which matches the tape version of the construction kit

edit:- so after a busy afternoon with the VICE emulator and Monitor, I now have a version of the game module without the silly crackers intro and documentation that starts at the main boulder dash cave selection screen - quite happy with myself today

[LogicDeLuxe]

Has it $565d sta $29? That is the cause for garbled memory resulting in crashes or broken caves. If you really intend to use this version, you should change that to nop nop.

I always wondered how that instruction ended there. That byte is never read explicitly, but it is part of a table used by the dissolve effect. Also BD1 and BD2 have such a superfluous instruction in this routine, except it doesn't conflict with anything on those. Must be a vicious typo in the source code ever since, but only took effect when they did PLCK for some reason.

[RaVeN72]

Has it $565d sta $29? That is the cause for garbled memory resulting in crashes or broken caves. If you really intend to use this version, you should change that to nop nop.

I always wondered how that instruction ended there. That byte is never read explicitly, but it is part of a table used by the dissolve effect. Also BD1 and BD2 have such a superfluous instruction in this routine, except it doesn't conflict with anything on those. Must be a vicious typo in the source code ever since, but only took effect when they did PLCK for some reason.

Thank you for the information - i have patched the two bytes with NOP's - although I played through some cave and saw no evidence of crashing or broken caves without the patch

[LogicDeLuxe]

although I played through some cave and saw no evidence of crashing or broken caves without the patch

It randomly happens when you press the button at finishing or restarting a cave. In corrupted caves, you'll get randomly placed dirt and hidden exits next to it, since the dissolve char (7c) equals to the nybble codes of those two elements.

[RaVeN72]

have been continuing to experiment with the different versions of the construction kit - I made some caves with the tape version, storing the single caves on individual .TAP files - now to join the individual .TAP files into a single .TAP file, I found that this works which was a bit of a surprise:-

at the command prompt type

copy /b 1.tap+2.tap+3.tap 123.tap

will join the three .TAP files into a single file named 123.tap

the game module will happily load all 3 caves - something I could not achive using a file copying program in emulation