Debugging misaligned read/write

Alright. I have added this to my hack, because I think it will be vital for me to have this in the future. But I have no address errors currently, what would be a simple way to test this? (IE: cause an address error on purpose)

 

Code (Text):

1.         ILLEGAL

Is the most common to use, you can always do stuff such as:

Code (Text):

1.         movea.w #$0001,a0
2.         jmp (a0)

To cause address errors.

 

The screen doesn't display for me when using either of those methods. I renamed everything to work with the xenowhirl 2007 version and all that. I just get a black screen, nothing more.

 

Nevermind, I got it. I had to mess with the vdpComm and dma68kToVDP. It's all working quite nicely now.

 

Would you mind telling how you did that? I have the same problem here, only getting a black screen.

 

Stupid 2 questions, but does EVEN go above or below?

Code (ASM):

1. word_1E7A: BINCLUDE "art/palettes/EHZ ARZ Water.bin"; Emerald Hill/Aquatic Ruin Rotating Water palette
2.     even

OR

Code (ASM):

1.     even
2. word_1E7A: BINCLUDE "art/palettes/EHZ ARZ Water.bin"; Emerald Hill/Aquatic Ruin Rotating Water palette

Second question. There are a lot of align commands. Mainly "align 4" Then there's a few "align 100" and "align 200" and with Sonic and Tails, etc, "align $20000". Should these be replaced with even or should be left alone?

 

Align goes above and even goes below. It does not hurt for them to be used with each other, never caused a problem for me.

 

Well, what I am doing is putting "even"s after all dc.bs, for example:

Code (ASM):

1. ; animation script
2. off_2CF6C:
3.     dc.w byte_2CF78-off_2CF6C
4.     dc.w byte_2CF7B-off_2CF6C; 1
5.     dc.w byte_2CF83-off_2CF6C; 2
6.     dc.w byte_2CF89-off_2CF6C; 3
7.     dc.w byte_2CF8D-off_2CF6C; 4
8.     dc.w byte_2CF90-off_2CF6C; 5
9. byte_2CF78: dc.b  $E,  0,$FF
10. byte_2CF7B: dc.b   5,  3,  4,  3,  4,  3,  4,$FF
11. byte_2CF83: dc.b   3,  5,  6,  7,  6,$FF
12. byte_2CF89: dc.b   3,  1,  2,$FF
13. byte_2CF8D: dc.b   1,  5,$FF
14. byte_2CF90: dc.b  $E,  8,$FF
15.     even

I'm also putting all evens after BINCLUDES and INCLUDES, for example:

Code (ASM):

1. Obj85_MapUnc_2B07E: BINCLUDE "mappings/sprite/obj85_a.bin"
2.     even
3. Obj85_MapUnc_2B0EC: BINCLUDE "mappings/sprite/obj85_b.bin"
4.     even

Then I'm putting "align 4" in front of all objects, as many objects have this and some do not. The shellcracker badnik didn't, so I did this:

Code (ASM):

1.     align 4
2. ; ----------------------------------------------------------------------------
3. ; Object A0 - Shellcracker's claw from MTZ
4. ; ----------------------------------------------------------------------------
5. ObjA0:

After I've done this will all badniks, I will then test again and see if I can re-produce this bug. If not, flamewing has solved my problem =)


Sorry if it feels like I'm de-railing the topic, but as the topic is about alignment, I thought it was still suitable.

 

I've gone over EHZ over and over and over, and so far, no freezes! ARZ still freezes but because I haven't gone through the whole ASM yet.

Thanks, everyone. Flamewing, I owe you one.

 

Nice work, flamewing! I think I'll add this to my "skeleton" code that I keep around to use as a base for starting a project on the MD. Fully credited, of course

Any special considerations I need to take into account when attempting to use this outside of a Sonic disassembly?

 

Well, I'd be using it for original projects rather than hacking existing games, so I'll need to ape KosDec, EniDec, PlaneMapToVRAM, the DMA macros, vdpComm, and the S&K address error constants and defines. Since I'm not as familiar with the actual Sonic codebase, do you know if there are any other dependencies that I'd need to ape to make the above subroutines work?

Thanks a lot, this is really one of the nicer exception handlers I've seen. A few commercial games here and there had some nice ones but for the most part they liked to pull a Sonic 1 (minimal info) or a Sonic 2 (spins on infloop). It'd be interesting to see the handlers they used in development (along with the hardware ICE that they'd use back then, I bet debugging was interesting, being able to halt and single-step the hardware itself).

 

Yeah, that was my plan, I just figured you'd be able to give me a good starting point, which you have

Oh, most certainly. It'd be more interesting from a historical perspective than anything, yet another glimpse into "the way things were". Although I'm pretty sure they didn't burn any EPROMs when they were debugging, but that they used ROM emulators to download the code from a connected PC (often via SCSI, from the hardware I've seen pics of, which is quite fast for this purpose). Also, some developers would use two-way communication between the console and their dev box through custom exception handlers (not sure if SEGA did this, but I'm pretty sure Psygnosis did, remember Psy-Q and "NOSEGAY"?) EPROMs were most likely only burnt for testing, magazine review or other public display where the ICE+ROMulator+dev computer combination would be unwieldy.

 

Sorry to be a pain in the ass, but are you definitely sure that evens are meant to be underneath the bincludes, Hitaxis? Only because in my asm, there lots of evens already but above the bincludes, and ARZ still hasn't gotten rid of the alignment error situation.

 

The use of "even" isn't really for the actual file itself, it's more for the data after it, if you have a file that has an odd number of bytes and is included into your source code, whatever is after that file will begin on an "odd" address, for example:

Code (Text):

1. File1Location:  binclude    "File1namehere.bin"
2. File2Location:  binclude    "File2namehere.bin"
3. RoutineName:
4.         move.b  d0,d1
5.         add.b   d2,d1
6.         etc
7.         etc
8.         ...

Now, an "even" only needs to be under File1Location's binclude if File2Location is read by the 68k in "words" or "long-words", if it is not being read by the 68k in "bytes", it will need to be on an even address, otherwise the 68k will crash.

As for File2Location, that WILL need even under it, because the data after that binclude is 68k code, and the processor can only process instructions on even addresses.

Remember, it's not what's above the even, it's what's below it. It has been mentioned by a few members already, and they're right, you should always put "even" under bincludes and arrays using dc.b that have the potential to fource what's after it onto an odd address:

Code (Text):

1. File1Location:  binclude    "File1namehere.bin"
2.         even
3. File2Location:  binclude    "File2namehere.bin"
4.         even
5. RoutineName:
6.         move.b  d0,d1
7.         add.b   d2,d1
8.         etc
9.         etc
10.         ...