On 12/01/14 16:35, Al Kossow wrote: I have a bunch of blank DiscFerret boards on hand, actually -- the problem is I don't have the parts to assemble them, or the money to do so. I do have a solder paste template for the board, working pick-and-place system and convection reflow oven... they were purchased after the last assembly house tried to screw me over (50% jump in NRE costs between quoting and placing the order, followed by a demand that I sent an extra ten spare FPGAs "just in case" which they were unwilling to return if unneeded). That and the hate-mail I got from several members of this community (notably Kryoflux proponents) has left an extremely bitter taste in my mouth. -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/

On 12 January 2014 18:02, Al Kossow <aek at bitsavers.org> wrote: Yes, I've noticed that, too. It's very strange to me. It has put me off from getting into the whole area. It's one of the few areas of computing where (IMHO) one can very plainly see the rationale for the Stallmanite absolute, inflexible, unyielding demand for pure GPL software and open, fully-documented hardware. Without speculating in any way on any of the rights or wrongs of any parties and not assigning any blame to anyone, the only way forward that I can see would be for everyone to release everything - code, file formats, exact hardware schematics, the lot - as Free, open source, call it what you will, completely public projects. Personally, I would not buy hardware or software or a bundle thereof to do something like data recovery if the resulting files were in any kind of proprietary format. How good or sophisticated the product was, however elegant the software, how easy to use or fast or efficient, if I were recovering data from media, the need for it to be in an open, documented file format is non-negotiable. Otherwise, you've not recovered it at all: all you've done is transfer it from one difficult or inaccessible system into a different inaccessible system. In everyday computing, I'm not anywhere near so puritan. I am typing on a Hackintosh running MacOS X Snow Leopard on a generic old PC I got off my local Freegle group (as Freecycle? has terms & conditions that are too restrictive for many in the UK) - a proprietary OS on COTS but still in places proprietary hardware. I mainly write in MS Word, a proprietary package - but loads of other software can handle MS Word files. I'm not locked in at all; the machine also runs Linux and Windows 8 and all can read each others' files. If the app won't let me do that, I don't run it. But for data recovery? Nope. Sorry. Got to be /at least/ as open as that and preferably a lot more so. I've seen too much of the squabbling and in-fighting. I still don't really understand why, but it's gone too far. Open or nothing. If I can't recover it with open tools into open formats, well, I just won't recover it then. Perhaps so, but while that might be a factor, it can't be all of it, surely. Piracy of recovery software is another factor, at the least, I am sure. -- Liam Proven ? Profile: http://lproven.livejournal.com/profile Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven Tel: +44 20-8685-0498 ? Cell: +44 7939-087884

On Sun, Jan 12, 2014 at 07:43:33PM +0000, Liam Proven wrote: I suspect that these groups think that there's actual money to be made in restoring old media. With a few high-profile exceptions, this is quite far from the truth. [...] As you know, I've recently discovered TOSEC and have been hoovering up the media they've been archiving. At least on the Amiga side, the file formats are completely open: one ZIP file per image, with the contents being a raw disk dump in the case of floppies (aka "ADF"), and a CUE file plus the raw ISO-9660 filesystem and uncompressed WAV files for CD-ROM media. I note that my very slow-moving archival project of my Amiga media also produced files that are bit-identical with TOSEC, which is encouraging. I don't know what they've been using to do the transfers, but I've been using an Amiga 1200 with a CF card and a copy of "SuperDuper" configured to dump to file instead of another floppy. On the modern hardware side, I just used a USB CF card reader on a Linux box (Debian natively understands RDB and FFS) to read the data, and I slapped together a Perl script to do the postprocessing from SuperDuper's custom IFF disk image format into the de facto standard ADF format. I'm not quite sure how I'm going to read all the HD disks I wrote on my somewhat ill Amiga 4000 that isn't really up to being run for long periods to do the data recovery. (Plus it doesn't have a CF slot.) [...] Reading between the lines, TOSEC pretty much started up as an Amiga warez operation that was collecting stuff that's basically abandonware at this point. If anybody wants my Perl script, they're welcome to it for nowt :)

On Tue, Jan 14, 2014 at 11:39:18AM +0100, rachael at telefisk.org wrote: I don't think I have *any* copy-protected Amiga software. Partly because I was much more interested in demos and productivity software, and it was only really games that were copy-protected, but mainly myself and my circle of friends were all skint teenagers, and original media was a rare and wondrous thing. Besides, TOSEC seems to be less an archiving project and more a thin veneer of respectability over a retro games piracy operation, and the majority of its Amiga archive appears to be cracked games or games that never had protection.

On Jan 14, 2014, at 09:25 , Al Kossow <aek at bitsavers.org> wrote: My KryoFlux does work with my Mac under OSX, but its flaw is the lack of general write support without using the parent company's paid disk analysis services. Without having investigated it myself, I'm willing to accept that reading a funky write-protected format and then being able to write it to a new disk in a way that satisfies the copy protection is tricky and difficult or impossible to automate. But for my own selfish purposes, I would be quite satisfied to have a good solution to read regular non-copy-protected disks and write them back out in a way that satisfies stock DOSes, just for keeping old hardware alive and fed with operating systems and basic utilities. The public domain Disk-Utilities package looks promising in conjunction with KryoFlux, but I haven't gotten around to trying to adapt it for the non-PC formats that interest me. Trying to bring this up on the KryoFlux support forums tends to agitate hostile responses. It's quite frustrating. Almost frustrating enough to motivate me to develop a competing product, but that would be a very large job to do well, and my darned day job ties up most of my time and gumption. -- Mark J. Blair, NF6X <nf6x at nf6x.net> http://www.nf6x.net/

Several thoughts on this. First, there was a tragic lack of understanding of the historical value and recovery needs of floppy disks in the general public. It's old, old hat to people in the vintage computing communities, but these are relatively small groups. Other people would be inclined to leave floppies along the same way they'd leave old photographs, business cards, brochures and trinkets of a life lived, without realizing how much more fragile or unrecoverable they were in passing years. Unlike, say, this can of Mountain Dew which was under a lake for decades: http://imgur.com/gallery/5Ipbj Without that fundamental knowledge, there are only a limited number of people realizing they even want the material off these floppies, or that they have rare copies,or any of a number of the usual aspects of recognizing something needs restoring. Kryoflux, more specifically Christian, took a very territorial approach to the "market" of disk imaging, wanting to keep one foot in the hobby market, while also approaching the professional and academic markets. I've only met one other person more adversarial than Christian in decades of walking these halls. It doesn't lead to a feeling of camaraderie and shared innovation to be sure. That said, Kryoflux has been tireless in the advocating of why these devices are even needed, in terms and illustration that anyone can understand; I just also happen to think the attitude and combativeness (some of which has changed in recent times) poisoned a lot of opportunities. Phil and Diskferret have money problems and Phil is pretty defeatist about the whole endeavor - but he continues to innovate and his dream is strong. Unfortunately, like a lot of people, he has had to face down against Kryoflux instead of being the Avis to their Hertz (the Lidl to their Aldi, if you prefer) and he just doesn't have the resources necessary at this juncture to bring it to the next level. I hope that changes. The FC5025 is a nice general (and available) solution for many situations - it should be one of multiple choices that are as easy to use and work with as the rest. The creator is relatively quiet, and it takes effort to even find out who makes it besides "Device Side Data". (Adam Goldman). Adam is not exactly shaking up the podcast and newsletter worlds with a presence, which is his perogative. There are a number of other solutions out there as well, usually aimed very well towards one specific machine, either to use the original hardware to pull in the image or to blow out the image to a machine to make it run. None of them are particularly hot to go toe-to-toe with debates about what they "should" be doing - they just did what they did. I do think the tide is turning. I think the fundamental message (this old stuff is important, this old stuff needs to go through a converter to make it come alive again, it's possible to take a disk image and do something with it) is filtering down to where people aren't questioning its utility or possibility. We all know this is 10-20 years after it should have happened, but that's kind of how it is in general - historical archives being left to rot for many years before they're suddenly the most precious and worthwhile things in the world. I think that's just a problem of human nature, not of floppies or vintage software folks. I think we're going to have a few iterations of floppy reading, and the bottom-floor collapse of computing accessibility with items like the Raspberry Pi will lead to more people doing this work, and knowledge being shared. I also hope that places like the Internet Archive, Stanford, the Strong Museum, and many others will be known as repositories of software as previous places are known as repositories of art, artifacts and history. I think it's a reasonable hope. On Sun, Jan 12, 2014 at 1:02 PM, Al Kossow <aek at bitsavers.org> wrote:

On Tue, 14 Jan 2014, David Schmidt wrote: Do current Macs still have PCI slots? Would the code from your project work on an ancient G4 with backlevel OSX (that's the only Mac I have with PCI)? Steve --

On Jan 15, 2014, at 7:10 AM, Steven Hirsch <snhirsch at gmail.com> wrote: Current Macs are all PCI Express. Machines up to early G5s have PCI slots (PCI-X is directly compatible with PCI, though the card must be keyed for and compatible with 3.3v signaling; typically on a standard PCI card, this would mean two keying notches since very few PCI cards were produced for 3.3v only). Multicore G5s have PCI Express, which won't do. Pictures I see online of the Catweasel Mk4 show dual keying notches, which indicates that it SHOULD work fine in PCI-X slots. There are Thunderbolt-to-PCI conversion boxes, but my understanding is that they require some driver support (i.e., they don't work out of the box with the original PCI drivers without modification). Driver-wise, I would hope that it works well under 10.4, at least; that's the latest OS I ever feel comfortable with on PPC Macs, because 10.5 was such a dog even on G5s. The site doesn't say, but the kernel PCI interfaces didn't change a whole lot between 10.2 and 10.5, to my recollection. Those neurons are a bit dusty, though. - Dave

Well I'll through my project into the pile also. I have been working on MFM hard drive disk reading and emulation using a BeagleBone Black. Its web page is http://www.pdp8online.com/mfm/mfm.shtml On 12 January 2014 18:02, Al Kossow <aek at bitsavers.org> wrote: Part of the reason I'm bring it up now. I wanted to see if there are existing formats I should be using. If there is a raw transition file format that people like I will see if I can use it. Let me know the URL documenting the format. My current format is just internal format so inefficient. Also if there is a common format for decoded data other than just straight sector contents which I currently do that is used let me know also. I expect the emulator file format to be its own with converter to other formats. The reader I expect can capture the raw transition data from most ST506/ST412 disks. It can decode to sector data with some issues the disks I have. Controller level sparing or mixed track formats are troublesome. I have made a little wirewrap board to interface the BeagleBone Black to disk drives/controllers. The BeagleBone captures/generates the transitions with 200 MHz clock. I am looking at doing a PCB version of the wirewrap board and if people are interested in getting one I can add it to my order since prices go down significantly with quantity. I wasn't wanting to get into kitting since qty savings isn't that much or assembling boards. The goal will be to only use parts that are hand solderable. I was looking at free or very low cost PCB packages so people can modify the board if they desire. I used Kicad http://www.kicad-pcb.org/display/KICAD/KiCad+EDA+Software+Suite for the last board I did a number of years ago. It was somewhat clunky but since the board isn't too complex it should be usable. May be better now. The other option I saw are http://www.geda-project.org/ (PCB), http://www.designspark.com/, and http://www.freepcb.com/ (last update 2010?) And online tools (with risks of poof or site term changes) https://upverter.com/ http://123d.circuits.io/ Anybody recently used any to have recommendations or know of others I should look at? I'll do a separate posting to talk about board features when ready to start. I am planning normal edge connectors for emulator so standard cables can be used though it will drive up the board price. Also use proper drivers etc.

On Thu, Jan 16, 2014 at 07:15:21AM -0500, Steven Hirsch wrote: And that will depend a lot on if enough interest develops around it to encourage me to do more with it than I have stated or even better if people contribute. Little less interest shown than I expected though its still somewhat vaporware so may not be a good indication. We will see when I release the other half of the code and start discussing the PCB. Thats when interest/usage will determine how much further it goes. I noticed that deploying from my test site to external didn't quite work right. I have fixed that the code directory wasn't browsable and display problem with the instructions.

On 1/16/14 6:27 AM, Al Kossow wrote: If you're designing a file format, you should look at this: http://www.fadden.com/techmisc/file-formats.htm

On Thu, Jan 16, 2014 at 10:21:04AM -0800, Fred Cisin wrote: Or use in-place under emulation? John Wilson D Bit

On Thu, Jan 16, 2014 at 10:21:04AM -0800, Fred Cisin wrote: What I currently plan to support is saving the raw transition data, decoded sector data, and MFM clock and data bit stream. The first is because it maintains the most information on the original disk and can be reprocessed later if decoding has problem. The second is useful for extracting contents (Linux loopback mounts/emulators that use straight sector data) though may be limited due to insufficient information on how to interpret the contents (RD53 thread, one of my drives has two cylinder 152). The last format is used by the emulator. If people have an actual use of other formats I can look into supporting them. Currently I'm looking at MFM hard drives so the sizes/rates are different though the issues similar. The hardware would have no problem with floppies if I put the proper connector on the PCB. I though that there were sufficient existing floppy projects. I don't want to add any floppy support if its just going to split the users between projects so neither are large enough to stay viable.

On Thu, Jan 16, 2014 at 08:22:10AM -0800, Al Kossow wrote: Stump format is probably better for having a routine to pull out a track for viewing in that format than trying to use for storing the entire disk transition data. Fadden has some good ideas. Looks like I will rework my format to something reasonable since it looks like there isn't a good existing format.

On 1/12/14, 12:21 PM, Paul Koning wrote: We're probably in a similar "place". When hand soldering a tssop or tqfp sort of thing and it is going great, it is great. When it goes bad, it is really bad, and sometimes I've ruined a board trying a repair. I have since tried reflow, manually managing the temp (using a thermocouple on the board, and having done some test runs to understand the toaster oven) and it is more consistent. It seems a little magical, which can be scary. I haven't 100% switched over, but I think I will. I'd love to hear that someone is having success with bga with toaster reflow. Ryan

The problem with BGA work/rework is to make sure the IC sits on the right position while you apply heat. I did a revolution on Xbox360 repair with that: You can use "positioners" made from silicon rubber, the same pink type you use on heat spreaders or processors heatsink. You cut a square on one of the corners and put it on the corners of the chip to stop it from moving. So you can apply heat. --- Enviado do meu Motorola PT550 Meu site: http://www.tabalabs.com.br ----- Original Message ----- From: "David Riley" <fraveydank at gmail.com> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Sent: Sunday, January 12, 2014 9:27 PM Subject: Re: "A DiskVaccuum For Obsolete Disk Formats"

On 01/12/2014 03:59 PM, Terry Stewart wrote: Tez, If you can hook up an 8" drive to a PC (use John Wilson's FDADAP if you want it simple--but you can also wire your own cable), you can use Dave Dunfield's ImageDisk to do the job. No special hardware required, other than a PC controller that can also handle FM encoding--there are programs to test that. Panasonic tended to rely on standard modulation (FM/MFM). Should work on DOS just fine. --Chuck

On 01/12/2014 05:23 PM, Terry Stewart wrote: Yup, MFM--only a few early systems wrote in MMFM (e.g. Intel MDS)--and they were pretty much sui generis--their scheme of address marks, etc. wasn't the same as another vendor's MMFM (I think some HP systems used MMFM as well). The so-called IBM System/3 double-density uses FM on the first track and MFM on the remainder. If you want, you can call it a 5.25" 1.2M drive in your BIOS, but tools such as ImageDisk don't use the BIOS anyway--it's all direct port I/O. The only gotcha to be aware of is that many 8" drives require +24VDC for their positioners and the like. But then, you're a TRS-80 owner as well, right? So you should be aware of that. --Chuck

On 01/12/2014 06:36 PM, Chris Pye wrote: Don't let the term "double density" confuse you--basically the coating's the same for all 8" floppies. What differs is the position of the index aperture in the jacket. Worst case, you might need to punch a hole in the jacket in the correct position. The thing about "double density" (MFM) and "single density" (FM) is that the maximum number of flux transitions per unit distance on a track is exactly the same in both cases. In FM, there is an explicit clock pulse accompanying every data pulse. In MFM, the number of pulses are reduced, as it's possible to infer a clock pulse, so long as a set maximum space between pulses is observed. So it comes down to what the drive thinks it is--and that's specified by the position of the index aperture. Simple and reliable. FWIW, it's also possible, using the right drive to use hard-sectored media as soft-sectored. That is, you can jumper many 8" drives to separate the index pulse from the sector pulses and place only the index pulse on the INDEX output. In most cases, you can use soft-sectored media without re-jumpering the drive. So don't throw those 8" floppies out! --Chuck

On 01/12/2014 08:18 PM, Chris Pye wrote: Have a look at http://bitsavers.informatik.uni-stuttgart.de/pdf/3M/3M_Diskette_Reference_M… Some very good specs there. Has anyone a stock of the old Memorex 650/Vydec media? Just curious. --Chuck

On Jan 12, 2014, at 9:51 PM, Al Kossow wrote: I have one used disk of unknown provenance. No drive. I know who I got it from and I'm sure he had it simply as a curiosity. ok bear. -- until further notice

On Mon, 13 Jan 2014, Terry Stewart wrote: In general, an 8" drive corresponds reasonably well to a "1.2M" 5.25". In fact, the "1.2M" was apparently intended to be an 8" drop-in replacement. The first "1.2M" that I got had a 50 pin connector! Alas, they then deviated a little, so there is still some cabling and jumpering to contend with. For reading files off of them, you can presumably ignore some things, such as "track 43" signal. Exactly. For slurping up sectors, ImageDisk will probably do fine. Then you can manually reassemble files. I never implemented any of the Panasonic 8"/1.2M formats in XenoCopy. Check with Chuck about 22Disk. -- Grumpy Ol' Fred cisin at xenosoft.com

On Jan 12, 2014, at 18:18 , Steven Hirsch <snhirsch at gmail.com> wrote: Sounds like that Kryoflux that I bought... I should have read the fine print more carefully. -- Mark J. Blair, NF6X <nf6x at nf6x.net> http://www.nf6x.net/

Thanks guys that's really helpful. I'll put the project on the "to do" list among other queued projects I have to do once I finish these video remakes. I'm not sure when it will get done, but I will certainly take a look at it at some point. Terry (Tez) On Mon, Jan 13, 2014 at 3:18 PM, Steven Hirsch <snhirsch at gmail.com> wrote:

At 05:05 PM 1/12/2014, Ryan Brooks wrote: By some coincidence, I have another window open to Amazon where I was looking for a rework station of the handheld variety. Many seem quite inexpensive. Which one should I buy? - John