5 replies to this topic

[4ever2600]

Just for curiousity, why would one want to change Low Byte, High Byte room data in Adventure? What purpose does it serve in the first place? As always, any help is appreciated in advance... - D

[Nukey Shay]

What tags are you referring to? Some of them are in there for the program to function correctly. In other words, let's say that a room begins at label LFD00...and that label is stored in another table that is used by the display kernal as low byte (<) and high byte(>). Then when the game kernal is looking at that table, it can grab those values, stick them in ram, and use indirect LDA ($nn),y addressing to fetch the actual data for the room.
The reason that anything is marked as tags instead of actual addresses is that it makes it easier to move things around while the program is being assembled. Dasm will interpret these tags and labels into the correct addresses on pass2.

What tag?

[4ever2600]

In the below data, offset 0 and 1 = low and high byte room graphics data... In the example below that, the CE and FB represent the low and high. What in THIS example is the data doing?

;Room Data
;Offset 0 : Low byte room graphics data
;Offset 1 : High byte room graphics data
;Offset 2 : Colour
;Offset 3 : B&W colour
;Offset 4 : Bits 5-0 : Playfield control
Bit 6 : True if right thin wall wanted
Bit 7 : True if left thin wall wanted
;Offset 5 : Room Above
;Offset 6 : Room Left
;Offset 7 : Room Down
;Offset 8 : Room Right

FE75 CE,FB,08,08,25,03,09,09,09 ;0A;

Maze Entry Invisible Reflected/Playfield Priority

[Nukey Shay]

Heck, are you STILL using the old VGR code?? There is a better version that the guys fixed up and saved a lot of memory (search for Adventure+Optimized).

Anyway, a source code will contain the labels in a table for the various rooms. The labels in the table point to the data for a particular room...let's call it LFE75 and assume that it holds the above data at that address. So the program grabs the first byte there, $CE, and drops it into a ram location...let's call it R1. Then the program grabs the second value, $FB, and plunks it into an adjacent ram location - $R2. Now when the kernal needs the pixel data for the room, it just uses the Y register as an offset to point to the data line that it is currently drawing, and LDA ($R1),Y will grab the byte that it needs.

In the optimized source code, that CE and FB have both been changed into labels...so if you add program instructions or data tables, etc., it will point to the correct address when it's compiled.

Again, this is not data that you (as the programmer) even needs to worry about. You just need to make sure that the data line is containing the correct < and > labels in it. In the optimized code, you'll see lines like...
.byte Yellow_Castle,$00,$00,$00...etc.
(actual data not used because I was too lazy to look them up)

Then when Dasm compiles the code for you, it checks it's list of indexes when it reaches that line...

"Hmm...The tag Yellow_Castle is now at address $FD00..."

...and it puts the correct values into the line...
.byte $00,$FD,$00,$00,$00...etc.

[Nukey Shay]

Optimized code here:
http://atariage.com/...ad.php?id=13519

Be sure to change this line in the optimized red dragon routine...

MoveRedDragon: 

       LDA    #<RedDragMatrix 

       LDA    #$03

That LDA #$03 should be changed to LDY #$03 instead. I dunno if it was updated already.

[4ever2600]

Actually, I am using both now, regular and optimized... : ) But I was just more curious about the theory of WHY someone would ever mess with low/high. You know, what is it doing there and why would I ever try changing it.. But as always, you did answer my questions, it's all good now. I'm just trying to do certain things to pull off other things and TONS of ideas are jumping into my head, I just need to make sure that I understand some of it as I go... You've been a great help as always... Thanks again! - Daryl