Author: Doc TB

ATX2AT Smart Converter – Negative Rails

While designing the ATX2AT Smart Converter (and especially when I did the modifications after the Kickstarter campaign – I’ll write about them later), I had to study how negative voltage (-12V & -5V) are used to implement everything correctly.

-12V is not really a problem: this power rail is still available in the current ATX Specification. I tried and measured current consumption on many motherboards and ISA cards to finally decide to protect the rail with a 500 mA resettable fuse (PPTC).

Generating the -5V rail needed by some ISA cards was a bigger challenge to properly size the components. Basically, there is two methods to get -5V from a modern ATX PSU:

  •  DC-DC converter. It can deliver tremendous power (several amps) on a -5V rail converted from +12V or +5V. But it has drawbacks: DC-DC Converter are electrically noisy. It also requires more components and are most expensive.
  •  Linear Regulator. It derives -5V from -12V by converting the unneeded voltage (7V here) to heat. Linear Regulator doesn’t generate electric noise and are quite cheap these days. Its major drawback is the heat they generate, which limit the maximum current they can deliver.

Should I go for a DC-DC Converter scheme and get a noisier current at a higher cost (in order to get more current), or stay with a linear regulator? It was time to study the needs.

A lot of old ISA cards requires -5V internally. Many of them integrate their own 7905 linear regulator and don’t use the -5V rail provided by the power supply through the motherboard. For example, the Media Vision Pro Audio Spectrum 16 (PAS16) is one of them: you can see the 7905 on top left of the board.

But many boards rely on the -5V provided by the PSU. One of them is the famous Sound Blaster 2.0 (CT1350) :

But what is the -5V used for? In all the ISA Card I studied, the -5V is used for the same stage: preamp. Basically, a sound card generates an analog signal from a digital bus with a DAC (Digital to Analog Converter). On the picture above, the DAC is the tiny IC in the center of the board marked “Y3014B”. It’s a Yamaha YM3014B. The output signal from this DAC is very weak and must be amplified before reaching speakers.

First, the analog from the DAC is preamplified with the two ICs marked KA3403 just above him. It’s a signal conditioning stage only. They are simple low-power operational amplifiers used to boost the voltage amplitude of the DAC signal to a bigger one. But in order to connect speakers, you need a much higher current/power capability. So the signal is then fed to a power amplifier: the ST TEA2025B located on the right of the board. This schematic is very common and used in almost all ISA sound cards.

-5V is only required for the KA3403s (the preamplifier stage). The datasheet available here tells us the output load is spec’ed at 2K Ohm so each KA3403 can output 2.5 mA x 4 opamp = ~10 mA. We have two of them and let’s add the power supply current (spec’ed at 7 mA max) and the Sound Blaster 2.0 will never need more than 2 x (10+7) = 34 mA on the -5V. That’s an absolute maximum in a worst-case scenario. Actually, the “typical” power supply is 2.8 mA and the load is much higher than 2K Ohm.

After the math, let’s check in real world:

As you can see, the actual load on -5V is only ~6 mA. This is a low current, but it’s required to get sound. As soon as I disconnected the -5V line, the sound card stops working.

Preamplifiers are very sensitive to electric noise. For such low current requirement, a DC-DC converter is useless and even harmful to sound quality.

The same schematic is found on all sound cards that requires -5V. Here is a Sound Blaster CT1920 AWE Upgrade “Goldfinch”:The -5V line is also used for the TL074C quad opamp (very similar to the KA3403) and outputs only a low power “Line Out” Signal. I measured the typical current slightly below 10 mA.

Finally, you probably wonder what’s the point with other ISA cards that are NOT sound cards. Short answer: same! None of them requires more than a few milliamps on -5V. For example, here is one of the rare ISA Network cards that needs -5V to work properly, the 3COM Etherlink 16 TV (3C507-TP) :

Connected to an Ethernet 10Base-T switch, it only requires 2.5 mA on -5V.

Conclusion: the maximum current required on -5V is very low and we need a voltage with low noise because it is usually used to fed preamplifiers. A linear regulator is definitely the way to go. On the ATX2AT Smart Converter, you will find a linear regulator protected with a 100 mA resettable PPTC fuse.

ATX2AT Smart Converter – Live On Kickstarter!

Thank you to everyone who has expressed interest in the ATX2AT Smart Converter!

After some major changes in my personal life in 2019, I’ve resumed the work on my projects to bring them to fruition. The ATX2AT Smart Converter is the first one to reach the production stage, and I’ve decided to go on Kickstarter to try the whole process as a creator. I’m a “Super Backer” there with 140+ projects backed, so I had some experience with the platform.

I would like to tell you that the Kickstarter Campaign will start tomorrow, Monday 25th October, at 18:00 UTC (19:00 CET / 10:00 PST / 13:00 EST).

Project link : https://www.kickstarter.com/projects/doctb/atx2at-smart-converter-protect-your-retro-hardware

Updated Project description : https://x86.fr/atx2at-smart-converter/

The price for a complete ATX2AT Kit (w/ OLED display & cable) is set at 29€ for Super Early Bird (first 10 backers), then 35€ for Early Bird (next 25 backers), then 39€ (KS Special).

Be sure to be on the first ones to grab one at the lowest cost!

Investigating the HCF (Halt & Catch Fire) instruction on Motorola 6800

While adding support for the Motorola 6800 on the Universal Chip Analyzer, I remembered the famous HCF instruction supposed to be present on that CPU. The Half & Catch Fire opcode is an undocumented and semi-mythical machine instructions with destructive side-effects, supposedly included for test purposes on several well-known architectures going as far back as the IBM System/360. The Motorola 6800 was the first – and almost only one – to have a HCF instruction well-known by the developers back in the 70s. It doesn’t really destroy the CPU, but makes it switch into a kind of debugging mode. Allegedly, HCF instruction on the 6800 should toggle the address lines in order very quickly. Legend added: up to the point that some support component might catch fire!

I read many resources online, including the Wikipedia page, about the HCF opcode and I found many contradictory information. It seems very few people actually tested the 6800’s behavior by themselves. Good news: the UCA has been created for this kind of experiment!

According to Wikipedia, the HCF opcode is 0x9D and 0xDD. I also found some other source locating it at 0x14, 0x15 or 0xCD, like on this Motorola 6809 and Hitachi 6309 Programmer’s Reference.

And here is another (different!) opcode matrix from here :

I have also investigated some other undocumented opcode (0xBD, 0xEB, 0xFB). All tests has been done on a Motorola MC6800P with a 1 MHz clock.

  • 0x14 / 0x15

Inserting 0x15 opcode doesn’t seem to have any effect on the CPU at all. Both opcode seems to be treated as NOPs, wasting 2 machine cycles. Registers unchanged. 0x14 executes a AND between both accumulator (A & B) and stores the result in A. However, only the later MC6800P seems to support this. An early XC6800 prototype does not to fetch the 0x14 opcode correctly.

  • 0xCD / 0xED

Both instructions crash the 6800 and make it unable to execute any more code until a full RESET is triggered. Exactly 64 ms after the opcode has been fetched, the CPU starts to toggle address line almost in order, but with many glitches and only for A0-A6. A7-A15 remain erratic.

Result of 0xCD or 0xED undocumented opcodes on a Motorola 6800 on lower address lines

But more interesting, I noticed a strange behavior on the upper address line. The 5 upper address line (A15-A11) started to count in reverse order from 0b11111 to 0b00000 at a very slow, human-readable, rate :

Same on upper address lines

The whole process (similar with both instruction) takes ~8 seconds with the 0xCD opcode and much longer (~60 seconds) with the 0xED opcode. Has this been added for simple human debugging (without oscilloscope or logic analyzer, costly in the 70s), or is it just a glitch? Hard to tell.

  • 0x9D / 0xDD

Here we find the expected “HCF” debug instructions. 64 ms after being fetched (which is quite long), the CPU starts to toggle all address lines in order, very fast (500 kHz for a 1 MHz clock) and with a clean square wave.

Famous HCF (0x9D/0xDD) opcode

After the HCF has been fetched, the 6800 stops responding to interrupts. A hard RESET is the only way to resume operations.

  • 0xFD

While messing with invalid opcode, I found another HCF instruction on the 6800. This one seems to behave exactly like the 0x9D/0xDD HCF, but is twice slower : 250 kHz instead of 500 kHz.

It seems 0x9D/0xCD/0xDD/0xED/0xFD are all related to HCF, but only 0x9D, 0xDD and 0xFD produce a clean (glitch-free) output.

The U.C.A. now supports Motorola 6800!

Finally, two years after a Intel 8088 (almost) booted for the first time on a very early UCA, I’m glad to announce the support for the last major 8-bit CPU : the famous Motorola 6800 !

The Motorola 6800, released in 1974, was one of the most advanced CPU in the 70s. Being TTL-compatible and only requiring 5V power, it was also  easy to use for hobbyist (albeit a two-phase clock was mandatory). Unfortunately, its high price prevented the 6800 to reach the DIY “mainstream” market. Many computer pioneer preferred the MOS 6500 and the Intel 8080, but Motorola  soon released a much cheaper, MCU-revision of the 6800 – the 6809 – that has been very successful.

The architecture of the 6800 is quite simple but efficient. It uses two accumulators, a 8-bit bidirectional data bus, a 16-bit stack pointer, and a 16-bit dedicated address bus that could address 64 KB of memory. Unlike the Intel 8080, the Motorola 6800 uses memory-mapped I/O : it doesn’t include specific instructions for I/O and they are handled as standard memory accesses.

Implementing support for the 6800 on the Universal Chip Analyzer (U.C.A.) wasn’t too difficult. The dual-phase clock was the main issue, as timings are usually tighter than with single-phase clock. Another issue was the UCA adapter. I designed it to support both MOS 65xx and Motorola 68xx, but the cheap chinese ZIF Socket (3M clone) I soldered on was crappy. The contact between the adapter and the main ZIF Socket wasn’t also very good, due to the standard 2.54mm pin header. Too thick, too square. So I build another adapter with a much more efficient Socket (an ARIES low-profile, burn-in ZIF Socket) and some new pin headers that mimic a real CPU :

The new Socket with “real” CPU pins (front) VS the old one (back)

Everything worked as expected and very reliably with that new adapter! Here is the UCA testing a Motorola MC6800P at 2 MHz and a very rare prototype (Motorola XC6800B) at 1 MHz :

Testing frequency can be set at 1.0 / 1.5 / 2.0 or 3.0 MHz to match the most popular 68xx.

Support for Motorola 6801/6802/6803/6808/6809 is planned soon.

More important, a brand new era is coming for the UCA, as I can now focus on much more advanced, 32-bit CPU. Many news planned soon!

U.C.A. Test & Calibration Adapter

Not really some big deal here, but I wanted to share some new “internal” tools I developed for the Universal Chip Analyzer. I ship them quite slowly due to long PCB assembly process, but the final testing process was also quite time-consuming. I used to test all U.C.A. with every supported CPU and, if something goes wrong, I inspected every IC and connector to find the issue.

I was a bit tired so I build that “calibration & test adapter” :

With a special test program loaded inside the FPGA, I’m now able to test every pins for stuck-to-0, stuck-to-1 and shorts in seconds! I have also added precision resistors to calibrate the internal shunt amplifier & ADC. Calibration data are now stored inside the internal EEPROM (and saved locally for any UCA serial#).

I’m also testing a new kind of “header” for Adapter’s pins. Previously, I used standard 2.54mm headers. They worked fine in most case, but the pins are much thicker than standard CPU’s pins. I was able to find these connectors that almost perfectly mimic CPUs pins :

They’re not cheap, but I will probably use them for active adapters like the 8080 Adapter.

Stay tuned for much more news soon!

The U.C.A. now supports MOS 6502!

Since the end of last year, I faced a lot of change in my personal life: new job, new house, new car, etc. Except my girlfriend, almost everything else changed in the last 3 months. Damn exciting, but I had very little time to spend on side projects.

It’s now time to resume the work on the Universal Chip Analyzer! My next goal was to add support for the very successful MOS 6502, an 8-bit microprocessor released in mid-70s that was at the heart of many designs well into the 80s.  The original 6501 (circa 1975) was pin-compatible with the M6800 while being much less expensive, but Motorola sued MOS almost instantly and the 6501 has been withdrawn very quickly. The 6502 shares the same internal micro-architecture with the original 6501 but uses a different pin arrangement.  It’s a very simple CPU, with a 8-bit accumulator, two index registers and a 16-bit address bus (able to interface with a maximum of 64 KB of memory). The 6502, just like many other early CPU, doesn’t have a specific way to handle I/O: you must define an arbitrary memory-mapped I/O range and configure your hardware accordingly.

Several variants of the MOS 6502 has been launched through the decade, some of the them with reduced addressable memory (6503 to 6507) and some others with additional features (6508 to 6510, …). Many early computers and consoles are based on a 6502: Apple IIe, Commodore 64, Atari 2600, Nintendo NES, Oric Atmos, etc.

Adding support for the 6502 wasn’t as easy as I expected. The main issue came from the timings. Usually, I drive all the logic inside the FPGA with the the clock signal generated locally and sent to the CPU. That doesn’t work with this particular CPU because it integrates an internal two-phase clock generator used to sync external IC. So, I finally had to feed these two clocks back in the FPGA and sync the internal logic with them. Some delays were needed to match the original timings (FPGAs hate delays) but everything now seems to work properly.

Here is the UCA testing a NMOS Rockwell R6502P at 1 MHz and a much more modern CMOS Rockwell R65C02 at 4 MHz (overclocked from 3 MHz):

Testing frequency can be set at 1.0 / 2.0 / 3.0 or 4.0 MHz to match the most popular 65xx

I’m waiting to get some samples to support other 6502-based CPU like 6510 or 28-pin 6503 -> 6507. A Rockwell 65C112 has already been seen working properly. The passive adapter isn’t final now, because I still need to work on my next goal: the Motorola 6800! This CPU Is the last (but not least) big one I need to support with the UCA. Stay tuned!

Pace è Salute !

Chers lecteurs, chers lectrices, chers tous,

Le numéro 38 de Canard PC Hardware marque la fin de mon règne despotique en tant que rédacteur en chef irascible : je quitte Presse Non Stop après 13 ans de journalisme total et plusieurs centaines d’articles scandaleux qu’aucun éditeur raisonnable n’aurait jamais dû accepter de publier. J’en profite également pour faire mes adieux à la presse en général.

Avant de rendre ma carte de journaliste, je voulais vous remercier sincèrement pour ces presque 10 ans où vous m’avez suivi sur CPC Hardware voire – pour les plus vieux d’entre vous – depuis 2001 sur x86-secret.com.  Je souhaitais aussi vous expliquer une partie des raisons qui m’ont mené à cette décision.

Continue reading “Pace è Salute !”

The U.C.A. now supports Intel 8080 !

A new milestone for the Universal Chip Analyzer (U.C.A.) : it now supports Intel 8080s, one of the very early CPU released by Intel in 1974! I originally planned to create a complete UCAS (UCA Shield) to support the 8080, but I was finally able to design a small UCA Adapter for the iAPX86 UCAS.

This is the first “active” UCA adapter (both the adapters for Zilog Z80 & Signetics 2650 are only passive). The biggest issue with the 8080 was the power requirements : unlike all CPU supported so far by the UCA, the 8080 doesn’t work with a single +5V supply rail. It also needs +12V & -5v. +12V has been created from +5V with a TI DC-DC Boost Converter and -5V is generated using a charge-pump IC.

Some signals like the two-phase clock are also not TTL compatibles and requires a true MOS voltage swing (0-12V). For the first alpha prototype, I tried some high-speed transistors as voltage translators, but I wasn’t able to meet the tight rise/fall time (~25 ns) expected by the 8080. I then tried a Dual MOSFET driver and it worked perfectly. All components are packed on a tiny adapter the size of the previous passive ones.

Testing frequency can be set at 2.0/2.6/3.1 or 4 MHz

Intel 8080A

Intel D8080A-2 ES

The expected “retail” price for the 8080 UCAS Adapter is ~$25.

Stay tuned for the next big announcement!

UCA progress & Xeon ID UCAS (Early prototype)

Some news about progress done on the Universal Chip Analyzer :

  • About the UCA itself (modded Mojo v3 board), I found a reliable source for assembled board and they will be modified soon. All firmware features are now implemented and working correctly. UCA FW v1.00 is close.
  • About the iAPX86 UCAS, a first batch has been ordered from Elecrow, but they soldered a wrong component on them (well, 50+ wrong components). So I had to send back the whole batch to China. Unfortunately, the package now seems frozen somewhere in China! Tracking is EW001348809FR if you want to check… If it get lost, I will lose $400 and I’ll have to order another batch. Sad.
  • Anyway, when I got the package from Elecrow, they added two unsoldered PCBs, so I was able to assemble one of them myself to validate the final 1.00 PCB. Good news: everything is working correctly! Signal integrity is much better than on ES/QS, up to 50 MHz, and all hardware bugs are solved. VERY good news. I tested quickly the new expansion port (dedicated for future uses) and it also works as expected.
  • I’m working on a new UCAS Adapter for the Intel 8080. The goal is to use the iAPX86 Shield to test Intel 8080. They requires +5/+12 & -5V, so the Adapter will be an active adapter, but the 8080 is TTL compatible. The design is done and proto PCB will be ordered soon.
  • I’m also working on 3 different UCA Shield :
    • The MOS/MOT UCAS for Motorola 68xx & MOS 65xx CPUs. There is no real technical difficulties on this one from the tech side.
    • The MCS-4/-40 UCAS for Intel 4004 & 4040. LOT of technical challenge here. Interfacing a 45+ years old PMOS CPU that requires -10V/+5V with a modern 3.3V FPGA is quite hard. Especially while using ONLY modern ICs. I’m still working on the schematics right now, messing with comparators, zeners and transistors. The HDL code will not be easy, but I have some ideas.
    • A new “Universal PGA Shield” (UPGA). I finally decided to cancel the iAPX-286 Shield that I already showed working on early stages. Why? Because having a 286 UCAS, a 386 UCAS, then a 486 UCAS and another 486 3.3V UCAS, and another 68000/68010/68020/etc. UCAS will be  expensive. The UPGA UCAS will support all of them at once, with (quite cheap) interchangeable Sockets. The design have been done, focusing on the fastest 486DX/DX2/DX4.  If my design works for them (not proven right now), it will also works with all slower CPUs like 386 or 286. Schematics are done and a nice 4-layer PCB has been designed. It’s a very complex PCB, so I don’t expect the Rev 0.10 to work without massive rework. Fingers crossed!

Now, let me introduce another concept for the UCA : the Xeon ID UCAS! I have big plans for the Universal Chip Analyzer as a truly “Universal” chip analyzer, and this is one of them. Xeons are sometimes hard to identify, especially Engineering Sample (ES are often unmarked, available in various flavor with the same part number, or unknown in databases). Xeon motherboard are also a nightmare to work with, expecting exotic RAM, 2- or 4- CPUs, with BIOS restricted to a few S-Spec. Fortunately, “True” Xeon  – like MPs but not the rebranded Desktop CPUs – comes with an embedded “PIROM” chip, used by the motherboard to check their specs without booting the whole CPU. The “Xeon ID UCAS” uses that PIROM to ID the unknown Xeon.

The Shield interfaces with Socket probes to connect with the CPU. Right now, I have a working Socket 603/604 Probe and a LGA1567 Probe, but the UCAS should also work with Pentium II/III Xeon (Slot 2) and up to modern Xeon (LGA2011/3467).

Many information can be grabbed that way. Here is an example with a quite-old Xeon (Gallatin) QF75 ES  :

And here with a later Xeon (Tulsa) QQBB ES (Intel Xeon 7140M) :

lightboxI also made a small video to let you see how it works:

That’s only a proof-of-concept right now, and the Socket Probe will not be cheap if ever sold, but it looks quite nice 🙂

Stay tuned!

 

Introducing the ATX2AT Smart Converter

Some weeks ago, I fried a nice 486 motherboard I got in a scrap lot at first boot. Some capacitors were shorted and my ATX PSU, coupled with a regular passive ATX2AT adapter, led to massive damage (burnt traces). That short was not “short enough” to trigger the (very large) PSU overcurrent protection. The motherboard was FUBAR by the time I noticed something went wrong and manually switched off the power (within 3/4 seconds).

So, while waiting for the first batch of Universal Chip Analyzer being assembled, I created a “Smart” ATX2AT Converter, featuring fully-programmable electronic fuses. I also added a small OLED display for monitoring purpose, a -5V regulator to regenerate that missing voltage (required by some sound cards) and some additional filtering capacitors. The project will ultimately be open-source and can be adapted for any other retro-platform that require -12/-5/+5 and/or +12V.

All technical details are available on this page: https://x86.fr/atx2at-smart-converter/

I’ll be happy to hear your thoughts and suggestions about this project. 🙂

Some friends already expressed an unexpected strong interest for this adapter. If we’re only a few to want one, I’ll assembled them manually, but if we’re more than a few, I can consider having them built by a fab to reduce costs.