nesdev.org

I think I got quite a good result. It is now much closer to what I see on the tape than it was before. Thanks tepples and lidnariq. Source code (caching code redacted for brevity, performance may be bad): SDL_Surface *s; const int xres=256*1, yres=240*1; void Init() { SDL_Init(SDL_INIT_VIDEO); SDL_I...

No, because the reconstructed chroma is subtracted from the received composite signal to calculate the true brightness. Hmm... Thanks for the explanation. I did not understand it, though... I am unsure how to phrase a question. I would think this in terms of an algorithm and I cannot figure out how...

It raises a new one, instead: Would that not mean that a stripe of constant color would appear having a fluctuating brightness? No, because the color phase doesn't reset with every pixel: (hhhhhhll)(llllhhhh)(hhllllll) \_pixel1_/\_pixel2_/\_pixel3_/ Doesn't that only confirm that it would appear to...

Pixels are eight half-cycles wide, not twelve. Oh! Wow. New information. Thanks for the correction. Does not answer my question, though. It raises a new one, instead: Would that not mean that a stripe of constant color would appear having a fluctuating brightness? hhllllllllhhhhllllllllhhhhllllllll...

The horizontal position of any given point on the scanline is completely determined by the time difference since the last horizontal sync pulse. Hmm... So let me get this straight. I'll use these simplified representations where the length of sync/black/pulse are irrelevant. A non-shifted scanline:...

One thing I don't understand about this pixel running phenomenon. If the scanline signal is shifted by 4 clocks every scanline, how come in all NTSC NES recordings I have seen so far, the edges between black and white pixels are completely artifactless while only color edges have artifacts? I am hav...

After spending a lot of CPU time trying to find the combination of timings that passes the ppu_vbl_nmi test, including test 7, in an automated manner, unsuccessfully , I dug up my earlier revision to try and discover what it was that I did earlier that actually worked. Reworking the complicated algo...

I am just wondering whether in my emulator, can I use the same buffer for $2007 reads by the CPU and for VRAM reads triggered by the scanline rendering. Knowing how PPU works either way would be helpful. Using the same buffer would make the emulator a bit shorter and less filled with special cases, ...

As in "I don't know what it yields but prolly nothing useful", or "I know it just gives the same value you would have gotten earlier if you read it earlier"? The former. It's useless to rely on that read regardless of whether the PPU initializes the buffer to a known state or no...

beannaich wrote:That is an indirect way of accessing it, it also won't yield anything of use.

As in "I don't know what it yields but prolly nothing useful", or "I know it just gives the same value you would have gotten earlier if you read it earlier"?

http://savepic.su/440214m.gif Wow! I remember that. Both the title screen (from some pirate cart), and the artifacts on the monochrome display that appeared at least when the channel was not properly tuned. Sorry for being selfish, but I would like to hear feedback on the images in my previous post...

beannaich wrote:The buffer isn't directly accessible to the programmer.

Sure it is! Just issue a VRAM read, and only use the first result and don't wait for the second result where the buffer has been replaced with the data you requested.

Do not forget that the TV smooths out the picture only in the scanline. Vertically, the picture remains clear, each scanline looks are very clear. Do you mean that there are distinctly only 240 scanlines (minus portions rendered outside the visible screen)? Hmm, makes sense. So the dot crawl happen...

Okay. Here is a version in which the lines are merged together. Left: Rendered at 256x720, rescaled to 256x240 with box filter. Middle: Rendered at 3072x720, rescaled to 256x240 with box filter. Right: Rendered at 3072x720, line offset -6 (image moved half pixel to the right), rescaled to 256x240 wi...

On the other end, duration of NTSC frame are not multiple to NTSC masterclok and this make subcarrier dots crawling. Familiar term? Oh, I see. So it looks like this? (+4 offset on each successive scanline, +6 offset on consecutive frame, modulo 12, loop length 2 frames) http://bisqwit.iki.fi/kala/s...