ThomasSpeedrunner Help Thread

An alternative way would be to use my SMPS Converter and convert from Sonic 1 to Sonic 1. (Yes, this works.) This will remap PSG instruments and DAC sounds.

The DAC sample tables will be helpful.

 

Erm...I know this is probably a stupid question, and I apologize in advance if it is, but is it possible to extend the amount of chunks in a SonED2 project file beyond FF? I want to make more new chunks for some of the levels in my hack, but I don't know whether or not it is possible to extend such a parameter without breaking everything else in the project file. Thanks in advance to anyone who can assist.

 

For once, this is not a limitation of SonED2 (well, it is, but that's irrelevant). It is a limitation of the amount of RAM reserved for chunks, and the level layout format.

In Sonic 2 and S3K, each chunk is $80 bytes, and the chunk table occupies $0000-$7FFF ($8000 bytes) in RAM. $8000 / $80 = $100 (256).

Additionally, the level layout format uses one byte for each chunk, again limiting you to 256 chunks.

In order to create more chunks you would first have to expand the chunk table in RAM, expand the level layout in RAM, rewrite all the layout code, then write a new level editor (easiest with SonLVL as it's open source), because both of the main editors are only designed for $100 chunks.

 

The Mega Drive doesn't have enough RAM to store more chunks plus an expanded level layout format (you'd need a word to represent each chunk in the layout instead of a byte). I think there are guides on retro to make the game read the layouts straight from ROM instead of copying/decompressing to RAM, but you'd need to somehow modify Soned2 or SonLVL to save your levels in a new format.

e;fb, should have refreshed

 

Well, thanks to both of you for giving me some insight as to how this type of thing works.

 

Well...I haven't posted much here for a while.

Anyway, recently I've been thinking about something, and I know it's kind of an odd question, but is it possible to have more than $FF music slots in Sonic 2?

 

I got Sonic 1 to use 14848 music slots (71 × 256) by using two bytes, I guess it would be possible to do the same thing in Sonic 2.

 

Okay, but how would I go around doing that type of thing? I go over $100 for the number of options in the sound test, and I get an error saying "range overflow". Confused, I am =/

 

(so sorry for the double post)

So......I've had a problem lately:

I cannot comprehend why, but there is a noticeable pause when disabling interrupts with the Sonic 2 Clone Driver, so I commented out each and every line that does so. However, sometimes the screen randomly blacks out for one frame (it pretty much redraws). Any suggestions on why this might be happening?

 

The Clone Driver, being SMPS 68K, works primarily on the 68K side and it needs interrupts to run every frame. Sound driver's main routine is called from VBlank's routine, which in turn runs on vertical interrupt (when VDP stops drawing the current TV-frame and prepares to start on the next one). This is why the sound stops updating when you disable interrupts on the 68K for too long. The original Sonic 2 driver doesn't have this issue, because it's working on another processor, the Z80. The driver relies on the interrupts as well, but if you disable interrupts on the 68K, it doesn't affect the Z80 (unless you disable interrupt generation on the VDP itself).

However, I wouldn't go for removing every line that disables interrupts. They are there for a good reason.

You must disable interrupts when you're writing to VDP outside of VBlank's routine, for example. Because, if the interrupt happens during the data transfer, the VDP address register state will be lost, and your transfer will get broken right after the interrupt, resulting in data being written to wrong locations, corrupting VDP's memory. It happens because during the interrupts the game does other transfers to VDP (palettes, sprites and more). In order to do a transfer, you must set VDP to access a certain address in its memory first, and when you do so, the previously used address is lost.

Freezing sound is actually a common issue with the 68K drivers. You can see this happening in a bunch of official games, most notably Moonwalker and Golden Axe 3 -- they disabled interrupts to decompress new art when boss fight starts. As the result, the whole game freezes for a while.

You could probably fix this issue by creating a special VBlank routine that doesn't do anything about VDP, but only updates the sound. Or perhaps, a memory flag that forces the original routine to skip everything, except for SMPS. That would do the trick, I think. Activate that special flag where you were meant to disable interrupts and clear it when interrupts should be re-enabled.

 

Thanks, vladikcomper.

Anyway, I finally got around to deleting all Special Stage coding from my hack, since it won't be needed due to the direction in which my hack is going. However, I got the following crapton of alignment errors after all required code/build script modifications were made:

http://pastebin.com/i3quDZv1

If anyone could advise me on how these would be fixed, thanks.

EDIT: Fixed, although an explanation of why using "align" works would be useful so that I know in the future.

 

(so sorry for the double post)

ERM...I just finished getting rid of the Special Stage stuff, and three errors come up:

1) Death Egg Zone's background is back to being fucked up. Mind you, I already fixed it before. What should I do?

2) 

Yeah...Hill Top Zone isn't showing its art correctly, and the pointers are already fixed from before.

3) 2P Zone select is screwed up as well (will give screenshot later)

Any solutions?

 

Somewhere before all of that code, you have data than "ends" before an odd address, those instructions then start on that odd address, the problem though, is that the main processor cannot process word or long-word instructions on odd addresses, this includes the processing of instructions themselves.

Somewhere before this instruction on line "7688":

Code:

		lea	(Chunk_Table).l,a4

You need this:

Code:

		even

To force the address onto the next even offset.

 

TSR, Did you edited the art of EHZ? Remember that HTZ and EHZ use the same art.

 

Winter Hill Zone (EHZ) and Mountain Climb Zone (HTZ) are already using different art. So that isn't the issue.

 

Then did you change the incbins?

edit: Did you remove the code that load HTZ's 16x16 extra blocks?

 

Again, no. Also, note that this is only after I got rid of all Special Stage coding, so I might have deleted something I wasn't supposed to...

 

I would just start from your back-up and try again, but just remove parts at a time and build from them.  And keep doing this until HTZ fucks up again, then you can pin-point where and why it went wrong.

 

That glitch seems very familiar to me. I get it nearly every time I split the mapping, art, and layout files for CPZ/DEZ and EHZ/HTZ. The only thing that is ironic about said glitch I'm referring to, is that HTZ is the only zone that has this graphical glitch when loading. Regarding the fact the the Xenowhirl disassembly has some slightly different named files. I eventually fixed it by renaming one measly file.

 

If you don't mind my asking, which file exactly was this file?