It is currently Tue Jul 23, 2019 11:26 pm

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 232 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6 ... 16  Next
Author Message
PostPosted: Wed Apr 03, 2019 3:52 pm 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 193
Location: Germany
Sour wrote:
I'll keep it in mind and try to review that code eventually, but without a g-sync monitor it may be rather hard to fix (and I don't exactly want to buy a 300+$ monitor that I would never use again just to debug this :p)

Not a problem, but other users might encounter it too. Might just be an issue of my setup, or all G-Sync monitors, or all VRR implementations. Maybe someone else here has one?

Sour wrote:
I've been gathering/reformatting info/documents into a wiki of my own as I go, which helped a lot in getting familiar with everything (and having a reference I'm familiar with to consult whenever I need to confirm some details)

fullsnes :)


EDIT:
krom wrote:
Sour wrote:
Thanks for those tests, by the way! They were extremely useful when I started this and helped me fix a pretty large amount of CPU bugs (though I did find a few bugs that they don't seem to catch - if you're interested in adding some more test cases to them, let me know and I'll try to come up with a list of things I found so far)

Yes I would love to make my cpu tests more useful to help new SNES emulation authors, let me know anything you want me to add, & I'll try to implement it =D

A perfect CPU test set would be quite difficult though... You'd have to test that an emulator's implementation does the right thing, taking the exact amount of cycles as the real hardware, and does it for all valid inputs and under all scenarios (i.e. internal states).

_________________
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10


Top
 Profile  
 
PostPosted: Wed Apr 03, 2019 5:31 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1505
Quote:
Wouldn't it be possible to sync on the CPU's own high resolution timer (QueryPerformanceCounter in Windows)?


Yes, but now you need DRC for audio to keep your buffers half-filled at all times.

Maybe we need adaptive sync for sound cards, a good old-fashioned PCM DAC register that you write the current sound card output sample to (as if :P)

Quote:
Thanks for testing so much, by the way, really helpful to get bug reports like these. Let me know if you find anything else!


Here's my evil games list, in case you wanted to test them, creaothceann:
* Speedy Gonzales (stage 6-1) [requires HDMA to update the open bus latch to break an infinite loop polling an unmapped register]
* Mecarobot Golf [picky on timing in-game]
* Jumbo Osaki no Hole in One Golf [picky on timing at the name entry screen]
* Koushien 2 [requires cycle-accurate DSP or echo RAM trashes SMP code] (if you ever replace blargg's DSP with your own, test this one)
* Air Strike Patrol [plane shadow and level start rotating text, mid-scanline writes]
* Battle Blaze [title screen flame effect and raster effect after winning battles]
* SInk or Swim [levels would break up]
* Magical Drop [endless mode game over screen hanging]
* Super Bonk [the intro sequence sometimes desyncs, but this also happens on real hardware, I never did find out why]
* Bishoujo Janshi Suchie-Pai [character sprites] and Marvelous (SA-1) [dialogue boxes] [very picky hires color add/sub effects]
* Goodbye Anthrox (atx2.sfc) [trainer that changes BGMODE mid-scanline]
* Krusty's Super Fun House [you have to block invalid DMA transfers to prevent palette corruption]
* Bugs Bunny [in-game] [requires that HDMA during DMA stops the DMA]
* Taz-Mania [in-game] [only if you emulate the MUL/DIV cycle states, this game reads the registers early]

Quote:
and the seemingly endless number of PPU features


What makes the PPU so daunting is that people don't really explain how the features all work together. Everything has to be done in a very certain order, and the settings for one thing change the effects of another thing.

With the NES, you get this wonderful break-down of every single cycle. It was trivial to run Battletoads with information that good.

Quote:
A perfect CPU test set would be quite difficult though... You'd have to test that an emulator's implementation does the right thing, taking the exact amount of cycles as the real hardware, and does it for all valid inputs and under all scenarios (i.e. internal states).


Most of my tests were like that. Mesen might be the first other emulator capable of using them.
(un)fortunately, I don't see the test_nmi, test_irq test ROMs up on snescentral ... odd. I always seem to lose those ones.


Top
 Profile  
 
PostPosted: Wed Apr 03, 2019 7:16 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 714
byuu wrote:
Here's my evil games list, in case you wanted to test them, creaothceann:[you have to block invalid DMA transfers to prevent palette corruption]
Krusty I fixed a few days ago, ASP *almost* works properly, but you can tell the shadow is not quite right (the timings are probably off by a couple of pixels) and the level start text has a glitch on the right hand side. I was aware of the whole Speedy Gonzales thing, but not the specific quirk it relied on. HDMA should be updating open bus like any other regular write, but it's possible open bus itself isn't quite correct yet. The others I don't think I've really tested yet, thanks for the list!
Quote:
What makes the PPU so daunting is that people don't really explain how the features all work together. Everything has to be done in a very certain order, and the settings for one thing change the effects of another thing.
Which is exactly the problem with my mosaic implementation at the moment :p There's something about how its applied that I'm not quite getting yet.
Quote:
Most of my tests were like that. Mesen might be the first other emulator capable of using them.
(un)fortunately, I don't see the test_nmi, test_irq test ROMs up on snescentral ... odd. I always seem to lose those ones.
Speaking of which, are the ones up on snescentral essentially all the ones you've written? I pass half or so of those I could find there at the moment (the HDMA timing ones fail, but it's a probably due to a combination of factors beyond just HDMA). Beyond that I have krom's tests, a number of tests by blargg (adc/sbc, oam, mul timing, both sets of spc tests) and that's more or less it. Am I missing anything major?

creaothceann wrote:
A perfect CPU test set would be quite difficult though
blargg pretty much created a nearly perfect set of test roms for the NES - if you pass all of his tests, you can essentially assume your emulator will run 99% of games without any issue. Really wish the SNES test roms were as complete as those, but beggars can't be choosers. I unfortunately completely lack the skills required to write any meaningful tests, and also lack the equipment needed to run them :p

Edit: Also, DKC should be fixed now, was a save ram mirroring issue as expected (my code was broken when trying to mirror SRAM sizes smaller than 4kb)


Top
 Profile  
 
PostPosted: Wed Apr 03, 2019 10:36 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1505
Quote:
Which is exactly the problem with my mosaic implementation at the moment :p


Mine is currently not perfect either. H mosaic and V mosaic are quite different. V mosaic has odd restart rules for messing with it during rendering, and there's a weird quirk with mode 7 EXTBG and mosaic. But then, EXTBG mode is another thing I don't fully emulate ... that actually has effects on all eight BG modes. Just not useful ones.

Quote:
Speaking of which, are the ones up on snescentral essentially all the ones you've written?


Oh no, it's a small number of them. I put them all on a flash drive for a disk reformat, then lost it for a while, and by the time I found them, they bit-rotted away. I still have all the files and source, but their file sizes are zero bytes.

The tests you most want to pass are demo_nmi, demo_irq, test_nmi, test_irq, test_dma*, test_hdma*. You can pretty much assume all the games with IRQ issues (Battle Blaze, Cu-On-Pa, etc) and HDMA issues (Mecarobot Golf, Energy Breaker, Circuit USA, etc) work if you pass all of those.

blargg's MUL timing test doesn't work on real hardware, but I have memory that it used to. I suspect Evan found an outdated copy of it, maybe?

Quote:
and also lack the equipment needed to run them


You've more than proven yourself worthy. If you'd like the means to test your code on real hardware, I can send you my sd2snes. If you don't want to provide an address to send it to (I wouldn't blame you), I can Paypal you some funding for one.

I feel you on test ROMs and documentation. My efforts were super lazy there.

You probably will want to dig through the bsnes source code though. A lot of my findings I never wrote about. A few off the top of my head:
* the DRAM refresh point plus the HDMA frame initialization point is different between CPUr1 and CPUr2
** (^ likely to fix the CPUr1 crash when performing DMA and HDMA at the same time)
* when OAM interlace is on, and sprite size is 0, OAM sizes 6 and 7 are halved to {width}x16 instead of {width}x32
* HDMA does all of its transfers first, and *then* updates all of the addresses as needed
** (^ otherwise you might run out of Hblank time for really complicated 8-channel HDMAs)
* if the final HDMA transfer on an entire frame is indirect, the last HDMA indirect address only fetches the low byte, and then sets the channel indirect address to lowbyte<<8 (so the channel low byte is 0x00), and it saves one cycle
* if an interrupt occurs during an instruction that is {opcode fetch + I/O cycle}, eg nop, inc, etc: then the I/O cycle is transformed into a bus read cycle from the current PC address instead. If the bus read is from a slow ROM region, this will cost another 2hz of time to pass.
** (^ I spent weeks tracking that down because latching IRQ / NMI PPU counters kept being off slightly from real hardware. It took forever to test every possible thing it could be on my old SNES copier.)
* if you write to VRAM on the *very* last possible cycle before frame rendering starts, it writes the CPU open bus value to VRAM instead of the value you wrote to it
* VIRQs and HVIRQs fire one scanline later than expected on the very first frame after reset (likely the CPU counter is misaligned)
* it takes either 186 or 188 cycles to complete a CPU reset before code starts executing (it varies)
* CPU soft reset acts just like a regular interrupt: it pushes the PC address and P register onto the stack, but there was a gotcha because the CPU switches to emulation mode on reset which causes stack wrapping around $01xx.
But there's definitely more I'm forgetting in there ...


Top
 Profile  
 
PostPosted: Thu Apr 04, 2019 6:13 am 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 1177
Location: Hokkaido, Japan
I just wish there was something like the nesdev wiki for the SNES which has very complete information for both emulator authors and homebrew developers alike. Fullsnes is nice and superfamicom.org exists, but it's still not as complete.

Sour wrote:
Pokun wrote:
Damn this is real?? I was reading this taking it half seriously thinking it was an april fools joke.
Mission accomplished, I've managed to fool at least one person!
Hahaha! So it WAS an april fools joke but in reverse... or something!? Ah my head hurts!

byuu wrote:
Quote:
whatever absolute nonsensical pedantry


The same ASD that led to me spending 15 years perfecting an emulator for a retro video game system is what also drives my obsession with supporting absolutely everything I possibly can. I get huge levels of anxiety when things aren't "perfect" in my mind. I can't really separate the two, nor is this a condition that can be cured. I know how annoying I've been about all of this, and you all have my apologies for that. I'll do my best going forward to act professionally. I'm hopeful that Sour's emulator will be a worthy alternative for people who are tired of putting up with me, and give me some more room to experiment with my emulator.
That nonsensical pedantry and research has given us a wealth information and made the SNES emulation and development scenes go forward (which can't be said about for example Nintendo 64 emulation until much more recently). I wholly understand your sense of perfectionism.

I just have to say that I also agree with Koitsu, and I'm not a fan of making new formats and standards left and right (for the same reason as in that linked xkcd strip). But I think this discussion will come up every time SNES "mappers" are talked about, and like Byuu said, there might not be a good solution to it.



Anyway I tested Mesen-S a bit. I like how similar it is to the great Mesen which has a very intuitive interace. It did hang a few times though when setting up input buttons.


Top
 Profile  
 
PostPosted: Thu Apr 04, 2019 8:39 am 
Offline

Joined: Fri Feb 16, 2018 5:52 am
Posts: 32
Location: Ukraine
I checked Mesen-S on my problem games and some games have the same issues that I had on my FPGA SNES :) .

1. Wild Guns, flickering
TSB $66 must be executed before runs NMI handler.
Attachment:
Снимок.PNG
Снимок.PNG [ 54.95 KiB | Viewed 2468 times ]

https://board.zsnes.com/phpBB3/viewtopic.php?p=77276&sid=bf8f0333cabdc554baa99bf8b3946eb4#p77276


2. Robo Cop Vs Terminator, flickering
If V-IRQ enable and current scanline = VTIME then IRQ set immediately. Scanline 31 IRQ handler finished on scanline 32 and immediately runs scanline 32 IRQ handler, but in Mesen-S scanline 32 IRQ handler execute on next frame, so current frame still in force vblank mode.
Attachment:
Снимок2.PNG
Снимок2.PNG [ 40.44 KiB | Viewed 2468 times ]



3. Uniracers
https://github.com/MiSTer-devel/SNES_MiSTer/issues/26
https://forums.nesdev.com/viewtopic.php?f=12&t=18447

I still have one issue with HV-IRQ in Top Gear 3000, but it with DSP4 chip.


Top
 Profile  
 
PostPosted: Thu Apr 04, 2019 10:45 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1505
> https://board.zsnes.com/phpBB3/viewtopi ... eb4#p77276

Oh heck, 2005. I remember that now:
https://gitlab.com/higan/higan/blob/mas ... ma.cpp#L20

When DMA/HDMA events fire, it blocks interrupts from triggering in the next IRQ test (which is on the last work cycle of each previous instruction, or the first bus cycle of each next instruction.) Confirmed on hardware.

I don't know if you emulate the psychopathic DMA<>CPU sync yet Sour. If you don't, I can explain it in detail. But basically, to start an H/DMA, it waits one cycle and then the clock aligns itself to a multiple of 8 cycles since reboot. When H/DMA ends, it aligns itself to an even multiple of the last CPU cycle that executed. That alignment probably does odd things that affect IRQs from triggering.

> 3. Uniracers

Two-player mode writes to OAM during Hblank in the middle of the frame. Not 'supposed' to be allowed. The write ends up going to where the PPU last fetched sprite data, which so happens to be the byte that Uniracers needs to write to move the sprites on the second player half of the screen around.

While we're on the subject, lots of titles also write to CGRAM not just in Hblank, but during screen rendering. Those writes go to whatever palette entry the PPU is currently fetching for display. The easy/lazy hack is to just assume it's CGRAM[0], or the usual backdrop color.

Quote:
I just wish there was something like the nesdev wiki for the SNES which has very complete information for both emulator authors and homebrew developers alike. Fullsnes is nice and superfamicom.org exists, but it's still not as complete.


What we really need is someone starting on a new SNES emulator (Mesen's probably too far along already) willing to write up detailed pages about each specific game's quirks that they had trouble emulating. That stuff is pure gold for new emudevs. "Are Wild Guns sprites flickering? Here's what you do to fix it. Here's a test ROM you can use so you don't have to test against the game itself."


Top
 Profile  
 
PostPosted: Thu Apr 04, 2019 11:15 am 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 714
Yea, Circuit USA is one I still need to fix, most likely timing related. I'll have to find the nmi/irq ones and try to figure out what they expected. Thanks!

RE sd2snes: As much as I appreciate the offer, I honestly don't have the assembly/hardware-level knowledge to actually write good tests (I've written a couple of basic ones for the NES, but they weren't timing-sensitive things, etc.) Not to mention I usually have my hands full already just coding the emulators in the first place, heh.

Thanks for the list of quirks, I think a couple of them I've seen mentioned in anomie's docs, but a lot of these I don't recall reading anywhere so far.

srg320 wrote:
I checked Mesen-S on my problem games and some games have the same issues that I had on my FPGA SNES
Thanks for testing and for the extremely detailed bug reports! I think the first couple of issues are pretty likely to fix some flickering problems I've encountered in another couple of games. If only all bug reports came with all the information needed to fix the problem, too! :p

byuu wrote:
I don't know if you emulate the psychopathic DMA<>CPU sync yet Sour.
I have a basic implementation of it based on anomie's timing info, but it's definitely not perfectly accurate yet.
byuu wrote:
While we're on the subject, lots of titles also write to CGRAM not just in Hblank, but during screen rendering.
Ah, that's interesting, and something that I didn't expect (unlike the OAM bit). Writing to palette RAM on the NES during rendering is actually impossible, afaik.
byuu wrote:
What we really need is someone starting on a new SNES emulator (Mesen's probably too far along already) willing to write up detailed pages about each specific game's quirks that they had trouble emulating.
I've got you covered! :p
Attachment:
Untitled.png
Untitled.png [ 33.51 KiB | Viewed 2425 times ]
I've been keeping track of what games were fixed by what changes in my code as I fix them, so I'm hoping to have a decent list of them eventually.

FYI, the wiki I've been working on is here: https://snesdev.mesen.ca/wiki/
It's very much incomplete and a work in progress, though.


Top
 Profile  
 
PostPosted: Thu Apr 04, 2019 12:21 pm 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 193
Location: Germany
There was some undefined behavior with the math registers. We might need to wait for Visual5A22 for that...

_________________
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10


Top
 Profile  
 
PostPosted: Thu Apr 04, 2019 5:43 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1505
Quote:
There was some undefined behavior with the math registers.


Unknown/unemulated hardware behaviors:

1. when you start a MUL during a DIV or vice versa with the SNES, both run at the same time and the results are nonsensical. It's sharing logic gates among both paths, basically. It's probably the easiest way to detect an emulator right now.

2. muting the DSP causes a short pulse effect where the audio fades out instead of instantly muting. This seems to happen in the analog space.

3. (partially emulated) the SNES brightness register is analog, not digital. A value of 0 is not actually black. It's like 99% black, similar to a CRT TV's mute function where if you put your ear against the speaker, you can still hear it. Max out your brightness and you can just barely make out an image. 8-bit RGB lacks the fidelity to show this.

4. the SNES brightness register has serious issues on 1CHIP PPUs. It can take several scanlines to update. Games that use it for gradient fades, and Air Strike Patrol's shadow, will render completely wrong.

5. on CPU revision 1, a DMA firing too closely to HDMA (or vice versa) will deadlock the system. I don't know the details as to how, but my presumption is somehow it causes the CPU to increment the program counter one too many times, misaligning things. If this is true, it could be possible to safely DMA during HDMA on CPUr1 by including NOPs immediately after sta $420b?

6. if both the CPU and SMP access the I/O ports (2140-217f / f4-f7) at the same time, a bus conflict occurs and the results get ORed together. I tried to write a test ROM for this and it caused my copier to immediately stop working, which was probably just coincidental, but worth keeping in mind just in case. I've also read 16-bit operations to these ports are dangerous?

7. the PPU uses the PPU MUL functionality during mode 7. If you use the MUL regs then, you'll probably either break mode 7 rendering, or get mode 7 results instead of what you asked for. The results appear to be as fast as you can read them, unlike CPU MUL. But I haven't tried reading the results as instantly as possible.

8. EXTBG can be enabled in any background mode. It does odd things in all of them, not just mode 7. Grouping it here, mosaic is likely not emulated correctly either.

9. there's a very obscure SMP timer glitch that blargg discovered on older SMP revisions. He mapped out a probabilities chart for it.

10. the exact behavior of the bus conflict manager of the SA1 (stalls to the SA1 when the CPU accesses the same memory region at the same time) is unknown. I was able to get the results ~98% correct compared to Vitor Vilela's test ROMs, but there are some incomprehensible numbers in there still. (emulating these bus conflicts is really painful, too.)

11. it's been reported to me that my emulation of the NEC uPD7725 has a bug in the carry flag implementation. Regrettably I lost the message I received about it (I have trouble with organization.)

12. I strongly suspect that an NMI triggering during an IRQ will transform the IRQ into an NMI during certain cycles (as it does on the NES CPU.)

13. finally, exact PPU timing behavior is unknown. When do registers get latched internally? When does the PPU access certain memory locations?

Implement all of that, and my perfectionism will be satisfied that SNES emulation is complete enough. There will always be bugs we don't know about, but that's unavoidable.


Top
 Profile  
 
PostPosted: Thu Apr 04, 2019 7:26 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 714
Pokun wrote:
Anyway I tested Mesen-S a bit. I like how similar it is to the great Mesen which has a very intuitive interace. It did hang a few times though when setting up input buttons.
Whoops, forgot to reply to this earlier. I haven't been able to reproduce this unfortunately - anything else you might have noticed in terms of steps to get it to crash, etc?

Wild Guns, Robocop vs Terminator & Uniracers should all be fixed - though that unfortunately didn't fix the other 2 games I knew of that have flickering issues (Alien vs Predator + Pocky & Rocky).


Top
 Profile  
 
PostPosted: Thu Apr 04, 2019 8:58 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4159
Location: A world gone mad
General feature request (I've wanted this in Mesen just as bad): File -> Reload ROM (or Reopen ROM). Equivalent to powering off + closing ROM + opening exact same file. I know infiniteneslives has wanted this as well. :-)


Top
 Profile  
 
PostPosted: Fri Apr 05, 2019 1:29 am 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 193
Location: Germany
byuu wrote:
Regrettably I lost the message I received about it (I have trouble with organization.)

"Only wimps use [...] backup: real men just upload their important stuff [...], and let the rest of the world mirror it" /s

byuu wrote:
If this is true, it could be possible to safely DMA during HDMA on CPUr1 by including NOPs immediately after sta $420b?

It seems Tepples and lidnariq have a 1/1/1 SNES...

_________________
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10


Top
 Profile  
 
PostPosted: Fri Apr 05, 2019 4:23 am 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 714
koitsu wrote:
General feature request (I've wanted this in Mesen just as bad): File -> Reload ROM (or Reopen ROM). Equivalent to powering off + closing ROM + opening exact same file. I know infiniteneslives has wanted this as well. :-)
"Power Cycle" in both emulators does this - it'll scrap everything and reload the ROM from disk.


Top
 Profile  
 
PostPosted: Fri Apr 05, 2019 1:44 pm 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 1177
Location: Hokkaido, Japan
Sour wrote:
Pokun wrote:
Anyway I tested Mesen-S a bit. I like how similar it is to the great Mesen which has a very intuitive interace. It did hang a few times though when setting up input buttons.
Whoops, forgot to reply to this earlier. I haven't been able to reproduce this unfortunately - anything else you might have noticed in terms of steps to get it to crash, etc?
I just got straight into the input options and setup SNES controller buttons to the keyboard and to an USB joystick (a Wii Controller Classic with an adapter). I noticed that after clicking a controller button to assign, it will take notably longer time to bring up the window that prompts for an input device button to press than it did in Mesen. A few times it took too long and it seemingly stopped responding so I forced Mesen-S to shut down (forcing me to redo all the buttons again as nothing was saved). I'm using the same computer and same joystick in Mesen without problems.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 232 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6 ... 16  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group