Another sync thread: Ikegami HTM-2050R and modded PCE

[SamIAm]

Very recently, I picked up an Ikegami HTM-2050R2, and it's a fantastic piece of equipment. Its RGB works with Mega Drive, Saturn, Dreamcast, PS2*, MSX, Neo Geo CMVS and SNES quite well. However, it doesn't work with my RGB modded PC Engine, and I'd like your help to fix this.

I had the mod done a couple of years ago, and it uses composite video for sync. This works fine on my consumer CRT and BVM, but on the Ikegami, there is warping in the top quarter of the image. It's very much like what you can see in this post, except that everything below the top quarter is completely fine. I tried putting an LM1881 in the sync line, but it hasn't done anything; the warping is unchanged. Although I have not put a 470 ohm resistor on the output like in viletim's post in this thread, I have a feeling it won't matter, and here's why: This HTM-2050R2 has an NTSC composite video input, and when I give it unmodded PC Engine composite video, it does the same thing as the RGB. I think there is a profound disagreement between the PCE and this display. It's frustrating, because the lower 3/4 really is perfect. Also, if I remove sync from RGB, the picture slowly rolls, and I can see that the warping is gone, so it's definitely the sync.

Do you have any suggestions?

It's worth mentioning that I have a Supergrafx and a Duo, both modded in the same way and both displaying the same warping.

One fellow told me that he had a similar problem with his modded PCE on an XRGB3, and he fixed it by enabling a low-pass filter that is built into the unit. Interestingly, I see that the datasheet on the LM1881 actually recommends making a low-pass filter for the source video with a 510pf capacitor to ground and a 620 ohm resistor in series. That's the next thing I'm going to try.

I also see on the datasheet that the 680k resistor on pin 6 of the LM1881 can be changed to affect the vertical sync pulses, which seem like they could be the culprit. I might try a 500k resistor + 500k pot so I can test a wide range of values.

That's about all I've got in terms of ideas, though. I suppose there is always re-doing the mod to tap and amplify composite sync directly from the console itself, but I don't know why this would work. At best, it seems like it could be useful for getting pure sync to manipulate in other ways...whatever ways those might be.

Anyway, if you have any ideas, please let me know. Thanks!


*PS2 is sync on composite video, right?

[Fudoh]

One fellow told me that he had a similar problem with his modded PCE on an XRGB3, and he fixed it by enabling a low-pass filter that is built into the unit.

I don't think so. He most likely fixed it by adjusting the AFC setting on his XRGB-3. The same setting is available on higher end BVMs (D series) and fixes the same problem there.

Can't help you with modding of the RGB mod, but I would try an Extron sync interface, so see if ADSP or any of the settings on the machine does change anything. These are so cheap that it's certainly worth a try.

[SamIAm]

I would try an Extron sync interface, so see if ADSP or any of the settings on the machine does change anything. These are so cheap that it's certainly worth a try.

Not in Japan, they're not.

I've searched, but have yet to find a promising substitute that is readily available for anything like a reasonable price.

[Fudoh]

Over here neither, but I can still get units for $30-40 SHIPPED from the USA, so you should be able to do the same.

[SamIAm]

If it comes to that, I might take the plunge, but for now, I'm enjoying buying parts for pennies and learning how to put them together. Especially when it works.

I've got a very nice parts shop right next to where I work, too. At lunchtime today, I went and bought all the resistors and capacitors I need to make a filter and/or adjust pin 6. They even had the LM1881.

[Fudoh]

of course. If you solve this in any way, let us know. It's been an incompatibility that has been hunting me for a decade.

[SamIAm]

Hmm.

The filter didn't work. The closest I could get was a 470pf capacitor, but I used a 1k pot as a resistor. There was essentially no change other than a slight shift in the horizontal position of the picture (expected).

I also tried replacing the 680k resistor on pin 6 of the LM1881 with a combination 510k resistor and 200k pot. Not only did it not work, but I was surprised to see that it produced no visible change in the picture at all.

Tomorrow, I'll pick up a 1m pot and try the full range. Reading the datasheet, I don't think it should be possible to get a picture with less than 400k or more than 900k ohms resistance.

[gojira54]

Why not try taking the sync directly from either the ext bus or 6260 instead of using composite video as sync?

[SamIAm]

I was hoping to do this with composite video, since I would otherwise have to use signals directly from the 6260 and not the EXT bus to pull off everything I want, and that's a pain. Unfortunately, it looks like going to the 6260 would be the best chance I have of making this work.

This page describes a guy tapping H-Sync and V-Sync on their own from the 6260, then putting them through a 74HC123 to increase the pulse widths to 4.7uS for H and 190uS for V. This worked, however he's using a JVC monitor with separate inputs for H and V, and apparently mixing them causes a slight skewing problem.

In this follow up, he says that he had mistakenly assumed that the H-sync pulses from the PCE were on the short side, but actually they were long according to his logic analyzer testing. He shows how the pulses are not created from the system's dot clock, and guesses that they are probably based on 36 ticks of the main clock. Finally, he gives a schematic using TC74HC123s (gotta be with the TC) that he says produces H and V sync that his monitor likes.



I can translate those posts in more detail later. Right now, it's bed time.

[viletim]

Quick comparison of the NES and PCE vertical part of the composite signal.

I notice two errors in the PC Engine's signal.

1) Vsync starts too late by about 4us.


-----

2) There is a serration h-sync pulse missing entirely at the end of the vertical pulse. (Keep in mind that only falling edges are counted.)

[SamIAm]

Very interesting, viletim. Thank you for looking into that.

I'd love to do some more experimenting and figure this out. Maybe I should finally invest in an oscilloscope?

I misunderstood what he was saying about the EL1883 before, but I wonder if it could be used with that circuit anyway? It does separate H-sync and V-sync from composite video.

[SamIAm]

Here's a real translation.

--------------
1st page
--------------

When displaying a PCE on a DT-V1910C through RGB, the upper area skews. To deal with this, I didn't use C-sync or signals split from C-sync, but tried connecting the H-sync and V-sync that the console puts out directly.

I learned through a foreign website that the PCE's H-sync and V-sync are output through pins B-11 and A-10 on the expansion connector, but in the case of my Duo-R, there is no connector, and I needed to take the signals from somewhere else.

Tracing with my tester (multimeter?), I followed these lines [on my normal PCE] to pin 71 and 72 of the HuC6260, and found that there are test lands between the HuC6260 and the HuC6270. These lands are where I took the signals. In the image, the red circle shows H-sync, and the yellow circle shows V-sync.
(Note: this may be different depending on your version of the board. If you're attempting this, please verify everything with a tester just to be safe)




However, both the horizontal and vertical signals as-is on the DT-V1910C are unstable. So, I used 74HC123s to change the pulse width of the H-sync to 4.7uS and the V-sync to 190uS. On a previous occasion, the 4uS width of an AFC HD signal I got with an NJM2257D C-sync splitting circuit gave an unstable picture. By widening the pulses, I fixed the problem; short pulses seem to be a bad thing.

Mixing the resultant signals does cause some skewing like you see in the picture below.


[Translator's note: this is still vastly improved over what I'm seeing on my Ikegami.]


But, with them separated, the skewing no longer happens.




It would seem that I have solved the problem, but bear in mind that the signals I'm taking are supposed to be for internal use, and for this reason the image is shifted more to the right than it would be with C-sync. I think that this is because the H-sync timing is early. Adding a delay through the dot clock should fix it, so I plan on trying a shift resistor as soon as I can get one.

However, besides requiring modding, this approach only works on hardware that has separate sync signals. I don't know what I could do about the Neo Geo...

--------------------------------------------------


--------------
2nd page:
--------------

When using the PCE's separate sync signals as-is, the screen shifts to the right. I decided to have a look at the H-sync timing with my logic analyzer. I used Zeroplus's lowest-rung model, the LAP-C(16032). Measurements are from a white PC Engine with a Tennokoe 2.

Because there might be a difference caused by the dot clock, I looked at two games: Dragon Spirit and R-Type. The red line is c-sync split from composite video (I wasn't able to measure internal c-sync because of differences in logic level). The orange line is the dot clock, and the yellow line is the Hu6260's H-sync.

First is Dragon Spirit:



Next is R-Type:



Look at that - it's not synced up with the dot clock! It seems that the C-sync pulses in both games have a delay equivalent to 36 ticks of the main 21.48MHz clock. While it is possible that my sync splitting circuit is adding some extra, there is no mistaking that the added delay is huge. Also, last time, I was saying that the H-sync pulse must be short, but in reality, it's long.

I could try tapping the main clock [to fix the image-shift problem], but making a circuit to add a delay of 36 ticks is a hassle. I decided that basically, I just needed to make the delay the appropriate length, and that this should be possible with 74HC123s. However, these timings being as short as they are, there is a chance that things won't go according to plan and will require adjustments.

I'll put a circuit diagram below. Due to the 74HC123's bender (?) the pulse width timing is off, so please use a TC74HC123. If you use this circuit, don't blame me for anything bad that happens.

*6/26 Note: If you connect this output to the DT-V1910C's H-sync and V-sync lines, the specified current in the ICs will not be enough for 75 ohm impedance. Please do not connect them directly.

*7/1 Note: I updated this to work on the DT-V1910C's sync inputs.



I connected everything like this:
HSn is pin 71 of the HuC6260
VSn is pin 72 of the HuC6260
5V and GND are connected to the same lines as the HuC6260.

I was able to get the sync signals from the test lands mentioned in the last post.

Using this circuit, you will get a picture in roughly the same position as you would if you used an EL1883 to separate H-sync and V-sync, but it will be a little more to the left compared to a SELECTY21. I get the feeling I added too much delay, so it might be a good idea to reduce the values of C1 and C2.

------------------------------------
------------------------------------


I made a couple of goofs in my earlier summaries, but went back and corrected them.

What he doesn't clarify is what happens when you use HV sync from an EL1883, possibly putting them through the same 74HC123 ICs to regulate their pulse widths. If that works, it would be a non-invasive solution for anyone who is using composite video in their RGB mod.

EL1883s are not common here, but I think I can get one. Time for some shopping!

[viletim]

SamIAm,

I didn't have time to explain the details in my last post.

The problem is basically the PC Engine has buggered up sync timing in the vertical interval. At the start of every frame there are four mis-timed h-sync pulses, followed by a missing h-sync pulse. The symptom is different depending on the design of the TV/Monitor. If TV's horizontal oscillator is slow to react to the differently timed pulses there will not be any symptom at all.

Anyway, the EL1883, or any other sync separator IC will not solve this problem. If you want to fix the composite sync you need to have a local oscillator, lock it on to the sync signal, and make sure it ignores the wrong pulses during vertical sync (counting lines, etc). This is quite complicated to do.

It would be easier to go with the method that the blog post describes. Take the Horizontal and Vertical sync signals (which I presume are fine) and use RC one-shot timers to reshape the pulses into what the TV standard requires. Then you can combine the H/V into a single composite sync with an exclusive or gate.

[SamIAm]

Ah, so it's not pulse lengths that are the problem, but missing and mistimed pulses? I suppose that would explain why only the top part of the image is affected.

Well, shoot, now I need to think about how much I want to see PCE games on this Ikegami.

Anyway, thanks a lot for your input. I'm actually in contact with the Japanese guy who did my mods for me, and he's very interested in all of this. He's got an Ikegami monitor himself.

[SamIAm]

Gah! I was so enamored with the idea of altering the pulse width as a solution that I made a mistake in the translation. 36 ticks isn't the length of any pulse, it's the length of the delay between the start of the 6260 H-sync signal and the start of the corresponding pulse in composite video. I edited the post appropriately.

That's maybe the most important thing, too. I can definitely believe that whatever is causing that much of a delay internally is also causing the problem with the V-sync timing and throwing off the first few H-sync pulses.

In other words, the reason why there is a flaw in the PCE's image on certain pro monitors and other equipment like upscan converters is that these expect very regular sync signals and often don't have much in the way of automatic frequency control, also known as AFC. Internally, the PCE does generate regular sync signals at the HuC6260 (we hope), but they get delayed at the stage where they are encoded to composite video, and something in this delay process screws up the V-sync in particular. This in turn leads to the first few H-sync pulses being in the wrong place, or even missing.

...Right?

[viletim]

In other words, the reason why there is a flaw in the PCE's image on certain pro monitors and other equipment like upscan converters is that these expect very regular sync signals and often don't have much in the way of automatic frequency control, also known as AFC. Internally, the PCE does generate regular sync signals at the HuC6260 (we hope), but they get delayed at the stage where they are encoded to composite video, and something in this delay process screws up the V-sync in particular. This in turn leads to the first few H-sync pulses being in the wrong place, or even missing.

...Right?

Kind of... This is problem with the horizontal pulses and the symptom is also only affecting the horizontal synchronisation of the picture is it not? It just so happens that these mis-timed h-sync pulses are in the vertical interval. If they happened to be were in the middle of the frame, the symptom would be the same except the wobble at the top of the screen would be a wobble in the middle of the screen. I can't see anything wrong with the vertical part of the compose sync which would cause a problem with the monitor's vertical sync circuits.

There is multiple pieces of info encoded in a composite sync signal, but the horizontal oscillator (in the TV/monitor) only really cares about the falling edges (transition from logic high to logic low). There must be one for every line no matter what. Check the four captures of the NES signal and compare them to the PCE captures and you should understand the problem immediately. The visible cursors are spaced at 63.6us in every capture.

Regarding the solution - As I said before there are two ways to go about it. The first option is to make a circuit that takes the defective composite sync and spits out good composite sync. The second is to bypass the problem and use the horizontal and vertical sync signals from the video bus, which I suppose were intended for synchronising an external display processor hardware expansion and not a monitor. The timing info is the same, you just need to make the pulses start and end at the time the monitor expects them to. Whatever you do, you'll want to get an oscilloscope before proceeding further.

[SamIAm]

I don't have much time at the moment, but first, let me just say again that I really appreciate everything you've done to help me and everyone else understand so many of these technical things.

Second, real quick, what's the name of the oscilloscope you're using? Do you have any budget recommendations?

[SamIAm]

Kind of... This is problem with the horizontal pulses and the symptom is also only affecting the horizontal synchronisation of the picture is it not? It just so happens that these mis-timed h-sync pulses are in the vertical interval. If they happened to be were in the middle of the frame, the symptom would be the same except the wobble at the top of the screen would be a wobble in the middle of the screen. I can't see anything wrong with the vertical part of the compose sync which would cause a problem with the monitor's vertical sync circuits.

There is multiple pieces of info encoded in a composite sync signal, but the horizontal oscillator (in the TV/monitor) only really cares about the falling edges (transition from logic high to logic low). There must be one for every line no matter what. Check the four captures of the NES signal and compare them to the PCE captures and you should understand the problem immediately. The visible cursors are spaced at 63.6us in every capture.

I think I'm starting to understand. I thought that the serration pulses during the vertical blank period were part of the V-sync signal, but they actually originate from H-sync, right? V-sync itself is just one long valley during vblank, right?

If I'm reading your pics correctly, the situation for the PCE looks like this:
1. V-sync starts 4uS late.
2. H-sync pulses during the V-sync period are also delayed relative to the H-sync pulses before the V-sync period.
3. V-sync finishes when it was originally supposed to rather than also being 4uS late.
4. One H-sync pulse that should have happened during the V-sync period winds up being cut out, but the delay in H-sync pulses also disappears.

...and we are hoping that none of this happens in the HV signals on the HuC6260, right?

Regarding the solution - As I said before there are two ways to go about it. The first option is to make a circuit that takes the defective composite sync and spits out good composite sync. The second is to bypass the problem and use the horizontal and vertical sync signals from the video bus, which I suppose were intended for synchronising an external display processor hardware expansion and not a monitor. The timing info is the same, you just need to make the pulses start and end at the time the monitor expects them to. Whatever you do, you'll want to get an oscilloscope before proceeding further.

I have a Supergrafx with a Super CD system attached, but I could probably remove it to do some testing, and if I wanted to do a permanent mod, it should be easy to tap the EXT port pins internally. As for my Duo, I'd be a lot more comfortable working on it with a proven mod.

NES sync might not be the best standard for comparison in all cases. I'm not asking you to look into this or anything, but NES composite video is shaky at the top of the screen on this Ikegami.

Also, for both the PCE and the NES, there is no color when using composite video, and the monitor's "no burst" lamp is lit. However, this is not a problem I particularly care to solve.

[viletim]

Kind of... This is problem with the horizontal pulses and the symptom is also only affecting the horizontal synchronisation of the picture is it not? It just so happens that these mis-timed h-sync pulses are in the vertical interval. If they happened to be were in the middle of the frame, the symptom would be the same except the wobble at the top of the screen would be a wobble in the middle of the screen. I can't see anything wrong with the vertical part of the compose sync which would cause a problem with the monitor's vertical sync circuits.

There is multiple pieces of info encoded in a composite sync signal, but the horizontal oscillator (in the TV/monitor) only really cares about the falling edges (transition from logic high to logic low). There must be one for every line no matter what. Check the four captures of the NES signal and compare them to the PCE captures and you should understand the problem immediately. The visible cursors are spaced at 63.6us in every capture.

I think I'm starting to understand. I thought that the serration pulses during the vertical blank period were part of the V-sync signal, but they actually originate from H-sync, right? V-sync itself is just one long valley during vblank, right?

If I'm reading your pics correctly, the situation for the PCE looks like this:
1. V-sync starts 4uS late.
2. H-sync pulses during the V-sync period are also delayed relative to the H-sync pulses before the V-sync period.
3. V-sync finishes when it was originally supposed to rather than also being 4uS late.
4. One H-sync pulse that should have happened during the V-sync period winds up being cut out, but the delay in H-sync pulses also disappears.

...and we are hoping that none of this happens in the HV signals on the HuC6260, right?

I captured the H-Sync, V-Sync, C-Sync, and OSC (21.4772 MHz master clock) signal on my logic analyser.
http://etim.net.au/temp/forum/v_sync_pc ... .jkdat.zip
To view it you need Jki Suite which can be downloaded from here at the bottom of the page.
https://www.seeedstudio.com/LA5016-Logi ... -2219.html

In short, the H/V sync signal timing is fine, just the wrong start/end times for a monitor.

Regarding the solution - As I said before there are two ways to go about it. The first option is to make a circuit that takes the defective composite sync and spits out good composite sync. The second is to bypass the problem and use the horizontal and vertical sync signals from the video bus, which I suppose were intended for synchronising an external display processor hardware expansion and not a monitor. The timing info is the same, you just need to make the pulses start and end at the time the monitor expects them to. Whatever you do, you'll want to get an oscilloscope before proceeding further.

I have a Supergrafx with a Super CD system attached, but I could probably remove it to do some testing, and if I wanted to do a permanent mod, it should be easy to tap the EXT port pins internally. As for my Duo, I'd be a lot more comfortable working on it with a proven mod.

NES sync might not be the best standard for comparison in all cases. I'm not asking you to look into this or anything, but NES composite video is shaky at the top of the screen on this Ikegami.

Also, for both the PCE and the NES, there is no color when using composite video, and the monitor's "no burst" lamp is lit. However, this is not a problem I particularly care to solve. :mrgreen:

I captured the H-Sync, V-Sync, C-Sync, and OSC (21.4772 MHz master clock) signal on my logic analyser.
http://etim.net.au/temp/forum/v_sync_pc ... .jkdat.zip
To view it you need Jki Suite which can be downloaded from here at the bottom of the page.
https://www.seeedstudio.com/LA5016-Logi ... -2219.html

The dot clock available on the expansion bus is programmable (three speeds) so that cannot be used for timing. That's why I use OSC as the reference. It's not difficult to regenerate the c-sync signal from H-Sync, V-Sync, and OSC, but it requires opening the console to get at OSC. This can be done with programmable logic only.

It's also possible to do it without OSC, but some other timing source is necessary such as some one-shots (74HC123, etc) or a PLL on the h-sync to regenerate OSC.

I know why the NES sync is a bit funny on some monitors. It does a little trick - the first line of every second frame has one less pixel than usual. It helps with make dot crawl better or something. Most TVs handle it ok, but a few (LG) TVs don't like it. That'e the first time I've heard a CRT monitor doesn't like it. It sounds like your monitor wasn't designed for use outside of a television studio.