Basic Questions & Answers thread

The music porting fixer guide is woefully oversimplified and inadequate. Out of curiosity: to which sound driver are you porting (S1/S2/S&K)?

 

I am porting music from Green Grove Act 1 (Sonic 3D) to AIZ1 (Sonic 3 & Knuckles). Forgot to mention that my almost-ported GGZ song for S3&K killed most of the songs in the music bank that contains AIZ1, oddly enough. Since both S3D/S3&K have such similar sound engines, I expected slightly better results with MPF. I don't mind a few imperfections in the output from MPF, but I do at least want all 3 channel types working in my music (FM, DAC, and PSG). Did you find any wrong inputs in the MPF picture, or wrong though processes?

 

Your pointer maths has gone wrong for the AIZ1 location - the pointer of $8000 you give is already big-endian. Its correct full location is $2C8000.

(As an aside, if conversion were necessary, it should have been converted to 0080, not 0008, then since the base bank is already $2C8000, you would've ended up with $2C8080... but it's not. And you're converting the pointers from little-endian to big-endian, not vice versa, for the record.)

Bear in mind that Green Grove 1 is shorter than Angel Island 1, too - you'll need to add some padding to get the next track in the bank back to its correct start point, if you're keeping it, or pointer fix the rest of the bank.

 

If you don't mind waiting a few days, I have converted all songs and SFX from S1/S2/S3/S&K/S3D to assembly format using a tool of my own making (the idea coming from Cinossu's S1SMPS2ASM); I will be integrating the ASM'ed S&K songs and SFX to the SVN disassembly and release the ASM'ed songs (as well as the program) at about the same time. I am also making an improved version of the S&K sound driver (basically, fixing bugs, removing dead/useless code, adding S1/S2 DAC samples, S1/S2 PSG flutter, a couple S1/S2 coordination flags and a few brand new coordination flags ported [and fixed] from Ristar's sound driver for FM commands/LFO). When all is finished, porting songs and SFX from S1/S2/S3/S3D to the S&K driver will be very easy -- although porting to S1 or S2 driver still requires hand editing of the song/SFX, if it is possible at all. I was talking to kram1024, and he intended to use this modified driver (and ASM'ed songs/SFX) for his tutorials on how to use the S3 driver in S1 and S2, but I haven't heard again from him since August. I am also waiting for Scarred Sun to finish converting SVN to Git (assuming she is still doing it...).

The "few days" is so I can finish all of this and prepare a release.

 

Hit a minor problem. Anyone got any idea what causes this problem with sprites?:

 

This is likely DMA-transfer error. I guess you have applied the Spin Dash guide, which changed the way Sonic art is updated.
In original Sonic 1, his art was directly written to RAM space (I call it art buffer), then DMA-transfered from there during VBlank. In Sonic 2 (also when you apply Spin Dash guide in S1) art is transfered directly from ROM section, and instead of art buffer it uses DMA cues queue.

The later way is much better and faster, but there can happen few issues due to DMA limitations.
When you DMA-transfer something, the source data should be within $20000 bytes bank, if it's not, you will get artifacts like on your screenshot after the bank ends. Note that this is emulated in Kega, but not in Gens.

To fix this, try to put 'align $20000' before your Sonic art:

Code (ASM):

1.     align $20000
2. Art_Sonic: incbin  "artunc\sonic.bin"

EDIT: GRAMMAR

 

Just a 2 quick question: how do you edit the SEGA PCM sfx for Sonic games, specifically S3&K? I read somewhere that the .bin file is basically compressed wav sample at 22KHZ or something. I'm assuming Sonic 1/2/3&K have the same sampling for this sfx. One more thing, could someone make a PlaneED project file for modifying the SEGA screen for S3&K? Here is what I have so far for that project file. Things marked with *s I don't know the values for, and need correct values for.

Code (Text):

1.  
2. Palette File: General/Title/Palettes/SK Sega and BG.bin
3. Mapping File: General/Title/Enigma Map/SK SEGA.bin
4. Art File: General/Title/Kosinski Art/SK Big SEGA.bin
5. Mapping Compression: Enigma
6. Art Compression: Kosinski
7. *Palette Offset: 0x20
8. *Palette Length: 0x20
9. *x-Size: 25
10. *y-Size: 9
11. *Tile Offset: 0x04
12.  

I found this new topicat SSRG about a util that might make porting songs/sfx between S2/S1 much easier. Havent tried the util, but it looks promising.

 

What I meant by that was that porting to S1 or S2 from S3/S&K/S3D will not be as easy as porting in the other direction -- there are many coordination flags that S3/S&K/S3D drivers have that don't exist in S1/S2. Porting between S1 and S2 is trivial -- or rather, from S1 to S2 is trivial -- as there are only 2 coordination flags in S1 with no S2 equivalent, and there is only 1 SFX for each of these coordination flags; all other songs and SFX works perfectly unedited. In fact, if you check the newest versions of S2: Heroes, you will note that several S1 songs are present in the sound test, starting at $20 (and I can't believe that no one noticed or commented about it thus far). Porting from S2 to S1 requires a bit more work as you need to port DAC samples and PSG flutter.

I am still working a few kinks for porting from S1/S2 to my modified S&K driver, mostly relating to different FM/PSG frequency tables; that $E1 coordination flag is also giving me headaches as I hadn't considered its effects in the previous version of my tool, and I will have to redump all songs -- or hand-edit them all, which is more-or-less the same amount of work.

 

Ouch. Well, at least the extra work will make another coord flag work. so it should be worth it. Patiently waiting for your high quality work and modified driver . One more, simple thing you should add to the modified S&K driver is modifiying the zmake68kptr function. You should modify so that it is a macro, which, when (DebugSoundbanks<>0)&&(MomPass=1), tells the user what the pointer is for the currently processed song. This would be useful, because people could then see where their new music is going, instead of doing tells of hex math and guesswork when working with the banks.

Below is an example of what I mean. It almost works, but throws tons of errors, but you should be able to get an idea of what I mean, and on how to code it by fixing the errors and optimizing the code.

Code (Text):

1.  
2. zmake68kPtr macro addr,disp
3.     dw  (zROMWindow+(addr&7FFFh))
4.     if (DebugSoundbanks<>0)&&(MOMPASS=1)
5.         message "SMPS Item {disp} is at $\{Val(zROMWindow+(addr&7FFFh))}." ;errors occur at trying to process this line message, not sure how to concatenate text in a message in AS
6.     endif
7.     endm
8.  
9. zmake68kPtr2 function addr,zROMWindow+(addr&7FFFh)
10. ;-----
11. z80_MusicPointers:
12. zmake68kPtr Snd_AIZ1,"AIZ1"
13.         zmake68kPtr Snd_AIZ2,"AIZ2"
14.         zmake68kPtr Snd_HCZ1,"HCZ1"
15.         zmake68kPtr Snd_HCZ2,"HCZ2"
16.         zmake68kPtr Snd_MGZ1,"MGZ1"
17.         zmake68kPtr Snd_MGZ2,"MGZ2"
18. ;& etc ("&c")
19. ;-----
20. z80_SFXPointers:
21.         dw  zmake68kPtr2(Sound_33),zmake68kPtr2(Sound_34),zmake68kPtr2(Sound_35),zmake68kPtr2(Sound_36)
22.         dw  zmake68kPtr2(Sound_37),zmake68kPtr2(Sound_38),zmake68kPtr2(Sound_39),zmake68kPtr2(Sound_3A)
23.         dw  zmake68kPtr2(Sound_3B),zmake68kPtr2(Sound_3C),zmake68kPtr2(Sound_3D),zmake68kPtr2(Sound_3E)
24.         dw  zmake68kPtr2(Sound_3F)
25. ;&c
26. ;If you rly wanted to, you could make the sfx pointers use macro zmake68kPtr to display its pointer
27. ;the SEGA PCM sound should also use zmake68kPtr2
28.  

 

The SEGA PCM is uncompressed, unsigned 8-bit audio at 14700 KHz (that's 44100/3).

As for the SEGA screen, I managed to get something with this:

Code (Text):

1. Palette File: General/Title/Palettes/SK Sega and BG.bin
2. Mapping File: General/Title/Enigma Map/SK SEGA.bin
3. Art File: General/Title/Kosinski Art/SK Big SEGA.bin
4. Mapping Compression: Enigma
5. Art Compression: Kosinski
6. Palette Offset: 0x0
7. x-Size: 40
8. y-Size: 28
9. Tile Offset: 0x0

However, there's only a white outline. I'm not very familiar with PlaneED, so maybe I missed something.

I think telling the assembler to generate a listing would be generally more useful. A listing contains the whole source code along with the address of each line and the data generated by each instruction, plus a table of all symbols (names and values) after the code. You can ask AS to generate a listing by specifying the -L switch on the command line (add it in the build script you use); the file will be named <name of main source file>.lst (e.g.: sonic3k.lst for S3&K).

 

Thank you very much, this is a problem I've had on and off in the past, which would seem to fix itself when I added more to the game. Now I understand why, and this is a handy bit of information I'll never forget. Cheers. :D

Actually, there may be something else you guys can help with.
I've checked against an old build, and the mappings are identical, yet in the most recent builds, Sonic2's sonic has this problem in 1 frame:

 

It looks to me like a dynamic pattern load cues issue (I.e. wrong art tiles being loaded), but I can't know for sure with limited information, sorry.

Have a look at your DPLC.

 

Ridiculously, this can be the same problem again, assuming you haven't accidentally corrupted DPLCs or tiles.
As I remember you have several characters in your hack, right? Each of them has its own art (tiles). Let's say you placed their art in ROM one by one and properly aligned the first art. But if art files of your characters took more than 128 KB ($20000 bytes), they will go past the 'bank' border at some point.

If DMA attempts to transfer group of tiles which crosses the $20000 bank, after the bank ends it most likely warps to the beginning of this bank. I think this happened in you case. Look artifact tiles, they are Sonic 1 tiles. You don't see random pixels because you properly aligned your art to be exactly at the beginning of $20000 bank, so it starts from Sonic 1 art.

When you have loads of uncompressed art in one place DMA-transfered from ROM, this problem can be annoying.
You can put 'align $20000' before you include Sonic 2's art (before the label). This will align the art properly, but using way everywhere you can loose much ROM space.

I can also suggest a bit dirty way. If you won't add tiles to you arts, if you placed art one by one like I thought, this will help to save some space.

Code (ASM):

1.   cnop  $20*6,$20000

Put this before the first art, Sonic 1's art, remove 'align $20000' there and don't align any later art.
I can't see the exact number of tiles need to be shifted from your screenshot, so after you do this, the number of artifact tiles will increase (if I'm correct). Increase 6 in that expression (I.e. try 7, 8, 9, $A values etc). The artifact tiles in frame will grow, but at some point, the whole group of tiles will be pushed to another 'bank' and artifacts will disappear.

Well, this is quite dirty method, also, I'm not sure about it. Try it if only you want to keep more free space.

 

Unless I'm putting the -L param in the wrong place in the list of params in the batch file, all that is outputted in the lst file is this, which isn't very useful:

Code (Text):

1.  
2.  AS V1.42 Beta [Bld 55] - source file sonic3k.asm - page 1 - 10/11/2011 10:49:17
3.  
4.  
5.        1/       0 :                     ;
6.        2/       0 :                     ; ---------------------------------------------------------------------------
7.        3/       0 :                     ; º    This file is generated by The Interactive Disassembler (IDA)        º
8.        4/       0 :                     ; º    Copyright (c) 2003 by DataRescue sa/nv, <[email protected]>        º
9.        5/       0 :                     ; º  Licensed to: Michael Wolski - Personal Use    (1-user Standard 07/2003)   º
10.        6/       0 :                     ; ---------------------------------------------------------------------------
11.        7/       0 :                     ;
12.        8/       0 :                     ; File Name   : C:\SKDisasm\SONICNUC.BIN
13.        9/       0 :                     ; Format      : Binary File
14.       10/       0 :                     ; Base Address: 0000h Range: 0000h - 200000h Loaded length: 200000h
15.       11/       0 :                     ;
16.       12/       0 :                     ; 2006-12-31 - Original buildable disassembly, labeling, and formatting by Stealth
17.       13/       0 :                     ; Please list any revisions
18.       14/       0 :                    
19.       15/       0 :                     ; Processor:        68000
20.       16/       0 :                     ; Target Assembler: 680x0 Assembler in MRI compatible mode
21.       17/       0 :                     ; This file should be compiled with "as -M"
22.       18/       0 :                    
23.       19/       0 :                     ; ---------------------------------------------------------------------------
24.       20/       0 :                             cpu 68000
25.       21/       0 :                             include "sonic3k.macrosetup.asm"    ; include a few basic macros
26. (1)    1/       0 :                         padding off ; we don't want AS padding out dc.b instructions
27.  

 

Oh right, I forgot, you have to remove all the "listing off" directives in all source files (s2.asm, s2.sounddriver.asm and s2.macrosetup.asm for Sonic 2; sonic3k.macrosetup.asm and Sound/Z80 Sound Driver.asm for S&K). I don't even know why they're there at all; does it speed up assembly if you don't specify -L?

 

Yes, it does speed up assembly by 50%. With listing off, it took 15 seconds to assemble; with listing on, it took 30 seconds to assemble. Making a listing for the entire diasm (which makes a big-ass 20MB list file!), isn't really efficient when all I needed was the listing for the sound driver (400KB). I modified the disasm to only make a listing for the driver; to do so, all one needs to do is add "listing on" the top of the driver, and "listing off" at the end. Macrosetup should have "listing off". Thanks for the help; the listing has made debugging music alignments in the music banks much easier!

 

Anyone know how to increase the number of sprites Sonic can have in Sonic 2 (it's E0 normally I believe)?

For another more intricate query, I've been trying to get newly programmed attack to destroy boxes. It worked however the character's state resets after he hits the box, meaning the instant it breaks he resets from his attack and starts running instantly instead of finishing the attack. I tried editing programming in the monitor's break code and found this:

Code (Text):

1. obj_26_sub_4:
2.     move.b  status(a0),d0
3.     andi.b  #%01111000,d0
4.     beq.s   loc_127EC
5.     move.b  d0,d1
6.     andi.b  #%00101000,d1
7.     beq.s   loc_127DA
8.     andi.b  #%11010111,(MainCharacter+status).w
9.     ;ori.b  #2,(MainCharacter+status).w
10.  
11. loc_127DA:
12.     andi.b  #%01010000,d0
13.     beq.s   loc_127EC
14.     andi.b  #%11010111,(Sidekick+status).w
15.     ori.b   #2,(Sidekick+status).w

By cancelling out that one line the attack works properly. However I'd like to know what exactly it is. I get it changes the status of the character as they interact with the box, but I don't what ori.b does. If I had more knowledge of what it was it could be useful for programming the attack on other objects in the game (eg. Hill Top rocks).

 

OR (ORI when the first operand is immediate data) performs a bitwise OR on the source and the destination and stores the result in the destination. For an explanation of bitwise operations, see Wikipedia's article.

In this case, the ORI forces bit 1 to be set (2 is %00000010 in binary, so it has only bit 1 set) without affecting the other bits. Bit 1 in the status field for players (Sonic and Tails) is the "in the air" flag. If a player is standing on or pushing the monitor when it's being broken, the "standing on something" and "pushing something" flags are cleared (that's what the ANDI's on the status field do) and the "in the air" flag is set (using ORI).

 

Okay then, I think I get it. I take it the in air flag is what caused the attack to cancel out (being on ground).

Also some minor cosmetic queries if anyone can help (yeah this always happens after I ask a question here):

* Does anyone know if or where you can edit the character animations used in the Tornado scenes?

* Does anyone know how to edit the Special Stage end results messages?

EDIT: Ignore the Tornado query, figured it out.

 

Hey guys, I've disappeared out of the realm of the internet for a while, but it's always nice to be here. I'm considering doing a music hack of Sonic CD as a project for my degree, and I was wondering, how much is known about the PCM 'Past' music in the game? Is it possible to hack it out altogether? (I know disk space is an issue, but I could try getting around that with compressed music). Or otherwise, how simple is it to code new music into these sections? Is it more or less the same as with the Mega Drive games, or are there specific tools? I'm just throwing out ideas at the moment, so any help would be really appreciated.

Many thanks