thats one of the strangest games I'd think to see mapped errm.. knowing how many tiles to map for a start.. it's not like it's static , which is the other thing that comes to mind.
it's probably stored in groups of 5 for the tiles or a few patterns ? e.g. chequered pattern for 4 lines.
The byte map for the 14 zones starts at $6590; each zone ends with $FF. Changing $87D3 LD (HL),$00 to LD (HL),$38 and setting a break point at $8900 (the end of the print routine starting at $8897) shows the way in which the scrolling display is constructed. Each byte in the map represents a specific horizontal combination of five tiles so, although there are only five tiles (plus no tile) there are many more than six distinct values used in the map definition. This can be confirmed by slowing down the emulator so that the rows of tiles can be counted and their pattern noted.
In this table the size is in decimal and excludes the $FF delimiter, so it shows the tile length of each level.
LEVEL AT SIZE TITLE
A $6590 219 Easy Going
B $666C 227 Wooly Jumper
C $6750 220 Terry's Test
D $682D 279 Pete Street
E $6945 326 Hackers Evil Holes
F $6A8C 371 Greg the Nipper
G $6C00 319 Shaun not Sean!!
H $6D40 335 Jason's Jumpabout
I $6E90 335 Mark's Motorola
J $6FE0 155 Chris's Cul-de-Sac
K $707C 115 Well I Never
L $70F0 175 Shriggles's Shriggle
M $71A0 175 Boing Boing Splat!!
N $7250 239 Last But Not Least!
. $7340
The byte map for the 14 zones starts at $6590; each zone ends with $FF. Changing $87D3 LD (HL),$00 to LD (HL),$38 and setting a break point at $8900 (the end of the print routine starting at $8897) shows the way in which the scrolling display is constructed. Each byte in the map represents a specific horizontal combination of five tiles so, although there are only five tiles (plus no tile) there are many more than six distinct values used in the map definition. This can be confirmed by slowing down the emulator so that the rows of tiles can be counted and their pattern noted.
Now all I have to do is decode what those values mean. I assume it's not just a simple bitpattern - it must be a "library" of types. Interestingly, I can see that normal tiles can be one of two types (in order to make the "checkerboard" effect visible at the start/end of the levels) and the special tiles - bounce, slow, sticky etc - only have one type each AFAICS.
If you:
* create a 256-byte string containing ascending values 0-255
* load the string into the level D byte map at $682D
* select the 3-course test option with D as the first course
* enter these POKEs: infy jumps 35499,0; infy time 36745,201
* enter this bit of assembler
org $88FC
jp $FAE0
org $FADF
COUNT10:defb $01
COUNT: ld ($84C9),iy
ld a,(COUNT10)
and $0F
jr nz,COUNTGO
ld bc,0000
COUNTHL:dec bc
ld a,b
or c
jr nz,COUNTHL
COUNTGO:inc a
ld (COUNT10),a
ret
Then you can play the game and step through all the possible combinations of tiles. (You might want to increase the pause interval.)
There are quite a lot of patterns which aren't used, namely:
1A 1C 20 21 2A 2E 30 31-33 41 62 63 66 6A 6B 6E 70 71 73 75 77-7E 83 86
8B-94 97-99 9F A1 AE-FE
OK, I've got a new routine which runs 255 times and sets the whole of the level to the same pattern. The baseline pattern dimensions are:
(64 + 42 + 44 + 42 + 64) wide * 24 high
In order to avoid making the maps too immense, and to make things easier by fitting each tile on byte boundaries, I was going to reduce them to:
(24 + 16 + 16 + 16 + 24) wide * 16 high
So, for each tile pattern in turn I cut out a plain rectangle of those dimensions from the middle of each of the five tiles, stick them together and save them, ending up with 255 tile permutations coded $00-$FE. Then I just set SP to the base of each of the 14 byte maps in turn, POP each code off the stack and print that pattern, stop at $FF, then do the next one.
Except, that wouldn't work, because ...
An as yet unresolved problem is that I can only fit 12 rows of tiles on the screen at once and, given that each row is 12*16=192, and that makes the pattern look-up table 48960 bytes, I couldn't even fit the look-up table into RAM, let alone one of the maps as well. The only way I can see it working is a 2-disk solution on the +3. With 255 pattern files on one disk (one less than the maximum) and one map file on the other disk (the largest being 71232 bytes) - unless someone else has a better idea.
Running this snapshot with this TAP file will print a mini-map for Zone A; just press Enter to make it scroll. I've just got to change it to stop each time the screen is full, save it, then I can convert them to GIFs and stick them together. It turned out that the only data which I needed in memory was the byte maps, so I could do it all on the 48k with TAP files.
(I've updated the snapshot to include the extra commands.)
The size of the tiles for a map is a balance between making them small to see a bigger segment of the map in one go and making them big for a clearer picture.
The TEZ in Zone C is probably short for Terrence or Teresa, as the zone is called Terry's Test.
There's also a HELEN mentioned in Zone M.
As I composed it for future reference, here's a summary of the steps involved in making the maps.
* Having found the zone map data and determined its structure ...
+ Save the map data in Trailblazer-bytemap.
* Make Trailblazer-dumps.Z80 from Trailblazer to create Trailblazer-patterns
+ $873B-$873F
+ start of dump loop, ($6590) is first byte of Zone A bytemap
+ $8796-$87B3
+ reset counters, fill Zone A bytemap with current pattern ID
+ discard level increments & end of game checks
+ $87E9-$87EE
+ disable ball display
+ $87FE-$880A
+ end of dump loop, call DUMPS routine, pattern IDs >=$AE not used
+ assemble DUMPS at 25409
+ DUMPS constructs a small rectangular version of each 5-tile pattern and saves it to tape
* A separate program SAVEMAP to:
+ Build a zone map from a bytemap loaded at 26000 from Trailblazer-bytemap
. and patterns in Trailblazer-patterns; save in map?.TAP.
+ Use SpecEmu as it will automatically loop around and continue reading when
. it gets to the end of a TAP file.
+ RANDOMIZE USR 23489
* A separate program PRINTMAP to:
+ Print Zone ? from map?.TAP
+ The "**********" is to mark the top of the last full page printed,
. as the last page is always short.
+ Save each SCREEN$ GIF at WAIT_KEY1.
+ INPUT "INK=";i,"PAPER=";p: INK i: PAPER p: POKE 23624,PEEK 23693: CLS:
. RANDOMIZE USR 30000: PAUSE 0
* To finish:
+ Paintshop batch job: crop each SCREEN$ to middle 96 pixels.
+ Paintshop: crop last SCREEN$ to remove anything left from previous page.
+ Irfanview: use "panorama" feature to join segments into full map.
Didn't have a page long enough :-D Great work to those who made the effort with that one!! Yes it is fascinating seeing it from above I keep looking for "hidden" graphics. Crumbs, is there any other games still not mapped?
Dunny just asked for the maps - if playing the game had been required to produce them then I'd have no chance with that sort of game - but hacking the code to dump out the map data, that I can do. I didn't even play Level 1.
Couldn't he just DL/view them from the thread like the rest of us? Or what do you mean?
The previous couple of posts had implied some game-playing skill had been employed to produce the maps. I was just pointing out that I'd employed no such abilities (not being possessed of them) and that I'd just delved into the game code & data to extract them.
Comments
it's probably stored in groups of 5 for the tiles or a few patterns ? e.g. chequered pattern for 4 lines.
check out 50 seconds in
http://www.youtube.com/watch?v=Ub9V59w63mY
I've also made a video from the RZX. What a bloody rock hard game. Used approx. 50 billion rollback points when making the RZX.
Here's the byte map for level A.
In this table the size is in decimal and excludes the $FF delimiter, so it shows the tile length of each level.
Thanks for that :-)
Now all I have to do is decode what those values mean. I assume it's not just a simple bitpattern - it must be a "library" of types. Interestingly, I can see that normal tiles can be one of two types (in order to make the "checkerboard" effect visible at the start/end of the levels) and the special tiles - bounce, slow, sticky etc - only have one type each AFAICS.
Let's see what we can come up with!
D.
shaun southern (he of kikstart 1/2 also :D) ... the c64 version / atari 8 bit versions are better.. only due to the colour aspect of the road.
the best 8 direction scrolling of this sort I guess is ballblazer on 8 bit atari , using the same effect
* create a 256-byte string containing ascending values 0-255
* load the string into the level D byte map at $682D
* select the 3-course test option with D as the first course
* enter these POKEs: infy jumps 35499,0; infy time 36745,201
* enter this bit of assembler
org $88FC jp $FAE0 org $FADF COUNT10:defb $01 COUNT: ld ($84C9),iy ld a,(COUNT10) and $0F jr nz,COUNTGO ld bc,0000 COUNTHL:dec bc ld a,b or c jr nz,COUNTHL COUNTGO:inc a ld (COUNT10),a retThen you can play the game and step through all the possible combinations of tiles. (You might want to increase the pause interval.)
There are quite a lot of patterns which aren't used, namely:
1A 1C 20 21 2A 2E 30 31-33 41 62 63 66 6A 6B 6E 70 71 73 75 77-7E 83 86
8B-94 97-99 9F A1 AE-FE
(64 + 42 + 44 + 42 + 64) wide * 24 high
In order to avoid making the maps too immense, and to make things easier by fitting each tile on byte boundaries, I was going to reduce them to:
(24 + 16 + 16 + 16 + 24) wide * 16 high
So, for each tile pattern in turn I cut out a plain rectangle of those dimensions from the middle of each of the five tiles, stick them together and save them, ending up with 255 tile permutations coded $00-$FE. Then I just set SP to the base of each of the 14 byte maps in turn, POP each code off the stack and print that pattern, stop at $FF, then do the next one.
Except, that wouldn't work, because ...
An as yet unresolved problem is that I can only fit 12 rows of tiles on the screen at once and, given that each row is 12*16=192, and that makes the pattern look-up table 48960 bytes, I couldn't even fit the look-up table into RAM, let alone one of the maps as well. The only way I can see it working is a 2-disk solution on the +3. With 255 pattern files on one disk (one less than the maximum) and one map file on the other disk (the largest being 71232 bytes) - unless someone else has a better idea.
Use the program as normal but ignoring the perspective and use the whole screen rather than just the bottom third.
Once you get the idea up 'n' running you can resize to suit.
A packet of rolos to the person that does the overhead view of this game ;)
INK 5: PAPER 0: CLS: POKE 23624,PEEK 23693: RANDOMIZE USR 30000
(I've updated the snapshot to include the extra commands.)
The size of the tiles for a map is a balance between making them small to see a bigger segment of the map in one go and making them big for a clearer picture.
--
Here's the assembled Zone A map.
Zone A - Zone B - Zone C - Zone D - Zone E - Zone F - Zone G
... and here's the second half of the maps ...
Zone H - Zone I - Zone J - Zone K - Zone L - Zone M - Zone N
Now, if some kind soul would assemble the unscaled maps together... ;)
SHAUN,TEZ (TEN?), PETE, CHRIS, BOING!, GREG, HELLO!, GREMLIN, SHAUN IS CHEESED OFF, HARD EH?, OUCH and THE END.
The 11th level seems to be the smallest of the lot.
Good work BB!
Bytes:Chuntey - Spectrum tech blog.
There's also a HELEN mentioned in Zone M.
As I composed it for future reference, here's a summary of the steps involved in making the maps.
I don't think I ever made it past level 2 at the time. "SHAUN IS CHEESED OFF" - ha!
Doffing my cap in the general direction of the talented/patient/OCD folk out there ;)
Couldn't he just DL/view them from the thread like the rest of us? Or what do you mean?
The previous couple of posts had implied some game-playing skill had been employed to produce the maps. I was just pointing out that I'd employed no such abilities (not being possessed of them) and that I'd just delved into the game code & data to extract them.
http://www.zx-spectrum.cz