I'm back after assembling, testing, modifying, and scratching my head. So much has happened since my last blog post. First off the CPLD being used for what I'll now call the MSX Enhanced Memory & Sound Module (name got changed to protect the innocent) didn't work on the first power-up. This had me very worried since it was my first go around at designing with a CPLD. However it wasn't long before it started working correctly, only taking a couple of tweaks to make it all better and then passing all the tests with flying colors.

So what is this MSX Module all about?
It takes the stock Colecovision memory configuration from a measly 1K up to a whopping 32K, and it throws in a second programmable sound generator (PSG), giving a total of 6 independent voices when combined with the original sound chip. However it can be put back into a stock 1K mirrored RAM mode with a simple register change, and the extra sound chip won't activate unless needed.

Having this new configuration in play makes it compatible with games that were developed for the MSX and SX platforms, making for very easy ports to the Colecovision system. This also means that it can take advantage of games created for the Super Game Module by AtariAge member opcode.

The ATF1500A CPLD (optional ATF1502ALS)  which acts like a Memory Management Unit (MMU), makes it possible to eliminate at least half a dozen 74XXX series logic chips, and allows for relatively simple CPLD core changes for altering any of the decoding characteristics. For this aspect, I utilized Protel 99 SE to design the inner workings of the CPLD, using it's schematic capture to PLD source code generator, thus keeping me in a graphical design environment not unlike what I use in PCB design.

Here's a peek into what just such a schematic looks like for eventual translation to PLD code. I believe this will be the final version for the project. Wow not too different than an actual physical component schematic!

What Happened Next?
With the proper CPLD in play, the system worked, and worked well. And thanks to AtariAge member PixelBoy, I was able to test right off the bat 40+ SGM/MSX derived compatible games. Of which most all worked, with only one exception turning out to be an issue with being run from an Atarimax Ultimate SD Cart instead of a real cart.

There were also a handful of other game prototypes that had issues, but for the most part compatibility was very good across the board.

However all was not good, and unfortunately I was seeing noise in my video output, which I temporarily fixed by substituting a linear 5V regulator for the switching one that I had spec'd. Of course this produced way too much heat and now required a large heat sink to disperse that extra heat. Good news is this got solved today when I found a very low noise version of a TO220 switching regulator, that actually turned out to be cheaper than the previous noisy one.

QUAD Board Problems
This is a board that fills in the missing circuits for using a quadrature based roller-controller, and better yet, also supports an alternative in a USB Mouse (wireless capable). Unfortunately I had screwed up with the Mouse USB port, having the power polarity reversed. I also had screwed up the orientation of the left and right mouse buttons vs. what a real controller has. So after some trace cutting and rewiring, it worked like a charm.

Then I discovered the game Armageddon, which is very much like Missile Command, having 3 missile silos protecting the city from attack. This game requires a roller-controller for targeting where the missiles will go when launched. However it takes 3 buttons from that controller to launch from all 3 missile silos, and I only had two of those available on my mouse, thus leaving one silo inoperative.

With the help of AtariAge member Chart45 we discovered that the middle mouse button would also pull down one of the unused I/O pins on the CH554, a microcontroller being used to translate the USB Mouse into something that the Colecovision can recognize. This middle mouse button would fill in for the missing button required to launch missiles from the formally inactive 3rd silo. But there was a slight problem, and that had to do with an inexplicable delay after pressing the middle mouse button before you would see a response on the I/O line, which was simply not acceptable. We are currently trying to solve this issue, along with the help of Chart45's brother who is a far better coder than either of us.

Changes are in the Works
There will be a 2nd revision of most all the boards associated with this project, and subsequently a 2nd order will be placed for new sample boards. This is looking to happen about 3-4 weeks from now once all the new aspects and fixes have been proven out. So stay tuned for more news to come on this project.

- Michael

It's been awhile since I've added any blog entries, and all I can say to that is sometimes life gets busy, and this is especially true around the holidays.

So what have I been up to? Quite a bit actually...

A few months back I got off on a tangent from my usual Atari stuff, and headed down the Colecovision path instead. Reason being is that I missed the boat on buying one of these in 1982, but had always intended to do so. Unfortunately I lacked the necessary funds at the time. So nostalgia kicked in and I found myself on an Adam/Colecovision forum at AtariAge. It's there where I discovered two alternative CV motherboards were either in process, or apparently been completed. This got the gears turning in my brain...

So per usual I started thinking how could I do this even smaller, possibly even 576NUC+ size.

To get this to happen I knew I needed to first understand how the CV was built, and to this end I discovered a great CV Schematic created by AtariAge member ChildOfCv. Next I needed a real Colecovision console to run experiments on -- enter eBay.

I picked up this console in very good condition for $100, and it came with everything you see here. the only problem being that it didn't work when I received it, which the seller had mentioned in the listing.

So no problem, I figured this would aid me in my quest to understand how a CV actually works by making me troubleshoot the dead one I just got.

Turns out that several of the video DRAM chips were bad, so I needed to change them. However that was easier said than done since all the chips were soldered in place. But after a marathon desoldering session (there are eight individual 16Kx1-bit DRAMs being used for video memory), I replaced the chips with sockets, and not having the 16Kx1 DRAMS on hand, I substituted some left over 64Kx1 chips from an Atari 1200XL. Next I made sure to do the board mods to eliminate the -5V and 12V that powered the original DRAMS, which not only wasn't needed anymore, but would have been destructive to the new 5V only DRAMs.

After the repairs were completed I powered it up and got crappy RF out that at least showed that the console was now working. But there was still a problem that was causing very erratic video output, and the system would occasionally hang. This was made even worse by touching the power switch or slightly flexing the PCB. Turns out I just got introduced to another common failure in a CV, and that is the slide power switch contacts being dirty. Since it switches 2 different power signals (+5V and +12V), when it starts getting flaky it does some very crazy things to the operation of the system. The usual fix is to spray it with DeoxIT and then rapidly switch it back and forth several times, but this failed to completely work for me (although it did help a tiny bit). The better fix is to completely disassemble and clean the switch contacts, but I was too impatient to do that and instead soldered jumpers, and then just plugged the power adapter into a plug strip and used it's switch to control power. This worked, and the system was now stable.

Next problem was to have something other than RF for the video output. Looking around the CV forums I discovered that a simple mod could be done to get composite video out of the console, documented by none other than Ben Heck. So I did that, and got a much better picture. However what I really wanted was S-Video for an even better result. This was no easy task to undertake at first glance, since the output from the video chip is R-Y, B-Y, and Luma (+sync). Basically Component video. Component is good, but I really wanted S-Video since many of my monitors support that.

So I dived in and discovered how that might be done. Fortunately for me, the CV's LM1889 RF modulator chip also encodes a Chroma (color sub-carrier) signal from both the R-Y and B-Y signals before passing them to the actual modulator section of the chip, and this is broken out on pin-13. It became a fairly simple matter to intercept that Chroma output before it was mixed with the Luma, and feed that into a video buffer chip (FMS6400), along with the separate Luma. Now I had high quality S-Video which looked really nice!

Onward and Upward

So now that we had a working console, it was time to move on to the original product idea, that being something I will call the CV-NUC+. This would be made small enough (4.5"x4.5") to fit into a slightly modded 576NUC+ 3D printed case. So as to be expected I made a few false starts in this endeavor, and of course things got more complicated as feature creep took over. But eventually the overall design started to gel and take shape.

Here's what the final form of the Main PCB design looks like today.

So this ends Part 1 -- stay tuned for the adventure to continue, where I'll delve into the design of the individual boards that make up this system.

- Michael

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

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.

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)

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

32K Quad Language (27C256 EPROM)

1. SLOT 1 = BASIC RevC
   
2. SLOT 2 = Altirra BASIC
   
3. SLOT 3 = Assembler/Editor
4. 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

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

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

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.

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

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