Game Boy

[GbaGuy]

On the rotate opcodes, do you need to shift the register or just swap the necessary bytes?

A rotate is a shift, the difference is what you do with the bit that gets
shifted out.

-----

As an update on the "emu team", none of us have had very much
time lately, as real life has struck everyone pretty much simultaneously.

to all, and to all a good nite... er... tomorrow... er... it's 12:07 AM...
I'm gonna sleep now...

 

[glVertex3f]

I was reading the docs and on some of the opcodes it has disp.

 30    JR   NC,disp

what does disp mean?

 

[bcrew1375]

disp is disposition. It's a signed 8-bit offset.

LOL. I just realized what word I wrote there. I think displacement would be better .

 

[glVertex3f]

Doh, thank you.

I have gotten just about every single opcode done (right or not has yet to be determined).

Also ran across a few more things that confused me.

1) I suppose dd is the same as disp?
2) Some of the "CB" opcodes have a +n*38 I would really like to know why it is like that. If I were I cat I would be dead from curiosity.

And I completely didnt even think about the memory holding signed values... I suppose that woould make the memmory a char array and not an unsigned char array.

disclaimer:
Anything that has been said either directly or implied, cannont be held against glVertex3f on account of it being 1:42AM and that glVertex3f has been programming all day.

Goodnight, I am now going to go get in my program and cover up with the main function.

for(int time = 143; time <= 1200; time++) {
    glVertex3f(SLEEP);
}

 

[bcrew1375]

The memory is usually emulated as unsigned. Certain instructions interpret the data as signed.

Answer to number 1: I'm not sure, where have you seen that abbreviation?

Answer to number 2: I'm not sure why it was written like that. Replace 38 with 8 and it should make more sense. For instance, opcode 0x40 checks bit 0 of register B, 0x48 checks bit 1 of B...

 

[glVertex3f]

E8 ADD SP,dd

it was in the docs that you posted, the "nocash hackwork" one.

 

[bcrew1375]

In that case, it would also be a signed 8-bit value.

 

[glVertex3f]

Do you think possibly that dd is 8bit while disp is 16bit?

And does disp differ in any way from nn notation. It doesnt explain the differences but there obviously must be.

 

[bcrew1375]

I am positive they are both signed 8-bit values. The difference between dd and nn is that nn is unsigned.

 

[glVertex3f]

Well here is my code so far. Most of it has been done in the past two days.
I have programmed all of the opcodes and thats about it. I havent checked the correctness of the functions but I made it so fixing bugs would be very simple. I am now going to go read and figure out how to implement the drawing stuff. (I know how its done just not sure how to implement it).

And for once I am not posting code for anyone to "check" it for me.

And keep in mind that I havent checked this stuff and I have no way to test it since I havent done the drawing code.

:icecream:

 

[zenogais]

Well after having had my wisdom teeth out and being knocked out on meds for a few days, I worked like hell and finished my CPU core not to mention added a few new features to my emulator. Heres a pic of the ROM information window:



I'm working on video emulation at the moment at hope to be finished with that soon. The sources have been attached, and the CPU core is ugly, so there's your early warning

EDIT: Also wanted to mention, theres alot of extra stuff inside that source file (i.e. Win32ErrorDialog.hpp/.cpp), this is stuff that I'm working on for a general emulator framework as having worked on about 4 now I find that I'm constantly writing the same stuff (Memory, Video, Controls, GUI, Error Handling etc...), so I'll keep you guys posted as I progress on that.

 

[bcrew1375]

Looking nice. I did notice one minor problem. When you echo memory writes, it should only go from C000-DDFF and E000 to FDFF. If you write above FDFF, you're going to be writing into the OAM or the I/O registers.

 

[zenogais]

Thanks for that, hadn't done much dealing with memory mapped I/O bits yet, but I'll fix that. Also, how is your emulator progressing?

 

[bcrew1375]

Well, alot of games are playable now. I've been slacking lately. I haven't done any real work on it in the last week . I've been kinda stressed, and am just relaxing a bit.

 

[aprentice]

Well, alot of games are playable now. I've been slacking lately. I haven't done any real work on it in the last week . I've been kinda stressed, and am just relaxing a bit.

Fixed a huge bug in my emu, now about 95% games are fully playable
Enabled that dusty opcode profiler i coded ages ago and looked at every opcode that the game executed until i found one that was rogue
I also implamented mbc5, and WRAM banking, not sure how accurate, since I haven't got gameboy color games that use double speed mode running
I also finished up what I think is complete interrupt support, so now I can focus on cleaning up the emu a bit

Edit: I've been slacking this past week aswell, last night i tried touching the emu but I ended up just opening the source and falling asleep on my bed

 

[glVertex3f]

I am correct in assuming that when they say that (for example) AF register is

(REG_A << 8) + REG_F

right?

I was just wondering because in one of the docs it says to load AF with 0x1 and then after that it says to load register F with 0xB0.

 

[bcrew1375]

AF is a 16-bit register. A is the high byte of this register and F is the low byte. So if I load F with 0x00 and load A with 0xFF, AF will then equal 0xFF00.

BTW aprentice. How could a non-existant opcode screw your emulator up that much? If it doesn't exist, then games wouldn't have it in their source, and so it should never be executed. So, how did that happen? Or maybe by rogue you just meant an opcode that wasn't functioning correctly .

 

[aprentice]

AF is a 16-bit register. A is the high byte of this register and F is the low byte. So if I load F with 0x00 and load A with 0xFF, AF will then equal 0xFF00.

BTW aprentice. How could a non-existant opcode screw your emulator up that much? If it doesn't exist, then games wouldn't have it in their source, and so it should never be executed. So, how did that happen? Or maybe by rogue you just meant an opcode that wasn't functioning correctly .

opcode that wasnt functioning correctly

It doesnt look pretty ingame though, lots of work to do

 

[glVertex3f]

bcrew, thats my point, look what the doc says

AF=$01-GB/SGB, $FF-GBP, $11-GBC
F =$B0

Loading F with B0h would completely undo loading it with 01h/FFh/11h...

Apretice, nice job! That has to give you a great since of accomplishment, if I ever get that far I think i'll crap my pants.

 

[aprentice]

AF=$01-GB/SGB, $FF-GBP, $11-GBC
F =$B0

Loading F with B0h would completely undo loading it with 01h/FFh/11h...

That means A gets loaded with 01 for gb mode etc and F always gets loaded with B0 regardless of gameboy mode.

A and F together form 01B0 for gameboy mode, 11B0 for gbc mode.