Sparklies on the Tandy Color Computer 2 model 26-3026 NTSC

[qbancoffee]

Excellent project!

I built V4 of the rgb to hdmi board and V3 of the analog 6 bit board and I tested with several versions of the firmware with the same results. The versions were 20201126, 20210529 and 20201126. I wired the analog board to the VDG chip to capture YUV signals and selected the Tandy CoCo 1/2 profile.

I get a very nice image but there are sparkllies all over the screen particularly the non-green screens. I've cleaned up the wiring and tested with to CoCo 2's.

I don't know if this is relevant but things seem to clean up when there is more green on the screen. I have tweaked things in the sampling menu like AC/DC coupled with some improvement but not a perfectly clean image.

Is there something that I should look for or tweak?

Thanks, and once again, excellent project!!!!

[IanSB]

@qbancoffee

If there are sparklies on flat areas of colour then you should try adjusting the Hi & Lo voltage thresholds for Y and UV (mainly Y). If the sparklies are on transitions between different coloured pixels then try running an auto calibration or manually changing the sampling phase.

Posting a screencap might help. (Short press of SW2, file on SD card)

[qbancoffee]

Yes, a screencap would have been helpful... Here are some I took. the sparklies show up quite a bit but it's hard to get a good screencap but these do have some.

-boot1.png : Regular green startup screen no cartridge loaded.

-cls4_0.png & cls4_1.png: When issuing the cls commandd followed by a number you can change the screen color. These two images show how the screen color alternates until I hit a key on the keyboard that causes the cursor to move and add more green.

-megabug_0.png: loaded megabug cartridge and you can see sparklies.

-megabug_1.png: next screen with sparklies.

[IanSB]

Can you do a screencap after running the line of BASIC shown in the gallery example: FORI=32TO255:?CHR$(I);:NEXT https://github.com/hoglet67/RGBtoHDMI/wiki/Gallery-of-Screencaps

[qbancoffee]

I made a video that I though would better show what is happening. https://youtu.be/5N2qXr0cjP0

[IanSB]

Also are you powering the converter from a USB supply or from the coco? There seems to be a lot of noise in the system as it is normally really difficult to get sparlikes on red as the thresholds for the analog voltage are >1V and I have only seen that kind of problem when using a very noisy USB 5v supply.

[qbancoffee]

I am powering it straight from the coco but initially I was using an external power supply with the same problem. It have cleaned up the wiring since so I'll go grab a power supply and test again.

[qbancoffee]

I just tested it with two canaKit power supplies with the similar results..... I think I may have to build another analog board to rule out any damage or bad components.

[IanSB]

You mentioned trying another coco, was that the same model? I have an NTSC coco 26-3134, a PAL micro colour computer, a Dragon and an Atom, all which use the 6847 and produce clean results but maybe some coco revisions are more noisy than others although as mentioned, most colours should be robust with only green & orange being more susceptible to noise. (I'm powering the converters from the machines.)

Try soldering some decoupling capacitors across the 6847 power pins. Another thing to try would be to put low value capacitors on the YUV lines to ground to add a small amount of filtering (maybe a few hundred picofarads).

I think I may have to build another analog board to rule out any damage or bad components.

Make sure your decoupling capacitors are the right values (10uF & 100nf)

[qbancoffee]

Well, technically yes they are the same model ,26-3026 NTSC, except that one is a motherboard that I cloned and assembled from scratch. I based it on the same schematic so except for how the board is routed they are the same. However, The info I'm providing here is from the original Tandy coco not my clone.

I'll double check the capacitor values and try adding decoupling capacitors across the 6847 power pins and some low value caps from YUV to ground.

Thanks for the advice!

[qbancoffee]

I confirmed that the caps are not switched and then went ahead and replaced the CPLD and the MAX5259EEE . Unfortunately the results are the same. I'm currently testing with decoupling capacitors and filters with capacitors I have available to see if I can get any improvement.

[qbancoffee]

I have made some progress in that I'm pretty sure it isn't the RGB2HDMI solution...... I decided to wire it into my CoCo 1 and after calibration and switching to AC coupled, the picture is absolutely flawless. It seems that the CoCo2 is a little noisier than the CoCo 1 and this means that I now need to see if I can find out why.

Again, thanks for this excellent project and your help!

[qbancoffee]

Here is a video of the same boards but with longer messier wires connected to my CoCo1 https://youtu.be/vix40zV71jA

[qbancoffee]

I guess this issue is still valid because it's an issue with these boards on the CoCo 2. Should it remain open?

[IanSB]

It seems that the CoCo2 is a little noisier than the CoCo 1 and this means that I now need to see if I can find out why.

That is the main issue with the thresholding approach to A to D conversion, it either works very well if there is enough noise margin or terribly if there isn't as it has a 'digital cliff edge' effect. It isn't all CoCo 2s though as mine is fine but it's a different model number so different PCB layout etc. Unfortunately I don't have a large enough sample size to know how much of an issue this is.

I assume you have tried varying the DAC lo & hi values as the optimum values will vary from machine to machine. Varying those is an alternative to the AC coupled option.

BTW the other issue you had with cls0 changing colour when you add more green is a bug in the auto NTSC artifact detection. It's meant to switch on NTSC artifacts if the screen is only monochrome and switch off again when there is any colour on the screen but it switches on when the screen is mostly monochrome instead of completely monochrome. I have fixed that and there will be a new beta to try soon.

[qbancoffee]

Yes, I have tried varying the DAC lo & hi values on both of my CoCo 2's with mixed results. If I lower the Y hi when one of my games is loaded, the picture produced is perfect. However, when I return to BASIC with those settings the picture is discolored and bouncy. I'll continue testing but my I'm kind of guessing at values so it might take a while......

Good to know that you have a fix for the the auto NTSC artifact detection.

[IanSB]

Should it remain open?

Yes for now.

It looks like the service manuals are available for both your problem one: https://colorcomputerarchive.com/repo/Documents/Manuals/Hardware/Color%20Computer%202%20NTSC%20Service%20Manual%20(26-3026%20&%2026-3027)%20(Tandy).pdf and my working one: https://colorcomputerarchive.com/repo/Documents/Manuals/Hardware/Color%20Computer%202%20NTSC%20Service%20Manual%20(26-3134%20&%2026-3136)%20(Tandy).pdf

A few suggestions: Try isolating the YUV pins on the 6847 from the rest of the circuitry so they only feed the RGBtoHDMI (Maybe remove the modulator?)

Change the comparators on the analog board from MAX9108 to MAX9144 (MAX9144ESD+). They are pin compatible slower parts (40ns instead of 25ns) which might have the effect of filtering out any high frequency noise. I have tested these on on some of my analog boards so they will work but I don't know if they will help with the noise.

[qbancoffee]

Thank you for the links.

I've tested my CoCo's with and without the RF modulator but the results are the same. I'll purchase the other comparator and see what that does and for the moment 'll study the schematics to see If I can see any differences that might help.

fingers crossed.

[qbancoffee]

What I forgot to ask you is what are the settings you are using for your CoCo 2?

[IanSB]

@qbancoffee

What I forgot to ask you is what are the settings you are using for your CoCo 2?

The default values in the profile.

The Y Hi & Lo settings are quite marginal but only affect white, green and orange. The UV Hi and Lo settings have a wide range and affect all other colours (yellow, blue, red, cyan and magenta etc) There are some test palettes that allow you to examine the individual channels so perhaps you could try the following: First run the for/next loop to get some colours on screen:

Then go into the palette menu and select: Test_4_Lvl_B_or_U

Try adjusting the UV Hi and UV Lo settings (Hi must always be greater than Lo UV Hi adjusts the white level UV Lo adjusts the blue level The range of values that are noise free on my setup are UVHi 113-142 UVLo 76-109

Repeat the test with: Test_4_Lvl_R_or_V UV Hi adjusts the white level UV Lo adjusts the red level The range of values that are noise free on my setup are UVHi 113-142 UVLo 76-109 (Same as the first one)

The optimum values will be half way between the two extremes

Note these values are shared between the two channels so if there is any difference then an average value will have to be selected.

Finally select Test_4_Lvl_G_or_Y

Y Hi adjusts the yellow Y Lo adjusts the white

The range of noise free values for me is: Y Hi: 41-45 Y Lo: 21-36

The interesting thing is that all the above are virtually identical for my PAL micro colour computer and my NTSC CoCo 2 which are two very different machines which is why I'm surprised there is much more of an issue with your CoCo 2 and reproduction. I can't really see a significant difference in design between the working and problem revisions.

EDIT: This is an updated version of the software that has the NTSC artifact fix among other changes: NTSCartifactFix.zip This won't help with the above problem but the CLS0 shouldn't switch artifacts on anymore

[qbancoffee]

Things are not perfect but I was able to improve things dramatically by bypassing the CoCo 2's transformer with a clean DC power supply and by powering the raspberry pi with a separate power supply.

I'll try what you described and replace the software with artifact fix you just sent and see how it goes. Thanks for detailed instructions!

[qbancoffee]

There was some stability by just using this new version of the software even though there should not have been?

I went through your instructions and I can get a very clean screen with all colors until I load one of my games cartridge or tape. I'll try and make a video to demonstrate it.

[qbancoffee]

I went through everything as you described it and I now have a better understanding oh how it works. Thanks! Here is a video sort of demonstrating what I'm talking about. https://youtu.be/5f4k-8KudQ8

[IanSB]

@qbancoffee

When you get sparklies around colour transitions like the characters at 2:30 rather than on solid blocks of colour you need to adjust the sampling phase (Try the entire range as there can be more that one null and have some other colours displayed using the for / next loop above). Note that the sparklies on the blue or orange areas in megabug are actually on transitions because those colours are actually hi res mono dot patterns with artifacting switched off. You may have to go 'around the loop' a few times tweaking the levels and sampling phase

EDIT:

There was some stability by just using this new version of the software even though there should not have been?

There is no specific change that would affect that although the NTSC artifacting code has been optimised which means different code is being executed. That might affect the noise being produced by the raspberry Pi zero so maybe your Pi zero is a bit more noisy than most. Do you have another one you can try?

[qbancoffee]

o.k. I'll experiment some more when I get home tonight.

[IanSB]

@qbancoffee

Also put the setting back to DC coupled before making your DAC and phase adjustments. You are picking up a DC coupled signal so AC coupling can cause more problems than it solves. With a DC coupled signals the only use for the AC coupling is to remove any mains hum in the signal caused by hum in the power supply and that is unlikely to be the case with your bench PSU.

[qbancoffee]

O.k. I've tried everything you've mentioned including using a second pi. I can get my games to look good or I can get the VDG green screen to look good but I can't have it both ways and I'm dizzy from trying all the combinations phase,DC/AC, HI LO's ect. The board seems to be working but I can't help but wonder that there is a bad component. I've already swapped out the A/D on the analog board and I've swapped out the CPLD. At this point I think I might just make another analog board just as a sanity check. If there is component that's bad which one would you say has the highest likelihood of not letting the board zero in on a configuration.

The Maddening part is that it's so close.

[IanSB]

Other than some build issue with the analog board there is one other thing I can think of:

Are all the problem games artifact ones?

If so try disconnecting the artifacting circuit from the VDG which can be done by lifting one end of R9 (1K). This circuit puts a low(ish) impedance load one of the VDG lines during the back porch to make the colour encoder generate a colour burst in hires mono mode but I have found VDGs don't like low impedance loads on the video outputs and it is not present on the CoCo 1.

Alternatively if the VDG is socketed bend out the 3 video pins so they are completely isolated from the rest of the circuitry as the luma channel has a capacitor on it (C59) which is not present on the CoCo 1 either.

EDIT: There is a possible workaround if we can't find a solution but it is not ideal: The latest software (posted above) has a new feature to switch between two sets of geometry and sampling settings in each profile and that can be enabled by changing the Auto Switch setting from "Sub-Profile Only" to "Sub + Manual" After that change you can switch between two sets of settings by pressing SW3 or changing the "Timing Set" option in the menu so you could set up one set for the main software and one for the problem games.

[qbancoffee]

Just got home and hopefully I can test all this out. The problems do seem to be artifact related however I'm not sure. I was contemplating removing R9 already but wasn't sure that would help but now that you mentioned it it's the first thing I'm going to try. I hadn't thought about C59 because I could have sworn that was there on both! Thanks I'll try that as well.

[qbancoffee]

I think lifting R9 and C59 did the trick at least with the pi beng powered externally. Here is a video so you can see the results. https://youtu.be/DYkkNiKiXAw When I power the pi from the board I get mixed results that I can correct but for some reason the profile isn't always saved. For example if I save as phase 10, the pi restarts phase 2 and the same happens with other phases. Is the program just loading a multiple? I'll try adding caps or something to the pi to see if that helps.

[IanSB]

@qbancoffee

Do you have to change both R9 & C59 or is it specifically one or the other mods that are required?

It looks like the saving problem is a bug which is saving the value modulo 8. I've not noticed that before as the values I use are less than 8 but I will fix it and post an update.

[qbancoffee]

I experimented with one or the other attached but the best results are with both disconnected from the circuit. I'll test the patch as soon as you have it up.

I'm currently testing some more and it seems that when pi is powered from the CoCo there is more noise.....

[IanSB]

Ok here's the update with the saving fix:

Phase_Save_fix.zip

Wipe the SD card and write the new files (make a note of any working DAC & phase values as you will lose them after the update and have to modify and resave them.

It might still be worth building another analog board using the 9144 chips I mentioned above.

[qbancoffee]

The patch works. I can get excellent results when I power the pi with it's own power supply but varying results when powered from the coco. I'll post a video soon

[qbancoffee]

It's pretty much flawless when using an external power supply. Here is a video of it in action https://youtu.be/gLXZYFm6bKM

I removed R9 & C59 and powered the pi with an external PSU to get these results. Do you need the final working configuration? is there a settings file I can copy for you?

[IanSB]

@qbancoffee

Do you need the final working configuration? is there a settings file I can copy for you?

Yes, it would be interesting to see how much difference there is. The file will be in /Saved_Profiles on the SD card

Are you using the original PSU for the CoCo now instead of your bench PSU?

[qbancoffee]

I completely forgot to get that for you before I left on my trip.I'll send it over as soon as I get back.

[qbancoffee]

I can't seem to get a completely clean picture using the original PSU, I have to use a separate on for the pi. Here is the profile for my working setup. Tandy_CoCo_60Hz.txt

I just got home and I do have a box of parts that arrived so sometime tomorrow I'll build a new analog board with the alternate comparators.

[qbancoffee]

I've built a second analog board using the max9144 instead of the max9108 comparators and it seems much more stable. However, in order to get a clean picture I had to lift C59 and R9 and use a separate PSU for the pi. This is the case for both of my CoCo 2's 26-3026 NTSC.

Attached is the config file and a link to a video showing it in action. This is an excellent project and again thank you for all of your work! Tandy_CoCo_60Hz.txt https://youtu.be/Ijkw9JX44r8

[IanSB]

@qbancoffee

I've built a second analog board using the max9144 instead of the max9108 comparators and it seems much more stable.

I had been considering changing to that chip in the BOM because I was already using the MAX9142 (half of a MAX9144) in the redesigned boards I'm getting assembled (the boards are functionally identical but use different chips due to availability issues) but as you have seen an improvement, I've made my mind up and now changed the BOM: https://github.com/hoglet67/RGBtoHDMI/wiki/Bill-of-Materials-%28Analog-Board%29

My 26-3134 CoCo 2 was a 16K version without extended Basic so it has been difficult to test with actual software but today I upgraded it with an 8K extended basic, 64K of RAM and a CoCo SDC and I've been able to run Megabug and other software and I can report that there are still no issues with it so I am still at a loss to explain the problems you are seeing.

A few things I noticed: The transistor connected to R9 is a different part number in the 26-3134 and the diode connected to that might be different as well.

It would be useful if we can find someone else to try this on a 26-3026

BTW I think I have already fixed the black & white bug you mentioned in your video as there was a known issue around that. It will be available in the next beta release shortly

Here are a couple of screencaps (The Pi is powered from the CoCo):

[qbancoffee]

Well, I'm glad I could help by testing the 9144's, those are really nice screen images.

I just looked in the service manuals for both the 26-3134 and the 26-3026 (at least the ones I have) and they both have the same part number for the transistor and the diode. I wonder if we're maybe looking at different manuals?? I see 2N3904 for both transistors and 1KF20-4 for the diodes in the color artifacting circuitry on page 33 for the 26-3134 but Q2 isn't listed in the parts list, at least not specifically. One of those switching transistors might be Q2.

I don't have another CoCo2 but I'll ask on coco discord to see if anyone has a coco 2 like mine and is willing to test so that maybe I could mail one of the boards.

I think the noise might be related to the transformer/power regulation circuitry because I powered both the pi and the CoCo 2 from the pi's PSU and it's really clear.

I disconnected the transformer, removed the SC77527(SALT chip) soldered a wire from a 5V pin on the RGBtoHDMI board and connected it to the 5V rail on the CoCo and the result is really good. I only had to change the coupling to AC from the configuration I was using.

Removing he SALT chip means that there is no RS232 or zero crossing circuit to load/save programs but that can be fixed. I've already made a salt chip replacement that works so not a big deal if it came to that. I'll keep investigating though.

Great to hear that there's a fix for the black and white image.

[IanSB]

I wonder if we're maybe looking at different manuals

I'm looking at the circuit diagrams on the PDF manuals I linked above. The 26-3134 shows 2SC945 or 2SC536K on the schematic The 26-3026 shows 2N3904

However I think that the R9 and C59 mod makes a very marginal difference and the real problem is a noisy power supply.

I would normally suggest recapping but you new build board also has the problem and the 26-3134 has the same PSU circuitry anyway. Maybe your AC supply is really noisy. The 26-3134 has the AC transformer in a screened can

The only difference with my AC supply is that I'm running from 240V 50Hz via a 110v step down transformer.

I just remembered one issue I had:

I normally use 1600x1200 HP LCD monitors for my retro computers but for some of the smaller sized ones like the CoCo I used some 10" monitors I got from ebay: https://www.ebay.co.uk/itm/164896147615

The first one was OK but another two I bought later induced terrible noise on the RGBtoHDMI's output which was caused by those two being supplied with different low quality "wall wart" 12v PSUs and they were inducing noise back into the computer or analog card. I fixed that by replacing the PSUs with better ones. I can see you are using a Dell monitor so that isn't likely to be the cause but maybe there are some other bad wall warts inducing noise in your AC supply.

[qbancoffee]

Well, in an interesting turn of events, I am powering the pi from my Coco 2's power supply and it is perfectly clean. I'm not sure what I did to make this so clean. I'll have to keep investigating to see if I inadvertently made a change.

[qbancoffee]

That's interesting that you noticed dirty power supplies in the monitors. I'll look out for that and check my AC Supply. One interesting note is that my cable and internet went out at the exact moment I got the clean display and at the moment I have no internet and no cable so I can't test that theory out even though it's a bit of a stretch.

[qbancoffee]

I don't know why but it works powering the pi from both coco psu's https://youtu.be/AFoeUqsYpfw

[IanSB]

Perhaps the interference source got switched off.

I suppose the main advantage to running the pi on a separate PSU is that you don't have to wait for it to boot up when you cycle the coco's power. BTW you can switch off the startup message in the preferences menu Also in NTSC artifact mode, some programs suggest you power cycle the machine if the blue/orange are swapped as the order is random but you can correct that in the menus by adjusting the artifact phase setting in the palette menu instead.

[IanSB]

I haven't finished the next beta yet but the alpha test version (AppleIIGS_Auto_Test_Alpha1.zip) posted at the end of this thread has the fix for the mono screen as well: https://github.com/hoglet67/RGBtoHDMI/issues/209

[qbancoffee]

Well, I think the real big difference at least on my end was the comparators and clipping c59 and r9. I'll download the latest alpha and test it out.

o.k. thanks for the message disable tip. I think I want to hook it up to my CRT monitor and test it out.

Perhaps the interference source got switched off.

Now I'm going to crazy looking for it!

[qbancoffee]

I updated to the latest alpha and switched to AC coupled and all was fine until I restarted. Instead of VDG green the background is black and white when running off of the cocos power supply but when I use a separate psu, the VDG green comes back occasionally after a restart.

https://youtu.be/LBKLxdv9zi0

I can reproduce the black and white problem most of the time by going into the palette menu and changing the artifact phase to 180 and changing the phase to 4 in the sampling menu. After saving it and restarting the pi, the screen randomly becomes black and white. However I can reset the configuration and go through the process a handful of times and it will randomly work and be fine between restarts without any issue. Very confusing but I think I'm getting close to reliably reproducing this problem.

[qbancoffee]

In this video I can reproduce the problem I'm experiencing. I don't know if this is the same bug you patched or if it's even a bug at all but at least you can see it and maybe make some sense of it.

https://youtu.be/l_a9kyk9IvU

[IanSB]

@qbancoffee

That was the bug I thought I'd fixed but my fix was incorrect. I think I have fixed it now but I can't test anymore as I managed to damage my coco 2 while testing and it's no longer booting :( (I think I plugged or unplugged the cart with the power on but I'm now just getting a screenfull of garbage text) Anyway here is the updated file to try: kernelrpi.zip Just unzip and overwite the kernel.img file on the previous alpha version.