CHIP8 thread

[Hatorijr]

in my latest build of chip 8, almost every game i have works except a few hybrids i have that do not work due to not emulating the boot stuff because i could never find much of anything on that but besides that i think there are only a few games i did not bother to fix bugs in because it was not really worth my time, i have almost 120 games working and i even got one demo working that used the hp48 flags using trial and error. if anyone knows how those flags are really supposed to work, i would really appreciate it .

[runawayprisoner]

Originally Posted by hap

Ohh Sokoban in colour!

Does it work well in your emu? I've seen it messing up on later levels on some emulators due to a bug with carry,
like this: V[F]=carry; V[x]=calculation;
while it should be: int temp=carry; V[x]=calculation; V[F]=carry;
The 1st implementation would cause a problem with eg. "add V[0],v[F]".

I'm not too sure whether it works for all levels, but I have tried a few later ones (the 3x 4x levels) and they worked well. I've attached the emulator so you can check it out yourself. Source codes will be released when I've finished cleaning them up.

Enjoy the colors. If you don't like the current pallete, restarting the jar file will also restart it and give you different colors. I'll give users the ability to store and save different palletes for different games once I've fully implemented the coloring engine.

There are also a few games included. As stated before, Worm 4 and Brix might still have coloring bugs.

And some games are dead slow on a 1.00GHz Celeron M thanks to the filter, but I can't be arsed to remove it. Hopefully you're on a faster machine than what I'm using right now. A Celeron L or Core 2 Duo will undoubtedly do the trick at fullspeed for everything you throw at it.

Oh yeah, and check out Maze. It's the reason I left the filter in.

Originally Posted by Hatorijr

if anyone knows how those flags are really supposed to work, i would really appreciate it .

Ah... the "flags". In my opinions, those are more like "registers" than "flags". Basically, what they are is a set of 8 registers, from and to which you can store your corresponding V registers.

Assuming they are named R registers (short for RPL):

The store instruction Fx75 stores your V[0] to V[x] registers in those R[0] to R[x] registers.

The read instruction Fx85 reads the data from R[0] to R[x] to V[0] to V[x].

That's it. No magic. Highest value of x is 7, though you can pretty much extend it to 15 to match the original 15 V registers, though I haven't seen a program that makes any use of that.

Attached Files

schip.7z (43.5 KB, 8 views)

__________________
cChip interpreter WIP - current status: Release Candidate
LRx Filter RC - current performance rating: 9/10

[serge2k]

I just recently (yesterday) restarted my emulator again (3rd or 4th time, kept getting stuck then sidetracked).

Anyway, C++ and directx this time.

So far I think I have most of the opcodes done.
Input works as far as I can tell.
The speed it decent, not lightning fast but okay. Looking for more optimizations.
Graphics are there but only seem to be right for pong. Even then the paddles flicker constantly. Haven't implemented collision yet either.

I was wondering what exactly is supposed to happen when something goes offscreen (bottom or side)?


so far my code is very rough (a fair is amount is just removed from tutorials and then modified)

Attached Files

Chip 8 Emulator.rar (561.5 KB, 4 views)

[Dax]

a fair is amount is just removed from tutorials

You're just copy pasting code? Bad serge.

__________________

My PC Specs|My Consoles|Emu SVNs|Project OSX|How to ask a Question

[Hatorijr]

yea i am talking about the R registers, does anyone really know what their values are supposed to be or is it just mainly a guessing type of trick to getting the games that use them to work right? i have a schip demo that uses them as the value makes a box scroll side ways than up and down before stopping, and the amount it scrolls is dependent on the values in 2 of the R registers.

[hap]

Originally, the SCHIP interpreter was developed for HP48 calculators. The HP48 has 64 1-bit (=8 bytes) system flags. Some SCHIP programs are actually part HP48, part SCHIP, eg. Ant has a nice titlescreen on HP48, and programs like that SCHIP scroll test or Loopz let the user change settings and store these in the flags so the program can read them out later.

Since your interpreter is not for the HP48, just clear all flags and/or let the end-user set them up.

[Hatorijr]

but clearing the flags, certain games that need the R flags to be set to some value, wont work. but work when a random value is used, but guessing those values is most likely not the best way to go.

[runawayprisoner]

Originally Posted by serge2k

The speed it decent, not lightning fast but okay. Looking for more optimizations.
Graphics are there but only seem to be right for pong. Even then the paddles flicker constantly. Haven't implemented collision yet either.

The paddles are supposed to flicker constantly. There's really not much you can do there...

If you use a tripple-buffering method to check VRAM matches then maybe you can deliver the game completely flicker-free, but drawing will be delayed, which makes the game feel a bit unresponsive.

I was wondering what exactly is supposed to happen when something goes offscreen (bottom or side)?

It wraps around to the other side. As in... if it goes off the right side then it comes back in from the left side, and if it goes off the bottome then it comes back in from the top. Note that the game Tank makes heavy use of this. Also, check your coordinates before passing them off as drawing coordinates.

Originally Posted by Hatorijr

but clearing the flags, certain games that need the R flags to be set to some value, wont work. but work when a random value is used, but guessing those values is most likely not the best way to go.

Actually, there's not too much guessing here as you'd think.

The flags are only used to store the values of the V registers, like I said above.

So for instance... assume we are storing V0, the R0 "register" (flag 0 to flag 7) would contain the bits as set in V0. Say... if V0 is 0x88, which is 10001000, then the flags would be set as follow:

flag : 0 1 2 3 4 5 6 7
value: 1 0 0 0 1 0 0 0

And so on... Like hap said, there's 64 flags, each is 1-bit long (but really, I don't think there's a point to having flags that are more than 1 bit long). But in my opinions, you are better off treating them as groups of 8 flags, or a bunch of extra 8-bit registers, as that's what the instructions treat them as. The flags are not checked or used in any other way.

I also discovered that in some games, the drawing coordinates are intentionally set to large values... (higher than 127 horizontal and 63 vertical), plus the VF flag is actually... set and unset in any operation that requires a carry/borrow flag regardless of whether that's in the documentation or not, or at least quite a few games assume that behavior. hap also said this in the Chip-8 thread on emutalk like... 3 years ago, but I didn't get to there. Try that and see if you'll get some results.

Also the I register may go well off the memory limit (0xfff), so you might want to make sure it wraps back to the other side... (the other side starts at 0x200, by the way... so if the pointer reaches 0x1000, for instance, then it goes back to 0x200)

__________________
cChip interpreter WIP - current status: Release Candidate
LRx Filter RC - current performance rating: 9/10

---

Last edited by runawayprisoner; May 31st, 2009 at 18:13..

[ShendoXT]

Originally Posted by hap

Ohh Sokoban in colour!

Does it work well in your emu? I've seen it messing up on later levels on some emulators due to a bug with carry,
like this: V[F]=carry; V[x]=calculation;
while it should be: int temp=carry; V[x]=calculation; V[F]=carry;
The 1st implementation would cause a problem with eg. "add V[0],v[F]".

I believe mine has that problem. Hm, maybe this is the right time to fix that.

__________________

C2D E8400 3.00 Ghz | EP45-DS3 | HD4850 512MB | 4GB DDR2 800 | 640 + 250 GB HDD
SyncMaster 2233BW 22" | Logitech G5 | Logitech G15 | Windows 7 x64

[serge2k]

Originally Posted by Dax

You're just copy pasting code? Bad serge.

a lot of my graphics and input code is based on a tutorial.

everything else I did, but I'm still trying to learn the graphics stuff.

[Dax]

I thought you meant the entire emu.

__________________

My PC Specs|My Consoles|Emu SVNs|Project OSX|How to ask a Question

[serge2k]

no just the directx stuff.

well and the windows stuff but thats just because I hate typing it all out.

pong is almost working, only problem wiht it now is that for some reason it only detects one score.

I'm also having problems with collision, it's supposed to be a collision when a pixel is erased right?

edit: fixed pong, had a < instead of <= on Fx55 and 65

so far pong2 is perfect
pong is fine except that when I wrap around the screen from top to bottom is leaves an image of half the paddle at the top of the screen.
Invaders - the SPACE INVADERS is fine, the scrolling text is garbled. The game is garbled when anything moves (not erasing old stuff properly)
Tetris - with no collision it falls right through the bottom (again not erasing properly) and with collision it's just garbled at the top (the piece, the columns still draw properly)

I think I need to make sure it's erasing properly.

---

Last edited by serge2k; May 31st, 2009 at 23:41..

[runawayprisoner]

Originally Posted by serge2k

so far pong2 is perfect
pong is fine except that when I wrap around the screen from top to bottom is leaves an image of half the paddle at the top of the screen.
Invaders - the SPACE INVADERS is fine, the scrolling text is garbled. The game is garbled when anything moves (not erasing old stuff properly)
Tetris - with no collision it falls right through the bottom (again not erasing properly) and with collision it's just garbled at the top (the piece, the columns still draw properly)

I think I need to make sure it's erasing properly.

Sounds to me like you are not XORing the pixels. Here's what happens when you XOR the pixel data:

1 XOR 1 = 0 (erase)
0 XOR 0 = 0 (as is)
1 XOR 0 = 1 (new pixel)
0 XOR 1 = 1 (replace old pixel)

The collision flag is set only once, and once it is set, all subsequent collisions are ignored, so do something like this:

void drawOpcode(...) {
    V[0xF] = 0;
    // Checks and stuffs...
    resultPixel = sourcePixel ^ destinPixel;
    if (resultPixel == 1) V[0xF] = 1;
    else V[0xF] = V[0xF]; // Leave the flag alone if there's no collision
}

__________________
cChip interpreter WIP - current status: Release Candidate
LRx Filter RC - current performance rating: 9/10

[serge2k]

edit: wait that is different.

You set the flag every time there is a pixel drawn then?

int x = registers[opcode>>8&0xF];
			int y = registers[opcode>>4&0xF];
			int height = (opcode&0xF)==0?16:(opcode&0xF);
			registers[0xF] = 0;
			for(int i = 0; i < height; i++)
			{
				byte result;
				int location1 = x/8 + y*8+i*8;
				int location2 = x/8 + y*8+i*8+1;
				if(location1 < 0) location1 += 256;
				else if (location1 >=256) location1 -= 256;
				if(location2 < 0) location2 +=256;
				else if(location2 >=256) location2 -= 256;
				byte current = ((gmem[location1]<<((x%8)))&0xFF) | ((gmem[location2]>>(8-x%8))&0xFF);
				if((((*(address+i)) ^ current)&0xFF) != (((*(address+i))&0xFF) | current))
					registers[0xF] = 1;
				result = *(address+i)^current;
				byte o1 = gmem[location1];
				byte o2 = gmem[location2];
				gmem[location1] = ((gmem[location1]>>(8-x%8))<<(8-x%8)) | (result>>x%8);
				gmem[location2] = ((gmem[location2]<<(x%8))>>(x%8)) | (result<<(8-x%8));
				if(DEBUG)
				{
					printf("X=%d, drawing = %02X, result=%02X, original first byte = %02X, first byte = %02X, original second byte = %02X, second byte = %02X\n", x, *(address+i), result, o1, gmem[location1], o2, gmem[location2]);
					system("pause");
				}
				for(int j = 7; j >=0; j--)
				{
					if(DEBUG)
					{
						//printf("%02X ", (result>>j&0xFF));
					}
					int location = ((x+y*64+(i*64))*6+(7-j)*6);
					if (location >= 12288) location -= 12288;
					else if(location < 0) location += 12288;
					if((result>>j&0x01)== 0x01)
					{
						(pgmem+location)->COLOR = D3DCOLOR_XRGB(255,255,255);
						(pgmem+location+1)->COLOR = D3DCOLOR_XRGB(255,255,255);
						(pgmem+location+2)->COLOR = D3DCOLOR_XRGB(255,255,255);
						(pgmem+location+3)->COLOR = D3DCOLOR_XRGB(255,255,255);
						(pgmem+location+4)->COLOR = D3DCOLOR_XRGB(255,255,255);
						(pgmem+location+5)->COLOR = D3DCOLOR_XRGB(255,255,255);					
						if(DEBUG)
						{
						//	printf("white\n", (result>>j&0xFF));
						//	system("pause");
						}
					}
					else
					{
						(pgmem+location)->COLOR = D3DCOLOR_XRGB(0,0,0);
						(pgmem+location+1)->COLOR = D3DCOLOR_XRGB(0,0,0);
						(pgmem+location+2)->COLOR = D3DCOLOR_XRGB(0,0,0);
						(pgmem+location+3)->COLOR = D3DCOLOR_XRGB(0,0,0);
						(pgmem+location+4)->COLOR = D3DCOLOR_XRGB(0,0,0);
						(pgmem+location+5)->COLOR = D3DCOLOR_XRGB(0,0,0);
					}
					
				}
			}
			Screen->render_frame();
		}

edit: found a few more bugs. pong/pong2 is perfect. breakout is playable but still has graphic issues. Blitz is messed up. Tictac is perfect except for updating the scores. Space invaders still has graphics issues.

Tetris looks like it might be playable if not for the same graphics issues.

---

Last edited by serge2k; June 1st, 2009 at 05:03..

[runawayprisoner]

Try this one for setting the flag instead:

    if (registers[0xf] == 0 && (*(address+i)) == 1 && current == 1) registers[0xf] = 1;

Your previous code is catching all changes to the video memory, whereas it should only catch erases.

Specifically, this would also trigger the flag:

(*(memory+i)) == 0 and current == 1 // <= End result is (*(memory+i)) == 1 and since it's different from its previous state, which is 0, flag is set.

We only want to set the flag when this condition occurs:

(*(memory+i)) == 1 and current == 1

__________________
cChip interpreter WIP - current status: Release Candidate
LRx Filter RC - current performance rating: 9/10

[serge2k]

I didn't update that code but I have actually changed it too

if((((*(address+i)) ^ current)&0xFF) != (((*(address+i))&0xFF) | current))
					registers[0xF] = 1;

so the flag is set whenever a bit is erased by XOR.

edit: updated the code above to match what I have now.

[runawayprisoner]

Originally Posted by serge2k

I didn't update that code but I have actually changed it too

if((((*(address+i)) ^ current)&0xFF) != (((*(address+i))&0xFF) | current))
					registers[0xF] = 1;

so the flag is set whenever a bit is erased by XOR.

edit: updated the code above to match what I have now.

Like I said, you might want to test for (*(address+i)) == 1 and current == 1 rather than testing for if the XOR result of those two would be different from the last pixel, because when you don't have anything in the display buffer at that position (pixel is 0), and the XOR draws something in there (note: draw, not erase) and change it to 1, your condition matches and the flag is set even in such a condition, which is not really the correct way to do it.

An erase occurs when and only when the pixel buffer at that address is 1, and the source to XOR is also 1.

__________________
cChip interpreter WIP - current status: Release Candidate
LRx Filter RC - current performance rating: 9/10

[serge2k]

yes I understand how an XOR works, despite the fact that I put some errors into my program previously.

That code tests if there is a difference between the result of OR and of XOR

i.e.

11010101
10111010

OR produces 11111111
XOR produces 01101111

if they aren't equal then that indicates an erase somewhere and the flag is set.

or am I just tired and making no sense?

[serge2k]

apparently I was making sense.

turns out the problem was these two lines

gmem[location1] = ((gmem[location1]>>(8-x%8))<<(8-x%8)) | (result>>x%8);
gmem[location2] = ((gmem[location2]<<(x%8))>>(x%8)) | (result<<(8-x%8));

after writing out what was happening, writing code to help me debug it, having no luck...

Finally I gave up and changed to this code:

gmem[location1] = gmem[location1] ^ ((*(address+i)>>x%8)&0xFF);
gmem[location2] = gmem[location2] ^ ((*(address+i)<<(8-(x%8)))&0xFF);

MUCH simpler and easier to read and it solved the problem completely.

Every game I've tried with the exception of blitz has been playable.

I really need to get better timing written in, space invaders was very clumsy and basically impossible to get through the first level (slooooooow)
blitz seems to load properly but then I see the plane and it says game over.
Blinky I'm not sure it's it alright or now (screen is fine, seems smooth and speedy but when I press a control it goes as far as it can in that direct making it hard to play)

so timing and getting everything to a playable state.
Then schip
Then I will probably add as much as I can to make it nice (I'd like to get more practice with graphics for example)

Right now I really need to update the GUI (I have to recompile just to change roms)

[runawayprisoner]

Originally Posted by serge2k

yes I understand how an XOR works, despite the fact that I put some errors into my program previously.

That code tests if there is a difference between the result of OR and of XOR

i.e.

11010101
10111010

OR produces 11111111
XOR produces 01101111

if they aren't equal then that indicates an erase somewhere and the flag is set.

or am I just tired and making no sense?

Actually, an erase happens only when a previously set bit is unset... or namely... if you had:

0001000

And later you have

0000000

Then that was an erase.

If you are looking for difference only then this is also a difference:

0000000

To

1001000

And of course that's only a normal drawing routine... things were only added.

See the issue? The games still "appear" right, but the collision flag will be iffy, and IIRC, one most obvious symptom would be that you start having afterimages or ghosts of old sprites whenever a collision occurs.

__________________
cChip interpreter WIP - current status: Release Candidate
LRx Filter RC - current performance rating: 9/10