Game Boy

[bcrew1375]

As far as I know, this is what everyone's been using: http://www.work.de/nocash/pandocs.htm

As far as timing, you simply count the cycles for each instruction and simply tie the interrupts and IO registers to that.

 

[ChaosBlade]

I understood that much from reading the thread and from zenogais, but it seems to me that its too simple just being that. Timing is a serious issue when emulating, and ive seen people comment about spending hours and even days just to fix timing, which seems odd if its just that. I could be wrong though (refer to my last post as to why ).

 

[bcrew1375]

Well, there's the timing of the emulator program, and then there's the timing of the emulated system. The emulator program needs to be restricted to running only the number of cycles per second that the original CPU would allow. The Gameboy has a timer that programs use to call code at specific intervals. They are 4096, 16384, 65536, and 262144 Hertz. That means they interrupt 4096, 16384, 65536, and 262144 times per second, respectively. As far as I know, the Gameboy has a machine speed of 1.048576 MegaHertz(4.194304 Megahertz clock speed). So, you would take 1048576 / Timer frequency, and that would give you the number of cycles you need to run before calling the interrupt. Hope that's clear .

 

[HyperHacker]

Interesting how this thread popped up in Similar Threads. Anyway, what exactly are you supposed to do with the memory at FEA0-FEFF?

 

[aprentice]

Interesting how this thread popped up in Similar Threads. Anyway, what exactly are you supposed to do with the memory at FEA0-FEFF?

Learn to use http://www.work.de/nocash/pandocs.htm

 

[HyperHacker]

Yes, but all that says is "unusable"; what does that mean? Would it read as 00 or FF or what, and what would happen if it were written to?

 

[bcrew1375]

Yes, but all that says is "unusable"; what does that mean? Would it read as 00 or FF or what, and what would happen if it were written to?

It means just that, unusable. If you write to the area, it won't be written at all. If you read from it, you will get undefined data, which means the data is unknown.

 

[Dark Stalker]

Well, there's the timing of the emulator program, and then there's the timing of the emulated system. The emulator program needs to be restricted to running only the number of cycles per second that the original CPU would allow. The Gameboy has a timer that programs use to call code at specific intervals. They are 4096, 16384, 65536, and 262144 Hertz. That means they interrupt 4096, 16384, 65536, and 262144 times per second, respectively. As far as I know, the Gameboy has a machine speed of 1.048576 MegaHertz(4.194304 Megahertz clock speed). So, you would take 1048576 / Timer frequency, and that would give you the number of cycles you need to run before calling the interrupt. Hope that's clear .

Not to mention video modes, lyc, serial transfer, sound, dma, rtc etc. Strict timers are simple, since it's pretty clear when to do them.

 

[bcrew1375]

Yeah, I always forget to mention the guts of it. And, um, I don't think you worry about the time for the DMA. You use it by writing to memory, the OAM data is copied to memory in a few microseconds, but the game waits for that to be completed before continuing. You shouldn't need to worry about timing the DMA.

 

[ChaosBlade]

Considering i havent worked with timing issues before im expecting trouble whenever ill grab this project up

 

[Dark Stalker]

Dma takes a certain number of clock cycles that need to be accounted for, if you are to believe the docs that insist that the cpu halts until the transfers are done. At least for hdma and gdma. Still, doing that seemed to break things, so I suspect that either the docs are wrong and the cpu doesn't halt, or they just fail to mention that everything else halts too, so that it doesn't really matter. Gnuboy hackers question dma timings too, as seen on their front page.

Also, interestingly, some of the the video modes exist strictly for timing purposes, as the game boy screen doesn't really have a physical hblank time.

 

[HyperHacker]

You don't have to time the actual DMA transfer, but it has to leave the memory inaccessible for ~160 emulated microseconds and set the 'DMA complete' flag. Most games go into a tight loop in the FF80-FFFE area (the only area accessible during DMA) that waits exactly this long.

 

[Dark Stalker]

Yes, that's basically quoting the docs on regular oam dma transfers

edit: Wait a minute, there is an oam dma complete flag to set? I thought the reason the games loop for a set number of cycles was because there is no feedback on when the oam dma transfer is complete.

 

[ShizZy]

Yeah bcrew, it's the same loop. But, there are still a lot of things that I'm not quite sure about, so I think that I am going to do a little more work on my Chip8 emulator, and then come back to this project. I am hoping that it'll give me a firming grasp on the whole concept of emulator programming.

 

[ChaosBlade]

It will certaintly help - Im saying this from personal experince.

 

[ZeroEffect]

I'm having a little difficulty with the 8-bit ALU instructions involving HL (eg ADD A, HL). Maybe I'm just over-complication...

Is this as straight forward as adding the low 8-bits of HL to A and setting the flag appropritely (where a carry occurs on bit 7)? I've read in several places that AF is in some cases used as a 16-bit register, would this be one of those situations, and if not, what would be an example of where AF is used.

 

[bcrew1375]

If it's "ADD A, (HL)" that you are talking about, it means to add the memory contents at address HL to register A.

 

[refraction]

If it's "ADD A, (HL)" that you are talking about, it means to add the memory contents at address HL to register A.

it will be that, i know no gameboy opcode that tries to cram a 16bit register into an 8 bit one lol.

you want something like register.A = memory(register.HL);

depending on how youve laid it out

 

[ZeroEffect]

So anytime an ALU opcode indicates (HL) in the docs, (HL) is an address. Thx

 

[Pontifice]

all "(number)" refers to memory[number]

I'm searching a simple rom to debug a GB emulator someone knows about one ???