- Thread starter djsheep
- Start date
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.
Here is a video from my F3 system showing the spot where it happens:
Darius Gaiden Extra ~ Stage D Bug ~ real hardware
(missing background and water surface)
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
'
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.
Unpatched (official MAME):
Patched with files from this thread:
Here is a video from my F3 system showing the spot where it happens:
Darius Gaiden Extra ~ Stage D Bug ~ real hardware
(missing background and water surface)
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
'- Release MAME 0.215 build with official dariusgx romset
(missing background)
- MAME 0.215 with the MAME workaround active, official dariusgx romset
(meaning, commenting out the #ifdefs here, and adding "int m_f3_skip_this_frame;" here)
(background appears, but the water surface is missing)
- Release MAME 0.215 with the patch from this thread applied to dariusgx.zip
(missing background, missing ocean ground and extreme slowdown as soon as the ship goes underwater)
- MAME 0.215 with the patch applied *and* the MAME workaround active
(background appears, missing water surface, the extreme slowdown returns, and part of the water surface pops up at the upper edge of the screen)
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.
Unpatched (official MAME):
802e91695a526f665c7fd261f0a7639a0b883c9e d87-01.bin
07cae8edbc3cca0a95022d9b40a5c18a55350b67 d87-02.bin
35ba7bcf29ec7a8f8b6944ee3544693d4df1bfc2 d87-03.bin
003f98b740a697274385b8da03c78f3c6f7b5e89 d87-04.bin
fd08d848079841c9237fa359a850980fd00114d8 d87-05.bin
72cdeffedeab0c1bd0e47f03172085390a2be393 d87-06.bin
ca53ea6641182c44a4038bbeaa5effb1687f1980 d87-08.bin
28692b731ae98a47c2c5e11a8a71b61a813d9a64 d87-13.bin
6eb238e47bc7bf635ffbdbb25fb06a37db980ef8 d87-14.bin
256a6aeb5633fe1db407fad567169a9d0c911219 d87-17.bin
402e26a05f1c3162fa3a8d3fcb81ef334b733699 dge_mpr0.bin
841396911d26ddfae0c9863431e02e0b5e762ac6 dge_mpr1.bin
4764355f51e207f4538dd753aea59bf2689835de dge_mpr2.bin
eafde331c3be5be55d0d838a84017f357ff92634 dge_mpr3.bin
07cae8edbc3cca0a95022d9b40a5c18a55350b67 d87-02.bin
35ba7bcf29ec7a8f8b6944ee3544693d4df1bfc2 d87-03.bin
003f98b740a697274385b8da03c78f3c6f7b5e89 d87-04.bin
fd08d848079841c9237fa359a850980fd00114d8 d87-05.bin
72cdeffedeab0c1bd0e47f03172085390a2be393 d87-06.bin
ca53ea6641182c44a4038bbeaa5effb1687f1980 d87-08.bin
28692b731ae98a47c2c5e11a8a71b61a813d9a64 d87-13.bin
6eb238e47bc7bf635ffbdbb25fb06a37db980ef8 d87-14.bin
256a6aeb5633fe1db407fad567169a9d0c911219 d87-17.bin
402e26a05f1c3162fa3a8d3fcb81ef334b733699 dge_mpr0.bin
841396911d26ddfae0c9863431e02e0b5e762ac6 dge_mpr1.bin
4764355f51e207f4538dd753aea59bf2689835de dge_mpr2.bin
eafde331c3be5be55d0d838a84017f357ff92634 dge_mpr3.bin
Patched with files from this thread:
Only these are different:
9d02e56e2cd2df9e9a9dadaf08016620ee1efa5b dge_mpr0.bin
66da29d6c66c0f34362a2f1dcfc62ae68304ea55 dge_mpr2.bin
9d02e56e2cd2df9e9a9dadaf08016620ee1efa5b dge_mpr0.bin
66da29d6c66c0f34362a2f1dcfc62ae68304ea55 dge_mpr2.bin
Last edited:
The beginning of Zone X in Player 2 mode would come to mind. Let me quickly pick up on this past post as an entry point:
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.
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
e: TMF68k's video (this post) is normal Darius Gaiden - demonstrates how it *should* look in Extra. All A-ok.
Last edited:
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?
Hmm..
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?
Hmm..
Attachments
Last edited:
that would be my assumption. How different is the code that was on that Eprom from the one that you replaced. IIRC there is like 3-4 bytes difference.
Right, 3 bytes are different overall.
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.
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.
Attachments
Last edited:
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)?
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:
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.
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
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,
Bash:
cat d87-09.bin >> dariusg_dual_mpr0_patched.bin
cat dariusgx.12.oddbytes >> dariusg_dual_mpr0_patched.bin
cat d87-11.bin >> dariusg_dual_mpr2_patched.bin
cat dariusgx.13.oddbytes >> dariusg_dual_mpr2_patched.binsha1(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.
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.
Attachments
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.
View: https://youtu.be/FDDRDeRtlM4
I am hoping for a fix for Darksoft.
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.
I am hoping for a fix for Darksoft.
Thank you.
Looking forward to it.
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.
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.
