Archive for May, 2010

PCE HuC6260 s-video output

Posted in Uncategorized on May 30, 2010 by pcedev

See link here:

I tested the 4 pins that make up composite video, today. It definitely looks like it’s possible to make s-video without a special encoder chip. I’m going to attempt to build such a cable .o> (<-little army man, saluting)

Two new chiptune conversions

Posted in Uncategorized on May 30, 2010 by pcedev


Enjoy 😀

Some ripped samples and examples

Posted in Audio on May 29, 2010 by pcedev

Music engine is delayed (’cause I’m a lazy bastard). But I whipped up some pce instruments for a XM file mean time. See here:

In the description is a link to the XM file. Feel free to use/rip whatever from that file. I did some sound examples too.

Remember, if you going to make PCE music in milkytracker – use the following rules:
– Set “Frequency Table” under “config” to “Amiga Frequencies”
– Set “Resampling” to “Amgia 1200” (*not* the LED one, please!)
– Set long samples to relative C-4 and use A-3, or set to relative A-3 and use C-4. The first is best as it’s easy to see long samples from other entries in the patterns.
– Set *ALL* short waveforms “repeat” to “forward”. You can find this under “Smp. Ed.”
– Long waveforms can be “no looping” or “forward” looping.
– Volume envelopes are fine. But use coarse steps if possible or look at the conversion table I made (somewhere on this blog)
I think that covers everything.

Turbofest ’10

Posted in Uncategorized on May 8, 2010 by pcedev

Here’s a link and here too. I can’t go, but I’m gonna do something a little special for the event (need someone to bring the rom or ISO with them though).

Other news: Been having some annoying problems recently (health related), so I haven’t been doing anything much. Going on the 3rd week and although it’s subsiding, it’s still pissing me off (and worrying me). When the test results get back from the doctors, should put my nerves at ease (I’m betting on that it’s some random weird/fluked bullshit. Always seem to work like that, except the one time in having my appendix removed. But hey, can’t win them all 😛 ).

Some PCE test

Posted in Uncategorized on May 2, 2010 by pcedev

Graphic tests on the real system. This is in relation to h-blur effect. I found some interesting results.

First the premise: divide the screen rate into even/odd frames. On odd frames, shift the odd scanlines left by one pixel, left the even scanline in normal place. On even frames, shift even scanlines by one pixel, leave off scanlines in normal place. An easy way to do this is to use a flip-bit. I use EOR #$01 to the horizontal offset, every other line. This way, only every other scanline is adjusted. The untouched scanline retain their normal offset on screen (not “opposite”, as that would give a 2 pixel offset). This pretty much replicates what the PCE is already doing when you turn the filter mode on, on the VCE. Except, on the VCE – the pixel offset every other scanline is half a pixel or less (for all res modes). The filter on the VCE is *always* running, but when you enable/disable 1 more scanline (filter on/off = 262/263 scanline, or vice versa. I forget which corresponds to which, but it doesn’t matter) it causes the flip-bit internally of the VCE to either “stick” or alternate. I replicated this myself in the following roms. If you have an even VS odd amount of scanlines (I do a compare to terminate), the effect “sticks” and you get a solid frame with every other scanline “stuck” in the offset mode – but no frame alternating.

If you can’t visualize this, don’t worry about it for now (well, until you try to implement this effect : P ).

Here’s some pics of what the effect should look like:
Here and here.

Since this requires “motion”, I had to simulate the effect. Which, for all attentive purposes, does a fine job. Minus the very-very slight flicker on hard edges, it looks like the simulation pic.

Now for the interesting findings. The image and rom demo, originally ran in 7.159mhz pixel mode. This is the mid res mode. On my SDTV NTSC set, the effect comes off near perfect. But a funny thing happened on my capture card. I kept getting these weird artifacts: horizontal lines. Almost like an emulator would do, if you enable 25% scanlines. But this was doing it on a single row of pixels, not in between. Didn’t matter if it was 720×480 or 360×240. My original demo had the VCE res set to #$05. The edges of the screen retained a comb look. Like the alternating system was “stuck”. But this shouldn’t be, because I would be getting vertical strips, not these funky slightly dimmed lines, every other line.

I though my code was acting differently on the real pce, so I increase the shift amount by 7 pixels ( EOR #$07). Nope… the code was working fine. So I figured, I’m gonna bypass the capture card and go directly to the SDTV set and HDTV set (CRT, rear projection 53″). That gave some interesting results. I saw almost the same thing on the HDTV set. But a little lighter. Like it was 12% intensity every other scanline. On the SDTV, it image looked as it was supposed to.

Now, this definitely stumped me for a bit. So I decided to disable the alternating scanline code and show the screen normally (completely disable the H offset in the hsync int routine). At this point, I think I also changed the VCE filter setting of 05 to 01. Same res, different filter state. Magically, the checkerboard pattern looked solid. I mean, completely solid. On the SDTV set, so I plugged it into the HD set. Sure enough, it looked beautifully solid. It dawned on me what was happening. The 7.159mhz res is higher than what a composite signal can put out for luma, let alone chroma subcarrier. Well, higher than what a TV would read in (they use cut off filters to separate the subcarrier and luma, and also to clean the luma). So I made a quick change to the demo and used a res of $00 on the VCE. Sure enough, this fixed the problem on the HD set. The SDTV set didn’t mind any of the resolutions.

But there was a small difference. My HD set has a faster fall off rate for the phosphor in the screen. It’s needed for faster refresh rates than my SDTV can deliver. So you see the flicker more on the HD set. But on the SDTV, it’s near non existent. Believe it or not, but sharpness has no effect on the flicker (or lack there of) on the SDTV set.

Both the capture card (it’s a BT878 chipset, not those MPEG ones) and the HD set, sample the resolution and apply filters to the image. The SDTV does neither (maybe comb filtering to eliminate dot crawl as it’s a fairly new/late generation SDTV I bought new about 5 years ago. Standard stuff for SDTV sets of late gen).

On the emulators for my PC display (LCD with 2ms), it looks pretty much like the SDTV set. Except when you see the emulator drop a frame – ugh. It’s a little more flickery on my other CRT PC display (but again, faster refresh rate).

So, the artifacts came from the mid resolution dot clock, in relation to the composite signal bandwidth, and how the devices reacted or handled this. Low res mode, didn’t seen to make a difference. I haven’t tested high res mode, but I’m guess it would be similar to low res mode since it’s exactly twice the dot clock bandwidth of low res. So caution must be taken care for using mid res mode. And not so much, if at all, for low res mode.

Ok, some specs about the images. The images were prepped using Orions checker board dither app. What this does, is essentially reduce the image down to 512 color image with half step dither for colors in between. Every other line is out of phase by 1 pixel, so you get a checker board dither pattern (not to be confused with the typical “pattern” dither of most apps). I then ran the image through Pro Motion 6 and set the subpalette to 15 colors (ignoring transparent color) for 8×8 tiles and 16 subpalettes. Now, Pro Motion 6 (the demo version I have) has a bug that builds out the subpalettes incorrectly. But it does the color reduction just fine (it’s incorrect for 15 color mode + common color, so I use just 15 color mode). I snap shot the image with XP screen capture, copy that into photoshop, select and cut, save as an 8bit BMP (which is where I get my color count from), then run the image through my special app. What normally takes all 16 subpalettes for pro motion, usually takes 2-4 less on my apps sorting algorithm. My app just loves the 15 color tiles (has no problem sorting them). So, convert, export, import into the asm app, and build the roms: zip.

My app doesn’t do any lossy color reduction. I tend to use it for accurately sorting a block of tiles, losslessly, into a build sheet. It has a few options and it does “look ahead” building to determine the best path when compressing/collapsing subpalettes into one another. But, there are often multiple results of the same value for the look ahead builds, it doesn’t try to take this a step further and find *every* possible route. That would be insanely time consuming. It also doesn’t sort the subpalettes by popularity to tile ratio, not until the end. Surprising results though for all things considering. Some snap shots of huvideo stored as BMPs, ran through my app – comes very close to putting the image back together. Very, very close. And, on pro motion pics, it actually compresses them smaller in subpalette size. One of Orion’s converted pics, which was done with Nintendo DS development kit software, actually made it 1:1 or even 1 subpalette less. Oddly enough, the images DamageX put out in his app – don’t convert that well, even though they are pretty simple in design/sortment of subpalettes.

Anyway, the checker board dither works perfect for Hblur technique, and works on the principle that the eye can’t see the small changes at fast rates – compared to large alternating sections. Funny enough, Capcom employed this technique in SF Zero, IIRC. Since the CPS hardware didn’t have transparency hardware, they used checker board dithered solid colors that they alternated per frame. Anything underneath appeared half as bright. Compared to solid black blinking shadows and what not used by many consoles, this difference of alternating was small enough to trick the eye (I’m sure the CPS nice res helps too : P )

So why even do hblur when you can just dither? Well, on a emulation or real system RGB out or even svideo modded console – that dither isn’t going to look so hot. Hblur, if used correctly, can work for all setups. Although for emulation, there’s the issue of the emulator dropping frames every so often. Most do this in windowed mode for me. Full screen usually fixes this on most emulators. Mednafen has a temporal blur system in the config file that could help alleviate that, but I’ve yet to mess with it.

Here’s some pics from my SDTV set: here, here, here, and here. First two pics are of hblur mode and 7.159mhz dot clock. Second two pics are hblur and 5.37mhz dot clock. That last two pics look just like that on my TV (well, clearer). I mean, they look just as solid as those pics. I’m curious how they would appear on a PAL SDTV set (not HD or LCD, or such).

On another side note: I remember some composite and broadcast video doing something similar to increase the color bandwidth (which is really poor for NTSC RF). Though, on a finer 480 vertical resolution. The method was a little bit different, but the premise is the same. Since you have finer control over luma bandwidth, you added a checker board effect overlaid into a specific (pixel) area – and alternate between two patterns. And since movies have a lower frame rate than 30fps, it makes it easier to pull off (24fps with 2:3 field duplicate ratio applied. Not to be confused with 3:2 pulldown, which is the reverse process for progressive displays to remove the redundant fields – and thus any “combing” from the original process).