Basic Questions and Answers Thread

Weird, because in another rom hacks theres some musics from Knuckles Chaotix and withouth the 32x.

 

You definitely require more knowledge when it comes to porting music.

 

The main thing with Chaotix music is that it makes use of a 4 channel PWM sample driver, so that has to be taken into account. You basically have to convert the PWM tracks to use the YM2612's DAC, and tricks are definitely going to be needed (like making singular samples for different sample combinations). A driver like Dual PCM would certainly help, and there's also the XGM sample driver, which I believe can mix up to 4 samples at once, but has less features.

 

You also have to account for the DAC track rendering the FM6 track almost completely unusable.

A convenient alternative to porting Chaotix music is to port Crackers music instead, since it is already designed to run on a plain Mega Drive. Though, I don't know where you'd find pre-made SMPS2ASM files for those songs, so you may have to use Flamewing's SMPS2ASM tool to make them yourself. I'll see about adding them to my Clone Driver v2's repository when I have some free time.

 

My incomplete Chaotix disassembly has SMPS2ASM generated files.

 

I meant files for Crackers' music. My driver has been bundled with SMPS2ASM Chaotix music for the last 9 years, but I never got around to bundling Crackers music as well.

 

Ah whoops. That's what happens when I read things late at night after a rough day of work lol

 

aw great...


















HOW DO I SLOVE THIS PROBLEM-

 

How i can disable the demo gameplays in credits?

 

It is saying that the code is using various constants that have not been defined anywhere. One is called 'plane_size_64x32', another is 'tile_size', and the last is 'ArtTile_SS_Plane_1'.

'tile_size' is likely '8*8/2', 'plane_size_64x32' is probably '64*32*2', but I do not know what 'ArtTile_SS_Plane_1' is. Maybe you can find it in one of the disassembles on GitHub (either in 'Constants.asm' for Sonic 1 or 's2.constants.asm' for Sonic 2).

You should add definitions for these three to your disassembly, and then the errors should go away.

 

Another problem whenever i try to fix it-

 

Usually only the first few errors are the ones that actually matter. Evident from the lines of code being shown (such as "move.w #$80+((&$C000)>>14),(v_vdp_buffer_2).w"), there is something going wrong with how the 'writeCRAM' macro generates code: you can see '(&$C000)', which does not make any sense as the '&' operator should be placed between two values, but here it is only placed before one.

Here is the 'writeCRAM' macro from the Sonic 1 Git disassembly:

Code:

writeCRAM:    macro source,destination
        lea    (vdp_control_port).l,a5
        move.l    #$94000000+((((source_end-source)>>1)&$FF00)<<8)+$9300+(((source_end-source)>>1)&$FF),(a5)
        move.l    #$96000000+(((source>>1)&$FF00)<<8)+$9500+((source>>1)&$FF),(a5)
        move.w    #$9700+((((source>>1)&$FF0000)>>16)&$7F),(a5)
        move.w    #$C000+(destination&$3FFF),(a5)
        move.w    #$80+((destination&$C000)>>14),(v_vdp_buffer2).w
        move.w    (v_vdp_buffer2).w,(a5)
        endm

The second-to-last line is the one that is producing the error. As you can see, the 'destination' parameter is meant to be placed before the '&' operator. The generated code having nothing before the '&' suggests that the 'destination' parameter is not set to anything. This may be because, when the 'writeCRAM' macro is used in your code, it is not being given enough arguments: every time that macro is used, it should have two arguments, like this:

Code:

        writeCRAM    v_palette,0

If this line of code were edited to not have the ',0' at the end, then it would produce an error that is identical to the ones that you are experiencing.

The error messages show you where these erroneous lines of code are: each message begins with something like 'sonic.asm(637)'. This means that the line of code that is responsible for the error is at line 637 of the file 'sonic.asm'. I suggest examining these lines of code to find out what is wrong with them.

Alternatively, it may not be the code which uses 'writeCRAM' that is broken, but rather 'writeCRAM' itself. You can compare your disassembly's 'writeCRAM' macro to the one that I provided above to see if there are any differences between the two that could be causing this issue.

Another error that you showed was about a constant called 'OptimiseZ80Stops'. As with the previous errors which were about 'tile_size' and 'plane_size_64x32', this error is saying that the 'OptimiseZ80Stops' constant has not been defined, or it could mean that the constant has been defined too late in the file and should be moved towards the start of the file instead.

Given this error message, as well as the ones from your previous post, it appears that you copied various macros from another disassembly. Because you did not also copy the constants which those macros depend upon, various errors were caused. Additionally, the errors about 'writeCRAM' may be because one of those macros that you copied had replaced the original 'writeCRAM', and this new version of the macro is incompatible with the old one. To remedy this, you can either revert the macros to their original versions, or correct the new macros to be compatible with the old ones.

There are also error messages about macros which do not exist, such as 'deassertZ80Reset' and 'assertZ80Reset', so it appears that you also copied some assembly code from another disassembly, and did not copy across the macros which it depends on.

 

I just literally moved most of the things (Except the S1 asms and others)

 

I don't mean to sound like a boomer who hates the future, but is there a way to make the current S1-AS disassembly's Variables work how they used to with the ram addresses instead of the numbers? The raw ram addresses are easier for me to understand, compared to the simple of today. (Though that might be due to my disabilities.)

 

You'd just need to make them use "equ" or "=". For the record, you can figure out what RAM address a variable gets set to in the generated listing (.lst) file after building.

 

I've done that, but each time I've done it, it always hurls me multiple errors, which makes me think I've got it all wrong.

 

Theres a way to add a partner mode like in Sonic 2 and 3 in Sonic 1?
im talking about this btw:

 

It is possible, though it is difficult: you would either have to port it from one of the later games, or you would have to reimplement it yourself from scratch. To my knowledge, there are no (easy) guides for either option.

 

How do I fix this:

 

Move the vram location of the signpost