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

[rodneykn]

This thread describes my work to recreate the IBM 5170 technology in open source designs.

The IBM 5170 was created by IBM under leadership of Don Estridge and represented the first PC/AT design by IBM. In the PC/AT the original 8 bit PC technology was further evolved using a 16 bit processor, the Intel 80286, where the brilliant PC designers achieved 100% backward compatibility with the IBM PC, however enhancing the performance by using the 16 bit 80286. At the time the system was so powerful that for the first time a PC system was able to become a serious competition for the existing mini computers, however the technology was available at a substantially lower price. When the IBM PC/AT was being manufactured initially, IBM was not able to meet the enormous demand. For a long time after starting to produce the PC/AT, no other manufacturer was able to offer the same performance for the same price. IBM played a very important role in solidifying the industry PC standard.

Currently the project development after 3 years is in the REV4 stage where we use FPGA technology to create higher integration. Boards have been manufactured and the project mainboard in micro ATX format will be built up so debugging and development of the Quartus II programming projects can start.

The project is featured both on this website and on GitHub.

Further progress will be outlined in this topic as development progresses.

Kind regards,

Rodney

[rodneykn]

I have received the REV4 QFP FPGA and TOPCAT REV2 mainboards from JLCPCB.

I need a few more parts however I will transfer a lot of parts from the existing TOPCAT REV1 mainboard. This mainboard has served its purpose as a design verification stage to verify how a system can be assembled with the TOPCAT 320A and 331 chips. I will need to find some 72 pin SIMM slots to be able to use the 72 pin DRAM SIMMs with the system, so I may borrow these from a different system temporarily. I also have a big shortage of 33 ohms serial termination resistors so I will need to find at least these as well. The TOPCAT REV2 will support a variation of tests including to run the VLSI 320A with a single oscillator, clocking the 331 companion chip in synchronous mode. The TOPCAT REV2 is also a 4 layer board so it should have a much better grounding and power delivery than the previous dual layer design.

I will update here and also start pages for the projects that don't have one here yet.

These pages can then be found in the top menu and will provide more photos, schematics and detailed information.

So the blog here is more to update about the status and findings while building and debugging projects.

Anyone who wants to join this forum can simply send me an email and I will reply with a login to be able to post and comment if you like.

Kind regards,

Rodney

[rodneykn]

In our preservation project for the historic IBM 5170 technology we have evolved a system controller design in the REV3E design where we have several options:

- running the 80286 CPU at 22.4MHz using a dynamic clock input on the CPU
The CPU input clock is transitioned into half speed for slow cycle types such as:
- 16 bit IO cycles
- 16 bit VGA memory cycles
- data byte conversion during 8 bit IO cycles
Basically we can decode any memory region to generate a slow cycle handling of access to the region.
This is already the case with all I/O to ensure full stability with slower IO devices on the system or X-bus.

- running a fixed clock model which includes more synchronously operating logic areas.
I have been developing the fixed synchronous model which is running for development purposes at 8MHz or 16MHz CPU speeds.
The idea is to first take the dynamic clock out of the equation temporarily, and using the fixed CPU clock model to attempt to develop more and more synchronous areas in the system control which has evolved from the largely asynchronous TTL/PAL model designed by IBM. This design is a masterpiece, though when we try to adapt this technology to higher clock speeds, and using CPLDs and FPGAs, we must gradually transition the design into a much more synchronous or fully synchronous design. That means that all registers should be primarily switched by global clocks and only asynchronously cleared when RESET is applied. And even that is debatable since we also can include a RESET clearing which can be clocked. Though care must be observed that a RESET will not stop the particular clock being used for clearing, of course.

Anyway, I have been working hard on this fixed clock System control design. I generated a verilog version of the block design and asked google AI to take a look at the code. Of course, it correctly identified all the sensitive areas where asynchronous presetting and/or clearing can introduce glitching into logic derived from those areas. After some experimentation I have decided to for now go the route of entering block design circuits to transition the whole design into increasingly synchronous operation.

A very complex part of the IBM 5170 technology in terms of adapting the logic into synchronous operation are those originally TTL based sections where certain signals have dual purposes depending on the exact position in the timing during a particular CPU cycle. So we must observe the sequential situation where the system control follows the cycle, and evaluate the full sequence of events that pass through the system control. Only in this way can we get a grasp of how the system control exactly functions up to the deepest level of detail.

We have several types of cycles in our 5170 recreation project executed by the 80286 CPU:
- 16 bit fast system ram cycle
- 16 bit VGA RAM cycle
- 16 bit IO read cycle
- 16 bit IO write cycle
- data byte conversion cycle doing all 8 bit compatibility cycle types

Depending on the clock speed, the VGA RAM cycles may be able to run at full speed, for example with a newer Cirrus Logic VGA controller and up to around 16MHz CPU access speed. As soon as we go above 16MHz, there will be increased throttling by the VGA controller by applying IOCH_RDY low which waits the cycle in progress until de VGA controller signals it is ready to execute the cycle from its end. At much higher speeds like 22.4MHz and above, we will need to slow down the 286 clock speed by half. That way we can have a larger range of CPU frequency where the VGA card can remain fully stable with all CPU cycles directed at it.

So the mechanisms of the 5170 design controlling the 80286 CPU cycle termination and driving the 8 to 16 bit cycle conversion mechanisms are extremely sensitive areas in the design because these directly affect the CPU cycle termination timing. So it would be essential to transition all the logic involved into synchronously clocked register inputs which can then drive all the controls necessary.

In my development process I have evolved an increasingly more synchronous system control design project. I am addressing each sensitive point in the cycle termination and byte conversion logic mechanisms so these all may ideally become synchronous points in the system controller. With more synchronous points, the theory is that within the timing that the system controller CPLD can support, we could then scale the input and 80286 clock frequencies to higher speeds, where each area in the design scales along in a synchronous manner.

I am currently going to focus on achieving more synchronous points, where today I made a breakthrough. The cycle termination and data byte conversion mechanisms are using some common registers. One example of this register is the former IBM 5170 register U72B. Looking at the schematic, we can see this register is clocked by ALT_ALE and has both a asynchronous preset and clear input in use. That automatically means that we will be dealing with simultaneous application of PRESET and CLEAR on the 74F74. Moving this into a CPLD has posed problems from the first designs in REV1. So the logic needed to be modified for this register to be able to perform its functions. In the new REV3E System control model I have been able to move IOCH_RDY away from this flipflop, that was step 1. Step 2 involved the asynchronous clearing by END_CYC of this flipflop. This is extremely problematic in a CPLD or FPGA because the asynchronously cleared ARDY_n further along generates the timing to apply READY to the 80286. Now the 80286 is famously sensitive in its READY timing window so the combination of all these facts created lots of issues since the first designs using a CPLD.

So I decided to address this matter in full detail by first creating a very detailed event list for the cycles. There I especially gave much attention to the conversion cycle event list which is the most complex mechanism present in the whole 5170 design. U72B is actually a multi purpose register which has different functions depending on the polarity of output ARDY_n. So we must address these functions in a synchronous matter inside the CPLD. Today I was finally successful to completely synchronize END_CYC and applying it to sample READY with the right timing to end up with a fuly stable CPU. The complexity in the system control is specifically that ARDY_n must run through several stages:
- being clocked high by ALT_ALE the first time
-> wait state shifter Q1-Q4 starts running a 1 through taps Q1-Q4
-> in a normal cycle type, DATA_CONV remains inactive and the END_CYC decoding signals to the READY sampling that unless there is a IOCH_RDY inactive low, the 286 can execute the command in the final wait state cycle determined by the wait state shifter taps.
-> in a conversion cycle things are much more complex:
In our design we have renamed ARDY_n to CYC_START_END_n.
-> first ALT_ALE pulse: clocks CYC_START_END_n high for the first time
-> Q1-Q4 shifter starts running a 1 through
-> the command activates and is decoded to a DATA_CONV active
-> ARDYEN_n is switched high
-> this prevents READY to occur at wait state 4
-> the CYC_START_END_n register is now cleared however READY doesn't occur
-> a 0 runs through the Q1-Q4 shifter
-> Q1 = 0 and ARDYEN = 0 starts the conversion shifter, which
- turns CONVA0 high, turning the command output inactive
- pulses ALT_ALE a second time
Which then starts the Q1-Q4 shifter to run a 1 through the taps
- ALT_ALE also clocks LS_A0 high for the converted cycle address
- register 4 of the conversion shifter now turns ARDYEN_n back to 0, qualifying the next READY occurrence
at the same time, the command is re-enabled for finalizing the converted CPU operation
- The Q1-Q4 shifter starts running a second time, and runs up to Q4
- Q4 for the second time clocks CYC_START_END_n low which then activates READY sampling
- READY is applied to the 80286 CPU and it performs the data transfer to the 8 bit device.
After this careful detailed analysis, I have counted 12 SYS_CLK clocks for the entire conversion cycle including the pre command delay CMDLY cycle.
This conversion effectively extends the 8 bit operation access times between T_STATUS and the final T_COMMAND state.
Especially if we also take into account when we will have a dynamic clock available which effectively doubles the whole process in time.
That would mean approximately 24 SYS_CLK periods for the slowest 8 bit cycles.

It's a pretty effective way to modulate the 80286 CPU speeds.

I will write up more detailed descriptions of the 80286 cycles performed in the IBM 5170 system model.
Even though my preservation designs aim to be increasingly to fully synchronous, they still will maintain the exact original system behavior which is one of the preservation project goals.

More details about the development process will follow shortly, and of course I will share all the upgraded design details openly here and on GitHub!

Kind regards,

Rodney

[rodneykn]

After having made some major breakthroughs in developing a more synchronous System controller design for the REV3E system, I will share some more details here about how I have succeeded to make this work in a stable fashion.

In addition, I have now restored a dynamic clocking model back into the System controller for the more synchronous version.
Currently I am testing with a 20MHz oscillator which results in 20MHz 80286 CPU clock using the new synchronous READY sampling design and fully synchronous CYCLE_START_END_n register design.

This design now works correctly with a new dynamic clock switcher based on a block of verilog code, which I use twice in the design. One is used for the faster synchronization clock that controls READY sampling and the CYCLE_START_END_n register, and the other is used to create a dynamic 286_CLK again which directly drives the 80286 CPU.

I have uploaded the relevant quartus projects to the GitHub page for the REV3E.
The quartus projects are uploaded in the file "SYSCON_80M_SYNC02U1_DYN_CLK_AUG2026.zip".

So the archive contains the new System controller quartus project directory, as well as a slightly updated Address bus driver project which excludes the VGA RAM windows 0A and 0B from any cycle control. So using a suitable fast Cirrus Logic VGA card, the RAM cycles that target the VGA controller can now run at identical speeds to the system RAM. I have successfully tested the unmodified VGA RAM cycles at a CPU clock of 20MHz (80MHz oscillator used) The address bus driver project included only contains a slow cycle decoding modification compared to the previous Address bus driver released project file archive.

If the VGA card you are using cannot keep up with the unmodified CPU speeds in your tests, you can reprogram the previous Address bus driver project present in the GitHub directory to restore cycle control to the 0A and 0B VGA RAM areas. The example updated Address bus driver assumes 4MB of XMS and 4MB of XMS/EMS capable SRAM positions. For other configurations chech the relevant project and make a manual update of the slow cycle decoding in the same way as seen as the provided project in the archive for the slow cycle decoding circuits.

Okay, so here a few areas of the new System controller design schematic where various key points have been modified to create a more synchronous design, most notably being:
- cycle end decoder is now including masking when a conversion cycle is in progress, which only operates on Q4 to terminate
- CYC_START_END_n is driven by a register which only switches on clocked states. The register locks until a CYC_END_n is (again) decoded during the cycle.
- Q1-Q4 system control shifter is now driven by CYC_START_END_n. Note that during conversion a lot more is going on with the Q1-Q4 shifter where it not only terminates the cycle in the end, but also stops and clears to kickstart the conversion shifter. When the conversion shifter runs for a second time, it will coincide with restarting the command when the conversion shifter has passed through its steps. At the second run, the Q1-Q4 shifter exactly follows the wait states for a converted cycle which always will end at Q4.
- the entire conversion process takes 12x SYS_CLK with the stipulation that a conversion cycle is now a slow cycle which dynamically switches to half speed. So we get the equivalent of 24x the fast SYS_CLK periods for the entire cycle. If the CPU runs at 20MHz, SYS_CLK is also 20MHz so the converted 8 bit cycles will then take around 50ns x 24 = 1.2 µs.
- the CUR_CYC_CONV signal is added which indicates during the entire cycle whether a conversion cycle is in progress. It is also used for masking the normal cycle terminations, though theoretically these should not be triggered, but just for added certainty these have been masked.
- the fully synchronous SLOWCYCLE logic has been included and the two verilog glitchles_clk_mux blocks are also present as block design parts.
Please note: in the example, we see 64M / 32M, which when using an 80M oscillator can be substituted as being 80M / 40M, etc.

The very short verilog code block with my thanks, as suggested by Google AI during a conversation, for the glitchless clock switch blocks is as follows: (Google AI talked with me in Dutch in the conversation, so I translated its helpful comments into English here.)

Code: Select all

module glitchless_clk_mux (
    input wire fclock,       // The fast master-clock input (80 MHz)
    input wire clk_286_sl,   // The slow cycle clock (286_SL_CLK)
    input wire slowcycle,    // The driving signal: 1 = slow, 0 = fast
    input wire reset_n,      // System-reset (active-low)
    output wire clk_286_out  // The final glitchless clock output
);

    reg clk_select_reg;

    // We sample the slowcycle-signal on the falling edge of FCLOCK.
    // This ensures that we never switch a clock pulse half way in the clock period.
    always @(negedge fclock or negedge reset_n) begin
        if (!reset_n)
            clk_select_reg <= 1'b0; // Always start in FAST mode
        else
            clk_select_reg <= slowcycle;
    end

    // The glitch-free hardware multiplexer
    assign clk_286_out = clk_select_reg ? clk_286_sl : fclock;

endmodule

So I like the way AI can possibly be of assistance with these projects which can save me a lot of valuable time. AI can by far much faster consult various sources to find the relevant information about for example here a glitchless clock. So I have verified this code to be indeed fully functional. It should be a big improvement compared to using only gates to multiplex a clock!

Anyway, the uploaded design has been put through a few of the most critical tests to indicate stability and didn't fail any.
If using EMS, remember to do a system RESET or power cycle before starting Windows, otherwise it will fail on XMS RAM which has been borrowed for the EMS memory pool. I suppose I could look into supporting a smaller 4MB XMS window for my DOS boot menu that loads EMS for supporting RealDOOM but oh well, it's not that big of a deal anyway. I may discuss with Patrick, if he has time, whether we could make some very short assembly based programs to switch some memory configuration registers, I suppose.

-> minor update: apparently the DMACs didn't really like their clock speed in the dynamic clock branches so I addressed this separately in other clock divider areas. They are running at 5MHz now with a 80MHz oscillator with this latest more synchronous design. So I have split off DMA_CLK from another divider and left the SDCLK triple fault detection on the dynamic clock branch and renamed it to SDCLK.(shutdown clock) I replaced the quartus project archive on GitHub with what is now the minor U1 version update. Filename above matches.

Okay so that's mostly it. If you want to see the entire System controller project you can download it from the GitHub directory.

Kind regards,

Rodney

[rodneykn]

This is my latest resulting project as verified on 14-8-2026.
Check the link to the file on GitHub below for the ZIP archive download.

I have developed the REV3E 80286 System controller CPLD design further which now includes synchronously created timing and control signals in even more of the extremely sensitive design points.

The System controller runs on a input clock double of 286_CLK frequency and contains two clock switcher verilog code blocks driven by decoding and cycle timing to provide dynamic clocking. I have mainly tested the design at 80MHz clock input, I don't have an alternative yet and will find a 100MHz oscillator for example so we can test whether the 286 CPU can run at 25MHz.

A copy of the address bus driver 156 and 1256 designs is included in this archive where the 0A and 0B cycles are removed from the slow cycle decoder. These versions of the address bus driver can be used if a suitable clock speed is combined with a very fast Cirrus Logic based VGA controller. This, if found stable in testing can potentially increase the VGA cycle processing to such a level that it nearly matches the CPU itself. IOCH_RDY throttling can slighly decrease performance but that is only a few hundred cycles per millisecond. In terms of clock speed, I have verified that the Cirrus Logic VGA controller can operate correctly with full cycle speeds up to at least 20MHz processing speed of the CPU so with the 80MHz input clock of the system controller. If the VGA controller used in the system is not able to keep up with full speed of the CPU, you can program the previous address bus driver quartus project instead which includes the decoding gates for VGA RAM in segments 0A and 0B to run at slow speed. So the difference for testing is only those two decoding terms.

So I have developed a range of stable design steps where I have uploaded this version.
I have scaled the CPU operational speed down to 4MHz using a 16MHz oscillator where the entire system runs completely stable.
Of course, DMA clock will be extremely slow, however DMA operations are slow to begin with.
Currently the system controller divides DMA_CLK down from the 80MHz input clock to 5MHz.
So when we scale the CPU speed down to 4MHz, DMA_CLK will run at 1MHz.
I have verified that it is still possible to format floppy disks with the 16MHz input clock.

The system controller contains some outputs not used in the system such as 8042_CLK and SYSCON1/SYSCON2, and the global RESET output, which for now need to remain in place as otherwise unused outputs to get a stable compilation result that provides the suitable timing we need.

This is down to the level of quartus compiler and fitter details at a practical level. Even with the level of synchronous operation we now have, there is some degree of variation in the compilation. This could be reduced by restoring VGA slow cycle control however that would also be counter productive of course because performance is a primary goal. At present, timing appears to be critical only in a small area that largely affects the VGA controller only which is now apparently even more sensitive than the CPU. Otherwise the VGA controller does remain stable, we just get some DOS character mode glitching if the compilation result is slightly different. Some design variations also resulted in no CPU function but those were more rare in comparison.

The DEN and DT_R signals, which are also very fast and precise signals that have a big impact on the system, are now also synchronously created, however these still remain a little sensitive to how exactly we generate the output logic in terms of whether this works well while testing with the VGA controller at full cycle speeds. So some logic is intentially derived from a certain register in a certain output circuit path which was found to generally work best. The timing differences are extremely subtle between compilations, though a lot of the results work well.

In addition, the DEN enable logic during T_COMMAND has been further reduced in our system controller where I determined certain circuits and inputs to be unnecessary when looking at a sequential clock period derived system control event list. Because certain signals were overlapping with earlier established logic levels for DEN from other sources, I found these overlapped signals obsolete and removed them from the DEN logic. The reason for some signals has also been because in certain designs, the 82288 was being used, and both the 82284 and 82288 are not aware of byte conversion cycles for the CPU.

Otherwise I largely recreated the DEN_WRITE signal which adds an early DEN enable during T_STATUS for all write cycles.

The design now uses 99 Macrocells out of the 128 the CPLD provides for this V3 version of the more synchronous design model.

Kind regards,

Rodney

[rodneykn]

I have done a lot more development on the System control design of the REV3E stage.

I started with merging the PCLOCK and SYS_CLK clock signals.
Previously I was not able to do this in a stable way, however this time I attempted again and finally succeeded to accomplish this.
So now the whole system control design is running on the SYS_CLK and SYS_CLK_n signals and no more PCLOCK to be found anywhere.
So that includes the state machine and Q1-Q4 shifter, it is all now running on SYS_CLK exclusively.

The next big step was to rework the entire RESET logic. I started with the RESET circuits documented in the Intel 80286 data book.
So these circuits contain a lot of asynchronous points because in that time period everything was pretty much built using TTL ICs.
So now we are using CPLD technology, and FPGA later on, we need to revisit all this logic and create a synchronous functional equivalent.
Which is what I have done. I decided for a block design approach because this enabled me to make small incremental changes and each time test the 80286 whether it remained synchronized and stable.

After I managed to recreate a functional synchronous equivalent of the Intel 80286 RESET logic, I decided to have a look at the 5170 logic for detecting the 80286 SHUTDOWN operation and executing the 8042 initiated CPU-only RESET. This turned out to cost a lot more time and I had some trouble getting it to work correctly. However after some hard persistence, I managed to find a path to push the design into a synchronous state. In the process I then changed several areas of the RESET logic to save some additional registers. There is a slight possibly asynchronous point in the Intel 80286 data book CPU RESET logic, however this concerns a timer which is cleared inbetween two synchronized points, and the timer output never controls multiple points of the logic so it should remain glitch free since it is then passed on to a clock synchronized register. So I am not at all concerned about this since it's a slow timer element consisting of a single T-flipflop clocked with a slow clock pulse that generates the CPU RESET hold timing.

So I have managed to update a large portion of the System controller into synchronous logic, which inevitably must amount to a huge improvement of the System controller design. This will also benefit the work coming on the REV4 stage soon since a more synchronous design will have a much bigger chance of working well in the FPGA.

The System controller CPLD now went down from 99 macrocells to only 90 macrocells necessary for the entire design. So that's including the dynamic 286 clock function.

In the attachment the new RESET logic of the latest quartus System controller project.
I will also upload the complete and tested latest quartus project ZIP archive file on GitHub which will be the new V4 version.

Kind regards,

Rodney

[rodneykn]

Okay, now I am making huge progress on the REV3E System controller, I have some very exciting news!

Today I was able to achieve something that was previously not possible.
I have created hundreds of quartus design projects in the past period, however up to today it has been illusive to be able to implement the changed design compared to the REV3D version, in that here in the REV3E we don't need to use:
- 16MHz division to 8MHz for the 8042
- inversion of RESET_n output into RESET
- duplicate MEMR_n and MEMW_n signals on SYSCON1 and SYSCON2 outputs to the data bus driver
So these changes mean that we don't have a 16MHz clock input in the design, and we don't feature the 8042_CLK output pin, RESET pin and the SYSCON1 and SYSCON2 pins.

In previous attempts to eliminate all these in the REV3E design, since on the REV3E mainboard these signals are no longer needed, this has not been possible yet because it resulted in a big shift in the timing. The idea to want to reduce the circuits is that the more resources we can free up, we can use those resources to increase the synchronous operation of the whole design.

Well, that latter point is now largely irrelevant since we have a mostly synchronous System controller now in the REV3E which even uses a lot less resources than before.

Anyway, after the most recent synchronous updates and a few more I just completed, I decided it is time for another attempt to remove all the unused pins and circuits to see if we can now do this somehow. So after removing the unused areas, I found that again the VGA cycles were slightly off as expected. It's probably only a few nanoseconds of difference like maybe 10ns or less. Otherwise the design does work fine. So I started to tweak things here and there until I have finally now found a solution which works with the new System control design! Very exciting news!

The solution has proven to come down to using the inverse fast clock for the READY sample stage register, and moving all the READY sample conditions into a single AND gate on the sample register data input, instead of the previous NOR -> AND gate combination. Which is also something I tried many times to move into a single AND gate, and previously it was simply not possible yet and sometimes leading to a dead system. However this time, it turned out that by doing this I was able to fix all the timing issues due to the compilation being of a substantially different timing now with the removed logic. Surely the design is now more efficient since certain areas are gone from the design.

Anyway, I am really glad with this latest improvement which is a really big deal. Even on the REV3D, which is very similar to the REV3E, I was never able to accomplish this yet in a stable fashion. Well, it appears that after getting so many areas synchronous now, the design is increasingly more stable than ever before. I will do a lot of testing now, and see if I find any other design area that could be improved.

Basically the only relevant "asynchronous" point in the design now is a single transition of one bit in the state machine logic. This has been necessary so far because the 80286 CPU timing is slightly offset past the 80286 input clock edges to assert its status lines S0 and S1, and similarly it's slightly skewed to the input clock transitions to respond to its READY input. In other words, READY needs to be right in a precise point which is not on a 286_CLK transition either. So after doing so much development and testing, I already know the status assertion by the 80286 is somewhere off by about a quarter of the 286_CLK period from the falling edge of 286_CLK that introduces the intended T_STATUS period by the 80286. So using some edge of 286_CLK is not an option to catch the S0 and S1 assertion as it just happened. So this means that we are slightly behind to catch it with some 286_CLK transition.

Yes, we now have a higher clock frequency which could indeed be used to catch the status assertion as it actually happens, similarly to asserting READY with the right timing shift off the 286_CLK edges, however now the entire state machine design comes into play. This is timed on transitions of SYS_CLK and very efficiently uses only 3 registers. Would we want to use a much faster clock to transition the state machine and catch the status bits right as asserted by the 80286, we would need to create a much more complex state machine.

Right now the way it works is that the state machine after READY always transitions into T_IDLE first. If the 80286 is going from T_IDLE into T_HOLD, the state machine will then synchronously transition "back" into T_HOLD by clearing the ACT bit, and if the CPU is going into the actual T_STATUS, this will asynchronously set the NEW bit to 1 to keep the closest to identical timing to when S0 and S1 are asserted by the 80286.

So it's not really a very big deal to leave this asynchronous transitioning since the CPLD has limited resources in terms of register numbers particularly. The reason it's not a critical thing is that we will have T_STATUS asserted well before the falling edge of 286_CLK mid of the CPU state clock period. All that needs to happen is a single register to be preset in time before that clock transition which drives lots of system signals. So I checked what would depend on T_STATUS which is mostly only DEN_WRITE and the DEN_WRITE register transitions at 286_CLK_n. ALE transitions by itself from the status assertion by using the 286_CLK falling edge anyway. In other words, DEN_WRITE transitions a reasonable setup time later compared to the assertion of T_STATUS, also at the 286_CLK falling edge, same as ALE. So far I have not seen issues with DEN_WRITE timing after creating the new synchronous logic.

I also reduced some inputs in the DEN gate logic so that surely also helps the speed of DEN. The brief appearance of T_IDLE may also be handy if we want to decode things from that because basically it also reflects that the previous cycle was just finished after the 80286 did the command data transfer.

Anyway the slightest timing adjustment has now made it possible in the current latest design to have only the logic and pins remaining that are actually used in the System controller quartus project. So now the logic usage of the System controller went even further down to 86 out of 128 macrocells, pretty amazing since I have had design versions that used 105 macrocells.

So this basically achieves everything I set out to do in terms of what can we improve. I will do further testing such as applying a range of input clock frequencies and testing whether the system runs stable. Though arguably the clock speed can also simply be varied by using some pre-division on the input clock, of course.

Regardless, varying the input clock may skew the timing again or it may not. And whatever happens, there is always a solution to fix the timing slightly, most notably by looking closely at the READY sampling to use a different clock edge or even adding a READY sample shifting stage. So these two measures seem to be enough to fix any timing skew. And let's not forget that the skewed timing is primarily only apparent since we are doing the VGA RAM cycles at full CPU speed. So we tend to get some DOS character artifacts but still a fully stable system. So changing the READY sampling can push the timing into a suitable point that the Cirrus Logic VGA controller timing also agrees with. I think the degree of variation may be very little like it even being around 12.5ns or below that would be realistic to estimate.

I will upload this latest System controller quartus project as the V5 version on GitHub shortly.

Each stage of the development is left available for download so you can see the design differences.

Kind regards,

Rodney

[rodneykn]

So after making so much progress developing the REV3E System controller CPLD to now function almost completely on synchronous logic, I decided to revisit the REV2A modified system using TTL and PLCC CPLDs. I now want to see what I can do with this system after all the findings with the REV3E system to rework all the CPLDs as close as possible to the technology used in the REV3E.

Of course, in the REV2A we don't have CPLD based bus drivers, which is the main difference in that system that we used TTL ICs to create the system bus, X-bus and memory bus.

So what we can do in this system has some limitations, however the core component is the System controller CPLD which is basically the same part as the REV3E. So I should somehow be able to implement a System controller close to the REV3E design in the REV2A.

I decided to first prepare the REV2A system to run on a single 1 megabit 8 bit mode ROM. So I wired an adapter together which was made to fit into the option ROM socket, with a few signals wired in to get the higher address bits. After desoldering the option ROM socket, I soldered in the adapter assembly and inserted the ROM. I did some beeping and found that I didn't connect SA15 to the option ROM, so I also wired this onto the adapter. After the connections were verified I copied the Memory decoder CPLD project and started to update the logic there. So I removed the shadow copy logic because we will not need this when using a 8 bit mode ROM which runs through the conversion mechanism and at slow cycle speeds from the dynamic clock system. I programmed a copy of the REV3E system ROM into the same EEPROM part and inserted it in the REV2A system. When powering up I found there is no VGA display, and after wiring up the speaker I found that the MR BIOS was reporting some POST 0A type of message which in this case meant that the system RAM was having issues. This made me suspect that the issues are more related to unreliability of the sockets and card slot for the memory board. I cleaned all the contacts, removed the PLCC CPLD from its socket, cleaned those contacts as well, and after putting the card together and inserting it again, I found that right away the REV2A system was able to initialize without shadow copy with the single 8 bit mode ROM. A great result! And also a big reminder and red flag for the vulnerabilities of having sockets in a system. Previous experiences made me right away clean the contacts before doing other complicated testing and probing etc.

So now we have prepared the REV2A system for initializing with the 8 bit mode ROM. And I have tried a 40MHz oscillator test, which allowed the system to intialize and do a partial boot already so with the CPU at 20MHz, with what seemed like the one wait state which the REV3E also has. Testing was a little unreliable so I switched the system back to 16.5MHz for the time being until we can prepare more things for possibly supporting higher clock speeds.

Okay so the System controller will be very different in this system where we will also run the input clock at double the 286_CLK frequency. The higher input clock can then be used to synchronously switch signals which need a higher timing resolution, just like in the latest REV3E System controller design.

Other things I am changing in the REV2A System controller, where I am now calling these recent upgrades the REV2C System state, are:
- DMA/core AT controller buffered commands are now routed through the System controller
- the System controller now will generate the SA0 and SBHE bus/slot signals, similar to how the REV3E Address bus driver does this
- REV3E latest CPU RESET, 8042RC, 80286 SHUTDOWN cycle handling
- REV3E latest glitchless clock multiplexing and clock division logic
- REV3E new cycle start/stop logic
- REV3E conversion start and timing logic
- REV3E READY sampling and application
- REV3E CPU Command generation logic
- REV3E CMDLY reduced with one register
- REV3E read/write cycle DEN timing, improved DEN logic and DT_R logic
- REV3E merged PCLOCK and SYS_CLK

And all of these are synchronous circuits. Let's hope this may all work out and we could achieve a higher clock speed now!

I shifted some signals around which now will eliminate transceiver U89 in the REV2C system.
The signals are either eliminated from the design or taken over by the new System controller logic.
The System controller is pretty much used up in terms of pin usage for this design, I could still repurpose the 0WS and read/write memory cycle separation decoder output pin though if I end up needing one or two more pins.

So it's a pretty cool result so far to modify the REV2A to use a single 8 bit mode 1 Megabit ROM, which was a pretty smooth process and will have many advantages in our work later on!

First I will rework the rest of the memory decoder logic as well now, one thing is the pre-latching which I want to use, rather than latching the decoder output chip selects. I will go over the whole CPLD to see if any other areas can be improved.

So if all of these design upgrades work well, I may find the resulting computer suitable for a board redesign, possibly using a micro-ATX board size if this could fit on the available surface. I will also see whether we can feature the memory on the mainboard itself, or possibly using a new type of memory connector or soldered bus instead of putting the memory on the slot.
Using a custom connection to the memory bus could open up the path to featuring RealDOOM compatible EMS RAM on the REV2C.

Kind regards,

Rodney

[rodneykn]

After getting the 8 bit mode ROM functioning on the REV2C system, I decided to prepare the system for the new system controller CPLD programming.

A few things are moved into the System controller so now we can get rid of U89 entirely.
We will generate all the DMA commands directly from the System controller so these can be merged in with the CPU commands.
Also, by generating the SA0 and SBHE signals directly in the System controller, this also lines up with the internal decoding and byte steering logic for the byte conversions. It's more ideal to have all of this integrated in the same chip.
So the System controller is doing some small part of the address bus driving as well, for where the byte selection address states are concerned.

So I rewired various signals to directly control these from the system controller itself. I then proceeded to test the new System controller CPLD programming, and it was a pretty smooth process! I didn't experience any issues at all after completely switching to the new mostly synchronous System controller logic from the REV3E system, which is good news! This means that apparently the REV2C system can function with logic developed in the REV3E system design.

So I have tested the 33MHz oscillator which because of halving the frequency runs the CPU at around 8MHz. So I tested with 64MHz (16MHz clock speed) and 80MHz(20MHz) oscillators. At 20MHz I have seen some level of functionality in terms of the system RAM and initializing all went correctly. However the VGA card was experiencing some issues. It was only sometimes initializing and at repeated attempts could lead to the VGA card not being detected by the BIOS. So it would seem that the VGA card is having issues on the system. I am not entirely sure what the exact cause of this could be. Possibly when running at 20MHz, the transceiver connecting the 80286 to the slot LAxx lines may introduce too long of a delay which runs the VGA controller a little late to respond to commands. So I could try to bypass the LAxx transceiver and just connect the CPU to the slot lines directly for testing. Maybe this difference in timing could get us to a better CPU speed.

The other thing is that the memory decoder doesn't have access to the CPU A15 and A16 lines which are used to decode certain memory functions on the memory card. For example the slow cycle activation during ROM reading. I have seen a few option ROM error messages which could possibly hint toward something like that. Just generally I am also suspecting that possibly the data bus TTL ICs are experiencing some issues at 20MHz with one wait state.

A final thing may very well be the 60ns SRAM access time for these particular SRAMs which might be too slow. At 20MHz CPU speed we have a period of 50ns per CPU state period. So when ALE establishes, this allows us around 75ns for the SRAMs to reach the final command period and do the transfers with one wait state. So these SRAMs are rated 60ns which is kind of tight. It might very well be the much faster SRAMs of 45ns which allow the REV3E to work much faster. On the other hand, with the REV3E we have a much faster bus response as well thanks to the CPLD driven system and memory bus. Another thing is that with the REV3E, we have the CPU address bus directly on the Address bus driver which is also pretty optimal. Basically the REV3E is a very versatile system where we can even control the connectivity of the LA lines to the CPU to feature those directly when the CPU is not in hold. A pretty optimal connectivity thanks to the 208 pin CPLD which even handles the DMA address generation on the system bus.

I think I want to remove the LAxx transceiver and bypass it to see whether this can speed up the VGA cycles. I know the Cirrus Logic VGA controller depends heavily on the LAxx lines to detect VGA cycles and respond to these. Also, the memory decoder could benefit from faster LAxx lines to direct VGA memory cycles to the slow cycle dynamic clock switching logic.

So the results are varied and I will do some more testing and experimentation. I need to get a wider range of clock oscillators so I can better test where the clock limits are in each new configuration. Also here I am missing the POST code display. Frankly, I was a little torn the past days between doing these extensive modifications and just designing a new board. Basically doing that would take a long period of time and modifying the existing system could get me some answers a lot sooner so I risked it in the end. I am glad to try this now with the present experience with the REV3E because I have tried before to remove U89 and it resulted in an unstable system in the end. So at that time I reverted the tests. So now I pushed forward because I feel more committed to somehow find some path for improvement in the REV2C configuration. Basically it's a little like all or nothing however I would be sorry to destroy the REV2 system. Thankfully it's still alive and ready for more testing and development!

Kind regards,

Rodney

[rodneykn]

Okay so looking at the PC/AT system in general, inside the system controller there are a lot of logic areas. In order to support the entire system control I created a state machine that follows the 80286 cycles and from the state machine we can decode where the 80286 is operating in the sequence of cycle periods.

So in our model we start, whenever the 80286 is not in hold, at T_IDLE. This is a state from which we can go into T_HOLD, or we can proceed with an active cycle into T_STATUS. After T_STATUS is finished, the state machine always goes directly into the T_COMMAND period. The command state starts a set of shift registers, the Q1-Q4 shifter, to time the wait states and determine when READY is sampled and applied. T_STATUS is normally used to setup the address because in a straight timing model following the Intel documentation, we activate ALE in the second half of T_STATUS.

I have now modified a lot of logic areas to require less input from the state machine, which allowed me to reduce the state machine complexity to only the NEW and CMD signals. We can always use 286_HLDA to determine if the CPU is in hold. The NEW bit has always been a final block to rework, which I have now finally done. The NEW register is now fully clocked so we have a synchronised T_STATUS operation which transitions on the FCLOCK_MUX fast clock. I have slightly reworked the CMD register terms as well so the entire state machine is much less complex now. I feel it's sufficient to use this design from now on. It also should work in the REV4 FPGA system, or otherwise I can make some minor changes in a few areas if needed.

Looking at the REV3E now, the last list of changes has basically improved the whole design to the level that I feel fully satisfied with the result. There are no more areas left where I feel there is a need to change them. So this release file is uploaded to the GitHub directory.

So the latest improvements in the V6 release include:
- reduced and converted CPU state machine to fully synchronous operation
- updated clock switching register
- removed AIOW
- created a new CMDLY design
- replaced SM_IO_n latch with DFFE register
- with 80MHz oscillator now 3.33MHz DMA_CLK divide by 24
- again updated DT_R with better clocked version - now meets timing
- updated DEN_WRITE another time with better reduced logic
- extended 80286 RESET duration to fix occasional RESET fails
- updated LS_A0 with DFFE register
- updated coprocessor error handling with synchronous version (to be tested)
- created a limited SDC file, don't see a difference but may be useful, DMA_CLK is not included it gave errors

Again here the Address bus driver CPLD project is included in the archive for a few EMS situations where we excluded the VGA RAM regions for slow cycle switching. So this requires a fast VGA card that can handle these speeds. Tested correctly with 80MHz oscillator and 20MHz 80286 operational clockspeed.
If using other oscillators than 80MHz, check your actual clock speed divisions and adapt DMA_CLK and 287_CLK if necessary. Typical CMOS DMACs can run around 4-5MHz but I had a few issues with floppy formatting when running the DMACs on 5MHz. So this led me to choose 3.33MHz for the DMACs. Since this only involves IO to memory transfers I have not seen any impact on the system performance.

Otherwise it's looking like I seem to have reached a pretty satisfactory end development stage where the entire design is mostly fully synchronous. A few asynchronous clears are present in registers where removing these would involve rather elaborate constructions which I don't want to introduce into this design using a CPLD, especially because it is working really well now and the clears just occur at the end of the cycle to prepare the registers to be set again. So nothing depends on the clearing instance timing where only the synchronous register set timing controls the system. This is the case in the READY output registers and the Q1-Q4 shifters.

As seen from the above list, I have now with this synchronous design been able to implement a lot of changes which previously didn't work because of throwing off the whole timing. With the now almost fully synchronous design I have been able to change the remaining things I wanted to do now and these all work. A big improvement!

In the attachment the important parts of the new design.

Kind regards,

Rodney