[redhotsonic]

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

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

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

Obj85_MapUnc_2B07E:	BINCLUDE "mappings/sprite/obj85_a.bin"
	even
Obj85_MapUnc_2B0EC:	BINCLUDE "mappings/sprite/obj85_b.bin"
	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:

	align 4
; ----------------------------------------------------------------------------
; Object A0 - Shellcracker's claw from MTZ
; ----------------------------------------------------------------------------
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.

[flamewing]

You can just put 'even' after all 'binclude's and 'dc.b's; you don't need to worry about 'align'.

[redhotsonic]

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.

[LocalH]

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?

[flamewing]

LocalH, on 20 February 2012 - 01:30 PM, said:

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

The debugger uses Kosinski-compressed graphics and Enigma-compressed mappings; so it needs the KosDec, EniDec and PlaneMapToVRAM functions (using the S2 names). Or you can convert the art and mappings to another format if the game supports neither Kosinski or Enigma compression (getting rid of the PlaneMapToVRAM dependency requires a more substantial rewrite). It also uses a RAM buffer to draw the screen before DMAing it to VRAM; this buffer must be at least $1000 bytes, and should not overlap with the stack data; the version I posted uses the start of main RAM, which is usually used as chunk data or plane map/decompression buffers. The DMA macros and vdpComm function mentioned for the 2007 disassembly also need to be copied over, as do the constants and definitions used by S&K in 'Address Error Defs.asm' (and edited as needed).

I don't see any other problems if AS is used.

On unrelated news: I found some bugs in the decoding of 'move' instructions; I am looking to see what is going wrong, so expect a bug-fix revision soon.

[LocalH]

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).

[flamewing]

To everyone that downloaded the debugger: I found a bug in the handling of the 'move' instructions that was causing incorrect disassembly; I updated the link in the first post, but here it is for convenience: Address/bus error debugger v2.

LocalH, on 20 February 2012 - 02:20 PM, said:

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?

All 3 subroutines are pretty much self-contained. Just a warning: there are some other constants and defines used other than only those needed by S&K, as S&K shares some with S2. It would probably be easier to make a minimal ROM and see what AS complains as being missing rather than going through everything.

LocalH, on 20 February 2012 - 02:20 PM, said:

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).

To be fair, I think we have better debugging tools nowadays with the debugger version of Regen. It is also easier to build a ROM and test from an emulator than it is to build a ROM, write a cartridge, then test on the hardware ICE.

[LocalH]

flamewing, on 20 February 2012 - 03:28 PM, said:

All 3 subroutines are pretty much self-contained. Just a warning: there are some other constants and defines used other than only those needed by S&K, as S&K shares some with S2. It would probably be easier to make a minimal ROM and see what AS complains as being missing rather than going through everything.

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

flamewing, on 20 February 2012 - 03:28 PM, said:

To be fair, I think we have better debugging tools nowadays with the debugger version of Regen. It is also easier to build a ROM and test from an emulator than it is to build a ROM, write a cartridge, then test on the hardware ICE.

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.

[redhotsonic]

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.

[MarkeyJester]

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:

File1Location:	binclude	"File1namehere.bin"
File2Location:	binclude	"File2namehere.bin"
RoutineName:
		move.b	d0,d1
		add.b	d2,d1
		etc
		etc
		...

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:

File1Location:	binclude	"File1namehere.bin"
		even
File2Location:	binclude	"File2namehere.bin"
		even
RoutineName:
		move.b	d0,d1
		add.b	d2,d1
		etc
		etc
		...

[Chilly Willy]

Exactly - anyplace that data may be accessed as a word (code fetches fall under this category) or a long, the address must be at least word aligned. Putting an even right before code starts, or before dc.w/dc.l/ds.w/ds.l variables assures that they will meet that alignment.

More difficult are blocks of data where the code that deals with said blocks use a mix of byte, word, and long accesses. In such a case, you would need to make sure the block of data is built to meet the alignment rules as well.

[redhotsonic]

MarkeyJester, on 21 February 2012 - 07:23 PM, said:

The use of "even" isn't really for the actual file itself, it's more for the data after it

Chilly Willy, on 22 February 2012 - 02:50 AM, said:

Putting an even right before code starts, or before dc.w/dc.l/ds.w/ds.l variables assures that they will meet that alignment.

So why put an even after it if it only evens data after the word? For example, how do you know that an even doesn't need to go before "File1Location:"? I've gone through my whole ASM putting evens after the BINCLUDES and after the dc.b's and etc.


An example:

return_2D42E:
	rts
; ===========================================================================
; animation script
off_2D430:
	dc.w byte_2D436-off_2D430
	dc.w byte_2D43A-off_2D430; 1
	dc.w byte_2D43E-off_2D430; 2
byte_2D436:	dc.b   7,  0,  1,$FF
byte_2D43A:	dc.b   3,  0,  1,$FF
byte_2D43E:	dc.b   7,  0,$FF
	even
; ----------------------------------------------------------------------------
; sprite mappings
; ----------------------------------------------------------------------------
Obj5C_MapUnc_2D442:	BINCLUDE "mappings/sprite/obj5C.bin"
	even
; ===========================================================================

JmpTo34_MarkObjGone 
	jmp	MarkObjGone

Should I put an even before the "off_2D430" and "Obj5C_MapUnc_2D442" and not after it?

[Chilly Willy]

redhotsonic, on 22 February 2012 - 12:49 PM, said:

MarkeyJester, on 21 February 2012 - 07:23 PM, said:

The use of "even" isn't really for the actual file itself, it's more for the data after it

Chilly Willy, on 22 February 2012 - 02:50 AM, said:

Putting an even right before code starts, or before dc.w/dc.l/ds.w/ds.l variables assures that they will meet that alignment.

So why put an even after it if it only evens data after the word? For example, how do you know that an even doesn't need to go before "File1Location:"? I've gone through my whole ASM putting evens after the BINCLUDES and after the dc.b's and etc.

If you see code or dc.w/dc.l/ds.w/ds.l, those MUST be on an even address. How do you know they are on an even address? Some cases are simple:

    rts

some_var:
    dc.b 5

another_function:
    movem.l d0-d1,-(sp)

See how you have a single byte stuck between pieces of code? Unless that second bit of code at another_function is aligned, calling it will cause an address errror.

    rts

some_var:
    dc.b 5
    even

another_function:
    movem.l d0-d1,-(sp)

That now works. However, some cases are harder...

    rts

some_var:
    incbin "some_data_file.bin"

another_function:
    movem.l d0-d1,-(sp)

Is another_function aligned or not? It depends on how long some_data_file.bin is. If it's an odd length, the code is unaligned again and will fail. But if the block is an even length, you don't need to worry, right? Maybe, but maybe not. Will the block ever change length? Will you remember that this block affects code later on when you change the contents of the block? Will you do something like this?

    rts

another_var:
    dc.b 11
some_var:
    incbin "some_data_file.bin"

another_function:
    movem.l d0-d1,-(sp)

Even if the file is an even length, you've changed where it starts to an odd address by adding the byte variable before it. That means since it's an even length, it will end on an odd address and the code is again unaligned. In the case of variables stuck between code segments, use alignment directives no matter what to guarantee the following code segment is aligned. Like this

    rts

another_var:
    dc.b 11
some_var:
    incbin "some_data_file.bin"

    even
another_function:
    movem.l d0-d1,-(sp)

Another case people forget occurs when code is split over several files. Say file 3 ends like this

    dc.b 0,0,0

and say file 4 starts like this

enemy_code:
    movem.l d0-d7/a0-a6,-(sp)

You've created an odd alignment without even realizing it. You need to keep in mind how the overall code and data sections are being populated when assembling/compiling to avoid this. For code that starts a file, ALWAYS align it no matter what.

    even
enemy_code:
    movem.l d0-d7/a0-a6,-(sp)

Now it doesn't matter how file 3 ends, file 4 will start with aligned code. This can also get you when you switch back and forth among sections...

    rts

local_var_used_by_last_routine_above:
    dc.b 1

    .data
level_data:
    incbin "level1.bin"

    .text

another_function:
    tst.l d0
...

    rts

    .data
global_var:
    dc.l 53

I've created TWO potential address errors in the above code! First the code section ends with a byte variable, but when the section resumes later, starts straight in with code. Second, I have an unknown length block of data in the data section that when the data section resumes has a long variable. Both may cause address errors. When you resume a section, you cannot really be certain how that section ended... so align it!

    rts

local_var_used_by_last_routine_above:
    dc.b 1

    .data
level_data:
    incbin "level1.bin"

    .text
    even
another_function:
    tst.l d0
...

    rts

    .data
    even
global_var:
    dc.l 53

[redhotsonic]

Chilly Willy, on 22 February 2012 - 02:12 PM, said:

    rts

another_var:
    dc.b 11
some_var:
    incbin "some_data_file.bin"

    even
another_function:
    movem.l d0-d1,-(sp)

There's only one thing I do not understand.


With this code above, you say when I make edits, it can become unaligned at anytime. So, you've put an "even" in front of "another_function". So you're saying that now, no matter what, "another_function" will be aligned, right?


Well, why not put an "even" in front of "another_var" and "some_var"? So, that way, "another_var" and "some_var" will also always be aligned?

[flamewing]

redhotsonic, on 22 February 2012 - 03:43 PM, said:

Well, why not put an "even" in front of "another_var" and "some_var"? So, that way, "another_var" and "some_var" will also always be aligned?

If they aren't read as words, then alignment doesn't matter for them; if they are used as words, then yeah, they should be aligned too.