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
Project to create an ATX 80286 mainboard based on the IBM 5170
Re: Project to create an ATX 80286 mainboard based on the IBM 5170
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
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