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

[sqpat]

Amazing Patrick! I have done my utter best to further advance these projects for those enthusiasts who want to build one.

I hope you will also enjoy the experience of building these systems!

For a REV3 CPLD system I would recommend the REV3E because it is the next stage version of the REV3D and the SRAMs are moved onto the mainboard which is also much more convenient.
With the SRAMs onboard it's pretty simple to add more RAM at any time you want later on.

I also have plans to work on a new SCAMP micro ATX design, possibly even a few different types of SCAMP designs.

I may attempt to use CPLD technology and a few simple core AT controller chips to replace the more difficult to obtain companion chip to the SCAMP.
I think the CPLD can drive the address bus to the slot with very sufficient speeds.
I will give this more thought how to proceed.
Having a CPLD also will further enhance a more complete SCAMP based system with integrated IO decoding and possibly a PicoGUS.

Kind regards,

Rodney

Oops, Yes I meant Rev3E, as opposed to Rev4 FPGA one (for now). It'd be nice to put the srams directly on the board, yeah.
The minimum orders via jlcpcb are also 5 boards, so I may do more than one, or order 5 sets of ICs and parts in case someone else wants a board and set.

I remember the SCAMP support chip being listed on ebay in small amount (~25 chips) one day. Then a week later or so, they were all bought. I'm not sure, maybe they are still in use industrially somewhere, so I sort of gave up on acquiring those chips in general. It's a shame because its a really cool chipset. If you ever get around to that, it'd be neat. I don't have enough experience running topcat machines to really judge, but it feels like SCAMP has some amazing stability as a platform to widely different bus and cpu speeds.

It's cool that picoGUS exists as an option, but it seems problematic in that sound hardware mostly struggles to exist on a faster bus. This is not just the picogus but even sound blasters, etc also struggle to run at 10mhz plus ISA busses. My hardware understanding is not at the level to be able to judge this yet, but is it a possible/easy thing to have a fast bus and a slow bus? Speed sensitive devices like a sound card may perhaps behave better on a slower bus, without dragging down performance on other devices on the bus like disk and video. (Or do integrated devices like IDE already have the ability to run at a different bus speed than the rest of the bus?)

--

By the way this reminds me - theretroweb added some photo someone took of decapped/delidded topcat dies:

ISA Bus Controller VL82C331
System Contoller VL82C330

It's pretty interesting to see a sixth of the die is the EMS page register memory in the System Controller. I think its about 4-8 kiliobits. I remember hearing that during 386DX development (which would have been years before the VLSI topcat), Intel engineers would be able to fit only 512 cache bytes on the die and decided against putting L1 cache in the chip because they did not believe the performance gain would have been worth it for such a size of cache. It shows the limited transistor budget that existed at this time.

 

[rodney]

It'd be nice to put the srams directly on the board, yeah.

Indeed, and I found even more flexibility in the assignment of XMS/EMS where you could actually populate only the first set of two XMS SRAMs to support conventional, and the remaining 4MB can be soldered into the EMS section which can then be configured to function as both XMS and EMS depending on loading your EMS driver or using it as 6MB XMS. In the REV4 QFP FPGA test stage we will have 6MB on the board too which can then also be freely configured in similar combinations as with the REV3E. The REV3E has additional lines between the CPLDs to support this free configuration, and I even added more than needed for possible future use.

I will still have another look at the REV4 QFP board to check whether mouser may possibly have some more easily solderable packages for the level shifters which are a little odd shaped for normal hand soldering. It's doable but I will check whether there are maybe some other SMD packages. Changing these packages would be trivial so I will at least check the packages sold on mouser for these chips.

I remember the SCAMP support chip being listed on ebay in small amount (~25 chips) one day. Then a week later or so, they were all bought

My god what a pity, that would have been able to support building 25 systems!
I really would like to know what the buyers are doing with these!
Anyway, I think it's not a big deal not to have these, I will read the datasheets again and then I will know what it would take to not be needing these support chips.
I will post more details about this as soon as I have this sorted out.

It's cool that picoGUS exists as an option, but it seems problematic in that sound hardware mostly struggles to exist on a faster bus

I am not so concerned about this, I have never had any issues with my sound card and I will do extensive testing and share the detailed experiences here in the thread after building the TOPCAT REV2. This will also help other potential builders who may not have used a PicoGUS before to gain more insight into what it is able to provide to the user.
More details will follow here in the future for those who are interested!

My hardware understanding is not at the level to be able to judge this yet, but is it a possible/easy thing to have a fast bus and a slow bus? Speed sensitive devices like a sound card may perhaps behave better on a slower bus, without dragging down performance on other devices on the bus like disk and video. (Or do integrated devices like IDE already have the ability to run at a different bus speed than the rest of the bus?)

It's a complex subject, basically I don't really like to refer to it as some clocked bus, I know this is a popular thing, but rather different types of cycle control mechanisms are involved where the clock that drives the mechanisms is generally one factor. But there are more types of cycle control as can be found in the REV3E design which actually in addition modifies the 286 clock itself, which is going one step further really to control the CPU itself directly. So when you use a scope to measure the 286 clock input on a REV3E, you will actually see the dynamic clock shapes as these are going into the 286 which I just feel is really a cool thing. Switching over the clock on a 286 while it is fully running and doing this with a CPLD was difficult to say the least and really only can happen synchronously in two very specific points of the clock transitions. And this not only involves the levels and transitions of the CPU clock but also needs consideration of derived clocks such as the SYS_CLK and how these are transitioning and "scaling" during each switch over. So this doesn't occur precisely on the cycle boundaries, but actually in specific points within the cycles themselves while these are in progress.

With the REV3E, all I/O cycles are simply assigned as slow AT cycles. And it still can achieve IDE speeds of over 4MB per second. So far I have not seen a chipset which is also doing this same dynamic 286 clock control, I have checked but I was not able to find this happening with the chipsets so far. The 286 CPU is able to be manipulated in many ways to influence and discern between different types of cycles. What I can say about the TOPCAT, and this probably also applies integrally inside the SCAMP, is that there are two CPU cycle state machines. With the TOPCAT these are located in two different chips. So the 320 has its own state machine which simply put mostly involves the fast onboard DRAM cycles. And the 331 has its own status inputs which are driven by the 320 in some way, along with the clock to the 331 which is under control of the 320 as well. It's my theory that the 320 probably only outputs the cycle status to the 331 if it's actually a cycle that is decoded to involve the 331. Hence as VLSI calls it the "quiet bus" operation. Generally we can call these slot cycles which is just a referral to all the other cycles which are not decoded as fast onboard 16 bit DRAM cycles. Not necessarily only on the slot either. It seems VLSI wanted to simplify the terms. Generally I don't think there is any difference between same type IO cycles regardless of what 8 bit device how these are handled, so we have 8 bit conversion IO cycles, we have 8 bit DMA cycles between system memory and IO, and we have 16 bit DMA which is much less used. Then we have 16 bit IO cycles like IDE which are faster, but not as fast as VGA memory cycles could potentially be, which normally should be the second fastest cycles and closest to the onboard DRAM speeds. 8 bit IO is because of the 8 to 16 bit conversion much slower, by default it's 4 wait states but in practice the ARDYEN mechanism is able to introduce even slower timing. If those 8 bit IO cycles cannot go, that means that the system is really operating far beyond what is even sensible. It's just not a good idea to do that because if 8 bit IO cycles which are the slowest of all cycles are starting to fail, that also means that the core AT controllers likely also will be having the same issues. So that would for example result in POST issues related to the timer, interrupt controllers, keyboard not working, etc.
Also the PicoGUS operates on a 8 bit data bus connection which is the slowest type. So even with a lightning speed state machine driving the IO cycles, the whole mechanism will still slow that down considerably. So to me right now it just looks very unlikely and not that concerning. The PicoGUS is even more advanced because it is even able to influence the READY process using the IOCH_RDY input to the cycle control. Even IDE drives are mostly not doing that, however for a VGA card this is an essential part. So the PicoGUS would behave similarly to a VGA card in that it can direct the IO to match its own CPU IO speeds. And otherwise a lot of sound IO is done by the slow DMAC.

I really need to do more testing which I will after building the TOPCAT REV2.
For several reasons I expect this to potentially faster than the REV1. So I would advise anyone building the REV2 TOPCAT to use a 320A chip which appears much faster to me.
Also the Intel version of the 331 may contain some improvements as well.

I think its about 4-8 kiliobits.

Interesting those 330 die shots. So that's the 386DX version of the TOPCAT. Which needs the 331 and I think a 332 or something.

Indeed these page registers are plenty and so apparently also cost a lot of die space in the TOPCAT and SCAMP.

What we need is someone who is able to do this with the 320A and then go all the way to the finish and determine the complete original logic on a gate and flipflop etc level.
Maybe AI can be used to rewrite the image into an actual exact logic representation.
Now that would really interest me a lot and I feel it's important if possible to preserve all this historic technology which includes the VLSI TOPCAT.
If we can reproduce the exact technology that would be really a worth while effort.

Kind regards,

Rodney

 

[rodney]

My hardware understanding is not at the level to be able to judge this yet, but is it a possible/easy thing to have a fast bus and a slow bus?

I have given this more thought and one point is, with the VLSI system model as used in the SCAMP and TOPCAT for example, there are a lot of different ways you can configure the two state machines involved, where the "331" or SCAMP equivalent internal state machine part would be the "slow bus" as you call it.

The other point is that you are doing a lot of extreme overclocking so I am not sure what would be the exact complete scenario where you are observing a sound card to start to fail. Maybe it's the combination, and the timing, of the specific configuration that is acting up in your cases you experienced. It may look like the slot cycles are setup at for example 10MHz, but that could be a different situation if the faster state machine is running above 30MHz.

When you increase the system controller and 286 clock to above 30MHz levels, there may be other timing issues existing in the interactions between the system control state machine doing the very fast DRAM cycles and the slower "slot" state machine. If the timing between these two starts to fail that may be another explanation of the sound card failures you have seen. The thing is, when the system control state machine is running at much faster speeds, this will also start to affect the slot state machine cycles even when those are controlled from a slower clock oscillator or division. When the 286 clock is higher, the 286 will still need to complete the slower slot state machine cycles which may get compromised if it's running at these high speeds. Maybe the fast CPU is starting to fail in completing the slow cycles.

Really to fully understand the exact failure mode I would need to have the complete test conditions that are being used:
- which chipset board?
- what is the fast 286_CLK oscillator speed?
- what is the BUS_OSC frequency and configuration settings used in the BIOS to set the "slot" related operation speeds?

I think your main overclock system as you mentioned is the SCAMP so maybe later you can let me know the complete configuration as used where you observe sound card failures.

Anyway, I will do more testing when I have the new TOPCAT REV2 built.
If we both use the same chipset build, BIOS and using the exact same configuration, speeds and synchronous/asynchronous clocking mode, I will be able to have a better picture of where and how certain failure modes are happening. If I can replicate the situation I could try to find some way around the failures as well.

I can try to do more testing with my SCAMP systems here as well and try to push the CPU further and then retest the sound under other conditions to maybe see it actually failing here. So more details of a failure mode test situation that I could replicate should help me to produce the same issues.

Otherwise I will just try to push the 331 slot clocks higher and see what happens to the sound card, should be fun!

Kind regards,

Rodney

 

[pirate]

GitHub - No0ne/ps2x2pico: USB keyboard/mouse to PS/2 interface converter using a Raspberry Pi Pico

USB keyboard/mouse to PS/2 interface converter using a Raspberry Pi Pico - No0ne/ps2x2pico

github.com

for usb keyboard

can be setup w ps2 passthrough via jumper

 

[rodney]

for usb keyboard

can be setup w ps2 passthrough via jumper

Hi pirate,

Are you interested to build a specific project?
I remember you were maybe interested in building a REV4 QFP board?

What I need to do is order some pico boards, I want to have the actual hands on test results and experience of this project when combining different keyboards etc. When I am more confident after having seen this reliably in action, I can use this in more situations as well.
And it would be even better to be able to combine the USB to serial project of Limeprogramming with the keyboard part of the PS2X2PICO project.
If someone who is skilled at working with the pico would be able to do this I would be very interested to test this.
Though I am realizing it would need some simple kind of USB hub to plug in the USB keyboard and mouse to the system.
However there is an advantage because not all projects are based on a PS/2 keyboard and mouse, and adding a UART is simpler.

I still may make some more updates to the REV4 board to simplify a few more things.

I have looked at the REV4 QFP PCB this morning and this also can be reduced in size to also be able to fit inside a micro ATX PC case.

So I modified an alternate project to be able to create a smaller more compact board.
I will probably put two gerber versions on the REV4 QFP GitHub for the different case size options.

Regarding the board costs, I quickly generated the gerber files however it only makes about 4 or 5 euro difference at JLCPCB.

However for a smaller case option that could be interesting for certain potential builders so I will include that smaller board gerber file archive later in the GitHub. Patrick you may also like this even smaller board format.

Since I will need to order more pico boards for the PicoGUS, I will test the PS2X2PICO in more detail pirate.
I may use a cheap PS/2 keyboard for some more risky experiments to see if different solutions could co exist.
Maybe using separator resistors are a safer way to just be able to populate the same parts for all use cases.
Or using some diodes to prevent conflicting connections.

And I would like to know if someone would be able to find out whether the USB to serial solution could be possibly combined with the keyboard part of PS2X2PICO in a single pico module?

Kind regards,

Rodney

 

[pirate]

Hi pirate,

Are you interested to build a specific project?
I remember you were maybe interested in building a REV4 QFP board?

What I need to do is order some pico boards, I want to have the actual hands on test results and experience of this project when combining different keyboards etc. When I am more confident after having seen this reliably in action, I can use this in more situations as well.
And it would be even better to be able to combine the USB to serial project of Limeprogramming with the keyboard part of the PS2X2PICO project.
If someone who is skilled at working with the pico would be able to do this I would be very interested to test this.
Though I am realizing it would need some simple kind of USB hub to plug in the USB keyboard and mouse to the system.
However there is an advantage because not all projects are based on a PS/2 keyboard and mouse, and adding a UART is simpler.

I still may make some more updates to the REV4 board to simplify a few more things.

I have looked at the REV4 QFP PCB this morning and this also can be reduced in size to also be able to fit inside a micro ATX PC case.

So I modified an alternate project to be able to create a smaller more compact board.
I will probably put two gerber versions on the REV4 QFP GitHub for the different case size options.

Regarding the board costs, I quickly generated the gerber files however it only makes about 4 or 5 euro difference at JLCPCB.

However for a smaller case option that could be interesting for certain potential builders so I will include that smaller board gerber file archive later in the GitHub. Patrick you may also like this even smaller board format.

Since I will need to order more pico boards for the PicoGUS, I will test the PS2X2PICO in more detail pirate.
I may use a cheap PS/2 keyboard for some more risky experiments to see if different solutions could co exist.
Maybe using separator resistors are a safer way to just be able to populate the same parts for all use cases.
Or using some diodes to prevent conflicting connections.

And I would like to know if someone would be able to find out whether the USB to serial solution could be possibly combined with the keyboard part of PS2X2PICO in a single pico module?

Kind regards,

Rodney

Hi,

I want to build something of my idea of a clone of a 'workstation' based on the 286 but with my nice modern usb mechanical keyboard (and mouse) and run Coherent on it.

 

[sqpat]

As far as the high bus speeds I mentioned - I had in mind my usual 25 MhZ SCAT router board which runs the ISA bus at 1/2 of clock speed, so at 12.5 mhz. This is probably towards the more mild side of overclocking the ISA bus, but at this speed I struggle to find many sound cards that work, and I think picogus itself says 8.33 mhz or lower is required in the documentation. It's not incredibly impactful on performance to lower disk and video cards to these bus clocks, and I can configure to a 1/4th divider and make it work.

Really to fully understand the exact failure mode I would need to have the complete test conditions that are being used:

Yes, I brought up a very general question and you bring up a good point, the behavior depends a lot on the system. For example what is happening when you write to a video card's memory? With an XT or early AT systems its very simple as the bus and cpu clocks are synchronous but on later systems depending on the chipset and how advanced it is, there might be some logic to introduce wait states to account for the difference in clock speeds. Or maybe the memory is written to at cpu clock speed instead of bus clock speed in some cases with 'fast video' writes. But when it comes to sound hardware I really have no idea what is going on. I just assumed the bus clock was used to drive some component on the card too fast and it failed to run properly.

I was going to order some OPL2 ISA card pcbs, but I suppose I will tinker with it and investigate what causes it to fail at high bus speeds. Maybe I can figure out a way to modify it to tolerate high bus clocks.

As for the SCAMP, yeah I run that at 30+ mhz bus speeds, but I have never even bothered trying sound cards in that configuration as I assume its hopeless.

---

I'm ready to make the order for the TOPCAT Rev2 board and Rev3E boards on JLCPCB. I wanted to check if there are recommended options besides the default for the PCB. I did not see any notes on github and browsed through the thread a bit. It seems you suggested 1 oz inner copper layer - is that correct? ENIG finish is probably not necessary if there are no edge contacts, I assume. (I may wait for the Rev4 boards because I imagine I won't have time to get to it for months, and you may come up with some ideas in the meanwhile)

It will take a few weeks to receive the board and also arrange for all the components. The TOPCAT assembly does not look as bad as the Rev3E, which looks like a lot of work (but has the helpful BOM). I think just a single board will involve a couple hours of soldering per day across a week. I will make sure to practice QFP soldering on some test kits beforehand. Hopefully I can have one of the boards assembled in June or July. I imagine its very possible I will then have to debug it as some random chip here or there might not be working.

 

[rodney]

As far as the high bus speeds I mentioned - I had in mind my usual 25 MhZ SCAT router board which runs the ISA bus at 1/2 of clock speed, so at 12.5 mhz. This is probably towards the more mild side of overclocking the ISA bus, but at this speed I struggle to find many sound cards that work, and I think picogus itself says 8.33 mhz or lower is required in the documentation. It's not incredibly impactful on performance to lower disk and video cards to these bus clocks, and I can configure to a 1/4th divider and make it work.

Okay thanks for the info Patrick.
I will do more tests with the SCAT board you sent me to try to replicate this.
With this happening I also think the only thing you can do is use a larger divider.
You also can check whether there is possibly some IO wait state option.
It depends on the sound card whether it uses 8 bit IO or 16 bit IO.
Regarding DMA cycles we would need to look into DMA clocking and wait states as well.
A lot depends on the clock source of the integrated DMACs which hopefully is not derived from the fast clock oscillator.
I have seen DMA options in the TOPCAT BIOS where you can also tweak the DMA speeds which may help.
It's worth a try if these options are available.

Or maybe the memory is written to at cpu clock speed instead of bus clock speed in some cases with 'fast video' writes.

Indeed and this needs a lot more testing. At some point I need to drill down on all types of 286 systems and compare these with eachother.

I do remember noticing with the SCAT that it does really well with the VGA memory cycles.
So it's also really great with RealDOOM.
With the REV3E I am also slowing down the clock of the 286 itself when decoding a VGA cycle.
That is essential with the REV3E to keep a stable display otherwise the cycles are too fast.

But when it comes to sound hardware I really have no idea what is going on.

Well, since you mentioned these issues which I had not experienced, I will pay more attention to testing sound cards under different IO speed and DMA conditions. I can change clock speeds that may affect IO and try to introduce issues by increasing the IO cycle speeds. I am also interested whether it's DMA or IO causing sound to fail. Since there is mention of bus speed I assume it's the CPU IO cycles. Maybe I can try to clock the DMA faster in the REV3E and see if the sound starts to fail. In addition I can try to raise the clock that controls IO speeds with a chipset system and see if I can correct the IO issues by increasing the IO wait states. Maybe such a construction can keep VGA cycles fast and still allow sound to work. I will examine in more detail and try to find some ways to possibly compensate for higher speeds.

I was going to order some OPL2 ISA card pcbs, but I suppose I will tinker with it and investigate what causes it to fail at high bus speeds. Maybe I can figure out a way to modify it to tolerate high bus clocks.

That would be cool, maybe with IO wait states something can be achieved. These at least don't affect VGA memory writes.

I have never even bothered trying sound cards in that configuration as I assume its hopeless.

I see about this. I will test in more detail with the maximum clocks I am able to get in my test hardware.
I just want to experience this fault mode so I can get some idea about it.

I'm ready to make the order for the TOPCAT Rev2 board and Rev3E boards on JLCPCB. I wanted to check if there are recommended options besides the default for the PCB.

That's a good point, mostly I always ordered the default board values for copper weight, however what I can recommend after one board got really damaged by my insistent tinning of some of the CPLD pads with my soldering iron set really hoy like 450, is to check what it would cost to use ENIG finish instead of HASL. Possibly ENIG finish may be a little more solid, and one thing is that the pads are much more level than with HASL.

Generally I can advise when soldering to use around 350 degrees on the iron, and using a thicker wedge tip to pre-tin the SMD pads to load them up with solder after applying generous amounts of no-clean flux, and then cleaning the board and positioning the chip. Then the chip can be fixed in place by heating a few pins on each side, then applying flux and using the same larger wedge tip just to wipe the pins so the solder can flow onto the pins. Using a larger tip enables to transfer more heat without the iron cooling down, and the rounded surface of the tip is also more gentle as not to scratch or damage anything. So this final flow and reflow step can be repeated a number of times on all the pins. After about 4 passes of reflowing, you can clean off the flux from the pins to you can see them clearly, and then start checking each pin if they are solid by touching them with one tip of a pointy thin tweezer. I also repeat the solid-check a few passes just to ensure I didn't miss anything being loose or almost loose.

Once you have practiced this routine and gotten used to what it takes to get all pins solid, you can solder any SMD QFP package really. I will post some example photos of the soldering stages just to illustrate the process. So the idea is to load up all the pads with solder, and that is all each pin will need to bond solidly to he pad. So then only remains to heat each pin and get the solder to flow onto it.

The pre-tinning, I found that it is best to wipe back and forth along the length of the pad really fast and just move over the row of pads with a certain speed while doing this. And the solder should be leaded and you can put more on the soldering tip than needed so combined with loads of flux, the solder will only remain on each pin as much as it can hold, which should be enough. So when you see this you can move forward and adjust the progress speed to keep this result. If too much solder starts to stick, just stop, clean the tip and add more flux first, since flux tends to evaporate or sometimes moves away from the heated area. Also the tinning you should keep a goal to do this in the minimum time to get a proper tin layer on each pad, but not overdoing it because the solder mask may start to become a little compromised. I also noticed that if the flux was evaporated, the solder mask is a little more vulnerable because the flux being present also will cool down the pads a little. Sometimes I wanted to do a better job which was a mistake because it introduced too much stress. However at the time I was also at 450 degrees with the tip so that may also have played a role. Anyway it only happened to me once to damage a board and once I was aware that this could even happen, that was already enough to prevent it from happening again.

(I may wait for the Rev4 boards because I imagine I won't have time to get to it for months, and you may come up with some ideas in the meanwhile)

Right, with the REV4 board I may have a few more things to update. I may change the switch ICs that do the IO voltage translation if I can find a more conveniently solderable package. Also I may do some testing of the Pico USB to PS/2 interface to possibly make a fixed combined circuit where there would be no optional parts needed, just one layout for all types of keyboard/mouse where you could plug them all in without damaging anything. I just don't like to need so many options and I am really searching for a solution that appeals to me more. On the other hand I am also eager to start with the QFP FPGA just to get some hands-on experience with how it responds to programming. And of course whether the integrated core IO chips can function in the design. I may order the extra small board that I worked on so I can build it into a small PC case for testing.

It will take a few weeks to receive the board and also arrange for all the components. The TOPCAT assembly does not look as bad as the Rev3E, which looks like a lot of work (but has the helpful BOM). I think just a single board will involve a couple hours of soldering per day across a week. I will make sure to practice QFP soldering on some test kits beforehand. Hopefully I can have one of the boards assembled in June or July. I imagine its very possible I will then have to debug it as some random chip here or there might not be working.

I suppose the REV3E is the most work of the projects. I think when being able to work a few hours per day on this, a few days will suffice.
I am also working on the REV3E now, I will detail more about this in a separate post.
Anyway, though more work or less work, generally the projects are the same in terms of types of ICs used etc.
I am really starting to like the very clean look of the top side of the boards in the last few designs which is achieved by putting a lot of the passive components on the bottom.

I wish you lots of success when working on the boards!

Kind regards,

Rodney

 

[rodney]

So I have received a ENIG finish (wow!) REV3E PCB from Edzard which he kindly mailed to me.
He also included a small 386SX board made by Sergey which uses the SARC RC2016.
So I happened to have a battery chemical damaged original board with this chip, so I can transfer the parts to this new PCB, great!
There is also a module included to be able to use a different voltage on the CPU which enables more types.

Anyway so this week I was surprised to receive the REV3E board in beautiful blue color from Edzard, I am really happy to have the opportunity to build up this improved version which I didn't expect to have this chance when I still believed at the time that REV3D was then final CPLD revision.

Of course, desoldering the REV3D board was a bit of an experience I also didn't expect to have, however to eliminate the SRAM modules and have all the great upgrades it's worth destroying the REV3D for.
After labeling and desoldering all the CPLDs and CPU, I found that using my aggressive hot air gun with some care, I was also able to easily desolder all the DIP ICs, just by heating from the top and picking them off the board with a simple IC extractor tool. The only thing I got stuck on were the slots. I will need to get a new tip for my Hakko and just desolder these pin by pin. I have zero slot connectors available here so I must always salvage these from other boards.

After the desoldering job I am left with a lot of ICs so I started to solder the CPLDs first to the new board using the pre tinning and reflowing method using lots of no clean flux. Using patience and many passes of all the pins, finally everything can be made really solid, which needs to be checked a few times to ensure no single pin is possibly still loose or half loose. It's by far better to pay a whole lot more attention to this before hand, then needing to get back to it later when discovering issues related to loose pins. After adding all the other components it's not as ideal as what you have with a bare board!

At the moment I have two of the 208 pin CPLDs soldered to the new board. In attachment a few photos just to get an impression of the work. I just did a moderate cleaning of the flux, I will do a little more cleaning after all the large QFPs and PLCC 286 are done. I will first test the board using no VGA card since I have no slots yet until I get a new Hakko desoldering tip. If I can get the system to a certain level of POST I will know everything is fine. Possibly it can even fully boot when the BIOS assumes a CGA video card is to be used. Usually MR BIOS will beep that a new video option is detected which you can enter into MR BIOS blindly and F10 to save. Though the drive needs to be changed to type 0 not present in MR BIOS which is more difficult. I need to get a slot soldered in really.

I will finish the QFP chips and then move on to add all the passives on the bottom, then a few through hole ones and the SRAMs and I can start testing. I think in a few days I should be able to have enough built up to do the first tests.

Kind regards,

Rodney

 

[pirate]

Another fun thought I just had, and I'd like your opinion on, is a bus driver and header to repeat the led boot code readout as a case front panel add-on just for funsies.

 

[rodney]

If a builder likes to have the post display on the front I would suggest soldering in headers on the mainboard and using some flatcable to extend the connections.
A display can then also be plugged directly on the headers as well during the build and debug process getting the system up for the first time.

The REV3E design also has a number of LED indicators so it may be cool to design some stylish front panel to accommodate these on the front of the system.
Maybe something inspired by the 5170.
It is cool to see the data byte conversion LED in action, and there are three LEDs indicating whether XMS, EMS or the BIOS code are active.
Also the standby power LED could be extended to the front.
So you can see a lot more of the system activity from all these.
This may enhance a professional workstation look.
It's cool when running software you can see different types of activity happening while the system is running the program.

Also another thing I am thinking about is how the POST display doesn't serve any purpose after a full boot.
Basically it's write only so nothing is reading this back.
Any software could also make use of this display simply by writing to port 80.
And then having the display on the front it could be cool to use for more purposes as a status indicator after the system is booted and software is started.
I use 4 bit binary to 7 segment conversion code to drive the displays(see the quartus project for details) but this may also be simply altered or extended to display other indications by expanding the IO decoder logic.

I do know that the ARC X286 model 12 contains a LED display and uses some dedicated ICs to drive it.
I am not sure what they used it for, maybe to indicate the processing speed or something.
I was not able to find the manual for this system.
If anyone does please let me know.
I have two of these discrete boards, one in working order and the other is partially stripped for parts.

In a later stage I may restore these reference boards and troubleshoot the issues on two of these.
Though these may simply have been broken trace connections.

Kind regards,

Rodney

 

[rodney]

I have been working on the REV3E mainboard to solder all the SMD ICs onto the board.

I had some difficulty with the J-lead SRAMs U10 and U11. These are used as the EMS page registers and that's why only part of the chips is used and the unused address lines are tied to ground. I don't have a short tip with a medium thin shape available at the moment so having several ground pins to solder this got a little bit tedious to get it right. Finally I decided to remove the SRAMs with hot air and I cut off the bottoms of the j-leads to make them more like a normal SMD IC where you can solder from the side instead of flowing solder to the bottom part of the "J" shape leads.

Anyway even when doing this, I kept getting the ground pins of U11 bonded with solder. This is no big deal but of course I prefer them individually soldered. So I will wait until I have a new short thin tip to tackle this job a little better. Also, I will check with Mouser to see if they possibly have some normal SO leaded type SRAMs of the same specifications. So any builders: if you read this, I advise to check whether you have a short thin soldering tip which is capable of staying hot while soldering these ground connections. If you don't, I would advise if you have the J-lead chip already or in shipping, to consider cutting off the bottoms of the j-leads flush with the bottom of the chip plastic. This allows the chip to sit lower and flush to the board, and enables to solder from the side rather than below.

Right now I only have a short larger wedge shaped weller tip, and the very thin LT-1S tips which cannot direct heat well. So I mostly use the wedge tip which is also suitable to handle the reflowing of all the QFP chips. The wedge is so ideal because it doesn't scratch anything and at the same time it can transport a lot of heat onto the pins being reflowed. With the last of the 208 pin QFPs I got used to the routine more and ended up with only one ground pin needing another reflow pass.

Indeed Patrick, doing some practice board is a good idea, and I would also suggest to continue with your actual project right after you feel like you are getting into the soldering routine very well, so you can apply that to the intended project. Usually when you don't do that type of work for a while, it takes another moment to get back into it again. So better to continue with the actual project board when things are going well with the practicing. Anyway using a wedge shaped short tip, you can apply enough heat and the tip itself doesn't ever carry any solder, which is flowing from the pre-tinned pads underneath onto the pins. So there is practically zero chance of getting a short between two QFP pins.

I also soldered all the SRAMs onto the board, this time these need a little more care than last time since they were desoldered from the REV3D modules. So I had to remove some solder between the SRAM pins. I also pre-tinned the pads so it takes a little more care to position the SRAMs straight on top of the tinned pads. With the SRAM pads the shape is such that more solder can stick to them so the surface is a little round which requires careful holding of the SRAM to keep it straight on the somewhat rounded pad surface. Also here pre-tinning is useful and I made do with only the pre-tinned solder amount. I used the wedge tip to gently push the pins a little into the solder surface while reflowing them with flux.

My flux is also running low so I will check for some tips and flux because my Hakko tip is worn out after desoldering a whole lot of pins these years.

I hope the page register SRAMs have survived the heat from rework, if not I will need to find some replacements. I also tried bending the J-lead pins however that is not a good idea because these are very rigid to also support socket insertion. So finally I found that cutting the bottom part of the J-leads flush with the plastic bottom was the best method. I spent a lot of time finding that out, and the real cause was not having the right soldering tip. The 286 has a much larger spacing and pads so it's much easier to solder it onto the mainboard, so I had no real problems using the wedge tip there.

I will try to get further today so hopefully I will be able to do some first power up tests of the board soon. I will search to see if perhaps I have some loose slot connector somewhere that I could use to test with a VGA card. Otherwise I will be waiting for the replacement Hakko tip to arrive to get the REV3D slots out.

In attachment a picture of the work in progress. So I will rework the grounded pins of SRAM U11 again when I have a more suitable soldering tip again. For now I should be able to test EMS, I checked all the U10/U11 pins with a multimeter.

In attachment the tips I was talking about. So the one on the right I would have needed to solder the J-lead SRAMs on the board. From the shape you can see that both these tips are very able to direct heat from the iron onto the board, and the one on the right is more suitable for SMD pins like J-leads where you can use more care not to accidentally bond two pins together with solder. Having enough heat transported onto the pin helps ensuring the soldering will be able to succeed in a single go for each pin. Right now I only have the LT-1S small tip which is totally not able to transport heat because it is very thin. With the wedge tip on the left I pre-tinned all the QFP chip pads and then reflowed all of the QFP and 1MB SRAM pins.

Kind regards,

Rodney

 

[rodney]

Okay so I am getting on with the REV3E build. After soldering the big QFPs I added the SMD chips for the ATX power on RESET functions and clock generation. So I want to advise builders indeed to use the tip as in the picture on the right, or a similar thin pointed wedge shape that can accommodate SO14, SO16 etc spacing. And keeping the SO chips well fluxed during the soldering. It's best to get the pad up to temperature and possibly some minor preheating of the area may help the solder job. Ground planes in some areas do draw some heat away so having a short tip and an iron that can provide enough heat capacity at 350 degrees is really the best way. One of these days I should find some cheap but powerful second soldering iron with a suitable tip. That will make the soldering work somewhat easier. I really don't like to use thermal relief on power planes because it just doesn't look great. Basically this is only for a moment a small concern while soldering the board. However looking at the appearance of the board is much longer to enjoy this so I feel it's best to have a more clean appearance of the board to look at.

Anyway so some small consideration in the iron and tip will go a very long way to make things more smooth and easier.

After the clock generators and ATX stuff was soldered on, I continued to add the through hole ICs like DMACs, DMA mapper chip, keyboard controller, RTC, system timer, UART, FDC chip etc, and then I added most of the through hole capacitors. Next I added the IDC headers and pinheader for LPT. The board is starting to fill up nicely now and looks much more like the REV3D used to look, this time with the cool update to have the SRAMs on the board!

I am starting to run out of solder, it may run out before I can be able to do any viable test, but I will try. Today I should get more solder and a better short narrow tip as in the picture on the right, and I also will get a Hakko nozzle to get the slots off the stripped REV3D board. At least, if the things I need can arrive by mail today hopefully! So the ICs and connectors are all there, but not fully soldered at the bottom. And I also need to add all the SMD caps and resistors etc on the bottom which will be some more work.

So I had another look at parts for 32kb SRAMs U10 and U11 since the J-lead versions are less convenient to solder compared to normal SO28 ICs with regular pins that lay flush on the PCB surface. However the ICs available at mouser are really limited. The CY7C199 is starting to run low in stock, and alternatives are all lower speed rated versions. Basically the footprint on REV3E is SO28. So any typical small fast SRAM 5V specified with the faster access times will also be able to fit on the existing footprint. Of course, I have not tested the EMS system with slower nanosecond rating. And the use case situation is where the SRAM is always output enabled which should reduce the access time. I would not be surprised if slower chips like 20ns would also work correctly though I have not tested this.

Anyway, as I said, cutting the J-lead pins off flush with the bottom edge of the IC plastic is also one way to make soldering more easy compared to a j-lead situation. It sounds a bit destructive but it does have advantages. The J-leads should not be bent because they will start to crack through the material, so just cutting them off as-is without bending is much better. Otherwise it may be worth a try to find some normal SO28 IC as well but it would need testing if slower rated. It seems that the faster SRAMs often have the J leads or larger TSOP shapes with smaller pin spacing. Between these I still would prefer a J-lead chip because it at least has SOP spacing, and just cut the bottoms of the J pins off. So when I have the better soldering tip that can direct heat but solder more precisely I will suck the solder off the top row of 9 GND pins of U11 where some of these GND pins bonded together with solder, and then solder these pins individually again which should look better. I also will preheat the area a little to get a better condition for soldering them individually.

At the bottom near the ATX connector there are a few electrolytic capacitors for the power nets like VCC and +12V. These can be chosen depending on what is at hand. With the +12V I would suggest using a 25V or higher rating so the cap won't go into fault mode like may be the case with a 16V one. Otherwise it's not critical so a few hundred µF should be fine. Also the VCC cap has less space but the fuse next to it could be moved to the side a little. I put a glass fuse with longer legs in which I could easily move to the side a little to allow more space for the cap next to it. So I would suggest 1000µF or more with 16V or higher rating. Some other cap on the board also could be replaced with a larger one if you want. I will do some scope measurements of the power nets but it should be really fine. So I put a 1000µF on VCC near the ATX connector and the others are 100µF 16V ones which I recently got in a nice compact size.

In attachment a picture of the board how it looks now.

Kind regards,

Rodney

 

[rodney]

I have worked hard to finish assembling the REV3E board.
I finished adding all the passive components on the bottom and with the new Hakko tip it was super easy to take a few slot connectors from the stripped REV3D PCB and solder these into the REV3E.
So I am starting with two slots for VGA and soundcard and more will be moved later on.

The first tests produced no activity at all, so I started checking things with the multimeter.
The result was two shorts and one loose pin while touching it with the multimeter probe.
One of the shorts was the /MEMR which is pretty critical, and the loose pin was an address line, I think maybe SA4.
Of course both of these will prevent any ROM code to be able to load.
I discovered the /MEMR remaining low while examining the system and finding weird behavior on the /MEMRX buffered command signal going from the EMS controller to the flash ROM.
So this could be traced back to the slot /MEMR also remaining low.

After fixing these soldering issues found so far, I found that the 286 is more normally starting to read the code from the 8 bit mode ROM, but no POST is generally happening yet.
The 286 CPU is absolutely a great chip to work on and it really helps with diagnosing any issues thanks to its default behavior even during fault conditions of the system.
In many occasions it just keeps going and that does help scope measuring the system.
When building these systems you also can find this out.
The status signals can be probed from the coprocessor footprint and are marked on the board.

I got more progress, on a few occasions I am starting to see even more promising activity, up to POST 0A memory fault which I have seen about 5 times.
About the POST 0A, this can occur even if no RAM at all found so it's a wide range of issues that can be covered by this code.

The reality of this system is, there are hundreds of pins involved on the CPLDs and SRAM so when issues occur there is a lot of stuff to check until I can find some cause of this condition it's in.

I advise REV3E builders, if you prefer, you could wait a moment before assembling your boards until I have found all the issues.
Basically that's why I am now assembling this board and why I stripped the REV3D board almost completely clean.
Most likely it's an assembly/soldering issue I am experiencing which I suspect first being the case, but I will examine further.
I also may have overheated one of the core AT controllers which will mean that I may need to desolder each of these, test in another system, and solder them back in after confirming they are okay.

Of course, if you are really confident to tackle any issues, which I totally understand and that's fine too, do go ahead and you can read here later what I have uncovered in my examination of the built system.
Diagnosing this type of system can tell you lots of things about the PC/AT as you discover the increased functionality which starts to happen when solving the issues.

I remember with the REV3D I had to return to the CPLDs a few times until I had made all the contacts solid so I can revisit the solid checking a few more times to ensure this.
And I had some bus logic issues between the Address bus driver and EMS controller, but these are already fixed in the inherited logic from REV3D of course.

Anyway, a consistent POST 0A is now definitely preferable as a next operational level, and I would subsequently attribute that code to a possible RAM chip select or bus enable issue or such.
Of course, the cause of sporadic POST 0A may be linked to the same issue that exists and it may solve everything in one go.
Debugging a build can be like that.

I may have also killed the page register SRAMs with all the reworking these have seen.
So I have also given this diagnostic situation more thought, about how we could tackle the troubleshooting in different ways that allow us to initially exclude a lot of areas.

One of my subsequent plans is that I will create a minimal diagnostic set of CPLD projects which disable most areas of the system, and only drive the minimal core areas needed to POST and do the VGA INIT and start to see life on the monitor. Once that level is reached, the full functionality CPLD project set can then be programmed. I will upload the diagnostic set of quartus projects into the GitHub as soon as I have this ready. So I will strip out lots of logic which also makes the whole situation look more simple which helps fault finding. The diagnostic set is going to disable all the SRAMs except set 1 on the board, which should result in 2MB of straight decoded RAM, providing a very basic situation of the conventional RAM and 1MB of XMS. I also will disable the option ROM part of the flash ROM, so it will only provide the system BIOS and nothing else. And the entire EMS system will initially be removed to it cannot influence the INITIAL fault check process. Once the VGA INIT is achieved and RAM is detected, then the CPLDs can be programmed with the full versions and the complete system can then be further tested.

So we are not there yet but I have progressed a lot to the point that I am not able to proceed with the actual testing and debugging.
I will share the continued troubleshooting process and results here.

Kind regards,

Rodney

 

[sqpat]

Wow, you got that done fast. OK, i will not begin with the REV 3E - was not planning to anyway. Good luck with the debugging!

Nonetheless my boards are arriving sooner than I thought (possibly this week!) and I don't have many of the parts in, so I am trying to prepare the parts orders.

Some questions about Rev 3E parts list:
- Is that USB connector really type B? Looks A to me but I might be wrong so I wanted to confirm. I guess B would be smaller footprint.
- Can "ATF1508AS 10AI100" be replaced by the newer 10AU100 model? I don't immediately see anything incompatible but wonder if you ruled this out for one reason or another.
- I have a dumb question about F1/F2 the fuses on the REV 3E board. Is there a particular voltage rating that should be selected? I can't say I am very knowledgable on power delivery details.
- Similarly, are the specs on ferrite beads FB1/FB2 important?
- A thought came to mind... is it easy to program the CPLDs before they are soldered to the board? I think many of these I am getting are possibly used, and maybe not all of them work so it might be nice to confirm first.
- Im a little confused about the rpzero 2040 connector. It seems like you have a female 40 pin IDC header on your assembled board, is that correct? Is the RP2040 a dip 40, so you use some dip40 to IDC adapter?

EDIT: plus a question about TOPCAT Rev2
- 74cb3t3257, 74cb3t3245, are these SSOP-20?

If anyone is interested in making a Rev3E build or Topcat build let me know. The PCB orders were 5 boards minimum. I will have spare boards and am bulk buying CPLDs and discrete chips and have topcat chips on hand. I'll happily provide most of the necessary parts at no extra markup, but be aware it still is not super cheap (haven't done the math but probably around $100-$150 not including SRAMs for Rev 3E, but topcat probaly signficantly cheaper).I would like to confirm my CPLDs and boards are good first before I go distributing them to people first though.

 

[rodney]

Wow, you got that done fast.

Hi Patrick,

Thanks for the message. Very cool that the boards are arriving so soon!

I have lost quite some sleep these days but for a good purpose, at least I got the entire board assembled which is the start.
It was more work than normal assembly in my case because I moved the parts from the REV3D to the REV3E board which is more than twice the work.
After desoldering the caps etc I needed to remove the excess solder and them put them on the new board. Time consuming.

Part of my checking work will be to ensure that the unusual components like small capacitors are the right values for the right positions.
I mean, most caps are 100nF, and only some are different values like load caps and the power sense passives on the RTC etc. are a little critical otherwise the RTC will remain inert.
So I will spend some extra time making sure of these.
The RTC is always a part to watch that it has the right specific circuits and voltage etc. or it will refuse to work.
Just for your information to be aware of this thing being a little specific.
The DS12885 appears to be better than the MC146818 so far in my experience so I dropped the optional stuff in the REV3 designs and stuck with the DS12885.
I have some cheap LC meter but it's very accurate in measurement resolution so I will verify and put the caps back on the board.
So a meter like that is maybe also something to look for when browsing Chinese suppliers.
It's a simple thing with backlight LCD display and some terminals and uses some microcontroller.

The USB connector is indeed a type A where you can plug a wireless mouse receiver into the connector.
I got these cheap on tiny PCBs from China where I desoldered them from the PCBs.
A little tedious but no matter. The connector internal part is not fixed so what I did was I inserted a USB receiver to align it and then soldered the thing in place on the board.
This ensures that the connector is solid aligned with the receiver you plan to use.

Can "ATF1508AS 10AI100" be replaced by the newer 10AU100 model?

The "U" in AU is apparently some lead free version of the same chip, I checked the datasheet which lists the U types separately.
Whether this is similarly soldereable with leaded solder as the AI version I can't fully predict but I would assume so.
Usually when manually reworking lead free circuits, technicians often use leaded solder as well so it should be fine.
It's always particularly important to use a lot of no-clean type flux during the work to ensure proper flow of solder.
I was surprised to still find some shorts between pins really.
I am using a microscope lens goggles which have the disadvantage that you need to go close to the object to get the right focus.
So this somewhat limits the access using tools between the goggles and the board.
One day I must get a USB microscope so I can have more space to work in a more ideal position with the iron and tweezers etc.
The most critical indication from "10AI100" is the 10ns and 100 pin part.

I have a dumb question about F1/F2 the fuses on the REV 3E board. Is there a particular voltage rating that should be selected?

The fuses are non critical in voltage rating because the mainboard doesn't contain any high voltage logic.
So any voltage will do and the important part is the current rating and I would suggest if you see some parameter like slow or fast blow fuse, choose the slower one.
The fuse blowing will only be because of a short so it can be a little slow which is still fast.
Anyway, the supply current in our more modern boards is a lot less than discrete chipset boards.
I should try to measure this one of these days, I think I have a very low value resistor somewhere which I could solder in place of the fuse and measure the voltage drop during some test like running RealDOOM.
Anyway it's an idea maybe for later.
Also, you can use a multimeter in ohms mode to check the power nets for shorts to ground.
If that is close to zero ohms it's not good.
You can then use very precise measurement to find where the short is located on the board.
The lowest resistance will mean you are closest to the area.
Hopefully you won't need to search for any short of course.

Similarly, are the specs on ferrite beads FB1/FB2 important?

Well, generally I would say that they are not critical for this application just to try to block high frequency noise into or from the long cables.
I just bought some from Aliexpress which had no specification but I didn't really do much research about this.
The keyboard controller is a very low frequency circuit and not at all prone to signal failure in my experience.
I have not seen that happen so far.
There are also some caps to keep the noise in the keyboard signals down which should make a good difference.

A thought came to mind... is it easy to program the CPLDs before they are soldered to the board? I think many of these I am getting are possibly used, and maybe not all of them work so it might be nice to confirm first.

The most prudent thing you can do when suspecting some form of programming is to solder the used CPLDs first and add the PSU components so you can power on the mainboard, and then program the used part first. As soon as you program it, it will go in tri-state immediately so it's not "running" the programmed application then.
So the idea would be to minimally assemble the board, prepare the PC to start programming, then power on the board and press the program button on the programming software.
This reduces the time the CPLD is running the "wrong" logic.
Otherwise the CPLDs are pretty solidly made and it's not easy to kill them.
The 100 pin CPLDs quickly can get hot especially with a fast clock input, so no need to be alarmed, it's normal and that's why I advise to use some form of cooling.
Whether that is blowing air on them or putting a heatsink, or combining a small heatsink with some airflow will be best of course.
During the assembly and debugging it's better not to concern about cooling yet because it will make access to the chip for inspection and additional reflow more difficult.

Im a little confused about the rpzero 2040 connector.

Yes, this needs some elaboration, thanks for bringing up this very good point.
The RP2040 in this case is soldered onto a single angled pin strip to save some space on the board.
The angled pin strip goes into the 1-20 pin number row which contains most of the used connections.
Then you can solder in the jumper wire to select mouse speed, and a wire to connect VCC to the RP2040.
I suggest you can try the same jumper wire position and try it out with your mouse.
The one shown works really well, I use some simple Logitech wireless mouse. Sometimes simple is better.
Also the RP2040 needs a two wire connector to plug it into the USB device header which is right next to the RP2040 footprint.
I have attached a few photos which show how I did this.
It's looks a little like a hacked thing but it works really well.
I have moved this RP2040 from the REV1 to the REV3 and never any issue.
Well, sometimes you may need a power cycle if the "USB mouse detected" LED doesn't light up.
Very occasionally the RP2040 may get erratic at power on but usually when it lights up during power on with a mouse receiver plugged, it will work fine.

74cb3t3257, 74cb3t3245, are these SSOP-20?

The 74CB3T3257PW is a 16 pin TSSOP part which is indicated as package option "PW0016A" in the datasheet. The PW is also present in the chip type.
The chip plastic width is about 4.4mm and the lead spacing is 0.65mm according to the datasheet. So anything that can fit on those pad positions and length is fine.

The 75CB3T3245DGSR used here is a 20 pin VSSOP package which is a little narrower. The package option is "DGS0020A" in the datasheet. Which is reflected in the chip type as well.
So the chip plastic width is about 3mm and the lead spacing is 0.5mm.

I based the choices on what Mouser had in stock in larger quantities at the moment when checking this.
So these seemed to be most commonly used looking at the stock numbers which would be the best choice.
And the pricing may also have been a factor with selection of course.

Thanks for your questions Patrick, and I will process this information into the GitHub pages when updating these in the future.

I hope to have some time today to go over the REV3E board further and get more stuff verified and probed.
Just to elaborate, the types of initial checks involve using a multimeter in continuity test mode with a beeper to beep out the adjacent pins of the CMD components and other areas like the slot pins.
When you beep the adjacent pins carefully you can detect any solder between two pins which may be so tiny that you almost can't spot it.
The other check which you will tend to do first is to feel the SMD pins from the side with a thin pointy tweezer tip. If it moves that means not solid yet.
Typically a few reflows later you will get entire rows of solid pins.

Let's hope for the sake of the project that I can be lucky to find whatever issue sooner rather than later so we can move on from there.
If some of my controllers etc are faulty that will be not great and cost more time to trace down since these are all on shared buses.

Kind regards,

Rodney

 

[rodney]

Okay so I have created a heavily reduced special diagnostic version of the Address bus driver CPLD.
Which only drives the SRAM set 1 and all other types of chip selects are held inactive high to disable everything else that is non critical.

So when compiling this special version, you can click in the quartus compilation message list to elaborate the outputs "stuck on VCC or GND" to verify that the Address bus driver keeps all non critical CS outputs on inactive VCC levels. ROM access is also reduced to the system BIOS only for the system BIOS area below 1MB and the INIT mirror for the 286 coming out of RESET in the top of the memory map, and no option ROM code area is enabled here during critical diagnostics.

And now I have reached the before mentioned consistent POST 0A level at each power on where the system BIOS is reporting a memory issue.
So this narrows down on this specific issue where the SRAM memory access now needs to be checked.

So apparently the memory has issues and I will start by going over all the SRAMs which are populated on the board.
So I will beep out for shorts etc and inspect the SRAMs with X15 magnification microscope glasses.
Which in my preference is better than X10.

If I find some issue with soldering etc I will retest to see if we then get further in the POST.
If not, I will continue with a heavily reduced special diagnostic version of the EMS controller CPLD.
And we move on from there with further reductions.

Once we can complete the POST where we can see MR BIOS etc, we can then reprogram the CPLDs to expand the full functions provided on the REV3E.

Kind regards,

Rodney

 

[kevju]

solder all the SMD ICs onto the board

You should try some Bi58Sn42 https://www.aliexpress.us/item/3256811495835760.html
Note that this is solid core wire, so you will need to apply flux to your board and parts, or just wipe a small amount onto the wire as you solder. It does not have the same mechanical strength as SnPb, but it is more than sufficient as long as you don't play frisbee with your board. There is also an alloy with silver added, but it is much more expensive. Flux core wire is also available, but it is over ten times more expensive.

I put together a thermal analysis to show how much easier it is to use with copper planes. It is also far easier to remove or rework parts.

new short thin tip

I recommend using a knife edge tip for QFPs, especially for soldering on or near planes. This is my goto for QPFs and QFNs: https://www.aliexpress.us/item/3256805601181480.html The idea is to make a large contact patch to flow a lot of heat into the board as quickly as possible and don't worry if a bunch of pins get soldered together. For QFP, be careful to only move the tip down and out/up; do not drag it along the pins sideways lest you bend one. Apply some flux where needed to any excess, apply a clean tip and then drag it away from the center of the chip and off the pins. It should leave the perfect amount of solder on every joint. You can also use solder wick to remove excess, but if you aren't careful you can be left with a tiny copper wire bridging some pins.

Another idea is to use one of those phone screen heating pads to preheat your board while you desolder: https://www.aliexpress.us/item/3256811913391580.html These also make using the Hakko desoldering gun much faster and easier. You can use aluminum foil to insulate the sections of the board you aren't immediately working on to help keep the over all temperature up. Here is a simulation showing the impact of preheating a board to just 75C. Compare the y scale values to the graph above.

 

[rodney]

The issues I experienced just came down to the fact that I only had a big wedge tip, and the LT-1S needle point, both of which are unsuitable for soldering pins where you will want to add solder manually instead of pre tinning. So it was the immediate lack of that tip which I misplaced somewhere, combined with me not having the patience to wait a few days for a new tip, that's all, nothing more.
Everyone can experiment with different tips and I encourage to try out stuff, what works works and it's perfectly fine. However my information I provide here is not as a comprehensive soldering tutorial, but only provided for the novice solder job to support my projects where following these tips can prevent the exact stuff that I had happening.

So a short recap, for the type of board(so far) in our project, such as the TOPCAT REV2 and the AT custom chipset REV3E:
- use a short thick non sharp wedge shape tip (see the photo I provided) for pre tinning the PCB with 60/40 leaded solder, and after cleaning apply new flux and fix some pins by heating on a few sides and reflow the pins. I think I mentioned this before, but the reflow should not be a dragging movement of course, but to be a wiping movement along the pin direction from the pin onto the pad. And it may help to initially just hold the tip for a short moment to make the pin and pad both heat up, so when you wipe it has the optimal flow of the solder between the pin and pad.

The QFP100 and QFP208 will flow more than enough solder onto the pins just from what is on the pads by pre-tinning, and it greatly reduces the chance of getting solder between two pads. Of more than 800 pins I only got two pins stuck together, probably because of not using enough flux.

- use the short and thick but narrow pointed tip (also seen in the photo on the right) to apply solder onto for example SO14, SO16 etc SMD ICs where you will want to use solder wire to apply a little more solder onto the pins because pre tinning is not enough to get these pins solid. So this is the case with SO IC packages and apparently also with the TSOP-II-44 SRAMs, especially when removing and resoldering these from one board to the other where some uneven solder residu may be at the bottom of the pins. So applying a little solder from 0.5 mm (or less if you can get it) leaded 60/40 resin solder wire can fill up the gaps and make the chips solid. Also with the SO type SMD ICs you will find some pins connecting with ground surfaces so the short and solid tip (rather than the LT-1S stepped tip) can direct sufficient heat to properly flow the pins, even on ground surface connecting pads.

 

[rodney]

Okay so the initial concern I had to resolve was that at first I had problems getting the system to consistently INIT and commence the POST at each power on.
So some reflowing and reducing the Address bus driver to a diagnostic level logic was exactly the solution because the system was able to then POST each time, which indicates that the 286 and system control are fully functional.

After ensuring that, I proceeded to put all my attention on the SRAM. So the reduced Address bus driver only drives the SRAM set 1 which I then proceeded to reflow in detail, and this time I added generous no-clean flux on the pins and then added a little more solder onto each pin using the 60/40 (or 63/37) leaded resin core solder wire. So the look of the pin is that it is surrounded by solder, arguably more than necessary, but I just like being especially sure of things when that is really easy to do as well.

After finishing the first set of SRAMs which are only active, I proceeded to do a beep out of the set of SRAMs. So what I do is I measure between the adjacent pins, and I also measure each pin from the top side near the chip plastic, and the other probe touching the edge of the pad on the board, so you can measure a direct solid solder connection between the pin and the pad.

After all these checks I had a good feeling about the board and just connected it to the PSU.
Well, good news! The board came up to POST code 21 which is a BIOS prompt message which MR BIOS usually sounds a beep to enter BIOS and save the update.
Though some changes MR BIOS just saves by itself since it is certain to be correct, even if you don't press F10, so convenient!

Anyway, so I powered down, put the VGA card in and yes! We have VGA as well now on the REV3E!
And in the MR BIOS we can see the conventional and XMS RAM detected as set in the Address bus driver diagnostic version programming.

I am really looking forward to moving on and now expanding and testing all the functionality with the full CPLD programming, and especially testing out all the improvements for which I did all this work, and destroyed the fully working REV3D board!

So I should be seeing 8MB XMS eventually and 4MB of this can be used simply by running the very convenient SCAMP version of RealDOOM that Patrick created and compiled, very cool!

So no configuration changes are even needed and we can use a single boot config for DOS, transparently using the EMS system when we want which then borrows the top XMS as populated.
I remember a while ago having some talks about how do we config the system for XMS and EMS, so this also solves that question.

Regarding the detection and where to populate which chips depending on the user preference, I will elaborate on this in the GitHub and I will put a few different CPLD programming sets for each scenario of soldering in SRAMs.

I'm in a really cheerful "it's working!!!" mood here, a great day!
The thrill to seeing the system come alive for the first time starting with a completely "dead" system, I hope more builders will decide to seek this experience for themselves as well, there is nothing else quite like it, really. These systems that are derived from the authentic original technology are pretty complex so it's a good challenge really. Arguably the REV3E has so many connections, though looking back, the process of solving the issues was still very straight forward. That's also why I share my exact experience, it can provide many clues to what to do in certain situations.

The first thing you will want to see is to get the same INIT and POST condition on each power up.
And I also want to remind builders, keep a 8 cm fan on hand to just put it above the 4 core CPLDs to cool these when the system is powered on longer.
The 100 pin CPLDs do tend to heat up and eventually the system will freeze if insufficiently cooled.

It suffices to run a 12V 8 cm fan on 5V to reduce the fan speed and noise, it's sufficient cooling to run the system continually for days or weeks if you like.
Later I want to test with some small stick-on heatsinks which I found online recently just to see what happens then without a fan.
If the chip stays cool enough I will share the findings here as well.
Basically only the 100 pin CPLDs have this concern about cooling.

Kind regards,

Rodney