On 2/2/21 7:18 AM, Al Kossow via cctalk wrote: Uh, I think over the decades, I've contributed a bit, no? I recently made my own Catweasel source code public, for example. I've helped out the guy with the fluxengine puzzle out a couple of formats, including the Brother 240K one that few seem to have sussed out. When I last proposed the STM32F407, I was met with "Oh, but the Blue Pill is cheaper". Okay, use the Blue Pill, but my code won't work with it. Not once has anyone contacted me and said "I'd like to try my hand at doing this, what can you tell me?". I've described the methodology of using an MCU elsewhere several times. And then there are 22Disk, Anadisk, Teledisk and specialized drivers of PC Yore that apparently nobody thinks that I originated. Anyone want to know why we sold off Anadisk and Teledisk 20 years ago, along with our specialized forensics software? Because we were getting bombarded with support questions (Sample: "I have game xxxx, why won't Teledisk make copies?" and later "Anadisk doesn't run on my USB drive".) while we'd maybe get a registration every one or two months. When offered money for the product rights, we jumped at it. We held onto 22Disk because there was the most public support for it--and we could sell it into the industrial PLC community. If someone really would like to help out, give me some hints on repairing a Matsushita LF-5010 WORM drive that won't mount a disc. --Chuck

I am still using a Cateweasel mk 1 and would be very interested in studying your source code. Do you have a URL?

On 2/2/2021 11:51 PM, Peter Corlett via cctalk wrote: For capture and writing (if that's part of the design) I heard there's a dedicated coprocessor for the GPIO pins.? It might be useful for offloading some of the proccessing from some external circuitry to do the capture or output. I don't know what's included for the capabilities.? And apparently since the chip is new, there's only assembler programming for it now. There's a video comparing the Pico, ESP32, ESP32-S and Blue Pill. The latter was a bit low in resources compared to the others. I'll try to find it and post it if anyone's interested. thanks Jim

Yes, I noticed the usual suspects are out of stock. Need to look further. My reaction was similar. I like the dual CPUs, that means one could do hard real time stuff like wiggling I/O lines (for example DDCMP at a megabit per second) while the other does buffer management and talks USB protocol. I didn't even realize there's a small I/O coprocessor, that's neat. The TI engine in the BeagleBone Black has that sort of thing (a much larger one) which seems very useful if the job is particularly hard. David Gesswein made great use of that for hard drive emulation. But that's a much larger and more expensive solution. paul

On 2/2/21 11:51 PM, Peter Corlett via cctalk wrote: a small performance list of STM32 parts and where they are used STM32F103C8T6 72MHz M3 64K Flash 20K RAM FS Original blue pill STM32F411CEV6 100MHz M4 512K Flash 128K RAM FS Latest WeAct black pill STM32F407VET6 168MHz M4 512K Flash 196K RAM HS Board Chuck likes STM32F730x8T6 216MHz M7 64K Flash 176K RAM HS Eric's GW / GW Lightning

I'm curious as to how the sampling code looks. Do you use the timers? Dwight ________________________________ From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Mattis Lind via cctalk <cctalk at classiccmp.org> Sent: Wednesday, February 3, 2021 5:01 AM To: Al Kossow <aek at bitsavers.org>; General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org> Subject: Re: Greaseweazle Den ons 3 feb. 2021 kl 13:25 skrev Al Kossow via cctalk < cctalk at classiccmp.org>: The performance difference between the STM32F103 and any of the M4 (and M7) chips is even bigger (than what the MHz tell) since there is a small cache in the M4 (and M7) called ART which is intended to give close to zero wait states when reading from flash. The STM32F103 has 2 wait states on flash reads when running at 72 MHz. Unless you put code the code in RAM there will be a performance hit on the 103. Unfortunately RAM is a scarce resource on the 103 as well so you have to plan well to do that. If one wants more buffer memory there is also the STM32F407ZET board which uses the bigger 144 pin chip. On the back of those boards are pads for a ISSI IS62WV51216 chip 512k x 16 chip. What I think is kind of strange with the WeAct board is that they are not identical in pinout to the blue pills. On one side all the pins are shifted on step. I have no idea why they designed it that way.

Den ons 3 feb. 2021 kl 18:00 skrev Chuck Guzis via cctalk < cctalk at classiccmp.org>: So you store a full track worth of data and then write it to the SD-card. Then move the flux-length data over to a PC and do post processing there, right? Isn't there performance in the CPU to do the actual decoding as well? FM, MFM, GCR or whatever into data. Find marks, check CRC and all that stuff? /Mattis

On 2/3/21 9:43 AM, Paul Koning via cctalk wrote: In the real world, this is fundamentally wrong. You need to know you haven't captured garbage while the disk is still in the drive and you want to minimize the time you spend dwelling on an individual track. Magtape is a completely different issue where you attempt to get as much information as you can before the tape sticks, tears off all of its oxide, or the head clogs. Even if it doesn't stall, the motor can drag and goofs up the tape speed. This is an issue for NRZI media. We (CHM) have had amazing luck recovering 50+ year old 7, 9 and Whirlwind tapes with analog recovery. See Len Shustek's talk at VCFW 2001 about the recovery software. There is some hardware work going on to recover double-sided floppies using A/D channels digitizing both sides of the disk simultainiously, and recovering 4-track pre-QIC cartridge tapes the same way.

Den ons 3 feb. 2021 kl 18:55 skrev Al Kossow via cctalk < cctalk at classiccmp.org>: I have been looking into designing a 12 bit A/D with a differential amplifier in front which would sample at 6, 12 or 24 Mhz delivering the raw samples to the host over USB (FX2LP chips are good at pumping USB data). In this way I have all the info I can get and then applying various algorithms to the signal is the task of the host. If the host is quick it might even be able to do processing in real-time? ( https://github.com/MattisLind/AnalogFluxReader) Need to work on the layout now.

Fair enough, but that means your real time processing needs to be sufficient to know where the tracks are. And if the media are in bad shape, you may in fact want to capture each track N times at slight offsets from the nominal position, then do signal processing to recover the data as best you can. Come to think of it, the techique of reading 1/2 inch tape with 36 track MR heads is somewhat similar: you get multiple readings of the same nominal data track and can use the additional data to help with recovery. I will, thanks for the pointer. I expect to need this in the not too distant future (for reading 1/2 inch 10 track tapes). paul

Which might mean either (a) what I suggested is in practice not needed, or (b) existing software treats as unrecoverable disks that could be recovered with more sophisticated tools. I have no idea which is correct. Yes, I was thinking of that issue while looking into how a 10 track tape would look to, say, a 16 track instrumentation recorder head. The picture looked marginal at best. paul

Some "stupid ideas": In line with trying to minimize possible damage during analysis of the format, try: Use a 96tpi drive. Try to read cylinder 72. MOST OS's are aware of the lower reliability of inner tracks, and will try to write the data to the outer (lower numbered tracks) Therefore, if the oxide comes off on your head, then it is less likely to be what you needed. See if you got a valid read. USUALLY (not always), that cylinder will have the same number of bytes per sector, sectors per track, and heads per cylinder as the other tracks. If the track read identifies itself as track 36 (look at the CHRN fields if there is an IBM/WD style sector header) then it was presumably written on a 48tpi drive. If it identifies itself as track 75, then it was probably written on a 100tpi drive. Switch to a 100tpi drive (MicropolisII, Tandon TM400-4M, etc.) Then try cylinder 36. If the disk had been written on a 48tpi 35 track drive (SA400/SA390 used on TRS80 and Apple), then cylinder 72 of a 96tpi/cylinder 36 of 48tpi would not have been used. If cylinder 72 does not read, but 36 gives a valid read that identifies itself as track 18, then it is most likely Watch out for re-used disks. If a formatted 5150 disk was reformatted by a single-sided machine, then you will have the single sided format on side A, and PC format on side B! Similarly, a used 40/80 track disk reformatted by a 35 track machine will have different formats from the residual formatting on the high tracks. Every even numbered cylinder of a 96tpi drive corresponds to a cylinder of a 48tpi drive. Every multiple of 24 cylinders of a 96 tpi drive corresponds with a multiple of 25 cylinders of a 100tpi drive. If you succeed in reading the track identification (CHRN in sector header in IBM/WD formats), then you have a clue of the tpi of the source drive. If you managed a successful track read, then knowing the tpi, number of heads, bytes per sector, sectors per track, will let you avoid some of the otherwise unsuccessful read attempts (such as unnecessary revolutions of the media trying to read between tracks on 48tpi) Is it worth the effort to modify the drive? Reading both heads at the same time would halve the number of revolutions needed of deteriorating media. I had some 8" diskettes for which I could get a successful read IFF I pushed gently on the side of the head with my finger. I always intended to try to add a micrometer lead screw to the head positioning, but never got around to it. Presumably, if the amount of offset from "correct" position is determined, it would probably be the same for most/all disks written with the same source drive. Howzbout analog positioning? Amlyn claimed to use "analog positioning with phase locked loop feedback" to find the tracks. Did they? If you have some semi-skilled assistants (interns, grad students, etc.) then some of the catch up of the backlog could be handed off to them for disks that aren't as likely to be damaged by a read attempt disks with a known/presumed/likely format If you have a group of workstations (and a swivel chair), you could then step-in only when the assistant(s) encounters a problem.

On 2/3/21 9:36 AM, Mattis Lind wrote: Sure, more than enough. But the MCU has to be programmed to do these things; when dealing with an unfamiliar or problematical sample, it's easier to move the data to the Big Machine and play with things there--and there's a "permanent record" of the sampling data. Were I dealing with lots of known samples, I'd probably include the deciphering routines. But in the end, the recovered data has to go back to the customer, so it's going to wind up on the Big Machine anyway. I incorporate a function on the MCU that attempts to find the "peaks" in the spectral information, just as a way to tell if I'm doing things right. Same for verifying the drive spindle RPM. --Chuck

I haven't used RPi at all, since when I looked at it some years ago the SOC technical information was secret. Contrast the BeagleBone, for which there is a 5000 page manual. In any case, for work like this an Ardiuno might be sufficient and quite possibly easier to use. I've used the ARM based Arduinos, they have quite a lot more memory, faster execution, and native USB. In fact (if you should need it for something else) host side USB, not just device side. The Adafruit "Trinket" is great for cases where not much I/O is needed; there are a variety of others that have a dozen or so I/O connections, all for $10 or thereabouts. paul

Nice to know. Thanks! That makes it like Arduino. Time for some more studying... Exactly. Broadcom had all sorts of strange notions. The BBB uses a TI chip, which was always fully documented. paul

On Feb 2, 2021, at 7:58 AM, geneb via cctalk <cctalk at classiccmp.org> wrote: I think Al has contributed enormously to the archival and preservation of our industry history, which is exactly why I pretty much always want to hear more from him on anything related?and why my ears perk up when he says there's a better way to do something. Also, I'm 100% with Al about not siloing projects _on social media sites like Facebook_. They're terrible for technical projects because they're specifically designed to surface "engaging" social information and push further engagement, rather than to actually preserve chronology, or to make it easy to refer back to or link to anything at all in the past. There is only forward, and only at the whim of The Algorithm. Mailing lists are by far the best choice when it comes to collaboration on technical projects, with tools from project hosting sites like SourceForge, Bitbucket, GitLab, and Github a close second. -- Chris

On 2/3/21 1:00 PM, John Foust via cctalk wrote: "Reasonably quickly" is a relative term. I've got samples here that I had to cogitate over for a year. Admittedly, these were items that were sui generis, but "quickly" was not in the picture. Perhaps with some choice pharmaceuticals, my thinking speed could be improved, but I haven't explored that yet. You know--you get a disk that's thought to contain some information, the identity of the originating system is unknown; no Rosetta stones to be seen. For my purposes, clearly defined spectral peaks are the critical thing--and that's done on my MCU implementation. --Chuck

On Wed, Feb 3, 2021 at 3:20 PM John Foust via cctalk <cctalk at classiccmp.org> wrote: My one big complaint about the kyroflux command line thing is that it doesn't give a list of 'bad' tracks at the end so you have to scan the logs to make sure the reading worked. Of course, that's in 'sector mode' not in flux capture mode... I wouldn't think to do the latter unless I could also say "I expect this disk to be X format, please abort if that's not plausibly true" and also to use that to inform retries maybe, but I haven't thought through all the implications of the latter... Warner Warner

On Wed, 3 Feb 2021, Chris Hanson via cctalk wrote: I agree. Al, Chuck, ARD, (and many others). may not have the time, nor inclination, to do a full handholding tutorial or troubleshoot somebody else's problems. They have provided a wealth of information. I always learn something. Within any gripes they make are gems of indentification of problems and things that may need to be addressed. Such as the specific suggestions to try to check read validity as soon and quickly as possible to avoid unnecessary read attempts that further damage deteriorating disks. My gripes about the Greaseweazle documentation should be construed as "suggestions for improvement" :-) I thought that the Fluxengine documentation was a really quite good start. He humbly acknowledged things that he didn't know, actively solicited comments and suggestions, and compiled a really nice collection of some of the weird formats. (including a link to Chuck's F85 page)