Home Page Forums MAME MAME The SNES WIP topic

Maybe you already fixed it...anyway:

00F915: CLC
00F916: XCE
00F917: SEP #$30
00F919: JMP $c00000
C00000: SBC $ffffff,X
C00004: SBC $ffffff,X
(and so on and on and on)


This is what it does in MESS and presumably in bsnes v0.048 too since that the snescart code is ported from there. It does that in "Live-A-Live (J)" and "3x3 Eyes - Jyuma Houkan (J)" too, pratically decodes the cart as LoROM but it's actually an HiROM...

EDIT: r5429 /src/mame/machine/snes.c: [SNES]: Fixed a vram out of bounds bug

Not from here it isn't ... that's from v048 official. Maybe an issue with the porting of my detection code?

Maybe, I'll check it out tomorrow...

byuu, I don't even work on the SNES driver here

Just assume I have "outside interests" that could benefit, but aren't necessarily MAME-architecture compatible. (I doubt it will pass just yet, but I'd assume the tests would have an explanation of expectations that would)

I guess I'm just looking to address the large hole in the SNES testing battery.

At the highest level, you have an SPC700 test ROM from Overload.
In the middle, the SNES test cart.

There's not much else. Nothing to test the 5A22 (where I'm sure I have a bug somewhere). Nothing to test DMA register behavior short of games. Nothing to test IRQ/NMI at a tighter tolerance than the electronics test (which is not terribly precise). Nothing to check for the DRAM refresh. Obviously, your tests come at the extremely fine end of the scale, but they still would serve a purpose in circulation: that of offering a highly precise set of "last tests" for shaking down an emulator.

Ah, before I forgot...
What exactly tests the SNES Test Program under "Eletronics Test"?

Off-hand?

range-time over flag.
interlace odd/even flag (always active)
RAM
interrupts (VERY coarse)

byuu might have ?anomie's? commented disassembly of it. I think that got left behind on my PC upgrade. It's not terribly useful anyway. You have to pass most of them just to get decent game compatibility, and the interlace flag is literally "opposite of whatever it was before" to pass. Not sure we know the initial state of the flag, though.

RTO is the big one, and anomie's documents ought to cover it all.

I had a partially commented disassembly that anomie made - I'll see if I can dig it up. First it tests things like VRAM and OAM uploads and downloads, then it tries to verify basic raster operations (VIRQ and HIRQ vs. latched counter values vs. the vblank and hblank status flags) and then it tests things like sprite time over/line over.

byuu: have frequency counter, will travel. which pin of which chip do you need measured?

EDIT: electronics test stuff? TRAC sent me a bunch, lemme see if i can find it...


LN

http://i570.photobucket.com/albums/ss144/whickercuppajo3/5A22pinout.png

Pin 72 looks to be our target. Should be ~21,477,272hz. The more precision you can get, the better!

Thank you very much in advance, this will be extremely helpful!

Is such accuracy even needed? Off the shelf crystal resonator will have about 50ppm initial skew. Even assuming constant ambient temperature (which it is not, worse even there are thermcal cycles when the device is turned on and then off) there will be about 10ppm shift every ten years. It's faster when the part is new and tends to slow down and stabilize as it gets older.
The frequency can be somewhat changed (and hence corrected) with a small variable capacitor but I really doubt getting it within 10ppm or so tolerance was a part of manufacturing process...

Sure, most of the PCBs produced are very similar to each other but every now and then there is a black sheep and it's crystal is way more off compared to the rest. That would mean the game requiring very precise timing would not work on that particular piece of hardware... In that case you can claim to emulate said kind of unit and explain it not working is normal behaviour