- vcf-midatlantic - lists.vcfed.org

Re: [vcf-midatlantic] How To Geek article on floppy data recovery
by gsteemso 10 May '20

10 May '20

Hi all, >> On May 8, 2020, at 2:45 PM, Herb Johnson <hjohnson(a)retrotechnology.info> wrote: > > So, Gordon S. writes, something like this. He buys-in, that these > floppy-recover solutions, are made from currently available hardware, > but that hardware goes away over time. So, he says, why not implement on > widely available and well-sourced hardware? Yep, pretty much. > Well, I reject the limitation "cheaply". > That constrains any modern > solutions to the hell of rapid obsolescence and proprietary solutions. > That's the current strategy. I'm being blunt but brief. At $10, $20 > single-board single-chip solutions, how does any hobbyist outdesign > *that* with more persistent hardware? *cough* Uh. I must apologize -- I was a bit sloppy in my wording, and should have written "inexpensive" there. By "cheap" I only meant "less expensive than buying, restoring, configuring, and operating an obsolete peecee for the same purpose". I quite agree that trying to do anything worthwhile with inadequate materials is a fool's errand. > The vintage hardware interface, is either a floppy drive for data > recovery; or a floppy drive controller, for diskette emulators (not > discussed but the complimentary device). Well, po-TAE-toe, po-TAUGHT-oe, > to a first order. That's not the hard part. I was fairly certain that would be the case, but it never hurts to check my assumptions. As you point out, if you go back a few years floppy controllers were not monolithic -- which (I infer) meant they did not necessarily present a wholly consistent interface to whatever host system was involved. A bit further back than that, there wasn't even a standard interface to the _drive_. How flexible _does_ a floppy controller have to be for maximal usefulness? > On FPGAs, and the hard part. [...] it comes down to the design practice, of massive > oversampling of floppy data streams, to extract arbitrary-rates of > binary data relatively fast. [...] So: one ether > borrows cheep ARM-class devices that do that, or cheep FPLA devices > which do that, or both. Because of that "cheap" constraint. Shrug. > > [...] the cheat is to sample like hell and let > post-1990's computers sort out the results in software. Fair enough. True. This all looks simpler in my eyes than I've been getting the impression is assumed, though. If the goal can truly be reduced, in hardware terms at least, to recording a high-resolution image of the disk's magnetic state -- why in the heck is that considered so challenging? Please check my reasoning here... I figure that current incarnations of 6502 and z80 CPUs are more than an order of magnitude faster than the first ones were. A parallel I/O chip to bit-bang the stepper motor controls is a _commodity_ item, as are ADCs to digitize the signal from the drive head. The rest is just dumping the digitized data into a buffer, and we all know that widely-used disk-image formats can remain actively supported for decades. Put a dirt-simple, old-school serial port on the wretched thing to control it -- they've been introducing "better" replacements for 40 years, and we still have RS232 et al because they were ubiquitous -- and voila. What am I overlooking, here? > I appreciate Gordon's point, that functionality in modern devices is a > matter of programming, and reprogramming. That's fine, for those who > enjoy modern embedded programming. This! This right here. Why is _every_ solution to this stuff I've seen done with some microcontroller? In a case like this, simpler is, well, _simpler_. We have, and maintain, and in many cases can _build_ hardware that works exactly the same as it might have 40 years ago, at four or five orders of magnitude lower cost. Is there really any hardware tinkerer on this mailing list who would resist designing something around (say) a 65C02, on the basis that there'd be no support for it in 5 years? Try and say _that_ about the FPGA of the week. > But when the hardware to be > programmed changes "too much"; the old software becomes obsolete. > Yesterday's FPLAs can't be programmed with today's FPLA tools. The codes > are changed too. The binaries are useless, even proprietary. That was my > point! And mine! This sort of conversation has been called "being in violent agreement" by a friend of mine. *grin* > [...] The 1990's solution - the Catweasel, an ISA or PCI > bit-sampling controller on PC's? Last I checked, there were five-six > "installation solutions" for running that puppy. Surprisingly, each > developer came up with their own software to drive it. Go figure. [...] That thing sounded great in principle... but getting one _and_ a host system which could actually run it was far beyond my means at the time, and the entire project was long-out-of-production unobtainium by the time that changed for me. The whole experience left a very foul taste in my mouth. > So: walk through this with me. What floppy control hardware is pretty > much standardized, available, and stable; year after year and even into > decades? and what software to support what software to drive it, has > those qualities? Answer: XT/AT/386 class PC's and MS-DOS. And that's why > solutions like "Imagedsk" / MS-DOS / ISA floppy controllers / IMG files > just keep on workin'. Yep. But if you never used one, never had a reason to get used to them, and really don't enjoy fighting with one to keep it operational, I personally feel that an imaging station built around one does not enhance the fun of retrocomputing. YMMV. > But they don't work for 68K Mac disk formats, Apple II disk formats, > etc. etc. Well, mostly. There are a handful of really clever programs that basically take over an older pc's floppy controller at the lowest possible level and do unnatural things to it, with impressive results; I vaguely recall using one called "Omniflop", or something to that effect, that was able to read & write Commodore 1581 floppies and -- IIRC -- read but not write an 800K Mac floppy. If you had a compatible FDC the thing could do a surprising amount -- though, as you point out, not everything. > [...] Sorry for the long lecture, I got a real question and it took time to > answer it. Hope this did that. It did indeed! Like all good explanations, it got me to think through just what my assumptions are -- and, potentially, what assumptions I ought to make instead. Regards, Gordon S.

1 0

Geeks, retro-geeks and curmudgeons - a reply to Dr. S100
by Jack Rubin 09 May '20

09 May '20

Hi Herb - Hard to reply directly to your post since I only get the vcf digest, but a couple of points re new modes of disc (I'm an HP fan) imaging. 1) The flavor-of-the-day MCU or whatever isn't as important as maintaining accessible disk images and metadata. Flux level transcriptions weren't really practical when Dave Dunfield was building his ImageDisk system, so we should be thankful for all the extra CPU cycles available to us today, especially in a $15 package. 2) The approach is a little different but the philosophy is the same - for ImageDisk stuff, I still have a Dell 486 with all the right stuff, including an FDADAP and a Thinker Toys 8" floppy, but I also have a couple virtual machines with the proper toolchains installed to control a few Arduinos and PSoCs for the new stuff that demands a full software ecosystem beyond the hardware. More important, today's cutting edge developers can still read (and write?) .imd files. I was thinking about this last night as I was installing and configuring all the stuff necessary to start working on my first Verilog project. It took me a lot longer to get the point where I could blink a light on the demo board than it would have to reconfigure a CP/M bios for a new serial card and sysgen a new system. Be well and stay safe, Jack

2 1

speaking of end times
by Bill Degnan 08 May '20

08 May '20

Ebay listing for an Commdore C128D "new in box" (more or less) https://www.ebay.com/itm/Vintage-Commodore-128D-Personal-Computer-NEW-IN-BO… $1600 and rising. Also there is a DEC LINC 8 north of $9000 right now. Bill

6 10

Re: [vcf-midatlantic] A sign of the End Times ...
by Christian Liendo 08 May '20

08 May '20

Well my 6501 cost me a lot of money, my 4004s not so much On Fri, May 8, 2020 at 1:59 PM Bill Dromgoole via vcf-midatlantic <vcf-midatlantic(a)lists.vcfed.org> wrote: > > 6501’s? > > > From: Christian Liendo via vcf-midatlantic > Sent: Friday, May 8, 2020 1:16 PM > To: vcf-midatlantic > Cc: Christian Liendo > Subject: Re: [vcf-midatlantic] A sign of the End Times ... > > Still cheaper then 6502s > > https://www.ebay.com/itm/Early-MOS-MCS-6502-cpu-chip-white-ceramic-gold-leg… > > https://www.ebay.com/itm/Rare-white-MOS-MCS-6502-cpu-chip-with-gold-legs-Us… > > Seriously though something happened where they all shot up in price. >

1 0

A sign of the End Times ...
by Herb Johnson 08 May '20

08 May '20

https://www.ebay.com/itm/c4004-intel-central-processing-unit-vintage-cpu-1s… What other captions could one write, about this auction of nine ceramic-gold 4004 processors? Regards I guess, Herb -- Herbert R. Johnson, New Jersey in the USA http://www.retrotechnology.com OR .net preserve, recover, restore 1970's computing email: hjohnson AT retrotechnology DOT com or try later herbjohnson AT retrotechnology DOT info

8 7

Re: [vcf-midatlantic] How To Geek article on floppy data recovery
by gsteemso 08 May '20

08 May '20

On May 8th, 2020, Herb J. wrote: > This reply is long, because I'm arguing in opposition, and that means I > have to make a case about, and explain about. But I'll save some people, > some time. I"m going to fuss about these microcontrollers becoming > obsolete. If you don't care about that, save time and stop reading here. [Herb's cogent argument elided here] > And in closing .... > > The reason I'm familiar with this kind of "these go obsolete" arguments, > is because I've seen this show before. Over the last few decades, > various modern means to read ancient floppy diskettes have been > produced. They have become in-favor and discussed and distributed. Then > the developers lose interest; then the users lose interest; and they go > out of production and use. Over geologic time (several years), these > things simply come and go. > > So the vintage computers remain, but these modern devices do not. That's > about as simple as I can put the argument. I can't materially dispute any of this; in fact, it neatly lays out something that has bothered me for years without my having been able to work out why. The obvious next question, then, is -- to borrow the words of Charles Schultz -- "Now that we know that, what do we do?" It looks to me as though the common thread, amongst all of these unintendedly ephemeral solutions, has been their use of "easily available" hardware which failed to stay that way. Obviously, then, solutions of this type must be implemented on hardware which is widely available from multiple independent sources, _and_ will be straightforward to substitute for when that eventually does change. We use this stuff in support of systems which remain usable, if not always all that use_ful_, for decades. We already know what stays around, or at least remains well-documented and -supported. By sheer weight of installed base, it would be very hard to lose all support for x86 or 6502 software. Equally, despite their clumsiness, I find it very difficult to believe that we will suddenly become unable to substitute newer devices for EPROMs; hell, such substitutes are already made by at least two unrelated sources just amongst the retrocomputing community, let alone industry at large. The only real irritant, then, becomes working out how to cheaply do whatever it is these other projects are using FPGAs for. Those are the parts that get updated whenever someone works out a better technique, but... as a general rule, the interface to whatever vintage hardware is more or less invariant, correct? That would mean the alterable functions can be carried out in software rather than in (redefinable) hardware. Flash updates are still flash updates, regardless of whether they contain computer programs or FPGA configuration files. Can anyone poke holes in this? Gordon S.

1 0

Virtual Computer Museum Docents Wanted!
by rar 06 May '20

06 May '20

Did you ever want to be a museum docent or curator? Here is your chance! We are making a virtual tour of the System Source Computer Museum. Here is the beginning: https://museum.syssrc.com/tour/index.html I have tagged a handful of objects. Would you create (or submit) great audio, video, or web pages about any of the artifacts in the museum? I'll review and post! Thanks. Also, save the date for a VCF repair workshop November 14th and 15th in Hunt Valley MD. Bob Roswell broswell(a)syssrc.com<mailto:broswell@syssrc.com> 410-771-5544 ext 4336 Computer Museum Highlights<http://museum.syssrc.com/> [syssrclogo_38years]

3 2

How To Geek article on floppy data recovery
by Jeffrey Brace 02 May '20

02 May '20

https://www.howtogeek.com/669331/how-to-read-a-floppy-disk-on-a-modern-pc-o… -- ========================================= Jeff Brace Vice President & Board Member, VCF East Showrunner Vintage Computer Federation http://www.vcfed.org/ jeffrey(a)vcfed.org

1 0

Zenith I/O board
by Mike Loewen 30 Apr '20

30 Apr '20

I have what looks like a Zenith 4-port serial I/O S100 board: http://q7.neurotica.com/Zenith_front.jpg The Z100 Technical Manual mentions a Z-204 Multiport Input/Output board: could this be the one? Does anyone have a manual? Mike Loewen mloewen(a)cpumagic.scol.pa.us Old Technology http://q7.neurotica.com/Oldtech/

2 1

Another C64 Fastfingers MIDI Demo
by Jeffrey Brace 29 Apr '20

29 Apr '20

Dan Laskowski posted another video on his C64 MIDI software demo: https://youtu.be/QLgzjaVQE34 -- ========================================= Jeff Brace Vice President & Board Member, VCF East Showrunner Vintage Computer Federation http://www.vcfed.org/ jeffrey(a)vcfed.org

1 0