On Monday, April 11, 2016 at 8:44:07 PM UTC-4, Rick C. Hodgin wrote:
> Theo Markettos wrote:
> > ... if Rick needs ~100 IOs there aren't many to play with. Each socket
> > has (if I remember) 34 I/Os and two clock inputs.
> 
> I need 92 GPIO pins.  The remaining 40 are Vcc, Vss, or not connected.

I began studying the 80386 data sheets last night.  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 are 30 address pins, 32
data pins, and either Vcc, Vss, or not connected.

Of those 14 pins:

    1 is the clock signal

    4 are address byte enablers (32-bit writes, 1 pin
      per byte to read 8-bit, 16-bit, 24-bit, or 32-bit)

    4 define the bus cycle definition
    2 defines the bus control operation

    2 define interrupt, non-maskable interrupt

    1 is reset

It is 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.

Edge timing appears to be 4 ns, so that will need slowed.  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.

Best regards,
Rick C. Hodgin

Theo Markettos wrote:
> ... if Rick needs ~100 IOs there aren't many to play with. Each socket
> has (if I remember) 34 I/Os and two clock inputs.

I need 92 GPIO pins.  The remaining 40 are Vcc, Vss, or not connected.

Best regards,
Rick C. Hodgin

rickman wrote:
> I will refrain from posting.

My loss.

Best regards,
Rick C. Hodgin

On 4/11/2016 7:13 PM, Rick C. Hodgin wrote:
> rickman wrote:
>>> I do intend to build a direct coupling board. I could envision also a
>>> second FPGA on it for some purpose. Not sure what that would be, but
>>> I could see it.
>>
>> Lol, if you don't know the purpose, that's not very good vision.
>
> I don't know the purpose because it's your suggestion.  Mine is to
> use my dev board.  It's been my plan all along.  It's why I bought it,
> for my LibSF 386-x40 CPU design.
>
>> Try focusing on the things you can see clearly. Normally a goal is in
>> mind, then the path is selected to reach a number of smaller
>> goals on the way to the main goal.
>
> Ah:
>
>      https://github.com/RickCHodgin/libsf/tree/master/li386/oppie
>      http://www.libsf.org/li386/indexmain.html
>      https://m.facebook.com/groups/726083540851343?view=info
>
>> You seem to be plotting a path without clear objectives.
>
> You seem to see things incorrectly, and always disparaging toward me.

That's the second time you have indicated you don't appreciate my 
comments.  I will refrain from posting.

-- 

Rick

rickman <gnuarm@gmail.com> wrote:
> That's better, but the issue is as much the length as it is how the 
> connection is made.  I suppose there will be many ground connections on 
> all of the sockets?  Signal integrity is key.

Assuming this is the standard Altera/Terasic 40 way pinout, there aren't. 
There's two ground, one 3.3V and one 5V per socket, at roughly 1/3 2/3
positioning.  The rest is GPIO.  You might get away with purposefully
grounding some GPIOs at the other end, but if Rick needs ~100 IOs there
aren't many to play with.  Each socket has (if I remember) 34 I/Os and two
clock inputs.

On the other hand, we get away with driving 40MHz video signals over ribbon
cable with that connector so there is some leeway.  YMMV of course.

Theo

rickman wrote:
> > I do intend to build a direct coupling board. I could envision also a
> > second FPGA on it for some purpose. Not sure what that would be, but
> > I could see it.
>
> Lol, if you don't know the purpose, that's not very good vision.

I don't know the purpose because it's your suggestion.  Mine is to
use my dev board.  It's been my plan all along.  It's why I bought it,
for my LibSF 386-x40 CPU design.

> Try focusing on the things you can see clearly. Normally a goal is in
> mind, then the path is selected to reach a number of smaller
> goals on the way to the main goal.

Ah:

    https://github.com/RickCHodgin/libsf/tree/master/li386/oppie
    http://www.libsf.org/li386/indexmain.html 
    https://m.facebook.com/groups/726083540851343?view=info 

> You seem to be plotting a path without clear objectives.

You seem to see things incorrectly, and always disparaging toward me.

Best regards,
Rick C. Hodgin

On 4/11/2016 5:23 PM, Rick C. Hodgin wrote:
> rickman wrote:
>> The issue is not the clock rate, it is the edge rate. You can configure
>> the FPGA for slower edge rates, but you can't do anything about the
>> 386 edge rates. Running 100+ signal lines over a ribbon cable is just not
>> a good idea unless you use differential signalling. You may get
>> away with it, you may not. Since you are building a custom board
>> anyway, why not just include the FPGA?
>
> The board I intend to build will have three female mates to the
> three male GPIO interface ports on the HSMC adapter card.  It will
> plug straight into it.  No ribbon cables.  Just a direct connection.

That's better, but the issue is as much the length as it is how the 
connection is made.  I suppose there will be many ground connections on 
all of the sockets?  Signal integrity is key.


> As I understand it, the level shifters will introduce a delay, which should
> not be an issue at much slower clock rates.

If you use the quickswitch parts you get less than a nanosecond delay. 
They aren't buffers, they are transmission gates that limit the voltage 
range on the 3.3 volt side.


> I do intend to build a direct coupling board.  I could envision also a
> second FPGA on it for some purpose.  Not sure what that would be, but
> I could see it.

Lol, if you don't know the purpose, that's not very good vision.  Try 
focusing on the things you can see clearly.  Normally a goal is in mind, 
then the path is selected to reach a number of smaller goals on the way 
to the main goal.  You seem to be plotting a path without clear 
objectives.


> BTW, my goals are not to have 30 year old technology, but rather to
> start somewhere.  I am familiar with 386, it is ubiquitous, and it's
> easily extensible.
>
> I look forward to LibSF 386-x40 coming to life.

Good luck.

-- 

Rick

rickman wrote:
> The issue is not the clock rate, it is the edge rate. You can configure
> the FPGA for slower edge rates, but you can't do anything about the
> 386 edge rates. Running 100+ signal lines over a ribbon cable is just not
> a good idea unless you use differential signalling. You may get
> away with it, you may not. Since you are building a custom board
> anyway, why not just include the FPGA?

The board I intend to build will have three female mates to the
three male GPIO interface ports on the HSMC adapter card.  It will
plug straight into it.  No ribbon cables.  Just a direct connection.

As I understand it, the level shifters will introduce a delay, which should
not be an issue at much slower clock rates.

I do intend to build a direct coupling board.  I could envision also a
second FPGA on it for some purpose.  Not sure what that would be, but
I could see it.

BTW, my goals are not to have 30 year old technology, but rather to
start somewhere.  I am familiar with 386, it is ubiquitous, and it's
easily extensible.

I look forward to LibSF 386-x40 coming to life.

Best regards,
Rick C. Hodgin

Rob Gaddi wrote:
> I'm glad all the research effort I put in of looking over at the
> stack of same sitting on the corner of my desk and writing down the
> number from the box came in handy.

Me too! :-)

Nonetheless, and regardless of how trivial the effort was, it got me
exactly what I needed, and it was/is appreciated.

Best regards,
Rick C. Hodgin

On 4/11/2016 2:12 PM, Rick C. Hodgin wrote:
> rickman wrote:
>> I think you are better off not using the FPGA eval board and just
>> making your own board with the 386 and the FPGA. The adapters
>> and cables are going to add a lot of capacitance and noise
>> to your signals. Why mess with the added complexity?
>
> I'll need enough capacity to simulate my ISA, as well as drive the Am386.  They will more or less execute together, with off-device debugging signals to control operations.
>
> Would the capacitance be an issue at a few hundred KHz max?  I plan to make the custom Am386 plug straight in to the three GPIO ports.

You won't have trouble with lines that are essentially data lines, you 
don't care if they ring.  The trouble will be with clock like lines. 
That will include the actual clock and potentially the read/write 
strobes depending on how you implement the interface circuit.

More importantly, you may have trouble with ground bounce.  I've put my 
scope on the far end of disk drive ribbon cables before and the noise on 
the ground can be horrendous.

The issue is not the clock rate, it is the edge rate.  You can configure 
the FPGA for slower edge rates, but you can't do anything about the 386 
edge rates.  Running 100+ signal lines over a ribbon cable is just not a 
good idea unless you use differential signalling.  You may get away with 
it, you may not.  Since you are building a custom board anyway, why not 
just include the FPGA?

The other way to do this is to use a set of bidirectional 
latches/buffers and let the FPGA access the interface via a simple 
serial interface using LVDS signalling.  The FPGA already includes this 
functionallity.  You just need to add a few interface chips to the 386 
board along with your quickswitch devices.

-- 

Rick