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

[rodney]

You could use bus switches in this application to make the FPGA I/Os 5V tolerant.

Hi kevju,

Thanks for sharing your practical experience which I appreciate a lot. And it's very practically relevant to read about your cost examples from JLCPCB so thanks also for that.

There are a lot of considerations in this project, which keeps me moving back and forth between using the 208 pin CPLDs and deciding to completely move the project into FPGA.
I am not quite there yet to decide this right now but it's getting close to take that decision. After I find no alternative except moving on to FPGA, I will need to consider a lot of things for the practical solution how to create the system. At that time I will be looking in detail into the level shifting and how to do it. The type of switches you mention, that kind of idea sounds great because it looks really basic and less complexity should indeed benefit the speeds, like you mentioned, fractions of nanoseconds that sounds really great. I will look around what type of ICs could be found, possibly in SMD format in order to decrease the board area more since I will be using a lot of pins to make the whole system possible. Definitely I will be using some modern solutions to connect the FPGA, and I will also look at the existing modules which can be bought to compare these with a custom board or module. One problem is finding some existing FPGA board with a larger number of pins. When pin numbers increase, the problem of how to make the connections in a solid way and keeping the connections short also becomes bigger. I will do more research in the future to try to find a good solution for this project.

Right now I am still looking at a possible CPLD version just as a final careful consideration to see if I can find some satisfactory configuration which could enable a 2 layer board design and using hand soldering.
Assembling these quartus projects takes some time to create all the logic and test compile, and I have had to rethink the whole system several times already in order to remain within the "6 OE" limitation of the CPLDs.

Right now, in order to be able to make a CPLD version which eliminates as many system transceivers as possible, I would need to make some changes in order to have a working compromise. It costs more pins because of needing to split a bus into an input bus in one package and a driving bus in another, which needs the same connections on two chips instead of one. Though this may not be a very big issue with the larger packages. Being able to choose the pin locations is also helpful to make the PCB traces at least less complex. However there will be a lot more connections on the board. It depends on if this could be done in a reasonable way. What I am looking at is to still get as many bus functions as possible inside a single chip, which is my preference rather than spreading parts of a bus across the board.

The biggest example is the AT DMA address generation. Some things even though they look correct from a standpoint of it being logically sound, presents different timing in the DMA process for example. Different timing in this case resulted in no issues at all. The DMA process is controlled in different stages, as long as the correct bus levels are established when the DMA controller is doing the actual operations, it will work without issues, which I was thankfully able to verify yesterday with the existing CPLD prototype.

I will finish the first large package CPLD project, enter it into KiCad and place it on the board, which will give me an impression of what the design and trace routing would look like. I need to determine if it would be a good idea in a practical sense to continue this development path using CPLDs, or if it will be better to continue with a FPGA instead. When I see the chip on the board, perhaps I can see a way to be able to run the large amount of traces in a reasonable way using a two layer PCB. That is really my target. For the FPGA version, I will also be looking at large connectors for a module and I need to try routing such a connector if this can even be done with two layers as well. Soldering a large pin count FPGA onto the mainboard will need more layers so using a module to connect it into the system may be a better solution.

Kind regards,

Rodney

 

[rodney]

Today I just about finished the first 208 pin CPLD, which has the function of PC-AT system bus driver / decoder. The chip drives the system bus from either the CPU or the DMA controllers. It also does the coprocessor control and memory decoding. In the attachment a picture of where it is placed on the board.

Next I will have a look at the second CPLD, I will see if I can combine system control with EMS memory control. The system controller previously had some OE functions however I will look at reducing these as much as possible by integrating certain things into the system bus driver, so I can get more functions into the next chip. There is definitely one OE function that I must have in the system control chip which are the command outputs which need to be able to be tri-stated. This will cost at least one OE function.

After I have spent some work on the second CPLD I will know more about how to proceed regarding the distribution of system functions. The EMS memory chip will also need to route the memory databus to all the RAM modules so a larger chip makes sense. I have been able to reduce the pins for the EMS controller by doing the memory decoding in the system bus driver CPLD. So the EMS controller will have more pins available for routing the memory data bus.

I am starting at the edge of the board next to the ISA slots and creating the placement while doing most of the traces. This way I will not waste too much board space and I can get a better impression of whether this two layer board could be possible at the same time. Another goal will be to keep the traces as short as possible in the core components that will run at the highest clock speeds. Hopefully I can reduce the impedance of traces and the faster CPLD logic could help us across the 20MHz threshold.

I will also split the ISA slots in two sections for fast and slow cards, so that during the fast operations the slower cards are not connected. Only when slower cards are being addressed, the bus will connect them. At least, that's the idea. This also would reduce the impedance and cross talk on the ISA slots.

I will also look carefully at what kind of memory I will be using if the board looks like it will finish in two layers. We will need the fastest memory, preferably SRAM or some faster solution, because I want to test with zero wait states as well, which would get much more efficiency out of the 286 if this would be possible.

Hopefully I will be able to find a way to be able to get the most out of these large CPLD packages within the 6 OE limitation. Since the X-address BUS only reverses for DMA, as long as I can get the DMA address generation working in the system bus driver, I could use another CPLD to drive the X-address BUS only as a simple buffer. The X-data bus is already featured inside the system bus driver.

In the attachment, the top PLCC chip is the CPU, below it the system bus driver, to the right the small chip possibly will be the system controller, though I may be able to eliminate this chip if I can integrate the system control in the larger package to the right if there is enough space and OE capability available. At the top are the two DIP packages which are the NPU and DMA page mapper chip. When using a FPGA later, we can finally get rid of that page mapper chip as well.

Kind regards.

Rodney.

 

[rodney]

I have done some work to develop the new system controller CPLD. Since I plan to use larger packages of 208 pins, I decided to combine system control with the new EMS controller for running RealDOOM by sqpat on the new system. However there were some results from the quartus compiler that are different from the design.

Apparently the quartus compiler was not able to implement even the 6 OE functions in that concept and needed to take more resources from the chip in order to make the functions, and the conclusion became that quartus would be needing 7 OE functions to do it and it threw the known error message, preventing the idea to work out. I triple checked it and there are really only 6 OE sources in the design, and not 7. So it must be a resource or chip routing problem.

So I decided to change the plan further and include other areas into the system controller CPLD. I removed the EMS control and added more bus circuits and the DMA page register interface which would use an external SRAM. And again, quartus threw the same 7 OE error message.

I am sure that with a lot of shifting of ideas into what is possible to compile, eventually I will be able to form the system. However, the compromises are starting to add up and so is the inclination to want to do it in an FPGA instead. Using an FPGA, I could do so many things I currently can't do with CPLDs, such as also making many registers internally, routing entire buses, and eventually trying to create the core chips such as 8237, 8254, 8259, creating the custom clock wave shapes I wanted to try, creating more elaborate wait state decoding, adding more state machines for separate cycle control, etc. That list is also adding up, and that list of things is in favor of switching to FPGA.

On the other hand there are some obstacles:
- BGA package and large pin count is difficult to integrate into the two layer PCB concept
- logic voltage levels need to be shifted
- power supply considerations

Fixing these things would be somewhat similar no matter which FPGA is chosen, so instead I would want to choose a FPGA with lots of internal resources and I/O pins in order not to run out of these again. Which means hundreds of pins. So the above obstacles would need to be fixed in a suitable and cost effective way.

I am currently first doing a search through GitHub hoping to find some suitable FPGA adapter PCB which could suit these specifications. And preferably I would like to continue in quartus as well. If I can find some open source adapter PCB, perhaps a Chinese manufacturer could assist in making some. If that is not an option either, I will consider other options next. I will then continue by searching in other websites for FPGA modules with more pins on the headers and somewhat suitable layout. If all ideas fail to pan out, I will look at designing my own module instead. This also has advantages such as being able to customize the solution for this specific type of work.

I will be gathering information in order to work out a solution so the project can continue with FPGA technology.
The most ideal module would be a large few hundred pin count combined with DDR or faster RAM.
Which would also eliminate any memory needs and bring a zero wait state concept nearer, however it seems unlikely that such a module exists.

Kind regards,

Rodney

 

[kevju]

How many IOs do you need?

search through GitHub hoping to find some suitable FPGA adapter PCB

You could try a board like this to get started:
https://github.com/ChinaQMTECH/EP4C...IV_EP4CGX150GX_User_Manual(CoreBoard)-V01.pdf

Using a smaller board to mount a BGA part to a large board is a good way to go. A BGA mounted directly to a large board using anything but a reflow oven is prone to failure, since the board will warp if it's not heated and cooled evenly.

designing my own module

The best value on the Altera side is probably the 10CL016 part in a U484 package. It has 15k LUTs/FFs and 340 IOs. The 0.8mm pitch which allows pretty much a full fanout on a 4 layer board with 3.5mil s/t. Retail cost for one is $24. There is also a 1.0mm pitch part (F484) for a few dollars more.

DDR or faster RAM

How much ram do you want to support? If 8-16MB is enough, you can probably just use 10ns async sram on the main board. Even the slowest speed grade of the part above can decode 15 bits of address in less than 10ns.

 

[rodney]

I have spent quite some time searching for FPGA modules which I could use for a FPGA implementation of the project.
I came across a few good ideas however none of them are really meeting the specifications I am looking for.
Also some types of FPGAs are not suitable for normal I/O operations but rather focus on differential paired I/O or other types of connections. Some of the FPGAs cannot offer many normal I/O pins.

Another issue is that most FPGA boards focus on some limited pin count experimentation which is not at all suitable to implement for our type project which involves an elaborate PC/AT system.

If I solder a FPGA BGA chip directly onto the mainboard or let JLCPCB do this, that also means that I will have a huge pin density in a very small area, which will require at least a four layer PCB or even more layers to get the traces through to all the BGA pads. However my target is still to design a two layer mainboard. So I want to use a module for handling the connectivity to the FPGA. Possibly the solution may have to be to design a module myself.

A lot of FPGA chips don't come in the form of modules. I also searched on the GitHub website and did come across some Chinese manufacturers which may show some promise since they are at least designing and building FPGA modules which surely will be more affordable for our purpose.

I looked at what type of connectors would be suitable for connecting a FPGA module to the mainboard, this is also an important aspect to consider. From everything I have seen, I think that using a solid type of SODIMM or DIMM connector would be the best idea. If a stronger type of DIMM slot could be found that could also provide a solution. And preferably the connector should be a surface mounted one because this allows more trace capacity near the slot connector since the bottom layer would remain completely accessible when using SMD soldering for the connector.

So far, I have not found any FPGA module that would make me decide to move forward and use it yet. The applications are just different. So I have decided to continue to work on the problem from two sides, I will continue to attempt to assemble the system while trying to get the most out of the larger CPLDs, and at the same time I also will try to find a suitable FPGA module. I also will do some searching on the website of JLCPCB or PCBWAY to check if they offer to manufacture some kind of existing open source boards, which may be available directly from them for example. Either direction, CPLD or FPGA, will present issues and difficulties. Regardless, I will move towards using a FPGA either now or in the near future in the next design revision.

If somehow I can get through the CPLD based concept in a reasonable way where I can see the entire system being accomplished in a way which appeals to me, I may still finish the CPLD variant. And, if that design were verified and functional, I will still have moved one step forward to continuing the FPGA stage anyway.

Another idea I am thinking about right now would be to use a few FPGAs instead of a single really large one. The FPGA modules can interface with low voltage between eachother and with the memory, and the outside connections can be brought out using level shifters.

In attachment an image of the current work on the CPLD implementation. After combining the system bus driver with the memory decoder(top 208 pin package), I have decided to combine the system controller with the I/O decoder and letting it handle all the remaining DMA connections(bottom 208 pin package). After I have used the full capacity of the system controller, I will move on to the EMS decoder and memory bus driver chip. Hopefully this third chip will be able to provide all the remaining logic needed for the complete CPLD implementation.

I am aware of the fact that by using an FPGA which holds a lot of design capacity, we could use some form of VHDL equivalent program to define the PC functions, however for this project that would be entirely missing the purpose because we want to recreate the actual real functions and mechanisms. Which holds much more historical value. On the other hand, if an approximation for certain chips is used for which the inner design is an unknown, a FPGA recreation would feel more acceptable for example to replace the DMA controllers, interrupt controllers etc, because there would not be any alternative route anyway to recreate these chips.

Kind regards,

Rodney

 

[rodney]

You could try a board like this to get started:
https://github.com/ChinaQMTECH/EP4C...IV_EP4CGX150GX_User_Manual(CoreBoard)-V01.pdf

Using a smaller board to mount a BGA part to a large board is a good way to go. A BGA mounted directly to a large board using anything but a reflow oven is prone to failure, since the board will warp if it's not heated and cooled evenly.

Thanks kevju for your reply. Yes, I have seen the designs by ChinaQMTECH which are definitely among the better GitHub publications. I have gone through many search result pages in GitHub and found the majority were empty projects or half finished ones which was very time consuming to get through them. Many projects have no comments at all so I often have gone into the folders to check what is there.

I would be willing to solder a BGA onto the mainboard if this needs to be the solution to move forward, which is doable with proper care and preparation, however the other factor remains the costs of the multi layer mainboard sized PCB. I have already paid a tidy sum(including some extra costs added by JLCPCB staff because they deemed the board to be labor intensive) for the first revision four layer board just to get the whole project moving forward, however now since the project is proven to be fully functional, I want to save more costs on the third revision. And for this reason, we must do what we can to keep a two layer design, and using a module with more layers, however much smaller in surface hopefully could provide the answer within a reasonable price range.

The best value on the Altera side is probably the 10CL016 part in a U484 package. It has 15k LUTs/FFs and 340 IOs. The 0.8mm pitch which allows pretty much a full fanout on a 4 layer board with 3.5mil s/t. Retail cost for one is $24. There is also a 1.0mm pitch part (F484) for a few dollars more.

Thanks for the suggestion, I will look at this device and consider it as well. $24 sounds good. After seeing so many modules, I have started to look from within quartus itself which is convenient because I can take a large design and be able to see what it looks like when fully compiled into the chip, and how many pins and logic capacity would remain. I have test compiled a few of the devices in quartus, and I will check the costs. 340 I/Os may be enough, I will know more when I do a complete single project of the entire system, which will result in a number of pins remaining internal in the FPGA thanks to the higher level of integration. When choosing any module, I will also need to consider the type of connector it uses. Some of the connectors I have seen look somewhat too delicate.

In terms of memory, I will need two types of RAM, XMS memory and EMS memory which is routed differently to the CPU. 8MB of each would be enough to support most of the software that a 286 is able to run. We will be using a suitable type of EMS for RealDOOM to be able to run on the system.

Regarding the memory speed, the faster the better because I want to try to enable zero wait states and gain a large increase in efficiency from the 286 CPU, and at the same time I want to raise the clock speed further as much as possible. I may also look at using a FPGA to interface DDR3 or faster RAM to the CPU. I have seen some modules which offer DDR3 RAM with 100 pins available. This may be sufficient for that module to possibly handle the memory for the system.

I am currently working on the second CPLD to get this finished and fully integrated into the layout just to see if this third retry would be possible to be implemented using the 208 pin CPLD. If I can get through this quartus project until the end without issues, maybe it can show a path forward. However I am still concerned about the EMS memory controller because this still may present to be too much for a single CPLD to handle. And the issue of two layers staying possible also will play a role.

I will keep searching for FPGA based solutions at the same time because I do like the idea of creating a completely integrated version of the project.

Kind regards,

Rodney

 

[rodney]

I have worked a lot on the System controller / IO decoder CPLD.
So far, I'm making some progress and the quartus project for this second large CPLD is able to fully compile now.

I am building up the PCB layout and at the same time updating quartus to match the PCB, while rechecking the compilation results.
I am doing this to be able to judge if the PCB will be able to complete in two layers which is my goal.

I am using the System controller CPLD not only for System control, CPU command generation, I/O decoding, connecting all the DMA control together and to the slot connectors, but to also buffer certain signals so that the onboard I/O will have less loading on the system bus. For example the IOW_n and IOR_n signals, I am creating those pins two times inside the System controller. One set of signals drives the system bus and the other set drives the onboard I/O. Both signal sets should work with the same timing and logic speed which will be an advantage to do it this way instead of using an external transceiver/buffer. Besides these things, I have also been able to compile the PC/AT Port B into the CPLD which controls some parity checking, reads the refresh pulse from the timer chip, and also the PC speaker logic circuits are included in the CPLD.

I have now fully connected the DMA controllers to the System controller and the slot connectors in the layout. So at least that has also been completed in only two layers now. Also a big part of the X-BUS PC/AT ICs and the IDE ports are fully connected.

I will reposition more ICs and then after I have connected the rest of the pins of the second CPLD, I will move on to designing the third. This CPLD will control the EMS paging memory system, page register programming and also provide buffered signals for the memory modules. Hopefully I can cover all the necessary signals with this third CPLD, if I can that means that the current system design would be able to be built around 3 CPLDs. I will know more later. Hopefully the third CPLD will not have trouble with compiling the remaining OE functions.

The trace density is getting very high around the 208 pin CPLDs, especially with only two layers to work with. So I will need to see if the CPLDs are able to be fully routed on the board in their current locations. With the second CPLD it is getting a little cramped, I would prefer to keep it where it is now. If that doesn't work out, I can move them further apart. However my goal on this revision is also to keep all the traces as short as possible in the core area of the system, especially all memory and DMA related signals.

Kind regards,

Rodney

 

[rodney]

I have done more work on the PCB layout, and the conclusion when I arrived at the EMS controller CPLD is that two layers doesn't seem possible. And even if it is, certain traces would become much longer than necessary. It just doesn't feel right to have to take big detours on the board with fast switching signals.

I have also evaluated the division of functions between the CPLDs. I started out with the concept to try to put as many signals into the first CPLD as possible, hoping that those functions would be possible with a single package. However when looking at the CPLD division, I decided to try a 3B revision where I have separated the address bus and data bus, and routed those through two different CPLDs. This presents a bit cramped layout near the ISA connector edge, however since I have decided to feature the PCB in four layers anyway, I wanted to also take that decision to make this new functional division. I tried to also include the memory data bus however that needs too many OE functions again because of having the two way data flow and needing to control the high and low data bus separately for the data byte conversion scenarios. When I arrive at routing the memory to the system, I will look at what the possibilities will be regarding what is able to compile in which package.

So currently I am creating the 3B layout and 3B CPLD packages, and routing the traces again. It's a lot better because I can route the traces much more directly. Also the address bus is now joined in a single package which does help the layout. I think it may also help the clock speed of the system. Still, the best solution would be a single large package, however this would also be best combined with a replacement for all the X-BUS core controller chips. If those don't need to go outside the package, that would cost a lot less pins.

I am combining the address bus control with the memory decoding, and combined the data bus control with system control and DMA connectivity. Again a few times I ran into compilation difficulty, which not only concerned the limitation in OE functions, however apparently also a limitation exists in where the OE functions are able to be routed in the CPLD. I previously had the Port B in one of the CPLDs, however when I do that, quartus quickly runs into trouble, while not close to all pins are even used. And that difficulty returned each time I added a single output. So I removed the Port B and I will feature it externally. It's I/O anyway so not so speed critical since all I/O uses four wait states anyway with higher CPU clock speeds.

So now I am on the way to building up the 3B version mainboard layout. It took a lot of work to get to this decision however it does result in a more complete impression about a better way to use these CPLDs. I will see if any further difficulties arise, though with four layers that chance is a lot less now. I will just have to spend more costs for completing this final CPLD stage of the project in a satisfactory way.

Kind regards,

Rodney

 

[MennoJoshua]

Could you just install a 16MB (or less SRAM) and then have your CPLD or FPGA do a very simply 16KB-sized page mapping from the address pins to the SRAM? Basically you would have a second (very small) SRAM that holds the page mappings that simply translates A18-A23 to something else with an option for "don't respond" such as the A0000-BFFFF range. You only need 1,024 word sized slots with 10 bits per slot (to use the full 16MB), with high extra bits used for "don't respond" or "steer to ROM" or "steer to ISA bus". SRAM is so fast that you could use the same SRAM for both purposes on each memory access. Such a design would also make it easy to implement ROM shadowing.

Your chip set would boot with an identity mapping pre-installed and then an EMS driver would simply remap those and could also implement full LIM EMS 4.0.

 

[rodney]

Could you just install a 16MB (or less SRAM) and then have your CPLD or FPGA do a very simply 16KB-sized page mapping from the address pins to the SRAM? Basically you would have a second (very small) SRAM that holds the page mappings that simply translates A18-A23 to

Hi MennoJoshua,

Thanks for your suggestion, I will indeed be using some small fast 1ns SRAMs for the page register function, that is, if I decide to continue with the CPLDs. A while ago I posted the EMS concept we are going to use in this thread, which I discussed with sqpat who is working on his RealDOOM project.

The layout difficulty was starting to get apparent not particularly because of the EMS system, the bigger difficulty was the amount of traces going to the CPLDs and not having enough space to get to them. Later I may want to revisit two layers again if I see any opening to be able make this possible.

Kind regards,

Rodney

 

[MennoJoshua]

Out of curiousity how big are your page map SRAMs?

When you are ready, I'd be interested in implementing a full LIM EMS 4.0 implementation (for the driver side of things).

 

[rodney]

I have worked on the layout and while building up the design of the board and the CPLDs, I found more problems with quartus due to resource limitations in these CPLDs.
If I added only a single clock output, this resulted in a big fault being thrown of 226 errors. The fitter can't place the design just because of adding a single output pin.

This is adding some difficulty in the design work because I need to be able to commit to one concept and work through the board accordingly in order to finish the complete system.

And during this recent work I am always considering the list of negatives and positives in my thoughts.
This new 226-error phenomenon due to simple design changes makes me reconsider the CPLD route once more.
I believe this new problem is not related to OE functions but more to the fitter even being able to create the design inside the CPLD package.
So this is creating difficulties in the separated data and address bus concept.
Which may be able to be solved by adding more CPLD chips to the design.

I really would like to create the system in the way I had envisioned before encountering these limitations in the CPLDs.
One of the things I would like to see is using a single large chip to create the system.

I don't want to use TTL transceivers to create the system, I want to design a system more similar to the VLSI TOPCAT concept.
Where you don't find any transceivers on the board to join all the buses using tri-state mechanisms.
I mean, it works, however I believe this solution of using many loose transceivers and latches also has its limitations in how fast it will run.
What I want to do is to multiplex the buses into their end points inside the programmable logic, as I planned to do in the final CPLD version.
However CPLDs pose a lot of problems.

What I really need ideally is a single FPGA package with many normal I/O capable pins, and possibly using something like DDR memory controlled by the FPGA.
If that turns out being too complex to integrate into XMS and EMS I could decide to create an intermediate FPGA version first, which simply uses SRAMs.

I will look into this however to try to figure out what type of memory control code exists for using DDR or faster RAM with a FPGA.
And in what ways this code could be used to access the FPGA memory using the PC/AT system.
SRAMs are also not cheap so the better option would be to use a FPGA as a memory controller.

The biggest obstacle when using FPGAs is to find a FPGA module which offers enough I/O pins that would be suitable to integrate on the mainboard.
Such a module may not exist and I may end up having to design one myself.

I may do some work shortly on a single quartus project which contains everything I wish to include, where I select a FPGA which is capable to contain the design.
This also offers more insight into the pin count and connectivity for the fully integrated version of the system.

I am still thinking what type of module to use. Some kind of "breakout" PCB to get access to the large number of BGA pins, or a more elaborate module containing a DDR3 RAM or something like that. However such a module still needs to add the amount of pins I am looking for.

In attachment the 3B layout in its current state when I start to encounter the quartus fitter problems now.

And here is the code that quartus throws:

Error (163103): Can't pack LABs
Error (163104): Can't place node "inst275~6" of type max_mcell
Error (163104): Can't place node "inst276~5" of type max_mcell
Error (163104): Can't place node "MEMW_n" of type max_io
Error (163104): Can't place node "inst270~6" of type max_mcell
Error (163104): Can't place node "MEMR_n" of type max_io
Error (163104): Can't place node "inst295~14" of type max_mcell
Error (163104): Can't place node "inst302~6" of type max_mcell
Error (163104): Can't place node "INTA_n" of type max_io
Error (163104): Can't place node "inst519~17" of type max_mcell
...... (long list)
Error (163104): Can't place node "inst324~111bal" of type max_mcell
Error (163000): Cannot find fit.

If I remove one simple output pin in the design, it compiles again.
Which I can't continue in this form because it could potentially pose some real risks of needing to update the programming and then encountering these errors again, which would prevent me from even being able to debug the whole system. That is really a big risk for the design and would be a real problem if this happens.

I will spend more time looking into using FPGAs.
Maybe the best way is to design a small custom module in four or more layers containing some modern fast RAM which has a known solution to control it in VHDL or Verilog.

Kind regards,

Rodney

 

[MennoJoshua]

Maybe I'm mistaken but shouldn't SRAM for this purpose be quite inexpensive? (16MB-128MB will be more than enough for most purposes.) The page register itself does not need to be more than a few kilobytes.

Implementing EMS or "advanced" XMS (i.e. ROM shadowing, etc.) should be very simple electrically speaking - if it is getting too complicated try to consider what can be moved into software so you don't have to implementing it in your clpd.

 

[Eudimorphodon]

Maybe I'm mistaken but shouldn't SRAM for this purpose be quite inexpensive? (16MB-128MB will be more than enough for most purposes.)

I talked about this in that 16 bit XMS board thread; you can get 16MB of memory "quite inexpensively" if you are willing to build a board using BGA packaged PSRAM. True SRAM gets kind of spendy.

If you've gone all-in on an FPGA driven design it probably makes sense to use SDRAM/DDR/whatever, given that an FPGA should have off-the-shelf memory controller code.

 

[rodney]

Out of curiousity how big are your page map SRAMs?

Hi MennoJoshua,

The EMS SRAMs are currently 4 megabit in size, and I am considering possibly using 8 megabit chips because these are similarly priced if I buy new ones.

The EMS page map SRAM memory only needs to be very small, it only needs 6 address bits for storing all the possible page locations. EMS Pages are 16KB each which in real mode results in 64 possible page programmable locations within the 1MB memory boundary of the CPU in real mode operation.

I am using two 8 bit SRAMs in the concept for storing the page map information.
This is able to cover the intended EMS memory pool of 8MB. Because we are using a 286 CPU we don't anticipate needing more EMS than that.

If using only a single SRAM and 8 bits to store the page numbers, this would result in a 4MB capacity so I chose to use two SRAMs to cover at least 8MB and possibly being able to use some spare bits for other decoding purposes in the future.

The system also will have 8MB of XMS SRAM in the CPLD version.

The EMS memory will initially support the area between 256KB and 640KB, and the D0000 and E0000 segments to be mapped.

However technically any part of the 1MB region of real mode operation of the CPU would be able to be page mapped to EMS pages.

The system will decode a "default page" number from the 16 bit page register memory which if read in that location of the page register, will default that page it refers to, to be mapped back to the XMS memory pool, a bit like a "page zero". So the EMS system switches a page into place or signals the XMS memory decoder to map the memory location in the XMS memory.

When the system powers on, we plan to include INIT code to store all the "default" page codes in the page register so the system will init in normal XMS operation until the page register is updated for the pages in use by the driver.

The system design has a shadow copy mechanism already included which is currently also in use in my test system. Operating the 286 CPU at 18Mhz and above also required shadow copy to be used.

The EMS system may be modified later if this is found to benefit the driver software.

I will be working with sqpat to support RealDOOM with the EMS system as soon as I have the new system revision built which will include EMS. So I will make the EMS system as much compatible with his work as possible so he will not need to write lots of code to support it.

Kind regards,

Rodney

 

[rodney]

Maybe I'm mistaken but shouldn't SRAM for this purpose be quite inexpensive? (16MB-128MB will be more than enough for most purposes.) The page register itself does not need to be more than a few kilobytes.

Possibly, the type of memory which will be used is currently under consideration, depending on whether the system will be CPLD or FPGA based.

I am currently working out first what I will do regarding the choice for CPLD/FPGA.
I may consider a REV3C CPLD variant and do a different division of logic, however the quartus compilation errors I have seen recently have alarmed me somewhat.
I don't want to be encountering those problems later on during the debugging phase that suddenly the design cannot fit in the chip after a simple update.

When using FPGA I will do some research into what type of modern memory could be suitable to be incorporated in the system.
If that is a DDR type or newer, a single cheap chip will likely already be very large compared to the memory space of the 286.
What I would then want is the fastest affordable RAM which could help us when trying to get to zero wait states for memory operations at higher CPU clock speeds.

Regarding FPGA types, I will probably be using an Altera chip.

If anyone knows of an existing "breakout" module for an Altera FPGA offering some 300 pins, please let me know, it could be immensely useful for my work if I can find a suitable existing solution. The FPGA needs to support the single ended I/O pin capability for this project, the normal types of pins, not the differential I/O types or analog stuff.

I will also work on a fully integrated quartus project for the whole system just to be able to see what that would look like in terms of numbers of external pins which would be needed to achieve this type of design. I will choose a FPGA device in quartus which also supports fully integrating the 74LS612 and the DMA latches, Port B etc which will save more pins. FPGAs could support a number of ideas I am having regarding the system control logic which the CPLDs were not able to completely support.

Maybe I can find some kind of example open source design and VHDL or Verilog code for supporting a certain RAM like DDR3 and it could be possible to include this system in a custom PCB. If a fast DDR3 RAM chip could be transparently interfaced with the 286 and later with a 486 as if it were SRAM that would be really great.

Kind regards,

Rodney

 

[kevju]

using an Altera chip

If you really have your heart set on a native 5V system, the last Altera FPGA that supported 5V IO is the Flex 10K. It's a 30 year old part, but you can still buy them https://www.mouser.com/c/?q=EPF10K. If you are willing to take a bit of risk, you can get them off Aliexpress for about 1/10 the price. You will need a copy of Quartus 9 (I can dig up the download link if you need it, lmk), and also configuration memory that supports 5V https://www.mouser.com/c/?q=AT17LV010A (or protect a 3.3V part with the bus switch I mentioned before). The QFP240 part has 189 IOs. Propagation delay for an address decoder would be about double that of a newer Cyclone/Max part.

fast DDR3 RAM chip could be transparently interfaced with the 286 and later with a 486 as if it were SRAM

This can be done with a newer FPGA, but you would struggle to do better than 50ns latency to read any random byte, and you also need to build in another 15-20ns or so to account for refresh with unequivocal 0 wait state operation. This is a good FPGA/SDRAM tutorial https://www.fpga4fun.com/SDRAM2.html

 

[rodney]

If you really have your heart set on a native 5V system, the last Altera FPGA that supported 5V IO is the Flex 10K. It's a 30 year old part, but you can still buy them https://www.mouser.com/c/?q=EPF10K. If you are willing to take a bit of risk, you can get them off Aliexpress for about 1/10 the price. You will need a copy of Quartus 9 (I can dig up the download link if you need it, lmk), and also configuration memory that supports 5V https://www.mouser.com/c/?q=AT17LV010A (or protect a 3.3V part with the bus switch I mentioned before). The QFP240 part has 189 IOs. Propagation delay for an address decoder would be about double that of a newer Cyclone/Max part.

This can be done with a newer FPGA, but you would struggle to do better than 50ns latency to read any random byte, and you also need to build in another 15-20ns or so to account for refresh with unequivocal 0 wait state operation. This is a good FPGA/SDRAM tutorial https://www.fpga4fun.com/SDRAM2.html

Hi kevju,

Thanks for this information, I will keep it in mind.

I read the tutorial information which is interesting and relevant of course, however this example seems to focus more on dual port memory, which is of course super useful for example for video applications, however I am looking for a much more simple mechanism than they created. When creating a custom video controller, it's more easy to build in some kind of request and grant based communication.

For this project I will need memory suitable for a 286 CPU based system which is capable to be directly accessed through the same bus for read and write operations, and for the memory to be able to simply respond within a certain known maximum amount of ns for the operations which I can test the CPU cycles at different clock frequencies. I can modify cycles with the CPLDs however of course at a considerable expense of efficiency. Currently I am using 60ns SRAMs which are able to at least keep up with a 18MHz clock speed of the 286, using a single wait state. Using 16 bit mode allows to do reads or writes on two bytes per CPU cycle.

Anyway, I appreciate your sharing of valuable information in this regard kevju.

Kind regards,

Rodney

 

[rodney]

I have done a lot more testing and looked further into the suddenly appearing quartus compilation/fitter troubles.
Those appear to happen due to a certain pin configuration which resulted from that REV 3B design variant in the PCB layout.
When looking at the quartus fitter chosen pin layout, which does compile when I assign no pins myself, quartus spreads pins all over the package which is not practical for such a PC/AT system design as we are doing in our project.
Anyway, it is a clue that possibly certain layouts and combinations of functions could result in problematic compilation results which are more vulnerable to resulting in errors from the quartus fitter. So it feels like if I "simplify" or modify the design somewhat, it could help prevent problems with the quartus fitter being unable to create the program for the CPLDs.
I will rethink the distribution another time, and this time perhaps I need to let go of the notion of super high integration if I keep running into more similar problems. Before I ran into these errors, the design was really starting to show promise in terms of the layout of the board and distribution of the system into the CPLDs.

Also I have created the single quartus project for the entire core PC/AT logic including the DMA page mapper and DMA mid address latches, Port B and bus logic.
Also containing the system control, memory decoding for XMS and I/O control, coprocessor control, DMA connectivity etc. Right now I am at the stage where everything is correct in the quartus project and compiles completely with a more advanced and larger device, and I will still need to do more checks and optimizations, and evaluate the new bus structures by comparing the new bus operations with the 5170 operation to make sure it will be able to function. Certain things I am changing simply because we can do this in the design, and these changes were not possible on the 5170 mainboard due to restrictions in the design, chips used etc., where I am of course hoping that the new concept will be able to run much faster.

So a very large part of the whole system is now assembled in one single quartus project, only needing to connect and buffer the XMS memory chips and the EMS controller.
With a larger package device these functions may also be able to be included in the device. Especially if the page registers could be included which would be great if possible.

And here with this single large project it became interesting to test out a few different devices in quartus. And it turns out that certain very advanced FPGAs don't support many simple I/O pins like above 200 pins, and I have tested some slightly older devices with large pin counts instead, which threw a lot less warnings and messages and inspired more confidence in the device being able to run all this logic. There are also some 3.3V BGA CPLDs with many pins which could contain this design as well, so it's not necessary persé to use a FPGA. And using 3.3V logic would be easily supported by the ATX PSU as well. Anyway, some considerations after these experiences with quartus.

I once again did some searches of Aliexpress and GitHub, however there are not any examples so far which I could use.
I saw the very interesting Cyclone III type EP3C120F780 which has a very large amount of 532 I/O pins, however when I read more information from Altera/Intel about how to implement a design I am seeing a lot of messages like don't put this type of pin near that type of pin, or put fast switching pins next to eachother, etc.
Which feels like there may be a lot of difficulty implementing that type of chip. And it would require some experimentation to be able to make use of the chip.
On the other hand, possibly these limitations are more applicable to very high clock speeds and may not apply as much to our relatively slower 286 application.
The point is, I don't know yet because I don't have any practical experience with these Cyclone III chips.
And implementing one right away in this complex application sounds more risky in terms of chances of success on the first design.
Since it's a huge job to assemble the entire PC/AT system together in a design, this would argue more for using a CPLD configuration first.
Like an intermediate step before jumping into a single FPGA solution.

Another thing I should do is study some reference designs and possibly some PCB layouts which are known to be working with faster modern FPGAs.
I should look at other designs which were at least able to function, just to get an idea of a FPGA module PCB what I would want to include.
This could result in a universal application board design which is able to for example plug into a SODIMM slot or into a PCI or PCI Express X16 slot connector.
Which is my current idea for the FPGA stage design. This would allow different FPGA based modules to be used based on what's available in the future, and still use the same base mainboard PCB. The FPGA PCB will take care of connecting whatever FPGA is chosen into the system.
For this purpose I will continue developing the single chip quartus project. I have a few more ideas such as routing more pins from the system so that in the future, the core X-BUS controllers could be replaced inside the FPGA as well. Doing only the core logic will use only a fraction of the FPGA so it could do much more for the system.
For example maybe a SATA controller could be developed eventually and other cool modern features like LAN etc.
Featuring those connectors on the FPGA board should be possible in future revisions as well.
So for the FPGA stage I am seeing a FPGA, level shifters/bus drivers, fast type of RAM and clock oscillators initially on the module, and other ideas could follow in the future.

For now I will have another good look at the CPLD distribution to see if I could get a reliable compilation done, which I will attempt to test by adding more stuff on extra pins to see if the compiler can do it or starts to throws the error.

I have seen a MSI TOPCAT mainboard on ebay from a seller in Italy. It's battery damaged however it inits to at least get a POST and display, throwing some keyboard controller errors. However it's configured and implemented with a 386SX which the TOPCAT chips also support.

What I am thinking about is taking the TOPCAT chips off some day and making a new 286 based PCB for them. I could rethink the memory interface to support SRAM instead of DRAMs. This should be possible with some signal conditioning to latch the address bits going to the RAM in a small CPLD. Anyway, this is an idea I am having for the distant future. I mean, I could desolder the 386SX, pull the TOPCAT chips in 286 mode and try to manually wire in a 286 CPU, however this would be extremely experimental and I don't expect such a manually wired concept to operate at higher clock speeds anyway or even stable at 16MHz maybe. So designing a TOPCAT board would be the better idea. Anyway, this board was not expensive due to the battery damage so I have bought it. I will at least study the layout to see how the 82C331 "ISA bus controller" is connected with the TOPCAT 82C320 system controller chip. And how the 82C320 connects to the DRAM etc. which is also somewhat documented in the datasheets.

I think that studying these chips and their connectivity by being able to beep out everything on this board may reveal some interesting details about the solutions VLSI used for the system. I believe that VLSI did a great job because later VLSI chips were starting to also even feature Intel logos on them, which would not have happened if they were not one of the best at the time for those solutions like system control and DRAM management. I think the Hyundai 486 board which didn't work out also has a 82C331 for the ISA slot.

Anyway, I will do some more test projects in quartus to see if I can make a distribution of logic which appears to compile reliably and at the same time makes sense in terms of being worth while to build a system based on that concept. This is a challenge, however switching to FPGA is equally a challenge and I would want to have a certain basis to work from, for example being able to plug a CPLD based board into the mainboard next to the FPGA, and selectively try to move system functions into the FPGA while disabling them from the CPLD module. So maybe such a "FPGA development" version mainboard should be next if this CPLD version works out in quartus somehow.

Kind regards,

Rodney

 

[rodney]

I'm currently assembling a new system configuration, REV 3D, which hopefully should be able to fully compile without issues eventually.

In my work the past few days I have seen that ominous quartus fitter error pop up a few more times, which was not great to experience. Every time when I saw it, I extensively modified the system division and CPLD tasks in the design once more to try to prevent this from becoming a problem in the future. So my work the past days has involved moving a lot of logic around between quartus projects, checking the compilation process and looking at how many pins are used in each project.

The result is that the system will be created in a few more CPLDs than originally planned. Efficiency of using the CPLDs is one factor, however when this starts to become risky in terms of causing compilation failures, that is a bigger factor for me to consider. So the design will use a few more chips, however I will want to keep the higher integration and using fewer TTL chips on the board as much as possible. I will mix two different CPLD sizes, both 100 pin and 208 pin packages, depending on the various functions of the chips.

I ended up needing more I/O decoding pins so I added a separate IO decoder chip, and since I am putting that chip on the board anyway, I will also feature the IDE ports in a large CPLD and I will use that CPLD to offer a POST display using two 7 segment displays. I found a very nice and helpful piece of Verilog code by Christopher Vickery on his website, which was very kind and helpful of him to share that code on his page. Of course, this feature is a bit experimental and depends on to what degree these POST codes are output by any BIOS used. I hope the MR BIOS can do a good job to give many POST codes on the display, which I would expect to be the case with such an excellent BIOS. The IDE ports inside the CPLD eliminate another 4 TTL transceivers. I will add the fast clock signal and IOCH_RDY to the CPLD in case I run in to some unfortunate timing problems with the IDE ports. Which of course I hope will not happen so it can save us from needing to go through a lot of development and debugging work later on when I have built this mainboard. There may be a lot of debugging in my future, or very little, anything can happen, however at least we have the first concept fully built and tested. The new design features a few bus changes which I will fully check in a few different ways by developing different notes and ways to describe the operations. It is somewhat enlightening to now be doing this work to develop the bus paths in a separated way and creating the individual logic elements involved, which allows more insight into working with separate bus connection paths, which in turn may eventually have provided a few advantages for possibly improving the system operation. In the end I am always thinking about the performance results, and hope to improve it further. But let's first start with getting the system built of course.

On the current REV1 build, this is really rock solid stable now. I have run the system for a few weeks without any freezing now. It's a pleasure to see the system doing so well now. A big improvement is really the Cirrus Logic VGA card. I hope someone could one day help us to reverse engineer this very excellent design so it can survive for the long future in the interest of preserving computing history.

I almost finished the IDE and post display design, and the final step will be to work on the EMS controller chip. Hopefully this can be done in a single package. After that work is completed, I will build up the layout and pin configurations of all these chips. This time, I am doing a best effort work to attempt to make sure first that there are no more quartus fitter troubles popping up easily in any of the chosen tasks within any of the CPLDs. Combining complex tasks seems to be the most risky situation so I have now avoided this as much as possible. I will share more details when I am sure everything will at least compile reliably.

Kind regards,

Rodney