nesdev.com

That's zoomed out enough that I can't tell from that picture the extent to which that Vp-p is actually signal instead of noise on top of the signal.

Different TVs do different things on CVBS input. I was under the impression that they were only supposed to normalize to sync depth, but at least one other person here on the forum found that his TV also normalized chroma amplitude; in this latter case any attenuation by the extra capacitor that you're seeing on color would be normalized out.

Sorry, here is a better picture:


I am using a Kramer VP-413 connected to an LCD computer monitor. Looking more closely when adding and removing this cap, there is no loss in sharpness from it. There is a very fine, light checkerboard pattern on the whole display that goes away when adding this cap. The colors do get a little less saturated with the cap, but maybe that's a good thing, not sure.

Playing with my scope, I sure wish it could sync properly to this, but it's not looking like it can. The image just rolls. It seems to have some pretty awesome video features, I can zoom way in on the video (shown). Not useful without syncing. It doesn't let me control the syncing/trigger, it just lets me choose the options shown in this mode and none of them work right.

You've got a nice Tek scope there, I can't imagine they removed the "sync to NTSC scanline #X" feature that's in my crappy one (TDS1002)

Does it look like that's the chroma carrier?

Oh it does have sync to line x in the trigger menu, but it can't trigger on anything with this signal. The best I can do is set the trigger to roll which allowed me to take that screenshot.

Here is without the 560pF:


Here is with the 560pF:

Ok, yeah, those artifacts look to me like chroma-into-luma bleed. I suppose the capacitor lowpass filters out some harmonic of the NES's square chroma signal.

Wow that's a nice o-scope. Thanks for taking the measurements, now at least we know that the bead is not a solution.

Are the last 2 shots you took with the top left corner with your tantalum bypass cap or without?

I do have to say, the composite out of the AV Famicom is WAY better than the NES or any console with the AV mod. It's like night and day.

One of the advantages of my job is this great scope that I get to use, I love it. The last 2 shots were both with the tantalum bypass cap.

A basic question I have is that with the tantalum route, you do not need to lift the PPU Video Output pin to eliminate jailbars? That is a good thing if you do not have to do that.

So, if you want to improve the picture quality on an AV Famicom to make it sharper, you should remove the 560pF capacitor and the ferrite choke/bead and bridge the connection where the ferrite choke/bead was with a wire. Also, you should add a tantalum capacitor between +5v and GND, but is there any special place where you should put it? If I have read this thread correctly, then a 4.7uF 35V Tantalum

For the original Famicom, should we do something similar for simplicity's sake, build the AV Famicom's output circuit minus the 560pF capacitor and the ferrite choke/bead. The AV Famicom uses a 220uF 6.3V electrolytic capacitor and we can reuse the existing transistor. The 4.7uF 35V Tantalum should be added between +5v and GND as well with this older system.

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog

No need. Ben Boldt didn't see any difference with the ferrite present/absent at all.

Okay, so you can keep the choke in place and limit the amount of work you have to do. Do you even need to add a tantalum to an AV Famicom? I can't see any jailbars in mine and I have looked hard for them. Do they become more noticeable once the 560pF is removed?

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog

I have not tried that yet. My pin is still connected in my test unit.

The 560pF seems to have no effect on the jailbars, but a finer grid pattern appears without it. lidnariq pointed out that this artifact is chroma-into-luma bleed. I would recommend using the 560pF. It dulls the colors slightly but does not make the image any more blurry. I also brought a typical cheap/thin yellow RCA cable with me today but I forgot to try it. I want to see if the ferrite bead makes a difference with that cable. I would not recommend making any change to a real AV famicom, Nintendo seems to have gotten it right with this model.

I have been having somewhat of a disaster of a night, not going too well. I finished wiring up the soccer cart into 240p Test Suite. It wasn't too bad, I had to use some copper foil to get at PPU /WR and CPU R/W but that went okay. I got home and went to program my W29EE512P-70 and found that my fresh Chinese PLCC-32 to DIP adapter had 2 (TWO) opens in it... Fixed that and programmed the chip. I put the cart in my Hi-Def NES and KABOOM, something blew up! No power with or without the cart in there now... Another project for another day. Hopefully fixable.

So I sat down with the cart, looked and probed for mistakes, shorts, etc, found nothing. I bravely threw it into another NES, and it was okay, no explosions... Not sure what happened with the hi-def NES, no visible damage anywhere.

The 240p Test Suite PRG runs great. I did end up going with the BN-ROM approach, I used a 74LS163 that I had, which is compatible in this case. However, the CHR-RAM isn't working quite right.

The same tiles remain glitched when resetting, jiggling, etc. I used a UM6164AK-25 for the CHR-RAM. I tried swapping from the 'H' jumper to the 'V' jumper, that introduced additional problems, went back to H. I also tried swapping /OE and /CE on the RAM (PPU +A13 and PPU /RD), that made big problems, went back the way it was. I have a whole stack of these 6164s, I tried a different one and it didn't make a difference. Could -25 be too slow? Hmm... Anyway, it is good enough to use it for video testing purposes, just sort of a shame it is glitchy.

The NES PPU needs timing somewhere between 186ns (one pixel) and 372ns (two pixels), so I suppose the RAM speed might explain things?
In practice, the PPU timing has the address bus guaranteed stable after one half pixel (edit: 93ns) so as long as the RAM has a tCE-to-valid and tAddress-to-valid of not more than 280ns, and a tOE-to-valid of not more than 186, it really ought to work.

I have no idea what to make of that the bad picture is almost entirely made of sprites in the right place but with the wrong graphics.

These SRAMs came mysteriously in the bottom of a big bag of ISA and PCI cards, wrapped in aluminum foil. They appear to have been used before. It is possible that they are damaged.

Based on that one blue sprite in Gus's vest that got displaced to the left side of the screen, I don't think that's a CHR RAM problem. It could be an OAM DMA problem. If it affected only tile number, a CHR RAM problem might be believable. But it affected one X coordinate, and that's copied straight from internal CPU RAM to the PPU's OAM data port.

_________________
Pin Eight | Twitter | GitHub | Patreon

Very interesting, you have a great point. Did you notice the sprites that should be mirror images - in many cases one displays correctly, the other does not. This should be accessing the exact same CHR data. I just went and ran a few other games in this NES and verified that it is not broken.

Has anyone run the BN-ROM version on real hardware before? I am using 240pee-0.16.