Re: Core memory emulator using non volatile ram.
> From: Paul Koning >>> core memory details such as destructive read weren't visible to the >>> CPU > DATAIP/DATAO on the Unibus doesn't depend on the destructive read > property. Yes, the CPU can't tell what the memory is doing. > The reason it existed is that it allows core memory to optimize the > timing In other words, it's only there to allow the CPU to act in a way that works well with core memory. Whether that means that the way core operates is "visible" to the CPU is a debate about definitions. Put it another way - do any modern CPU's do 'read-modify-write' cycles (other than for interlocks in a multi-CPU system)? Noel
Re: Core memory emulator using non volatile ram.
On 12/17/18 9:51 AM, Guy Sotomayor Jr wrote: > Except it is *much* more expensive than MRAM. 32x8 NVSRAM is $18.50 in qty 1 > from Digikey. > A 64Kx16 MRAM is $11.84 in qty 1 from Digikey. MRAM requires no additional > circuitry so that > also reduces the overall cost (and has unlimited write endurance). nvSRAM is sole-sourced technology, so there's a premium. The crazy thing is that I was using the Xicor NOVRAM in the late 70s-early 80s. I still have a parts drawer full of X2444 8-pin DIPs from about that time. The technology appears to be roughly the same. Xicor got gobbled up by Intersil V2; Intersil V1 got gobbled up by Harris and then spun off again as Intersil V2 and then gobbled up by Renesas. You really need a program to tell the players apart. FWIW, there seems to be increasing interest in NVDIMMs: https://www.electronicdesign.com/industrial-automation/why-are-nvdimms-suddenly-hot I have no doubt that by the time they're wiping the drool from my face and wheeling me in front of the TeeVee to pass the time, that engineers will be discussing their favorite 20 psec. 8 exabyte non-volatile RAM chips... --Chuck
Re: Core memory emulator using non volatile ram.
> On Dec 17, 2018, at 10:52 AM, Noel Chiappa via cctalk > wrote: > >> From: Paul Koning > >> For that matter, core memory details such as destructive read weren't >> visible to the CPU > > Umm, not quite. If you'd said 'core memory details such as destructive read > weren't visible to the _program_', you'd have been 100% correct. > > But as I suspect you know, just overlooked, most (all?) of the -11 CPU's do > use 'read-modify-write' cycles on the bus (DATIP in UNIBUS terms, DATIO in > QBUS) where possible precisely for the benefit of core memory with its > destructive readout. (And there's some hair for interlocking the multiple > CPU's on the -11/74 which I don't recall off the top of my head.) > > And I have a vague memory of something similar on other early DEC machines; > probably some -8 models. But it does *no* harm if the underlying memory does *not* have a destructive read-out. Otherwise all of those (even DEC branded) MOS memory boards wouldn’t work. ;-) The DATIP and friends were an optimization implemented in the bus protocol to allow for it to take advantage of the behavior of core. However, nothing breaks if the memory doesn’t implement a destructive read-out. TTFN - Guy
Re: Core memory emulator using non volatile ram.
> On Dec 17, 2018, at 1:52 PM, Noel Chiappa via cctalk > wrote: > >> From: Paul Koning > >> For that matter, core memory details such as destructive read weren't >> visible to the CPU > > Umm, not quite. If you'd said 'core memory details such as destructive read > weren't visible to the _program_', you'd have been 100% correct. > > But as I suspect you know, just overlooked, most (all?) of the -11 CPU's do > use 'read-modify-write' cycles on the bus (DATIP in UNIBUS terms, DATIO in > QBUS) where possible precisely for the benefit of core memory with its > destructive readout. (And there's some hair for interlocking the multiple > CPU's on the -11/74 which I don't recall off the top of my head.) No, that doesn't invalidate what I said. DATAIP/DATAO on the Unibus doesn't depend on the destructive read property. It works just fine with DEC semiconductor memory. It is perfectly valid to implement DATAIP as if it were DATAI, so that transaction simply becomes a read followed by a write. The reason it existed is that it allows core memory to optimize the timing, by running a "half cycle", omitting the restore part. But the DATAO supplies the new content of the word, and so long as the memory does that write you're all set. If PDP-11s ever did a DATAIP without a DATAO, you'd be able to tell the difference between core and semiconductor memory by reading the location afterwards and looking for non-zero. But conforming Unibus masters don't do that. paul
Re: Core memory emulator using non volatile ram.
> From: Paul Koning > For that matter, core memory details such as destructive read weren't > visible to the CPU Umm, not quite. If you'd said 'core memory details such as destructive read weren't visible to the _program_', you'd have been 100% correct. But as I suspect you know, just overlooked, most (all?) of the -11 CPU's do use 'read-modify-write' cycles on the bus (DATIP in UNIBUS terms, DATIO in QBUS) where possible precisely for the benefit of core memory with its destructive readout. (And there's some hair for interlocking the multiple CPU's on the -11/74 which I don't recall off the top of my head.) And I have a vague memory of something similar on other early DEC machines; probably some -8 models. Noel
Re: Core memory emulator using non volatile ram.
I've seen a lot of talk about memory technologies, but as far as I can see, no one has offered any complete solutions. One already exists, thanks to the efforts of Steve Lafferty, Vince Slyngstad, and others. http://so-much-stuff.com/pdp8/32KOmnibus/32KOmnibus.php Yes, it uses a battery. FPGAs and CPLDs are not needed (though a CPLD could reduce all of the logic and drivers to a single chip, with the ATF1508). Numerous Omnibus PDP-8 owners have these cards, and I swear by them in my machines. I'd much rather keep a hefty load off of the power supply and free up 11 card slots, especially in my 8/M. Maybe with enough interest, Vince would consider doing another run of boards. Thanks, Kyle
Re: Core memory emulator using non volatile ram.
> On Dec 17, 2018, at 12:51 PM, Guy Sotomayor Jr via cctalk
> wrote:
>
>
>
>> On Dec 16, 2018, at 10:40 PM, Chuck Guzis via cctalk
>> wrote:
>>
>> On 12/16/18 11:21 AM, Paul Koning wrote:
>>
>>> If you simply want non-volatile memory, the obvious answer is SRAM with
>>> battery backup and a small FPGA to do the interfacing.
>>
>> I proposed nvRAM - CMOS SRAM backed by cell-for-cell flash. Loads SRAM
>> from flash on power-up and stores into flash at power-down. All that's
>> needed is a capacitor to extend the power-down cycle a bit.
>>
>> Very fast, available in 8 to 32-bit wide architectures, up to 16Mbit per
>> package.
>>
>> Claims to be guaranteed for 1M power cycles and doesn't require a battery.
>
> Except it is *much* more expensive than MRAM. 32x8 NVSRAM is $18.50 in qty 1
> from Digikey.
> A 64Kx16 MRAM is $11.84 in qty 1 from Digikey. MRAM requires no additional
> circuitry so that
> also reduces the overall cost (and has unlimited write endurance).
>
> If it sounds like I’m harping on MRAM, maybe I am. I’ve looked at the
> various technologies in
> detail (what’s available, cost, interfacing, etc, etc) for years and for
> anything that requires
> non-volatility, MRAM wins until you get into seriously large sizes at which
> point you need to
> go to FLASH for economics.
I'll go along with that. I worked on a storage product that needed
non-volatile memory in modest sizes for tracking transaction states. The first
product used FRAM for that, the second used SRAM backed by a small battery
("coin cell") and the third used MRAM. All worked fine. FRAM supposedly has
endurance limits but they are high enough they weren't a concern. The main
issue was the size limits, at least at the time (2003-ish).
For simplicity, battery backed SRAM should be just as good as SRAM. In any
case, you presumably will need a CPLD or small FPGA for the interface protocol
conversion.
paul
Re: Core memory emulator using non volatile ram.
> On Dec 16, 2018, at 10:40 PM, Chuck Guzis via cctalk > wrote: > > On 12/16/18 11:21 AM, Paul Koning wrote: > >> If you simply want non-volatile memory, the obvious answer is SRAM with >> battery backup and a small FPGA to do the interfacing. > > I proposed nvRAM - CMOS SRAM backed by cell-for-cell flash. Loads SRAM > from flash on power-up and stores into flash at power-down. All that's > needed is a capacitor to extend the power-down cycle a bit. > > Very fast, available in 8 to 32-bit wide architectures, up to 16Mbit per > package. > > Claims to be guaranteed for 1M power cycles and doesn't require a battery. Except it is *much* more expensive than MRAM. 32x8 NVSRAM is $18.50 in qty 1 from Digikey. A 64Kx16 MRAM is $11.84 in qty 1 from Digikey. MRAM requires no additional circuitry so that also reduces the overall cost (and has unlimited write endurance). If it sounds like I’m harping on MRAM, maybe I am. I’ve looked at the various technologies in detail (what’s available, cost, interfacing, etc, etc) for years and for anything that requires non-volatility, MRAM wins until you get into seriously large sizes at which point you need to go to FLASH for economics. TTFN - Guy
Re: Core memory emulator using non volatile ram.
> On Dec 16, 2018, at 10:49 PM, Rod G8DGR via cctech > wrote: > > > I’m trying to make a look and feel reproduction PDP-8/e. > So the memory characteristics need to be as close as possible. > > An original ( and I do have one) and the copy when placed side by side > should run in sync. > When executing he same code – What code I couldn’t care. > > Rod All you need for that to be true is to use the same bus timing as the original. What happens behind the scenes is unimportant. At LCM while restoring their CDC 6500 they built replacement memory modules, which actually mimic not just core memory cycle timing but also core memory waveforms -- which took some fiddling with pulse transformers. But behind the interface logic there's simple modern memory, probably SRAM, I forgot. paul
Re: Core memory emulator using non volatile ram.
On Sunday (12/16/2018 at 10:40PM -0800), Chuck Guzis via cctalk wrote: > On 12/16/18 11:21 AM, Paul Koning wrote: > > > If you simply want non-volatile memory, the obvious answer is SRAM with > > battery backup and a small FPGA to do the interfacing. > > I proposed nvRAM - CMOS SRAM backed by cell-for-cell flash. Loads SRAM > from flash on power-up and stores into flash at power-down. All that's > needed is a capacitor to extend the power-down cycle a bit. > > Very fast, available in 8 to 32-bit wide architectures, up to 16Mbit per > package. > > Claims to be guaranteed for 1M power cycles and doesn't require a battery. These are pretty neat. Took me a bit to find an example. They like to call it "NvSRAM", http://www.cypress.com/search/psg/1259#/?_facetShow=ss_ppart_family,ss_pinterface,fs_pdensity_kb_,ss_porganization_x_x_y_,ss_ppackage,ss_pfrequency_mhz_,fs_pspeed_ns_,ss_ptemp_classification,fs_pmin_operating_temp_c_,fs_pmax_operating_temp_c_,fs_pmin_operating_voltage_v_,fs_pmax_operating_voltage_v_,fs_pmin_operating_vccq_v_,fs_pmax_operating_vccq_v_,ss_ptape_reel,ss_pautomotive_qualified,fs_part_price_pinterface=Parallel_pmin_operating_voltage_v_=4.5_pmin_operating_voltage_v_=4.5 which is a typical 32K x 8, 5V device. The "flash" subsystem is something they call SONOS / QuantumTrap technology. Takes 8mS to STORE the SRAM to the backing store at power down and 20mS to RECALL it at power up. The storage cap is typically 68uF so nothing monster. Chris -- Chris Elmquist
Re: Core memory emulator using non volatile ram.
> On Dec 16, 2018, at 10:07 PM, ben via cctalk wrote: > > On 12/16/2018 8:00 PM, allison via cctech wrote: > >> In the end, current generation CMOS ram is the easy out, battery is >> small, cost is small, and >> produces much less of the heat that is killer to systems. The only >> reason to do that is core >> cost big if you can find it for your machine. I can cost more if you >> want to run an OS that >> needs a fair amount of it. AC as well as it can help heat the room and >> also power as in >> makes the meter spin. >> So much lathering and speculation about what and how. When the point is >> totally missed. >> Allison > > What programs or operating sytems require non volatile core? > Did DEC have any BOOTSTRAP programs in prom for the 8? > A small prom and regular slow mos memory may be the solution. > Ben. Before boot ROMs, it was standard practice to toggle the boot loader into core where it would be available indefinitely, including across power cycles. You can see this in the PDP-8, and it was also documented in the early days of the PDP-11 (though in 1973 I didn't have to do this, we had a 16-word diode matrix boot ROM). RSTS-11 V4 had optional power fail handling, which would allow it to continue running after a power cycle. Not by rebooting as later versions did, but by continuing from where it left off. It would have to reinitialize the I/O devices since I/O registers are volatile, but the OS in memory would be intact and logged in user sessions would be preserved. I actually saw that work once, pretty neat. For all this, the only necessary memory property is simply that the contents was preserved across power cycles. None of the other details of core memory are important. For that matter, core memory details such as destructive read weren't visible to the CPU; the read/restore cycle was handled inside the core memory logic. That's typical; one exception I know of is the CDC 6000 series peripheral processor, which I mentioned before: there the restore cycle is part of the main execution pipeline. That's why readstart (system reboot) drops a zero in memory, it disrupts that read/restore cycle. paul
Re: Core memory emulator using non volatile ram.
On 12/16/18 11:21 AM, Paul Koning wrote: > If you simply want non-volatile memory, the obvious answer is SRAM with > battery backup and a small FPGA to do the interfacing. I proposed nvRAM - CMOS SRAM backed by cell-for-cell flash. Loads SRAM from flash on power-up and stores into flash at power-down. All that's needed is a capacitor to extend the power-down cycle a bit. Very fast, available in 8 to 32-bit wide architectures, up to 16Mbit per package. Claims to be guaranteed for 1M power cycles and doesn't require a battery. --Chuck
Re: Core memory emulator using non volatile ram.
> On Dec 16, 2018, at 8:21 PM, allison via cctech wrote: > > On 12/15/2018 03:51 PM, Jon Elson via cctech wrote: >> On 12/15/2018 02:45 PM, Anders Nelson via cctalk wrote: >>> Serial flash has an endurance between 10K-100K writes per cell so I >>> think >>> that would break down quickly. Wear-leveling on a serial device would be >>> very slow... >>> >>> >> If you intend to use it as main core memory on an old CPU, it will >> perform VERY poorly, as these memories need to erase a page at a time, >> and the erase takes milliseconds. So, writing ONE SINGLE word at a >> time would invoke an erase cycle each time, slowing it to 1/1000 or >> worse the speed of the original core memory. Also, most old CPUs have >> the memory timing built into the CPU, and can't handle a memory that >> says "wait". >> >> Jon > The only place where Flash or similar tech fits is applied to the mass > storage problem such as replicating > a RF/DF32 multihead disk. > > The cycle life is a limiting factor for things like swapping drums/disks > but for something that's > read mostly its ok. Frankly even in those applications (RF11/DF32) I’d use MRAM (available in 2Mx8) rather than FLASH because (a) it’s byte addressable (b) it has unlimited write endurance (c) it looks like SRAM so there’s no erase cycle (or blocks) to deal with so it makes the hardware easier (e.g. it should be possible to implement one of those controllers just with logic and not require a microprocessor). BTW, that’s what I use for the emulators that I’m working on (when I have time…in short supply at the moment). I also use them even when I do use FLASH as I can use it as a buffer/cache to help absorb some of the write/overwrite cycles and to be able to handle (non-volatile) full FLASH block operations and for wear leveling (tracking and block remapping). That way I don’t have to deal with a PMIC and battery. MRAMs also have a >20 year data retention as well (something you don’t have with a battery…if the battery dies, you loose everything). TTFN - Guy
Re: Core memory emulator using non volatile ram.
On 12/15/2018 09:32 PM, Charles Anthony via cctech wrote: > On Sat, Dec 15, 2018 at 6:15 PM Rod G8DGR via cctalk > wrote: > >> All very interesting.. 1201 alarm while I deal will all of the information >> Rod >> >> > 1202 coming up... > > I don't know specifically about the various memory types being bandied > about, but I do know that the destructive read behavior of core memory my > be required for some architectures; "load and clear" type instructions rely > on the suppressing the write-after-read cycle to make the instruction > atomic, allowing the implementation of data locking instructions. For some > architectures, it may be that any replacement memory would have to support > the suppression signal to work correctly. > > -- Charles That's all fairy land speculation and guessing. The person that started this is working with a PDP-8E so the above does not apply. the 8E and later had both DEC made ram and third parties did when 2102 were cheap enough about 78ish. Later it was battery backed up cmos. For system with disk a rom based booter was enough as who cares if the ram held valid stuff. As to realism, the cost of a core was high enough then if it broke or worse now if it breaks its out of sight. Breakage back then was costly, not its possibly unobtainium. The for the most part with the covers on the only thing noted was binary blisters from the switches and the incessant loud fans. In the mean time the user was interacting with a TTY with its notable noises and if needing service a sometimes bad attitude. The fact that CORE does a R-Rewrite or RMW cycle is both unseen without a scope and had no impact while running a file though PAL-III in all caps. In the end, current generation CMOS ram is the easy out, battery is small, cost is small, and produces much less of the heat that is killer to systems. The only reason to do that is core cost big if you can find it for your machine. I can cost more if you want to run an OS that needs a fair amount of it. AC as well as it can help heat the room and also power as in makes the meter spin. So much lathering and speculation about what and how. When the point is totally missed. Allison
Re: Core memory emulator using non volatile ram.
I put focal in it...I leave focal in it... then I turn on the power it talks focal to a tty! ( for grains want copy of focal 11 for the 11/20 too...) But definitely want to see focal on a little omnibus 8! Just like that famous night in 1979.. Life is good Ed# In a message dated 12/16/2018 8:08:01 PM US Mountain Standard Time, cct...@classiccmp.org writes: What programs or operating sytems require non volatile core? Did DEC have any BOOTSTRAP programs in prom for the 8? A small prom and regular slow mos memory may be the solution. Ben.
Re: Core memory emulator using non volatile ram.
On 12/15/2018 03:51 PM, Jon Elson via cctech wrote: > On 12/15/2018 02:45 PM, Anders Nelson via cctalk wrote: >> Serial flash has an endurance between 10K-100K writes per cell so I >> think >> that would break down quickly. Wear-leveling on a serial device would be >> very slow... >> >> > If you intend to use it as main core memory on an old CPU, it will > perform VERY poorly, as these memories need to erase a page at a time, > and the erase takes milliseconds. So, writing ONE SINGLE word at a > time would invoke an erase cycle each time, slowing it to 1/1000 or > worse the speed of the original core memory. Also, most old CPUs have > the memory timing built into the CPU, and can't handle a memory that > says "wait". > > Jon The only place where Flash or similar tech fits is applied to the mass storage problem such as replicating a RF/DF32 multihead disk. The cycle life is a limiting factor for things like swapping drums/disks but for something that's read mostly its ok. Core is RAM, and not serial anyway. Allison
Re: Core memory emulator using non volatile ram.
On 12/16/2018 10:07 PM, ben via cctech wrote: > On 12/16/2018 8:00 PM, allison via cctech wrote: > >> In the end, current generation CMOS ram is the easy out, battery is >> small, cost is small, and >> produces much less of the heat that is killer to systems. The only >> reason to do that is core >> cost big if you can find it for your machine. I can cost more if you >> want to run an OS that >> needs a fair amount of it. AC as well as it can help heat the room and >> also power as in >> makes the meter spin. >> >> So much lathering and speculation about what and how. When the point is >> totally missed. >> >> Allison >> > > What programs or operating sytems require non volatile core? > Did DEC have any BOOTSTRAP programs in prom for the 8? > A small prom and regular slow mos memory may be the solution. > Ben. > None. Non volitility was handy if you wanted to power down go home and restart where you were the next day but at the OS level that was never a consideration. CMOS is MOS! Current generation parts are cheap and easy to use. Its not a speed issue as core was so slow, PDP-8 the fastest core was 1.5uS and even current cmos (5101) was under 1uS. No advanatage for slow memory as everything from 1978 on was likely much faster than an 8e needed anyway. The easy way if obvious use cmos as its cheap and common as house flies. Leave out the small lithium cell. The problem is PROM cards for PDP-8 omnibus was not common at at then then time cheap and used parts likely to be unobtainium now. The machines that had it used an abbreviated front panel maybe 12 sense switches for the OSR instruction and a boot/start switch. Not many made and FS contract required the full panel to do checkout and fix. So cost wise the boot card was not common. Call it an artifact of systems then. The loader for most stuff was small anyway, toggle it in, usually rim or bin loaders. Run the reader and that loaded whatever. Typical small non disk systems were CPU, TTY and maybe a high speed reader. Next level added TU56 or maybe RX01 floppy, from there a DF32 disk and maybe a RK05 or two. The user interacted with them the box ala the CPU was a small part of that interaction/experience. Allison
Re: Core memory emulator using non volatile ram.
On 12/16/2018 8:00 PM, allison via cctech wrote: In the end, current generation CMOS ram is the easy out, battery is small, cost is small, and produces much less of the heat that is killer to systems. The only reason to do that is core cost big if you can find it for your machine. I can cost more if you want to run an OS that needs a fair amount of it. AC as well as it can help heat the room and also power as in makes the meter spin. So much lathering and speculation about what and how. When the point is totally missed. Allison What programs or operating sytems require non volatile core? Did DEC have any BOOTSTRAP programs in prom for the 8? A small prom and regular slow mos memory may be the solution. Ben.
RE: Core memory emulator using non volatile ram.
Sent from Mail for Windows 10 From: ben via cctech Sent: 17 December 2018 03:08 To: cct...@classiccmp.org Subject: Re: Core memory emulator using non volatile ram. On 12/16/2018 8:00 PM, allison via cctech wrote: > In the end, current generation CMOS ram is the easy out, battery is > small, cost is small, and > produces much less of the heat that is killer to systems. The only > reason to do that is core > cost big if you can find it for your machine. I can cost more if you > want to run an OS that > needs a fair amount of it. AC as well as it can help heat the room and > also power as in > makes the meter spin. > > So much lathering and speculation about what and how. When the point is > totally missed. > > Allison > What programs or operating sytems require non volatile core? Did DEC have any BOOTSTRAP programs in prom for the 8? A small prom and regular slow mos memory may be the solution. Ben. I’m trying to make a look and feel reproduction PDP-8/e. So the memory characteristics need to be as close as possible. An original ( and I do have one) and the copy when placed side by side should run in sync. When executing he same code – What code I couldn’t care. Rod
Re: Core memory emulator using non volatile ram.
On Sun, 16 Dec 2018, Jon Elson via cctalk wrote: made, but if they are still being made they might not be too bad. I'm not sure 3D-printed housings would be strong enough for this, but maybe if ABS PLA is actually a stiffer plastic than ABS. That being said, PETG might be a better choice due to the heat found inside the enclosure. ABS can be pretty difficult to print if you're not working with a heated enclosure. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://scarlet.deltasoft.com - Get it _today_!
Re: Core memory emulator using non volatile ram.
> On Dec 15, 2018, at 1:55 PM, Chuck Guzis via cctalk > wrote: > > On 12/15/18 10:01 AM, Guy Sotomayor Jr via cctalk wrote: >> FRAM or MRAM. I make extensive use of them in my projects. >> >> Everspin has a few (all SMT and 3.3v). As I recall they run ~$20/ea for 4Mb >> (512K x 8 or 256K x 16). > > As neither MRAM nor FRAM requires a write-after-read refresh, I fail to > see the "realism" in this that couldn't be satisfied with simple > battery-backed RAM or even flash-backed RAM. > > Yes, MRAM is magnetic, but ti's not the same principle as real core. The key question is what the level of accuracy of the emulation is. If you simply want non-volatile memory, the obvious answer is SRAM with battery backup and a small FPGA to do the interfacing. If you need to emulate the destructive read, the same but with a slightly more complex FPGA. It's hard to see -- other than "because you can" -- why it's useful to emulate the destructive read. Read/modify/write will work without the destructive read, so long as a write simply overwrites what was in the word. The only place I can think of where the destructive read propery is useful is in CDC 6000 series peripheral processor memory, at least when you're debugging PP programs that get stuck -- a memory dump taken after a restart will show a zero at the point of the hang. paul
Re: Core memory emulator using non volatile ram.
On 12/15/2018 11:19 PM, Rod G8DGR via cctech wrote: However I began to think would it be possible to create a close copy of an 8/e out of modern parts. Finally the big one – Omnibus and the connectors its made from. A 3D printing candidate? I’m going to autopsy a busted connector and see how they are constructed inside. Yup, this will be a problem. A couple decades ago, there was a very common technology, press-fit backplanes. You made a PC board with all the interconnect on it (power + signals) and pressed-in contact fingers. Then, connector housings were pressed onto the contacts. I don't know if anybody still makes these contacts. It would be hugely expensive to have custom ones made, but if they are still being made they might not be too bad. I'm not sure 3D-printed housings would be strong enough for this, but maybe if ABS they would. Of course, there might actually still be somebody making clones of the DEC connectors. They used basically the same design for PDP-8, PDP-11, KL10, VAX, etc. Certainly, there were people cloning them back in the 1980's. Winchester made the official ones for DEC. Objectives The basic board set as original. M8300, M8310, M8320 etc. Same form factor Plug compatible – but board contents can differ from original Well, this could all be done with one FPGA, but if you want to do each PC board separately, a modest CPLD or small FPGA would certainly do each board's functionality. Jon
Re: Core memory emulator using non volatile ram.
Anyone building 8 omnibus batter backed up core replacement currently that is available off the shelf reasonably for 8 m,e and f? (( Smaller size board than the 8a would accept for memory as I remember..)) Have a 8 m or f in my den on a shelf... as as I best remember it 20 years ago had 4 k or flaky core in it. might be fun to play with. Alas there might me other things wrong on other boards by now too Ed# In a message dated 12/16/2018 6:44:55 AM US Mountain Standard Time, cctalk@classiccmp.org writes: On 12/15/2018 01:01 PM, Guy Sotomayor Jr via cctech wrote: > FRAM or MRAM. I make extensive use of them in my projects. > > Everspin has a few (all SMT and 3.3v). As I recall they run ~$20/ea for 4Mb > (512K x 8 or 256K x 16). > > TTFN - Guy > >> On Dec 15, 2018, at 1:22 AM, Rod G8DGR via cctalk >> wrote: >> >> I have an idea to produce an MM-8 clone using RAM that acts like core when >> turned off. >> Can anybody suggest a chip that will do this? >> >> Rod Smallwood >> >> My call on this is that cmos static ram 4Bit wide does the job well I have 32K of it in my PDP-8 to get past possible failure of hard to find and get core. A Panasonic BR-1 lithium cell has enough capacity at the measured drain for about 6-7 years and the Dallas power management chip makes it a non hack. Flash, EEprom and Magnetic FRAM and MRAM) types have many unacceptable properties for a random access read write memory. It makes no difference to the PDP8(ILEFMA) that read is not destructive as it will write back as needed anyway. There is a design on the 'net for using CMOS ram in a straight forward buildable array for Omnibus with battery back up that is fine. Don;t get wraped around the axle about RMW as any sufficiently fast ram can do that without wearout. And compared to core it doesn't take much speed. EEprom and Flash work fine for read mostly disks or disk simulators. Allison
RE: Core memory emulator using non volatile ram.
Sent from Mail for Windows 10 From: allison via cctech Sent: 16 December 2018 03:08 To: cct...@classiccmp.org Subject: Re: Core memory emulator using non volatile ram. On 12/15/2018 01:01 PM, Guy Sotomayor Jr via cctech wrote: > FRAM or MRAM. I make extensive use of them in my projects. > > Everspin has a few (all SMT and 3.3v). As I recall they run ~$20/ea for 4Mb > (512K x 8 or 256K x 16). > > TTFN - Guy > >> On Dec 15, 2018, at 1:22 AM, Rod G8DGR via cctalk >> wrote: >> >> I have an idea to produce an MM-8 clone using RAM that acts like core when >> turned off. >> Can anybody suggest a chip that will do this? >> >> Rod Smallwood >> >> My call on this is that cmos static ram 4Bit wide does the job well I have 32K of it in my PDP-8 to get past possible failure of hard to find and get core. A Panasonic BR-1 lithium cell has enough capacity at the measured drain for about 6-7 years and the Dallas power management chip makes it a non hack. Flash, EEprom and Magnetic FRAM and MRAM) types have many unacceptable properties for a random access read write memory. It makes no difference to the PDP8(ILEFMA) that read is not destructive as it will write back as needed anyway. There is a design on the 'net for using CMOS ram in a straight forward buildable array for Omnibus with battery back up that is fine. Don;t get wraped around the axle about RMW as any sufficiently fast ram can do that without wearout. And compared to core it doesn't take much speed. EEprom and Flash work fine for read mostly disks or disk simulators. Allison Sheesh!! Well what a response. This stems from my (so far) successful major over haul of my PDP-8/e. I found one failed 7474 and one failed 8881 – replaced and now working. I think I have the rim loader toggled in and will attempt to send a paper tape image from Hyperterm Strangely I do have at least three genuine complete 4k memory sets. However I began to think would it be possible to create a close copy of an 8/e out of modern parts. As you all know I make front panels so that’s not a problem. I did manage to copy my (distorted) bezel in resin. A friend has been able to 3D print toggle switch leavers that fit and work. Vince Sylngstat has done a console board PCB layout. Power supply clearly not a problem. So what’s left? Case? Well I have one of those and I suspect a sheet metal shop would not have a problem Finally the big one – Omnibus and the connectors its made from. A 3D printing candidate? I’m going to autopsy a busted connector and see how they are constructed inside. Objectives The basic board set as original. M8300, M8310, M8320 etc. Same form factor Plug compatible – but board contents can differ from original The idea is replace one item at time until you no longer have any DEC parts. Yup a FAKE-8 I may even need a label “No part in this PDP-8/e computer was manufactured by digital equipment corporation” Rod Smallwood
Re: Core memory emulator using non volatile ram.
> On Dec 15, 2018, at 7:09 PM, allison via cctech wrote: > > On 12/15/2018 01:01 PM, Guy Sotomayor Jr via cctech wrote: >> FRAM or MRAM. I make extensive use of them in my projects. >> >> Everspin has a few (all SMT and 3.3v). As I recall they run ~$20/ea for 4Mb >> (512K x 8 or 256K x 16). >> >> TTFN - Guy >> >>> On Dec 15, 2018, at 1:22 AM, Rod G8DGR via cctalk >>> wrote: >>> >>> I have an idea to produce an MM-8 clone using RAM that acts like core when >>> turned off. >>> Can anybody suggest a chip that will do this? >>> >>> Rod Smallwood >>> >>> > Flash, EEprom and Magnetic FRAM and MRAM) types > have many unacceptable > properties for a random access read write memory. I think you’re mistaken about FRAM and MRAM. They are byte oriented devices and are designed to replace SRAM + battery. Which in my mind makes them preferable as they reduce parts count. The current MRAM has unlimited write endurance (same as SRAM) and depending upon the part is 35-55ns access/cycle time. FRAM has a similar access time but requires an internal restore so it’s cycle time is about 2x (one of the reasons I prefer MRAM now). TTFN - Guy
Re: Core memory emulator using non volatile ram.
On 12/15/2018 01:01 PM, Guy Sotomayor Jr via cctech wrote: > FRAM or MRAM. I make extensive use of them in my projects. > > Everspin has a few (all SMT and 3.3v). As I recall they run ~$20/ea for 4Mb > (512K x 8 or 256K x 16). > > TTFN - Guy > >> On Dec 15, 2018, at 1:22 AM, Rod G8DGR via cctalk >> wrote: >> >> I have an idea to produce an MM-8 clone using RAM that acts like core when >> turned off. >> Can anybody suggest a chip that will do this? >> >> Rod Smallwood >> >> My call on this is that cmos static ram 4Bit wide does the job well I have 32K of it in my PDP-8 to get past possible failure of hard to find and get core. A Panasonic BR-1 lithium cell has enough capacity at the measured drain for about 6-7 years and the Dallas power management chip makes it a non hack. Flash, EEprom and Magnetic FRAM and MRAM) types have many unacceptable properties for a random access read write memory. It makes no difference to the PDP8(ILEFMA) that read is not destructive as it will write back as needed anyway. There is a design on the 'net for using CMOS ram in a straight forward buildable array for Omnibus with battery back up that is fine. Don;t get wraped around the axle about RMW as any sufficiently fast ram can do that without wearout. And compared to core it doesn't take much speed. EEprom and Flash work fine for read mostly disks or disk simulators. Allison
Re: Core memory emulator using non volatile ram.
On Sat, Dec 15, 2018 at 6:15 PM Rod G8DGR via cctalk wrote: > All very interesting.. 1201 alarm while I deal will all of the information > Rod > > 1202 coming up... I don't know specifically about the various memory types being bandied about, but I do know that the destructive read behavior of core memory my be required for some architectures; "load and clear" type instructions rely on the suppressing the write-after-read cycle to make the instruction atomic, allowing the implementation of data locking instructions. For some architectures, it may be that any replacement memory would have to support the suppression signal to work correctly. -- Charles
Re: Core memory emulator using non volatile ram.
On Sat, Dec 15, 2018 at 11:55 AM Chuck Guzis via cctalk < cctalk@classiccmp.org> wrote: > On 12/15/18 10:01 AM, Guy Sotomayor Jr via cctalk wrote: > > FRAM or MRAM. I make extensive use of them in my projects. > > > > Everspin has a few (all SMT and 3.3v). As I recall they run ~$20/ea for > 4Mb (512K x 8 or 256K x 16). > > As neither MRAM nor FRAM requires a write-after-read refresh, I fail to > see the "realism" in this that couldn't be satisfied with simple > battery-backed RAM or even flash-backed RAM. > FRAM requires write-after-read refresh, but it's done internally to the part. That's why FRAM has limited read endurance; each read also does a write. FRAM endurance is typically 10^14 cycles (check the datasheet of a specific part), which is adequate for most uses.
Re: Core memory emulator using non volatile ram.
On 12/15/18 1:30 PM, Warner Losh via cctalk wrote: > True. Lessening the pain still doesn't make it right :). MRAM or FRAM does > sound a lot simpler to use... How about nvRAM? Faster, with high capacity. Stores into flash (every CMOS RAM cell is paired with a flash cell) when the supply drops below a certain level; restores data to RAM upon power-up. http://www.cypress.com/products/nvsram-nonvolatile-sram --Chuck
Re: Core memory emulator using non volatile ram.
On Sat, Dec 15, 2018, 2:25 PM Guy Sotomayor Jr > > On Dec 15, 2018, at 1:18 PM, Warner Losh via cctalk < > cctalk@classiccmp.org> wrote: > > > > On Sat, Dec 15, 2018, 1:51 PM Jon Elson via cctalk < > cctalk@classiccmp.org > > wrote: > > > >> On 12/15/2018 02:45 PM, Anders Nelson via cctalk wrote: > >>> Serial flash has an endurance between 10K-100K writes per cell so I > think > >>> that would break down quickly. Wear-leveling on a serial device would > be > >>> very slow... > >>> > >>> > >> If you intend to use it as main core memory on an old CPU, > >> it will perform VERY poorly, as these memories need to erase > >> a page at a time, and the erase takes milliseconds. So, > >> writing ONE SINGLE word at a time would invoke an erase > >> cycle each time, slowing it to 1/1000 or worse the speed of > >> the original core memory. Also, most old CPUs have the > >> memory timing built into the CPU, and can't handle a memory > >> that says "wait". > >> > > > > If you paired it with a microcontroller, you might be able to implement a > > log device and then manage to logical to physical translation ala FTLs in > > SSD land... but it would be ugly as heck and you'd still have the stall > to > > worry about when you got to the end of the erase block... better > > performance, but maybe beyond a cheap uc… > > And my question is why go through all of that pain when an FRAM or MRAM > device can do this with no hackery? > > What you’re describing is the very definition of an “impedance mismatch”. > You’re trying to use a block oriented device as a byte device and > attempting > to paper over the differences. I think the end result would be less than > satisfactory in almost every measurable dimension. > True. Lessening the pain still doesn't make it right :). MRAM or FRAM does sound a lot simpler to use... Warner >
Re: Core memory emulator using non volatile ram.
> On Dec 15, 2018, at 1:18 PM, Warner Losh via cctalk > wrote: > > On Sat, Dec 15, 2018, 1:51 PM Jon Elson via cctalk wrote: > >> On 12/15/2018 02:45 PM, Anders Nelson via cctalk wrote: >>> Serial flash has an endurance between 10K-100K writes per cell so I think >>> that would break down quickly. Wear-leveling on a serial device would be >>> very slow... >>> >>> >> If you intend to use it as main core memory on an old CPU, >> it will perform VERY poorly, as these memories need to erase >> a page at a time, and the erase takes milliseconds. So, >> writing ONE SINGLE word at a time would invoke an erase >> cycle each time, slowing it to 1/1000 or worse the speed of >> the original core memory. Also, most old CPUs have the >> memory timing built into the CPU, and can't handle a memory >> that says "wait". >> > > If you paired it with a microcontroller, you might be able to implement a > log device and then manage to logical to physical translation ala FTLs in > SSD land... but it would be ugly as heck and you'd still have the stall to > worry about when you got to the end of the erase block... better > performance, but maybe beyond a cheap uc… And my question is why go through all of that pain when an FRAM or MRAM device can do this with no hackery? What you’re describing is the very definition of an “impedance mismatch”. You’re trying to use a block oriented device as a byte device and attempting to paper over the differences. I think the end result would be less than satisfactory in almost every measurable dimension. TTFN - Guy
Re: Core memory emulator using non volatile ram.
On Sat, Dec 15, 2018, 1:51 PM Jon Elson via cctalk On 12/15/2018 02:45 PM, Anders Nelson via cctalk wrote: > > Serial flash has an endurance between 10K-100K writes per cell so I think > > that would break down quickly. Wear-leveling on a serial device would be > > very slow... > > > > > If you intend to use it as main core memory on an old CPU, > it will perform VERY poorly, as these memories need to erase > a page at a time, and the erase takes milliseconds. So, > writing ONE SINGLE word at a time would invoke an erase > cycle each time, slowing it to 1/1000 or worse the speed of > the original core memory. Also, most old CPUs have the > memory timing built into the CPU, and can't handle a memory > that says "wait". > If you paired it with a microcontroller, you might be able to implement a log device and then manage to logical to physical translation ala FTLs in SSD land... but it would be ugly as heck and you'd still have the stall to worry about when you got to the end of the erase block... better performance, but maybe beyond a cheap uc... Warner >
Re: Core memory emulator using non volatile ram.
> On Dec 15, 2018, at 12:51 PM, Jon Elson via cctalk > wrote: > > On 12/15/2018 02:45 PM, Anders Nelson via cctalk wrote: >> Serial flash has an endurance between 10K-100K writes per cell so I think >> that would break down quickly. Wear-leveling on a serial device would be >> very slow... >> >> > If you intend to use it as main core memory on an old CPU, it will perform > VERY poorly, as these memories need to erase a page at a time, and the erase > takes milliseconds. So, writing ONE SINGLE word at a time would invoke an > erase cycle each time, slowing it to 1/1000 or worse the speed of the > original core memory. Also, most old CPUs have the memory timing built into > the CPU, and can't handle a memory that says "wait”. Anything FLASH related is quickly going to have issues because of the limited write endurance (1000s of cycles only). It’s one of the issues that I’m facing with the disk emulators that I’m (trying to) work on. But it works better there because of the block nature of disks (and I’m using a larger FLASH than necessary to allow for wear leveling plus some really heavy duty error correction…had to refresh myself on error coding theory again). For core replacements, as I’ve said previously, I prefer MRAM. They’re as fast as SRAM (35-55ns) with unlimited write endurance, 10+ year data retention and non-volitive (implied by the data retention). Other than the 3.3v interfaces (and SMT…but almost everything is SMT these days) they’re ideal. TTFN - Guy
Re: Core memory emulator using non volatile ram.
On 12/15/2018 02:45 PM, Anders Nelson via cctalk wrote: Serial flash has an endurance between 10K-100K writes per cell so I think that would break down quickly. Wear-leveling on a serial device would be very slow... If you intend to use it as main core memory on an old CPU, it will perform VERY poorly, as these memories need to erase a page at a time, and the erase takes milliseconds. So, writing ONE SINGLE word at a time would invoke an erase cycle each time, slowing it to 1/1000 or worse the speed of the original core memory. Also, most old CPUs have the memory timing built into the CPU, and can't handle a memory that says "wait". Jon
Re: Core memory emulator using non volatile ram.
Serial flash has an endurance between 10K-100K writes per cell so I think that would break down quickly. Wear-leveling on a serial device would be very slow... On Sat, Dec 15, 2018, 3:33 PM Gerhard Kreuzer via cctalk < cctalk@classiccmp.org wrote: > Hi Rod, > > take some microcontroller and some serial flash memory. > > With best regards > > Gerhard > > -Ursprüngliche Nachricht- > Von: cctalk [mailto:cctalk-boun...@classiccmp.org] Im Auftrag von > cctalk-requ...@classiccmp.org > Gesendet: Samstag, 15. Dezember 2018 19:00 > An: cctalk@classiccmp.org > Betreff: cctalk Digest, Vol 51, Issue 15 > > Send cctalk mailing list submissions to > cctalk@classiccmp.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.classiccmp.org/mailman/listinfo/cctalk > or, via email, send a message with subject or body 'help' to > cctalk-requ...@classiccmp.org > > You can reach the person managing the list at > cctalk-ow...@classiccmp.org > > When replying, please edit your Subject line so it is more specific than > "Re: Contents of cctalk digest..." > >
AW: Core memory emulator using non volatile ram.
Hi Rod, take some microcontroller and some serial flash memory. With best regards Gerhard -Ursprüngliche Nachricht- Von: cctalk [mailto:cctalk-boun...@classiccmp.org] Im Auftrag von cctalk-requ...@classiccmp.org Gesendet: Samstag, 15. Dezember 2018 19:00 An: cctalk@classiccmp.org Betreff: cctalk Digest, Vol 51, Issue 15 Send cctalk mailing list submissions to cctalk@classiccmp.org To subscribe or unsubscribe via the World Wide Web, visit http://www.classiccmp.org/mailman/listinfo/cctalk or, via email, send a message with subject or body 'help' to cctalk-requ...@classiccmp.org You can reach the person managing the list at cctalk-ow...@classiccmp.org When replying, please edit your Subject line so it is more specific than "Re: Contents of cctalk digest..."
Re: Core memory emulator using non volatile ram.
If you want the real deal you can always make a driver out of a bunch of H-bridge ICs and an old core plane. I'll skip suggesting you weave your own core... On Sat, Dec 15, 2018, 2:01 PM systems_glitch via cctalk < cctalk@classiccmp.org wrote: > Chuck, > > FRAM is destructive read on the die, from what I understand. It's just that > the onboard controller takes care of it for you, much like a core > subsystem. > > Thanks, > Jonathan > > On Sat, Dec 15, 2018 at 1:55 PM Chuck Guzis via cctalk < > cctalk@classiccmp.org> wrote: > > > On 12/15/18 10:01 AM, Guy Sotomayor Jr via cctalk wrote: > > > FRAM or MRAM. I make extensive use of them in my projects. > > > > > > Everspin has a few (all SMT and 3.3v). As I recall they run ~$20/ea > for > > 4Mb (512K x 8 or 256K x 16). > > > > As neither MRAM nor FRAM requires a write-after-read refresh, I fail to > > see the "realism" in this that couldn't be satisfied with simple > > battery-backed RAM or even flash-backed RAM. > > > > Yes, MRAM is magnetic, but ti's not the same principle as real core. > > > > FWIW, > > Chuck > > > > >
Re: Core memory emulator using non volatile ram.
Chuck, FRAM is destructive read on the die, from what I understand. It's just that the onboard controller takes care of it for you, much like a core subsystem. Thanks, Jonathan On Sat, Dec 15, 2018 at 1:55 PM Chuck Guzis via cctalk < cctalk@classiccmp.org> wrote: > On 12/15/18 10:01 AM, Guy Sotomayor Jr via cctalk wrote: > > FRAM or MRAM. I make extensive use of them in my projects. > > > > Everspin has a few (all SMT and 3.3v). As I recall they run ~$20/ea for > 4Mb (512K x 8 or 256K x 16). > > As neither MRAM nor FRAM requires a write-after-read refresh, I fail to > see the "realism" in this that couldn't be satisfied with simple > battery-backed RAM or even flash-backed RAM. > > Yes, MRAM is magnetic, but ti's not the same principle as real core. > > FWIW, > Chuck > >
Re: Core memory emulator using non volatile ram.
On 12/15/18 10:01 AM, Guy Sotomayor Jr via cctalk wrote: > FRAM or MRAM. I make extensive use of them in my projects. > > Everspin has a few (all SMT and 3.3v). As I recall they run ~$20/ea for 4Mb > (512K x 8 or 256K x 16). As neither MRAM nor FRAM requires a write-after-read refresh, I fail to see the "realism" in this that couldn't be satisfied with simple battery-backed RAM or even flash-backed RAM. Yes, MRAM is magnetic, but ti's not the same principle as real core. FWIW, Chuck
Re: Core memory emulator using non volatile ram.
FRAM or MRAM. I make extensive use of them in my projects. Everspin has a few (all SMT and 3.3v). As I recall they run ~$20/ea for 4Mb (512K x 8 or 256K x 16). TTFN - Guy > On Dec 15, 2018, at 1:22 AM, Rod G8DGR via cctalk > wrote: > > I have an idea to produce an MM-8 clone using RAM that acts like core when > turned off. > Can anybody suggest a chip that will do this? > > Rod Smallwood > > > Sent from Mail for Windows 10 >
Re: Core memory emulator using non volatile ram.
On 12/15/2018 03:22 AM, Rod G8DGR via cctalk wrote: I have an idea to produce an MM-8 clone using RAM that acts like core when turned off. Can anybody suggest a chip that will do this? Any CMOS SRAM chips can do this, with a backup battery. I used a IS62WV6416DBLL in a project a while ago. I did not use in in battery-backed mode, but it could do that. You do have to make sure that any outputs from the memory are driven to the high-impedance state during power-off to prevent draining the battery. Jon
RE: Core memory emulator using non volatile ram.
1201.. 1201 .. Processing large amount of data... Rod Sent from Mail for Windows 10 From: Bob Rosenbloom via cctalk Sent: 15 December 2018 16:45 To: cctalk@classiccmp.org Subject: Re: Core memory emulator using non volatile ram. On 12/15/2018 1:22 AM, Rod G8DGR via cctalk wrote: > I have an idea to produce an MM-8 clone using RAM that acts like core when > turned off. > Can anybody suggest a chip that will do this? > > Rod Smallwood > > > Sent from Mail for Windows 10 > > I used Everspin MRAM chips for my PDP-8e memory cards. It's just like SRAM, fast at 35 ns, and unlimited read/write endurance. Only drawback is it's 3.3 volts only. I just used level converters. It's a magnetoresistive memory, feels just like core. $12 for a 64K x 16 chip at Digikey. Bob -- Vintage computers and electronics www.dvq.com www.tekmuseum.com www.decmuseum.org
RE: Core memory emulator using non volatile ram.
All very interesting.. 1201 alarm while I deal will all of the information Rod Sent from Mail for Windows 10 From: systems_glitch via cctalk Sent: 15 December 2018 16:40 To: Anders Nelson; General Discussion: On-Topic and Off-Topic Posts Subject: Re: Core memory emulator using non volatile ram. Another vote for RAMtron/Cypress FeRAM. I've used their FeRAMs in a number of systems, here's a writeup on my "core board" for S-100: http://www.glitchwrks.com/2016/03/29/ferroelectric-ram-part-1 I've got a bunch of FM18W08s in stock if you need one, I can stick it on a DIP adapter if needed. One thing to be aware of, RAMtron FeRAMs latch the address bus when *CS goes low, so make sure everything's set up before *CS goes low. Thanks, Jonathan On Sat, Dec 15, 2018 at 11:11 AM Anders Nelson via cctalk < cctalk@classiccmp.org> wrote: > Texas Instruments' MSP430 MCUs use FRAM. This one for example: > http://www.ti.com/product/msp430fr5969 costs ~$2.30. > > You could do some emulation in the same package, too. Not sure what your > speed requirements are of course! > > =] > -- > Anders Nelson > > +1 (517) 775-6129 > > www.erogear.com > > > On Sat, Dec 15, 2018 at 10:37 AM alan--- via cctalk > > wrote: > > > > > Ramtron had most of the patents on Ferroelectric RAM in the past. > > Cypress acquired them many years ago. > > > > New production FRAM is still sold on Digikey - in 5V SOIC packages. Not > > cheap though: > > > > 8K x 8 - $12.72 (qty 1): > > > > > > > https://www.digikey.com/product-detail/en/cypress-semiconductor-corp/FM16W08-SGTR/428-3774-1-ND/6181520 > > > > 32K x 8 - $19.54 (qty 1): > > > > > > > https://www.digikey.com/product-detail/en/cypress-semiconductor-corp/FM18W08-SGTR/428-3775-1-ND/6181516 > > > > Completely non-volatile. Faster than most SRAM of the day (130ns cycle > > time). And good for 100+ trillion write cycles and more than a century > > of endurance. > > > > -Alan > > > > > > On 2018-12-15 05:19, Paul Birkel via cctech wrote: > > > Perhaps Cypress FM1808 (32Kx8). Obsolete, but available on eBay. SOP > > > for a bit of extra challenge! > > > > > > -----Original Message----- > > > From: cctech [mailto:cctech-boun...@classiccmp.org] On Behalf Of Rod > > > G8DGR via cctech > > > Sent: Saturday, December 15, 2018 4:22 AM > > > To: General Discussion: On-Topic and Off-Topic Posts > > > Subject: Core memory emulator using non volatile ram. > > > > > > I have an idea to produce an MM-8 clone using RAM that acts like core > > > when turned off. > > > Can anybody suggest a chip that will do this? > > > > > > Rod Smallwood > > > > > > > > > Sent from Mail for Windows 10 > > >
Re: Core memory emulator using non volatile ram.
On 12/15/2018 1:22 AM, Rod G8DGR via cctalk wrote: I have an idea to produce an MM-8 clone using RAM that acts like core when turned off. Can anybody suggest a chip that will do this? Rod Smallwood Sent from Mail for Windows 10 I used Everspin MRAM chips for my PDP-8e memory cards. It's just like SRAM, fast at 35 ns, and unlimited read/write endurance. Only drawback is it's 3.3 volts only. I just used level converters. It's a magnetoresistive memory, feels just like core. $12 for a 64K x 16 chip at Digikey. Bob -- Vintage computers and electronics www.dvq.com www.tekmuseum.com www.decmuseum.org
Re: Core memory emulator using non volatile ram.
Another vote for RAMtron/Cypress FeRAM. I've used their FeRAMs in a number of systems, here's a writeup on my "core board" for S-100: http://www.glitchwrks.com/2016/03/29/ferroelectric-ram-part-1 I've got a bunch of FM18W08s in stock if you need one, I can stick it on a DIP adapter if needed. One thing to be aware of, RAMtron FeRAMs latch the address bus when *CS goes low, so make sure everything's set up before *CS goes low. Thanks, Jonathan On Sat, Dec 15, 2018 at 11:11 AM Anders Nelson via cctalk < cctalk@classiccmp.org> wrote: > Texas Instruments' MSP430 MCUs use FRAM. This one for example: > http://www.ti.com/product/msp430fr5969 costs ~$2.30. > > You could do some emulation in the same package, too. Not sure what your > speed requirements are of course! > > =] > -- > Anders Nelson > > +1 (517) 775-6129 > > www.erogear.com > > > On Sat, Dec 15, 2018 at 10:37 AM alan--- via cctalk > > wrote: > > > > > Ramtron had most of the patents on Ferroelectric RAM in the past. > > Cypress acquired them many years ago. > > > > New production FRAM is still sold on Digikey - in 5V SOIC packages. Not > > cheap though: > > > > 8K x 8 - $12.72 (qty 1): > > > > > > > https://www.digikey.com/product-detail/en/cypress-semiconductor-corp/FM16W08-SGTR/428-3774-1-ND/6181520 > > > > 32K x 8 - $19.54 (qty 1): > > > > > > > https://www.digikey.com/product-detail/en/cypress-semiconductor-corp/FM18W08-SGTR/428-3775-1-ND/6181516 > > > > Completely non-volatile. Faster than most SRAM of the day (130ns cycle > > time). And good for 100+ trillion write cycles and more than a century > > of endurance. > > > > -Alan > > > > > > On 2018-12-15 05:19, Paul Birkel via cctech wrote: > > > Perhaps Cypress FM1808 (32Kx8). Obsolete, but available on eBay. SOP > > > for a bit of extra challenge! > > > > > > -----Original Message----- > > > From: cctech [mailto:cctech-boun...@classiccmp.org] On Behalf Of Rod > > > G8DGR via cctech > > > Sent: Saturday, December 15, 2018 4:22 AM > > > To: General Discussion: On-Topic and Off-Topic Posts > > > Subject: Core memory emulator using non volatile ram. > > > > > > I have an idea to produce an MM-8 clone using RAM that acts like core > > > when turned off. > > > Can anybody suggest a chip that will do this? > > > > > > Rod Smallwood > > > > > > > > > Sent from Mail for Windows 10 > > >
Re: Core memory emulator using non volatile ram.
Texas Instruments' MSP430 MCUs use FRAM. This one for example: http://www.ti.com/product/msp430fr5969 costs ~$2.30. You could do some emulation in the same package, too. Not sure what your speed requirements are of course! =] -- Anders Nelson +1 (517) 775-6129 www.erogear.com On Sat, Dec 15, 2018 at 10:37 AM alan--- via cctalk wrote: > > Ramtron had most of the patents on Ferroelectric RAM in the past. > Cypress acquired them many years ago. > > New production FRAM is still sold on Digikey - in 5V SOIC packages. Not > cheap though: > > 8K x 8 - $12.72 (qty 1): > > > https://www.digikey.com/product-detail/en/cypress-semiconductor-corp/FM16W08-SGTR/428-3774-1-ND/6181520 > > 32K x 8 - $19.54 (qty 1): > > > https://www.digikey.com/product-detail/en/cypress-semiconductor-corp/FM18W08-SGTR/428-3775-1-ND/6181516 > > Completely non-volatile. Faster than most SRAM of the day (130ns cycle > time). And good for 100+ trillion write cycles and more than a century > of endurance. > > -Alan > > > On 2018-12-15 05:19, Paul Birkel via cctech wrote: > > Perhaps Cypress FM1808 (32Kx8). Obsolete, but available on eBay. SOP > > for a bit of extra challenge! > > > > -Original Message- > > From: cctech [mailto:cctech-boun...@classiccmp.org] On Behalf Of Rod > > G8DGR via cctech > > Sent: Saturday, December 15, 2018 4:22 AM > > To: General Discussion: On-Topic and Off-Topic Posts > > Subject: Core memory emulator using non volatile ram. > > > > I have an idea to produce an MM-8 clone using RAM that acts like core > > when turned off. > > Can anybody suggest a chip that will do this? > > > > Rod Smallwood > > > > > > Sent from Mail for Windows 10 >
Re: Core memory emulator using non volatile ram.
Ramtron had most of the patents on Ferroelectric RAM in the past. Cypress acquired them many years ago. New production FRAM is still sold on Digikey - in 5V SOIC packages. Not cheap though: 8K x 8 - $12.72 (qty 1): https://www.digikey.com/product-detail/en/cypress-semiconductor-corp/FM16W08-SGTR/428-3774-1-ND/6181520 32K x 8 - $19.54 (qty 1): https://www.digikey.com/product-detail/en/cypress-semiconductor-corp/FM18W08-SGTR/428-3775-1-ND/6181516 Completely non-volatile. Faster than most SRAM of the day (130ns cycle time). And good for 100+ trillion write cycles and more than a century of endurance. -Alan On 2018-12-15 05:19, Paul Birkel via cctech wrote: Perhaps Cypress FM1808 (32Kx8). Obsolete, but available on eBay. SOP for a bit of extra challenge! -Original Message- From: cctech [mailto:cctech-boun...@classiccmp.org] On Behalf Of Rod G8DGR via cctech Sent: Saturday, December 15, 2018 4:22 AM To: General Discussion: On-Topic and Off-Topic Posts Subject: Core memory emulator using non volatile ram. I have an idea to produce an MM-8 clone using RAM that acts like core when turned off. Can anybody suggest a chip that will do this? Rod Smallwood Sent from Mail for Windows 10
RE: Core memory emulator using non volatile ram.
Perhaps Cypress FM1808 (32Kx8). Obsolete, but available on eBay. SOP for a bit of extra challenge! -Original Message- From: cctech [mailto:cctech-boun...@classiccmp.org] On Behalf Of Rod G8DGR via cctech Sent: Saturday, December 15, 2018 4:22 AM To: General Discussion: On-Topic and Off-Topic Posts Subject: Core memory emulator using non volatile ram. I have an idea to produce an MM-8 clone using RAM that acts like core when turned off. Can anybody suggest a chip that will do this? Rod Smallwood Sent from Mail for Windows 10
Core memory emulator using non volatile ram.
I have an idea to produce an MM-8 clone using RAM that acts like core when turned off. Can anybody suggest a chip that will do this? Rod Smallwood Sent from Mail for Windows 10
