@Wuerfel_21 said:
5 seconds once. It really has a problem getting started. I want to blame insufficient regulation of the 1.8v rail, but I have nothing to back that up.
I tried another board (the one that's missing the audio IC) and that made it all the way through the knight league - how curious?
Not a good sign. Over 340MHz with all COGs flat out is pushing the P2 pretty hard so you might start to see some board to board performance variations. Yeah you could try the freezer option to see if it helps, or changes anything in the outcome.
The performance variations have been observed with NeoYume already. Though I don't think anyone's been having problems with a Parallax official design (outside of @pik33 and his strange logic bug, but that wasn't an overclock problem)
The SimpleP2 without audio IC is still running fine btw (I left it running over night). Don't know why that one is suddenly super-stable.
@Rayman said:
Is .smc the same as .sfc for the SNES ROM? I guess not, right?
Maybe, maybe not. The file extensions have gotten confused over the years. What's important is that it's exactly 512k (no 512 bytes extra) and has a SHA256 checksum of bf16c3c867c58e2ab061c70de9295b6930d63f29f81cc986f5ecae03e0ad18d2
If you do have the extra 512 bytes at the beginning (the "F-ZERO" string is at $81C0 instead of $7FC0), you can simply delete them with a hex editor.
Ok, I just tried it with P2 Eval and I have a salmon screen with gray vertical strip and "Hello PPU!" at the top...
Guess missing something...
Wait... Forgot needs PSRAM...
Did just get it going on a SimpleP2 board though. Ran for about a minute or two then froze up...
Going to try freezing and then using forced air cooling on it...
Anyway with fan on it, a SimpleP2 board survived two games and still going.
But, the top two or three lines of the display are sometimes garbled. Not sure if that's the SimpleP2 on the edge or the result of using PSRAM4.
Or, maybe my PSRAM4 settings need tweaking or something...
The top two lines being garbled is just how it is, I need to fix some synchronization. Basically the screen is offset by two lines due to video pipeline delay
BTW that one board is still going. No crash after ~13 hours. (Other than me picking up the controller and failing to make the jump on White Land II a few times)
Intriguingly, it's about the same size as the actual cartridge.
Oh, and in terms of the video issues, the binary I posted is actually a few fixes ahead of the last source ZIP. So here's a new one. (Mostly fixes Dracula X, but you'll notice in F-Zero that the bottom lines of some of some of the HUD numbers are no longer cut off)
Also, I figured out why Demon's Crest is broken: It isn't, but because it's using fast ROM mode, it has severe timing crust and thus stays on a black screen for just long enough to make me think it doesn't work when rapid-firing different ROMs at the emulator. Presumably adding HDMA fixed the black screen issue.
Really need to optimize more, but that feels more exhausting right now than fixing all the other stuff.
Is this likely to work with an Edge EC-32MB? I set up config.spin2 like so:
#define USE_PSRAM16
PSRAM_CLK = 56
PSRAM_SELECT = 57
PSRAM_BASE = 40
PSRAM_BANKS = 4
#define INPUT_USE_PINS { <- used this to rule out possible USB-related issues until it runs }
I left all the other symbols at their defaults, and matched my connections to them (A/V board basepin 24).
In misoyume_upper.spin2, I renamed the ROM file to match mine (FZERO.SMC)and put it in the MISOYUME subdir on the card. I had to nuke the first 512 bytes in mine as mentioned above.
This gives an audible click on the audio pins on startup and a black screen.
Is this likely to work with an Edge EC-32MB? I set up config.spin2 like so:
Should work, though I do my development on P2EVAL+96MB.
Don't change too much of the config, it's mostly copy-pasted from one of the other emulators and most settings WILL NOT WORK. In particular:
- Video mode must be VGA2X
- Input must be USB
- HyperRAM does not work
- probably something else I forget
Also, EC32MB only has 1 bank. Bank means chips with a shared select pin. Chips with shared data pins I call "lane". Also, maybe try PSRAM8. I haven't tested 16 bit mode.
Crushed down the decimal math code to make more room
Added H/V counters and some other readable PPU registers (fixes Pocky & Rocky crashing after character select)
Made it so enabling NMI while the NMI pending flag is set triggers an NMI immediately (fixes flashing screen in Pocky & Rocky when playing as Rocky)
Actually allowed one more instruction to execute when NMI is triggered as per above (fixes Jaki Crush)
Fixed player 2 input
Figuring out the H/V counter thing was easy. Apparently the story sequences use a busy wait on the line counter to do a screen split instead of just using HDMA or the IRQ. How odd. I somewhat accidentally realized this because I was running the game in Mesen-S with the event viewer enabled. The NMI thing was also easy because I read about that exact issue.
Anyways, for some reason Jaki Crush requires the NMI to be delayed by one instruction. This is what a real 65816 does when the interrupt registers on the first cycle of an instruction. But strange that that'd come up like this.
Also, as far as missing video modes go, I still need to do modes 2, 4 and 6. These are all the offset-per-tile modes (= column scrolling). OPT works in incredibly strange an obnoxious ways. Basically, BG3's nametable gets repurposed to house a table of scroll values. This is read exactly as if it was a row of tiles on BG3, so all scrolling, nametable size and tile size registers for BG3 are in effect. Also, in modes 2 and 6, two rows are read: one allows vertical column scrolling and the other allows coarse horizontal column scrolling (why would you?). Mode 4 only has one row and lets the MSB of each word decide whether to apply H or V scroll. Also, each entry in the scroll table has bit flags indicating if they affect BG1, BG2, both or neither. Oh, and the tile size flags for BG1 and BG2 are also still effective.
Mode 6 (hires 4bpp + OPT) in particular is so amazing and useful that no real game is known that uses it.
Anyways, now that I have achieved the seemingly impossible task of playing Pocky & Rocky and Jaki Crush with the same code, a new alpha version ZIP file.
I guess next up: OPT modes, adding menu or at least ARGV, tons of bugfixes and optimizations.
Made it so enabling NMI while the NMI pending flag is set triggers an NMI immediately (fixes flashing screen in Pocky & Rocky when playing as Rocky)
Actually allowed one more instruction to execute when NMI is triggered as per above (fixes Jaki Crush)
So, combining those two details together, and the ISR not clearing the pending NMI, allows executing of one non-ISR instruction between each ISR call I presume?
Made it so enabling NMI while the NMI pending flag is set triggers an NMI immediately (fixes flashing screen in Pocky & Rocky when playing as Rocky)
Actually allowed one more instruction to execute when NMI is triggered as per above (fixes Jaki Crush)
So, combining those two details together, and the ISR not clearing the pending NMI, allows executing of one non-ISR instruction between each ISR call I presume?
No. Remember, 65xx NMIs are edge-triggered (otherwise the NMI would constantly interrupt itself). But it is possible to get in multiple NMIs if you disable the NMI and enable it again without clearing it (by reading the RDNMI register). However, the pending flag is also auto-cleared when VBlank ends.
ugh, that wasn't the detail I was trying to clarify. I wanted to know exactly how many non-ISR instructions would be executed between immediate retriggerings when the NMI is not cleared.
@evanh said:
ugh, that wasn't the detail I was trying to clarify. I wanted to know exactly how many non-ISR instructions would be executed between immediate retriggerings when the NMI is not cleared.
The NMI only triggers when the NMI pin goes from high to low. So if it is never cleared, there are no more NMIs (of course, as mentioned, on the SNES specifically, it eventually clears itself automatically). The CPU does not know or care if it is currently executing the ISR.
@evanh said:
so there is no return-from-interrupt instruction?
Yes, but it just pops the status register and PC. For a normal IRQ, this does result in the sort of behaviour you're thinking of, because the interrupt sets the IRQ disable flag after pushing the status. There is no NMI disable flag because then it wouldn't be non-maskable, would it? Thus the edge-trigger mechanism on the NMI pin. If you read a 6502 manual it'll have greater detail on this.
@evanh said:
Reinforces my dislike of NMI ever existing. Always should be an extra IRQ.
Yea. It's easy to cause a crash with this. If your NMI happens inbetween the ISR clearing it and the RTS instruction (of course this would never happen with the VBlank NMI on the SNES), another NMI is triggered before the previous one got to pull its stuff off the stack. So if this happens repeatedly, eventually the stack runs out.
On the C64, the NMI line is directly connected to the RESTORE key on the keyboard. So if you could theoretically mash that key really fast, any program would crash. (In practice there's a debounce circuit. Also, some scene coders figured that you can disable the RESTORE key by letting one of the other NMI sources trigger and then never clearing it)
@Rayman said:
C64…. Hmmm
That’s probably a lot easier to emulate than snes, right? Or, no ?
On one hand, it's a lot slower and simpler. On the other hand, C64 programmers are from a different plane of existence and have figured out how to glitch the VIC-II video chip into having features it was never intended to have. Normally the screen can only be scrolled 7 pixels back and forth and you always need to copy the tile and color maps around to get full smooth scrolling. Except when you write the vertical scroll register in just the right time window, the state machine in the video chip glitches and starts fetching tile data mid-scanline, which results in the addresses for subsequent lines being shifted by an amount depending on the exact cycle the write was done, allowing for smooth horizontal scrolling without copying the entire screen around. Which sounds like a demoscene effect, but Mayhem in Monsterland is a well-known commercial game that makes use of it. Though on some machines this corrupts the RAM. Very funny.
Comments
If bored, try putting board in freezer for a few minutes first..
The audio-less board is still going. Idk why, but that one's a trooper. But it's also a mute, oh bother.
EDIT: Still going!
Not a good sign. Over 340MHz with all COGs flat out is pushing the P2 pretty hard so you might start to see some board to board performance variations. Yeah you could try the freezer option to see if it helps, or changes anything in the outcome.
The performance variations have been observed with NeoYume already. Though I don't think anyone's been having problems with a Parallax official design (outside of @pik33 and his strange logic bug, but that wasn't an overclock problem)
The SimpleP2 without audio IC is still running fine btw (I left it running over night). Don't know why that one is suddenly super-stable.
Is .smc the same as .sfc for the SNES ROM? I guess not, right?
Maybe, maybe not. The file extensions have gotten confused over the years. What's important is that it's exactly 512k (no 512 bytes extra) and has a SHA256 checksum of bf16c3c867c58e2ab061c70de9295b6930d63f29f81cc986f5ecae03e0ad18d2
If you do have the extra 512 bytes at the beginning (the "F-ZERO" string is at $81C0 instead of $7FC0), you can simply delete them with a hex editor.
Ok, I just tried it with P2 Eval and I have a salmon screen with gray vertical strip and "Hello PPU!" at the top...
Guess missing something...
Wait... Forgot needs PSRAM...
Ok, works with P2 Eval and 96 MB PSRAM board.
Are you using the binary I posted or the source? The former was built for SimpleP2 and will not work on EVAL due to SD pin difference
The binary you posted looked too small to work...
Did just get it going on a SimpleP2 board though. Ran for about a minute or two then froze up...
Going to try freezing and then using forced air cooling on it...
I added a --compress flag to flexspin that makes the binaries really small.
Hmm. Didn't know about that...
Anyway with fan on it, a SimpleP2 board survived two games and still going.
But, the top two or three lines of the display are sometimes garbled. Not sure if that's the SimpleP2 on the edge or the result of using PSRAM4.
Or, maybe my PSRAM4 settings need tweaking or something...
The top two lines being garbled is just how it is, I need to fix some synchronization. Basically the screen is offset by two lines due to video pipeline delay
BTW that one board is still going. No crash after ~13 hours. (Other than me picking up the controller and failing to make the jump on White Land II a few times)
Intriguingly, it's about the same size as the actual cartridge.
Ok, that actually makes me feel better
Oh, and in terms of the video issues, the binary I posted is actually a few fixes ahead of the last source ZIP. So here's a new one. (Mostly fixes Dracula X, but you'll notice in F-Zero that the bottom lines of some of some of the HUD numbers are no longer cut off)
Also, I figured out why Demon's Crest is broken: It isn't, but because it's using fast ROM mode, it has severe timing crust and thus stays on a black screen for just long enough to make me think it doesn't work when rapid-firing different ROMs at the emulator. Presumably adding HDMA fixed the black screen issue.
Really need to optimize more, but that feels more exhausting right now than fixing all the other stuff.
Anyways, here's another updated ZIP.
Anyways, current compatibility list to my knowledge:
Cool, making nice progress
Is this likely to work with an Edge EC-32MB? I set up
config.spin2like so:#define USE_PSRAM16 PSRAM_CLK = 56 PSRAM_SELECT = 57 PSRAM_BASE = 40 PSRAM_BANKS = 4 #define INPUT_USE_PINS { <- used this to rule out possible USB-related issues until it runs }I left all the other symbols at their defaults, and matched my connections to them (A/V board basepin 24).
In
misoyume_upper.spin2, I renamed the ROM file to match mine (FZERO.SMC)and put it in theMISOYUMEsubdir on the card. I had to nuke the first 512 bytes in mine as mentioned above.This gives an audible click on the audio pins on startup and a black screen.
Should work, though I do my development on P2EVAL+96MB.
Don't change too much of the config, it's mostly copy-pasted from one of the other emulators and most settings WILL NOT WORK. In particular:
- Video mode must be VGA2X
- Input must be USB
- HyperRAM does not work
- probably something else I forget
Also, EC32MB only has 1 bank. Bank means chips with a shared select pin. Chips with shared data pins I call "lane". Also, maybe try PSRAM8. I haven't tested 16 bit mode.
You also want to change timing. NeoYume needs
so that might work. If not, wiggle delay and sync_data around.
Also, if you haven't used any of the other two emulators before, get one of them working first.
Some more work done:
Figuring out the H/V counter thing was easy. Apparently the story sequences use a busy wait on the line counter to do a screen split instead of just using HDMA or the IRQ. How odd. I somewhat accidentally realized this because I was running the game in Mesen-S with the event viewer enabled. The NMI thing was also easy because I read about that exact issue.
Anyways, for some reason Jaki Crush requires the NMI to be delayed by one instruction. This is what a real 65816 does when the interrupt registers on the first cycle of an instruction. But strange that that'd come up like this.
Also, as far as missing video modes go, I still need to do modes 2, 4 and 6. These are all the offset-per-tile modes (= column scrolling). OPT works in incredibly strange an obnoxious ways. Basically, BG3's nametable gets repurposed to house a table of scroll values. This is read exactly as if it was a row of tiles on BG3, so all scrolling, nametable size and tile size registers for BG3 are in effect. Also, in modes 2 and 6, two rows are read: one allows vertical column scrolling and the other allows coarse horizontal column scrolling (why would you?). Mode 4 only has one row and lets the MSB of each word decide whether to apply H or V scroll. Also, each entry in the scroll table has bit flags indicating if they affect BG1, BG2, both or neither. Oh, and the tile size flags for BG1 and BG2 are also still effective.
Mode 6 (hires 4bpp + OPT) in particular is so amazing and useful that no real game is known that uses it.
Anyways, now that I have achieved the seemingly impossible task of playing Pocky & Rocky and Jaki Crush with the same code, a new alpha version ZIP file.
I guess next up: OPT modes, adding menu or at least ARGV, tons of bugfixes and optimizations.
So, combining those two details together, and the ISR not clearing the pending NMI, allows executing of one non-ISR instruction between each ISR call I presume?
No. Remember, 65xx NMIs are edge-triggered (otherwise the NMI would constantly interrupt itself). But it is possible to get in multiple NMIs if you disable the NMI and enable it again without clearing it (by reading the RDNMI register). However, the pending flag is also auto-cleared when VBlank ends.
ugh, that wasn't the detail I was trying to clarify. I wanted to know exactly how many non-ISR instructions would be executed between immediate retriggerings when the NMI is not cleared.
The NMI only triggers when the NMI pin goes from high to low. So if it is never cleared, there are no more NMIs (of course, as mentioned, on the SNES specifically, it eventually clears itself automatically). The CPU does not know or care if it is currently executing the ISR.
so there is no return-from-interrupt instruction?
Yes, but it just pops the status register and PC. For a normal IRQ, this does result in the sort of behaviour you're thinking of, because the interrupt sets the IRQ disable flag after pushing the status. There is no NMI disable flag because then it wouldn't be non-maskable, would it? Thus the edge-trigger mechanism on the NMI pin. If you read a 6502 manual it'll have greater detail on this.
Reinforces my dislike of NMI ever existing. Always should be an extra IRQ.
Yea. It's easy to cause a crash with this. If your NMI happens inbetween the ISR clearing it and the RTS instruction (of course this would never happen with the VBlank NMI on the SNES), another NMI is triggered before the previous one got to pull its stuff off the stack. So if this happens repeatedly, eventually the stack runs out.
On the C64, the NMI line is directly connected to the RESTORE key on the keyboard. So if you could theoretically mash that key really fast, any program would crash. (In practice there's a debounce circuit. Also, some scene coders figured that you can disable the RESTORE key by letting one of the other NMI sources trigger and then never clearing it)
C64…. Hmmm
That’s probably a lot easier to emulate than snes, right? Or, no ?
On one hand, it's a lot slower and simpler. On the other hand, C64 programmers are from a different plane of existence and have figured out how to glitch the VIC-II video chip into having features it was never intended to have. Normally the screen can only be scrolled 7 pixels back and forth and you always need to copy the tile and color maps around to get full smooth scrolling. Except when you write the vertical scroll register in just the right time window, the state machine in the video chip glitches and starts fetching tile data mid-scanline, which results in the addresses for subsequent lines being shifted by an amount depending on the exact cycle the write was done, allowing for smooth horizontal scrolling without copying the entire screen around. Which sounds like a demoscene effect, but Mayhem in Monsterland is a well-known commercial game that makes use of it. Though on some machines this corrupts the RAM. Very funny.