Project to create an ATX 80386DX mainboard based on the Compaq Deskpro 386 Model 40

[rodneykn]

This thread describes the process I am working through of reverse engineering and CPLD based recreation of the Compaq Deskpro Model 40 80386DX PC system, preserving original system behavior using modern hardware. After the CPLD stage, FPGA technology will be used in the next phase.

After talking with Stefan on my 80286 thread describing my work to recreate the historic IBM 5170, I have decided to look into a project that aims to recreate the Compaq Deskpro 386 Model 40 system for which the designs were leaked and shared by user illys on the VCF forums who obtained scans of the original design documentation.

This design is of a 386DX based system and it's a very early system created by Compaq. The historic value of these leaked designs is significant because the designs include PAL based system control, and not only that, the designs also include the PAL source code. That makes it a complete early 32 bit PC design which supports the 80386DX. Because Compaq didn't use LSI technology yet, that means that thanks to the design being leaked, we should be able to recreate this historic 32 bit system, and continue from there as I am also doing with the 286 CPU project based on the IBM 5170.

So I am processing the schematics first to get a complete overview of the Deskpro system, then I will process the schematic for two different builds.
The system will be built in a ATX form factor TTL/PAL based design using 1MByte SRAMs on the mainboard, REV1, and at the same time I will create and build a CPLD version of the system, REV2, also in ATX format which aims to remove all the PAL and TTL logic and integrate all of it into the CPLDs similar to the REV3E 286 system. Later on we can move on to REV3 which will be a FPGA based iteration.

The conversion to SRAM will require some of the PAL logic to be modified since we don't need refresh and CAS/RAS etc, so I will modify the design accordingly.

It's currently early in my process, however I am starting this thread early and maybe others who know a lot about this system could share their input as well.

Just for clarity, this project is going to be created in order to preserve this original historic technology by rebuilding it in a practical new form.
So the main aim is preservation by rebuilding and verifying the entire design.
I don't have this system or even a mainboard of it, so the whole project will have to evolve from paper basis only.

If anyone wants to support or help me with this work, please get in touch, I will be happy with any help and/or information you can provide!

Kind regards,

Rodney

[rodneykn]

As I am doing all this work in preparation, I ended up on sheet 9 of 14 of the schematic where the logic for system control is described.

This is by far the most interesting section of the entire design that I have come across so far.
So in the schematic we can see that Compaq used a ALS273 as a shift register, that looks just pretty cool to me!
I must admit that I also like pure TTL based projects, just when you reach more advanced levels it would start to require such large numbers of ICs, ever growing board size and the propagation will inevitably start to act up at some point. Though excluding DRAM and parity from the design should be of some help to increase stability at higher clock speeds.

A lot more will become evident when I start to unravel the PAL programming and combine this with the external shift register driving the PAL.
These circuits together should be very telling about how the Deskpro functions.

Second most interesting part of course will be the data byte conversion logic. Like how do we translate between 8 and 16 bit, between 8 and 32 bit, and between 16 and 32 bit, and so on.
As I understand, the 486 apparently includes parts or all of this conversion mechanism internally. At least, I remember reading about this.
So that would be at least one significant difference between the 386DX and a 486 CPU.

Here the small section of sheet 9 I am talking about as a preview.
I just really like this circuit especially since realizing that this is coming from a proven mass produced system.
I wonder how many were made of these, I will do more research about this.

All the PALs are indicated with a "D4" prefix in their programming reference.
So it's my theory that this could refer to "Deskpro Model 40".

It's a really cool project and I am starting to look forward to building this system.
Luckily, in this model they are not using the 82384 clock and reset controller.
So basically the design consists of the 386DX CPU, an optional 287 or 387 coprocessor, and only PALs and TTL logic.
So Compaq here has done the great work to no longer need any type of bus chip at all to create a 386DX system.

I hope there could be some interest for this project and maybe others would be interested in building one of the resulting designs after these have been proven.

If anyone can provide additional information or interesting context, or other historic facts about this system, or be able to help me with something etc, I would love to read about it since I am now going to build and verify this leaked design.

Of course, I will keep an eye out if any example board or even a system comes up anywhere for sale at a good price.
Regarding the boards, these will probably end up needing full ATX size and in a 4 layer board design.
Hopefully with the PAL/TTL board I will have enough space to fit the SRAMs.

Kind regards,

Rodney

[rodneykn]

A small update regarding the system control for a 386DX.

Initially since the PAL equations were a part of the Deskpro documentation, I believed that the system control was completely created by Compaq, however during my assembly of the system schematic I am also going through the 80386 data book and I found that Intel also published very helpful PAL logic to create the bus control signals and to enable READY. Knowing when to apply READY to the CPU is the most timing sensitive area of the system and this requires carefully following the CPU in addition to a state machine model of the designed system memory and I/O timing. Memory and I/O timing design is also a critical part of gaining full system stability because there are different cycle types involving different kinds of I/O and memory transfers.

In summary I want to list:

8 bit device I/O timing
16 bit device I/O timing
8 bit memory timing (8 bit mode system ROM)
16 bit memory timing (VGA controller on the PC/AT slot)
32 bit memory I/O timing (main system RAM)

All of these will need to be handled separately so you can see the complexity of the system control regarding the cycle mechanisms and timing. When a lower bit width is connected, it will require transceiver control to switch the transferred byte(s) into the right data byte pins of the system data bus which will depend on the exact address the transfer command is taking place on. So this will require a lot of decoding. When data needs to be read by the CPU from 8 or 16 bit devices there will also be latching and conversion involved of the 8 or 16 bit wide bytes to they will line up with the correct 32 bit bytes on the CPU. I have read somewhere that the 486 is able to do this internally which is another step forward in the future, but also outlines a difference in the design of a 486 system. I will outline more details about this complex area of the 32 bit systems later.

So I will compare later between the PAL logic in the Deskpro Model 40 documentation and we can find out whether it's a copy of the Intel supplied PAL equations or if there are any differences. There are also DRAM control PAL equations in the Intel data book.

I am going through a lot of documentation which is going to take time to process everything in the entire 386DX system. I also saw a lot of information about CPU cache in the Intel data book which we can revisit later on especially when we are in the FPGA stages which will enable a lot more resources to be used in the system. FPGAs contain a lot of really fast dual port block RAM internally so this may also enable us to speed up the CPU with cache RAM. More details will follow later when we arrive in that stage of the projects.

Kind regards,

Rodney

[rodneykn]

I have been very busy reworking the entire Deskpro schematic after completing it from the original schematics.

So now I am processing the entire design in several ways:

removing REFRESH logic
removing parity circuits

In addition, I have renamed a lot of Deskpro signals to their IBM 5170 equivalent names.

So this will allow us to compare between systems otherwise the changed signal names will be very confusing and prevent a thorough understanding from the perspective of being familiar with the IBM 5170 design, from which a large area of the Deskpro is derived.

After doing a lot of schematic processing work, I am getting a deeper insight into the changes Compaq has made:

integrating DMA (and refresh) hold request with the CPU RESET logic

The triple fault check or 8042 IO output initiated CPU RESET will set in motion a few flipflops, which in the process also prevent any hold requests from REFRESH or DMA to be processed. The pulse will arrive on the CPU itself and reset it.

integrated a FAST GATE A20 function using a PAL IC

The PAL IC intercepts the write commands going to the 8042 and changes the logic state of the A20_GATE signal itself.

I am not entirely clear on how this can happen without contention happening because the A20_GATE signal "LOW_A20" is connected both to the 8042 output and the "D4-SKEY" PAL U87. That seems to only be able to work if the signal would be open collector.

Anyway the write to the output port is intercepted by the U87 PAL by disabling the IO write signal on the 8042 side when it decodes the right IO write happening. So the IO write will not happen to the 8042.

Regarding contention I will change the A20_GATE signal so both sources can control it. Or maybe I will feature a jumper to select using the fast A20_GATE or use the 8042 to control the A20_GATE.

I have stripped out the refresh and parity logic just as I have done with the 5170 recreation design which also uses SRAM memory.

Same as the design based on the 5170, I will need to look into the PORT B I/O bits and how these are used for feedback detection during the POST and BIOS operation. I have sorted this out mostly however this still needs testing.

I don't have a Deskpro Model 40 mainboard available for testing so I will only be able to test these things after building the design. In this regard possibly it will be better to first build the CPLD based REV2 design since this would be more freely reconfigurable.

I have looked into the SLOWD/SLOWH circuits in the Deskpro schematic and apparently these have been created to be able to slow down the CPU if needed. The pulse is gated by a 8042 output and if enabled will generate hold requests which will create delays in the CPU's operation.

So I have decided that slowing down the CPU is not in our interests for this project, so I have removed that area of the system and there will not be any slow down pulses arriving into the hold request circuits in our new design.

In the CPU hold request logic I am seeing another flipflop stage before the request arrives on the CPU pin, so I have tested this additional stage in the 286 REV3E Address bus driver CPLD, and this looks to be working fine with the 286 as well.

The DMA wait/READY logic appears to be identical to the 5170 so that's also sorted out.

There is another difference in the Deskpro, the HOLD acknowledge logic is merged with the HOLD request logic so this combined signal will be enabled earlier and is used to drive certain inputs which in the 5170 were only driven by the CPU acknowledge signal.

In addition there is more elaborate 80287 numeric coprocessor control to improve compatibility with the 386DX CPU and handle coprocessor error interrupts.

It is proving to be a lot of work to go over so much logic, and in this case the system is a lot more complex than the 5170.

The PAL equations need to be converted into gate and flipflop logic and integrated into the entire system. At the same time I am keeping in mind how I am going to implement a new TTL/PAL based design. The PAL refresh related signals can be tied inactive and outputs can remain unused. So the new PAL logic would need to drive the new cycle type decoding such as using an 8 bit mode ROM and memory chip select decoding to support the new SRAM memory design. And I will need to look into how much board area would be used by the TTL/PAL design in order to be able to judge whether possibly some integrated IO could be added to the board. If there is no space, I can look into a minimal board area addition that makes using the mainboard easier such as featuring IDE, floppy drive and UART for the USB to serial mouse only.

So I am assembling a "version 0" schematic of the Deskpro system, from which I will then transition into the REV1 and REV2 board designs. For REV2 I will be moving a large section of the logic into several CPLDs. In this I will also need to look into the 32 bit aspect of the design how this would be able to fit in CPLDs and whether that would be reasonably possible using the 6 OE functions per CPLD.

Here as a preview an image of the hold request, CPU reset and part of the DMA control. The blue sections are drawing representations of logic that will be provided elsewhere on the mainboard for example in PALs or shared register ICs. I have split out this logic so we can assemble a schematic where the design structure can be visible. After getting this clarity, we can then transition into a new design from there.

So here is a schematic section of removed logic. More areas will be modified in the following design steps.

In addition I will analyze all the PAL logic and adapt it to the new design where necessary.

So in the CPLD version I will need to assemble the CPLD logic distribution and integrate everything into KiCad.

After creating the CPLDs it will be easier to move design sections between quartus CPLD projects and do compilation tests of all the CPLD projects to make sure these are fully able to compile with some logic and pins remaining as spares.

Kind regards,

Rodney

[rodneykn]

Here in attachment a section of the HOLD request and CPU RESET logic.

Certain signals are already renamed to the 5170 standard names however I am still reworking the entire schematic which is going to take some time to process everything. After processing I will look into how to adapt the design to SRAM decoding, the 8 bit ROM, how to attempt to create a 32 bit VGA card slot based on VLB mode operation of a Cirrus Logic VGA controller.

So here is the schematic section mostly related to HOLD request, DMA arbitration, DMA READY logic.

I included a list of the original and renamed signals in the design.

It's not meant as fully comprehensive however it can provide some insight how the signals differed in the Compaq schematic.

It's a work in progress, there will be a lot more work done on the project!

If anyone wants to help or support me in this preservation project, please feel free to contact me!

Kind regards,

Rodney

[rodneykn]

Okay so I am working on the PAL logic where we want to obtain a logic overview that is reasonably comparable with the 5170.

PAL U46 in the Deskpro design roughly creates half of the IBM U87 equations, where we see the data path equations for the 8 to 16 bit situation. In addition the PAL, same as with the IBM U87, controls BHE and A0 during DMA.

With DMAC-1 active, A0 should follow the A0 pin of the DMAC. When DMAC-2 is active, XA0 should be held low.

When DMAC-1 is active, BHE should be the inverse of A0. When DMAC-2 is active, BHE should be held low. The combination of XA0 and BHE both being low enables the 16 bit situation where both bytes get connected. In practice this rarely will occur because typically DMAC-1 is used in a AT system in the majority of cases.

I have simplified /AEN_1, /AEN_2 and /DMA_AEN for now to exclude BHLDA from these.

During DMA, I don't expect that the DMACs would enable their AEN outputs before the CPU has asserted the HOLD state.

In case BHLDA is warranted in some combination with the hold request and acknowledge arbitration which is now combined with CPU RESET, I can always test this later on if DMA doesn't work correctly. Since DMA is a relatively slow process I just don't see any issues but we will test this.

Here the section diagram. I have included the PAL for the purpose of showing the pinouts here.

The schematics here are more for illustrating function, rather than showing the exact final logic, which will be determined during later stages of the work.

I am still considering what to design first because I am tending towards a CPLD design first.

The CPLD design when build will allow for modifications after building the system, which would be much less the case when building the PAL/TTL REV1. In that stage we only can reprogram PALs or GALs, while when using CPLDs we can group the logic together and pretty much revise everything there.

Kind regards,

Rodney

[rodneykn]

I have been working on the State machine section of the Deskpro design.

So here we have the state machine logic and directly related other areas.

There is also some WAIT state function included which is driven by the slot IOCH_RDY which is primarily coming from a VGA controller on the slot to throttle writes to VGA RAM while the controller is not able to directly accommodate the writes.

The state machine logic also generates the bus READY outputs which is one component of the CPU READY output.

SA0, SA1 and SBHE are decoded and generated by the logic for compatibility reasons for example driving IO and the slot.

Also the data bus latch control is generated in this section.

The logic in addition generates the MYCYC = Bus state machine cycle signal, and provides part of the logic to drive the CPU /NA input which controls the address output assertion timing.

Here is the sectional schematic which also includes some PALs to show the PAL connection pinouts.

Kind regards,

Rodney

[rodneykn]

Okay so I am now working on the first quartus project to create the System controller CPLD for the new Deskpro system design.

So we are going to include at a minimum all directly related logic which will reduce the pin numbers because various system control signals are created to be used internally inside the System controller only. We also have the DMA situation, however we will handle the DMA commands etc externally from the System controller where the System controller will put certain signals in tri-state for input to the byte control decoders etc during DMA. So the System controller basically focuses mainly on the CPU operations.

I will need to see whether a 100 pin CPLD would be able to cover all the directly related signals. It's a little more elaborate than the REV3E 286 system because we have a number of byte control signals which I would prefer to handle from inside the system controller so we can potentially control the timing more. In addition, the DMA hold request and acknowledge to the DMACs will need to be included because these were directly paired by Compaq to the 80386DX RESET control mechanisms. I am not sure how timing critical these are to synchronize the 386 to its input clock, anyway it's directly a part of System control.

In addition we will generate the CPU clocks from the System controller so we would be able to do more in terms of switching to much faster input clocks in the future for achieving potentially more precise internal synchronized timing.

I was able to successfully compile the project in quartus as it is up to now.

So I will be adding a few more things such as the coprocessor control logic.

There is one part still missing in the system control which is in the Compaq design located on the memory board in a few PAL chips.
Basically it generates the memory CAS and RAS control, does page comparisons to generate a memory page HIT or MISS condition. So that then determines the handling of each cycle on the DRAM system.

Anyway I will be modifying the memory board logic for SRAM support so we can build and test our first design and we will be able to prove the Deskpro design as recreated. An important step.

After finishing the System controller, next up will be the Address bus driver CPLD which generates the DMA address bus as well, does address decoding, EMS handshaking, and handles some other DMA and ISA slot controls.

After the address bus driver CPLD, I will be looking into the data bus driver CPLD which will need to support the full 32 bit data bus. So we will need to see whether the CPLD will be capable of doing that task since it can handle only 6 OE functions.

Then next up will be the EMS controller which in this design also will need to handle a 32 bit data bus with 4 byte controls.

Still a lot of work to do but the System controller is definitely a complicated design area with a lot of logic. So that is almost handled now, except for designing the new SRAM system control. I will reserve some pins for this so we can use some form of feedback from the address bus driver memory decoding to drive the memory cycle control. Of course, we also have the MEM_CS_16 and MEM_CS_32 to generate the byte controls and bit width for the various cycles.

In attachment the quartus schematic for the System controller CPLD up to now. So this block design now fully compiles.
Certain areas I have reduced for compilation purposes since the controls need to be created for these, such as READY and /NA generation to control the CPU cycle termination and pipeline status timing.

Kind regards,

Rodney