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