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

[rodney]

I have worked hard on finding a more synchronous design by using a higher frequency oscillator on the System controller CPLD.
So the test frequency right now is 64MHz, which I am dividing down to 32MHz, which drives the 286_CLK.
Further divisions then drive the PCLOCK and SYS_CLK main clock frequencies of the PC/AT system control logic.

Well, the idea is to use the much faster clock frequency of 64MHz and try to modify more areas of the system control to storing and clearing signals by clocking only, rather than using the asynchronous preset and clear of flipflops.
In the current stable asynchronous version of system control I am using some signals that drive the cycle termination in the READY logic which has managed to shift the timing to obtain a functional READY at 22.4MHz.

So these days I am looking at trying to find ways to separate these different areas more, particularly so we could then simplify the READY logic more to include/need only the minimal signals necessary and still arrive at the functional READY timing for all cycle types.

The idea is using the double input clock frequency to clock the READY sampled conditions. I named the new double clock signal 2FCLOCK to indicate it's double the input clock. This signal basically can register and shift data at the resolution of the FCLOCK transitions, rising or falling edge, or mid way in the high or low half of the FCLOCK signal, around 7.8125 ns granularity when being able to choose the rising or falling edge.

In addition, have linked the command on/off timing to the 286_CLK falling edge for all commands.
Because of the timing in the system controller CPLD it has been proven difficult to be able to do functional testing because when testing a certain logic, the outcome also depends on the accuracy of all the logic combined.

I have noticed today that very subtle compilation differences may occur where one result is fully functional and stable, while the other result of the same functional logic does display some timing issues.

After switching to the 2FCLOCK design, I have removed some gates previously used to shift the timing because these now stopped the entire design from even working. After that I got a POST 10 pause, some beeping, and the system continued to execute the POST and booted partially.

After more modifications where I am now resetting the 286 CPU with the 2FCLOCK falling edge, I changed the ARDY register to a normal flipflop combined with a logic gate, I was able to then remove IOCH_RDY from the READY sample stage, including it only in the ARDY stage itself. I was also able to use READY to reset the termination cycle shifter because END_CYC is no longer needed when the READY end stage is already active.

The problem is really that I am not sure when the test result differs whether this is due to a compilation variation, or that the changed circuit is actually functionally valid. This kind of randomness during the testing does make it more difficult to make any assumptions. So I have experienced a lot of moments where I had to take a few steps back and continue from the last functional version of the development process. I am trying to interpret what is going on with the test results in order to determine a possible direction for the whole design where I can proceed to what I would like to see more in the design.

What I am trying to do is just separate areas of the design so we can have the clear view on which signal is doing what, and to attempt to use signals only where they are actually being needed, and not anywhere else for shifting the timing. Otherwise I also aim to reduce the number of "dual purpose" signals in the design, trying to assign clear functional parts while dealing with the above limitations with sometimes stable, and then suddenly not, where the cause actually turned out to be from compilation results from the same logic being different.

As I removed the dynamic clock, I am clocking the 286 CPU currently at 16MHz because I know this should be able to run fully stable with VGA cycles, loading the BIOS etc at full unmodified speeds. Well, for a long time I have seen DOS text errors happening and getting only to POST 10 or beeping and continuing on to a partial boot. Even with the dual clock model, the lower CPU clock speeds around 16MHz didn't work well yet. Sure I could have created alternative projects to support this but of course the ultimate goal is still running at highest clocks, so this was not a priority.

Anyway, this afternoon I finally got a design compiled which is able to run without any beeping from the MR BIOS when turning the system on! It was pretty weird because I thought the system got stuck on the POST and not able to beep because of that, but then I suddenly saw the system passing the POST and doing a complete boot! This is a pretty significant progress in our project because I had not yet been able to get this result at a lower 16MHz CPU clock even since the start of working on the REV3D system. So we definitely seem to be getting some rewards now from using the higher clock speed. I will also do more tests at even lower clock speeds just to see what happens. If the design is synchronous enough, it may now even be able to function at the lower clocks, I will get back on that after more testing.

I also added some tiny stick-on heatsinks on the data bus driver and system controller today, which indeed enabled the system to run stable with a 8cm fan blowing on the CPLD area, and now with pleasantly low RPMs. So indeed having the heatsinks on the 100 pin CPLDs allows these CPLDs to cool down much more easily, which is definitely noticeable with the warmer ambient temperatures these days. It's a lot better for my development and testing efforts because the fan is really relatively quiet again, and it's the same fan speed as I was used to having before.

Okay, I will do more testing and look at more areas to get the circuits more synchronous. The READY logic is now almost fully synchronous, except the asynchronous clear of the first sample register stage. Though this may be necessary for now because of compilation outcomes differing. I may be able to find ways to eliminate this later on, though having an asynchronous clear to turn off a sample stage is for now a lot more acceptable thing to have. I will be pleased if the eventual outcome would be able to provide us at least with a more synchronous than before design, and if possible, of course I will try to get as many more areas synchronous as possible.

I have uploaded this more synchronous fixed 16MHz CPU clock fully stable version to GitHub.
The JEDEC file is included in the archive and can be directly programmed.
Builders can try to compile and convert to JEDEC again however if this is not fully working, then better use the JEDEC file itself and keep the downloaded archive as a backup. All other CPLDs can be programmed with the may archive in the same GitHub. So you can program the project I uploaded today into the System controller and then swap the oscillator to 64MHz, and you can test this version. Switching back to the original system controller programming, you can swap the oscillator back to 44.8MHz and update the system controller CPLD again.

So a big progress has been made for the project today!

Kind regards,

Rodney

 

[rodney]

I have done some additional tests on the released 64MHz/16MHz CPU clock system control project released on GitHub.
So for example this system controller is able to operate using a 32MHz oscillator where the CPU then runs at 8MHz.

There was some inconsistent detection of apparently more COM ports being present, which caused some beeping, enter BIOS and save again.
Weirdly, I have seen similar weird detection phenomena in the slower discrete 286 mainboards as well when using MR BIOS.

Anyway I was able to use the system at 8MHz CPU clock without further issues, everything functioned normally.
I have run a RealDOOM game demo test for a while and never saw it crash.

The system control design is not stable at every oscillator frequency, so results will differ and builders can test more oscillators to find out which frequencies are stable. Usually if the screen looks clean and no DOS character artifacts are seen while booting, that will be a clear indication that the frequency of the oscillator is apparently supported to run fully stable.

I will revisit the system control design to find out if we can improve more sections of the logic and get these more synchronous as well.

So these days I am testing using the tiny heatsinks on the smaller 100 pin CPLDs and an 8cm fan blowing at lower RPMs, typically running the 12V fan on 5V will get you this more comfortable low noise level while cooling the CPLDs sufficiently.
In attachment a photo to illustrate this. When I got these heatsinks they looked really tiny, however it's a big difference for the data bus driver and system controller. I have not seen any freezing due to heating up ever since using these with the warmer temperatures.

I tested with 20MHz divided down from an 80MHz oscillator however I was initially getting the skewing of wait states again where the wait states shifted one cycle. So this led to the performance going down a lot, though running stable. Since then I already managed to get the wait states reduced again which led to much faster operation at the same clock, however I still will need to change the timing in the READY end stages to get these speeds stable again with the new logic. Particularly the DOS character mode is off so this needs more improvement. Also there is an issue with the dynamic CPU clock, which during IO cycles switches down, because in the READY end stages this also appears to be an issue that we need to apply dynamic clock switching in these areas too. This remains to be seen whether this can be solved in a fully stable dynamic clock model using the CPLD system controller.

I will update some more info on the GitHub page about the latest findings and I will work more on developing further possible improvements in the system controller.

So in attachment a photo of the small heatsinks.
I added a few large caps in the CPLD area, where on the left you can see I soldered a 1000µF one into the coprocessor socket power pins for now since not using a coprocessor at the moment anyway.

Kind regards,

Rodney

 

[MennoJoshua]

Hi Rodney,

What's the goal of the higher system clock?

 

[rodney]

What's the goal of the higher system clock?

Hi MennoJoshua,

There are several goals, generally the purpose is getting a higher resolution for storing and timing events more precisely by having a shorter clock period available.
More resolution and precision may lead to a more synchronous design.

Using a 80MHz input clock, we get a precision of 6.25 ns, assuming that we will be able to use both the rising and falling edge transitions.

Using 100MHz it will be 5ns which is even more precise. I will be searching for a 100MHz oscillator because it may be able to eventually get us to a 25MHz CPU speed if I can find a functional synchronous design model, or let's say, at least a synchronous enough model to then be fully stable at 25MHz.

The most challenging will be the READY timing and adding the dynamic CPU clock back into the design where the new situation will contain more clocked areas which then also may need to scale along with the dynamic CPU clock.

So initially I am using a fixed CPU clock design for development and testing of a more synchronous design, and at some point I will need to rework the whole design to restore dynamic CPU clock operation. I moved back and forth a few times in the past few days however I think it will be better to first focus on a certain level of more synchronous operation, up to a certain point, and then fully commit to dynamic clock conversion of the entire design.

Kind regards,

Rodney.

 

[rodney]

I have looked over the REV4 QFP FPGA project another time and decided to make a few changes and additions to the board.

So I increased the size of the board to micro ATX format and moved everything around so the layout is less cramped around the FPGA. I found that at JLCPCB the micro-ATX PCB size costs almost the same as the tiny board I created before. So we might as well create a fully featured mainboard as far as this will go with the smaller pin count QFP FPGA.

In addition I decided to change the CPLD to a 208 pin chip so we can feature two IDE ports, an LPT port and I also want to be able to optionally test the PicoGUS on the mainboard once the debugging and system control has progressed to full functionality. If tests go well, we can keep this as a standard integrated option since the PicoGUS is also able to emulate different sound cards including the sound blaster.

I have changed the FET switch ICs used for level shifting between 3.3V and 5V logic to a more conveniently solderable TSSOP package, and changed the 286 into a socketed footprint so testing can be done with a variety of 286 chips.

I am again reworking the keyboard and mouse options where I want to change to using jumpers for selecting the solution. Doing this, I can also prevent any conflicting signals from occurring.

Basically this QFP project will serve as the first stepping stone to get a PC/AT built using an FPGA, and if that's successful we can then move on to more advanced usage of larger FPGAs. Using a larger FPGA, we will not need to use any CPLDs anymore to supplement the system and we can also max out the memory, do more development and experimentation etc.

In attachment a picture of the board, it's still a very rough and in progress view where lots of things will change, and the PicoGUS is still going to be added so we will have three pico footprints when it's finished. Using the PS2X2PICO is purely optional for builders who would prefer to use a USB keyboard. As is the PicoGUS, pending tests at higher clock speeds.

Kind regards,

Rodney

 

[rodney]

Okay so I have worked really hard on the updated Micro ATX PCB layout for the REV4 QFP FPGA system.
I reworked most of the board another time to attempt to improve things even further, which has been another huge job to tackle.
I have paid a lot of attention to the power bypass caps and providing additional large power capacitors spread out across the board.

The resulting micro ATX board has now definitely turned out to be a lot more according to the way I would have wanted to see it done.
In the past I saw some things which I would have liked to change and these have now all been changed accordingly.
So basically the board is now finally in a form where I will look forward to build this project and taking the first steps in the development of the FPGA iterations of the project.
Let's hope things will go well so our project will be able to move forward to a higher level of integration while still keeping an original time period 80286 CPU.
So let's see how much this will cost at JLCPCB at the moment to get this board produced for our project.

So the surface of the board has been increased to Micro-ATX which provided more space on the board.
The additional space has also been used to free up more room around the FPGA and to better separate the power areas between different supply voltage sections of the system.
I moved the CPLD into the IO area and increased it to 208 pins for providing more functionality. The CPLD will now also provide a number of LED indicators which can indicate what the CPU is doing. This may prove useful during the debugging phase to know what the CPU is doing at any given point in the debugging process, and what area of memory is being accessed etc.

The keyboard and mouse connections are now selected by jumpers, where the builder can connect the FPGA pins to the back panel keyboard connector and PS/2 mouse pinheader, or connect them to the PS2X2PICO created by GitHub user NoOne, which then enables the use of a USB keyboard/mouse to drive the PS/2 pins. In addition we have the COM1 port directly connected with the USB to serial adapter by LimeProgramming on GitHub. This has been a tried and tested solution enabling pretty much perfect mouse control for the AT system via a serial post mouse driver like CTMOUSE.

Finally I added the third Pico footprint for polpo's PicoGUS. The PicoGUS logic needs to be verified by testing in a later stage, where the tests will need to indicate whether the PicoGUS can be driven by the 286 when it is running around 20MHz and above. I expect it should work as I have elaborated before, however we can even tweak the cycle logic to further slow down the 286 for the IO programming of the PicoGUS if needed. So even if the circuits provided by the CPLD in combination with the PicoGUS functionality cannot keep up with the 286, we should be able to resolve any issues in other ways. Otherwise of course the PicoGUS circuits I created will need to be verified as well. I used the same logic in the TOPCAT REV2 board which I also will be manifacturing together with this board.

I have updated the GitHub directory with the new designs and removed the tiny board versions because they cost practically the same as this larger and more elaborate board.
You can see more details in the PDF prints of front and back of the board which I have provided there, and the gerber files are also there for download and viewing.
The latest schematic is also available on the GitHub for the REV4 QFP system.

Here in attachment a picture to give a first impression of the completed design.

Kind regards,

Rodney

 

[MennoJoshua]

Has there been any movement on implementing an emulator for your architecture in 86Box?

 

[sqpat]

I doubt the 86box team is aware of the architecture. I've more or less put the ems subsystem on an isa card in martypc.

EDIT: I think in 86box's eyes this machine would simply be a generic 286 plus an EMS subsystem. I don't think there would be a lot else to emulate "chipset behavior" for.

 

[rodney]

Has there been any movement on implementing an emulator for your architecture in 86Box?

I am also not aware of anything in that regard and I have not been contacted about this.

I doubt the 86box team is aware of the architecture. I've more or less put the ems subsystem on an isa card in martypc.

EDIT: I think in 86box's eyes this machine would simply be a generic 286 plus an EMS subsystem. I don't think there would be a lot else to emulate "chipset behavior" for.

That's cool that you created the EMS system on an ISA card in martypc Patrick.

Indeed, generally the project here follows the IBM 5170 as closely as technically possible.
When lowering the clock, the functionality could be made even more closely matching the 5170.

So since the REV1 when including all the additions that I have developed, this started to focus on faster clock speeds which then has created the need to control cycles more carefully to make sure the IO and VGA cycles remain stable. If you don't do this, the whole system will become non functional above 16MHz. So this is where our project here needed to create additions to maintain stability with 18 MHz and above, as has been done in the AT industry developing faster and more integrated 286 systems. So you always can know that a system is more elaborate and complex when simply looking at the CPU clock speed.

The methods used in the REV3E are quite complicated and I am not sure how this could be emulated. The thing is that the CPU clock is dynamic and switches while a cycle is in progress. That is related to the transitions which you have when switching, which must match up in both the slow situation and the fast situation. So observing the transitions before and after switching, it's possible to do the clock switching in a completely stable fashion while the 286 is executing the cycles.

Otherwise the REV3E attempts to follow the same principles as the IBM 5170, with the addition of EMS if the driver developed by Patrick is loaded which enables the EMS system. The EMS system remains inert until the driver activates it. For now when in operation it will remain activated until the next power cycle or pressing the RESET button. However a very simple program could also be created to do this and RESET the system. Or maybe just turn off the EMS system and then using the keyboard to restart with CTRL-ALT-DEL would also be possible if someone wants this feature.

Arguably the Address bus driver design differs from the IBM 5170 where DMA address generation is integrated into the Address bus driver. So the DMACs push the DMA mid address bits into the Address bus driver where these are then added into the address output logic, and the XBHE and XA0 mechanisms and passthrough of XA0 coming from DMAC-1 itself are handled differently. Same goes for the 286 A20 handling. And in addition we have a SA20 address line created for driving the 1MB SRAM chips in 16 bit mode. However the functional outcome is still completely identical, just the way the bus operates differs. With the 5170 the bus is joined by different sources using output enabled transceivers or latches, and in the REV3E we have more internal merging of address bits and data bits because of the higher level of integration.

It would be cool though if an emulator could reproduce the cycle exact operation of the REV3E for example but I think this will be very complicated because it requires looking at the logic during every clock transition to know how the timing changes, where there are a lot of factors involved. I also don't know the functioning of these emulators in detail. The emulator would need to separate between each possible cycle that can occur which are a lot of variations in a PC/AT system. Even emulating a 286 chipset system like the SCAT or SCAMP with cycle accuracy would be pretty amazing work really if someone can pull this off. It would be interesting to run the emulator next to the physical system and see if they remain synchronous while running identical demo programs.

Kind regards,

Rodney

 

[rodney]

Okay so after a lot more hard work on the layouts I finally ordered the TOPCAT REV2-U2 and REV4 QFP mainboards made at JLCPCB.
Let's hope these can arrive safely and undamaged.

So the first steps are now taken to finish the TOPCAT development path and getting started with building the first FPGA iteration of our project.

The TOPCAT design has now been upgraded to a completely integrated design where we also have dual IDE, LPT, COM 1 connected with the USB to serial mouse adapter by LimeProgramming, and I have added the PicoGUS integration using the IO decoder CPLD to provide the additional logic necessary for the PicoGUS control signals. Using the CPLD also provides some flexibility on how to handle things in the future.
The CPLD also decodes the address lines for the option ROM, where we are going to use the /SMEMR signal to additionally decode that the option ROM is located in the below 1MB memory address space.
The option ROM is connected to the system databus so the TOPCAT would be able to shadow it and disable "slot" access to the option ROM after shadowing.
The system ROM is decoded by the TOPCAT itself same as in the TOPCAT prototype design.
Otherwise the BUS clock is separately provided by an oscillator which then can be swapped or removed for further testing of synchronized operation of the 331 chip.
I split the OSC outputs between the slot pins and the TOPCAT chips so this may possibly provide some further improvements on the clocking internal core AT controllers inside the TOPCAT chips.
I saw that MSI also did this so I want to test if this can provide some actual differences.
In addition, I have updated the capacitor locations and some other small changes like moving the Pico modules to create more space for the level shifter ICs.
Here in the design we are going to use 72 pin SIMMs because these can typically contain 4 bit DRAMs which in turn enables having smaller numbers of DRAMs on the DRAM memory bus.
Likely this should improve the DRAM impedance to be a lot lower. In addition we will be able to experiment with the drive current settings of the 320 chip, possibly the outputs can be driven with less current and we can test with that to see how this influences the clocking range of the 286.
Otherwise the CPU is now in a socket so it can be swapped by builders.

The REV4 QFP FPGA board has also undergone some additional optimization until I finally just placed the order.

I had another final check in the JLCPCB gerber viewers in the order page just panning around the boards if nothing looks off.
Otherwise it's now up to the testing and debugging phase to see how the project can hopefully transition next into FPGA stage development.
So after I get more familiar with the FPGA iteration in actual functionality of a PC/AT system, if things do go well, we could then possibly start using more and more FPGA technology to further integrate and hopefully improve the AT systems. It strongly depends on the findings whether I will want to proceed further on the FPGA path. I have done my utter best and have worked hard to prepare for this as much as possible, so now the results will be up to how the development and testing will proceed. So I will also be testing the AS configuration of the FPGA which seemed unclear in the documentation, where I have created the design as I believe should be correct. Otherwise the REV4 QFP system is also supplemented with a large CPLD to provide the typical integrated I/O like dual IDE, floppy drive control and a PicoGUS RP2040 which could provide the sound functionality if this also works out well. And we will have a POST display and several status LEDs which hopefully can provide some debugging insights.

So boards are now ordered and I will get back on the results as soon as I can work on them.

In the mean time I will go over a Compaq Deskpro 386DX leaked design to see if this would be viable and possibly could allow us to enter into a 386DX type of system. I didn't intend to work on a 386 but since this design came on my path thanks to Stefan pointing this out, I will look into possibly reworking the design into a more compact format. For starters I will look into replacing the large numbers of DRAMs with some SRAM chips on the board to reduce the total board area. Since we can rewrite the design into a more "discrete" form representation, we could also redesign the memory structure and adapt it to SRAM and not being dependent on DRAM. Also I would want to look into featuring a 32 bit VGA controller whether this would be possible so we can increase the VGA memory transfer speeds. When we create our own memory decoder logic in programmable form, we could also adapt the memory space to possibly accommodate a linear VGA frame buffer access to increase the graphics speeds for example when running windows or other protected mode software, etc. Maybe this would have potential to lead to a 386DX system which doesn't depend on any closed source chipset but instead is fully open source. It's also a big tribute to the historic work done by Compaq. I am sure that is the main reason for having leaked these designs that the hope exists that we could recreate such a system in a more modern format for retro enthusiasts.

Kind regards,

Rodney

 

[rodney]

I just got a link about the PCB shipment for the TOPCAT REV2 and REV4 QFP FPGA mainboards.
I checked the progress and it looks like maybe soon the boards will arrive here.
I hope no issues will happen with delivery and the boards can arrive undamaged.

I will source some parts for both projects soon regarding what I don't have yet. Like the level shifter chips and the FPGA and some SRAMs. At least I can start with the TOPCAT board and maybe do some initial testing to see if the system can initialize and how well it can run regarding the clock speeds. I will need to see if I have some 72 pin SIMM module connectors for the mainboard, maybe I can borrow these from some other system temporarily. I also remember I don't have any 33 ohm series termination resistors.

Anyway I will order some things from Mouser and ebay so I can get started soon to build and debug these two projects.

I will likely finish the TOPCAT REV2 system first since this is much more straight forward to test and debug if needed.
It will be cool to have a complete TOPCAT system eventually where you only may need a VGA card to create a complete system.
I look forward to being able to test very easily, just connect the harddisk and boot up the system.
I still have a few micro ATX cases so I can build the board into a case for stable and easy testing.
This way I can leave the system assembled and can just connect it up.
At some time I will create and test a small module which then also enables a 386SX to be used, and it should be possible to select the CPU and leave both in the system. It depends on whether each CPU can be held in RESET and would remain in tri-state to support the other CPU to then be active on the CPU bus. Would be cool to try this out later on.

Kind regards,

Rodney