Game Boy

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

 

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

 

[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

 

[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 . He's been awfully quiet...

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

 

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