CHIP8 DrawSprite

[Kevin19]

I have been trying to figure this routine out for more than 40minutes now
But i still do not get how it works

void DrawSprite(int rx,int ry,int s)
{
int countery,counterx;
char pixel;
for(countery=0;countery<s;countery++)
{
pixel=memory[I+countery];
for(counterx=0;counterx<8;counterx++)
{
if((pixel&(0x80>>counterx))!=0)
{
if(screen[rx+(ry*64)]==1)
{
V[0xF]=1;
}
screen[rx+(ry*64)]^=1;
}
}
}
}
Why is there a need to go through the same loop 8 times if any number is going to be the same anyway NUM&0x80=80 or 0
Is not it highly CPU consuming

[RipNLa]

I have been trying to figure this routine out for more than 40minutes now
But i still do not get how it works

void DrawSprite(int rx,int ry,int s)
{
int countery,counterx;
char pixel;
for(countery=0;countery<s;countery++)
{
pixel=memory[I+countery];
for(counterx=0;counterx<8;counterx++)
{
if((pixel&(0x80>>counterx))!=0)
{
if(screen[rx+(ry*64)]==1)
{
V[0xF]=1;
}
screen[rx+(ry*64)]^=1;
}
}
}
}
Why is there a need to go through the same loop 8 times if any number is going to be the same anyway NUM&0x80=80 or 0
Is not it highly CPU consuming

Its because, it is not being & with just 0x80 each iteration. 0x80 is being right shifted each time BEFORE the & (notice the order of precedence, parenthesis).

Basically, 0x80 is 10000000 in binary right?
So
(0x80 >> 0) = (10000000) & pixel
(0x80 >> 1) = (01000000) & pixel
(0x80 >> 2) = (00100000) & pixel
(0x80 >> 3) = (00010000) & pixel
(0x80 >> 4) = (00001000) & pixel
(0x80 >> 5) = (00000100) & pixel
(0x80 >> 6) = (00000010) & pixel
(0x80 >> 7) = (00000001) & pixel

So each iteration of the outer loop, the variable pixel gets one byte (8 binary bits) of memory, that represents a graphic. You then check EACH BIT OF THAT BYTE with this piece of code to see if we need to draw on the screen or not.

If the byte you pulled was 11001111, you wouldnt want to do anything with the 00 because another graphic might be drawn there on that screen location already.

[Kevin19]

I still do not see the purpose of this process I think it is overly redundant and could be optimized With a single check whether the number is resulting in zero or not

[RipNLa]

I still do not see the purpose of this process I think it is overly redundant and could be optimized With a single check whether the number is resulting in zero or not

Hmm..I'm not sure what you mean, but do you understand that one "number" contains 8 separate values?

Imagine your PIXEL is integer 213 on one iteration, so that means in binary it is 11010101. That means, that starting at location x,y you have to draw THOSE 8 pixels from that ONE value. Remember, that PIXEL is updated every outside loop iteration to go through each ROW of the sprite youre drawing.

I think your confusion comes from your using the name PIXEL for the variable, when it should really be called something like RowOfSprite since it contains many pixels, not just one.

[Kevin19]

I understand I have practiced assembler for over 2 years Do trust me i understand what it means

And yes i have been lost in confusion I was being too hasty and have neglected to see the part where it increases the positions

and the single check thing WELL i simply suggested that maybe instead all of this loop you could use boolean

[aprentice]

I understand I have practiced assembler for over 2 years Do trust me i understand what it means

And yes i have been lost in confusion I was being too hasty and have neglected to see the part where it increases the positions

and the single check thing WELL i simply suggested that maybe instead all of this loop you could use boolean

I seriously doubt you have coded in asm for 2 years, if you have, you would understand bit management. Every byte is composed of 8 bits. Every bit tells the chip8 emu where to draw the pixel and where to not draw the pixel. You can think of it as a matrix. I can't explain it more simpler than this :P

summary
--------
0 = no pixel
1 = pixel

[Kevin19]

Are you kidding me now I hope you are It definitely Seems like you are

I am sorry if It looks like I am taking offense to it

But i am a serious person And I do not like when i am being mocked

[Kevin19]

I decided to forgive you For making Fun of my negligence And Throwing it back at me 10 times more than i deserved it

So i have been working all day and coded the whole instructions Did not use assembly yet for optimization Not that i think any would be required after all it is only a 40 instruction emulator

Of course it would be fun To experience and enrich my knowledge

anyway Now that all is done It seems so dull and inanimate I think Thanks to my carelessness again I have omitted something

I know I should not be asking and trying to figure it out myself but really I have coded this thing all day and i am really tired to the bone

[Kevin19]

Am i missing something here Because How ridiculous and newbie it may sound It only draws That image

Now i have been checking and compared all the opcodes to other peoples codes And everything seems adequate SO to speak

These are the last opcodes which the little debugger I have coded issue

[2FC] F129 FONT V1
[2FE] 6337 MOV V3,37
[300] 6400 MOV V4,0
[302] D345 DRYS 345
[304] 7305 ADD V3,5
[306] F229 FONT V2
[308] D345 DRYS 345

And there it also seems to get stuck almost at the end of the binary file

[THE END] - Just right before it excutes d345
0xD3, 0x45, 0x00, 0xEE, 0xE0, 0x00, 0x80, 0x00, 0xFC, 0x00,0xAA,0x00, 0x00, 0x00, 0x00, 0x00
[/THE END]

I have only coded the instructions the sprite drawer which i had to revise as well and a function to load THE romFile and the font table

void main()
{
debug();
LoadTable(FontTable);
loadROM();
while(keyCheck()!=27)
CPU();
}

I know this may look like one big joke to you But no I am very serious And tired

So i will go to sleep now and hope i will be able to solve this in the morning or someone will be able to solve it for me

THANK YOU

[manboy]

Am i missing something here Because How ridiculous and newbie it may sound It only draws That image

Now i have been checking and compared all the opcodes to other peoples codes And everything seems adequate SO to speak

These are the last opcodes which the little debugger I have coded issue

[2FC] F129 FONT V1
[2FE] 6337 MOV V3,37
[300] 6400 MOV V4,0
[302] D345 DRYS 345
[304] 7305 ADD V3,5
[306] F229 FONT V2
[308] D345 DRYS 345

And there it also seems to get stuck almost at the end of the binary file

[THE END] - Just right before it excutes d345
0xD3, 0x45, 0x00, 0xEE, 0xE0, 0x00, 0x80, 0x00, 0xFC, 0x00,0xAA,0x00, 0x00, 0x00, 0x00, 0x00
[/THE END]

I have only coded the instructions the sprite drawer which i had to revise as well and a function to load THE romFile and the font table

void main()
{
debug();
LoadTable(FontTable);
loadROM();
while(keyCheck()!=27)
CPU();
}

I know this may look like one big joke to you But no I am very serious And tired

So i will go to sleep now and hope i will be able to solve this in the morning or someone will be able to solve it for me

THANK YOU

Try contacting Refraction for help. He knows a lot about the chip8 :bouncy:

[Kevin19]

Good morning everyone
Hello manboy
That is ok I just woke up and everything looks more clear in the morning
The problem originated from hastiness to get to see results I thought i could have it done in one day

The problem was In the RTS calling Instead of juxtaposing the whole byte To see if it matches the case I only juxtaposed the lower nibble Which created this conflict and i also seem to have made one of the stupidest most foolish mistakes in the whole history of programming I have defined the stack as 8bits instead of 16

Now it seems to loop through the subroutine infinitely

And another uncanny thing is happening it appears that if i do not position the stack array in a certain way it creates another conflict But it is all fixed now except for the iterative LOOP

of course

[smcd]

Eww, you "void main()" gross gross gross! COOTIES!

[zenogais]

Eww, you "void main()" gross gross gross! COOTIES!

'nuff said.

[Kevin19]

HAHAHAHA
I am unsure of the reason which led you to say that But i will take it you were laughing at the fact that Unlike all of you bill gates butlickers

I did not use Visual c++

or any of those neoteric 21 century means such as directx and opengl The simplicity of using them so simple Why use something so primitive and outdated You probably think to yourself HAHAHAHA

"Children of the future"

anyway I have just finished the GFX implementation
I used mod 13 which is about 320*200 with a direct pointer to the screen buffer which gives it pretty much a smooth sail I wish I could post you some pictures to see my newbiness But it does not seem to let me printscreen it

So i will just append the file to this message of course I would not recommend anyone to see it because It is one of the most disastrous things I have ever coded

But first impression and first demo

[Kevin19]

I just finished coding the input function and when i run it
It seems to get stuck during the game if you keep pushing it as a matter of fact All the game seems to get stuck

According to the debug file it seems to get stuck at address

[2CE] A30E MVI 30E
[2D0] 7EFF ADD V14,FF
[2D2] 80E0 MOV V0,VE
[2D4] 8004 ADD V0,V0
[2D6] 6100 MOV V1,0
[2D8] D011 DRYS 11
[2DE] 3E00 SKEQ V14,0
[2DE] 12DE JMP 2DE
[2DE] 12DE JMP 2DE
[2DE] 12DE JMP 2DE
[2DE] 12DE JMP 2DE
[2DE] 12DE JMP 2DE
[2DE] 12DE JMP 2DE
[2DE] 12DE JMP 2DE

case 0xE000:
if((opcode&0xFF)==0x9E)
{
if(input(V[(opcode&0xF00)>>8])==V[(opcode&0xF00)>>8])
{
PC=PC+4;
}
else
{
PC=PC+2;
}
}
if((opcode&0xFF)==0xA1)
{
if(input(V[(opcode&0xF00)>>8])!=V[(opcode&0xF00)>>8])
{
PC=PC+4;
}
else
{
PC=PC+2;
}

}
int input(int key)
{
switch(key)
{
case 4 : if(keyCheck()=='a')return 4; break;
case 6 : if(keyCheck()=='d')return 6; break;
default : return 0; break;
}
}

I also attached the file to this message

[aprentice]

I just finished coding the input function and when i run it
It seems to get stuck during the game if you keep pushing it as a matter of fact All the game seems to get stuck

According to the debug file it seems to get stuck at address

[2CE] A30E MVI 30E
[2D0] 7EFF ADD V14,FF
[2D2] 80E0 MOV V0,VE
[2D4] 8004 ADD V0,V0
[2D6] 6100 MOV V1,0
[2D8] D011 DRYS 11
[2DE] 3E00 SKEQ V14,0
[2DE] 12DE JMP 2DE
[2DE] 12DE JMP 2DE
[2DE] 12DE JMP 2DE
[2DE] 12DE JMP 2DE
[2DE] 12DE JMP 2DE
[2DE] 12DE JMP 2DE
[2DE] 12DE JMP 2DE


Its not stuck, have you bothered to read the output?

[2DE] 3E00 SKEQ V14,0 <- skip next instruction if register 14 is equal to 0
otherwise execute the instruction, and since the instruction jumps to itself, it means that the rom was meant to end there, think of it as a "game over" or "execution complete".

[smcd]

Actually Kevin19, I was referring to your breaking the standard set forth by ANSI/ISO commitees regarding both C and C++, they define main() as a function that returns a value of type int, not a void function. :P

[Kevin19]

Yes i thought it was a gameover myself at first because it had no other place to jump But then this little gameover address came before the game was over

It still gets stuck in the middle of the game
I am having problems establishing the correct input system
I have already tried approximately 8 different approaches which none of them seemed to work properly


and sethmcdoogle Yes little rebellious me

When you get caught up between the rush of finishing something and fatigue
of the night
You forget who and where you came from

after all this rant
I would like to thank you all for helping me whether you did or not Thank you anyway for even replying

[Kevin19]

Ok it seems to get stuck with and without any input just like that random sometimes after 10 seconds and sometimes after 40seconds

[zenogais]

HAHAHAHA
I am unsure of the reason which led you to say that But i will take it you were laughing at the fact that Unlike all of you bill gates butlickers

I did not use Visual c++

or any of those neoteric 21 century means such as directx and opengl The simplicity of using them so simple Why use something so primitive and outdated You probably think to yourself HAHAHAHA

"Children of the future"

anyway I have just finished the GFX implementation
I used mod 13 which is about 320*200 with a direct pointer to the screen buffer which gives it pretty much a smooth sail I wish I could post you some pictures to see my newbiness But it does not seem to let me printscreen it

So i will just append the file to this message of course I would not recommend anyone to see it because It is one of the most disastrous things I have ever coded

But first impression and first demo

No, as was stated, we were referring to the fact that void main() an ancient and deprecated way of defining the program entry point. Also, in my Chip8 emulator I use neither DirectX or OpenGL.

[Kevin19]

I am sure you do not

[Kevin19]

I do not know how that is relating to anything but i just increased the size of the stack to 40 and it seems to work much better now
The weird thing is that when i positioned the stack array somewhere else in the program as under all the other variables for example the stack started to act weirdly and gave very improbable numbers I think it is something with the compiler I use borland 5.2

[LXS]

Probably you have overflown some other array...

[zenogais]

I might recommend familiarizing yourself more with C/C++ and then reading through the Chip8 documentation again, because alot of these problems seem to stem from lack of familiarity with the language or the system you're emulating.

[Kevin19]

I have an experience of 3.5 years in the field of C programming which was upgraded from JAVA
and also as i have already said an experience of 2 years in the field of assembly
I think that is enough of familiarity with the language

I have read enough of the chip8 documentation

And I do not know if you took note of my antecedental post but i already finished coding it and everything seems to be working beautifully except for the slow input part and The array problem probably originated from wrong option settings
Which this primitive Borland 5.2 does not let me revise now
But my project has already come to its end
And I thank you all for being helpful
Haha

[refraction]

For the input system on Neochip8 the way i worked it was to have the keys mapped as a boolean Array of 15 slots, and when you press the key on the keyboard, it sets the corresponding slot (in terms of the chip8 key) in the array to true, then when you take your finger off it, it sets it to false again.

it seems to work pretty well anyway, having it as a single variable i found you couldnt jump forward or anything like that in ant, so it made it kinda impossible to play.

also its best to make the delay registers much slower than the opcode loop cycle, this makes games like invaders much more playable, you can get passed level 1 then :evil:

[Kevin19]

I just used port 60h to get a more accurate input
And your method just does not seem to work very well
Or at least on my emulator
I set the array and all and It seems like it will not accept true alone
It must have a condition which verifies Its value

Anyway STill thank you for your help

I think i will move on to the next emulator

Gameboy or SNES
I am not sure which one i am going to choose at the moment
Hopefully neither one of them will be this 8chip like primitive

I also considered to use Visual C++ But I think i would rather make everything
from scratch

so Anyway Goodnight everyone and once again thank you for your help

[Doomulation]

By leaving a work unfinished and moving on, truly you will learn nothing.
But, really now, if you are as experienced as you say you are, then write a debugger for your emulator and you'll probably be able to solve MANY problems on your own.

[zenogais]

I don't mean to be rude. But if you can't finish a Chip8 emulator, than a Gameboy/SNES emulator will leave you completely confused. Personally, I think you should stick with Chip8, because Gameboy and SNES are I would say 5x more complex than the Chip8.

[refraction]

I also considered to use Visual C++ But I think i would rather make everything from scratch


id consider that harder if i was you, doing stuff in asm (if you are) your making your life extremely difficult, use something of a higher level like Visual C++ to get to grips with how it all works and how to emulate it before diving in with stuff like that. When you master Chip8 in that try something like GameBoy which is about the next step up in emulation, unless you can emulate a machine like the Commadore 64 or ZX Spectrum which are kind of on a par, but the system is a bit more complicated as they were computers and not consoles.

So do a chip8 emu in Visual C++, get it totally working, then try a GB one when and ONLY when your chip8 one is finished, else your gonna just get stuck not knowing what to do.

[Kevin19]

I truly thank you all for helping me but i have already finished The input system and I just got on and forgot to inform you

So I am sorry for troubling you

and zenogais I am sorry for being rude to you and thinking of you as a nuisance But you really were being very impolite to me at first and jumped to conclusions which really did irk me based on such small knowledge of me

I do not know which one of us was wrong but i am truly sorry for anything offensive which i said to you

I really should thank you for even bothering to take a few seconds of your life to answer any of my posts

And refraction you have been tremendously helpful
Which I would like to thank you for it
Your methods could not really be of any use for me because we are both programming on different environments I am a bit obsessive because i like doing things from scratch without consulting with other people And Visual c++ really everything comes on a golden platter so to speak

I am sorry if i sound a bit pompous

and doomulation yes at some point i wanted to leave it unfinished and move on to the next project because it really looked very insignificant

I mean come on it is only chip8 ARE WE A BUNCH OF newbies working with such primitive hardware

But i really gave a lot of thought about this issue and decided to try again till i successfully managed to complete it and i just got to get online and inform you of this

I am also sorry if my sentences may be blessed with the run-on-sentence feature and totally lacking punctuation


ONCE AGAIN THANK YOU ALL FOR BEING SUCH GREAT HELP

[glVertex3f]

I mean come on it is only chip8 ARE WE A BUNCH OF newbies working with such primitive hardware

Why, yes yes I am... :)

[Doomulation]

and doomulation yes at some point i wanted to leave it unfinished and move on to the next project because it really looked very insignificant

I mean come on it is only chip8 ARE WE A BUNCH OF newbies working with such primitive hardware
You're missing the point. We do this because it's FUN. It does not matter WHAT system it is. It does not matter how HARD it is to emulate. We do it because it's fun. And even though chip8 is very primitive, it is a system nevertheless, and a good start to introduction of emulator programming.

Believe it or not, we had a lot of troubles to get perfect emulation on the games. Now, it was good training to solve these problems and make it work correctly.
This is truly something you need for bigger emulation projects.

Now believe me, because I'm working on a GB emulator, and even though it's "primitive," it got over 100 opcodes and is damn complex rather than a chip8 system.

[Kevin19]

Yes the is true it is good introduction to the fascinating mysterious world of emulation programming

I just myself started to work on the 6502

THE Z80 is a killer too
But I do not know the gameboy is not all that

I wanted to choose the commodore for my next project because unlike what we are dealing with here this is the real deal a real computer but i chose the 6502 the nes is far more interesting

I am sure you probably are almost done coding it but even thought if you still have not and to all the other people out there who are interesting in learning more about the gameboy

here is an informative reference

http://www.enliten.force9.co.uk/

[refraction]

looks like a nice site for doing a gameboy emu :) seems to have pretty much everything you need

[Kevin19]

Yes it does but i already decided to try the 6502 for my next project

It was more popular and known in the 80s than the z80

[Doomulation]

Nice site. Unfortunaly, the tutorials are not in C code. I could see asm, and some other but none really helps. Remember: a lot of people don't even know assembly.
It would be very nice if you could provide C code sample. And even better, a walkthrough in the tutorials describing how to do in step-by-step.

[Kevin19]

You are talking about actual tutorials that describe how to emulate a system

I am sorry But i do not have any
I posted that link so maybe you could find some useful information in case you needed any for your gameboy emulator

[refraction]

wel the site had opcode hex's and system information, the rest you should be able to work out on your own :) remember icarus developers didnt even have the opcodes when they started

[Kevin19]

wel the site had opcode hex's and system information, the rest you should be able to work out on your own :) remember icarus developers didnt even have the opcodes when they started

That is exactly the way i work by

Gathering all the information on the system myself and then i start putting it all together

So what systems have you emulated yet If you do not mind i ask

[refraction]

That is exactly the way i work by

Gathering all the information on the system myself and then i start putting it all together

So what systems have you emulated yet If you do not mind i ask


just chip8 :D but im a very novice programmer, i would even say some of it was fluke mixed with my eye for spotting problems.

I intend on stepping up to Gameboy or NES next tho.

[Kevin19]

I am sorry for quoting you I always delete the quote at first when i start typing the message
But this time I hurried so much to respond that i forgot to remove it

Next time I will just use the quick reply

And about the novice programmer

I do not think that even one of the greatest minds even the best programmer could grasp that easily the concept of emulating a machine
It takes time and determination

starting to sound like a cheesy line from a bad movie

You seem to have posted over 160 posts
You cannot be that novice

Anyway i have gathered and still am gathering information on the 6502
I have emulated about %5 of the instructions

So if you or anybody is looking for any kind of information

I can post links

[refraction]

ive not been posting here long but ive been programming in C++ longer than i have been a member here :) but im still to grasp the basics of SDL (or any other graphics engine), Windows Programming like menus etc and some structuring methods like using classes.

When it comes to thinks like opcodes etc, i am fine with that :)

as for 6502 which was nes yes? i have enough links for that, but thanks anyway :)

[Kevin19]

In my opinion it is a waste of time to use and study 32-bit products
But of course it is easier and more functional to deal with it

[refraction]

indeed, i prefer my job to be easy and more understandable than asm, tho i intend on using slices of asm where i can for optimisation reasons

[Kevin19]

Optimization
You actually bumped into something that requires this kind of approach

The only Optimization that i used and I do not think it should even be called that
Is mod 13 on my chip8 emu to draw the pixels onto screen
and direct pointer to the screen buffer

[zenogais]

In my opinion it is a waste of time to use and study 32-bit products
But of course it is easier and more functional to deal with it

I don't see why this is a waste of time, as the majority of systems around nowadays are 32-bit systems.

Also, as for inline assembly in your C/C++ code, chances are you would never need it. Most compilers nowadays generate equal or better assembly language than your handcoded assembly "optimizations".

[Kevin19]

Yes I think it is a waste of time

And the majority Who cares about the majority Yes the majority is composed of people who dedicated their life to the learning of MFC Directx opengl etc..

But they are missing out on the real thing The thing that their 32 bit systems were made of

Going back to their roots

Maybe this is a crazy talk

But there are so many things to learn about your system that People just cannot see it with all the modern systems and tools that come out To make their life easier

and "optimizations" I do not know If you noticed it But i actually disagreed on this issue that you can hardly get any optimization especially when emulating 8 bit systems

But then again what do i know
I am just using logic

[Kevin19]

assuming that you people already have been through this part

How did you exactly handle the MMC the bank switching

I Got a few approaches in mind But i think they are too much complicated to be applicable

Except for one
Which is handling it through another array But i do not think that would do it
It is too cumbersome

[smcd]

Kevin19 is one of those people who won't listen to you even if you know what you're saying, you've not discovered this, yet? :P

[Kevin19]

I have read about 20 articles on the 6502

There is a lot of things that could be spared but after all it is kind of primitive

anyway according to my knowledge from the documents i have read
I would like to know if my formulas are correct Because i am going to duplicate them and change the values so they will fit to the other instructions

But i would still like to post them here to compare and see if everything is done right Because i sometimes get the feeling that something here is wrong

void ADCImmediate(char Immediate)
{
A=A+Immediate+Carry;
if((A+Immediate+Carry)==0)Zero=1;
if((A&0x80)==0x80)Negative=1;
if((A+Immediate+Carry)>127||(A+Immediate+Carry)<-128)Overflow=1;
if((A+Immediate+Carry)>=255)Carry=1;
}

void ADCZpg(char Zpg)
{
A=A+Memory[Zpg]+Carry;
if((A+Memory[Zpg]+Carry)==0)Zero=1;
if((A&0x80)==0x80)Negative=1;
if((A+Memory[Zpg]+Carry)>127||(A+Memory[Zpg]+Carry)<-128)Overflow=1;
if((A+Memory[Zpg]+Carry)>=255)Carry=1;
}

void ADCZpgX(char Zpg)
{
A=A+Memory[(Zpg^XIndex)]+Carry;
if((A+Memory[(Zpg^XIndex)]+Carry)==0)Zero=1;
if((A&0x80)==0x80)Negative=1;
if((A+Memory[(Zpg^XIndex)]+Carry)>127||(A+Memory[(Zpg^XIndex)]+Carry)<-128)Overflow=1;
if((A+Memory[(Zpg^XIndex)]+Carry)>=255)Carry=1;
}

void ADCAbsolute(int Absolute)
{
A=A+Memory[Absolute]+Carry;
if((A+Memory[Absolute]+Carry)==0)Zero=1;
if((A&0x80)==0x80)Negative=1;
if((A+Memory[Absolute]+Carry)>127||(A+Memory[Absolute]+Carry)<-128)Overflow=1;
if((A+Memory[Absolute]+Carry)>=255)Carry=1;
}

void ADCAbsoluteX(int Absolute)
{
A=A+Memory[(Absolute+XIndex)]+Carry;
if((A+Memory[(Absolute+XIndex)]+Carry)==0)Zero=1;
if((A&0x80)==0x80)Negative=1;
if((A+Memory[(Absolute+XIndex)]+Carry)>127||(A+Memory[(Absolute+XIndex)]+Carry)<-128)Overflow=1;
if((A+Memory[(Absolute+XIndex)]+Carry)>=255)Carry=1;
}

void ADCAbsoluteY(int Absolute)
{
A=A+Memory[(Absolute+YIndex)]+Carry;
if((A+Memory[(Absolute+YIndex)]+Carry)==0)Zero=1;
if((A&0x80)==0x80)Negative=1;
if((A+Memory[(Absolute+YIndex)]+Carry)>127||(A+Memory[(Absolute+YIndex)]+Carry)<-128)Overflow=1;
if((A+Memory[(Absolute+YIndex)]+Carry)>=255)Carry=1;
}

void ADCIndirectZpg(char Indirect)
{
int TempValue=((Memory[Indirect+1]<<8)+Memory[Indirect]);
A=A+Memory[TempValue]+Carry;
if((A+Memory[TempValue]+Carry)==0)Zero=1;
if((A&0x80)==0x80)Negative=1;
if((A+Memory[TempValue]+Carry)>127||(A+Memory[TempValue]+Carry)<-128)Overflow=1;
if((A+Memory[TempValue]+Carry)>=255)Carry=1;
}

void ADCIndirectZpgY(char Indirect)
{
int TempValue=((Memory[Indirect+1]<<8)+Memory[Indirect])+YIndex;
A=A+Memory[TempValue]+Carry;
if((A+Memory[TempValue]+Carry)==0)Zero=1;
if((A&0x80)==0x80)Negative=1;
if((A+Memory[TempValue]+Carry)>127||(A+Memory[TempValue]+Carry)<-128)Overflow=1;
if((A+Memory[TempValue]+Carry)>=255)Carry=1;
}

void ADCIndirectZpgX(char Indirect)
{
int TempValue=(((Memory[Indirect])+XIndex)+(Memory[Indirect+1]<<8));
A=A+Memory[TempValue]+Carry;
if((A+Memory[TempValue]+Carry)==0)Zero=1;
if((A&0x80)==0x80)Negative=1;
if((A+Memory[TempValue]+Carry)>127||(A+Memory[TempValue]+Carry)<-128)Overflow=1;
if((A+Memory[TempValue]+Carry)>=255)Carry=1;
}

[Doomulation]

Yes I think it is a waste of time

And the majority Who cares about the majority Yes the majority is composed of people who dedicated their life to the learning of MFC Directx opengl etc..

But they are missing out on the real thing The thing that their 32 bit systems were made of

Going back to their roots

Maybe this is a crazy talk

But there are so many things to learn about your system that People just cannot see it with all the modern systems and tools that come out To make their life easier

and "optimizations" I do not know If you noticed it But i actually disagreed on this issue that you can hardly get any optimization especially when emulating 8 bit systems

But then again what do i know
I am just using logic
Actually, the C/C++ language and MFC is good things, as opposed to assembly. In C++, you can utilize classes, which can handle themselves. You can overload operators, and such. Classes, polymorphy, virtual functions... very handy things. Can't be done in assembly. You have do all the hard work of coding it. What would you rather do - code a 100 lines or code or 10?

Remember the general thumb rule of applications: the applications are supposed to "hide" their function for the user. The user knows how to use the application, but not how it works. Maybe you could say the same about the programming. You know how to use the C/C++ code, but you do not know what assembly is generated out of it.

Assembly is a major waste of time except in some situations where the compiler cannot do very good code.

[Kevin19]

Yes
as you can see most of the code i am doing in C
But assembly gives you pretty much the background

if you want to work on an emulator otherwise it would be pretty difficult to start without something to strenghten your knowledge and understanding

That is why I believe that it would be more beneficial and productive if people first started with ASSEMBLY and then moved on to a high programming language

AND about the MFC I like doing things from zero
Or it is just sloth to read one of the books i got here on MFC
and start a whole chapter with windows programming

So tell me is there any progress with your GB emulator

Because i am looking for someone to compare my code with

I really need to know if my functions are correct or could have been done differently before i proceed

Because i am going to use the same formulas on all the other instructions

[glVertex3f]

"Why use a horse and buggy on the interstate when we have cars" - glVertex3f

:P

[Doomulation]

Hehe, good reply glvertex :evil: that's exactly the point I'm trying to make!
As of now, the GB emulator I'm co-working on is under heavy development (read: it still has much to do before even concidering a release).
It runs only a few demos, very crippled. No speed control, no interrupt control, no sound emulation...
basically, it only draws the scanlines and has the ops done (probably with lots of bugs too).

[Kevin19]

HAHAHA
Read what and here
I only asked for a little observation

Because i foresee a long time before i get any result displayed on the screen

It is going to be one hardass job to get anything running or drawn under dos

[Doomulation]

Then don't do it in dos :icecream:

[zenogais]

Actually, I spent a long while learning assembly langauge before I ever started on my first emulator. Assembly language is an excellent tool for the aspiring emu author, because it teaches you how the low-level hardware works and how it communicates. I'm just saying I wouldn't use it to code an emulator.

[Kevin19]

I am not sure what you people are getting at

But it is madness to even think of assembling such complexity as an emulator in assembly

And i have never attempted such thing before you get anything in your head

But yes like zenogais it is the best basis if you are working on an emulator or anything that requires knowledge of the system itself It is even a necessity

in my opinion

[Doomulation]

Now, if I translate this,


"Why use a horse and buggy on the interstate when we have cars" - glVertex3f

...we'll get this:
"Why use assembly when you can use C/C++?"
OR
"Why use pure win32 api programming when you can use MFC?"

We will simply write out program without knowing how the inner working of the code we use works :icecream:
Although knowing how the hardware communicates is a good thing... but it doesn't require asm.

[aprentice]

Now, if I translate this,



...we'll get this:
"Why use assembly when you can use C/C++?"
OR
"Why use pure win32 api programming when you can use MFC?"

We will simply write out program without knowing how the inner working of the code we use works :icecream:
Although knowing how the hardware communicates is a good thing... but it doesn't require asm.

Some people find winapi more easier than MFC, I know I do.

[glVertex3f]

Im not saying "dont learn or ever use assembly" or anything like that.

I think its great we learn this stuff for the concepts and understanding. Im just saying there's really no reason to write a large program (emulator) in assembly. (Except for the novelty)

[Kevin19]

I think you people have encouraged Me to upgrade to WIN32API

Or at least that is the name of the book i got here

WIN32API and introduction to MFC

[Kevin19]

and the second reason that i am going to need a real easy way to access files or something to create a sort of debugger

Because my last debugger in the chip8 project was kind of burdensome to code

[Cyberman]

The WinAPI is actually easier to understand than the Poo people call MFC. Unfortunately sometimes obfuscation of what is going on underneath makes for poor programing. I never use MFC to be honest because as many professionals have observed "MFC is a poor excuse to hide all the inadequacies of win32 with even worse ways of handling all the functionality of the windows API"

I use Borlands classes and the win32 API directly. I don't waste time with something that is moot and pointless (MFC in this case).

As for how Kevin19 is doing things, I think most of you are arguing for the sake of arguing, obviously he is having fun with what he's doing. If he wants to use DOS or win32API let him. He'll have fun and learn something, it's bettern than learning nothing as a result.

I really find MFC just another anoying layer of obfuscation by Microsoft that really isn't useful unless you like to cut your head off and use it for shark bait regularly :teehee:

Cyb

[zenogais]

I personally use MFC, and I find it to be easier than WinAPI as I don't have to create long files dealing with useless message handling switchs, which was something that always annoyed me about the WIN32 API. Although MFC isn't perfect, I find that I write alot less code, and the windowed code that I write has alot fewer bugs and memory leaks. But don't be fooled, the WIN32 API is not nearly as bloated as MFC in terms of interface size. I'm sure eventually I may end up just writing my own wrapper around WIN32, as alot of programs who deal with it often do, but I'd only be doing this to avoid the bloat of MFC while keeping the idea behind it achievable.

[Kevin19]

I exmained both and WIN32API looks more extensive and sensible to the eye

But all this windows programming business is really frustrating so many pieces of code to deal with one thing

I know this is win32api

But is not there something that lets you build and modify the properties of the window and make menus other than program them yourself using resource files

I would really appreciate it if you people could help me understand this interface better
Because i really need to get done studying the basics of it
So i can start trying out THE 6502 CPU code i programmed

[Kevin19]

I do not want to sound petty

But this is really frustrating scripting the resource file

Could not they just make a friendly PROGRAMMER interface like in visual basic to design your menus and all the visual appendages

[smcd]

You can make everything in a resource editor and instead of using "real" windows, use the designed dialogs (this is what I often do), or use a platform like Borland C++ Builder.

[Doomulation]

Lemme quote y'all... starting with apprentice =)


Some people find winapi more easier than MFC, I know I do.
I really can't see how people find win32 api easier. For example, you need to define a message handler when working with windows. In MFC, you can sinply override those messages you want to handle. Ahhh, sweetness.
And not to even bother with the accursed structs when you for example want to add an item to listview... MFC has functions that doesn't use all of the functionality of those, hence making it MUCH easier to add a simple line without much hassle. Of course, it still provides struct functions so you don't lose out anything on using MFC.
And the fact that all functions are wrapped up in classes and you don't have to use GetDlgItem or such... that's just friggin' sweet!


and the second reason that i am going to need a real easy way to access files or something to create a sort of debugger

Because my last debugger in the chip8 project was kind of burdensome to code
That is the beuty of win32 programming ;) it saves you a lot of trouble rather than dos.


The WinAPI is actually easier to understand than the Poo people call MFC. Unfortunately sometimes obfuscation of what is going on underneath makes for poor programing.
It sure isn't. Win32 api is confusing, hard to understand, hard to get right and a friggin' pain in the ass. Sure, mfc hides a lot of details, but it never leads to poor programming.


I never use MFC to be honest because as many professionals have observed "MFC is a poor excuse to hide all the inadequacies of win32 with even worse ways of handling all the functionality of the windows API"
Well, that's them. MFC is rather good, if you get to know it. I have yet to see ONE THING that mfc makes worse than using the real win32 api.


I use Borlands classes and the win32 API directly. I don't waste time with something that is moot and pointless (MFC in this case).
Once again, it isn't pointless and moot.


As for how Kevin19 is doing things, I think most of you are arguing for the sake of arguing, obviously he is having fun with what he's doing. If he wants to use DOS or win32API let him. He'll have fun and learn something, it's bettern than learning nothing as a result.
Actually, you see... it's better to lead a mad who's lost out of the labyrinth rather than leave him there. I think kevin should try an effort to learn win32 api. Dos is outdated is is obviously crap.


I really find MFC just another anoying layer of obfuscation by Microsoft that really isn't useful unless you like to cut your head off and use it for shark bait regularly :teehee:
And I think you're wrong ;)


I personally use MFC, ...
Yes, I think zenogais is correctly here... MFC is really useful. But oh I'm repeating myself :evil:


I exmained both and WIN32API looks more extensive and sensible to the eye

But all this windows programming business is really frustrating so many pieces of code to deal with one thing

I know this is win32api

But is not there something that lets you build and modify the properties of the window and make menus other than program them yourself using resource files

I would really appreciate it if you people could help me understand this interface better
Because i really need to get done studying the basics of it
So i can start trying out THE 6502 CPU code i programmed
There is. The easiest way is to do it is to create resources, then use the LoadMenu() api, which will give you a handle to the menu. There's also other menu functions such as ShowMenu() and EnableMenu() if I'm not mistaken. There are also functions to modify and create menues dynamically. Such are CreateMenu, CreatePopupMenu, AppendMenu, and more. You should take a look into the windows sdk. VC++ has all win32 api functions documented.


I do not want to sound petty

But this is really frustrating scripting the resource file

Could not they just make a friendly PROGRAMMER interface like in visual basic to design your menus and all the visual appendages
I thought this too when I first started... but there is a grid which can be enabled in the toolbar. Also buttons that align buttons and make them same size/height =) Great stuff.

[Kevin19]

Where and how do i use this resource editor

I know this question might sound very general
But I just got to the chapter that teaches about menus and dialogs and the scripting language looks very dreadful in a way that i cannot explain

I will be honest with you i am not a big fan of scripting languages

[Doomulation]

Lol, the resource editor is part of the visual c++ envoirment. Click the resources tab and insert whatever resource you want ;) It'll bring up the resource editor. Also, if you double-click on them.

You'll find menues in windows is very easy actually. With resources, almost no code is necessary =)

[smcd]

There are also numerous free resource editors, for free C and/or C++ IDE & resource editor, you might check out Mingw Studio, http://www.parinya.ca/

It's practically a clone of VC++ 6's IDE, though not as fully featured. For being free (and cross platform, wow!) it is great.

[Kevin19]

Yes i tried to make a resource with the MVC++ resource editor
and it seems to give me this error

d:\win\resource.rc(20) : error C2143: syntax error : missing ';' before 'constant'
d:\win\resource.rc(20) : error C2501: 'LANGUAGE' : missing storage-class or type specifiers
d:\win\resource.rc(20) : fatal error C1004: unexpected end of file found

[Kevin19]

Nevermind
I solved it