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

[rodney]

I am working hard on the REV3E mainboard these days.

I have updated all the REV3E CPLD logic to the full functionality after using the minimal diagnostic configuration.
I also enabled the 8MB of system memory as populated in sets 1, 2, 5 and 6.

I have also transferred the remaining 3 slot connectors from the REV3D to the REV3E mainboard. It now has 5 slot connectors which should be more than enough for further testing.

So I am now conducting a series of different tests with the REV3E built into a PC case.
EMS is also working now and I have been able to run RealDOOM.

I did experience a few general unexpected issues with stability which I am examining by doing series of tests and observing the changes in results.
I have been in this process with all of the CPLD based projects before. Possibly there is still some soldering issue and I will do more extensive cleaning of the board, add more capacitance on the VCC plane. Just a few examples of what I am looking into, it's a process.

So I establish a base of testing and proceed from there to move towards a completely stable system.
This may or may not be time consuming, it depends. These are the things involved in the development of all of my projects, in order to obtain the ideal functionality of the system.

So while troubleshooting, I am updating and following a list of what I plan to change/add etc and each time I will note the changes to log what changes provide increased stability. By following this list I can cross off items and move on towards other changes. And I can retrace which changes have provided the biggest influence on stability.

When testing, I note the status and for example how long the test is able to run will indicate the level of stability obtained with each change.
So these time durations can provide more precise insight into how the stability is gradually improving.

At this time I also will search for the 0.35mm leaded 60/40 soldering wire which I used before for years until it ran out.
This diameter solder wire is one way to be able to add a tiny additional bit of solder to the 208 pin CPLDs on some pins if I wanted to.
All pads are solid which I verified multiple times, however when visually looking at these with the microscope goggles, I would like to add some solder to some of these pads just so they look better as well, besides the pins now already being solid to the pads.

So I am currently working hard on the process I am dealing with to increase the stability now in the tests with the full configuration of the CPLD programming including the EMS system. This is another level of hard work that needs to be done now in this phase.

So I am doing this work especially for other builders of the REV3E so they need not concern with the hard matters I am resolving now, and they can more simply replicate what I have done to reproduce the same resulting system. That's my goal and I am working hard on this. I will then update more detailed information on the GitHub as a guideline for everyone who wants to build the system.

Some changes in my experience may seem very subtle but provide huge improvements. The system is clocked at 22.4MHz which of course is pushing the speeds to the current limit of the design as established so far.

I am planning to experiment with synchronous system control using a much faster clock on the system controller in a later stage. For this purpose I have worked in the move of system control to REV3E to offload as many functions from the system controller as possible, and a section of the system controller pins are currently unused. In the current test process I am using the exact identical programming of the system controller as in the REV3D published in january on GitHub.

In attachment a few photos of the REV3E.

Kind regards,

Rodney

 

[rodney]

Okay I seem to be getting close to a possible solution to increase the stability substantially, likely to 100% already as my most recent tests seem to show.

So I found that when I test on the table with a loose PSU with VGA, soundcard and the IDE drive, all the tests run fine and nothing is unstable at all.

So apparently there is something different when mounting the REV3E board into the case.
What we only need to find out now apparently, is exactly what that significant difference is.

The first thing I suspected was a slight difference in the VCC level of the PSU. The one on the table had 4.93V and in the case 4.82V.
Both are a little on the low side though on the table PSU it was better, and it's difficult to do anything about this other than not so elegant solutions like loading the 12V rail which improves the 5V level.

And probably you can open up the PSU and tweak a 5V potmeter, however this requires a lot of caution when in the future actually loading the 12V current more which may then raise 5V above specs. Maybe in the future I should use a pico PSU or such thing.

Anyway, I swapped the case and table PSU however no luck, still in the case I get freezes.
And on the table with 4.82V it's running rock solid stable.
So it's not the VCC voltage level.

Another important difference that may be the cause is the cooling.

When testing on the table, the cooler is laying on top of the oscillator and directly on the ICs on the board.
Also it blows less air on the 286 itself, this may also be significant.
I tried to replicate this somewhat in the case however it's a little difficult.
The difference is very subtle, however this may be the solution.

So the temperature influences timing and this may be the whole issue.

I will also find some small heatsinks to paste on the CPLDs, so I can do more tests to see how this influences the stability.

Otherwise my next change will be adding some very large capacitors near the CPLDs because I also did that with the REV3D.

So these findings today are very big clues toward 100% stability. Basically on the table we already have achieved this level.
It appears we are very close to solving the remaining issue.

I am running a RealDOOM game duration test and it has not frozen a single time now on the table.

Next I will run a Checkit full memory test and let it cycle.
If that can keep running without errors that is also another clear indication of full stability.

Kind regards,

Rodney

 

[kevju]

So it's not the VCC voltage level.

Are your mounting holes connected to the board ground? Try insulating them from the chassis, or leave only one connected, closest to the power connector.

 

[rodney]

Are your mounting holes connected to the board ground?

It's a consideration I also had because that is also a difference the way ground is connected to the case, and I will get around to this if the things I suspect are not showing correct from the tests I am running. I finished testing on the table for 2 hours and no issues happened.

 

[sqpat]

Cool to see the Rev3E is running and stable!

Meanwhile my boards arrived:




Shockingly took only 9 days to receive after initial order including fabrication. Theres some extras like OPL2, 5434 VGA boards and some prototyping stuff for simms and memory cards.

I don't have all the parts in yet (CPLDs and such wont arrive till the end of the month) but i do have the TOPCAT chipset parts lying around. I'll get started working on it today or tomorrow. I imagine i mostly want to get the surface mount stuff done. QFP maybe worries me less than soldering SOJ and PLCC type stuff but I also have a lot more soldering experience than last time I tried. Meanwhile I'm sure I will come across parts I have misplaced over the course of things... likely to be a month long project.

 

[kevju]

testing on the table for 2 hours and no issues happened

Another possibility is that a component might not be attached as well as it should be. Either having the board sitting directly on the table is making a connection, or screwing the board into the chassis is causing flex and breaking a connection.

my next change will be adding some very large capacitors near the CPLDs

You are likely suffering a surplus of inductance rather than a deficit of capacitance I traced out the path of the high frequency current flowing through some of the decoupling capacitors on your board(the ground plane is not shown). Longer paths that enclose more area have a higher inductance, which raises the power delivery network impedance that the capacitor is trying to keep low. Additionally, large loops both radiate and capture RF energy. Hopefully you can see how the capacitors could be repositioned to improve power delivery.



Also watch out for via slots in your ground plane; these can substantially increase loop area.



For boards that use a single ground plane with a power plane (instead of two ground planes) you should place a capacitor between ground and power next to any via that moves a signal from a power reference to a ground reference (or vice versa). This allows the high frequency current conducted in the plane to stay close to the trace and keep loop area low. If your board has two ground planes, you would use a via instead.

 

[rodney]

Cool to see the Rev3E is running and stable!

Meanwhile my boards arrived:

Hi Patrick,

Thanks for sharing this photo, I am delighted to see these new PCBs! It's a pretty fast service really!
I am just delighted that others can enjoy and benefit from all my hard work and sleepless nights!

The TOPCAT boards look nice and compact!
I even don't have these myself yet, and it also reminds me that I need to finish the quartus project for the IO decoder CPLD and upload that to GitHub, which is no problem of course.

QFP maybe worries me less than soldering SOJ and PLCC type stuff but I also have a lot more soldering experience than last time I tried. Meanwhile I'm sure I will come across parts I have misplaced over the course of things... likely to be a month long project.

The soldering is especially a matter of practice as you also mentioned. I think I shared some example photos in the thread. Good convenient tools, flux, thin solder wire etc are important and also good lighting and very clear magnification so hopefully you can spot any short or non solid pin as it happened, which could reduce your time needed to get the system working. Those are the basics and the rest is purely practicing. Like everything, just doing it is the best thing! The most important step is to get into the flow of the work, and keep persisting until you get the right results. With so many IC pins it's a good opportunity to get lots of practice. It's really a great idea to get into this hardware, I wish you lots of success and hopefully an enjoyable process! The best enjoyment is using a system that you have soldered together yourself.

Okay I also have additional news regarding the REV3E. I started out today with a list of intended changes to the REV3E, and it turns out that in fact a few of the items on my list seem to have sufficed to fix all the stability issues I experienced inside the PC case. This now appears to work the same as the table test situation, and the same as the REV3D as well. Of course, still pending a full range of tests.

So what I did is:
- added 2 large capacitors on VCC near the CPLDs(3300µF) and near the SRAMs (1500µF)
- added a 33 ohms series resistor on the FCLOCK to the system controller. (unsure if this did anything, I suspect it's the caps actually)
I already planned to try out this FCLOCK resistor in the REV3E design so I included that footprint, so now let's test this as well.
So with these changes, already I am now able to run continuous Checkit memory tests of conventional and XMS memory with no errors.
For what I was experiencing before, the Checkit memory tests have proven to be the fastest indicator to show that the issue was present.
Checkit has been testing for 30 minutes without issues and still running, it's looking great so far and a big difference with before!
After a few hours of Checkit testing I will move on to run continuous RealDOOM demo gameplay next.
I also will look into the VCC voltage level how to get this at least slightly above 5V. This is certainly an area which I have not paid a lot of attention to yet.
I will update the GitHub soon with the guidelines how to improve the stability in the same way as my REV3E build here.
Again a great day and big cheer today!!

Great stuff Patrick! And feel free to message me if I can help you with any advice or questions.

In the future we will work on a SCAMP system as well and we can make a compact SCAMP board like the TOPCAT REV2.

Best of luck with your hardware projects Patrick!

Kind regards,

Rodney

 

[rodney]

I have finished running the Checkit memory test cycles on the REV3E mainboard for quite a while without issues, and then started some RealDOOM game demo duration tests.
So I found some freezing issues which may or may not be related to my slot 7 connector.
Also I remember once when I touched the VGA card in slot J7 on the table I got a crash which normally would not happen.

However after moving the VGA card into slot J6, besides curing the bad contact, I also noticed a substantial improvement in the RealDOOM graphics which was clearly visible.
So it is a recommendation to also test with the VGA card in J6, I want to point this out to the builders.

Anyway, I have run the RealDOOM game demo test with release 0.88 for over 4 hours without any freezing or other issues.
So this test was also concluded successfully. Also the display looks clean and no pixel issues anymore.

I am pleased to report that the REV3E so far is showing equally stable functionality now as the REV3D board.

So I have updated the GitHub with the stability improvement guidelines which should be followed to obtain the same stability.
It's not complicated at all, just a few parts are changed.
The capacitors are noted which need to be replaced with larger values, where I noted the values as I used to obtain full stability now.
After doing this, I seem to remember doing the same thing with the REV3D, I will check my debug logs to see if I can find some notes about this.
Anyway, the details are listed in the GitHub.

I will continue doing more longer duration stability tests as I always do with each project release during the development and debug phase.

And I also will upload quartus project sets to the GitHub which are intended for different SRAM population scenarios.
We can support continuous XMS RAM which is transparently supplemented by the EMS system SRAMs soldered in sets 5-8.
When Patricks EMS driver is loaded, the EMS system takes control of SRAM sets 5 and 6 which amounts to 4MB of EMS RAM for running RealDOOM.

Kind regards,

Rodney

 

[Edzard]

Hello Rodney,

That looks amazing!

Best regards,

Edzard

 

[rodney]

That looks amazing!

Thanks Edzard!

I am elaborating the REV3E GitHub more these days, a lot of information has been added and I will add some more practical info that comes to mind.
I also added the pictures of the RP2040 for the USB to serial mouse by Limeprogramming.
The link to his project on GitHub is also on the GitHub page where you can get the programming file to drop into the RP2040 for the USB mouse.

Today I have done some more testing with the REV3E and it appears to have a much improved clock range of operation compared to the REV3D.
This is likely because of adding the series resistor to the FCLOCK input, and also because of running the FCLOCK trace only to the System controller.

Apparently this change has resulted in the fact that now the 286 is able to initialize at 25MHz. However we don't have a full POST yet.
There are a few secondary problems at 25MHz operation, one of which is apparently that the DMACs are not able to be programmed by the CPU by IO writes and reads. Also I have seen other indications that IO is somewhat compromised at these higher speeds.

Anyway the important test result is that in the REV3E, the 286 is now able to initialize even at 25MHz, so that means that it is able to execute the 8 bit mode ROM code, it is able to beep the speaker(system timer etc) and output the POST codes to the display and it also can program the DMA page mapper chip which is one of the first BIOS tests which appears to pass. So it seems to get stuck on programming the DMACs and reading back the status data from them as part of the POST. If it could pass that, possibly it will start to do some RAM pattern tests next and test other stuff like the refresh signal active check etc.

So in the future I may play around more with the System controller CPLD to try to get it to support 25MHz CPU clock.
Anyway, if I would be able to get it operational in synchronous mode, which I am also planning to work on at some time, that also may help to get 25MHz to fully work including DMAC IO cycles. The fact that the 286 is now able to execute ROM code at 25MHz is very promising. At 32MHz it is once again inert as it was before at 25MHz, so 32MHz is too much for the moment.

I have run various elaborate tests at 22.4 MHz, such as continuous Checkit memory test cycles, RealDOOM demo playback for hours, windows idle test and check from time to time if still responsive, windows playing games for longer duration with the mouse, full HDD subdirectory listing scroll tests, floppy formats, writing disk images to floppies. I have not been able to find any further issues, so the testing phase is now basically concluded.
20MHz appears to also work correctly, however I still recommend to run the system at 22.4MHz since all testing is based on this clock speed so far. And of course, it offers some additional performance.

I will supplement the GitHub with some more info that will be useful and can save some time for the builders.

In addition, I have made a lot of progress with the quartus project for the TOPCAT REV2 as well, which will be uploaded to GitHub as soon as I finished it.

Kind regards,

Rodney

 

[rodney]

I have finished and uploaded the TOPCAT REV2 CPLD project into the GitHub.

Unfortunately I discovered a few address lines missing on the CPLD, my apologies about this.
The IO decoder here is also used as a memory address decoder which is a first case to do this, so I didn't notice this while working on the schematic unfortunately.
I have prepared a new layout and will upload it shortly after going over the surrounding ground planes etc.

For anyone who has already manufactured this board, such as Patrick has, sorry Patrick!, fortunately the lines are easy to manually wire at the bottom of the board between the slot address lines and a few unused vias which connect to a number of unused CPLD pins at the top. Starting with the TOPCAT REV2 I am now using vias to provide access to as many unused CPLD pins as possible. So these vias can help to allow easy access to solder a wire on the bottom of the board to one of the vias to connect with an unused CPLD pin if so desired. So in this case we can make use of a few of these vias. I prepared a few images, as seen from the back of the board, to indicate where the wires need to go. The vias that need to be soldered to can be gently cleared of solder mask paint by softly scraping with a small flat screwdriver or similar not so very sharp small tool. It's best to solder a piece of flatcable wire that fits between the vias and slot pins so the wires will remain neat and flush to the back of the board, and are kept in sequence which is also easier to work with. So these manually soldered connections in the pictures here match up with the uploaded quartus TOPCAT REV2 IO Decoder CPLD project and these are also the same pin numbers which are going to be used for the layout update which I will publish shortly.

For a complete test of the TOPCAT REV2, I do advise to take the effort to just solder these wires in so the option ROM feature can be included and also tested with the XT-IDE universal BIOS.

Of course, I will also order the TOPCAT REV2 board made and build it here as well, and I will also be testing and using the option ROM.

So the TOPCAT REV2 CPLD project includes CPU control to direct the TOPCAT 320 to operate in 286 or 386SX mode.
I have added some provisions to prevent even being able to switch the CPU mode at all while the board is powered.
A jumper or switch change should then simply be followed by pressing the RESET button and then the jumper setting should be applied to the TOPCAT during the RESET pulse.
Of course, we will need to test this feature because we don't know whether the TOPCAT reads the CPU mode input pin at power on or also at RESET.
Only VLSI knows this I think. So we will be able to find this out on the build as well.
I also will design the small adapter board which can hold the optional 386SX CPU, the gerbers for this will be added to the GitHub.

Once again, sorry for this omission, it has been on my mind the whole day and this morning I worked to update the layout as soon as possible.
The fixed layout will be available on GitHub shortly.

Kind regards,

Rodney

 

[sqpat]

OK, no problem, I will keep that in mind once I get to the TOPCAT board. I assume the will be pretty easy to solder to.

I've been keeping very busy with various projects. On the soldering point, I soldered a few QFP-208s already on the cirrus 5434 repro cards. I kind of messed up the first one, one pin got stuck backwards and I broke it trying to pull it back. The second one came out messy with one side with totally off-pad pins. It is probably still repairable with a lot of manual work adjusting each leg. I will come back to it.
The next 3 in a row, I got done and confirmed no shorts on adjacent pins. So I am getting the technique down. It was just a matter of finding a technique I am comfortable with. I personally line up the chip as well as possible, flux 2 opposite corners while holding the chip down and get a couple pins down. Then I tap solder to one leg at a time rather than doing the drag technique. Sometimes i am clumsy with the drag technique and i have noticed that i can push multiple a row off the pads. Then it is a headache to repair them, but I have done it. I may revisit soldering iron tip choice.

Also, I don't love the design of this particular 5434 card. There's some odd choices like a 64 KB video rom of plcc32 variety. Then theres a mix of 0603, 0805, 0402, 1206 resistors/caps. Well, if it works it works. The full kicad design is available. I can always make some modifications later if I am comfortable with it.

I will probably try to get the VLSI QFP chips on the TOPCAT motherboards soon. I suppose working on a larger board might be a little tricky compare to those VGA cards. I'm worried about the CPLDs. If they don't work that will be very annoying.

---

If you want to work on a SCAMP board I am down to help in any way I can!

Some interesting things I came across:

- VL82C114 is supposedly backwards compatible with VL82C113, and also supports 32 bit processors and may be tolerant of faster clocks. This is the RTC+KBC chip, part of the 3-chip type SCAMP designs. They both offer ps2 mouse support in addition to AT keyboard support. Perhaps this will be convenient moving forward if you want to adapt this to a 32 bit design later. I have a few on the way, they seem cheap if legitimate chips.
- I ordered some 33 mhz rated SCAMP chips (VL82C311-33FC4) supposedly compatible with either 286 or 386sx. I was under the impression the chips were either 286 or 386sx, but they are either 286 or cross compatible. They are not prohibitively expensive. I believe these chips are popular because they have some use in some sort of AMIGA computer application.
- I came across some comments about a particular TOPCAT machine with two 72 pin slots https://theretroweb.com/motherboards/s/magnavox-286-386sx-20. Funny considering what we know now:

Board is VERY picky on what memory you use. 2 sticks of single-sided 4MB each FPM parity (1Mx36) RAM, consisting of 8 4-bit 1M chips and 4 1-bit 1M chips (see photo) are so far the only thing that made it boot.

Glad to see all the progress meanwhile! I hope to show off a working TOPCAT board around early June if everything arrives and is working.

 

[rodney]

The next 3 in a row, I got done and confirmed no shorts on adjacent pins

That is pretty amazing work Patrick, congratulations and respect for your persistence, it's exactly the most important part of doing this work!

It was just a matter of finding a technique I am comfortable with.

Absolutely, that's exactly it really. Everyone must use common sense to think up their way of how to handle the soldering work. Whatever works, works. When you can get all the pins straight and very solid to the board and no shorts, basically it's done for that chip.

Then I tap solder to one leg at a time rather than doing the drag technique.

Right, dragging is really no good in this case with the tiny pins in my opinion as well. If tapping can suffice, great, or else you also can wipe along the pin direction which may stimulate more solder to creep up between pin and pad. Though flux action also can really do a lot for sure. If it's solid, it's solid.

The next 3 in a row, I got done and confirmed no shorts on adjacent pins. So I am getting the technique down. It was just a matter of finding a technique I am comfortable with. I personally line up the chip as well as possible, flux 2 opposite corners while holding the chip down and get a couple pins down. Then I tap solder to one leg at a time rather than doing the drag technique. Sometimes i am clumsy with the drag technique and i have noticed that i can push multiple a row off the pads. Then it is a headache to repair them, but I have done it. I may revisit soldering iron tip choice.

Really great idea to use the VGA card as a practice project. And it's also purposeful and very rewarding to be able to use the hardware after the hard soldering work is done. Such a card will be much more special than a ready made bought one.

Also, I don't love the design of this particular 5434 card. There's some odd choices like a 64 KB video rom of plcc32 variety. Then theres a mix of 0603, 0805, 0402, 1206 resistors/caps. Well, if it works it works. The full kicad design is available. I can always make some modifications later if I am comfortable with it.

Indeed that would also be possible to modify parts of the design. The original creator has done the really heavy lifting to get to this design, which is the most essential part of course. And of course I am really curious about how this card does in RealDOOM tests later on! It should be a pretty big impact if VGA writes can be substantially faster. This of course also depends on how the chipset used handles the VGA cycle speeds.

I will probably try to get the VLSI QFP chips on the TOPCAT motherboards soon

That sounds great! Well, the QFP chips come first so dealing with empty boards in the direct solder area is pretty ideal because nothing is in the way yet and you have full access from any direction. So basically you are free to work in whatever way feels comfortable. It's not that much different from a smaller board in terms of working on it.

For the CPLDs I would suggest soldering these one by one and adding the ATX stuff so you can easily plug in the PSU and power up the board with a jumper remaining on the RESET header. So the System controller first, then the data bus driver, address bus driver, EMS controller and IO decoder finally, programming each chip after it is fully confirmed solid on the board. I would suggest to do solid checks of all pins at least 3 or more times. If you have trouble not being able to use the JTAG pins, let me know because it may be the case that the JTAG pins are also in use for IO. This situation can be resolved by applying 12V to a certain input, but we had better do this with special care, so if need be I will guide you through the process. Let's hope the CPLDs simply have JTAG still enabled and not some extreme design formerly used on it which also consumed the JTAG pins. When programming, it's best to keep the programming application fully prepared to have recognized the USB hardware, connect the programming cable, power on the board and press the program button. This also tri-states all the CPLD pins which helps that no longer than one or two seconds of any possible contention can happen.

- VL82C114 is supposedly backwards compatible with VL82C113, and also supports 32 bit processors and may be tolerant of faster clocks. This is the RTC+KBC chip, part of the 3-chip type SCAMP designs.

I thought I remembered this too from reading about these before. Well, the KBC and RTC are pretty low speed chips anyway because any AT system must use cycle control to modify the IO cycles. The stuff in the companion chips should be reasonably possible to replace with acceptable other solutions really. And when designing a system, often there is the need for some additional circuits as well like additional onboard IO etc, so using a CPLD is really the best way to approach this. Using a CPLD with a keyboard controller and RTC will make the design much more flexible I predict. There is plenty of board space so that's not a restriction either really.

- I ordered some 33 mhz rated SCAMP chips (VL82C311-33FC4) supposedly compatible with either 286 or 386sx. I was under the impression the chips were either 286 or 386sx, but they are either 286 or cross compatible. They are not prohibitively expensive. I believe these chips are popular because they have some use in some sort of AMIGA computer application.

Certainly we will make some SCAMP systems as well, very much worth our efforts really, just like the TOPCAT as well. Very cool that you managed to source some of these ICs! That these are even available is the main concern really.


Thanks for the link, I will check it out. Indeed the right configuration providing two TOPCAT banks high and low per module is the way to go.
Parity or not, I suppose having these on the module is best. I will test without parity first because my modules don't have that. I think they have some footprints for those so maybe I can add them if required. I remember that parity can be enabled or disabled in the AMI BIOS.

I hope to show off a working TOPCAT board around early June if everything arrives and is working.

I am sure you can do it, and I will also be building and testing one here, the 72 pin SIMM speeds I am also really curious about! It's pretty optimal with less chips attached to the DRAM address and control bus.

Great work Patrick!

Kind regards,

Rodney

 

[sqpat]

I got the two VLSI chips on my first board. 160 pin qfps are so easy after working with a few 208 pin ones earlier. Sometimes the corner pins have a habit of not wanting to connect, but I eventually got around it.

Unfortunately I realized my order of 10ns 208 pin CPLDs from 3 weeks ago never shipped. Perhaps they weren't in stock, but I wish I realized sooner. I put in orders from two different suppliers just now for 10ns and 7ns chips today. I also received a batch of 15ns 208 pin CPLDs recently... do you think that 15ns IO decoders will be enough for the IO decoder or should I wait for a faster chip to arrive?

 

[rodney]

I got the two VLSI chips on my first board. 160 pin qfps are so easy after working with a few 208 pin ones earlier. Sometimes the corner pins have a habit of not wanting to connect, but I eventually got around it.

It's great to see your progress in the work Patrick!

Unfortunately I realized my order of 10ns 208 pin CPLDs from 3 weeks ago never shipped. Perhaps they weren't in stock, but I wish I realized sooner.

I have had similar experiences however I would advise to let the order sit and just wait it out. Even later, it's better to finally have more chips available. Sometimes the dealers also have to put out an order which may extend the time. As long as they strive to fulfill the order at least you can have more ICs available later.

I also received a batch of 15ns 208 pin CPLDs recently... do you think that 15ns IO decoders will be enough for the IO decoder or should I wait for a faster chip to arrive?

Possibly these may work, however you should look at the scenario when they are not sufficient, whether you will be able to desolder the CPLD and resolder the 10ns one. This will also involve using hot air and as a preparation removing any plastic stuff around the area. The slots can be shielded with a piece of solid metal you can place in front of them while working with hot air. So it depends on your tools, do you have a hot air tool that is very fine directional where you can apply a very specific point with sufficient airflow coming out? And secondary, your desoldering tool is that able to remove connectors soldered to a ground plane? So it is a good idea to anticipate needing to remove the chip before soldering it down in place, and what you will be possibly looking at in terms of the work.

I have a Hakko FR-301 which was not cheap, however with a fresh sturdy tip with 1.3 mm hole it makes short work of desoldering connectors or slots. So that's a recommendation generally to readers.

In the 2000 years I worked in repair of data terminals, and the company invested in Weller hot air tools. Those were really the best I have ever used. The level of accuracy applying heat and the amount of heat coming out of the nozzle are really excellent. However, the price of this tool is really way over my budget. Anyway I just want to indicate that the capability of the hot air tool also determines how precisely you can remove a large chip from the board without melting too much plastic around it. In my work in those days, I never removed any plastic stuff from the board, I was always able to direct the heat sufficiently to get large ICs loose. It's a sharp contrast with my current hot air tool which is from a hardware store. It has two settings so I always use the lower one. The big disadvantage is the spreading of heat that comes out. I may look into manufacturing some kind of nozzle for the thing however my caution there is that possibly it will burn itself out if not enough air goes through the heating element.

So I don't have a clear definitive answer Patrick, it's up to you if you want to risk it and just test. Generally, IO cycles are slower than memory cycles so that's a positive point in favor of it possibly being able to suffice. I would say, if you risk it and found IDE access not stable, that would be an indication that the chip select and bus propagation time may be adversely affected. I have no idea how critical the IDE timing is to make IDE transfers within a stable window. If there is some room in the timing, it could work out. The CPLD version of an IDE port is extremely stable, however I am not sure what change made the biggest difference, whether it being the logic levels being favorable, or the propagation time of the data bus, or possibly it may have simply been the two 16 bit IO wait states all along. So that's another tip to look at this in the AMI BIOS if the IO to the IDE drive is not stable.

Kind regards,

Rodney

 

[rodney]

I have worked on the REV3E layout this weekend.
It's no big deal, only a few capacitors added or moved slightly here and there on the board, and then I just optimized the traces and power planes again.
So the layout update is U1 and I uploaded the gerbers.
I decided to add the capacitors since I found that these do make a huge improvement in stability.
So I added a few additional footprints just for good measure.
Otherwise the system structure is exactly the same as my built REV3E board here.
In existing builds, capacitors can also be swapped and/or added in other ways.
I just want to update the board with any findings to facilitate possible changes when building the system.
It's not persé necessary to populate all these elco capacitors but I will add some more on my built system.
I will order a few very large ones to add more VCC capacitance especially in the farthest areas from the ATX PSU connector.
From the REV3D build I almost forgot that these capacitors made a big difference while working on the REV3D, which is now also the case.

I also have more things to test such as I am now testing without pull up networks on the SD bus high and low byte.
So this change appears to work fine, proving my point which I suspected to be the case that these are not really necessary.
So indeed these don't need to be present on the board.
After the initial build and debug I am now able to test more stuff such as removing the pull up resistor networks.
I did find that the IDE drive autodetect on the secondary IDE port does get slower to not find a drive there.
I also saw this happening when not using my Trust sound card previously. When I removed the Trust card or added a normal sound blaster pro, I also got the slow secondary IDE detection waiting for the timeout period. I think this period can also be setup in the XT-IDE so it should be reduced maybe.
Or possibly I need to change some resistors on the IDE port, I will research about this or do more other testing on the port like when adding/removing some resistors on the port itself.

I also will add more elco capacitors on VCC in the main section around the CPU.
I also plan to solder one into the VCC and GND pins of the coprocessor socket just to see how much difference it will make.

In addition I have now been able to test with warmer ambient temperatures since the weather is getting warmer here, and indeed I got some freezing when running the fan at slow RPMs now.
So I switched it back to 12V and indeed the system no longer froze.
I also will order some stick-on heatsinks for the 100 pin CPLDs which I will try to test soon.
The fan I used is is a cheap and loud one when running at full RPM, so I will swap it with a more quiet one.
And I will report back about the findings when using a heatsink.
Maybe we can run without a fan or with the fan again set at low speed with warm ambient temperatures.

I have expanded the GitHub with more helpful information for builders such as the CPLD programming process.
I added the JTAG cable description table how to make one.

In addition I have started to add some 286 system debugging guidelines on the REV3E GitHub.
Such as POST code meanings, what and how to measure the 286 in operation, etc.
Stuff that is useful when building and debugging a REV3E, or even probing other 286 systems.
I may add more to this list in the future.

I also added the missing address lines on the TOPCAT REV2 board layout which is only a small update, and uploaded this to the GitHub.
For the TOPCAT REV2 builders I also added the relevant CPLD programming info for the IO decoder CPLD.
The quartus project is available on the GitHub page as well.

Kind regards,

Rodney

 

[rodney]

Okay as I mentioned a few posts back, I made a list of things I wanted to improve and test on the REV3E.
These days the weather is heating up a little more and I am looking into the cooling details to keep the asynchronous system controller running stable.
I will be testing with some heatsinks added shortly as well.
So far with the recent higher temperatures I do need a 8cm fan running at the rated speed.
This can keep stability without issues.
Of course, this is with the situation where no heatsinks are present.
After I get those I will get back about how this changes the situation.

So other things from my list were the VCC voltage level. I used some cooler master PSUs which were common with my supplier at the time and I have two here.
I opened them up and neither had a potmeter for adjustment of VCC.
So I looked around what other ATX PSUs I had.
I had taken apart some discarded HP PCs, something like 15 years old, and kept the PSUs among other things.
Well, one of them had a HP part number DPS something, so those must be made by Delta and probably worth looking at.
After opening and cleaning one, I found that it indeed has the potmeter. However the measurement of unloaded voltage of VCC was 5.15V, nice!
So I just replaced two caps which had bulged up and measured them, one was only a few µF left... The other also from 1500 down to a few hundred.
I found some old caps which I measured at reasonable capacitance, and put them in. It was for the 3.3V output and 5V output.
Anyway, when starting the REV3E, I still measured around 5.15V or something.
The Cooler master had something like 4.80V so that's 0.3V difference.
The Delta PSU was all SATA so I cut these off and soldered some normal connectors for IDE drive, DVD and floppy etc to the PSU wires.

Testing however didn't result in any improvement that I was able to notice so far.
It didn't seem to increase the clock range.
So apparently the lower voltage seems to not be a problem really in case of the REV3E.
Anyway it's nicer to see a voltage at least above 5V, and a Delta PSU seems like a better choice.
The power draw is so low for the PSU anyway, it's practically no load I think for the thing.
When I move to working with smaller cases for certain designs, we also can look at a Pico PSU or similar power supply to save more space and reduce case size.

I also removed the series resistor on the FCLOCK for the time being which didn't make any noticeable difference either.
Maybe later I add it again but it depends on seeing actual improved test results.

Okay, I just added as much capacitance as I could just to see if any noticeable difference is found.
So I added a large 1500µF cap next to the first slot connector, and a few 2200µF caps around the core CPU and CPLD areas.
In addition I soldered a 1000µF into the coprocessor socket, just for testing purposes at the moment.
In tests I didn't see a noticeable improvement in the temperature/timing.
It doesn't look like so many caps are really needed.
I think what is listed in the stability notes on GitHub is sufficient in that regard.
And builders who want to add more, seems okay.
The VCC caps are really just some value meant as a minimum, and more is also fine.

I tried some fans branded "Bequiet" however these seem to have somewhat lower RPM which turned out not sufficient.
My latest fan is some ASUS barebone salvaged 8cm fan on 12V.
It's more noisy than the quiet ones however the system does keep running without any freezing.
I will just leave this one in and wait until I have the heatsinks to test more.
I also ordered a few larger caps for future testing.
Which reminds me, I will look at the Cirrus Logic VGA card, which also doesn't have much on the card in terms of capacitors on VCC.
I will increase this and remove any tantalum caps.
I will then test more with that change and share more details about this.
Any meaningful improvements I will add on the stability list on the GitHub page.

I am currently using the RealDOOM 0.88 autoplaying demo as a test program, it seems to use all areas of the system judging from the LEDs so it's a very good all-round test.
If that can keep running for days we can call that very stable.

Kind regards,

Rodney

 

[rodney]

I have started with the REV3E system controller to test with clocking this at 64 MHz and 80 MHz. I was able to get the system to initialize by dividing this input clock first and feeding into the existing system controller. However the timing already shifted a little, which is to be expected due to the nature of the asynchronous design. I am able to at least have a partial boot into DOS, which is a start.

I have no idea if this design will be able to even work correctly eventually but I am at least having a go at this. I will work on this from time to time while also continuing other things as planned. I can swap the oscillator and programming each time and then work on this more.

I am also studying the datasheets of the 82284 in more detail to see if I can find some clues into how this chip operates. Particularly the mechanism of turning READY on and off is the most sensitive design area. In the REV3E I am always using a set two 286_CLK clock period for READY to turn on and off. During all my work I found that very subtle shifts in timing can push READY into the on and off timing points to yield a fully stable 286 CPU operation. I achieved those shifts by doing a lot of testing, where eventually I have been able to find the fully stable asynchronous designs.

Here with the much faster clock input, I am already seeing differences of course in how the asynchronous circuits are affected. I used some unusual gate constructions which don't necessarily make sense design wise, however I do know that these have an effect on the actual timing. With the faster clocks of 64 and 80MHz, up to now I have discovered that these unusual gate constructions needed to be removed. Probably the fact that we now get a partial boot happening is related to removing these gates.
On the other hand, the goal of this attempt is to get to a synchronous design. So what I will do is just try some fundamental changes and especially attempt to do all the READY and command related processes in registers rather than using gates and asynchronous flipflop presets.

The whole delicate timing of system control starts with the command assertions. These will result in decodes in the U87 logic of the 5170 system control design, which will lead to READY getting applied further along in the system control. So I will start with creating fully clocked command outputs which will require more registers, and then move on from there trying to clock the decoders into other stages which are then driving READY further along. So the challenge will be to use the faster clock input to shift the timing from the 286_CLK and PCLOCK transitions into where the 286 CPU actually needs it to be. The 82284 datasheet also hints to this because they wrote about how they are using a delayed PCLOCK to clock the READY events. How they create this internal delay, of course they don't say. Anyway it's not a great way since the 82284 is somewhat limited until around 16MHz CPU clock speed, almost failing. Maybe this is a clock limitation or maybe due to using a fixed delay which then runs out of spec. Anyway so the PCLOCK in the 82284 is different from the SYS_CLK timing. I have worked with a PCLOCK_DLY as well in the past, however I was only able to shift this signal by half of the 286_CLK period since that's the shortest clock interval available with the previous oscillator.

Anyway it will be a lot of trial and error since I will need to find a READY on/off window that the 286 CPU will be able to use in a fully stable way. Once I can get close to that, I think it's already part of the way to get to a working synchronous solution.
Maybe I need to do more tests and measurements using a SCAMP system however my scope is just too crude to measure thess precise types of delays. Well, I can try anyway, however I already know that I will need to re-interpret what I see on the screen and factor in the delays between displaying channel one and two which is by standard already a display error of the scope I am using. This error can be determined by using two shifted signals and then reversing the channels, then looking at the actual shift in displaying them. Something like that. It's surely at least a few nanoseconds of error margin.

An additional challenge will be to convert the state machine to a fully synchronous one. The 286 asserts the status signals slightly off the clock transitions. So the question will be, what type of clock resolution will be required to catch the 286 status assertion very precisely when it actually occurs. Being too far off this event will not work in my experience. If the whole state machine is shifted, this will disrupt the entire system control. I would want to maintain the current state machine model with the same transitions between the states, however just to get the transitions by a fully clocked logic timing would be really cool of course.

I hope I will somehow be able to do this with the 100 pin 10ns rated CPLD in the REV3E. I did what I could to reduce the logic and reserve more resources to be left to dedicate for system control only in the chip, so I purposely am using less of the device pins as well so the compiler and fitter could possibly also use the logic in these for the design.

So I am working hard on this but it depends on the test results to find the exact synchronous timing that is able to work with the 286.
And that depends on the faster clock input now being enough to get on this functional timing.
Hopefully we can find some solution to achieve this new design. Maybe finally it can also yield even faster CPU clock operation, I hope we can make a stable 25MHz happen eventually. There have been some indications that maybe this could be possible.

My first step will be to have a single clock functional design at a 16MHz CPU clock. This is a particularly useful speed because it doesn't require cycle control. The Cirrus Logic VGA card is also able to cooperate with this clock speed to perform normal write cycles, which is cool because it operates at the same speed as system RAM with a single wait state. After getting this design to operate synchronously, I will work on introducing the cycle control again. It's a pretty elaborate process really to try to get to this type of fully synchronous or even a more synchronous design.

Kind regards,

Rodney

 

[sqpat]

Glad to hear the Rev3E is stable, lining up the timings of the logic states sounds quite difficult. Is the idea with faster clock that you just have finer resolution for example to make one signal active a "fractional CPU clock" after another?

Something interesting I found out - some 286 overclockers on the vogons forum have noted improved performance in certain things like VGA games by disabling page mode on their chipsets which I found interesting. I will need to give it a try myself, I think SCAMP has settings for this. I could imagine page miss penalties are pretty significant so if a system could just reliably run on 0ws without page mode that sounds optimal.

I wonder if you might want to try it on the TOPCAT by programming the RAMSET register differently to turn it off for the two banks. I don't know exactly if it leads to optimal performance in all scenarios. I have also read disabling interleave can improve performance in the same way, but I can't understand why this would help.

 

[rodney]

Glad to hear the Rev3E is stable, lining up the timings of the logic states sounds quite difficult. Is the idea with faster clock that you just have finer resolution for example to make one signal active a "fractional CPU clock" after another?

Exactly right Patrick.
Previously I used the exact 286_CLK frequency in the design, and I was not yet able to get a fully clocked READY timing.
READY for the 286 CPU is the most difficult signal to get right in the design. Basically if it's slightly off, the system won't run stable at all.
Then for example when you have an INIT and the system starts to boot, you don't get all the way to loading the drivers and getting into DOS.
So with the stable asynchronous system controller, I use other constructions to shift READY onto a functional timing.

Right, so now I am working on a design attempt using the double frequency of the 286_CLK as the input, and dividing it to supply the 286_CLK frequency.
Then I am trying to introduce the double clock into the design to make the timing work out.
For the time being I am using 16MHz CPU internal clock speed because this doesn't require dynamic CPU clock switching to be part of the design.
I needed to remove this to simplify the model slightly otherwise I can't know where any potential issues that may occur are coming from exactly.
Then after getting some model working, I can revisit the dynamic clock and try to run the model on that.

Basically when using the higher frequency input, the entire situation in the system controller is also already shifted now and needs to be reworked.
I found that previous additions for shifting the timing now can't be in place or the system ends up not initializing even.
So I removed the additional gates and now I am getting some limited level of POST and even booting partially.

So that's what I am doing right now, and I am starting with the command logic to try to create a circuit that is able to detect the status and store the command types, and is able to clock the commands back off instead of using an asynchronous clear input of a flipflop to clear the command. So that's the whole idea of let's call it a more synchronous design. If more points are able to stay exactly on the main clock signals, you get a more elaborate synchronous operation which hopefully could work out to operate in a very wide input clock range. If a wide clock input range is fully functional, that is a clear indication in my view that the design is much more synchronous at least in the critical areas that matter. So that would be cool if we could reach that design.

While working on this, I am also starting to realize that maybe a fully synchronous operation will end up being very difficult to create. It depends on whether areas can get functional on the exact clocks and no longer using asynchronous preset and clear inputs of registers. I will see while I progress through the system control. I am taking on sections and trying to convert these to using the clock as the switching mechanism combined with gates determining the conditions for switching the commands, for example. During this work, I know I won't have fully functional operation yet, which is okay for now. I hope that further along I will be able to use the faster clock to shift a clocked READY signal onto a timing that the 286 supports. So rather than using some gate logic delays to shift READY away from the exact clock timing, I will try to run the READY signal through additional clocking to shift it into the right timing window for the 286. The whole situation is necessary because of the shifted status output timing of the 286, so the system control must adapt to this in a synchronous way, that's the challenge.

Well, I did find a way to store the cycle type and clock the commands back off using the 286_CLK falling edge which is a timing point in the Intel 286 cycle model. The falling edge of 286_CLK is at the 286 cycle boundaries and also occurs mid cycle. Then you have the status outputs which are asserted slightly past the falling edge of 286_CLK during the T_STATUS, the address setup stage. So you can't clock the status signals on the cycle boundary. Mid cycle, you can, which coincides with the timing of ALE.

So far I am able to run a functional /MEMR and /MEMW output using the 286_CLK falling edge, and using the command delay and conversion cycle registers to gate the memory commands to the outputs. As long as I can keep seeing this identical level of partial boot at least, I know the command timing is at least correct since it's able to detect all the fast RAM and also read the ROM code in 8 bit mode. The command timing is critical not only for the commands themselves to succeed but also because it drives the decoders for READY pre conditions.

Hopefully while keeping the functional situation going, I can then create a new READY timing logic that switches exactly on the fast clock. I will try again to use PCLOCK to clock READY on and off synchronously which then uses a single flipflop to control READY with the PCLOCK cycle timing. Then I will try to introduce some delay to READY using that finer granularity until I can see the 286 CPU starting to respond again.When starting the new READY logic. I expect the whole system to go dead at first until the READY timing is improved. I did find that the 286 can really support trying to find the right timing, though it will take a lot of reprogramming and testing.

So my idea is to get the first stages all switching exactly on the main clocks, and then making provisions for shifting the READY timing to functional level using the finer clock input so it can remain locked on a clock transition.

Something interesting I found out - some 286 overclockers on the vogons forum have noted improved performance in certain things like VGA games by disabling page mode on their chipsets which I found interesting.

That is indeed very cool that this is the case. It can tell you something about the internal workings of fast page mode DRAM commands.

I could imagine page miss penalties are pretty significant so if a system could just reliably run on 0ws without page mode that sounds optimal.

Maybe that's indeed the case, and worth a test of course.
I think the less complex way to achieve 0ws is interleaving which will be much less prone to needing to return to a normal command mode dynamically if the fast page type command is decoded not to be possible within the same page frequently. Where the interleaving may be relatively more solid to occur more frequently. Also the interleaving is able to work without using fast page mode because each bank is able to be RAS clocked separately, rather than trying to clock RAS page once and perform multiple CAS cycles which is much more complex.

Thinking about this, of course I still have hope that some really skilled and talented decapping experts could one day take on the task of fully decoding all the logic in the main chipsets like SCAT and SCAMP, and the TOPCAT. And maybe an Acer 286 system controller as well which seems to run pretty fast. Maybe using AI to process the chip die shots could provide a solution, who knows. This type of work also could serve as a historical preservation of technology which would be really great if that could happen one day.

I wonder if you might want to try it on the TOPCAT by programming the RAMSET register differently to turn it off for the two banks.

Doing this will probably require setting this at INIT time in the BIOS. I don't expect switching this dynamically while fully initialized and fully booted will result in the system remaining functional.
Any reset will likely revert back to the BIOS configured register.
Of course, I haven't tried this yet. I will keep it in mind when setting up the TOPCAT system to look into that.
I can try to use the SCAMPCFG tool you created.
If we can change it and then be able to retest the performance, we might learn more about this.
It's interesting and thanks for relaying this info here!
If this could increase efficiency that would be a big win.

Kind regards,

Rodney