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): ILLEGAL Is the most common to use, you can always do stuff such as: Code (Text): movea.w #$0001,a0 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.
Stupid 2 questions, but does EVEN go above or below? Code (ASM): word_1E7A: BINCLUDE "art/palettes/EHZ ARZ Water.bin"; Emerald Hill/Aquatic Ruin Rotating Water palette even OR Code (ASM): even 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): ; 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: Code (ASM): 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: Code (ASM): 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.
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?
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.
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).
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. 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. 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.
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): 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: Code (Text): File1Location: binclude "File1namehere.bin" even File2Location: binclude "File2namehere.bin" even RoutineName: move.b d0,d1 add.b d2,d1 etc etc ...