GSS hanging on hw, spc quirk?

Using Shiru's SNES GSS, a ROM that works in every emulator including latest higan, plays some noise and hangs on hw. This is during the bootup GSS load, no IRQs or NMIs are firing, and by random chance we found that adding a delay after spc_load_data but before spc_command(SCMD_INITIALIZE) made things work.

Are there known spc quirks that need working around, that could cause this? It could also be a bug in the GSS code, but I don't want to bother Shiru without being sure.

I have been having a very similar issue with SNESGSS; my WIP ROM works fine on emulators including bsnes-mercury v094 accuracy, but the SPC hangs after sending cmdInitialize on hardware. Interestingly, the SPC loads fine and the music plays after a console reset. Also, at the point where the SPC hangs, i.e. during the wait loop for SNESGSS to signal ready, I am seeing $AA on APUIO0 and $BB on APUIO1 as if the SPC had somehow jumped back to the IPL after getting cmdInitialize (but only on first load from the SUP8, -not- after a reset). Of note, I am doing all my hardware testing with a 1/1/1, and a Super UFO Pro 8. Also, my rom has been tested on a SD2SNES and has no problems booting and setting up the SPC on that cart.

EDIT: Just tried adding that delay where you did (I used 6~7 seconds) and I'm still ending up with the SPC going off the rails and ending up in the IPL (until a reset, then it still works fine as before after a reset)

I would guess minor bug in SPC code. If waiting just a little bit between steps fixes it.

The SPC runs an automated program, and perhaps it hadn't jumped to the "waiting for new input" loop yet and was still finishing up on some "loading" loop code. And you were too fast for it.

This almost sounds like viewtopic.php?p=229195#p229195 (read quoted material and paragraph after it)

There are documented "cautions" with the SPC700 that are outlined in the official developers manual; all 10 of them are outlined in Chapter 9. At least two pertain to issues that can arise based on timing/delays during I/O or data transfer. Section 9.9 sounds very close to what IGH described above.

Edit: I should add I know absolutely nothing -- LITERALLY NOTHING -- about "GSS".

Yes, I forgot to mention that reset made things work here too. Thanks IGH for the additional info.

I don't have the SNES manual, but will try to find it now, thanks koitsu.

Okay, it shouldn't be 9.9, since there are no interrupts or NMIs happening. It could be 9.10, since GSS was doing 16-bit writes to APU01. I've changed them to 8-bit writes, in the order that writes APU1 before APU0 like Memblers mentions in that link. Works in emulators, will report later if this fixes it on hw.

I've been doing 8-bit writes the whole time, as per that warning, and I'm still getting the GSS crash/hang issue.

It helped slightly, but still happens. How do we summon byuu?

I have a theory but no way to test it. The superfamicom wiki mentions a hazard if both cpus are reading/writing a channel at the same time. All other accesses seem protected by ordering except the main command channel. So if a command is written exactly when the spc reads it, the result may be garbage, leading to a jump to the two highest unpopulated cmdList entries. It would then execute data bytes, eventually hit a brk, and reset itself.

No emulator probably emulates this hazard, though I only checked one bsnes fork source. As for why a reset fixes things, anomie's timing doc says a reset sets a consistent alignment for everything. No mention of the alignment on a cold boot anywhere, so unless someone has better knowledge, the cold boot alignment between the cpu and spc is likely such that it leads to this issue.

So if this theory is correct, the following patch would fix it.


...which brings me to the testing issues. The code was written for some ancient bass version. The latest bass has changed the syntax completely, making it not at all viable. There's a bass fork with less changed syntax at ARM9's github, but even that version lacks important features the code uses a lot, like local labels; it also has several bugs in its string and hash nall lib. So there's no assembler able to build the code, even with small changes, requiring pretty much a manual rewrite. I don't really feel doing that, especially as then there's issue #2, needing a Borland Windows environment to build the GSS editor with the new code.

Old forum posts say all other assemblers suck. There's a ca65 macro pack newer than those posts, but that would also need a manual rewrite, since there's no spc700 support in da65.

edit: Patch tweak.
edit 2: quote to code tag

Would it need a rewrite by hand, or would it just need an automated translation? When I worked on Action 53, I remember having to translate a few projects' source code from other syntax to ca65 to get them to build as submultis. I wrote a preprocessor in Python to do the deed.

That patch jibes with what Nintendo provides in official documentation; see Appendix D.4, "Sound Boot Loader v1.1". This post of mine explains the typos/mistakes (caused by bad OCR), as well as assembler nomenclature, of that piece of code -- all of which is important when reading it. Note the repeated cmp $2140 / bne {previous instruction} model used heavily throughout the code. This "nuance" of the SPC700 is actually covered in Appendex D.1 "Data Transfer Procedure" (block/flow diagram) and D.2, "Data Transfer Instruction", though it's not written very well.

In other words: I can see exactly how that patch would alleviate the problem, but the bne mainLoop should really be bne {address of previous cmp CPU0 instruction}. I'm making the assumption CPU0 == $2140 in that code.

How much rewriting would be necessary depends on the features. Even byuu's bass does not support local labels, for starters.

Found a historical archive of old basses at https://gitlab.com/higan/bass, lucky. The last one there, v06r01, manages to compile the code with minor changes to a byte-exact result. Now only to change the gss editor to a command-line app that exports a gss project with this new spc code.

It's not that much code (this patch). Could it be hand assembled? Like, on paper, and then typed in a hex editor?

It's in the middle of everything. You really don't want to hand-shift everything after it, updating references.

https://github.com/clbr/gsscli

The new compiled spc code, and a cli GSS exporter. The cli version's output differs in a few places from the Windows version though, probably some bugs somewhere. Couldn't yet test it on hw.

Is there a compiled .exe available? If not, could someone compile one? Thanks.

Oh, forgot to post here, this fixed the hangs. Using the cli exporter's output sounds fine too, the byte differences were minor and only in size bytes and sfx/music data. It created some bytes smaller optimized songs for some reason, which explained the size byte changes. One byte difference was in BRR data.

There is no exe.

Yes there is. The editor. Here's one.

https://github.com/nathancassano/snesgss?files=1

I haven't used it, but the documents say "The editor exports a number of files: spc700.bin"

I would assume that you had to modify the editor exe to get it to output a modified spc engine.

Right?

I don't see spc700.bin in your files, so am I to assemble it from spc700.asm ?

There is no exe, as in you need to compile it if you want one. spc700.bin includes all your sfx and sounds used by your music, so it's unique to your project.

I didn't modify the editor, I ported the cli logic to a platform-independent binary, under the cli/ folder. You certainly could compile the editor with my changed spc code if you have a suitable Windows Borland env. The cli version is able to export the bin files from a gss file, which you can create with the existing exe from Shiru (that github link is way out of date), but even in that case you need to compile the cli version.

Can I expect that developers of retro console games who use Windows will either have already installed MinGW-w64 and MSYS2 or be willing to install them? My current build process requires Python and GNU Make, and I occasionally get complaints that installing a Python interpreter is a barrier.


Does the free "classic" Borland C++ compiler on this page work, or is the (trialware) C++Builder required?

Of course not. That'd be a barrier. /s

I wonder if people would install Free Pascal / Lazarus for my software... it's only 154MB too, only 1.3GB on disk...

Ok, so if I'm understanding you. I just need to compile the stuff in the cli folder, which makes a minimal comand line tool to make the spc700.bin. (with the bug fix)

I don't have mingw, but I do have cygwin installed. And I have gcc on my linux computer (that I rarely use)

Well, I already told that like, 2 years ago? Do not worry too much about that; if the tools do work, any free software/tools is fine for the common user. One easy step you can do to lower the barrier is to bundle the tools into an installer (Innosetup?) so the user just has to click "next" through it to install. Whatever that minimises the steps to get the thing running is good for the common "noob".