Chip 8

[refraction]

If destination and source are in the same memoryblock, use memmove instead of memcpy.

thats the thing tho, you dont wanna just move the memory, you wanna cut an entire chunk off it ill give an example

.............................................
**..........................................
**..........................................

say thats a texture on the far left on the screen, this is what youd get if you just moved the pixels left

..............................................*
*............................................*
*............................................

you dont want that tho, you wanna chop off the pixels so your left with

...............................................
*............................................
*............................................

the blank pixels on the right get redrawn by the system, so it doesnt matter that they have nothing in. and the only way i know how to do this sucessfully is the for statement, unless you can do a memmove then some how come up with a way to blank out the certain positions in the array

 

[hap]

Yes, for horizontal scrolling, but Doomulation's code is a vertical scroll, 1 line down.

Your example is nice though if (new) people have problems with horizontal scrolling.

 

[refraction]

Yes, for horizontal scrolling, but Doomulation's code is a vertical scroll, 1 line down.

Your example is nice though if (new) people have problems with horizontal scrolling.

ahh sorry, wasnt paying attention , if thats the case he wants to move it all down by 128 (all 1 line down) affectively pushing the data out of the end.

 

[Doomulation]

How are you allocating the 64*128 of space and why you are doing screen[1] in the memcpy routine, is it a pointer for a specific location?

Easy.

char (*screen)[64] = new char[64][128];

Hmmm... memmove, you say? I'll try that. Still don't get why it works in debug and not release, though.

ahh sorry, wasnt paying attention , if thats the case he wants to move it all down by 128 (all 1 line down) affectively pushing the data out of the end.

And so it is that I do. Copying all the data in the screen minus one line (128 pixels) to screen + 128 bytes offset.

Hmmm... I wonder... will memmove zero out those bytes that I move? I never really used it because I didn't get exactly how it worked (besides copying/moving memory).

 

[refraction]

on a wild stab in the dark, im guessing it works the same way as bit shifting, where its been moved along the array and no data has been put into it, it just fills it with 0's, never tried memmove, had a bit of trouble using memcpy when doing the scrolling (it wouldnt have it i tell you!) but they are much faster than pratting about with for loops

 

[Doomulation]

Hmm, well anyway.
I've been working on a chip8 game maker for a while... but I just recently brought it up and continued work on it. It mght be interesting for you to fiddle around with. I'm sure there's lots of bugs in it, and so, but it shouldn't crash, and that's what's important.

I'm going to finish it sometime, though, hopefully soon, and attempt that gb emu as well. Only 4 of the opcodes are implemted. See the opcodes.txt in the package for them. Note that I like clean coding style (like "jump test + V[0]" and not "jump test+V[0]"), so it won't work with bad coding style. At least yet... dunno if I will support it

It does of course require .net 2003 runtime, so I attached them as well. Not sure if you need the richtextbox dll, so I added it anyway. Someone care to check it out? Sorry, I don't have a debugger yet, but maybe next time...

Anyway, check it out! See if it interests you. Bring it to its bare knees! Test everything! Make its life a hell! Hehe... I like stable programs, so that's why I like these tests ^_^

 

[bgilb]

I was wondering what would cause a distortion in the graphics like so:
http://lockandload.8m.com/chip8-2.png

 

[bcrew1375]

Perhaps a corrupt ROM?

 

[scottlc]

I've seen this problem before. You've either not implimented the necessary opcode, or not done it correctly.

http://www.ngemu.com/forums/showpost.php?p=715833&postcount=57

 

[bgilb]

its probably in the code where it locates the I address

 

[Need4Speed]

I've been thinking about trying this chip8 emu thing. I asume using gcc is fine, right?
Any suggestions on language? I've mainly worked with java and some c/c++ from school. I really like to code in java, but I know running java porgrams suck...

 

[dogdogwoof]

i wouldnt suggest java unless you have a nice speed pc. java uses a lot of memory

 

[bcrew1375]

What language you use doesn't matter. Most people use C/C++. Java would be more than fast enough for Chip8, I think.

 

[hap]

Java's fine, nothing sucks about being able to play chip8 games on the internet. Running java programs offline though, sucks indeed.

gcc is nice too, and was my chip8 'environment'

*edit* seems i was a bit too slow finding the reply button

 

[dogdogwoof]

thats what i meant, java programs take a lot of memory. i really think you should goto C++, much more easier

 

[bgilb]

Java programs dont take alot of memory.. Every normal java program has a max of 64mb before it gives a out of memory error. I've never even come close to that at all.

 

[zenogais]

don't worry, its just another ignorant person spewing Java myths. I swear there are more people spewing ancient myths and attacking Java more than any other language.

 

[bgilb]

Well, I've been working at this for a couple hours and I can't figure it out :-(

The opcodes used are simple ones, 0x7, 0x6, 0xD, 0xF00E, etc.

http://www.rafb.net/paste/results/LiJ0x261.html


My gut feelings tell me its somewhere in 0x7, but I see no errors at all..

 

[Need4Speed]

I think I may just start off with java and them maybe try to port it to C++ later. I'm sure chip8 will be able to fine on 2ghz in whatever language and at least it will be good practice for the AP Comp Sci exam which is in java.

 

[bcrew1375]

bgilb, 0x4 and 0x5 appear to be incorrect. It looks as if you're not incrementing your program counter correctly. The PC+=2 in 0x5 should be PC+=4 with an else PC+=2. If the registers are equal, you're going to the next instruction, if they are equal, 0x5 should SKIP the next instruction. In 0x4, you should have an else PC+=2. BTW, it might be simpler to add 2 to the PC after getting the opcode, instead of incrementing it in every instruction, if it calls for a skip, simply add 2 again. Maybe I'm missing something, but you don't seem to be incrementing the PC register on alot of instructions.