Only an issue on the multi: honestly, that was my impression too when I first had a quick look on this thread a few weeks ago. Came back recently and TMF68k's posts stood out to me. They seem to have a game cart very similar to mine; you can see the toggle switch that's used to switch between Gaiden and Gaiden Extra. "No, that can't be?" was my initial thought - went to check and yup, the bug is there, on a real cart (well, sans the changed ROMs due to it being a conversion). TMF68k also talked about how Extra always had bugs because it was rather unfinished and never an officially released game.
Neither my Framemeister nor my OSSC were able to capture the F3 (an often discussed problem I'm sure you know of already, but not relevant here...). So a camera recording shall suffice for now.
Furthermore, while I'm still baffled why it is that way, I've figured out how to make use of the patch (throw away every even byte). The filenames to overwrite I posted earlier were correct.
Was curious to see what happens at the beginning of Stage D in MAME (I used the current version, 0.215), and tried four different configurations (see below).
It's almost funny, because each configuration produces their own unique incarnation/appearance of the bug; the real hardware one is unique too, so that's five!
Behind each link is a corresponding video capture (sorry for the missing audio). It has taken me some time to prepare all this '
So yes, the game technically works in MAME, but the bug still appears (at least in the current version, which should be the benchmark).
Edit: that would mean that the patch is effective on real hardware, but only makes things worse on MAME?
Well, MAME emulation certainly is not the best Look at the boss explosion, the smaller orbs are definitely behind/much more covered up by the bigger explosion. On real hardware they're clearly in the foreground.
For confirmability, here are the sha1sums of the dariusgx romsets I used.
@6t8k great analysis. As you can see the error is a bit complicated to find and troubleshoot. Luckily we have a working version for both the multi and original cart as was confirmed by @TMF68k.
I'm not sure what else is to be fixed in the original.
It happens without the Multi as well, as can be seen e.g. in the Wasshoi in Tokaigi 2015 stream.
So I'd be very surprised if the Multi fixes it "unintentionally".
In other words, the Zone X bug was there in the game from the beginning, was not introduced by your Zone D patch from this thread, and is as of yet not fixed anywhere (to my knowledge)
MAME playthroughs show it as well, e.g. here
A quick digression back to the Zone D bug; as it's easily confused (at least I struggled with it at first): the Zone D bug only happens when playing as player 1 ("normal" Extra mode). The Zone X bug only happens when playing as player 2 ("marathon" mode).
What would be the Zone D of the player 2 mode (namely Zone P), is fine there. And conversely, Zone X, (and what can be seen of the actual player 2-Zone X graphics) in the player 1 mode, is fine there as well.
When looking for MAME gameplay of the player 1 mode, I'm currently only able to find videos where Zone D looks fine (barring mine I posted above). That's what @djsheep meant I suppose.
To me it looks like the MAME devs have introduced a regression recently.
Back to the player 2 Zone X bug, following the comments of @maldoror68, I think it's kind of a philosophical question if Extra should be patched further, it's just what the game is.
Seeing that Zone X is nothing as bad as the near-gamebreaking darkness that haunted Zone D, maybe it just adds to the charme.
I myself don't mind it, but other opinions could prefer it to be further polished.
As I understand it, there might also be something wrong with the BGM as per @maldoror68's reportings, but I would attribute that to the note above.
Addendum: and as goes without saying, none of this is has to do with yer olde, standard Darius Gaiden
Addendum 2: OK, this is riddling me again. Player 1 mode. Zone X is completely different in TMF68k's video than in this one. Why is this so complex :'D Well, the above is still correct, Player 1 Zone X is fine in any case (as opposed to Player 2).
e: TMF68k's video (this post) is normal Darius Gaiden - demonstrates how it *should* look in Extra. All A-ok.
Today I finally got around trying the patch on my F3 system with EPROMs (pic attached).
Surprisingly, it does not work (video). I must be missing something, since apparently, it did work for @TMF68k?
Like real hardware with unpatched ROMs, the background and water surface are missing.
With the patch, the ocean ground is also missing and the extreme slowdown happens on the real hardware. Before, I attributed that to some MAME glitch.
So this is another unique variation of this bug.
Genuinely puzzled at the moment. Any ideas on what could be causing it?
Supposing the ROMs are bad, I'd assume seeing all sorts of glitches or even a failure at boot time.
Could my conversion cart / the other ROMs be different from TMF68k's?
Attached two xxd | vimdiff screenshots (dge_mpr0 and dge_mpr2).
On the left is the patch, on the right is the original ROM.
Another theory that came to mind later is:
I have read somewhere that the Multi does something with the addressing of the games (I could err on that). The aforementioned "bytes in between" could have something to do with it. These bytes are missing in the ROM files when making them usable on a real cart in the daredevil way I did. Could it be that the patch is actually not designed to run in a non-Multi scenario? The question remains, though, how TMF68k got it to run on their cart. The only explanation I have is that they developed their own patch based on the info available up until that point without explicitly telling so.
But given your answer, that theory does seem to be disproven.
Can you change ONLY those 3 bytes on the eproms that you have replaced? The 3 bytes can be in 1, 2 or 3 different eproms. Sometimes the files can be splitted differently depending on the PCB that you have.
This finally convinced me to get an IC programmer, which I have here now.
So I read out the two M27C4001s that I previously removed to install the patch, and the contents are identical to the corresponding ones within the dariusgx romset as recorded by MAME. Meaning only those 3 bytes were changed (as per the diff I posted).
It seems as though my ROM PCB should be the same one that @TMF68k has (both have the ident J9100361A)?
Bump. Still trying to figure out why I can't make Darksoft's patch work on a real game cart.
To start with, there are actually 2 more patched bytes in dge_mpr0.bin/dariusgx.12, which I overlooked when I produced that diff appended to my Dec 11 post, making for a total of 5 changed bytes.
How is it possible to miss that using vimdiff? Well, just like that! Always scroll around and make sure you're really seeing everything there is to see before inferring anything from vimdiff output.. I updated the post above with the correct diff.
Moreover, I should perhaps note specifically that the M27C4001 I used in December is of a too small capacity for a dual cart like @TMF68k 's and mine, which has a switch that lets you choose between Gaiden and Gaiden Extra.
The M27C4001 has 512Kbyte, which is only enough for one of either Gaiden or Gaiden Extra. The M27C801 is actually the correct one for a dual scenario; it has double the amount of memory and is pin-compatible with the M27C4001 except for pin 1, which effectively controls whether the rest of the pins address the first or the second half of the memory - which is why the toggle switch is soldered onto that pin. I only used a 2xM27C4001, 2xM27C801 program ROM setup because I wanted to keep the unpatched ones for the time being and had no other spare EPROMs lying around.
However, none of these specifities are a reason why the patch doesn't work. With that out of the way, I took a fresh approach today.
First I read out the two other program ROMs for good measure, which I hadn'd touched yet (and aren't changed by Darksoft's patch); no problem here:
2nd program ROM (when counted from right to left):
first half is dariusg d87-10.bin, SHA1(57d36a62d490d9e53b6b80a92ea0e8c41d61799f)
second half is dariusgx dge_mpr1.bin, SHA1(841396911d26ddfae0c9863431e02e0b5e762ac6)
4th program ROM (when counted from right to left):
first half is dariusg d87-12.bin, SHA1(126464a826685f5bfab6cc099448ce4df207a407)
second half is dariusgx dge_mpr3.bin, SHA1(eafde331c3be5be55d0d838a84017f357ff92634)
I then erased the two M27C801s that have to be patched, plugged together the program data like this,
For posterity:
sha1(dariusgx.12.oddbytes) = 9d02e56e2cd2df9e9a9dadaf08016620ee1efa5b
sha1(dariusgx.13.oddbytes) = 66da29d6c66c0f34362a2f1dcfc62ae68304ea55
burnt the files onto the M27C801s and installed them on the PCB. The EPROMs were thus positioned as shown in my December 10 post (from right to left: mpr0, mpr1, mpr2, mpr3).
It still doesn't work, the symptoms are the same as previously described. I also tried it with a different motherboard (but a "M20E001B NEW F3 MOTHER(EUROPE)" as well), same result.
Do you have an example where else these bytes could be located / how the files could be split differently? Can you confirm the even "in-between" bytes I'm throwing away have nothing to do with it?
Does anybody else have this patch installed successfully (or unseccessfully) on a real cart? When I first read this thread it had about 4k views, now we're hitting 11k soon, so there must at least be some interest in this
Regarding the background of DARIUS GAIDEN EXTRA.
When playing on the 2P side with the corrected ROM, ZONE P has been corrected, but ZONE U is strange.
The background is now displayed, but the background of the previous ZONE T is displayed.
ZONE U had the same mistake as ZONE P.
U is the same stage in the ocean as P.
Darius Gaiden EXTRA
This is a screen bug video on the 2P side.
The MAME roms do not show the screen for about 2 sides.
The U-zone is still weird, even in the fixed version.
Here is the proof video.
So let me see if I can summarize what is wrong and unfinished by Taito that needs to be fixed:
GRAPHICS:
- ZONE U: The background of the previous ZONE T is displayed.
- ZONE X: graphic glitch in the "28 levels marathon mode" on player 2 side.
MUSIC:
-No music in level M (ice level)
-the music plays continuously between levels A and level C (no intermission music)
-no music in level C in marathon mode
These bugs happen in the original cart. These ARE NOT produced by the multi in any way. The game was not released bug-free.