As an historical point, back in the days of magneto-resistive disk drive heads the folks making the read electronics were making ultra-low noise npn's with some simple tricks. No one outside the industry with the ability to do some reverse engineering would ever have noticed since IIRC there were never any patents or publications.
You're right. This is an interesting read from 2004 on the academic view on front end design challenges. https://core.ac.uk/download/pdf/4268554.pdf high passed at 250kHz mind!
it's easy to forget that the heads themselves on hard drives are non-trivial bits of fabrication!
it's easy to forget that the heads themselves on hard drives are non-trivial bits of fabrication!
That's the app note I quoted from, a few posts up https://www.diyaudio.com/forums/ana...tra-low-noise-mc-head-amp-34.html#post5839291
Once again, I beg to differ; 90% of code in all spice distros today is from the Berkeley original Spice. Everything coming in the last 30 years were only icings on the cake. All bugfix that I am aware of were not really bugs, but adjustments to the newer CPU architectures (larger FP precision, etc...).
KiCAD integration with ngspice would be a great thing, but is currently at the very beginning. Last time I tried, earlier this year, it was so hard to simulate even a one transistor gain stage that I ended giving up. Not even me, a hobbyist, can afford to spend that much time to complete an almost trivial job, with any degree of confidence.
The platters themselves too - many layers of carefully designed magnetic nano-materials, magnetic backings, wear-resistant and lubricant layers, and better than optically smooth, advances like 3D recording, and whatever else they've come up with since.
It would be nice if you could import LTSpice netlists into KiCad (which AFAIK you cannot). As you say, their own spice program has some way to go. (and why create another anyway?)
And thanks for the ref. to the Toshiba AN, I shall have a read tonight.
IBM HDD division was sold/partnership to Hitachi. (maybe? I think the IBM research lab in Santa Teresa area of San Jose is still doing magnetic research).
Will have a read of the aforementioned documents. I've veered a long ways from my device physics and fabrication days so everything is rusty.
Will have a read of the aforementioned documents. I've veered a long ways from my device physics and fabrication days so everything is rusty.
I don't think that I was easy to misinterpret regarding the heritage of today's spices.
And it is forgotten too soon how useless spice3 was for board design as soon as p-spice prospered. All manufacturers delivered only models that contained p-spice extensions. It was the start of the LTspice success story that Mike Engelhard re-implemented all of that.
It is not as if all work was done an no further progress necessary. For example, you cannot get LDMOS models that really work (if at all) and you cannot simulate a pin diode. Carrier lifetime is an unknown concept. Or if Spice3 maxes out just _one_ core of your new 16 core computer with CUDA.
And I would not call mextram, Verilog-AMS models, harmonic balance, event-based cosimulation etc only icings. And with regard to word length: we had version 2G6 on a 48 bit Telefunken TR4 with OC604 transistors and tons of AA112 Ge-diode microprogram store, or later TR440 and CDC Cyber 176 with 60 bits. These were fun in comparison to 32 bit VM/370 WRT convergence etc. All that was not much more than a recompile. OK, the compile experiment on my Bullet Speedboard 286 running Interactive UNIX in large memory mode was a complete failure. (2G6)
Methinks that's true. IIRC that was the time of the IBM DeathStar SCSI disks. I had some, all of them failed. I remember a data saving action with the disk drive in the deep freezer with the SCSI cable going through the crack the door.
Attachments
I won't argue this past this point. We seem to have a fundamental difference in what "core code" and what data manipulation and I/O "cake icing code" are.
BTW, spice3 was never intended for "board design". For it's scope, it is as good and performing as any other "advanced" spice distros today, provided it is adjusted and compiled for the target platform.
Models are not part of the core spice code, in fact adding new models is a rather easy programming exercise, given the source code, and this is mainly because of the clever layered and structured core code.
Why are more advanced models not added to the generic spice platforms, that's because it is not worth of. Where it is worth of (and I know at least two examples, one proprietary) they are in, including the transit time, etc... Check the EESoft (currently Keysight) ADS (which is in part still built on top of spice) and I don't think you will miss much to simulate your RF/Microwave stuff. Ah, yes, it's expensive, I know
.
How about 60's tunnel diodes (TD 11), snap diodes, gold doped switching transistors (IIRC NS1000) all used in the Lumatron scope (25psec in 1963).
Hopefully tomorrow or Thursday I will post the updated sims for the phono stages. I am adding Demrow’s circuit plus one or two others.
Surprising what happens when real world source resistances and more accurate models are used.
Thanks for the work you have been doing, and sharing, I'm grateful.