Game Boy

[-//zAe\\-]

Hello!
I have wrote my chip8 emulator already. Now i want to upgrade to a Game Boy emu.
Where should i start from? What docs should i read? What should i know before start coding?
Help me, please! :)

[sammyboy]

http://www.goldroad.co.uk/archive1.html it had some usefull information on hoe he programmed the gb emulator... there may be some docs on there (you could always email the developer and ask for his docs) but it is quite a useful site.
Could you execute your emu and put a link here please.

[-//zAe\\-]

Thaks! Other Links? :)

[SculleatR]

I hope this helps. :)
It says "GameBoy CPU Manual" but IIRC it has info on other parts aswell.

Good luck with ya emu. :)

[-//zAe\\-]

Thanks! Really Thanks SculleatR!
Other :) ??

[SculleatR]

hmm I guess that one should have everything you need, but anywayz. :)
I am not sure but maybe Zophar'z stuff can help you,
http://www.zophar.net/tech/gb.html or you might look at zophar.net/tech
if you are interested in other older systems.

Have fun! :)

[-//zAe\\-]

hmm I guess that one should have everything you need, but anywayz. :)
I am not sure but maybe Zophar'z stuff can help you,
http://www.zophar.net/tech/gb.html or you might look at zophar.net/tech
if you are interested in other older systems.

Have fun! :)
Well.. i already have this one :) .
But THANKS anyway!

[-//zAe\\-]

Mybe it is a stupid question. but anyway:
Can someone write here a smaaaaaal "how to" with a few basic steps, like this:
"To code your Game Boy Emulator, you will need to Load the rom into the memory, create a stack pionter, a program counter, a screen array..." Yes, something like that.
Please! Your help is greatly needed! :)

[Teamz]

I got an emulation thesis if you're interested

[aprentice]

I don't think you need anything other than that manual skulleatr posted, I had a look at it, looks very nice.

You could also download a cart header doc and a memory map doc and you should be set to go.

Btw skulleatr, where'd you get this doc from?

[-//zAe\\-]

Well, if you say so Aprentice, i will try to code my emu all by myself! :)
At least i can try...
But anyway, thanks a lot guys! I will try to do my best! :)

[SculleatR]

Ap, I got it off google, I used that doc end of 2002 i think too when
i was doing some GB stuff, so I refound it easily.

[refraction]

i dunno if its any help but ive got 4 documents in this zip on the concepts of emulation, i mean with consoles its pretty much the same thing, the tech docs for the gameboy on zophar should tell you the parts you need then the opcodes will tell the pc what to do with the data as it comes in.

How To's General Emulation (http://djxander.artists.mpfspromotions.com/emulationhowto.zip)

[-//zAe\\-]

Thanks! I think i have all i need to code my Emu ! :)
Thanks A LOT!

[Doomulation]

Gambaru yo! :D
(Good luck)

[-//zAe\\-]

Gambaru yo! :D
(Good luck)
Arigato :)
(Thanks)

[Stezo2k]

i dunno if its any help but ive got 4 documents in this zip on the concepts of emulation, i mean with consoles its pretty much the same thing, the tech docs for the gameboy on zophar should tell you the parts you need then the opcodes will tell the pc what to do with the data as it comes in.

How To's General Emulation (http://djxander.artists.mpfspromotions.com/emulationhowto.zip)

wow mate, nice to see you here alex :)

this guy knows his stuff, his chip8 emulator was well mint

good luck with your other projects mate

[refraction]

wow mate, nice to see you here alex :)

this guy knows his stuff, his chip8 emulator was well mint

good luck with your other projects mate

nice to see you too man :)

haha ive not finished it yet! its in the process of being converted to windows, and is being designed with a custom Graphics Engine created by Zenogais (Creator of NeoPSX and dev for ps2sp sound plugin) but ive not touched it for a while, hoping to release it to the public once its done :)

i know its nowt special but its got full chip8 and schip8 support, sound still to come (but shouldnt be hard) and gonna reprogram a couple of bits so it doesnt eat your cpu.

[Doomulation]

nice to see you too man :)

haha ive not finished it yet! its in the process of being converted to windows, and is being designed with a custom Graphics Engine created by Zenogais (Creator of NeoPSX and dev for ps2sp sound plugin) but ive not touched it for a while, hoping to release it to the public once its done :)

i know its nowt special but its got full chip8 and schip8 support, sound still to come (but shouldnt be hard) and gonna reprogram a couple of bits so it doesnt eat your cpu.
Wow, now that's something I'd like to have the source for! :D
:ninja: :ninja: :ninja:

[refraction]

Wow, now that's something I'd like to have the source for! :D
:ninja: :ninja: :ninja:


well we MAY make it open source when we release it, but we will have to wait n see ;)

Must give him most of the props tho, he started me off with a template, then i sorted out the bugs in the op codes and wrote most of the ones that hadnt been done and altered a few things to draw the sprites, including buffer flipping :)

[Stezo2k]

nice to see you too man :)

haha ive not finished it yet! its in the process of being converted to windows, and is being designed with a custom Graphics Engine created by Zenogais (Creator of NeoPSX and dev for ps2sp sound plugin) but ive not touched it for a while, hoping to release it to the public once its done :)

i know its nowt special but its got full chip8 and schip8 support, sound still to come (but shouldnt be hard) and gonna reprogram a couple of bits so it doesnt eat your cpu.

sounds good mate, would like to see a few screenshots as it progesses :)

keep up the good work mate with your emu :naughty:

[refraction]

here we go, my screenshots just uploaded one to show the engine off a bit :)

plus put a couple of SChip8 games on there too.

http://djxander.artists.mpfspromotions.com/chip8/chipscreens.htm

[Stezo2k]

here we go, my screenshots just uploaded one to show the engine off a bit :)

plus put a couple of SChip8 games on there too.

http://djxander.artists.mpfspromotions.com/chip8/chipscreens.htm

looks pretty good so far mate, i like the windows interface, would like to see more pics as it progresses, the ASCII DOS graphics output make the games look even more dated lol, would like to try the windows version though. The custom graphics engine sounds well great, hope development goes well

[Doomulation]

Now now, you made the same mistake as I did when I first started with chip8 gfx. Remember to center it, or pong will look ... well, like it did on your screenshot! It looks much better centered, believe me ;)

Btw... does all these games work flawless or some typical bug?

[-//zAe\\-]

Game Boy! Remember the name of the thread? :)

[sammyboy]

Yeah how far have you got with your gameboy emulator. Or have you not started it yet. If you have, have you got anything to show for it or not.

[refraction]

Now now, you made the same mistake as I did when I first started with chip8 gfx. Remember to center it, or pong will look ... well, like it did on your screenshot! It looks much better centered, believe me ;)

Btw... does all these games work flawless or some typical bug?

its only liek that because the pc basically types the graphics out character by character, thats the only reason its off centred.

and as far as ive tested ALL games work perfectly, apart from Field on Schip8 which seems to have some problem once you get in game.

[Doomulation]

Awww shoot, you fixed lots of issues I couldn't be arsed to fix :yucky:
Btw, if you use a decent API (ie DirectDraw), you can center the gfx.
Guess I should discuss it elsewhere from now on :P

[refraction]

Awww shoot, you fixed lots of issues I couldn't be arsed to fix :yucky:
Btw, if you use a decent API (ie DirectDraw), you can center the gfx.
Guess I should discuss it elsewhere from now on :P


got an openGL engine mate, its kinda bein worked on with Zenogais, if you dont know him, hes one of the developers of the first Pcsx2 sound plugin that made sound and he is the dev behind Neo-PSX, so he knows his stuff :D

Sneeky Preview of it...

HERE! (http://djxander.artists.mpfspromotions.com/chip8/chipscreens.htm)

[-//zAe\\-]

Yeah how far have you got with your gameboy emulator. Or have you not started it yet. If you have, have you got anything to show for it or not.
Yes, along with Teamz and GbaGuy :)

[sammyboy]

Cool... would you be posting the news on this thread or the emu dev thread that teamz started up.
Edit: I have recently been setting up another emulation site, and I would post the information about the emulator there. The site domain is currently http://www.freewebs.com/siteemu. Hope you will like it, hopefully get .tk forwading domain name soon. This site ill hopefully suck seed or I will hang my head in shame :paperbag: (sorry but that is the first time I have seen this smiley and I like it).

[bcrew1375]

Hey, sorry for reviving this old thread. I heard some other people were working on GB emus, and wanted to see how far they've gotten. So far, I've got almost all opcodes covered, most of the I/O registers taken care of, the V-Blank and Timer interrupts handled, and drawing of the background. There's obviously some things I still need to sort out. I've either gotten a blank screen or distorted graphics. Not a single game has run as expected yet :/. Oh well, maybe soon, I hope. Have any of you guys gotten results yet?

[sammyboy]

could you show some screen shots, what language is it programmed in and how long have you been working on it.

[refraction]

could you show some screen shots, what language is it programmed in and how long have you been working on it.


what about your emulator? how far have you got? youve been working on it about 3-4 months now, you must have something..

[bcrew1375]

Here's some shots. The first is the BLEM! demo :p. The other two are from Big Scrolling Demo. BTW, these are showing the full 256x256 VRAM.

[refraction]

Here's some shots. The first is the BLEM! demo :p. The other two are from Big Scrolling Demo. BTW, these are showing the full 256x256 VRAM.


PSX emu for GB hahah love it :P

lookin good there tho mate!

[GbaGuy]

The GB emulator being worked on by TeamZ, zAe, Doom, and myself is at a similar
place in development. http://sourceforge.net/projects/clonegb

What ROM is that 3rd shot?

I tried implementing the V-Blank interrupt, but it doesn't seem to work (or atleast, it
doesn't seem to change compatibility *at all* which would lend itself to the not working conclusion...)

I'd like to see screenshots of the Space demo (aka Grey moving globe..) and the
commercial game Solar Striker (if you have it, that is. That was the first cart I ever
bought for gb, 7 bucks many years ago at Funcoland.), could you? thanks.

It would seem that the exuberance isn't insubstantial yet...

[bcrew1375]

Sorry, I've been at work all day, and haven't had a chance to reply. Anyway, the third screenshot is from the Big Scroller Demo. I haven't gotten any results from either of those ROMs yet. I had a look at your guys' code. This may be a stupid question, but are you generating the interrupts? You seem to be pretty far, maybe farther than me, but it doesn't seem like you're generating any of them. Anyway, you'll need cycle counters(Or, at least that's what I used). You could have a counter for the LY register. Once so many cycles have passed you increment the LY register, when it's between 143(The lowest line on the screen) and 153, you generate a V-Blank interrupt(Just after it passes 143. After it passes 153, you turn off the V-Blank flag and reset LY to 0). I believe the cycles between each line is close to 114 in machine cycles. That's clock cycles divided by 4, in case you didn't know. Let me know if that helps, or if you need more info. I'll be happy to help if I can :).

[aprentice]

Heres some screens from my gameboy emu.
First game to run was actually super mario land,
as strange as that sounds :P I couldn't get any
ingame screen shots since input is not implamented,
and i havent finished mbc1 yet, so most mbc1 games
crash :P

edit: I know the colors are off, i put any bs value as the palette for the time being :P

<post truncated>

[PsyMan]

WARNING! n00b QUESTION: aprentice, does legend of Zelda - Link's awakening work? :unsure:

[aprentice]

WARNING! n00b QUESTION: aprentice, does legend of Zelda - Link's awakening work? :unsure:

get back to me when i finish mbc1 emulation, cause it currently crashes the emu :P

[bcrew1375]

Mine now plays the intro of Link's Awakening(MBC1 is actually a cinch to implement). Unfortunately, it crashes just before the screen scrolls up to the egg. Oh, heh, I also don't quite have sprites working yet, so there's no boat, or Link, Or Marin :P. I also got the title to Metroid 2 working, and probably some others, but I have no input yet, so I can't go further :P.

Here's some screenies:

[zenogais]

So, what documents are you guys using for this. I think I'm going to start one pretty soon here, just for a fun.

[aprentice]

Mine now plays the intro of Link's Awakening(MBC1 is actually a cinch to implement). Unfortunately, it crashes just before the screen scrolls up to the egg. Oh, heh, I also don't quite have sprites working yet, so there's no boat, or Link, Or Marin :P. I also got the title to Metroid 2 working, and probably some others, but I have no input yet, so I can't go further :P.

Here's some screenies:

I dont have sprites or input either, i guess everyone considers these lower priorities :P

I couldn't find any info on the gb palette, is there any known accurate values for this, or is it kinda like a guess thing?

edit: is everyone using a public cpu core, or am I the only one crazy enough to code my own? :P

[smcd]

Coding your own is half the fun of it! (actually some of the available cores are not well documented and downright scary looking :P)

[refraction]

well im starting a GB emu as well, its like were all in a classroom together progressing at the same rate :P

if anyone could provide a GOOD document on the gameboy itd be handy.

Im puzzled tho on how these MBC1 and that works, im guessing the 32k rom games just load straight into memory, but is MBC1 and MBC2 etc direct access to the cart or what?

[aprentice]

well im starting a GB emu as well, its like were all in a classroom together progressing at the same rate :P

if anyone could provide a GOOD document on the gameboy itd be handy.

Im puzzled tho on how these MBC1 and that works, im guessing the 32k rom games just load straight into memory, but is MBC1 and MBC2 etc direct access to the cart or what?

mbc is like a memory controller, it controls which banks are "paged" or "switched" in and out since the cpu can only address a limited amount of space. The memory paged can be accessed at 4000-7FFF. I think that should clear everything up :P

[refraction]

mbc is like a memory controller, it controls which banks are "paged" or "switched" in and out since the cpu can only address a limited amount of space. The memory paged can be accessed at 4000-7FFF. I think that should clear everything up :P


so basically chunks of memory are copied from the cart into the memory between 4000-7FFF?

and how does the switching work? :P sorry to sound like an ass, but ive not actually started on the fundamentals of the emu yet, just getting the GUI sorted.

[aprentice]

so basically chunks of memory are copied from the cart into the memory between 4000-7FFF?

and how does the switching work? :P sorry to sound like an ass, but ive not actually started on the fundamentals of the emu yet, just getting the GUI sorted.

Every rompage is 0x4000 bytes, so when you load the rom you would need to settup a pointer to every page after the complete rom has been loaded into memory. You can get the rom page information from the header.

example:
mem.rompage[3]=(mem.prgrom+(3*0x4000));

this would make page 3 point to 0xC000 of the program rom in memory.

since some roms can have up to 0x7F pages, its a good idea to use a for loop.

I wouldnt worry about mbc1 right away though.

[refraction]

I wouldnt worry about mbc1 right away though.

yes but it would be nice to know how it works :P

thanks for the other info tho.

[bcrew1375]

Here's the best documents I've ever seen for the Gameboy. These should contain everything you'll need for basic emulation. As far as the MBC1, if it's on is determined by the ROM header. Basically, if the area from 0x2000 - 0x3FFF is written to, you take the value and use it to choose the ROM bank. Banks 0 and 1 both point to bank 1. So, you can just take the bank number and multiply it by 0x4000(Each bank is 16K). Take that chunk out of the ROM and put it into memory at 0x4000. Make sure you don't actually write the bank value to memory, just evaluate it. That should be all there is to it.

[refraction]

ahh right, thanks for the docs bcrew1375 :)

[bcrew1375]

No problem :bouncy:. So, do you think you understand MBC1 now?

[refraction]

No problem :bouncy:. So, do you think you understand MBC1 now?


Kinda, let me say how i think it works and you tell me if im right or wrong.

Different games are different sized, so the data is stored in blocks of data on the card (mbc1, mbc2 etc) the system only has 32k of space for the data from the rom so what it does is pages the data from the memory block into the system depending on which block it needs, then swaps it if it requires a different block of memory.

that sound right to you?

[bcrew1375]

Well, for the most part. I'm not really sure where it stores it, but what does it matter :P. Yes, it essentially swaps in the 16K block that it happens to need at the moment.

[aprentice]

Some more screens to revive the thread :P

<images removed>

to bcrew1375:

I implamented dynamic background palette and that fixed the color issues, but a couple games have inverted colors now, i was wondering how you implamented this feature?

[bcrew1375]

The palette is layed out like this:

1 AND 1 = bits 7-6
0 AND 1 = bits 5-4
1 AND 0 = bits 3-2
0 AND 0 = bits 1-0

Hopefully, that is clear :P. If not, I'll try to explain in more detail. Remember though, this is just what I'm using. No guarantees that it's correct :P.

BTW, I've managed to get a single controller button implemented, the Start button. It seems to work for the most part, but I think I'm doing something wrong still. Anyway, I can go in-game on Tetris now. Unfortunately, I don't have sprites, so I have no idea what's going on :P.

[aprentice]

The palette is layed out like this:

1 AND 1 = bits 7-6
0 AND 1 = bits 5-4
1 AND 0 = bits 3-2
0 AND 0 = bits 1-0

dude, your just spitting back at me whats in the docs,
i want to know how you implamented it. The way i did it
gets the colors right in 90% of the games, but games like
mario land 2, the colors are inverted :P

edit: (this is how i do it, so you can point out what im doing wrong) :P

gb_bgpal[0]=palette[(data&0x3)];
gb_bgpal[1]=palette[((data>>2)&0x3)];
gb_bgpal[2]=palette[((data>>4)&0x3)];
gb_bgpal[3]=palette[((data>>6)&0x3)];

edit 2: never mind, the bad colors were just a bug in my interrupt routine, problem magically fixed :P

[bcrew1375]

Well, that's good to know. Let me know if you get sprites implemented, I'm still working on it :plain:.

[aprentice]

Well, that's good to know. Let me know if you get sprites implemented, I'm still working on it :plain:.

rough implamention of sprites, very incomplete, as a matter of fact, this is the only case that it works right in, but since its 3am, i can't do better :P

http://darkengine.net/gb/sml_sprite.gif

On the side note, I haven't figured out how pad (P1) works, does anyone understand this register?

[bcrew1375]

If you mean the joypad register, I have a rough idea of how it works(I got the Start button working :P).

Here's an extract from one of the documents:

FF00
Name - P1
Contents - Register for reading joy pad info
and determining system type. (R/W)

Bit 7 - Not used
Bit 6 - Not used
Bit 5 - P15 out port
Bit 4 - P14 out port
Bit 3 - P13 in port
Bit 2 - P12 in port
Bit 1 - P11 in port
Bit 0 - P10 in port

This is the matrix layout for register $FF00:


P14 P15
| |
P10-------O-Right----O-A
| |
P11-------O-Left-----O-B
| |
P12-------O-Up-------O-Select
| |
P13-------O-Down-----O-Start
| |

These are all reversed(0 means on, 1 means off). If bit 5 is 0, that means P15 has been turned on. If P15 is turned on, you take the corresponding buttons and put their on/off status in the appropriate bit.

For instance, if I pressed the Start button and P15 was off. I would turn off the P13 bit(remember, off means on). If I pressed Down while P14 was turned off, the P13 bit would also be turned off. The programs can only get the status of 4 buttons at a time. They usually turn on P15, get the keys, then turn on P14, get the keys, and then combine them. This is how I understand it as of right now. There is also an interrupt that is called, I think it's when P10-P13 change.

[aprentice]

I got sprites almost completely done, theres just a bug somewhere that makes some sprites a little screwy (as you can see in the image below).
I also didnt implement priorities or a sprite limiter yet, so 40 sprites could show on the screen at once if they wanted to, but this will be easy to add.

Input however is messed up, I just can't seem to get it right, but
its enough to get into the game, but not to play :P

http://darkengine.net/gb/tetris_sprite.gif
http://darkengine.net/gb/zelda_sprite02.gif
http://darkengine.net/gb/zelda_sprite01.gif

[bcrew1375]

Well, I just got through switching around some of the interrupts. I'm now having the same inverted colors problem you were having :P.

[aprentice]

Well, I just got through switching around some of the interrupts. I'm now having the same inverted colors problem you were having :P.

Make sure you request a vblank interrupt right at the beginning of the vblank period. That should fix your problem almost indefinately :P

[bcrew1375]

I'm doing it immediately after the LY register hits 144. Alot of games seem to be going farther now that I fixed the LCDC interrupt. Unfotunately, the graphics are distorted because of whatever I'm doing wrong :/.

[aprentice]

I'm doing it immediately after the LY register hits 144. Alot of games seem to be going farther now that I fixed the LCDC interrupt. Unfotunately, the graphics are distorted because of whatever I'm doing wrong :/.

distorted graphics aren't caused by interrupts, its caused by cpu bugs in most cases, i'd look over some of your opcodes if i were you. You'd be surprised at the supidest mistakes you can make, I know i was :P

[bcrew1375]

I would agree with you except the games ran right for the most part until I changed the way interrupts are handled. I also added the LCDC interrupt which is probably the main cause.

[zenogais]

Well, I've begun work on my Gameboy emulator. Its not very far atm, but you can check it out here (http://www.zenogais.net/projects/NeoGameBoy).

[aprentice]

Well, I've begun work on my Gameboy emulator. Its not very far atm, but you can check it out here (http://www.zenogais.net/projects/NeoGameBoy).

cool, great to see another person working on a gameboy emu, I was beginning to think it was just me and bccrew (with the rest of the people disappearing) :P

Keep us up to date on the progress, I need something to read :P

[glVertex3f]

You guys are making my mouth water.... I think i'll embark on this journey if I ever get my Chip 8 emu done. Ofcourse i'll be behind again though :)

[bcrew1375]

This is a much, much bigger project than Chip-8. If you decide to, make sure you're prepared for it.

[zenogais]

Do you guys both already have completed CPU cores? Just curious how you guys dealt with the endianess issues, I'm using macros atm.

[bcrew1375]

Well, I don't think you could call them "complete." Mine definitely has some bugs to work out. The endian-ness, I basically deal with it whenever I need to. Such as: register = ((memory[PC + 1]) << 8) + memory[PC];

BTW, I solved my problem. It had nothing to do with the interrupts. I was accidently denying writes to the display RAM under certain conditions, which was un-needed -_-.

[zenogais]

Well, I don't think you could call them "complete." Mine definitely has some bugs to work out. The endian-ness, I basically deal with it whenever I need to. Such as: register = ((memory[PC + 1]) << 8) + memory[PC];

Ah right, I just have a predefined macro for dealing with it, so for me that would be:



register = SWAP_WORD( readMemory16(PC) );


where swap word is defined like so



#if defined (_HIGH_ENDIAN_)

/// A macro which swaps the least significant byte and most significant byte of a 16-bit word.
#define SWAP_WORD(word) word = (word>>8) | (word<<8)

#else // !defined (_HIGH_ENDIAN_)

#define SWAP_WORD(word)

#endif // _HIGH_ENDIAN_


This way I can just define a preprocessor flag for HIGH_ENDIAN systems (Intel and AMD) and swap the bytes around, or on naturally low endian systems not do anything, this is for a bit more cross-platform compatability. Also, out of curiosity, what are you guys using for graphics? I was planning on using DirectX 9, because I wanna learn how to use the API, but I still might stick with SDL.

[bcrew1375]

SDL for me. I'm still having trouble getting sprites to show. It's strange, the blocks will appear in Tetris after they hit the bottom of the well, but nothing else shows any sprites.

[zenogais]

SDL for me. I'm still having trouble getting sprites to show. It's strange, the blocks will appear in Tetris after they hit the bottom of the well, but nothing else shows any sprites.

hmm, maybe thats because when it hits the bottom it gets drawn as part of the background?

[bcrew1375]

Oh, hehe :blush:. Well, that was kinda stupid. It does indeed become part of the background once it hits the bottom of the well :P.

[aprentice]

Oh, hehe :blush:. Well, that was kinda stupid. It does indeed become part of the background once it hits the bottom of the well :P.

I use direct draw for gfx and my cpu is complete :P

What I have done so far:

- All CPU Instructions
- Debugger w/ disassembler & logger
- Background GFX
- 90% complete sprite emulation
- SRAM/PRG Banking
- Complete MBC1
- Buggy Controllers
- Timer w/ TAC Freq control
- DIV register
- OBJ0,OBJ1,BG palettes
- 95% complete interrupt system (missing bounce interrupt)

If you guys need help with any of this, feel free to ask :P

[bcrew1375]

BTW, aprentice, when did you start work on yours?

[aprentice]

BTW, aprentice, when did you start work on yours?

I've been working on it on and off the last 2 months, in the past 2 weeks I've made the most progress. How about you?

[zenogais]

I've been working on it on and off the last 2 months, in the past 2 weeks I've made the most progress. How about you?

Looks like the CPU core is gonna take me a bit, so i'll be a while in catching up with you guys :P

But I'm guessing the sound will be the hardest part.

[bcrew1375]

Yes, I agree. I also think the sound will be the most difficult part. About when I started, I've understood basic emulation concepts for a few years. There were just some things I couldn't quite grasp until after doing my Chip-8 interpreter. After that, it was just like "Eureka!" :P. So, probably about as long as you, aprentice.

[zenogais]

Ok, I got looking at some docs refraction sent me last night, and it turns out that the CPU isn't nearly as large as I thought 255 * 3 opcodes, thats special extended opcodes and all, alot of typing, but whateva.

[aprentice]

Ok, I got looking at some docs refraction sent me last night, and it turns out that the CPU isn't nearly as large as I thought 255 * 3 opcodes, thats special extended opcodes and all, alot of typing, but whateva.

Its only about 500 opcodes give or take one :P

[glVertex3f]

Wow thats not as bad as I thought. I might could actually do this :P

[smcd]

Regarding endianness, if you don't mind doing a little assembly, there's an instruction that can help, XCHG. There are several methods discussed here:
http://www.codeproject.com/cpp/endianness.asp but not all methods use assembly. :)

[zenogais]

Regarding endianness, if you don't mind doing a little assembly, there's an instruction that can help, XCHG. There are several methods discussed here:
http://www.codeproject.com/cpp/endianness.asp but not all methods use assembly. :)

I had found those methods before, but the optimization isn't necessary.

[aprentice]

Wow thats not as bad as I thought. I might could actually do this :P

I wouldn't recommend this project to you, its a lot more complex than you think it is, and we cannot guide you step by step through this huge project. The gameboy is not as simple as most people think it is :P

[bcrew1375]

I completely agree. Not to mention the tiniest change can ruin everything, and then it takes you forever to find it -_-.

[glVertex3f]

Ok, as I try not to take offense to that... :P

Would you say Atari would be a more logical next step? I know I am new to emutaltion but never underestimate a n00b whose willing to learn :)

btw, in all the Chip docs they have opcodes in 2 formats the actual 0xFFFF format in the roms and then the assembly codes themselves (jmp, mov). All of the GB/Atari docs have just the assembly codes. Do these translate directly into binary or how do you decipher whats coming in from the rom.

[refraction]

btw, in all the Chip docs they have opcodes in 2 formats the actual 0xFFFF format in the roms and then the assembly codes themselves (jmp, mov). All of the GB/Atari docs have just the assembly codes. Do these translate directly into binary or how do you decipher whats coming in from the rom.

there are documents out there with the hex codes for the related opcodes, you just have to find them... ive uploaded my docs here to give you a few to look through

[zenogais]

Ok, I've started doing the CPU stuff now, its working pretty good, I even got a few opcodes done. I've also decided to create nightly builds for this project, check it out here (http://www.zenogais.net/projects/NeoGameBoy/)

[bcrew1375]

Bah, darn it zenogais. I always seem to need extra DLL's to run your stuff :P.

[zenogais]

Bah, darn it zenogais. I always seem to need extra DLL's to run your stuff :P.

*cough* its in Debug mode so of course *cough*

[aprentice]

*cough* its in Debug mode so of course *cough*

Found all the dll's that zenagais uses at http://www-personal.engin.umich.edu/~atcheng/

just ran that exe, as far as i know, that exe does absolutely nothing, and by nothing i mean zip, 0, nada :P

[zenogais]

Found all the dll's that zenagais uses at http://www-personal.engin.umich.edu/~atcheng/

just ran that exe, as far as i know, that exe does absolutely nothing, and by nothing i mean zip, 0, nada :P

Hehe, its not supposed to do anything yet, I just started remember? :P

[aprentice]

Hehe, its not supposed to do anything yet, I just started remember? :P

Ive slacked the past 3 days, but I have finally got input working bug free. Lets just say it took a crap load of debugging and tracing to get a solid idea of how it works, and I must say its pretty damn simple once you understand it :P

Now tetris is finally fully playable :P

edit: heres the proof incase noone believes me

http://darkengine.net/gb/tetris_game01.gif

[smcd]

Awesome! Gonna release it and take over the GB emulation world? ;)

[bcrew1375]

Maybe he will release it, but take over the GB emulation scene? Hehe, not likely :P. Though, I must admit at this point he is alot farther than me.

[refraction]

doin a good job guys :) i wish i was as far as some of you! but my emulator ive not even started doing cpu ops yet! but i did give zenogais a bit of a hand the other night, most of it was pretty easy to understand but some are quite baffling!

isnt it fun doing opcodes from 0x40ish to about 0x60? :P

[bcrew1375]

Yeah, those were easy. I'm got 2 functions to cover all of them :P.

[zenogais]

doin a good job guys :) i wish i was as far as some of you! but my emulator ive not even started doing cpu ops yet! but i did give zenogais a bit of a hand the other night, most of it was pretty easy to understand but some are quite baffling!

isnt it fun doing opcodes from 0x40ish to about 0x60? :P

meh, you're as bad a linuzappz I swear, I had to go through a run cleanup after you sent me what you had last night :P But thanks! :)

I've now worked through to about 0x7F.

[aprentice]

doin a good job guys :) i wish i was as far as some of you! but my emulator ive not even started doing cpu ops yet! but i did give zenogais a bit of a hand the other night, most of it was pretty easy to understand but some are quite baffling!

isnt it fun doing opcodes from 0x40ish to about 0x60? :P

The load opcodes are the easiest, just lots of copy and pasting :P

edit: Just finished emulating the battery pack, works like a charm
edit2: Just added save/load states, took only 5 mins, so damn easy :P

[bcrew1375]

Man, you're really kicking my arse :P.

Edit: Dooooooooooooooooooooooooooooohhhhhhhhhh hhhhhhhhhhhhhhhhh!!!!!!!!!!!!!!!!!!!! I figured out my sprite problem. After trying everything else, I noticed I hadn't implemented the DMA register -_-.

[aprentice]

Man, you're really kicking my arse :P.

Edit: Dooooooooooooooooooooooooooooohhhhhhhhhh hhhhhhhhhhhhhhhhh!!!!!!!!!!!!!!!!!!!! I figured out my sprite problem. After trying everything else, I noticed I hadn't implemented the DMA register -_-.

Hehe, good luck on your sprites problem, if you have any questions, im here :P

Also, on the side note, does your zelda go in game? When i try leaving the house (starting point), the game freezes. I dunno if its a bug in mbc1 or interrupts, everytime i mess with both of these factors, compat increases, but im running out of ideas :P

[bcrew1375]

I used to be able to go out of the house and walk around the town with distorted graphics, but now that I've repaired some opcodes, I can't get past name registration. I have a feeling that's it's not the MBC, but some minor bugs in the CPU core.

Edit: Well, Tetris now works flawlessly, except I still haven't implemented the DAA instruction. Would you be so kind as to to tell me the formula you used, aprentice :blush:?

Edit 2: Another thing. Is there any purpose at all to the H and N flags? I haven't seen a single thing that makes use of them.

[refraction]

i dont know if people have noticed or not but ill just give this as a warning

The gameboy has 2 sets of general purpose registers, one basically an alternate set of the other, like if you look at this opcode

LD C, C' <-- the C register is one of the main ones and C' is the alternate set, as i looked at that and thought it was a pointless cpu op but it does make sense if you have the alternate registers!!!

altho im not sure if its just mirrored after every cpu operation or what.

[aprentice]

I used to be able to go out of the house and walk around the town with distorted graphics, but now that I've repaired some opcodes, I can't get past name registration. I have a feeling that's it's not the MBC, but some minor bugs in the CPU core.

Edit: Well, Tetris now works flawlessly, except I still haven't implemented the DAA instruction. Would you be so kind as to to tell me the formula you used, aprentice :blush:?

Edit 2: Another thing. Is there any purpose at all to the H and N flags? I haven't seen a single thing that makes use of them.

H and N are used when the AF register is used in opcodes :P

This is what i used for DAA, but I dont know if its correct, its probably wrong :P

int hi=(regA>>4)&0x0F;
int lo=(regA)&0x0F;
regA=(hi*10)+lo;

Do you emulate the HALT instruction? I dont have it emulated and I'm not exactly sure how to "correctly" approach it.

[zenogais]

H and N are used when the AF register is used in opcodes :P

This is what i used for DAA, but I dont know if its correct, its probably wrong :P

int hi=(regA>>4)&0x0F;
int lo=(regA)&0x0F;
regA=(hi*10)+lo;

Do you emulate the HALT instruction? I dont have it emulated and I'm not exactly sure how to "correctly" approach it.

Well, right now what I'm doing is throwing an exception, and then later down the line the exception is caught and the body of the exception handling code loops until an interrupt occurs. I'm not sure quite sure how this'll work, I'll tell you when I have a completed CPU core.

[bcrew1375]

I've basically got two variables called 'halted' and 'stopped', which I turn on when either command is executed. I then stop executing opcodes until a interrupt occurs for halted, or a button is pressed for stopped.

[aprentice]

I've basically got two variables called 'halted' and 'stopped', which I turn on when either command is executed. I then stop executing opcodes until a interrupt occurs for halted, or a button is pressed for stopped.

how are you making the cpu idle until an interrupt occurs?

[bcrew1375]

Basically, doing "if (!halted) { *execute opcode* } I'm still using the giant switch statement, so before I get an opcode, I check to see if the CPU is halted or stopped.

[zenogais]

Hmm, how are you guys detecting carry's and half-carry's, because I dunno, doesn't seem like I'm doing this right.

EDIT: Whoops. Basically this is what I'm doing now:



void GBProcessorZ80::INC_R()
{
byte value = 0;

switch( opcode )
{
case 0x34:
{
value = readMemory8( registers[0].wds.HL ) + 1;
writeMemory8(registers[0].wds.HL, value);
}
break;
default:
{
opcode >>= 3;
*(registers8[opcode])++;

value = *registers8[opcode];
}
break;
}

if((value&0xF) == 0)
SET_FLAG ( GAMEBOY_FLAG_H );
CLR_FLAG ( GAMEBOY_FLAG_N );
CHECK_ZERO_FLAG( value );
}

void GBProcessorZ80::DEC_R()
{
byte value = 0;

switch( opcode )
{
case 0x35:
{
value = readMemory8( registers[0].wds.HL ) - 1;
writeMemory8(registers[0].wds.HL, value);
}
break;
default:
{
opcode >>= 3;
*(registers8[opcode])--;

value = *registers8[opcode];
}
break;
}

if((value&0x0F) == 0x07)
SET_FLAG ( GAMEBOY_FLAG_H );
CLR_FLAG ( GAMEBOY_FLAG_N );
CHECK_ZERO_FLAG( value );
}

[aprentice]

Basically HALF CARRY is set when bit 3 carries into bit4, and CARRY is set when bit 7 carries into bit 8.

Half carry if value > 15
Carry if value > 255

So for INC it would basically be:

if ((reg&0xF)+1) > 15 set half carry

Since op INC wraps, carry flag isnt affected.

Edit: your code looks like it works, I didn't take the time to actually look at it when I originally posted.

[aprentice]

I can't seem to get interrupts working right, has anyone had any success with them? If i attempt to execute interrupts on a per op basis it breaks some games, if I attempt to execute interrupts on a per frame basis more games work, but the compat still sucks. If anyone has a method they'd like to share, please do ;P

[smcd]

Check gnuboy's source? It's an open-source GB emulator. Maybe look how they handle it? http://gnuboy.unix-fu.org/

[aprentice]

Check gnuboy's source? It's an open-source GB emulator. Maybe look how they handle it? http://gnuboy.unix-fu.org/

Source code doesn't help if you dont know where the source is comming from and if you consider the interrupt system being a large portion of the system, it's not easy to follow in other emulators source codes. It would mean more to me if someone explained it :P

[bcrew1375]

I've been generating interrupts based on the number of cycles executed. I have a counter for the H-Blank and the Timer that holds the number of cycles it takes for a H-Blank or Timer update to occur. Everytime an instruction is executed, I subtract the number of cycles it used from the counter. When the counter hits <= 0, I call a function that updates the I/O registers. Then I reset the counters. When LY hits 144, I generate a V-Blank interrupt. I can't be sure, but I don't seem to be having any trouble with mine.

[aprentice]

I've been generating interrupts based on the number of cycles executed. I have a counter for the H-Blank and the Timer that holds the number of cycles it takes for a H-Blank or Timer update to occur. Everytime an instruction is executed, I subtract the number of cycles it used from the counter. When the counter hits <= 0, I call a function that updates the I/O registers. Then I reset the counters. When LY hits 144, I generate a V-Blank interrupt. I can't be sure, but I don't seem to be having any trouble with mine.

so the compat in your emu is generally good?

[bcrew1375]

Well, I get some kind of result from just about any game(even though they're not always good. :P). I can't tell you if it's the best way. It's just the way I'm doing it.

[aprentice]

Well, I get some kind of result from just about any game(even though they're not always good. :P). I can't tell you if it's the best way. It's just the way I'm doing it.

7/10 games i test run an intro, but like 3/10 get ingame and are playable :\

[refraction]

off from my memory, hasnt the R register got something to do with the interupts?

[zenogais]

Is there even an R register?

[refraction]

ah its a z80 thing, but seen as the GB uses Z80 slightly modified i assumed it was relavant, this is what it says tho.


R is the Refresh register, whose value is increased by the length of every instruction, when they are executed. Only seven of its bits are updated, its MSB (most significant bit) is always zero. This register has normally no practical use for the programmer.


so all in all its a load of crap and ill shut up again ;p

[aprentice]

so all in all its a load of crap and ill shut up again ;p

havent heard anything usefull from you yet :P

[refraction]

havent heard anything usefull from you yet :P

haha well cheers for that, im just trying to get to grips with the concept of the gameboy hardware, ive not even started my emu yet, all ive got is a very simple user interface ;p

[aprentice]

Zelda is now fully playable in my emu :P

While optimizing my cpu core, i found a few bugs causing some games to glitch up, and crashing zelda before going in game :P

[bcrew1375]

Nice! Hopefully, I will be there soon :P. I just got the X and Y flip for the sprites implemented. Now Link doesn't split in half on the game select screen :P.

BTW, could we see some screens :bouncy:?

[aprentice]

Nice! Hopefully, I will be there soon :P. I just got the X and Y flip for the sprites implemented. Now Link doesn't split in half on the game select screen :P.

BTW, could we see some screens :bouncy:?

Actually, I need to implament X,Y flipping aswell before i make any screens, once thats done, the game will look flawless :)

I'd like to see screens from your emu too :P

[retroK]

Anyone had a look at our Java Gameboy emulator AEPgb? It is opensource and we are looking for help. We do also have some problems with the DAA part ;)

Homepage:
http://aepgb.aep-emu.de/

Project page:
http://sourceforge.net/projects/aepgb/

[bcrew1375]

Wow, looks like you're a ways ahead of us. I haven't even thought about GBC yet :plain:.

[retroK]

This is not 100% our code - we took over another GBC emu called Pgb added some new features and increased compatibility.

[aprentice]

bccrew, how are you handling Sprite Y Flipping? I got X Flip working but my Y Flip code doesnt do anything :\

This is my code:

int curr_pos=(160*ypos);
int dest_pos=(160*(y+8));
int diff_pos=(dest_pos-curr_pos);
int draw_pos=dest_pos-(160*(8-(diff_pos/160)));
vreg.memory[(draw_pos)+x+i]=gb_spr_pal[spr_pal][pixel];

Y is Sprite Y Coordinate
X is Sprite X Coordinate
YPos is Y position in the loop, either 8 or 16, depending on sprite.

[bcrew1375]

To be honest, I'm not even sure if mine works(only in theory). Do you have a program I could test it with :P.

[aprentice]

To be honest, I'm not even sure if mine works(only in theory). Do you have a program I could test it with :P.

You could msg me the code and i could have a look at it, or you could explain what theory you based it on :P

I thought its top=bottom, top+1=bottom-1, etc etc, but that doesnt seem to work (as the code above tries to do) :\

[bcrew1375]

Basically, I'm getting the pixel data in the reverse order. I have a variable j looping from 0 to the sprite height - 1. I'm taking the sprite data area(0x8000) and multiplying it by (currentSprite * 4). Since each line is 2 bytes. I then add (j * 2), get the data, then add (j * 2) + 1. If the Y-flip bit is on, I'm simply doing (j ^= sprite height - 1). After I get the data, I do another Exclusive OR to get j back to it's old value. Hope that's clear enough.

[refraction]

Basically, I'm getting the pixel data in the reverse order. I have a variable j looping from 0 to the sprite height - 1. I'm taking the sprite data area(0x8000) and multiplying it by (currentSprite * 4). Since each line is 2 bytes. I then add (j * 2), get the data, then add (j * 2) + 1. If the Y-flip bit is on, I'm simply doing (j ^= sprite height - 1). After I get the data, I do another Exclusive OR to get j back to it's old value. Hope that's clear enough.


wouldnt it be easier just to load the data in backwards :huh:

[bcrew1375]

Um, that's exactly what I'm doing :P. I'm inverting the loop variable, using it as an index and then inverting it again. I'm only doing that if the Y-flip bit is on though. Of course, i could just have two separate sprite drawing routines, but I'm trying to keep it compact :P.

BTW, what I said earlier about the H and N flags. I know there are instructions that set or reset them, but there seems to be nothing at all that evaluates them. So, what's the point in even worrying about them :huh:? Maybe they're just useless flags that were used in the Z80.

[refraction]

hmm, i duno, some things seem to look at previous calculations and base their result upon what happened in the last operation.

[glVertex3f]

Sorry to "butt in", but I decided to try a GB emu anyway (it sure as heck wont hurt me).

I noticed you saying something about the edianess issue's. I take it the the GB and x86 processors are differet? (High.Low)

So for that I would just swap the bytes around and then write them to registers?

(Im not to sure how to word all of that so sorry if it seems hard to understand)

[bcrew1375]

refraction: Alot of instructions rely on the last instruction, H and N are assigned values, but never seem to be evaluated, only Z and C. Once I get most things working correctly, I think I'll try not altering the H and N flags, and see what happens.

glVertex3f: The x86 and GB z80 both use little-endian. That means with 16-bit or higher numbers, the lowest byte is stored first. For example: If you have the number 0x7965. In little endian, this would be stored as 65 79.

[GbaGuy]

H and N are used by the DAA instruction.

A game could always do
PUSH AF
POP HL
and then look at L if it really wanted to :)

[glVertex3f]

The x86 and GB z80 both use little-endian. That means with 16-bit or higher numbers, the lowest byte is stored first. For example: If you have the number 0x7965. In little endian, this would be stored as 65 79.

Ok, so you only need to worry about this if you want your emu to be portable onto High endian.

btw, bcrew.. those docs you posted are EXTREMELY useful. ggs :icecream:

[aprentice]

Hey GbaGuy, hows yours (and the rest of the teams) gameboy emu going, we haven't heard from you guys in awhile.

[aprentice]

Heres some motivation for you gameboy coders out there :P

http://www.darkengine.net/gb/zelda_la01.gif
http://www.darkengine.net/gb/zelda_la02.gif

Edit: Forgot to mention I added zip support :P

[bcrew1375]

Well, I finally nailed my problem(even though I'm still not sure what it was :P). Zelda now goes in game, as well as Metroid 2. Both appear to be fully playable, except I'm still having some window display problems.

[zenogais]

Hehe, I've been procrastinating on my Gameboy emu, haven't worked on it since Doom 3 came out :P

[aprentice]

Hehe, I've been procrastinating on my Gameboy emu, haven't work on it since Doom 3 came out :P

don't let doom 3 consume you, fight the urge! :P
I haven't played doom 3 on the other hand, so im safe :P

[bcrew1375]

I haven't seen the game(I'm actually not even interested). Though, my cousin says it has an option that even the most high-end computers can't handle.

[glVertex3f]

A few quick questions,

When an op-code wants you to load a register with a 16bit integer, I assume that you get that integer from the current position in memory right?

and

LD (r16), A

Do you just simply load the value of A into the 16bit register?

I know these questions may sound simple but i Just want to make sure about these couple of things.

[bcrew1375]

If it has parentheses, such as (r16), that means store the right operand in memory at the location held in the left operand. So, assuming:

A = 0x16
HL = 0x8000

After the instruction "LD (HL), A", memory location 0x8000 would hold the value 0x16.

[aprentice]

A few quick questions,

When an op-code wants you to load a register with a 16bit integer, I assume that you get that integer from the current position in memory right?

and

LD (r16), A

Do you just simply load the value of A into the 16bit register?

I know these questions may sound simple but i Just want to make sure about these couple of things.

I'm gonna keep this post short and sweet, and I hope you won't ask us anymore rediculously easy question after this one, because we aren't going to help you code this emu one line at a time (chip8 comes to mind).

LD (r16),A is basically writing 8 bit register a to a 16 bit address.

Example: mem_write8(mem_read16(regPC),regA);

Edit: bccrew beat me to it :P

[glVertex3f]

Thank you,

And I didnt need people to help me write ChipAte one line at a time.
Yes of course I needed help, it was the first time I had ever done emulation and alot of the things that I was doing were very new to me.

Anyways, I'll try not to ask any more simple questions, I usually ask before I think anyway :P

[bcrew1375]

Well, I appear to have solved my window display problem. Now I think I'll go for reconfigurable input, but I'm still not quite sure how to approach it :/. I really want to start using my joypad, the keyboard is starting to get annoying. I could just hardcode it for my joypad, but why not make it reconfigurable for anything :P.

[aprentice]

Well, I appear to have solved my window display problem. Now I think I'll go for reconfigurable input, but I'm still not quite sure how to approach it :/. I really want to start using my joypad, the keyboard is starting to get annoying. I could just hardcode it for my joypad, but why not make it reconfigurable for anything :P.

nice job :P How are you planning to approach sound? Thats suppose to be a nightmare. I don't think i'll touch sound for a long time, and not cause of the gameboy, but because direct sound just looks plain scary :P

[zenogais]

nice job :P How are you planning to approach sound? Thats suppose to be a nightmare. I don't think i'll touch sound for a long time, and not cause of the gameboy, but because direct sound just looks plain scary :P

DirectSound isn't so bad, but honestly coming from a bit of sound emulation experience, I'd use something like FMOD (http://www.fmod.org), its much easier to perform sound emulation tasks using this library. Really though, FMOD works no different than DirectSound, I just found it easier.

[aprentice]

DirectSound isn't so bad, but honestly coming from a bit of sound emulation experience, I'd use something like FMOD (http://www.fmod.org), its much easier to perform sound emulation tasks using this library. Really though, FMOD works no different than DirectSound, I just found it easier.

maybe you will be able to help us when we decide to do sound, I don't come from a sound background, and have never really used sound at all in my programming experience :P

is FMOD hard to settup like direct sound? Also, its gonna need to support some sort of streaming since i assume we are gonna have to stream WAVE data generated by the cpu somehow :P

edit: also bccrew, the answers to your question about half carry and negative :P

Bit/Flag/Name/Use
6 n - - Add/Sub-Flag (BCD)
5 h - - Half Carry Flag (BCD)

Found that in another doc i was looking in :P

[glVertex3f]

I am so sorry for posting again..
(If you want I'll start my own thread if im disrupting progress)

I just want to make sure I am doing this right before I continue
(No, this isnt something im gonna do on every op-code)



void ADC_A_HL()
{

unsigned char carry_flag = ((gbReg.F & gbReg.CF) >> 4)
unsigned char temp_value = gbMemory[gbReg.HL];

gbReg.A += (temp_value + carry_flag);

if(gbReg.A == 0) SetFlag(gbReg.ZF, 7);
if(gbReg.A > 15) SetFlag(gbReg.HF, 5);
if(gbReg.A > 255) SetFlag(gbReg.CF, 4);

ResetFlag(gbReg.NF, 6);

}


gbReg.CF is 0x10, and the SetFlag functions, the first argument is the Flag to be set and the second argument is the bit number.

Now, if this is wrong, I appologize again.. I just need to be pointed in the right direction :o

[bcrew1375]

Um, flags are all one bit. You shouldn't need to specify a bit to turn or off, only the flag you're going to turn off or on. Also, the A register and all the other 8-bit registers are all modulated by 255.

[zenogais]

FMOD takes about 5-10 lines to set up depending if you want error checking, and how much detail you want about the error. Of course, it has support for streaming, or else it would even be a decent audio library. The best thing about it is that streaming is very simple. If you look at the PS2SP sources, you'll that I wrote a small wrapper for FMOD, I'm currently working on an updated much cleaner version of the wrapper that I'll be using on my Gameboy Emulator. FMOD is basically a wrapper library, one of the things it wraps being DirectSound.

[aprentice]

I am so sorry for posting again..
(If you want I'll start my own thread if im disrupting progress)

I just want to make sure I am doing this right before I continue
(No, this isnt something im gonna do on every op-code)



void ADC_A_HL()
{

unsigned char carry_flag = ((gbReg.F & gbReg.CF) >> 4)
unsigned char temp_value = gbMemory[gbReg.HL];

gbReg.A += (temp_value + carry_flag);

if(gbReg.A == 0) SetFlag(gbReg.ZF, 7);
if(gbReg.A > 15) SetFlag(gbReg.HF, 5);
if(gbReg.A > 255) SetFlag(gbReg.CF, 4);

ResetFlag(gbReg.NF, 6);

}


gbReg.CF is 0x10, and the SetFlag functions, the first argument is the Flag to be set and the second argument is the bit number.

Now, if this is wrong, I appologize again.. I just need to be pointed in the right direction :o

The whole opcode is wrong, back to the drawing board for you :P
We could tell you the correct code, but then we wouldn't be helping you, so read the docs one more time more carefully and give it another shot :P And half carry is the carry from bit 3 to 4 by definition, so look into that.

[glVertex3f]

Well, as far as the set flag function I was doing this



void GBmemory::SetFlag(unsigned char bit_num, unsigned char bit_shift)
{

if(((gbReg.F & bit_num) >> bit_shift) != 1)
gbReg.F += bit_num;

}


And yes I guess I obviously need to read the docs much more thoroughly as it sounds like I missed a whole lot.

But it was 2AM :P

[bcrew1375]

aprentice, could you post that document that has the BCD information in it. It might have some other information I've been looking for :P.

[aprentice]

aprentice, could you post that document that has the BCD information in it. It might have some other information I've been looking for :P.

http://www.work.de/nocash/pandocs.htm

Very conveniently layed out, this is the doc i used most of the time :P

[smcd]

http://www.work.de/nocash/pandocs.htm

Very conveniently layed out, this is the doc i used most of the time :P

Yeah, that guy knows his stuff :P too bad people always ripped off his GB/GBC and various other emulators...

[glVertex3f]

Ugh, ive been looking over my code only to fild that it was in a mess.

I guess thats what I get for programming while half awake (I have to quit doing that).

Here is my code, I cant really just post the ADC (HL) opcode by itself and have it make sense.

If any of you have the time, (and the heart) :P, Please give it a once over and make sure im actually getting this.

And bcrew, why do I need to modulate the registers?

Also note, to those of you who helped with my ChipAte (nearly all of you), I think you should be able to see a great difference in my coding style. To me it seems more "neat" and organized and overall moe readable.

[zenogais]

Really you need to just code and stop asking people to walk you along in coding emulators. The gameboy is loads more complex than the Chip8, and if you're not understanding whats going on you should do some research or try something simpler.

[aprentice]

Really you need to just code and stop asking people to walk you along in coding emulators. The gameboy is loads more complex than the Chip8, and if you're not understanding whats going on you should do some research or try something simpler.

I have to agree with Zenogias on this. I think the real problem here is not his lack of understanding of the gameboy, its the lack of solid programming skills, which is required to take on a task such as the gameboy. Lack of understanding of how bits work is a major set back as well. I think glVertex should first enhance his programming skills, and start with simple programs instead of jumping into the complex world of emulators as a beginners program. I know he will just ignore this advice just like he has ignored many other peoples advice, though.

[refraction]

my programming isnt spectacular, i dont know a lot about the gameboy (at the moment but that document is really helping) but im still gonna have a shot at it, im sure i will understand the system better the more of it i emulate, or attempt :)

i was the same with chip8, kinda didnt understand it at first, but the more i made of the system, i realised how it worked and understood the system better.

[glVertex3f]

Look, the only reason I was asking is to make sure I had the basic concept of what the DOCS were saying. I mean wouldnt you hate to program all of the opcodes when all along you were just missunderstanding what the docs were saying?

I'll admit I had alot of trouble with Chip8, and I know I wouldnt have been able to do it if it werent for all the help. But now I understand the concepts of emulation and I am confident in my programmming skills. You just have no idea how much the chip8 emulator has taught me. It caused me to look deeper into my language and understand ten times that of wich I knew before.

But i hope that if you look at my code (what little there is), you will see that I am serious about this and I am looking forward to the things that this emulator will teach me.

I understand that for most people, programming an emulator shouldnt be a place to learn, but I know I can do it.

I will try to continue and do as much as I possibly can without asking for help.

[aprentice]

I mean wouldnt you hate to program all of the opcodes when all along you were just missunderstanding what the docs were saying?


The stuff your asking for help has nothing to do with emulation, its purely bit math, which you should already understand before you touch emulation. I would like to help you, but not with learning the concepts of programming, that is your responsibility. If you have a question with something EMULATION related, then by all means ask, everyone here has a question or two, and its understandable. I will not answer any C++ related questions.

PS: I'm not trying to sound rude, but the attitude in gl's post slightly ticked me off...

[glVertex3f]

I am really sorry, I honestly didnt write that post with any kind of negative attitude.

I guess I am merely confuse because I dont understand what you mean. I have a ver good understanding of bit math, and my main question was actually dealing with what the docs were saying. I guess I should have made this clearer in the beginning.

See my main problems were things like not understanding what
(HL)
meant, I know HL is a 16 bit register, I just at first thought that I added the VALUE of HL (+ carry) to the A register. I didnt know that the parentheses around the HL meant a memory location.

Anyway, it was things like that that were throwing me off. Nothing C++ related at all.

And the bit of code I posted (not the attachment) is code I wrote at 2am while I was half asleep, so excuse that bit :P

Now, if the code in the atachment is still way off, then I guess I am very wrong and there is something I am missing greatly, but I will never know what if you dont tell me.

I am very sorry if I have been sounding rude. I, in no way, meant to sound rude at all.
And thanks aprentice for not getting rude, you have very great patience :)

OH OH EDIT EDIT:

I know I have this

ADC_A_HL()
ADC_A_CONST8()
ADC_A_REG8()

when all i need is

ADC(unsigned char value)

I just wanted to let you know that that was one of those 2am things.
:whistling

lol no wonder you guys got ticked off at me (I ticked myself off)

I believe this should be right for the ADC opcode



void GBcpu::ADC(unsigned char value)
{

unsigned char carry_flag = ((REG_F & CF_MASK) > 0) ? 1 : 0;
unsigned char temp = (value + carry_flag);

if(REG_A + temp == 0) SetFlag(ZF_MASK);

ResetFlag(NF_MASK);

if((REG_A + temp) > 0xF) SetFlag(HF_MASK);
if((REG_A + temp) > 0xFF) SetFlag(CF_MASK);

REG_A += temp;

}

:blush:

[bcrew1375]

It looks like it MIGHT work, assuming you are correctly assigning values to the flags. Post the code again once you've done alot more work.

[glVertex3f]

I have just about all the opcodes programmed (whether they are right or not)
I was wondering about a few things.

the opcodes that have conditions, how do you tell what the conditions is?

also, I was wondering about the stack, I cant seem to find anywhere in the docs that have the size of it. Im not sure how much memory to allocate for it. (I assume it would either be a 0xFFFF or just simply use tha already allocated memory).

And without telling me how to do it, What exactly does the DAA opcode do?

[bcrew1375]

The condition is hard-coded into the opcode. The stack uses the Gameboy's internal memory. The DAA(Decimal Adjust A) instruction is meant to convert the A register into its proper packed-BCD representation.

[aprentice]

Heres the DAA code everyones been asking for, it runs right out of the box :P

void op0x27() //DAA
{
if(regF&0x40) //Negative Flag Set
{
if((regA&0x0F)>0x09 || regF&0x20)
{
regA-=0x06; //Half borrow: (0-1) = (0xF-0x6) = 9
if((regA&0xF0)==0xF0) regF|=0x10; else regF&=~0x10;
}

if((regA&0xF0)>0x90 || regF&0x10) regA-=0x60;
}
else
{
if((regA&0x0F)>9 || regF&0x20)
{
regA+=0x06; //Half carry: (9+1) = (0xA+0x6) = 10
if((regA&0xF0)==0) regF|=0x10; else regF&=~0x10;
}

if((regA&0xF0)>0x90 || regF&0x10) regA+=0x60;
}

if(regA==0) regF|=0x80; else regF&=~0x80;
}

I read up in BCD and I also had a peak on how other emus do it and tried to get an understanding of how it works. I didnt use any macros in this code so everyone should be able to use it without any mods.

I finally broke some walls that I ran into and the games that run that werent playable before are now :P Apparently it was a bug in my interrupt system that had me boggled, but now solved :P Also, I completely redid timing, although that didnt really have any major visible effects.

[aprentice]

Got tired of hardcore debugging of my bug infested emulator, so i added gameboy color support, which is very raw and prilimary at the moment, to take a small break from bug fixing :p

No commercial games run except a few menus in tetris dx. Second screen is from a gameboy color demo game called jet pack dx :P

http://www.darkengine.net/gb/gbc_tetrisdx01.gif
http://www.darkengine.net/gb/gbc_demo_jetpakdx.gif

edit: I didnt add this in the past 3 hours, i actually did it a few days ago (havent touched the emu in the past few days) and fixed a few bugs to make it start working. Just wanted to make it clear so people don't think its a cinch to add, although its not too hard, it just takes a lot of figuring out :P

[bcrew1375]

Man, no offense, but that code is a pain to look at :P. I tried it, I'm still getting incorrect values, but not as bad as my implementation. Maybe I'm setting some flags wrong :/. I'm still trying to understand how this works.

Edit: Congratulations on the GBC support :P.

[aprentice]

I tried it, I'm still getting incorrect values, but not as bad as my implementation. Maybe I'm setting some flags wrong :/.

Which games you testing the DAA code on?
And setting flags wrong could cause incorrect values since the F flag plays a major role in getting the right numbers

[bcrew1375]

I've tested it with Tetris and Metroid 2.

[aprentice]

I've tested it with Tetris and Metroid 2.

Tested it with tetris, no problems here.

In your emu, in which cases are you generating the LCDC interrupt? I just generate on LYC coincidence, was wondering if there were any other situations I would generate this on.


edit: Actually there might be a bug in the code or in another opcodes code when going from 99 to 100 in score. It might have something to do with the carry flag, If i figure it out, i'll get back to you on it.

[bcrew1375]

The high bits in STAT determine whether an interrupt should occur on certain conditions.

Edit: Ah, I've noticed a potential problem. The A register is being altered before the other checks are done. It shouldn't be altered until the end of the instruction, right?

[glVertex3f]

Ive bee ntaking a braek form my emu, I have been doing nothing but emulators for the past few months, I would spend ALOT of time every day. just programming.

It got so bad that I would try to sleep and I would wake up in the middle of the night, and cover up my whole body so that I would be "all in" the main function... I laughed myself to sleep...

So, I decided I probably needed a break.. lol

[smcd]

Ive bee ntaking a braek form my emu, I have been doing nothing but emulators for the past few months, I would spend ALOT of time every day. just programming.

It got so bad that I would try to sleep and I would wake up in the middle of the night, and cover up my whole body so that I would be "all in" the main function... I laughed myself to sleep...

So, I decided I probably needed a break.. lol

You're weird :P

By the way, nice job @ color aprentice. One of these days I might sport a try at the GB... I just need to learn something like DirectDraw first, GDI only is kinda slow.

[aprentice]

glVertex broke the ultimate of geekdom, I think he even made geeks cry :P either that or hes a nut case :P

[glVertex3f]

Yeah it was a low point in my life, I think I have recovered and I think I am ready to return to the IDE...

Note: Geek, nut case,, try both! :P

EDIT: Emu question,
I want to make sure I understand interrupts.
Basically, an inturrupt is something that stops the current operation and goes and does something else and returns to where it "interrupted"?

So on a gameboy an inturrupt occurs on a time cycle, when the interrupt occurs you halt the current opcode and do the interupt then return to the opcode?

[bcrew1375]

Interrupts work like this:

1. An event has occured that generates an interrupt.
2. The flag that applies to that interrupt is turned on.
3. If the *IME and the corresponding flag in IE register is turned on, the IME flag is then turned off and a call is made to that interrupt's jump location.

* IME stands for Interrupt Master Enable. This enables or disables all interrupts.

BTW, all you do is disable interrupts and jump to the address, the program should take care of the rest. I'm still working on when the interrupt flags should be reset :plain:.

[glVertex3f]

Oh ok, isee.

How long did it take you to get "any" results from your emu? (like a scrambled title screen or something)

I have a feeling mines gonna take a while as I have not even began to implement a timer or even touch the drawing.

[bcrew1375]

I was afraid of the drawing for a long time until I realized how incredibly simple it is :P. I was stumped for a long time because for some reason I simply could not grasp the I/O ports. Once I finished with my Chip8 emu, it suddenly became clear for some reason :P. After I got the I/O ports implemented everything started to flow again. Finally, after getting some things sorted out, I got my first demo to run :happy:.

[aprentice]

I never got to see that "first demo" :P My gameboy emulation was very complete before I even got gfx coded. I too was afraid of graphics and had trouble at first, so I spent most of my time working on other parts of the gameboy hardware. By the time I got gfx, the emu was already doing commercial games :P

To this day, my interrupt system is still shabby, and lacks correct implamentation. I still lack all cases where the LCDC interrupt is triggered, which causes some games to act wierd and some to glitch :P

A handful of games are playable now though, but a handful means nothing compared to the emus already released :P

[zenogais]

@bcrew: I would recommend learning Direct3D9 instead of DirectDraw as DirectDraw has been deprecated, and Direct3D allows for far more complex techniques such as vertex/pixel shaders and shading.

Also, I've just had my wisdom teeth taken out yesterday, but I should be back to working on my Gameboy emulator soon. I've made alot of progress since the last source release.

[bcrew1375]

@bcrew: I would recommend learning Direct3D9 instead of DirectDraw as DirectDraw has been deprecated, and Direct3D allows for far more complex techniques such as vertex/pixel shaders and shading.

Also, I've just had my wisdom teeth taken out yesterday, but I should be back to working on my Gameboy emulator soon. I've made alot of progress since the last source release.

Huh, what brought DirectDraw up all of a sudden? When I was referring to drawing, I meant the interpretation of the Gameboy's graphic data :P.

Edit: BTW, this is unrelated to this thread, but is anyone good at file handling? I'm working on another program where I need to search exceptionally large files (> 4 GB) for certain patterns. The problem is that it is going incredibly slow. I'm pretty sure it's the file reading and not the search algorithm. I'm only able to search like 1 MB per second :/.

[smcd]

Huh, what brought DirectDraw up all of a sudden? When I was referring to drawing, I meant the interpretation of the Gameboy's graphic data :P.

Edit: BTW, this is unrelated to this thread, but is anyone good at file handling? I'm working on another program where I need to search exceptionally large files (> 4 GB) for certain patterns. The problem is that it is going incredibly slow. I'm pretty sure it's the file reading and not the search algorithm. I'm only able to search like 1 MB per second :/.

I believe he was talking to me @ DirectDraw, see post #184.

[bcrew1375]

Ah, I see. zenogais referred to me though :P. Maybe he got confused, or maybe he's just crazy :plain:.

[zenogais]

Yeh, it was to seth, sorry about the mixup.

[aprentice]

Edit: BTW, this is unrelated to this thread, but is anyone good at file handling? I'm working on another program where I need to search exceptionally large files (> 4 GB) for certain patterns. The problem is that it is going incredibly slow. I'm pretty sure it's the file reading and not the search algorithm. I'm only able to search like 1 MB per second :/.

Your harddrive is the bottleneck, sorry buddy :P

[smcd]

I was making a program to search large files and would allocate a buffer, then read a block (for this size i would recommend 4 to 32 MB, not too high because allocation could fail easier), then use memcmp to search for my stuff. if not found, skip along. Since the portion was in memory, searching was a lot faster, but speed came at the expense of memory.

[bcrew1375]

Your harddrive is the bottleneck, sorry buddy :P

If my harddrive is the problem, why can other programs read from it so fast? :P

[zenogais]

If my harddrive is the problem, why can other programs read from it so fast? :P

Of course the hard-drive isn't the major bottleneck. Its really just the algorithm you're using that makes the difference. I ran into this problem when writing a program to calculate the SHA-1 hash of any given file. The basic idea is if the file exceeds X megabytes, where X is a number of your choosing then you'll read the file into memory and process it in Y megabyte chunks. Basically what I did, was if the file was larger than 10 megabytes then I read it into memory from the file in 5 megabyte chunks and processed each chunk through the hash algorithm, then read the next 5 megabyte chunk and so on until I was out of chunks, then I processed the final hash and badda bing badda boom. I can post some source code if you like, but its really quite simple. Of course the chunks weren't always 5 megabytes in size, but thats easy to account for. Just read as much as you can into the 5 megabyte buffer and process it.

[glVertex3f]

On the rotate opcodes, do you need to shift the register or just swap the necessary bytes?

I am currently doing it like this, I am just wondering if I am supposed to shift or not.



void GBcpu::RL(unsigned char &reg)
{

unsigned char bit_7 = (reg & 0x80) ? 1 : 0;
unsigned char carry = (REG_F & CF_MASK) ? 1 : 0;

if(REG_F & CF_MASK)
if(!bit_7) REG_F -= CF_MASK;

else
if(bit_7) REG_F += CF_MASK;

reg <<= 1; // < Heres the part in question!

if(reg & 1)
if(!carry) reg -= 1;

else if(!(reg & 1))
if(carry) reg += 1;

}

[GbaGuy]

On the rotate opcodes, do you need to shift the register or just swap the necessary bytes?

A rotate is a shift, the difference is what you do with the bit that gets
shifted out.

-----

As an update on the "emu team", none of us have had very much
time lately, as real life has struck everyone pretty much simultaneously.

:) to all, and to all a good nite... er... tomorrow... er... it's 12:07 AM...
I'm gonna sleep now...

[glVertex3f]

I was reading the docs and on some of the opcodes it has disp.

30 JR NC,disp

what does disp mean?

[bcrew1375]

disp is disposition. It's a signed 8-bit offset.

LOL. I just realized what word I wrote there. I think displacement would be better :D.

[glVertex3f]

Doh, thank you.

I have gotten just about every single opcode done (right or not has yet to be determined).

Also ran across a few more things that confused me.

1) I suppose dd is the same as disp?
2) Some of the "CB" opcodes have a +n*38 I would really like to know why it is like that. If I were I cat I would be dead from curiosity.

And I completely didnt even think about the memory holding signed values... I suppose that woould make the memmory a char array and not an unsigned char array.

disclaimer:
Anything that has been said either directly or implied, cannont be held against glVertex3f on account of it being 1:42AM and that glVertex3f has been programming all day.

Goodnight, I am now going to go get in my program and cover up with the main function. :P



for(int time = 143; time <= 1200; time++) {
glVertex3f(SLEEP);
}

[bcrew1375]

The memory is usually emulated as unsigned. Certain instructions interpret the data as signed.

Answer to number 1: I'm not sure, where have you seen that abbreviation?

Answer to number 2: I'm not sure why it was written like that. Replace 38 with 8 and it should make more sense. For instance, opcode 0x40 checks bit 0 of register B, 0x48 checks bit 1 of B...

[glVertex3f]

E8 ADD SP,dd

it was in the docs that you posted, the "nocash hackwork" one.

[bcrew1375]

In that case, it would also be a signed 8-bit value.

[glVertex3f]

Do you think possibly that dd is 8bit while disp is 16bit?

And does disp differ in any way from nn notation. It doesnt explain the differences but there obviously must be.

[bcrew1375]

I am positive they are both signed 8-bit values. The difference between dd and nn is that nn is unsigned.

[glVertex3f]

Well here is my code so far. Most of it has been done in the past two days.
I have programmed all of the opcodes and thats about it. I havent checked the correctness of the functions but I made it so fixing bugs would be very simple. I am now going to go read and figure out how to implement the drawing stuff. (I know how its done just not sure how to implement it).

And for once I am not posting code for anyone to "check" it for me. :P

And keep in mind that I havent checked this stuff and I have no way to test it since I havent done the drawing code.

:icecream:

[zenogais]

Well after having had my wisdom teeth out and being knocked out on meds for a few days, I worked like hell and finished my CPU core not to mention added a few new features to my emulator. Heres a pic of the ROM information window:

http://www.zenogais.net/projects/NeoGameBoy/Images/RomInfo-Small.jpg (http://www.zenogais.net/projects/NeoGameBoy/Images/RomInfo.png)

I'm working on video emulation at the moment at hope to be finished with that soon. The sources have been attached, and the CPU core is ugly, so there's your early warning :P

EDIT: Also wanted to mention, theres alot of extra stuff inside that source file (i.e. Win32ErrorDialog.hpp/.cpp), this is stuff that I'm working on for a general emulator framework as having worked on about 4 now I find that I'm constantly writing the same stuff (Memory, Video, Controls, GUI, Error Handling etc...), so I'll keep you guys posted as I progress on that.

[bcrew1375]

Looking nice. I did notice one minor problem. When you echo memory writes, it should only go from C000-DDFF and E000 to FDFF. If you write above FDFF, you're going to be writing into the OAM or the I/O registers.

[zenogais]

Thanks for that, hadn't done much dealing with memory mapped I/O bits yet, but I'll fix that. Also, how is your emulator progressing?

[bcrew1375]

Well, alot of games are playable now. I've been slacking lately. I haven't done any real work on it in the last week :P. I've been kinda stressed, and am just relaxing a bit.

[aprentice]

Well, alot of games are playable now. I've been slacking lately. I haven't done any real work on it in the last week :P. I've been kinda stressed, and am just relaxing a bit.

Fixed a huge bug in my emu, now about 95% games are fully playable :P
Enabled that dusty opcode profiler i coded ages ago and looked at every opcode that the game executed until i found one that was rogue :P
I also implamented mbc5, and WRAM banking, not sure how accurate, since I haven't got gameboy color games that use double speed mode running :P
I also finished up what I think is complete interrupt support, so now I can focus on cleaning up the emu a bit :P

Edit: I've been slacking this past week aswell, last night i tried touching the emu but I ended up just opening the source and falling asleep on my bed :P

[glVertex3f]

I am correct in assuming that when they say that (for example) AF register is


(REG_A << 8) + REG_F


right?

I was just wondering because in one of the docs it says to load AF with 0x1 and then after that it says to load register F with 0xB0.

[bcrew1375]

AF is a 16-bit register. A is the high byte of this register and F is the low byte. So if I load F with 0x00 and load A with 0xFF, AF will then equal 0xFF00.

BTW aprentice. How could a non-existant opcode screw your emulator up that much? If it doesn't exist, then games wouldn't have it in their source, and so it should never be executed. So, how did that happen? Or maybe by rogue you just meant an opcode that wasn't functioning correctly :P.

[aprentice]

AF is a 16-bit register. A is the high byte of this register and F is the low byte. So if I load F with 0x00 and load A with 0xFF, AF will then equal 0xFF00.

BTW aprentice. How could a non-existant opcode screw your emulator up that much? If it doesn't exist, then games wouldn't have it in their source, and so it should never be executed. So, how did that happen? Or maybe by rogue you just meant an opcode that wasn't functioning correctly :P.

opcode that wasnt functioning correctly :P

http://darkengine.net/gb/mariodx.jpg

It doesnt look pretty ingame though, lots of work to do :P

[glVertex3f]

bcrew, thats my point, look what the doc says

AF=$01-GB/SGB, $FF-GBP, $11-GBC
F =$B0

Loading F with B0h would completely undo loading it with 01h/FFh/11h...

Apretice, nice job! That has to give you a great since of accomplishment, if I ever get that far I think i'll crap my pants.

[aprentice]

AF=$01-GB/SGB, $FF-GBP, $11-GBC
F =$B0

Loading F with B0h would completely undo loading it with 01h/FFh/11h...


That means A gets loaded with 01 for gb mode etc and F always gets loaded with B0 regardless of gameboy mode.

A and F together form 01B0 for gameboy mode, 11B0 for gbc mode.

[Greevy]

Hey guys pretty good progress on your emulators ! :)

One of the most interesting thread I've read in a while. Frankly.

[glVertex3f]

I finally decided to get back to work on my emu,

A really easy question here (sorry aprentice! :) )
Since there are no opcodes for drawing.. I assume it is done through interrupts?
So, a certain interrupt will occur every few loops, and you draw the screen when the interrupt occurs?

[aprentice]

I finally decided to get back to work on my emu,

A really easy question here (sorry aprentice! :) )
Since there are no opcodes for drawing.. I assume it is done through interrupts?
So, a certain interrupt will occur every few loops, and you draw the screen when the interrupt occurs?

you draw the screen when LY hits 144.

[glVertex3f]

Oh, snap and fo shizzle.... I guess I missed that in the docs... argh.. I feel like I have a frekin learning disorder sometimes I swear.

Thank you aprentice.

[zenogais]

Here's the quote from GB.pdf page 55:

"The LY can take on any value between 0 through 153. The values between 144 and 153 indicate the V-Blank period."

[glVertex3f]

Ow wow, you spoil me.... now I dont have to find it myself YAY!

If you were a chick i'd kiss you!

Or, not... cuz that sounds wierd and stuff...

[aprentice]

Not much activity going on with this thread lately, besides glVertex posting and deleting his posts :P

Anyway, I'd like to hear a summary of everyones status, just cause im bored (and curious) :P

Ive been pretty lazy the past week, so I haven't done much work, but I have added huge cpu optimizations, fps counter, and support for 16,24, and 32 bit modes :P

Heres my emus status:

- Full Z80 CPU emulation
- MBC 1, 2, 5 implamented
- VRAM/WRAM/PRG/SRAM Banking
- Save State/Battery Pak Support
- DIV/TAC/TIMA Timers
- Full Input Support
- GBC Palette Support (for BG)
- CPU Speed Switching (for GBC)
- Zip Support
- Incomplete GBC DMA emulation

Edit: Also, i'd like to hear about some optimization techniques you guys have used to make your emulator faster :P

[smcd]

My progress is, I've still not started. :P School & work are keeping me tied up something fierce, so until it settles down, no time for fun stuff, unfortunately. I'm taking a class in C# this semester so it might be interesting to learn C# better while being the first to do an emulator in C# (that I'm aware of, if there are some in existence in C# already let me know?). Though I'll probably just do a chip8 in C# since I don't know it so well yet.

[glVertex3f]

Heh, the reason I deleted my post is that for somereason my picture disapeared...

I figured that a mod took it out because of the rom name and stuff.

But heres my progress.

I have done all the opcodes (I'll probably have to redo them)
I have implemented a rom info Dialog and I am working on a debug dialog.

I am also reading various docs about the LCDC and how it works. I would love to get some actual visual progression.

But other than that Ive been playing around with the tile format.. (the 'A' example in the docs) Havent figured out the nintendo logo yet... :P

[aprentice]

Heh, the reason I deleted my post is that for somereason my picture disapeared...

I figured that a mod took it out because of the rom name and stuff.

But heres my progress.

I have done all the opcodes (I'll probably have to redo them)
I have implemented a rom info Dialog and I am working on a debug dialog.

I am also reading various docs about the LCDC and how it works. I would love to get some actual visual progression.

But other than that Ive been playing around with the tile format.. (the 'A' example in the docs) Havent figured out the nintendo logo yet... :P

noone removed your picture, you had it hosted on your own server, so your server must have been down at that time. I thought you removed it cause you got embarassed about loving pokemon games :P

[glVertex3f]

rofl, Thats the only rom I could find.. Well, I had that and tetris but the tetris was a fakie.

And actually in their time those pokemon games were really good. I bet I invested over 600 hours into those babies...


I had the image hosted at ImageShack. Its done that to me a couple of times now.. guess i'll have to go somewhere else :p

[bcrew1375]

My current progress... Well, I'm still trying to find bugs in the CPU emulation, alot of games have really strange errors. What was the opcode giving you problems, aprentice? Maybe mine is the same one :P. Anyway, I've been kind of lazy lately, so just trying to kink some bugs out every once in a while. About optimization, I'm favoring readability over speed. There are plenty of fast Gameboy emulators, but I don't think I've seen one with source that is easy on the eyes, at least not to me :P.

[aprentice]

My current progress... Well, I'm still trying to find bugs in the CPU emulation, alot of games have really strange errors. What was the opcode giving you problems, aprentice? Maybe mine is the same one :P. Anyway, I've been kind of lazy lately, so just trying to kink some bugs out every once in a while. About optimization, I'm favoring readability over speed. There are plenty of fast Gameboy emulators, but I don't think I've seen one with source that is easy on the eyes, at least not to me :P.

The opcodes that gave me problems where the shift right and left, at that time, i misunderstood what to do with the flags etc and it caused problems, when i fixed that, problems were gone, if you want, paste those opcodes and i'll have a look at them, i've went over those opcodes with a fine needle, and even threw situations at them and traced em to death till I knew it was 100% accurate :P

Right now, the compat in my emu is like 90% games playable for mbc1, since about 9 out of 10 games i threw at it worked :P I think i may have a bug somewhere in my emu still that i haven't caught onto yet.

[bcrew1375]

Well, I don't know if there is a problem with them or not, but here they are:


void z80_SLA_reg8(unsigned char *reg)
{
// Put *reg's old bit 7 data in Carry flag.
if (*reg & 0x80)
regs.F |= FLAG_C_ON;
else
regs.F &= FLAG_C_OFF;

// Shift *reg left once. 0 is shifted in from right.
*reg <<= 1;

// If the result was 0, set flag Z, otherwise reset it.
if (*reg == 0)
regs.F |= FLAG_Z_ON;
else
regs.F &= FLAG_Z_OFF;

// Flags H and N are reset.
regs.F &= (FLAG_Z_ON | FLAG_C_ON);

// Machine cycles used is dependant on opcode.
if (opcode == 0x26)
cycles += 4;
else
cycles += 2;
}

void z80_SRA_reg8(unsigned char *reg)
{
// Put *reg's old bit 0 data in Carry flag.
if (*reg & 0x01)
regs.F |= FLAG_C_ON;
else
regs.F &= FLAG_C_OFF;

// Shift *reg right once. 0 is shifted in from left. If bit 7
// is set, make sure it stays set.
if (*reg & 0x80)
*reg = (*reg >> 1) + 0x80;
else
*reg >>= 1;

// If the result was 0, set flag Z, otherwise reset it.
if (*reg == 0)
regs.F |= FLAG_Z_ON;
else
regs.F &= FLAG_Z_OFF;

// Flags H and N are reset.
regs.F &= (FLAG_Z_ON | FLAG_C_ON);

// Machine cycles used is dependant on opcode.
if (opcode == 0x2E)
cycles += 4;
else
cycles += 2;
}

void z80_SRL_reg8(unsigned char *reg)
{
// Put *reg's old bit 0 data in Carry flag.
if (*reg & 0x01)
regs.F |= FLAG_C_ON;
else
regs.F &= FLAG_C_OFF;

// Shift *reg right once. 0 is shifted in from right.
*reg >>= 1;

// If the result was 0, set flag Z, otherwise reset it.
if (*reg == 0)
regs.F |= FLAG_Z_ON;
else
regs.F &= FLAG_Z_OFF;

// Flags H and N are reset.
regs.F &= (FLAG_Z_ON | FLAG_C_ON);

// Machine cycles used is dependant on opcode.
if (opcode == 0x3E)
cycles += 4;
else
cycles += 2;
}


If you can't understand the variables, I'll explain them.

[zenogais]

Well here's a summary of my progress so far:


Full Z80 emulation - only partially tested.
Partially Finished GUI.
Partial Video Support.


Right now I've been very busy since I've gone back to school. I'm taking one Advanced Placement course (AP English) as well as a college-prep algebra II class, so I've been kinda swamped with homework thus far. When I do find some time to work on it, I'll probably work on cleaning up the CPU emulation core. I was also playing around with some stuff involving the "Observer" pattern in order to pass data between the various components i.e. Video, Sound, and CPU/Memory. I'm just looking forward to trying out some cool new ideas for this project, but first I want to clean it up. 'll get back to you guys when I have a chance to work on it.

[aprentice]

I was also playing around with some stuff involving the "Observer" pattern in order to pass data between the various components i.e. Video, Sound, and CPU/Memory. I'm just looking forward to trying out some cool new ideas for this project, but first I want to clean it up. 'll get back to you guys when I have a chance to work on it.

What exactly is the "observer" pattern you speak of? I'm into doing things that haven't been done before. In my CPU i deployed a feature that hasn't been implemented in any gameboy emu, which so far produced amazing results. I'll explain in detail once i finalize my work :P

[bcrew1375]

Hmm, I compared the shift instructions between the current version of my emu and a backup. The backup uses some older code. The shift instructions are the same, yet the current version screws some things up, like text, and the backup version doesn't. Considering both are using the same shifting instructions, I highly doubt they are the problem :P. I'm now going through the code of both to see what is different, and what is the same. It'll be a pain, but hopefully I can squash this annoying bug, or bugs.

[aprentice]

Well, I don't know if there is a problem with them or not, but here they are:


void z80_SLA_reg8(unsigned char *reg)


If you can't understand the variables, I'll explain them.

Did you check to make sure the flags are getting reset like they should?

and change if (*reg & 0x80) to if(reg & 0x80) because reg is already pointing at an address

[GbaGuy]

Did you check to make sure the flags are getting reset like they should?

and change if (*reg & 0x80) to if(reg & 0x80) because reg is already pointing at an address

But the code is supposed to & 0x80 with the value, not the address, so
you need the dereference, right? Or have I totally confused myself?

[bcrew1375]

I can be sure *reg is properly addressing. I am almost positive that the shift instructions are not the problem.

[zenogais]

What exactly is the "observer" pattern you speak of? I'm into doing things that haven't been done before. In my CPU i deployed a feature that hasn't been implemented in any gameboy emu, which so far produced amazing results. I'll explain in detail once i finalize my work :P

Booble (http://www.booble.com)...err I mean Google (http://www.google.com) is your friend on that one. Once I get an example up and running though then I'll show you what I'm talking about. It seems like a good concept right now, and I've got a couple other similar alternatives if it doesn't pan out in the long run. Not to mention I'm working on a few things for NeoPSX, which I might incorporate into NeoGameboy, that I've never seen emulators with or just never heard of an emulator using.

[aprentice]

But the code is supposed to & 0x80 with the value, not the address, so
you need the dereference, right? Or have I totally confused myself?

reg is already a pointer, pointing at the original memory in data, so you don't need to dereference :P

[GbaGuy]

"Do you listen to yourself talk?" - Brian
"I drift in and out..." - Peter

I guess I'll be quite now, carry on. :)

[glVertex3f]

Oh, I love family guy.

With that being said...
I think its safe to say I'm just not ready to continue on this project.

It is definately something I'll look forward to coming back to, but I'm afraid I would only hurt myself and my relationship with C++ if I continue this now.

I think I will either go back and do another Chip8 emu or program a few other programs.

Maybe I'll make a Chip8 emu that uses gfx plug-ins... lol

I might drop in and out of the board if I get the urge to drap a funny, or ask a stupid question. :whistling

Thanks for all of your help..
If I do another Chip8 emu Im sure I'll post it here :bye3:

[bcrew1375]

I didn't think you were ready for it yet. Don't worry, I went through the same phase. I got almost all of the CPU programmed for my Gameboy emulator and just couldn't grasp certain concepts. I came back to it after programming my Chip-8 interpreter, and for some odd reason everything started to make sense then :P.

[bcrew1375]

I didn't think you were ready for it yet. Don't worry, I went through the same phase. I got almost all of the CPU programmed for my Gameboy emulator and just couldn't grasp certain concepts. I came back to it after programming my Chip-8 interpreter, and for some odd reason everything started to make sense then :P.

[bcrew1375]

I didn't think you were ready for it yet. Don't worry, I went through the same phase. I got almost all of the CPU programmed for my Gameboy emulator and just couldn't grasp certain concepts. I came back to it after programming my Chip-8 interpreter, and for some odd reason everything started to make sense then :P.

[bcrew1375]

I didn't think you were ready for it yet. Don't worry, I went through the same phase. I got almost all of the CPU programmed for my Gameboy emulator and just couldn't grasp certain concepts. I came back to it after programming my Chip-8 interpreter, and for some odd reason everything started to make sense then :P.

[glVertex3f]

Yes, the first step is admiting your not ready. :P

[aprentice]

Only worked on the emu a few hours in the past week or so, times run short now that university has begun, but I will try to find time here and there :P

Heres some screens :P

http://www.darkengine.net/gb/zeldadx.gif
http://www.darkengine.net/gb/tetrisdx.gif