80286 ATX mainboard based on the IBM 5170 AT PC
github.com
github.com
It's really some form of CC-BY-SA-NC plus some more limits about "safety" which is impossible to define and prove or disprove and none of the creators business.
Basically it's almost untouchable until the terms are actually defined and made sensible.
Even the simple "only for hobby/personal/educational use" is internally inconsistent because education is itself a commercial activity.
Trying to say too much in the license is just wasting an exceptionally cool project. Just make it CC-BY-SA, add the warnings and disclaimers, and leave it at that. Only add the -NC if you want to sell them and be the only one allowed to sell them. If you aren't planning to sell them as an important part of your own livlihood, then don't add -NC, it doesn't make the world a better place.
people (usually with a limited engineering background) have a fantasy that they might start a hobby business, and are afraid someone will "steal" their design and sell a dozen on ebay
Even the simplest, most straightforward licenses (like MIT) take care of that much.
Nobody would ever want liability for a project they donate to the world as open source.
The attribution request is a "should", not a "must", and not part of the license.
Personally, I wouldn't interpret anything in the readme as binding conditions.
I did not say anything about attribution. GPL3 already requires attribution and is not a problem. Similarly my suggested CC-BY-SA includes BY.
I mean, not really -- it's mostly just a big disclaimer of liability, and the only time it uses the phrase "not permitted", it's also just amounts to another disclaimer of liability in that it's saying that it's "not permitted" to use the product without assuming full responsibility for the associated risks.
only in some countries.
I miss the ISA bus and its simplicity. People raved about PCI's Plug and Play, but in practice I found it very straightforward to set IRQ jumpers and the experience was free of the quirky issues I encountered with PnP (especially in the early days).
I recall wiring an LED display and some very simple logic (like a buffer IC or something enabled by an address line in a non-existent memory segment) directly to an ISA wire wrap card and getting it to work on the first try. One of the reasons I love working with microcontrollers (especially the relatively clean 8-bit architectures like AVR) is they lack so many layers of abstractions.
One major aspect of PCI which I do respect is it's incredible backwards compatibility. I still use a 20 year old Adaptec PCI SCSI card via an adapter carrier in in my latest PC (drivers were fun but it works).
The other big pains of ISA were finding working I/O assignments with lots of cards, and finding DMA channels (although ISA devices started doing their own bus mastering DMA because the motherboard DMA controllers were a fixed, slow, speed, by spec)
Back in the before times, Papa Delni setup an old 486 (actually 386 using a cyrix "486" cpu) as an X terminal. This was a hot setup with an ATI Graphics Wonder, AMD Lance network, 8mb of ram, the whole 9 yards.
Everything worked great except the network was terribly slow. Except when I moved the mouse, then it was nice and normal.
Turned out the network card and mouse were on the same IRQ, or maybe the driver was looking at the wrong IRQ, and the network buffers only got drained when the mouse was wiggled.
I actually used that little nugget of knowing things to know to switch to polled network buffers on a big fat firewall that was running freebsd -- it was constantly under huge load so there was no real advantage to waiting for IRQs.
Don't miss that world at all.
So often in computing we've completely overhauled the stack with loads of new complexity, when simply adding more of some limited but unexpectedly popular resource would have sufficed (great example... IPv6).
(Ps. Thanks for your informative reply to my comment)
In general, I2C bus is a great way to interface with computers: it's needs only 2 wires, can be easily connected even to 8-bit MCU, and it has great development experience: start with $10 USB-I2C bridge (like CP2112) for development, then connect final device via internal SMBus connector or via unused monitor port. Linux comes with all the drivers, so there is no need to write kernel code.
(You can also do USB, but this is annoying to implement from scratch, without any libraries. And USB-Serial bridge might be taken over by ModemManager and various embedded IDEs.)
I've put plenty of AVRs on ethernet - and once, a 386, using an ancient DOS TCP/IP stack, but never a 286. Linux doesn't support it due to requiring an FPU.
It'd be fun to design the electronics for an old-style computer, but IMHO it'd be far more amusing to do it from scratch with an original architecture than try recreating a third party motherboard using a similar layout scheme. Something with parallelism and auto-scaling would be quaint.
But I'm kind of sad that all OSes converged on a flat address space for the sake of ~PoRtAbIlItY~. Monocultures are bad, and we currently have one, where everything is basically a UNIX clone written in C.
32-bit x86 allowed to use both segments (of any length up to 4 GiB) and paging at the same time. Before the NX bit was introduced, this was the way to have write-xor-execute permissions. And some security features of segmentation can't be replicated at all in a flat address space: with a separate stack segment (or one with the same flat base address but a different limit), it will be impossible to add the wrong offset to a pointer to stack and get access to data that is outside of it.
IMHO, the iAPX 432 had some good ideas, and x86 should have evolved in that direction, adding a few more "extra" segment registers which code can use freely as pointers to isolated objects. Each would have two "limit" fields (for negative and positive offsets from the base), with one of these spaces used for storing pointers to other objects, which can only be manipulated through CPU microcode that guarantees memory safety.
Instead they eliminated segments completely in 64-bit mode, except for FS/GS serving as an extra offset that gets added with no limit checking whatsoever.
Compilers like Turbo Pascal and Microsoft C all gave you a choice of which memory model you wanted to use, often you wrote programs where a 64k code and 64k data space is all you need.
TP forcing use of large pointers for everything, and its lack of even trivial peephole optimizations, probably contributed to the myth that C was somehow inherently more efficient.
[BT]P7 includes for compatibility: tiny (.COM), small, compact, medium, large, and large w/ overlays (which can use EMS when available). There are DPMI clients for [BT]P7 that make it possible to switch to protected mode and use more memory.
It definitely generated offset-only pointers in the tiny, small, and medium memory models because that's how they referred to data with the common DS segment. I did plenty of memory and instruction-level debugging in [BT] Profiler/Debugger and inspected plenty of pointers where they lived in RAM.
http://bitsavers.trailing-edge.com/pdf/borland/turbo_pascal/...
Page 221 (232 in the PDF): "A Pointer type is stored as two words"
Who cares about address space organization? (k|)ASLR, PIC & PIE means this is a detail not worth your time. This kind of standardization is vital for security, debugging, and profiling.
The 386 has LDT that generally isn't used, and there's only one TS that is updated rather than multiple ones. FS and GS tend to be used for thread-local storage.
As an aside, this reminds me of an amusing early example of a rough-and-ready configure-style script[1] included in the BSD source for the compress(1) utility, used to limit the maximum supported LZW code length based on an estimate of memory that will be available to the process[2].
[1] https://github.com/dspinellis/unix-history-repo/blob/BSD-4_3...
[2] https://github.com/dspinellis/unix-history-repo/blob/BSD-4_3...
386 support was dropped, 486 support has not yet been dropped as of writing.
Not saying this to brag, just to establish that I probably know more about that chip than the average poster. And you're also posting plainly wrong claims elsewhere in this thread. I don't get why you're doing this?
I have used Linux on a 386SX which did not have any FPU. Linux had x87 floating point emulation for a long time (AFAIK, that emulation has since been removed, together with the rest of the support for very old CPUs).
The main reasons Linux doesn't support the 80286 are AFAIK that the 80286 is a 16-bit CPU, and Linux (other than the short-lived ELKS fork) has never supported 16-bit CPUs; and that the 80286 doesn't have paging (it has only segmentation), which would require running it as a "no-MMU" CPU.
mTCP (http://brutmanlabs.org/mTCP/) is a currently-maintained TCP/IP stack for MS-DOS that will run on any PC, 8088 and up. You also need a packet driver for your NIC. 286 machines are easy; nearly any 16-bit ISA NIC will work. XT-class machines are slightly trickier because not all NICs will work in 8-bit ISA slots and some packet drivers use 186/286 instructions.
This is incorrect.
FPU means "floating point unit". Linux does not need this. Few OSes do at all.
You meant "MMU", meaning memory management unit. This is what Linux uses to perform virtual memory handling, and that is why Linux can't run on an 80286: the '286 had no MMU (or FPU).
The difference being that 99% of computers without an FPU could just have one added. This was never true of an MMU.
Indeed some early Unix machines based on CPUs with no MMU used an entire 2nd CPU just for MMU duties.
It’s the hardware task switching features that the 386 introduced that it requires (and the reason why Linus got one in the first place back in the day)
The only situation where it would be required to use this misfeature is for handling exceptions like stack overflow in the case that they can occur in kernel mode. A "Task State Segment" is really more like a pre-allocated stack frame anyway, the CPU puts active ones in a linked list and does not allow freely switching between them, only returning to the outer level.
x86-64 does not have hardware task switching anymore, instead it is now possible to switch to another stack on an exception or interrupt, which is all that the TSS was used for in practice anyway.
Nope.
8086 and 80286 multitasked fine.
It was memory management hardware that came in with the 80386. You need that for virtual memory.
Motherboards with PCI slots are becoming rarer and rarer though. Most modern boards only seem to have PCI Express.
Current status(okt 2024): This project is built, fully functional, now able to operate at 20MHz CPU speed.
There's still stock out there of original 286 CPUs, as Intel licensed several manufacturers[1].
[1]: https://en.wikipedia.org/wiki/List_of_x86_manufacturers#Manu...
When I was in high school I developed some software for a teacher on my PC, was a little shocked to find she was still running CP/M. It was no problem at all because I could emulate a Z-80 on my AT clone at 3x speed!
It was very common to find ancient computers just being used for work and word-processing, etc, up to and into the Internet era.
The Internet was what mainly pushed those aside; once that really took off it became a question of "can you connect" and if you couldn't, an upgrade started looking really good.
Either way, it's amazing to think that basically every non-power related chip on that board is now inside a modern chipset IC.
LS125 - 3-state bus buffers - https://www.ti.com/lit/ds/symlink/sn54ls125a.pdf?ts=17314810...
LS612 - Memory mappers - https://media.digikey.com/pdf/Data%20Sheets/Rochester%20PDFs...
8259 - Interrupt controller - https://en.wikipedia.org/wiki/Intel_8259
27C256 - ROM - https://ww1.microchip.com/downloads/aemDocuments/documents/O...
Most of it is somewhat more high-level than the 7400-series ICs and such you might find in something older like the early 6502-based microcomputer motherboards.
An FPGA is planned for the remaining AT controllers, which are now hard to source:
- the 2x 8237 DMA controller
- the 2x 8259 Interrupt controller
- the 8254 System timer
This will allow anyone to build a modern AT, like this was done for the XT.
Follow the discussion here: https://forum.vcfed.org/index.php?threads/project-to-create-...
The only other PLCC-packaged chips are two ATF1508AS, which are indeed ASICs (CPLDs) - oh, and the 53C400, which is... a SCSI controller (probably added as a bonus?!).
That's basically it. The 286 has a much larger wafer inside than a typical DIP, and DIPs are extremely inefficient packages.
It would be interesting to see how much you could shrink this board down if all these chips were replaced with BGAs (using the same wafers inside). Obviously, that's not really feasible (no one is selling a BGA version of an 8259 interrupt controller, much less an 80286), but it would be interesting to see the dramatic size reduction, just from packaging waste. Also interesting would be if you designed a board using BGA versions of all these chips, but fabbed on modern IC processes (thus yielding much smaller wafers. and therefore somewhat smaller BGA packages). Of course, the whole thing could probably just be implemented with a single FPGA these days.
They are obviously ICs, but being programmable they’re general purpose, not application specific (the AS in ASIC).
Old days were hard before USB showed up.
Xenix and Concurrent DOS 286 were the two most capable 286-native OSes. Followed, quite some way behind, by OS/2 1.3.
Lots of info on the 51xx series of machines is here: https://www.minuszerodegrees.net/index.htm
https://dfarq.homeip.net/ibm-5162-pc-xt-286-the-at-in-xt-clo...
I wonder if he looked at any clone motherboards from that time, or a few years later? 16MHz and 20MHz 286s were quite common before the 386 took over, and they probably had to make some changes too (and came a few years after the PC AT, and so probably had a lot of improvements; the AT came out in 1984, but the clone 286s were still pretty strong in the late 80s).
In any case, from the description:
Luckily I found an Ebay auction which offered an IBM 5170 mainboard for a very reasonable price.
I proceeded to draft modern KiCad schematics for the 5170 and subsequently modified the IBM designs to suit this project as much as possible.
The IBM 286 can operate at frequencies below 20MHz as well.
>http://www.machine-information-systems.com/286_Processor.htm...
Link to separate repository: https://github.com/rodneyknaap/atx-486at-mainboard
I started out doing Z80 stuff since the 90s, and did a Z80 PC mainboard. It got me interested in also designing an XT system to learn from this and possibly it could benefit a later revision Z80 system because that was my favorite CPU. I did that until I found that the XT design was sufficiently user friendly and complete. The original XT schematics were relatively complete in terms of the schematics. I have seen some bare PCBs of my design being sold of my XT on a Russian website, which I was happy to see because I hope that anyone enthousiastic, feeling nostalgic about the XT machine and able to do so could have the chance to also build one. Usually you get 5 pieces from for example JLCPCB so there will be some excess boards left over. All the mainboards are not easy and require some skill level and understanding in order to be able to debug any timing related issues. It could be interesting for students for a school project.
Next I decided to look at the AT which is a completely different machine, and yet shared many similarities. The big appeal of the AT to me was the fact that the IBM team involved had the great foresight to make the 16 bit AT completely hardware and software compatible to the 8 bit XT machine. When you study the complete design, you can find that this is not a trivial matter and goes deeply into the core of the technology in order to be able to really have true backward compatibility. In doing this, the PC/AT paved the way for the industry standard to successfully evolve from it. The 16 bit 286 is limited but it deserves respect and served its role in giving humanity the PC technology. The clone builders then took off with the standard which has in it's core kept the original 5170 functionality inside it. It's pretty amazing for this machine to have survive in so many iterations of PC technology! To me this is a level of legendary invention by IBM and particularly thanks to Don Estridge.
The 5170 is a severely limited machine because it consists of a lot of TTL circuits which are vulnerable to timing problems and difficult to scale up in that configuration. The 5170 and similar TTL chipset boards are vulnerable and error prone in my experience, I tested 4 of these old boards and they all had some issues. In order to get the functionality I needed, I had to say goodbye to the TTL graveyard approach and venture into programmable logic. Initially I didn't want to do this because it's not open, but when I recreated more circuits hidden in the PAL chip U87, the scale of the whole design started to grow beyond what I am comfortable with integrating into a single mainboard, and being able to include some useful integrated I/O. The design files are shared so technically it's also openly known technology just in a programmable form. The CPLD chips are a little large, however they have the advantage of through hole sockets being possible. This makes the design more accessible for people who don't like SMD. There is a LAN chip on the board but it should be left out, my tests were not great, it seems to cause stability issues in the system so I took the chip off again. My design does support the 80287 math coprocessor, I have tested this. Please keep in mind, this was literally my first prototype PCB concept of an AT design, and took me more than a year to develop. Before my work, the AT design was only partially known openly to the world. You can see some MAME files and some previous failed attempts to reverse engineer the U87 PAL. A big and important part was hidden inside PAL chip U87, which is now openly known in a functional schematic finally. Without knowing the logic inside U87, there is no chance to fully know the system and how it works. After the 5170 it's mostly all chipset based AT PCs and these chipsets are not known.
After I had replicated a functional 5170, the next goal was clock speed above the original 8MHz. I progressed into 16MHz and then targeted to replace the 82284 and 82288 control chips inside the existing system controller CPLD. This required some level of rewiring finally to patch in an oscillator IC for the new clock signal. A lot of the development work I have done so far is the same as what chipset developers have done before. So I could learn and understand the issues they had faced before in order to get to higher clock speeds and reduce the design in size. Simply replicating the logic in a CPLD comes with a lot of timing related challenges and issues which I have had to overcome in my development.
Please note, the original 5170 used a S-BUS or system bus. Directly behind this bus on the mainboard is the M-BUS or memory bus. So in principle it's possible to move the M-BUS onto a card into the ISA slot which is what I have done. Also note, the ISA bus is simply a CPU/system bus and has no real clock operation. It's only limited looking at the system as a whole in terms of how fast the entire system is able to operate. And that limit is not 8MHz. It's much higher, at least 18 to 20MHz, depending on the configuration. My design was originally intended to be a recreation of the 5170, however it turned out to have much bigger potential far beyond that design thanks to the CPLD chips. My design is not DRAM based, it's SRAM based. So no CAS/RAS involved and no refresh. I removed all refresh functions which are not needed and to some extent free up the CPU for a few more useful cycles per second.
The next step I am working on now is a combined 286/486 system which can swap the CPU. The 486 function will be at some level in 32 bit so it is planned to support all the faster DX2 and DX4 CPUs which evolved. I will use BGA FPGA chips which have much higher integration capability and higher clock rating. This design is in the same spirit as the first revision prototype, to redo the development which was done in the 90s, however I am using more modern technology which was not available at the time. However it's about the technology at its core to be openly known and published finally, and not being lost in time because of original machines dying off. Doing this design can preserve the historic technology in a reproducable form, it's fun to me and also allows to explore the further limits and efficiency of these CPUs, hopefully the FPGAs used will be able to do this in previously unseen levels. I will be using some modern RAM like DDR or such and let the FPGA control it and interface to the legacy CPU. That's the idea. Imagine running a 486 with the full memory in the same speed as cache chips. I don't know if that's possible but I will attempt it. For more details, check out the VCF thread. The new 286/486 development follows in the same thread which started with my 286 PC/AT design. In GitHub there are separate projects published for each of my design iterations.
I stumbled over it while searching for some details on the turbo button my 286 had for a subthread in this[1] story.
When the 286 finally died we upgraded to a 468, but it was one of those Cyrix clones that could be run on a 386 motherboard. It worked very well overall, except there was some features missing which caused issues with a couple of games as I recall. Will be interesting to see if you can get the 486 working on this board as well.
Regarding the 486 support in my next iteration, it will be a huge work to get this going. The 486 has no 82284 and 82288 type of equivalent IC to get the system going initially, so I will need to depend completely on reading the Intel timing diagrams in the datasheet/book and developing the logic to create my own CPU state machine and the system control mechanisms. With the 286 I did this same work in the end, however with the 486 I will need to develop this right at the beginning to even be able to execute code and have a functional system. I will probably modify an existing 486 mainboard in order to test out my own system control circuits on the CPU in order to replace the existing ones from the chipset one by one. I will create a method as I go along in the process. Basically it involves first creating a predictive CPU state machine model, verify this against the actual CPU in operation and comparing everything with the datasheet diagrams. In my VCF thread anyone can read how I am going about this project, and how I did it with the 286.
I am preparing the work leading up to integrating the 486 CPU into the system so I am not reading into this specific documentation yet. That will come when I have all the PCB designs ready and I have everything built up for testing because the preparation itself is already a lot of work. I have been warned that designing FPGA logic is even harder than using CPLDs for this type of "asynchronous" functions as in an PC/AT system which are easy to be skewed by seemingly insignificant circuit changes in any area inside the FPGA. The compiler may completely "overhaul" the programmed file for the FPGA at any time which may pose a new challenge every time to fix the problems, that can occur at any moment during the project. Anyway it was kind of newold86 at VCF to give me a heads up about this. So it will be the trick to find ways of changing the core AT design to become more "immune" to compiler changes.
Another challenge using different types of 486 will of course be the CPU voltage which is different between different types and brands of the 486 CPU. So I will need to design an interface between the FPGA and the CPU which has a variable logic voltage on the side of the level shifters connected to the CPU. Then we have the interface between the FPGA and the 5V ISA slots and cards, and with the 32 bit connection to a VGA adapter it may also pose other challenges, I am still doing the research and preparation of the various modules incrementally, so I will know more details about the actual complexity later. As far as the RAM is concerned I also will need to look at the voltages involved which type of RAM is most compatible with the FPGA of choice. A lot of work ahead.
I got some support from Luca (Retro*Tech) from Italy, who offered to help me and donated a ST 486DX4V100, which will be one test subject for the project.
I will start testing the system using a custom 286 module just to verify lots of things like the ISA slots, onboard I/O and memory interface. There will be the chance to speed-test the 286 to its limits. I talked with user sqpat who is also doing very cool work. He overclocked some 286 CPUs to above 30MHz using a TOPCAT chipset mainboard. Not only is he doing that, he created a custom cooling solution to keep the CPU from burning out, and he is developing his own port of DOOM for the 286 called RealDOOM, where he is using Real mode of the 286 because the TOPCAT chipset is able to generate a paging system within the 640KB base memory area. So he can keep software in the lowest section running while flipping the pages to load in DOOM game data. A unique and cool approach, and a kind of challenge to get this port fully optimized and I would imagine it involves a lot of code rewriting and completely new game loading configuration and mechanisms.
Anyway, thanks for the interest magicalhippo, it's much appreciated.
- reset (and COM1_CS/RTC_DS) is routed horizontally across the board on inner layer cutting ground plane in half right under Realtek and both CPLDs :o. Weak stitching top layer islands using sparse tiny high impedance Vias is not a good way of joining isolated grounds.
- only one Realtek VDD pin 17 is connected to power plane with thick via, rest are using tiny signal vias.
- one tht 100nF capacitor might not be enough to decouple Realtek, usually on ISA cards there are pairs of caps for every one of RTL8019 six VDD inputs. Personally I think 12 caps is total overkill, but there is some middle ground in between.
- Realtek differential TX output is routed along whole ISA J7 slot between pins, seemingly not a problem except it also goes between crystal pins (with interrupted ground, big no no) and over SD8-15 with no ground plane under. Once again ground plane is disrupted by signals being routed in it. This might lead to for example 20 MHz clock being coupled to upper part of data bus.
- looks like 1.8432M for UART also goes across whole board with no ground plane in places.
>In GitHub there are separate projects published for each of my design iterations.
Would it be possible to upload whole kicad project (pcb, sch)? Much easier to browse than gerbers re-imported into pcbnew.
- Whats the deal with RTC_CS from POWER_GOOD? Why additional redundant hex inverter generator for 32KHz?
- Power and reset generation seems very elaborate, 6 chips doing the work of two 7404 inverters and few RC pairs.
Am I correct in assuming those are leftovers from experimentation? Btw calling VBAT "VDD" was a funny trap, took me a good second to realize what was going on :)
If you ever plan adding DRAM or Cache Im happy to help. My hobby dabbling https://github.com/raszpl/FIC-486-GAC-2-Cache-Module https://github.com/raszpl/386RC-16
The 80286 can only address 16MB of RAM. Why not just fill the memory map as standard, then there's no need for SIMM slots or any other memory expansion?
Give me a few Upper Memory Blocks for DOS, and provision for 32MB of EMS as well, and frankly for a DOS machine there is nothing left to add in terms of memory.
How much is 48 _megabytes_ of RAM in 2024? 5¢? 10¢?
about $500-1000 https://eu.mouser.com/c/semiconductors/memory-ics/sram/?memo...
>Why not just
he said the magic words!
Only because you're including RAM spec'ed at 75pS access times.
If you limit the selection to 133MHz (the slowest 'max speed' - ridiculous, you can still easily purchase NEW 50nS and 70nS SRAM elsewhere, this is why I don't buy from mouser)...
Then the price falls to £5 for a 32MB (256Mbit) chip, which isn't excessively priced, but it still more than I paid for similar chips a few weeks ago.
https://www.geeksforgeeks.org/difference-between-sram-and-dr...
Personally Im also a fan of keeping ram oldschool. I even reverse engineered a ram card for a 386 board just last week https://github.com/raszpl/386RC-16
(Re your 386 RAM board: Nice necroproject!)
More than I thought, but still, a relatively small amount for what will work out as a quite expensive retro build.