Chip 8

[Redjack]

my chip8 emulator is now finish !
Click here for screenshots

 

[Garstyciuks]

It looks quite nice, but I think that the window is in incorrect size (or is it supposed to be bigger than the chip8 display area?)

 

[hap]

Garstyciuks, does Sokoban work for you now?

I've also updated it, but probably didn't fix anything related to why it didn't work for you before. Also updated it in the collection (and added one from 1979 )

; april 11th 2006: tested with SCHIP (the original SCHIP interpreter) on EMU48
;   and saw it didn't work, fixed it by removing hpflags operations, relative
;   jump, and reducing the filesize by 1. to fit this in, some unnecessary
;   delays were removed, and beeping at the titlescreen, max undo had to be
;   reduced from 74 to 57. also made a trivial change: floornumber is now shown
;   as F xx, instead of xx F.

 

[Garstyciuks]

No, it does not work with flags fixed either. I don't have a lot of time to find what's causing it not to work due to other projects I think the problem is with memory, as it does not seem to draw anything else than the floor number and the sokoban title at the start of the game.

 

[Redjack]

yes Garstyciuks, it's normal that display is bigger

 

[hwave]

Hi all, I've been lurking this forum for a week, give or take a few days, reading up on chip8 I'm an experienced coder but to emulation and also c++ to some extent I'm not quite as experienced. I started out with vb 7 years ago...

Anyway my chip8 emulator is built using sdl and opengl for graphics and a gui using gtkmm. Why not win32 you may ask? Because there is no win32 under linux GTK does work under windows but not without some struggle so most of you probably can't run my emu, but the source is of course viewable anyway

My reason for posting is cause I'm having some issues with it.

Blitz shows the intro fine but after pushing a key it goes off somewhere weird...
Maze, Cave, Tapeworm, Space Flight among others show correct graphics in the beginning, then they just loop that image endlessly.

Most other games show nothing at all for some reason. Space Invaders show a lot, but only garbage. This leads me to believe that I either set (I) wrong somewhere or that my registers get wrong at some point. No matter how many times I go through them though they still look correct.

I've also noticed that at some points there are jump instructions to below 0x200, as is now I'm ignoring opcode reading from below 0x200 so it doesn't interpret the fonts as opcodes I need to revise it of course but as said I am unable to find what is causing it as of yet.

I've attached the file chip8core.txt (renamed cpp), all opcode handling is done in there. If anyone feels like helping me out a bit I'd appreciate it

Oh, and the bcd opcode was kind of ripped of from something I read in this thread...

 

[Garstyciuks]

I would love to take a look at your source file, but it's encoded in linux newline format and I use lame windows, because I can't get linux working <properly> on my pc...

 

[hwave]

Ohh, right, I had totally forgot about that, sorry! I have saved the file in a msdos compatible format now so it should be viewable without any probs this time. Sorry about that

I've also done some correcting in this one, after another reread through there and comparing with the docs I noticed I had the VF borrow flagging backwards didn't raise compatibility one bit as far as I could tell though, so my problem is elsewhere. I also corrected return from subroutine call, but I've not found even one of those yet so that shouldn't be the problem either.

By the way, I use an std::vector for the stack, I noticed almost everyone uses a plain array and a counter for it.

I'm also attaching the chip8core headerfile so you can see how I've declared my variables just in case...

 

[smcd]

I would love to take a look at your source file, but it's encoded in linux newline format and I use lame windows, because I can't get linux working <properly> on my pc...

You can open it in wordpad and then save it and it'll have the newlines all wonderfully converted for you. Just a tip for in the future

 

[zAlbee]

Um... get a better text editor?

E.g. ConTEXT

 

[Garstyciuks]

I have looked through your code and I didn't see anything wrong with it (of course I could have missed something). Maybe there are some emulation bugs elsewhere? When I was programming my own emulator and it had bugs, I have implemented a debugger, which let me see what are the values of each cpu register, index, PC, opcode and other stuff. I used it to go through the machine code step by step and look on which opcodes I get incorrect values. I calculated the values looking at the machine code of the rom and checked it with my emulator output to find the incorrectly emulated opcodes. It sometimes took me quite a long time to find a mysterious bug, but the one with the space invaders wouldn't be hard to find for you You can check my emulator source code if you like. There's a link in my signature.

 

[hwave]

Thanks for the response I will download your source and have a look as well.

I had built a debugger where I could step through, I just did a mistake of accepting what I saw since the only things I saw wrong was jump adresses and certain I register values. I was set that the problem would lie within the instruction code that I didn't consider a problem elsewhere, thanks for opening my mind :whistling

Won't have much time to check it tonight though, I'll see what I can find.

 

[hwave]

I just did a last change before I was going to hit the bed, I decided to try C style file handling instead of fstreams. And after that switch I remembered the problem I had with fstream not accepting my memory variable as unsigned. Well, I changed it to unsigned char and now space invaders work properly!!

Guess I've got to read up a bit on fstream so I don't switch variable types for it

I'm attaching a nice little screenie of the space invaders title, I got a small ship when I attempted to get ingame but nothing to shoot at so I guess there's a smallish error or two lurking around still

Thanks again for the tip of checking outside of the core garstyciuks I will do some more checking on the other games tomorrow, and eventually I will also get schip into this thing

(EDIT) forgot the actual attachment...

 

[Garstyciuks]

It's good to hear that you fixed it. I would suggest you to get chip8 emulation working bug-free before implementing schip instructions. And a tip about random numbers - some games use rand() % kk, some use rand() & kk. Tetris doesn't work properly if it hasn't got the right random. To deal with this I have made a menu option to select which method to use. And why do you do stuff like regV[0] & 0x00FF ? I believe that all chip8 registers should already be 8bit size

 

[bcrew1375]

Um, don't % and & work pretty much the same way? Except the second number of the & instruction should be one less than the % instruction. 48 % 32 = 16, 48 & 31 = 16. 37 % 16 = 5, 37 & 15 = 5. The whole 0x00FF thing, if he is using a 16-bit array that would be to modulate the register values so they don't go over 0xFF(I don't know why you would need to use a 16-bit array though), if he is using 8-bit, then I don't know .

 

[Garstyciuks]

Isn't it the biggest difference between them? Tetris doesn't work properly if the method is %, while rocket isn't generating no starfield if it is &. Some other games depend on this random stuff too. Like those car games. The other solution is to fix the code in the roms, so all of them use the right method for this. But this would get problematically, because there are a lot of sources to get the same game roms from, so replacing them with fixed ones would be nearly impossible.

 

[hwave]

Let me explain what those excessive & 0xFF are for They're remnants from a test I did after noticing that my debug log would sometimes cut off when I didn't do &0xFF to the register I read. I believe I've gotten rid of most of them in the newest version, but one or two still around won't affect anything as far as I know.

My random instruction has worked well so far where I've seen it in use using &. I'll try switching to % just to see what happens

Thanks for the help guys

 

[Garstyciuks]

Bah, what I'm saying is that some games need to use % and some need to use & So you need to make it switchable.

 

[smcd]

This explains some of the "issues" around the built-in rand() function. Overall, it's best to just use a different one if you need "good" randomization.
http://www.azillionmonkeys.com/qed/random.html

As for the %N versus &(N-1), I believe that only applies for power of 2 N's as demonstrated below:

#include<stdio.h>

int main()
{
	int a=48;
	int b=47;
	int c=55;
	int d=22;
	printf("mod 2 = %d %d %d %d\r\n", a%2, b%2, c%2, d%2);
	printf("and 1 = %d %d %d %d\r\n", a&1, b&1, c&1, d&1);
	printf("mod 7 = %d %d %d %d\r\n", a%7, b%7, c%7, d%7);
	printf("and 6 = %d %d %d %d\r\n", a&6, b&6, c&6, d&6);
	return 0;
}

mod 2 = 0 1 1 0
and 1 = 0 1 1 0
mod 7 = 6 5 6 1
and 6 = 0 6 6 6

 

[bcrew1375]

Yes, it does only apply to powers of 2, but I don't remember having to use any mods in my Chip-8 emu except 256 and 32.