This will be a Big Update.   Note: it became even bigger when I realized I hadn't covered some of the topics I had promised to in the last post. So more stuff got added today on March 12th

It's getting down to the wire on releasing this thing hopefully within the next month or so. Several break throughs have occurred, ranging from fixes for video jail bars which were especially terrible over Composite, fixes to the MSX CPLD core, and finally a resolution on 5 AtariSoft games that kept ignoring keypad input not allowing them to start-up. And there's more...
​

Jail Bars

I discovered this problem when finishing up the CV-EAV board I had been working on, which is pretty much a copy of the CV-NUC+ video circuit made for the original Colecovision game console. Although I had seen subtle jail bars on the image over the S-Video output on certain monitors, I had shoved this to the back of my mind because of other more important stuff I was trying to get done. However one day I hooked up the Composite monitor and pretty much got freaked out by what I saw. Horrible much worse jail bars could now be seen!!! In my mind this was impossible, how could I have missed this?

Well as it turns out I remembered some earlier tests via the Composite output that had looked just fine. So I asked myself "What the heck had changed?" -- and then I flashed back to when I improved the Chroma buffer circuit and was able to get the colorburst signal up to where I felt it should be, which at the time was about 2-1/2 times the poor amplitude I was seeing before. Just to be clear, there were benefits to this change that made it worth doing, such as blacker blacks with no green tint that can be a characteristic of many of the Composite, S-Video and some of the DIY RGB mods being done. So I started thinking that somewhere I had read an article in reference to the VDP chip and getting RGB out of it where the proposed fix for jail bars was to reduce the amplitude of the R,G, and B signals. This started to coincide with the change that I had made, where I had increased the amount of chrominance, and apparently the jail bars as well.
​
Well the simple solution was to decrease the chroma level until the jail bars went away, but not so far as to affect the color being produced on the monitor. This was accomplished with a reduction in the pass-thru capacitor. And I still ended up with good color saturation in spite of it. Go figure.

A New Core for the MSX Module's CPLD

When I first got the CV-NUC+MSX Module working, it was with the version 1.3 core which powered up the machine in an Adam memory configuration, starting off with 24K of the 32K SRAM being active. And yes it did pass the SGM tests as an Adam with an AY sound generator, but this was a CV not an Adam so that always bugged me. Anyway I thought I saw my mistake and came up with a version 1.4 core to fix it, and sure enough it passed the SGM test, starting out as 1K CV. So I thought I was good as gold at that point. NOT!!!

When I later checked several of the Pixelboy SGM games that I had previously downloaded, a bunch of them would no longer work. So getting flustered, I just put the version 1.3 core back in, and seeing that all the games now worked again I decided for the time being to call it good and to simply move on.

Well you know how that goes, I wasn't happy and decided to make another attempt. This meant hitting the books so to speak, and going over all the various things I had come across about how the memory banking worked. I also went back and double checked AtariAge member opcode's posts about how to test for the SGM module, and then I stared at the Protel CPLD schematic for a bit more.

All of a sudden it popped out at me that I hadn't truly disabled the 24K ram after all when in 1K mirror mode. After I added a few more gates, version 1.5 was ready to test.
​ 
Once again it passed the SGM Test as a real 1K Colecovision game console, and not as an Adam Computer. So far so good (fingers crossed). Next I started executing SGM enabled games, and one by one they all worked same as when my system was pretending to be an Adam so to speak. This was fantastic news, and confirmed that version 1.5 was working like it was suppose to.

For those that are curious, here is the new version 1.5 Protel CPLD logic schematic.

Getting AtariSoft Games to Behave

This boiled down to figuring out why only 5 AtariSoft games refused to accept keypad input that would allow them to be played. Basically they would get stuck at the screen that would be requesting number of players, skill level, ect..

What was puzzling is why these games worked on an original CV but not on my CV-NUC+, which for all practical purposes appeared to be using a very similar controller interface circuit. Or at least it seemed that way.

Thanks to AtariAge member Falonn's sleuthing, he discovered what was so different about AtariSoft's start-up screen vs. most other games. Apparently Atari felt the need to pay attention to the highest bit of the 74LS541 controller interface chip. This is something not connected with the standard controller, but usually relegated to the quadrature circuit (roller-controller territory). So if that bit isn't zero when reading the controller, the keypad check will fail and the game will not move on no matter how many times you press a key.


When I ran the same test on the CV-NUC+ it had a one instead of a zero at that bit location -- a big no-no as far as AtariSoft was concerned. Well as it turns out I had used a pull-up resistor array across all 8 inputs of the interface chip, whereas Coleco only pulled-up the first 7 bits instead, thus relying on the quadrature circuit to pull that 8th bit down making it a zero.

After a little desoldering and adding a 10K pull-down resistor, all was better, and now I can play AtariSoft's versions of Centipede, Defender, Dig-Dug, Pacman, and Joust -- Success!!!
​

What's With a Case?

As we approach the launch date for a release, I really started thinking about the 3D printed case for this little dude. The original plan was to piggyback on the availability of one of the blank case designs that came out of the Atari 576NUC+ project, thanks to the generosity of AtariAge member Mr Robot. However there was a serious problem with that...

Because of the CV-NUC+MSX Module taking a bit more room, one of the screw posts of the case was getting in the way. To try and move it would have been a major task, and would have also possibly interfered with the symmetry as well. So I started looking at what specifically was causing the issue.

It was the CPLD over in that front corner that was at fault. So why not move it to the back side of the board instead?  And that's what I ended up doing, as simulated in the photo below.

Of course this meant a new layout for that board was needed, but I really felt that it was a worthwhile thing to do. And I'm getting so good at it, that it only took me a day to get it done.

So now with that behind us, I started looking at how tall this case needed to be. To figure that out I placed a partially assembled CV-NUC+ board into one of my Atari 576NUC+ cases, along with the MSX Module plugged in. Surprisingly it'll only need to be 1 cm taller, with an overall height of 6 cm. Pretty compact. And with the screw post clearance problem behind us, it shouldn't be too hard to do the modifications required for this to become a CV-NUC+ case.

Did you see a Mouse?

Yes there will be mice coming with this project, or at least a place to plug one in. Because Roller-Controllers are rarely going to be ok out of the box from the usual sources, I started thinking a while back that a mouse might be the way to go. To this end I also liked the idea of using a USB mouse, and even better one that could be wirelessly connected. Only problem was that I didn't really have the time to invent such a thing from scratch, or at least the actual translation from USB to Quadrature that the CV required. So I did what I always do when presented with such a situation, I start looking for an open source solution on the internet.

Here's what I found: https://github.com/jjmz/Atari-Quadrature-USB-Mouse-Adapter

Although it's original purpose was to interface with an Atari ST or an Amiga, it really gave me the essence of what I needed. So with a little bit of added circuitry (actually quite a bit of added stuff) I was able to make this work on the CV. However the more I played around with it, and started finding and trying different games that would work with it, I began to see the need to have the buttons cover more functions than to simply be fire buttons. So it evolved to the point of using all 3 mouse buttons.

*NOTE: Pressing and holding the Left and Right mouse buttons for about a second or two will send the Asterisk key, which is used in SLITHER as both a pause or game restart key.

Since I was already designing a piggyback plug-in board to allow Roller-Controllers to work, it was a simple matter of just adding the mouse functionality to that same board. Here's a schematic of what it became, all based on the CH554G microcontroller chip and the open source mouse code that gets flashed into it.

Can you Hear Me?

The CV-NUC+MSX Module also contains the two sound chips (SN and AY or Yamaha) so it also needs to contain an audio mixing circuit. I had tried a few different approaches in this regard, one using purely passive components, and another based on a single NPN transistor buffer added to the mix. Well after much fiddling I ended up using the later which also gave me sufficient drive to power un-amplified headphones if so desired. I also ended up adding a series RC filter network into the collector-base feedback loop to better balance the sound between the two chips. All  in all this appears to work very well, and allows for tweaking each sound chip's volume level to obtain an even mix.

So you might have caught that mention of either an AY or Yamaha sound chip. There's a story behind that.

Well I started reading about all the fake AY-3-8910A chips being sold by the Chinese on eBay and AliExpress, and this got me curious about what I had purchased. So I took some acetone and a cotton swab and started rubbing on the top of the chip. Sure enough the swab started to turn black and revealed a Yamaha YM2149F label underneath. I had gotten a FAKE chip!

I then proceeded to do the same to all 6 chips I had purchased, with two of those coming from a different seller. They were all Yamaha chips underneath. Well all except for one, which was an AY-3-8910 instead of an AY-3-8910A  (they had substituted an earlier version AY chip).

Getting a Yamaha YM2149F really isn't a bad deal, since it was a licensed clone of the General Instruments/Microchip AY-3-8910A, and for all practical purposes it works the same. This is also the same sound chip that the Atari ST used.

So now I started thinking what do I get if I order a Yamaha YM2149F instead -- will I get the genuine item?  The answer to that will get covered in a follow up blog post.

Is This Thing Ever going to Get Launched?

It will, but realistically I think we are still at least a month to a month and a half away from that day if all goes as planned. But you probably know the old saying about the best laid plans...

Another small run of sample boards still needs to happen, including the main board to verify that all is ok after removing some unneeded components. And you know why I have to do this, because no change is ever simple and fool proof, and I don't want to get bit because I failed to double check something

Stay tuned for more to come, and to get even more info check out .the AtariAge Forums CV-NUC+ Thread.

- Michael

Before I can truly finalize the system and have another set of sample boards made, I wanted to address a problem I was seeing in the video output where a very faint color snow was visible in the background. This also seemed to relate to the method by which I was conditioning the subcarrier output of the LM1889 Color Encoder chip with a simple one transistor emitter follower buffer. There was no inherit gain to this stage, so I had to resort to some trickery with an inline inductor to even have a somewhat reasonable color burst signal, although it was half of what it really should have been. Later I discovered that the inductor was responsible for the noise I was seeing in the chroma signal, and subsequently in the background of the image.

So back to the drawing board it was, with the that emitter follower circuit being changed out for amplification instead. Luckily this didn't require any more components than what I was already using, and I was able to get rid of the inductor at the same time (win-win).

Here's a look at the entire video circuit as it now stands, shown in two parts to better fit the page.

The first part converts the TMS9128 VDP (not shown) R-Y and B-Y color difference signals into a single 3.58 Mhz subcarrier output suitable for the S-Video chrominance signal via the LM1889 color encoder chip, although that chip doesn't provide enough drive on its own to feed into a standard monitor input (we'll address that in part 2). In this particular application the LM1889 is only being used for its color encoder aspect which is half of its normal purpose. It also has an RF modulator section which was utilized by the original Colecovision game console as the sole means of connecting a TV.

The second part of the schematic shows the final signal conditioning and driver circuit going right out to the Atari 8-bit compatible audio/video jack, with the FMS6400 outputting both S-Video and Composite Video. I chose to mimic the Atari connector and pin-out since there are standard cables already available with this in mind.
​

​As can be seen, transistor Q3 is now serving to amplify the subcarrier output of the LM1889 to a level suitable for injection into the video buffer/combiner FMS6400 chip,

​With the proper chroma amplification now in place, the color burst is at the correct level for standard video. This can be seen in the captured image of the composite video output being viewed on my hand-held O-Scope.

For this test, the composite output was  terminated with a 75 ohm resistor to ground to mimic what would be the case for a video monitor if it were connected instead.

Normally the color burst signal is suppose to be at the same relative voltage swing as the sync pulse (350-400 mV), which we now appear to be doing thanks to the added amplification of the new Q3 circuit. The output of the LM1889 just wasn't sufficient with buffering only being applied. I think with these changes we're good to go on this aspect. and can now call it a day.

​So after making the modifications, I put Donkey Kong Jr up on my VIZIO S-Video monitor and captured this un-retouched screen shot with my camera.

Captured image from 19" VIZIO LCD TV, via the S-Video input (taken with a Canon EOS Rebel T7)...

Finally the black background is flawless, with no evidence of noise or snow what-so-ever. And the detail and color saturation in the image are quite good at this point.

In order to get such fully saturated colors I did need to boost the color setting on my VIZIO for it to appear as it does in S-Video mode on the LCD screen. However all the other levels were set to 50 out of 100, being the default mid-point settings of that monitor. Later when I fed the composite output to my CRT monitor the color saturation was perfectly fine at the default settings for that particular monitor. I think this is partly due to the differences between how the LCD displays information vs. the CRT. A CRT display just tends to be more vibrant when compared to early 2000's LCD monitors like the one I'm using.

 Update February 2nd 2023

I connected the S-Video output into a cheapo HDMI converter I picked up off of AliExpress and was literally blown away by the result when viewed on my large screen HDTV.

Captured image from 55" LG HDTV, via the HDMI input (taken with a Canon EOS Rebel T7)...

I'm back after assembling, testing, modifying, and scratching my head. So much has happened since my last blog post. First off the CPLD being used for what I'll now call the MSX Enhanced Memory & Sound Module (name got changed to protect the innocent) didn't work on the first power-up. This had me very worried since it was my first go around at designing with a CPLD. However it wasn't long before it started working correctly, only taking a couple of tweaks to make it all better and then passing all the tests with flying colors.

So what is this MSX Module all about?
It takes the stock Colecovision memory configuration from a measly 1K up to a whopping 32K, and it throws in a second programmable sound generator (PSG), giving a total of 6 independent voices when combined with the original sound chip. However it can be put back into a stock 1K mirrored RAM mode with a simple register change, and the extra sound chip won't activate unless needed.

Having this new configuration in play makes it compatible with games that were developed for the MSX and SX platforms, making for very easy ports to the Colecovision system. This also means that it can take advantage of games created for the Super Game Module by AtariAge member opcode.

The ATF1500A CPLD (optional ATF1502ALS)  which acts like a Memory Management Unit (MMU), makes it possible to eliminate at least half a dozen 74XXX series logic chips, and allows for relatively simple CPLD core changes for altering any of the decoding characteristics. For this aspect, I utilized Protel 99 SE to design the inner workings of the CPLD, using it's schematic capture to PLD source code generator, thus keeping me in a graphical design environment not unlike what I use in PCB design.

Here's a peek into what just such a schematic looks like for eventual translation to PLD code. I believe this will be the final version for the project. Wow not too different than an actual physical component schematic!

What Happened Next?
With the proper CPLD in play, the system worked, and worked well. And thanks to AtariAge member PixelBoy, I was able to test right off the bat 40+ SGM/MSX derived compatible games. Of which most all worked, with only one exception turning out to be an issue with being run from an Atarimax Ultimate SD Cart instead of a real cart.

There were also a handful of other game prototypes that had issues, but for the most part compatibility was very good across the board.

However all was not good, and unfortunately I was seeing noise in my video output, which I temporarily fixed by substituting a linear 5V regulator for the switching one that I had spec'd. Of course this produced way too much heat and now required a large heat sink to disperse that extra heat. Good news is this got solved today when I found a very low noise version of a TO220 switching regulator, that actually turned out to be cheaper than the previous noisy one.

QUAD Board Problems
This is a board that fills in the missing circuits for using a quadrature based roller-controller, and better yet, also supports an alternative in a USB Mouse (wireless capable). Unfortunately I had screwed up with the Mouse USB port, having the power polarity reversed. I also had screwed up the orientation of the left and right mouse buttons vs. what a real controller has. So after some trace cutting and rewiring, it worked like a charm.

Then I discovered the game Armageddon, which is very much like Missile Command, having 3 missile silos protecting the city from attack. This game requires a roller-controller for targeting where the missiles will go when launched. However it takes 3 buttons from that controller to launch from all 3 missile silos, and I only had two of those available on my mouse, thus leaving one silo inoperative.

With the help of AtariAge member Chart45 we discovered that the middle mouse button would also pull down one of the unused I/O pins on the CH554, a microcontroller being used to translate the USB Mouse into something that the Colecovision can recognize. This middle mouse button would fill in for the missing button required to launch missiles from the formally inactive 3rd silo. But there was a slight problem, and that had to do with an inexplicable delay after pressing the middle mouse button before you would see a response on the I/O line, which was simply not acceptable. We are currently trying to solve this issue, along with the help of Chart45's brother who is a far better coder than either of us.

Changes are in the Works
There will be a 2nd revision of most all the boards associated with this project, and subsequently a 2nd order will be placed for new sample boards. This is looking to happen about 3-4 weeks from now once all the new aspects and fixes have been proven out. So stay tuned for more news to come on this project.

- Michael

It's been awhile since I've added any blog entries, and all I can say to that is sometimes life gets busy, and this is especially true around the holidays.

So what have I been up to? Quite a bit actually...

A few months back I got off on a tangent from my usual Atari stuff, and headed down the Colecovision path instead. Reason being is that I missed the boat on buying one of these in 1982, but had always intended to do so. Unfortunately I lacked the necessary funds at the time. So nostalgia kicked in and I found myself on an Adam/Colecovision forum at AtariAge. It's there where I discovered two alternative CV motherboards were either in process, or apparently been completed. This got the gears turning in my brain...

So per usual I started thinking how could I do this even smaller, possibly even 576NUC+ size.

To get this to happen I knew I needed to first understand how the CV was built, and to this end I discovered a great CV Schematic created by AtariAge member ChildOfCv. Next I needed a real Colecovision console to run experiments on -- enter eBay.

I picked up this console in very good condition for $100, and it came with everything you see here. the only problem being that it didn't work when I received it, which the seller had mentioned in the listing.

So no problem, I figured this would aid me in my quest to understand how a CV actually works by making me troubleshoot the dead one I just got.

Turns out that several of the video DRAM chips were bad, so I needed to change them. However that was easier said than done since all the chips were soldered in place. But after a marathon desoldering session (there are eight individual 16Kx1-bit DRAMs being used for video memory), I replaced the chips with sockets, and not having the 16Kx1 DRAMS on hand, I substituted some left over 64Kx1 chips from an Atari 1200XL. Next I made sure to do the board mods to eliminate the -5V and 12V that powered the original DRAMS, which not only wasn't needed anymore, but would have been destructive to the new 5V only DRAMs.

After the repairs were completed I powered it up and got crappy RF out that at least showed that the console was now working. But there was still a problem that was causing very erratic video output, and the system would occasionally hang. This was made even worse by touching the power switch or slightly flexing the PCB. Turns out I just got introduced to another common failure in a CV, and that is the slide power switch contacts being dirty. Since it switches 2 different power signals (+5V and +12V), when it starts getting flaky it does some very crazy things to the operation of the system. The usual fix is to spray it with DeoxIT and then rapidly switch it back and forth several times, but this failed to completely work for me (although it did help a tiny bit). The better fix is to completely disassemble and clean the switch contacts, but I was too impatient to do that and instead soldered jumpers, and then just plugged the power adapter into a plug strip and used it's switch to control power. This worked, and the system was now stable.

Next problem was to have something other than RF for the video output. Looking around the CV forums I discovered that a simple mod could be done to get composite video out of the console, documented by none other than Ben Heck. So I did that, and got a much better picture. However what I really wanted was S-Video for an even better result. This was no easy task to undertake at first glance, since the output from the video chip is R-Y, B-Y, and Luma (+sync). Basically Component video. Component is good, but I really wanted S-Video since many of my monitors support that.

So I dived in and discovered how that might be done. Fortunately for me, the CV's LM1889 RF modulator chip also encodes a Chroma (color sub-carrier) signal from both the R-Y and B-Y signals before passing them to the actual modulator section of the chip, and this is broken out on pin-13. It became a fairly simple matter to intercept that Chroma output before it was mixed with the Luma, and feed that into a video buffer chip (FMS6400), along with the separate Luma. Now I had high quality S-Video which looked really nice!

Onward and Upward

So now that we had a working console, it was time to move on to the original product idea, that being something I will call the CV-NUC+. This would be made small enough (4.5"x4.5") to fit into a slightly modded 576NUC+ 3D printed case. So as to be expected I made a few false starts in this endeavor, and of course things got more complicated as feature creep took over. But eventually the overall design started to gel and take shape.

Here's what the final form of the Main PCB design looks like today.

So this ends Part 1 -- stay tuned for the adventure to continue, where I'll delve into the design of the individual boards that make up this system.

- Michael