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

Normally these chips which are re-programmable, go for $5 each as seen in other eBay listings. And I had previously bought a few at that price point. However they're no longer in production, so what you get are NOS ones that someone still has a stash of tucked away. What makes them really nice is that you don't have to have a UV light source to erase them, since it's done electrically instead. Making for a much better and faster programming cycle.

Now I can get OTP (One Time Programmable) 512K EPROMS by Microchip/Atmel for about $2.50 in single quantities, and they are in current production. But being a one time programmable device means that you better get it right the first time, and be happy with it forever. However unless you plan on investing in a chip programmer such as the TL866 Plus, this may not be many peoples cup of tea. Luckily for the 576NUC+ there really is no need, since The Brewing Academy will be selling them with pre-programmed ROMs when they go into production.

The 576NUC+ system ROM contains two different Operating Systems, two versions of BASIC, and two games. It could be handled by a OTP device as mentioned, and for most people that'll probably be OK. But for a few of you who love to be able to customize your system, a re-flashable ROM would be desirable, hence the reason I was looking for an inexpensive and readily available source of these.

So I went in search for that cheaper EEPROM, once again going back to eBay. This time I found another seller for the SST EEPROMS that was advertising a deal that I knew was too good to be true, but part of me was game to find out for sure since the seller was only asking for about $1.00 a piece.

Here's that eBay listing.

About 2 weeks after my purchase I received the EEPROMS with all 20 pieces appropriately packaged in several standard IC anti-static plastic tubes. So far so good.

I then proceeded to plug them into my trusty TL866 Plus programmer and initially tried to flash them with the 64KB system ROM image for the 576NUC+, at which point, no real surprise they all failed one after the other.

Next I tried to erase a few of them, and once again no dice with the same error. So I tossed in a known to be good chip, and it programmed without issue. But then I noticed a crucial difference in the chip ID. The one from JK Parts showed 0X DA 08, whereas the working chip was 0X BF A4. So I checked my stock of good chips, and all of them returned the same ID (0x BF A4). Next I checked several of the chips from JK Parts, and they all had that different chip ID of 0X DA 08. Obviously the JK Parts chips were not really SST 27SF512s but something entirely different (what are they really??? - initially I didn't know - hint: see note at the end of this blog post for the answer).

So with that revelation, I scrutinized the appearance and labeling on the top of what I will now call a 'REAL' 27SF512, and compare it to a 'FAKE' 27SF512 better known as the chips I purchased from JK Parts on eBay. As can be seen below it's rather obvious that something is amiss with the FAKE chip's labeling. For one the numbering is way too crisp and clean, yet the SST label looks a bit rough around the edges. And although you can't really see it all that good in the photo, the depth of the indentation is much more shallow on the FAKE chip, as if someone sanded off some of the material (which they probably did in order to prep it for the new label). The printing is resistant to acetone, which was the strongest solvent I had on hand, and it might even be etched like the original would be.

So what's on the bottom of the REAL chip? Let's find out.

Yep that looks like something one would expect. Now let's check out the bottoms on those FAKE chips.

Oh yeah... that probably shouldn't look like that. Did the seller have a picture of the chip bottom on his listing? No certainly not. Apparently they couldn't be bothered to sand off and reprint the bottom of the chips like they had obviously done to the top side. At this point it was pretty clear that these were not genuine SST 27SF512 EEPROMs that I had gotten from JK Parts. But what could I do since the seller clearly stated "No Returns" on his listing.

This story has a happy ending...

Thanks to a AtariAge member Mr Robot's sleuthing skills, he matched the FAKE chip ID to a Winbond W27C512 EEPROM. And when I plugged those parameters into the XG Pro TL866 Plus programming app, everything fell into place allowing me to do multiple re-flashes of the chip as seen below.

So long story short, JK Parts sold me a relabeled Winbond W27C512 chip instead of the originally sought after SST 27SF512 I ordered. Both chips are EEPROMS, and they can both be repeatably re-flashed and erased. So bottom line I still ended up with a good deal that still works for my application, but I'll have to relabel the chips to avoid confusion. And now thanks to the seller's substitution I also know of an alternate chip for what I was originally looking for.

BTW, I was able to flash all 20 chips successfully as Winbond W27C512's.

However even though in the end this will work for what I need, I can't in my right mind recommend ordering from this seller without at least verifying what the heck is going on, although it's probably a case of Cha Bu Duo (aka: "close enough" - thanks to Mr Robot for that bit of insight). I won't be posting a link to that eBay auction, and I won't change the title of this blog post either, since it really is a fake, or in other words a substitution of another chip meant to fake the characteristics of the one it replaces..

- Michael

Since the procedure for loading cassette (cas) files is uniquely different for the NUC/FujiNet combination I thought it good to outline that procedure.

The following assumes that you have your FujiNet Program Recorder configuration set to use the 'Pulldown Resistor' option. This selection is made using the FujiNet web UI via a browser, and then  saving it.


NUC-FujiNet Cassette Loading Example

1. Select a cas file (e.g., O'Riley's Mine from FujiNet.online) via the config menu, press ENTER, and it will be placed in disk drive slot 8.
2. Press OPTION (F4) and hold it, then press START (F2) and hold it until the system reboots with the characteristic BEEP, then release both the START and OPTION keys.
3. To begin the file load, momentarily press the START key one more time... the RED LED will light up, and then just a tiny bit later the loading tones will commence.

 

- Michael

Yesterday I assembled, tested, and shipped out three prototype NUC-FujiNet V1.5 boards to people in the Beta Team for their review.

When it comes to hardware development I can be very tenacious at fine tuning the design, but I'm afraid my patience for running thorough tests of all the different aspects is quite a bit less then desired. In order to insure that all of the bugs got squished out of this particular design iteration, I'll bow out and let the Beta Team have at it (Stephen, Herb, and Simon).

Assuming that all goes well in this regard, then AtariAge member Mr Robot will finalize the production FujiNet design he has been diligently working on, which will also incorporate the option of a top side-loading cartridge slot, as well as all the interface changes coming out of the V1.5 prototype (e.g., full SIO isolation when powered off).

And thanks to AtariAge member mozzwald, the SD card detect switch feature of this design has also been fully realized in the latest firmware release, so that we can now do SD card hot plugging and/or card swapping without the necessity of powering down or resetting the FujiNet board to reinitialize the card. This is an uber cool feature!

Production Design
Mr Robot's production board + case design concept is rapidly advancing, as can be seen in these simulated examples he created and first posted at AtariAge. And thanks to dimensional info coming from other members in the forums, he has hopefully gotten things sized to accept any and all cartridges ever made for the Atari 8-bit, including those wider AVG and SIDE carts, and the unique XE carts with the ridge sticking out of the back side.

Ultimately the plan is to offer it either as a stand-alone FujiNet minus the cart connector and raised case design, or as the full boat that you see here with the cartridge port inclusive. Obviously the non-cart version will be extremely compact with a minimal height requirement, thereby having a much lower profile lid for the case.

Needless to say, I think Mr Robot's design really hit it out of the park!

- Michael

Made several changes to the previous prototype V1.3 design, and now have another set of sample boards for testing being manufactured by JLCPCB - scheduled to arrive around the end of this week. BTW, the SD card issue I was seeing from day one, has been solved, and came down to human error as well as an incompatible SD card.

What's Changed?

The Cassette Motor Control line has now been buffered and switched out of circuit when FujiNet is powered OFF, and the SD Card Detect Switch is now being sensed by IO12 on the ESP32, and will eventually see future support in the firmware (Now Implemented in firmware version 0.5.879c407c).

This will be my last prototype, with the design already proven out by previously modding a V1.3 board. However I simply couldn't resist putting a bit of polish on the process, and doing one last board run with all the V1.5 changes in place. I also need a few boards for others to test so as to prove out the design, so having boards that incorporated all the changes was a prerequisite.

This time around I also wanted to properly pay homage to AtariAge members Mr Robot and mozzwald. Mr Robot deserving a call out for sourcing the switches, SD socket, and LED holders. And for the direction I got from his excellent PCB layouts that came before. And of course a big acknowledgement also goes to mozzwald the creator of the hardware design being used in the standard Atari FujiNet devices, which served as both my guide and inspiration. And a shout out to the rest of the FujiNet team for a wonderful game changing innovation known simply as FujiNet (visit FujiNet.online)

So the intention is to get a few of these out to the 576NUC+ Beta Test and Development Team, and let them run it through the ringer in order to shake out any bugs. Assuming that all goes well with that, then Mr Robot will take back the reins and proceed with the final production designs. There will be more to it then just FujiNet, so keep a look out for any posts he makes concerning that.

This new SIO interface circuit which is being proven out in this final V1.5 design, has been released into the public domain, and it is hoped that it'll see future use in other FujiNet related projects.

- Michael

In all cases, pressing control in combination with the arrow keys will temporarily reverse the present mode. So if you press CTRL+Arrows when in the normal 'PS/2 mode', that will produce symbols instead of cursor movement. Whereas if in 'Atari mode', will result in moving the cursor, with symbols only being rendered when no control key is pressed in combination.

Using SHIFT in combination with the PS/2 arrow keys produces the same symbols as the stock Atari keyboard, no matter which arrow mode you are currently in. SHIFT+CTRL when pressed with the PS/2 arrow keys, will not produce a character but instead mimic the same key codes as produced by the stock Atari keyboard for this same combination of keys.

The Insert key when pressed by itself will insert space to the right of the cursor, and when pressed with SHIFT, will insert extra blank lines below the cursor.

The Delete key when pressed by itself will delete characters or space to the right of the cursor, and when pressed with SHIFT, will delete lines below the cursor.

Home when pressed with either SHIFT or CTRL will clear the screen and home the cursor to the upper left. When pressed alone, will invoke a 1200XL function of simply homing the cursor to the left on whatever line it was on without clearing the screen.

End will invoke a 1200XL function to move the cursor to the far left of whatever line it was on.

PgUp (Page-Up) will invoke a 1200XL function and move the cursor directly up to the top left of the screen.

PgDn (Page-Down) will invoke a 1200XL function and move the cursor to the bottom left of the screen.

Those last 4 special navigation keys (Home, End, PgUp, PgDn) can be very useful when utilized in an Atari program,  especially anything that requires the user to navigate a menu. For a good example, check out the customized SDrive Control Program or AtariAge member flashjazzcat's SIDE Loader and the Uno Cart contributions. Also FJC's The Last Word makes good use of these keys.

As FujiNet continues to mature, it would be nice to see more of these  special navigation keys play a roll in navigating the TNFS directories in a similar way to the examples given above.

- Michael

Because of changes that were required in the first prototype, and then getting a bit more inspiration from a recent DIY THT build project, I decided to create a new hybrid prototype that would allow either a ESP32 SMT module or ESP32 THT DEVKITC to be utilized.

Note: Although the silk screen shows a ESP32 part number with a '-IE' suffix, the cheaper version with an '-E' suffix can be substituted instead. The only difference is that the '-IE' version has both an IPEX and PCB antenna, whereas the '-E' only has a PCB antenna. Keep in mind that the one with the IPEX connector has this selected by default, and needs to be modded to use the PCB antenna instead by moving resistor R14 to the R15 position (refer to diagram - click to enlarge).

This board is currently being manufactured by JLCPCB in China, and has an expected completion date for this coming Monday.

When I get at least one board assembled and tested, I'll be sure to post the updated schematics, as well as my observations. So far I can tell you that it incorporates the same SIO interface as its predecessor, using a 74LS07 and a 74HCT4066. This new interface has been working very well, and appears to have solved the audio noise issues.

- Michael

Thanks to AtariAge member mozzwald (creator of the original FujiNet hardware), it was brought to my attention that pull-up resistors should be used on 3 of the 4 signal lines of the SD card. This article goes into more detail about that.

So today I added the resistors and once again held my breath and attempted to access the SD card on my FujiNet device - No dice still not working. It was wishful thinking that it would, but with other people's units working without pull-ups, I wasn't surprised. No matter, the pull-up resistors will still be added in my design.

Next I re-flowed the solder at the ESP32 connections, but that also failed to correct the situation. When probing the signal lines with a scope I saw no activity, and the CS line remained high, which is the normal idle state. It's almost like there's no one awake inside.

At this point I can only surmise that my ESP32 possibly has at least one I/O pin that is damaged. And since it's not easy to replace, I'll be looking at a 2nd build with a fresh board and new parts.

In the meantime I've been fine tuning the design, and moved it up to Version 1.2.

Another thing I discovered, was that the information I had gotten for my USB/Serial cable was incorrect, which was why I thought I needed to swap the RX and TX pins. So that's been restored to the way it was shown in the very first schematic, matching the prototype PCB that was based upon that.

Next I really didn't like where the ADC VREF voltage divider was getting its positive voltage from (SIO), so I moved it over to the regulated 3.3V bus... EDIT: I totally misunderstood the purpose of the voltage divider. In actuality it is being used to sense voltage coming from the Atari in order to determine if it's powered ON or OFF. The voltage divider simply brings the 5V of the Atari down to a level that's safe for the ESP32 to look at by one of its ADC inputs. So I have restored the original voltage divider in my schematic and renamed the wire label as VSENSE instead of VREF. The schematic download has been updated with this change.

I also decided to reduce the size of the programming header, as well as eliminate the SIO-Thru header and only pass along the PS/2 and power related signals via a 5-pin header. The PS/2 connections are present in case I wish to develop an active Wireless USB to PS/2 converter, which is something that is definitely on my wish list.

And for the final touch, the resistor array has been expanded to include the three SD related signals, thus actively pulling them up to 3.3V.

Hopefully the next time I write about this specific FujiNet prototype it will be to discuss the successful operation of the SD card.

- Michael

I ran into a few snags after assembling the first mostly THT NUC FujiNet prototype. The main problem off the start was that the 3.3V regulator was intended for a 5V input which didn't bode well with our diminished power supply due to the Schottky diodes that are inline with both the USB 5V and the 576NUC+ power. Specifically I wasn't seeing a high enough voltage feeding the ESP32 module as a result.

Once that problem got resolved by spec'ing a LDO (Low Drop-Out) voltage regulator. Then the only issue remaining was that the SD Card wasn't working, and in fact it still doesn't, but that will be pushed down the road until another day. However the network side of things works great as can be seen below. I was able to quickly log-in to my WiFi router, and then added a couple of existing TNFS server addresses, subsequently I was able to download a game via the internet and run it. It was quite fun and absolutely amazing all at the same time!

However the freshly assembled board did require a few more tweaks...

The series resistor for the SIO-Audio had to be increased from 470 ohms to 100K because the NUC already has a fairly high gain on that audio in port, making the SAM software speech synthesizer way too loud.

I also didn't like the look or the inconsistency of the first LEDs being used, and changed them all over to a diffused NTE version instead. Since these are very high efficiency, I was able to increase the current limiting resistors to 2K for all three of them, which matched the brightness of the dual green LED's on the NUC main board. What's also rather nice is that they all look the same when not lit, having a frosted white appearance, and best of all they are inexpensive at about 14 cents a piece.

During the initial firmware flashing I had discovered an error on which pin was designated as TX and which one was RX on the programming header. They need to be swapped. Luckily the programming cable I'm using broke out each wire independently making it easy to fix the issue, and get the ESP32 programmed (PL2303TA Cable Buy Link).

By the way, I also discovered that the program select header (PGM) was not needed, since the 'A' button works in its place.

Flashing Procedure for this Specific FujiNet Board

1. Turn OFF FujiNet power switch.
2. Connect USB/Serial cable between FujiNet and the computer.
3. Press and hold the 'A' button.
4. Turn ON the FujiNet power switch.
5. When you see both the white and blue LEDs light up release the 'A' button.
6. You are now ready to download the new firmware.
7. Start the FujiNet Flashing app, and after selecting the serial port associated with the cable, press the Flash FujiNet Firmware button and let it do it's thing (this takes a while).

And finally we get to the real reason I was so keen on redesigning the SIO to ESP32 interface circuit, and that has to do with a random but very noticeable noise experienced during certain sequences in shutdown and restart that has been observed in several versions of the FujiNet hardware. Disconnection of the SIO-audio input has been integrated into the new interface design in an attempt to minimize or eliminate the problem. So far the noise hasn't been seen in the initial tests of this new prototype. Or at least I haven't experienced the right conditions that will make it reveal itself (fingers crossed).

Now all I need to do is get that pesky SD card to work.

During my troubleshooting I did a continuity check of all the connections between the SD card socket and the ESP32, but so far everything looks correct. Although I haven't entirely ruled out operator error, as in my docs may not match up with reality concerning what pins do what on the socket. The datasheet for the SD card socket I'm using is really piss poor concerning the pin definitions.

That's it for now. I'll be sure to report back in when I solve the SD card problem.

- Michael