my next emulation project

[serge2k]

hmmm

I keep getting writes to a weird place 000E. What should I do with these?

If I just allow it the program continues executing but ends up crashing.

If I just ignore it the program continues fine, for a while anyway. Then it crashes (debug assertion failed in VS2008).

I'm still getting graphic errors.

On the other hand I have dramatically improved my speed.

Still having issues with my code though.

attached is the newest source.

Attached Files

Space Invaders 2.0.rar (1.57 MB, 2 views)

[Hatorijr]

what i recommend doing is testing every opcode you have to determine if it behaves properly, if they behave as intended, they should not have any errors. i know i have found some crazy errors in my cpu core caused by not coding for all possibilities.

Edit: trying to run your emu, how do i get it to load, i get a blank screen with a dos box blink, i did not see any of the 4 space invaders rom files so i figured i would try to put it in the directory with mine but nothing.

Edit2: i notice in your code, did you hard code the rom file path? also i can safely say you got cpu core errors, at first glance it looks like your drawing is a bit slow but that may be due to how many vertices you have made which i started doing at first too. you could create a texture to render to and when you go to render a frame, place the texture on top of a quad which would only use maybe a total of 6 vertices which would be a lot faster. but in any case, good work so far, it has really come together.

---

Last edited by Hatorijr; August 5th, 2009 at 16:21..

[serge2k]

I really don't know enough about directx to do that.

Do you have any links to good tutorials?

[Hatorijr]

well actually i created a test app for dax once to show off that method, i could upload it for you and than you can play around with it, its not optimized well but it still shows the basic idea.

Edit: here is the test project, its not quite well optimized but shows the technique. it was made for a chip 8 method of drawing but i am sure you could make it work for you.

Attached Files

render to texture.rar (482.7 KB, 4 views)

---

Last edited by Hatorijr; August 6th, 2009 at 20:18..

[serge2k]

hmmm

tried implementing that on both emulators. I get output but it's garbled. Not sure whats wrong. probably have an incorrect calculation somewhere.

Thanks for the help.

[Hatorijr]

how garbled, i know if you try to have windows manage the texture with a non power of 2 texture it will garble output which i did not know until i switched to power of 2 on my space invaders.

Edit: o calculations....you will have to redo calculations possibly, a lot of that was designed to be implemented in chip 8 emus and not space invaders so you may have to rework that i can help if you need it, if i get time tomorrow i may redo it for a more space invaders like implementation.

[serge2k]

garbled as in stuff like this


thats with no changes to the way the CPU executes, just the drawing code.

[Hatorijr]

can you send me an updated copy of your source? or just post an updated copy on here would work.

[serge2k]

updated source

I modified so if you select the .h (and the rest are in the smae directory) it will work.

Attached Files

Space Invaders 2.0.rar (1.58 MB, 1 views)

[Hatorijr]

umm what you could do, is do small drawing tests, plot pixels at specific spots and check if they are placed where they should be. what i eventually did with space invaders was make my texture 256x256 so that i could set it as a managed texture, than i had a much easier time plotting pixels. all i had to do was change texture coordinates when i created my vertices so it only showed the correct part of the texture at any given time. but i have a feeling your location calculations may be off and its trashing your graphical output to the screen.

[serge2k]

well I'm still not sure what the problem is but I'm following your suggestion.

I'm noticing something weird though.

if I tell it to draw at 2400h it draws 8 pixels down. fine for now.

The problem is that it doesn't draw them in the upper right corner, UNLESS I put in a printf, then it works properly.

also, if I set my texture to be blue to start as soon as I draw anything anywhere it turns completely to a black background.

I have it set to clear to red, I have nothing anywhere else.

edit:

annnnnnnd I feel stupid. it is my location code. it was an obvious error.

Basically I was drawing the first byte at (0,0) then the second at (0,1) instead of (0,8). Thats why it was only using a little chunk of screen on one side. So I guess I will fix that.

after I watch my episode of Eureka.


edit 2: this is really annoying.

here is the newest write to memory function

void Processor::Write_Byte(u8 val, u16 location)
{
	u16 tmp;
	if(location >= 0x4000)
	{
		tmp = location;
		location -= 0x2000;
	}
	else if(location >= 0x2000)
		tmp = location + 0x2000;
	else
	{
		return ;
	}
	
	
	if(location >= 0x2400 && location < 0x4000)
	{
		graphics->drawSprite(((location-0x2400)%32)*8,(location-0x2400)/32, val);
		
		printf("%d\t%d\n",(location-0x2400)%256,(location-0x2400)/256);
	}
	memory->Write(location, val);
	memory->Write(tmp, val);

}

that produces



which is great, working fine right.

but by commenting out that seemingly useless printf statement

---

Last edited by serge2k; August 8th, 2009 at 09:44..

[Hatorijr]

the way that space invaders draws is weird mind you but if you know the general trick it works.

i never had to flip my screen after drawing i just went ahead and drew how i saw it drew the game screen. i start at 0,0 and i drew each byte downwards and i kept a counter to know what height i was at and when it hit the last row i incremented x and started all over.

Edit: i would debug that function in visual studio and find out exactly what its doing when the printf is there and when its not, it might be doing something that not obvious at first is all i can think of. as that is weird.

[serge2k]

chip8 emulator is having the same problem.

I don't understand why a printf solves it. Really weird.

[Hatorijr]

you try and debug to find out exactly whats going on when it plots a pixel?

[serge2k]

Still haven't been able to figure out.

I think it's either a memory problem or a timing problem.

[Exophase]

Ah yes, the infamous heisenbug that only occurs when you aren't debugging it.

If you think it's a timing issue try replacing the printf with a delay, and change the amount delayed by until it goes away.

Normally in an emulator you don't draw the graphics right when the video state changes, but at certain synchronization points like per-scanline or per-frame. Chances are it'll be per-frame for you. Then you synchronize this event with real time on the emulating machine so it happens at the right interval.

But, I think your symptoms don't suggest a timing problem. You should paste what the drawSprite method is doing. It could be relying on random state, like an uninitialized variable, that the presence of the printf is modifying.

[Hatorijr]

i would try to help but i been so busy lately with starting a new web development job that i just do not have the time during the week, maybe this weekend ic an try to help you with it unless you solve the issue.