40 replies to this topic

[4ever2600]

Hello Everybody!

I'm trying to change/ add an object in adventure (say the magic dot) into a weapon

LF832: STX $9A
LDX $A0
JSR LF6FE
LDX $9A
CMP #$51 - If the sword (#$51) hits dragon, jump to 'kill' routine
CMP #$87 - I added this line to make the dot (#$87) kill the drag
BNE LF84B
LDA #$01
STA NUSIZ0,X
LDA #$03
STA $E0
LDA #$10
STA $DF

But the problem is, when I add this and recompile, it messes up the game big time... I also took away the extra 2 bits at the end to keep it a 4096 k file... Believe me, what I did just seemed to make sense... : ) But I also tried using this, CMP #$51,#$87, that didn't work either...

Or am I just living in a programmer's dream world? Could someone tell me if what I'm trying to do takes ALOT more programming, or just something simple? Thanks! - Daryl

[Robert M]

4ever2600 said:

Hello Everybody!

    I'm trying to change/ add an object in adventure (say the magic dot) into a weapon

LF832: STX    $9A      
      LDX    $A0      
      JSR    LF6FE    
      LDX    $9A      
      CMP    #$51  - If the sword (#$51) hits dragon, jump to 'kill' routine
      CMP    #$87 - I added this line to make the dot (#$87) kill the drag
      BNE    LF84B    
      LDA    #$01    
      STA    NUSIZ0,X
      LDA    #$03    
      STA    $E0      
      LDA    #$10    
      STA    $DF      

But the problem is, when I add this and recompile, it messes up the game big time...  I also took away the extra 2 bits at the end to keep it a 4096 k file...  Believe me, what I did just seemed to make sense... : )  But I also tried using this, CMP #$51,#$87, that didn't work either...  

Or am I just living in a programmer's dream world?   Could someone tell me if what I'm trying to do takes ALOT more programming, or just something simple?  Thanks! - Daryl

Okay, their are two problems with the change you made. First, you can't put another CMP instruction immediately after the first. When you do, the processor "forgets" the results of the first compare instruction. You need to put a Branch test after each compare like this:

CMP #$51 - If the sword (#$51) hits dragon, jump to 'kill' routine
BNE LF84B
CMP #$87 - I added this line to make the dot (#$87) kill the drag
BNE LF84B


The other problem is you can't just delete bytes from the end of the new file to make it 4096 bytes long. By doing so you probably deleted the address that the processor uses to know where to begin executing the code. Another problem with adding code is that it can rearrange where graphics are located in memory. That can destroy the game timing because the processor may need to start crossing page boundaries to read graphics data. Doing so slows the processor down, which means it can't draw as much as it needs to to properly draw the screen.

If you want to alter the code, you must first make sure that your changes won't move the graphics from their original positions, or else you will need to change the code to account for the moved graphics (not a trivial task). To do this compile the original file and produce a list file using the -l option on the command line. Look in the list file and see what addresses the various graphics are located at. Then go back into the code, and add an ORG statement before each section of graphics data to lock it location in memory in place like this:

ORG

spritestable
.byte $00,$01...yada yada yada

Now that you have locked the graphics in place. You need to find free space so you can insert your new code. I don't know if there is any unused space in the Adventure ROM. The best place to look again is in the list file. Hopefully the free space (if any) will be in a place that will not require you to move the graphics to get it into the region of space in the ROM where your additional code can expand into it.

Here is another alternative. If you can reorder the objects in the game so that all the items you want to have be able to kill a dragon have the highest code values or the lowest code values, then you can make the change without needing to add any bytes of code. I am of course assuming that no where in the code it takes advantage of the objeect order in the same manner I am about to demonstrate.

Assuming the dot and sword are the lowest numbered objects, say $00 = dot, and $15 = sword, then

LDX $9A
CMP #$16 - If the sword $15 or dot $00
BMI KillDragon

Of if they are the highest object values:
LDX $9A
CMP #$6E - If the sword $6E or dot $7D
BPL KillDragon


I just noticed in your code snippet above you used the BNE instruction after the comparte. If LF84B is the location of the routine to kill the dragon, then you should be using BEQ not BNE. If by NOT branching falls through to the routine to kill the dragon then BNE was correct.

Regards,
Rob

[Nukey Shay]

He's using the optimized version of Adventure IIRC.

Just bump down the number of bytes shown in the .ds line near the end of the file by how many bytes' worth of instructions you add. Using the above correction, you would need to bump this number down by 4 (2 bytes for the CMP, and 2 bytes for the branch). The assembly file is pretty much relocatable...except for a few routines/tables that require to be on or above page breaks.

Another thing to watch out for is that ALL conditional branch instructions (most that begin with the letter B) can only jump 128 bytes backward or forward. By adding instructions, you might make the existing routines be out of range for their jumps (Dasm will warn you of this when you try to compile if some are). Be sure and comment the lines that you add just in case you need to move them someplace else or replace them with JMP instructions. And save early, save often.

[4ever2600]

Well, just so you know, I didn't just delete any code from the end of adventure... There are 8 bits of unused data ALMOST at the end of the code... I am using the heavily commented dissambly of adventure that shows what each line of code does...

I also understand, now, what you say about not being able to just stick the other line in with out a branch statement... I didn't know that... So I went ahead and put the line in you told me to, and took away 2 more bits of data (unused), but it still scrambles the data... I'm thinking that this is going to take alot more rearranging that I can handle... : (

I do believe that what is happening is what you said, about me putting this code in causing the graphics data to be moved to where everything is thrown off...

And in the snipet I put in the example, it does do the branching afterwards I just didn't cut and paste that much for the sample... Sorry...

And unfortunately, the game doesn't take advantage of the object order, as far as a list of things to kill a dragon. I don't think that changing the 'high or low' value will make a difference... I can try though...

Have you ever checked out the dissasembled adventure code? This shortcut to Nick B's website has the code I speak of... if you have time, check it out and see if there is a way to do this without having to take out or add any code... If you have time or any interest... And if you do... MANY THANKS!

http://www.io.com/~n...tari/games.html

AND a big thanks to you regardless, you've certainly showed me HOW all things I tried to do, makes things happen... Every little thing I can learn about 6502 helps me a little more every day... Thanks again! - Daryl

[Nukey Shay]

Whoops! I spoke too soon
The file you are using is NOT the optimized Adventure code. Editing the one you have can have disasterous effects.

OK let's say that you added your instructions at the routine LF832 and subtracted the few bytes from the unused bytes near the end. Why does it mess up? Well, many of the game's pointers are no longer pointing at the correct addresses...look at this line for the yellow castle...

FEB4: .byte E3,FB,....

Do you see those first two bytes? Those are pointers that direct the computer to the proper address for the room pixel data (the comments in the disassembly even tells you this). Since you (in effect) moved a few unused bytes at the end of the file to someplace in the middle, those pointers are no longer indicating the correct address the computer needs to look at for the room graphics. The graphics table was at $FBE3...but now it's at $FBE7...but the pointers in the table still indicate $FBE3. And this is just one example...there are plenty more pointers that would need to be changed!

Before you go crazy and begin altering all those pointers by hand, just use the optimized version made by Joel Park and Thomas. In that version, all the pointers have been changed to labels, and Dasm will figure out the correct values in those data lines for you.

[4ever2600]

Hang on, I tried what you said... you are right it didn't work, though you would think it would... But all I did was added one line of code in the middle:

CMP #$87 - I added this line to make the dot (#$87) kill the drag

And took 4 bytes of the unused code of adventure away to make the cart 4096 bytes again... I don't see where the prob is... : (

Here is the original code:

F832 86,9A STX &9A ;Store the object dynamic data address.
F834 A6,A0 LDX &A0 ;Get the object number.
F836 20,FE,F6 JSR &F6FE ;See if another object has hit the dragon.
F839 A6,9A LDX &9A ;Get the object address.
F83B C9,51 CMP #&51 ;Has the sword hit the dragon.
CMP #$87 (-I added this line to make the dot (#$87) kill drag)
F83D D0,0C BNE &F84B ;If not, branch.
F83F A9,01 LDA #&01 ;Set the state to 01 (Dead)
F841 95,04 STA &04,X
F843 A9,03 LDA #&03 ;Set sound three.
F845 85,E0 STA &E0
F847 A9,10 LDA #&10 ;Set a noise count of &10.
F849 85,DF STA &DF


and then I took 4 bytes of code out of this line:

;Not Used
FFEF 00,00,00,00,00,00,00,00,00,00

That sounds good! whatta you guys think?

[Nukey Shay]

I think I'm smacking my head against the table

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

Judge Reinhold said:

Read it, know it, live it.

[4ever2600]

I'm sorry Nukey... I know you've been pushing me using this 2nd optimized code, I know your getting tired of saying that, but I started out using the ORIGINAL adventure code, then switched over to using distella... I know I need to use this new one, but how do I transfer all my old data from my bin to the new one? Easy way? - Me

[4ever2600]

In other words, I have a rom that's 99% done... Now I have this new optimized code that's still the original adventure, what's the easiest way to transfer all the code from my almost completed rom to the new one besides copying and pasteing? If I had to sit there and go line for line, it 'd take longer to do than it did for me to hack the original... : ) Later!

[Nukey Shay]

What old data? If it's just bitmaps of the various objects, you can simply cut and paste them from one assembly file to the other (don't transfer the labels tho...this will just confuse the assembler). Only replace the .byte lines of things you modified. Or better yet, you could just edit your values into the optimized code by hand...there are not that many images in the game.
Setting ORIGINAL = 1 will leave you with 171 free bytes of romspace...if you set ORIGINAL = 0 you will have 271 (there are many more than can be found...especially by moving the various screen bitmaps around to "share" data between 2 screens).

[4ever2600]

That's the problem, I've edited more than just bitmaps, remember, we wrote new code in, and I've changed ALOT more things in this game than graphics. I guess if I want to pull this off, I'm going to half to go line by line and compare and copy and paste... Sigh...

Please remember, I'm new at ALL of this... It's extremely frustrating sometimes going from one thing to another to another...

Over the last few months I've edited more than half of the original code, then found out about the optimized code... At this point, I'd literally have to recopy and paste almost half of the code line by line to make sure I don't get rid of anything important... It's not just graphics...
Rooms, sounds, matrix's, the works...

Please be patient...

PS. I have no idea what you meant by this... (in other words your about to begin banging your head against the table... : )


Setting ORIGINAL = 1 will leave you with 171 free bytes of romspace...if you set ORIGINAL = 0 you will have 271 (there are many more than can be found...especially by moving the various screen bitmaps around to "share" data between 2 screens).

[Robert M]

Okay, if you want to stick with your current listing, then I recommend you make what is best described as a software patch. From your source:

F832 86,9A	STX &9A	;Store the object dynamic data address.

F834 A6,A0	LDX &A0	;Get the object number.

F836 20,FE,F6	JSR &F6FE	;See if another object has hit the dragon.

F839 A6,9A	LDX &9A	;Get the object address.

F83B C9,51	CMP #&51	;Has the sword hit the dragon.

F83D D0,0C	BNE &F84B	;If not, branch.

change it to this:

F832 86,9A	STX &9A	;Store the object dynamic data address.

F834 A6,A0	LDX &A0	;Get the object number.

F836 20,FE,F6	JSR &F6FE	;See if another object has hit the dragon.

F839 A6,9A	LDX &9A	;Get the object address.

            JMP &FD88                ;Jump to patch.

            NOP                          ;Use exactly 4 bytes ROM

Then change the listing:

;Object #4 : State FF : Graphic

FD88	F0  XXXX

FD89	80  X

FD8A	80  X

FD8B	80  X

FD8C	F4  XXXX X

FD8D	04       X

FD8E	87  X    XXX

FD8F	E5  XXX  X X

FD90	87  X    XXX

FD91	80  X

FD92	05       X X

FD93	E5  XXX  X X

FD94	A7  X X  XXX

FD95	E1  XXX    X

To this:

;Object #4 : State FF : Graphic
;Software patch

FD88    CMP #&51

        BEQ  &FF93       ; Touching sword

        CMP  #&87

        BEQ  &FD93      ; Touching dot

        JMP   &F84B      ; nothing happens

FD93    JMP   &F83F       ; dragon dies

That should work.

[Nukey Shay]

Right...in the original game, there are a lot of instructions that are not even needed at all. Like this:

LDA $95

CMP #$00

BEQ SwapPrintObjects

When you load a register with a value, the N and Z flags are already set. There is no reason at all to even use CMP to see if it's zero (unless another branch jumps there...but I won't go into that). You can shorten the above to this which does the same thing...

LDA $95

BEQ SwapPrintObjects

In the revised version, setting ORIGINAL equal to 1 (way up near the top in the assembly file...just below all the variables) will compile the game still using these space-wasting instructions. The only thing that will have been removed is the black & white support and most of the secret message (171 bytes free). If you set ORIGINAL equal to 0, those instructions will be omitted from the binary (and the game will still play like the regular cart...you'll just have 271 bytes left over). That is how you end up with free space in both versions of the binary.

Re: reusing data...
In the existing game, it already shares some bytes between two screens (you'll see this in the assembly file...all the shared lines are marked). But the programmer never went the whole nine yards...and you can move some screen bitmaps around so that the upper and lower borders are shared. Heck...some of them you con't even need to move at all! Look at this...

;White Castle Entry

WhiteCastleEntry:

       .byte $F0,$3F,$0C

       .byte $F0,$00,$0C

       .byte $F0,$FF,$0F

       .byte $00,$30,$00

       .byte $F0,$30,$00

       .byte $00,$30,$00

       .byte $F0,$FF,$0F


;Top Entry Room

TopEntryRoom:

       .byte $F0,$FF,$0F

       .byte $30,$00,$00

       .byte $30,$00,$00

       .byte $30,$00,$00

       .byte $30,$00,$00

       .byte $30,$00,$00

       .byte $F0,$FF,$FF

Take a look at the bottom line of bytes for the White Castle Entry...and then look at the top line of bytes for the Top Entry Room. They are the same 3 bytes So you could do this...

;White Castle Entry

WhiteCastleEntry:

       .byte $F0,$3F,$0C

       .byte $F0,$00,$0C

       .byte $F0,$FF,$0F

       .byte $00,$30,$00

       .byte $F0,$30,$00

       .byte $00,$30,$00
;      (erased these bytes)


;Top Entry Room

TopEntryRoom:

       .byte $F0,$FF,$0F

       .byte $30,$00,$00

       .byte $30,$00,$00

       .byte $30,$00,$00

       .byte $30,$00,$00

       .byte $30,$00,$00

       .byte $F0,$FF,$FF

Then when the display routine is looking through the values for the White castle, it doesn't have enough values in that table, and looks at the bytes we have labelled for the Top Entry Room (because the data there is next in line). That just saved you 3 bytes of rom space And you don't need to worry about shifting the memory around (much), because this assembly file is fully labelled...and all the pointers will be updated by Dasm.

So how do you know what address you are moving things to? You don't need to know...Dasm figures all that out on it's own. All you need to do is stick a label on anything that you need to reference...instead of writing a routine that says JMP $FD00 you'd just JMP Custom_routine (or any name you want to give to it). Then someplace in the code, you would write your routine starting with the line Custom_routine: Dasm will figure out the real addresses by itself.

[4ever2600]

Man, you guys are hardcore! I pretty much understand what you mean... BUT for example... I need the name for the secret room, I've changed it around and now is a title screen... Remember Nukey, you helped me with this... So I can't ditch that...

If I set the original to 0 OR 1, both b&w and secret message are omitted right? That kinda screws me... I know it can be done pretty easily with the way you've both showed me, but unless I knit picked through the code getting the few lines here and there that connect rooms etc, I'd probably have to cut JUST the black and white out... I see this is going to take a while...

[Andrew Davie]

4ever2600 said:

...  I see this is going to take a while...

... 4ever, probably

[4ever2600]

That's funny... Now you know why my handle is 4ever2600... 2600 programming takes 4frigginever... : )

Thanks though guys, I'll let you know what happened in a couple of months... : ) - ME

[Nukey Shay]

The GFX for the secret message in both versions has been changed to this:

;Object #4 : State FF : Graphic

GfxAuthor:

       .byte $FE                 ;XXXXXXX

       .byte $25                 ;  X  X X

       .byte $26                 ;  X  XX

       .byte $A4                 ;X X  X

       .byte $64                 ; XX  X

       .byte $00

If you want to use a new graphic bitmap, just paste it in there below the tag GfxAuthor. Just don't exceed 96 bytes and be sure that a zero byte ends it. Just paste in whatever graphic you want to use.

Here's one that details packing all those rooms together...and has the original signature graphic enabled when ORIGINAL=1 is used You still end up with 81 bytes free in the original version. If that variable is set to zero, you will end up with 341 bytes free (I tracked down a few more wasteful instructions and moved around all the room definitions to share more of the upper/lower borders - be sure to look at the ELSE portion of the room definitions). If you want to enable the optimizations AND still have the signature graphics, just remove the IF ORIGINAL and ENDIF surrounding that image. You'll also need to erase the GfxAuthor: tag I placed above the chalise.

BTW the secret message room number is $1E. The graphics are shared with the bitmap BelowYellowCastle. If you want to make seperate graphics for the secret message room, edit the last line in the "room data" table (just above the "room differences" table near the end of the file).

       .byte <BelowYellowCastle,>BelowYellowCastle, $66,$0A,$21,$06,$01,$06,$03
;1E; Name Room           Purple

For example...let's say that we want the secret message room to have a center wall. You can create a screen bitmap like this...

;a custom screen with center wall

CenterWallScreen:

       .byte $F0,$FF,$FF ;XXXXXXXXXXXXXXRRRRRRRRRRRRRR

       .byte $00,$00,$C0 ;             XR

       .byte $00,$00,$C0 ;             XR

       .byte $00,$00,$C0 ;             XR

       .byte $00,$00,$C0 ;             XR

       .byte $00,$00,$C0 ;             XR

       .byte $F0,$FF,$FF ;XXXXXXXXXXXXXXRRRRRRRRRRRRRR

OK...there is the bitmap...but how do you tell the game to use this? Go to the last line in the Room data for that "name room" (that line shown above), and change the first .byte values like so...

       .byte <CenterWallScreen,>CenterWallScreen, $66,$0A,$21,$06,$01,$06,$03
;1E; Name Room           Purple

That tells the computer where to find that new bitmap you created when the player is in that room and the game needs to display it.

Attached Files

•  adventure_optimized.zip   26.97K   48 downloads

[Thomas Jentzsch]

For more flexibility someone should add a few more compiler switches.

I always use ORIGINAL when disassembling and then hacking games. By setting ORIGINAL to 1 you can easily check that you didn't break anything (compare with original binary).

Maybe switches like REMOVE_BW, REPLACE_EE or NEW_ROOMS would be a good idea.

[4ever2600]

I like Thomas's idea, that would be cool to do a removebw switch...

Thanks Nukey, I think I'll be able to use this version of the optimized code! Though I have a couple of dumb questions, you're all gonna laugh at, but I'll save that for the end. : )

Is that why after each graphic image, there is a zero line? I wondered why the original author did that, does that just mean it's the end of the image? I accidently used one of them in an earlier hack and it didn't seem to affect anything...

Also, I'm getting the whole, "original = 1 or 0" concept, I think... If you use original = 1 then it uses a certain set of lines of code, (particularly anything in between a set of "original and enddif" lines), and if you use original = 0 then is uses a different set of lines of code.

Remember when you guys talk 6502 code, I'm just learning ALL of this, so when you say something I don't understand, I have to figure out just how it fits into play... : )

Oh, by the by, in the optimized code you JUST posted, I compiled it and ran it, did you notice in the entry to the blue maze room one of the columns is off by a hair... Maybe it's the emulator I'm running it on, latest pcaewin. Just curious if you had the same thing happen, no biggie.

Ok, dumb question time.. Or did I already start that...?

When I go to compile your optimized version, I just use DASM like this...

DASM advop.asm -f3 -oadvop.bin ? I renamed the .asm to advop.asm.

Also, when I distella, I only get code, not like what you get...
Mine shows up only like this:

.byte $66,$0A,$21,$00,$00,$00,$00 so on so on so on

where your examples always show this:

.byte $66 | XX |
.byte $0A | X |
.byte $21 | XX |

Am I not using the proper distella command line? I use :

distella -paf adventur.bin > adventur.src

If there is any docs on this please point me in the right dir. I tried using the command line help file but ya know... I know that you can use a config file but I'm not sure how to create it...

Anyways dumb q session over for now... Talk to you all soon! Thanks for the help as always! - Daryl

[Thomas Jentzsch]

4ever2600 said:

Also, when I distella, I only get code, not like what you get...
Mine shows up only like this:    

.byte  $66,$0A,$21,$00,$00,$00,$00  so on so on so on

where your examples always show this:

.byte $66   | XX     |
.byte $0A   | X       |
.byte $21   | XX     |

That's because the adventure code was disassembled using a configuration file (-c DiStella parameter) telling the disassembler where to assume code, ordinary data and graphics.

[Nukey Shay]

Yes, the zeros are in there so the program knows where those graphic images end. That's why in the signature graphic, there are small lines or dots between the letters...if a zero was used, the program would just stop displaying the image at that point.

And yeah...that's the idea about the "ORIGINAL" variable. Whatever value is set, the compiler will ignore instructions under IF-lines that are between the opposite ORIGINAL value. By changing the assembly in that manner, you can keep multiple versions of the program in the same asm file (and be able to look back at the way that it was like Thomas said).

Funny you mention that skewed bit in the blue maze. I don't think that nobody ever provided an explaination for that I dunno where it comes from, just that it's there when you enable optimizations. In any case, it doesn't seem to affect the game at all.

And yeah, you need to supply a .cfg file if you want graphic bitmaps to show up in the disassembly. An easy way to do this is to use HOM or Showgfx to look through the binary and write down where all the bitmaps occur (the starting and ending addresses...be sure to change the first hex digit to F). Then create a text file in Notepad...something like this:

CODE F000 F347

GFX F348 F500

CODE F501 FD09

GFX FD0A FFFA

CODE FFFB FFFF

...and save it to the folder that you are working with Distella in. I usually name it with the game's name followed by the extension .cfg
BTW you should also use the -s switch, so the cycle counts will appear next to the instructions. These counts can be really helpful when learning how they affect the timing issues in the 2600 hardware.
So, the command line would be something like:

[b]distella -pafsc

[4ever2600]

Alright Nukey, don't read the following... I don't want any head pounding... : )

Hey Robert M,

I'm willing to sacrafice some of my name graphic, just like to suggested to try this out and get a little more exp. with patches... BUT

In your quote,

"change it to this:

Code:

F832 86,9A STX &9A ;Store the object dynamic data address.
F834 A6,A0 LDX &A0 ;Get the object number.
F836 20,FE,F6 JSR &F6FE ;See if another object has hit the dragon.
F839 A6,9A LDX &9A ;Get the object address.
F83B JMP &FD88 ;Jump to patch.
F84D NOP ;Use exactly 4 bytes ROM "

What does the NOP above mean? I couldn't find an example of that anywhere in the adventure rom, original or optimized...

AND all the above code actually stays the same EXCEPT for F83B, F83C, AND F83D... But what about F84E? In the original code it stood for,
F83D D0,0C BNE &F84B ; (If not, branch.)

See Below...
F832 86,9A STX &9A ;Store the object dynamic data address.
F834 A6,A0 LDX &A0 ;Get the object number.
F836 20,FE,F6 JSR &F6FE ;See if another object has hit the dragon.
F839 A6,9A LDX &9A ;Get the object address.
F83B C9,51 CMP #&51 ;Has the sword hit the dragon.
F83D D0,0C BNE &F84B ;If not, branch.

Does the entire line of F83D and F83E stay the same? Or is F83D = NOP and F83E = 0?

MY NEXT QUESTIONS IS:

The second part of your solution, where I change some of the "authors name" to the actual patch, I understand... BUT I do want to use what's left of the authors name to make a title screen (which is actually already done) My questions is, once I've cut off the first 12 lines of it and replace it with your patch, do I need to do anything else, or put pointers to reflect that the program should start 12 lines down from what was there originally? Lemme know if I haven't explained that one right... Thanks! -D

[4ever2600]

Robert,

Ignore this question:

AND all the above code actually stays the same EXCEPT for F83B, F83C, AND F83D... But what about F84E? In the original code it stood for,
F83D D0,0C BNE &F84B ; (If not, branch.)

See Below...
F832 86,9A STX &9A ;Store the object dynamic data address.
F834 A6,A0 LDX &A0 ;Get the object number.
F836 20,FE,F6 JSR &F6FE ;See if another object has hit the dragon.
F839 A6,9A LDX &9A ;Get the object address.
F83B C9,51 CMP #&51 ;Has the sword hit the dragon.
F83D D0,0C BNE &F84B ;If not, branch.

Does the entire line of F83D and F83E stay the same? Or is F83D = NOP and F83E = 0?


I figured it out my mistake right after I posted the last question... Thanks

[Nukey Shay]

Just use the optimized code...then you won't need to mess around with coding specific addresses and using NOP's to fill holes

[4ever2600]

I KNEW THAT WAS COMING!

But is that what an NOP is? A hole filler?

How does that translate into binary or hex?