Project to create an ATX 80286 mainboard based on the IBM 5170

[rodneykn]

So after my recent findings to further improve the PC/AT system controller derived from the original IBM 5170 technology, I am currently looking into a follow up REV2C system design. Since the completely revised system controller design is also applicable in the PLCC/TTL based design iteration, this also brought me on the path to look into how I could even further optimize the usage of the CPLDs to help form a PC/AT system, where we make use of CPLDs assisted by TTL bus logic to achieve an alternative system design.

The new design will have the following features and specifications:
- 3 84 pin PLCC CPLDs will be used
- a lot of bus logic will be handled by TTL ICs
- the design will feature onboard 1MByte SRAMs
- system address bus will be generated by CPLDs.
- possibly I will include an EMS system supporting RealDOOM by making use of TTL bus and mux components to support the same two page register SRAMs as the REV3E system
- if successful, the XMS/EMS RAM will be flexible for dual usage, same as the REV3E system

The CPLDs will be named:
- Address bus driver CPLD
This CPLD will generate all chip selects including EMS and drives the highest system address lines.
- IO decoder CPLD
This CPLD does all IO decoding and controls enabling of the EMS system by the driver. In addition it drives the lower system address lines.
- System controller CPLD
This CPLD does cycle control, generates the dynamic 80286 clock, generates the SA0 and SBHE signals for byte control, outputs the commands and merges these with DMA command inputs.

So here I will look into whether we could still feature an EMS system using regular logic to provide access to the page register SRAMs, and switch between XMS and EMS operation of the combined SRAM footprints.

I have completed the Address bus driver CPLD design where due to pin shortage I will make use of external mid DMA address latches, then combined and connected with the CPU side of the address bus, and we will make use of the CPU being in HOLD status to be able to apply the mid DMA address section to the address bus driver inputs. So the Address bus driver CPLD will handle all memory decoding in one chip, and we don't feature a separate EMS controller. Part of the EMS controller functions will be handled by TTL chips in that scenario. So I am looking into whether that would be reasonably feasible to do it that way.

Next I will work on the REV2C IO decoder design which will do some additional decoding for the EMS enable and control signals. I still will need to see whether I can have enough pins available for this. The idea is to also generate a portion of the lower system address bus with the IO decoder. Together the two CPLDs can handle the entire system address bus, at least, in the best way as this could be achieved with the limited small CPLDs. When the DMACs drive the lower system address lines, the IO decoder CPLD will release the bus during DMA, so basically the IO decoder can be viewed as a CPU-only component. In the Address bus driver, at the edges of the shifted aligned bus control between DMAC-1 and DMAC-2, the Address bus driver handles the separated sources where otherwise we would have a bus conflict in certain cases. Here I will also attempt to use the ungated 286_A20 line to drive the LA20 signal on the slot. I have previously done tests and the VGA controller supports that without issues. Of course, such a system will only function when the system RAM is not on the slot, which in our modern design is always the case since we are not using memory boards that cross the 1MB boundary on the slots. I could even do tests whether it's possible to POST the system with /MEMW and /MEMR only since more advanced VGA controllers like the Cirrus Logic will observe all the highest address lines to decode the full address locations.

I am also going to do some testing with the REV2C hand wired build to see whether we can make do without the LAxx address transceiver. Theoretically when the CPU and DMA page mapper don't drive the CPU address bus and go into tri-state, we can then let a ISA bus master drive those lines from the slot and we can decode them inside the address bus driver CPLD for driving the system SRAMs during bus master cycles. In effect, the transceiver is used for buffering the CPU address lines A17-A23 however since there are not so many cards on these high memory address lines anyway, in fact in most cases only the VGA controller itself, we can then simply let the 80286 CPU drive the lines directly. Basically I am doing the same in the REV4 QFP FPGA design. The QFP is severly limited in pins so we will need to use some reductions to be able to make the design work.

I have zero budget so if you want to sponsor some parts and/or help me pay for PCB production, please get in touch with me. In the future we may be better off using more modern FPGAs if CPLD prices are increased.

I am not sure after the REV2C designs are finished what I am going to do next. I still need to rework the REV4 FPGA design and build up the board. Next I may focus on a 80486 design that largely works on 3.3V logic. The 80486 does a lot of internal byte path handling so this doesn't need to happen externally in the system, which simplifies the design somewhat.

Kind regards,

Rodney

[rodneykn]

I have previously done some testing on the REV3E system and this led me to believe that this system may be capable of running at higher clock speeds.

Since we now have a System controller CPLD design which is fully synchronous by using double the 286_CLK clock frequency on the CPLD clock input, this opens up a path to start testing at 80286 operational frequencies above 20MHz in this design model. So far, I have verified the system by using a 80MHz oscillator which works perfectly and completely stable.

We can find some 100MHz oscillators, for example, on the market however this will still present a limited test opportunity so I have decided to go the path of wanting to use a variable oscillator. I have done some experimentation using a transistor oscillator that uses a tunable LC tank circuit however my experiences varied in terms of the oscillation range, because here a lot of RF frequency factors are affecting the circuit operation. So this path would require me to manufacture some type of solderable PCB where I can add or remove components from several solder points, and for example the bottom layer would then be all ground plane. So that type of PCB is more RF compatible and will not offer so many stray capacitance etc. Anyway that is one way, however after some consideration, I have decided to go with a microcontroller setup that controls a SI5351A clock generator Adafruit module.

I have some ATMega328P chips in my parts box and my Galep-III programmer can directly program those, so I will do something along these lines:

- Adafruit SI5351A module connected directly to the oscillator pinout shape like a socket or something
- ATMega328P controller
- SSD1306 display module to output the frequency information
- a few buttons for up and down, and setting the increment size step
- serial debugging interface that drives a PC terminal

So the SI5351A module will be directly connected to the REV3E mainboard, and we feature a small I2C cable to the ATMega328P board, where we can press the buttons to set the test frequency and test the system to find the exact clock ranges. Later I will make some changes so we an enter a frequency directly in a PC terminal window, and we may wire a RESET connection so we can RESET the system automatically after each new frequency being set.

This idea will allow me a much wider range of test capability where I can also test the lower clock regions. Just to see which values are 100% stable for operation. It will be interesting to test the system at very low clock frequencies, and at the highest of course.

If this works well, I may feature the SI5351A as a board option if someone wants to build such a system. The connected ATMega328P can be easily added on a mainboard design where you can plug a PC terminal, or connect some buttons, etc to make the system fully flexible in terms of the frequency range. The display and some buttons can be possibly added to the front panel of the PC case. Software could be made to each time RESET the system after updating the clock frequency, and in the software programmed into the ATMega328P, we can set a base clock frequency to initialize by default. If we could update the SI5351A within the 2 second RESET pulse duration, this may even initialize the system transparently without even needing to issue another RESET pulse. So if we can vary the clock speed with high resolution, this should allow us to detemine the absolute clock limits of the REV3E, and possibly later on in a REV2C edition design if there would be some interest for that.

I am working with google AI to put this solution together and I will test the programming it provides. It will surely save me a lot of time by extracting the exact information I need without needing to go through example code, modify and test and experiment etc., which is of course cool to go through these steps myself, however it will be very time consuming, same as using the transistor oscillator, with enough time and experimentation that also should work out fine. However I just want to find a suitable quick solution that suits the needs for doing overclock range testing. If this all works out, I can think about how to add this as an option to certain designs, especially those systems that don't have a FPGA yet where you could reprogram the FPGA PLL to modify the clock speeds. So for the REV4 system we will hopefully have an easier time to modify the 80286 clock speed.

Come to think of it, on a possible board design where we feature an ATMega328P or similar controller anyway, I could also use that controller for doing other tasks such as resetting the system, possibly powering it on 5V standby power and letting the controller also respond to the power button, and possibly output other information on the display. Maybe we could use software to write to the controller, let it translate the POST codes to the front panel, and after POST finishes, writing other status information about the system to the display via port 80h.

Possibly if the work with this little controller chip goes well, I could make more elaborate use of the thing in the future. On the REV3E, we have 4 spare pins on the IO decoder CPLD directly on a header, and we also have the display output pins which we could double as a I/O port to the little controller for the system to interface directly to it. This could be used for all sorts of experimental stuff like maybe write a frequency update value to a IO port and RESET the system to initialize that frequency. If you have some software that needs to run slowly, this could enable some custom clocking features. A simple executable program could update the clock speed to any value and then RESET the system automatically.

Kind regards,

Rodney

[rodneykn]

After doing a lot of soldering on the REV4 QFP mainboard, I want to document the process of building the REV4 QFP system here.
I more in depth description of my process can provide a builder with a few guidelines regarding the order of assembling and testing the mainboard.

So I first soldered all the 0402 capacitors on the bottom of the board, then I soldered the 3 regulators in place. Also wait with the two power diodes until the SMD capacitors around them are in place. Then the work is not so hampered with the iron. The components are tightly spaced in the design because this is electrically the most optimal situation. Practically for soldering this requires a little strategy what to do first.

In the initial batch of components to be soldered, I also added the 32MHz oscillator for the FPGA.

I have a warning regarding the XC6706 regulator used for the 4V power net.
This regulator is apparently not very well resistant against soldering heat at all.
I apparently managed to kill the first one only by soldering it, and got 0V on the output.
So I removed the regulator and cleaned off the solder from the board.
After replacing it, I got the 4V net up.
It's my advice to first solder the input and output capacitors that are next to the XC6706 regulator, then position the regulator and very briefly solder the input and output pins on their pads. The ground in the middle you can leave loose, and instead you can again briefly solder the tab to the ground pad underneath. So the shorter with the iron, the better. I would suggest adding flux so the solder on the pins flows quickly so the tiny regulator can cool down faster. So it's not a good idea to spend more time to flow the solder underneath the whole ground surface of the regulator, that may be too harsh for it.

So after soldering the three regulators, I proceeded to solder all bottom SMD components. Then I proceeded to add the standby power LED, the ATX power on RESET ICs, the ATX power connector, and a few capacitors next to it. Also the power, reset, speaker, power LED pinheaders are useful for connecting a switch and power LED.

I have also soldered the top clock generator ICs and passive components for these including the crystals.
So the whole idea is that you can plug in the ATX connector, power up the board using a pushbutton switch power cable, and monitor the ATX power with a power LED on a short lead. The Standby LED can signal when the ATX PSU is connected and switched on, which applies standby power.

In addition, in the first batch of soldering, I also soldered the 208 pin Altera MAX7000S CPLD onto the board, and added the JTAG pinheader.

So I proceeded to power on the board in a safe place on the table, and you can take a multimeter in voltage mode, hold the ground pin on GND, and then after powering on the mainboard, you can check inside all capacitor footprints what voltage that footprint should carry, and check all of them with the multimeter. So if the capacitor footprint is marked "3V3", you should measure 3,3V there, etc.
This way, I found the 4V missing and replaced the regulator as described. The only thing you can't find on normal capacitor footprint is the analog PLL power voltage, so you can carefully turn around the mainboard and measure directly on the regulator itself. So both the core and PLL voltages should all be 1,2 Volt.

Next test can be after verification that all the power voltages are correct, to connect the USB blaster with the special cable to the CPLD pinheader in the correct orientation, and you can power on the mainboard and do a test programming sequence.

I will create an initial testing project for the CPLD which I am going to program for initial testing, and I will mark it as such and upload the quartus project folder to the GitHub directory. I will spend some time to work on the quartus project, and it will be programmed and uploaded next.

Another test you can do is to measure all the clock generator outputs with a scope just to confirm all the clocks are there.

So we have 16MHz, 14.318MHz, 32.768KHz and 32 MHz on the bottom side SMD oscillator. The latter should have a 3,3V amplitude, of which the clock output is going into both PLLs dedicated clock input pins on the Cyclone II.

Generally when you consider to solder anything onto the board, first check whether doing that will not hamper anything else.
Basically I can say it's best to be able to power on the board, and get all the SMD components soldered first.
Before soldering the FPGA, it's prudent to power on the board and measure all the voltages including the 1.2V analog PLL output.

Note: I soldered the same D-package 1.2V regulator on the analog power input regulator footprint location because Mouser didn't supply the microchip one. So I chose this path. You can carefully scrape off a little more soldermask so you can solder the D-pack instead of the low power microchip one, it's very easy to do.

Okay, next up is creating the first quartus project for the IO decoder and programming that in.
After that I will check a few clock pins and then I will proceed to solder the FPGA, serial configuration flash and the programming headers.
I will have a lot of work to create the complete quartus project for the FPGA, and then I will attempt to flash it into the configuration flash using quartus on the AS mode programming port on the board with the USB blaster programmer. For the FPGA JTAG and AS headers I simply used the complete 10 pin connection so there a straight normal 1:1 10 pin flatcable can be used.

Soldering the 208 pin packages is pretty straight forward, first apply flux on the SMD pads, then pre-tin them with leaded solder by wiping all the pins with plenty of solder on a larger wedge shaped tip. Then clean off the flux and carefully position the CPLD or FPGA. Take ample time to do this, and the reward can be a very straight positioned chip where every pin is spot on in the middle of the pads. After you made the package super straight, then take the iron which you have ready and heated, and simply wipe a few pins on each side from the package outward. This will fixate the package in it's position. Then you can apply flux again and I would suggest using the larger wedge tip first to give each pin a good reflow treatment. Basically what I do is I press down and hold gently on each pin, and then proceed to wipe it from the IC outward on each pin around 6-8 times. This will flow the solder to the pin in a very solid fashion. Using the short wedge tip, it's gentle on the pins, and supplies plenty of heat to do a good reflow job. In fact, I got all the pins solid to the pads in one single pass already. I then replaced the tip with a short cone shaped one with a small tip, and proceeded to wipe all the pins another time just to spread the solder more. Also, if any pin is not straight, the smaller tip end can help to very gently try to nudge the pin into a more straight position. Handle with lots of care of course as not to damage the pad.

More info is coming soon.
You can check the pictures of this phase 1 assembly to also see what is needed to get all the clocks and power ready for measuring and being able to power on the ATX PSU for testing. After all testing, the CPLD initial quartus reduced testing project can be programmed next. The CPLD also outputs the divisions for UART_CLK and TCLK (system timer clock) so you can verify that these clocks are coming out of the CPLD using a scope.

After the CPLD is confirmed, the FPGA can be soldered on next, and the JTAG and AS headers, and then the bus switch ICs, and finally the SRAMs.
The FPGA programming can then be flashed into the serial configuration program. If you can succeed to get this in and quartus makes a correct verification, you can then proceed to add the system ROM and CPU socket. So you can test the CPU whether it's showing signs of life, such as lowering S1 and reading the system ROM, you can see activity on the address lines on the ISA slot, which is then a sign that the FPGA is at least working up to a certain level. So I will detail more things in the next post.

Kind regards,

Rodney

[rodneykn]

I have checked all the voltages on the REV4 QFP mainboard to be correct.
I then proceeded to solder the FPGA, serial flash configuration ROM, bus switch ICs, SRAMs, 286 CPU socket and system ROM socket strips.

After all the SMD ICs in the core FPGA/CPU area were in place and checked to be solid on all the pins, I have soldered in a number of mostly 2200µF capacitors, a few 100µF and some 1000µF capacitors.

Basically I just chose 2200µF capacitors wherever these were able to fit as a general preference. Near the FPGA there was less room because I placed the capacitor footprint a little nearer to the FPGA since this involved the core 1.2V which I was trying to reduce the length of the connection from the cap to the core power plane. I think 1000µF should be fine for the general core 1.2V power supply. If not, I think I should be able to fit a 2200µF later but I think my capacitance provision is likely a lot more than sufficient. So generally I advise to find a smaller footprint type of 2200µF capacitor at 6.3V for the low voltages 5V and below, because this lower voltage also results generally in a smaller diameter capacitor which is better to fit everywhere on the mainboard. In the REV3E system I discovered a general need for more capacitance on the board in the core areas, which was however also due to the trance density in that particular system design. Anyway, after that experience I am now making sure there is no lack of buffer capacitance anywhere on the board for any of the core power nets.

Generally the rule is, start with the SMD ICs after doing phase 1 and programming the IO decoder, and then finish all the SMD ICs, then proceed to add the other components around them making sure you are not hampering access to any component that needs to be added later.

I left out the POST displays, FDC and UART ICs because I want to start up with a lighter load on the system data and address bus since these are shared with the ROM and main system SRAM. After I have been able to verify all is well on the address and data bus, I will proceed to add the remaining IO components, then proceed to test boot the system and after doing some stability and higher clock frequency tests, I will then start doing tests with the integrated PicoGUS. I have no experience with this very cool sound solution yet, so I am leaving this off the board until I have fully verified the system. So more about the PicoGUS experience later.

Now in phase 2 of assembly, I am going to work on the FPGA quartus project in much detail. I have not programmed anything into the serial configuration ROM yet. I still need to replace the system control section in the quartus project with the latest design which is now as good as completely synchronous so this should be much more FPGA compatible already. Likely with the much higher internal clock of the FPGA, I could be even more able to fine tune the READY timing for the 286 to be precisely on a certain clock transition point of which we can then know the exact timing in terms of which clock edge is best to be used.

I chose a 286 CPU (of course, a Harris) which Patrick has verified up to 30MHz, however we also have a CPU socket now so later I will be able to easily swap in another 286 CPU if needed. Regarding the PLCC socket, be very careful what you solder in and inspect the contacts with a strong magnification and light to make sure there is no corrosion on the contacts. Many of the sockets are old stock and it depends on how well they have been kept in the years. The one I used is not a newly bought one because those all had some level of corrosion on them, I instead desoldered the one I am using from a 386SX board where it was used for an optional 387 coprocessor.

Okay, so now I will go over the entire quartus FPGA project for the Cyclone II which will be a lot of work. After doing many checks, I will then proceed to attempt to program the project into the serial configuration ROM on the mainboard using the AS mode connector and the USB blaster.

Here a photo which shows the current state of assembly. I have not powered on the mainboard yet at this moment, I will wait until I am able to attempt a first AS mode flash programming.

Note that I have inserted the 286 and system ROM chip, which is the ROM which was also used in the REV3E system.

Kind regards,

Rodney