Chip 8

[ShizZy]

Nice job Yosh. Looking forward to seeing your progress in the GB Emu thread. Mine is coming allong...

 

[Doomulation]

AND chip8def.htm

It's funny how people keep linking to that document, because it is in fact, faulty! The last two ops are incorrect. I does not increment.
Nevertheless, it's good to see another make a chip8 emu.

 

[maxpert]

Hi guys,
here is my emu it is called Chirp :icecream: ...
I coded it completely using win32 api and opengl with 100% C
(No cpp extention). Hence it is very fast. Now I want to control its speed and add some keyboard controls to it.

 

[Doomulation]

It doesn't matter in what you do it in, as long as you do it right. Great to see another emu.

 

[cloudy]

Hey all,

Well I started coding the chip8 emulator without looking at any documentation but the opcode table and I managed to code half of them correctly but Im having trouble with the other half.

Where Im having the most problems is with the "logic" behind it, for instance im not sure what the following piece of code does.

void FetchOpcode()
{
	Opcode =  memory[PC] << 8 | memory[PC+1];
	PC += 2;

}

I understand why 2 is added to the program counter, I just dont understand the rest of it (well just the "Opcode =" line)

void ShiftRegRight()
{
	arrcRegisters[0xF] = arrcRegisters[REG_X] & 0x1;
	arrcRegisters[REG_X] >>= 1;
}


void ShiftRegLeft()
{
	arrcRegisters[0xF] = arrcRegisters[REG_X] >> 7;
	arrcRegisters[REG_X] <<= 1;
}

I dont understand what is happening in the above two functions. Its when the following is used that i dont understand, << and &.

So if you could explain whats happening in the code above or if you could give me a link to a tutorial which will give me the basic understanding of the "logic" side of emulator programming (I guess its probably going to be a tutorial on ASM) then that'd really help me out.

As I said I coded half of the Opcodes correctly with no help but opcode table, It's just the Opcodes that are more logic based like the ones stated.

Thanks for any help.

 

[bcrew1375]

Okay, the "<<" and ">>" mean "shift left" and "shift right", respectively. The "&" means a logical AND.

Shift left means shift the bits of a variable to the left. For instance:

"00000001"(1) shifted left once would be
"00000010"(2), this shifted left again would be
"00000100"(4), so shift left is effectively multiplying by 2(Note, if the 7th bit is on, and you shift left, the 7th bit disappears, and is replaced by the 6th bit. Bit 0 will have 0 shifted into it.

Shift right is the opposite. It effectively divides the variable by 2.

AND basically compares two variables. If the bits in each variable are on, they remain on, otherwise they are turned off.

"00010010"(18) ANDed with
"00101110"(46) would be
"00000010"(2)

Hopefully that isn't too confusing .

 

[cloudy]

Hey mate,

Thanks a lot for the reply. I do understand everything that you explained but I fail to see why it is being used in the coding below:

void FetchOpcode()
{
	Opcode =  memory[PC] << 8 | memory[PC+1];
	PC += 2;

}

Why is the Opcode being set to memory[pc] << 8 | memory[PC+1]?

I know that the Opcode is being set to the memory[pc] value which is shifted to the left 8 times and then or'd with memory[PC+1] but I dont understand why.

Just like I dont understand whats happening in the other code I posted above.

Thanks again for your help mate

 

[hap]

Because 'memory' is a byte array, and chip8 opcodes are 2 bytes long

example:
memory[pc]=0xaa
memory[pc+1]=0xff

opcode=0xaa<<8|0xff=0xaaff

 

[bcrew1375]

What hap said. You shove the first byte of the opcode into the upper 8-bits and then put the second one in the lower 8-bits. So, with the hex numbers hap said.

memory[PC] = 0xAA
memory[PC+1] = 0xFF

opcode = memory[PC] (0000000001010101) = 0x00AA
opcode = memory[PC] << 8 (0101010100000000) = 0xAA00
opcode = (memory[PC] << 8) | memory[PC+1] (0101010111111111) = 0xAAFF

 

[Sdw]

Progress update

A little progress update from me. A few pages ago I posted some screenshots from my CHIP8 emulator for J2ME (cellphones etc.) called MobiChip. I've now added SCHIP aswell, and it's working pretty good.
I did however have problems with some game ROMs not working properly, now I don't know if it is because my emulator is faulty, or the maybe the guy who wrote the ROM just happened to have some bugs in it!
Since debugging stuff like this can be a tough when running in J2ME, I ported my CHIP8/SCHIP emulator core to C++, slapped on a MFC frontend and also wrote a dissassembler to create a combined emulator and CHIP8/SCHIP debugger:

Now I can single step through the ROM, monitor the registers etc. In the screenshot you see me single stepping through the SCHIP game "Car".

I plan to release this utility later, I think it could be useful for both people who want to write CHIP8/SCHIP software, but also to people who are developing their own emulator, as it is easy to see what the expected behavior of instructions is (see what registers are affected etc.)

 

[Doomulation]

Hehe... but most people do write their own debuggers. That looks like great progress, though.

 

[Sdw]

Actually I haven't seen any CHIP8 emulator with a real good visual debugger yet, but I have only tried a few emulators (the ones I found at Zophar), I'm guessing there are a LOT!

 

[hap]

Yeah, Zophar's a bit behind with its emulator archives. If you want any Chip8 emulator, just check this thread

 

[Fastolfe]

SCHIP backwards compatibility with half-pixel scrolling?

Are the CHIP8 and SCHIP8 varieties totally independent, or is SCHIP intended to be an "enhanced" mode backwards-compatible with regular CHIP8 games?

I ask because earlier posts seemed to indicate that in SCHIP "mode", scrolling should be performed with SCHIP resolutions, even in "low" mode. So if you were playing a game with CHIP8 resolution, but in SCHIP "mode" (???), scrolling should appear to be performed with half-pixel precision. Is there a resource that explains this any better?

I was under the impression that the SCHIP functionality was just an "extension" to a regular CHIP8 environment, so if you were playing a game in CHIP8 mode (either by not executing a "high" opcode, OR by using the "low" opcode explicitly), all of the opcodes should execute just as they would have in a vanilla non-SCHIP CHIP8 manner, including scrolling.

In other words, I don't quite understand why scrolling 1 "unit" should scroll a half-pixel when we're running at standard 64x32 resolution.

Sorry if I'm missing something basic! Thanks for your help.

 

[hap]

Have you read David Winter's documentation ? Specifically, chapters 1.4, and 1.5 "notes": http://www.pdc.kth.se/~lfo/chip8/CHIP8.htm

 

[Fastolfe]

Thanks for the kick in the butt, hap. I had reviewed that documentation when implementing my emulator, but I didn't look at it closely enough to realize that all of the scrolling operations WERE SCHIP opcodes. So, effectively, any program using the scrolling opcodes is, by its nature, a program written for the SCHIP, so these rules would be anticipated.

I was under the mistaken impression that the scroll operations were present in CHIP8. I couldn't figure out how this operation was supposed to have two behaviors like that.

Looks like I'll need to re-work my graphics layer since I made this bad assumption. (Fortunately it doesn't look like I was alone!)

Thanks again for the tip.

David

 

[Doomulation]

Yes, basically, the schip8 is an enhanced chip8 with double precision and some extra instructions.

 

[weston]

Hello, first post here! I actually read most of this thread about a week ago and I've pretty much finished my CHIP-8 emulator since then. I'm coding it in java with opengl. I know there are a lot of java skeptics on here so I've put up a page with some screen shots to tempt any who would refuse it because of its java-ness http://www.cyntaks.com/projects/chip8 If theres one thing I'm proud of about this emulator its that I got rid of the damn flickering!! (and the option to enable it is still there for those who want an epileptic seizure).

While the emulator is nearly complete, there are a couple problems I've run into that I'd like to fix before I implement the schip features. The first of these has to do with boundary conditions, although I suspect its actually caused by some broken instruction. The problem shows up in the games Tapeworm and Syzygy (now that I think of it, there is something else funky going on in syzygy too..), if I move my worm off the screen in the negative-y or negative-x direction the program crashes (array out of bounds when drawing pixels). Now I could avoid this by just not drawing anything that is out of bounds, but this doesn't solve the problem because it should really be wrapping (note: it does wrap if the worm leaves in the positive x or y direction). I realize this probably isn't possible to debug from here but since there are so many people on here that have written chip-8 emulators I figured I'd just throw the problem out and see if anyone else had seen/solved it.

two other issues I'm having: garbled tetris pieces, mis-placed tic-tac-to pieces, and if I watch the scrolling text on space invaders for a while it becomes garbled. This sound familiar to anyone?

/me continues looking.

 

[zenogais]

All of that sounds very familary Basically for screen wrapping just make sure you've coded the proper checks, i.e. ensure x and y are positive and withing bounds and if not use modulo or AND to wrap them around, something like this:

// Wrap if too small
if(x < 0) { x = X_MAX; }
if(y < 0) { y = Y_MAX; }

// Wrap if too large
x &= X_MAX;
y &= Y_MAX;

writePixel(x, y);

Usually the cause of crashes like that is a lack of proper error-handling/error-coping mechanisms.

Also the garbled text may be caused by the fact that you aren't drawing pixels or setting pixels correctly. I had a similar problem and it turned out to be a bug in how I setting/clearing pixels. Hope this helps.

 

[weston]

I actually have used the screen wrapping before but removed it because I'm convinced it is not the solution to my problem. First of all I've read on here that the only game which requires the wrapping is a game called Field where a bird goes out of bounds. I am having bounds problems with other games, so handling them by wrapping would be a workaround and not a solution. This is why I say I think the problem is in some so far unkown instruction.

If I do add the wrapping, I get some interesting effects which I'm guessing are caused by the fact that I'm wrapping when the game doesn't expect it this can be seen in ufo where the 'ufo' gets to the left side of the screen, wraps to the right and gets stuck. Same thing happens in tapeworm. Here is my wrapping code.

for (int i = 0; i < pixels.length; i++) 
{
      int x = (xOff + i%width)%MAX_X; //wrap if too large
      int y = (yOff + i/width)%MAX_Y;
      
      //wrap if too small
      if(x < 0)
        x = MAX_X;
      if(y < 0)
        y = MAX_Y;
      
      if(setPixel(y, x, pixels[i])) 
           collision = true;
}

so I think the games that have sprites going off the edge actually attempt to handle this condition in their code but it is failing because of some broken instruction of mine.

>Usually the cause of crashes like that is a lack of proper error-handling/error-coping mechanisms.

hmm, well I think this crash was caused by a messed up instruction that caused the game I was running to perform an invalid operation. If the game tries to render outside the screen, I would personally rather have my program freeze and point me to where the problem occured then to go on silently operating incorrectly.

As for garbled text, all the text I've seen looks fine except for when I watch the scrolling message at the beginning of space invaders for a long time. Is this the problem that you had also?

I should have been more clear in my original post, I'll try not to be so vague in the future. If I were you I probably would have given the same answer to my wrapping problem since I know lots of others on here have had that problem