Alright dudes, I need your help! (soft-reset bug)

[Sik]

Any pointer used to access a hardware register should be declared with the volatile keyword (like Sik suggested above).

Yep, though one has to be careful because it's easy to get the declaration wrong (since you have both the type of the pointed data and the type of the pointer iself, you need to ensure volatile applies to the former). Also it's important to declare it static or the pointer will end up being stored in RAM, though this also means every file needs to declare it (easiest way is to just cram it inside a header).

Given that it's the assembler doing this, it seems unlikely that volatile will help in this case.

Depends if the compiler passes the assembler a hint if the variable is volatile.

Plus using a modern GCC to build Genesis stuff felt not unlike using a shotgun to swat a fly, you know?

Is it? I know Sega used GCC for the Saturn, I wouldn't be surprised if GCC was also an option with the Mega Drive. Really the only difference is that you'd be using a newer version of the tool in question.

[powerofrecall]

Plus using a modern GCC to build Genesis stuff felt not unlike using a shotgun to swat a fly, you know?

Is it? I know Sega used GCC for the Saturn, I wouldn't be surprised if GCC was also an option with the Mega Drive. Really the only difference is that you'd be using a newer version of the tool in question.

Back then it would have been GCC out of the 2.x series--probably not really comparable to commercial 68k compilers of the time, but back when 68k was still at least an active target in development. These days if you want to use GCC on a modern operating system you have to use the 4.x series at least, it's kind of a pain in the butt to compile for cross targets because it seems really sensitive to what version of binutils/gcc/gmp etc you are going with and on top of all that I think (though I'm not sure) vanilla 68k is basically a dead/deprecated target for that toolchain anyway. You can build the whole of vbcc in about 2 minutes--and that's mostly typing out the build commands, and you can easily throw the binaries in your local ~/bin and get going.

The downside of course is what I mentioned earlier. It's hackish, mostly used by the Amiga enthusiast community (though I guess Jaguar hobbyists use it too), and not documented really well. In all other aspects to me it compares favorably to GCC or in some ways is better.

[Mask of Destiny]

I'm not sure GCC is necessarily going to be any better on this. I seem to remember some threads in which GCC was incorrectly optimizing volatile access (don't remember which version) on the 68000 target. I seem to remember Chilly Willy resorted to a combination of putting hardware accessing code in a separate file with a lower optimization level and using assembly.

Looking at the vasm manual, it looks like optimizing move #0, <ea> to clr <ea> is only enabled default if you tell it that you're targeting something newer than a 68000. Are you passing -m68000 to vasm?

[powerofrecall]

Looking at the vasm manual, it looks like optimizing move #0, <ea> to clr <ea> is only enabled default if you tell it that you're targeting something newer than a 68000. Are you passing -m68000 to vasm?

Yeah, -m68000 is getting passed to vasm and -cpu=68000 is getting passed to vbcc. Also tried -no-opt on vasm, that didn't work either, and -no-peephole on vbcc. Same result.

The options seem to work if passed directly to the assembler rather than through the vc frontend, so I worked around it that way. Everything is good now! I will know what to watch out for in the future though if it stops working suddenly.

[Stef]

I never encountered any problem in GCC as soon you specify the "volatile" keyword for port access.
It's true than when you want to clear memory, it's use the dumb CLR instruction (which is actually slower then a simple move). I made some specials methods in SGDK (getZeroU8(), getZeroU16()...) to force move instruction use instead for faster memory clear operation.

[Sik]

Yeah it does a dummy read, but it's not slower than using MOVE #0 (they take the same amount of cycles), so I'm guessing GCC is using CLR simply because it takes up less memory. It's only an issue when either 1) you're doing lots of clears so MOVE from a register becomes faster or 2) you're accessing hardware and reads have a side-effect.

[Stef]

Yeah i was speaking about "memory clear" operation, in which case GCC does not optimize it correctly if you use 0 value, it does for other value (memory fill) but for 0 it forces the CLR instruction :-/

[Mask of Destiny]

So I was wrong about why this didn't break in BlastEm. clr was correctly reading from the operand, but I had some old incorrect code that would just return 0 if trying to read while the VDP was configured for writes. That has been fixed and it now freezes and prints a helpful message when running the broken binary. You'll have to build from source (or wait a few days) if you want to try it out though.