What's new

Game Boy

ChaosBlade

My Heart Chose.. Revenge.
Might seem like a silly question, was looking at that GB tech PDF, the $ signs account for memory addresses ? $FF00 would be 0xFF00 ?
 

ZeroEffect

New member
Is there an contradiction in the Gameboy CPU Manual (aka Everything you always wanted to know about the GameBoy...)?

From the I/O Registers section for TMA($FF06), the doc indicates "When TIMA overflows, this data will be loaded"

Whereas in the Timer section, the document mentions that TMA is used to divide the value of the clock set in TIMA.

In Otaku's cribsheet DIV($FF04) is indicated as the Timer Divider register.

What is the correct use of these registers?
 

Pontifice

Learning
Now i get something ---> some sprites

gl-gb.JPG


Ufff i rewrote the cpu core two times and the bug was in the drawing routine, first i wasn't drawing anything, second i made a 10x zoom.


Thanks bcrew1375 your sources clarified many things about gb to me
 

ChaosBlade

My Heart Chose.. Revenge.
Well, update, i guess ill have to wait with this project for now. started boot camp this week, so no time to program and my muscles are in no state to code :p

Nice to see all of you guys progress tho, im waiting to see your names in some upcoming next-gen cool emnlation project ;)
 

LinkOfTime

New member
I have a question about a GB emu I am making...
How do you draw the pixels of the GB to the screen?
For now I use the DirectDraw DrawBox method for each pixel but screen refresh is waaaaayyy too long using that method (about 0.3 fps)...
Note that I want to be able the change the screen's size, hence, the pixels size...
Thanks for the help :)
 

zenogais

New member
You draw during VBlank interrupt so that your emulator doesn't run so slow, and until the VBlank interrupt you merely draw the scanlines out to video memory allocated by your emulator. When the VBlank interrupt occurs you loop through that buffer and draw all of the data in it.
 
Last edited:

LinkOfTime

New member
Well, that's more or less what I have been doing... I made it draw the screens every 70244 (more or less, don't remember the exact number) clock cycles... Meaning, every VBlank interrupt...
 

bcrew1375

New member
LinkOfTime said:
Well, that's more or less what I have been doing... I made it draw the screens every 70244 (more or less, don't remember the exact number) clock cycles... Meaning, every VBlank interrupt...

What kind of computer do you have? CPU Speed, RAM, etc...
 

LinkOfTime

New member
Well, I don't think the speed of the computer has much to do with the speed of the emulator because today's computers should be fast enough to run those the old Gameboy's emulators, but anyway... My computer is a Pentium 3 - 1000 MHz, 256 MB of ram, 64 MB of video ram... Well, hope I wrote everything important :)
 

zenogais

New member
I would say find a different method than DrawBox as thats probably a very slow method for drawing rectangles.
 

bcrew1375

New member
I apparently just "fixed" a big bug. However, it seems to contradict what I have read on the system. When the LY register passes 153, I was resetting it to 0. Just for the heck of it, I decided to remove the part that resets it to 0. For some reason that fixed the instant dying bug in Earthworm Jim, and made Pokemon Gold and Silver (partially) playable. So, my question is, do you guys reset the LY register yourself when it passes 153, or is the game supposed to do it?

BTW, aprentice, this still hasn't fixed Mario Land 2 for me :p. However, it did change the errors that are occuring, and it doesn't freeze my emulator now.
 
Last edited:

zenogais

New member
Well, the curent timer implementation I've written does reset it to zero after it reaches 153, but I may just try removing that or making it a compiler option. Thanks for the heads up bcrew. :)

I also have a question I was just pondering. Right now I am thinking of writing the video system so that each pixel written to my screenBuffer takes up two bits which denote its color. Then as I draw the data onto the screen during VBlank I read through each byte from the screenBuffer and draw 4 pixels from that, each of the specified color. Is this how you guys are doing it, and would this even work?
 
Last edited:

bcrew1375

New member
You're welcome :p. I'd really like to know how Dark Stalker and aprentice are handling the LY register. About the drawing, I've just been using the numbers 0-3. I look at the two bits, get the palette index, and store the number in the palette in my screenbuffer. So, 0, 1, 2, and 3 are the colors white, light grey, dark grey, and black, respectively.

Hmm, this is weird. An extract from my log of Mario Land 2:

Code:
PC = 350 SP = a8fb AF = 3370 BC = 0 DE = 2be5 HL = 2be5 Interrupts = 1 FF80 = 0 
PC = 352 SP = a8fb AF = 3370 BC = 0 DE = 2be5 HL = 2be5 Interrupts = 1 FF80 = 0 
PC = 354 SP 8HL = a8fd Interrupts = 1 FF80 = 0 
PC = 54dc SP = a8fd AF = 20 BC = c4f9 DE = 9a08 HL = a8fd Interrupts = 1 FF80 = 0 
PC = 54dd SP = a8fd AF = c400 BC = c4f9 DE = 9a08 HL = a8fd Interrupts = 1 FF80 = 0

Notice the "hiccup"? I call a function to write to the log that is just a bunch of "fprintf"'s. Why would it suddenly cut that section? Nothing else is called. Would this be a Windows problem?
 
Last edited:

zenogais

New member
It can sometimes happen if you print some weird non-character value such as delete or backspace. All depends on how you're fprintf'ing though. Definately unusual. As for the drawing I thinking your system would make it easier to do both GameBoy and ColorGameboy drawing, so I think I'll use that :) And for anyone who cares, a NeoGameBoy status update - I'm currently rewriting major chunks, and am almost done. The rewriting was a necessity in order to integrate NeoGameBoy with Neologism (An API for simplifying emulator creation) and because timing/interrupts weren't implemented properly and would have required major rewrites anyway. Hopefully we can join you guys who have graphics working soon :icecream:
 
Last edited:

Dark Stalker

New member
bcrew1375 said:
So, my question is, do you guys reset the LY register yourself when it passes 153, or is the game supposed to do it?
I think you can be pretty certain that the hardware wraps LY around after 153.

Update on progress:
I haven't had as much time lately, but I've been fixing minor bugs when I've had the time. Most games seem to work flawlessly, with som very rare exceptions. At least one game known only to run on kigb runs on my emu :p. I've still got some open questions wrt timing, as some things are imprecisely documented. I could get just about every game running perceivingly perfectly with a few game-specific hacks, but I really want to do things right. Namely the game Altered Space is a very weird one, I can easily get it to run correctly with a few changes, but that's at the expense of other games (EDIT: I think I just solved it :p ).
You're definitly up for a few surprises if you go for the obvious solutions according to doc. I don't think I'll be looking at sound until I've investigated this a bit further.

zeldaooa1.png
mmx_1.png

dkc_1.png
warioland2_2.png
 
Last edited:

ShizZy

Emulator Developer
Very nice shots.

I've done some more research, and finished up my chip8 emulator... I'm going take a second stab at the GB project. My old source code is very messy, so I've decided to redo most of it. So far I have a much cleaner frame up, the api initialized, the rom loader, a nice debugger, and most of the needed memory and registers declared. A lot of fluff, but a good start to begin actually implementing the emulation and testing it. Hopefully it'll go well...

Question.. or curiousity rather: Does anyone have sound emulated? It's the only thing that I really don't have much of an idea of where to begin with. Any links to useful information on it?
 
Last edited:

aprentice

Moderator
bccrew: are you executing 153 before you reset it?

DarkStalker: how are you so effectively tracking the bugs, can you share a few tips with the rest of us? and what obvious solutions?
 

Top