Using an FPGA to drive the 80386 CPU on a real motherboard

[rickman]

On 4/6/2016 12:08 PM, Rick C. Hodgin wrote:

On Wednesday, April 6, 2016 at 11:51:16 AM UTC-4, rickman wrote:
On 4/6/2016 8:20 AM, Rick C. Hodgin wrote:
I don't want to spend a lot of time trying to get it to work, but if
I can, it would be really nice to be able to have my CPU side-by-side with
a real-world product, able to test out compatibility.

You should be able to design one board with an FPGA, a 386 socket and a
386 plug which will work for any of the three things you have talked
about doing, emulating the mobo with your FPGA, emulating the 386 with
your FPGA and monitoring the 386 in a real mobo with the FPGA.

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.

If you aren't in a hurry, I can help you with the PCB design. I can use
this as a learning tool to come up to speed with KiCAD which I've been
meaning to do.

I think this sounds like a great solution. I've never programmed an
FPGA outside of the dev board and dev environment (Quartus), so I have
no idea how I'd program the on-board FPGA as you indicate. If it's
possible, your design looks amazing.

How is the FPGA programmed when it's not on a dev board? Is it that
certain pins feed into its programming mechanism, and those would be
wired to a usb port we'd add to the board for that purpose?

MCUs have a various means of programming them which often allow the use
of a simple USB port and a small chip. FPGAs have two ways of
programming... JTAG and a proprietary serial interface, each brand and
sometimes even family of FPGAs are different. The proprietary
interfaces are often very similar, but the programmers are different. I
just buy a cable from the makers and live with that. There are
"universal" cables sold on eBay but I've never tried one so I don't know
how well they work. I should as I have manufacturing needs and only
have one cable with no spares. I should either buy a new cable or try
using one of the universal ones.

If you have an eval board, it may have a chip on board to handle the
programming or it may require a cable. I have an iCEblink40 (Lattice)
eval board that uses USB. Looks like they use an AT90USB2 with custom
programming to bring up the FPGA. I bet other manufacturers do similar
things on their low end boards. If you can get the code you could copy
that, or just tie into the signals and use that programmer with your FPGA.

I like some of the Lattice chips because they have Flash. Once you
program them the programmer is no longer needed. If you are going to
use a RAM configured part you need something to program the FPGA every
time you power it up, so might as well design an MCU programmer onto
your board.

--

Rick

 

[Rick C. Hodgin]

On Wednesday, April 6, 2016 at 4:38:20 PM UTC-4, rickman wrote:

On 4/6/2016 4:19 PM, Rick C. Hodgin wrote:
On Wednesday, April 6, 2016 at 3:00:51 PM UTC-4, Aleksandar Kuktin wrote:
On Wed, 06 Apr 2016 11:51:15 -0400, rickman wrote:

On 4/6/2016 8:20 AM, Rick C. Hodgin wrote:
On Wednesday, April 6, 2016 at 12:35:43 AM UTC-4, rickman wrote:
On 4/5/2016 10:47 PM, Rick C. Hodgin wrote:

Alright ... suppose I target this from another angle. What if I take
the CPU completely off the 80386 motherboard, and create a custom
socket connected to my FPGA, and I provide it with everything it
requires?

This is probably a much better idea.

The reason for that is that I would expect the motherboard manufacturer
probably didn't expect someone would be messing with the onboard clock.
And then they, presumably, didn't design it to handle it. It's enough for
a single component to misbehave at low frequency and the whole thing
would fail.

Doing things the other way around should be easier. I can't imagine the
CPU to be that picky about what it gets from the outside world.

Then again... if the memory controller is embedded in the CPU...

Not on the 386 chips. The first memory controllers which appeared on
x86 CPUs came from AMD and that was on K8 I believe.

You should be able to design one board with an FPGA, a 386 socket and a
386 plug which will work for any of the three things you have talked
about doing, emulating the mobo with your FPGA, emulating the 386 with
your FPGA and monitoring the 386 in a real mobo with the FPGA.

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.

Oh, ok. I was really struggling to figure out how would he mechanically
intercept the signals between the CPU and the motherboard. Although this
design still has me scratching my head about those several hundred pins
that need to be manufactured and installed (by hand?), it's much better
than what I envisioned.

If you two really build such a PCB, would you post the design here? I'd
really like to see how you route all those wires.

The 80386 used a 132-pin socket, of which 40 pins are either not connected
or only carry Vcc or Vss voltages:

http://www.electronicsurplus.com/samtec-ndas-132zsgt-h-connectors-ic-sockets-132-pin-grid-array-package-of-2

The sockets and pinouts are fairly standard, though less common these
days. I could de-solder a connector on one of the motherboards I have
for my particular application. Provided the vias were all in the right
place, it should transfer over and re-solder just fine.

An innocent question: why not intercept the signals running at full
speed, storing them and transmitting them later? You probably wouldn't be
able to record a whole lot of them at once, but you record a bit, power
cycle the CPU, record a bit more, power cycle the CPU, record a bit
more....

That was my first desire. But, once I learned about AMD's Am386's
ability to clock down to even 0 MHz and maintain its internal state
correctly, I began to think it would be easier to examine if it were
running at lower speed.

The clock signal to an 80386 is double-pumped, so a 2 Hz input clock
would cause 1 clock cycle per second.

That jogged a recollection. Once the internal speeds got faster they
added phase locked loops to use a slow external clock and a faster
internal clock. These are no longer compatible with slow clocking.

I believe that occurred on the 80486 and the DX/2, DX/3 (un-released),
and DX/4 models.

The 80387 co-processor has the ability to run dual clocks internally,
which are governed in the range of 14:10 (I believe), but they don't
have to run faster. They can be locked and always run at the same
speed.

Same is true of FPGAs if you use the internal PLL. It will be fairly
simple to generate a variable speed clock to drive the CPU with. Then
the FPGA can either work at that same rate, or resync the interface to a
fast internal clock which does not change rate. It all depends on what
you are doing with the data once you get it and what your other
interfaces are.

I had the idea that I would use the simulated clock output for an input
trigger back into the FPGA for doing all monitoring/sampling.

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

On Wednesday, April 6, 2016 at 5:26:08 PM UTC-4, Jon Elson wrote:

Rick C. Hodgin wrote:



My ultimate goal is to build a completely homemade CPU using my own
garage fab on 3 to 10 micron processes! Once I can get that product
working, then it can be optimized and honed to more modern processes,
with my ultimate goal coming in around those process technologies used
in the late 90s around 500 nm.
OH, MY!!! Call out the men in the white coats! While some people have
actually made transistors and even very SIMPLE ICs at home, when you get
into more complex stuff, it starts to get real hard! Intel's version of the
'386 had 275,000 transistors! Do you have the software tools to simulate
the timing on such a chip? And, of course, all 275,000 of those transistors
have to work!

I occasionally make PC boards in my basement, and I have some professional-
grade machinery to use, such as a laser photoplotter, Kepro dry film
laminator and Kepro etcher. I still have problems with yield, and have to
touch up the boards to make them work. I can't IMAGINE how much harder that
could get with 275,000 transistors on Silicon! Uhhh, maybe you might try to
get a single FF to work, first. How are you going to make the masks? Have
you ever worked with Arsine, DiBorane, Phosphine and similar gases?

I plan to move in stages. I also don't plan on doing it alone. I
presume there will be people at some point who would come on board and
help me manufacture chips, possibly with old fab equipment we could pick
up at that time for the price of scrap metal, and then retool as needed.

I'm not planning on making my own chips before the end of the 2020s.
Until then, I'll use commercial fabs.

These are all part of long-term plans. I'd like to have my first CPU
being shipped to a fab for real manufacturing by July 12, 2022, which I
expect to be around a 90 MHz part.
Ah, well, this is different. Let the fabs deal with the deadly gases, clean
room environment, maks making, etc.

I've been working on projects which make chips through the MOSIS service.
This is NOT cheap, by any means. We use the very old AMI C5N process, now
provided to MOSIS through ON Semi. It is a .5 um process. A small chip we
made was fabbed by them on a multi-project wafer for about $18,000. I doubt
your 80386 would fit in that size. They charge by the square mm. Their
multi-project wafer system combines 20 or more different designs onto one
reticle, and then they dice up the chips for the different users. A larger
project ended up running about $44000, but we got more instances of the chip
for that than the standard order of only 40 chips.

I figured the CPUs I'd make would cost $1,000 each in the early samples,
with an anticipated 50 to 100 CPU minimum, but that if I am able to create
the industry I'm hoping to create (people who are willing to buy CPUs that
are wrought of love, more than high-speed bells and whistles, looking to
them as a utility to augment man's existence, rather than as a whizz bang
eye candy newest fad ("gotta have the $12K iPhone 6 because my $10K iPhone
5 is just so last year") kind of thing).

I want to foster an industry that seeks to re-educate people that there are
needs, and then there are wants, and that people don't need to get the most
expensive, or newest things, to have things that are useful and usable, but
that it's more important for us to work together to help one another, and
to use the skills and resources we have to make better each other's lives,
than to hoard that talent behind a money wall, or an intellectual property
wall, etc.

In short: I want people helping people. I want people loving people. I
wan people being to other people the way people should be to other people,
and not for forced reasons, but for internally realized reasons, as by an
examination of what it truly means to be here in this world alongside all
the other people we're here with in this world.

It's a tremendous gift we've been given, and I want us to recognize that
gift for what it is (and from Who it comes from), and to then live our
lives as we desire to do so, but being subject to that realization, and
all it entails (remembering God who gave us these opportunities, for
example).

I want there to be love in the things we help each other with, rather
than just a pursuit of cold, hard, dispassionate, money, or of some
personally held view of what it means to have power (owning the rights
to some "intellectual property," for example).

It's not a very popular position I'm in pursuit of, but it's one I believe
in whole-heartedly, which is the one at the foundation and core of all of
these efforts I'm involved with (using the unique and special talents and
skills I possess to make other people's lives better, encouraging them to
also use the unique and special talents and skills they possess, to do the
same in the areas of life they're interested in -- I'm interested in CPUs,
in hardware and software, but other people are interested in manufacturing
houses, or bulldozers or whatever. Each of us can look to the people around
us and say within ourselves, "What can I do to make the people's lives
better, rather than the banker's lives better?").

There is real reward in giving, and in loving. There is far less reward
in cashing a fat paycheck. Real love endures. Gifts of real giving endure.
The fat paycheck comes and goes quickly, and leaves little behind which
truly fills any part of our core being.

I want more people to experience that real fulfilling from giving and
loving, and in a true and sincere "nothing to be gained except in the
giving" way.

Hope this makes sense.

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

On Wednesday, April 6, 2016 at 5:45:12 PM UTC-4, Rick C. Hodgin wrote:

I figured the CPUs I'd make would cost $1,000 each in the early samples,
with an anticipated 50 to 100 CPU minimum, but that if I am able to create
the industry I'm hoping to create (people who are willing to buy CPUs that
are wrought of love, more than high-speed bells and whistles, looking to
them as a utility to augment man's existence, rather than as a whizz bang
eye candy newest fad ("gotta have the $12K iPhone 6 because my $10K iPhone
5 is just so last year") kind of thing).

....then the need for larger runs would be there and the price would go down.

Best regards,
Rick C. Hodgin

 

[rickman]

On 4/6/2016 12:45 PM, Rick C. Hodgin wrote:

On Wednesday, April 6, 2016 at 12:38:45 PM UTC-4, rickman wrote:
On 4/6/2016 12:08 PM, Rick C. Hodgin wrote:
On Wednesday, April 6, 2016 at 11:51:16 AM UTC-4, rickman wrote:
On 4/6/2016 8:20 AM, Rick C. Hodgin wrote:
I don't want to spend a lot of time trying to get it to work, but if
I can, it would be really nice to be able to have my CPU side-by-side with
a real-world product, able to test out compatibility.

You should be able to design one board with an FPGA, a 386 socket and a
386 plug which will work for any of the three things you have talked
about doing, emulating the mobo with your FPGA, emulating the 386 with
your FPGA and monitoring the 386 in a real mobo with the FPGA.

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.

If you aren't in a hurry, I can help you with the PCB design. I can use
this as a learning tool to come up to speed with KiCAD which I've been
meaning to do.

I think this sounds like a great solution. I've never programmed an
FPGA outside of the dev board and dev environment (Quartus), so I have
no idea how I'd program the on-board FPGA as you indicate. If it's
possible, your design looks amazing.

How is the FPGA programmed when it's not on a dev board? Is it that
certain pins feed into its programming mechanism, and those would be
wired to a usb port we'd add to the board for that purpose?

MCUs have a various means of programming them which often allow the use
of a simple USB port and a small chip. FPGAs have two ways of
programming... JTAG and a proprietary serial interface, each brand and
sometimes even family of FPGAs are different. The proprietary
interfaces are often very similar, but the programmers are different. I
just buy a cable from the makers and live with that. There are
"universal" cables sold on eBay but I've never tried one so I don't know
how well they work. I should as I have manufacturing needs and only
have one cable with no spares. I should either buy a new cable or try
using one of the universal ones.

If you have an eval board, it may have a chip on board to handle the
programming or it may require a cable. I have an iCEblink40 (Lattice)
eval board that uses USB. Looks like they use an AT90USB2 with custom
programming to bring up the FPGA. I bet other manufacturers do similar
things on their low end boards. If you can get the code you could copy
that, or just tie into the signals and use that programmer with your FPGA.

I like some of the Lattice chips because they have Flash. Once you
program them the programmer is no longer needed. If you are going to
use a RAM configured part you need something to program the FPGA every
time you power it up, so might as well design an MCU programmer onto
your board.

I think I asked you this before in 2014?? Do you live anywhere near
Indiana? I would be willing to drive out and spend a weekend with
you sometime on this project, listening and learning, seeing and
experiencing. I'd even be willing to buy you lunch for it.

I am in Maryland, VA and WV near Charlestown. I do a lot of my
electronic thinking in VA. I asked google how far it is to Indiana and
it said 630 miles to an arbitrary point north of Indianapolis.

I doubt a trip is really necessary. We can exchange emails. gnuarm dot
2007 at arius dot com

--

Rick

 

[rickman]

On 4/6/2016 1:37 PM, Rick C. Hodgin wrote:

On Wednesday, April 6, 2016 at 12:38:45 PM UTC-4, rickman wrote:
If you have an eval board, it may have a chip on board to handle the
programming or it may require a cable. I have an iCEblink40 (Lattice)
eval board that uses USB. Looks like they use an AT90USB2 with custom
programming to bring up the FPGA.

Is it this one?

http://www.digikey.com/product-detail/en/ICE40HX1K-BLINK-EVN/220-1581-ND/3198285

I have a similar one with the iCE40LP1K chip which is lower power and
less speed.

--

Rick

 

[rickman]

On 4/6/2016 1:37 PM, Rick C. Hodgin wrote:

On Wednesday, April 6, 2016 at 12:38:45 PM UTC-4, rickman wrote:
If you have an eval board, it may have a chip on board to handle the
programming or it may require a cable. I have an iCEblink40 (Lattice)
eval board that uses USB. Looks like they use an AT90USB2 with custom
programming to bring up the FPGA.

Is it this one?

http://www.digikey.com/product-detail/en/ICE40HX1K-BLINK-EVN/220-1581-ND/3198285

I started a thread in comp.arch.embedded about PCB makers. You may also
need assembly help too. Many FPGAs are BGA which can be tricky to
assemble at home.

--

Rick

 

[rickman]

On 4/6/2016 3:00 PM, Aleksandar Kuktin wrote:

On Wed, 06 Apr 2016 11:51:15 -0400, rickman wrote:

On 4/6/2016 8:20 AM, Rick C. Hodgin wrote:
On Wednesday, April 6, 2016 at 12:35:43 AM UTC-4, rickman wrote:
On 4/5/2016 10:47 PM, Rick C. Hodgin wrote:

Alright ... suppose I target this from another angle. What if I take
the CPU completely off the 80386 motherboard, and create a custom
socket connected to my FPGA, and I provide it with everything it
requires?

This is probably a much better idea.

The reason for that is that I would expect the motherboard manufacturer
probably didn't expect someone would be messing with the onboard clock.
And then they, presumably, didn't design it to handle it. It's enough for
a single component to misbehave at low frequency and the whole thing
would fail.

Doing things the other way around should be easier. I can't imagine the
CPU to be that picky about what it gets from the outside world.

Then again... if the memory controller is embedded in the CPU...

You need to go much further back in time to an era where CPUs were just
CPUs and *everything* had to be done by the motherboard. The CPU has a
simple bus and doesn't actually know about your memory. But you are
right that the mobo may not be happy clocked at 2 Hz.

You should be able to design one board with an FPGA, a 386 socket and a
386 plug which will work for any of the three things you have talked
about doing, emulating the mobo with your FPGA, emulating the 386 with
your FPGA and monitoring the 386 in a real mobo with the FPGA.

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.

Oh, ok. I was really struggling to figure out how would he mechanically
intercept the signals between the CPU and the motherboard. Although this
design still has me scratching my head about those several hundred pins
that need to be manufactured and installed (by hand?), it's much better
than what I envisioned.

Check again. I think Rick Hodgin posted the exact count at some point,
but it is not hundreds of pins. Also, they are on 0.1 inch centers (pin
grid array, right?) so you can use easy to find machined pin strips.
0.24 square posts won't cut it, but the smaller diameter pins are
available too.

If you two really build such a PCB, would you post the design here? I'd
really like to see how you route all those wires.


An innocent question: why not intercept the signals running at full
speed, storing them and transmitting them later? You probably wouldn't be
able to record a whole lot of them at once, but you record a bit, power
cycle the CPU, record a bit more, power cycle the CPU, record a bit
more....

Reminds me of how they used to do hardware emulation in combination with
simulation. The simulator would run one cycle and then stimulate the
hardware to get the result. This would be factored into the simulation
and the next cycle would run. The hardware would then be rebooted and
two cycles of stimulus would be applied and the result captured.
Lather, rinse, repeat ad nauseam.

--

Rick

 

[rickman]

On 4/6/2016 4:19 PM, Rick C. Hodgin wrote:

On Wednesday, April 6, 2016 at 3:00:51 PM UTC-4, Aleksandar Kuktin wrote:
On Wed, 06 Apr 2016 11:51:15 -0400, rickman wrote:

On 4/6/2016 8:20 AM, Rick C. Hodgin wrote:
On Wednesday, April 6, 2016 at 12:35:43 AM UTC-4, rickman wrote:
On 4/5/2016 10:47 PM, Rick C. Hodgin wrote:

Alright ... suppose I target this from another angle. What if I take
the CPU completely off the 80386 motherboard, and create a custom
socket connected to my FPGA, and I provide it with everything it
requires?

This is probably a much better idea.

The reason for that is that I would expect the motherboard manufacturer
probably didn't expect someone would be messing with the onboard clock.
And then they, presumably, didn't design it to handle it. It's enough for
a single component to misbehave at low frequency and the whole thing
would fail.

Doing things the other way around should be easier. I can't imagine the
CPU to be that picky about what it gets from the outside world.

Then again... if the memory controller is embedded in the CPU...

Not on the 386 chips. The first memory controllers which appeared on
x86 CPUs came from AMD and that was on K8 I believe.

You should be able to design one board with an FPGA, a 386 socket and a
386 plug which will work for any of the three things you have talked
about doing, emulating the mobo with your FPGA, emulating the 386 with
your FPGA and monitoring the 386 in a real mobo with the FPGA.

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.

Oh, ok. I was really struggling to figure out how would he mechanically
intercept the signals between the CPU and the motherboard. Although this
design still has me scratching my head about those several hundred pins
that need to be manufactured and installed (by hand?), it's much better
than what I envisioned.

If you two really build such a PCB, would you post the design here? I'd
really like to see how you route all those wires.

The 80386 used a 132-pin socket, of which 40 pins are either not connected
or only carry Vcc or Vss voltages:

http://www.electronicsurplus.com/samtec-ndas-132zsgt-h-connectors-ic-sockets-132-pin-grid-array-package-of-2

The sockets and pinouts are fairly standard, though less common these
days. I could de-solder a connector on one of the motherboards I have
for my particular application. Provided the vias were all in the right
place, it should transfer over and re-solder just fine.

An innocent question: why not intercept the signals running at full
speed, storing them and transmitting them later? You probably wouldn't be
able to record a whole lot of them at once, but you record a bit, power
cycle the CPU, record a bit more, power cycle the CPU, record a bit
more....

That was my first desire. But, once I learned about AMD's Am386's
ability to clock down to even 0 MHz and maintain its internal state
correctly, I began to think it would be easier to examine if it were
running at lower speed.

The clock signal to an 80386 is double-pumped, so a 2 Hz input clock
would cause 1 clock cycle per second.

That jogged a recollection. Once the internal speeds got faster they
added phase locked loops to use a slow external clock and a faster
internal clock. These are no longer compatible with slow clocking.

Same is true of FPGAs if you use the internal PLL. It will be fairly
simple to generate a variable speed clock to drive the CPU with. Then
the FPGA can either work at that same rate, or resync the interface to a
fast internal clock which does not change rate. It all depends on what
you are doing with the data once you get it and what your other
interfaces are.

--

Rick

 

[Jon Elson]

rickman wrote:

I like some of the Lattice chips because they have Flash. Once you
program them the programmer is no longer needed. If you are going to
use a RAM configured part you need something to program the FPGA every
time you power it up, so might as well design an MCU programmer onto
your board.

Xilinx also has he Spartan 3AN (N for non-volatile). For a couple extra
bucks, you can get get the flash memory built in. Otherwise, their Spartan
3 family will download from a fariety of serial PROMS with no additional
circuitry. I've been using SST serial EPROMS for some time, they are
something like $0.80 which seems pretty amazing. They don't make them in
DIP, however, so I have to make a little board about fingernail size so I
can plug them in to the board.

Jon

 

[Jon Elson]

Rick C. Hodgin wrote:

My ultimate goal is to build a completely homemade CPU using my own
garage fab on 3 to 10 micron processes! Once I can get that product
working, then it can be optimized and honed to more modern processes,
with my ultimate goal coming in around those process technologies used
in the late 90s around 500 nm.

OH, MY!!! Call out the men in the white coats! While some people have
actually made transistors and even very SIMPLE ICs at home, when you get
into more complex stuff, it starts to get real hard! Intel's version of the
'386 had 275,000 transistors! Do you have the software tools to simulate
the timing on such a chip? And, of course, all 275,000 of those transistors
have to work!

I occasionally make PC boards in my basement, and I have some professional-
grade machinery to use, such as a laser photoplotter, Kepro dry film
laminator and Kepro etcher. I still have problems with yield, and have to
touch up the boards to make them work. I can't IMAGINE how much harder that
could get with 275,000 transistors on Silicon! Uhhh, maybe you might try to
get a single FF to work, first. How are you going to make the masks? Have
you ever worked with Arsine, DiBorane, Phosphine and similar gases?

These are all part of long-term plans. I'd like to have my first CPU
being shipped to a fab for real manufacturing by July 12, 2022, which I
expect to be around a 90 MHz part.

Ah, well, this is different. Let the fabs deal with the deadly gases, clean
room environment, maks making, etc.

I've been working on projects which make chips through the MOSIS service.
This is NOT cheap, by any means. We use the very old AMI C5N process, now
provided to MOSIS through ON Semi. It is a .5 um process. A small chip we
made was fabbed by them on a multi-project wafer for about $18,000. I doubt
your 80386 would fit in that size. They charge by the square mm. Their
multi-project wafer system combines 20 or more different designs onto one
reticle, and then they dice up the chips for the different users. A larger
project ended up running about $44000, but we got more instances of the chip
for that than the standard order of only 40 chips.

Jon

 

[Jon Elson]

Rick C. Hodgin wrote:

I figured the CPUs I'd make would cost $1,000 each in the early samples,

OK, the MOSIS standard order is for 40 parts. So, that's $40K each
revision. Unless you are truly brilliant, it is going to take a BUNCH of
respins of the part to get anything working.

with an anticipated 50 to 100 CPU minimum, but that if I am able to create
the industry I'm hoping to create (people who are willing to buy CPUs that
are wrought of love, more than high-speed bells and whistles, looking to
them as a utility to augment man's existence, rather than as a whizz bang
eye candy newest fad ("gotta have the $12K iPhone 6 because my $10K iPhone
5 is just so last year") kind of thing).

Uhhh, I can imagine there will be at LEAST 5 customers for this. How many
shirts do you have? Because you are certainly going to lose your shirt on
this project!

Jon

 

[rickman]

On 4/6/2016 5:05 PM, Jon Elson wrote:

rickman wrote:


I like some of the Lattice chips because they have Flash. Once you
program them the programmer is no longer needed. If you are going to
use a RAM configured part you need something to program the FPGA every
time you power it up, so might as well design an MCU programmer onto
your board.

Xilinx also has he Spartan 3AN (N for non-volatile). For a couple extra
bucks, you can get get the flash memory built in. Otherwise, their Spartan
3 family will download from a fariety of serial PROMS with no additional
circuitry. I've been using SST serial EPROMS for some time, they are
something like $0.80 which seems pretty amazing. They don't make them in
DIP, however, so I have to make a little board about fingernail size so I
can plug them in to the board.

Serial flash parts use extra board space and are a PITA to design in so
you can program on the board. The serial configuration of Xilinx parts
is also rather slow in comparison to the boot time of a internal flash
FPGA. I believe it is something like two orders of magnitude faster.
The Spartan 3AN is a bit of a joke in some respects, but if you are
using Xilinx parts I guess that is what you get. If it were a good
idea, why do they only do that on the 10 year old Spartan 3A line?

--

Rick

 

[rickman]

On 4/6/2016 4:41 PM, Rick C. Hodgin wrote:

On Wednesday, April 6, 2016 at 4:38:20 PM UTC-4, rickman wrote:
On 4/6/2016 4:19 PM, Rick C. Hodgin wrote:
On Wednesday, April 6, 2016 at 3:00:51 PM UTC-4, Aleksandar Kuktin wrote:
On Wed, 06 Apr 2016 11:51:15 -0400, rickman wrote:

On 4/6/2016 8:20 AM, Rick C. Hodgin wrote:
On Wednesday, April 6, 2016 at 12:35:43 AM UTC-4, rickman wrote:
On 4/5/2016 10:47 PM, Rick C. Hodgin wrote:

Alright ... suppose I target this from another angle. What if I take
the CPU completely off the 80386 motherboard, and create a custom
socket connected to my FPGA, and I provide it with everything it
requires?

This is probably a much better idea.

The reason for that is that I would expect the motherboard manufacturer
probably didn't expect someone would be messing with the onboard clock.
And then they, presumably, didn't design it to handle it. It's enough for
a single component to misbehave at low frequency and the whole thing
would fail.

Doing things the other way around should be easier. I can't imagine the
CPU to be that picky about what it gets from the outside world.

Then again... if the memory controller is embedded in the CPU...

Not on the 386 chips. The first memory controllers which appeared on
x86 CPUs came from AMD and that was on K8 I believe.

You should be able to design one board with an FPGA, a 386 socket and a
386 plug which will work for any of the three things you have talked
about doing, emulating the mobo with your FPGA, emulating the 386 with
your FPGA and monitoring the 386 in a real mobo with the FPGA.

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.

Oh, ok. I was really struggling to figure out how would he mechanically
intercept the signals between the CPU and the motherboard. Although this
design still has me scratching my head about those several hundred pins
that need to be manufactured and installed (by hand?), it's much better
than what I envisioned.

If you two really build such a PCB, would you post the design here? I'd
really like to see how you route all those wires.

The 80386 used a 132-pin socket, of which 40 pins are either not connected
or only carry Vcc or Vss voltages:

http://www.electronicsurplus.com/samtec-ndas-132zsgt-h-connectors-ic-sockets-132-pin-grid-array-package-of-2

The sockets and pinouts are fairly standard, though less common these
days. I could de-solder a connector on one of the motherboards I have
for my particular application. Provided the vias were all in the right
place, it should transfer over and re-solder just fine.

An innocent question: why not intercept the signals running at full
speed, storing them and transmitting them later? You probably wouldn't be
able to record a whole lot of them at once, but you record a bit, power
cycle the CPU, record a bit more, power cycle the CPU, record a bit
more....

That was my first desire. But, once I learned about AMD's Am386's
ability to clock down to even 0 MHz and maintain its internal state
correctly, I began to think it would be easier to examine if it were
running at lower speed.

The clock signal to an 80386 is double-pumped, so a 2 Hz input clock
would cause 1 clock cycle per second.

That jogged a recollection. Once the internal speeds got faster they
added phase locked loops to use a slow external clock and a faster
internal clock. These are no longer compatible with slow clocking.

I believe that occurred on the 80486 and the DX/2, DX/3 (un-released),
and DX/4 models.

The 80387 co-processor has the ability to run dual clocks internally,
which are governed in the range of 14:10 (I believe), but they don't
have to run faster. They can be locked and always run at the same
speed.

Same is true of FPGAs if you use the internal PLL. It will be fairly
simple to generate a variable speed clock to drive the CPU with. Then
the FPGA can either work at that same rate, or resync the interface to a
fast internal clock which does not change rate. It all depends on what
you are doing with the data once you get it and what your other
interfaces are.

I had the idea that I would use the simulated clock output for an input
trigger back into the FPGA for doing all monitoring/sampling.

If you are plugged into the mobo, I don't think you can source the
clock. That would work ok if the FPGA is emulating the mobo.

--

Rick

 

[rickman]

On 4/6/2016 4:38 PM, Rick C. Hodgin wrote:

On Wednesday, April 6, 2016 at 3:07:55 PM UTC-4, Aleksandar Kuktin wrote:
On Tue, 05 Apr 2016 12:15:35 -0700, Rick C. Hodgin wrote:

I have a desire to create an 80386 CPU in FPGA form, one which will plug
in to the 132-pin socket of existing 80386 motherboard as a replacement
CPU.

Okay, so I'm not the only one who's into slow system design.

I am not objected to having it go faster, but the faster it goes the
most expensive it is.

Okay, are you sitting down? Here goes...

My ultimate goal is to build a completely homemade CPU using my own
garage fab on 3 to 10 micron processes! Once I can get that product
working, then it can be optimized and honed to more modern processes,
with my ultimate goal coming in around those process technologies used
in the late 90s around 500 nm.

I want to be able to provide the features of the 80386 on that
machine, but through my FPGA, to then allow me to extend the ISA to
include other instructions and abilities.

I have to ask: why spend time hacking x86 when there are so many other,
BETTER architectures out there?

I have a long history on 80386. I wrote my own kernel, debuggers, etc.
It's been a relationship dating back to the late 80s.

However, one of the reasons I'm doing this is because I am extending
the ISA out to include 40-bit addresses, rather than just 32-bit,
which accesses memory in the Terabyte range, and to include a built-in
ARM ISA which allows the CPU to switch between ISAs based on branch
instructions.

Also, why are you doing this? Is this a hobby? Work related? Starting a
new bussiness? Want to design and implement a NSA-proof PC?

To be honest, I am a Christian, and I want to use the talents I was gifted
with and give the fruit of my labor back to God, and to my fellow man (and
not a pursuit of money, or proprietary IP, or patents, or other such things,
but rather an expression of love basically in giving back).

How would this accomplish that, the benefit to God or man?

Does anybody have an experience or advice in creating an FPGA-based CPU
that connects to a real hardware device and simulates the real device's
abilities?

Does simulation count?

Yes. Also in emulation, as by a real FPGA product, but one which does not
plug into a socket, but is its own entire creation. Here's an Aleksander
who created a 486 SX CPU (it has not integrated FPU):

https://github.com/alfikpl/ao486

My goals are part of a project I'm working on called LibSF 386-x40, which
is a 40-bit extension to the 80386, and 32-bit ARM. I use a WEX register
model which extends the 32-bit registers to 40-bit registers:

https://github.com/RickCHodgin/libsf/blob/master/li386/li386-documentation/images/wex_register_mapping.png

However, in the past couple weeks I've had the idea of a pointer selector,
which operates like a segment selector, but on a specific pointer register.
When enabled, it loads an extra 8-bits into the segment register associated
with specific register, such that it then is able to reference a 4GB window
of memory within the 1 TB address space:

https://groups.google.com/d/msg/comp.arch/bcpb03mL0o0/xUBzCXDmBgAJ

These are all part of long-term plans. I'd like to have my first CPU being
shipped to a fab for real manufacturing by July 12, 2022, which I expect to
be around a 90 MHz part.

So in 2022 this will rival the $5 ARM MCU devices currently available?

--

Rick

 

[rickman]

On 4/6/2016 11:40 PM, Jon Elson wrote:

Rick C. Hodgin wrote:



I figured the CPUs I'd make would cost $1,000 each in the early samples,
OK, the MOSIS standard order is for 40 parts. So, that's $40K each
revision. Unless you are truly brilliant, it is going to take a BUNCH of
respins of the part to get anything working.
with an anticipated 50 to 100 CPU minimum, but that if I am able to create
the industry I'm hoping to create (people who are willing to buy CPUs that
are wrought of love, more than high-speed bells and whistles, looking to
them as a utility to augment man's existence, rather than as a whizz bang
eye candy newest fad ("gotta have the $12K iPhone 6 because my $10K iPhone
5 is just so last year") kind of thing).

Uhhh, I can imagine there will be at LEAST 5 customers for this. How many
shirts do you have? Because you are certainly going to lose your shirt on
this project!

I think Rick H doesn't understand that electronics works exactly the way
it does because it allows the industry to provide $25 cell phones to
those who *need* them rather than the $400 latest eye candy phones to
those who want them. (I don't know of any $12,000 phones) In some ways
the $400 phones subsidize the cheap phones, but not in a serious way.
The expensive phones just drive the "bleeding edge" market since that
always costs more initially. Then once the high initial costs are
amortized, the rest of us get the benefit of the technology at the
sustained product rate.

Producing a CPU chip with no real market in an antique technology will
not help anyone, man or God.

This project *is* starting to sound familiar now.

--

Rick

 

[rickman]

On 4/6/2016 4:38 PM, Rick C. Hodgin wrote:

On Wednesday, April 6, 2016 at 3:07:55 PM UTC-4, Aleksandar Kuktin wrote:

Also, why are you doing this? Is this a hobby? Work related? Starting a
new bussiness? Want to design and implement a NSA-proof PC?

To be honest, I am a Christian, and I want to use the talents I was gifted
with and give the fruit of my labor back to God, and to my fellow man (and
not a pursuit of money, or proprietary IP, or patents, or other such things,
but rather an expression of love basically in giving back).

This jogged a memory of a joke I was told at work when I worked on an
IRAD project that was being graded by the government. The government
format for the write up had a few sections and two were the GOAL and the
PURPOSE. Everyone was confused about the difference in the two. So
Fred wrote his report and said his goal was to measure some parameter
and his purpose was to prove the parameter met some requirements. His
boss read his report and said, "No, your goal is to prove the parameter
met the requirements so what is your purpose?". He worked on it again
saying his purpose was to show the unit X would work in system Y. It
was reviewed by his second level boss who said, "No, your goal is to
prove unit X works in system Y, what is your purpose?"

This happened a couple more times until his report got through all the
reviewers and he presented his report to a meeting. He started out
saying... "My purpose is to get into heaven".

--

Rick

 

[Rick C. Hodgin]

On Wednesday, April 6, 2016 at 11:40:35 PM UTC-4, Jon Elson wrote:

Rick C. Hodgin wrote:



I figured the CPUs I'd make would cost $1,000 each in the early samples,
OK, the MOSIS standard order is for 40 parts. So, that's $40K each
revision. Unless you are truly brilliant, it is going to take a BUNCH of
respins of the part to get anything working.

I can't remember who it was I searched a while back (2014 I think), but
I found a company that was manufacturing on 250nm and 500nm process
technologies. The mask sets were $15K each, and each run varied, but
the total cost for 100 parts was less than $100K including masks.

with an anticipated 50 to 100 CPU minimum, but that if I am able to create
the industry I'm hoping to create (people who are willing to buy CPUs that
are wrought of love, more than high-speed bells and whistles, looking to
them as a utility to augment man's existence, rather than as a whizz bang
eye candy newest fad ("gotta have the $12K iPhone 6 because my $10K iPhone
5 is just so last year") kind of thing).

Uhhh, I can imagine there will be at LEAST 5 customers for this. How many
shirts do you have? Because you are certainly going to lose your shirt on
this project!

Well, it's not a goal. It's not being done for money. I would like to have
assistance from those who are willing to give. I also don't intend on being
the only one who works on it. I intend others who are experts in this field
will come forward and help out. And if not, then I will do my best.

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

On Thursday, April 7, 2016 at 2:42:24 AM UTC-4, rickman wrote:

On 4/6/2016 4:41 PM, Rick C. Hodgin wrote:
On Wednesday, April 6, 2016 at 4:38:20 PM UTC-4, rickman wrote:
On 4/6/2016 4:19 PM, Rick C. Hodgin wrote:
On Wednesday, April 6, 2016 at 3:00:51 PM UTC-4, Aleksandar Kuktin wrote:
On Wed, 06 Apr 2016 11:51:15 -0400, rickman wrote:

On 4/6/2016 8:20 AM, Rick C. Hodgin wrote:
On Wednesday, April 6, 2016 at 12:35:43 AM UTC-4, rickman wrote:
On 4/5/2016 10:47 PM, Rick C. Hodgin wrote:

Alright ... suppose I target this from another angle. What if I take
the CPU completely off the 80386 motherboard, and create a custom
socket connected to my FPGA, and I provide it with everything it
requires?

This is probably a much better idea.

The reason for that is that I would expect the motherboard manufacturer
probably didn't expect someone would be messing with the onboard clock.
And then they, presumably, didn't design it to handle it. It's enough for
a single component to misbehave at low frequency and the whole thing
would fail.

Doing things the other way around should be easier. I can't imagine the
CPU to be that picky about what it gets from the outside world.

Then again... if the memory controller is embedded in the CPU...

Not on the 386 chips. The first memory controllers which appeared on
x86 CPUs came from AMD and that was on K8 I believe.

You should be able to design one board with an FPGA, a 386 socket and a
386 plug which will work for any of the three things you have talked
about doing, emulating the mobo with your FPGA, emulating the 386 with
your FPGA and monitoring the 386 in a real mobo with the FPGA.

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.

Oh, ok. I was really struggling to figure out how would he mechanically
intercept the signals between the CPU and the motherboard. Although this
design still has me scratching my head about those several hundred pins
that need to be manufactured and installed (by hand?), it's much better
than what I envisioned.

If you two really build such a PCB, would you post the design here? I'd
really like to see how you route all those wires.

The 80386 used a 132-pin socket, of which 40 pins are either not connected
or only carry Vcc or Vss voltages:

http://www.electronicsurplus.com/samtec-ndas-132zsgt-h-connectors-ic-sockets-132-pin-grid-array-package-of-2

The sockets and pinouts are fairly standard, though less common these
days. I could de-solder a connector on one of the motherboards I have
for my particular application. Provided the vias were all in the right
place, it should transfer over and re-solder just fine.

An innocent question: why not intercept the signals running at full
speed, storing them and transmitting them later? You probably wouldn't be
able to record a whole lot of them at once, but you record a bit, power
cycle the CPU, record a bit more, power cycle the CPU, record a bit
more....

That was my first desire. But, once I learned about AMD's Am386's
ability to clock down to even 0 MHz and maintain its internal state
correctly, I began to think it would be easier to examine if it were
running at lower speed.

The clock signal to an 80386 is double-pumped, so a 2 Hz input clock
would cause 1 clock cycle per second.

That jogged a recollection. Once the internal speeds got faster they
added phase locked loops to use a slow external clock and a faster
internal clock. These are no longer compatible with slow clocking.

I believe that occurred on the 80486 and the DX/2, DX/3 (un-released),
and DX/4 models.

The 80387 co-processor has the ability to run dual clocks internally,
which are governed in the range of 14:10 (I believe), but they don't
have to run faster. They can be locked and always run at the same
speed.

Same is true of FPGAs if you use the internal PLL. It will be fairly
simple to generate a variable speed clock to drive the CPU with. Then
the FPGA can either work at that same rate, or resync the interface to a
fast internal clock which does not change rate. It all depends on what
you are doing with the data once you get it and what your other
interfaces are.

I had the idea that I would use the simulated clock output for an input
trigger back into the FPGA for doing all monitoring/sampling.

If you are plugged into the mobo, I don't think you can source the
clock. That would work ok if the FPGA is emulating the mobo.

Correct. I don't plan on connecting to the motherboard though until I get
the entire ISA working. And even then it will be a minimal research effort
such that if I can't get it working in a week or two, then I'll move on to
the next thing.

After hearing all of the difficulties I may have on the motherboard side,
the re-grouping of just working with the Am386 CPU makes a lot more sense.
Plus, it actually accomplishes nearly all of my goals as my goals were to
replace the CPU's instruction set with my own, and to validate it 1:1 that
I am correct. By having a side-by-side comparison I can do that. And as
I've stated, it might even be interesting to try to get other 80386-clone
CPUs to test out side-by-side in the configuration, and then write a
paper outlining where they are different. But, that's the lowest possible
goal, just a "wouldn't it be interesting" thought.

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

On Thursday, April 7, 2016 at 2:46:51 AM UTC-4, rickman wrote:

On 4/6/2016 4:38 PM, Rick C. Hodgin wrote:
On Wednesday, April 6, 2016 at 3:07:55 PM UTC-4, Aleksandar Kuktin wrote:
Also, why are you doing this? Is this a hobby? Work related? Starting a
new bussiness? Want to design and implement a NSA-proof PC?

To be honest, I am a Christian, and I want to use the talents I was gifted
with and give the fruit of my labor back to God, and to my fellow man (and
not a pursuit of money, or proprietary IP, or patents, or other such things,
but rather an expression of love basically in giving back).

How would this accomplish that, the benefit to God or man?

Well, it's difficult to describe to many people. To date, only a small
handful have seen any value in the idea whatsoever ... but, some do see
the value and I am one of them.

It comes down to our fundamental reason for being alive in this world.
Am I a self-made man with all of my abilities being my abilities? Or do
I acknowledge that I was gifted with those abilities by God, and then do
I hold God in that place in my life ahead of all things?

I am not rich. I am not strong. I am not many things. What I am though
He has gifted me with. I happen to have an interest in these areas and,
despite not having a formal education, have discovered over time that
these things just make sense to me and I'm able to maneuver in them with
little difficulty. They are also a great interest to me.

So, I refocus the purposes of my life from within that knowledge and
understanding: I was created by God. God had a purpose in creating me.
I desire to do these things in my life, so I will do them for God. And
if God has another purpose for me in my life, then as I am walking on
this path, He will put up obstacles and roadblocks to move me from this
direction to some other direction, which is the one He truly wanted me
to be on.

So long as I'm moving, and doing so for Him, I'm walking as I should.
And for me, it's in this industry (hardware, and software). But for
others walking similarly in their line of work, it would be in whatever
they do, using whatever skills they possess.

-----
It's an endeavor I've been working on since July 12, 2012, when I had
instead started heading down a path of doing what I'm doing now on
this project, except for GNU and the FSF. However, just before I began,
I found out some things about Richard Stallman that were very disturbing
to me, and I resolved within myself that I could not work for that
entity, contributing to its growth or prosperity because its very
foundations were wrought of a man whose viewpoints on several things are
not only against God, but against most people's assessment of what is
true right and true wrong.

So, instead of the Free Software Foundation, I created the Liberty
Software Foundation, and dedicated all of my work to honoring God. I
have given the labor I possess on these projects away, so that others
might benefit from them. I have done my best on this project, and not
many others have seen benefit in my work, and I've observed a similar
reaction to my efforts as I see here, where people initially are very
interested in helping, but once they see any kind of an association with
God, or doing work for God, there is a recoil, and a pulling away. Of
course it makes me sad because I desire to create these hardware and
software products, and I desire to receive help from others, but I also
desire to do it in a way which gives God the credit (glory, honor, praise)
for what He first did in me, giving me the abilities to do any of these
things in the first place, and in all who participate as well.

In essence, my heart cries out to God in acknowledgement of who He is,
what He has done, and I recognize why we are here in our various short-
comings, ineptitudes, strengths, and abilities: to help one another.

We are here to compensate for one another's weaknesses, to be strong in
areas they're weak, and have others be strong in the areas we're weak.
And in these areas of hardware and software design, I would very much
like to have a part running at 4 GHz or faster, but I cannot do that
alone. My goals are more modest, though my hope remains that I will
not only have a part running at 4 GHz, but rather that God will shine
the light of knowledge and understanding in these areas of physics and
allow a part to be created which operates at 100 GHz or faster, and
does so on less power, less heat, etc.

I am confident in my relationship with God, and with who God is, so I
seek to do the things I do in my life for Him. I do this in my work, my
hardware and software pursuits, in my family relationships, in the
relationships I have/attempt with friends, etc. I make Him part of my
life, and explicitly the biggest part, and the part out front of the
things I do, and I do this because of who He is, who I am, and what He's
given me here in this world.

Bottom line: I am not a self-made man. I need His help, guidance, and
that of those around me. But I know that together, in acknowledgement
of Him, there is nothing we cannot accomplish.

Does anybody have an experience or advice in creating an FPGA-based CPU
that connects to a real hardware device and simulates the real device's
abilities?

Does simulation count?

Yes. Also in emulation, as by a real FPGA product, but one which does not
plug into a socket, but is its own entire creation. Here's an Aleksander
who created a 486 SX CPU (it has not integrated FPU):

https://github.com/alfikpl/ao486

My goals are part of a project I'm working on called LibSF 386-x40, which
is a 40-bit extension to the 80386, and 32-bit ARM. I use a WEX register
model which extends the 32-bit registers to 40-bit registers:

https://github.com/RickCHodgin/libsf/blob/master/li386/li386-documentation/images/wex_register_mapping.png

However, in the past couple weeks I've had the idea of a pointer selector,
which operates like a segment selector, but on a specific pointer register.
When enabled, it loads an extra 8-bits into the segment register associated
with specific register, such that it then is able to reference a 4GB window
of memory within the 1 TB address space:

https://groups.google.com/d/msg/comp.arch/bcpb03mL0o0/xUBzCXDmBgAJ

These are all part of long-term plans. I'd like to have my first CPU being
shipped to a fab for real manufacturing by July 12, 2022, which I expect to
be around a 90 MHz part.

So in 2022 this will rival the $5 ARM MCU devices currently available?

The part I have planned today won't. But if more people come together,
we can together create something that will exceed it. It just takes the
willingness from within to work together, and the guidance of God guiding
our hearts and minds in the right direction, for He is truth, and this
universe is His creation. If there is anyone who can guide us on the
direction we should go, it's Him. And I place my faith, hope, and trust
in Him because of who He is.

That being said, that doesn't mean I don't want to work with you on this
project. You have exhibited incredible kindness, and I have been moved
by it. I have these desires to pursue these hardware ends, and nothing
about that has changed. The only thing that's different now than it was
yesterday or the day before, is that now you know that I am desiring to
do this as an effort given over to God, in honoring Him with the fruits
of my life. I hope this won't be a stumbling block. I find your generosity
of spirit refreshing, and your knowledge and experience desirable assets
that you are willing to share so freely. It's made me happy actually.

Best regards,
Rick C. Hodgin