Archive for January, 2011

Die Hard

Posted in Uncategorized on January 27, 2011 by pcedev

Should be getting back into town this weekend. I think I’ll be looking for new work after this project/job. I can’t keep going out of town, it’s killing me :/
Anyway, I saw this:,11987.0.html Die Hard WIP translation for PCE huey.

Besides finding some new work/job, I also need to find a new place. Man…. But this isn’t my life blog, so I’ll leave it at that. Updates might be sparse for a while.

Also wanted to say awesome job to Dave/Nodt and team. I checked out the platformer demo. Really nice. Impressed that they got it done that fast too. And that they have something to show to the public. It sucks when you have projects that you can’t show to the public. And they also got someone to help with finishing the cinema art for MSR. Things are definitely look up for them. I hope morale is high.

S-video mod

Posted in Uncategorized on January 11, 2011 by pcedev

I’m out of town (been like that lot these days), but I dragged some equipment along with me (scope, sgx/duo, rom board). Did a few more tests on the SGX, Duo, and SuperCDROM (addon) video output. This time all under 75ohm receiver load. SGX and SuperCDROM are near identical under load. Duo is still over spec, but I suspect a bad resistor either after the amp or the VCE source before the amp.

Did a lot more reading about transmission line theory. I think I have enough understanding to build a ‘correct’ driver circuit ( from the looks of it, a lot of the s-video mods and drivers out there on the net aren’t exactly correctly setup). The VCE is directly capable of driving both composite and svideo signals, it’s just that you use an amp to buffer the chip. In case anything ever happens, the VCE will be protected (which is important, since the VCE isn’t just some off the shelf standard part).

The circuit will bypass the existing amp and add two separate amps for Luma and Chroma lines. But this brings me to a decision as how to handle IRE 0/7.5 issue. Csync is on the Luma line already, coming out of the VCE. The separate syncs coming out of the VCE aren’t exactly in sync (no pun intended) with Csync, IIRC. The point is, if you wanted to correct the IRE ‘black’ level issue for US NTSC TVs, you’ll have to strip sync from the Luma line, offset the line by adding a small amount of voltage. It gets a lot more complicated than that, because you need to simulate blanking vs black, which means another timed circuit with a fixed value between the rising edge of hsync and activating/switching to luma output. The more complicated part is vsync. The circuit would have to know when vsync is happening and not out the adjusting ‘black’ level. Pure black and blanking are the same level. See the problem? Most sets probably woundn’t care that the non sync part of vsync line had higher than blanking level voltage. But you never know for sure.

For now, I’m just going to skip over the issue. TG/SG/Duo/PCE fans having been turning up the brightness a bit to reclaim that lost black level colors/video, it would be no different now by leaving this issue alone. (Brightness adjusts were in the Luma line the offset from blanking level is for black level, Constast adjusts the compression/decompression of the Luma range.)

Another thing that I’m not 100% sure on, is driver/receiver divider. Transmission should be 2x voltage. The receiver divides it. Vout=r2/(r1+r2)*Vin. Unless I got my math wrong (the receiver has a fixed load of 75ohms), the only way to get 1/2 voltage after load – is to have both the driver and receiver use matching 75ohm resistor in circuit. And from what I understand, this matches the 75ohm (Z0) impedance of the transmission cable. A match is important to removing reflections back into the signal (which causes a number of artifacts like ghosting or ringing ,etc). I’ve seen DIY circuits out there with 33ohm or 27ohm (etc) drivers (with expecting 75ohm load on the receiver). Are they ignoring the cable impedance match up? Or am I missing something?

Anyway, I have little time each day – so this is progressing slowly. I have one amp built for Luma. May have some time to tap the VCE pins tomorrow or next day, to test out the circuit.

More composite signal analyzing

Posted in Uncategorized on January 4, 2011 by pcedev

This time, I used a 8 step gray scale to test the signal. Looking for max white and pure black.

This interesting. Max white for both the SGX and the white PCE is 0.84v. That’s 0.14v above NTSC US, or IRE 100. There’s also some slight stepping distortion. I.e. all the steps aren’t the same space apart. This happens in pairs. If you divide all 8 levels into groups of 2; 0&1, 2&3, 4&5, 6&7. That’s how they are paired. And by paired, I mean the two steps are closer to each other, than from their neighbors. It’s slight, but it’s enough for me to see it with my eyes on the scope. And I see it on all three systems I tested: SGX, US Duo, white PCE.

Now, for something else that’s interesting. The Super CDROM2 addon. It normalizes the composite signal (from 0v to max, sync isn’t effected). Luma range is now 0.v to 0.76v (down from 0.84v. And it’s scaled, not clipped). Closer to spec to NTSC US, and probably what the Japanese spec is (I don’t have a direct reference, just assumption based on ‘whiter than white’ reports of Asian NTSC DVD players not correcting them the circuit/output on the US equiv models). The Chroma Burst PLL signal on the back porch, is also scaled up. On the white PCE, the amplitude of the CB is kind of small. There’s more amplitude on the SGX straight CVBS out. But on the SuperCDROM2 out, the amplitude is pretty large. I guess some TVs had problems phase locking to the burst signal. That’s the only reason I can think of it. It doesn’t effect saturation at all. It’s just a reference signal to lock to on every scanline.

So, over all brightness will be a little bit darker than the system itself – on the Super CDROM2. Though I don’t have a booster, so I can’t compare it against that (the white PCE). And the white PCE technically doesn’t have composite output ports, so who’s to say that the Booster wouldn’t perform the same normalization as the SCD addon. But the SGX is a different scenario. The SGX has composite output normally. So this is effectively a direct change. I can’t speak for the Core Grafx I or II, since I don’t have those. But it wouldn’t surprise me if they are set to the same levels as the SGX built in CVBS out.

I should bring out the ‘brief case’ CD addon and see if it does anything like the SCD addon is doing.

Back to the stepping of the DAC. From what I’ve tested, ALL the VCE DACs have this stepping distortion. Here’s how it translates:
I scaled the voltage for the pairs that I listed. They are scaled to 1.0v
The difference to its neighbor is a step of ~1.2v. See? Not an even scale.
Translate to into a linear range of 0-255: You get 0,+34,+40,+34,+40,+34,+40,+34. Instead of the linear steps of 36. So to use grayscale to simplify this: 0, 34, 74, 108, 148, 182, 222, 256(255). And, this pretty much matches what I saw when I set my capture card to full luma (you have to force this on for NTSC-J, else you get an incorrect clipped and scaled Luma range).

So, to recap. This isn’t just for Composite output. RGB DAC output has the same stepping pattern too. But here’s the kicker. The Y/Cr/Cb DACs aren’t 3bit like RGB (even though they output the same stepping). They’re higher res. 5bit DACs. So the next test would be to cut Chroma lines and test all 32 Luma levels. See if the stepping pattern shows something different for values finer than 8 levels.

VCE Y channel update

Posted in Uncategorized on January 3, 2011 by pcedev

I got my turborom board working along with my usb rom programmer. Only 128k at the moment, but it’s better than nothing. Once I get a par port option setup again, I can start using the tototek card for larger rom tests.

Anyway, I did what I said previously. I cut the R-Y and B-Y traces from the composite build circuit. So nothing but Y is being output. Which is different than just turning off the CB in bit 7 of the VCE. That would give you a bias to the Luma chart because R-Y and B-Y are still there.

So, this is a pure look at the Luma stepping from the VCE rgb to yuv rom table inside the chip. There are a total of 32 luma levels. Can you spot them all? 😀

Some oscilloscope tests…

Posted in Uncategorized on January 2, 2011 by pcedev

I was just testing some stuff. But thanks to charles to requesting a special trigger setup, to look at the non displayed scanlines. Using Ccovell’s screen test app (it was on the flash card already, and I have no parallel port to reflash the card with anymore), I set the scope trigger to A20 address line. Chris reads the upper address range (for the VDC status reg, part of VIRQ handling code). So the scope happens to trigger on VIRQ (there’s no HIRQ happening, so it’s nice and clean).

I was able to cleanly look at the blanking scanlines in vblank. Using Ccovell’s test app, I moved the screen around (vertically). Sure enough, you can put the display to show pixels in the blanking lines. Now, this won’t hurt anything. The three vsync (inverted blank scanline) scanlines are never outputted with pixel data – the VCE cuts that off. But before and after are.

This means that there’s a possibility of manually embedding stuff in the blanking. You know, stuff like Close Captioning… ah-hahahahahah. That’s hilarious. Imagine subtitling a Japanese game or just.. anything. That really makes me laugh 😀