Next Generation Emulation banner
Cancel
Create thread New Forums

CHIP8 thread

1 reading
Jump to Latest
381 - 400 of 486 Posts
#381 ·
No bug yet. But I'll concord a test ROM and beat that emulator to a pulp. :p

Nah, just kidding.

Regarding the flicker filter, what I do is implement an event system so that the draw opcode would actually just draw to a video RAM buffer.
The draw opcode will also flag any collision to a separate flag, which contains both the start position of the sprite being drawn and the position of the collision, and then push the flag into an array.
When a timer event occurs (mine counts 60 times per second), I'll fire an event to a pre-drawing routine.
The pre-drawing routine will then look ahead in the buffer and see if a draw operation will occur within the time frame of the next timer event (since there is a set number of opcodes executed per time frame, this is easy).
Now check if there is an erase operation flag, then check if there is a drawing routine in the time frame. If there is no drawing routine, raise the erase flag if it's not already raised, raise an intentional-flicker flag if the erase flag was raised. If there is a drawing routine, send a draw event if there is no erase flag, or if there is an intentional-flicker flag. Otherwise, clear all flags and flush the collision flag array.
The drawing routine will then evaluate the collision flags and determine if it's an erase operation (start position of sprite is the same as the position of the collision), or just a normal collision detection (start position of sprite doesn't match the position of the collision). If there is an erase operation and the intentional-flicker flag was raised, render it. After this, clear all flags and flush the collision array.
Then the rest is just render the video RAM buffer to the screen buffer. :)

What is the collision array for? It's so that I don't render the entire screen all the time. I'll just read in the positions in the collision flags, compare it with existing sprite buffer and draw the pre-rendered sprite instead of re-rendering it. The positions will be used for motion-interpolation (ooh) so that instead of erasing and drawing the same sprite again, I'll just move it in the scene. Smoothly... :D (it's also actually used to compensate for the lag caused by the delayed rendering of some frames since obviously, this method doesn't render everything exactly when it occurs)

That's how I'm doing flicker filter and motion-interpolation now. It's been perfect so far. There is practically no such thing as flicker anymore, and some games behave as if they were built in Flash. I'm only having problems with some drawing performance issues... But when those are sorted, I'll release the next version.
 
#382 · (Edited)
feel free to break my emulator as much as you can, just let me know whats broken lol. i know of some games that do not work and i have my game collection ordered in working and non working directories. most broken games are due to being hybrids and no one has posted anything really on whats needed for hybrid games.

i am still working on my game scanner to pull out what games use what keys. some games work very easily if they are aligned correctly but for games that are not aligned right, i am having severe troubles with, so it might take me some time to perfect.

i am thinking that i might have a solution to my flicker issue due to the way i do rendering. and it would make it very simple compared to what you posted lol. i might give it a try later tonight and report back my findings, if it works i can post a summery of what i did.

update: i just monkeyed around with my code and so far, my flicker free mode idea seems to work much better than i expected, some games seem to respond well to it. pong is mostly flicker free except the enemy paddle, got to work on that. airplane is flicker free basically.
 
#383 ·
Ah, the enemy paddle in Pong... I am somewhat under the impression that it's actually using 2 sprites to draw the same thing so trying to detect erasure on it will be pretty elaborate, hence my way of doing it is kind of... a bit too complicated.

Though to be quite honest, I never tried to disassemble the whole game so I don't really know the logic behind it.
 
#384 ·
overclocked said:
Yea (Bill_gates) you're right!

Test 24 is the last in Tronix SCTEST-suite, so that means FNC actually passed the 23 first which it very good! Test 24 is to check the functionality of the I=I+VX opcode AND also the overflow of it. As it probably is the overflow check that fails this is not a crucial part of Chip-8 compatibility. My ChipMon problem with FNC is due to something else. I'll look into it and post my findings here. The program uses self-modifying chip-8 code, which is a must to get the monitor to work as I want. Anyone know if this is a problem with FNC?
Click to expand...
You're talking about the SCHIP game Spacefight 2091, right? I've always assumed it's a bug in the game. I once included an optional hack in FNC to make it work, but removed it in a later version. There's no I=I+VX overflow on either Joseph Weisbecker's 1977/8? official CHIP-8 interpreter for COSMAC VIP, or on Eric Bryntse original SCHIP specification for HP48.
and IIRC, some games rely on I=I+VX not touching VF.

Something else: Which (S)CHIP games are actually *gasp* enjoyable to play? Here's my list: Ant, Blitz, Brix, Joust, Rush Hour, Sokoban, Tetris. (includes bias: Rush Hour and Sokoban are mine:p)
H.Piper and Loopz look good too, but I can't get into it easily.
 
#385 · (Edited)
ChipMon goodness

For now, my ChipMon program (memory hex editor) is working quite good. It is now possible to scroll through the entire memory and change any value at will. But you really want to keep clear of the actual values that make up the monitor itself.. ;)

The reason for the scroll problem seen earlier by some of you here, was that the old code was written to demand overflow handling of the instruction "7XNN -Adds NN to VX" which is not part of the standard. I exchanged it for a "8XY4 - Adds VY to VX" which has overflow handling according to the standard and now it seems to work for most of the emulators I've tried. I'll post it here for you to try out when I've ironed out the last known bug still left..

When compiling the assembler code for chip-8/SuperChip the start screen looks like this:
https://www.dropbox.com/gallery/10348066/1/ChipMon?h=c9a86f
 
#386 · (Edited)
all i see are red x's where your pictures should be
try using photobucket or image shack insted of dropbox
 
Save
Reply Quote Like Like
#388 ·
Hi, Im new to this forum, but have been coding for a couple years now. Anyway, I wanted to get into emulation, and now Im writing a Chip8 emulator. Im using this site as a reference and help for my emu. After I got most of the opcodes finished, I decided to work on screen output, so I could actually see something. My code compiles fine, but I get a segmentation fault upon executing it.
Other helpful info:
-Im compiling using Code::Blocks on Windows

-The problem is somewhere in the draw_pixels function

-If I change SCREEN_WIDTH and SCREEN_HEIGHT to something smaller, it doesnt give a seg fault but nothing appears onscreen. This makes me think the problem is with the pixels variable in the draw_screen function.

Could someone please help me figure out whats wrong?
 
Discussion starter · #389 · (Edited)
Jacic said:
Hi, Im new to this forum, but have been coding for a couple years now. Anyway, I wanted to get into emulation, and now Im writing a Chip8 emulator. Im using this site as a reference and help for my emu. After I got most of the opcodes finished, I decided to work on screen output, so I could actually see something. My code compiles fine, but I get a segmentation fault upon executing it.
Other helpful info:
-Im compiling using Code::Blocks on Windows

-The problem is somewhere in the draw_pixels function

-If I change SCREEN_WIDTH and SCREEN_HEIGHT to something smaller, it doesnt give a seg fault but nothing appears onscreen. This makes me think the problem is with the pixels variable in the draw_screen function.

Could someone please help me figure out whats wrong?
Click to expand...
According to Visual Studio it's on this line:
pixel[width * X + Y] = SDL_MapRGB(screen->format, 0, 0, 0);

With this error:
Unhandled exception at 0x012732e7 in SDLTest3.exe: 0xC0000005: Access violation writing location 0x00580100.

Ignore the SDLTest3.exe name, that's just what I called it. :p

Edit: Try this formula instead for your pixel setting(assuming a 32bpp surface):
pixel[x + (y * surface->w)]

That seems to have fixed it for me. I inserted an SDL delay so I could see the output slower[on my PC it went to a black screen instantly with space invaders, so I slowed it down to see its progress].

http://pastie.org/1314823
 
#390 ·
Dax said:
According to Visual Studio it's on this line:
pixel[width * X + Y] = SDL_MapRGB(screen->format, 0, 0, 0);

With this error:
Unhandled exception at 0x012732e7 in SDLTest3.exe: 0xC0000005: Access violation writing location 0x00580100.

Ignore the SDLTest3.exe name, that's just what I called it. :p

Edit: Try this formula instead for your pixel setting(assuming a 32bpp surface):
pixel[x + (y * surface->w)]

That seems to have fixed it for me. I inserted an SDL delay so I could see the output slower[on my PC it went to a black screen instantly with space invaders, so I slowed it down to see its progress].

#1314823 - Pastie
Click to expand...
Thanks for the help, but it still doesnt work. Well, I dont get a seg fault but it exits with a runtime error. Here is my new draw_pixels function:
Code: 
void draw_pixels(SDL_Surface *screen, int X, int Y, int color)
{
  Uint32 *pixel;
  int width;
  SDL_LockSurface(screen);
  pixel = (Uint32*)screen->pixels;
  width = screen->pitch / sizeof(Uint32);
  if(color == 0) //black
  {
      pixel[X + (Y * screen->w)] = SDL_MapRGB(screen->format, 0, 0, 0);
      //pixel[width * X + Y] = SDL_MapRGB(screen->format, 0, 0, 0);
  }
  else //white
  {
      pixel[X + (Y * screen->w)] = SDL_MapRGB(screen->format, 255, 255, 255);
      //pixel[width * X + Y] = SDL_MapRGB(screen->format, 255, 255, 255);
  }
  SDL_UnlockSurface(screen);
}
On C::B it just keeps exiting with "status 3", although, like I said, I dont get a segmentation fault now.
I think the problem is now with this line:
stack.push_back(pc);
 
#393 ·
LoRd_SnOw said:
Sorry for the mix up, yes i did try this before. I get a blank screen when doing so. However when i do this.

Code: 
Dim vx AsInteger = opCode And &HF00
vx >>= 8
 
REG_I += (REG_V(vx) And &Hf) * 5
It will show the fonts but they will appear scrambled, i know im not suppose to add "+" right after the Address Index, but with out it nothing shows on screen. I'm really not sure what the problem could be. Im pretty certain i have my dxyn code fine as every chip-8 game i seem to throw at it seems to render correctly. As for the font test for SuperChip, I haven't implemented any SuperChip Instructions yet.

Does 15 Puzzle require SuperChip? and/or does it require 16 by 16 sprite drawing? Well, because I haven't implemented that either into my dxyn draw code.


Also for FX29, are the values in address index suppose to start from 0?

Thanks.
Click to expand...
Just to quote myself, i did manage to fix the problem some months ago. Turns out i never had the chip-8 fonts loaded from the start. However, now i do have both chip-8 and schip fonts. Unfortunately, i wasn't able to find a table on cowgods website for schip fonts, so i had to make my own, which was rather tedious but atleast it came out okay.
 
#394 ·
Hi guys,

I lost interest in the development of the chip8(16) pascal compiler. So I decided to post the source code here. The archive includes a few chip8 and chip16 examples of programs, written in c8Pascal and full source code of c8pascal compiler (in Pascal programming language). I hope that someone does come in handy ;)
 
#395 ·
Hey everyone!

So I downloaded about 15 or so roms that are in public domain so that I could test how my chip8 emulator was running. I opened one rom in notepad to see the format. Now I was expecting to find a series of a 4 letter/number sequences. Instead I found gibberish, mostly characters that aren't present in the English language. I looked in some of the other roms only to find the same thing.

I thought that perhaps I was viewing the file the wrong way and opted to run my emulator using the files anyway. The debugger confirmed that the same gibberish I saw in the files before was being read into memory.

Here is an example of what PONG2 looks like:
jk l?m ¢êÚ¶ÜÖn "Ôfh``ðð0 Çwiÿ¢ðÖq¢êÚ¶ÜÖ`à¡{þ`à¡{`‹Ú¶` à¡}þ`
à¡}`ÜÖ¢ðÖq†„‡”`?†a‡FxF?‚GiÿG iÖq*hc€p€µŠhþc
€p€Õ?¢a€?º€?È€?Â` ð"ÔŽ4"Ôf>3fhþ3hyÿIþiÿÈyIi`ðvF@vþl¢òþ3òeñ)de ÔUtò)ÔU €€€€€

Who knows what the heck is going on here?
 
#398 ·
zodab12 said:
Hey everyone!

So I downloaded about 15 or so roms that are in public domain so that I could test how my chip8 emulator was running. I opened one rom in notepad to see the format. Now I was expecting to find a series of a 4 letter/number sequences. Instead I found gibberish, mostly characters that aren't present in the English language. I looked in some of the other roms only to find the same thing.

I thought that perhaps I was viewing the file the wrong way and opted to run my emulator using the files anyway. The debugger confirmed that the same gibberish I saw in the files before was being read into memory.

Here is an example of what PONG2 looks like:
jk l?m ¢êÚ¶ÜÖn "Ôfh``ðð0 Çwiÿ¢ðÖq¢êÚ¶ÜÖ`à¡{þ`à¡{`‹Ú¶` à¡}þ`
à¡}`ÜÖ¢ðÖq†„‡”`?†a‡FxF?‚GiÿG iÖq*hc€p€µŠhþc
€p€Õ?¢a€?º€?È€?Â` ð"ÔŽ4"Ôf>3fhþ3hyÿIþiÿÈyIi`ðvF@vþl¢òþ3òeñ)de ÔUtò)ÔU €€€€€

Who knows what the heck is going on here?
Click to expand...
That's the native language in mars so you will have to visit some language school and learn how to read it :p


on a more serious note.... that was a good one :p if you want to view/edit the rom you better use a hex editor as mentioned here. notepad is good for text but not for that kind of things and seriously how do you came to the idea to open it with editor???? :???:
 
#399 · (Edited)
awesome. I can see the hex data now. Thank you. But I'm also suddenly understanding why a debugger is so necessary. I can't simply use the one in VS because it isn't converting these integers to hex values that have meaning to me. Instead the debugger just tells me that the first opcode is 8950, which is quite meaningless.

EDIT: And I just discovered that there is a hexadecimal display option in the VS debugger. This will make life much easier
 
#400 ·
Save
Reply Quote Like Like
381 - 400 of 486 Posts
About this Discussion
485 Replies
57 Participants
Last post:
@ruantec
Next Generation Emulation
posts
2.2M
members
465K
Since
2001
A forum community dedicated to all emulation enthusiasts. Come Join discussion on all platforms from Nintendo, Microsoft Xbox, Sony Playstation, to PC. Coding, tips, builds, specs, tricks and more.
Full Forum Listing
Explore Our Forums
Open Discussion Game/Console Discussion Hardware Discussion ePSXe Software Discussion