Game Boy

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

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.

 

[aprentice]

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.

I'm sure what you're saying right now makes sense to you since you apparently mastered this stuff but to me it makes little sense, did you use direct sound for your emulator?

Each gameboy sample is 4 bits, and in direct sound i have it set up as 16 bits for each sample, so am i suppose to shift 8 or 12 bits to make it louder? And do i have to do anything to each sample to control the frequency because i see direct sound has a SetFrequency function but that wouldnt control it for every sample..

 

[bcrew1375]

Dark Stalker, I noticed your emulator has one of the same problems with Donkey Kong as mine. It shows a white blank area at the bottom where the status screen should be when you complete a level. Any idea what might be causing it? Also, I'm surprised that you already have the sound down. I've noticed a few jerks in it, but other than that it sounds great.

 

[Dark Stalker]

(By "amplitude value" I really mean the position on the y-axis of a typical wave-drawing. I can't find the right term, and in a square wave the displacement is always as big as the amplitude anyway.)

I'm sure what you're saying right now makes sense to you since you apparently mastered this stuff but to me it makes little sense, did you use direct sound for your emulator?

I used SDL, which wraps around DirectSound on windows.

Each gameboy sample is 4 bits, and in direct sound i have it set up as 16 bits for each sample, so am i suppose to shift 8 or 12 bits to make it louder?

There is no such thing as an actual game boy sample (unless you refer to ch3). The amplitude of the waves generated by each channel indeed has a range of 0-15. Additionally there is the output level of SO1 and SO2 which range from 0-7, which the final amplitude will be multiplied by. The value of a sample represents the "amplitude value" of a position in the sound wave. If you multiply each sample's value, you will get a louder output. There's no rule for what's the right average volume of the output, as long as one sample isn't amplified more than another. That said, I'm currently multiplying the value of the individual samples I'm generating by 64, since that seems to yield an overall volume similar to most other things outputting sound on my comp.

And do i have to do anything to each sample to control the frequency because i see direct sound has a SetFrequency function but that wouldnt control it for every sample..

No, you don't. As I said, each sample only represents an "amplitude value". Frequency refers to how often this value changes. The sample rate is how often a new sample is generated/expected (typically 44100 Hz). Generally, the higher the sample rate, the more accurate the representation of the sound wave, since you can support more fine grained changes and higher frequencies. What matters for the notes of the melody is how often the values of the samples you output change from high to low (and back). If you ignore a channel's volume/amplitude/envelope register, and just use a fixed value, you will generally still be able to produce the notes of the melody. You need to keep counters for how many high/low samples you've outputted depending on the frequency (and wave duty) of the channel.

Dark Stalker, I noticed your emulator has one of the same problems with Donkey Kong as mine. It shows a white blank area at the bottom where the status screen should be when you complete a level. Any idea what might be causing it? Also, I'm surprised that you already have the sound down. I've noticed a few jerks in it, but other than that it sounds great.

No, I haven't tested that game. Thanks for letting me know. What kind of sound jerks? Some of them are supposed to be there...

 

[Dark Stalker]

Tada!

It seems that if the window is enabled, then disabled, and enabled again later the same frame, it will continue drawing from the same position in the tile map.

 

[ShizZy]

Nice work I don't know how you do it. About 3 commercial games run for me, but I don't no how or where to look for bugs. There's got to be tons of them. I'll spend hours without any luck. Any tricks?

 

[Dark Stalker]

More fixes for Donkey Kong: It appears that Donkey Kong was treating my emu as an sgb. This made some garbage appear on startup, and made the princess mute. The reason was that the game expects the unusable bits (6 and 7) of 0xFF00 to be set. The game did "ld a,(ff00); cp a,ff; jrnz;" which always ended in a jump.

ShizZie: I'm afraid there aren't any tricks. I usually try to find something that affects the bug as a starting point. Sometimes it's just easier to guess where to look than other times.

 

[ShizZy]

Alrighty thanks, I'll see if I have some better luck later tonight.

 

[truth2]

Well... I'd like to say that I recently started writing a GB emu and it didn't progress very well, but I can't.
I started writing the emu way back in September (although I did do a few large pauses and rewrote the whole thing from scratch twice) and now, it's pretty basic:

i have:
all GB opcodes are (hopefully) supported
all IO except sound and serial (hopefully) works correctly
video display (hopefully) works decently:
backgrounds are (hopefully) fully supported
windows might lack some special 'effects', not sure
sprites are so-so supported, but im sure there are priority issues

i dont have:
sound, serial and sgb (and i won't be doing that till/unless everything else will be mostly fine, and even then it's doubtful)
gbc (meh... maybe when most gb stuff is working)
nice features (savestates, non-violent user interface, etc..)
correct timing - im sure lots of my timing is brutally incorrect.
mbc (im currently working on this, but im getting kinda stuck...)

meh...

 

[ShizZy]

Nice... get it working and post some shots

 

[truth2]

Nice what?
And apperantely I got some CPU bugs too, because some othello game (the only commerical game I could find that is not using MBC) decided to take the scenic route through the code, passing through a few illegal opcodes (i didn't bother making the emulator stop when such are reached) and ending up in a nice loop of ff's
also the Big Scrolling Demo is acting weird : sometimes it does shows too much of the "cubes" background and too little of the "text" background, and sometimes the opposite...

i just tried tetris and it gives me a weird screen (white on top, black on bottom, nothing else) and when i checked my half assed debugger, it also got stuck in a loop of ff's.