My PotatoChipAte

[zenogais]

Nice debugger Doomulation! I'm working on something similar to that one at the moment, the debugger will also have a memory disassembly which can be stepped through in real time. I'm also thinking about finally moving out of a console application, and creating a windows application from which I can run the programs. Anyway, there are alot of top notch Chip8 emulators on these forums, so glVertex3f, I would recommend that you look at the source code for at least one of these emulators, as there are plenty for you to learn from, just don't copy code without giving proper credits :happy:

 

[sammyboy]

I agree with zenogais, I know nothing about debuggers apart from the fact that they show up bugs (do they fix them as well or something).
But from my past experience most of them look messy but your looks really clean.

 

[glVertex3f]

Speaking of debuggers... anyone know of a nice tutorial or can someone give me an example of how to text/variables onto my little debuger window.

Note: I have a basic Dialog box for a bebug window, I just need to know how to put crap on it lol.

EDIT: also My emu is showing great progress... Some games are nearly playable (note: Nearly).

 

[aprentice]

http://winprog.org/tutorial/

 

[glVertex3f]

Ive been there but it only shows how to print text through the resource file. I want to be able to print variables onto the window. Can I assign variables in the resource file?

 

[smcd]

You could try looking up SetWindowText or SetDlgItemText - use it to set the text in an edit box or the like.

 

[glVertex3f]

Ok, i'll google it

Thank You!

 

[glVertex3f]

Have a look at this Debug output

OpCode: 0x22F6 Memory[220] Call SubRoutine at 2F6
OpCode: 0xA314 Memory[2F6] I = 314
OpCode: 0xF533 Memory[2F8] Store BCD
OpCode: 0xF265 Memory[2FA] Load Mem
OpCode: 0xF129 Memory[2FC] I to Font
OpCode: 0x6337 Memory[2FE] V[3] = 37
OpCode: 0x6400 Memory[300] V[4] = 00
OpCode: 0xD345 Memory[302] DrawSprite: X = 55 Y = 0 Height = 5
OpCode: 0x7305 Memory[304] V[3] = V[3] + 05
OpCode: 0xF229 Memory[306] I to Font
OpCode: 0xD345 Memory[308] DrawSprite: X = 60 Y = 0 Height = 5
OpCode: 0x00EE Memory[30A] Return From Sub
OpCode: 0x0000 Memory[2] Return From Sub
OpCode: 0x0000 Memory[2] Return From Sub

After that it loops the Return From Subroutine indefinately.

I am pretty sure I need to store the place where the memory was when it first called the SubRoutine but I cant figure out what or how.

Here is my call\return SubRoutine code

void CallSubRoutine()
{
  if(SubCall < 16)
  {
    Stack[SubCall] = MemoryIndex;
    MemoryIndex = (OpCode&0x0FFF);
    SubCall++;
  }
}

void ReturnFromSub()
{
  if(SubCall > 0)
  {
    MemoryIndex = Stack[SubCall];
    Stack[SubCall] = 0;
    SubCall--;
  }

  MemoryIndex += 2;
}

 

[zenogais]

Here's a quick fix for ya:

void ReturnFromSub()
{
  if(SubCall > 0)
  {
    MemoryIndex = Stack[--SubCall];
  }

  MemoryIndex += 2;
}

Hope this will help you. Its not absolutely vital that you set the previous stack address to zero, just as long as you don't reuse it, which shouldn't happen.

 

[glVertex3f]

It still gets "stuck" at the ReturnFromSub function...

EDIT: Here is my full source if you would like to have a gander

 

[refraction]

take out that memory index increment, i have a feeling thats the cause of the problem

 

[glVertex3f]

Well, I had thought about that, but it still got stuck.

When it calls it the first time it looks ok but then it calls it again and the MemoryIndex drops and it gets stuck there

 

[Kevin19]

Hello and good morning glVertex3f

The same thing happened to me yesterday and when i looked at the report my debugger issued it seemed to have stuck at the address which indicates the RTS opcode the return from subroutine instruction
It took my a while to figure out a solution to this problem

and the solution is to increase the size of the stack array I increased mine to 40 and had the cycles set to 200 and it works beautifully

This is my RTS function Incase you want to compare
if((opcode&0xFF)==0xEE)
{
PC=stack[++SP];
}

And this is my JSR


stack[SP--]=PC=PC+2;
PC=opcode&0xFFF;

 

[zenogais]

Hello and good morning glVertex3f

The same thing happened to me yesterday and when i looked at the report my debugger issued it seemed to have stuck at the address which indicates the RTS opcode the return from subroutine instruction
It took my a while to figure out a solution to this problem

and the solution is to increase the size of the stack array I increased mine to 40 and had the cycles set to 200 and it works beautifully

This is my RTS function Incase you want to compare
if((opcode&0xFF)==0xEE)
{
PC=stack[++SP];
}

And this is my JSR


stack[SP--]=PC=PC+2;
PC=opcode&0xFFF;

Thats not really the answer. Its just a fluke that that worked, but as you can see in your emulator you don't set a cap on the number of calls you can make.

The problem is that the address he returns to isn't the same as the address he jumps from.

 

[Kevin19]

I stopped at the part when he said he ran into the kind of problem I had
And no i do not think it really matters

I might not be working very carefully but i still know that nothing is accurate when you work under the supervision of a compiler

I still think he should increase the Array because his debugger indicates the same stop at RTS I do not know how extended and knowledgeable You are And i would not want to derogate You and start bashing so i am going to stop here

I also suggest him to try and decrease the cycles to 200
I am almost 100 percent sure that it would work and solve his problem if he did IT

 

[Doomulation]

Nice debugger Doomulation!

Thanks.

I agree with zenogais, I know nothing about debuggers apart from the fact that they show up bugs (do they fix them as well or something).

Basically, a debugger is a tool which helps you find bugs in your software.

Kevin19: I think the actualy problem lies writing beyond array bounds. Increasing the size of the array probably won't help, as no game ever does more than 16 sub jumps from what I have seen.
I've experienced a similar problem as the return address gets corrupt. Put a breakpoint at the sub jump op and trace your way along the code to see when the the value gets corrupted.
The best way to do this is a data breakpoint.

 

[refraction]

it could also be another opcode is messing it up, like with Dragon1 i found it was making loads of illegal jumps for some reason which i dont know, but it was nothign to do with the subroutine code, i suggest you check your other opcodes as well, ill have a look through n see if i can see anything that would cause the illegal jumps.

Edit: right i just had a look through and theres just a couple of problems with opcodes i can see, altho i dont know how it affects your jumps.

void RegRandom()
{
vRegister[(OpCode&0x0F00) >> 8] = ((rand() % 16) & (OpCode&0x00FF));
MemoryIndex += 2;
}

that i think should be more like this

void RegRandom()
{
vRegister[(OpCode&0x0F00) >> 8] = (rand() & (OpCode&0x00FF));
MemoryIndex += 2;
}

as i think its a number lower or equal to 0x00FF, dont quote me on it tho if not try

void RegRandom()
{
vRegister[(OpCode&0x0F00) >> 8] = ((rand()%0xFF) & (OpCode&0x00FF));
MemoryIndex += 2;
}



The 0x8000 opcodes with carry, you should set the carry to the value in VX like you did with RegAssign_I(), but so it does

vRegister[0xF] = vRegisterX&0x1;


oh and your font code, you have to times the number in VX by 5 to get the correct point in the memory (which may be one of your problems)


apart from that something is seriously wrong with your l33t programming skillz cos it crashes after about 1 second of running

 

[Doomulation]

I doubt the other opcodes messes up the returns. They can cause all kinds of problems, but not return errors unless writing outside the array bounds. Which was actually a problem I dealt with, which caused the error in the joust game I think that I bothered you about some time ago (remember?).

 

[glVertex3f]

This might seem like tying up the horse after its already drown... or something... but I have a question...

C or C++... Is one really more eficient than the other. I mean I hardly ever see an emulator written with C++ (except a few chip8 emus).

And a follow up on that question

I want an example of how to emulate the memory by allocating it indtead of an array.

like

unsigned char Memory;
Memory = new unsigned char;

If someone could give me an example of how that would work as far as pointing to a certain place in the memory. And Loading the rom into the Memory.

 

[zenogais]

This might seem like tying up the horse after its already drown... or something... but I have a question...

C or C++... Is one really more eficient than the other. I mean I hardly ever see an emulator written with C++ (except a few chip8 emus).

And a follow up on that question

I want an example of how to emulate the memory by allocating it indtead of an array.

like

unsigned char Memory;
Memory = new unsigned char;

If someone could give me an example of how that would work as far as pointing to a certain place in the memory. And Loading the rom into the Memory.

That is rather like beating the dead horse, but the truth is it doesn't really matter. Both languages are fairly fast, though some hardcore C programmers will claim that C++ is always faster, which is just plain wrong. I personally think C++ has some powerful features that authors of other emulators who program in C have to go out of their way to implement (virtual functions and polymorphism are good examples). also, when allocating memory the C++ way as you are showing, you would do this:

// Allocating a single pointer variable
unsigned char* pMemory = new unsigned char;
// Deallocating the single pointer variable
delete pMemory
....
// Allocating an array using new
unsigned char* pMemory = new unsigned char[0xFFF];
// Deallocating the array using delete
delete [] pMemory;
..
or
..
delete[] pMemory;

As for loading the roms into memory, well theres plenty of source code on these forums for you to look at.