What's new

Game Boy

ShizZy

Emulator Developer
Here's what I get. It's the exact same on Aprentice's and Darkstalker's emulators. Sagon's only has the garbage at the top, like KiGB, but no tiny blinking line (looks more like a glitch to me). The really old version of yours has no garbage. My old version didn't have the garbage, but I think that's supposed to be there. BGP is the exact same as mine. No$Gmb and VGBC both freeze, I think it has to do with checksum issues.

All and all, I don't think it's a good rom to test with, just about every emu handles it differently. Maybe it would be best to see it on the actual hardware.:p
 

bcrew1375

New member
Well, I tried Prehistorik Man on a slightly older version of my emu, and it works! Yet I get a blank screen after the first two in the latest version. -_- I think it might be because I changed the way I was handling STAT modes, or the LY register. Mortal Kombat and Wave Race seem to love conflicting. If I don't emulate the serial interrupt, Mortal Kombat freezes at "Midway presents." If I do, Wave Race makes the program crash. -_-

ShizZie, got a flash cart? :p
 
Last edited:

smcd

Active member
bcrew1375 said:
Another one that's hard is Prehistorik Man. I haven't seen an emulator aside from KiGB get that one in-game.

bgb (1.11 is the latest) has no problems that i can tell with Prehistorik Man, it goes in game and is playable.
 

bcrew1375

New member
Ah, so it can :). You know, since part of KiGB's goal is to make Gameboy emulators perfect, they should release some documentation. There's obviously some things that aren't mentioned in the documents I have.
 

Dark Stalker

New member
Preshistoric Man works in-game on lameboy since before the first test release I made. Interrupts Demo looks the same as on vba on recent builds. The last release didn't include the fixes I made to window drawing, which is why it has garbage on the bottom too. KiGB and BGB seem to be the best emus compatibility-wise, the rest seem to do about the same as lameboy or worse from the games I've tested. I'm up to my neck in exams, so I haven't been able to do anything for lameboy lately, but I do have some plans for things that may improve accuracy further.
 

ShizZy

Emulator Developer
Preshistoric Man goes in game here and is perfectly playable, but there's some slight glitching in the transition from the titlescreen to the actual game.
 

ShizZy

Emulator Developer
@bcrew... no flash cart, unfortunetly :( Almost bought one a while back too. As for the whole serial interrupt thing, my emu elso freezes at the Midway Presents screen in MK, even with serial emulated. (And Waverace is still fine) I guess one of us is doing something wrong, it's probably me.
 

bcrew1375

New member
I forgot to mention I solved the serial thing a while back. Try requesting a serial interrupt if bit 0 and bit 7 of 0xFF02 are on, if bit 0 is not on, don't request one. This seems to keep Alleyway, Mortal Kombat, and Wave Race happy.
 

ShizZy

Emulator Developer
Nice catch bcrew. All 3 run perfectly here. Now the only game that doesn't work fully of my whole GB rom folder is SML2. Still crashes at the titlescreen :p

Edit: I noticed in your old old build of your emulator that you released a while back you have the same problem bcrew. You remember how you fixed it?

Also Edit, got Orcale Games working. Goes in game, but I have some nasty issues with vram bank switching. My GBC compat isn't half bad considering the little time I put into it though as I'm just finding out, but it's kind of buggy.

29941-game-boy-zeldaoracleshot.jpg
 

Atomizer

New member
Wow, ive finally reached the end! :)

Been reading this thread over the past few days, and have started on my own GB emulator, and this thread had kept me inspired, and has also helped me out quite a bit.
This is the first time ive worked on an emulator, and although I almost decided to switch to a chip-8 emulator, I stuck with GB and I now have some cpu instructions working, I know it probably doesnt sound like much, but I started with window and OpenGL drawing code, got a logger, memory manager and timer.

Anyway, I should get alot of the cpu instructions done today, if not all of them, and mainly just wanted to thank everyone who has been a part of this thread, and for those still around, keep at it! :)


I would like to ask a question though, unfortunatly not GB related, with my emulator, yesterday I decided I needed a second window to display debug info, however, it seems that when my second window turns up, I am unable to move it, theres no text in its title bar, and no other input seems to work on it, yet after trying to move the second window, if I click on the title bar of the first window it jumps to about where I tried to move the second window to.
Now im using standard win32 code to create my windows, and I have 2 seperate WndProc functions to handle messages, and ive logged the window handles and such on each message and the second window seems to be getting its messages properly, ive tried playing around with various window styles, including a child window(which just made the window appear inside the first one, rather then external), and im stumped.
Im sorry for asking this here since I know this should be about GB emulation, but im completely stumped, and msdn and google dont seem to help, if someone here can help, then ill accept any help I can get, but if not, you can just ignore this part :)

Cheers
 

bcrew1375

New member
Welcome to the group :p. I assume this is your first emulator? If so, it's probably not going to be easy. I had trouble understanding the IO registers when I started :D. I stopped and wrote a Chip 8 emulator, and I managed to understand it when I came back. Sorry, I'm not too experienced with Windows programming, so I can't help with your problem. I'll be happy to help with any GB questions if I can.
 

ShizZy

Emulator Developer
I stopped and wrote a Chip 8 emulator, and I managed to understand it when I came back.
Unfortunetly, is chip8 isn't a "real" system, and thus it doesn't have io ports, interrupts, or timings. So you can only learn so much from the project. I think it's been pretty much the same for all of us, things just click once you've had enough experience with the emulation - and suddenly it all makes sense.

As for your win32 code, gonna need to see your source.
 

Atomizer

New member
Yep this is my first attempt, and yeah, while reading this thread, and I was having trouble understanding quite alot of stuff, and some people had mentioned trying chip8 first, so I actually started reading the chip8 thread(man these forums are a good resource :) ), but I was kind of starting to understand what I was reading about the GB, so I decided to stick it through, and im making decent progress now, so im glad I decided to stick with it.

At the moment I seem to be doing fine on the emulation side of things, anything I needed to understand previously I have mostly figured out, so things seem to be going ok, apart from the debug window, but ive decided to ignore that for now and just focus on doing the opcodes :)


EDIT: Adding my source, im still in the process of doing the CPU, and the rom location is currently hardcoded, im likely going to rearrange the memory variable locations though, since they need to be seperate, the registers too.

Oh right, almost forgot, the debug menu item is grayed, just remove the MF_GRAYED part from the following line(in gabe_main.cpp, line 231):
AppendMenu(g_hMainMenu, MF_STRING | MF_GRAYED, ID_DEBUG, "&Debug" );
 
Last edited:

bcrew1375

New member
Wow, looks like a nice start. Now, I don't want to seem big-headed, but it seems from the way some of your code looks, you may be getting ideas from the source I posted a while back. If so, it is horribly outdated, and I wouldn't rely on it too much. It is infested with bugs.
 
Last edited:

Atomizer

New member
Yeah I did borrow some, mainly just the defines and some register stuff, though I can see some of it is wrong and/or im not making much sense of it, but I am going through each instruction(from GMB%2D~1.TXT) and doing them myself, and using http://www.work.de/nocash/pandocs.htm#cpuinstructionset for flag/cycle info.
I am a little confused about the RLCA instruction though, in terms of the carry flag, but ive never come across rotation in variables before so im not sure what it should be doing.(I think it was answered in this thread, so ill be going back and going through it later)
 
Last edited:

HyperHacker

Raving Lunatic
I haven't worked on mine in quite a while, but it's not cancelled, I just haven't got around to it. :p

Anyway, someone mentioned a bug where their scores were displayed in hex... this means your DAA opcode isn't working. It's a tricky bastard, I had a lot of problems with it as well (my score kept jumping to 999999 in Tetris :D). I still don't think it works right. Mainly I think I just have flag bugs and some timing problems though.

Can anyone provide info on MBC7? And there must be an MBC6 as well, info on that is also welcome. I've never heard of either.
 

LotsArs

New member
Hi there,

Could anyone explain me the GBx rendering scheme (in terms of LCDC modes/stats/cycles)? I mean, how many cycles are executed while rendering a scanline, how many are spent on the HBlank, and how many on the VBlank. How are your emulator schemes handling this?

Thanks.
 

synch

New member
Let's see, this is how it's handled in my emulator, but I don't think it's 100% correct (as of today, it runs only a few games).

A whole screen redraw lasts 17556 cycles, that are divided in:

One scanline lasts 110 cycles. The 20 first cycles are OAM Search (mode 10), from 20 to 70 are Data Transfer (mode 11), if cycles greater than that (70 to 110), then HBLANK is enabled, and I increment the LY (0xFF44) register.

Then, when cycles are greater than 16416, I enable the VBLANK (mode 00).

I should repeat, that it's probably very wrong, but it works for me as of today, enabling some games to work, but I guess someone will correct me, or give some proper numbers.
 

ShizZy

Emulator Developer
One scanline lasts 110 cycles.
That's wrong, it should be 114 machine cycles (456clcks/4) - the same period as a full vblank. Otherwise what synch said looks correct enough to get you started, and things working. Can't remember the exact details off the top of my head, but it's described in detail in the pan docs.

If I can remember, basically each scanline is as I said 114 cycles, in the order OAM, Transfer, HBlank. (all three periods occur each scanline) At the end of the scanline (HBlank) you draw that line and increment LY. When LY reaches 143 (end of the screen) you continue for 10 more lines (114cycles*10) in vblank period, without actually drawing anything. LY is still incremented, and remember to request a VBlank interrupt.
 

LotsArs

New member
Thanks both, that clears it up.

Well, almost. What is the exact cycle count for each mode (0, 2, 3)? PAN docs just say "it lasts between m and n cycles". By taking the highest values, we have 207, 83, 175 (respectively), so we get 465 cycles per scanline, while it should be 456.
 

Top