Home Page Forums MAME MAME The SNES WIP topic

Alright, I'll put that off then

fwiw, dkc3 garbled text is fixed in current svn



but latest fixes have broken Desert Figther title screen: I'm still working on a proper fix for this regression and on some more hdma improvements...

as of rev.7657 Desert Fighter title screen is properly cleared again (of course, without breaking Donkey Kong Country 3).

I hope to be able to make HDMA slightly closer to Anomie's doc soon, though... it might fix some other reported issues

Spent about 14 hours on the problem, I can't come up with anything to perfectly emulate ( http://board.byuu.org/viewtopic.php?f=16&t=614 ), so if you wanted to port the S-CPU stuff you may as well do so now ... up to you, though.

Awesome!

There is a problem with Rudra no Hihou after you start a new game. The screen is wrong below the first textbox.

also, I start to think many of the remaining problems in the driver (but not all) reside in the CPU timing and opcodes... hence, a core which handles 99% of the cases properly would definitely help to single out the remaining problems in video and machine code.

And hopefully any future changes to fix the one case so far will not require gutting and redoing the entire s-cpu core...

LN

This bug reported in August has been fixed today (either by 7658 or by 7661). Not that I want to play this game, but...


This might have never worked (it was already broken during 0.136 cycle). Not sure what is causing the isssue, I'll add it to the list of bugs to check

The worst possible thing that could happen is having my hold times for reads and writes disproven somehow. That would require adjusting every last timing value (when does Hblank start/stop, when does DMA transfer begin, etc) by +/-2 or whatever.

Nothing really major.

I also don't have the first idea how to verify it. All I know is that reading from $2137 latches the counters at N, and writing to $4201 latches them at N+4 master clock cycles.

Since they are FastROM, I extrapolate that to means writes "occur" at cycle_start+cycle_length, and reads "occur" at cycle_start+cycle_length-4.

TRAC concurred based off timing information in the official 65816 doc, but that doesn't mean it doesn't vary depending upon which chip / register you are accessing.

I don't have any way to verify that, need a hardware guru to go at it with an oscilliscope or something.