Well lot's of things happened over the past 3 months.

• The NUCplus4 Project got released
• The UGV got a new, better, revised version released called the UGV-II
• I was in the hospital for 3 days because of massive blood clots in my lungs
• The 1200XL-1MB Project (a 1088K SRAM upgrade) got started

NUCplus4
This got released on September 21st 2024 nearly 3 months ago, and there have been several people that jumped right on it and are building their own (Marek, LarryL, remowilliams, Panther, Jfcatari).

There were a few small issues that popped up, such as the solder pad holes for the battery holder being too small, and the FujiNet module's 3.3V supply needing a larger capacitor. But all in all things went pretty smoothly. I also introduced a new beta version of the TKNUC1MB firmware on November 15th, with a download at AtariAge in the World's Smallest Atari 8-bit forum thread (LINK).

EDIT: The new firmware now works very similar to the 576NUC+ original firmware, and only brings up the A8PicoCart aspect when you specifically want it via the F6 key. The 576K vs 1088K RAM selection is still automatic, being wholly dependent upon whether one of the internal Language/Game Slots is active. Yes I'll need to update the operating manual datasheet, and that will happen eventually.

I haven't updated the files yet on this website, but that'll hopefully be happening soon.

And probably worth mentioning, the SD Push-Push Socket P/N: RSMT-2-MQ-WF went obsolete soon after the project's release. Unfortunately there is no drop-in substitute that I've been able to find, and when it went obsolete it completely disappeared from the likes of Digi-key, Mouser, and Newark. So for those contemplating this build, you'll need to source this as a surplus item from eBay or AliExpress, with the cost being higher.


UGV-II
I wasn't 100% happy with the original UGV, and finally decided to do something about that. Thus the UGV-II was born.

Improvements...

1. Better quality video than even the 576NUC+, being on par with the latest UAV.
2. Non-interference with stock video outputs.
3. No modifications to Atari motherboard, other than the GTIA needs to be in a socket (W2 jumper is a non-issue).
4. Simpler and easier build for a DIY person than the previous original UGV, being mostly THT components this go around.

This got pre-released at AtariAge only 3 days ago (LINK), and will eventually make it's way over here (I gotta lot of changes to the UGV webpage in mind).


I Was in the Hospital for 3 Days
Yep you heard that right, due to a genetic deficiency my blood began clotting at an unrestricted rate and got to my lungs making it very difficult to breathe. My brother has a similar condition and went through this 23 years ago. For some unexplained reason my susceptibility to this took much longer to kick in. Anyway I got on top of it in the nick of time, and I'm doing fairly well now without any permanent damage.


1200XL-1MB Project
During my recovery I was getting a little bored, so I started a new Atari upgrade project for my 1200XL. That being to replace the noisy DRAM and its associated glue logic with SRAM instead. I called upon Juergen van Radecke (AtariAge: tf-hh) to help me out with this, utilizing a variant of his NUCplus4 1MB EMMU jed.

The new memory upgrade will piggyback 4 chips on the 1200XL: PIA, SALLY, MMU, and the 74LS138. From these it will get all the required connection points, and thus be a totally solder-less design. The prototype layout is complete, and sample boards are on their way from JLCPCB in China.

So that wraps it up for now.

Hopefully see all of you in the New Year.

- Michael

NUCplus4 Brief Description...

This daughter board is meant to expand the basic 576NUC+ miniature Atari computer system with a multitude of new abilities. Four at any given time to be exact. Go here for more INFO.

Assembly...

This is pretty much a through-hole board in most regards, with the only exceptions being the the Push-Push SD Card socket and the optional FujiNet Module's ESP-32 which has a castellated surface mount configuration.

So just like most such boards, it's normal to start out with the low profile components first such as the resistors followed by the capacitors, and then move into the larger ones. I'm not going to go into a lot of detail regarding this, since I'll be assuming that whoever undertakes this project from a DIY aspect already knows how to assemble and solder a PCB.

Let's get into the more critical stuff, with the first being the installation of the pin-to-pin male headers for piggybacking the PLDs on the 576NUC+ board.

In order for the NUCplus4 daughter board to sit parallel to the 576NUC+ board, these pin-to-pin headers need to be absolutely flush as possible with the underside of the NUCplus4 PCB and perpendicular to it (specifically the shoulder on the pins should be flush with the PCB). To insure perpendicularity, temporarily plugging in one machine pin socket will maintain proper alignment. These will get removed after the pin headers have been soldered in place on the top side of the PCB.

Here's what that'll look like.

After soldering the male pin headers, trim all the protruding pins inside the IC socket footprints as flush as you can with the top of the board (good quality side cutters should be used for this).

Now insert the sockets for the PLDs, and after removing the temporary alignment socket on the bottom side, solder those in as well. This will be a bit tricky, and a soldering iron with a long skinny conical tip really helps.

Now you will be ready to solder in all the remaining sockets and headers. I suggest doing it in this order, so that you don't block your access.

1. Machine Pin socket for U1 (make sure U1 is pushed all the way in with its shoulder slightly protruding from the bottom of the board).
   
2. Now insert and solder all the rest of the sockets.
   
3. Insert SIO extended male pin header (P1) from the bottom side of the board and solder it from the top.
   
4. Insert remaining headers and components and solder in place. Wherever possible insert devices (Pico Module and FujiNet Module) with their male pin headers in place to hold alignment of female headers before soldering.
   

With all the soldering done, it's now time to install the necessary number of piggyback machine pin sockets for the PLDs (2 sockets each) and U1 (3 sockets). The final stack up should look like this.

The completed assembled board should look like this when you are done.

Three chips will need to get moved (U3 SRAM, U4 MMU, U5 EMMU) from the 576NUC+ to the NUCplus4. The EMMU will need to be re-flashed with the 1024K jed.

There's a modification that needs to happen before plugging the NUCplus4 into the 576NUC+, and that has to do with the top clearance of the 576NUC+'s 8-Pin DIN A/V jack. It needs to have some of the plastic filed off (mainly the bump towards the rear).

It'll also help to trim off the pins on the rear most row of the PLD socket with side cutters after soldering.

Plug in all the required chips after flashing any that require it, and be sure to re-flash the embedded TK-II chip in the 576NUC+ with the NUCplus4 specific firmware (consult the Datasheet for more information about this)

You should now be good to go.

- Michael

I got side tracked once again the other day, and found myself studying some posts on various websites about MIDI-CAR and it's player. I had seen some things about this a couple years back, but at the time it appeared to be focused on a PBI based hardware device only. And because my focus had been centered around SIO based MIDIMATE devices, I wasn't all that interested. However when I was having a discussion with AtariAge member flashjazzcat and the subject came up about how it would be nice if there were a new and better MIDI player on the Atari 8-bit, AtariAge member PeBe popped in and said MIDI-CAR now had an SIO driver designed for MIDIMATE and its clones, and that I should check it out.

Well long story short, I did check it out and I was quite impressed at what I saw. So much so, that I decided to package it in an ATR and put it on my MIDI page as a download to take the place of that less than desirable MIDIPLAY program.

MIDI-CAR is a full featured player. It accommodates multiple drives, and works very well with SpartaDos and SDX, as well as other DOS'es. The interface is very intuitive to use, and it has an easily accessible help screen that can be viewed anytime for specific command shortcuts, and brief descriptions of what they do.

This player also fully supports the MIDI-CLK output as generated by MIDIMATE and compatible SIO2MIDI devices for proper syncing and timing, something that MIDIPLAY did not do.

However in my testing I ran across a problem with that last aspect when trying to launch the player from FujiNet. It seems that an issue has existed with FujiNet's firmware which has been pulling the SIO CLK-IN line low during its idle state, and holding it there. This defeated the MIDIMATE's MIDI-CLK output which also shared that same SIO pin. The end result was that MIDI-CAR was not able to actually send MIDI data to the end device, thus there was no music being heard from a connected synthesizer. Luckily AtariAge member mozzwald got right on the problem and very quickly provided a test version containing a fix. Since that worked, we'll be seeing an update coming soon in the next FujiNet firmware build to come (V1.4 and before will exhibit this problem). Until that update occurs, here's a link to the patched version of the firmware.

---------------------

This MIDI player diversion gave me renewed interest in MIDIMATE devices, and I finally found time to upload some of the MIDI related stuff from previous contributors like AtariAge members Montezuma and Fierodoug5 in the form of new firmware and a new 3D printed case. Montezuma provided a SILENT "no intro" and MULE theme music version for the PIC MIDI Controller, and Fierodoug5 customized one of Mr Robot's 3D case designs for the SIO2MIDI-S2 system. Check out the MIDI page for these updates.

That covers the MIDI changes and related innovations for now.

- Michael

The original 576NUC+ case design was created by Steve Boswell (AtariAge: Mr Robot) who later released the STLs to the open source community, which I was able to modify to suit this new incarnation. This was also made possible through the use of a free online 3D CAD application called TinkerCad, a simple to use but very powerful 3D design tool.
 

New 3D Printer

I recently graduated to the Bambu Lab A1 mini 3D printer, and can now do some seriously good prints.

Previously I had been using an AnyCubic Kobra Plus that I picked up for ultra cheap as a customer return via eBay. It was good for getting my feet wet in 3D printing, but I got tired of constantly having to tweak all the settings in order to get good prints, and quite frankly the Bambu blows it away. And now I can do multi-color printing the easy way.

So the cases you see above are of my final design made on the Bambu printer.


3D Printing Station Update

I had to do some rearranging to make things fit into the allocated 3D printing station space in my shop, but in the end I think it came out quite well. And I also got serious with my filament storage, opting to use sealed containers with desiccant packs inside.

HeatSets are Out

In the previous 576NUC+ case design, the upper and lower halves depended upon heat set threaded brass inserts for the screws to screw into. However I wasn't thrilled about using these since they are very dependent upon correct insertion to avoid cross-threading issues. So in this new case design I've gone with screws and nuts, with both being recessed into the case halves, and black in color to make them virtually invisible.

I sourced these from McMaster-Carr, but probably something equivalent could be gotten at your local hardware store, not requiring a minimum purchase of 100.

P/N 91249A618  Black-Oxide 18-8 Stainless Steel Pan Head Phillips Screw, 4-40 thread, 1-3/4" long, pack of 100

P/N 90328A101  Black-Oxide Zinc-Plated Steel Locknut, 4-40 thread, pack of 100


Got Feet?

On the bottom of the case there are 4 circles showing the location of the rubber feet (Clear Vinyl actually). These reference circles were sized at exactly the same diameter as the feet produced by EverBilt which can be purchased either from Amazon or Home Depot.

P/N 158 724 1/2 in. Self-Adhesive Vinyl Surface Bumpers, 16-Pack


- Michael

Previous Post

C64-VGATE for Short Board
Today I finally had a chance to test a PAL version set-up in a 250469 Short Board that I converted from an NTSC 8562R4 VIC-II over to a PAL 8565R2.

It works!!!  Including using the same VGATE firmware and the same component values as the NTSC version.

I was able to boot up and play the game Turricon in all of its PAL glory, and it looked quite good. 

Initially when attempting the installation of the RF Modulator Replacement Interface PCB into the Short Board I encountered a couple of issues involving physical fit.

Update: May 2nd, 2024  Good news! I took a different approach to assembling the PCB and discovered that it could be made to fit without issues.

After mounting the motherboard with one mounting screw between the two existing DIN jacks in the C64C case... you can then set the RF Modulator Replacement PCB in place with the two bottom 4-pin and the single 2-pin support headers. Then adjust it to fit flush with the inside back of the case. After making sure that the board is pressed down and even, solder at least one pin on each header to lock in this alignment.

Note: the other 2-pin support headers on the left and right side are not required and should be left out.

When you remove the PCB you'll see that the support headers are slightly angled - this is perfectly fine.  Note: an extra piece of header insulator block is used on all the support headers as an additional spacer. I'll probably make an adjustment on the final gerbers to allow these to be straight up and perpendicular with the PCB.

With the motherboard out of the case, use a stepped-drill to enlarge the RF output hole to 9/16" diameter. Then with a round file, create a U-shaped slot in the rectangular channel switch hole which will allow clearance for the 3.5 mm jack. This is a very minimal modification to the case, and could be reverted to the original RF modulator with hardly anyone noticing the case changes.

If everything is correct, then you should see the result below.

Assemble all of the required components into the PCB, and then mount and solder it to the motherboard.

When I mounted the MAIN C64-VGATE PCB into the VIC-II socket, it was friggin tight as hell !!!  So I de-soldered it and replaced it with a 40-pin machine pin socket instead, which worked much better.

I didn't encounter this difficulty in my Long Board installation, so it appears that my Short Board used a different socket having very tiny holes.

This could be problematic for other people wishing to install one of these C64-VGATE boards in their machine, assuming it too has the same socket issue.

Since I'm feeling pretty good about the MAIN schematic, here's version 1.1 for download...

Nice to see this work without having two different versions of the firmware, and with the same values that work for both the NTSC and PAL HMOS VIC-II chips. personally I've experienced less issues with sourcing the HMOS vs. NMOS VIC-II chips, and found them to produce a very clean picture, while giving off considerably less heat. Since my C64-VGATE MAIN board can also serve as an HMOS to NMOS adapter, I'll be sticking with HMOS chips for all of my video upgrades.

- Michael

Previous Post

I have a few projects in various states of completion that have all been put on hold, or that have experienced limited progress over the last couple of months. This has a lot to do with needing to shift gears and applying most all my time towards my 'real' job which makes me money. I don't foresee this changing over the next month or so.

Here's a list of unfinished projects that are in the queue...

1. C64-VGATE: 90% completed, presently undergoing NTSC testing and final component selection. Also awaiting PAL testing. Not sure if this will see a public release, but if it does, then I need to possibly create a BOM and update the schematics to reflect any changes.
   
2. 576NUCplus4: 80% completed, need to correct boot-up behavior issue with the FujiNet module, and finish up BOM and schematics needed for release.
   
3. Heat Load Controller: 50% completed, cost of the custom aluminum front and rear panels is holding things up, as well as the actual need for this device which is predicated by my real job requirements.

I try to squeeze in project time for items 1 and 2 wherever I can, but it's very limited at the moment. And item 3 is not aimed at general consumption, being something that might prove handy for my real job as a specialized test instrument, so currently its priority is set very low.

- Michael

It's been a busy few weeks for me, so I wasn't able to post an update on this project until now.

About 2 weeks ago I was able to assemble one board set with an HMOS 8562R4 VIC-II chip and installed it in my 250407 Long Board, using it's built-in NMOS-to-HMOS configuration jumper and special piggyback socket.

After some initial experimentation, I settled on what appeared to be the best component values, including figuring out a way to boost the video output all the way up to 1 V P/P without causing any shadowing when bright colors were being displayed, something that I had previously seen during earlier attempts to increase the video to that same level.

EDIT 4/26/2024: I discovered that my scope wasn't accurate with the probes set to x1, but was when set to x10. So because of this I ended up pretty much reverting to my original values to achieve a 1 volt video signal. However I did do a few other adjustments to better standardize the chroma level.

I was also able to compensate for some thermal drift issues that caused misalignment of the VGATE black level with the one generated by the VIC-II chip by changing out several resistors from 5% Carbon Film types over to 1% Metal Film types instead. Metal Film resistors have a much better temperature coefficient of resistance than carbon film types.

Overall the video output of the C64-VGATE video board is quite excellent, and the VGATE technology eliminates the white line that's usually seen on the left side of the image when viewed on newer HD monitors. However in order to achieve the best results it did require some additional timing adjustments in the VGATE firmware.

A nice side effect of eliminating the white line was that my cheap S-Video to HDMI converter was able to properly do the conversion without weird color and contrast issues it previously suffered from. I believe the reason for this improved behavior had to do with the white line causing confusion as to what the black level really was, because it occurred so soon after the color burst signal. With VGATE active, there now exists both a proper breezeway and back porch in the video output, something that was lacking in the original VIC-II output. And apparently my HDMI converter likes it much better.

Keep in mind that this upgrade is much more than just the elimination of the white line. It's also meant to improve the video output quality utilizing triple shielding, a higher quality video output buffer, and by breaking out the S-video into a more standardized connection scheme. At the same time, there is also provision for stereo audio output, or composite video, or LumaCode video assuming the proper upgrades are also present. These last signals are broken out to a separate 3.5 mm jack, and with the addition of a simple RCA 'Y' adapter can be connected to standard RCA inputs.

Soon I'll be updating both the schematics and a download for the firmware reflecting these changes.

I also got some HMOS PAL VIC-II chips, so I should be able to see how this improved video system works for PAL as well.

Hopefully my next blog post will cover much more detail... stay tuned.

-Michael

Previous Post (Next Post)

Complete C64-Vgate Video Board Set Installed in Long Board 250407

The PCBs for the C64-VGATE project are entering the final phase of design and are looking very good indeed.

The top board as the silkscreen describes is meant to replace the stock RF Modulator utilizing a few of the existing mounting holes to line up the board with its S-Video and Audio jacks to the holes in the rear of the case. This is then interconnected with the C64-VGATE Main board via a short dual female Dupont Cable (I tried to make this a straight shot to keep the cable flat and untwisted).

The 3.5mm Stereo jack outputs the stock SID audio to the left channel, with provision to route either a 2nd SID audio to the right channel, or gives the option of having Composite or perhaps LumaCode video on this output instead. I got the idea to do this multi purpose assignment by watching a similar project on TheRetroChannel.

The C64-VGATE Main board contains the meat of this project, containing all of the actual electronics that perform the signal amplification, conditioning, and over-scan elimination of the video from the VIC-II chip which it piggybacks. The RF Replacement board is passive, containing only headers and jacks.

There is also provision for installing a later HMOS version of the VIC-II chip in the older NMOS boards, thus eliminating the necessity of an adapter board.

And finally if one is inclined to do so, a small hole can be drilled in the back of the case next to where the 3.5mm jack resides for an optional hard reset switch. I also glommed onto this idea from The RetroChannel's project, and although it got eliminated on their 2nd revision board, I decided it was a good idea to incorporate this idea into my board for that just in case scenario.

Schematics

After I do some more checks of the layout, gerbers will be sent off to JLCPCB to get a few samples manufactured for testing.

- Michael

Previous Post (Next Post)

I noticed that everyone working on cleaning up the video in the C64 likes to use the Easy Flash 3 menu as a reference image. So in keeping with this spirit I extracted the ef3-menu-1.2.0.crt contained in the zip file I downloaded from HERE and copied it too my Kung Fu Flash Cart's SD card, and then proceeded to spend the next 2 hours trying to take a picture of it from my VIZO LCD monitor. Why 2 hours you may ask? Well it all came down to trying to avoid the moiré pattern that the camera insisted was there, but really wasn't in reality.

Finally I achieved success and got a very clean image of what my eyes were actually seeing. And believe me it was every bit as good as the image below.

This looks so good, that I doubt it would have been noticibly better with one of the C64 HDMI solutions, other than perhaps a bit more crispness.

So not only has my alternative video board gotten rid of the over scan and resultant white line, it also produces rather excellent video quality as well. And because of the FMS6400CS video buffer/summer chip, it will also render some of the best composite video ever seen coming out of this system, without compromising the S-Video, or requiring a switch to disable it. In fact both video outputs can be used simultaneously without any issues or interference.

Edit: you may have noticed that there are some horizontal bands that appear darker. Yes that was really there and not an artifact created by the camera. As it turns out my last revision to the schematic where I had changed two resistor values to achieve a higher Luma output, was a mistake. After I changed them back that dark banding completely disappeared. Some times it's best to leave well enough alone.

The banding was in areas that had a particularly bright object being displayed, thus exceeding the nominal 1 Volt peak-to-peak video level, and causing this unwanted side effect due to the overdrive.

I'll be re-posting the schematic with the changes after I add the interface board schematic as the 2nd page.

- Michael

Previous Post (Next Post)

Well I started thinking more about this C64-VGATE board today, and specifically about the look of the video wave form as compared to what's considered the standard in the industry. And I noticed that what is called the Breezeway, is non existent out of the VIC-II video chip (reference image below for what it should look like).

In the NTSC standard, there is a 0.6 uS long blanking level just after the end of SYNC and prior to where the color burst is suppose to begin called the Breezeway. As I stated earlier this is virtually non-existent where the VIC-II is concerned, with it's color burst immediately following the end of the SYNC pulse. And another not as significant change is that the VIC-II outputs a rather long color burst, which in itself is not usually going to be a problem, but for the sake of making it a bit more standard it should be shortened (some video converters might take issue with it's longer state).

Luckily no hardware change is required to implement these changes, and everything can be adjusted within the PIC chip's firmware. Specifically in the Interrupt section of the assembly code as seen below...

In this new firmware version the Color Burst was shortened to 3 uS which is the equivalent of 10 cycles, with the standard being as little as 9 or as much as 11 cycles. The 0.6 uS Breezeway got re-instated. And in order to eliminate any left side over scan and to shorten the Color Burst , the Back Porch was lengthened by 2.6 uS, and set to begin before the VIC-II's color burst ended. This last part is about 1 uS longer than the standard, but isn't a detriment.

By the way where retro computer video is concerned, there is no separate blanking vs. black level, they are one in the same.

Here's how things compare with stock video shown on the left and VGATE enabled video on the right (Color Burst is in the middle)...

On the stock video output you can see that the Breezeway is extremely short and practically merged with the Color Burst which looks to be 15 cycles long. Whereas with VGATE engaged, and using the new firmware, we now have a bit more normal looking video with a standard 0.6 uS Breezeway and a 10 cycle Color Burst.

The firmware is now at rev 1.1 and available for download below.

I presently don't have the means to test this in a PAL machine, but if it's anything like the Atari VGATE version I think it will automatically scale to the slower speed (60 vs. 50Hz). If not then a PAL specific firmware version will need to be developed by adjusting the timing in the interrupt routine.

- Michael

Previous Post (Next Post)