All Categories

CV-NUC+ a ColecoVision Mini Game Console (Part 4)

3/10/2023

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.

Before

After

SGM Test as 1K Colecovision with SGM Capability

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.

Click On Image To Enlarge

Joystick Test 2 - Keypad (2014) (Nitrofurano).rom

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.

New CV-NUC+MSX PCB Top Layout

New CV-NUC+MSX PCB Bottom Layout

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.

GAME	LEFT-Button	MIDDLE-Button	RIGHT-Button
SLITHER*	FIRE-UP	FIRE-DOWN	FIRE-UP
ARMAGEDDON	LEFT-MISSILE	MIDDLE-MISSILE	RIGHT-MISSILE

*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.

Click On Image To Enlarge

FAKE AY-3-8910A

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

CV-NUC+ a ColecoVision Mini Game Console (Part 3)

1/29/2023

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.

YPbPr Translation from the TMS9128 VDP chip's R-Y and B-Y outputs to a 3.58 Mhz subcarrier

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.

S-Video/Composite Driver Circuit

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)...

Click on Image to Enlarge

So I think I'm done monkeying around with the video (it's probably about time).

Stay tuned for Part 4 of this series where I will delve into some audio mixing changes that got implemented, some USB mouse discoveries, and hopefully a demonstration of what should be the final boards for this project.

- Michael

CV-NUC+ a ColecoVision Mini Game Console (Part 2)

1/20/2023

Tests like an ADAM having an AY sound chip

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!

Click Image to Enlarge

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

CV-NUC+ a ColecoVision Mini Game Console (Part 1)

12/21/2022

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!

Colecovision S-Video Circuit Diagram

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

RLC-4000 Heat Load Controller Power Board Testing

8/10/2022

RLC-4000 Power Board (middle rear mounted) - Click Image to Enlarge -

I finally found a bit of time to do a quick lash-up of the RLC-4000's Power Board with most of the other devices that it'll ultimately be connected to. Don't mind the rat's nest of wires, this is temporary, and only meant for a quick test.

>>> Link to First Part in this Series

The Power Board serves as a combination of a multi-output PSU and a relay board. Powering the needs of the 576NUC+ and the LCD monitor display via an unregulated 12 VDC supply, also supplies 230 VAC step down to 115 VAC for the watt transducer's instrumentation, and provides low voltage AC for the proportional AC power control module.

Beyond this it encompasses the power control aspects of the system (RLC-4000 System Power On/Off, Load Power On/Off, and Cooling Fan On/Off).

I was curious if the transformer would be able to handle all the various loads being demanded of it without over heating. So after hooking up all the individual loads and powering on all the relays, I left it sitting in this state for several hours without any fan cooling.

I'm happy to say it did very well, but it was fairly warm to the touch. However in the final application there will be a good amount of air flow through the cabinet via the cooling fan, so my feeling is that there shouldn't be any problems with heat.

In order to really bring this project together, does require funding some additional stuff such as the front and rear custom aluminum panels which carry a hefty price tag that I'm not yet in the position to cover. So although today's post is a tease of sorts, I do intend to finish this project by the end of the year.

This project is kinda like the long wait for the StarShip's first orbital flight.

Stay tuned for more to come.
- Michael

My 1200XL has a Multiple Personality Disorder (Part 2)

5/1/2022

Today I'll be talking about how to operate this system, since Part 1 already went in depth on what hardware and modifications were required.

Below is a table covering basic operation of the system in order to select what OS you want active, and if desired, what Language SLOT you want selected as well.

As can be seen the original L1 and L2 LEDs have been reassigned to indicate whether a SLOT or Cartridge is inserted (L1), or what OS is in play (L2). When SHIFT is added to any one of the selection hot keys, it simply modifies which OS is to be used, by selecting the 2nd bank of the OS EEPROM, with the first bank holding the default OS.

Note: The last selection that you make is stored in non-volatile EEPROM memory, and restored upon the next power-up of the system - resuming where you left off.

SELECT	STOCK 1200XL Keyboard	Optional PS/2 Keyboard	LED L1	LED L2
SLOT 1 + OS 1	F1	ALT+F1	ON	ON
SLOT 2 + OS 1	F2	ALT+F2	ON	ON
SLOT 3 + OS 1	F3	ALT+F3	ON	ON
SLOT 4 + OS1	F4	ALT+F4	ON	ON
NO SLOT + OS 1	OPTION+F1	ALT+ESC	OFF	ON
+ OS 2	ADD SHIFT	ADD SHIFT	NO CHANGE	OFF

To make this concept a bit easier to understand, I did a short demonstration video of the system in action.

Keep in mind that any two Atari 8-Bit OS variants can be used. So for instance you could have OmniView 80 in one bank and the stock XL/XE in the other. Same goes for the Language EPROM, where any combination of four 8K language, application, and/or games could be pre-programmed.

This is what I have in my test EPROMS at the moment.

32K Dual OS (27C256 EPROM)

OS 1 = HSIO patched XL/XE (default)
OS 2 = Stock XL/XE (selected with SHIFT) I changed this to OmniMon XL, and it works great!

32K Quad Language (27C256 EPROM)

SLOT 1 = BASIC RevC
SLOT 2 = Altirra BASIC
SLOT 3 = Assembler/Editor
SLOT 4 = SpeedScript

Each time a new selection is made, a Cold Restart (similar to Bob Woolley's FREEZER) is initiated in order to reboot into the new configuration without requiring a power cycle of the computer. Whereas the SIO 5V/Ready signal is power cycled to reboot something like an SDrive sitting on that serial bus.

This is all perfectly timed, and happens automatically in the background when changing selections.

I think that covers it for today, but stay tuned, because there might be a Part 3 if I decide to get into how the code in the TKII-PB1200's PIC chip performs some of this magic.

- Michael

My 1200XL has a Multiple Personality Disorder (Part 1)

4/29/2022

It all started out with me wanting to do a few updates to a 1200XL that Bob Woolley had given me in 2015 to get me back up to speed, since I no longer had any Atari 8-bit computers at the time.

And because of many other projects competing for my attention, that poor 1200XL had been sitting in a box under my workbench for the last couple of years, with the only mod being a TK-II Pokey piggyback board which I had installed when the stock keyboard started getting flaky.

So I guess it was about two months ago that I pulled it out of the box and installed a new at the time internal SDrive-Simple board, which actually came out very nice with an almost invisible SD card slot in the rear being just below the overhang in the top part of the case. After playing around with it for a bit, I started reading an older post on AtariAge about converting from the stock 1200XL OS over to an 800XL OS, and incorporating internal Basic. This sounded cool, and is why my Multiple Personality adventure began.

The instructions I found online...

add_800xl_os_and_basic_to_1200xl.pdf
File Size:	29 kb
File Type:	pdf

Download File

Initially I followed the instructions as written, but with the only EPROMs I had on hand being 32 Kbyte (27C256), I had a lot of extra space that would inevitably get wasted. 32K was four times what I needed for Basic, and twice what was required for the OS. So this got me thinking... why not use all that extra space to have four different 8K languages and/or applications, and two different OS variants. And to make the selection of these a bit more sophisticated then merely some physical switches, why not make a special version of the TK-II that could make these selections via keyboard control. The challenge was to bring this all together, from both a hardware and firmware aspect.

So I designed a new Pokey piggyback board that would break-out some of the PIC's I/O that could be used for banking the ROMs, and to execute a Cold Restart when changing selections, thus eliminating the need to cycle power in order to reboot with the new configuration. On the first iteration of this new TK-II board I had one left over I/O bit, but as the experiments progressed I quickly realized that a simple Cold Restart was not going to be enough to have the SDrive also reboot, so that extra I/O bit got used for switching a MOSFET ON and OFF to control power for the SIO 5V/Ready line.

Here's what the final form of the new TKII-PB1200 board looks like both schematically and graphically...

tkii-pb1200_v1.1_schema.pdf
File Size:	31 kb
File Type:	pdf

Download File

TOP VIEW

BOTTOM VIEW

ASSEMBLED BOARD

To put this all into play required extensive modifications to the 1200XL, which I have put together a pictorial to show the changes. Please note that there was limited room to label the TKII-PB1200's header pins, so I opted for two letter IDs, and have used these same IDs in the pictorial showing where the TKII-PB1200's header wires go.

First order of business was to substitute 28 Pin sockets for the original 24 pin ones which had held the split two part 1200XL OS, as well as some 'W' jumper rearrangement to make it address the new larger EPROMs. The trace cut below is not part of the original 800XL conversion, and was done to facilitate banking of the multi-language EPROM. And for the same reason, there are some additional trace cuts done on the bottom side between pin 27 and pin 28 of both EPROMS.

Here you see the new TKII-PB1200 board installed into Pokey's socket, with the Pokey piggybacking on top.

Console and Reset switch connections.

The next series of pictures will map out the additional trace cuts and jumper wires to fully bring this into reality.

The trace cut next to U17 severs the connection of the GTIA PIN 11 (TRiG3 input) to RD5 on the cartridge port so that we can separately signal the GTIA that a cart has been changed as part of our Cold Restart function (thank you Bob Woolley for your FREEZER article).

Here you can see the connection of the Bank Selection bits (B0-B2) that will determine which 8K SLOT of the language EPROM and which 16K OS will be in play. Also we can see the RD5 input going over to the TKII-PB1200 via the brown wire. This will tell the TKII-PB1200's PIC chip whether a real cart has been inserted or not so that it can take appropriate action when executing a Cold Restart.

Below can be seen a light green Jumper wire going from pin 18 on the 800XL MMU (U14) over to pin 11 on the PIA chip (U23). This allows Basic, or in our case the language SLOTs, to be enabled.

Pin 23 on the CPU is A13 which needs to be routed over to the OS ROM (U13) via one of the pads from the removed W6 jumper.

UPDATE 4-30-2022: Added the blue jumper wire between the Dual OS socket (U13) and pin 13 of the PIA (U23) to enable the L2 LED to indicate when the primary OS (OS 1) is selected.

This is the 2nd part of our Cold Restart circuit coming from the TKII-PB1200's PIC chip via the orange wire, and feeding into the TRiG3 input (pin 11) on the GTIA chip (U19).

And finally we remove resistor R63 which is no longer needed and attach the green wire coming from the TKII-PB1200 board to allow it to control the SIO 5V supply.

Since I just happened to have a spare UAV, Sophia RevC, and a RAMBO XL, I went ahead and installed them as well. This system will now become one of my daily drivers, no longer relegated to sitting in a box.

Because I also needed the flaky 1200XL stock keyboard to work reliably once again, I purchased and installed the Best Electronics 1200XL replacement mylar kit (P/N: CB103156). It worked like a charm! And basically it was as easy as peeling off the old membrane, cleaning the PCB with acetone, burnishing the contact pads with the anti-tarnish paper that's provided in the kit, placing the thin PCB and the new mylar (also in the kit), aligning all of this with the keyboard side, and screwing in all of those very tiny securing screws.

And for those that may be interested, here are the details on the RAMBO XL installation.

I installed a right angle header on the RAMBO XL board for the PBx connections, and luckily it just cleared the Sophia board, although I am using an additional machine pin socket on both devices to get some extra clearance above the surrounding components.

The RAMBO XL board takes the place of U10 (74LS158), plugging into the same socket that the IC was removed from.

Notice the position of the shorting block on the RAMBO XL board for proper 1200XL configuration.

Here we see the other end of the PBx connections to the PIA (U23) chip. The PIA was first removed, the 12-16 pins were bent up, and then the PIA gets plugged back into it's socket. Afterwards the wire ends are soldered to the bent up pins in the order shown below.

And here's where I chose to mount Sophia's DVI connector, plus take note of the switching regulator modules in place of the original linear regulators that ran very hot, thus requiring a large heat sink that we no longer need anymore thanks to the very cool running switching regulators.

OverView of Completed Upgrades

Click on Image to Enlarge

Stay tuned for Part 2 of this project, where I'll describe how the TKII-PB1200 board allows control of the OS and Language SLOT selection via both an external PS/2 keyboard, or through the use of the internal stock 1200XL keyboard's function keys (no PS/2 keyboard required).

- Michael

RLC-4000 Heat Load Controller (576NUC+ based)

12/27/2021

This begins my first posting on an industrial based application for my home brew 576NUC+ Atari computer system. A very unique "Real World" application for this equally unique Atari 8-bit computer.

Background

Sometime between 2005-2006 I was approached by a company doing service work on industrial cryogenic chillers used for what was called water vapor cryopumping of vacuum chambers. These chillers acted like a selective pump for water vapor inside the chamber, by freezing it to a cryocoil, and thus trapping it in place (it would no longer be floating around inside the chamber). These vacuum chambers would be used for an assortment of applications, including environmental simulation, semiconductor fabrication of IC Chips, decorative coatings, and various other coating applications.

When servicing these units, it required having the means to subject them to a specific heat load in order to match a given customer's application. Anywhere from 90 watts up to 3600 watts of applied heat was necessary (imagine a very big electric space heater). So they wanted me to design and build them a heat load controller that they could use for testing these cryo-chillers under a simulated condition. Below you can see a diagram depicting one of those early load controllers in a typical testing set-up.

Early 2006 Mytek Controls Heat Load Controller as used in Typical Application

MPI Thermal TA-5000

Now I'll fast forward to the present day, where I'm approaching my 9th year of being in business with a Taiwan based company called MPI Thermal who's primary mission is focused on producing environmental and stress testing systems for electronics manufacturers that need to qualify their products to work reliably any place on Earth. So this could be the Flaming Mountain outside of the Taklimakan Desert of China during the Summer (80°C/175°F), or Antarctica in the dead of Winter (-93°C/-130°F).

The current product line of MPI Thermal consists of three different models of gas chillers (or gas heaters depending upon the mode of operation) that flow either chilled or heated compressed air over active electronic devices under test. And in order to verify the unit's capabilities during development and production, a calibrated flow meter is used with a variable compressed air source.

I'm anticipating new chiller designs to come that will require a simulated radiant heat source for testing, being very similar to what I was doing back in 2006. And because this testing apparatus will be for my own use, and confined to my own test lab (strictly non-commercial in nature), I decided to base the controller on one of my Atari motherboard creations. Specifically the 576NUC+. It should be fun.

SCR Phase Angle Control Module

The Project

This all began about 3-4 months ago when I was staring at a completed 576NUC+ board in my hands, and started thinking what a small and powerful package it really was. Size-wise it was very much like those single board computers I remember seeing being advertised in the back pages of electronics magazines in the early 2000's. In fact it was even smaller then many of the ones I recalled from back in the day.

So what would it take to industrialize it for connection to real world devices? It would need some kind of data acquisition expansion board. Something that would allow it to read a wattage transducer and control an SCR based power device to feed power to a heater, and to activate some relays as well as monitor an over temp contact on a temperature module for safety.

Also I needed a way to get a program to load automatically at power-up (SDrive) that would serve as the heat load control software. And there should be a numeric keypad to enter a load set point.

And last but not least I want to mount all of this in a nice rugged 19" rack case to keep it well protected, and to keep the high voltage stuff safely tucked away.

Well first things first... I got right to work on the Data Acquisition expansion board, had great success on accommodating all the requirements, and even added an RS232 communications port. I then sent the board design off to JLCPCB for manufacture, and got the boards in my hands about 5 days later. Assembly took less than a day, and on the following day I assembled a slightly customized 576NUC+ board that would get mated up to my previous days work. Here's what that all looks like...

Enter the RLC-4000 576NUC+ INTFC Carrier Board

RLC-4000_INTFC_schema.pdf
File Size:	119 kb
File Type:	pdf

Download File

Firmware

After assembling the first board set, I needed a way to run some preliminary tests to be sure things would work the way I had in mind. So I divided the tasks between machine code for the DAQ driver, and Altirra Basic for the actual control/monitoring aspect.

FILE: DAQ.SRC

10 ;*********************************
20 ;*                             *
30 ;*             RLC-4000 DAQ Driver       *
40 ;*       MAX187(ADC) MCP4921(DAC)     *
50 ;*                     DEC 26 2021    *
60 ;*    4000 WATT Heat Load CONTROL    *
70 ;*                              *
80 ;*           By: MyTek Controls          *
90 ;*                              *
95 ;*********************************
110 ;
120 DAQMSB=$06F0    ; 12-bit OUT (0-5V)
130 DAQLSB=$06F1
140 ADCMSB=$06F2    ; 12-bit IN (0-5V)
150 ADCLSB=$06F3
160 PORT=$D300 ; PIA PORTA
170 SDO=$D010      ; SPI-SDO (TRIG0)
180 SCK=1          ; SPI-SCK PORTA.0
190 SDI=2     ; SPI-SDI PORTA.1
200 CS1=4      ; ADC-CS PORTA.2
210 CS2=8      ; DAC-CS PORTA.3
220 ;
230      *=$0600
240 ;
250 ;=== READ MAX187 X=USR(1536) ===
260 ;
270 PLA        ; BASIC ENTRY POINT
280 LDA #CS1
290 EOR #$FF
300 AND PORT
310 STA PORT      ; ADC-ON CS1 LOW
320 LDA #0
330 STA ADCMSB ; zero storage
340 STA ADCLSB    ; registers
350 WAIT LDA SDO
360 CMP #1       ; End Of Conversion?
370 BNE WAIT      ; not yet...
380 JSR ADCREAD    ; retrieve ADC value
390 LDA #CS1
400 ORA PORT
410 STA PORT      ; ADC-OFF CS1 HIGH
420 RTS
430 ;
440 ADCREAD LDX #4
450 JSR CLKHI
460 JSR CLKLO
470 RLOOP JSR CLKHI ; read High-Byte
480 LDA ADCMSB
490 ASL A
500 ORA SDO
510 STA ADCMSB
520 JSR CLKLO
530 DEX
540 BNE RLOOP
550 LDX #8
560 RLOOP2 JSR CLKHI ; read low-Byte
570 LDA ADCLSB
580 ASL A
590 ORA SDO
600 STA ADCLSB
610 JSR CLKLO
620 DEX
630 BNE RLOOP2
640 RTS        ; read all 12-bits
650 ;
660 ;=== WRITE MCP4921 X=USR(1623) ===
670 ;
680 PLA           ; BASIC ENTRY POINT
690 LDA #CS2
700 EOR #$FF
710 AND PORT
720 STA PORT   ; DAC-ON CS2 LOW
730 LDY DAQMSB
740 JSR DAQSEND      ; write DAC MSB
750 LDY DAQLSB
760 JSR DAQSEND      ; write DAC LSB
770 LDA #CS2
780 ORA PORT
790 STA PORT             ; DAC-OFF CS2 HIGH
800 RTS
810 ;
820 DAQSEND LDX #8
830 LOOP TYA
840 CLC
850 ASL A
860 BCC ZERO
870 TAY
880 LDA #SDI
890 ORA PORT
900 STA PORT
910 JMP CLKIT
920 ZERO TAY
930 LDA #SDI
940 EOR #$FF
950 AND PORT
960 STA PORT
970 CLKIT JSR CLKHI
980 JSR CLKLO
990 DEX
1000 BNE LOOP
1010 RTS
1020 ;
1025 ;========= SPI CLOCK SR =========
1030 ;
1040 CLKHI LDA #SCK
1050 ORA PORT
1060 STA PORT ; SCK HIGH
1070 RTS
1080 CLKLO LDA #SCK
1090 EOR #$FF
1100 AND PORT
1110 STA PORT ; SCK LOW
1120 RTS
1130 .END

FILE: HEATLOAD.BAS

10 DAQMSB=1776
20 DAQLSB=1777
30 ADCMSB=1778
40 ADCLSB=1779
50 CONFIG=48
60 REM PIA SET-UP
70 POKE 54018,56:POKE 54016,255:POKE 54018,60:POKE 54016,28
80 REM
90 REM ======== MAIN PROGRAM ========
95 REM
100 INPUT N:IF N>3439 THEN ? "ý":GOTO 100
120 POKE DAQMSB,INT(N/256)!CONFIG
130 POKE DAQLSB,N&255
140 X=USR(1623):REM WRITE TO DAQ
150 FOR X=1 to 200:NEXT X:REM PAUSE
160 X=USR(1536):REM READ ADC VALUE
170 ? (PEEK(ADCMSB)*256)+PEEK(ADCLSB)
180 GOTO 100

Watt Transducer

What does RLC-4000 stand for?

Rack Load Controller - 4000 watts max.

Heat Load Control Algorithm

Using Altirra Basic for the control program has some definite advantages over using the stock Atari Basic when it comes to the expanded bit manipulation capabilities of Altirra (!=OR %=EOR &=AND). Also better code structure will be possible by utilizing the enhanced IF, THEN, ELSE, ENDIF features. And of course writing the main control algorithm in interpreted Basic allows for quick changes on the fly when perfecting the closed-loop control.

The basic idea (excuse the pun) is to have the ADC connected to a watt transducer that monitors the voltage and current (amps) going into the heater, and automatically converts that into a digital representation of voltage (0-4.095V) that represents the wattage (1mv/per watt). Since the ADC's 12-bit output directly equates to milivolts (1mv = 1 = 1 watt, 4095mv = 4095 = 4095 watts), no conversion necessary.

The DAC's 0-5V output will be controlling a Phase Angle SCR module to feed power to the heater, which is proportionally based on the control voltage coming from the DAC.

The Control Program will form a closed loop between these two aspects, and precisely maintain a wattage based on the set point that was entered, by constantly controlling the DAC's output, and thus the actual power feeding the heater, while monitoring the ADC so as to not overshoot or undershoot the target.

Since there will be a 7" color LCD screen built into the design, I plan to take advantage of the Atari graphical abilities and have some interesting, as well as useful information being displayed. It should look quite nice, only limited by my programming abilities.

Possible Layout for LCD Screen

Well that pretty well covers it for now - stay tuned for more to come as this project takes form over the next few months.

- Michael

New Menu Bar Arrangement and Project Pages

10/13/2021

Well its been a long time coming, but I finally got the last 3 projects I was working on setup with their own web page. And since the density of the projects started to exceed what was comfortably able to be fit on the menu bar, I had to do some rearrangement and create a common tab for like minded projects. So the biggest by far was what I call the SYSTEMS tab, which now has all 3 individual alternative Atari motherboard projects in a drop-down selection.

The 3 new projects are...

576NUC+ The Smallest Atari Ever
XEP80-II A reproduction of the original Atari XEP80
SIO2MIDI-S2 A Stand-Alone MIDIMATE interface with integrated Synthesizer

Its taken a lot of work to both create these projects, and to fully document them here. And quite frankly I'm bushed, so this blog post will be short and sweet.

Check out the new stuff, and enjoy!

- Michael

XEP80-II V1.0 BETA PCB First Test

7/31/2021

First Test of assembled BETA PCB looks to be an initial success! Well at least it is in the analog mode via the composite output.

The ROM switch to go between PAL and NTSC parameters is also working, although I think I need to do some tweaks on the NTSC ones, but that'll happen in due time.

Meanwhile I'm still waiting for the JST 1.25 mm cable and connector to show up, which will allow me to run with the A/V-to-HDMI Converter installed. That will be quite exciting to say the least (hey I get excited easily, what can I say).

So all in all, not bad to get to this point in a bit over 2 months. Yes it was towards the end of May this year that I first downloaded Sobola's XEP80 schematics and began the process of backward engineering his schematic into a form I could use to eventually lay out a PCB from. Then the creeping featurism took over, and here we are today, although I don't really think the extra features are creepy at all, and should prove to be quite useful. Anyway I'll make this a short post and get out of here - stay tuned for further test results to come.

- Michael

<<Previous

CV-NUC+ a ColecoVision Mini Game Console (Part 4)

CV-NUC+ a ColecoVision Mini Game Console (Part 3)

CV-NUC+ a ColecoVision Mini Game Console (Part 2)

CV-NUC+ a ColecoVision Mini Game Console (Part 1)

RLC-4000 Heat Load Controller Power Board Testing

My 1200XL has a Multiple Personality Disorder (Part 2)

My 1200XL has a Multiple Personality Disorder (Part 1)

RLC-4000 Heat Load Controller (576NUC+ based)

New Menu Bar Arrangement and Project Pages

XEP80-II V1.0 BETA PCB First Test

Author

Archives

Categories