SpritesMind.Net

The fixed one works as intended in every emulator I throw it into including Blastem, but not from Megacart. If I was going to venture some sort of guess it probably has to do with bankswitching or something, but that doesn't explain a lot when commercial games by and large are compatible. Here it is:

https://mega.nz/#!GlIjVKJC!DKLejUAcaisj ... 6dthPeikoo

The code is very conservative and conventional too. Holding z80 for pad reads, using gemsdmastart/gemsdmaend before and after DMA. VRAM is still loaded in software, the DMA is only used for the palette and a copy of the sprite attribute table in RAM. There isn't even any use of sprites in this ROM so it shouldn't even trigger, actually.

Thanks. I'll give it a go in my Mega Everdrive tonight after work. Might still work there though since the menu does some initialization. If I had to guess, the problem might be some piece of hardware state that you're failing to initialize and the emulators in question just happen to start things out with the correct state. I'll let you know how it goes.

OK, I found the problem. Your compiler is "helpfully" optimizing some writes of 0 to the VDP data reg to clr instruction. On the 68000, this actually issues a read first as it uses some generic microcode for handling the effective address. This is a bad thing when the target is the VDP data port and the VDP is configured for writes, as the read ends up waiting forever for a RAM fetch that never happens. The reason this does not fail in BlastEm is that I am incorrectly not performing a read. I will fix that within the next day or so (in the middle of a different change).

The first offender is at $154E. Patching that to use a move instruction instead, gets it through the SEGA logo, but then it freezes again sometime after that. I'm guessing it's the same problem, just in a different function.

How is the pointer to the VDP port declared?

Like so
I've traced it to at least one function to clear a plane, since it always writes zero to clear it wants to use clr.l to do it.

I'm assuming I need to throw another keyword in there? Or just rewrite it in asm

Mask of Destiny wrote:OK, I found the problem.

Nice find by the way! I had actually heard about this issue once upon a time but of course couldn't put two and two together.

Also, I was confused for a bit because the assembly source emitted by the compiler (vbcc) didn't actually contain a clr instruction. It turns out the assembler (vasm) makes the substitution... which is why playing with compiler optimization levels (one of the first things I tried) didn't do anything. Unfortunately there doesn't seem to be a switch to disable that particular optimization, but there is a -no-opt switch.

powerofrecall wrote:Like so

Code: Select all

uint32_t *data = (uint32_t *)VDP_DATA;

Yeaaaaaaaaaaaah it'll just assume it's RAM. It may even reorder those writes!

You need something like this: EDIT: ouch assembler wtf! =/

Any pointer used to access a hardware register should be declared with the volatile keyword (like Sik suggested above). A standards compliant compiler will perform all accesses through such a pointer in the original order (with respect to sequence points anyway) and will do exactly as many accesses as you specify. Unfortunately, compilers are not always compliant (especially ones for architectures that have fallen out of favor). Given that it's the assembler doing this, it seems unlikely that volatile will help in this case.

Mask of Destiny wrote:Unfortunately, compilers are not always compliant (especially ones for architectures that have fallen out of favor).

Ironically, this is one of the main reasons I went with vbcc in the first place. It's still actively getting worked on, even if it is a little rough around the edges, and 68k is pretty much the main target for it. Plus using a modern GCC to build Genesis stuff felt not unlike using a shotgun to swat a fly, you know?

vbcc is still missing functionality that even old 68k C compilers had though. Right off the top of my head there is no extension to specify fastcall or stdcall in a function declaration for instance. :/ And the documentation, to put it bluntly, sucks my ass. I am going to have to take time to figure out how to make it not "optimize" where I don't want it to.

No matter WHAT I tell the assembler to do it insists on generating clr.l (a1). This is what I meant by bad documentation, there's probably something I'm not doing right.

btw joypad & dma should be in same gemsdmastart() gemsdmaend() block.
You don't need to stop z80 for joypad. All you need is guarantee no access to m68k bus. That is done by this funcs.

r57shell wrote:btw joypad & dma should be in same gemsdmastart() gemsdmaend() block.
You don't need to stop z80 for joypad. All you need is guarantee no access to m68k bus. That is done by this funcs.

I saw this in that Gargoyles source dump and thought it was kind of strange but I guess it makes sense

This is beginning to drive me a little crazy. The source emitted by the compiler contains move.l #0,(a1), manually assembling that with -no-opt generates a listing file that also contains move.l #0,(a1), but something about the process of compile->assemble-> link it is getting "optimized." No commandline options seem to change this on either the compiler or assembler and I doubt the linker is doing it.

Oh well, this isn't something I can bother you guys with, so thanks for the help and I guess that leaves me to scour Amiga boards for the answer to this one, lol.