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!!!!

[qbancoffee]

No! I'm sorry to hear about your coco 2! Hopefully it's a simple fix....... Do you have spare parts? I'll test this fix now.

[qbancoffee]

It's absolutely perfect now. Do you need anything from me in terms of configuration and testing? Thank you for all of your help!

[IanSB]

@qbancoffee

Do you need anything from me in terms of configuration and testing?

I don't think so at the moment. One other thing that occurred to me about powering from the CoCo is that the power goes through a schottky diode on the analog board to protect from reverse power if you power up the Pi zero at the same time. There is a small voltage drop but if the power on the CoCo is already low that might result in the 5v supply to the Pi being too low.

Hopefully it's a simple fix....... Do you have spare parts?

I have some RAM, 6847, 6821, EPROM adapters for the ROMs and the TTL. I can test the SAM and 6809 in my Dragon but I don't have any of the other ICs.

[qbancoffee]

One other thing that occurred to me about powering from the CoCo is that the power goes through a schottky diode on the analog board to protect from reverse power if you power up the Pi zero at the same time. There is a small voltage drop but if the power on the CoCo is already low that might result in the 5v supply to the Pi being too low

I actually thought about bridging the diode yesterday in order to power the coco via the 6 pin plug but ultimately decided against it.

I have some RAM, 6847, 6821, EPROM adapters for the ROMs and the TTL. I can test the SAM and 6809 in my Dragon but I don't have any of the other ICs.

I can't say I'm an expert on the coco but I had a similar problem twice. One was a burnt SAM although I don't see how removing the cart while powered on would burn the sam...... The other was when I burnt a PIA. Luckily I found a still made new replacement for the 6821 and the 6822 it's the W65C21N6TPG-14. https://www.mouser.com/datasheet/2/436/w65c21-661.pdf

And it's what I have in my new coco 2 board

Good luck on the repair hopefully it's something you have on hand and I'll reach out if I think of anything.

BTW I was thinking of including this design as part of a coco2 board I'm making or a maybe Ill make an RF can replacement board or something so that all one would need is to provide a pi. I don't think it would sell much if at all, but If I do sell it I would like to give your project some of the money.

[qbancoffee]

the luma channel has a capacitor on it (C59) which is not present on the CoCo 1 either.

If you are doubting whether to recommend removing C59 for my version of the coco 2, I have some more evidence that C59 should be removed. I remembered this video by AC where his coco 2 has this capacitor removed to improve the image for a composite video mod he did. https://youtu.be/tayGsz7Xs3A?t=3274

[IanSB]

@qbancoffee

Good luck on the repair hopefully it's something you have on hand and I'll reach out if I think of anything.

Back in business! The BASIC 1.2 ROM was dead. I noticed that it was completely cold when other chips were warm. Fortunately I had bought a couple of 2764 EPROM adapter PCBs, one to use on the Extended Basic to get the CoCo SDC working and one spare although I was already thinking of using it to upgrade from BASIC 1.2 to 1.3 which I have now done.

I don't think it would sell much if at all, but If I do sell it I would like to give your project some of the money.

Thanks, any contributions would be put towards purchasing more vintage computers so I can add support for them.

I remembered this video by AC where his coco 2 has this capacitor removed to improve the image for a composite video mod he did.

Yes it's probably a good idea to remove it as it isn't there on the CoCo 1

I've decided to power my Pi externally now because you get instant video when power cycling the CoCo

[qbancoffee]

should I close this issue?

The board works with an MC10 I recently purchased but I had to cut C33, 150pF cap, to get a clean picture.

[qbancoffee]

Back in business! The BASIC 1.2 ROM was dead. I noticed that it was completely cold when other chips were warm. Fortunately I had bought a couple of 2764 EPROM adapter PCBs, one to use on the Extended Basic to get the CoCo SDC working and one spare although I was already thinking of using it to upgrade from BASIC 1.2 to 1.3 which I have now done.

Excellent! glad to hear it.

[IanSB]

should I close this issue?

Leave it open until someone else has tried the same revision board.

The board works with an MC10 I recently purchased but I had to cut C33, 150pF cap, to get a clean picture.

Again my PAL MC10 didn't need any tweaks although I will experiment further as removing the cap might produce a wider noise free range of levels giving better noise immunity.

Does the R9 part of the mod make much difference?

There is a new Beta 33 release on my fork which has all the recent changes consolidated. This will likely be a release candidate for the next stable version unless bugs are found so could you check it is OK for you (Some minor changes since the version above): https://github.com/IanSB/RGBtoHDMI/releases

BTW can you suggest a few games or demos to try on the CoCo that have good graphics or sound as I don't really know anything about the machine.

EDIT: Just removed C59 on my machine and there is now a much wider range of acceptable voltage levels on the Ylo and Yhi settings so I will definitely include that as part of the mod instructions. Also the R9 signal isn't separately controllable so leaving it in won't help with artifact detection I've updated the default profile in beta 33 to match my machine with C59 & R9 removed

Can you post your saved MC10 profile and I'll include it

[qbancoffee]

BTW can you suggest a few games or demos to try on the CoCo that have good graphics or sound as I don't really know anything about the machine.

My childhood memories of these of these games are very colored..... I'll have to look around to see which game really had many colors because I remembered megabug with more colors than it actually has. I'll ask on the discord server.

There is a new Beta 33 release on my fork which has all the recent changes consolidated.

I'll test this out and let you know how it works .

Just removed C59 on my machine and there is now a much wider range of acceptable voltage levels on the Ylo and Yhi settings o.k. I was going to solder it back in and test but seeing that you did get a wider range I won't bother.

Can you post your saved MC10 profile and I'll include it

yes, here it is. Tandy_CoCo_60Hz.txt

[qbancoffee]

Here is a video of the mc-10 https://youtu.be/DVpewK6XRqk

[IanSB]

Thanks for the profile. I've updated the connection instructions to include what we have discovered here: https://github.com/hoglet67/RGBtoHDMI/wiki/Cables

C59 and R9 aren't fitted on any PAL systems, probably the same for my PAL MC10 as well as the 6847 is connected to the TCC1000 60Hz to 50Hz converter chip on PAL machines.

One final thought on internal powering: Have you tried picking up the power from closer to the regulator as maybe noise from the Pi is getting injected into the 6847 by connecting to it's power pin.

[qbancoffee]

Thanks for the profile.

No problem

I've updated the connection instructions to include what we have discovered here:

Would you like a picture of my version of the board with the location of the component circled or maybe a 3d rendering of the board?

Have you tried picking up the power from closer to the regulator

I tried powering from 3 or 4 separate points with similar noisy results while c59 was connected.

[qbancoffee]

Something like this

[qbancoffee]

Here is one for the MC-10

[qbancoffee]

I just tested Beta33 on my CoCo 1, both of my CoCo2's and my MC-10 Coco2's removed C59 and reattached R9. MC-10 removed C33.

For all of my computers, I used the default CoCo 1-2 60Hz profile only having to switch from DC coupling to AC coupling. The pi was powered from the rails of the computers with no external PSU.

Basically it looks like there is no mod needed for the CoCo 1, only C59 needs to be removed from the CoCo2, and only C33 needs to be removed from the MC-10

[qbancoffee]

I loaded a game I recently learned about called donut dilemma. I know what it should look like on the coco 3 but I'm not quite sure what it should look like on the coco 2. I'm going to ask around because I think the artifact colors are wrong on my coco 2.

[IanSB]

only having to switch from DC coupling to AC coupling

The AC coupling can help as it effectively eliminates any problems with DC variation in the absolute Y level as the Y Hi and Lo settings are then relative to the Clamp level rather than absolute.

Between us we now have quite a few machines so it would be useful to measure the amount of variation between them and maybe come up with some sensible compromise values that work with all the systems.

Can you repeat the above Y level test: i.e. use the for/next loop for some colour on screen then select the Test_4_Lvl_G_or_Y palette from the palette menu and vary the Ylo and Yhi settings to see what the noise free value ranges are SWITCH TO DC MODE WHEN DOING THIS TEST

On my NTSC CoCo2 with C59 removed: Yhi = 44-46 Ylo = 31-38 I then set the values to mid way (i.e 45 & 35) and then varied the sampling phase Sampling Phase = 2-4

On My PAL MC10: Yhi = 43-45 Ylo = 32-37 Sampling Phase: = 3-5 Note all the PAL machines will likely be different to NTSC as some of the signals come out of the TCC1000 but there is a separate 50Hz profile anyway.

[qbancoffee]

Can you repeat the above Y level test:

Yes, hopefully soon.

[qbancoffee]

CoCo 2 NTSC Y level test with DC coupling C59 removed I ignored the phases where I couldn't get a noise free image. The ranges for the best results are these.

sampling phase 1 YHi = 41 YLo = 32-33

sampling phase 2 YHi = 40-41 YLo = 30-33

sampling phase 3 YHi = 40-42 YLo = 30-34

sampling phase 4 YHi = 46 YLo = 29-34

sampling phase 9 YHi = 41 YLo = 32-33

sampling phase 10 YHi = 39-41 YLo = 30-33

sampling phase 11 YHi = 39-41 YLo = 29-34

sampling phase 12 YHi = 39-41 YLo = 29-33

I'll try another computer later on.

[qbancoffee]

MC-10 with C33 removed I ignored the phases where I couldn't get a noise free image. The ranges for the best results are these. sampling phase 1 YHi = 41 YLo = 29-44

sampling phase 3 YHi = 40-41 YLo = 29-34 sampling phase 9 YHi = 40-41 YLo = 30-33

sampling phase 10 YHi = 39-41 YLo = 29-33

sampling phase 11 YHi = 38-40 YLo = 28-33

[IanSB]

OK, can you try the following settings:

Sampling phase 3 YHi 45 Ylo 35 AC coupling YV Sync 63 Y Clamp 67 Everything else should be the same as default.

[qbancoffee]

Testing the mc-10

Sampling phase 3 YHi 45 Ylo 35 AC coupling YV Sync 63

With the above config all looks good

Y Clamp 67

At 57 you start to see some sparklies and it gets progressively worse as you increase. At 63 you start to see vertical scrolling.

[qbancoffee]

[qbancoffee]

The cleanest Y clamp values are from 53-56

[IanSB]

Try YV sync 62 Y clamp 56

And then tweak Y hi +-1 if necessary

[qbancoffee]

Try YV sync 62 Y clamp 56

And then tweak Y hi +-1 if necessary

62 and 56 looks good on the mc-10

[qbancoffee]

I can switch over to the coco 1 afterwards if you want.

[IanSB]

Those voltage settings work for both my NTSC coco2 and PAL MC10 but the phase is 4 on the MC10, probably due to the TCC1000

I can switch over to the coco 1 afterwards if you want.

Yes please as we need to check all your other systems with those settings. If something is a little marginal we may still be able to tweak Yhi/Ylo as they can be adjusted over a +- a few before it causes any issues on my system.

[qbancoffee]

Yes please as we need to check all your other systems with those settings.

The coco 1 works with those settings. tell me if you want to test more on the coco 1 or if I can switch to the coco 2

[IanSB]

Maybe just vary the YHi & YLo settings at least +-1 to see if the settings are marginal but other than that, switch to the coco2

[qbancoffee]

Yhi 45-48 Ylo 37 <- with slay the nereis there are some artifacts on the right edge of the screen when 36 but looks good otherwise

switching to coco 2

[qbancoffee]

CoCo2 looks good too Yhi 45-48 Ylo 37 <- with slay the nereis there are some artifacts on the right edge of the screen when 36 but looks good otherwise

[IanSB]

Well we could change Yhi to 46 and Ylo to 34 if you think that would give better margins with your systems as that has no effect on my system.

[qbancoffee]

I'm comfortable with what we have so far. I'll play with it some more and let you know if I notice anything that needs to be tweaked.

[IanSB]

I'm comfortable with what we have so far. I'll play with it some more and let you know if I notice anything that needs to be tweaked.

OK. I like to have +-1 of margin where possible so that variations when hot or cold can be catered for.

BTW I have just discovered a slight problem: The auto 50/60 Hz profile selection no longer works when both profiles are set to AC clamp mode. This is because the H sync polarity on the PAL CoCos is inverted compared to the NTSC ones (It comes out of the TCC1000 chip). The system always starts with the 50Hz profile and if the timing doesn't match it switches to the 60Hz profile but in AC mode it can't get a lock when feeding the 60Hz output into the 50Hz profile because the sync polarity is wrong so it can't measure the time and do the auto selection. It actually worked more by luck than by design in DC mode!

To work around this I have split them out into separate profiles so in future releases you will have to specifically select the Tandy_CoCo_60Hz profile in the main menu.

[qbancoffee]

BTW I have just discovered a slight problem: The auto 50/60 Hz profile selection no longer works when both profiles are set to AC clamp mode

Would it be possible to have it temporarily switch to DC mode and do some lucky-auto-detecting whenever a profile is switched by the user and then revert the to whatever mode was previously selected/loaded? In other words, have autodetect always switch over to DC mode when it does its thing.

If not, manual configuration is bad at all to do. I mean if you're wiring one of these converters to your retro computer, you should be able to switch between the different profiles.

[qbancoffee]

BTW this game was recommended to me for testing colors. https://www.youtube.com/watch?v=9lUiwo7Zly4 rally sg

[IanSB]

Would it be possible to have it temporarily switch to DC mode and do some lucky-auto-detecting

I don't think that will be practical. The only reason auto 50/60 selection is used at the moment is to reduce the number of profiles by not having separate 50 or 60 ones for each computer which used to be the case but having 1 extra is not going to be a problem. Unlike some other computers, the CoCo can't dynamically switch from 50 to 60 Hz output so once the correct profile is selected no further profile changes would be needed unless you are using the same converter on multiple PAL and NTSC machines.

[IanSB]

@qbancoffee I've just released Beta35 which has all the recent profile and palette changes: https://github.com/IanSB/RGBtoHDMI/releases

There is also a new feature aimed specifically at the CoCo: When NTSC Artifact colour is enabled, pressing SW3 will cycle through the four phase quadrants.

I know the CoCo has the colour phase randomly flipped 180 degrees on power up and many games have an option to press the reset button to flip the Orange/Blue colours. (e.g. Monkey King)

However this random flipping doesn't seem to affect RGBtoHDMI and it always comes up in the same phase although I don't think that is a complete fix as it depends on which phase the developer assumed so some programs will always be right and some will always be wrong and pressing reset won't fix it.

Pressing SW3 until you get the right colours is easier than messing with the menus.

Can you check you are happy with the default sample menu settings (Phase/YHi/YLo etc) with all of your systems?

[qbancoffee]

When NTSC Artifact colour is enabled, pressing SW3 will cycle through the four phase quadrants.

That's fantastic!

Can you check you are happy with the default sample menu settings (Phase/YHi/YLo etc) with all of your systems?

Unfortunately my room is in disarray right now so I cant check all of my systems until things are a bit more ordered but I can check at least one of my CoCo 2's.

On Friday I posted videos of the RGBtoHDMI in action on my Dell flat screen and CRT monitors and then the videos got played on Saturdays episode of CoCo Talk.

I showed some color on my dell monitor and there were some comments. One was "where is the cyan?" https://youtu.be/Fbbc84MooKo?t=6488

I played a semigraphics game that was recommended to me to show off some color. The developer of the game, Nick Marentes, said it looked good. https://youtu.be/Fbbc84MooKo?t=7416

BTW after a couple of months I was finally able to buy a 26-3134 at a reasonable price and if it works, I might have another coco to test with.

[qbancoffee]

In terms of sparklies, Beta35 worked well with my coco 2 after selecting the CoCo 60hz profile. Cycling through the phase quadrants with SW3 worked perfectly. The colors look a little off with the Dragon-CoCo full palette but look closer to what I think they should look like with Dragon-CoCo emu palette. May we're all just use to seeing emulated colors?

I'm still organizing and cleaning but I'll try and get the other systems tested tomorrow.

Games tested -Slay the Nereis -Color Baseball -Mega Bug -Dungeons of Daggorath

[qbancoffee]

I had to change YHi on for my CoCo-1 to 46 in order to get a perfect picture. YHi=46 gave a clean picture for the following. -MC-10 -CoCo 1 -CoCo2 26-3026 original -CoCo2 26-3026 new board

Results for my latest coco, 26-3134, were not so good. I had to cut C59 in order to get a stable-ish picture but I could never get a clean picture. I think I need to remove the RF can or this coco just needs work as the board was full of rust on and around the VDG.... I'll have to get back to you on that. I used the emu palette for all these tests, attached is my saved profile Tandy_CoCo_1-2_60Hz.txt .

The RGBtoHDMI board seems very stable and the results look good to me, thank you for all that you've done to get this made!

[qbancoffee]

O.k. I was able to get a clean picture with my latest coco 2. I cut C59 and removed the RF can. I had to make some adjustments to the profile. Attached is what works for this coco which is actually a 26-3134A. I don't know if the "A" makes a difference in terms of board design. Tandy_CoCo_1-2_60Hz.txt

[qbancoffee]

I just found that my board 26-3134A is a very different design than the 26-3134 schematic I was looking at and it turns out that C59 is not conected to the Y signal. The capacitor I should have cut is C23 so tomorrow I will reconnect C59 and the RF-can to see if removing C23 is enough.

[IanSB]

The capacitor I should have cut is C23 so tomorrow I will reconnect C59 and the RF-can to see if removing C23 is enough.

OK, that's a pain for writing installation instructions if the component numbering changes depending on which board you have.

I'll change the Y-Hi default to 46 on future releases

BTW there were some bugs in Beta 35 so it has been superceded by Beta 36 although they only affected the RGB CPLD, not the YUV one used on the CoCo but it's probably worth updating again for consistency when testing.

Also, beta35 / 36 has a new feature that affected the CoCo: Previously when auto calibrating on a static image, a flashing cursor was seen as noise which affected the results so it was preferable to switch off the cursor before running the calibration. In the above release, flashing cursors are automatically detected and ignored when auto calibrating so you should get zero errors as the best result.

[qbancoffee]

I reattached the RF-can and cut C23 and it works perfectly with Beta36 and Y-Hi=46 Auto-calibration completes with far fewer errors and it seems stable.

OK, that's a pain for writing installation instructions if the component numbering changes depending on which board you have.

Yes it is and since the procedure seems to be the same at least for our CoCo's, how about having general instrcutions accompanied by a table like the following.

In order to get a clean picture with the Dragon/CoCo computers you may need to cut a capacitor that is attached between the Y signal and ground. The following table lists the capacitor reference by model/model number.

Model	Model Number	Capacitor to cut
TRS-80 CoCo1	26-3002	None
TRS-80 CoCo2	26-3026	C59
TRS-80 CoCo2	26-3027	C59
TRS-80 CoCo2	26-3134	C59
TRS-80 CoCo2	26-3136	C59
TRS-80 CoCo2	26-3134A	C23
MC-10	26-3011	C33

[IanSB]

Please unzip and copy the following to your SD card overwriting the original file: kernelrpi.zip Then delete the Palettes folder to force them to be regenerated with new values

Note there are actually two orange colours (well three if you include the dark orange background to the orange text) Medium orange is used for text chars and block graphics and bright orange is used on the higher resolution graphics. You can see the difference by increasing the Y lo value which will change the medium orange to bright orange You may want to try matching the bright orange from any higher res multi colour graphics game (not NTSC artifact colours which are generated separately) Let me know if the colours are OK and I'll do an updated release

[qbancoffee]

Thanks!

I'll check it out right away!

[qbancoffee]

The emu palette looks the same, did u make the changes to CoCo-Dragon and CoCo-Full? The colors do seem better. I'll keep testing.