Archive for December, 2010

An Epiphany

Posted in Uncategorized on December 31, 2010 by pcedev

I woke up this morning, with an immediate realization of truth. I was wrong about the chroma dot pattern. Not that it doesn’t exist, because it’s there. And not that it’s not unique in style to the PCE, because it is (compared to the snes and Genesis). But that I believed there was a mechanism internal to the VCE that help produce this pattern on the Luma channel, when the Chroma channel needed. As if, to emphasize this pattern.

I guess my subconscious noticed that there was no mechanism mentioned in the schematic. That, and some other things of late (namely designing my own composite output system on an engineering level, on an FPGA).

I originally tested the chroma dot pattern to see if it was just chroma bleeding into luma frequency, by removing one of the subcarrier modulated signals. Looking at the signal in pure B&W (green in on componet), I originally didn’t see a difference.

So immediately waking up (and I mean immediately), I took the lid off my Duo and cut the both traces to the paired chroma sub channels. Then hooked it to my captured card. B&W white signal like I had expect. Ok, so far so good. Then I plugged composite into the old tek scope, to make sure it was the both subcarrier lines I cut and not the Color Burst line. The scope verified that the CB was indeed on the back porch.

So, the pure XOR dot pattern going down the screen makes sense, in the fact that the pixels (of the chroma dot pattern) look exactly as on then off. Not like the SNES or NES. Duh – because the CB is alternated exactly 180 degrees out of phase every other scanline.

Phase alternating was meant to directly tell comb filters the difference between two scanlines (three in fact, that’s why the SNES and NES use a three scanline phase shift group). The comb filters know how to separate chroma frequency bleed into the Luma frequency, because of the phase shifts. And because the Genesis external encoders do not do this, there’s no shift on the chroma dot pattern and it’s pretty much impossible to pull the additional detail from the Luma channel, after narrow frequecy filtering subcarrier frequency. It makes perfect sense 😀

Why is that really important? Because I had originally thought making an s-video mod for the PCE was useless – because I had thought part of the chroma dot pattern was partially or fully driven on the Luma channel. But it’s NOT, this means you CAN do beautiful s-video out on the PCE without ANY encoder chip… and without looking the real PCE colors (because an external s-video chip doesn’t convert the RGB to YUV as same as the table in the VCE). That’s fantastic news. So much so, that I’m gonna get a second amp for the chroma signal, and make an s-video mod myself 😀

It’s also possible to make component video from this too. But that requires a bit more circuitry. You need to demodulate the amplitude modulation of both chroma channels. I haven’t tested it but, if the VCE pattern schematic is any indication, the rate at which the sine wave frequency is amplitude modulated actually might just be the dot clock of the VCE (the dot clock that the VDC sees/is feed). If it is (which I have a strong feeling it is), than that means you have full chroma resolution for component too. Well, assuming your demodulation circuit is up to snuff. That’s pretty freaking awesome.

VCE YUV rom table dump

Posted in Uncategorized on December 31, 2010 by pcedev

Okay, I think I got this figured out. I compared the patent table of the RGB to YUV matrix rom to that of just YUV clipped to 5bits. There’s rounding in there. Not just rounding, but some weird bias in the first all blue level entries (didn’t seem to follow any logic that I could see). Something I really didn’t expect to see that. That makes it a little problematic for trying to model the YUV conversion process.

You could just set a weight to round all values that aren’t in the patent table, to 5bit. But there’s another way.

The VCE doesn’t handle complete quadrature modulation inside the chip. The last step is done externally, right before the amp. Since it’s just a simple addition (you just simply tie the lines together. Remember; amplitudes add). But the 90 degree phase shift and the amplitude modulation of subcarrier sinewave is (handled internal, that is). So, you actually have all three independent Y,U,V outputs. Even the color burst reference is on its own output (but that’s irrelevant for this).

What that means is; is that I can cut the trace of either U or V component of the subcarrier and easily just look at the amplitude modulation. It’s 5bit, so I should be able to clearly see the stepping on my oscilloscope if I stretch it vertically. I’ve already removed U and V independently on my Duo unit before (it’s pretty cool looking :D). So, I just need to do this for Y, then U, then V.

So, I can reliably dump the whole table by hand. That only downside is that I’d be writing 1536 entries down on paper. But yeah, beggers can’t be choosers (that would be me 😉 ). I’ll take this over $600+ decap and micro scope pics.

Edit: Oh yeah, I wanted to mention that just looking at the first few and last few entries in the patent matrix rom table – the Luma is full range. It’s not compressed to 16 – 225. It’s full 0 to 255 (in 5bit steps). That’s important to know. Though, I just figured that out a few hours before hand when messing with the capture card. But it’s nice have a direct second source confirmation of this.

Posted in Uncategorized on December 31, 2010 by pcedev

Man, user end capture card chipsets really do suck. Anyway, with more tweaking and the right level (default for CBS, imagine that) and full luma range enabled:

A much much better look at the luma stepping scale that’s unique to the PCE’s VCE (that I’ve seen yet).

Once I figure out the correct values, and I get m fpga dev kit (which should be soon), I’m gonna make a RGB ADC index to a simulation table, to output back out as component and RGB. A real RGB and component converter for the PCE.

Composite to RGB comparison chart

Posted in Uncategorized on December 30, 2010 by pcedev

Bottom taken from emulation, top from my capture card. Constrast and saturation set to default levels. Brightness set to normal level (little bit above default). But really, it doesn’t matter. You can clearly weird Luma stepping in the color transitions. If you turn the contrast up, or brightness down, or even turn the saturation down so the screen is black and white – it has no effect on the relationship of each color to its neighbor. The odd stepping it already there.

I suspect it’s either an error in the original table (and this is from an SGX, so it has a second revision VCE) or it’s because 5bits per channel isn’t enough for the color conversion to carry over correctly and you get stepping errors. Either or, it’s pretty significant. Like I stated before, SO2 simply looks great with this color mapping. It makes me want to go back through the PCE library of games where I thought the color choices were poor and re-check them.

I hate to sound like a purist, but if I were to have to choose between which color set is appropriate and which is incorrect – I’m definitely leaning towards the VCE table converted set. That means GFX tools, general graphics, etc with that in mind.

PCE color space

Posted in Uncategorized on December 29, 2010 by pcedev

Anyone who’s played emulation via the real system, knows there’s a difference in colors/brightness. Usually, the first thing that comes to mind is how much more vibrant the colors are in RGB. It’s a no brainer.

I’ve was recently playing the Startling Odyssey 2 translation patch (which is a lot of fun, but that’s for another post/entry). The colors on the emulator look pretty bad. I always thought this. I figured the artist just chose some crappy colors to use. I mean, they attempt to emulate that SNES RPG color look but on a low RGB step value system. It’s hard to describe, but anyway. I decided, because I’ve been doing tests on my real system lately, to play the game on the real hardware. Holy crap. What a difference. The color choice becomes much more workable and appropriate. The graphics are actually good. Now, I’m not talking filter or scanlines. This is on my HD CRT. It has neither. The image of composite, on my HD set, has pixels as perfectly square as any emulation shot without filters (raw shot). I’m talking about the COLOR.

A good example, but definitely not limited to, is the open land back drop for the fight scenes. There’s a color of blue that’s barely even noticeable. I’m REALLY unnoticeable. On RGB of emulation. That’s mednafen, doing max RGB translation steps (of 36). Yet, on the TV – this is a clear difference between that and the next color up… which is for the upper sky color. It’s more than just about a picture being lighter or darker. It’s about the luma of each color in relation to the other colors, that’s totally different between RGB and the PCE’s conversion map rom (there’s a rom in the VCE that remaps all the RGB values into YUV color space). The patent of the VCE says the three Y,R-Y,B-Y DACs are 5bit. Separate from the 3bit RGB DACs. The 9bit RGB values of CRAM are used as a direct index into this table of 15bit color (5bit*3). Unfortunately, the patent only shows a few entries of this table ( a few first and a few last). If there is indeed a luma correction or bias, you’ll need the whole table to see it. It might be that there is infact such a bias built into the table, *or* could be from the mere fact 5bits is fairly low precision to represent the RGB to YUV conversion, and this you have some rounding (it’s a table after all, who knows what they tweaked or such). So whatever it is, I think some PCE artists directly had this in mind when choosing the color palette for game graphics.

Not only that, all the colors are softer on the real console. Yeah, they might be a little less vibrant, but the graphics are complete wrong in RGB.

The choice was easy. I’ve been working on a BRAM dump tool from my Duo/SGXCD, that dumps all 2k through the sound channels (you record it on the PC, and run the wave file through a decoder, to get the file out). In light of this, I added an option to update BRAM with any file on my custom util/CD. So I took the BRAM file from mednafen, decompressed it, put it on the CD, then updated the real system with my current save point. Now I can enjoy the games graphics with the colors in the way it was meant to be viewed. RGB was never officially supported on the PCE or TG. Nor were the RGB lines even amp’d for normal usage. On top of that RGB, via the back plane pins, was removed for the flag ship Duo series systems… which are arguably the main consoles when you talk PC-Engine (because of CD becoming the dominant format of the system).

Sure, that fixes that problem. But what if I want to play games using emulation. After all, I like to preserve my consoles. I play the real systems from time to time, but I like to keep the wear and tear down to little as possible. Mednafen provides a solution. The pass few releases of mednafen support ‘colormap’. Actually, two colormaps. One for normal, and one for B&W output of the PCE (color burst off, see Chris Covell’s B&W demos and some rare instances of PCE games using it).

With that in mind, I’m off to create a RGB make of the PCE’s real colors. Or as close to it as I can do. I’ll post some colormaps when I feel I have a good match. You can also use tools like Photoshop and such, that have the ability to adjust colors in HSL, to brighten or darken this map. I’d rather see a feature in mednafen to handle this, though 😉

Also, on a side note: There’s a difference between NTSC US and NTSC JP saturation levels. Assuming the VCE’s in both US and JP systems are identical (the amp circuit), your US Duo is showing less saturation that it should – if you’re using it on a US TV. JP composite on a US TV/setup will show less saturation. Buy how much, I’m not sure yet. But it means your colors should be a little bit both brighter and vibrant than what you’re seeing, if you’re using a US NTSC set or capture device (you can usually set this to JP NTSC though). I have a US Duo and a JP SGX and PCE. When I have some time, I’ll see if there’s a difference between them.

Unreal Superhero 3 again

Posted in Audio on December 29, 2010 by pcedev

Hmm. I guess I forget to post the link:

HES file link to the download is in the description.

Youtube limit

Posted in Uncategorized on December 11, 2010 by pcedev

Yay! I can upload up to 4 hour videos on youtube now 😀

Object map

Posted in Uncategorized on December 8, 2010 by pcedev

I’ve been working out the logic for an object reference map. This type of map is just like a tile reference map (tilemap) except it’s sprite based. I originally needed something for Lunar for overlapping parts of the town/houses/dungeons/etc.

What’s the purpose of an object map? Pretty much the same purpose of the tilemap (in this case). I needed flexibility, so I decided to see what could be applied in the most extreme cases. Say, something like a whole separate movable map layer. Something solid enough in operation to be a foreground map. Now, I could have made something up from scratch to fit the need/hardware. But that’s less challenging. Thinking through some games that I’ve always wanted to demo with this sort of technique… Sonic for the Genesis comes to mind.

Looking at Chemical zone and applying it against a pseudo tilemap. 16×16 was too small to satisfy most areas, because of the limited (in this case) 64 entries of the SAT. 16×32 and 32×16 still presented limitations. 32×32 on the other hand fit perfectly. To keep transition from screen edges, one would need a smaller window than the sprite bandwidth limit. 240 or 232 pixels wide instead of the normal 256. 240 is doable, seeing as how the VDC drops cells automatically when the sprite limit is met on a scanline. That would allow free scrolling left and right with seemless transition (no wholes or such – a solid ‘edge’ across the screen is doable). Limit the screen height to ~192 pixels and use a ‘window’ either top or bottom of the screen for status stuff (pretty standard). And you have yourself a nice clipped window setup for sprite-made foreground layer.

Now, 32×32 is fairly large. And it’s also pretty wasteful in areas. I had originally though maybe a four layer map (one 32×32, one 16×16, one 16×32, one 32×16). As long as you didn’t purposely overlap sprite entries, you solve the problem of small sections of the 32×32 that only needs small ’tiles’. The idea works, but its simplicity ends up bloating logic and size (or resource for decompressing).

I took another approach at representing theses 32×32 segment. Meta-cells. The 32×32 entry is just a reference to an object that is build of attributes, instead of direct hardware reference. Another layer before it gets to the hardware layer. This isn’t anything new. This concept has been around for a long time. PCE games often use tilemaps that reference metatiles. Usually in defines of 16×16 sections (four 8×8 real tiles).

The concept is the same. The metacell references an object that may actually be a direct reference to a hardware level element (single 32×32 sprite cell). But it also might reference a group of 16×16 sprite cells. Actually, any number of hardware sprite configurations. And other attributes like sprite flipping, palette attribute, and sprite/sprite and BG/sprite priority settings. The cool thing about the object map, as opposed to just a tilemap, is that each entry isn’t limited to to the grid point it was assigned to. The grid point of the 32×32 sectioned map, is just a reference point. Because sprites are independent objects, you can assign relative offsets to that map point. That’s the power of an object map. The flexibility over a tilemap, but a mapping point system to more easily parse and handle objects on a larger field without having to parse and apply coords/logic to every single object, and then more so once it reaches the ‘view window’.

This makes it easier to apply objects for pixel accurate priority between sprites and BG layers (which many RPGs do on the PCE). There are sooo many parameters and features you can directly apply to objects too. Like the previous mentioned masking/priority system, and have it go ‘live’ when an active sprite is near the required zone (instead of having there all the time. Many PCE games do this too).

An Object map with 32×32 segment size makes it possible to mimic a separate foreground/background layer, without eating up the Sprite Attribute Table entry list (or to keep it minimal as possible). It also makes it possible to have more object oriented behavior when required. With the attempt to keep logic/cpu resource at a realistic/less complex level. The real trick comes when you have to write the SAT sorting routine. A fully loaded dynamic SAT list isn’t particularly easy to write the coder for. But not beyond the skill of any coder (just a pain depending on the requires of the game engine VS how much cpu resource you throw at it).