What is the right way to set up IRQ to preform a forced blank 16 lines at the bottom of the screen and use it for extra v-blank time? I can't seem to figure out how to use register $4200 properly to do this kind of stuff.
The main thing to know is that you have to acknowledge/clear the interrupt before returning. Here is code from my NSF player, this is for horizontal IRQ, but I guess there is a similar way for vertical control.
What this code does, is every scanline (at a horizontal position near hblank) it replaces the background palette with random data grabbed from data being decompressed. That slowed the loading down, but I thought it looked pretty funny (better than just having everything freeze, a few of those loads were really long).
More related to what you'd be doing, I guess you would use the IRQ routine much you would normally use the NMI routine. Only difference being that you turn the screen off, since it's not vblank yet. I guess then you could ignore NMI when you're using the IRQ like that.
Code:
;---------------------------------------------------
set_work_rasters:
ldx.w #200 ; horizontal position to trigger IRQ (hblank?)
stx $4207
lda #%00010000 ; horizontal IRQ enabled
sta $4200
rts
;---------------------------------------------------
disable_work_rasters:
lda #%10000001 ; enable joypad
sta $4200
jsr set_bg_black
rts
;---------------------------------------------------
h_irq:
phb
pha
php
; rep #$10
sep #$20
lda #$00
pha
plb
stz $2121
lda $105D
sta $2122
lda $105E
sta $2122
abort:
lda $4211 ; clear interrupt
plp
pla
plb
rti
For scanline location detection, see registers $4200, $4209, and $420A.
Regarding forced VBlank, looks like Memblers already took care of that for ya. :-)
Does the Super NES PPU have the same OAM refresh glitch as the NES PPU, in which programs have to
disable rendering at the right point on the scanline or risk getting a random pair of sprites' data replaced by the data for sprites 0 and 1?
Off the top of my head, dunno -- I never got around to tinkering with sprites in all my years (on either NES or SNES). I would hope that Nintendo would have been aware of whatever mistakes were made in the NES and improved/addressed those. :-)
Disch might have some ideas...
I can get it to work, but only for one emulator at a time. Once I get it to work on one emulator, it doesn't work on the others.
Why care about any other emulator than BSNES? Of course the main concern should be whether it works on an actual SNES or not. But while you're developing on a PC I don't see any reason to care about how your code behaves in zSNES/Snes9x/whatever.
Snes9x has video capture built in.
mic_ wrote:
Why care about any other emulator than BSNES?
For end users who play on a device less powerful than a recent desktop PC and more common than the SNES PowerPak. Or does bsnes work well on a GP2X, Wiz, Droid, 10" laptop, modded PSP, or modded Wii?
psycopathicteen wrote:
Snes9x has video capture built in.
Maybe you could use BSNES + fraps or some similar program? Or run your program on a real SNES that you hook up to a video capture device (which is what I do if I want to grab a video of something I've written).
Quote:
For end users who play on a device less powerful than a recent desktop PC and more common than the SNES PowerPak. Or does bsnes work well on a GP2X, Wiz, Droid, 10" laptop, modded PSP, or modded Wii?
It probably doesn't. But this is SNESdev, not SNES9Xdev or zSNESdev.
If you write a game that works on a real SNES but not e.g. in Snes9x, then Snes9x should be fixed; you should adjust your game to work on inaccurate emulators.
mic_ wrote:
Maybe you could use BSNES + fraps or some similar program?
Is it worth
$37? And can its capture be synchronized to the emulator's output?
Quote:
Or run your program on a real SNES that you hook up to a video capture device (which is what I do if I want to grab a video of something I've written).
Super NES video with the interlace bit turned off is a non-standard 240p signal, and both video capture devices that I own have had a problem with it. One (an Aiptek camcorder with a composite input) works with 480i video from my Wii, but with 240p video, it stops recording after five seconds, throws an error message, and ends up with a horribly out-of-sync clip. The other (a Philips DVD recorder) works with NES video but for some reason rapidly flickers between color and black-and-white when trying to receive Super NES video. Good luck finding an online electronics store whose sales staff know whether or not the devices that the store sells are compatible with the non-standard video output of any given pre-Dreamcast console.
Quote:
If you write a game that works on a real SNES but not e.g. in Snes9x, then Snes9x should be fixed
In theory, I agree. In practice, good luck getting the maintainers of Snes9x to attend to your test case collection before your video is due. It's been eight months since the most recent version of Snes9x. But it's worth a shot; I made a whole bunch of test cases for VisualBoyAdvance while trying to get TOD working on GBA.
mic_ wrote:
; you should adjust your game to work on inaccurate emulators.
You mean shouldn't?
It did seem when I was developing, that zSNES and SNES9x would run anything. But I used an SNES clone for initial and periodic testing, which seemed to be fairly close to the actual hardware (except for a couple oddities with the controller ports). On that, nothing would work right until I had initialized probably every single register in the system.
Snes9X and ZSNES have poor support for NMI and IRQ. Try F-1 Grand Prix and Sink or Swim. Whereas I spent two weeks researching an edge case where if an IRQ triggers on the edge of a two-cycle opcode with an I/O cycle, it gets converted to a bus read without PC increment. A timing difference of two 21-millionths of a second, and even then only on SlowROM code.
The only other emulator I could recommend for IRQs would be Super Sleuth, which does an exceptional job.
Quote:
For end users who play on a device less powerful than a recent desktop PC and more common than the SNES PowerPak. Or does bsnes work well on a GP2X, Wiz, Droid, 10" laptop, modded PSP, or modded Wii?
10" laptop
As for the rest, give the Snes9X devs incentive to improve.
byuu wrote:
Wow, I'm glad you posted that, I didn't realize I was so behind in bsnes releases. I also have a MSI Wind and was getting only ~45 FPS with v034, but now with v068 a steady 60! Thanks for the netbook friendly profile, it's very forward thinking.
I wouldn't say v068 official is entirely 1.6GHz Atom ready. Some of the crazier PPU-heavy games can stall it a bit.
The next release will be an extra ~10% faster, and if you combine that with the MSI Wind turbo function (1.91GHz dynamic overclock), 60fps should be doable in just about any non-SA1/SFX game.
And no problem. It's sort of been my goal all along. Rather than go top-down (start with fast code, then fix bugs), I went bottom-up (start with correct code, then make it faster.) Still a work in progress, so hopefully I can keep making it faster.
Memblers wrote:
mic_ wrote:
; you should adjust your game to work on inaccurate emulators.
You mean shouldn't?
Yeah, that was a typo. It was supposed to say "shouldn't".
Quote:
It did seem when I was developing, that zSNES and SNES9x would run anything. But I used an SNES clone for initial and periodic testing, which seemed to be fairly close to the actual hardware (except for a couple oddities with the controller ports). On that, nothing would work right until I had initialized probably every single register in the system.
I got the NESticle-effect with the very first thing I wrote for the SNES (an SPC uploading routine). Snes9x happily ran the code even though it had bugs in it that would cause a deadlock (among other things) on a real SNES. My conclusion from that was that Snes9x is useless for development purposes (at least for me).
The big unspoken fact is that ZSNES is probably less accurate to the SNES than NESticle is to the NES. You don't notice as much because the SNES being faster, games are less sensitive to timing.
Think about system requirements:
NESticle -> 100MHz (written in x86 ASM too)
ZSNES -> 166MHz
Nestopia -> 800MHz
Nintendulator -> 1,500MHz
There's something seriously not right when a system that has five processors instead of two, all clocked faster, on a substantially more complex system, results in emulators that are far faster than their quintessential NES counterparts.
I basically got it wrong. I believed people flocked to Nestopia because it was so much more accurate. But it was a combination of many things. 800MHz is well within 90% of peoples' hardware ranges, Nesticle was dying off and discontinued, was closed source, was DOS only and was no longer even producing sound. People had to switch, and they went to the best option of the time.
With ZSNES being the #1 choice these days, it has caused people to believe that its system requirements are what an SNES emulator "should" require. And don't get me wrong, for what it does it's amazing, and it certainly has its place. But for any kind of dev work, forget it.
And just suggesting that anything was like NESticle has become something of a pejorative in the emulation community.
But if you've run any kind of code on it, you know. Here's some fun facts if you don't:
There is no S-SMP opcode timing. All opcodes consume "a clock". The 12-cycle DIV YA,X takes the same amount of time as the 2-cycle NOP. This was done to avoid a single indirect memory access penalty.
The S-CPU does not support FastROM memory access. When you turn it on, it simply uses a different lookup table that takes one less cycle for every opcode, even if that opcode never accesses any FastROM regions, or even if it accesses it multiple times (eg 16-bit RMW).
S-CPU open bus is faked. It returns address>>8 because that is faster than storing the MDR after each successful read. Works great on lda $004212, not so great on lda [$00]. Enjoy MMX v1.0 Chill Penguin stage.
DMA does not consume any CPU time.DRAM refresh is non-existent. Different memory access speeds do not exist. The S-PPU field bit was not implemented until v1.51, which would deadlock all of my timing tests.
The S-CPU runs 40% faster than a real CPU, because you're more likely to break a game by running too slow than by running too fast.
Unlike NESticle, where people hacked NES ROMs to run in it, the hacks are stored internally. Even when you think you've found them all, you miss the "hidden" ones, like for Uniracers. It knowingly behaves wrong on OAM address reset to get the game to have the right value to work, and this affects every game instead of just one.
The S-DSP never writes to the echo buffer at all, it keeps its own internal one.
And it wouldn't be a "byuu post" if I didn't bring up that I first reported the VRAM write during active display bug in 1998. It's a one-line fix.
I'm also somewhat disappointed with the direction of Snes9X v1.52. They went with blargg's accurate DSP core, but they paired it with opcode-based CPU and SMP cores, largely negating its merit (try Earthworm Jim 2.) A much better accuracy to performance tradeoff would have been a cycle CPU core with blargg's fast DSP or anomie's DSP. 9X is now "only" ~80% faster than bsnes, but not much more accurate than when it used to barely compete with ZSNES on speed.
And of course, my emulator is slow as a snail and the GUI+drivers are buggy as all hell. Thanks to Qt there's a new mystery bug with every build.
We really, really, really need some new blood.
Quote:
The S-CPU does not support FastROM memory access. When you turn it on, it simply uses a different lookup table that takes one less cycle for every opcode, even if that opcode never accesses any FastROM regions, or even if it accesses it multiple times (eg 16-bit RMW).
You'd cringe if you saw my ARM emulator then. All LDR/STR ops take the same number of cycles regardless of whether they access ROM or DTCM, and whether they are part of a chain of sequential accesses or not.
My swiWaitVblank emulation simply adds to the cycle counter the number of remaining cycles until the next vblank and returns immediately.
But accuracy was never a goal of that project - speed was (which in retrospect should've made me go dynarec instead of interpreting).
Speaking of zSNES, it has another major flaw: no debugger. None that I've seen anyway. At least Snes9x has a mod that contains a debugger, but it doesn't help much when the emulator emphasizes compability with the existing library of commercial games rather than accuracy.
ZSNES has a debugger, but whoever converted it to ncurses completely ruined it in trying to make it portable.
Get v1.42 for DOS and run in DOSbox. "zsnes -d romname.sfc"
I personally think it's a fantastic debugger, and it's how I did all my ROM hacking for seven years. I much prefer it to Geiger's, probably because I don't have to be on Windows or Wine.
Quote:
But accuracy was never a goal of that project - speed was (which in retrospect should've made me go dynarec instead of interpreting).
Yeah, I always come off as an ass with these rants. If the goal is speed, then they did an even better job than NESticle. ZSNES is the only way to go when you want to game on your Packard Bell Navigator. 9X is the only way to go for your PSP.
They both definitely have their places. Accuracy and development are not two of them. And if people would understand this and stop
comparing two entirely different goal emulators, I would have a much more enjoyable experience in this community.
byuu wrote:
Yeah, I always come off as an ass with these rants. If the goal is speed, then they did an even better job than NESticle. ZSNES is the only way to go when you want to game on your Packard Bell Navigator. 9X is the only way to go for your PSP.
Which reminds me of this email that someone sent to Bloodlust back in 1997:
Quote:
Hello, this is a question.
you do nots think to make a SNESTLICLE or think to make it?
if make it make please it but that they could so that run to a speed 100 % in a pentium to 133 MHz with 16MB of RAM, make it it but similar to nesticle that for my the best emulator.
Ahh and that good has sound as nesticle.
Thanks and I wait a good response.
I guess it doesn't matter that snes9x is displaying a screen full of garbage, just as long as it works on bsnes.
As long as it works on all revisions of the Super NES, it's fine. Any difference between the Super NES and an emulator is either a defect in the emulator (for emulators intended to work on current desktop PCs) or a tradeoff (for emulators intended to work on handheld or set-top devices). If you can arrange the garbage to spell "Use a real SNES" in the snesticle-class emulators, that might help drive the point home.
Yes, test on hardware if you can. Otherwise, make sure you initialize absolutely every register and memory device (just to be safe, avoid the randomness of real hardware on power-on), and make sure it works in bsnes. If it works on hardware but not any emulator, don't care to the emulator.
byuu wrote:
S-CPU open bus is faked. It returns address>>8 because that is faster than storing the MDR after each successful read. Works great on lda $004212, not so great on lda [$00]. Enjoy MMX v1.0 Chill Penguin stage.
What happens exactly? Never heard of this before but I'd heard of many other ZSNES accuracy issues in the past.
Health power ups vanish as soon as soon as they hit the ground.
Shooting certain objects in the CP stage takes you to the password screen.
This happens in the v1.0 ROM, not the v1.1 ROM. Some people think it was anti-piracy that got removed (maybe it was falsely triggering sometimes); others think it's a game glitch. I personally think I'm too lazy to find out or care which one it was :P
Speedy Gonzales 6-1 switch was the best. It reads from open bus in a loop, and even standard open bus isn't enough. You have to allow for an edge case where HDMA triggers right before the address read, so the HDMA routine will eventually fetch the byte that will break you out of the loop after a few hundred passes :D
Quote:
Any difference between the Super NES and an emulator is either a defect in the emulator (for emulators intended to work on current desktop PCs) or a tradeoff (for emulators intended to work on handheld or set-top devices)
I like that. If an emulator wants to be correct but makes a mistake it's a defect, so you can say "I'm only worried about speed" and ignore all emulation issues, even the ones that have virtually no impact on speed, and now it's a tradeoff :)
Nobody does that, but it sounds like a fun solution. I should do that with my performance core when it gets a bit faster.