MiSTer FPGA Forum

I have two composite adapters - mAVster_MD2, and Antonio Villena's composite adapter, and I'd like to post my experiences with both.

Just to be clear, I had startup troubles with both of them - I believe these are not due to design or construction, but rather documentation.
I haven't yet resolved my issue with Antonio Villena's, but it works to a degree where I can comment on some aspects.

Connections
Both have a dedicated 4-pin mini-DIN SVGA output, but they deal with composite output differently:
- mAVster_MD2 puts the composite and sound over a 9-pin mini-DIN Genesis 2-style connector, which will require a specific cable
- Anotonio Villena uses a standard RCA connector, and sound does not pass through his board.

For input from MiSTer:
Note: both adapters require 5V power to be connected to pin 9. This is a jumper on the IO board. They won't work without power.
- Anotonio Villena uses a male VGA connector which can attach directly to the VGA connector on the IO board
- mAVster_MD2 uses a female VGA connector, requiring a VGA cable (male to male) to connect to the MiSTer.
Note: not all VGA cables pass pin 9 - which carries the power - and I had two such problem cables. One was obvious as the connector didn't even contain this pin, but the other cable gave no hint until I tested conductivity with a meter.

Picture:

mAVster_MD2
- The picture is good, but due to the nature of a modulated signal, there is apparent dot-crawl on screen for coloured parts of the picture; this does not happen for shades of white/grey, and is related to the way that composite is modulated. I'll explain more in a moment.
- The colours are good, but seem a bit dim. If you are playing TurboGrafx games, you will notice that playing with Raw RGB will look a little better, because of the way the modulator chip treats the signal; the adjusted colour lookup table is intended primarily for HDMI usage, because the colour spaces are different.
- The modulation chip applies quite a bit of gamma to the signal, so dark areas are quite dark - I had to adjust brightness & contrast on my Commodore 1701 monitor to show features clearly, but it looked quite good (notwithstanding the dot crawl)
- The now-famous scene in Startling Odyssey II does not show 3 clearly-distinct shades of blue in the sky with the original RGB colour set, but does show them with the adjusted lookup table. However, the adjusted colour table shows Keith Courage's sky as more green than it ought to be... so there are some trade-offs.

Antonio Villena
I'm going to have to be brief on this description, because the issue I am having isn't solved yet. I get a brief (1-2 second) period of very clear screen, followed by a similar-length period of dark/no picture, and this cycle repeats. This is obviously not playable, but when it is clear, I can say a few things about the picture quality.
- The colours are more vivid than the mAVster_MD2, and seem to match original colours more closely on RGB settings, including having the 3 distinct sky gradients.
- The screen does not, however, stay clear long enough for me to observe anything about possible dot-crawl, which was the reason I had purchased the adapter in the first place.
- If I could get this adapter to work I may prefer it due to the colours, but at the moment it's too early to say anything.

Dot Crawl
In the early 1980's many computer-based modulated signals had dot-crawl, because of the way that coloured images are modulated. Without going into too much technical detail, the first solution was to have the colorburst signal synchronized with the dots. This reduced dot crawl, but there was still flickering due to the interlacing of images every second frame. Patents were filed in the mid-80's which adjusted the timing of the dots on every second field (ie. half of a frame) to make the screen less 'wavy'. Likewise, there were corresponding advances in the comb filters put to use inside of TVs and monitors to stabilize the images.

These are limitations of composite itself.

The first two principal improvements are not present on either of these adapters - the colorburst signal is not synced with the dot-clock from the core, and the core does not produce a timing-altered intermediate field in the interlace period, so the images will not appear identical to the original systems.

Regarding dot crawl, I've added a variable capacitor to try and minimise the effect as much as possible and "tuned" these as best I could before dispatch. The effect will differ depending on the core though (due to the difference in system clocks) but I believe they are tuned to work resonably well with most cores.

You could try to adjust this to improve the effect, though these really need a ceramic (or non conductive) tool. Using a small screwdriver will affect the signal as soon as you touch it, even if you are isolated from the tool so can be a laborious task, especially since it only requires very small turns and these "varicaps" can easily be damaged. Again, it would need to be adjusted per core so I'd advise against it.

As you say, the effect this has will vary depending on your display as it all depends how your monitor decodes and filters the signal.

The ONLY way round this issue is to use a colour subcarrier in sync with the core, which means it needs to be generated by the FPGA. I've tested this on multiple cores and it does work very well and is a trivial change, but it's my understanding this won't ever make it to the official builds so I won't support it unless it does. I'm working on a PR but I'm not overly hopeful.

retrorepair wrote: ↑Mon Dec 07, 2020 9:51 am The ONLY way round this issue is to use a colour subcarrier in sync with the core, which means it needs to be generated by the FPGA. I've tested this on multiple cores and it does work very well and is a trivial change, but it's my understanding this won't ever make it to the official builds so I won't support it unless it does. I'm working on a PR but I'm not overly hopeful.

I'd be interested to see the code for adding the colour subcarrier.
Do you have a GitHub of a core/commit which shows the differences ?


I should add to the above - I have only tested the composite output so far; S-Video will be at some later date, as the Commodore 1701 monitor doesn't deal with it in a standard manner.

retrorepair wrote: ↑Mon Dec 07, 2020 9:51 am The ONLY way round this issue is to use a colour subcarrier in sync with the core, which means it needs to be generated by the FPGA. I've tested this on multiple cores and it does work very well and is a trivial change, but it's my understanding this won't ever make it to the official builds so I won't support it unless it does. I'm working on a PR but I'm not overly hopeful.

Can you fork the cores on github with the change so you could share it with everyone else?

Also, have you submitted a PR to the official project for the change?

I think it would be really interesting and helpful for multiple people for you to make this change public in some way.

dshadoff wrote: ↑Mon Dec 07, 2020 12:50 pm I'd be interested to see the code for adding the colour subcarrier.
Do you have a GitHub of a core/commit which shows the differences ?

No yet, but I want to make sure it's handled as gracefully as possible and most importantly, selectable, though it will have to be per core.

I don't really want to create and maintain a whole other branch of every core as I don't think this is really feasible for me and I don't want to make things more confusing for users. Though when I submit my changes it will all be visible on the PR. It will be on my git also.

I'm more curious about where you are directing the signal - are you modulating onto green, all colors simultaneously, or another routed signal that I'm not considering ?
It may have relevance as to whether such an additional would be usable by other adapters as well.

I'm outputting to pin14 / vsync when composite sync is enabled. Currently this pin is held high when csync = true, but I'm planning an ini option to change this behaviour (sub carrier freq on/off). The freq could then be selectable in a video sub menu to allow PAL 60hz (not 100% sure that NTSC 50hz would work?).

It would require a hardware revision though on any current adapters. I don't really see any way round that, though I think Antonio's adapter already listens for a sub carrier on that pin.

DISCLAIMER: Not an engineer, just a soldering newbie learning, and am good at googling and learning things quick. Mostly bringing this all up to help stimulate the conversation.

This is supposedly Antonio's original schematic for reference to the discussion (this was the revision of adapter I used to have). This is public info (was posted on atari-forum by antonio himself - https://www.atari-forum.com/viewtopic.p ... dcc84a4361). The newer revision he made or is working on (haven't kept up with it lately) might be different.
EDIT: Also adding the AD724 schematic (which is the chip he uses) for connecting VGA to composite, for comparison.
We can see that antonio used the correct capacitor and resistor for the CMPS pin10 of course. VSYNC in is connected to wired up using a 4FSC clock. Sorgelig suggested using the FSC clock instead (FSC = 3.579545Mhz instead of 4FSC = 14.31818Mhz for NTSC and FSC = 4.433620MHz instead of 4FSC = 17.734480MHz for PAL).

retrorepair's device uses a Sony CXA1145M (https://console5.com/techwiki/images/f/fb/CXA1145PM.pdf) instead to generate the signal:
I'm curious, have either of you tried an AD725 instead of an AD724? I say this because the AD725 makes it so you wouldn't require an external oscillator like you do with the AD724. This seems to be what you were attempting by going with the CXA1145M instead though. does the CXA1145M have a luminance trap (YTRAP) though? Because that's one of the main differences between the AD724 and AD725. Looking into this a bit more now...

This describes I think what was happening in Antonio's adapter (https://www.renesas.com/us/en/document/ ... techniques) for me. Relevant section attached:
Reading on in that article it's suggested that a luminance trap filter method is advised and that a COMB filter method to be optional in case the need arises. How effective would it be to implement a "3 line adaptive comb filter"?

My design incorporates a Y trap. It is actually very similar to a real megadrive with just a few differences to compensate for the difference in MiSTers RGB output and the additional crystals.

Comb filters are usually (always) built into the receiver or TV, not the encoder.

Trust me when I say the only way to beat this is to use a sub carrier generated by MiSTer. Any other technique is just masking the problem and will bring it's own drawbacks. I've actually spent a long, long time on this adapter and tried a lot of different things.

I maintain that most users won't notice the effect and the tuning cap does go a long way to helping with this (at the expense of sharp edges), but for the rest of us (I can't not see it now) it can only be resolved with a subcarrier exactly in sync with the system clock.

I should add, with the subcarrier generated using the fpga, the megadrive core exhibits the same blue/yellow "banding" that my real megadrive 2 does with this chip, probably due to the PAL frequency. Not all that relevant but interesting I thought.

That's awesome, that means it would be an improvement over Antonio's pretty significantly then since you have a Y-Trap used. In your development, did you try out an AD725? If so, were there any disadvantages?

While I had some challenges finding VGA cables for the mAVster_MD2 which pass +5V properly, I found that this gender changer worked quite well:
https://www.amazon.ca/gp/product/B0732SHF14/

In fact, the picture was brighter, and the dot crawl was significantly less noticeable than in my previous test of this board. In fact, I have definitely seen similar dot crawl on commercial products in the past, and accepted it as a fact of life with composite video in the 90s.

Unfortunately, I didn't pipe the audio from MiSTer into the AV board in this test, because of the physical position and dimensions of the board and gender changer, compared to the 3/8" audio cables I own (they wouldn't all fit together properly).

Compared to my previous test, I'm reasonably sure that the (previous) longer VGA cable was the cause of the degraded signal, rather than the fact that the previous test was passing both audio and video through the board.

I was not able to get a stable image on my Commodore 1702 monitor in both composite and S-Video using the Antonio adapter. See video...

https://youtu.be/62HsLadc5FQ

The mAVster i was able to get a stable image with the 1702 monitor.

Also the Antonio adapter I was able to get a stable picture using a JVC CRT monitor with composite only. Ironically, Commodore monitors are made by JVC LOL

Yes, this looks pretty much identical to the problem I also had with AntonioVillena's adapter.
I didn't get a chance to send him an email at the support email address from his website, but I did ask in a few threads on this forum (without receiving a response).