Game Boy

[bcrew1375]

I thought that myself, but I tried decrementing after, and it breaks alot of games. I also checked it against three other emulators with good compatibility, they all decrement first.

[Soccr743]

So they do all decrement the stack pointer before writing to the memory... That is very strange. Thanks for the info on that. I would have never even thought it would turn out that way, ever.

-----Soccr743-----

[bcrew1375]

Hmm, I'm curious about something... aprentice or DarkStalker, could you tell me what cycle timings you are using? Also, when you do conditional instructions, does the amount of cycles change depending on whether the condition is true or not?

[Soccr743]

"Does the amount of cycles change depending on whether the condition is true or not?"

The processor in the Gameboy has to check if the condition is true. So, I think the cycles are still added on even if the condition proves to be false.

-----Soccr743-----

[Pontifice]

I think conditional RETs have different cycle length if it is done or not ( writing in the stack or not) and the same for conditional CALLs.

With conditional JRs i'm not sure because Z80 could read the displacement before checking the condition, but why some designer will lost time doing nothing when speed was ( is ) so important at that level.

[Soccr743]

I checked the Gameboy PDF that I got from a zip in this post, and it says that there are 12 cpu cycles used for CALL nn and also for CALL cc,nn. So infact the cycles stay the same even when a condition check is required.

The same goes for RET and JR as well.

-----Soccr743----

[aprentice]

Hmm, I'm curious about something... aprentice or DarkStalker, could you tell me what cycle timings you are using? Also, when you do conditional instructions, does the amount of cycles change depending on whether the condition is true or not?

the cycles are different if the condition is true, i used all my cycle timing from the pan docs :P

[Soccr743]

aprentice, would you mind posting what those numbers are. The pdf I have says nothing about it being different if depending on how the condition turns out... :plain:

-----Soccr743-----

[bcrew1375]

Look here: http://www.work.de/nocash/pandocs.htm#cpuinstructionset

[ShizZy]

:blush: I've been using a much more outdated version of these docs all allong.

[Soccr743]

This would have been helpful to have when I started out. Now to recode some of the processor that was wrong...

bcrew1375, thanks for posting that :happy:

-----Soccr743-----

[bcrew1375]

Sure, but I think aprentice also posted a link to it a while back :P.

[Dark Stalker]

I have a request to those who have working emus, it would be cool if you guys would make occassional releases (executable releases) just so those of use who don't have working emu's yet can check out your progress.
In case anyone's still interested, I've decided to make a sort of binary-only "technical preview" release. There's absolutely no usability features whatsoever. In other words, no gui, configuration, or speed-syncing (simply because I've not cared to implement any of those yet). If you want to enjoy playing games, this isn't for you. The compatibility has gotten quite good by now, if I may say so myself :P. Still no sound though. As for speed, the emu is currently slow, but it should be fast enough to run a few times faster than the real GB on a modern PC. I mean to remedy this later of course.

The emu doesn't really have a name yet, but it's been dubbed "lameboy" during development.

The win32 version is really ugly btw., since it's a direct, violent, unfitting port of the command-line linux version. To use it, just "drag and drop" a romfile onto the lameboy.exe icon, or associate the gb-filetype with lameboy.exe, or just pass the romfile as a parameter to lameboy.exe (using cmd, run, or a shortcut).

For the linux version you need to have libsdl>=1.2 installed (should be in your distros package-repository). To use it, just give the romfile as a parameter to lameboy (./lameboy <romfile>). The linux version has been compiled with two different versions of g++ for compatibility with libstdc++.so.5.

edit:
Just thought I might mention the keyboard controls:
Return = Start
Right Shift = Select
Key 'D' = Button A
Key 'C' = Button B




Download links: Lameboy win32 (http://home.tussa.com/iaamaas/lameboy/lameboy-0.7.0_win32.zip)
Lameboy linux (compiled with g++-3.4 for x86) (http://home.tussa.com/iaamaas/lameboy/lameboy-0.7.0_linux-g++-3.4.tar.gz)
Lameboy linux (compiled with g++-3.3 for x86) (http://home.tussa.com/iaamaas/lameboy/lameboy-0.7.0_linux-g++-3.3.tar.gz)

[smcd]

Nice work, Dark Stalker. I tried the windows version and aside from it playing too quickly and having no sound, it ran Castlevania II Belmont's Revenge perfectly :)

[ShizZy]

Nice, Dark Stalker.

@bcrew, I was just checking some things and spotted an error in your code. On SLA, you're reseting flags Z and C, when you should be reseting H and N. I'm sure it's just a typo, but just thought I'd point it out if you havn't corrected it yet. (Not that it'd make a whole hell of a difference anyways)

Anyways, a few more things I want to tack on, and I'll post my current cpu source tonight. Timings and interrupts are pretty much nonexistent, but other than that I have a good chunk of coding done.

[bcrew1375]

Not exactly. I'm ANDing the flags register with FLAG_Z_ON and FLAG_C_ON, which are the values 0x80 and 0x10, respectively. So, I'm turning off flags H and N(That actually could make a big difference depending on the game. Thanks for that, though :P. That source is pretty outdated, I've made quite a few changes since then. There's a bug in the LY register updating that I can't seem to fish out. I'm almost certain it has to do with incorrect timing. Could someone run a test on Earthworm Jim for me? I need to know the value of the Program Counter when LY goes from 0 to 1 for the first time. Anyway, here's the updated source. I haven't really checked it... at all. So, it might have some really messed up stuff in it.

[ShizZy]

Ahhh...

Okay, here's my current CPU source. Any feedback appreciated. I know my rotates and shifts are really baddly off, I'm not really doing anything to the carry at all. At the moment, I'm just coding to get something to run... then I'll fix things. :P

[bcrew1375]

Shizzie, looks good so far. I saw a few problems, but I'm sure you'll find them.


Could someone run a test on Earthworm Jim for me? I need to know the value of the Program Counter when LY goes from 0 to 1 for the first time.

Please, anyone? I can't seem to find an emu that let's me do this sort of test and get the data I need.

[aprentice]

Shizzie, looks good so far. I saw a few problems, but I'm sure you'll find them.



Please, anyone? I can't seem to find an emu that let's me do this sort of test and get the data I need.

I'm not sure if this is correct but i guess it goes to 1 at pc 0x3ac3, but before it did that for me, it ran a few frames with the lcdc screen off so ly stayed at 0 for awhile, and ly starts at 144 on boot. hope this helps

[bcrew1375]

Yes, it helped a great deal, thank you very much! With that information, I solved my Earthworm Jim and Super Mario Land 2 problems! :happy: SML2 freezes before the first level at the moment, but that should be nothing now that I solved that problem(Which I'd rather not mention, as it's pretty embarassing :blush:.) Once again, thank you, aprentice. That's been a plague on me for weeks!

[aprentice]

Yes, it helped a great deal, thank you very much! With that information, I solved my Earthworm Jim and Super Mario Land 2 problems! :happy: SML2 freezes before the first level at the moment, but that should be nothing now that I solved that problem(Which I'd rather not mention, as it's pretty embarassing :blush:.) Once again, thank you, aprentice. That's been a plague on me for weeks!

no problem, glad i could help :)

[ShizZy]

Thanks for checking it over bcrew. One little error which I noticed was that my 8bit registers weren't even pointing to the 16bit ones :blush: That could cause a problem.

Anyways, fixed that. Finished my interpreter (well, I'm sure it only half works... but hopefully enough of it is right to run something). Interrupts should be mostly set. Last thing before I test it is finishing the timings, and doing the scanline drawing.

Anyone have any tips or good documents for these? I havn't really quite grasped the concept of getting and displaying images from the rom, this is one of the things which gave me a lot of trouble with my chip8 emu.


Big thanks-

[bcrew1375]

Okay, drawing can be a little confusing. Each 8x8 tile is 16 bytes(2-bit color encoding). Okay, first you need to get a tile number from the Tile Map Table(0x9800 or 0x9C00). You then use that tile number as an offset from the tile data table at either 0x8000 or 0x8800(0x8000 is 0 to 255, 0x8800 is -127 to 128). Make the tile number unsigned or signed depending on the Tile Data Table location, then multiply the number by 16 and add it to the Tile Data Table address(example: tile number is 240. 0x8000 + (240 * 16) = 0x8F00). Each line of the tile is made up of 2 bytes. You take the bits in the first byte and add them with the bits in the second byte. If a bit in the first byte is on, it is 1. If a bit is on in the second byte is on, it is 2. So, if bit 0 of byte 1 is on, and bit 0 of byte 2 is off, the value is 1. If bit 0 of byte 1 is off, and bit 0 of byte 2 is on, the value is 2. If both are on, it's 3. This value is used with the BGP I/O register. If it 3, the color is gotten from bits 6-7. If it is 2, bits 4-5. 1 is bits 2-3. 0 is bits 0-1. The value you get(0-3) determines the color to draw. 0 is white, 1 is light grey, 2 is dark grey, and 3 is black. Hope that was clear :P That should be everything you need to know starting out.

[ShizZy]

That's a mouthful :bouncy: Thank you though - that makes a whole lot more sense now. And things like whether to use the 0x8000 or the 0x8800 location or what size the sprite is can be gotten from the bits of the LCDC, correct? Does all of this also apply the same for backgrounds? Thanks!

[bcrew1375]

ShizZie: Yes and yes.

Dark Stalker: I tried lameboy out. I notice that the Win32 version is horribly slow(as in, won't run full speed on a 2.0 GHz.) whenever dealing with sprites. The Super Mario Land 2 map or just about any part of Zelda: Link's Awakening are good examples.

I noticed that Dark Stalker and my emulator run the Interrupts Demo the same, but it's different than NO$GMB or VisualBoy Advance. How about you aprentice, what does the Interrupt Demo look like?

[aprentice]

ShizZie: Yes and yes.

Dark Stalker: I tried lameboy out. I notice that the Win32 version is horribly slow(as in, won't run full speed on a 2.0 GHz.) whenever dealing with sprites. The Super Mario Land 2 map or just about any part of Zelda: Link's Awakening are good examples.

I noticed that Dark Stalker and my emulator run the Interrupts Demo the same, but it's different than NO$GMB or VisualBoy Advance. How about you aprentice, what does the Interrupt Demo look like?

it looks exactly like the vba one except mine has the garbage on the bottom of the screen too and not only the top...

[Dark Stalker]

Dark Stalker: I tried lameboy out. I notice that the Win32 version is horribly slow(as in, won't run full speed on a 2.0 GHz.) whenever dealing with sprites. The Super Mario Land 2 map or just about any part of Zelda: Link's Awakening are good examples.That seems a bit strange, but I've only tested it in vmware actually (and it seemed to run 3-4 times normal speed in GBC-games iirc). I've actually never experienced any notable slowdown related to sprites in any version. You could try running it with 16-bit colours. Anyway, the upcoming release will likely improve on this, and more at that...


I'm not sure if this is correct but i guess it goes to 1 at pc 0x3ac3, but before it did that for me, it ran a few frames with the lcdc screen off so ly stayed at 0 for awhile, and ly starts at 144 on boot. hope this helpsThis reminds me that I forgot to mention that I was wrong about not setting modes while the screen is disabled. You are actually supposed to set them, as you would for a normal non-vblank line it seems. Bubsy 2 won't run if you fail to do this.

[HyperHacker]

The slowdown might be due to hardware incompatibility or system settings. For example, it might not be able to do whatever it would normally do for video and have to use a slower method instead. (Ever try using SetPixel? Slooooooow. :p)

[aprentice]

This reminds me that I forgot to mention that I was wrong about not setting modes while the screen is disabled. You are actually supposed to set them, as you would for a normal non-vblank line it seems. Bubsy 2 won't run if you fail to do this.

So whats the difference between screen mode on and off besides the screen being actually off? Got any other secrets you hiding as well? :P

[Dark Stalker]

Like you said LY stays at 0, and there's no LYC of course. As for secrets, there's way too many to list them all :P

Any specific game(s) you've got problems with?

[ShizZy]

My core is done :) Well, done *enough*. I still don't have cartridges coded, and my memory write function is little more than "memory[address]=value;", but technically, it should be enough to boot a few simple demos, I'd imagine. So now I'm nitpicking and trying to find our where all my typos are, based on how badly it loads the roms. None have worked yet, but I'm getting the first good chunk of opcodes right, so I'm assuming it's only a matter of time before I fix enough things for something to give me some results.

Edit: I'm getting very excited. Just fixed another major error, and now I'm getting through many many more opcodes properly :phone:

[bcrew1375]

Congratulations, ShizZie! I remember getting very excited when I saw my first demo. I couldn't believe I'd actually made it work! :happy: In case you're interested, the first one to show anything for me was "Big Scroller Demo."

[HyperHacker]

Am I the only one whose first game to run was commercial? :p (Tetris; not the first to actually run, but the first to properly display graphics. One attempt after the first to display any sort of recognizeable graphics, which was also Tetris but with lines on the screen.)

I oughta start working on this again. <_<

[aprentice]

Am I the only one whose first game to run was commercial? :p (Tetris; not the first to actually run, but the first to properly display graphics. One attempt after the first to display any sort of recognizeable graphics, which was also Tetris but with lines on the screen.)

I oughta start working on this again. <_<

no, if you've actually read this whole thread (and i really doubt you did) you'd notice i got super mario land running as my first game :P

[bcrew1375]

Yeah, that's because aprentice was afraid of the Gameboy's graphics :P. I solved a few more bugs, including a major input bug. That seems to be the cause of the distorted SGB graphics, so most games no longer have that. Though, they still show up in Donkey Kong for some strange reason. Right now I seem to have a bug in the LYC. Certain things in games(like status bars) are getting offset by 1 pixel.

[ShizZy]

:) Thanks bcrew. I think I'm getting closer and closer... I can almost feel victory :-D Just found a really stupid error. I didn't realize there was a difference beween x++ and X+=1. I'm guessing one of them only increments a single byte, while the other increments both bytes for a 2byte variable? By changing all my increments and decrements to -= and += instead, it seemed to make a big difference.

Cheers... and hopefully I'll have a screenshot soon :)

[HyperHacker]

Odd... x++ and x += 1 should do exactly the same. I can see how the compiler might assemble them as 'inc x' and 'add x,1' (or whatever the x86 has for that), but I would think it would optimize 'add x,1' into 'inc x' anyway. O_o

Of course, in the case of x *= whatever, it could be a matter of not having spaces between x and *, since x* is a pointer... Doesn't sound like that's what you're working with though.

[bcrew1375]

Hmm, I think I'm missing something here. My LYC check isn't working unless I do it before LY is incremented. Is it supposed to work like that? It screws things up if I do it right after LY is incremented.

[bcrew1375]

Edit: Um, this post was intended for ShizZie. How it got above his when he had already posted I may never know :huh:. The time of my post is even earlier than his! Did I just see into the future? :huh:

Hex Workshop will compare files byte-by-byte.

Have you implemented the V-Blank yet? If so, are you turning on and off the bits in the IF register? Are you properly incrementing the LY register? You should be able to get SOMETHING just having those things and the opcodes programmed. Not to question your programming skills, but are you sure the graphics routines are being called properly, and being given the correct arguments :P.

[ShizZy]

Hmmm... still stuck with a blank screen. I think I'm getting there, but error checking is starting to get very tedious. Just spent about an hour fixing things, and yet I think I've created more errors :blush:

Does anyone know of any programs that compare files? Finding errors that are hidden within thousands of lines of spit out logs is like trying to find a needle in a hay stack :plain:

[HyperHacker]

What I did when I couldn't see any video output was to hack the drawing code to draw whatever was in VRAM instead, that way I could at least verify the drawing routines worked and the game had loaded some graphics.

[ShizZy]

Thanks guys! Ladies and Gentlemen, I think he's done it! :party:
Ahh.. so maybe it isn't much, but it's something! Finally I get video :bouncy: Sure made my day. (Big Scroller Demo btw, and everything else still crashes hahaha)

I'm currently stumped on a problem with my f0 opcode, which would be LDH an immediate to A. I've double and triple checked my code, and I'm sure that it's right. What it is doing is setting AF to 0x4440 in the Big Scroller Demo, when it should be setting it to 0x4040 - which leads me to believe that somewhere else I am setting A wrong, or somewhere else I'm not setting A at all... which is puzzling. Here's my LDH code:



void Interpreter::z80_LDH_A_n8()
{
/* load reg.A with mem at address 0xFF00+immediate */
reg.A=mem.memory[0xFF00+mem.memory[reg.PC++]];

/* add the cycles */
cpu.cycles+=4;
}
Any suggestions? Thanks!

Cheers!

[bcrew1375]

Congratulations! :bouncy: Sure is a mess, but it's a start! :happy: Heh, Big Scroller Demo was the first to show anything for me as well. I got the background blocks, but they weren't swaying, they were just sitting there, doing nothing :P. Give yourself a pat on the back(if you haven't already), things become alot more fun now :).

Of course there's nothing wrong with the 0xF0 opcode. You've been checking the wrong thing for errors. :P You're loading A with the values of the memory area from 0xFF00 to 0xFFFF, right? If A contains an incorrect value, you're probably not handling the I/O registers correctly. Find out what address it's loading the data from, and check over the code that's handling that address.

[aprentice]

Thanks guys! Ladies and Gentlemen, I think he's done it! :party:
Ahh.. so maybe it isn't much, but it's something! Finally I get video :bouncy: Sure made my day. (Big Scroller Demo btw, and everything else still crashes hahaha)

I'm currently stumped on a problem with my f0 opcode, which would be LDH an immediate to A. I've double and triple checked my code, and I'm sure that it's right. What it is doing is setting AF to 0x4440 in the Big Scroller Demo, when it should be setting it to 0x4040 - which leads me to believe that somewhere else I am setting A wrong, or somewhere else I'm not setting A at all... which is puzzling. Here's my LDH code:



void Interpreter::z80_LDH_A_n8()
{
/* load reg.A with mem at address 0xFF00+immediate */
reg.A=mem.memory[0xFF00+mem.memory[reg.PC++]];

/* add the cycles */
cpu.cycles+=4;
}
Any suggestions? Thanks!

Cheers!

looks fine to me, what memory location in 0xFF00 are you talking about?

[ShizZy]

Thanks guys!

things become alot more fun nowI hope you mean that in a good way :happy: Somewhere I'm setting that address in high ram to a wrong value before loading it into AF, so as long as I pinpoint that spot things should work out. I'm going to work through it some more tomarrow.

[bcrew1375]

If you want, post the address and the code you're using to handle it, and maybe we could help.

[ChaosBlade]

Nice to see you advance aswell, ShizZie :)

Status update on the rest of our coders ? im interested to see how far did people go :)

[ShizZy]

Thanks ChaosBlade :) I'm curious to see where Zenogais is going with his...

Right off the bat my high-ram is completelly empty... that could be a problem :blush:

Edit: Nevermind, that's not it...

[ShizZy]

Okay, here's what's happening. AF = 0xA40, and memory at address 0xFFF0 is currenty 0. Register A is being set to memory[0xFFF0], and now AF = 0x4440. And like I said, it should be being set to 0x4040. What's going on here?

[bcrew1375]

Okay, Big Scroller Demo never tries to load the contents of 0xFFF0 into A for me. What is the Program Counter when this happens? That might help.

[ShizZy]

It's F0, so it's basically saying that memory[0xf0] = 0xf0, which is coincidentially odd. (because of the syntax of my LDH call)

[bcrew1375]

Are you sure the Program Counter is 0xF0? It never goes there for me. I'm asking for the value of the Program Counter register. Not the data in memory at the Program Counter's address. Also, if you think there's something wrong with one of the instructions, you could post the source and let us see if we can find a problem.

[ShizZy]

Thanks for the tips bcrew... I'm going to take a further look at it tomarrow.

I've attached my current cpu source. If anyone can point out any mistakes that would cause these bugs for me, I'd very much appreciate it. Thanks!

[bcrew1375]

Hmm, I don't see anything horribly wrong. I see a few things left out, but you probably just haven't gotten to those yet. I'll look over it a bit more. By the way, it looks like your code might have been inspired by mine a bit. I don't mind you using it, but I consider it slow, sloppy, and it is probably still riddled with bugs :P.

[ShizZy]

I know, some of it is. I took a look at some of yours to see how some things were done that I was unsure about until I saw how it worked, and then I was planning on optimizing/recoding a lot of them.

[zenogais]

Hey all, been a while. I've been extremely extremely busy as this school year winds down it seems like my plate is constantly full :blush: I've been trying to work on NeoGameBoy, but progress is pretty slow @ the minute. I managed to get executables loading, and to play around with a few other things but nothing concrete as I haven't had the time.

I've also been screening various GUI libraries, I've decided after do some tests with a few libraries, namely FLTK (http://www.fltk.org), wxWidgets (http://wxwindows.sourceforge.net), and win32gui (http://www.torjo.com/win32gui/). I finally decided on win32gui, because the design was much more thought-out than any of the others and the author actually took the time to eliminate common GUI design problems like graphical controls, its simple to use, and unlike wxWidgets, which is basically cross-platform MFC, it actually increases my productivity significantly, we're talking ~20 lines of code to get a window with a small menu and menu event handlers working.

Back to NeoGameBoy, I'm having a problem understanding the video system, so I've been looking at the sources of a few other emu (cheating, I know) and checking what I find with the docs to increase my understanding. I want to get this working, but it'll take me some time. Hope to be back into developing once things really wind down, nice to see you progress Shizzie :)

EDIT: btw Shizzie, my real name is Eric too :P

[HyperHacker]

Hah, mine too. Freaky huh?

[bcrew1375]

Wow, all three of you are named Eric? :huh: Freaky. My name is Ben. :P

[HyperHacker]

Oh sure, break the chain why don't you. ;)

[bcrew1375]

Okay, I admit it. I lied. My name is Eric :P. I just THOUGHT it was Ben :happy:.

[ShizZy]

Heheheh... that's really freaky. Anyways, I'm still stuck, but I've promised myself that I'd get it fixed by sunday night. We'll see how it goes :P

[ShizZy]

3a.m.... I made it a point to not get any sleep until I had fixed it. Well, I'm not sure if I did fix it, but I practically gutted the whole damn thing, and progress has been made! While it still looks the same, it no longer crashes with the first frame - all the little thingies are waving around the screen such like the nature of the big scroller demo. It appears to stay in the loop. I also noticed that I had never finished my RST op - which was probably one of my largest problems.

I can feel it guys, victory is on it's edge :icecream:

Anyways, time for sleep :yawn: I'll get it tomarrow, I've got my "game" face on :term:

[ChaosBlade]

Sleep comes before victory, dont wear yourself out :p

[bcrew1375]

Improved my drawing routine a bit. Unfortunately, something is making it screw up a handful of games, but it has otherwise worked great :P. It now runs a tad bit faster than Dark Stalker's old lameboy executable :happy:. May not be much improvement, but at least I've gained a bit of speed. Now I've got to figure out what's keeping the other games from working :/.

[aprentice]

screw it, i'll post an executable of my emu here for you guys to check out, its nothing special and the debugger is grayed out cause its incomplete but whatever... if you want to unleash the fury, turn off vsync lol...hopefully it will motivate a few of you guys to show off your work as well :P

edit: btw, save states arent fully implamented, i gotta stop slacking and actually finish it lol..

[HyperHacker]

Bah! I lost part of my source in a hard drive crash. Of course the only files corrupted (completely destroyed) were the main CPU core and its backup, all the rest of the code (the parts that are small and easy to re-do) are fine. :ranting: Figures.

[ChaosBlade]

Damn, that sucks. Sorry to hear that, Hyper :\

[bcrew1375]

screw it, i'll post an executable of my emu here for you guys to check out, its nothing special and the debugger is grayed out cause its incomplete but whatever... if you want to unleash the fury, turn off vsync lol...hopefully it will motivate a few of you guys to show off your work as well :P

edit: btw, save states arent fully implamented, i gotta stop slacking and actually finish it lol..

Nice speed. For some reason, the first time I tried a game(Legend of Zelda), the speed went at an insane FPS of over 500. The second time I ran it, it ran around the same speed as mine. Any idea? Also, you probably already know, but I've noticed two cases in games where sprites do not show up. A Boy And His Blob and Earthworm Jim.

BTW, thanks for the shout in the credits :P. (That is referring to me, right?) :plain:

[HyperHacker]

It might be video-related... My first really crappy video implementation caused a nearly 2000% slowdown. :p For sprites, you'd want to see if the game is loading anything into OAM, and if not, why not.

[bcrew1375]

Could be. I sped alot of my stuff up simply by doing shifts instead of multiplying. That especially helped my video routine. I also did conditional drawing(which is what is causing problems with games at the moment. I still haven't figured out why.).

[aprentice]

oh i already know about sprites not showing in some games, if i disable the ability to hide sprites it will show in the game, cause the sprites ARE in oam memory, somethings just being all wierd, i dont know whats causing the sprites to stay hidden in some games.. about the slowdown on running it the second time, it doesn't happen for me, it always runs 500+ fps no matter how many times i run it in a row.. but i do think my video code is a bottle neck, video isnt exactly my forte.. and yeah your in the credits bccrew lol, if i missed anyone don't fret, i rushed the about window and everyone will be in it lol..

[bcrew1375]

If your video is a bottleneck, I hate to see the speed with a good video routine :P. I wonder if the massive speed your's has over mine is because I'm using SDL? You're using DirectX, right?

[aprentice]

If your video is a bottleneck, I hate to see the speed with a good video routine :P. I wonder if the massive speed your's has over mine is because I'm using SDL? You're using DirectX, right?

no, its cause i spent 2 weeks optimizing my cpu core lol, lets just say one example is my compare opcode is only 1 line of C code (compiles to 4 lines of asm) >:P

it definately helps that my cpu core doesnt calculate flags :P


edit: also my memory system runs on a jump table and so does my cpu core, my video routine is definately not optimized much at all, i lose a lot of speed in it..

[ShizZy]

I did some debugging this weekend :P

In order... Big Scroller demo, "Test" demo, and RNC Calculator.. I'm surprised because BSD runs fairly well... almost as it should, yet nothing else does. These are the only games to give me results so far. Getting there though :)

[aprentice]

I did some debugging this weekend :P

In order... Big Scroller demo, "Test" demo, and RNC Calculator.. I'm surprised because BSD runs fairly well... almost as it should, yet nothing else does. These are the only games to give me results so far. Getting there though :)

congrats, looking good, you're getting there.

[bcrew1375]

no, its cause i spent 2 weeks optimizing my cpu core lol, lets just say one example is my compare opcode is only 1 line of C code (compiles to 4 lines of asm) >:P

it definately helps that my cpu core doesnt calculate flags :P

How did you bypass calculating flags? And how did you make a compare opcode with only 1 line? :huh:

BTW, added an FPS limit option... finally :P. Also, congrats Shiz.

[HyperHacker]

Multiple statements on one line. I could make an entire emulator on one line if I was crazy enough. ;)

[ShizZy]

Thanks guys. Spent another few hours coding, though little progress has been made :P Added a ReadByte function and implemented it in all my ops per suggestion of ren, but I've yet to give it any more functionality than it previouselly had. :P Also found a silly error in my MBC1 code. Instead of if(rom.type==0x02||rom.type==0x03){//code here//}, I had if(rom.type!=0x02&&rom.type!=0x03){//code here//}. No wonder no MBC1 games didn't work :blush: Then again, they still don't ^^

Anyways, I'll squeeze some more work in on tomarrow, and post if I make anything to be proud of. Unfortunetly I have school tomarrow, spring break is over :yucky:

[aprentice]

Multiple statements on one line. I could make an entire emulator on one line if I was crazy enough. ;)

yes but i did say it compiled to 4 lines of asm code :P
I'll fill you guys in on what I did when its 100% complete, right now I still might change some stuff around :P

[ShizZy]

Could someone give me a brief overview of what should go on in the readbyte function, and any specific things that I should take into consideration? (besides just return memory[address], of course). Thanks!

[Dark Stalker]

yes but i did say it compiled to 4 lines of asm code :P
I'll fill you guys in on what I did when its 100% complete, right now I still might change some stuff around :PThat would be really nice. I just tried your emu, and it's really intriguing seeing those sprites fly by at 1000fps on an old GeForce 1 DDR (of course the cpu matters a lot in these kinds of situations, but still). Impressively done!

[Dark Stalker]

I planned to release this weeks ago, but everything has been happening all at once lately so I've been hard pressed on time.

Anyway, here it is:

SinGB 0.8.3
(recursive acronym for "SinGB is no Game Boy")

Some of What's New:
- GUI in fltk (http://www.fltk.org).
- Video Mode configuration.
- Internal video engine abstraction.
- OpenGL support.
- Video YUV-scaling support.
- Custom software scaler.
- Frame limiting.
- Turbo-key (TAB).
- Pause, continue and reset support.
- Config-file, storing preferences.
- Optional "30hz" mode for slow computers.
- Workarounds for Windows-weirdnesses.
- Workarounds for Konqueror, Nautilus etc. habits wrt to executables.
- Some cleanups and minor optimizations.
- Abstraction and modularity so that I can build SinGB as a library with optional front-ends.
- An überhot "I'm just here to fill space" logo :P
- Preliminary readme.


Downloads:
SinGB-0.8.3-win32 (http://home.tussa.com/iaamaas/SinGB/SinGB-0.8.3-win32.zip) 475.8kB.
SinGB-0.8.3-linux (http://home.tussa.com/iaamaas/SinGB/SinGB-0.8.3-linux.tar.gz) 265.6kB.

[ChaosBlade]

Thats Amazing, DarkStalker, Good job ^_^

(Now go make us an XBOX360\PS3\Revolution All-In-One Emulator.)

[bcrew1375]

Added an option to change the screen size from 1 to 4 times normal size. I also improved my drawing routine a bit more by drawing the colors directly rather than using a switch statement. At 1x size with Zelda, I now get about 350-400 FPS :happy:. For some reason, if I goto 2x size, I get a significant slowdown to about 200 FPS.

aprentice, your emulator must have some serious issues with my comp. It starts out running Zelda at 500+ FPS and now it won't even run Donkey Kong full speed!

Now it's running fine. What the crap!? :huh: My computer hasn't had any load either!

[aprentice]

At 1x size with Zelda, I now get about 350-400 FPS :happy:. For some reason, if I goto 2x size, I get a significant slowdown to about 200 FPS.


Thats normal, in my emu at 2x it runs at 500fps but at 4x it runs like half of that :P



aprentice, your emulator must have some serious issues with my comp. It starts out running Zelda at 500+ FPS and now it won't even run Donkey Kong full speed!

Can't be a problem with my emu, it runs fine here and everyone who tested it hasn't had any problems with speed either :P

[bcrew1375]

Yeah, it has issues with my computer. Your emu doesn't like it :P.

Hmm, seems like the bounce interrupt is keeping A Boy And His Blob from getting past the title screen.

[Dark Stalker]

Just a comment wrt SDL, drawing, etc.

AFAIK SDL in general isn't hardware accelerated (although you can get direct fb access in fullscreen if the system allows it). This doesn't matter for "putting pixels" though, since writing to fb through the agp bus is usually slower anyway, as I understand it. What you can do with OpenGL (and probably Direct3d too), is make the graphics card do the scaling for you. I archieved this by drawing my graphics to a texture and scaling it onto a quad in OpenGL. The loss in performance is neglible when scaling to 640x480 on a GeForce 1 DDR, and not that significant at twice that resolution when the bandwith starts to be limiting. More recent cards are probably much faster too.

You can, however, get a somewhat fast scaling in SDL by using "YUV overlays". Many graphics drivers accelerate this (probably intended for scaling movies which often use YUV colour formats), and SDL also has an mmx fallback which seems to be quite a bit faster than plain software scaling. To make use of this, you need to convert the Game Boy's RGB colours to YUV which can be a bit tricky. I'm not sure why SDL doesn't provide faster routines for scaling RGB surfaces, but I think it's planned. I'm sure Microsoft's drawing APIs provide ways to do fast scaling.

[bcrew1375]

aprentice, about the flags calculating. Are you using some sort of flag table?

[HyperHacker]

Hmm, bit of a problem here. I re-did the CPU core and such, and it's all working good again. Thing is, the input's kinda laggy. For speed reasons I have a second thread which does nothing but process the window messages (couldn't get it running fast otherwise). When a key is pressed, it sets the corresponding bit, when released it clears the bit. Now, since 4x speed makes some games a bit difficult, I added a speed limiter. If it exceeds 60 frames per second it just sleeps off the remaining time. The problem is while it's in this delay loop (the standard Windows Sleep() function) it misses keys being pressed and thus many of them aren't processed... Any idea what I should do to fix that?

[smcd]

instead of sleeping do a "busy waiting" delay by doing the (get tick count - time ) < some_wait_length and in the loop call PeekMessage to look for input?

[HyperHacker]

No, it's still doing it, although that does get rather decent speed with a single thread. And that reminds me, I need to kill the keyboard repeat effect too.

[ShizZy]

@HyperHacker, what's the compatability of your emu? Got any shots? How long have you been working on it? I havn't heard much about it, curious.

[bcrew1375]

The repeat? Should that matter to the game? Don't most games check to see if a key is being held down?

Is the lag on Window's part or the emu's?

Also, this may be a dumb question, but are you doing the delay only after the 60 frames have ran? If so, you should be doing the delay after each frame.

[HyperHacker]

Yeah, that's how I did it... How exactly would I do it between frames? As for the repeat, it actually seems to have fixed itself. O_o It was a problem though, because Windows would actually send WM_KEYUP and WM_KEYDOWN messages making the emulator think you were mashing the button.

Compatibility sucks right now given that it doesn't support any MBCs and still has some CPU bugs. ;) It runs Tetris up to the title screen and most of a test ROM I made (which if I ever get around to finishing I'll release :ermm: ). No sprite support (well it's there, just not working) but I did implement most of the I/O regs, video scrolling, the window, and OAM DMA (even though sprites don't show up yet :P).

As for screenshots, not much to show but:

1) Old CPU core running Tetris. This was the very first real video output. I fixed the lines in the picture immediately after. :P

2) Current build with the test ROM. Colours sucking right now, yay Windows GDI. Gets ~300%, though it can get up to 1200 using BitBlt to draw. :)

[bcrew1375]

The way I did it, after the CPURunning "while" loop, I have a variable get the current number of milliseconds. In another "while" loop, right after getting the milliseconds, I run the amount of cycles in 1/60th of a second (Machine Speed(1048576 HZ) / Screen refresh per second(60 HZ) = 17477). After that number of cycles has run, I subtract the number of cycles that actually ran from the number of cycles that should have run and store that in my cycles variable, and I simply have an empty "while" loop outside of the other "while" loop that waits the amount of milliseconds in 1/60th of a second to pass(16.6 ms).

[HyperHacker]

Uhhh, yeah... :huh: Could you post an example or something maybe?

[bcrew1375]

Heh, I seem to have a knack for confusing people :P. Okay, let's see:



cycleTotal = 0;
cyclesToRun = 17477;

while (cpuRunning)
{
currentTime = currentTime in milliseconds;

while (cyclesTotal < cyclesToRun)
{
// Do all the Gameboy cpu/IO/graphics stuff.
// Add all the cycles used to cycleTotal.
}

// This is in case more than the allocated number of cycles run.
// It keeps the leftover cycles in the cycleTotal variable for next time.
cycleTotal -= cyclesToRun;

// This will wait until the 16.6 ms(the time in one frame) have passed.
while ((currentTime in milliseconds - currentTime) < 16.6) {}
}


Hope that's understandable. :P I was kind of in a rush earlier, I had to be to work in about 15 minutes :P.

[HyperHacker]

I think I get it. What if less than the given number of cycles run though? A program that uses HALT a lot can have as few as 12000 actual cycles executed in one second.

[bcrew1375]

I'm not sure what you mean. The loop won't exit until the minimum number of cycles has run. Even when the system is halted, you need some way to time the interrupts and update the I/O registers, and to keep the timing accurate, I think most people would use the cycles. I just add 10 cycles while the system is halted.

[HyperHacker]

How are there CPU cycles being executed when the CPU isn't doing anything, though? O_o

Anyway I added various MBC support. Metroid 2's title screen now half-works. In doing so, I broke something related to VRAM timing, so now in fact everything only half-works. :angry: And apparently I can't spell 'angry'.

[edit] Doh! Stupid bug in vblank interrupt. LCD mode is changing during VBlank, and that just happens to be what it uses to tell when VRAM is accessible. :P Let's see if we can't fix that...

[bcrew1375]

There isn't really. I use that because all of my updates are tied to the cycles. The cycles are also like a timer. If you used actual time for things like the I/O registers, then things would probably get screwy.

[HyperHacker]

Yeah. I'm about as confused as a cat chasing a laser pointer now. <_<

What are you guys using for timing for the LCD modes? I've got 201 cycles for mode 0, 4560 for 1, 80 for 2, and 175 for 3. It works except for the occasional time when the game will try to access VRAM at scanline 0 during mode 3. (Interesting note: The NO$ docs say modes 0, 2 and 3 should add up to 456 cycles; added to mode 1 that's 5016 for a full redraw. Where do they get 70224 from? O_o That's 14 times how long it takes...)

[bcrew1375]

The mode flags are changed between 0, 2, and 3 once per scanline, not screen refresh. Those timings are pretty close, except you shouldn't be changing the mode flag to 1 unless LY is higher than 143.

Each line takes 456 cycles to draw. Including the V-Blank lines, there are 154 lines(0-153). 154 * 456 = 70224.

[HyperHacker]

During Vblank, though, the Mode flag is always 1 isn't it? That might make it somewhat difficult to 'pretend' to draw the extra lines.

[bcrew1375]

Okay, you've lost me. :huh: All you do is increment the LY register every 456 cycles, and reset it to 0 once it hits 154. The mode flag has nothing to do with it. You don't actually draw the lines after 143, they are just the time it takes for the screen projector to reset to it's starting position. Though, games use the LY register to verify if they are in the V-Blank or possibly how far along the V-Blank is. Also, you might want to consider using machine cycles rather than clock cycles. It's basically the cycle timings divided by 4. So, instead of having 456 cycles for a line, you would have 114. It wouldlet you use smaller numbers.

[HyperHacker]

Er... The mode flag indicates what it's doing (drawing, vblank, hblank etc), so I've based the timing off that. Change the mode every few cycles like it says in the docs, and when it gets to hblank, move to the next line. I don't get how I'd even be able to set the mode flag if I was just changing the scanline every so many cycles.

[ShizZy]

Anyone know of any good open source emus that I could peak at? Everything I've found so far has all been exteremely optimized quasi code... impossible to read.

I'm still having some difficulties, only a few demos are booting. I guess that means I should be putting more time into it :P

[HyperHacker]

Problem is, that's generally how emus are written, for speed reasons. I'd give you mine but it won't do much good until I get it cleaned up... and finished... and working. ;)

[bcrew1375]

Well, you've already looked at mine. I've tried to keep it at least somewhat readable. Someone else here might have readable code(aprentice? :P). Most of the emus I've looked at seem to be hard to read because the authors don't use descriptive names or use abbreviations(cycles = c), don't comment or comment only easily understood things, and don't use indentation properly. I've seen some that put a single space in their code for indentation! People releasing their source is great, but they don't seem to spend any time freshening it up.

By the way, did you die, aprentice? :P

[ShizZy]

Aye... yours was very readable and helpful bcrew, but I can't find what I'm looking for in it, and I'd like to see how other people have done things. I've talked to ren regarding his emu, and apparently he uses a lot of very optimized code; precalculated opcodes and a lot of other stuff that would make it useless for another programmer. @HyperHacker, regardless whether or not it's finished, I'd still be interested in seeing your progress. I'll upload my source friday for anyone who'd like to take a look.

[bcrew1375]

You could just ask about what you need to know. If you can't find any source, maybe someone could give or write you some if you post what you need.

[ShizZy]

I already asked, didn't get any response. I'm wondering if anyone could tell me how I should handle reading from memory - things that I should take into consideration and what not.

[bcrew1375]

So far, I haven't had to make any exceptions when reading from memory. The data is read from memory as bytes. The program/game will handle the data in the byte. The only thing you should need to check is memory writes.

[HyperHacker]

I'd like to fix this damn timing bug before I release it. It's running really slow for some reason. :(

[smcd]

shizzie: tgb/dual has source available, so does gnuboy,gest, visualboy advance, pgb(java), and a few dozen others that i cant remember the name of :P

[ShizZy]

I looked into all those, Hash, GB'98, and more. They're all good, but all of them have been very much optimized for speed and such, and are very uncommented.

[bcrew1375]

I wonder if aprentice is working on some super-secret feature :P. He's been awfully quiet...

As often as he posts, it kinda makes me worry :plain:.

[HyperHacker]

The Matrix has him. :matrix:

[aprentice]

no super secret feature, just exploring optimization possiblities, and yes, it does involve tabling and such, but i'm trying to go beyond that.. haven't had time lately to work on it, but i might have time now in the comming days, time will tell..

[Dark Stalker]

I hope I'll get the time to do further work on my emu too.

Looking at blocks of instructions until a branch happens should give lots of room for interesting optimizations...

[bcrew1375]

Anyone attempted sound output yet?

[aprentice]

Anyone attempted sound output yet?

nope, if everyone is up for a group effort count me in lol..

[HyperHacker]

If I knew how to output sound at all, I'd try, but I'd rather get it working first. :P

[bcrew1375]

I tried, but all I get right now is a series of beeps. It sort of sounds like a radar. :P Any idea what the Gameboy's playback frequency is? Is it variable or what?

[HyperHacker]

Not sure what you mean... Basically you take whatever value is written to each channel's frequency register, convert it to a real frequency (I think the pan docs have the formula) and play it. Not including things like volume, envelope and noise, of course.

[bcrew1375]

Yeah, I mean the... I guess you'd call it the sampling rate? It seems like it'd be 256 or something.

Edit: Looked at another emu's source. It looks like the sampling rate might only be 16 Hz! Of course, I still have no idea, this could be completely wrong.

[aprentice]

i dont even know how to use direct sound or any sound api for that matter, knowing how to set it up and one could definately be a good start..

[bcrew1375]

Setting up SDL's sound is pretty easy. Though, I still can't get it to play the sounds I want to yet. I have no idea about Direct X.

[zenogais]

Sorry for not positng for a while, I've been extremely busy with other endeavors including thinking about college, and I'm itching to get back to work on NeoGameBoy, which has been gathering dust on my hard-drive for some time now. I see that you all are working on sound, and so I figured I'd make a post to help you guys get stuff up and running.

As far as decoding and playing waveforms goes that is fairly easy and straightforward, however actually creating the other channels (noise, sweep, etc..) that is a bit trickier. The noise is not very straightforward, though it sounds like it should be. The most common way of creating noise, and the one that is most likely correct, is to create Gaussian Noise. I did some research on this when I was working on PS2SP, and understanding it requires some basic knowledge of calculus. Gaussian noise is really quite simple, though the math to actually create it can be less simple. Gaussian noise is a pattern of waveforms which is evenly distributed across all frequencies. You can find a simple method for generating semi-gaussian noise on the fly here (http://www.musicdsp.org/showArchiveComment.php?ArchiveID=168). For more information on the math I would look here (http://en.wikipedia.org/wiki/Gaussian_noise). Hope this helps, I'll try to dig up some of my notes on ADSR later today.

[bcrew1375]

Heh, I think most of us need help on actually setting the soundcard up for playback.

Edit: Hmm, I'm wondering about something. If you were to play a 22 KHz sound wave back at 44 KHz, but filled every other byte with the data of the byte before it(example: 0x00, 0xFF = 0x00, 0x00, 0xFF, 0xFF), would it sound exactly the same?

[refraction]

Heh, I think most of us need help on actually setting the soundcard up for playback.

Edit: Hmm, I'm wondering about something. If you were to play a 22 KHz sound wave back at 44 KHz, but filled every other byte with the data of the byte before it(example: 0x00, 0xFF = 0x00, 0x00, 0xFF, 0xFF), would it sound exactly the same?

sorry for my absense too, been busy :P

from my audio knowledge that would be correct yes BUT, playing a mono sound wave at 44khz would be pointless. even a CD is only 44khz for both left and right channels (2 * 22khz), not to mention the human ear struggles to hear frequencies about 20khz, so its best off staying at 22khz :)

[bcrew1375]

Okay, does anyone know where I can ask for help with SDL? If I play unchanging sound data shouldn't it be a unbreaking screech sound? Like if I continually play 0xFF to the speakers, shouldn't the pitch and volume remain exactly the same? Everytime I try to do this I get a sort of "fuzz" noise.

Another dumb question. Is the sound data that you send to the sound card the volume or amplitude, or what?

[Dark Stalker]

Okay, does anyone know where I can ask for help with SDL?The SDL mailing list (http://www.libsdl.org/mailman/listinfo/) might be a good place to start :P
And as you should know, the SDL Home Page (http://www.libsdl.org) has quite a bit of documentation, with the doc wiki (http://www.libsdl.org/cgi/docwiki.cgi/) being especially nice.

I haven't looked at sound at all yet, but it's on my todo list. I've, however, found a bottleneck in my SDL drawing code that effectively made my emu several times slower. (My profiler couldn't catch this, since the cpu time was spent in an SDL function.) Fixing this made my emu run at 1000-4000 fps in unscaled software mode (in GNU/Linux at least). I should be able to do similar things for my other video engines too, since they're now mysteriously slower than the sw drawer (in unscaled mode at least).

[bcrew1375]

What was the bottleneck?

[Dark Stalker]

What was the bottleneck?I underestimated the time it took to convert the colour format of my buffer to the screen format. Even if this only happened every v-blank, it took much more time than the sum of everything else happening. My profiler couldn't see it, since the time-consuming code was located in SDL's BlitSurface function.

[zenogais]

To play RAW sound using SDL you're going to have to use RWops, this requires a bit more work to set up, but its what you're going to need unless you decide to go with some other sound library. Here (http://gpwiki.org/index.php/C:Playing_a_WAV_Sound_from_a_Custom_Reso urce_File_using_SDL_RWops) is a good sample to get you started, the buffer used in the example will be your sound data buffer generated by the GameBoy program.

[bcrew1375]

Anyone had any progress with sound? I think I may be close to getting at least channel 3 working.

[bcrew1375]

*bcrew1375 walks through the desolate wasteland that was once this thread.* Hello, is anyone out there!? Can anyone hear me!? :P

Seriously, it's been almost a month. Is anyone still working on there emus? Or, will I have to continue being the only "survivor" :P

[HyperHacker]

Not in a while, no. I should but there's so much else to be done... Haven't quit though, just haven't worked on it in a long time.

[aprentice]

*bcrew1375 walks through the desolate wasteland that was once this thread.* Hello, is anyone out there!? Can anyone hear me!? :P

Seriously, it's been almost a month. Is anyone still working on there emus? Or, will I have to continue being the only "survivor" :P

I touched mine last week, put it direct sound code, just havent gone beyond that yet regarding sound, i might give it a go today.. btw, is your emulator generating any good sound since you said your close to getting channel 3 working?

[ShizZy]

I havn't quit yet. Just depressed that mine still won't boot any commercial games :(

[bcrew1375]

I touched mine last week, put it direct sound code, just havent gone beyond that yet regarding sound, i might give it a go today.. btw, is your emulator generating any good sound since you said your close to getting channel 3 working?

I haven't got any sound out of a game yet, but I'm beginning to understand more and more how Channel 3 works after reading the docs over and over and over. However, I know my sound setup is correct, since I got it to play some raw sound data correctly. Probably the most confusing part is how I am going to adjust the samples to play at the correct speed.

[zenogais]

I've been working on my emulator on and off, just polished off the CPU and debugged it using Executaboy :P , added Interrupt support and I'm now working on drawing. I've been extremely busy working on a webpage for someone, but when I get back to it cross your fingers, hopefully something will show up this time :D.

[KaioShin]

Hi!

I started working on a GB emu too, just last week. I am nowhere near a "showable" state though (Haven't even touched Grafics yet). I am collecting some Demos to test stuff. In this thread you mentionend a Interrupt Demo earlier. I googled for it but could not find it. From some info I found I know its so PD so could someone upload it?

Regards, KaioShin

EDIT: Never Mind, I finally got it (Those creepy "vote 100 times" Rom-Sites should stick to GoodGbx naming convention :saint: ).

[zenogais]

KaioShin: Best of luck to you, and if you have any questions feel free to ask. :) I hope you know what you're getting yourself into. :P

[HyperHacker]

Never Mind, I finally got it (Those creepy "vote 100 times" Rom-Sites should die :saint: ).
Fixed your quote. :P

[ShizZy]

KaioShin: Best of luck to you, and if you have any questions feel free to ask. :) I hope you know what you're getting yourself into. :P
It's a blast bro. Enjoy this part while it lasts... the fun comes when you start debugging ^^

[ShizZy]

Anyone make any progress? I'm not the only one still working on one, am I? I busted my laptop, and need to buy a new one before I can get back to coding - but mine is still very much allive.

[HyperHacker]

You might be. I was spending all my time on a Pokémon map editor, and then my motherboard fried so I have to wait to get a new one. :(

[bcrew1375]

I've been catching up on video games lately. I plan to get back to mine soon. I'm pretty sure I fully understand Channel 3 now. I just can't figure out how to implement it :/.

[aprentice]

I've been catching up on video games lately. I plan to get back to mine soon. I'm pretty sure I fully understand Channel 3 now. I just can't figure out how to implement it :/.

i dont understand how to play back the WAVE data, i dont think you can just read it into a buffer and play it off the bat, not exactly sure how to approach it..

[ShizZy]

Could anyone help me with my STAT code? Trying to get my timings right so the proper modes are set at the right time. Something major is wrong... I've attached my cpu, but here's some basic snippets of the code:

Here's the actual set mode function, stollen from Aprentice (this part works fine, it's the calling of it that is off):


#define reqINT(x) IOReg_IF|=x;

void VIDEO::SetLCDCMode(int mode)
{
IOReg_STAT=(IOReg_STAT&0xFC)|mode; //Clear and set bits 0,1
switch(mode)
{
case 0: //HBlank
if(IOReg_STAT&0x08) reqINT(INT_LCDC);
break;
case 1: //VBlank
if(IOReg_STAT&0x10) reqINT(INT_LCDC);
break;
case 2: //OAM
if(IOReg_STAT&0x20) reqINT(INT_LCDC);
break;
case 3: //Transfer
//if(cpu.hdma&0x80) hdma_hblank();
break;
}
} Now, here's where I call it. This is in my main CPU loop, shortly after I execute my opcode...
/* handle input/output */

// set STAT mode

cpu.count_stat+=cpu.cycles;

if(cpu.count_stat_mode==0 && cpu.count_stat>=CYCLES_OAMTRANSFER){
vid.VIDEO::SetLCDCMode(MODE_HBLANK);
cpu.count_stat_mode=1;
cpu.count_stat=0;
}else{
if(cpu.count_stat_mode==1 && cpu.count_stat>=CYCLES_HBLANK){
vid.VIDEO::SetLCDCMode(CYCLES_TRANSFER);
cpu.count_stat_mode=2;
cpu.count_stat=0;
}else{
if(cpu.count_stat_mode==2 && cpu.count_stat>=CYCLES_TRANSFER){
vid.VIDEO::SetLCDCMode(MODE_OAMTRANSFER) ;
cpu.count_stat_mode=0;
cpu.count_stat=0;
}else{
if(cpu.count_stat_mode>2 && cpu.count_stat<CYCLES_VBLANK*10){
cpu.count_stat_mode=0;
cpu.count_stat=0;
}
}
}
}

// main input and output

if (IOReg_LY < 144){
vid.VIDEO::DrawScanline();

cpu.count_stat_mode++;
if(cpu.count_stat_mode==3)
{
cpu.count_stat=0;
vid.VIDEO::SetLCDCMode(MODE_VBLANK);
}
}That's basically it. It's kinna sloppy... bare in mind the first thing I do is set the OAMTRANSFER mode outside of the loop, that's why the first mode set is actually the HBLANK. Anyways, I bugged Aprentice on IRC enough about it, so hopefully you guys will see something wrong. Currently, I don't think it is working. :P Attached my core... STAT stuff is around line 2246. Thanks!

Regards,

[bjz]

I havent looked at the file attatched but... if vid is an instance of VIDEO than you probobly want to call it

vid.SetLCDCMode()

instead of
vid.VIDEO::SetLCDCMode()


But.... like I said I havent looked at your code so I dont know what you have going on.

[KaioShin]

I am currently working on the Stats register too, but I think I can't help you much because I am using another programminglanguage (Delphi). If I get mine working fine I will post the part (unlike the other way around Delphi is very readable for C users). ATM it counts up to 91 and then stops cause I did not yet wrote the part that distinguishes between LY > 144 in Mode 0 or Mode 1 (Was that sentence understandable? I Fear not :saint: ).
what i don't know is what bits 3-5 are for. Are these just additional Statusflags to check the mode by one bit instead of 2 ???

[KaioShin]

One question:

When an Interrupt occurs and the Pc is pushed to the Stack and then a jump is performed, these steps consume clock-cycles, right?

[ShizZy]

Yeah... Just call your RST opcode which pushes the program counter onto the stack, and then jumps to the address. That opcode should use about 4 machine cycles (or 16 clock cycles).

[HyperHacker]

Er, the RST addresses only go up to $38, and interrupt vectors start at $40. You could use 'di, call' though, but depending how your system is set up it might be easier to just manually push and modify the PC, disable interrupts and increase the cycle count. Should just mean modifying a few variables.

Also, at http://www.devrs.com/gb, they just dumped the original Gameboy bootROM. Might be fun to add support for that. :p

[ShizZy]

Eh? I use RST, and my interrupt system works great... I think :P

[aprentice]

Also, at http://www.devrs.com/gb, they just dumped the original Gameboy bootROM. Might be fun to add support for that. :p

interesting indeed, even more interesting is getting it to work :P

edit: ok, i got off my lazy ass and just did it myself..

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

edit2: here is the emu (boot rom not included), put the bootrom in the same directory as the emu and make sure its named "DMG_ROM.bin". Then load the game and enjoy the show :P

[KaioShin]

Apprentice I tried it with your emu and this is what I get:

BTW: I like this distorted Logo, so I made it my Avatar :)

[aprentice]

Apprentice I tried it with your emu and this is what I get:

BTW: I like this distorted Logo, so I made it my Avatar :)

did you load a game and not the bootrom itself?

[Sagon]

Hi, everyone! I'm programming gameboy emulator too. Right now i have fully implemented, but not debugged cpu, interrupts are finished at 40%. I'm now searching for a good test roms, so i'd like to know what test roms you used for your emulators?

[HyperHacker]

The bootROM reads the Nintendo logo at $104. You need to load an actual game, then write the bootROM over the first $100 bytes. (Then when it writes 01 to $FF50, copy the start of the ROM back into that area. This is done right at $FE, so you don't need to perform a jump or anything.) If the logo or header checksum don't match it just goes into a jr-loop ($18, $FE), so you might be able to trap that and force-jump it out of the loop (modify PC manually), so that it still boots if the header is invalid.

[aprentice]

The bootROM reads the Nintendo logo at $104. You need to load an actual game, then write the bootROM over the first $100 bytes. (Then when it writes 01 to $FF50, copy the start of the ROM back into that area. This is done right at $FE, so you don't need to perform a jump or anything.) If the logo or header checksum don't match it just goes into a jr-loop ($18, $FE), so you might be able to trap that and force-jump it out of the loop (modify PC manually), so that it still boots if the header is invalid.

exactly what i did, did you get it working in your emu?

[KaioShin]

did you load a game and not the bootrom itself?

Right, that was my mistake. It is now working :saint:
Awesome work!

@Sagon: At Zophars Domain you can get a pack of PD-Roms called Test.zip (I think). These are Roms specifically for testing emus. addidtionaly I use Tetris as Test Rom as it is ROM only and seems not to complex. I must admit that I have nothing working yet, though :)

EDIT: Can someone Tell me after how many Frames Tetris Displays its first Screen??? I waited 54 Frames (due to shitloads of useless Debugoutputs this takes 2 minutes) but nothing apears on screen. I don't know if the problem is my drawing code (it's BG only atm but this screen is only BG right?) or if the rom doesn't get to load the data into the Vram area.

[KaioShin]

Tetris stays on the first text screen for about 5 seconds.


You got me wrong. I don't want to know how long it stays, but after how many frames (from the beginning) it appears. The Tiles must be load into memory somewhere but my screen always stays blank. that's the prob. This counts for all games of course. if you know exactly when one of the demos loads its tiles please tell me so I can look there.

[bcrew1375]

Tetris stays on the first text screen for about 5 seconds.

I didn't know the GB bootROM was dumped! I think I'll try and add support for it :D.

KaioShin: The 3-5 bits are interrupt enable registers. 3 is for H-Blank, 4 is for V-Blank, 5 is for OAM. They request an LCDC interrupt depending on the mode. So, if bit 3 is on when the mode changes to H-Blank, an LCDC interrupt is requested. You would then treat it the same as an LY Coincidence interrupt.

[KaioShin]

KaioShin: The 3-5 bits are interrupt enable registers. 3 is for H-Blank, 4 is for V-Blank, 5 is for OAM. They request an LCDC interrupt depending on the mode. So, if bit 3 is on when the mode changes to H-Blank, an LCDC interrupt is requested. You would then treat it the same as an LY Coincidence interrupt.

Thanks a lot, that is clear now :bouncy:
Now if i'd only get some display :plain:

[bcrew1375]

Yay, added support for bootROM. Runs great :D. Funny how just having the Nintendo logo scroll down makes the emu fell more authentic :).

[ShizZy]

Howdy.... been working a lot on mine latelly. Here's a shot of my emulator wip - right now I'm working on a new debugger, and disassembler (which is partly functional at the moment). As you can also see, I found another rom that was compatable! :D

Cheers

[hap]

hmm, nice desktop background ;)

I just took my GameBoy out its dusty case and played some Mario1, I forgot how hard it is too see the screen without sitting under a 100watt lightbulb.

[Sagon]

After two days of debugging my emulator plays normal most of 32K roms (i haven't added any MBC support), but i encountered some problems with graphics, looks like my emulator incorrect draw BG Map. I've attached some shots from Asteroids (1,2), Space Demo (3), Missile Command(4), Heiankyo Alien (5).
Any clues?

Added later:
Hmm seems like problems with my cpu emulation or smth else, but not graphics. Any ideas?

Some time later:
I've found problem, that's all because of my incorrect timing and STAT register handling.

[ShizZy]

Damn Sagon, you've outcoded my few months work in just a few days. I'm impressed, keep up the good work!

Edit: Disassembler is now done, and seems pretty flawless:

[Sagon]

Thanx. By the way, i'm creating debugger too. There are still some bugs in my cpu that i can't catch, many 32K games works perfect, but in Motocross Maniacs sometimes bugs occurs.

[ShizZy]

Can someone really explain to me how exactly I should be handling the STAT register? Thanks!

[ShizZy]

Bingo. Now we're making progress.

First commercial game to boot - Tetris (Note that the first shot of Tetris, the titlescreen one, I was only to get by hacking a bit with my debugger. The rom alone crashes after the copyright screen. But it still boots :P). This and some other demos started working when I rewrote by Input/Output register code. I'm still out in the dark with my STAT stuff though.

Thanks for the help aprentice :P More to come...

[Sagon]

I've finally fully debugged my cpu, now it 100% bug free :happy:
Finished my debugger, and using it fixed some bugs with my interrupts handling. Now i'm moving toward MBC emulation. Here some ingame shots:

[ShizZy]

I've done a lot of work on my emu this weekend as well. My CPU is still very much buggy - but I'm getting there. Tetris now boots and goes to the title screen on its own. (This shot is of the little preview thing that comes up when the player idles on the main screen, no in game yet :P). Asteroids now also boots, with a nasty bug - can't seem to figure that one out. I also coded some early input code for the enter key, don't know if it works but when I press it in Tetris it flickers a bit (hopefully I'm getting close). Anyways, much work to get done - still no sprites or mbc. Shots look great Sagon!

[Sagon]

Good work ShizZie!
Looks like that you have a similar problem that i have with Asteroids, so maybe the further information will be useful for you.
The value that written to the STAT register shouldn't change mode bits, code might be smth like that: STAT=(STAT & 7)|(data & 0xF8). And of couse you should have a proper emulation of mode flag and lcd stuff, i've emulated it like this:

if LCD is On
{
lcd-=cycles;
special handle of vblank for LY increment
if lcd<=0
{
//handling of all modes, and of couse lcd+=next mode ticks
}
}
It work for me, hope it help you.

[ShizZy]

Hmmm... while it does look similiar, I think it may be different. You were able to get the first logo to work, weren't you? It's just blank for me, then the title screen fades in. I've scoured my opcodes, and I don't think the bug lies in there either. Anyways, I handle my STAT stuff pretty much the same way you posted:
if(cpu.LCDon)
{
cpu.count_stat-=cpu.cycles;
if(cpu.count_stat<=0)
{
switch(IOReg_STAT&0x03)
{
case 0:{ // HBlank
// --------------------------------

// increment LY each loop
IOReg_LY++;

// LY/LYC Coincidence???
if(IOReg_LYC==IOReg_LY) // LY compare
{
// set coincidence flag
IOReg_STAT|=BIT_2;

// request interrupt
if(IOReg_STAT&BIT_6) reqINT(BIT_1);
}else{
// reset coincidence flag
IOReg_STAT&=0xFB;
}

// time for vblank???
if(IOReg_LY>144){
vid.SetSTATMode(MODE_VBLANK);
cpu.count_stat+=CYCLES_VBLANK;

cpu.vblank_wait=1;

if(IOReg_STAT&BIT_3) reqINT(BIT_1);
}else{ // time for mode2, OAM transfer???
vid.SetSTATMode(MODE_OAMTRANSFER);
cpu.count_stat+=CYCLES_OAMTRANSFER;


if(!(IOReg_STAT&BIT_6) && IOReg_LYC && (IOReg_STAT&BIT_5))
reqINT(BIT_1); // fixes joust, altered space, homm
}
}break;

case 1:{ // VBlank
// --------------------------------

if(cpu.vblank_wait)
{
cpu.count_stat+=CYCLES_VBLANK;

reqINT(BIT_0);

if(IOReg_STAT&BIT_4)
reqINT(BIT_1);

if((IOReg_STAT&BIT_6) && (IOReg_STAT&BIT_2))
reqINT(BIT_1);

// ----------
// joypad interrupt shit here
// ----------

cpu.vblank_wait=0;
}

if(IOReg_LY<153){
++IOReg_LY;

if(IOReg_LY>=153) cpu.count_stat+=24;
else cpu.count_stat+=CYCLES_VBLANK;
}else{
// update user input
EventSDL();

// reset the LY register
IOReg_LY=0;

// goto mode2, oam transfer
vid.SetSTATMode(MODE_OAMTRANSFER);
cpu.count_stat+=CYCLES_OAMTRANSFER;
}

// LY/LYC Coincidence???
if(IOReg_LYC==IOReg_LY) // LY compare
{
// set coincidence flag
IOReg_STAT|=BIT_2;

// request interrupt
if(IOReg_STAT&BIT_6) reqINT(BIT_1);
}else{
// reset coincidence flag
IOReg_STAT&=0xFB;
}
}break;

case 2:{ // Searching OAM...
// --------------------------------

cpu.count_stat+=CYCLES_OAMTRANSFER;

cpu.draw_wait = 12;

// next mode...
vid.SetSTATMode(MODE_TRANSFER);
cpu.count_stat+=CYCLES_TRANSFER;

break;}

case 3:{ // Transfer
// --------------------------------

cpu.count_stat+=CYCLES_TRANSFER;

// next mode..
vid.SetSTATMode(MODE_HBLANK);
cpu.count_stat+=CYCLES_HBLANK;

if(IOReg_STAT&BIT_4)
reqINT(BIT_1);

break;}
}
}

if(cpu.draw_wait)
{
cpu.draw_wait -= cpu.cycles;
if(cpu.draw_wait <= 0)
{
cpu.draw_wait = 0;
if(IOReg_LY < 144)
{
vid.DrawScanline();
}
}
}
}

And here is my STAT adjust function:


void VIDEO::SetSTATMode(int mode)
{
IOReg_STAT=(IOReg_STAT&0xFC)|mode; //Clear and set bits 0,1
switch(mode)
{
case 0: //HBlank
dbg_lcdc_phase=1;
if(IOReg_STAT&0x08) IOReg_IF|=BIT_1;
break;
case 1: //VBlank
dbg_lcdc_phase=4;
if(IOReg_STAT&0x10) IOReg_IF|=BIT_1;
break;
case 2: //OAM
dbg_lcdc_phase=2;
if(IOReg_STAT&0x20) IOReg_IF|=BIT_1;
break;
case 3: //Transfer
dbg_lcdc_phase=3;
//if(cpu.hdma&0x80) hdma_hblank();
break;
}
}

Any ideas?

Edit: I see what you mean by writing to STAT in the form of STAT=(STAT & 7)|(data & 0xF8), tried it. Results are the same though.

[Sagon]

You increment LY each VBlank, that's not correct, you should inc it in general after each 114 cycles, which should be counted while LCD is on and mode is VBlank. This bug is first i've found, there are several other including fix for joust and other, but they are not significant, and i don't want to spoil all fun :P

[ShizZy]

Ahhh yes, I've also got the stuff for the fixes for Paradious, Crazy Burger, and a few others :P I didn't put them in for less clutter, but when I get it pretty bug free I'll add them. But thanks, I'll try that. If you see anything else, let me know. Btw... HBlank happens after every 114 cycles... it's the third phase for each scanline and each scanline is 114 cycles. (in my emu)

[zenogais]

Hey all, Its been a while since I posted something, and for good reason :P It appears I've had a little hard-drive crash, but I'm back now and luckily I didn't lose too much of my programming files. I've got to reinstall Visual Studio etc, but I should be able to get back to working on NeoGameBoy once I've taken care of this. Talk to you all when I have something to show or I need help troubleshooting my code.

[ShizZy]

Anyone been making any progress? I still have shitloads of bugs in my interpreter code. :(

[zenogais]

I just got visual studio reinstalled, so now I'm back on the road to development. Can anyone tell me how much timing I'll need to get basic display on from my video system?

[aprentice]

I just got visual studio reinstalled, so now I'm back on the road to development. Can anyone tell me how much timing I'll need to get basic display on from my video system?

opps, hit edit post instead of quote, my mistake :P
well, you need phase timing, theres about 114 cycles per scanline, not much to it :P

[HyperHacker]

I'd love to work on mine, but I'm STILL waiting on fixing my computer. More specifically, I'm waiting for my new video card and power supply to arrive so I can assemble them together with the motherboard and CPU I bought. They were due to arrive today, but yeah. <_< Looks like a boring weekend ahead...

[Sagon]

I've been busy last week, however i've added MBC 1,2,3,5 and it works fine. Now working on optimization, maybe soon i'll release first beta.

[HyperHacker]

Well I finally got around to working on mine again. I fixed several 'crashes' which turned out to just be sprites and/or the window covering the entire screen. :P Working on two things at once, trying to get tiles to display properly in that queer signed mode (check out Mario Land) and trying to make sprites not cover the entire screen.

[ShizZy]

Looking pretty sweet man, keep it up!

[HyperHacker]

Jeez, I can only imagine what you think looks crappy. ;) I mean I'm glad to have it getting that far, but I wouldn't call a glitched-up title screen and a game that doesn't run right 'good'. Just progress.

Fun trying to play though. If you jump, it freezes. If you move left sometimes your lives go waaaaaay up. :blink: I bet it has to do with the fact that my logical rotation instructions don't work. Gotta fix that. :P

Tetris runs, but you can't see the blocks and it crashes at random. Hehe.

[ShizZy]

Farther than mine. Mario doesn't run, and tetris crashes after the title screen :P

[HyperHacker]

That's how mine was, it turned out to be a sprite problem. When I implemented sprites/windowing I didn't do the scanline/pixel check properly, so they would cover the entire screen and make it look like it crashed.

Of course I do have to work out some CPU bugs. That's always the worst part.

[Lordus]

I was following this thread for a while and it inspired me ...
As i just finished making my first game in J2ME (for mobile phones) and always wanted to get into emulation programming, i thought to give it a try now.
I know Java is maybe not the best choice for this and neither are mobile phones, as their power is not quite up for the task, but well...
finally, yesterday i got my first screen showing up :bounce:
and by now i think its working quite well, every game i tried so far worked without glitches. Still have a lot of optimizing to do though - on my mobile, which is an older one, it works at like 3fps atm.

http://www.workingdesign.de/projekte/Ja2meBoy_01.pnghttp://www.workingdesign.de/projekte/Ja2meBoy_02.pnghttp://www.workingdesign.de/projekte/Ja2meBoy_03.png

[HyperHacker]

Coooool. Too bad I hate mobile phones. :p

[ShizZy]

Nice...

HyperHacker, does mario require sprites to work? I don't have any sprite support yet...

[Cyberman]

I was following this thread for a while and it inspired me ...
As i just finished making my first game in J2ME (for mobile phones) and always wanted to get into emulation programming, i thought to give it a try now.Woo Hoo another emulation addict.. err :D

I know Java is maybe not the best choice for this and neither are mobile phones, as their power is not quite up for the task, but well...
finally, yesterday i got my first screen showing up :bounce:
and by now i think its working quite well, every game i tried so far worked without glitches. Still have a lot of optimizing to do though - on my mobile, which is an older one, it works at like 3fps atm.
Oh shizzle sticks LOL. Yes Java is a poor choice unless you have a VERY powerful processor. However you might be able to find a devkit for the phone platform that is not Java based. Java code should be fairly portable. You should get a boost of about 5-10X the performance by going to C or C++. The reasons for this are Java engines are essentially an emulator in reality. The majority of which are interpreted. This makes in highly portable but at the same time also makes it slow because the system processes data then performs an operation. Not exactly speedy. So in summary it's going to be slow, even on a powerful CPU. You could try it on your desktop machine and see how fast it is on that to gauge performance.

http://www.workingdesign.de/projekte/Ja2meBoy_01.pnghttp://www.workingdesign.de/projekte/Ja2meBoy_02.pnghttp://www.workingdesign.de/projekte/Ja2meBoy_03.png Looking pretty good really. It's better than mine, oh wait I didn't make one ;) hehehe anyhow nice job there.

As a possibility you might want to find a better Java Engine for your phone with JIT dynamic recompilation. Your biggest issue is having enough RAM space to run such an animal. JIT isn't as bad as recompiling the whole Java binary though. You probably should look into frame limiting too as I noticed your static image is a bit too fast for the GameBoy (LOL)

Cyb

[HyperHacker]

Mario will run without sprites, but it always has one on the screen (that little mushroom on the title screen is a sprite), so if your sprite implementation is broken like mine was you'll only see a blank screen.

[Lordus]

Thx Cyberman. I know C/C++ would be the better alternative and there are actually Gameboy emus for phones with SymbianOS that run in fullspeed (even a SNES emu, that claims to run fullspeed, didnt test it though), but i wanted to try the whole thing in Java to make it more compatible. As you see in the phone emulator running my emu, it is perfectly playable this way. On my real phone i never expect it to be playable, i mostly wanted to make an emu at all ,and see, that it can be done on this limited platform.
Profiling it, i can see, that most of the time is spent in the actual method to draw the screen with j2me, as a new image is created out of the pixeldata every frame. that is not acceptable speedwise, so i will try to tweak that and gain some speed from that.
Sound is the other issue. it is emulated, but not interfaced with j2me yet.
dont know if i will be able to do that at all, maybe some monotone sounds, but no real interpretation. there is a j2me nes emu though with sound, maybe i can look into that...
frame limiting is actually implemented, the screens were taken with a version though that had a 'bug' in showing the fps, as the emulation loop as well as the 'canvas-loop' were updating the screen, which also caused some flickering, anyway this is solved now.
The memory to work with is really a pain ... Zelda wouldnt work on my phone for example, as the heap size is too small to load the rom, just smaller games work. You really needed a high end phone to make something of this, but i am sure, not too far in the future this might actually be playable on real phones.
Actually i ported javaboy now, to compare its speed with my emu and its a bit slower, but well, it was not designed for j2me.
I am thinking of porting a C64 emu and maybe GameGear emu now, or to do one from scratch. We'll see.
Anyway, i am really enjoying this working in emulation, will see what will become of it.
My ultimate goal is to make a working Saturn emu :ph34r: (not in J2ME of course :P )
but thats quite a way to go.

[ShizZy]

Lordus, how long did it take you to do your gb emu?

[Lordus]

/*
* jmboy.java
*
* Created on 17. August 2005, 20:04

...do the math.
It was my first emu project, but i know 'a bit' of low level hardware programming /design and assembler, which is quite helpful ;)
And last year i did a bit of research already, because i made an OpenGL KartRacer, that took the tile and sprite data from a MarioKart rom. It actually looked quite cool, just that the whole thing was lost due to a hd crash in december...

[weston]

erm, I don't think cyberman has seen what java can do since 1997 or so... if you want to see what the java community is doing with games nowadays, check this out: http://www.iotd.kaioa.com/ 5x faster with C/C++ is ridiculous...

I also just finished a chip8 emulator (http://www.cyntaks.com/projects/chip8) written in java and I don't believe its slow at all (ok yes its a chip8 emu but still).

Startup time may be a little slower with java still, but keep in mind that this is a constant and doesn't increase with app complexity, its almost not noticeable anymore.

Can't say anything about j2me though as I've never used it.

[Cyberman]

erm, I don't think cyberman has seen what java can do since 1997 or so... if you want to see what the java community is doing with games nowadays, check this out: http://www.iotd.kaioa.com/ 5x faster with C/C++ is ridiculous...Not really, it depends on the Engine used to run the JavaCode and the compilor. However Java has slowly improved in two key areas, memory management and execution management. GCC for example has a Java compilor front end. What's that mean? It means it can compile native binaries from Java code.

I also just finished a chip8 emulator (http://www.cyntaks.com/projects/chip8) written in java and I don't believe its slow at all (ok yes its a chip8 emu but still). Fine with me.. what is the performance of the system you are running it on though? I believe you are mistaking improvement in processor execution performance, for improvement in Java execution performance. Trust me they aren't the same. In fact special variants of ARM processors had to be made for improved performance of J2ME on Cell Phone and PDA platforms.


Startup time may be a little slower with java still, but keep in mind that this is a constant and doesn't increase with app complexity, its almost not noticeable anymore.
Well it does take a certain amount of time to load the Java bin data and perform initialization of the Java Engine. It's expected. Sort of like watching PJ64 run through an N64 ROM.


Can't say anything about j2me though as I've never used it. Java 2 + Mobile Embeded? Hmmm which means the only thing you have to compare is with a desktop machine. Ok.. let me explain this in understandable terms then. Your DT machine 2Ghz processor 32bit to 64bit 133mhz to 500mhz 64 to 128 bit FSB and has 3 FPU pipelines and 3 Integer pipelines along with several look ahead engines to precompute addresses and fetch code for speculative execution uses from 20 to 50 watts of power, your Cell Phone 200mhz processor uses 1mw to 1W, uses a RISC processor optimized with power as the primary concern, FSB 100mhz tops 32 bits tops most likely 33mhz and 16bits. In order for that thing to run Java with any speed, it has to have specialized instruction set and hardware. Otherwise it might be like running Java on a 486/66 :)

I hope this sinks in, that if you used your processor to its full performance for your DT it is likely to be about 10 (normal apps) to 100 (optimized apps) times faster than the Cell phones. That's the complete picture. A well written and properly optimized C++ program will be 5 to 10 times faster than that the equivalent Java program depending on the compilor and if it's native compiled code or not. It's not far fetched that's just reality. Sometimes you don't need to tweak that extra bit of power out of your machine. Well at least not with the hugely powerful systems of today as opposed to 1997 ;)

The important thing to keep in mind, is does it work and is it fast enough. Cell phone's are a challenge for an emulator and Java and it's not fast enough as a consequence. Perhaps using GCC's Java compilor might help? Depends if the platform will allow native binaries to be run.

Cyb - have fun with Emu's!

[weston]

Hmm, should have clarified a couple things I guess. First of all, I'm talking about the standard implementation of java provided by Sun Microsystems. I am not talking about compiled java, or using a 3rd party virtual machine. When you say Java Engine, I assume you are referring to a jvm?

Second, I realize that cell phones and desktops have vastly different hardware. I was just talking about java in general (so on the desktop). I only mentioned j2me at the end because one platform Lordus could be writing for is cell phones and j2me != desktop java. J2me vs native cellphone code is different from desktop java vs native and I don't know how j2me holds up.

I also made the assumption that people would understand that I was talking about an increase in java's operating speed, not the fact that computer hardware has gotten better. As for startup time, I mentioned that it is independant of the program you run (jvm startup time, not the start up time for your specific program), so increase in computer hardware speeds is all that matters here (I'm not saying this is true about execution speed!!).

Now that thats all cleared up, I say once again: C/C++ being 5x to 10x faster than java code is a ridiculous statement (not talking about j2me which once again is not the same as desktop java).

[HyperHacker]

Well it all depends what you're running. A simple program like a word processor or image editor would probably run at the same speed in Java as in C, since the speed boost it gets from being native code wouldn't make much difference since the program is idling most of the time anyway (unless your CPU is particularly slow). An emulator is a lot more demanding, doing millions of calculations per second and probably not idling much, so a difference in speed is going to be very apparent. Java can get faster and faster but it'll never match native code (unless they can recompile the program to 100% native code at runtime ;)).

[weston]

I'm not talking about percieved performance, I'm talking about actual performance. I know people writing next generation game engines in java... not the crappy java applets that it got its reputation from. Look at the screens I linked to, those are hardly text editor type applications. Or even better, look at this benchmark comparing a current version of java vs. C running quake2: http://www.bytonic.de/html/benchmarks.html

Does that look like C is winning 5 to 10 times over? People seem to think that modern jvms are still just simple interpreters or something. There are trade offs between run-time and ahead-of-time compilers, both are able to gain speed in different ways. With a run-time compiler (e.g. a jvm), you can do things like adjust the size of code blocks to fit your current cache size.

I honestly just don't think you are going to run into the slightest performance problems writing an emulator 'because' you are using java. If its slow, thats because you coded it slow (exceptions made for ps2/gc/xbox perhaps).

[HyperHacker]

Well I'm sure Java can be pretty damn fast, but C will always be just a little faster.

[Cyberman]

I'm not talking about percieved performance, I'm talking about actual performance. I know people writing next generation game engines in java... not the crappy java applets that it got its reputation from. Look at the screens I linked to, those are hardly text editor type applications. Or even better, look at this benchmark comparing a current version of java vs. C running quake2: http://www.bytonic.de/html/benchmarks.html

Does that look like C is winning 5 to 10 times over? People seem to think that modern jvms are still just simple interpreters or something. There are trade offs between run-time and ahead-of-time compilers, both are able to gain speed in different ways. With a run-time compiler (e.g. a jvm), you can do things like adjust the size of code blocks to fit your current cache size.

I honestly just don't think you are going to run into the slightest performance problems writing an emulator 'because' you are using java. If its slow, thats because you coded it slow (exceptions made for ps2/gc/xbox perhaps). I did put caveats, please stop busily defending your position, this hasn't anything to do with what's fast and what's not on a PC. I told you exactly why Java is not a good choice for a particular platform. I also said there are Java compilors etc. In addition I mentioned that a mobil platform is bad for Java. It has limited memory (you can't do dynamic REC easily if at all and JIT has the same issues), it has limited hardware performance (IE required special hardware to run the Java Engine). Bottom line is it won't run fast for the particular application I was refering too (IE mobil phones and PDA's). Sure it will get faster eventually, but in order to do that the JE's have to use the tricks of Emulators in order to improve Java. Basically JavaEngines are no longer JavaEngines but JavaEmulators. That's a more complete perspective of what's going on.

I have never been fond of Java but it does work for specific applications just fine. I'm not sure Java should be used for everything. That seems kind of like giving someone a hammer and nail, and everything suddenly becomes a board to pound nails into. It reminds me of the people who use to use 4th for everything, or assembly for everything. You use what's appropriate, Java is not appropriate for everything. You can't use Java at the current hardware level of mobil systems without using the low resource usage interpretor. That will change of course. As everything does. It doesn't make Java faster though, because it's not really running Java code anymore is it? Just like an emulator that uses HLE JIT and dynamic REC is no longer actually executing the original code inside the game. It's one of those strangely gray areas of the world. JE's that run that way are no longer JVM's. Reading the Jake 2 stuff revealed most of the optimizations are in Memory handling of which Java has been traditionally very bad at.

You have the same issues with Java and speed on emulation as you would with C and C++ with all the great and wonderful JavaEmulators. Unless you can do Dynamic Rec HLE etc in Java you will not see Java based N64 emulators that run fast for a while (hehe).

I'll continue to be skeptical. FUD is FUD. :)

Cyb

[zenogais]

Cyberman: I want to try and clear up this performance issue annoyance hopefully on these forums once and for all. Being a java programmer myself and having to take crap over the "performance problems" time after time I've come to sympathize with weston's point of view and quite frankly his frustration at these criticisms. First things first, the performance issues are quite frankly null and void anymore for most applications, and I've come to realize the people who talk about them are 99% of the time (1) Not Java programmers (2) Have no clue what they're talking about (3) Usually heard it either via word of mouth or from some ancient article.

Honestly I wouldn't mind if you disliked Java semantics etc. as you don't need to be an active use of the language to criticise these, but please have coded something "performace intensive" within the last 6 months in Java to even think you can speak on the topic. Now these criticisms are not aimed at you (Cyberman) in particular as your second posts shows you're fairly level headed on this issue, but instead more towards to ignorant "anti-Java" people in general. Please know wtf you're talking about before you talk about it. Finally, spewing these things doesn't make you sound knowledgable or informed, it instead shows that you possess neither of these qualities.

[Lordus]

I guess i shouldnt have mentioned Java in these forums :whistling

No programming language is better than the other, just use what u like best and what fits the purpose.
I just started with Java again after a while and its surely wonderfully easy to do some things with it, and you wont see any speed differences on most applications on modern hardware, as you wont see any speed difference between a bmw and a ferrarri in the rush hour.
To get the last bit of speed in a limited environment a C/Assembler combo will surely do the trick a little bit better.
Anyway, PEACE... and btw. just ported a GameGear emu to J2ME and its slow as hell of course, but nice to look at a Sonic-slideshow on my mobile.

[bcrew1375]

So, um, anyone interested in getting back on the main topic? :whistling

[ShizZy]

I finally made some progress... Got joypad emulation working. All the keys work, but for some reason I cannot get it to find the distinction between the directional pad and the rest of the buttons. Not important at the moment, nothing is playable yet anyways - all I need input for is testing.

Anyways, it allowed me to get in-game with Tetris :D I also roughly implemented sprites, although it doesn't actually read tile data yet. It draws a black 8x8 square instead (as seen in the screenshot by the score). It works afaik, but unfortunetly there's a bug which in tetris causes the emu to write garbarge into OAM throwing the sprites all over the place. It works right in other roms though...

So, fix input, find out what is wrong with the memory issues, and Tetris becomes fully playable :D Not going to bother with MBC yet, still too bug ridden....

[HyperHacker]

How did you manage to finish the game with no points? :P

[ShizZy]

Easy, you don't get any lines when you can't see the blocks :P Also love how the score is in hex when you do randomly get them :D

[Cyberman]

I guess i shouldnt have mentioned Java in these forums :whistling

No programming language is better than the other, just use what u like best and what fits the purpose.
I just started with Java again after a while and its surely wonderfully easy to do some things with it, and you wont see any speed differences on most applications on modern hardware, as you wont see any speed difference between a bmw and a ferrarri in the rush hour.
To get the last bit of speed in a limited environment a C/Assembler combo will surely do the trick a little bit better.
Anyway, PEACE... and btw. just ported a GameGear emu to J2ME and its slow as hell of course, but nice to look at a Sonic-slideshow on my mobile.
Putting aside all heritical Java remarks ;) hehehe :D


I finally made some progress... Got joypad emulation working. All the keys work, but for some reason I cannot get it to find the distinction between the directional pad and the rest of the buttons. Not important at the moment, nothing is playable yet anyways - all I need input for is testing.
Well it looks like it sort of works :D
You need to port your jet hydro game to the game boy as one of your key emulated games ;)

Cyb

[ShizZy]

LOL yeah I wonder how software based shaders would be handled on the GameBoy, rendering 20k+ polys on screen at a time, vertex based fogging, and atmospheric cloud settings - plus a physics engine ;)

[HyperHacker]

Very, very slowly. :P

[Cyberman]

ShizZie it's obviously going to be at least 60fpm That is 60 frames per month LOL.

Cyb

[ShizZy]

Probably possible to get it to render though, in monochrome :D Not in my lifetime as a programmer ;)

[HyperHacker]

If the GB has enough memory. Which I doubt.

[Dark Stalker]

Time for an overdue update. I haven't exactly got an abundance of time, but I do work on my emu occasionally. I've gotten enough done now that I thought it might be worthwile to make a WIP release.

I guess the biggest new feature of this release may be sound support. Implementing it was interesting and a lot of fun too. It wasn't really that hard either. Of course, since I haven't done anything sound related before, I had to learn a bit of the terminology and how sound waves tend to be represented digitally etc. After that things became a lot clearer. My general impression is that the accuracy is pretty good. The only quirk I know isn't emulated is the so-called "zombie volume change", which is wrongly or inaccurately documented. I think bgb is the only emu supporting this, and I've only found one rare game depending on it. I could make an implementation based on some guesses I suppose. The quality of the sound seems to be quite decent too, even though I don't use any complex filters or synthesis.

I also added the 10 sprites pr. line limit, in addition to sprite sorting by x-pos for DMG games, while doing some optimizations to sprites-rendering. This will make some sprites flash or disappear when the limit is exceeded like on the real GB. GB games tend to combine several sprites to make bigger ones, so usually it will be parts of sprites disappearing/flashing. For the same reason, DMG sprites that pass each other tend to have a somewhat segmented appearance.

Another new feature is input configuration as well as gamepad/joystick support. There's a simple addition to the GUI for this. Speaking of the GUI, I did some cleanups and changes to make it a bit less ugly. I also added some ifdefs so that the win32 build uses the native windows file selecting dialog. I'll probably make a nicer GUI later, but it's not the highest priority atm.

The RTC emulation now uses system time so that the time passed in the game will reflect the actual time passed between sessions. I also added support for games to change the actual rtc values through modifying the timestamp, although I haven't seen this used in any game.

Save-files now spawn in a seperate subfolder, so your rom-folders will no longer be spammed with .sav-files. Note that the save-files should be compatible with most other emus.

Cleaning up my drawing code, I came across some interesting issues. It turned out that the previous overlay-based renderer used a generally unsupported YUV-format, making it fall back to SDLs software implementation more often than not. Having fixed this, platforms supporting a hardware overlay should get essentially free scaling. However, it seems that the windows-version of SDL doesn't use an actual overlay, but rather uses the normal DirectDraw scaling-function (which should still be a good bit faster than software at least). According to SDL changelogs true overlay was disabled because of performance issues. I found that the performance problems they encountered were due to them misunderstanding how the DirectDraw UpdateOverlay-function works (they were calling it every screen update). If I get the time to implement a decent fix, I'll see if I can get it included in SDL.

Additionally there's been optimizations and cleanups all over the place, as well as some minor bug fixes and compatibility tweaks.


Downloads:
lameboy-0.10.0_i386_linux.tar.gz (http://home.tussa.com/iaamaas/lameboy/lameboy-0.10.0_i386_linux.tar.gz)
lameboy-0.10.0_win32.zip (http://home.tussa.com/iaamaas/lameboy/lameboy-0.10.0_win32.zip)

[HyperHacker]

Cool. Can we choose the save file path?

What is this 'zombie volume change' anyway, and what game depends on it?

[ShizZy]

Very nice Dark Stalker, great quality sound too.

[Dark Stalker]

Thanks!


Cool. Can we choose the save file path?

What is this 'zombie volume change' anyway, and what game depends on it?
The save path is hardcoded to the "saves" subdirectory for now, but it would be easy to add.

The "zombie volume change" supposedly happens when a game adjusts the volume of a channel while it's outputting sound. Depending on what is written to the envelope register it increases a certain amount and may overflow as I understand it. There's more to it than that too though. It is further described in Lord_Nightmare's GBSOUND.txt (http://www.netaxs.com/~gevaryah/GBSOUND.txt). The game I found to depend on it is "Prehistoric Man".

[aprentice]

wow sounds very complete, are you even missing anything?

My emu lacks sprite limiting,sound, and some compat, i need to get around to it sometime again, its not too far off from being release worthy :P

[Dark Stalker]

wow sounds very complete, are you even missing anything?
There's all the usability features like save states and video filters for one. It still lacks support for some of the rarer mbcs, and I guess compatibility will never be 100% perfect :P


My emu lacks sprite limiting,sound, and some compat, i need to get around to it sometime again, its not too far off from being release worthy :P
Looking forward to it! :)

[mono]

I made a Gameboy emulator and it runs most games, but it can't get past the opening of Altered Space due to a timing issue. It gets stuck in an infinite loop at 78A. Can anyone tell me how one determines the display mode and the number of lcd cycles there should be after the lcd is turned back on?

[bcrew1375]

Could you be a little more clear, what do you mean by display mode? What LCD cycles? The retrace cycles?

[mono]

Good point. By display mode I mean the mode in the STAT register, and by LCD cycles I mean the number of cycles remaining before the mode is switched.

In my emulator, I handle it like this. I use the term "ticks" here to refer to what I referred to as lcd cycles previously, by the way...


ticks -= cpu_cycles;

if (ticks <= 0)
{
switch (mode)
{
case 0:
++ly;

if (ly == 144)
{
mode = 1;
ticks += 114;
}

mode = 2;
ticks += 20;
break;
case 1:
++ly;

if (ly == 154)
{
ly = 0;
mode = 2;
ticks += 20;
}
else
{
ticks += 114;
}

break;
case 2:
mode = 3;
ticks += 43;
break;
case 3:
mode = 0;
ticks += 51;
break;
}
}

This is just to demonstrate what I mean, by the way. I handle the interrupt stuff as well in my real code.

What I want to know is, when the LCD is turned back on, how do I set "mode" and "ticks"?

[aprentice]

anyone know what the numbers in the irq demo (pd).gb mean? im getting different numbers than other emus out there :P

[ShizZy]

mono: After the VBlank period, reset LY, Set mode 2 (OAM Transfer,STAT=(STAT&0xFC)|2), request LCD interrupt, add mode 2 cycles, (20 machine cycles). And start back over.

[Dark Stalker]

I made a Gameboy emulator and it runs most games, but it can't get past the opening of Altered Space due to a timing issue. It gets stuck in an infinite loop at 78A.
Executing the vblank interrupt too early will get you stuck on the title screen of Altered Space.


Since I'm not fond of regressions, I'm bumping lameboy to 0.10.1 with the following changes:
- Some changes I did to the halt/interrupt system made "The Smurfs" and "Thunderbirds" stop working. This is fixed.

- Backed down some optimizations as it turns a out that Mortal Kombat 3 actually sets the SP to i/o RAM to change display settings.

- Fixed a silly bug in my DAA opcode that made the counter in Castlevania jump from 9 to 2.

- Fixed a sound initialization bug that sometimes made the sound disappear if the frequency was changed without a reset.

lameboy-0.10.1_linux_i386.tar.gz (http://home.tussa.com/iaamaas/lameboy/lameboy-0.10.1_linux_i386.tar.gz)
lameboy-0.10.1_win32.zip (http://home.tussa.com/iaamaas/lameboy/lameboy-0.10.1_win32.zip)

[aprentice]

Executing the vblank interrupt too early will get you stuck on the title screen of Altered Space.


Since I'm not fond of regressions, I'm bumping lameboy to 0.10.1 with the following changes:
- Some changes I did to the halt/interrupt system made "The Smurfs" and "Thunderbirds" stop working. This is fixed.

- Backed down some optimizations as it turns a out that Mortal Kombat 3 actually sets the SP to i/o RAM to change display settings.

- Fixed a silly bug in my DAA opcode that made the counter in Castlevania jump from 9 to 2.

- Fixed a sound initialization bug that sometimes made the sound disappear if the frequency was changed without a reset.

lameboy-0.10.1_linux_i386.tar.gz (http://home.tussa.com/iaamaas/lameboy/lameboy-0.10.1_linux_i386.tar.gz)
lameboy-0.10.1_win32.zip (http://home.tussa.com/iaamaas/lameboy/lameboy-0.10.1_win32.zip)

Are you requesting a vblank interrupt on line 145 to get wizards and warriors to work? I did this to get it to work but it won't go in game. I also cant get wario land 2 for gameboy mono to work, have you had this problem as well when working on your emulator? also i dunno why our numbers are so different in the irq demo

[Dark Stalker]

Are you requesting a vblank interrupt on line 145 to get wizards and warriors to work? I did this to get it to work but it won't go in game. I also cant get wario land 2 for gameboy mono to work, have you had this problem as well when working on your emulator? also i dunno why our numbers are so different in the irq demo
I haven't actually tested wizards and warriors until you mentioned it now :P I'm requesting the vblank interrupt at the start of line 144, but I'm delaying it's execution by one cycle/instruction. I suspect there may be a tiny latency on all interrupts from the moment they're requested until they're called. I can't remember having any problems with the dmg version of warioland 2, and I don't know what the numbers in the irq demo are supposed to represent.

[aprentice]

I haven't actually tested wizards and warriors until you mentioned it now :P I'm requesting the vblank interrupt at the start of line 144, but I'm delaying it's execution by one cycle/instruction. I suspect there may be a tiny latency on all interrupts from the moment they're requested until they're called. I can't remember having any problems with the dmg version of warioland 2, and I don't know what the numbers in the irq demo are supposed to represent.

is delaying it one instruction your suspicion or is it documented somewhere?

[Dark Stalker]

it's not documented

[bcrew1375]

I've been having quite an annoying problem for some time now. I've tried the suggestion of delaying interrupts, as at first I thought for sure that was it, but it
still has not solved it. Alot of games seem to have a one pixel offset in the drawing, my original suspicion was that the LYC was causing it. In a few games such as Donkey Kong, Earthworm Jim, and Zelda: Link's Awakening(Wow, I mention those games alot :p), I have this problem. Donkey Kong has a problem with cutting off the last line of pixels in the status bar and the very bottom of the screen. Earthworm Jim seems to push its status bar down one pixel. I tried a fix which seemed to solve this problem for both games, but then it breaks Zelda. I'm out of ideas on how to fix it.

aprentice, I didn't have any problems with Wario Land 2, even before trying Dark Stalker's suggestion. So, I couldn't say.

Also, after looking at the code for Wizards and Warriors, I noticed it does something weird. It reads the contents of FF44 and expects them to be 0x90, but it also leaves the interrupts enabled. So, if you do immediately call the interrupt, it won't have time to read in the contents as being 0x90. By the time it gets done with the interrupt routine, it's probably already past line 0x90.

[ShizZy]

Rewrote my entire emulator, now uses DirectX and is much quicker. Now in the process of debugging. Does anyone have any ideas of what could be going wrong in the following screenshot? (Asteroids) It doesn't show the startup logo, but after a few seconds this titlescreen fades in. I traced through the opcodes, and it breaks after opcode 0x22 (changes from that of other emulators). This was in a loop, I checked every opcode from that point to the beginning of the emulation. All seem to be correct, which leads me to believe it is something wrong with IO. Might be stat, but I'm not sure - I've double and triple checked that already. Any ideas?

[bcrew1375]

Well, that is the opcode to load a 16-bit register's value into memory, so maybe the register is trying to load somewhere into memory it shouldn't? Where is it trying to write to?

[TJA]

Hi all I've finally got off my arse and decided to start my gameboy emulator today, I'm going well I think just coding lots of opcodes so far but have a question. When the documentation for the cpu for an opcode such as ADC A, n for example is copying (HL) does it mean because the regester is in brakets that it holds an address to be read from memory and then copyed into A, this makes more sense than my original though that I simply copy the 16-bit register to the 8-bit one

[aprentice]

Hi all I've finally got off my arse and decided to start my gameboy emulator today, I'm going well I think just coding lots of opcodes so far but have a question. When the documentation for the cpu for an opcode such as ADC A, n for example is copying (HL) does it mean because the regester is in brakets that it holds an address to be read from memory and then copyed into A, this makes more sense than my original though that I simply copy the 16-bit register to the 8-bit one

thats exactly the case

[ShizZy]

Well, that is the opcode to load a 16-bit register's value into memory, so maybe the register is trying to load somewhere into memory it shouldn't? Where is it trying to write to? Actually, isn't that opcode supposed to load an 8bit value to a 16bit address in memory, in this case loading A to mem@ HL? Then increment HL.

At any rate the address is 0xc1a3, which is what HL is. Work RAM, not very suspicious there. Hmmmm, any ideas?

I'm going to check what opcodes are writing to that address in the program, other than 0x22, maybe I'll come up with something.

Edit: Nope, only 22 :(

[bcrew1375]

Actually, isn't that opcode supposed to load an 8bit value to a 16bit address in memory, in this case loading A to mem@ HL? Then increment HL.

Yes, I'm sorry. Wasn't paying much attention at the time.


At any rate the address is 0xc1a3, which is what HL is. Work RAM, not very suspicious there. Hmmmm, any ideas?

I'm going to check what opcodes are writing to that address in the program, other than 0x22, maybe I'll come up with something.

Edit: Nope, only 22 :(
You said the program breaks. Do you mean it froze, or stopped executing?

[ShizZy]

No, it doesn't freeze. A very distorted "Code Monkey's" screen fades in after this one.

I meant to say the opcode changes from what it's supposed to be. Should change to 0xc3 (PC=0x0040) after 0x22 (PC=0x097c), but instead it changes to 0xb (PC=0x097d) (ie... the 0xb is part of the next sequence in this loop, which it should be getting out of at this point. But it isn't). I'm assuming this error is one of the factors in the video glitches. PC is getting changed somewhere in the real hardware (or a very accurate representation in other emulators :P) from 0x97c to 0x40, but I don't see where. I double checked all the opcodes up until this point, as well as interrupts.

[ShizZy]

Nailed it :P

Seems it doesn't like calculating the flags after the opcodes, but before instead. Fixed this in add and it worked, I suspect if I fix the rest I might get better compat :) Thanks for the help..

[mono]

Executing the vblank interrupt too early will get you stuck on the title screen of Altered Space.

Yes, I was aware of this. My problem is that I don't know to fix the problem. I know that the reason the vblank interrupt is being called too early is that turning the lcd on and off with bit 7 in the LCDC register throws off my timing. What I was trying to ask was how should I maintain correct timing when the LCD is switched on and off. I looked in the sources of other emulators and found that they all do different things. For example, VBA sets the mode to 0 (H-blank) and runs it for 1140 machine cycles, which strikes me as very odd. I can't find the correct behaviour documented anywhere, so I was hoping I could get an accurate answer here.

[Dark Stalker]

Yes, I was aware of this. My problem is that I don't know to fix the problem. I know that the reason the vblank interrupt is being called too early is that turning the lcd on and off with bit 7 in the LCDC register throws off my timing.
Are you sure? Did you read my comment on interrupt latency?


What I was trying to ask was how should I maintain correct timing when the LCD is switched on and off. I looked in the sources of other emulators and found that they all do different things. For example, VBA sets the mode to 0 (H-blank) and runs it for 1140 machine cycles, which strikes me as very odd. I can't find the correct behaviour documented anywhere, so I was hoping I could get an accurate answer here.
The only way to know for sure is to get ahold of a flash cart and do some tests on the real hw.

[aprentice]

i can't get any sound output from directsound other than pops and clicks, how did you build a sample out of gameboy raw wav? If I understood correctly every sample can be 16 bits and the gameboy sample is 4 bits, what would i fill for the other 12 bits? direct sound is so confusing.. I also dont get sample rate and latency..

[refraction]

i can't get any sound output from directsound other than pops and clicks, how did you build a sample out of gameboy raw wav? If I understood correctly every sample can be 16 bits and the gameboy sample is 4 bits, what would i fill for the other 12 bits? direct sound is so confusing.. I also dont get sample rate and latency..


you could try doubling up the samples and outputting at 8 bits

[Dark Stalker]

Bigger sample sizes simply give you higher resolution for the relative amplitude/volume of the wave. You can multiply/leftshift the sample to get a louder output.

The frequency of the sound wave usually refers to the time it takes for it to complete one oscillation (going from high to low and high again). A higher frequency will give a lighter tone, and a lower frequency will give a darker tone. A sample represents the amplitude of a position in the wave. In other words, if every alternating sample you output has a low value while the next one has a high value, you'll get a really high pitched square wave.

Now, if the game boy was sample-based, it would have something like a sample rate of 4194304/2=2097152 Hz. Your task will be to downsample this to the sample rate of the output. Probably the most crude way to do this, is to genereate a sample for every 2097152/SAMPLERATE Hz. A better way is to account for all samples, using a form of interpolation. Linear interpolation should be fine in most cases.