This project is suffering from a bit of feature creep, but it's all good and desirable stuff that's being added (trust me).

So because of also wanting to be able to incorporate at least the networking aspect of FujiNet into the project, a couple of extra headers were added, and a FujiNet Plug-In Module has been designed.

The PCB mock-up of this new FujiNet Module can be seen to the right. With the real thing nearly ready to have the gerbers sent off to the board manufacturer to get some sample boards made.

This is meant to plug in on the right of the A8Pico Cart module of the NUCplus4 daughter board. Taking advantage of the 576NUC+ internal SIO header, and a couple of small 2 pin headers on each of the bottom corners to stabilize the piggyback aspect of this module.

Everything from a WiFi aspect has been retained, so accessing TNFS servers, assigning remote files to virtual drives, and doing wireless printing to the PC is fully supported. However unlike the regular FujiNet implementations, SD Card access is separate being handled by the SDrive-ng.

For the firmware update aspect I chose to use a pre-made FTDI based RS232 Serial to USB-C board from AliExpress. Its cheap at just a tad over $3 (that price includes shipping), and has all the required signals broken out, including the ones that allow for Auto Program mode.

Being USB-C mimics the connector on the A8Pico Cart board, so only one cable need be stocked in order to load files to the A8Pico Cart, or to update firmware on either that or the FujiNet.

Individual physical switches have been eliminated for control of either the FujiNet, SDrive, or the A8Pico Cart, making use of the keyboard PS/2 signals broken out on the internal SIO header of the 576NUC+. This combined with individual PIC12F629 8-pin DIP 'slave' micro-controller chips on both the NUCplus4 daughter board and FujiNet module, allows all control to be done via the PS/2 keyboard. This method also allows for monitoring by the 'master' PIC16F1847 chip on the 576NUC+ so that certain actions can be modified and/or the present state displayed upon entering a key shortcut sequence. Having all actions controlled and coordinated by the single PS/2 keyboard, lets the 3D printed enclosure be much simpler and have far fewer holes, or any need for identification labels.

Speaking of having a PIC12629 on the NUCplus4 daughter board, yes that required a new board layout bringing it up to revision level 1.5.

I think that'll do it for this blog post. More to come...

- Michael

LINK to Previous Post.

AtariAge member electrotrains released his A8Pico Cart Project a few days ago on GitHub, and I've been busy integrating that into my design. Here's where things are at presently...

Everything is now 100% routed.

I made a lot of changes on the component placement in the PCB layout, making it far more conducive to routing traces between components. This also altered the board shape slightly.

On the R-Time 8 aspect I changed to a larger battery same as was used on the original ICD variant back in the day (CR2430). I also have the power for this and the SDrive as an 'Always ON' situation taken from the 576NUC+ 5V Stand-By power connection, which is available from the internal SIO header. This means that so long as the NUC is plugged into wall power, irrelevant of whether the 576NUC+ is turned on, the R-Time 8 will run from the 5V power supply and not from its battery thus greatly extending the battery life. I wouldn't be surprised if the battery lasts for at least a decade with this setup.

Because the SDrive also gets its power in a similar aspect, drive assignments should be retained between power cycles.

Over the next couple of days I'll be double checking the PCB layout and schematics, and if all looks solid I'll be pressing the BUY button at JLCPCB soon after. Then when those sample boards arrive we'll see how or if I screwed up on something - always exciting.

-Michael

Update 9/13/2023:  I never pressed the buy button on this board version. After running some breadboard tests, and because of discussions in the A8Pico Cart AtariAge thread about protection circuits, and a change in direction on the SDrive aspect, everything changed. So much so, that an entirely different PCB layout was required, with the first sample PCB based upon this change having now been manufactured and awaiting assembly and test.

LINK to Previous Post

Robin Edwards (electrotrains at AtariAge) has been at it again, and recently starting talking about an entirely new version of the 8-bit UNO Cart, only this time based upon a Chinese clone of the Raspberry Pi Pico. On this go around it has no removable media such as what the original UNO Cart utilized via its micro-SD Card, and instead it stores its files to an onboard 16MB of non-volatile Flash RAM, updated via USB.

Note: The Chinese Pico Clone is not a drop in for a real Pi Pico, having a different pin-out, as well as more I/O and more Flash RAM. The clone was required for this A8 version.

So I started thinking (always a dangerous thing), and decided to make something akin to an All-In-One daughter board module for the 576NUC+ project which would incorporate this new Pico Cart idea, along with several other very useful peripherals.

And here's a sneak peek as to what that may look like...

Currently I've assigned the moniker RPSX to it, which stands for the 4 main aspects contained within this module.

• R = R-Time 8
• P = Pico Cart
• S = SDrive
• X = XRAM (1024K extended RAM)

The Pico Cart does have ATR capability, but just like it's UNO Cart cousin this has some limitations, such as not being able to launch a CAR and an ATR at the same time. So it rules out doing something like launching Basic XE as a virtual banked cartridge and still being able to load and save Basic XE source files to and from the built-in file space. Hence the reason for also incorporating the SDrive.

BTW, the default 576NUC+ platform has absolutely no inherent banked cartridge support what-so-ever.

And while I was at it, I decided to give it the full 1MB of RAM, as well as a battery backed real time clock, making this a very well rounded upgrade for the 576NUC+.

Now on the surface it may look like I have this all figured out, but I presently don't have a clue as to what I/O pin goes to what on the Pico board until such time that the A8Pico Cart documentation gets released to the public, something that I have no idea of when that may happen.

Anyway stay tuned, and hopefully we'll see this project continue to come together.

- Michael

The design has finally been completed after about 9 months of some very challenging development work. And as of one week ago the final pieces needed to manufacture this system got released to Marlin over at The Brewing Academy, with him and I launching our CV-NUC+ webpages on the same day.

During the development phase of this project I learned a lot about CPLD programming, 3D printing. And also the technical as well as historical aspects of the ColecoVision Game Console and Coleco the company during this pursuit.

Things like Coleco starting out as a leather goods company, then switching to portable swimming pools, and then game systems with some early handheld and pong variants was all new info to me.

Later I learned about the aggressive R&D that went into the creation of the ColecoVision and Adam Computer Systems. And of course all the future products that were being dreamed of, but never came to pass, much of it the result of the 1983 North America Game Crash. Shades of Atari.

So are we Really Done?
Yeah it's kinda bittersweet, but this marks the end of the development aspect for me at least. In many ways that's good. The people that have anxiously been waiting for this, will now have the chance to own one either through building it themselves or buying a pre-assembled one from TBA. For me the excitement that comes through creation has now begun to rapidly fade into the distance. But it's all good.

There will still be a few things I will explore, such as having a resin printed case made at some point to see what that would look like. And who knows I might dream up an upgrade or two for this new little game system, but don't hold your breathe on that one because my mind is presently blank as to what that could possibly be.

Stay Tuned for more Assembly Tips and Tricks...
I'm sure as time goes on and the DIY people try their hand at putting one of these together there will inevidently be questions that'll come up. Some of those will get answered in the AtariAge forums, some might get talked about in the assembly manual in the download section, and some topics might get their own blog posts, so check back here from time to time.

That's it for now -- Enjoy!!!

- Michael

Which Sound Chip gets used for the enhanced MSX compatible audio in the CV-NUC+MSX Module?

When this project first started out it was going to be the General Instruments/Microchip AY-3-8910 which was originally created by a company called General Instruments in 1978.

It was widely used in arcade machines in the early 80's, and was also integrated into the MSX and ZX Spectrum home computers. And two of the size reduced versions made their way into the Mockingboard for Apple II computers.

Later in 1987 General Instruments spun off a new company called Microchip Technology which started producing the chip for a couple more years under its brand name, so it's common to see the chip with either GI or Microchip markings.

Around the mid 80's, it became available from Yamaha as the YM2149F under a license agreement with General Instruments. Although Yamaha made a few changes, one being a selectable clock divider which could allow it to operate from a 4 Mhz system clock, and they also added additional resolution in the internal volume envelope tables. This last part plays a roll in our decision of which chip to use.

Probably due to the Atari ST and MSX2 computers using the YM2149F chip as their main sound chip, as well as being the last such chip that was still in production in the early 90's, there appears to be quite a large supply of these being sold on the surplus market. Whereas the AY-3-8910 is in extremely short supply, and is often counterfeited, using a remarked YM2149F in its place (referenced in Part 4).

Because that counterfeiting is so common place, you are more likely to get a remarked YM2149F instead of an AY-3-8910 when purchasing the AY chip. And this is important since there will be a marked difference in how 'hot' the audio output will be when compared, with the AY chip being louder out of the gate due to the lower resolution audio control when interfaced as an AY chip.

So a decision was made to spec the CV-NUC+MSX Module's 2nd sound chip as the Yamaha YM2149F since 9 times out of 10 that is indeed what you will get when purchasing from the surplus market (there are arcade parts suppliers that still carry genuine AY chips, but you'll pay quite a bit to get one). Sticking with the YM chip will insure consistent audio output utilizing the same audio processing circuit, with no need to have any configuration adjustments. And it also consumes half the power as compared to the AY-3-8910.

So on all CV-NUC+MSX production boards only the YM2149F will be marked on the silk screen as seen below. And this is the chip that should be purchased, which appears to be available from utsource at a reasonable price.

- Michael

Let's talk about the Case

The case for this cute little Colecovision clone has now been completed. And as Steve Jobs once said when he unveiled the Macintosh at the 1984 launch event, "insanely great" kinda fits how it turned out. I don't think I could've expected or gotten a better outcome.

I know it doesn't look at all like an original Colecovision, but then again this isn't your Grandma's game console. It's the 21st Century Baby!

The basis of this case design was the Atari 576NUC+ having the same footprint and only being 10 CM higher.

I cannot thank AtariAge member Mr Robot (Steve Boswell) enough for creating such a beautiful design, and also being kind enough to put the STL files in the public domain for others to download. Of course when I release this unit I will be sure to do the same.

Baby Steps

Since the generic design files that Steve released was essentially a blank slate, not having any holes other than the vents. I had to import his STL files into Tinkercad and get to work. So first order of business was to purchase a 3D Printer so that I could test my changes as I went. Not wanting to spend a lot of money on this aspect, I headed over to eBay and came across a listing for what appeared to be customer returned Anycubic Kobra Plus printers going for only $190 shipped. Although a bit risky I ended up purchasing one of these units.

A few days later it arrived packaged in what appeared to be its original box with all the foam inserts to cushion the individual pieces. And best part of all it still looked brand new.

About 2 hours later I had it unpacked, assembled, and ready to print -- or so I thought. Turns out it's Hot End was malfunctioning, but for $25 I ordered a replacement from the Anycubic website. Swapping out the new hot end for the defective one was extremely easy, and with that done the printer was now fully operational. Even factoring in having to replace a part and an ongoing Kobra Plus sale, I still saved $165 opting for this customer return unit vs. buying a new printer. So money well spent as far as I was concerned and I lucked out that something major wasn't wrong with the unit.

So next on the list was to integrate the required changes specific to the CV-NUC+ into the blank STL case design. This ended up taking just as long as I thought it would, meaning it wasn't easy. But after all was said and done I think it turned out quite well. And as it came together, I decided to do two variations of the Lid, one with a built-in keypad and one without.

The idea behind the integrated keypad is to allow non-standard joystick controllers to be used such as those from an Atari or Sega Genesis. Since these particular controllers don't have an integral keypad, the built-in keypad could provide that missing aspect so that games could be started and number of players could be selected. The built-in keypad is scanned as controller #1, which works in a majority of situations. However there are some exceptions, such as Turbo that only recognizes a keypad on port #2. In that particular case we'll still unfortunately need a keypad controller to be present in port #2 to facilitate starting the game.

Anyway I'll leave it up to the end user to decide which lid to use for their CV-NUC+. With both lid versions to be included in the STL upload coming down the road. And for the keypad version, you will require a complete CV-KEYPAD Module as well.

You'll Also Need Some Other Stuff

I don't plan on doing a formal BOM for the case, but suffice it to say there will need to be a few fasteners to tie it all together, and some feet to give it stability, so I'll briefly try to describe what is required in this blog post.

To make the overall case a little bit more robust for assembly and disassembly, the case Lid was designed with Heat Set Threaded Brass Inserts in mind. These are typically pressed into place using the tip of a hot soldering iron.

Something Screwy Going On

As for screws to hold the lid to the base, it looks like M3 x 35mm long pan heads would likely be the ticket in either Stainless Steel (SST) or nickel plated steel.

In order to mount the PCB board to the base via the holes in the Cartridge Edge Card Socket, I used 4-40 x 3/4" long SST flat heads that I happened to have on hand, with two KEPS Nuts to secure it. Of course the metric equivalent could likely be substituted (M3 x 20mm).

To secure the keypad to the Lid, I used four 2-56 x 3/8" long SST flat head screws and standard nuts to secure it (with a dab of Locktite). Once again this could probably have metric equivalents substituted (M2 x 10mm). And although I used flat heads, this did require a countersink tool to create the chamfer first. Pan heads would probably be a better way to go, not requiring any additional prep.

As you can probably tell by now, nothing is truly set in stone when it comes to the fasteners.


Don't Forget the Feet

Now you don't want your little NUC to slide off the table or scratch it's bottom, so you gotta put some self adhesive feet, or sometimes called bumpers underneath its base.

I picked mine up from a local Home Depot Hardware Store, made by a company called EverBilt (P/N: 158437), but they can also be ordered online. I got the clear 3/8" diameter ones which are supposed to not mar or discolor the surface they are sitting on, and being self adhesive makes it super easy to apply them to the case.

BTW, There Could be a Burr or Two

Depending upon your printer, there can be a burr that gets created on each end of the extrusion towards the front of the base that regulates how far forward the PCB can sit behind the front panel. If that burr isn't removed (I use an Xacto to trim it) it can interfere with getting the back panel of the case to fit.

So if you find yourself fighting with getting that panel in place, or you have succeeded but there is a definite outward bow, then you got burrs my friend and they need to be removed.


Well I think this is a good place to end this post. However there is a lot more to come, so stay tuned for the next blog post on this miniature Colecovision system.

- Michael

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