SpritesMind.Net

Can someone test my ROM in a real gen/md?

here!

If you have a male plug on the ext port please test it (with a controller)


Thanks

Don't work on my MD1 (board IC BD M5 PAL VA4). Seems like you don't do proper init of security system. Or something like that.

Bah! Or maybe it's hanging on the Z80 loading...

Maybe, but even on emulator sometimes it generate an exception.

Ops I missed that! I just tested it in fusion and gens.

Ok seems that the joypad read has a problem, it gives different results in gens/regen/fusion (accidental emulator detection)

BTW how did you trigger the exception?

I pressed 'A' then 'Start' and got to that screen HardWareMan posted.

Reposted... Please test (again )

Well option A has a yet unknown problem.


When A is pressed:

In Regen:
An exception occurs (probably address error), the screen is grey. But when start is pressed the program is resetted and something goes wrong.

In Fusion:
The screen deforms (plane dimensions changed) but the mappings are the same.

In Gens:
A gradient from black to red (should be blue) appears, but scrolling it makes it weird green and flicker (raster bugs)

my TMSS bypassed MD2 gave white screen which means the VDP is not initialized properly or you trigger an DMA during reg init and it crashes the system.

Well the code is started with a move #$2700 to sr, so that accidental dma is not started.

I think that "Clr.w VDPdataport" is not allowed, yes?
And "Clr.xx AnyRamLocation" ?

Now the Address error issue (HBL buggy code) in regen is fixed, and the 3 emus show the same gradient.

BIN reuploaded

CLR, BTST and some other instructions cannot be used with VDP

EDIT: Latest greatest still shows white screen, and $2700 in SR will not prevent DMA's from happening, put a $80 into last DMA reg, if you don't have it there.

Well I though you were referring to Vblank DMAs, before the code inits properly. That's why the move to sr is right at the start.

But now I'm doing a "MOVE.w #$8100, VDPControlport" after deactivating HBL/VBL. This should end with the accidental DMAs...


Re-Reuploaded

I'm getting out of ideas

Now it gives a black screen instead of white

At least it DMA filled Vram with 0s...

Going to check if more clears/tests are done on the vdp ports...

OPS! I am...

Done! Removed every clear to the vdp ports. there weren't any tsts/btsts.

Re-Re-Reuploaded

Jorge Nuno wrote:Well I though you were referring to Vblank DMAs, before the code inits properly. That's why the move to sr is right at the start.

But now I'm doing a "MOVE.w #$8100, VDPControlport" after deactivating HBL/VBL. This should end with the accidental DMAs...

I think you may be confusing DMA and interrupts. Both of the measures you've described disable interrupts and have nothing to do with DMA.

I'm not It's that I only do DMA copies in VBlank. And clearing register $81 should disable all kinds of DMA, unless there is some obscure bug.