Previous Thread
Next Thread
Print Thread
Page 2 of 3 1 2 3
#22 08/20/06 03:40 PM
Joined: Jan 2006
Posts: 3,688
Very Senior Member
OP Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,688
thanks for the update. i also noticed the huge slowdown in snes emulation...

the day before i was playing more or less flawlessy 'super mario all star' (except some graphic scrolling problem), the day after 'link to the past' took 2 minutes only to make the triforce to appear in the intro sequence frown

anyway, good luck (also to heretical_one and his pce stuff)

#23 08/20/06 09:01 PM
Joined: Dec 2005
Posts: 443
Senior Member
Offline
Senior Member
Joined: Dec 2005
Posts: 443
Exact SNES PPU timings aren't known, but the level of information is much, much improved over even six months ago.

For example, H-DMA is now known to be capable of writing to VRAM. It just doesn't work during the display period because of sprite handling. That makes sense, of course, but the only known example had been during display, where it would corrupt the graphics.

The same thing with offset-per-tile modes, where the left tile is exempt... because the tilemap data is all cached first. Offset-per-tile would need a near-instantaneous decode to work. By the second tile, that's no longer an issue.

So it's a good thing that MAME is getting closer to handle the SNES weirdness, because the SNES weirdness is closer to being understood.

Some of the APU weirdness, though... is still just weird. I guess I understand the entire BRR pipeline never stopping, though. Probably cheaper in hardware to just do your worst case every iteration.

#24 08/20/06 10:47 PM
Joined: Mar 2001
Posts: 16,680
Likes: 4
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,680
Likes: 4
Byuu's dot clock timings on his page are great though.

Is someone compiling all this new information or do I have to read zsnes development daily to avoid missing something? smile The nice thing with the NES is that blargg wrote the documents.

#25 08/20/06 11:01 PM
Joined: Jan 2006
Posts: 3,688
Very Senior Member
OP Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,688
probably you should start with a search among byuu's posts at zsnes forums because i fear he's too involved in developing his emu to write down what he found.

the bsnes post in emulators section collects at least more recent news (together with the posts he opened in the development section...)

byuu also wrote many test roms. i downloaded some from his posts at time, but i'm not sure to still have those (i remember a couple of oam tests and few others). you should ask him about his tests roms, as a shortcut to find out subtle errors

#26 08/21/06 12:49 AM
Joined: Mar 2001
Posts: 16,680
Likes: 4
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,680
Likes: 4
Yeah, it'd be nice if he at least collected all his test programs in one place. I think I'm saying I wish all standalone emu developers were blargg smile

#27 08/21/06 02:03 AM
Joined: Jul 2000
Posts: 497
MacMAME Author
Offline
MacMAME Author
Joined: Jul 2000
Posts: 497
Quote:
Originally posted by etabeta78:
i filed 5 bugzilla reports about failure of some (really pedantic) blargg's timing/ppu/apu tests. these tests pass on the real hardware and not in mess.

probably they use exotic features of the system and no game is affected, anyway i thought it was good to report them.
I saw those reports, thanks. I ran most of blargg's tests before submission and you are right - they stress areas of the PPU that, as far as I can tell, have no practical effect on games. I'm open to being proven wrong, of course. ;-) Fixes for most of these require "cycle exact" PPU emulation, and that's a bit much right now. Still, since MAME and MESS are documentation projects, I suspect eventually that will happen.

However, I'm going to let most of them rot in Bugzilla until real games start exhibiting bugs.

#28 08/21/06 01:45 PM
Joined: Dec 2005
Posts: 443
Senior Member
Offline
Senior Member
Joined: Dec 2005
Posts: 443
The vblank timing could cause real problems.

aside from that, there might be one or two that require sprite timing. The gross inaccuracies in the NES are already gone, though smile

SNES is disorganized as ever, but the BRR bit comes from anomie's documents that are included with "vSNES" (save state viewer for most emulators that support them).

The H-DMA behavior is byuu's news, but as far as the PPU dot-by-dot behavior, I don't think that is actually recorded anywhere. The offset-per-tile oddity is well-known. The dot-by-dot just explains why Hook fails to glitch on real hardware smile

(for the interested, the SNES has 16-bit VRAM access, and has to cache two tiles at a time. This likely happens without regard to what BGs are active)

Probably the most important discovery lately is that H-DMA on the same channel as DMA terminates the DMA on the first H-DMA occurance.

#29 08/21/06 07:18 PM
Joined: Mar 2001
Posts: 16,680
Likes: 4
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,680
Likes: 4
Aaron Giles added a new raster timing mechanism to the core where you give it the pixel clock and the parameters and everything's handled much more precisely than before - HIRQs now always hit on the exact pixel I want them to, for instance, and vblank and hblank should be the proper duration.

#30 08/22/06 09:39 AM
Joined: Dec 2005
Posts: 443
Senior Member
Offline
Senior Member
Joined: Dec 2005
Posts: 443
have you retried the SNES electronics test using the new support?

#31 08/25/06 01:21 AM
Joined: Jan 2006
Posts: 3,688
Very Senior Member
OP Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,688
ok, instead of posting a new thread i'll continue to ask here my doubts.

1. i tried to use some computer driver, but i found a problem with keyboard emulation. switching to emulated keyboard i should be able to use TAB to open the option menu as in mame, isn't it? or does it depend on the system input? at this moment TAB doesn't work at all here, neither with natural keyboard (but this is expected) nor with emulated one... is it a problem at my end?

2. would it be hard to allow main driver to accept general .bin extension? i mean: all consoles have those stupid extension .gb,.n64,.z64,.v64 etc. that actually are simple .bin files (an exception is of course .nes...)

couldn't be possible to allow in mess also plain .bin files to be picked up?

btw tosec dats has started to rename back those files to bin... so it would be easier to use them if mess would recognize them wink

Page 2 of 3 1 2 3

Link Copied to Clipboard
Who's Online Now
1 members (Olivier Galibert), 42 guests, and 2 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,882
Posts116,799
Members4,962
Most Online890
Jan 17th, 2020
Forum Host
These forums are hosted by www.retrogamesformac.com
Forum hosted by www.retrogamesformac.com