LibSF 386-x40 Hardware Interface to Real-World 80386 Motherboard

[Rick C. Hodgin]

I'm planning for future goals, something prayerfully in 2017, and
I wanted to get some advice. Please remember that my initial goals
in implementation are not high speed or optimization, but rather are
in functionality and correctness.

I have been considering using an 80386 motherboard, creating a custom
cable connection to my Altera FPGA, which will simulate my CPU core in
a real-world device. I envision the Altera FPGA mounted a few inches
above the 80386 motherboard, with cables running into the CPU socket.

I have some questions about doing this:

http://image.slidesharecdn.com/salientfeatursof80386-140822084001-phpapp02/95/salient-featurs-of-80386-14-638.jpg?cb=1408709884
http://www.minuszerodegrees.net/at_clone_bios/ECS-386_32%20motherboard%20of%20revision%201.0.jpg

#1 -- Would it work? :-)

#2 -- The 80386 is a 5V device. What kind of hardware would I need
to translate Altera's lesser-voltage signals to +/- 5V in the
cable connection?

#3 -- Would the translation hardware in #2 be sufficient for switching
at a clock speed of between 4 MHz and 16 MHz?

-----
In essence, this would be an overdrive processor, one which upgrades
the CPU on the standard motherboard to use my Arxoda core and ISAs,
which will allow me to test out the various features I have on a real
system with real interrupts, etc.

I have been considering the 80386 motherboard because they're relatively
simple from an electrical signal point of view, and should be easier
to debug.

Any thoughts or advice is appreciated. Thank you in advance.

Best regards,
Rick C. Hodgin

[HT-Lab]

Hi Rick,

I would advice against trying to shoehorn an FPGA into a 386 socket, it
will be a lot of hassle! An easier option is to build (or purchase) an
ISA/PC104 card with an FPGA, a UART and IDE and some SRAM. Then get
yourself an ISA backplane and VGA card from eBay and you are ready to go.

Pender (http://www.pender.ch/) used to make a nice (but expensive)
ISA-FPGA board for the Leon core, they might still have some,

Good luck,
Hans
www.ht-lab.com

[Rick C. Hodgin]

I have this Cyclone V GX starter kit dev board:

https://www.altera.com/products/boards_and_kits/dev-kits/partners/kit-terasic-cyclone-v-gx-starter.html

It has a 160-pin HSMC connector, which connects with this flexible cable:

https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ds/hsmc_spec.pdf
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=275

If I read the documentation correctly, it's stating that basically there
are about 100 CMOS pins available used for GPIO. There are 42 pins on
the 80386 socket that are either not connected, or simply carry voltage,
and these can be handled separately as needed by the motherboard (resistor
termination?), allowing the remaining 90 pins to be processed through the
~100 pins on the HSMC connector.

My thinking is... I'll be able to construct a physicl adapter board which
plugs in to the 80386 CPU socket. That board will have voltage converter
circuitry on it along with the 160-pin HSMC cable connect output port, which
then plugs into the corresponding HSMC port on my cyclone v dev board. It
also handles the sync circuitry for VCC and VSS from the motherboard (if
required).

Assuming the HSMC pins are all directly addressable with the Quartus
software (which they all have names, so I assume they are), then I'm
presented with a 1:1 pin-to-pin relationship with the CPU and FPGA,
meaning I can sample and set every pin as necessary for operation.

Some of them are common voltage pins that won't change, and they can be
wired up differently (to resistor termination circuits??) as the FPGA
won't need them.

I would also like to include a "pass-thru reader socket" (don't know the
proper name for it) which allows an actual 80386 to plug in the top, and
the signals going in/out of the 80386 can be monitored through another
Cyclone V GX board which is hooked up for that operation, allowing me the
ability to monitor signals of the true CPU, to help me debug where mine
has gone awry.

That's my thinking anyway. :-)

-----
I see you have a product HTL8086/HTL8088:

http://www.ht-lab.com/commercial/htl8088/htl8088.html

It is impressive. Is it pin-compatible with existing systems?

[Rick C. Hodgin]

> My thinking is... I'll be able to construct a physical adapter board which

> plugs in to the 80386 CPU socket. That board will have voltage converter
> circuitry on it along with the 160-pin HSMC cable connect output port, which
> then plugs into the corresponding HSMC port on my cyclone v dev board. It
> also handles the sync circuitry for VCC and VSS from the motherboard (if
> required).

Oops! That's "sink" circuitry. :-)

> Assuming the HSMC pins are all directly addressable with the Quartus
> software (which they all have names, so I assume they are), then I'm
> presented with a 1:1 pin-to-pin relationship with the CPU and FPGA,
> meaning I can sample and set every pin as necessary for operation.
>
> Some of them are common voltage pins that won't change, and they can be
> wired up differently (to resistor termination circuits??) as the FPGA
> won't need them.
>
> I would also like to include a "pass-thru reader socket" (don't know the
> proper name for it) which allows an actual 80386 to plug in the top, and
> the signals going in/out of the 80386 can be monitored through another
> Cyclone V GX board which is hooked up for that operation, allowing me the
> ability to monitor signals of the true CPU, to help me debug where mine
> has gone awry.
>
> That's my thinking anyway. :-)

I plan for my original Arxoda products to be plug-in compatible with
existing motherboards, though my final form goal is to be socket and
pin compatible with Pentium motherboards at around 50 MHz or maybe
higher if it works well.

Once I get it to that stage, we'll see what the Lord holds for me in
moving forward. Maybe someone will see value in it and invest in the
optimization required. If not, then it will be sufficient.

> -----
> I see you have a product HTL8086/HTL8088:
>
> http://www.ht-lab.com/commercial/htl8088/htl8088.html
>
> It is impressive. Is it pin-compatible with existing systems?

FWIW, I have the mental image that the CPU is basically a type of executive
officer. He receives all of the available input, and provides direction and
marching orders for the rest of the machine. So long as things are done in
the proper protocol, then whether it's Mr. 80386, or Mr. Arxoda giving the
orders, they both should direct the rest of the system properly, just as
would the AMD 386 clone plug-in chips, or overdrive 486+ chips by Cyrix and
others.

It all comes down to outward-facing protocol adherence as I see it, with
the internal processing being done on the inside being of no real
consequence to the "outside world," so long as it adheres to all protocol.

Of course, that's just my thinking. I could be wrong.

[Rick C. Hodgin]

And one final thought:

I have considered also creating all of the hardware required to make a
complete system, designing everything from scratch completely. I may
still do that as in many ways it would be easier with modern FPGA tools
and dev boards like what's available today with all of their various
pins and connectors.

I'm very much looking forward to this project. I'm working on it in
little bits until I get the changes made to my OS kernel. But it is
my ongoing plan, and long-term focus, and Lord willing it will come
to fruition.

[Rick C. Hodgin]

In looking at the 80386 motherboard this morning, I realized it
would be easier to connect to the 80387 socket. It monitors the
instruction stream, and will be able to decode the FPU instructions
which would, in the case of my processor, be repurposed for
testing out other instructions.

In that way, the original 8386 processor can do all of the normal
handling, and I can test out the capabilities of my processor one
by one in a controlled environment using traditional tools.

[David Brown]

As others have said, I don't think this is a particularly good idea - it
would be a great deal of effort, and you would not get anything useful
out of pin compatibility with an outdated processor and outdated
motherboard.

I would recommend you get a decent FPGA evaluation board (go for a
Cyclone board with both flash and DDR memory on board, and support for
Ethernet and at least one RS232 port. Also consider an HDMI output and
USB transceivers). If you want to do some hardware debugging, a
PicoScope would be convenient.

That setup will let you put together the basic hardware such as memory,
a UART or two, and some LEDs and switches, without having to work on
designing, building, testing and debugging your physical hardware. Your
ambitions might stretch to designing /everything/ yourself, but take
steps along the way, minimising the number of new things you need to
learn, create and test at each point.

If you get your processor working, the sort of devices on a board like
this would be far more realistic than the devices to be found on an old
i386 motherboard. 1 GB of DDR3 memory is cheaper and easier to obtain
than a 256 KB DRAM module from the i386 days.


If you /really/ want to go for pin compatibility, then you will need
level converters. Depending on the particular FPGA, you might find it
is already tolerant to 5V on the inputs. For slower signals, a simple
series resistor and zener diode clamp will be fine if the FPGA max
voltage is 3.3V. And for such old technology as you find on an i386
board, many of the parts which expect 5V inputs will be quite happy with
3.3V levels.

For the faster signals, you might need level translators such as these:

<http://www.ti.com/logic/docs/translationresults.tsp?sectionId=458&voltageIn=1.2&searchDirection=1&voltageOut=1.5&Search=Search>

Bi-directional translation (for data buses) is a pain - it's a lot
easier to use unidirectional translation where possible. (For
convenience you might want to simply use the same bidirectional chips,
and hardwire the direction.)


But it is all pointless - you need to go to a lot of effort to
understand and connect to the north bridge on the motherboard, even
though that arrangement has been obsolete for a decade or two.

[Rick C. Hodgin]

As I understand it, it's a very simple protocol that is timing based.
Address pins are asserted with read-enable / write-enable, and the
same for the data pins on the main bus. It doesn't seem that difficult.
The only difficulty I could see is in getting the timing just right,
but that's just an issue of elbow grease and debugging.

[Rick C. Hodgin]

Here's a slideshow identifying the pins in use. Look specifically at
slide 3:

http://www.slideshare.net/Raunaqss/pin-description-diagramof80386dx

[David Brown]

That is one way to look at it. But getting the timing right for this
sort of thing is not always easy - and it can greatly restrict or
complicate the rest of your design. The way to get logic design right,
without a substantial amount of extra work, is to use synchronous logic
- get a clock, and change your signals on those clock edges. The i386
stems from a time when asynchronous buses were common for memory or
other (for the time) high-bandwidth buses - you need careful
synchronisation and timing between the different sorts of signals. It
is /much/ easier to get the synchronous designs right. (Note that for
the asynchronous stuff, you can't do it by trial and error, testing and
debugging. You have to /know/ that your timings are right - otherwise
it will work most of the time but not always, and whenever you connect
your scope to view the problem, you change the parameters.)

And once you have full control of the timings of the bus signals, you
have the protocol on top of that - an extra layer of historic junk that
is best forgotten.

It is all a huge waste of effort. It is like wanting to write a book,
and starting off by catching a swan for its wing feathers and squeezing
an octopus for its ink.

You wanted advice and thoughts - that's the best I can give you here.

[Rick C. Hodgin]

I appreciate your advice.

In looking over the 80387DX specs today...:

http://ps-2.kev009.com/madmax/madmax/files/cpudata/24044805.pdf

...I had a question: Why couldn't I design a daughter board which
plugs into the co-processor socket, one which routes signals through
the level converters, through the interface cable to my Cyclone V GX
dev board, which would allow me to monitor and sample the various
signals on the actual CPU itself?

I would then be able to begin step-by-step by introducing the equivalent
of an FPU-NOP instruction, which simply holds the #coprocessorbusy high
for a few clock cycles, and then releases it, etc., to get it to the
point where it's working that way? And then begin by attempting to
read a value from memory, or write a value to memory, and then to do
some simple integer manipulation, and then some other things, to the
point where I have the protocol worked out.

And then, I can begin introducing my own CPU ISA which is able to be
enabled as part of its own instruction stream.

As I understand it from the Pentium overdrive CPU that plugged into
the 80387 co-processor socket for the 80486 CPU, it basically took
over the computer and never relinquished control back to the 486,
but required the 486 to boot up to "tickle it" in just the right
way to get it to work.

With my CPU I could do something similar at one point. Boot up with
the standard 80386DX, and then switch over to mine with some tickling,
from which my CPU never returns.

I think doing this on the co-processor socket is an interesting idea.
I'll have to do some more reading. Everything I've read about the
asynchronous bus signals is on the CPU side, and only for a look-ahead-
to-the-next-address purpose. The FPU allowed asynchronous clock
speeds, and there are two clock inputs for that purpose, but it does
not have to use the second clock at a different speed. It can remain
fully synched to the CPU, which is what I would do.

It also looks like the 80386DX cannot clock below 10 MHz for some
reason. I'm considering using an Amd386 CPU, which I believe can be
clocked down into the KHz range from their data sheets, though that
may only be on more modern Amd386 CPUs which are used for embedded
systems, and not their ceramic counterparts from the 80s.

Baby steps:

(1) Daughter board with level converters and HPMC ports.
(2) Cyclone V GX dev board programmed to monitor and record
voltages on the coprocessor socket, and relay the same
for analysis, triggered by things like a write to a
specific I/O port for on, another for off, allowing
examination across single instructions.
(3) Introduction of the coprocessor-NOP instruction.
(4) Introduction of a "read memory" instruction
(5) Introduction of a "write memory" instruction
(6) Introduction of a "read, process, write something" instruction
(7) Movement forward to a full FPU capability that performs the
full FPU ISA, even if it's exceedingly inefficient.
(8) Movement forward to a full CPU capability that performs the
full CPU ISA, even if it's exceedingly inefficient.
(9) Optimization.

The Cyclone V GX board has 4Gb DDR memory (512 MB) and should be suitable
for loading DOS and Windows 95 at least, with only the lower 8MB or so
needing to be shadowed to the actual 80386 motherboard for the various
hardware devices. I'd like to get my CPU to the point where it could
boot Windows, and maybe some other OSes as well.

Once I'm there, I'll start introducing my other ISAs with ARM first. I'd
like to get it to the point where it can boot an ARM kernel on an 80386
architecture, for example, by having the hybrid ISA load a boot sector
which then sets up the CPU in a flat mode, switches ISA and transfers
control to the ARM code.

And last I'd like to introduce my own ISA.

I'd like to have the daughter board created by this time next year, and
have the coprocessor-NOP working by my birthday next year (August, 2017),
and have the read, write, read-process-write operations completed by the
end of 2017, with the full 80387 ISA coming quickly after that.

I am going to design the internal engine of the FPU to use the unum
format, and will translate to IEEE-754 encodings (not rounding modes, at
least not at first) with an in/out translation on load/store instructions.

-----
Doesn't this sound like a natural and logical step-by-step progression
for someone who wants to create an extended 80386 ISA (the LibSF 386-x40),
from someone who already has all source code to a custom 80386 OS that
boots, has full debugging abilities, and can be altered as needed?

[Rick C. Hodgin]

On Monday, April 4, 2016 at 11:49:08 AM UTC-4, Rick C. Hodgin wrote:
> As I understand it from the Pentium overdrive CPU that plugged into
> the 80387 co-processor socket for the 80486 CPU, it basically took
> over the computer and never relinquished control back to the 486,
> but required the 486 to boot up to "tickle it" in just the right
> way to get it to work.
>
> With my CPU I could do something similar at one point. Boot up with
> the standard 80386DX, and then switch over to mine with some tickling,
> from which my CPU never returns.

Something didn't sit write with me with this statement. I searched some
on Google and couldn't find corroborating evidence.

I'm remembering reading about an overdrive CPU doing this, but I have
the details incorrect about which one it was, and which socket. I'll
have to try to look it up and find the actual reference.

I still think working through the coprocessor in this way is a good way
to have healthy debug tools in a working system that can report on its
own computed results.

[Rick C. Hodgin]

I found it. It was the "Intel 80487," which was an 80486 DX that plugged
in to the upgrade socket replacing completely the 80486SX CPU. It was a
full CPU but had an integrated math-coprocessor, and simply took over the
full execution of the instruction stream when installed:

http://www.cpu-world.com/CPUs/80487/index.html

[Walter Banks]

On 2016-04-04 10:01 AM, David Brown wrote:
> On 04/04/16 14:51, Rick C. Hodgin wrote:
>> On Monday, April 4, 2016 at 8:13:49 AM UTC-4, David Brown wrote:
>>> On 03/04/16 15:25, Rick C. Hodgin wrote:
>>>> I'm planning for future goals, something prayerfully in 2017, and
>>>> I wanted to get some advice. Please remember that my initial goals
>>>> in implementation are not high speed or optimization, but rather are
>>>> in functionality and correctness.
>>>>
>>>> I have been considering using an 80386 motherboard, creating a custom
>>>> cable connection to my Altera FPGA, which will simulate my CPU core in
>>>> a real-world device. I envision the Altera FPGA mounted a few inches
>>>> above the 80386 motherboard, with cables running into the CPU socket.
>>>>
>>>> I have some questions about doing this:
>>>>
>>>> http://image.slidesharecdn.com/salientfeatursof80386-140822084001-phpapp02/95/salient-featurs-of-80386-14-638.jpg?cb=1408709884
>>>> http://www.minuszerodegrees.net/at_clone_bios/ECS-386_32%20motherboard%20of%20revision%201.0.jpg
>>>>
>>>> #1 -- Would it work? :-)
>>>>
>>>> #2 -- The 80386 is a 5V device. What kind of hardware would I need
>>>> to translate Altera's lesser-voltage signals to +/- 5V in the
>>>> cable connection?
>>>>
>>>> #3 -- Would the translation hardware in #2 be sufficient for switching
>>>> at a clock speed of between 4 MHz and 16 MHz?
>>>>
>>>> -----

>

> That is one way to look at it. But getting the timing right for this
> sort of thing is not always easy - and it can greatly restrict or
> complicate the rest of your design. The way to get logic design right,
> without a substantial amount of extra work, is to use synchronous logic
> - get a clock, and change your signals on those clock edges. The i386
> stems from a time when asynchronous buses were common for memory or
> other (for the time) high-bandwidth buses - you need careful
> synchronisation and timing between the different sorts of signals. It
> is /much/ easier to get the synchronous designs right. (Note that for
> the asynchronous stuff, you can't do it by trial and error, testing and
> debugging. You have to /know/ that your timings are right - otherwise
> it will work most of the time but not always, and whenever you connect
> your scope to view the problem, you change the parameters.)
>
> And once you have full control of the timings of the bus signals, you
> have the protocol on top of that - an extra layer of historic junk that
> is best forgotten.
>
> It is all a huge waste of effort. It is like wanting to write a book,
> and starting off by catching a swan for its wing feathers and squeezing
> an octopus for its ink.
>
> You wanted advice and thoughts - that's the best I can give you here.
>
>

A point that cannot be over emphasized is the timing is rarely
documented in the detail that is needed and it is the type of document
that is often may not be correct for the specific mother board.

w..

[Rick C. Hodgin]

Are you suggesting some kind of proprietary trade secret is employed, one
that prevent other companies from stepping in with what would seem to be
a straight-forward offering which could supplant their product?

I was searching today for the number of various kinds of math coprocessors
that were created. There were quite a few.

I wouldn't mind designing everything from the ground up. It would be easier.
But it would be quite an accomplishment to have a real 80386 ISA that works
on a real 80386 motherboard, servicing the various interrupts.

I view timing as something that has to follow a strict protocol. If it can
be observed through a running CPU, for example, such as by creating a sandwich
sampler board between the physical socket and the actual CPU, so that the
actual CPU plugs into the sandwich on this side, and the sandwich plugs into
the physical socket on the other, then those signals passing through could be
sampled by circuitry on the sandwich board.

If I remember correctly from my days of working on programmable stepper
motors, we used opto-isolation circuits so as to not draw any significant
current from the circuit we were examining. I believe those had a switching
speed of about 3 MHz max, but whatever it was I remember it being above
whatever the highest speed possible was through the EPP parallel ports we
were using for communication at the time was, which I think was 1.5 MHz??
Can't remember. That was mid-90s, and I only worked on that project for
a few months.

I'm going to try to see if I can't get the 80386 motherboard I have, which
has an Am386 40 MHz CPU in it, to underclock, and to see how far down it
will go, and if I'm able to clock it at a speed different than the rest of
the system and it will still work. I'd like to ultimately target a speed
of 1/100th the machine clock speed, which would put me down around 400 KHz.
If I can, then I think I will have my target in sight as timings should be
far more forgiving at those low clock speeds than at the higher ones.

Walter, do you think it's a bad idea? Or that it will just present its own
set of challenges? I've never done anything like this before, but I can
see, in theory, this entire world opening up before my eyes of how these
things might be accomplished.

[Rick C. Hodgin]

In reading this page:

http://www.cpu-world.com/CPUs/80386/MANUF-AMD.html

It looks like the Am386 can be clocked down to 0 MHz, allowing it to draw
just 0.001 Watt.

Perhaps I can drop it down as needed programmatically to even 10 Hz for
real analysis and examination during specific operation.

[Walter Banks]

It depends on your goals but the interface to duplicate an existing chip
could easily be bigger project than your proposed ISA. Part of it is
timing knowledge and limited spec. The people who designed the board had
the resources of the chip provider for support, reverse engineering
missing information from timing data can be frustrating and time consuming.

What I am really saying is it can be a big project in itself think
though if it is draining a swap or or an alligator hunt you want to do.

w..

[David Brown]

I think what he means is simply that people frequently did not bother
documenting the details, or at least not publishing the details. Rather
than being a conspiracy to prevent competition, there was often no need
to bother making such documents. After all, the socket and board only
ever had to work with a few specific chips, often devices made within
the same company. Why bother with accurate formal published
documentation, if the job can be handled with a post-it note sent
between two offices?

> I was searching today for the number of various kinds of math coprocessors
> that were created. There were quite a few.
>
> I wouldn't mind designing everything from the ground up. It would be easier.
> But it would be quite an accomplishment to have a real 80386 ISA that works
> on a real 80386 motherboard, servicing the various interrupts.
>
> I view timing as something that has to follow a strict protocol. If it can
> be observed through a running CPU, for example, such as by creating a sandwich
> sampler board between the physical socket and the actual CPU, so that the
> actual CPU plugs into the sandwich on this side, and the sandwich plugs into
> the physical socket on the other, then those signals passing through could be
> sampled by circuitry on the sandwich board.

You have to decide if this really is a good use of your time and effort.
The answer is blindingly obvious to anyone else - no, it is /not/ worth
the effort. But it is equally obvious that you have a totally different
idea of what makes sense.

I think I have already made it clear that I consider the whole "design a
40-bit sort-of 386 compatible cpu" idea to be ludicrous, and a total
waste of time and effort. You have vast numbers of ideas, some of which
may actually be possible to realise in practice, and maybe even useful
to other people. From a purely selfish viewpoint, many of them would be
more interesting and educational for you. And of all the ways to
implement your 386 device, trying to reverse engineer an ancient and
poorly documented board is one of the worst ways.

Making your own cpu can be great fun. Starting from an existing ISA can
make the job easier - but go for ARM, not x86. Making your own ISA
makes some parts easier, other parts harder. But stick to doing it on
the FPGA board - connecting to an existing 386 motherboard is definitely
something that you don't want to consider at the moment.

>
> If I remember correctly from my days of working on programmable stepper
> motors, we used opto-isolation circuits so as to not draw any significant
> current from the circuit we were examining. I believe those had a switching
> speed of about 3 MHz max, but whatever it was I remember it being above
> whatever the highest speed possible was through the EPP parallel ports we
> were using for communication at the time was, which I think was 1.5 MHz??
> Can't remember. That was mid-90s, and I only worked on that project for
> a few months.
>

Opto-isolators can vary in speed between a few hundred KHz to multiple
GHz. But in cases like this, you can't think in terms of frequency -
you have to think about delays, switching speeds, channel-to-channel
delays, and jitters. If you need to reverse engineer the timing on the
socket here, you can't do it with optoisolators connected to a PC port -
you need a solid logic analyser, and they are expensive. You also need
to know what you are doing - and that is well beyond the level of a
newsgroup post.

[paul wallich]

On 4/5/16 5:14 AM, David Brown wrote:
> On 04/04/16 21:27, Rick C. Hodgin wrote:

[...]

> Opto-isolators can vary in speed between a few hundred KHz to multiple
> GHz. But in cases like this, you can't think in terms of frequency -
> you have to think about delays, switching speeds, channel-to-channel
> delays, and jitters. If you need to reverse engineer the timing on the
> socket here, you can't do it with optoisolators connected to a PC port -
> you need a solid logic analyser, and they are expensive. You also need
> to know what you are doing - and that is well beyond the level of a
> newsgroup post.
>
>> I'm going to try to see if I can't get the 80386 motherboard I have, which
>> has an Am386 40 MHz CPU in it, to underclock, and to see how far down it
>> will go, and if I'm able to clock it at a speed different than the rest of
>> the system and it will still work. I'd like to ultimately target a speed
>> of 1/100th the machine clock speed, which would put me down around 400 KHz.
>> If I can, then I think I will have my target in sight as timings should be
>> far more forgiving at those low clock speeds than at the higher ones.

And even if the CPU can be underclocked, you have no guarantee that any
other part of an old, imperfectly documented board can be underclocked
to the same rate, or which of the timing requirements scale and which
don't. If you get things working on an FPGA board, you can always come
back and extend your work to the retro hardware, but if you have to get
the retro hardware working with your proposed daughterboard
(siblingboard?) before you can start work on the ISA, you might be stuck
for a long, long time.

paul

[Rick C. Hodgin]

Well FWIW, I didn't plan to hit a wall and then stay there incrementing
in Krell energy until I'm able to blast through it. :-) I'd give it a
few evenings at most, and if that didn't work, I'd abandon the effort.

[pavlov...@googlemail.com]

I'm a software guy now (higher level too), but it sounds like a few evenings wouldn't get you very far, even if you could pull a rabbit out of the hat (which is going to be very hard because of levels as well as timing).

I do have some experience of things like bit-slice design.

[Rick C. Hodgin]

Am I wrong in thinking it's as simple as taking the crystal timing circuit
out and replacing it with a soft timer powered by the FPGA through a level
converter, beginning at the same frequency as the original, loading a test
program that runs continuously, and then slowing decreasing the clock speed
to see where it fails? And if it doesn't fail all the way down to a slow
speed, then try rebooting at the slower speed, etc?

[David Brown]

Yes, I am afraid you are wrong - it is not that simple. I don't know
details of PC motherboard design, but I expect there will be a fair
number of clocks. Some will be at fixed rates, such as 32.768 kHz for
the real-time clock, and 1.8432 MHz for the UARTs. Others will vary,
such as the main processor clock and the ram clock (on a motherboard as
old as this, the ram clock may be generated from the processor clock).
The various buses will have their own clocks too - part of the point of
using asynchronous interfacing is that you can have separate clock domains.

And while the processor itself may be able to run at any speed (up to a
given maximum), that does not apply to all other clocks, and there may
also be limitations on the relative speeds. For example, the ram clock
will have a minimum speed in order to keep the dynamic ram refreshed.
And you may find that the processor clock has to be a minimum speed
relative to the ISA bus clock.

(As I say, I don't know the details - I am just guessing about possible
challenges.)

[Rick C. Hodgin]

In my particular application, there's no reason why I couldn't lower the
clock rates of those other clocks proportionately as well, by sending out
their signals at a commensurately slower rate as the main clock is also
lowered.

> Others will vary,
> such as the main processor clock and the ram clock (on a motherboard as
> old as this, the ram clock may be generated from the processor clock).
> The various buses will have their own clocks too - part of the point of
> using asynchronous interfacing is that you can have separate clock
> domains.
>
> And while the processor itself may be able to run at any speed (up to a
> given maximum), that does not apply to all other clocks, and there may
> also be limitations on the relative speeds. For example, the ram clock
> will have a minimum speed in order to keep the dynamic ram refreshed.
> And you may find that the processor clock has to be a minimum speed
> relative to the ISA bus clock.

I should also be able to disconnect the address and data lines to the
DRAM chips after they are initially discovered by BIOS, and when a
particular bootup code sequence signals a particular value out a par-
ticular port, which signals the FPGA to disconnect the on-board DRAM
from the main bus, and then use the FPGA's on-board memory shadowed
into that range, essentially bypassing the north bridge to the DRAM
and using the Cyclone V GX's SRAM in its place.

> (As I say, I don't know the details - I am just guessing about possible
> challenges.)

I think they're all workable. The goal is to ultimately have it working
at full frequency. And if I can't underclock it down into the KHz or Hz
range, then I'll just underclock it down as far as I can and start there,
making the timings a little more forgiving.

[Waldek Hebisch]

Rick C. Hodgin <rick.c...@gmail.com> wrote:
>
> In my particular application, there's no reason why I couldn't lower the
> clock rates of those other clocks proportionately as well, by sending out
> their signals at a commensurately slower rate as the main clock is also
> lowered.

Video needs specific timing, otherwise signal will be unusable.
Similar for raw disc. IDE interface will isolate you from
raw disk, but disc controller must have its clock and you
will have to respect its timing requirements. Next,
there is 8042 keyboard controller -- keyboard interface has
a wide variation in timing, but it is not clear how low
you can go.

Many 386 had "turbo button": in one setting you got slower
speed for compatibility with old hardware or software.
So some slowdown may be as easy as choosing "noturbo mode".
Disabling cache will also slow down system due to RAM
wait states (IIUC sometimes "noturbo mode" was done by
disabling cache).

But many chips in this era used dynamic logic and had
minimal clock frequency. Other had clocks fixed by
external requirements. With external devices you
probably will have to use at least few MHz. Without
devices may be better.

Still not clear how this exercise will move you closer
to your goal: given FPGA with connected SDRAM and other
interfaces you can easily test your CPU logic. Connecting
to 386 motherboard will tell you someting about old
buses. But those buses are obsolete and there is no
reason to use them in your design. OK, if you want
to bake your own chips then old designs are easier
to manufacture. But my understanding was that you
plan to stay at logic level, allowing relatively
modern (say 2005) manufacturing.

--
Waldek Hebisch

[Rick C. Hodgin]

My goals are actually to create my own fab someday (Lord willing), and
create my own CPUs. I'm literally targeting a 3 micron process technology
for my initial attempt. I'm hoping to get an 80386 + ARM + my own ISA
core that will clock in the KHz range, and will yield at least 10%. :-)

However, that's a long ways off (late 2020s at best per my current
estimates). For now, I'm looking to get my 80386 compatible ISA designed,
coded, tested, and debugged, and I was thinking the best way to do that
was alongside real hardware. But, it's sounding like the motherboards
are non-cooperative.

So, what if I simply took the Am386 CPU, created my own 132-ping socket
for it to plug in to, which then plugs in to my FPGA, and I become the
entire chipset for it? I feed it its clock, provide the northbridge,
southbridge, interrupt controller, and all other hardware devices?

Is such a thing possible?

If I could do that, and get it working, then I could design my core
and, via protocol, execute single instructions on the Am386 CPU and
on my CPU, comparing registers, memory, flags, and port reads/writes
in all cases to see if they are identical. I could report any
discrepancies, and in that way it would be a known 100% clone.

IN theory, I should be able to also compare side-by-side an Am386
and an Intel 80386, along with Cyrix, etc., to see how they all
compare by providing the same input as I would initially design for
the Am386, but to all of them.

-----
So, is this method possible (just using the CPU plugged in to the FPGA,
with the FPGA providing the entire chipset)?

[Walter Banks]

Re-read what you just post and see if it is your real goal. I have been
part of quite a few processor developments. Timing rise time, bus load
pin capacitance there are lots of non timing issues that will become
part of the problem. You want to duplicate that as well as a ISA
development?

Someone I think David pointed out ISA or interface first consideration.
The interface to duplicate an existing processor interface is not trivial.

w..

[Rick C. Hodgin]

Walter Banks wrote:
> Re-read what you just post and see if it is your real goal...

My goal is to create a full hardware and software stack which is
an offering unto the Lord, and my fellow man. Not one tied to
proprietary IP, or patents, or trade secrets, but one which leverages
the facilities of the universe He gave us, in this area of discipline, as
these are my particular interests.

I would like to create an industry, one which doesn't run at 4GHz,
but one which provides utility to mankind, and does so in a way which
explicitly gives glory to God, for He is the reason any of us are alive,
possess the faculties we do, have our unique and special talents and
abilities, and even have been given the circumstances we have had
to achieve the things we've achieved, entering in to our station of life.

We are not self-made men. We have been gifted. Jesus Christ is
everything, and I desire to honor Him and hold Him in that position
in all areas of my life.

At a point and time in my life when I did not know Him, I began
working on my 80386 kernel and OS. When I was saved in 2004,
I held all of the things of my life up before Him, and it was a complete
revamping of everything which took place. Old interests were supplanted
with new interests, and others remained.

I have not felt conviction over my interests in 80386, and I actually
feel a calling toward that end. I feel this inner drive and desire to
not simply skate along the ways blazed by money-seeking interests,
and instead create and offer a sacrifice of my life's interests unto
the Lord.

I desire to set my sights on Him, and run using that which He blesses
me with.

There's a Christian song called, "Follow Me." Kt has some lyrics which
speak to this point:

"If just a cup of water I place within your hand, then
just a cup of water is all that I demand."

That whole song is inspiring, but many performers try to over-sing it:

https://www.youtube.com/watch?v=jh1lFiar8tk

-----
FWIW, I find it very surprising that a CMOS CPU would have issues of
edge timing if notably underclocked. I don't understand why things
wouldn't be triggered by edge events, but persist as the clock
continues in level cycle.

It makes no sense to me. Switches are switches. Even if they don't switch
at the same speed, the electrical pathways will sort themselves out if
given enough time, as per the slowest switch's needs.

And as such, the needs of a CPU at underclocked speeds
should merely be protocol, with all timing issues removed from the
equation as trivial non-issues due to the much slower clock speed, and
especially in a CPU capable of static operations like the Am386.

I think it's worth a try. If it doesn't work quickly, I can abandon the
effort.

[Walter Banks]

On 2016-04-06 5:50 AM, Rick C. Hodgin wrote:

>
> And as such, the needs of a CPU at underclocked speeds
> should merely be protocol, with all timing issues removed from the
> equation as trivial non-issues due to the much slower clock speed, and
> especially in a CPU capable of static operations like the Am386.
>

You are making a big assumption that the interface problems will go away
by slowing it down. As several people have pointed out it is more than
just timing and slowing it down may not solve or reliably allow
operational behavior at low speed. I suspect that most of these folks
like me have large bags under our eyes from trying this type of
approach. It is not an approach that is easy without a lot of resources.

These things are like a fractal every time you think you understand what
is happening another layer of detailed problems emerge. After a half
dozen layers the ISA development will appear to be inconsequential.

Do the simple tests and get some real experience on the board you want
to use.

w..

[Rick C. Hodgin]

There's an incredibly kind person on comp.arch.fpga named rickman who has
offered to help me design the board I'll need, as he's suggested I create
a board which operates like this (view in fixed point font):

----[ Begin ]----
386 Chip
____________
++++++++++++ FPGA
============== _____________
|||||||||||| ,,,,,,,,,,,,,
=================================================== PCB
||||||||||||
Plugs into 386 Mobo

When emulating the 386 unplug it from the socket. When emulating the
mobo, unplug from the mobo. When monitoring the 386 in operation plug
in the 386 and plug the board into the mobo.
----[ End ]----

In that way I can route wire signals into the FPGA and the two sockets,
and become the chipset for the system when it's not plugged in to the
motherboard, or monitor what's taking place when it is.

And if I can get it working so that my own CPU has correct timing for
the motherboard I'm using (at clock speeds of 25 to 40 MHz), then I'll
be able to use my own ISA for all of these purposes on a real-world
device, extending its design to all of the features I propose, including
the 40-bit extensions which then use extra pins for memory to reach out
beyond the 4GB 80386 limitation.

That would be exciting. And then ultimately, if it works, I can use
the FPGA and custom board to directly plug in to a socket, receiving
power from the board itself, stepping up or down as needed for voltages,
allowing a literal drop-in alternate CPU solution, which then has the
ability to operate on other ISAs in an 80386 motherboard.

I saw an Intel offering yesterday that was called Intel RapidCAD. It
was an 80486DX CPU (with integrated FPU) in an 80386 132-pin socket
form factor. That chip was able to overdrive an 80386 motherboard to
the faster internal processing of the 80486DX design with its integrated
cache and pipelined integer ops.

https://en.wikipedia.org/wiki/RapidCAD

Since that type of conversion was possible, it should be fairly easy for
me to then extend my 132-pin 80386 design to plug in to the 169-pin 80486
socket, and its protocols, and then to jump to the Pentium, and so on.

But regardless of whether or not I pursue any of that, I do plan on working
with at least the Am386 in this type of configuration:

Am386
____________
++++++++++++ FPGA
============== _____________
|||||||||||| ,,,,,,,,,,,,,
=================================================== PCB

...without having the socket actually going into the motherboard, even
if the pins to do so are present. I'll start simply at the "be the
motherboard to the Am386" stage, and see if I can get anything to boot.

[Rick C. Hodgin]

In studying the 80836 pinout datasheets, I've come to an amazing realization:

In looking at what features are considered "optional" by the CPU, of the
132-pin socket, there are only 19 control pins which will be used in a
32-bit bus implementation that does not support address pipelining. And
only 16 if a math-coprocessor is not used. And only 14 if there isn't an
arbitrated system bus. The rest of the pins are 30 address pins, 32 data
pins, and then a slew of either Vcc, Vss, or not connected.

Of those final 14 control pins:

1 is the clock signal
4 are address byte enablers (for up to 32-bit writes, 1 pin per byte)
4 define the bus cycle definition (what's on the bus)
2 define the bus control operation (when it's ready)
2 define the interrupt and non-maskable interrupt signal
1 is reset

In short, it's an incredibly simple design. The Intel 80386 manuals also
define timing for their 20 MHz to 33 MHz parts. I'm assuming the Am386
would follow similar protocols, though most likely with some leeway on
either side due to their static operation abilities down to 0 MHz.

Edge timing appears to be 4 ns, so that will need slowed as I'm told my
Cyclone V FPGA has sub-ns edge transitions. The rest would seem to fall
within the clock cycle timing, but requires a certain amount of time to
pass before the data on the pins is valid, typically in 20 or less ns,
and often 4, 6, or 7 or more ns.

-----
I have been pleasantly surprised at how simple the design is. My
concerns now turn to voltage and timing protocols, which are pretty
decently outlined in the Intel 80386DX data sheets.

I wish I had could create kind of "monitor board" which I could plug in
to the actual Am386 on its motherboard as a go-between wedged in between
the motherboard socket, and the Am386 CPU, which monitors the signals which
pass through each pin, and in that way continuously sample and record the
timings over various intervals through the monitoring ability.

I could also envision migrating this "study" of the CPU characteristics up
to an 80486 DX, then Pentium, and so on. I may do that if I get an FPGA
with more pins, or chain more of them together. That person on the other
thread (rickman) said there are a few pins which allow programming of an
FPGA, so I could probably create a custom board which chained more than
one together, and then worked in concert for the monitoring.

If only I had resources.

[Rick C. Hodgin]

On Sunday, April 3, 2016 at 9:25:58 AM UTC-4, Rick C. Hodgin wrote:
> I'm planning for future goals, something prayerfully in 2017, and
> I wanted to get some advice. Please remember that my initial goals
> in implementation are not high speed or optimization, but rather are
> in functionality and correctness.
>
> I have been considering using an 80386 motherboard, creating a custom
> cable connection to my Altera FPGA, which will simulate my CPU core in
> a real-world device. I envision the Altera FPGA mounted a few inches
> above the 80386 motherboard, with cables running into the CPU socket.
>
> I have some questions about doing this:
>
> http://image.slidesharecdn.com/salientfeatursof80386-140822084001-phpapp02/95/salient-featurs-of-80386-14-638.jpg?cb=1408709884
> http://www.minuszerodegrees.net/at_clone_bios/ECS-386_32%20motherboard%20of%20revision%201.0.jpg
>
> #1 -- Would it work? :-)
>
> #2 -- The 80386 is a 5V device. What kind of hardware would I need
> to translate Altera's lesser-voltage signals to +/- 5V in the
> cable connection?
>
> #3 -- Would the translation hardware in #2 be sufficient for switching
> at a clock speed of between 4 MHz and 16 MHz?
>
> -----

> In essence, this would be an overdrive processor, one which upgrades
> the CPU on the standard motherboard to use my Arxoda core and ISAs,
> which will allow me to test out the various features I have on a real
> system with real interrupts, etc.
>
> I have been considering the 80386 motherboard because they're relatively
> simple from an electrical signal point of view, and should be easier
> to debug.
>
> Any thoughts or advice is appreciated. Thank you in advance.

Well much to my surprise, I was watching CPU-related videos today and
I came across this video:

https://www.youtube.com/watch?v=y0WEx0Gwk1E&t=4m22s

Beginning around 4:22 it shows the very type of board I was looking to
create to plug in to an existing 80386 system and monitor its signals.

Does anyone have one of these types boards on their shelf from back in
the day?

[Rick C. Hodgin]

On Saturday, April 16, 2016 at 10:57:43 AM UTC-4, Rick C. Hodgin wrote:
> Well much to my surprise, I was watching CPU-related videos today and
> I came across this video:
>
> https://www.youtube.com/watch?v=y0WEx0Gwk1E&t=4m22s
>
> Beginning around 4:22 it shows the very type of board I was looking to
> create to plug in to an existing 80386 system and monitor its signals.
>
> Does anyone have one of these types boards on their shelf from back in
> the day?

On another thread, Herbert Kleebauer posted:

http://www.forcetechnologies.co.uk/news/replacement-for-intel-processors-in-high-reliability-long-life-systems
http://www.forcetechnologies.co.uk/downloads/x86-Processor-Recreation

[Rick C. Hodgin]

I received a quote today from Amanda. She's the sales director of Force
Technologies. Regarding their soft x86 IP core option #2 for an Altera
FPGA (seen here at the bottom of page 2):

http://www.forcetechnologies.co.uk/downloads/x86-Processor-Recreation

She quoted me a ROM price of $250,000, with a lead time of three to six
months.

I wanted to post here and find out if you think this is a valid quote or
not? I replied asking her if they have ever designed an 80386 core before,
and if so have they ever created Altera FPGA project files for that core?
I also asked if this product exists already, and if it has a proven track
record of use?

I would appreciate your thoughts.

[Rick C. Hodgin]

I have received a reply from an application engineer at Force Technologies.
He reported they have not yet designed an 80386, but only an 80186 and
80286.

I have replied that I intend to write an 80386 compatible core using
my Logician tool, which will compile down to Verilog and can be used in
an Altera FPGA project file. I have offered to give them a free IP
license once it is completed so they can have the product, and possibly
pass along savings to other would-be customers.

[Quadibloc]

On Sunday, April 3, 2016 at 7:25:58 AM UTC-6, Rick C. Hodgin wrote:

> #3 -- Would the translation hardware in #2 be sufficient for switching
> at a clock speed of between 4 MHz and 16 MHz?

I doubt you would run into too many problems below about 1 GHz, so at this range
you should be able to easily find suitable translation hardware. The last 5 volt
Pentium ran at 66 MHz, after all.

John Savard

[Rick C. Hodgin]

Would somebody help me with this design? I'd like to create an fpga
"motherboard" for this CPU as indicated above.

I understand the basics on how it will work physically, and logically
it makes perfect sense. It's in the mechanics where I need help.

Would anybody help me?

--
Rick C. Hodgin

[Rick C. Hodgin]

On Friday, November 10, 2017 at 12:04:01 AM UTC-5, Rick C. Hodgin wrote:
> Would somebody help me with this design? I'd like to create an fpga
> "motherboard" for this CPU as indicated above.
>
> I understand the basics on how it will work physically, and logically
> it makes perfect sense. It's in the mechanics where I need help.
>
> Would anybody help me?

To be clear, I'm wanting to use an AMD Am386 and create a simple
FPGA motherboard that has an interface to RAM, and some ROM, so it
will boot, load a fixed program and process data by that program.

--
Rick C. Hodgin