• entries
222
606
• views
591480

# Compatibility increases further...

1074 views

I've added better memory emulation (that is, handling ROM paging, RAM mirroring and enabling a BIOS or not). I wouldn't dare say "more accurate", as that might indicate that something about it is partially accurate. [smile]

I've isolated one of the biggest problems - and that's programs getting caught in a loop waiting for an interrupt that is never triggered.

The source of these interrupts is the VDP. It can generate two kinds of interrupt - on a line basis (where you can configure it to fire an interrupt every X scanlines) or on a frame basis (where it fires an interrupt at the end of the active display).

Two bits amongst the VDP's own registers control whether the interrupt fires or not. On top of that, there are two internal flags that are set when either of the interrupts fire. They are reset when the VDP's control port is read.

Quote:
 Charles MacDonald's VDP documentationBit 5 of register $01 acts like a on/off switch for the VDP's IRQ line. As long as bit 7 of the status flags [this is the frame interrupt pending flag] is set, the VDP will assert the IRQ line if bit 5 of register$01 is set, and it will de-assert the IRQ line if the same bit is cleared....Bit 4 of register $00 acts like a on/off switch for the VDP's IRQ line. As long as the line interrupt pending flag is set, the VDP will assert the IRQ line if bit 4 of register$00 is set, and it will de-assert the IRQ line if the same bit is cleared.

The way I've chosen to emulate this is as a boolean storing the IRQ status, and to call a function, UpdateIRQ(), every time something that could potentially change the status of it happens.

private bool IRQ = false;private void UpdateIRQ() {    bool newIRQ = (LineInterruptEnabled && LineInterruptPending) || (FrameInterruptEnabled && FrameInterruptPending);    if (newIRQ && !IRQ) this.CPU.Interrupt(true, 0x00);    IRQ = newIRQ;}

This detects a rising edge. Falling edge hasn't worked so well. Well, truth be told, neither work very well. So, hitting the I key in the emulator performs a dummy read of the control port which usually 'unblocks' the program.

I'm hoping that my problem is related to this similar one, as the fix seems pretty straightforwards.

The SEGA logo at the top of this entry is not the only evidence of working commerical software...

Not reading the Start button is a common affliction.

Here's the Game Gear DOOM for Scet. [smile]

Marble Madness appears to be fully playable, though needs prompting from my I key every so often.

Columns can't find the start button either, but the demo mode works.

Getting as far as a title screen is still an achievement in my books.

My luck can't hold out forever, but the homebrew scene is still providing plenty of screenshots...

Maxim's Bock's Birthday 2002 has been immensely useful for sorting out ROM paging issues.

Bock's Birthday 2003 demonstrates the interrupt bug, but appears to run healthily otherwise.

Chris Covell's Hicolor Demo also demonstrates this bug, needing a prod before each new image is displayed.

Aypok's Digger Chan appears to play fine.

Martin Konrad's Zoop 'em Up and GG Nibbles games run, Zoop 'em Up seems to have collision detection issues (aluop-related bug).

The bug in the Z80 core still eludes me - how aluop with an immediate value passes and aluop with a register fails is rather worrying. At least part of the flags problem has been resolved - the cannon in Bock's KunKun & KokoKun still don't fire, but at the switches now work so you can complete levels.

Hey, Faceball. I remember that game. Didn't know they had it for the GG, though.

You can't fool me, that's not DOOM!

## Create an account

Register a new account