Chaotix 1207 discussion

Ugh bumping. It's been a long time since this all happened. Feels almost like yesterday.

I wanted to see what was going on with the audio. Still unclear as to why it's producing the sound exactly (even though drx mentioned it on the first page), I decided to disassemble the sound driver (z80) based on the great disassembly ValleyBell did on the final (U) version.

You can download the IDB database and an asm output for both here (you need IDA Pro 6.1 to open the database):

http://www.mediafire.com/download/v8ekqx94a2cusul/chaotix_snddvr_disassembly.zip

Note though, my disassembly is pretty much poo because I'm still pretty much an amateur at IDA Pro. So aesthetics aside, the sound driver used in this prototype is almost identical to the final version but there are some differences. I believe all the subroutines are there, but some instructions were added to a handful of them for the final version. Another oddity, which might be due to my inability to use IDA Pro, I think the instructions that reference data locations that come mostly after all the code are all pointing the the wrong locations. Also note that I have no knowledge of the Z80 or how the sound drivers in these games actually work. I really just wanted to mention this just in case someone might want to take a crack at it. If this has any impact on the audio issue, I don't know, but it's a start at least.

Here are some differences I noticed:
1.) At 0x38, "VInt" is missing instructions that loads 0 to register 'a' and adds $80 to 'a' in a loop. The prototype just disables interrupts and calls "ProcessSndQueue" and "sub_A4" right away before returning.
2.) As stated somewhere before, there's a string from the sound driver programmer in every version. The final version however, is truncated possibly due to the added instructions mentioned before. The prototype has the full string - "casablanca version by MILPO". Nothing seems to reference this string AFAIK.
3.) At 0x204, the disassembly for the final version notes that "ex af, af'" is dead code. This code doesn't exist in the prototype, but space for it does exist. I added the line back manually in my database, but note that it wasn't there originally.
4.) At 0x4C1, the final compares $2A with the accumulator and the following instruction jumps to PlayBGM ($00-$29 for a total of 41 music tracks?), while at 0x4C3 if compares $6F with the accumulator and the following instruction jumps to PlaySFX ($2A-$6E for a total of 68 sound effects?). The prototype is slightly different in this regard - the prototype compares $29 instead of $2A making for a possible total of 40 music tracks while also comparing $69 instead of $6F for a total of 63 sound effects if my math is correct.
5.) At 0x500, the beginning of PlayBGM is different. At the start of the label, the final ORs with the accumulator 'a' and returns 'z' (zero flag) and finally decrements the accumulator 'a' before the first "ex af, af'" instruction. The prototype just decrements the accumulator and returns 'm' before the first "ex af, af'" instruction.
6.) At 0x60F, the instruction subtracts $2A in the final and $29 in the prototype from the accumulator, related to sound effects.
7.) At 0x814(final)/0x813(proto), "PauseAudio" doesn't return in the prototype but does in the final. The Final calls sub_E58 after calling "PSGSilenceAll", which does something. The prototype makes no such call after "PSGSilenceAll". The equivalent subroutine to sub_E58 is sub_E53 in the prototype.
8.) Under "ProcessSndQueue", the final does this:

Code (ASM):

1. RAM:0885                 jp      m, ShiftSoundQueue ; Jump (conditional & unconditional)
2. RAM:0888                 sub     2Ah ; '*'       ; Subtract from A
3. RAM:088A                 jr      c, ShiftSoundQueue ; Jump relative (conditional & unconditional)
4.  

While the prototype does this:

Code (ASM):

1. ROM:0880                 sub     28h ; '('       ; Subtract from A
2. ROM:0882                 jp      c, ShiftSoundQueue ; Jump (conditional & unconditional)
3. ROM:0885                 sub     1               ; Subtract from A
4.  

That's pretty much all there is as far as code changes go. I didn't look through the data that comes after all this though.

 

I relabelled the Chaotix disassembly a while ago so that it uses the same labels and names as all the other disassemblies I did. You can download the "new" disassembly here.
It also includes a Chaotix 1207 with the new labels, a Sonic Crackers disassembly and a disassembly of the Chaotix PWM driver. The offsets of this one are wrong though, I'm working on redoing that one.

So let's list the changes:
1. Beta:

Code (Text):

1.  
2. VInt:
3.         di
4.         call    DoSoundQueue
5.         call    UpdateAll
6.         ret

Final:

Code (Text):

1. VInt:
2.         di
3.         call    loc_3C
4. loc_3C:                 ; DATA XREF: RAM:loc_40w
5.         ld  a, 0
6.         add a, 80h
7. loc_40:
8.         ld  (loc_3C+1), a
9.         jr  nc, locret_4B
10.         call    DoSoundQueue
11.         call    UpdateAll
12. locret_4B:              ; CODE XREF: RAM:0043j
13.         ret

I haven't check this in the PAL version yet, but I assume the added code is responsible for the PAL tempo fix.

2. I have nothing to add here.

3. The dead code exists in almost all SMPS Z80 drivers. That includes the Chatoix beta. The Z80 instruction " ex af, af' " has the code byte 08. (In IDA, click on the "db 8" and press 'C' to turn it into code.)

4. Beta:

Code (Text):

1. PlaySoundID:                ; CODE XREF: UpdateAll+9p
2.         ld  a, (byte_1C09)  ; read Sound ID
3.         cp  29h
4.         jp  c, PlayMusic    ; 00-28 - Music
5.         cp  69h
6.         jp  c, PlaySFX  ; 29-68 - SFX

Final:

Code (Text):

1. PlaySoundID:                ; CODE XREF: UpdateAll+9p
2.         ld  a, (byte_1C09)  ; read Sound ID
3.         cp  2Ah
4.         jp  c, PlayMusic    ; 00-29 - Music
5.         cp  6Fh
6.         jp  c, PlaySFX  ; 2A-6E - SFX

I think the comments make it obvious what they changed - they added 1 song and 5 SFX.

5. Beta:

Code (Text):

1.  
2. PlayMusic:              ; CODE XREF: PlaySoundID+5j
3.         dec a
4.         ret m

Final:

Code (Text):

1.  
2. PlayMusic:              ; CODE XREF: PlaySoundID+5j
3.         or  a
4.         ret z
5.         dec a

The code does exactly the same in both versions. I have no idea why they changed it. It makes sure that Sound ID 00 does nothing. (The Beta code would also do nothing for 81-FF, but PlayMusic is never called for these IDs.)

6. Beta:

Code (Text):

1.  
2. PlaySFX:                ; CODE XREF: PlaySoundID+Aj
3.     ...
4.         ex  af, af'
5.         sub 29h     ; Sound ID -> SFX Index
6.         ex  af, af'

Final:

Code (Text):

1.  
2. PlaySFX:                ; CODE XREF: PlaySoundID+Aj
3.     ...
4.         ex  af, af'
5.         sub 2Ah     ; Sound ID -> SFX Index
6.         ex  af, af'

7. Beta:

Code (Text):

1.  
2. SilenceAll:             ; CODE XREF: DoPause+Ej
3.         call    PSGSilenceAll
4.         push    bc

Final:

Code (Text):

1.  
2. SilenceAll:             ; CODE XREF: DoPause+Ej
3.         call    PSGSilenceAll
4.         call    SendPSGState
5.         push    bc

In the beta, the PSGSilenceAll has no effect, because all PSG commands are stored in a buffer. The added instruction in the final makes sure that the PSG commands are sent to the chip and all PSG notes are stopped.
The added "ret" instruction at the end of the DoPause routine is a small optimization. In the beta it just falls through to the next code and executes PSGSilenceAll again.

8. Beta:

Code (Text):

1. DoSoundQueue:               ; CODE XREF: RAM:0039p
2.     ...
3.         sub 28h
4.         jp  c, DequeueSound
5.         sub 1   ; Here it effectively did "sub 29h

Final:

Code (Text):

1. DoSoundQueue:               ; CODE XREF: RAM:0039p
2.     ...
3.         jp  m, DequeueSound ; jump if 80-FF
4.         sub 2Ah
5.         jr  c, DequeueSound

In the final, it makes sure that sound commands (FadeOutMusic, StopAllSound, etc., they have the IDs E0-FF) are ignored by the sound priority system. The beta only ignores songs.

The data for modulation envelopes and PSG instruments is the same.

btw: Most of the information in the wiki about changed songs between the 1207 beta and the final version of Chaotix is wrong. There are 3 songs with major differences. I'll just quote my .txt file:

Code (Text):

1. - The intro of "Oriental Legend" is a lot longer than in the final.
2. - "Decision" is split into 2 parts in the final. In this beta it just loops once and finishes then.
3. - In the final, "This Horizon" has an additional intro that is missing here.
4. - All other songs either match exactly or have a slightly higher PSG 3 volume.

The actual issue with the sound is caused by the PWM driver. So far I was able to port the beta PWM driver to Chaotix final (after fixing some offsets). Considering how it sounds I assume that it is unable to play "silence" correctly.


The Chaotix sound driver is pretty much the same as the one in Sonic Crackers, just without the DAC channel and with 4 additional PWM channels.

 

Since this was mentioned recently (and is popping up from time to time), let me correct this popular wrong fact:

The PWM noises you hear in the Chaotix prototypes are not caused by different hardware revisions.
The actual cause is a bug in the PWM driver. (I did some research in 2014 when I added the Chaotix proto to my SMPS archive.)

The PWM driver used by Chatoix does 4-channel mixing and also performs a linear interpolation when upsampling from the internal 11 KHz processing rate to the 22 KHz sample rate sent to the PWM FIFO.
During that process, it uses the registers R4-R7 to store the current sample values. (R4/R5 = first sample for L/R speaker, R6/R7 = second sample for L/R speaker)
Due to buggy/incomplete interpolation code, registers R4/R5 aren't always written, introducing bad samples depending on the sample rate. (R4/R5 aren't even initialized, but that's not the main problem.)


Anyway, there is an easy way to fix this.

1. search for D013 4420 4620
2. replace 2041 2061 with 2061 2061
3. 6 bytes later, replace 2051 2071 with 2071 2071
4. fix the checksum by adding $0040 to it.

In the spoiler you can find the ASM code of what you just changed, for those who are interested.

Spoiler

Code (Text):

1. D013    mov.l   $4C(pc), r0     ; load "PWM FIFO Left Channel" address ($20004034)
2. 4420    shal    r4              ; sample L1 *= 2
3. 4620    shal    r6              ; sample L2 *= 2
4. 2041    move.w  r4, @r0         ; write sample L1 to FIFO
5. 2061    move.w  r6, @r0         ; write sample L2 to FIFO
6. D011    mov.l   $44(pc), r0     ; load "PWM FIFO Right Channel" address ($20004036)
7. 4520    shal    r5              ; sample R1 *= 2
8. 4720    shal    r7              ; sample R2 *= 2
9. 2051    move.w  r5, @r0         ; write sample R1 to FIFO
10. 2071    move.w  r7, @r0         ; write sample R2 to FIFO

In order to debug the PWM driver, I ported it from the Chaotix 1207 proto to the final version, because the proto doesn't boot in MAME/MESS. I can upload an IPS patch of the patched final Chaotix with proto PWM driver if anyone is interested.

 

That could be a good addition to its page at hidden-palace.org, seeing how it carries some fixes for other prototypes as well.

 

Sorry to come charging in but I have something that might be useful.

For years people have assumed that Sonic Studium is a typo for Stadium. However, studium is actually a Latin word and means 'study' or 'devotion', so somewhat translatable as "a Sonic study". As in, a Sonic prototype or experiment. I know Latin and the expression works.

I know it sounds maybe stretched but it makes far more sense than Sonic Stadium, which has nothing to do with Sonic Crackers. Also, Japanese developers sometimes use Latin as internal names (look at the Final Fantasy series).

Perhaps worth a thought :v:

 

From what I seem to remember, it was similar with Pokemon Crystal's unused text, which called it "MOBILE STUDIUM". It's a much safer bet to assume a mistranslation.

EDIT: Jesus Christ, didn't notice the date.

 

The ROM Header is called Sonic Zeal and one translation of studium in Latin is zeal (as in a zeal for study).

There might be something to the Latin word 'studium'. I mean, why would Chaotix even be called Stadium?

 

What? Which ROM header?

 

Why would it be called Sonic Zeal?

 

Because 'zeal' is one translation of 'studium'. However for Sonic Crackers, (and the most general translation) studium would mean a Sonic study or experiment. Makes sense considering what Sonic Crackers was. The guy who wrote the ROM Header probably looked the Latin word studium up and applied an awkward translation.

Also, I'm talking about the ROM Header fo Sonic Crackers (or maybe Chaotix 1207, can't remember for sure but it's one of them).

 

There's one internal document from STI that we have from around the time of Crackers that the game was usually referred to Sonic Stadium, not studium, as the next game from SoJ. Although I don't know why the game also used Crackers mostly, it's possible that the game had a different name based on region at some point (with Crackers being the title for Japan, Stadium being the localized one). None of the Chaotix prototypes had Crackers in the header, just the unused art for "SONIC CRACKERS S32X" in this prototype.

 

TCRF already beat you guys to the STUDIUM bit. It's a simple transliteration error:

 

I'd say there's a quite high probability for that text having been written by somebody from here (or Sonic Cult).

 

http://info.sonicretro.org/Game_Secrets:Sonic_Crackers

http://info.sonicretro.org/index.php?title=Game_Secrets:Sonic_Crackers&diff=66423&oldid=55417

Nice necro, though

 

Three posts or so above mine is a statement saying not to worry about bumping things in Archives as long as it's relevant :'D My apologies...

 

I was just thinking the other day how some things in the final Chaotix ROM weren't discovered for a few years after it was assumed people had gone through it. Any chance this possibly still has some stuff hidden in it, or has it been scraped dry?

 

I think there's some graphics that still haven't been found in the final ROM, which may be using a different compression algorithm.

 

Sometimes, rarely, when I play this prototype on an Everdrive and try to load Time Attack,
It will load a different, more fleshed out Atraction Select screen that looks intended for Time Attack, instead of the one usually loads and freezes because it's meant for World Entrance. It loads the level without crashing and has default times to beat! Three of the Isolated Island levels are there too as "Time Attack" levels. They're the same ones that are in the Stage Select and 0119's Time Attack.
Sorry for the crappy CRT photo.I'm not sure what triggers this but it's happened to me twice now. By far, the most interesting part is...



Who is Nuts?!

 

Maybe Heavy and Bomb were once known as Nuts and Bolts? :v:

EDIT:
Haven't been able to find the text strings in that menu (is all that stored as a static, mockup-ish screen?) but I did find some final ROM code from After Burner Complete between 0x3DC30 and 0x40000:

For reference, that game was released one month after this prototype's build date.