More Boulder Dash!

[raspberrypioneer]

I wish there was more Boulder Dash for the Electron (I've recently acquired one). It is excellent and compares very favourably to the C64 and Atari versions, which I’ve also played a fair bit. The developer did an amazing job. If only there were more in the series!

With that in mind I wondered if I could tweak the existing version to make it easier. There are some hard caves (especially cave J), and the other levels are fun but there's not enough time to complete many of the caves from level 3 onwards especially.

I found a way to do this as below, which other Boulder Dash fans might find useful.

Hex addresses for cave diamonds, time limits, start/end points:

diamond value (caves A to P and 4 bonus caves, all levels) hex 3800 to 3813
diamond extra value (caves A to P and 4 bonus caves, all levels) hex 3814 to 3827

diamonds needed (caves A to P and 4 bonus caves, level 1) hex 3828 to 383B
cave time limit (caves A to P and 4 bonus caves, level 1) hex 383C to 384F
diamonds needed (caves A to P and 4 bonus caves, level 2) hex 3850 to 3863
cave time limit (caves A to P and 4 bonus caves, level 2) hex 3864 to 3877
diamonds needed (caves A to P and 4 bonus caves, level 3) hex 3878 to 388B
cave time limit (caves A to P and 4 bonus caves, level 3) hex 388C to 389F
diamonds needed (caves A to P and 4 bonus caves, level 4) hex 38A0 to 38B3
cave time limit (caves A to P and 4 bonus caves, level 4) hex 38B4 to 38C7
diamonds needed (caves A to P and 4 bonus caves, level 5) hex 38C8 to 38DB
cave time limit (caves A to P and 4 bonus caves, level 5) hex 38DC to 38EF

start box row (caves A to P and 4 bonus caves, all levels) hex 38F0 to 3903
start box col (caves A to P and 4 bonus caves, all levels) hex 3904 to 3917
end box row (caves A to P and 4 bonus caves, all levels) hex 3918 to 392B
end box col (caves A to P and 4 bonus caves, all levels) hex 392C to 393F

Tools:
Beeb Image.exe, the BBC Micro disk image editor
Notepad++ with Hex Editor plugin (add plugin if necessary)

Method:
Download Boulder Dash.ssd. I found it on www.everygamegoing.com
Run Beeb Image.exe, choose 'Load Image' and select Boulder Dash.ssd
Choose 'Write All To Host' to write all the game files to a local folder
Open file 'MBOL2.$' in Notepad++ and choose Plugins > Hex-Editor > View in HEX
Navigate to the hex addresses mentioned above and edit the ones you'd like to change with new hex values
Save file 'MBOL2.$'
Run Beeb Image.exe, choose 'Load Image' and select Boulder Dash.ssd again
Select the line with the 'MBOL2.$' file and choose 'Cut Files' to remove the original version of this file
Choose 'Add Files from Host' and select the edited version of the 'MBOL2.$' file
Choose 'Save Image'
Load the new version on the Electron and test the changes / play the game

There might be better ways to do this, especially editing the ssd file with the hex value changes. I'm new to this, so if there is another way to go about this I will be interested to know.

[Cybershark]

Great job, with the excavations there! The game annoys me - as the movement controls are unreliable - but I'm still half-tempted to knock up a full level editor for it. Seems like it'd probably be simple enough. Were you also able to identify where the map data begins and ends?

I'm curious though, as you reference a file called "MBOL2.$" on an SSD image. I can only find UEFs of the Elk version, and those do not contain such a file. Can you link to the disc image that you have, or upload it here?

I note from the original game instructions:
"To select a different DIFFICULTY level, go to the menu screen and press arrow keys (or move the joystick up or down). The greater the difficulty level, the less time and the more jewels you have to collect."

So, presumably, that's exactly what * and ? do on the Acorn versions' Options screen?

[raspberrypioneer]

Apologies, the ssd I must have used is this one: https://wowroms.com/en/roms/acorn-bbc-m ... 63461.html.

I know what you mean about the keys, I've been using the ElkSD128 remapping the keys for a joystick, which works well for me. I've completed levels 1 and 2 without feeling the controls were letting me down. That is with a hack for cave J 'tracks' which is too hard for me!

I did have some success in decoding the caves, see below, but some are more complicated than others and I guess the developer has some cave-specific routines to build them. This link helped me know what each cave should look like when decoding them: https://www.boulder-dash.nl/

Cave A 3060F to 30BC - this was my best decode (decoding below). I am missing the walls though otherwise 'complete' for level 1
Cave B to D is uncertain, I think there are a couple of reasons - looks like there are values to build the walls and also perhaps how to change caves for the different levels from a base starting point.

These caves look like they start / end here because of the decoding, and if I change some hex values I can see the effect on these caves. I'm missing some caves but guess they're somewhere in between these addresses.
Cave E 3458 to 349B
Cave F 349C to 34E9
Cave G 34EA to 350F
Cave M (approx) 3620 to 367C
Cave N (approx) 367D to 36CF
Bonus Cave 2 (approx) 3750 to 37B1

Each cave is 22 x 40 including the titanium border, the bonus caves are 12 x 20
I think levels are applied over the base cave using some 'random' values (not really random but work for each level). I'm not sure where this is done. Yes, I just select the levels on the main options screen which is nice so you can get a slightly different cave layout. With some time limit hacks I have a chance of completing them!

Decoding caves ...
Convert hex value to binary value
First 5 bits are the number of ground squares
Next 3 bits represent the number of the last object which is translated:
0 = space, 1 = ground, 2 = wall, 3 = ground, 4 = diamond, 5 = boulder, 6 = firefly, 7 = ground
There are missing objects like the butterfly and amoeba and there is more ground than expected so there are probably bespoke routines to remap these values for some caves

Some examples:
Hex > Bits 5 + 3 > Ground > and char
20 = 00100 000 = 4 ground +1 space
5d = 01011 101 = 11 ground +1 boulder
f9 = 11111 001 = 32 ground
5 = 00000 101 = 0 ground +1 boulder
14 = 00010 100 = 2 ground +1 diamond

Hope this helps!

[Cybershark]

Thanks for the link. That seems like pretty much the same as the other versions out there, I think.
For some reason it had two copies of the game on the disk image?

You've really done some digging here! From the sound of it, it may be quite the undertaking to alter entire levels. I will look into it a bit more for sure but, for now, you'll have to make do with this:

Boulder Dash mod.ssd

(46.25 KiB) Downloaded 7 times

Load up the disk image, CHAIN "EDITOR" and you will have easy access to tweaking the default game values

EDIT: Just remembered you said you were playing on an Elk emulator, and I've gone and written my number fiddler in MODE 7...

[Cybershark]

Elk compatible (MODE 6) version of my number adjuster now included:

Boulder Dash mod.ssd

(46.25 KiB) Downloaded 10 times

CH."EDITOR6" to start juggling

[raspberrypioneer]

Very cool! So much easier than messing around with hex values and saving files. I've just edited a couple of caves so far (using EDITOR6) and it works a treat . I'm using a real Electron / Elk so all good on real kit

Thanks so much! I'll also take another look at dissembling the caves (or excavating them as you mentioned ). I've done some 6502 assembler before (C64), but completely new to the BBC and Electron ecosystem at this stage

[Cybershark]

Yes, definitely a bit less long-winded than the route you were going before! Glad you found it useful

I took a stab at (visually) parsing the data of the first "base" cave but it's very minimal. Without understanding how the other objects are overlayed then there's not much to see - or that can be done with it!

Thanks for your breakdown of how that data is interpreted. I doubt I'd have ever cracked that myself!

First 5 bits are the number of ground squares
Next 3 bits represent the number of the last object which is translated:
0 = space, 1 = ground, 2 = wall, 3 = ground, 4 = diamond, 5 = boulder, 6 = firefly, 7 = ground

Any clue why there are 3 different values used for the dirt squares?

[raspberrypioneer]

That base display of the cave looks good! I went down a similar route using Excel/macros to get a visual from decoding the cave which helped work out where some of the other caves are stored.

I've not yet found where the extra bits are overlayed on top including the wall and all the extra boulders and diamonds for cave A for example. I found this resource http://www.gratissaugen.de/erbsen/BD-Inside-FAQ.html (for C64, Atari) which helped know what parameters are used and here it mentions something about decoding 'randomly placed' objects (those extra boulders etc). I think the random probability values will be the same on say the C64 version, so might be a lead in finding them on the Electron version. Tweaking these values could provide slightly different caves I think, adding to the base. I'll do some 'digging' there next.

Yes, I was surprised there were repeated ground/dirt values when this was decoded. I thought I'd see the other elements in there. I checked this by taking a value for a single element for simplicity and changing it, e.g. 5 = 00000 101 = 0 ground +1 boulder, making it a 6 becomes a firefly etc. I'm guessing some caves might vary this mapping or perhaps the randomly placed elements take care of the missing elements.

[Cybershark]

I've also been looking at a some of the resources available out there, with a view to better understanding the routines that generate the caves.

I'd been refering to this VIC20 disassembly which, as 6502 assembler, was something that I thought might have been used as a basis for the Acorn version, but I had no luck finding the code that should translate as a call to the line drawing routine for a line of bricks on cave 1: 42 01 09 1E 02. Even just searching for a byte pair of "01 09" or "09 01" - the start coordinates for the first line - yielded nothing. Hell, I couldn't even seem to locate the data values that specify what colours the caves should be!

Reading this article, by the creator of the Acorn version, sheds some light on the fact that it seems to bear no relation to the original. As with many such conversions, the author was, essentially, working in the dark.

The original "random" item generator seems like it should be easy to duplicate (based on its documentation) but I don't see how levels created in such a way could then be edited, as the elements generated in that way would always be locked in place. I guess you'd instead have to just reseed the generator until you came across an configuration that looked workable.

Found a Boulderdash clone written in Python too!

Here's the assembler:

Code: Select all

LDA RandSeed1
ROR
ROR
AND #$80
STA TempRand1
LDA RandSeed2
ROR
AND #$7F
STA TempRand2
LDA RandSeed2
ROR
ROR
AND #$80
CLC
ADC RandSeed2
ADC #$13
STA RandSeed2
LDA RandSeed1
ADC TempRand1
ADC TempRand2
STA RandSeed1
RTS

This confuses me because there is only one seed specified per skill level, isn't there? Where does a second come from, and what is it? The seed for level 2? Doesn't look like the other 3 seeds are used either. Rather odd.

Really wish we'd had the Construction Kit converted here, back in the day! Alternately, maybe we should just switch over to playing Repton instead

[davidb]

I vaguely remembered that the author of Boulder Dash for the Acorn machines wrote some comments on a YouTube video about how their version was written from scratch, then turned into an official "port" of the game.

This article by the author might explain a few things. (Found via this video of Boulder Dash on the Electron.)

[billcarr2005]

Convert hex value to binary value
First 5 bits are the number of ground squares
Next 3 bits represent the number of the last object which is translated:
0 = space, 1 = ground, 2 = wall, 3 = ground, 4 = diamond, 5 = boulder, 6 = firefly, 7 = ground
There are missing objects like the butterfly and amoeba and there is more ground than expected so there are probably bespoke routines to remap these values for some caves

I presume that the amoeba is the slime/fungus on screen M? I found that that appears as 7 on the map
Butterfly is 14
Cave E has an object number 11 which appears to join together in some way and then clear the area
Walls are added separately too, on Cave A
Seems as though the left and right of the cave is covered with the border too, ie 7 earth as the first object on Cave A, but only 6 shown
I've managed to intercept the Cave data just before the game begins, from &5040 to &5580, although after every 40 bytes, 24 are then skipped over
Intercepting the cave data slightly later fixes Cave E and also moves the firefly

[Cybershark]

I presume that the amoeba is the slime/fungus on screen M? I found that that appears as 7 on the map
Butterfly is 14
Cave E has an object number 11 which appears to join together in some way and then clear the area

That seems to make sense but, as RaspberryPioneer says, the data bytes don't seem to be broken into even nybbles - instead, there is a 5 bit/3 bit split, which seems to rule out the possibility of character values higher than 7?

Walls are added separately too, on Cave A
Seems as though the left and right of the cave is covered with the border too, ie 7 earth as the first object on Cave A, but only 6 shown
I've managed to intercept the Cave data just before the game begins, from &5040 to &5580, although after every 40 bytes, 24 are then skipped over
Intercepting the cave data slightly later fixes Cave E and also moves the firefly

Yeah, it's those later (rectangle and line) wall drawing routines that we're currently trying to identify - and what calls them.
Great screenshot maps there!

This article by the author might explain a few things.

Congrats, you just reposted the exact same article that I did

[davidb]

Congrats, you just reposted the exact same article that I did

Well, I was actually looking for the YouTube video. I'm not convinced that it's the one I was looking for.

[billcarr2005]

I presume that the amoeba is the slime/fungus on screen M? I found that that appears as 7 on the map
Butterfly is 14
Cave E has an object number 11 which appears to join together in some way and then clear the area

That seems to make sense but, as RaspberryPioneer says, the data bytes don't seem to be broken into even nybbles - instead, there is a 5 bit/3 bit split, which seems to rule out the possibility of character values higher than 7?

I think that during the various processing numbers must be changed?
The player becomes 8, Firefly is 54 (instead of 6), Butterfly is 46 (instead of 14) - curiously/coincidentally adding to 60! - and the outside edge appear to be 3

I had the following breakpoints when I whiled away the hours yesterday

2982 to save the cave layout before the walls had been added, ie just after the raw data had been processed around &2D55
2D44 for after the walls - was looking at data @ &4700 and then splitting the byte into even nybbles around &2D0A
2E3F for clearing the area on Cave E
2E70 had added the start location / player and end point

[raspberrypioneer]

Really interesting finds above! I had read that article where the developer Andrew Bennett explains some of the background to the development, but had forgotten about the pseudo random method bit. Perhaps if he had a better experience with Tynesoft, we wouldn't be doing this chat now! I did try emailing him on the crazy off chance he may still be on that email address and perhaps remember more. Alas no, it bounced!

I agree this likely means those algorithms used on the C64 for example won't apply that well or at all. I did find all the cave data in a C64 version, but the cave definition format is different in the Electron version and the values for the pseudo random stuff don't seem to apply (at least no pattern I could find). That link to the disassembly with comments looks interesting (I think it's C64), I imagine there should be some correlation in the Electron / BBC version for the game mechanics but not the cave setup.

@billcarr2005 - what tools are you using? I'm an Electron noob and don't follow some of what you've got there unfortunately? I think this could be a better way forward to figuring out how the caves are fully assembled (among other things). Any pointers, links etc will be welcome

For the program on disk MBOL2.$, so far I think is broken into these sections roughly (from trying to figure out where the caves were defined, a rough view of things).

$0 to $81F - the elements, e.g. diamonds, boulders are defined graphically
$820 to $EEF - main menu graphics
$EF0 to $1DEF - game main code
$1DF0 to $1EFF - uncertain, not code
$1F00 to $1FFF - labels for on-screen text
$2000 to $202F - more assembler code
$2030 to $28EF - title screen graphic of Rockford
$28F0 to $37FF - cave data - although cave A starts half way into this *
$3800 to $393F - cave parameters - number of diamonds needed, value, cave time
$3940 for 20 bytes - Looks like the cave sequence (mostly), not fully understood yet
$3950ish to $3CFF - unknown, maybe cave definition data *
$3D00 to $426F or so - screen labels for player, men etc
$4270 to end - unknown - maybe music, demo movements for Rockford

* Missing cave data here potentially? I'll probably go here next and see if I can make any sense of it

[Cybershark]

I think that during the various processing numbers must be changed?
The player becomes 8, Firefly is 54 (instead of 6), Butterfly is 46 (instead of 14) - curiously/coincidentally adding to 60! - and the outside edge appear to be 3

In the inflated version of the map, any values are possible. I have a nasty feeling there's no overall structure to this and there's just some really ugly "IF level=X THEN place Y and Z on it" instructions somewhere. That said, from the author's comments (in the linked article) I'd definitely expect something with a bit more finesse.

I agree this likely means those algorithms used on the C64 for example won't apply that well or at all. I did find all the cave data in a C64 version, but the cave definition format is different in the Electron version and the values for the pseudo random stuff don't seem to apply (at least no pattern I could find). That link to the disassembly with comments looks interesting (I think it's C64), I imagine there should be some correlation in the Electron / BBC version for the game mechanics but not the cave setup.

Actually, I have that very "pseudo random" code in play now. The initial seed value took a bit of tweaking - to offset the map items correctly - but it almost succeeds in correctly generating the first cave (at level 1). Don't get too excited about those two brick walls though, as they are just brute force PRINTed onto the screen after everything else

There are also a couple of glitches in the item generation as, for example, there should only be dirt in that top left square. Not sure what that's about!

$1DF0 to $1EFF - uncertain, not code

The initial execution address of the code is &1EC0 (although it could jump to anywhere from there).

[raspberrypioneer]

That is looking really close! Great to see most of the other missing elements now.

Did you use some of the values below in the randomiser? This is from the C64 version. I think the Electron version uses different values for a different algorithm, which might be hard to uncover - maybe the work billcarr2005 was doing might be a way to discover this?

Properties Cave A
$04 Initial randomiser seed value for difficulty level 1 $0a
$05 Initial randomiser seed value for difficulty level 2 $0b
$06 Initial randomiser seed value for difficulty level 3 $0c
$07 Initial randomiser seed value for difficulty level 4 $0d
$08 Initial randomiser seed value for difficulty level 5 $0e
$18 Random object number 1 $00
$19 Random object number 2 $10
$1A Random object number 3 $14
$1B Random object number 4 $00
$1C Probability of object 1 $3c
$1D Probability of object 2 $32
$1E Probability of object 3 $09
$1F Probability of object 4 $00

Thanks for the other info, I also wondered about the potential use of specific code to setup a given cave and/or level. This doesn't seem consistent with the comments by the author as you say, and the assembler found in the file seems pretty compact. It would be great to isolate the cave setup routines, perhaps replace them, which could open up the possibility of creating new caves!

[Cybershark]

Did you use some of the values below in the randomiser?

Yes, I did work from the C64 values - I used the initial (level 1) seed value of &A (10). I was confusing myself by looking for a second seed but that is generated in the first (and subsequent) code pass

Things didn't come out quite right at first - I could see familiar patterns in the items but they were offset wrongly on the level. By setting up a loop to dry run the (psuedo)RNG a few times then I was able to get them to position correctly. Then I was able to take that actual initial seed value and scrap the dry run segment.

Doing a bit more prodding and poking I was able to turn a couple of things up. I went searching through the code for the location of the start of cave data (using the value that you had provided - &306F). As the game code loads at &1300 then that start address becomes &436F, so that was the value I went looking for. My thinking was that there may be a whole lookup table for the other start values alongside it. I turned up something but I'm not sure what. It certainly looks like a list of points in the code but it really jumps around, bears no relation to the other start addresses you had identified and there are a couple of odd values in there too (which I have marked).

Code: Select all

436F
43D3
40BB
4321
C0EA ??????
432C
4219
445E
4354
4452
4279
4528
40B0
45CD
43DE
45E7
430F
465A
433E
4628

4000
00E7 ??????
4500
43B1
4100
00AC ?????
4107
4392
431B
4328
4069
3E28
40A1
3E28
40DA
3E28
4029
3F28
405E
3F28

Those are the values that are stored from &4CF5 onwards. There are precisely 40 of them - which tallies somewhat with there being 20 caves to the game.

In other news, I wondered if I could find any significance to the 3 codes for the exact same dirt. I was curious if the "random" generated items would overwrite all of them, and it seems that dirt type 7 does not get overwritten. I do still wonder what dirt type 3 is about and if it's a placeholder/trigger for the more exotic items - the butterflies and amoeba.

[billcarr2005]

Doing a bit more prodding and poking I was able to turn a couple of things up. I went searching through the code for the location of the start of cave data (using the value that you had provided - &306F). As the game code loads at &1300 then that start address becomes &436F, so that was the value I went looking for. My thinking was that there may be a whole lookup table for the other start values alongside it. I turned up something but I'm not sure what. It certainly looks like a list of points in the code but it really jumps around, bears no relation to the other start addresses you had identified and there are a couple of odd values in there too (which I have marked).
.

So far as I can tell, for Cave A, &5040 - 5580 is made 01 (all earth) (with the good data of 40 bytes followed by 24 junk data in every 64)
Then the lookup table begins at &4CF4, so includes 43 9D

The &43 is then used as an offset for the cave generation to start at 5043
&4E is used with the 9D to create another index at &4E9D

200 bytes (&C8) are then used to create a basic cave, which appears to have similarities with the final cave A

&436F-43BB is then used to add the earth, diamonds, boulders in other places

&4CA4 - 4CB7 Colour 1 for caves A-P
&4CB8 - 4CCB Colour 2 for caves A-P
&4CCC - 4CDF Colour 3 for caves A-P

Only the low part of the byte are used

[billcarr2005]

I've managed to achieve some automation, at least for Cave A

Routine at &2D95 using data from &4E9D (200 bytes) gives the basic cave

Routine at &2D55 using data from &436F (75 bytes) adds some details

At &4CF4 we have &9D (low byte, +&4E to make &4E9D for the basic cave - there seems to be a shared bit of data here which can overlap to create different caves)
&4CF5 = 43 (low byte, +&50 to have the starting offset of data)
&4CF7 + 4CF6 = &436F, start of details
&4CF8 = D3
&4CF9 = 40
&4CFB + 4CFA = &43bb, end of details

Wall routine is at &2D00, using data from &4700 for Cave A
I noticed when adding breakpoints that the routine at &2D55 to add details is never called for some caves (cave C,E,F amongst others) i suppose this is because the basic cave does the job.

Changing &4C68-4C77 all to 1 allows all caves to be accessed
Altering &321E to &33 means you have just 1 life, so ESCAPE returns to the title page quickly.

[raspberrypioneer]

Wow that's some good progress! Feels like a convoluted way to build a cave but it looks like you're not far off unlocking how it has been done - for Cave A at least - hopefully the others follow a similar pattern.

I had a fiddle with the addresses you provided to change the colours. Can disorientate you a bit if used to the standard ones! Great to have that option. Access to all caves is a must have in my hacked version! Thanks for finding that

[Cybershark]

&4CA4 - 4CB7 Colour 1 for caves A-P
&4CB8 - 4CCB Colour 2 for caves A-P
&4CCC - 4CDF Colour 3 for caves A-P

Only the low part of the byte are used

Nice find on the cave colours! I had gone looking for those but was unable to turn them up, and now I can see why
Can confirm that it's down to the low 3 bits, and also that the high bits in each case should not be disregarded. Messing with them (somehow) causes changes to the cave generation.

Changing &4C68-4C77 all to 1 allows all caves to be accessed
Altering &321E to &33 means you have just 1 life, so ESCAPE returns to the title page quickly.

Those are some handy hacks! Bravo again.

Feels like a convoluted way to build a cave but it looks like you're not far off unlocking how it has been done - for Cave A at least - hopefully the others follow a similar pattern.

Yeah, it's a ridiculously layered approach. "Fun" as it's been to try to disentangle, I'd only been looking at this with a view to being able to edit the existing cave layouts - or create new ones - but that now seems unfeasibly difficult, so I think I'm out of that endeavour.

I presume that the Boulder Dash sequels (that tied to the Construction Kit) used a more straightforward data storage method. Shame they never got converted - perhaps someday!

[billcarr2005]

Can confirm that it's down to the low 3 bits, and also that the high bits in each case should not be disregarded. Messing with them (somehow) causes changes to the cave generation.

The lower 3 bits are used in the basic and details part of the map generation, the walls section requires some more, 14 being a magic wall

I've now got my map maker (in BBC BASIC for Windows) finding the data directly from the SSD and have discovered that Cave E, J and N don't use basic or details routines, it's all done in the 3rd procedure (walls section). Also added the start and end locations on the map.
I don't think there's any way, at least that i've been able to discover, to change the colour of tiles in BBCB4W so maps are currently in the colour scheme of Cave A
As can be seen from Cave A-E below, C and D using the same basic layout, but C doesn't add any details. Vertical walls aren't added yet

I've also added a map of Cave A with the offset at 0 - rather than 3 - but with the same details to show how a different cave can be quickly created, so perhaps with a mixture of offsets / details / walls with edits at the data around &4CF4, it would be possible to add some playable differences

[raspberrypioneer]

Looking pretty close on some of the other caves now! I like the maps especially now that they show the start and end tiles, and Rockford too. It's handy to see the whole thing on one image to help plot a way through.

I wondered how feasible it would be to split the cave generation from the game mechanics? If the cave generation was closer to the 'Boulder Dash Common File Format', it should be more editable I think. There also seem to be many designs which others have made to tap into.

[Cybershark]

I wondered how feasible it would be to split the cave generation from the game mechanics? If the cave generation was closer to the 'Boulder Dash Common File Format', it should be more editable I think.

Definitely feasible! But would be a damn sight easier if we had access to the Beeb source code or a full disassembly of it. Could always mention it to Level 7 and see if they're interested (see here).

The front-end and gameplay are sound enough, so it'd then "just" be a case of coding new cave generation routines based around ...some new level data format?

The "randomly" generated approach of BD1 caves doesn't seem amenable to any sort of useful modification but I presume the later games in the series must use a more sensible format (to allow them to be edited in the Construction Kit). Would be interested to learn more about how the caves for the sequels are stored and generated.

[billcarr2005]

The "randomly" generated approach of BD1 caves doesn't seem amenable to any sort of useful modification but I presume the later games in the series must use a more sensible format (to allow them to be edited in the Construction Kit). Would be interested to learn more about how the caves for the sequels are stored and generated.

I would think that having a nybble approach per block would work since there are less than 15 block types, but then it would be difficult to store 16 levels x 400 bytes (width is internally 40, despite only 38 being displayed - allows for the exit to be in the outer wall), but having the program load a level each time would be simple - I was thinking about the feasibility of this just yesterday!
The bulk of the cave generation is in a subroutine @ 2900, then creating a blank level, which I discovered doesn't need to be all earth, cave I begins with all boulders with everything added on top.
2D90 creates the basic
2d50 adds details (where the blocks can vary depending on the content of 73-75), the high nybble of the colour bytes are used to decide which 3 blocks
2d00 adds simple walls
2404 is called twice, with modifications, to add vertical and horizontal walls

After this - 2404 calls some additional routines to add space around butterflies, etc. then the cave is complete. It's at this point that the cave is complete-ish so these routines could all be skipped and another loaded / split into full bytes.
I'm fairly confident these Caves are drawing correctly now

Cave B

Cave C

Cave D previously had too many boulders, until the detail routine replaced everything with earth

Cave I

[billcarr2005]

After getting stuck with why some items disappear on the map program, I looked into the idea of cave replacement.
Some marginal success with the loading of caves, I've got A, B, C, D and E saved as individual files, loading as necessary - cave storage / retrieval works fine

[TobyLobster]

If no-one else is doing so, I started making a disassembly (using the the version from http://bbcmicro.co.uk/game.php?id=669)

https://github.com/TobyLobster/Boulderd ... __1___.asm

I've not got far with the level decoding routines yet though, so any info appreciated.

[raspberrypioneer]

Fantastic work billcarr2005 ! The caves as individual files / retrieval idea sounds like it should really open the game up for slotting in new caves! Are you going ahead with the nybble per block approach, perhaps with an initial parameters section for cave times, diamonds needed etc? That would seriously get into construction set territory and allow tapping into other good designs found on sites like https://www.boulder-dash.nl/ (would need to be for the BD1 engine of course).

I wonder how closely related the BBC and Electron versions are? Maybe some useful spin-offs here for the BBC version.

[Cybershark]

The caves as individual files / retrieval idea sounds like it should really open the game up for slotting in new caves...

...would need to be for the BD1 engine of course.

Yes, while reading up on the subject I discovered that - in the later games - it's possible to interact with an adjacent square without moving the character. Obviously any level that requires this functionality would be of little use.

If no-one else is doing so, I started making a disassembly (using the the version from http://bbcmicro.co.uk/game.php?id=669)

https://github.com/TobyLobster/Boulderd ... __1___.asm

I've not got far with the level decoding routines yet though, so any info appreciated.

That's great news. You'll probably pick up quite a bit from Bill's insights in this thread