Re: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
On Wed, Feb 20, 2019 at 11:40 PM Warner Losh via cctalk wrote: > At least on the Rainbow the floppy chip is kept in MFM mode all the time, > unless you've written something to hack it to read alien disks. And modified the hardware. On the Rainbow the 'Dden/' pin of the floppy controller chip is tied to ground forcing said chip into MFM mode. -tony
Re: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
> Ability to read MFM data with FM headers (RX50) On 2/20/19 3:40 PM, Warner Losh wrote: The RX50's are MFM encoded. There's no FM anything on it, unless it's that way on all MFM diskettes. Other DEC diskettes may have done this, but RX50's are just higher track density, but old pre IBM-AT data encoding rate diskettes. At least on the Rainbow the floppy chip is kept in MFM mode all the time, unless you've written something to hack it to read alien disks. On Wed, 20 Feb 2019, Chuck Guzis via cctalk wrote: You're quite correct--I didn't notice the "RX50" until I'd posted. No, I was thinking (as probably was the OP) of RX02 double-density. That was my mistake. I wrote RX50, but I meant RX02. And, as Chuck pointed out, the MFM data within the sectors is not quite the same as the MFM encoding used by others. Sorry about that.
Re: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
On 2/20/19 3:40 PM, Warner Losh wrote: > The RX50's are MFM encoded. There's no FM anything on it, unless it's > that way on all MFM diskettes. > > Other DEC diskettes may have done this, but RX50's are just higher track > density, but old pre IBM-AT data encoding rate diskettes. > > At least on the Rainbow the floppy chip is kept in MFM mode all the > time, unless you've written something to hack it to read alien disks. You're quite correct--I didn't notice the "RX50" until I'd posted. No, I was thinking (as probably was the OP) of RX02 double-density. --Chuck
Re: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
On Tue, Feb 19, 2019 at 3:38 PM Chuck Guzis via cctalk < cctalk@classiccmp.org> wrote: > On 2/19/19 2:02 PM, Fred Cisin via cctalk wrote: > > > Ability to read MFM data with FM headers (RX50) > > It's not that simple. There's the matter of "DEC MFM" which encodes a > few bit patterns differently to avoid collision with FM headers. > The RX50's are MFM encoded. There's no FM anything on it, unless it's that way on all MFM diskettes. Other DEC diskettes may have done this, but RX50's are just higher track density, but old pre IBM-AT data encoding rate diskettes. At least on the Rainbow the floppy chip is kept in MFM mode all the time, unless you've written something to hack it to read alien disks. Warner
Re: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
On Wed, 20 Feb 2019 at 18:08, Eric Korpela via cctalk wrote: > > Don't forget hard sector CompuColor II, GCR, and variable speed GCR. :) Well, yes, OK, but one step at a time. Step 1: a generic USB floppy controller that allows 5¼" and 8" (and other standard Shugart-interface) FDDs to be attached to USB and seen by the OS on the system as floppy drives. That seems to be either coming or here. Step 2: some smart driver software for the above to enable weird disk formats that a standard WD FDD controller could read. Step 3: something very smart that enables weird non-WDD-disk-controller disks (e.g. Mac 400/800 kB and Amiga disks) that were written in fairly standard drives. Step 4 is when you get to all the non-hard-sectored drives and so on... -- Liam Proven - Profile: https://about.me/liamproven Email: lpro...@cix.co.uk - Google Mail/Hangouts/Plus: lpro...@gmail.com Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
Re: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
On Tue, Feb 19, 2019 at 4:39 PM Chuck Guzis via cctalk < cctalk@classiccmp.org> wrote: > On 2/19/19 3:40 PM, William Sudbrink via cctalk wrote: > > A design that can manage Ohio Scientific as well would be nice. > > Might as well add Victor 9000... > Don't forget hard sector CompuColor II, GCR, and variable speed GCR. :) -- Eric Korpela korp...@ssl.berkeley.edu AST:7731^29u18e3
Re: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
Hello folks, I'm coming into this a bit late but a bloke called David Given is working on such a floppy controller right now, it's called Fluxengine and is based around a Cypress microcontroller that connects directly to a floppy drive and is driven by USB. Early days as yet in that it supports IBM formats plus Acorn BBC DFS/ADFS but since all the decoding is done in software pretty much any format can be added and David is looking for examples of eg C1541 floppies from the C64 as well as others. https://github.com/davidgiven/fluxengine -- adrian/witchy Owner of Binary Dinosaurs, the UK's biggest private home computer collection? t: @binarydinosaursf: facebook.com/binarydinosaurs w: www.binarydinosaurs.co.uk On Tue, 19 Feb 2019 at 23:40, William Sudbrink via cctalk < cctalk@classiccmp.org> wrote: > A design that can manage Ohio Scientific as well would be nice. > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > >
RE: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
> By the time that I got out (for other reasons), XenoCopy had not been > profitable for a while. THAT handled files, but the user still had to > deal in other ways with modifications that they needed to the content > of > the files. True, but at that point that is the user's problem. The idea is simply to make it easy to get the file or make backups. What someone would do with it after is their prerogative. > For your 286 machine(s) wouldn't you like a combination of Compaticard, > CatFerret, and option board, to use instead of the existing FDC board? Yes. Which is what I keep hoping someone would make. :) As opposed to a floppy emulating TSR. > If this were USB, then it could add floppy back onto some more "modern" > machines. If USB, with appropriate "modern" drivers, no reason why > this > couldn't be used for MOST machines. True, but you need one hell of a SW driver. Also can you even install unsigned drivers on Win10? > It could have. But Brown? (not sure whether I remember his name right) > correctly realized that he could make money doing Mac, but there wasn't > enough additional money with Apple2 to even necessarily reimburse him > to > hire those programmers. If I recall correctly the DOB came out in 1987 so the Apple II market was still pretty strong. I have an older (don't recall how old) but probably first series DOB board and on the box they really don't emphasize the Mac disk aspect. That seemed to come later with the white boxes w/ the rainbow logo. I had always heard it was because the IBM copy protection market had fizzled out i.e. the new 5.25" HD disks and the 3.5" disks did not have disk based copy protection. The Mac thing was a marketing ploy to keep sales going. Interestingly according to Wikipedia the DOB could read both Mac and Apple disks. I don't recall that personally and I am not sure even if true if that applied to Apple II 5.25" disks. > FDADAP is a cabling adapter, plus generating the TG43 signal, which > would > be trivial to do with a conventional FDC. For READING (I hardly never > WROTE), I cabled my 8 inch drives to 34 pin. True. I have the same setup. However, most FDCs don't provide this (I am not counting proprietary FDCs like the Flagstaff cards). Even the XT-FDC project chose not to include the TG43 signal generation on their card. I can't imagine it would have added that much to the cost of the card and could have been simply optional components (i.e. only put on if you wanted/needed write capability). I am not sure if there is a technical reason for it or not but the Ultimate FDC should not only read but write 8" drives out of the box > Yes. FM adds 8" SSSD "Standard", TRS80 model 1 (although still > problems > writing some address marks), and a handful of others. Exactly! I mean I know the Vector 9K will be left out but one must make sacrifices. Seriously though the card I propose would cover 95% of most people's needs (archivist and preservationist aside). If the card could be made to work with Amiga and/or Atari Disks you would almost have nirvana for 99.999% of the users. Yes, a guy like Chuck who needs to recover some obscure format off of some obscure scientific machine will probably need something better/more powerful/and more customizable but a plebe like me? I would be perfectly happy and I wouldn't have to give up two or more slots in my PC to do it. > Pro-Lock relied on a physical defect on the disk. Both in terms of > getting an read error trying to read that track, but sometimes even > confirming that WRITING to that track also failed. I have never owned and Enhanced DOB board but my understanding was that it defeated Pro-Lock by reading a disk and saving information as to the bad sector/location. Then when you wanted to run the Pro-Locked disk it would simply load that info into the Enhanced DOB's memory and it would be served up when requested by the program. > But, is it really that hard to find the patches for the major programs? > I don't doubt your statement; I'm just surprised. What used to be Major programs are now relics of long gone time. > It used to be, that if I Googled XenoCopy, many of the hits were for a > patch to remove the copy protection from those early versions. Still > are! I just did this - first two hits are your site. Next two are for un-protection routines. I am not sure if the second one is legit but the first one is. However, it suffers from what I had described earlier. It is specific to version 1.09. So I would either have to have version 1.09 or somehow find it... Maybe I could write the author and ask for a copy ;) Frankly, at this point I am less interested in hunting down the one version that works, or crack that is not a virus or a crack being hosted on some seedy site with malware galore, or... you get the idea. I like having the old SW with the manuals and all so that I can actually figure things out and have something to refer to. That was one of the beauties of SW back
Re: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
With all deference to the real collectors, I don't see the objective here. The thing should be NEC 765 compatible? Why? What about non-NEC-based sytems (e.g. the bulk of CP/M and countless other systems that don't use an LSI controller)? Or those systems that permanently already have a controller installed? And you know--not all systems used disks with standard-length (i.e. power of 2) sectors. (e.g. Zilog MCZ) or oddball addressing schemes? How about those old Apple II floppy protection that manipulated the positioner current to land the head *between* tracks? And other than *reading* the things once, why are we trying to fool with decaying doughnuts of rusty dust? Sample the rusty rings, stash the data away for use by analysis. If amenable to emulation, write a floppy *drive* emulator to match. Otherwise, you've got the data. My take on this subject only--but then, I'm mostly concerned about *reading* dusty rust and preserving the information for future reference, not recreating the original scenario. A NEC 765 is pretty limited in what it can do, in the firmament of floppy formats--I don't even know how to tell it to deal with, say, 132-byte sectors. Thanks for allowing me to spout my nonsense. --Chuck
Re: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
I would like to see software for . . . THEN, I would like to see that software as . . . THEN, I would like to see that . . . On Tue, 19 Feb 2019, alan--- via cctalk wrote: What's stopping you from writing it? It's in the queue! Which is longer than my expected remaining lifespan. There are several aspects that I need to learn a lot more about. Alas, a few other things have greater urgency/priority, than completing what XenoCopy coulda/shoulda/woulda been.
Re: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
On 2019-02-19 19:42, Fred Cisin via cctalk wrote: On Tue, 19 Feb 2019, Ali wrote: Are we being a little sarcastic or serious? :) A lot of BOTH I would like to see software for flux transition hardware that would extract sectors. THEN, I would like to see that software as a subroutine, with an interface similar to INT13h. THEN, I would like to see that ROMable, either on a physical ROM, or loaded into RAM, with the INT13h vestor repointed to it. What's stopping you from writing it? -Alan
Re: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
Doesn't SuperCard Pro already do this? The hardware isn't open source, but the USB control protocol to read and write flux transitions on an entire track is open and well documented. And there are already several tools to exercise the protocol. Sure, one could replicate the hardware work for kicks, but that isn't the real heavy lift. Advanced tools for manipulating the flux images for low level encoding, high level format, and file system is the prize. The Amiga ADF disk tools project is a really good start... (supports dozens of formats beyond Amiga). -Alan On 2019-02-19 17:31, dwight via cctalk wrote: Actually, I'd like to see it just read/write flux changes + index marks onto a SD card for later analysis. Building all the smarts into the controller means that some formats will get missed. One can later write translation code for what ever format one has. Make this information open source, much of it is already in bits and pieces. Make sure it can read and buffer an entire track of data in RAM ( Gotek can't ). We no longer need proprietary hardware. There are a number of off the shelf controller boards capable of handing this. It would only need cables to match the drive. Dwight
RE: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
On Tue, 19 Feb 2019, Ali wrote: That would make for a very powerful tool but as you pointed out yourself how many users would learn to use it? Unless it is a simple driver that gets loaded and the user has to simply put in a couple of generic parameters, e.g. "device=c:\drives\emudsk.sys APPLE", and it is up and running most users won't be able to make use of it. By the time that I got out (for other reasons), XenoCopy had not been profitable for a while. THAT handled files, but the user still had to deal in other ways with modifications that they needed to the content of the files. Sure, a Wordstar file could be made into a generic text file by stripping the high bit. But converting WordPervert format codes into Weird format codes would have required another career. > My preference would be REAL MODE (DOS). As would mine but would a 286 be able to do it? And if you have a machine that runs real mode DOS why not make use of the HW that is there? For your 286 machine(s) wouldn't you like a combination of Compaticard, CatFerret, and option board, to use instead of the existing FDC board? If this were USB, then it could add floppy back onto some more "modern" machines. If USB, with appropriate "modern" drivers, no reason why this couldn't be used for MOST machines. > Match Point could be implemented in software on the Central Point > board. Great. Then if the DOB HW is duplicated then that part can be SW and no need to have Match Point HW duplicated. I am surprised the Copy II PC DOB card did not handle Apple II disks along with Mac disks. It could have. But Brown? (not sure whether I remember his name right) correctly realized that he could make money doing Mac, but there wasn't enough additional money with Apple2 to even necessarily reimburse him to hire those programmers. > CompatiCard was just an ordinary FDC, without the crippling corners > cut. True, but if you are building the ultimate FDC then you don't want crippling corners cut. So something functionally equivalent. Exactly. But, I want to make it clear that there is nothing SPECIAL about Compaticard; it's simply one of the best, but not unique. > SO, you are asking for FDC plus flux transition, but better > integrated, rather than flux transition hardware interrupting the > drive cable. By the time DOB came out, 286 normally had FDC combined with HDD, so my suggestion to integrate FDC with OB wasn't applicable. Yes! All on one card. Throw in FDADAP functionality to properly write 8" disks and you have a controller that handles most if not all IBM, Apple II, and Mac disks. FDADAP is a cabling adapter, plus generating the TG43 signal, which would be trivial to do with a conventional FDC. For READING (I hardly never WROTE), I cabled my 8 inch drives to 34 pin. As I understand it, in my limited way, having both FM and MFM should allow for many CP/M formats including SD. Yes. FM adds 8" SSSD "Standard", TRS80 model 1 (although still problems writing some address marks), and a handful of others. Will some formats be left out? Sure. GCR, hard sector, etc. My (and I think Chuck's) favorite example for weird is Sirius/Victor 9000. (80 track GCR, although with its own versions of CP/M-86 and MS-DOS!) Will it be as powerful as a Kyro Flux for archiving? Heck no. But will it let me pop in my original 123 disk and copy it for use with out too much hassle and work? Of course.? There are a few exceptions, such as Pro-lock.Well then you had the ENHANCED Deluxe Board. :) Not necessarily. MANY versions of Pro-lock used the same identical check code, so one "crack" beat a lot of them. But some of the better ones rewrote their own subroutine. Pro-Lock relied on a physical defect on the disk. Both in terms of getting an read error trying to read that track, but sometimes even confirming that WRITING to that track also failed. They called it a "laser fingerprint", because "a sweatshop where they scratch disks with a paperclip" doesn't sound as impressive. Similarly, my Prius has a "LASER CUT key". Yeah. Right. The one that I'm using right now was cut with a tiny side-mill bit and a pantograph. > But, in quite a few cases, people have disassembled (now illegal under > >DMCA!), found the vulnerabilities and >simply disabled the copy protection.? Yes but that is harder and harder to find. They were never public but each city had multiple BBSes offering such altered programs. And of course the other problems w/ this method is you are confined to the one altered version?? (even if you own a later version). Also there is no guarantee the alterations will not cause a bug that will crop up later due to a lack of total testing. I removed the copy-protection from my [legitimate] copy of 123. So that I could install it onto machines with different drives. Sorry, I don't remember where the patch is. But, is it really that hard to find the patches for the major programs?
RE: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
Fred,> Are we being a little sarcastic or serious? >:)>>A lot of BOTHJust making sure. ;)>I would like to see software for flux >transition hardware that would >extract sectors.>THEN, I would like to see that software as >a >subroutine, with an interface similar to >INT13h.>THEN, I would like to see that ROMable, >either on a physical ROM, or >loaded into RAM, with the INT13h vestor >repointed to it.That would make for a very powerful tool but as you pointed out yourself how many users would learn to use it? Unless it is a simple driver that gets loaded and the user has to simply put in a couple of generic parameters, e.g. "device=c:\drives\emudsk.sys APPLE", and it is up and running most users won't be able to make use of it.>My preference would be REAL MODE (DOS).As would mine but would a 286 be able to do it? And if you have a machine that runs real mode DOS why not make use of the HW that is there?>Match Point could be implemented in >software on the Central Point board.Great. Then if the DOB HW is duplicated then that part can be SW and no need to have Match Point HW duplicated. I am surprised the Copy II PC DOB card did not handle Apple II disks along with Mac disks. >CompatiCard was just an ordinary FDC, >without the crippling corners cut.True, but if you are building the ultimate FDC then you don't want crippling corners cut. So something functionally equivalent.>SO, you are asking for FDC plus flux >transition, but better integrated, >rather than flux transition hardware >interrupting the drive cable.Yes! All on one card. Throw in FDADAP functionality to properly write 8" disks and you have a controller that handles most if not all IBM, Apple II, and Mac disks. As I understand it, in my limited way, having both FM and MFM should allow for many CP/M formats including SD. Will some formats be left out? Sure. Will it be as powerful as a Kyro Flux for archiving? Heck no. But will it let me pop in my original 123 disk and copy it for use with out too much hassle and work? Of course. >There are a few exceptions, such as Pro-lock.Well then you had the ENHANCED Deluxe Board. :)>But, in quite a few cases, people have >disassembled (now illegal under >DMCA!), found the vulnerabilities and >simply disabled the copy protection. Yes but that is harder and harder to find. They were never public but each city had multiple BBSes offering such altered programs. And of course the other problems w/ this method is you are confined to the one altered version (even if you own a later version). Also there is no guarantee the alterations will not cause a bug that will crop up later due to a lack of total testing.-Ali
Re: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
On Tue, 19 Feb 2019, Paul Koning wrote: I' reminded of the Bordynuik tape reading machine that uses an MR head. Capturing analog flux levels at, say, 10x the nominal flux change density means all the rest is simply digital signal processing. That can be done in real time if you must, but much more easily in post processing using whatever tools and languages you like. As Al pointed out, at least an initial stage of analysis should be done real-time, or close to that, to determine whether the read seemed to have been successful. 'Course, that doesn't preclude later stages from also requesting a new attempt, if the data doesn't look good on further analysis. And, of course, using multiple machines, or just multiple processes, one system could begin processing, while another is reading more tracks. The reliability encountered would determine how much testing should be done before moving on, either to the next track? or the next disk? If errors are RARE, then there would be no cause to hesitate and hand off processing while moving on to the next JOB. If errors are FREQUENT (Al, Chuck, and I dealt with some that required dozens of attempts to get a successful read of a track), then that would caall for MORE processing before stepping to the next track or disk. FDC does a CRC "real time", and compares that with the value stored in the sector header.
Re: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
> On Feb 19, 2019, at 8:00 PM, Fred Cisin via cctalk > wrote: > > On Tue, 19 Feb 2019, Fred Cisin via cctalk wrote: >> As I see it, flux transition hardware COULD be all that is needed for >> hardware. Emulation of FDC could be done in software with flux transition >> hardware. > > That should read flux transition plus appropriate control signals for the > drive. Seeking tracks, turn on the drives R/W circuitry, etc. > Flux transition ITSELF is just making sense out of the pulses on the track. Rather than flux transitions, flux levels would seem even better. If the flux levels are sliced and reduced to square waves, you've lost a bunch of information that could have helped recover marginal data. I' reminded of the Bordynuik tape reading machine that uses an MR head. Capturing analog flux levels at, say, 10x the nominal flux change density means all the rest is simply digital signal processing. That can be done in real time if you must, but much more easily in post processing using whatever tools and languages you like. paul
Re: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
On Tue, 19 Feb 2019, Fred Cisin via cctalk wrote: As I see it, flux transition hardware COULD be all that is needed for hardware. Emulation of FDC could be done in software with flux transition hardware. That should read flux transition plus appropriate control signals for the drive. Seeking tracks, turn on the drives R/W circuitry, etc. Flux transition ITSELF is just making sense out of the pulses on the track.
Re: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
A design that can manage Ohio Scientific as well would be nice. On Tue, 19 Feb 2019, Chuck Guzis via cctalk wrote: Might as well add Victor 9000... It was in my original list :-)
RE: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
On Tue, 19 Feb 2019, Ali wrote: Are we being a little sarcastic or serious? :) A lot of BOTH I would like to see software for flux transition hardware that would extract sectors. THEN, I would like to see that software as a subroutine, with an interface similar to INT13h. THEN, I would like to see that ROMable, either on a physical ROM, or loaded into RAM, with the INT13h vestor repointed to it. Honestly, a sw implementation would be interesting but would it work on vintage hw? Or are you suggesting for use only with a modern system? My preference would be REAL MODE (DOS). But, for marketability, it would have to be WIN11 For example here is my dilemma: my stinkers, whom you have met, are getting old enough to want to mess with my stuff. *shudder* i mean cool! but I really don't want them ruining my one actual original disk for any programs I own. So what I do is make backup copies just like in the old days. And before someone suggests emulators, it is just not the same. I mean if we wanted to emulate everything why bother even preserving hardware?Problem is when we have copy protection, as many games or old SW do, then you need a Copy II PC board. I have one and they are fairly common but ridiculously expensive now a days. So it would be nice if the functions could be duplicated in an easy to use manner. Kyro Flux is powerful but not for everyone. I want an FDC that would cover 90% of the vintage hobby (i.e. Apple II, Mac, and IBM). An FDC that combines a CompatiCard IV with a copy ii pc deluxe and a Match Point card would cover all of the above plus then some.Just a thought ;D Match Point could be implemented in software on the Central Point board. I discussed Mac disks with Brown of Central Point, and told him that I didn't think that the regular option board could handle an adequate range of data transfer rates. Hence, he came out with the Deluxe, including some Macintosh disk software. CompatiCard was just an ordinary FDC, without the crippling corners cut. There were a few others that could do comparable things. SO, you are asking for FDC plus flux transition, but better integrated, rather than flux transition hardware interrupting the drive cable. A lot of copy protected software can be duplicated using flux transition. That was Centraal Point's target market for the Option Board. There are a few exceptions, such as Pro-lock. But, in quite a few cases, people have disassembled (now illegal under DMCA!), found the vulnerabilities and simply disabled the copy protection. Often, it is as simple as replacing a conditional JMP with an unconditional JMP or a NOP. The trick is knowing WHERE :-) Such "unlocked" programs are what you ideally want.
Re: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
On 2/19/19 3:40 PM, William Sudbrink via cctalk wrote: > A design that can manage Ohio Scientific as well would be nice. Might as well add Victor 9000... --Chuck
Re: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
On Tue, 19 Feb 2019, dwight wrote: Actually, I'd like to see it just read/write flux changes + index marks onto a SD card for later analysis. Building all the smarts into the controller means that some formats will get missed. One can later write translation code for what ever format one has. Make this information open source, much of it is already in bits and pieces. Make sure it can read and buffer an entire track of data in RAM ( Gotek can't ). As I see it, flux transition hardware COULD be all that is needed for hardware. Emulation of FDC could be done in software with flux transition hardware. First stage would be with minimal software, to save the track flux transitions in a file. Next stage, If and when a 765 FDC can be emulated. THEN, make the FDC emulation code loadable into RAM, and repoint the Int13h vector to it. (TSR) THEN, make new version that adds TRACK-READ (ala WD, NOT the multi-sector read in the 765) Then fine details, such as whether or not to implement (switchable) index pulse "flash blindness", inability to handle 128 byte sectors, etc. OR, that much could be done without full flux transition functions. But, if you DO retain full access to the flux transition data, THEN, add GCR decoding, and add that into the FDC emulation (so that Int13h/fn2 could read GCR sectors, etc.) THEN, add hard sector handling THEN create IFS (Installable File System), which is totally not connected with any of this, except when needed for non 765 compatible physical formats. That is what XenoCopy would have eventually become, IFF I were to have been able to continue. (Uniform did implement most of an installable file system for CP/M formats) The end-user wants to load their Epson QX-10 documents and Kaypro CP/M documents into Word. They don't want to know how it is done, nor go through the essential steps of reading alien sectors, processing alien file system to select appropriate sectors, AND convert word processor formatting codes from one word processor to another. Do you think that you could teach them how? XenoCopy transferred FILES; but left the content alone. So, YES, I did get people telling me that XenoCopy had "trashed the last letter of every word in the Wordstar files" I drew the line between transferring files V modification of the content of the files. You are drawing the line between flux transition data V sectors/file system/files/content -- Grumpy Ol' Fred ci...@xenosoft.com
Re: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
On 2/19/19 2:31 PM, dwight via cctalk wrote: > Actually, I'd like to see it just read/write flux changes + index marks onto > a SD card for later analysis. You want to do the analysis at the time of capture, in case you need to re-read the media, or wiggle the head to try to push off a bit of gunk, or micro step it for off-track errors. ie. you need to know if what you capture is meaningful.
Re: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
Ability to read MFM data with FM headers (RX50) On Tue, 19 Feb 2019, Chuck Guzis via cctalk wrote: It's not that simple. There's the matter of "DEC MFM" which encodes a few bit patterns differently to avoid collision with FM headers. Which is presumably a matter of appropriate code for analysis of the raw flux transition data.
RE: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
> Actually, I'd like to see it just read/write flux changes + index > marks onto a SD card for later analysis ... > We no longer need proprietary hardware. Well some of us might not and then there is the rest of us who just need a tool that kind of works. I guess the question is "who is your audience"? If your audience is the general vintage hobbyist (i.e. someone who used IBM or Apples 20 years ago and wants to mess with the same equipment) then they are not developing their own HW, cables, or writing ASM routines (BTW I count myself in this group). Don't get me wrong I would love to be able to do so but realistically I will never have the raw knowledgebase and the experience required to do something like that. For someone like me I need a tool that works with some fuss i.e. it is not polished and needs tweaking, handholding, and prayer to work but does not need me to also learn Sumerian or assembler (same difference ;) to make a backup copy of a disk. That maybe asking too much though given that this is a hobby
RE: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
A design that can manage Ohio Scientific as well would be nice. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
RE: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
Fred, Are we being a little sarcastic or serious? :)Honestly, a sw implementation would be interesting but would it work on vintage hw? Or are you suggesting for use only with a modern system? For example here is my dilemma: my stinkers, whom you have met, are getting old enough to want to mess with my stuff. *shudder* i mean cool! but I really don't want them ruining my one actual original disk for any programs I own. So what I do is make backup copies just like in the old days. And before someone suggests emulators, it is just not the same. I mean if we wanted to emulate everything why bother even preserving hardware?Problem is when we have copy protection, as many games or old SW do, then you need a Copy II PC board. I have one and they are fairly common but ridiculously expensive now a days. So it would be nice if the functions could be duplicated in an easy to use manner. Kyro Flux is powerful but not for everyone. I want an FDC that would cover 90% of the vintage hobby (i.e. Apple II, Mac, and IBM). An FDC that combines a CompatiCard IV with a copy ii pc deluxe and a Match Point card would cover all of the above plus then some.Just a thought ;D
Re: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
On 2/19/19 2:02 PM, Fred Cisin via cctalk wrote: > Ability to read MFM data with FM headers (RX50) It's not that simple. There's the matter of "DEC MFM" which encodes a few bit patterns differently to avoid collision with FM headers. --Chuck
Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?
I'm planning on a USB controller, but I've seen ISA projects that are also microcontroller based so I think it wouldn't be awfully difficult to replace the USB data pipe with an ISA one. On Tue, 19 Feb 2019, Ali via cctalk wrote: Well just because you don't have enough to do please plan on an ISA version as well ;) I think it really is time someone did a super floppy controller bringing together a number of older technology on to one easy to use card (e.g. 8" drive support, copy protection bypass, GCR reading) - all of this was available as separate products in the past... What I would like to see, coming at it from a high level software viewpoint, would be: Complete and accurate emulation of 765. Including ROM or being loadable into RAM (TSR) and repoint the Int13h vector. That would permit it to fully replace the stock 765. Include a switchable "quirks" mode for full compatability with 765 "features", such as "flash blindness" after index pulse, switchable inability to handle 128 byte sectors, etc. 8" and FM and 128 byte sector support (obviously) 125kbps (5.25" FM), 250Kbps, 500Kbps, 1000Kbps (2.8M) Ability to read MFM data with FM headers (RX50) Added commands accessible through the [replacement] Int13h: Track read, modeled after the WD track read (that could also provide access to Amiga, with additional code for sectors and filesystem) RAW track read (flux transition), with and without data/clock synchronization. Hard sector, GCR, copy protection cloning, etc. could be handled by other code that calls that function in the [replacement] Int13h. Optionally: drivers for "modern" OS, inverted data reversal, EBCDIC/ASCII conversion Installable File System (IFS) to permit mounting alien disks, including: Apple2 ProDos/SOS Apple CP/M Apple P-System Mac 400K/800K Commodore Sirius/Victor 9000 CP/M (partial list available at http://www.xenosoft.com/fmts.html) P-System Amiga Northstar N-DOS TRS-DOS and derivatives (list available on request) Coco-DOS Microsoft Stand-Alone BASIC (NEC, Oki, etc.) Unix/Linux file systems If it also does HDDs, . . . My friends think it's silly, and they're probably right. =P -- Grumpy Ol' Fred ci...@xenosoft.com
