Discussion in 'Discussion & Q&A' started by Malevolence, Jul 7, 2009.
If you use SonLVL to import, then PNG will work perfectly.
How do I import the PNG into SonLVL?
Right click on the chunk list in the Chunks tab and click Import.
Where are the mappings for Sonic & Tails on the title screen? I can't seem to find them.
How do I fix monitors always being broken? I see monitors broken even though I have not destroyed them yet ingame.
Remember Sprite State flag, it's usually Monitors and Badniks that use this. If you are using Sonlvl there is an option to make it true or false, but if your using SonEd2, it's different, harder to explain how to do it though, since I have not used SonEd2 in a while.
I believe both editors should set the flag by default when placing monitors, as long as you haven't edited the setting in the object definitions.
So I've been messing around with my hack in a hack idea, and decided to binclude my hacked S2 rom on top of my S1 disassemby. I removed S2s' end command and S1s' checksum. Building it predictably boots S2, but jumping to the end of the S2 rom seems to simply freeze the game. Also, I get the feeling that I need to remove S1s' rom header, but I don't know where the code starts and the header ends.
SonED2 doesn't do it but default, and neither did yours, until I set it to in the object definitions, it could be in new ones you made though, because I first used your editor, like a year ago and I remember having to turn it on.
Not sure about S1, but the S2 disasm has a label called EndOfHeader, and it's pretty much what it says on the can: the end of the ROM header. Likewise, EndOfROM marks the end of the ROM, and usually there's an 'END' command at that location, so there's an easy way to tell where the ROM ends.
I can't imagine why you didn't think to mention such an obvious bug, considering enemies and Rings have the flag set properly.
Regardless, it's fixed now.
Is Clownacy's Sonic 2 Clone Driver v188.8.131.52 compatible with the Xenowhirl 2007 Disassembly? I'm going to guess that it's not.
Hi. I have a question about the Github disassembly for Sonic 1. I'm triying to edit the graphics for the HUD in SonMapEd and the mappings for the sprites don't seem to work with it. I loaded the Nemesis compressed graphics HUD.bin from the artnem folder, then I loaded the mappings from the _maps folder but it doesn't work. Is there anything im not aware of that I should do? I haven't loaded anything except the mappings or the HUD.
Why don't you back-up your disasembly (just in case) then try it out for yourself? You won't know until you try.
By the way, I don't actually know the answer, and cannot be arsed to find out.
Go to this post (a couple of pages back in this very topic). I think the problem is exactly/similar to this.
I can follow it up to a certain point, but now i'm going to have to put in every music constant from the GitHub Version. It'll be worth it if it works.
EDIT: Now I need a way to free up $600 RAM.
EDIT 2: Finished the main part of the guide just to be greeted with 121 errors, No idea how to fix them so i'm going to abandon the new Clone Driver for now.
If I had much of a use for it I'd port the Clone Driver V2 to the Xenowhirl disasm and write a guide on it, but eh. I can't see it being THAT hard to pull off.
I'm sorry to bring this back again, but I really want this to be part of my hack, and I need help to get it to work. I tested what would happen if I jumped to S2s' end of rom without S1, and it brought about the exact same results, right down to the title screen music oddly fading away. What's wrong? Why won't it move on to the S1 rom?
Edit: I also tried disableing rom padding on the S2 rom. It didn't help.
The starting 68k address of most (if not all) Mega Drive games (ignoring the whole concept of 68k vector table here for just a moment), is the offset held at 000004 - 000007 of the ROM. So if you have Sonic 1 on the end of your Sonic 2 ROM, you would need to enforce a sort of:
jmp (a0)In your Sonic 2 code. I was going to say that the offsets in your Sonic 1 ROM need to be corrected, but if you're doing it in such a way that your including the Sonic 2 ROM into the Sonic 1 source at the very beginning, then the assembler will sort that out, so there should be no problem there.
As it stands, the 68k vector table is at offset 000000 - 00000FF. SEGA's software header used for the Mega Drive specifically is at offset 000100 - 0001FF. This leaves the actual game data and routines starting at 000200.
That is not to say however that you cannot use the space from 000000 - 0001FF for anything other than what it says, you just have to be careful and know what is not going to be used.
Chances are, you won't use the trap instruction, so the trap offsets in the vector table are free to use. Some parts of SEGA's header are also free, for example, "SEGA MEGA DRIVE ", it is only the characters "SEGA" that is needed, the " MEGA DRIVE " section is free to change or use for something else. What anyone would want that space for is beyond my comprehension, though one could use that space to store setup data/instructions to save on ROM space (if they really desperately needed a few extra bytes).
Well, I got a fucked up S1 hack to boot. That's a start. It sufers from no sound, glitched up graphics, seemingly random lags, and a fucked level scroll. Also, it takes an eternity to boot, making it seem as though the S2 rom has frozen at first.
Edit: I have not edited the s1 sound driver beyond adding custom music, nor have I messed with the background scrolling
Edit2: The S2 soundriver plays cute little random tones before the reset. At one point, this played as a death tone while S1 was on, suggesing that the S2 driver doesn't breakdown properly. I don't know anything about the S2 driver, though, so I'm clueless on how to fix it.
Can't you read? I-
Oh right, I removed that warning. Oops...
Short answer: no. The thing is, Xeno, without an overhaul, really isn't build to have its driver replaced. It's the hardcoded sound IDs, making adding, changing, or doing pretty much anything to the sound ID order into an enormous chore, potentially requiring you to change every single hardcoded ID in your disasm. The magic of MusID_EHZ, people...
Good luck. You'd either be sacrificing features, or making a guide detailing the aforementioned changing of every sound ID in a Xeno disasm.
It's funny that you say you have no use for the driver. I can remember when you tried using the original Clone Driver, way back when.
I'd imagine switching whole ROMs to be handled as playing with four variables:
And to do that...
I'd recommend a little something S3K does: Take the machine code for 'jmp' and put it in RAM, then change the VBlank address in the vector table to point to that area in RAM. Near the beginning of GameProgram, push the address of S2's V_Int to after the 'jmp' in RAM. Doing all of that will make the code 'jmp V_Int' appear in RAM, this code will be processed to reach the V_Int whenever it needs to be accessed. Now, when you switch to S1, change the address after the 'jmp' in RAM to the address of S1's VBlank.
Do the same for HBlank, using a different area in RAM.
Simple really: Just set the Program Counter, (pc) to the address of S1's EntryPoint. Any old branch or jump can do that.
Another seemingly simple one, load the stack pointer (the first longword of S1's vector table) into sp.
Doing all of that should replicate the usual functions of the vector table, allowing you to, in a way, have two of them. There, of course, is more work to be done to achieve a working 'game swap', but this should detail a fair part of it.
EDIT: I should mention that we don't do anything about the error-related and other parts of the vector table, but you should be okay with having the two ROMs share an error trap or debugger.
Separate names with a comma.