My PotatoChipAte

[smcd]

To keep the same type, make Memory of type "unsigned char[]" and your Rom.read( method to take "unsigned char*" as the first parameter as well, or vice versa?

 

[refraction]

I downloaded and installed the MinGW studio again. And I am really enjoying the IDE. A few problems though.

..\..\Emul8\Chip8.cpp:81: error: invalid conversion from `unsigned char*' to `
char*'

That happens here..

bool CPU::LoadRom(char *sFileName)
{
  ifstream Rom(sFileName);

  if(!Rom.is_open())
    return FALSE;

  Rom.seekg(0, ios::end);
  long size = Rom.tellg();
  Rom.seekg(0, ios::beg);

  Rom.read(Memory + 0x200, size);  <---- HERE 

  Rom.close();
  return TRUE;
}

Why is this happening and how can I fix it?

edit: Also I had functions named and() or() and xor()
These names seemed to be keywords in this IDE.. why is that.

EDIT2: I did this

Rom.read((char*)Memory + 0x200, size);

Is this acceptable?

you want unsigned char as its gonna be a hex value from 0x0 to 0xFF in each memory space, signed only does -0x7F to 0x80.

look for mine or zenogais's source in the chip8 thread and have a look at our load rom code to see how we load ours in.

 

[glVertex3f]

you want unsigned char as its gonna be a hex value from 0x0 to 0xFF in each memory space, signed only does -0x7F to 0x80.

look for mine or zenogais's source in the chip8 thread and have a look at our load rom code to see how we load ours in.

Thats my problem. Memory IS an unsigned char and the compiler is freaking out because the (read()) function accepts a char* and not unsigned char*

I will look at that source and see what happens.

EDIT:

Rom.read(RomBuffer, size);
memcpy(Memory + 0x200, RomBuffer, size);

:whistling

 

[smcd]

This is why I use C I/O, fread uses a void pointer, it just doesn't care what it is so long as it has a place to go.

 

[glVertex3f]

lol, thanks again seth for showing me the MinGW Studio.

 

[zenogais]

This is why I use C I/O, fread uses a void pointer, it just doesn't care what it is so long as it has a place to go.

C++ does the same exact thing, should be:

Rom.read(&RomBuffer, romFileSize);

Where rom file size is an integer with the total size of the rom file determined as follows:

Rom.seekg(ios::cur, ios::beg);
long size1 = Rom.tellg();
Rom.seekg(ios::cur, ios::end);
long size2 = Rom.tellg();
Rom.seekg(ios::cur, ios::beg);
long romFileSize = (size2 - size1);

 

[glVertex3f]

Rom.seekg(ios::cur, ios::beg);
long size1 = Rom.tellg();
Rom.seekg(ios::cur, ios::end);
long size2 = Rom.tellg();
Rom.seekg(ios::cur, ios::beg);
long romFileSize = (size2 - size1);

Question... is this the same thing or is it better to do it the above way.

Rom.seekg(ios::cur, ios::end);
long romFileSize = Rom.tellg();
Rom.seekg(ios::cur, ios::beg);

Also if I do

Rom.read(&RomBuffer, size);

wouldnt that actually be passing an int value into the function.


EDIT: just tried it and it wont compile that way.

 

[refraction]

if you look size1 grabs the beginning of the file, and size2 grabs the end of the file

Edit: i see what you mean tho.. size1 would probably return the value 0 anyway... so possibly

 

[smcd]

Zenogais:
// C I/O ... it is using void *
int fread( void *buffer, size_t size, size_t num, FILE *stream );
// C++ I/O ... it is using char *
istream &read( char *buffer, streamsize num );

A side note, given that it is an array, you don't have to put the ampersand in the read(&

 

[glVertex3f]

You ever wanna... take a stick... and beat yourself?

unsigned char stack[16];

Can you believe this whole time.. the biggest problem was that I accidentally made it an unsigned char instead of short..... omg....

Good news, I found this out by using the debugger, I'm starting to figure this thing out lol.

 

[refraction]

i woulda thought ud guess that if you had a stack, seen as the opcode comprises of a 16bit hex number

didnt you get any "short to char conversion: data may be lost"

errors when compiling?

 

[glVertex3f]

i woulda thought ud guess that if you had a stack, seen as the opcode comprises of a 16bit hex number

didnt you get any "short to char conversion: data may be lost"

errors when compiling?

Actually the char instead of short was a simplr typo I made in the midst of declaring stuff. And would you believe I didnt get that error/warning at all!

I new it was supposed to be a short but I never thought I woulda made it a char. aperbag:

EDIT:
Yay, Space Invaders runs without crashing!!! Woo...

lol

Question: If a 2d array is not a good idea, how else could I do the graphics?

 

[zenogais]

Zenogais:
// C I/O ... it is using void *
int fread( void *buffer, size_t size, size_t num, FILE *stream );
// C++ I/O ... it is using char *
istream &read( char *buffer, streamsize num );

A side note, given that it is an array, you don't have to put the ampersand in the read(&

You can cast just about anything into a char*, so it works almost exactly the same. Thanks for the ampersand correction though.

 

[glVertex3f]

Heres the updated code. It runs a few games pretty well. I think there might be a problem with the LoadRom function as some games fail to even start. Ive used the debugger and found that on pong everything loads right until It tries to draw. The x y and height values are all correct but its detecting that the information at Register I is all 0. This leads me to believe somethings wrong with the loading function.

I know I've been asking for alot of help, but at least I'm learning from all this.
If you see anything wrong or something you just dont like... let me know.

 

[Doomulation]

Actually the char instead of short was a simplr typo I made in the midst of declaring stuff. And would you believe I didnt get that error/warning at all!

I new it was supposed to be a short but I never thought I woulda made it a char. aperbag:

EDIT:
Yay, Space Invaders runs without crashing!!! Woo...

lol

Question: If a 2d array is not a good idea, how else could I do the graphics?

Ummm bad IDE! BAD!
Actually, if you looked at the stack array when assigning a value, you'd see the value getting corrupted the second it's assigned. That's common debugging, mate.

 

[refraction]

why do you have it converting the x, y and height from unsigned chars to unsigned shorts? they should be the same format, or convert them to int's (which is what i did).

on your load rom function try doing memory[0x200] instead of adding it... just as a tester.

but whatever you do make sure all the values are set to 0x200 before it starts emulating.

 

[glVertex3f]

Doomulation, thats how I found the problem, was using the debugger.

refraction, the x y and height being shorts was just something I was trying.
And using Memory[0x200], wouldnt that try to load it into "Memory[0x200]" and not "Memory"?

 

[refraction]

Doomulation, thats how I found the problem, was using the debugger.

refraction, the x y and height being shorts was just something I was trying.
And using Memory[0x200], wouldnt that try to load it into "Memory[0x200]" and not "Memory"?

well in mine it just returns the address 0x200 like so..

in.read((char*)memory->get_pointer(0x200), size);

get pointer just returns that address like this

u8* ChipMemory::get_pointer(u16 location) {
	return (&memory[location]);
}

 

[glVertex3f]

memcpy(&Memory[0x200], RomBuffer, size);

thanks refraction. It seems to work about the same but this way seems more "correct".

 

[refraction]

memcpy(&Memory[0x200], RomBuffer, size);

thanks refraction. It seems to work about the same but this way seems more "correct".

any improvement on running games?