Can't get enough of Boulder Dash? :o
After converting the caves from Boulder Dash 2 (https://www.cpcwiki.eu/forum/games/boulder-dash-2-rockford-s-revenge/) from the C64, I wondered how all the other caves would feel like with the BD4 engine...
So I converted all caves from BD1 and BD3, too. Back in the days I was too lazy to convert the caves with the Construction Kit. Without tools this would be just too much work. Sadly I never converted cave I in which you really see the difference between BD1 and the BD4 reimplementation. Curiously BD4 feels like the Nintendo conversions. IMHO. (I can't say which engine is better BD1 or BD4...)
The zip contains two disks, because I provide all caves ready to play and to edit. BD4 came without editable caves which was quite a pity. But now there you go: I also reimported the BD4 caves. The colors should now be closer to the original and I tried to make the caves behave as they were intended. But I also added the original caves.
I also added BD2, so this is a very complete collection 8)
To do all this I wrote some command line tools in Java to convert the caves. Maybe you find them useful, too. [LINK REMOVED, UPDATE COMING]
To convert the C64 caves I had to understand the CPC file format. Unfortunately we don't have such an awesome page like the C64 Boulder Dash Inside FAQ (http://www.gratissaugen.de/erbsen/BD-Inside-FAQ.html), so I had to to it myself:
Boulder Dash Construction Kit for Amstrad CPC
---------------------------------------------
.CAV/.INT file format
---------------------
Offset Bytes Range Description
------ ----- ----- -----------
0000 0045 AMSDOS header (start address: #0051, length: #0385)
NOTE: Nothing in the header is used, just make sure
start/length/filename/checksum are valid!
0045 0001 40-5F background color (not used, see #400)
0046 0001 40-5F foreground color1 (not used, see #401)
0047 0001 40-5F foreground color2 (not used, see #402)
0048 0001 40-5F foreground color3 (not used, see #403)
0049 0001 40-5F border color (not used, see #404)
004B 0001 filename[4] (not used)
004C 0001 filename[5] (not used)
004D 0001 filename[6] (not used)
004E 0001 filename[7] (not used)
004F 0031 AMSDOS header
0080 0370 40 x 22 = 880 bytes of cave description (including all borders)
03F0 0001 0-99 cave delay as decimal hex (*)
03F1 0001 0 unused
03F2 0002 0-999 cave time in seconds as decimal hex (high byte first)
03F4 0001 0-99 diamonds needed as decimal hex
03F5 0001 0 unused
03F6 0001 0-99 diamond value as decimal hex
03F7 0001 0 unused
03F8 0001 0-99 bonus diamond value as decimal hex
03F9 0001 0 unused
03FA 0001 0-99 slime permeability as decimal hex
03FB 0001 0 unused
03FC 0002 0-999 amoeba time of growth as decimal hex (high byte first)
03FE 0002 0-999 magic wall time as decimal hex (high byte first)
0400 0001 40-5F background color
0401 0001 40-5F foreground color1
0402 0001 40-5F foreground color2
0403 0001 40-5F foreground color3
0404 0001 40-5F border color
(*) decimal hex: #11 means 11 seconds, #A-#F is never used
Boulder Dash Objects
#00 = space
#01 = voodoo Rockford
#02 = slime
#03 = growing wall
#04 = boulder
#05 = brick wall
#07 = magic wall
#08 = dirt
#09 = butterfly
#0a = firefly
#0b = diamond
#0d = titanium wall
#0e = amoeba
#10 = open exit
#11 = exit
#12 = inbox
#13 = border titanium wall
.GAM file format
----------------
Offset Bytes Range Description
------ ----- ----- -----------
0000 0080 AMSDOS header (start address: #060a, length: #11f5)
NOTE: Nothing in the header is used, just make sure
start/length/filename/checksum are valid!
0080 0001 number of caves + 1 as decimal hex (example: #11 means next cave is cave no. 11)
0081 0001 number of caves + 1 (example: #0B = 11)
0082 0002 last cave address (high byte first)
0084 0013 1 byte for each cave:
#00 = not selectable intermission
#01 = selectable intermission
#80 = not selectable cave
#81 = selectable cave
0097 0001 0 unused (start of cave data header, header length = #18)
0098 0002 cave end address (high byte first) where cave end address is:
first cave end address: #0622 + length of cave data (including header)
next cave end address: previous cave end address + length of cave data (including header)
009A 0001 cave delay as decimal hex
009B 0001 0 unused
009C 0002 0-999 cave time in seconds as decimal hex (high byte first)
009E 0001 0-99 diamonds needed as decimal hex
009F 0001 0 unused
00A0 0001 0-99 diamond value as decimal hex
00A1 0001 0 unused
00A2 0001 0-99 bonus diamond value as decimal hex
00A3 0001 0 unused
00A4 0001 0-99 slime permeability as decimal hex
00A5 0001 0 unused
00A6 0002 0-999 amoeba time of growth as decimal hex (high byte first)
00A8 0002 0-999 magic wall time as decimal hex (high byte first)
00AA 0001 40-5F background color
00AB 0001 40-5F foreground color1
00AC 0001 40-5F foreground color2
00AD 0001 40-5F foreground color3
00AE 0001 40-5F border color (end of cave data header)
00AF 11C5 run length compressed cave (including all borders)
each byte has this compression rule:
the first three bits are the count, the last five bits are the element
if the first three bits are zero, then the byte is the element itself and the next byte is the count
element specification is identical to .CAV file format
ends with #FF, then follows next cave end address and so on...
1274 0001 in theory: the last byte of the last cave, in practice: garbage,
because it is unlikely that a cave will fit exactly in the remaining space
Hope this could be useful for future projects... Like including the new elements in BD4?? Or even use this file format in BD1?? :o
Hi @pmeier (https://www.cpcwiki.eu/forum/index.php?action=profile;u=2206) , another Boulder Dash appears !!!
https://www.indieretronews.com/2021/11/boulder-dash-junior-vi-another-c64.html (https://www.indieretronews.com/2021/11/boulder-dash-junior-vi-another-c64.html)
Yeah, it's cool that the BD scene is still active... But be warned: I can do bulk imports with my tools ;D