What's new

Game Boy

HyperHacker

Raving Lunatic
Damn this lag... *deletes 5 duplicate posts from last time*

Anyway I tried using <= in place of == when setting the H flag during subtraction... just broke things. The line count in Mode B in Tetris jumps from 25 to 2A when clearing a line. o_O Course there seems to be a lot of bugs in my DAA handling code (actually just Aprentice's he posted a while back) and/or flags (my score jumps to 999999 when I clear a line) so who knows...
 

HyperHacker

Raving Lunatic
Odd results with DAA

I'm getting really weird results with the DAA instruction. I've hacked up a quick test ROM (not done yet, still some things to add) which can test it, among other things. (Go to TEST DAA OPCODE to start the test; feel free to test other things with it too.)

What I'm noticing here is that if I do this:
Code:
ld a,b
and a
call printhex
[...]
ld a,b
and a
daa
call printhex
I get weird results; 0 comes out as 6 and so on. If I omit the 2 "and a" instructions (as ld a,b doesn't set the flags), then it seems to function mostly normally. The results are the same on both No$GMB and bgb; I don't have any way to test it on a real GB at the moment. Can anyone explain this?

(BTW, if you want to assemble that big mess of code, use tniASM; a simple batch file is included, but it probably won't be of much use to you. :p tniASM is simple enough to use, though. Or just run the test.gb included.)
 

wrayal

New member
Just out of interest, I am actually working on an emu - I've got every opcode except DAA emulated (I'm determined to write that for myself in spite of it being posted copy-and-paste-ready earlier in this thread ;) ). I'm fiddling with Memory and timings at the moment, but all my opcodes seem to work perfectly once I stopped being an idiot and wondering why the LY reg compare kepy failing for me sending me into an infinite loop (I didn't have it being incremented since I hadn't implemented timings).

Thanks for all the interesting chat on this thread guys - it's brilliant stuff to read.

Two questions though - which ver of the pandocs should I use? I've been using ver 1.01, but it seems to disagree on some flag settings when I trace through in both bgb and executa boy?

The other thing is, Shizzy, aprentice, I take it you are the two I've heard mentioned as working on a quickly progressing GC emu? If so, congrats!!

Wrayal
 

bcrew1375

New member
wrayal said:
I'm fiddling with Memory and timings at the moment, but all my opcodes seem to work perfectly once I stopped being an idiot and wondering why the LY reg compare kepy failing for me sending me into an infinite loop (I didn't have it being incremented since I hadn't implemented timings).

I had that exact same problem when I was started. It just sort of came to me as I got more experience :p.

wrayal said:
Two questions though - which ver of the pandocs should I use? I've been using ver 1.01, but it seems to disagree on some flag settings when I trace through in both bgb and executa boy?

To my knowledge, this is the latest version http://www.work.de/nocash/pandocs.htm None of the docs seem to fully agree, but that one is the most reliable. All of them seem to have incorrect information, so you will probably have to collect what is right from different docs. Such as the halt bug. Some docs say it skips the next instruction, some say it repeats the next instruction. Unfortunately, many games require these bugs to operate correctly.
 

refraction

PCSX2 Coder
bcrew1375 said:
To my knowledge, this is the latest version http://www.work.de/nocash/pandocs.htm None of the docs seem to fully agree, but that one is the most reliable. All of them seem to have incorrect information, so you will probably have to collect what is right from different docs. Such as the halt bug. Some docs say it skips the next instruction, some say it repeats the next instruction. Unfortunately, many games require these bugs to operate correctly.


That sounds to me like an original limitation of the hardware rather than a miss informed document. The docs probably describe how it is suppose to work, but neglects the fact that this might have bugs in the original hardware.
 

HyperHacker

Raving Lunatic
Well the behaviour the docs describe is a bug. :p Supposedly, the instruction after a halt is either skipped or repeated if interrupts are disabled.

What I most often hear is the first byte is repeated. That is, 12 34 56 is executed as 12 12 34 56. Again, no way to test on a real GB to find out. :(
 

bcrew1375

New member
HyperHacker said:
What I most often hear is the first byte is repeated. That is, 12 34 56 is executed as 12 12 34 56. Again, no way to test on a real GB to find out. :(

That's what I meant to say, It's the byte, not the instruction.
 

Falcon4ever

Plugin coder / Betatester
Finally after being punched by Shizzy a few times ;P
I decided to continue my Gameboy emu.

Currently I have quite some z80 opcodes implented. Altough I'm now struggling with the interrupts and IME.

This IME thing, do I need to create a BOOL for it? or is it a place in the memory. Because by looking at the docs i see 0xFFFF represents the Interrupt Enable Register. Not sure if this is the same.

hopefully one of you guys can help me out :)


attached a layout of the emu :p no gfx was implented yet so :p it's all black =]
 
Last edited:

ShizZy

Emulator Developer
Looks good. Yeah, just create a bool, set it in EI, and clear it in DI. Then check that bool when going to execute requested interrupts.
 

bcrew1375

New member
IME is Interrupt Master Enable, it's like a register. It's basically a universal interrupt on-off switch. It's turned on by EI or RETI, it's turned off by DI or when an interrupt is executed. The IF register is the interrupt request register. The IE register determines which interrupts are enabled. So, even if an interrupt is requested in IF, that doesn't mean it will be executed. An interrupt will only be executed if the IME is on, it is requested in the IF register, and it is enabled in the IE register. If IME is not on, then no interrupts are executed, even if enabled. You have to turn on the IF flags yourself when an interrupt situation occurs and clear them when the interrupt is executed. The IME and IE flags should be handled by the program for the most part. Sometimes the program will turn on the IF flags itself, usually to get some kind of special effect.
 
Last edited:

yosh64

New member
hey

Well I just came across both Otaku No Zoku's GB Crib Sheet at http://www.otakunozoku.com, AND Adrian Brown's HTML version of it at http://www.enliten.force9.co.uk, and thought people here might find it handy.

Anyhows that's all... will have to complete my own Gameboy emulator oneday soon also. :)

Ohh yea, almost forgot to mention... I also found http://www.rawer.de/marc/Gameboy/Docs/GBCPU_Instr.html AND http://www.rawer.de/marc/Gameboy/Docs/Opcodes.htm FROM "B.2 Useful documents" section of http://www.rawer.de/marc/Gameboy/. =]

ALSO, http://www.z80.info maybe handy too... :plain:

cyas
 
Last edited:

Opfer

New member
Alright, my gameboy emulator finally reached a state where I thought I could release it as version 1.0.

It's a gameboy emulator written in Visual C++, using unmanaged (native) code to do the emulation core and managed .NET and managed DirectX to do the GUI, graphics, sound and input.

I'm planning to release the unmanaged core as a dll so that other people can program some sort of client for the emulator.

I get about 10% processor load on my P4 3GHz, but if any of you have a rather old PC around, I'd be very glad if you could try to run it on that one and post how/if it works in the "Feedback" board on my site.

And since this is version 1.0 and I plan do release improved versions, I'd be really glad if you could give detailed feedback (in the "Feedback" board on my site) on how you like it, what you think I should add to it, and what you think I should improve or leave out, since I don't have an idea what features would actually be used by the common user, and I don't want to flood it with features that nobody actually uses. So feedback is greatly appreciated.

Oh and: Please report any bugs using the forum.

And finally, here's the link: http://multiserver.ath.cx/PowerCoding/

If you have any questions, feel free to ask.
 

synch

New member
Probably my fault, but crashes when opening a rom. I can be more precise tomorrow, when I will have rested a bit. And why requiring the .net framework? My emulator uses winforms and .net, without requiring it, but probably due to using vc2003. (Didn't even care to check which version 2005 uses).

Seems that more or less, we have the "same" structure for the emulator: Managed (winforms rules!) for the gui, unmanaged for core. I'll try to compare speed when I'm able to run it to give some proper feedback :)
 

Opfer

New member
Well, I don't know about older versions (like 2003), but in the .NET Framework 2.0, which is the only one you can use with VC++ 2005, Windows Forms and the .NET Framework is basically one package.

If it crashes when opening the rom, make sure you've got the most recent version of the .NET Framework (v2.0) and DirectX (April 2006 release). Also, while the emulation core seems to be pretty much bugless now, the GUI still does some random crashes that I haven't been able to track down yet (because they are random and therefore not reproducable). This includes some crash on startup, when it fails to initialize the managed JIT Debugger. So make sure you try it more than once. If it still crashes, I'd be happy if you could either email me the error report or post it on the forum.
 

ShizZy

Emulator Developer
Crashes for me right when I try and open it (the program itself). Why not just use a win32 gui? Emulators don't require extensive gui's, and win32 is much more compatable :)
 

Opfer

New member
Well, after you made sure that you've got both the .NET Framework 2.0 and the DirectX Runtime (April 2006) installed (in the right order), and you still get the crashes, you could copy and paste the error report, which you get. (along with the module information on the second dialog window of the error report) and post it somewhere so that I can have a look at it.

I'm using the .NET Framework because it's far easier to use than native Win32 (especially since I don't have a forms designer for Win32). Also, the DirectX functions are accessible in a more comfortable way when using .NET.

And for the compatibility, in Windows Vista, .NET will be the language of choice when developing applications. Right now, there is a runtime that wraps the managed code into Win32 code, but on Vista, the managed code will be executed directly, and the native Win32 programming will be declared as deprecated and will sooner or later not be supported anymore.

Also, portability to other systems is easier, there is even a way to easily port .NET applications to Linux, since it doesn't depend on the OS's functions anymore.

And since the emulation core is completely independent from the gui, I don't have any speed problems, too, because the core is programmed using unmanaged code (unmanaged isn't a synonym for native Win32, I don't use a single windows library in that core code, it just means that I don't use .NET).

So .NET is the language of choice for me.
 

Top