Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - IRQ and Iperiod nightmare :)

Reply to topic
Author Message
Bruno
  • Guest
Reply with quote
IRQ and Iperiod nightmare :)
Post Posted: Tue Nov 21, 2006 6:50 pm
Hi SMS experts.

I'have totally rewritten IRQ system in my emulator. Things work better but i still have problems with 5 roms that doesn't work at

all. After investigation, it's a problem linked to interrupts. All the 5 games are waiting for Bit7 of VDP status to be set, and it

never happens, because an interrupt occurs, accepted by the CPU, and the bit7 is cleared in the IRQ handler... Then i spend time

yesterday evening on smspower.org forums, looking for threads related to IRQ generation. I realise that a lot of emulator coder had

these kinds of difficulties. I read that a common trick consist in changing the number of cycles per line to get a good (or better)

timing.

I can't understand this solution. It's like if the SMS could Overclock it's CPU and i don't think hardware work like this ? The

more complicated for me, is the origin of the problem. Could it be a problem with the timing of CPU instruction? Maybe instead of

increasing CPU cycles per line should i generate the IRQ later ? The theoretical cpu cycles per scanline is 227.70 cycles. My emu

is using 228, so every frame CPU run a few extra cycles. Should i compensate for these extra cycles ? Do i miss something in Charles Macdonald's documentation ?

As you can see i'm lost with these tricky problems. If someone has explainations or ideas about this, please tell me :)

Best regards

Bruno
 
  • Joined: 28 Sep 1999
  • Posts: 1197
Reply with quote
Post Posted: Tue Nov 21, 2006 6:58 pm
Quote

After investigation, it's a problem linked to interrupts. All the 5 games are waiting for Bit7 of VDP status to be set, and it never happens, because an interrupt occurs, accepted by the CPU, and the bit7 is cleared in the IRQ handler...


Because interrupts are only taken between instructions, if the IRQ status flag is set *during* the execution of an instruction the CPU will be able to read it without the interrupt occurring.

For example, "IN A,($BF)" is 11 T-states. If bit 7 of the status flags is reset prior the instruction being fetched and executed, but then set 2 T-states into execution, then the value read from the I/O port will have bit 7 set. No interrupt will happen because we are still executing an instruction. But now that the port has been read, the pending interrupt has been cancelled so when the instruction finishes, no interrupt will occur.

In an emulator, you can cheat by doing something like this:

if(scanline == 192) // Time to set bit 7
{
status |= 0x80 // Set the flag
z80_execute(8) // Run Z80 for a few cycles so it can read the flags
z80_set_irq(); // Assert /INT
}

You basically give the Z80 a chance to poll the flags before the interrupt is asserted.

This is a hack, the proper thing would be cycle-accurate emulation of the Z80 and VDP which is crazy. But for just emulating 228 cycles per scanline, I think this an OK technique.
  View user's profile Send private message Visit poster's website
  • Joined: 21 Jul 2005
  • Posts: 412
  • Location: GBG
Reply with quote
Post Posted: Tue Nov 21, 2006 7:27 pm
Just to clarify your question regarding cycles per scanline... it is exactly 228 cycles on both NTSC and PAL consoles, the only difference being number of lines per frame (and frames per/second).
I let my emulator emulate 1 instruction after I set the vblank flag so it correctly counts the cycles used.
  View user's profile Send private message Visit poster's website
Bruno
  • Guest
Reply with quote
IRQ and Iperiod Nightmare
Post Posted: Tue Nov 21, 2006 7:36 pm
Thank's for the quickest answer i ever had :)

I've just tried your suggestion. It solves all my problem, and all the games are now working. But now i have another question. Do you think this hack is free of side effect ? I mean, it solves problems, but could it generate problem somewhere else ?

Do you think that compensing (executing less cycles on next scanline) the few cycles given before asserting IRQ line could be a good thing ?

Why not, instead of running extra cycles before generating the IRQ, generating the IRQ at the 20th cycles of next scanline ? As you can guess, i'm scared about generating new timing problems :) (maybe more by the need to test once again all SMS/GG roms :)

regards
 
  • Site Admin
  • Joined: 25 Oct 1999
  • Posts: 2029
  • Location: Monterey, California
Reply with quote
Post Posted: Tue Nov 21, 2006 7:58 pm
Well I got out of the emulation authoring business a few years ago and Smeg never did have a particularly high compatibility rate. I remember IRQ timing seemed to be responsible for a number of problems. What are the five games that are affected by this?

I remember some discussion on this here but I don't recall the details. I seem to remember it being proposed that the bit is set shortly before the actual IRQ, but I don't recall if it was proven one way or the other.

Also, since the z80 emulator will rarely emulate exactly as many cycles as you tell it to, are you collecting the overflow result and deducting it from the number of cycles to run the next line? Some z80 emulators might do this automatically. As I recall, the one from MAME returns the actual number of elapsed cycles as a result from the z80_execute() function.
  View user's profile Send private message Visit poster's website
Bruno
  • Guest
Reply with quote
Post Posted: Tue Nov 21, 2006 8:11 pm
The games which give me nightmare were:
Zool (SMS and GG version)
Chicago Syndicate (GG version)
Sega Chess (SMS versions)
Monster Truck War (GG version).

For my cpu core, yes, i'm collecting the cycles overflow result and deduct them on next scanline. But the Hack is running out of my cpu->Run(228) scanline call, and isn't deducted from the next one.
 
Bruno
  • Guest
Reply with quote
Post Posted: Wed Nov 22, 2006 11:32 am
Just for information:

I ran test with Charles Macdonald hack. For me, it solves all the problems with the previously listed game. But it also break a lot of games that worked before. I think this hack must be specific to these games, not included in the main emulation.
 
  • Joined: 12 Apr 2005
  • Posts: 391
  • Location: London, United Kingdom
Reply with quote
Post Posted: Wed Nov 22, 2006 11:45 am
I think I have a similar problem - Chris Covell's high colour Game Gear demo dispays junk unless I run the CPU for a large number of clock cycles between scanlines, where it runs fine.
  View user's profile Send private message Visit poster's website
  • Joined: 21 Jul 2005
  • Posts: 412
  • Location: GBG
Reply with quote
Post Posted: Wed Nov 22, 2006 6:36 pm
Bruno wrote
For me, it solves all the problems with the previously listed game. But it also break a lot of games that worked before.

Care to mention any of those?
And are you running exactly 1 instruction (and not a whole scanline or something like that) after you set the vblank flag?
  View user's profile Send private message Visit poster's website
Bruno
  • Guest
Reply with quote
Post Posted: Wed Nov 22, 2006 7:02 pm
Yes, i ran exactly one instruction after setting Bit7 in VDP status, and before asserting Z80 irq.

I had new problems with:

Alex Kid in Miracle World (gfx bugs) (SMS)

Dinobasher-proto-sms (black screen)
Dynamite Heady (sms and GG versions, black screen)
Ninku 2 tenkuryu... (GG, black screen)
Pet club inu daisuki (GG, black screen)
Nomo's World serie baseball (GG, black screen)
Wimbledon (GG, black screen)

And a lot more, but i can remember exactly and don't want to tell you wrong names. These games could work without problems with your emu, because of a different implementation.
Just tell me if you encounter the same problem with this games, i'm just curious :)
 
  • Joined: 21 Jul 2005
  • Posts: 412
  • Location: GBG
Reply with quote
Post Posted: Thu Nov 23, 2006 9:59 am
I'm not at home right now so I can't check my source, I have an idea though it fells even more like a hack. Try to set the VBL flag after you execute that single instruction as well. I don't remember if that is correct (Charles?) when the bit is set during the execution of an instruction.
I'll look into deeper tomorrow.
  View user's profile Send private message Visit poster's website
Reply to topic



Back to the top of this page

Back to SMS Power!