Home Page Forums MAME MAME The SNES WIP topic

the actual snes output is 512 pixels wide. in hires-X and hires-XY mode a bg layer is displayed on every single one of the 512 pixels. in normal mode the bg later is displayed with every pixel doubled (effectively horizontal res of 256). in pseudohires mode, two bg layers are displayed at once: one is displayed on every odd pixel of the 512, and one on every even pixel. The example image etabeta showed above (at http://mamedev.emulab.it/etabeta/fast/files/0051.png ) is correct (though the exact 'order' of the interleave of the two bg layers might be backwards, this is difficult but not impossible to check on real hardware). be sure to click on it so you can see it in full res.

Hires-Y mode and Hires-XY mode on the snes are flickery because they're swapping the Y lines every 60fps field, for a 30fps full framerate. Or this is how it's supposed to have worked.

LN

I can understand the pedancy about blending hires mode. If you guys really want to go with the hideous version here ( http://mamedev.emulab.it/etabeta/fast/files/0051.png ), you can just tell people to stand really far back so that the eyes naturally blend the two layers

My understanding was that someone tried this on an RGB monitor (either with SCART or an RGB mod), and it still blurred. I don't think that the S-PPU itself is doing the blending.

Also note that the same blur affects both true hires and pseudo-hires. It's extremely inconsistent to only apply it to one and not the other. With the right tiledata and maps, you can make the exact same image in either true or pseudo-hires mode. They should not look different just because hires is more often actually 512-width, and pseudo-hires is more often used to blend two 256-width layers together.

----------

I have a huge favor to ask. Apparently the game Speedy Gonzales, both v1.0 and v1.1 lock up in level 6-1 whenever you hit this button:



Snark says it doesn't lock up on the real thing.

Some starting trace log stuff here:
http://board.byuu.org/viewtopic.php?f=3&t=611
http://board.byuu.org/viewtopic.php?f=3&t=571

I can't seem to figure this one out. It apparently affects every emulator out there, but not real hardware. And the game isn't doing anything even slightly unusual

Given that it also affects MESS, could I bug you guys to see if you can find a fix as well

Would really like some help. None of the other SNES emu devs are active anymore.

EDIT: to make it less horrible, here's a hack to always start at level 6-1

$81a626 lda $0b55
Modify that to:
a9 05 00; or lda #$0005

And Youtube comments on this:
http://www.youtube.com/comment_servlet?all_comments&v=4uUGr5wZJYg&fromurl=/watch%3Fv%3D4uUGr5wZJYg

the order should be fine as well: I followed Anomie's doc and BSNES by starting with the subscreen pixel, then going on with a mainscreen pixel etc.


I started by the assumption that averaging only pseudo-hires would have been a gross hack, hence I followed your example and I blurred both (even if the whole blurring is an option left to the user).

Notice that tomorrow morning I will commit a more verbose revision of the code where, among other things, I will properly credit you and blargg for the average algorithm.


yeah, I was following that thread. I'll see if I can find any possible reason for the freeze, but I hope Kale and/or Just Dessert could take a look as well, since they are way better than me in this...

Thanks a lot, I really appreciate the help

Would be good to verify it happens in MESS too, I can't get to that point without cheat codes and save states; even with the start-at-6-1 hack.

Great work etabeta, time for me to do an svn update and some serious testing methinks!

With the latest updates (great work!) the only remaining issue in DKC3 is the scrambled text in Swanky's side show.

I've mostly cracked Speedy Gonzales. It seems that under certain circumstances, it's possible to glitch the S-CPU MDR to feed back 0x00 instead of the actual MDR. Speedy gets stuck in a loop for several hundred iterations fetching $1818, until eventually it gets $1800 and breaks out (by extreme luck and through multiple nested convolutions. This was definitely a bug in the game and not intentional.)

Logged hardware results and test source code here:
http://board.byuu.org/viewtopic.php?p=12961#p12961

So, you guys are the most pedantic about emulation authenticity (not a bad thing!) ... we can't emulate this. The glitch occurs completely randomly and unpredictably. The closest we can do is simulate it with a pseudo-random number generator, eg:


What would, or rather, what are, you guys going to do for this case?

wow! you've been really fast!

dumb question (because I haven't read through the log results): is it 100% random? is there really nothing that can have changed the open bus value, due to some write/read from the game? it seems so strange that the game relies so heavily on unexpected behaviors... but I guess that bugged games have always existed, so this is just a particularly nasty example

won't this mean there is a 1/256 chance of a game that requires the right value breaking? ;-) (of course, maybe it would on real hardware if the glitching is unconditional, and not caused by any kind of excessive reading / writing / other activity in the system)

could you provide an .inp file from the start to a Swanky show? remember to either delete .nv or to include it together with the inp file.

thanks in advance