What's new

My PotatoChipAte

OP
glVertex3f

glVertex3f

Crap Cracker
I haven't seen any. Its just like a handfull of the games will run fine, and the others wont run at all. Ive been doing some debugging and all I can come up with is somethings wrong with my drawing code. Its just wierd that it works really well on some games.

Doomulation said 2d arrays were a bad idea. Could someone simply explain the concept of using a "1-D" array to hold X and Y coords?
 

refraction

PCSX2 Coder
glVertex3f said:
I haven't seen any. Its just like a handfull of the games will run fine, and the others wont run at all. Ive been doing some debugging and all I can come up with is somethings wrong with my drawing code. Its just wierd that it works really well on some games.

Doomulation said 2d arrays were a bad idea. Could someone simply explain the concept of using a "1-D" array to hold X and Y coords?


best using a single dimension array which is like 4096 big (or whatever 64*32 is) then store the pixels in that by adding x & y together.
 
OP
glVertex3f

glVertex3f

Crap Cracker
Its really that simple?
I think I will try to do it this way as I havent seen anyone else use a 2d aray so must be something wrong lol.

Also Wipeoff works better since I did the &Memory[0x200]..

EDIT: Hmm.. some odd results.. I know I'm missing something here.

Code:
void CPU::sprite()
{
  int x = V[(OpCode&0x0F00) >> 8];
  int y = V[(OpCode&0x00F0) >> 4];
  int height = (OpCode&0x000F);
  V[0xF] = 0;

  for(int ly = 0; ly < height; ly++) {
  unsigned char Data = Memory[I + ly];

  for(int lx = 0; lx < 8; lx++) {

    if((Data&(0x80 >> lx)) != 0) {
      if(Display[(x + lx) + (y + ly)] == 1) V[0xF] = 1;
      Display[(x + lx) + (y + ly)] ^= 1;
      }
    }
  }

  Draw();
}

EDIT:
I had to multiply the "y" values by 64. Is this the correct way or is there something better.
 
Last edited:

refraction

PCSX2 Coder
glVertex3f said:
I had to multiply the "y" values by 64. Is this the correct way or is there something better.


yes thats right, you times Y by 64 as 64 of the spaces are the X line, so you have to shift it forward 64 to change line.

and yes, it is that simple :p
 

smcd

Active member
refraction said:
yes thats right, you times Y by 64 as 64 of the spaces are the X line, so you have to shift it forward 64 to change line.

and yes, it is that simple :p

A possible speed improvement, to multiply by 64 ... since 64 is a power of 2, you can do a bitwise shift.
 

refraction

PCSX2 Coder
sethmcdoogle said:
A possible speed improvement, to multiply by 64 ... since 64 is a power of 2, you can do a bitwise shift.


not really, multiplication is pretty fast, its division that is slow (i think thats the right way round)

plus i dont think it would work, the result might be wrong.
 
OP
glVertex3f

glVertex3f

Crap Cracker
I need a little help. Can someone please explain the act of scrolling the screen?
I certainly dont want to make a larger array to hold the extra data.

I know im probably just not thinking hard enough, but just the basic "concept" of the process should work :)
 

refraction

PCSX2 Coder
glVertex3f said:
I need a little help. Can someone please explain the act of scrolling the screen?
I certainly dont want to make a larger array to hold the extra data.

I know im probably just not thinking hard enough, but just the basic "concept" of the process should work :)


i find the best way is to copy it into another array the same size as the main one (but shifted by 4) in a for loop, tho you might need some if statements in there to make sure it doesnt too far and end up on a diff line or out of the screen array. then wipe the screen array then use the memcpy command to copy it back over (cos its faster than a for loop).

if you can find a way to use memcpy both ways or cut out using 2 different sequences, good luck to you :p
 
OP
glVertex3f

glVertex3f

Crap Cracker
Thank you refraction. I am still also trying to get all the Chip8 roms working, but they are being quite stuborn. For example when I load Connect4... The first OpCode it tries is 0x1200... so it jumps to 0x200... were the opcode 0x1200 is waiting. Also, on the
jsr() function, the first time a sub routine is called it works fine, but if it calls another jsr... the PC becomes a rather large number causing the opcode to be zero. Some very odd and simple sounding problems here.

EDIT: Also should I create 2 arrays at startup (One Chip8 and one SuperChip8) Or create the array at runtime as needed?
 
Last edited:

refraction

PCSX2 Coder
glVertex3f said:
Thank you refraction. I am still also trying to get all the Chip8 roms working, but they are being quite stuborn. For example when I load Connect4... The first OpCode it tries is 0x1200... so it jumps to 0x200... were the opcode 0x1200 is waiting. Also, on the
jsr() function, the first time a sub routine is called it works fine, but if it calls another jsr... the PC becomes a rather large number causing the opcode to be zero. Some very odd and simple sounding problems here.

EDIT: Also should I create 2 arrays at startup (One Chip8 and one SuperChip8) Or create the array at runtime as needed?

well on my text version i just had the SChip8 size array then doubled the size of the pixels. but when i did NeoChip8 with zenogais, i made the normal chip8 one on startup and if the Schip8 mode was called it destroyed that array and made one the schip8 size.

Can you post your jsr and return code?
 
OP
glVertex3f

glVertex3f

Crap Cracker
Code:
void CPU::rts()
{
  if(SubCall > 0)
    PC = Stack[--SubCall];
}

void CPU::jmp()
{
  PC = (OpCode&0x0FFF);
}

void CPU::jsr()
{
  if(SubCall < 16) {
    Stack[SubCall++] = PC;
    PC = (OpCode&0x0FFF);
  }
}
 

refraction

PCSX2 Coder
its probably because your not decrementing right ;)

its

PC = Stack[SubCall--];

you were decrementing it before it accessed it, or not decrementing it at all lol
 
OP
glVertex3f

glVertex3f

Crap Cracker
I tried it anyway and it starts looping itself backwards. For example.. on brix it draws a line the turs around and "undraws" it. Odd behavior like that.

I cant find any reason why my emu wont work either... except the programmer lol.
 

refraction

PCSX2 Coder
glVertex3f said:
I tried it anyway and it starts looping itself backwards. For example.. on brix it draws a line the turs around and "undraws" it. Odd behavior like that.

I cant find any reason why my emu wont work either... except the programmer lol.


i know itll probably do the same but try incrementing and decrementing Subcall outside of the Stack array call so you do like

Stack[SubCall] = PC;
SubCall++;

then to return

SubCall--;
PC = Stack[SubCall];


cos it could be that its not decrementing the stack on the return until after its tried to put it back into PC, which could cause problems :p
 
OP
glVertex3f

glVertex3f

Crap Cracker
That still didnt work.. so... I revamped it...
The games seem to work now but I have the stupidest problem...

I cant clear the screen.....

Code:
void Video::reset()
{
	delete [] Display;
	Display = new unsigned char [CHIP8_DISPLAY_SIZE];
	
	ZeroMemory(Display, sizeof(Display));
}

Am i just way off base here?

Heres the updated source. I separated every thing off. Display, Memory, and CPU all have there own class + other changes.

Some of it may be sloppy but this is the first time ive attempted to do some of these things so bear with me :p
 
Last edited:

refraction

PCSX2 Coder
way way off!! just do

Code:
memset(Display, 0, sizeof CHIP8_DISPLAY_SIZE);

or something simular to that, cant remember off the top of my head :p

Edit: looked through your source, looks pretty much alright to me, bitshift is an interesting way of doing things instead of *64 :p but if it works then go for it
 
Last edited:

Top