Patching roms changes a lot in the roms, triggers in-game crashes

[Asure]

If i patch an existing rom set, with say a single .wav file that fits into existing rom space (let's say 4 roms ,U2 to U5), the U2 rom does not change as i would expect. All roms change.

My test case:
To add to an existing ROM i would have a Stream with a filename, and a track playing that stream.

Expected result:
I would expect that almost nothing changes in U2. (CRC and signature perhaps)
I would expect that the track pointer ends up at $4048+x3 track value(402). (=4C4E), it does.
I have double checked that there is free space at $4C4E in this rom set.

However, i see that the track pointers all have changed, and the positions of the samples in rom as well.
Rom U2 changes from $400A.

Is it possible to just keep the order as it was and dump the new additions into U6 which is free?

The reason for this is that we are adding a lot of samples to a rom, and every now and then we run into strange problems.
In-game, there is popping or garbles during playback, and sometimes a stream of static which causes a crash when testing the results with MAME.
It is very hard to debug the exact cause of the crash/pops/garbles because this game makes a whole load of sounds.
Changing parameters like bitrate and powercut solves it sometimes, but i'm thinking there could be samples that still trigger a crash, that just never get played. The game has hundreds of sound calls (NBA Hangtime) and it's nearly impossible to debug that.
Last time i fixed it by setting "type=0 subtype=0" but it just feels like a random fix, that i'm still not sure of.

DCSExplorer idents this version as:
Version: DCS audio board, Software 1.01 (1993)

Do you have any suggestions as to what could cause this, and if there's any way i can properly debug the cause of these crashes?
I guess a first step would be to find some way to reproduce & present a broken + original set of dcs roms right?

[mjrgh]

It's been a couple of years since I looked at this, so I might not be remembering the algorithms correctly, but from what I recall, I actually WOULD expect the ROM layout to be completely changed, even after a simple patch replacing a single track. Here's why. A "patch" only differs from a completely original ROM creation in that the patch copies over all of the track and stream data from the original, except for the track or tracks that you replace. The key here is that it's still creating an entirely new ROM set, just like if you created a new ROM completely from scratch. The process of generating the new ROM set is the same in both cases: starting with an empty ROM address space, the compiler appends each stream referenced in each track to the end of the ROM space. The order of streams in the new ROM might differ from that in the original ROM, because the DCS format doesn't define (as far as I can tell) any specific ordering of the streams - there's no "correct" or "natural" ordering, just the accidental ordering of however the streams appeared in the compiler's internal list. This is definitely true of DCS Explorer's compiler, and I assume it was also true of the original compiler the manufacturer used. So DCS Explorer doesn't attempt to reproduce the original stream ordering - it's just an accident of the internal organization of the compiler's internal representation of the data while it's creating the new ROM.

It sounds like what you want is an option to generate the new ROM with as much stability as possible in the stream layout in memory, not only copying the stream data verbatim (already true for unmodified tracks during a patch), but also maintaining their original locations in ROM. That's certainly possible - the compiler could be contrived to just copy the old ROM stream layout into the new ROM, and place all new/modified streams in previously unused space after the last pre-existing stream. I'm not sure how much work would be involved in that.

[Asure]

Yes, such an option would be perfect as it helps debugging on real hardware and would benefit others too.
(Patching a rom would then also mean users only burn 1-2 new roms (a2 + new a6 for example) and keep the rest original.)

I'm still unable to tell what causes crashes but i really feel like it's caused by the patched romset.
(Placing back the original DCS roms solves the problem, even if we have non-existing sound calls in place.)

[Asure]

I've been able to track down a crash-causing sound number and can reproduce it 100%.
It's a sound already in orig rom, nothing i added.
I can fix it by changing bitrates etc so the sound sample shifts around, but then something else will break.
(This rom has a ton of samples and it's by luck that i managed to create a rom where i can pinpoint a sound that causes a crash.)

output:
nbatest10.zip

orig:
nba.zip

Mame debug dcs trace:
dcs-trace.zip

Playing sound 0x01a8 with MAME (x64, latest) causes the DCS cpu to crash.
Playing the same sound with DCSexplorer seems fine.

Comparing track/program output from orig and new prog seems the same except the stream pointer differs.

--- Original rom ---
Track $01a6 Channel 4 {    // Address $00086ed [U2 $086ed], Time 1482.24ms
    SetMixingLevel(level 90);                                       // 0000 07 04 5A
    SetMixingLevel(channel 0, decrease 127);                        // 0000 09 00 7F
    Play(stream $3DB804);                                           // 0000 01 04 3DB804 01
    Wait(134) SetMixingLevel(channel 0, increase 127, steps 58);    // 0086 0B 00 7F 003A
    Wait(59) End;                                                   // 003B 00
};

--- Newly created rom ---
Track $01a6 Channel 4 {    // Address $00087ef [U2 $087ef], Time 1482.24ms
    SetMixingLevel(level 90);                                       // 0000 07 04 5A
    SetMixingLevel(channel 0, decrease 127);                        // 0000 09 00 7F
    Play(stream $17C580);                                           // 0000 01 04 17C580 01
    Wait(134) SetMixingLevel(channel 0, increase 127, steps 58);    // 0086 0B 00 7F 003A
    Wait(59) End;                                                   // 003B 00
};

Maybe this can help pinpoint the issue?

Side note: i have similar issues with a romset i'm building from scratch, but it too has a lot of streams and a large program, and it's difficult to pinpoint the crash-causing command/stream.

[mjrgh]

Have you tried the generated ROMs on a physical DCS board? That might be useful to try, to see if this is actually a MAME bug, especially given that you pointed out that it's not crashing DCSExplorer on playback. I took a quick look at the MAME trace you attached, and it looks like what's going on is that a portion of program memory is getting zeroed at some point in playback. The curious thing about that is that ADSP-2100 is a (rare these days) Harvard Architecture machine, meaning that program memory and data memory are in separate address spaces, so that ordinary memory writes physically can't affect program storage. Looking at the trace, it doesn't look like there are any writes to program storage after the initial boot sequence (where a program overlay is loaded, kind of like a modern DLL) - in normal operation, DCS loads the program overlay at boot time and never touches the program storage space again. And it looks like the program is faithfully following that plan... and yet, this little section of program storage is getting zeroed somehow. It makes me suspect that MAME might be the responsible party here: EVEN IF the generated ROM data is ill-formed in such a way that it's causing the DCS control program (i.e., the ADSP-2100 machine code) to misbehave, it shouldn't be physically possible on a physical ADSP-2100 for that misbehavior to cause the observed effect of zeroing a portion of program storage, because of the physical architecture of the chip. But I can't rule that out entirely, because the DCS boards are more than just the ADSP-2100; they also do some of their own memory mapping external to the chip, so it's possible there's an interaction with the memory mapper that's getting involved and letting the DCS control program somehow update program storage without explicitly using the program storage write instructions (PM(x) = y). Testing on a physical DCS board would probably settle this question.

Assuming it's not a MAME bug - that a physical DCS board behaves the same way and crashes the DCS control program at the same point - my next guess would be that there's some subtle alignment requirement that I didn't uncover, probably in the way the stream starts are aligned. Merely moving a stream to a new starting address, without changing any of its contents, could trigger such a problem if the new location doesn't have the same magic alignment as the old location. I did discover one such requirement, which is documented in the DCS Format Reference, which arises from the way an auto-increment indexing window is constructed in the stream decoder. The stream decoder sets up a window with a 2-byte wrap mask for the compressed bit vector decoder, and the 2-byte mask implicitly requires that the bit stream be aligned on an even address boundary. There might be another one of those lurking somewhere that I didn't recognize, maybe with a 4-byte or 8-byte wrap mask, which would make the even-alignment requirement not strict enough. That would be another way to explain the discrepancy between MAME (crashing) and DCS Explorer (not crashing), since DCS Explorer has its own decoder that doesn't depend on such peculiarities of the ADSP-2100 hardware. I suppose it might be worth experimentally just trying some larger alignment sizes and see if that fixes it, since that would be low-effort. If it is something like that, understanding the root cause is probably going to require someone to spend a couple of weeks tracing through the ADSP-2100 code - it's been several years since I looked at it so none of this is fresh enough in my mind to spot anything intuitively.

[mjrgh]

It occurs to me that another test to try would be to run the modified ROMs in the DCSExplorer emulator mode (--decoder emulator-strict or emulator-fast). That would run it under the DCSExplorer version of the emulator, which is an independent implementation of the MAME emulator, so it might offer a weak second opinion on whether or not it's a MAME bug. The DCSExplorer emulator uses essentially the same ADSP-2100 CPU emulator core that MAME does, so if the crash is due to a bug in the ADSP-2100 CPU portion of the emulator, it'll probably replicate in a similar way under DCSExplorer and thus this won't shed any new light on it. But DCSExplorer uses an independent implementation of the rest of the DCS hardware, so if there's a MAME bug in that part of the code, this test might turn up an obvious difference in behavior, and that would be highly suggestive that it's a MAME bug. And finally, even if it does crash, it might at least be a little easier to debug the crash in the DCSExplorer emulator environment than in MAME, since it doesn't drag in the rest of the MAME system.

[Asure]

Maybe i'm doing something wrong?

DCSExplorer --decoder=emulator-strict rom.zip

Loads & resets the system, allows me to send one command but hangs after that, requiring ctrl-c to exit.
It also does not play the track i sent to it.

DCSExplorer --decoder=emulator-fast rom.zip
Loads and then just exits to the command line after the reset bong.

Debug option shows both do the JMP $0008 and then hang/exit.

Using latest 1.1 rel.

Edit: Testing with an original rom set, from NBA Hangtime. Tried Theatre of Magic, and that works fine. No clue why this causes an issue, both are 1.1 (1993) type.

[mjrgh]

It might be different manifestation of the same problem that's crashing MAME, or just an entirely unrelated bug in the DCSExplorer emulator. This is the NBATEST10.ZIP attached above? I'll try to take a look when I have a chance.

[Asure]

Both the nbatest10.zip (which is the end product of a program i'm working) and the original NBA.ZIP (which is original Midway production roms) have this problem, as well as the Killer Instinct (Midway original production) rom set.

I've attached the original NBA Hangtime and KI roms to this post for convenience .

nba.zip

kidcs.zip