NODES OF YESOD DATA FORMAT
this document contains the data format for nodes of yesod, it is not complete but gives a good start and understanding. for futher information download nodes of yesod  source this may help fill in some of the blanks. should you find any errors with this document or indeed have any information to add, please send me an email.

 

i have written a nodes of yesod viewer which uses all the below information. you may find looking at the source of that if far more understandable than this description!

 

the game locations are played on a 16*16 grid
location 0 is the top  left corner of map
location movement is implicit by adding to the location no depending on direction ie: +16 north, -16 south, -1 west, +1 east
if you have the crash map it is worth noting that their location [a,1] is not the actual [0,0]. it starts at [a,4]

 

address 0x8982 starting locations of required alchiem
a 4 byte table that holds the location of the alchiem required to finish the game. which ever location is picked, the monolith will be in the location directly underneath.
type offset description
byte 0 location

 

address 0xb500 location graphics and border
a 256 byte table that holds the Platform Graphic Set and the Border type for each location. Access by location no.
type offset description
byte 0
set border
7 6 5 4 3 2 1 0
Set - Platform Graphics Set
Border - Border Style

 

address 0xb600 loc misc flags
a 256 byte table that holds various flags  for each location. Access by location no.
type offset description
byte 0
oa o al el sf e ed
7 6 5 4 3 2 1 0

The edible wall flag is for the right hand wall only. The left hand wall is checked by looking at the data of the location to the left.

 ed - edible wall is open
e - edible wall in left border
sf -  fall through in middle of floor
el - extra life takes in object position
al - alchiem no in location
o - alchiem currently in location
oa - alchiem/extra life allowed in location
0 1 2 3 4

 

32 objects as placed randomly on the map using object=(count*2)&0x30
and then 6 extra lives. it is done somthing like.

	count = 32;
	while ( count ) {
		loc = randomobjectlocation();
		objdata[loc] |= (count*2)&0x30;
		count--;
	}

 

address 0x5d68 location object coordinates
this is a packed table that only has a byte per location that could hold an object. 45 in all. to find the required byte you have to step through it by referencing table 0xb600.
type offset description
byte 0
x y
7 6 5 4 3 2 1 0
y - y coordinate * 8
x - x coordinate * 16		 
    if ( BIT7(specmem[0xb600+room]) == 0 ) 
        return; // the room can't hold an object?
    u8* data = &specmem[0x5d68];
    u8* rooms = &specmem[0xb600];
    for ( int ii=0; ii<=room; ii++ ) {
        if ( BIT7(*rooms) ) data++;
        rooms++;
    }
    // data now points to required byte

 

address 0x62ac platform graphic sets
the table holds the information about the platform graphics sets. entries 0-3 are the platform graphics and entry 4 is for general display graphics.
type offset description
word 0 pixels - ptr to actual pixels to draw
word 2 block makeup -

address ???? block makeup data
this table holds the block makeup of bigger graphics. the table must be traversed until the required graphic is located.
type offset description
byte 0
width height
7 6 5 4 3 2 1 0
w - width in bytes ( 8x8 pixels )
h - height in bytes ( 8x8 pixels )
byte 1
r graphic
7 6 5 4 3 2 1 0
graphic - graphic to draw
r - reverse. draw this block reversed

 

address ???? pixels
type offset description
byte 0..7 bytes of pixel data
if the graphic set is 0-3 then the following byte is used.
byte 8 attribute

 

address 0xb700 player sprite table
offset for each frame of the player sprites. 41 frames.
type offset description
word 0 offset to sprite frame

 

address 0xc700 other sprites table
offset for each frame of the other  sprites. 112  frames.
type offset description
word 0 offset to sprite frame

 

address 0x5b54 location objects sprites table
offset for location object sprite. 5 frames.
type offset description
word 0 offset to sprite frame

 

address ???? frame data
type offset description
byte 0 width, this is given in actual pixels so must be rounded to the nearest 8 in order to give width in bytes.
byte 1 height
byte 2 attribute
byte 3... data

 

address 0xa299 mole location table
this 6 entry table holds the possible locations of the mole. there are two possible coordinates that the mole can appear at in the given location.
type offset description
byte 0 location
byte 1 x coordinate 1
byte 2 y coordinate 1
byte 3 x coordinate 2
byte 4 y coordinate 2

 

address 0xa2b7 mole animation table
this table looks like it holds the animation sequence for the mole.

 

address 0x5e2c top border mask table
9 entries of possible top border makeup.
type offset description
byte 0
0 1 2 3 4 5 6 7
7 6 5 4 3 2 1 0

 

address 0x5e35 bottom border mask table
13 entries of possible bottom border makeup.
type offset description
word 0
0 1 2 3 4 5 6 7
F E D C B A 9 8 7 6 5 4 3 2 1 0

 

address 0x5e4f border data
this table holds all the border makeups. the table must be traversed to locate the required border.
type offset description
byte 0
BM B R L T
7 6 5 4 3 2 1 0
BM - bottom mask
B - bottom border
R - right border
L - left border
T - top border
if topborder
byte 0
g ? border mask
7 6 5 4 3 2 1 0
border mask - bottom mask
? - unused
g - graphic for top left corner. ( -16, 0 )
word 1
0 1 2 3 4 5 6 7
F E D C B A 9 8 7 6 5 4 3 2 1 0

using the mask from the from the Border Top Mask Table draw the graphics according to the relevant 2 bits from this word. ( bottom_solid_mask )
if leftborder
byte 0
0 1 2 3 4 5 6 7
7 6 5 4 3 2 1 0

draw 7 platforms down the screen starting at (0,0) using the graphic 4 + bit y from the above mask.
if rightborder
byte 0
0 1 2 3 4 5 6 7
7 6 5 4 3 2 1 0

draw 7 platforms down the screen starting at (240,0) using the graphic 6 + bit y from the above mask.
if bottomborder
byte 0
0 1 2 3 4 5 6 7
7 6 5 4 3 2 1 0
if bottommask == 0
draw 8 platforms across the screen starting at (0,152) using the graphic 8 + bit x from the above mask.
lookup the bottom mask from the bottom border mask table.
draw 8 platforms by using the 2 relevant bits from the mask.		 0 - do nothing
1 - draw graphic 8 + bit x from BOTTOM_SOLID_MASK
2 - draw graphic    0x0a
3 - draw graphic    0x0b

 

address 0x5fa6 locations 0 - 15 data
these above ground locations are handled differently the below ground levels. traverse the table to find the location.
type offset description
byte 0
byte 1
craters bottom mask
7 6 5 4 3 2 1 0

using the bottom mask draw 4 graphics using 4 + bit x startting at ( 0, 144 )

 craters - total craters on level
bottom mask - masked used to draw bottom border.
word 2
0 1 2 3 4 5 6 7
F E D C B A 9 8 7 6 5 4 3 2 1 0

using the mask from the from above. draw 8 graphics using the two relevant bits. starting at ( 0,48 )
for each crater
byte 0
x y c
7 6 5 4 3 2 1 0
c - graphic type, 6 or 7
y - (y coordinate+11)*8
x - (x coordinate*16)

 

address 0xdbff locations 16-256 data
holds the platform data for locations. the table must be traversed to locate the required location. it is a series of two byte entries.
type offset description
byte 0
s e x
7 6 5 4 3 2 1 0
s - start of new location
e - room empty?
x - x coordinate
byte 1
y platform
7 6 5 4 3 2 1 0
y - y coordinate + 4
platfrom - platfrom graphic from the current block data
the sequences are access until s bit is set.

 

address 0xaaed moving nasties table
this 94 entry table holds the information about the wandering nasties in the game. ie: not the random location generated ones. entry 91 is the space ship, entry 92 is the required alchiem to finish the game, entry 93 is the monolith.
type offset description
word 0 offset into sprite info block
byte 2 location
byte 3
frame frame inc
7 6 5 4 3 2 1 0
byte 4 x coordinate
byte 5 y coordinate
word 6 working copy of 0?

 

starting values use for sprite info block

0xae7f
0xae9a
0xb484
0xb3fc

0xafd5
0xafa0
0xb3b8
0xb440

0xaddd
* 0xade2
0xade6

*this is actually changed to represent the alchiem needed to finish the game

 

address 0xaddd sprite info block
this is a strange table. the first byte is the graphic no ( use in the OtherSpritesTable ) the rest of the data control animation etc. it seems to have the odd word address that points to other blocks in the table or back to the same block.
type offset description
byte 0
r sprite no
7 6 5 4 3 2 1 0
r - reverse graphics
sprite no - sprite to use from OtherSpriteTable
byte 1 unknown sequences