Game Boy

[Dark Stalker]

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

That 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.
- 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
- Preliminary readme.


Downloads:
SinGB-0.8.3-win32 475.8kB.
SinGB-0.8.3-linux 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

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

 

[bcrew1375]

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

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. 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 ).

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.

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 . 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. I was kind of in a rush earlier, I had to be to work in about 15 minutes .

 

[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?

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. Let's see if we can't fix that...