Page 6 of 10
about palette colors
Posted: Tue Feb 28, 2006 6:31 am
by lord_Chile
talking about nes 16 color palette for background.
we are taking 1 color: by example, we are taking 2nd byte.
by example 2nd byte is $22 = 00100010 (BGR) colors..
i wanna to knowing the algorithm in order to map it to computer screen (RGB color). any idea?
Posted: Tue Feb 28, 2006 8:24 am
by tepples
The NES palette is not RGB or BGR; it's closer to HSV (hue saturation value). The easiest way to translate from NES HSV to PC sRGB is to load a palette file, which contains a suitable lookup table. Some of the older palette files floating around the net are hand-made, but newer emulators generate a more accurate palette by emulating the NES output signal and an NTSC TV's decoder. Details are in
NESdevWiki:NTSC Video.
question about scrolling
Posted: Wed Mar 01, 2006 11:56 am
by lord_Chile
one scrolling in Y or X advance is 8 pixels?
Then.... in sprite ram, sprite position X or Y, can be not 8 multiple number???
Re: question about scrolling
Posted: Wed Mar 01, 2006 6:41 pm
by tokumaru
lord_Chile wrote:one scrolling in Y or X advance is 8 pixels?
You can scroll 1 pixel at a time. The scroll registers are 8-bits, meaning they can hold values from 0 to 255 (256 unique values). The NES screen is 256 pixels wide by 240 pixels tall. The 8 bits per axis is enough to represent any point in the screen where you'd want the rendering to start.
Then.... in sprite ram, sprite position X or Y, can be not 8 multiple number???
Sprite RAM has nothing to do with the scroll registers. Writes to $2005 only affect the background. For the sprites to scroll you have to manipulate their X and/or Y positions every frame. But you can also place sprites anywhere in the screen with pixel precision. The only thing you can't do with sprites is having them scroll smoothly from the left or from the top of the screen, as they can not have negative X/Y positions.
about emulation
Posted: Thu Mar 02, 2006 6:58 am
by lord_Chile
when you make emulation of nes... do you use classes for creating 6502 nes registers like x, y, a.?. or just can you use directly processor registers of x86 or another arquitecture in order to get fast speed?
Posted: Thu Mar 02, 2006 8:17 am
by tepples
You typically would make a subroutine/function/method to emulate the 6502 and then use local variables inside that. This may end up translating into host CPU registers, or it may end up translating into stack memory if you're on a register-starved architecture (such as x86).
yep
Posted: Thu Mar 02, 2006 8:40 am
by lord_Chile
i mean asm inline for c. just manually work x86 processor registers.. i see many emulators, but they need a lot of cpu power. the fastest is virtuanes. i think that coders dont take into account that emus would be running good in machines like pentium 3, 550 mhz.. (because in my machine, pentium 3, 550 mhz any emus are very slow). any nes emus need 800 mhz..
Posted: Thu Mar 02, 2006 9:29 am
by tokumaru
I run NES, SNES, Genesis/Megadrive and Master System emulators on an old K6II 533 I reassembled just for old games and they work very well. I may have trouble running Nintendulator, for example, but haven't tried.
There must be something wrong with your PIII. Too much spyware, maybe. Most of the time I use FCEU, ZSNES, GENS and DEGA with the computer I mentioned. The newest windows versions, and they still run full speed, even with the 4MB video card I put there.
I don't think you'll benefit much from using the x86's registers and flags. The slowest thing in an emulator of an old console like the NES is the rendering of the screen, I guess, with all the details you have to pay attention to to keep the emulator accurate. Well, I'm not an emulator author so I'd better shut my mouth before I say too much crap.
heheh
Posted: Thu Mar 02, 2006 10:05 am
by lord_Chile
rendering slow?, yes. imagine... i made a script php for view one capture of .nam file of super mario bros. 1st version reading .nam and .chr was very slow (35 minutes in draw image by ie 5). now i make all work in memory. it take 1 minute 10 seconds. i process attribute table correctly

(thanks for your explanations tokumaru) then i can see accurate colors for background. i dont process sprite ram, then you can only see background. processing attribute table is a very funny routine in php, it was hard think on it, i read .nam 64 bytes after 960 bytes of one of four nametables. it generate a type of rare string, i translate string into binary, then i have a string with 64*8= 512 bits or positions, then i scan this string and i send attr tbl to memory detecting positions and 2x2 tile squares 0,1,2 and 3 creating a 32x32 matrix with a value of 2 bits for each position hehehe

.. then easily i say something like:
if im going to show tile in coords (y=32,x=30)..
get_4color_palette(attr_tbl[y][x],&$color0,&$c1,&$c2,&$c3,$arraypalette)
show_sprite_image($color0,$c1,$c2,$c3,pattern,nametbl,$arraypalette,.. )
when i have my webpage, i will show my html generated.
if you wanna to access one byte in 512 bit string:
$byte_number=1; //we want getting 1st byte
$byte_value=substr($byte_number, ($byte_numberx8)-8 , 8 )
PHP
--substr: extract a substring from string
--substr(string,start_pos. note that 1st string pos is 0,how many chars)

Posted: Thu Mar 02, 2006 11:14 am
by tokumaru
Yes, then you can see how complicated rendering can be. Of course, the speed of a compiled program running on it's native processor can't be compared to an interpreted scripting language such as php.
And with your php program you're just dealing with a static screen. You're not dealing with scrolling, mid-screen PPU operations, and other things that require you to use a scanline-based approach for rendering, instead of a block-based one. Well, you can see how complicated it can be.
I really believe you'll get much more speed from improvements made to PPU emulation than to CPU emulation.
best language for emulator programming
Posted: Fri Mar 03, 2006 11:34 am
by lord_Chile
what is the best language for emulator programming??
Posted: Fri Mar 03, 2006 1:43 pm
by tepples
The best language for implementing a virtual machine is the language in which you can most easily communicate the behavior of the virtual machine to the compiler. If that's BASIC, then so be it. Most PC based NES emulators that I've read about are written in C.
question
Posted: Tue Mar 07, 2006 4:36 am
by lord_Chile
i dont know very much about EPROMS.. if i buy eproms, i can saving prg or chr on it, but EPROMS not are rewritable in order to save my stuff, play my homebrew game on nes, clear my chip, and save my another stuff homebrew games i have to using EEPROMS (rewritable eproms), but can i use EEPROMS on nes boards???, or just it's limited to EPROMS?
and another question is : how can i put nsf in my demo??
im using nesasm.. which bank is best to say: .incbin "music.nsf" , imagine a music.nsf cut off in order to contain only 1 song... yeah i know 128 byte header of nsf.. i need init, play and another stuff.. but how can i implement it on code?? can you give me a quick explanation on it, how can i implement it??
thanks.
quest
Posted: Wed Mar 08, 2006 11:22 am
by lord_Chile
for what any games (nes roms on internet) say PRG 0 , PRG1.
example: super mario bros 3 [PRG0], super mario bros 3 [PRG1]?????
what is difference??
Posted: Wed Mar 08, 2006 12:23 pm
by Bregalad
EPROMs and EEPROMs are pinout compatible. The only difference is that EEPROMs are Electricaly Erasable, and EPROMs are only Erasable, that mean you need a UV light machina to erase them.
Play an nsf would be nothing more complicated than this :
Code: Select all
PlayNMI
jsr Init
*: jmp *
NMI
jsr Play
rti
The Init and Play ardress are found in the header.
Also, make sure that you ORG your include at the load adress.
I don't know by hear which byte # in the header is the load, play and init adress. Look at NSF format specifications by Neil Cornett.