On Sun, 15 Apr 2007, Jules Richardson wrote: I think I've found what I'd been thinking of - Wilson Labs do an MFM->SCSI bridge, and for some reason I'd convinced myself that they did a flash equivalent. I was referring to the IMSAI Super I/O board; $350 seems to buy you a whole lot of connectivity to newer devices. I'm thinking about the software as well as the hardware, though - if such an emulated device were available, it'd probably be preferable to teaching a number of operating systems how to speak to new hardware. Plus I've got a couple of non-S100 machines where the MFM drive has proven to be the achilles heel as well - it'd be useful in a number of places. Cheers, Simon.

Rumor has it that David Comley may have mentioned these words: Ah, but the beauty of this is, if you make it IDE compatible, you already *have* flash compatibility - just slap a CompactFlash module of your preferred size into a CF->IDE adapter, and Bob's your uncle! I doubt there were MFM drives (read: ST506) available that hit the gigglebyte size, but 1G CF drives are not only plentiful (I have two on my desk right now, for my Nikon D70) but now they're quite inexpensive. Laterz, Roger "Merch" Merchberger -- Roger "Merch" Merchberger | "Profile, don't speculate." SysAdmin, Iceberg Computers | Daniel J. Bernstein zmerch at 30below.com |

--- Ethan Dicks <ethan.dicks at gmail.com> wrote: If, however, your OS requires a writeable Exactly. My intended uses are primarily VAX/VMS-based. -Dave

Chuck Guzis wrote: I'm not sure - remember the task is to emulate a drive, not a controller. Isn't an MFM ST506/412 drive just a bucket of rotating bits and a track stepper? Or does the index pulse function more like that of a hard-sectored floppy - i.e. the number of sectors per track is fixed in hardware, and there's an index pulse at the start of each sector? Even if that is the case, I wouldn't have thought it makes much difference - it just means that buffer memory and permanent storage is organised a little differently. The device is still like a big floppy, just with more heads and the need to record faster timings between bit transitions: the principle's the same, it just needs someone with experience of working with fast logic to design the board layout and code for whatever CPU / DSP is used. cheers Jules

Rumor has it that Ethan Dicks may have mentioned these words: Ah, but a decade ago, "pundits" said the floppy was past it's prime... I'll admit that I actually have a computer that doesn't have one installed and I don't really miss it (because I do have access to a USB floppy drive I use on occasion) and my wife's machine doesn't have one either, but I recently found the last floppy I made for her... a 720K DSDD ditty for MS-DOS which still a) was readable and for the "too much info" crowd b) still had an "e-loveletter" that I wrote to her on it before we were married... the disk is over 15 years old; so she never really used 'em much to begin with. PATA vs. SATA is merely an argument of the little board they stick on the hardware, which both right now are being made in such quantity that they're equal in price. Until there's no call for PATA upgrades (which might take at least 1/2 decade, judging from the floppy's history) there will still be SATA->PATA converters (which exist already in both directions) and so it's just another seamless emulation layer to CF that really doesn't matter. Maybe in 15 years we should start worrying, but by then the petabyte CF cards will be available for your gigapixel DSLR... ;-) Must be nice to live in a populous area, even if it is only half-the-time... ;-) How many of those could I get for $20 plus shipping? I could use (at least) a couple for my SuperIDE interface for my CoCo that I'm repacking in a Tandy 1000 RLX case. No, the guts didn't go to waste... Most of the non-sucky CF implementations (read: Sandisk/Lexar) have built-in sector-writing-balancing (for lack of a useful term -- or a still-functional pair of connected neurons ;-) - so a sufficiently large CF card _could_ last a very long time even as swap on a classic system (depending on a boatload of factors, and your definition of "very long" of course... ;-) and IIRC, newer flash has an order of magnitude more write cycles than the old stuff, but that just might be the beer talkin'. I still need the AT keyboard interface for my CoCo repack - see an upcoming wholly OT post that hopefully Jay won't kick my butt over on how I'm gonna pay for that.... Laterz, Roger "Merch" Merchberger -- Roger "Merch" Merchberger | "Profile, don't speculate." SysAdmin, Iceberg Computers | Daniel J. Bernstein zmerch at 30below.com |

On 4/16/07, Alexandre Souza <alexandre-listas at e-secure.com.br> wrote: I am aware that CF does "wear levelling", but there is a substantial difference of quantity of write activity between, say, CP/M, and VAX/VMS. With CP/M, if I'm sitting at a prompt or sitting inside Wordstar, I don't think the OS is writing to the hard disk behind my back. With VMS, it's pretty much constantly writing to the boot volume at least (you could mount write-protected data volumes) whether you are typing any commands or not. In the case of CP/M, you could decide to accept a 1GB card and present it to the host as, say, a 5MB drive. That would be rather a lot of space to a CP/M machine. You'd be able to fill that drive 200 times, in theory, before you reused a single segment of the CF card. In the case of VMS, though, a 5MB boot volume isn't particularly useful. The smallest I've ever shoehorned VMS 6.0 into (and it was a trick) was an RD54 at 154MB. Practically speaking, unless you are going to use it only with pre-VMS-5.0 distros, you are going to want to present a drive to the VAX in the hundreds of megabytes. If you decide on, say, 250MB, that's quadruple sector redundancy for complete drive re-writes, but in practice, only a percentage of the drive is going to change on a frequent basis as the machine runs. Since the OP mentioned VAX/VMS and I'm reasonably certain that the target would be a MicroVAX with either an RQDX1, RQDX2 or RQDX3, or the near equivalent in an MicroVAX 2000, it's likely that the RQDX controller is the only drive controller on the system. Since part of the problem with machines of that vintage is the lack of available, reliable, large ST506/ST412-interface MFM drives, the whole point of drive emulation is to take a MicroVAX and get it running with no real MFM drives, just emulated ones. Therefore, you will end up with the page file and swap file on the emulated drive. Even if you aren't doing anything "interesting" with your machine, the pagefile and swapfile will still see activity. If you start doing things that need lots of memory, starting VMS Mail, or running a compiler, or using a word processor like MASS-11 (to name a few things we used to do all day long with our departmental VAX 15+ years ago), there will be a flurry of reads and writes at each image launch. While it would "work" to run a VAX from a CF drive, I don't think the lifetime of the CF card would be particularly high. I can't quantify it off the top of my head, but to speculate wildly, I think I'd rather depend on an RD53 drive as unreliable as they are (I still have several from the 1980s,. but I don't tend to use them as boot volumes). As for experience with Flash wear and shrinking capacity, I ran an "Earthdial" at the South Pole over sunny parts of 2004 and 2005. My camera was an old 2megapixel Olympus, chosen because a) it was in the cupboard, and b) it had a serial interface. I wrote a script to take a picture every 2.5 minutes, dump it, add some text at the top and bottom, and post it to my web page. Over a few weeks of operation, that flash card lost two photographs-worth of capacity from being asked to make 576 writes of a few hundred sectors, day after day. Percentage-wise, it was probably 3% of the capacity lost over 4 months of constant use. While the card would then last for years in that arrangement, it does seem like a fast decline to me. This card was an older one. Perhaps newer ones have 10 or even 100 times as many write cycles as ones ten years ago, but that only delays the inevitable. If Flash advances to the point that using it in a write-intensive environment would have a lifetime measured in multiple years, then it's probably a viable replacement for rotating media. We are, after all, accustomed to replacing hard drives every three to five years anyway. I don't think I'd want to intentionally set up a system where I have to be concerned about how fast it's degrading, and watch the hour-meter tick away its remaining lifetime. Yes, the argument could be made that disks do that anyway, but I don't think it's the same when you can set your calendar by the self-destruct date. -ethan

There were several MFm replacement devices years ago, IIRC they were battery backed SRAM -----Original Message----- From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org] On Behalf Of David Comley Sent: Sunday, April 15, 2007 5:19 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: MFMulation? (Solid-state replacements for MFM drives) Oddly enough, I've been working on a design for an MFM drive replacement on and off for a while now. I don't believe that flash memory is the way to go though with cheap and plentiful IDE drives available. I've seen that commercial offering somewhere in Europe - looks expensive. -Dave --- Entity <entity at nenevr.demon.co.uk> wrote: