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

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

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

Post by powerofrecall » Mon Apr 25, 2016 6:43 pm

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

powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

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

Post by powerofrecall » Mon Apr 25, 2016 6:46 pm

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.

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

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

Post by Mask of Destiny » Mon Apr 25, 2016 7:44 pm

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.

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

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

Post by Mask of Destiny » Tue Apr 26, 2016 6:14 am

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.

Sik
Very interested
Posts: 939
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

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

Post by Sik » Tue Apr 26, 2016 11:52 am

How is the pointer to the VDP port declared?
Sik is pronounced as "seek", not as "sick".

powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

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

Post by powerofrecall » Tue Apr 26, 2016 3:13 pm

Like so

Code: Select all

uint32_t *data = (uint32_t *)VDP_DATA;
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

powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

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

Post by powerofrecall » Tue Apr 26, 2016 3:14 pm

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.

powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

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

Post by powerofrecall » Tue Apr 26, 2016 3:36 pm

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.

Sik
Very interested
Posts: 939
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

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

Post by Sik » Tue Apr 26, 2016 3:50 pm

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:

Code: Select all

static volatile uint16_t* const vdpdata16 = (uint16_t*)(0xC00000);
static volatile uint32_t* const vdpdata32 = (uint32_t*)(0xC00000);
EDIT: ouch assembler wtf! =/
Sik is pronounced as "seek", not as "sick".

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

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

Post by Mask of Destiny » Tue Apr 26, 2016 3:52 pm

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.

powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

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

Post by powerofrecall » Tue Apr 26, 2016 5:26 pm

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.

powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

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

Post by powerofrecall » Tue Apr 26, 2016 5:38 pm

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.

r57shell
Very interested
Posts: 478
Joined: Sun Dec 23, 2012 1:30 pm
Location: Russia
Contact:

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

Post by r57shell » Tue Apr 26, 2016 5:51 pm

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.
Image

powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

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

Post by powerofrecall » Tue Apr 26, 2016 5:56 pm

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

powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

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

Post by powerofrecall » Tue Apr 26, 2016 6:01 pm

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.

Post Reply