What's new

Game Boy

aprentice

Moderator
Dark Stalker said:
I've mostly been bug-fixing lately and I've worked a lot on timing. Regression testing was hell, but I think I've finally just about hit the spot (or pretty close to it, since new surprises have been appearing all the time up until now). During this I came across a few things that may be relevant to some of your problems (bcrew/aprentice).

For super mario land 2 to work, you need to allow execution of vblank-interrupts when the display is disabled.

For waverace to work, you need to do lyc-compare during vblank (note that if you don't take some precations, this will break other games).

The lyc compare during vblank definately fixed waverace, brilliant find dude :)
Im not sure what you mean by execution of vblank when the display is disabled though. I dont really emulate turning off the display though yet, dunno if that makes a difference even. Btw, how are you handling the timing for the lcd modes?
 

Dark Stalker

New member
aprentice said:
The lyc compare during vblank definately fixed waverace, brilliant find dude :)
Im not sure what you mean by execution of vblank when the display is disabled though. I dont really emulate turning off the display though yet, dunno if that makes a difference even. Btw, how are you handling the timing for the lcd modes?
If you're not disabling display according to the LCDC register you'll have problems getting past the title screen (and a lot of other games will break too). It's just not very well documented exactly what gets disabled when the lcd is off. I had to try lots of combinations to find a solution that didn't break anything. Just ask if you want to know how I've implemented it.

Timing lcd-modes can be a bit strange. Some documentation claim that mode3 is set longer according to the number of sprites on the the line being drawn, which in turn makes mode0 shorter. I implemented that, but it gave me a flashing line in Mega Man 5, so I've backed down to setting fixed intervals again for now.
When the LY-register has been incremented, I set mode2 for 80 cpu cycles (20 machine cycles) and check if I should request an oam lcdstat interrupt. Then mode3 is set for 172 cpu cycles. When mode3 is done, I draw the line, set mode0, and check if hsync lcdstat interrupt should be requested. Mode0 is staying set for 204 cpu cycles. After that LY is incremented, and mode2 will be set again.

When LY reaches 144 I set mode1 and request v-blank interrupt (and lcdstat if apropriate). Vblank should then last for 4560 cpu cycles.
 

refraction

PCSX2 Coder
this is all i could find on the lcd thing

Stopping LCD operation (bit 7 from 1 to 0) must
be performed during V-blank to work properly. Vblank
can be confirmed when the value of LY is
greater than or equal to 144.

The Mode Flag goes through the values 0, 2,
and 3 at a cycle of about 109uS. 0 is present
about 48.6uS, 2 about 19uS, and 3 about 41uS.
This is interrupted every 16.6ms by the VBlank
(1). The mode flag stays set at 1 for about 1.08
ms. (Mode 0 is present between 201-207 clks, 2
about 77-83 clks, and 3 about 169-175 clks. A
complete cycle through these states takes 456
clks. VBlank lasts 4560 clks. A complete screen
refresh occurs every 70224 clks.)
 

aprentice

Moderator
Dark Stalker said:
If you're not disabling display according to the LCDC register you'll have problems getting past the title screen (and a lot of other games will break too). It's just not very well documented exactly what gets disabled when the lcd is off. I had to try lots of combinations to find a solution that didn't break anything. Just ask if you want to know how I've implemented it.

Timing lcd-modes can be a bit strange. Some documentation claim that mode3 is set longer according to the number of sprites on the the line being drawn, which in turn makes mode0 shorter. I implemented that, but it gave me a flashing line in Mega Man 5, so I've backed down to setting fixed intervals again for now.
When the LY-register has been incremented, I set mode2 for 80 cpu cycles (20 machine cycles) and check if I should request an oam lcdstat interrupt. Then mode3 is set for 172 cpu cycles. When mode3 is done, I draw the line, set mode0, and check if hsync lcdstat interrupt should be requested. Mode0 is staying set for 204 cpu cycles. After that LY is incremented, and mode2 will be set again.

When LY reaches 144 I set mode1 and request v-blank interrupt (and lcdstat if apropriate). Vblank should then last for 4560 cpu cycles.

okay, thats exactly what im doing timing wise, not sure why sprites aren't showing in some games. Hmmm.
 

Dark Stalker

New member
That might be because you shouldn't be changing mode-values while the display is disabled. :p
I think some games choose to disable the display to write sprite data.
 
Last edited:

aprentice

Moderator
Dark Stalker said:
That might be because you shouldn't be changing mode-values while the display is disabled. :p
I think some games choose to disable the display to write sprite data.

edit: scrap all i just said, MARIO LAND 2 works!!!
you were right about the lcd disabled thing, thanks dude :)

<bragging>
marioland2.gif

marioland2_tree.gif

</bragging>

mario land 2 with vsync enabled :p

only problem is the sprites issue wasnt fixed and super mario land 4 (jap hack) broke and all the hardware test demos :p
 
Last edited:

Dark Stalker

New member
Congrats! Must feel good to finally get that annoyance out of your life :p

Yep, things break once something else works, I've gotten used to that by now. It took me an unpleasant amount of guesswork and experimenting to get it all (hopefully) working together.
 

aprentice

Moderator
Dark Stalker said:
Congrats! Must feel good to finally get that annoyance out of your life :p

Yep, things break once something else works, I've gotten used to that by now. It took me an unpleasant amount of guesswork and experimenting to get it all (hopefully) working together.

so when bit 7 is set in lcdc, all you do is execute 70224 cycles and nothing more? (besides interrupt execution)
 

Dark Stalker

New member
aprentice said:
so when bit 7 is set in lcdc, all you do is execute 70224 cycles and nothing more? (besides interrupt execution)
Pretty much everything not related to drawing runs as normal until the display is enabled again. I had to deny LCDC interrupt execution for Street Fighter 2 to be satisfied, but that may be the result of something else of course. Also LY should be set to 0, and mode to 0 it seems. The order in which you do things and how often you do them can also affect compatibility greatly btw.
 

aprentice

Moderator
Dark Stalker said:
Pretty much everything not related to drawing runs as normal until the display is enabled again. I had to deny LCDC interrupt execution for Street Fighter 2 to be satisfied, but that may be the result of something else of course. Also LY should be set to 0, and mode to 0 it seems. The order in which you do things and how often you do them can also affect compatibility greatly btw.

ok, setting mode to 0 fixed the games that stopped working as a result of this change :p
 

zenogais

New member
Seeing those pics or Mario Land 2 brings back alot of memories. You guys rock! :)
I've still got a long ways to go, but I've finished the CPU stuff and now I'm working on video.

Update:

Picture page updated here
 
Last edited:

Doomulation

?????????????????????????
Hey you guys, anyone care posting a source? :p
I need one to see how to do all these fuggin' stuff. The gb is, like, well, a machine to me. Heh, I don't know much 'bout the interior workings of them.
I must try to kick that emulator off for a good start at the gb eme which my *cough* co-workers *cough* seems to have abandoned. I'm all by myself now =(
 

bcrew1375

New member
I could give you mine, but it's not nearly as compatible as aprentice or Dark Stalker's code. I also tend not to use the fastest code, so I can understand my own code(I don't understand alot of speed techniques in programming just yet.).
 

hap

New member
How are all of you doing cpu-useage-wise then ?
My chip8 emu uses 0-1% on my athlon 2ghz :) and my (yet unoptimized) nes emu uses about 50% :(
 

zenogais

New member
The leap from Chip8 to NES is a giant one, and 50% doesn't sound at all unreasonable. Although doubtless your code probably could be optimized.
 
Last edited:

Dark Stalker

New member
I just redid my memory code and cleaned up my cpu. Quite magically I've got near 100% compatibility with all my games. :p
Only flaws I can think of is that the menu in FFA has some issues, Street Fighter II has some visual annoyances, and Escape from Camp Deadly has a problem when you "lose".
 

refraction

PCSX2 Coder
Dark Stalker said:
I just redid my memory code and cleaned up my cpu. Quite magically I've got near 100% compatibility with all my games. :p
Only flaws I can think of is that the menu in FFA has some issues, Street Fighter II has some visual annoyances, and Escape from Camp Deadly has a problem when you "lose".

thats simple, your emu is a sore loser :p
 

Doomulation

?????????????????????????
bcrew1375 said:
I could give you mine, but it's not nearly as compatible as aprentice or Dark Stalker's code. I also tend not to use the fastest code, so I can understand my own code(I don't understand alot of speed techniques in programming just yet.).
Oh yeah well who cares about speed?! =) The main objective is to get it working now. I'll see if I can do some own optimizations as well.
I just need to know how to emulate things, not copy code! Heh. I just want to see how it is emulated, so I can write my own code. =)
 

bcrew1375

New member
Hmm, as far as speed, task manager claims my emulator takes over 95% of the CPU time. Though, I seriously doubt that's correct because no other programs are slowing down.
 

Doomulation

?????????????????????????
Doesn't matter if it runs at 10% or 90%, it still might not slow down other programs because windows shares processor power will all apps.
 

Top