Help with SA-1 demo
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
Help with SA-1 demo
Hi,
I've been writing a SNES demo to be released at Revision 2019, which happens next weekend. Development has been going well so far, but a few days ago I decided to put it in an SA-1 cart and test it on hardware.
For some bizzare reason, despite working perfectly in BSNES, it does not work on hardware. It shows a pink screen, which means that the main CPU code is running, but the main part of the demo does not play.
Over the past few days I've tried everything I could think of to make it work, including copying config code from Jumpin' Derby but the BSNES one still works and the cart still doesn't.
I've come up with one of two options:
1. My SA-1 cart is rubbish. This is the better option. In order to test this I need the help of someone else with a SA-1 cart to test it on their system, and then I can try and fix my own cart. I'm not sure why this would be the case ( the demo starts and shows a pink screen) but is still a possibility.
2. There is an inaccuracy between BSNES and hardware. This is more likely, and the worse option. In this case I'd need to probably send someone my code to try and help me debug it theoretically or something, as I can't rely on BSNES-Plus' tools to be accurate. (My code should technically work in mesen-s, but it doesn't support sa1 yet).
Both of these would need to be done in private preferably, because usually demos are kept secret until the party, but will probably make it public on Thursday if I haven't fixed it by then. Sorry for the short notice.
Thanks so much,
Molive.
I've been writing a SNES demo to be released at Revision 2019, which happens next weekend. Development has been going well so far, but a few days ago I decided to put it in an SA-1 cart and test it on hardware.
For some bizzare reason, despite working perfectly in BSNES, it does not work on hardware. It shows a pink screen, which means that the main CPU code is running, but the main part of the demo does not play.
Over the past few days I've tried everything I could think of to make it work, including copying config code from Jumpin' Derby but the BSNES one still works and the cart still doesn't.
I've come up with one of two options:
1. My SA-1 cart is rubbish. This is the better option. In order to test this I need the help of someone else with a SA-1 cart to test it on their system, and then I can try and fix my own cart. I'm not sure why this would be the case ( the demo starts and shows a pink screen) but is still a possibility.
2. There is an inaccuracy between BSNES and hardware. This is more likely, and the worse option. In this case I'd need to probably send someone my code to try and help me debug it theoretically or something, as I can't rely on BSNES-Plus' tools to be accurate. (My code should technically work in mesen-s, but it doesn't support sa1 yet).
Both of these would need to be done in private preferably, because usually demos are kept secret until the party, but will probably make it public on Thursday if I haven't fixed it by then. Sorry for the short notice.
Thanks so much,
Molive.
SNES demos are great
Re: Help with SA-1 demo
I'm afraid this is a sore point for emulation.
It's only been very recently with the 21fx that I've had any ability at all to test the SA1. It's only been very recently that emulators are even remotely accurate with bus conflict timings.
The main difference I've heard of is that only the SNES CPU can access certain I/O registers, and only the SA1 CPU can access other I/O registers. But I don't know for sure which ones are which.
Beyond that, sorry to say, you're in a tough position. If we knew what was wrong, I'd definitely fix it. If you do find out, let me know and I'll fix it.
It's only been very recently with the 21fx that I've had any ability at all to test the SA1. It's only been very recently that emulators are even remotely accurate with bus conflict timings.
The main difference I've heard of is that only the SNES CPU can access certain I/O registers, and only the SA1 CPU can access other I/O registers. But I don't know for sure which ones are which.
Beyond that, sorry to say, you're in a tough position. If we knew what was wrong, I'd definitely fix it. If you do find out, let me know and I'll fix it.
Re: Help with SA-1 demo
Yeah, one of the first things I did was make the main cpu run from WRAM, so the SA1 wasn't constantly tripping up over it, but that wasn't the issue.
I might try getting the SA1 to run from IRAM as well, as that might be faster than reading from rom...
I might try getting the SA1 to run from IRAM as well, as that might be faster than reading from rom...
SNES demos are great
Re: Help with SA-1 demo
Put in an SA-1 cart means booting from other hardware, and then hotswapping carts? EDIT: If yes, then you shouldn't read rom : )
Cart problem might be related to size/presence of BW-RAM (SRAM). And does the cart still work with its original retail ROM?
Software problems might be memory control, memory init, IRQs, or DMAs. Best add simple test codes on SA-1 entrypoint (like writing to IRAM, and then check if the result can be seen on SNES-cpu side) (and do something more meaningful on SNES-cpu side, eg. blink blue+pink, instead of relying on pink only).
For emulation problems, you could try 2-3 other emulators, if your code is unstable then it might behave differently in each emu.
I probably don't have whatever hardware setup that you might need, but I could have a look at the binary in no$sns debugger, maybe I can spot something in the init code or so.
EDIT: To debug main+sa1+apu CPUs in no$sns: Use Ctrl+T to toggle between the different CPUs. There is also an option to warn on invalid memory accesses, if you are lucky then it might instantly tell you what is wrong.
Cart problem might be related to size/presence of BW-RAM (SRAM). And does the cart still work with its original retail ROM?
Software problems might be memory control, memory init, IRQs, or DMAs. Best add simple test codes on SA-1 entrypoint (like writing to IRAM, and then check if the result can be seen on SNES-cpu side) (and do something more meaningful on SNES-cpu side, eg. blink blue+pink, instead of relying on pink only).
For emulation problems, you could try 2-3 other emulators, if your code is unstable then it might behave differently in each emu.
I probably don't have whatever hardware setup that you might need, but I could have a look at the binary in no$sns debugger, maybe I can spot something in the init code or so.
EDIT: To debug main+sa1+apu CPUs in no$sns: Use Ctrl+T to toggle between the different CPUs. There is also an option to warn on invalid memory accesses, if you are lucky then it might instantly tell you what is wrong.
Re: Help with SA-1 demo
I have an SA1 cart a made a while ago which is game I have removed the ROM from and replaced with an IC socket. It takes over 10 minutes (I haven't timed it) to flash and test a 4MB ROM, which is why I didn't do it sooner. (they take another 10-15 minutes under UV to erase.)
I haven't tested the original game recently, but Kirby's Fun Pak was working a few days ago.
My demo doesn't access BW-RAM, or use SA1 DMA or IRQs (It used to, but the interrupts didn't respond fast enough. Guess they don't like being triggered over 30k times a second).
The SA1 is initialized the same way Jumpin' Derby is.
I am currently writing a test screen to test a few things that the SA1 does.
I haven't tested the original game recently, but Kirby's Fun Pak was working a few days ago.
My demo doesn't access BW-RAM, or use SA1 DMA or IRQs (It used to, but the interrupts didn't respond fast enough. Guess they don't like being triggered over 30k times a second).
The SA1 is initialized the same way Jumpin' Derby is.
I am currently writing a test screen to test a few things that the SA1 does.
SNES demos are great
Re: Help with SA-1 demo
Will that work on a stock SNES? Pulling the cart out will deadlock it. Breaking pin 4 off the CIC to allow hot-swapping will prevent SA1 games from booting.Put in an SA-1 cart means booting from other hardware, and then hotswapping carts? EDIT: If yes, then you shouldn't read rom : )
But is the SA1 just locking out the ROM, or is it disabling the entire SA1? You couldn't really upload your own code to ROM anyway, so if the rest of the SA1 is functional, then that's the most viable path for most people to test SA1 code on through BWRAM.
Re: Help with SA-1 demo
If it's not known yet what I/O registers are accessible by what processor, I guess the recently released SA-1 implementation in SD2SNES isn't any more accurate than in bsnes or Higan?
Re: Help with SA-1 demo
Oh yeah: on SD2SNES it shows only black screen when I tested it.
SNES demos are great
Re: Help with SA-1 demo
In no$sns it's pink screen. You can see that for yourself if you have windows (or wine).
With the bad memory access warnings enabled it complains about:
2210h written by main cpu, that's not possible as far I know.
2261h written by main cpu, that's probably from the Jumpin Derby code? The register is undocumented and no other games use it.
Oh, and no$sns is bugging about setting the auto-increment bit in VBD register. That's not a bug, and it might work perfectly fine on hardware (the warning is just there to say that "this is first ever program seen setting that bit").
And, having quick look at SA-1 CPU, the PC seems to sit at what looks like a valid entrypoint. But it does seem to start execution. The state of the CCNT register can be viewed in Window --> Cart Profile (showing coprocessor registers, that 's, yeah, not so elegant, but it works). The CCNT register seems to be 20h (but, as far as I know both bit5 and bit6 should be cleared to "run" code on the SA-1 CPU).
With the bad memory access warnings enabled it complains about:
2210h written by main cpu, that's not possible as far I know.
2261h written by main cpu, that's probably from the Jumpin Derby code? The register is undocumented and no other games use it.
Oh, and no$sns is bugging about setting the auto-increment bit in VBD register. That's not a bug, and it might work perfectly fine on hardware (the warning is just there to say that "this is first ever program seen setting that bit").
And, having quick look at SA-1 CPU, the PC seems to sit at what looks like a valid entrypoint. But it does seem to start execution. The state of the CCNT register can be viewed in Window --> Cart Profile (showing coprocessor registers, that 's, yeah, not so elegant, but it works). The CCNT register seems to be 20h (but, as far as I know both bit5 and bit6 should be cleared to "run" code on the SA-1 CPU).
Re: Help with SA-1 demo
Thanks for your help!
Not sure where you got that, I write to TMC using the SA1.nocash wrote:2210h written by main cpu, that's not possible as far I know.
Yeah, that'll be the config settings.nocash wrote:2261h written by main cpu, that's probably from the Jumpin Derby code? The register is undocumented and no other games use it.
Does seem a bit odd that no other program used this feature.nocash wrote:Oh, and no$sns is bugging about setting the auto-increment bit in VBD register. That's not a bug, and it might work perfectly fine on hardware (the warning is just there to say that "this is first ever program seen setting that bit").
In order to start the SA1, I run "stz CCNT". I don't write to CCNT anywhere else.nocash wrote:The CCNT register seems to be 20h (but, as far as I know both bit5 and bit6 should be cleared to "run" code on the SA-1 CPU).
SNES demos are great
Re: Help with SA-1 demo
So I rewrote my code to have a few checks at the start, and to display the results to the screen.
I just tested it on hardware, and all of them failed.
All I got was a black screen, which I thought was impossible - and then I realized: right after starting the SA-1 I wait on interrupt for it to get ready. If the interrupt didn't fire it means the SA-1 is running no code whatsoever. It's like I never turned it on (removing the stz CCNT produces identical results).
What on earth?
I just tested it on hardware, and all of them failed.
All I got was a black screen, which I thought was impossible - and then I realized: right after starting the SA-1 I wait on interrupt for it to get ready. If the interrupt didn't fire it means the SA-1 is running no code whatsoever. It's like I never turned it on (removing the stz CCNT produces identical results).
What on earth?
SNES demos are great
Re: Help with SA-1 demo
2210h is written at 01:8CFA, but now that you are saying it... no$sns is somewhat randomly showing "main" or SA-1" as current CPU in lower-right of the debug screen... that looks like a glitch in the no$sns debugger... What seems to be wrong there is: If you reset the emulation while the debugger is in SA-1 view... then the emu seems boot up with SA-1 and SNES cpu's swapped, whoops : )
Okay, but that glitch occurs only if SA-1 view was used before reset. When not doing that:
In that case 2200h is 00h (SA-1 running), that's fine. And the 2210h write is done on SA-1 side, that's fine, too.
APU is in an endless loop at 0284h? Main CPU is also in an endless-loop at 7F:0060 for audio streaming with several NOPs? And IRQs/NMIs are both disabled... hmmm. And SA-1 is somewhere at 01:8C7B.
And, btw. when also enabling the illegal opcode warning... at 00:8036 is that a reserved WDM opcode?
For the VDP auto-increment bit. I am not sure what the bit is doing at all... apart that it is supposedly incrementing something?
I think VDP is solely used by Jumpin Derby, and that one is having auto-increment disabled.
Which SA-1 register is accessible by which CPU isn't really unknown. It's documented in fullsnes.htm, and probably also in book2.pdf. At worst there might be 1-2 mistakes in those specs (and it lacks specs for undocumented registers like 2261h).
Okay, but that glitch occurs only if SA-1 view was used before reset. When not doing that:
In that case 2200h is 00h (SA-1 running), that's fine. And the 2210h write is done on SA-1 side, that's fine, too.
APU is in an endless loop at 0284h? Main CPU is also in an endless-loop at 7F:0060 for audio streaming with several NOPs? And IRQs/NMIs are both disabled... hmmm. And SA-1 is somewhere at 01:8C7B.
And, btw. when also enabling the illegal opcode warning... at 00:8036 is that a reserved WDM opcode?
For the VDP auto-increment bit. I am not sure what the bit is doing at all... apart that it is supposedly incrementing something?
I think VDP is solely used by Jumpin Derby, and that one is having auto-increment disabled.
Don't know for sure with SA-1. Hotswapping should work with most carts (as long as the CIC in the console is disabled, of course). And there should be some ways to boot SA-1 carts even the console's CIC is disabled, or if the PAL/NTSC region of the CICs don't match up (something like rewiring CIC CLK to GND or VCC, or installing an external CIC with separate Reset button in the SA-1 cart as last resort).byuu wrote:Will that work on a stock SNES? Pulling the cart out will deadlock it. Breaking pin 4 off the CIC to allow hot-swapping will prevent SA1 games from booting.Put in an SA-1 cart means booting from other hardware, and then hotswapping carts? EDIT: If yes, then you shouldn't read rom : )
Which SA-1 register is accessible by which CPU isn't really unknown. It's documented in fullsnes.htm, and probably also in book2.pdf. At worst there might be 1-2 mistakes in those specs (and it lacks specs for undocumented registers like 2261h).
Re: Help with SA-1 demo
Yep, this sounds correct.nocash wrote:APU is in an endless loop at 0284h? Main CPU is also in an endless-loop at 7F:0060 for audio streaming with several NOPs? And IRQs/NMIs are both disabled... hmmm. And SA-1 is somewhere at 01:8C7B.
BSNES-Plus can use WDM as a software breakpoint on the debugger. LibSFX can insert them with the macro "break" if in debug compile mode.nocash wrote:And, btw. when also enabling the illegal opcode warning... at 00:8036 is that a reserved WDM opcode?
SNES demos are great
Re: Help with SA-1 demo
I wonder if it has something to do with cart headers? Do we know if the SA-1 checks them?
EDIT: it's not
EDIT: it's not
SNES demos are great