My PotatoChipAte

[glVertex3f]

Well, see im going to rewrite my emulator. I wanted to know of another way of emulating memory besides making an array. But without an array, I dont know how to go to a certain address in the memory I allocated.

For example:

unsigned char *Memory = new unsigned char;

MemoryIndex = 0x200;

Now how would I load the rom starting at "MemoryIndex" or jump to "MemoryIndex"?

 

[zenogais]

Well, see im going to rewrite my emulator. I wanted to know of another way of emulating memory besides making an array. But without an array, I dont know how to go to a certain address in the memory I allocated.

For example:

unsigned char *Memory = new unsigned char;

MemoryIndex = 0x200;

Now how would I load the rom starting at "MemoryIndex" or jump to "MemoryIndex"?

The only logical way to emulate the memory is an array, other than that theres a series of much much less efficient ways of doing it.

 

[glVertex3f]

so..

unsigned char *Memory = new unsigned char[0xFFF];

//Would that be more eficient than

unsigned char Memory[0xFFF]

I am wanting to go back and redo this emulator because I want to be sure I understand all the concepts well. At the point I am at now theres no way I could go and emulate a GB or anything, but for future refrence... would an Atari be a logical next step. I really dont need something with ALOT of instructions.

 

[zenogais]

so..

unsigned char *Memory = new unsigned char[0xFFF];

//Would that be more eficient than

unsigned char Memory[0xFFF]

I am wanting to go back and redo this emulator because I want to be sure I understand all the concepts well. At the point I am at now theres no way I could go and emulate a GB or anything, but for future refrence... would an Atari be a logical next step. I really dont need something with ALOT of instructions.

One is not necessarily more efficient than the other. The first one allocates the memory dynamically at a point of your choosing during execution, the second allocates the memory statically on the heap at program start. I prefer the dynamic method because you can detect out-of-memory errors more efficiently with it (if you set the Memory pointer to 0 at before allocating and its still 0 after using operator new then you know the system is out-of-memory, as most operator new's are just wrappers around malloc and free) and also its size can be expanded at anytime during program execution.

Also, the ATARI would certainly be a logical next step after the Chip8, although the ATARI just uses a customized 6502C processor, i.e. the processor used in the NES I believe. I think that most processors besides the Chip8 have "alot" of instructions. But they can also do more things than the Chip8. I hope this stuff helps you.

 

[smcd]

Err... if it is "allocated" inside the program before running, that'd be STATIC, not DYNAMIC. Looks like you mixed those 2 up, zenogais?

 

[zenogais]

Err... if it is "allocated" inside the program before running, that'd be STATIC, not DYNAMIC. Looks like you mixed those 2 up, zenogais?

Did I? All I know is that if you use new or malloc to allocate it, thats dynamic. If you declare the size at compile time without using new or malloc, thats static.

 

[Cyberman]

Did I? All I know is that if you use new or malloc to allocate it, thats dynamic. If you declare the size at compile time without using new or malloc, thats static.

I think you are quite confused

First off...

delete [] array_of_data;

is an OLD C++ method of deleting arrays. It's not needed anymore, Bjorne Stausap got rid of that about 10 years ago because it was confusing and obfuscating. In C++ the compilor knows the type it's deleting because the object knows what it is.

Thus

delete aray_of_data;

is quite acceptable.

Static Dynamic and Stack allocated.

All righty you've got these ALL confused.

Static is technically another version of a globally allocated variable, the difference is that the static type is only accessable in the scope in which it's used.

unsigned long Lerg()
{
 static unsigned long whatsit;
 
 whatsit++;
 return whatsit;
}

whatsit will always be incremented by lerge but is never accessable by anything else. DO NOT USE STATIC unless you know exactly what you are doing. Otherwise it could have some bad consequences.

You know what dynamic already is.

LOCALLY allocated arrays and variables are only in existance when that function inside a class or C function is called. These are actually alocated on the stack.

unsigned long lerg::lerg(void)
{
 unsigned long whatsit;
 whatsit++;
 return whatsit;
}

This is BAD code because whatsit is not initialized, basically it could be any value. The variable only exists within the scope of the function outside it, it is not allocated nor accessable by the compilor. Static however since it is globably allocated can still exist and persist although is inaccessable except from within the scope it's used.

Cyb

 

[glVertex3f]

So.... I could allocate an aray of memory like so

unsigned char *Memory = new unsigned char [0xFFF];

// initialize memory

now are you saying its bad to access this directly? That I shut make Memory a local variable only accessible inside a function an use it through a pointer?

(Isnt it already a pointer though)

 

[smcd]

<Was extremely sleepy> and posting again. I must stop this dangerous habit...

 

[zenogais]

@Cyb:

Well actually I was talking about static vs dynamic allocation, static being nonchangable, dynamic being changeable. Not static variables vs dynamic variables.

Anyway, most of the stuff you said was correct except for the fact about delete[] being deprecated from the standard. I went and checked the standard, and it says that every compiler needs to define "operators new, new[], delete, delete[]", and if you read further into the standard you'll find that the behavior of delete on any variable allocated with new[] is undefined. In other words this is a dangerous operation and should'nt be used, use delete[]. Allocated variables (other than class) carry no type information along with them, meaning that a variable of type "unsigned char" allocated with new[] doesn't know that its an array. In order for these kinds of objects to retain type data , there would have to be "extra" hidden code generated by the compiler which would make operator new and delete in all their forms much less efficient than their C equivalent malloc and free, which would be a very poor design decision just to avoid the programmers making a simple mistake.

 

[glVertex3f]

so your sayin the whole allocating memory array with new is a bad idea?

 

[zenogais]

so your sayin the whole allocating memory array with new is a bad idea?

Sorry man, didn't mean to confuse you. As far as memory arrays are concerned "yes you need to allocate an array of memory to emulate the chip8's memory".

 

[Doomulation]

so your sayin the whole allocating memory array with new is a bad idea?

To clear things up a bit, read this:

Know the diffrence between the stack and the heap. Using new, you put data on the heap; not using new, you put them on the stack.
Now, in most threads (and default), the stack is only 1 mb. But on the heap, there is no such limitation. The heap is only limited by the actual amount of memory you have available in your machine (save for the fact that windows actually hands each application a max of 4 gb of memory).

Therefore, large data should be put on the heap, and lesser on the stack.
Data on stack is prefer because it's automatically destroyed by the compiler. With memory on the heap, you must manually destroy it with delete.

Also, data on the stack is "static," as explained. It's always the same size and cannot be changed. Data allocated on the heap is dynamic and size can be changed during the long run.

So no--there is nothing wrong with using the new on the memory

 

[glVertex3f]

So as far as Chi8 is concered its 6 in one hand and half a dozen in the other?

 

[Doomulation]

Ehhhh... I don't think I got your meaning there :blush:

 

[glVertex3f]

ok since your a programmer lets do it this way...

#define SIX     6
#define DOZEN  12

int hand1, hand2;

if(System == Chip8) {
  hand1 = SIX;
  hand2 = DOZEN/2;
}

EDIT:
In pure terms.... I desnt really matter wich one (on the stack/heap) with Chip8. Neither has an advantage.

 

[Doomulation]

I understood what you said, but not what it meant...
Use whichever you feel you wish to use... there's no forcing you. Either is as good. But usually you'd use the stack for small data and the heap for large data.

 

[glVertex3f]

One more thing... am I really this bad of a programmer that I cant get this Chip8 to work.

I mean I have looked through several Chip8 emulator sources and I seem to be doin everything right but it still gets stuck at the return from subroutine.

 

[Doomulation]

As I wrote before,
first, you check the subroutine call. Make sure it stores the correct return address.
Then, at the return, if the address to return to is wrong, then it gets garbeled somewhere. Add a data breakpoint to see where it's getting corrupted.

Easy.

 

[glVertex3f]

"Add a data breakpoint "

What is that exactly.. heh... :blush: