+  RHDN Forum Archive
|-+  Romhacking
| |-+  ROM Hacking Discussion
| | |-+  Garbled/Missing Text in certain emulator's (BSNES etc.) DMA Related
Pages: [1]
Author Topic: Garbled/Missing Text in certain emulator's (BSNES etc.) DMA Related  (Read 1 times)
Kagemusha
Guest
« on: February 14, 2010, 12:20:27 pm »

Greetings fellow RHNDers. There is an issue with Arabian Nights that been fixed yet and requires outside help. Basically certain text is either missing or garbled. For example the name in the name input screen is garbled and the battle text doesn't appear in BSNES etc.


well, I tried everything I can think of and SNES9x still doesn't want
to execute the tile-data-copying DMAs, even though there's nothing
different than with the others that copy WRAM to VRAM; and the ones in
the dialog blitter are still the originals, too!!
I tried the latest version of Geiger's debugger and it only offered
what I knew already: the DMA was setup correctly, but the data never
was copied. Additionally, the source address for the clearing-tile-area
DMA was incremented, despite that I tell it not to.
Therefore, I conclude that it is a bug in the emulator's code rather
than mine or Takara's. As such it can't be fixed by me, and I official
give up on trying to until someone can prove I'm wrong and provides the
necessary code.

If anyone can help us out, it would be appreciated.
KingMike
Guest
« Reply #1 on: February 14, 2010, 12:31:24 pm »

Which emulator has errors: BSNES, SNES9x or both?

I suppose if it's a BSNES error, try asking on byuu's board (board.byuu.org)?
Kagemusha
Guest
« Reply #2 on: February 14, 2010, 12:40:44 pm »

It's both, BSNES and SNES9x.
I.S.T.
Guest
« Reply #3 on: February 14, 2010, 01:23:22 pm »

Yeah, I'd go over to his board and report the bug.
Vegetaman
Guest
« Reply #4 on: February 14, 2010, 06:14:09 pm »

Some emulators just seem to handle certain functions of games... Improperly, shall we say? For example, Destination Earthstar (NES) works fine at the star for both FCEU and Nestopia, but when you go "underground" in it, FCEU completely glitches out and you can't play the level while Nestopia runs it fine. They all have nuances and run certain games better than others. Must have to do with the underlying code base...
Gideon Zhi
Guest
« Reply #5 on: February 15, 2010, 12:05:57 am »

Is it possible that the DMA channel you've got your transfer wired up to is already in use? Have you tried using a different channel?
Nightcrawler
Guest
« Reply #6 on: February 15, 2010, 11:45:03 am »

Yes, certainly check and double check your channel is not being used by the game for DMA or HDMA.

Second, your DMA still needs to occur during vblank. Is it? Check the V counter. Even if you use the original game's routine, if you've done any modifications to the game that occur during vblank or the NMI,  there may be less available cycles for the DMA transfer and it may no longer complete in the remaining vblank time.

I'd have somebody check your code on the real hardware to get a definitive answer.
Gideon Zhi
Guest
« Reply #7 on: February 15, 2010, 10:59:36 pm »

Quote from: Nightcrawler on February 15, 2010, 11:45:03 am
Second, your DMA still needs to occur during vblank. Is it? Check the V counter. Even if you use the original game's routine, if you've done any modifications to the game that occur during vblank or the NMI,  there may be less available cycles for the DMA transfer and it may no longer complete in the remaining vblank time.

DMA only needs to occur during vblank/NMI if they're transferring straight to VRAM. If they're overriding a decompression routine and just dropping data into WRAM with the expectation that the game's built-in handlers will move it to VRAM when the time comes, they can DMA whenever - but they also need to make sure that the appropriate data is entered into the NMI queue (WRAM address, size of data, etc.)
Nightcrawler
Guest
« Reply #8 on: February 16, 2010, 09:56:51 am »

Correct, but he said:

Quote
he was "even though there's nothing
different than with the others that copy WRAM to VRAM;"

I thought what I said would be relevant if that's what he's doing. I have dealt with some of these cumbersome issues in the past where it may fail (even intermittently) for reasons mentioned.

I agree it would probably be easier to massage the code into the game if you transfer to WRAM and use the standard NMI queue handler if possible.

These things can be a little tricky to troubleshoot, but you'll get it with close examination of what's happening and process of elimination. The biggest help is eliminating emulator bugs by having someone try it on the real hardware. byuu tries hard to keep BSNES as accurate as possible and free of major bugs, so chances are it may not be an emulator bug. Either way, you need to know for sure.
Kagemusha
Guest
« Reply #9 on: February 16, 2010, 10:22:10 am »

Is there anyone here that I could trust to test the ROM on hardware? The problem is that I don't think any of us are capable of that and it probably wouldn't be a good idea to hand out a WIP ROM to a stranger.
Nightcrawler
Guest
« Reply #10 on: February 16, 2010, 10:41:02 am »

You can send it to me if it's something I can get to in-game in a few minutes. Maybe send me a screenshot and a description of what I should be looking for. I would have a little time tonight if you can get it to me today. Otherwise, probably not until this weekend. Or you can look for someone else. Your call.
Gideon Zhi
Guest
« Reply #11 on: February 17, 2010, 02:15:30 pm »

I'd offer as well, but you're probably better off with Nightcrawler - I haven't used my SWCDX2 in *years*, and my new laptop doesn't have a parallel port Sad This means I'd have to hook it up to the desktop in the bedroom, and I think my cable is only 6ft long, which means there'd be wires going all across the middle of my floor. Probably not good :|
Nightcrawler
Guest
« Reply #12 on: February 17, 2010, 02:57:32 pm »

I already took care of testing it for him, found the cause of the problem on the naming screen for an example, fixed it, and hopefully pointed them in the right direction for the rest of the seemingly similar issues.  Cool

Problems were present on the real hardware. No emulator bug. They were doing DMA to VRAM without concern for vblank on the example I debugged.
Pages: [1]  


Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC