Game Boy

[aprentice]

I get that same exact image in wave race if i disable the LCDC interrupts, otherwise its just a white screen. If you figure out what causes this, feel free to share as I'll do the same.

Your controller issue has to do with a bug in the cpu core, I've had the same problem until i fixed this "magical" bug

Also, some games didnt show sprites in my emu either, so i just temporarily disabled the sprite enable check

 

[bcrew1375]

Would you mind telling me this 'magical bug', oh Wise One ? I'm really at a loss as to what it could be :/. Hmm, I'll try messing around with the interrupts and see if I can get something else out of Wave Race.

 

[aprentice]

Would you mind telling me this 'magical bug', oh Wise One ? I'm really at a loss as to what it could be :/. Hmm, I'll try messing around with the interrupts and see if I can get something else out of Wave Race.

I don't recall what the bug was, I've rewritten my cpu core 3 times, everytime i get frustrated i scrap code and redo it, in hopes of not making the same mistake again

I would make sure your ADC, SBC, and rotate opcodes are setting flags right, these are common opcodes for mistakes

 

[bcrew1375]

Yes, I would suspect the same ones. the ADC instuctions were messing up alot of games simply because of a tiny problem with the carry flag. Unfortunately, I've already fixed that a while ago, and games still don't work. Eh, maybe I'll re-write like you did.

 

[zenogais]

Well, seeing as how this thread has kind of died, I figured I'd respur it with news about my emulation framework. I don't really think its worth starting a new thread for...yet Anyway, I've consolidated all the individual frameworks into a single framework which spits out "EFramework.dll". Right now I've finished creating facilities for the following:

• Generic exception for error handling (Check Here For More Information)
• Generic logging framework which allows for the creation and management of multiple log files.
• System versioning class which allows for management and comparison of versions as well as a few other things.
• Class which allows one to trace the execution of a program.
• Generic save states class and two derived class, one which allows for basic binary file output, and a second which uses zlib to produce a compressed save state file. Basically allows the programmer to decide how their program saves states, without the need to modify more than a few lines of code.
• A class for loading, managing, and retrieving of methods from plugin DLLs. It is also almost completely cross-platform.

Thats about it for now, while I haven't released any source code or anything yet, I am hoping to make a release in the future once I have the system for creating and managing emulator components laid out and completely implemented.

 

[Doomulation]

That's cool.
Say, if it gets finished, I could test this for the chip8 emulator I did. How's the work going, then? Any idea on what's left and when it "might" be finished?

 

[zenogais]

No estimates yet, I'm currently retooling the GUI framework to work the the Windows Template Library (WTL) instead of MFC. Basically this would be come the new version of WinMain using the framework:

int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
					 LPSTR lpCmdLine, int nCmdShow)
{
	
	// Create our WTL class management instance.
	EFWindowApplication< MainWindow > WTLStuff;

	// Display our window and process message until closing.
	return WTLStuff.Run();
}

 

[Doomulation]

Err, just if you do that, you can't use MFC? Baaaad.
I was going to try this though, by rewriting the chip8 emulator a little with it.
Hmm well, I'll wait until you give word that some intresting is about to happen :evil:

 

[zenogais]

Err, just if you do that, you can't use MFC? Baaaad.
I was going to try this though, by rewriting the chip8 emulator a little with it.
Hmm well, I'll wait until you give word that some intresting is about to happen :evil:

Not really, I've had too many headaches trying to distribute plugins that used MFC, the Windows Template Library in addition to having a smaller footprint than MFC and less dependencies (the dependencies were the cause of the problems btw), just seems to be the right balance between pure, ugly Win32 and the bloated MFC, also it has a few nice features built-in that MFC and Win32 certainly don't have.

 

[Doomulation]

Still, everything - all the classes that MFC provides that makes programming easier, what about these? But I'll take your word for it. If it's easy to use then it'll certainly be good. I'd like to test this framework sometime, too.

 

[zenogais]

Still, everything - all the classes that MFC provides that makes programming easier, what about these? But I'll take your word for it. If it's easy to use then it'll certainly be good. I'd like to test this framework sometime, too.

Well...have you looked at the windows template library? From using it I can tell you that it has all of the things I used to incorporate into my windowing classes, including tooltips and all the predefined helper classes. Often times it also makes the components a bit easier to use. Anyway thanks for taking my word on it and, if you'd like to test it if you can just drop me an email I can send you a copy of the latest framework, plus the sources so you can get an idea and possibly start working with it and telling me if it simplifies creating an emulator or improving a prebuilt one, anyway I suppose I should get back to working on it

UPDATE:

Here is the basic list of the Emulation Framework I have so far:

• Plugin Management
• Save State Support For Both Binary Files and ZIP Files
• Cross-Platform Size-Guaranteed Types (uint8_t will always be 8-bits)
• Support For Simple Singleton Creation
• Simple Classes For Versioning Of The Framework And Your Emulator
• WTL Application Module Wrapper
• Windows Register I/O Wrapper
• Dynamic Logging With Support For Creation And Management Of Multiple Log Files
• Special Exception Class
• Program Execution Tracing Class

That's about it for now.

 

[aprentice]

anyone from this thread still working on a gameboy emu, or have you all moved onto gamecube emulation?


(ps: just kidding about the gamecube emulation).

 

[bcrew1375]

Still working on it, just not often. I'm still bug hunting though :/.

 

[aprentice]

Still working on it, just not often. I'm still bug hunting though :/.

Same here, i work on it at least once a week, bug hunting as well, with no luck might i add. I've also started a nes emu, its up to the stage where it should show gfx but i didnt fully implement interrupts, so nothing shows right now. Theres only about 4 days of work i put into the nes project since i've been working on it sunday nights only.

 

[Doomulation]

Still no word from my co-programmers. Too lazy to work on it, been doing other stuff.

 

[bcrew1375]

Same here, i work on it at least once a week, bug hunting as well, with no luck might i add. I've also started a nes emu, its up to the stage where it should show gfx but i didnt fully implement interrupts, so nothing shows right now. Theres only about 4 days of work i put into the nes project since i've been working on it sunday nights only.

Oh, NES? Got any good information on it? Everything I found was junk. :/

 

[aprentice]

Oh, NES? Got any good information on it? Everything I found was junk. :/

Good info is hard to find for the nes, too much old stuff and junk in between the docs unlike the gameboy. I have a collection of docs with data scattered between that I've been collecting since 2001. You might need to stare at the docs a bit to get use to em first

 

[bcrew1375]

Thanks. That's better info than I've been able to find. Those mappers look kind of intimidating though.

Edit: Oh, made these stickies, huh? Sweet. :bouncy:

 

[aprentice]

Has anyone reached up to emulating tile/sprite priorities?

"Bit 7 BG-to-OAM Priority (0=Use OAM priority bit, 1=BG Priority)

When Bit 7 is set, the corresponding BG tile will have priority above all OBJs (regardless of the priority bits in OAM memory). There's also an Master Priority flag in LCDC register Bit 0 which overrides all other priority bits when cleared."

I can't really figure out how to implement this efficiently, considering my gfx routine is split into 3 functions, Background display, window display, and sprite display.

I could read the oam memory every tile and compare priorities, but this doesnt sound that efficient does it? Any advice?

edit: oh btw, hows your emu going bccrew?

edit2: Thanks for all the replies (just kidding), figured it out on my own, i set up a pointer that pointed directly to the video memory buffer for that pixel and it works out perfectly. This pretty much puts my gb/gbc gfx emulation at 100% complete, leaves more time now to focus on the hardware aspect

 

[bcrew1375]

I haven't even concerned myself with the priorities yet. I'm still trying to crack out bugs -_-. Ive tried tracing several games. Everytime I get close to pinpointing a problem, it seems to split off into hundreds of other problems. I've fixed a few bugs, my emulator is now slightly more compatible. Anyway, I haven't given up. If I can't get a gameboy emulator more compatible than this, I'll never make it with other emulators .