Thanks for pointing me to this interesting other thread as well. I replied to this just now offering my theoretical two cents to the conversation.

Regarding the 486 support in my next iteration, it will be a huge work to get this going. The 486 has no 82284 and 82288 type of equivalent IC to get the system going initially, so I will need to depend completely on reading the Intel timing diagrams in the datasheet/book and developing the logic to create my own CPU state machine and the system control mechanisms. With the 286 I did this same work in the end, however with the 486 I will need to develop this right at the beginning to even be able to execute code and have a functional system. I will probably modify an existing 486 mainboard in order to test out my own system control circuits on the CPU in order to replace the existing ones from the chipset one by one. I will create a method as I go along in the process. Basically it involves first creating a predictive CPU state machine model, verify this against the actual CPU in operation and comparing everything with the datasheet diagrams. In my VCF thread anyone can read how I am going about this project, and how I did it with the 286.

I am preparing the work leading up to integrating the 486 CPU into the system so I am not reading into this specific documentation yet. That will come when I have all the PCB designs ready and I have everything built up for testing because the preparation itself is already a lot of work. I have been warned that designing FPGA logic is even harder than using CPLDs for this type of "asynchronous" functions as in an PC/AT system which are easy to be skewed by seemingly insignificant circuit changes in any area inside the FPGA. The compiler may completely "overhaul" the programmed file for the FPGA at any time which may pose a new challenge every time to fix the problems, that can occur at any moment during the project. Anyway it was kind of newold86 at VCF to give me a heads up about this. So it will be the trick to find ways of changing the core AT design to become more "immune" to compiler changes.

Another challenge using different types of 486 will of course be the CPU voltage which is different between different types and brands of the 486 CPU. So I will need to design an interface between the FPGA and the CPU which has a variable logic voltage on the side of the level shifters connected to the CPU. Then we have the interface between the FPGA and the 5V ISA slots and cards, and with the 32 bit connection to a VGA adapter it may also pose other challenges, I am still doing the research and preparation of the various modules incrementally, so I will know more details about the actual complexity later. As far as the RAM is concerned I also will need to look at the voltages involved which type of RAM is most compatible with the FPGA of choice. A lot of work ahead.

I got some support from Luca (Retro*Tech) from Italy, who offered to help me and donated a ST 486DX4V100, which will be one test subject for the project.

I will start testing the system using a custom 286 module just to verify lots of things like the ISA slots, onboard I/O and memory interface. There will be the chance to speed-test the 286 to its limits. I talked with user sqpat who is also doing very cool work. He overclocked some 286 CPUs to above 30MHz using a TOPCAT chipset mainboard. Not only is he doing that, he created a custom cooling solution to keep the CPU from burning out, and he is developing his own port of DOOM for the 286 called RealDOOM, where he is using Real mode of the 286 because the TOPCAT chipset is able to generate a paging system within the 640KB base memory area. So he can keep software in the lowest section running while flipping the pages to load in DOOM game data. A unique and cool approach, and a kind of challenge to get this port fully optimized and I would imagine it involves a lot of code rewriting and completely new game loading configuration and mechanisms.

Anyway, thanks for the interest magicalhippo, it's much appreciated.