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 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. :) 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....
Using an FPGA to drive the 80386 CPU on a real motherboard
Started by ●April 5, 2016
Reply by ●April 6, 20162016-04-06
Reply by ●April 6, 20162016-04-06
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 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? :) 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?> 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? :D
Reply by ●April 6, 20162016-04-06
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
Reply by ●April 6, 20162016-04-06
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. Best regards, Rick C. Hodgin
Reply by ●April 6, 20162016-04-06
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
Reply by ●April 6, 20162016-04-06
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).> > 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? :DYes. 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. Best regards, Rick C. Hodgin
Reply by ●April 6, 20162016-04-06
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
Reply by ●April 6, 20162016-04-06
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
Reply by ●April 6, 20162016-04-06
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
Reply by ●April 6, 20162016-04-06
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
