Home Page Forums MAME MAME The SNES WIP topic

Huh. On my laptop I couldn't see a difference between the "before" and "after" Aerobiz pictures above, but it's very obvious on my desktop (which admittedly has a much higher quality LCD panel). I guess those pictures are useful as a sort of color gamut quick check

Well that's one more reason to try hardware rasterization :P

Looks like you're making exciting progress, congratulations!
Please don't hesitate to ask if you have any questions.


Yes, discussed on my forum. Minor regression caused while moving some things for save state support:
src/ppu/ppu-inline.hpp:77:
status.hcounter = 0;
//was status.hcounter = 186;
//which was mis-aligning OAM address reset and such

http://img13.imageshack.us/img13/2981/71901316.png

In the middle of adding a GUI-based debugger, so no new build just yet.


If you're meaning SNES RGB555->RGB888 bit-extending (10111->10111101 instead of 10111000), I already do that. If you're meaning direct-color mode RGB443->RGB555, then you are incorrect. The low bits are always zero on the real thing.

//palette data = 00000bgr
//tilemap data = BBGGGRRR
//result = 0BBb00GGGg0RRRr0

Verify yourself by placing an all-white sprite on top of the BG layer.

If your goal is to make the output prettier than the real thing, it's a good strategy. I'd also recommend rasterizing mode 7 at 512x448 in that case

Now then, if you really want to be the first to do something ... $2100 INIDISP controls the screen brightness. But it is not a linear drop as you go down. In fact, with a brightness of zero the screen is still visible. Max out your TV brightness control and you will see it. The effect can't be simulated in RGB555 colorspace. The actual color adjust occurs on the luma channel upon TV output in YUV format. The exact algorithm is unknown, as it's very hard to measure.

Good!
The Super Mario Kart are now showing the screen!
But i have a problem to report: the other racers are being attracted by mine...
and i can't go forward after this...

Yup, color depth extension can be tricky - usually due to hardware limitations. On PowerVR twiddled textures will reuse high-order bits but non-twiddled (for example RT stride-type texture) will be zero-padded. Except one-bit channels, those are always properly extended (this only applies to alpha in 1555 mode anyway).

The goal wasn't to do the output prettier, but to do things in line with all the other Arcade/Console HWs that does things like that (yes, it's a guess). If you've done tests on the real HW that says otherwise, then I'll go reverting it.

Well, I always recommend everyone test on real hardware themselves. The truth is, I've tested thousands upon thousands of things, but I don't always keep documentation for each and every last thing.

I'm quite sure I've tested this, and it's the reason I always use my own custom palettes in mode 3 rather than direct color for my fan translation splash screens. Well, that plus only being able to control the low bit per 8x8 tile makes it extremely useless ...

But without a documented test ROM to prove it, I don't want to tell you with 100% certainty that I am correct here.

The best advice I can give you though, is that 99% of the time, the way you *think* something should logically work, is not the way the SNES actually works :P

SVN r5427

Wordtris does not start (no input allowed]



You get to this screen and you should be able to options with the joypad/arrows or hit START to continue. Neither works and it sits there for a long while before restarting the Title Screen again.

byuu, how much of a testing battery for things like interrupts and DMA do you still have? I know you've done extensive work on these areas, but it's rather difficult to sort out the "right behavior" from forum posts (and code is notorious for subtle bugs that break things, so an actual test is always better than a source compare)

I certainly wouldn't be proud of writing such flaky software, but to each their own

People tend to think that if something works on one real SNES, that it will work on every real SNES. Not true, those crystal clocks tend to vary per unit, if ever so slightly. I can almost guarantee you that even if it's only on 0.1% of SNES units, that some have problems with these types of games.

Anyway, I'm not aware of any audio glitches in this game. But I do know that we desperately need someone to clock the S-CPU crystal with an oscilloscope. We know that the S-SMP is rated at 24,576,000hz, but really runs at around 24,606,720hz. The S-CPU is rated at 21,477,272hz, but if it actually is off by such a large amount as well, it could very well be the cause of issues in Clayfighters.

If someone can reproduce Clayfighters sound issues, they can try modifying cpu.ntscClockRate in bsnes.cfg. I'm almost certain they could get sound perfected if they find the right value.


I've heard this a lot, and since bsnes started, I've always filled APURAM with 0x00 on power-on. Never had any problems, not even with Bomberman games.

The only game I know that has issues with APURAM initialization is SD Gundam G-NEXT, an SA-1 game. It has some sort of issue if you don't clear certain parts of it on reset. I haven't looked into it much.


I can't reproduce that, it runs fine here. Any more details?


I have a few test ROMs that combine a few dozen tests each.

But seriously, you don't want them right now. You will need extremely precise timing for them to work. They will fail if you're off by even a single master clock cycle.

You'll need bus-level (not cycle-level) accuracy, DRAM refresh, (H)DMA/CPU sync, the differences between CPU revisions 1 and 2, every opcode tested to ensure the cycle timing and ordering are correct, full MDR support, etc etc etc perfected before you try them.

At this time, no other emulator can even pass my seek_frame function, which when called, returns with the PPU counters at *exactly* V=0,HC=0 (H=HC/4, by the way. $213c reports the current *dot*, but there are four cycles per dot.)

You guys really need to drop the current CPU approach and go full-on at 21MHz. Be prepared that proper DMA sync timing requires executing the next cycle of the current position, which can be in the middle of two opcodes, and you need to be able to sync up all other processors while a DMA that can be up to ten frames long runs.

I never managed to pull that off flawlessly with state machines, so hopefully you guys are more skilled with those than I am.

I would love it if you guys could catch up, and especially if you guys could start performing your own hardware tests. I desperately need someone else who's really interested in SNES emulation to help motivate-and-work-with me, so we can start making real progress once again

Things have stalled badly since anomie left ...