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.

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.

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

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

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.

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

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

1. 576NUC+          The Smallest Atari Ever
   
2. XEP80-II            A reproduction of the original Atari XEP80
3. 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

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

It's gone through a bit of evolution since I first posted about it, and took a turn away from SMD in the process, now fully embracing THT components. This was done for a couple of reasons, one because of the added AV jacks the footprint expanded in such a way that extra space opened up that made sense for through-hole components to be used instead. And secondly it'll be more conducive for a DIY hobbyist to assemble the board, as well as greatly easing the troubleshooting of such. And even though the board has grown because of this decision, the new layout is still pretty compact at only 4.5" square - the same footprint as the 576NUC+ motherboard.

The addition of the extra AV jacks will facilitate all of the input possibilities that come with the A/V-to-HDMI converter. So now not only will the 80 column output be sent over HDMI, but so too will the 40 column stock video and sound.

To make this happen... an analog switch IC (MAX4619) will appropriately route the video signals, being toggled by a small tactile push button centered on the front side of the board. Each button press will switch between 40 and 80 columns, and then back again, with a dual stacked LED next to it indicating which video mode you are presently in. This will allow a single HDMI monitor to serve both video sources.

Let's pause for a minute and look at a preview image of the 'newest' 100% fully routed THT board layout. And for those that have been following this over at AtariAge, you'll possibly notice that I have moved the A/V-to-HDMI converter landing spot, so that it can now be flipped around 180 and have it's HDMI port facing the same direction as all the other jacks. This will become much more obvious when I post some pics of the real assembled boards.

Video and Communication Connection Breakdown

The JST 1.25mm x 8-pin male connector (J1) is to provide connection to the optional Wiistar WS-Z51 A/V-to-HDMI converter. It requires a double-ended cable with 8-pin female JST connectors to mate the two aspects together. Once connected, the 80 column output can be sent thru the HDMI port. And the stock Atari 40 column text output (as well as graphics) can also be converted to HDMI, with either being individually displayed at the press of a button.

Jumper block header (J2) is for configuration without an A/V-to-HDMI converter daughter board being present, so that the 80 column composite signal can be routed directly out through the yellow RCA jack to feed a standard composite monitor instead.

The three RCA (J3) jacks on the left provide the following inputs from left to right: Right channel audio, Left channel audio, and composite video (CVBS). The Mini-DIN (J4) jack provides an S-Video input. These analog A/V signals are only required if the A/V-to-HDMI converter is installed, and will get sourced from the Atari's normal video output jack using a suitable A/V cable.

And last but not least we come to the DB9 jack on the far right which is to be connected to one of the Atari's joystick ports to provide both serial communication and 5 VDC power.

Over the next couple of weeks I will be testing the newer 74 series High Speed CMOS chips in place of the older 74LS ones originally found on the XEP80. I'll also be testing the new lower power display RAM, and the lower power EEPROMS that will take the place of the factory ROMs. This is all aimed at extracting power for this board from the Atari's joystick port without overwhelming the stock power supply. If all goes well and the board+schematic are brought to an error free state, I will then have a small batch of boards made by JLCPCB for testing.

Update: July 22nd 2021 - All of the chips in my stock XEP80 baseline unit were replaced with their 74HCxxx counterparts that were proposed for the new design, as well as the newer SRAM and EEPROMS. After this change, power draw dropped from 430 ma down to 210 ma, making it practical to derive power solely from the Atari, while XEP functionality remained unaffected. Gerbers have since been sent to JLCPCB for sample boards to be manufactured.

That pretty much covers it for now,

- Michael

In June of 1987 Atari was preparing to release a piece of hardware to finally give the Atari 8-bit computer a universal 80 column text display, something that many felt would make it more usable as a business machine. Unfortunately it didn't end up being quite the wonder box in reality as depicted by the July 1987 Antic magazine article (VOL. 6, NO. 3). Instead people began to complain about it being slow, and in later years having serious over scan issues on more modern TVs.

However in spite of its bad reputation, there were those that liked it, and found it useful for editing code in Basic, the Assembler/Editor, and MAC65, as well as others who would go on to write extensive documents in the 80 column word processor AtariWriter 80.

I was one of those people that opted not to buy the XEP80 when it first appeared in the stores, instead saving my money for the new XE line of computers and printers that had arrived just a couple years earlier, and were quickly dropping into my price range. However over the years that followed, I always wondered what it was really like to use one of these mystery boxes, and if they truly were as bad as I had heard.

Well just recently I got that chance thanks to Bob Wooley of SLCC fame, that not only had one of these in his Atari barn, but ended up giving me 3 of them in various states of disassembly, and/or modification. We played around with them on his test bench for a while, with only one of them actually working. But what I saw was a video solution that rendered very readable 80 column text even on the tiny 9" CRT that we had it hooked up to.

So I took my new found treasure home, and continued fiddling with the one that worked over the next several days, and also discovered what was wrong with the other two that hadn't worked (bad firmware ROMs). As I tried out various things, I started to really like the possibilities, although I wasn't loving the over scan issues on my LCD. But thanks to Avery Lee (aka AtariAge member phaeron) creator of Altirra the Atari 8-bit emulator, I discovered that he had written a utility called XEPVHOLD.COM that corrected the timing chain parameters in the XEP to work much better with modern monitors, and boy did it ever!

Now for the Project

So long story short, I thought this might make for a cool reboot project, and started investigating the availability of the main display processor chip being used on the board (National Semiconductor NS405). Well it was no big surprise that a chip used in a 30+ year old design would be obsolete, and only available as surplus stock or pulled from other equipment. But amazingly after a very short search I found a great source for pulled chips at an incredibly cheap price, and in large quantities from a seller on eBay. So I pulled the trigger and bought 200 of them. Hey I told you they were cheap!

Having gotten that problem out of the way, I proceeded to backwards engineer the XEP80 with the help of Jerzey Sobola's schematic. And although his XEP80 diagram consisted of what should have taken 2 or more pages to cover, but all crammed on to a single sheet, it was remarkably accurate, only missing a capacitor, resistor, and some inline RF chokes. Thus using his diagram as a starting point, I began the process of drawing up my own schematics (3 pages this time), and took the liberty of specifying HCT chips to take the place of the original 74LS ones as used by Atari, and replaced the old ROMs and SRAM with modern CMOS ones as well, with the goal of running this directly off of 5 VDC Joystick power (the original XEP80 used a 9VDC wall wart). My schematic is now done, but I'm not yet ready to release it until I've really proven it out.

Next I started laying out a PCB, and continued my testing, some of which related to an alternative video output circuit I was experimenting with. It was during this phase that I discovered I could get a very nice centered image on an HDTV by using one of those inexpensive AV -to- HDMI converters. In fact it really was quite amazing how good it looked. So at that point things took a turn, and I decided to see what would be required in order to incorporate one of those AV2HDMI boards into my project.

Here's a look at where this has taken me (the white circles with the red 'X' inside shows where the AV2HDMI board will mount).

I decided to keep the analog video output as part of my design, and implement the AV2HDMI aspect as a daughter board stacked on top with it plugged into the CVBS video output jack. So first I had to extract the board out of one of those Chinese made converters being sold on Amazon and eBay for a very low price of $14-15 including FREE shipping.

The one I chose will convert either a CVBS (composite) or S-Video analog input to HDMI, and it also incorporates audio pass-thru to the HDMI output. The conversion of the Atari color video output into HDMI is less than spectacular when using one of these cheap converters, however in contrast the quality of the timing corrected XEP80 video looks quite remarkable - probably the best I've ever seen for the XEP80.

As it turns out, the board inside is very easy to extract, only requiring prying open a pressed together clam shell plastic housing. And conveniently it already comes with 4 mounting holes on its PCB, of which I was able to use 3 of them to mate up with my proposed XEP board design. The idea is to use 3 standoff's in order to clear the chips underneath. I don't plan on using the S-Video or audio inputs, but will retain them and tuck them inside whatever case is created for this project. They will be available as hackable possibilities for the end user to take advantage of if he or she so chooses.

So here's what that AV2HDMI board will look like mounted to my XEP80-II board.

The AV2HDMI board will get it's power from my board, and require a modified micro USB cable to do it.

The yellow composite input lead for the AV2HDMI gets plugged directly into a mating RCA jack on my board, making it ready to roll. All that's required is to plug a custom joystick style cable into the computer, turn it on, and boot the XEP driver.

                   -----------------
Click on the image to the right to get an idea of what this board combination can do on a modern HDTV when using Avery's modified video timing parameters and feeding through one of those Chinese video converters.

It's remarkably clear, with very legible text, and no distortions like one might encounter on an old CRT display. Basically this brings the XEP80 into the 21st century.
                  -----------------

My future plans are to incorporate Avery's XEPVHOLD parameters into the firmware ROM, assuming I can figure out how to do that. And since there are different requirements for PAL vs NTSC, I have implemented a configuration jumper that bank switches the firmware ROM, with the lower half containing code with NTSC parameters and the upper half having the PAL parameters. This way something like AtariWriter 80 will work correctly out of the box.

Well that covers it for now, but please check back for more news on the progress of this project.

- Michael

Well just when I thought everything had been covered, and all the bugs had been safely put to bed (or wherever dead bugs go), another problem surfaced. It too was obviously something that had been in existence for quite sometime, but had somehow flown under the radar. What I'm talking about has to do with the stock Atari keyboard's CTRL, SHIFT, and BREAK keys becoming garbled. Or in other words erratic in nature.

I think the reason I didn't see this was that during the early days of TransKey development, when I more thoroughly tested under all possible criteria, this issue did not exist. But that was also before I configured the code for a sustained key press from the PS/2 keyboard side of things. Prior to doing that, I had only given PS/2 key presses a timed key press equivalent on the Atari key matrix, which at first appeared to work fine, but later I realized not under all circumstances (or with all software applications). So in a later iteration of the firmware I implemented a more Atari like key response, and had it maintain an Atari key down for as long as the PS/2 key equivalent was being held as well. This appeared to work fine at the time, but apparently I never went back and tested this with the actual Atari keyboard still connected. And it appears no one else has either, or they're just not complaining about the erratic keys on the stock Atari keyboard. Or better yet they probably don't use the stock keyboard since installing the TransKey.

So back to the problem. As best I can tell the issue was associated with the new code that was added for sustained key presses at the time, and has been around ever since. So once I realized this, it was a simple matter to look at the routine in the firmware and spot the offending line of code. It turned out to be the Pokey KR2 line handling that was the issue. This is where a held key was using a TTL based version of a PIC I/O line to communicate to the Pokey KR2 bit, irrelevant of what the mode was actually set to (float or TTL). Float is the case where one of the PIC's I/O ports mimics an open drain output, thus still allowing the Atari keyboard to work in parallel with the PS/2 keyboard. TTL mode was only suppose to get used when no internal Atari keyboard is connected, usually in the case of an XEGS, but also applies to a 1200XL. this mode can be toggled by pressing CTRL+ALT+X, with ALT+X showing the present setting (ON = TTL Mode, OFF = float).

So once the bug was discovered it was a very simple matter to correct the situation, thus restoring the stock keyboard to full functionality.

This has now been fixed in both the 'classic' version, and the new 'J' version firmware. Downloads are available HERE for the newest universal V2.7J version, and HERE for the 'classic' V2.6 version, which has now been depreciated where new hardware designs are concerned.

There's no need to update the TK-II firmware on an XEGS, or for the 1088 series machines. And there is also no need to do so even on other systems where you no longer use the stock Atari keyboard.

- Michael

Back in early 2019 I decided to incorporate the SIO2MIDI into a 600XL. And while I was at it, I also added UAV upgraded video (including the missing DIN-5 jack on NTSC systems), 64K RAM, and BASIC Rev C. It was a fun little project at the time

It languished for a while afterwards, but then I set it up in a permanent spot on my workbench, attached an SDrive-Max to it, and connected it to a tiny color TV I pulled out of storage. It then became my JOY2PIC programming station, and was quite useful in this new role.

However never one to leave well enough alone, and getting inspiration from Flashjazzcat's video on installing a U1MB inside a customer's 600XL, I started thinking why not take it a step further and also install an internal CF drive. But what could I use to make that happen? Then it hit me... make a new board mimicking the XEL-CF3 circuit, and piggyback Antic because virtually every signal needed was already there. So was born the XL-CF4.

It was going to be very tight space-wise in order to fit underneath the stock keyboard. So to help out, I shifted the piggybacked Antic towards the back. Then to get the ID44/CF Adapter to fit, I had to remove it's female header and solder it directly to the male header on the board. This was just enough to do the trick.

But of course I wasn't going to stop at only installing The U1MB and the internal CF drive, I also decided to add a TK-II as well, which actually made it much easier to test stuff without the stock keyboard getting in the way, or risk damaging its Mylar circuit connection from the constant plugging and unplugging that would have ensued.

Flashjazzcat's video gave me the best location and mounting method to use for the U1MB. And believe me when I say there really was no other choice.

Drilling the mounting holes was the trickiest part, which required slowly incrementing in size from a tiny drill bit to the final size. It's literally on the edge of the board threatening to break out at any moment. Check out Flashjazzcat's video above for the details on doing this.

There were a few other tricky parts such as making the hole for the CF card to pass thru. However because it sits just above the bottom of the case, only the top half of the case needed to be filed to accommodate the actual CF card passing through it.

I was able to mate up the top and bottom of the case, mark the left and right side of the required opening and then measured the thickness of the card to get a height (I added a smidge more to allow free travel). The end result looked pretty good.

The downward angle towards the right is part of the original case design, so there was no way other than Bondo or plastic fillers that could have been done about that. Although it looks kinda like it's talking :-)

Wow but where was I going to mount the PS/2 keyboard connector for the TK-II ?

I found a tiny bit of space between the joystick and the SIO jacks, but it required notching out the SIO jack mounting ear on that side, as well as doing an extreme reduction in the PS/2 jack interface board (lot's of sanding required). I also sanded off the bottom of the interface board to minimize the height of the various soldered pins.

Lastly I also had to move two resistors, and scrape off part of the ground plane on the 600XL motherboard, all to reduce the height at which the jack would be mounted off the motherboard, and thus prevent it from shorting out to the ground plane. A little epoxy completed the installation.

What's nice about having the TK-II, is the flexibility of putting the keyboard wherever I want irrespective of the computer. And secondly the TK-II has some hot keys aimed at supporting the  U1MB as well as the Loader. However I did discover a small timing issue with the TK-II firmware that required my attention (stay tuned for a new version to be released soon).

As for how the project turned out... I think the final results speak for themselves.

So what all is inside this Monster 600XL ?

• UAV
• SIO2MIDI
• 64K Base RAM Upgrade
• U1MB
• XL-CF4 Prototype
• TK-II-PBJ with ARROW2JOY Feature Connected to Joystick Port 1

What might I still add ?

• Internal Dream Blaster S2 MIDI Synthesizer with a 3.5 mm Stereo Jack and a Mini-Toggle Switch to Select the MIDI Source (Internal or External).

Will the XL-CF4 be Made Available to the Public ?

No I'm afraid not, or at least not in its present form. There are still some timing issues that need to be resolved, which limit it to only working reliably with a handful of clone Sandisk cards I have left over from a lot of 10 pieces purchased years ago on eBay. However unlike it's little brother the XEL-CF3, most other CF cards including genuine Sandisk simply do not work in this application. Also the prototype is a 4-layer board which due to its size is a little pricey. It would be far better to redesign it as a 2-layer board instead to keep the cost down. And finally, it requires precision mods to the case plastic in order to create the opening where the CF card can slide into the socket, not something very many people have the capability of doing especially if the end result is to approximate a factory finish look. If done poorly, at the very least you have done irreparable damage to your Atari's enclosure.

- Michael

Due to a long standing error that got missed, CTRL+SHIFT+Arrow keys were not rendering the correct key codes. Essentially they would just send the same code as pressing the arrow key alone, which was the equivalent to a CTRL+Arrow on a stock Atari keyboard. Basically it was missing the SHIFT aspect when combined with CTRL.

So both the TK-II Classic and the improved Universal 'J' version firmware have been corrected, and uploaded to the TK-II main page, as well as included in the XEL and XLD zipped compilation folders.

The classic version has moved from version 2.4 to 2.5, and is mainly provided to support the dual PS/2 keyboard aspect in the following products: TK-II-STEREO, TK-II-XEGS, TK-II-GS, TK-II-PB, and 1088XEL. This feature has been depreciated, and will no longer be seen in newer hardware such as the TK-II-PBJ.

The improved V2.6J version is the more universal TK-II firmware, and brings support for an AKI 'like' Console Function Key mapping, which is selectable between two modes: TK (Classic) and AKI. The AKI method is identical to what the Altirra emulator uses for the console and reset keys, thus making the transition between the two systems much easier. This mapping was adopted as the default for the 576NUC+.

To toggle between the two possible Console Key assignments, the key press combination of CTRL+ALT+E is used, with ALT+E displaying the current setting. This is non-volatile, so it will get restored to whatever the last setting was upon system power-up.

Another aspect of the V2.6J firmware that has hardware support in some of the newer TK-II boards, is the Arrow to Joystick mode, thus allowing the arrow keys to sit in for a joystick when selected. For the trigger, the Left-Windows key does the trick. Thus far there only two boards that support this: TK-II-PBJ and the ARROW2JOY-XLD adapter board for the 1088XLD. Pressing ALT+J will toggle the mode from standard arrows to joystick mode, and back again. It is a volatile setting, and will be restored to the arrow key default on a power cycle.

- Michael

Although it's not a mandatory must have upgrade for the NUC, having dual Pokey stereo output would none the less be very cool.

Normally if this were a stock Atari 8-bit computer I'd say go with the modern plug 'n' play PokeyMAX in place of the original Pokey chip. However there are two reasons that won't fly on the NUC, one being an incompatibility with the TK-II chip responsible for keyboard input, and secondly there were some clearance issues. Because the 576NUC+ is an extremely condensed version of an A8, there simply isn't a lot of room between chips and other required hardware. And due to a wider footprint of the PokeyMAX vs. the Atari Pokey chip, this presents problems, one being a standoff for the FujiNet daughter board getting in the way.

So not being one to throw in the towel when the going gets tough, I started looking at some of the old school solutions, namely Gumby as originally proposed by Chuck Steinman of Dataque fame. In his proposal he outlined a method of stacking two Pokey chips and then adding a circuit for address decoding to let them share space. Here's a link to the article he wrote in December 1989 about doing that very thing. What Chuck really accomplished back then, was to create the standard for dual Pokey addressing that lives on to this day, over 30 years after its initial development.

In Chuck's design he uses a single gate from an inverter chip to invert the A4 address line for connection to the original 'left' channel Pokey chip's CS1 pin, and then simply routes the non-inverted A4 address to the same pin on the stacked 'right' channel Pokey. This gives a flip-flop action between which Pokey chip is enabled, dependent upon the state of A4. To finish off the circuit, the 'right' channel audio output was handled in a pretty simple way with the addition of a single resistor and capacitor, using trim pots to balance the stereo output between channels.

Looking at the original Atari 8-bit circuit, a pull-up resistor was connected to CS1 creating a high (logic 1) on that pin, which can be easily overridden by external logic. Unfortunately I didn't do that in the 576NUC+ design, so for my upgrade that pin needs to be lifted.

In my design I wanted to match the characteristics of the already present 'left' channel audio circuit in the NUC, thus having the same output level in both channels and eliminating the need for any trim pots. I also had to keep what I'll call the Gumby Interface circuit relatively small, due to the lack of space in the NUC. So for the A4 inversion I was able to use two resistors and a 2N7000 N-Channel FET.

Next decision was where to locate the circuit board in order to avoid a point-to-point wiring mess of the required components dangling in mid-air. And because there was a limited amount of free space available, I chose to create an XRAM piggyback PCB to give both a secure and stable mounting platform, as well as to pick up power, ground, and the A4 signal.
Note: XRAM is my abbreviation for eXtended RAM.

This method of both mounting the PCB via piggybacking the XRAM and grabbing the prerequisite signals from that chip ended up working pretty well. And although it would have been super nice if I could have taken the more conventional approach, and piggybacked the original Pokey chip along with using sockets instead of soldering the Pokeys together, this simply was not an option so a compromise had to be made.

Here's how it looks installed in the 576NUC+ (the system ROM and 512KB SRAM have yet to be inserted). It turned out pretty clean if I do say so myself.

And now with the hard stuff out of the way, I can connect my amplified stereo speakers, and then sit back and enjoy some Stereo Pokey tunes. Life doesn't get much better than that.

Oh just to be perfectly clear... this project is purely a personal pursuit and will not see a public release for the gerber files, or ever get produced by someone like The Brewing Academy.

- Michael

I had one of Mr Robot's early prototype NUC-XE cases which was patterned after its big brother the XEGS. However this was not designed with FujiNet in mind, and would require some careful modding to get it to work. But I really wanted to house my naked 576NUC+ with its proto FujiNet board installed. So out came the files, drill bits, and a hot knife.

Luckily there appeared to be just enough headroom to pull this off. Although it would require creating holes right where the top and bottom of the case joined up, which was a tricky proposition to say the least.

After a lot of careful pencil marks and filing, I was able to create the initial holes for the LEDs and push button switches, and finished it off by holding the case halves together while spinning a drill bit to yield a smooth circle.

For the SD card, I heated up an X-Acto knife, and made a rough cut smaller than required, which I then finished off with a file to the proper size.

On the rear of the case I ended up making a square hole with a file for the reset button instead of a round hole like I had done on the front. I did this because the lid has a lip with an extra thickness which would have required some carving out in order to allow clearance for the body of the push button switch. And although I did this for the front buttons and LEDs, it was a lot work.

I also did something similar for where the serial programming header needed to protrude, but had to make it bigger all the way around so that the serial USB cable's Dupont connector would slide all the way in.

Luckily since the body of the toggle switch sits farther back, I was able to make a round hole between the case halves, same as what was done in the front of the case.

Note: I use a Prolific PL2303 serial UART to USB cable for updating the ESP32's firmware, but a FTDI cable would work just as well.

Next came some ventilation holes in the bottom, since things did get a little toasty with only the angled vents on the top side.

The holes were started with a small drill bit, and then followed up with a Uni-Bit to the desired size. I was able to get a chamfer by lightly touching the top edge of the hole with the next increment of the Uni-Bit.

Identical holes were added to the other side of the case for a uniform air draw from the bottom to the top via convection.


I am very pleased with the final result, although in the future, proper cases with FujiNet in mind will get designed by Mr Robot for production. In the meantime my NUC is now safe in its cozy little home, and is dwarfed by the XEGS sitting below.

And for that added a touch, a proper label was placed in the space already provided for it.

I got this from Sticker You and ordered a sheet of them to share with the beta testers on this project.

Also found some very nice self-adhesive clear silicone feet at Home Depot.

- Michael