Quantcast

Page 4 of 4 FirstFirst 1234
Results 46 to 53 of 53

Thread: Hellfire sounds slow on my Model 2

  1. #46
    Raging in the Streets xelement5x's Avatar
    Join Date
    Feb 2011
    Location
    Southwest USA
    Age
    40
    Posts
    4,316
    Rep Power
    71

    Default

    Wow, that is awesome devotion to fixing the issue.
    Quote Originally Posted by StarMist View Post
    A spine card is the hymen of a new game assuring its first owner that he is truly her one and only, and of a used game assuring its new owner that whilst she has been played with in the past that play has never been too careless or thorough.

  2. #47
    Creator of the Mega Amp Raging in the Streets Ace's Avatar
    Join Date
    Jun 2008
    Location
    Montreal, QC, Canada
    Age
    29
    Posts
    3,737
    Rep Power
    43

    Default

    Quote Originally Posted by Eke-Eke View Post
    From my tests on VA4 MD1 (with discrete YM2612) and VA0 MD2 (with 315-5660 ASIC), it appears that FM BUSY bit can only be read from address 0 (4000h) with discrete YM2612, while the integrated version in Sega ASIC returns it on all 4 possible addresses.
    This contradicts what you said earlier in the thread:

    Quote Originally Posted by Eke-Eke View Post
    From what I remember, the issue was caused by Hellfire reading the FM BUSY flag from address $4001 or $4003 (whichever address was written just before) and, for some reason, the ASIC-integrated YM3438 core does not return valid FM status from these addresses. There is even a Sega Bulletin from Sept. 1991 that says to only read FM status from address $4000.
    Which one is correct? Also, what about Earthworm Jim? Removing the FM BUSY read from $4002 outright fixes the music pacing glitch on pre-VA7 Genesis Model 1s and the VA2(.3) Genesis Model 2; it's like the game expects the address to return nothing. I'm confused here.
    HATES ATGAMES WITH A PASSION


    Mega Amp: An all-new audio circuit for your Sega Genesis/MegaDrive and clones.

    Note: If you want to contact me on Skype, identify yourself or your contact request will be rejected.

  3. #48
    Raging in the Streets Sik's Avatar
    Join Date
    Jan 2011
    Posts
    3,625
    Rep Power
    65

    Default

    Quote Originally Posted by Ace View Post
    This contradicts what you said earlier in the thread:

    Which one is correct?
    The newest post, in the older one he was just trying to recall from memory (and memory is man's worst friend =P).

  4. #49
    Sports Talker
    Join Date
    Oct 2012
    Posts
    41
    Rep Power
    0

    Default

    Quote Originally Posted by Eke-Eke View Post

    I've attached two IPS patches:

    - the first will patch the Z80 program code to always read FM status from address 0: this makes the music being similarly slow on both MD1 & MD2, probably not useful to anyone but it served me to confirm my theory

    - the 2nd one patch remove the BUSY flag wait in Z80 program code: this makes the music run as fast on MD2 as it does on MD1

    They should be applied on US version of Hellfire
    I never got around to fiddling with how to debug Genesis code. Thank you for making the effort to do this.

    Consider me ignorant, but is there any way this IPS for fixing the MD2 can be translated to Game Genie codes?


    EDIT:

    I opened the Hellfire (USA) [ASIC FM sound speed fix].ips file in a binary editor and reading about the format of IPS here (http://www.smwiki.net/wiki/IPS_file_format), I used this online tool (http://www.d.umn.edu/~bold0070/proje...oders.html#gen) to convert to Game Genie codes. However, it doesn't seem to work on an model 2.

    The codes I generated using the tool are:
    AA7T-CADS
    AA7T-CAEB

    Did I do something wrong?

    When I boot Hellfire with the Game Genie switched on, nothing boots. If I turn the Genie off, enter the codes, boot the game, the game starts, switch on the Genie, the music is still slow.

    Strangely, if I hit reset, the Genie changes the codes entered to:
    AA7T-CADR
    AA7T-CAEA
    Last edited by yZoneFox; 04-04-2017 at 03:22 PM.

  5. #50
    WCPO Agent CrossBow's Avatar
    Join Date
    Feb 2017
    Location
    Ivory Tower Collections
    Posts
    765
    Rep Power
    11

    Default

    Not sure this is helpful in the least...

    But I tested Hellfire and EWJ 1 on my modded va2 model 1. Like Evildragon (Who apparently isn't around here anymore), I have a discrete YM3438 added ontop of the 2612 in my Genesis. Hellfire sounds correct, and while there is a very tiny bit, the EWJ doesn't lack in the pacing nearly as much as it would normally. I really wish there was a dedicated sound test in the first EWJ, but the debug menu has no such animal, unlike the sequel's menu. If there were, I would more than happily record it.

  6. #51
    Wildside Expert
    Join Date
    Nov 2008
    Posts
    104
    Rep Power
    16

    Default

    Quote Originally Posted by Ace View Post
    Which one is correct?
    Last one, it's based on recent hardware tests while former one was based on unverified assumptions and bad memory

    Quote Originally Posted by Ace View Post
    Also, what about Earthworm Jim? Removing the FM BUSY read from $4002 outright fixes the music pacing glitch on pre-VA7 Genesis Model 1s and the VA2(.3) Genesis Model 2; it's like the game expects the address to return nothing. I'm confused here.
    I don't know, I didn't looked at that game and I am not sure what sound differences exactly I should look for in provided recordings, sorry.
    What is sure is that reading from $4002 on models with discrete YM2612 is exactly like reading nothing when it comes to BUSY flag.


    The codes I generated using the tool are:
    AA7T-CADS
    AA7T-CAEB

    Did I do something wrong?
    Those codes would correspond to following address patches

    013B6F:0000
    013B81:0000

    Game Genie hardware however can only handle patches as 16-bit words: patch address lowest bit is always ignored to compare it with ROM read address (which is always an even address) .

    The consequence is that those codes are actually decoded as

    013B6E:0000
    013B80:0000

    which is wrong (this also explains why your codes are changed back on reset)

    The correct patches would be

    013B6E:0700
    013B70:00FD
    013B80:0700
    013B82:00FD

    with the original (untouched) ROM values in bold

    In Game Genie format, this gives:

    AA7T-CRDR
    9Y7T-CADT
    AA7T-CREA
    9Y7T-CAEC

  7. #52
    Sports Talker
    Join Date
    Oct 2012
    Posts
    41
    Rep Power
    0

    Default

    Quote Originally Posted by Eke-Eke View Post

    In Game Genie format, this gives:

    AA7T-CRDR
    9Y7T-CADT
    AA7T-CREA
    9Y7T-CAEC
    Fantastic!

    I know this next question is off-topic but maybe since I have you on the line here, could give me a quick primer for this translation? You already gave me a few bits. It would be helpful if I ever want to do IPS file to Sega Genesis Game Genie code translation in the future.

    The wiki said the format would be
    - PATCH ASCII string, the header of the file
    - (Records) Any number of records and/or RLE records (I interpreted the data as simply record format and not RLE format)
    - EOF ASCII string, the footer of the file
    - (Truncate) Truncate data is stored after the EOF

    Each record formatted as:
    Address (3 bytes) The start address of the data to modify
    Length (2 bytes) The length of the following data (greater than zero)
    Data ("Length" bytes) The data to be written to "Address"

    What I saw in the binary:
    50 41 54 43 01 3B 6F 00 02 00 00 01 3B 81 00 02 00 00 45 4F 46

    To me, this meant:

    the string PATCH

    Address 01 3B 6F
    Length of data is two bytes
    Data of first byte is 0
    Data of second byte is 0

    Address 01 3B 81
    Length of data is two bytes
    Data of first byte is 0
    Data of second byte is 0

    the string EOF


    There's a thread of logic I'm missing. It seems like I have the start addresses correct (minus the one bit adjustment as you noted), but I don't have the values correct nor that fact that you are changing an additional value just after the first (ie 013B6E then 013B70).

  8. #53
    Wildside Expert
    Join Date
    Nov 2008
    Posts
    104
    Rep Power
    16

    Default

    Quote Originally Posted by y9784 View Post
    There's a thread of logic I'm missing. It seems like I have the start addresses correct (minus the one bit adjustment as you noted), but I don't have the values correct nor that fact that you are changing an additional value just after the first (ie 013B6E then 013B70).
    Taking the first IPS patch record as example:

    Code:
    Address 01 3B 6F
    Length of data is two bytes
    Data of first byte is 0
    Data of second byte is 0
    This means two contiguous bytes need to be patched in ROM file:

    byte at address $13B6F is patched with $00 value
    byte at address $13B70 is patched with $00 value


    Now, as said in my previous post, Game Genie hardware can NOT do byte patching, it can only do word (16-bit) patching.

    Also:

    - the patching does not really occur on the ROM (like an IPS patch or an emulator are doing) but it occurs in real time when the CPU makes a read access to the ROM and Game Genie detects the read address matches one of its patch addresses.

    - CPU read access to ROM are ALWAYS 16-bit access to an even word address


    As a result:

    - the two contiguous bytes above can NOT be patched in a single ROM access since they each belong to two contiguous word addresses

    - Game Genie hardware first needs to patch word address $13B6E (which holds bytes $13B6E and $13B6F), then word address $13B70 (which holds bytes $13B70 and $13B71)

    - since you don't want to modify bytes $13B6E and $13B71 (but only bytes $13B6F and $13B70), you need to keep their original value in the word patches (that's where the $07 and $FD values in my previous post come from)


    In short, in this specific case (patch starting at an odd address), you cannot directly convert IPS patch to Game Genie code, you will need to open the original ROM in an hex editor to copy some of its original byte values. Same goes if the patch start address is an even address but the length of patched data is not an even number of bytes.

    I hope it's clearer now
    Last edited by Eke-Eke; 04-07-2017 at 08:28 AM.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •