[Al Kossow] Thanks Al - I will check it out and see if I can determine any possible explainations... [Chuck Guzis] Thats what I had assumed (thanks for confirming). I do exactly the same. I set the appropriate data rate in the register at 3F7/377, and select FM/MFM by the absense or presense of the MF bit (6 - 0x40) in all related commands. During analysis, IMD cycles through the six possible combinations (250, 300 and 500 kbps at both FM and MFM) as it tries to identify the disk. I've not seen another case yet where a disk was readable on the PC and IMD could not detect it correctly, no matter what drive type and data rate. Even if the analysis was failing, IMD configures the controller directly to the desired mode and data rate when writing, and the user reports that he cannot write my images either. If anyone has any idea as to what I might have missed or misinterpreted in the specs that could cause this, please let me know. TO ALL: Does anyone else have an Adaptec 1522A controller that you can try with my latest version of ImageDisk to see if you can read/write single-density disks? I don't have this controller to test with, and I would like to confirm that the problem is generic and not related to the one particular unit in question. Regards, Dave -- dave06a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Collector of vintage computing equipment: http://www.parse.com/~ddunfield/museum/index.html

Hi Chuck, Thats what I suspect as well. I don't think it's reset - I wait 55ms (not us) with reset LOW, then 55ms with reset high before proceeding - that should be plenty of time. Is this a 82077 related command? The uPD765 documentation does not mention a CONFIGURE command - only SPECIFY which just sets step/head-load/unload rates. I reset and configure the FDC at the beginning of any operation, however I am currently NOT resetting it for each rate/mode attempt during the analysis phase - are you saying that I should do this? This will cause all kinds of disgusting things like the controller forgetting what track it's on... not to mention slowing down analysis substantially as the controller will have to be re-initialized and probably another whole revolution will slip by during the chaos... I'm inclined to think that this is not the problem either, because the user reports that he cannot WRITE my Osborne SD images ... During WRITE, I only setup the controller once (unless the mode/rate changes which it doesn't in the SD disks) - and the controller is reset just before the initial setup takes place. If no other solution turns up, I'll try this as a last resort, however I'd make it an option, so that the performance degradation and reseeking will not have to occur if you have a better behaved FDC (this is the first one I've seen with these problems - and we don't know that this is the cause yet). I guess it's too much to hope for that the manufacturers implement backward compatibility to the 765 properly ... ? Thanks for the input - I'll check out the 82077 data sheet (downloading it now) and see if comparing it to the 765 gives me any ideas. Dave -- dave06a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Collector of vintage computing equipment: http://www.parse.com/~ddunfield/museum/index.html

On Wed, 22 Mar 2006, Dave Dunfield wrote: I did some tests of several FDC chips found on different Multi-I/O boards and motherboards some time ago, here are my results: These work fine with single-density (reading and writing): M5105 (Acer) WD37C65 (Western Digital) i82072 (Intel) DP8473 (National Semiconductors) SMC Super I/O chip found on many motherboards (e.g. old Intel or Asus boards) These won't work at all: Winbond W83757, Intel i82077 and other modern crap. There's one unusual constellation that not many FDCs support: MFM with 128 bytes/sector. I have a Robotron A5120 computer (ex-GDR) that uses 26 sectors with 128 bytes/sector and *MFM* on a 5.25" 96tpi double-density diskette, so the layout is exactly the same as with 8" drives, but only half the data rate (250 kbits/sec.) My tests showed that the M5105 and DP8473 can read *and* write such diskettes, the other FDCs can't even reliably read them (e.g. they only read around 80 instead of 128 bytes etc.) Another thing to take care of: Some FDCs don't work reliably in FM mode at a bit rate of 150 kbits/sec. So in order to write single density minifloppies (48 or 96 tpi) you should either use a drive with dual speed (300 and 360 rpm selected via the density select input pin 2) or use a drive that is fixed to 300 rpm; in both cases use a data rate of 125 kbits/sec. (I have a CP/M system that uses an Intel 8271 FDC at 125 kbits/sec, this is a FM only chip) Hope that helps in finding usable I/O boards and FDCs. I have a multi-media PC (a PC that handles multiple medias, what else?) with 3.5" and 5.25" HD at the primary onboard FDC, and a 5.25" 96tpi DD(300rpm ) and 8" drive connected to an ISA Multi-I/O board with DP8473 set to the secondary address. This handles most of the diskette formats I have. Christian

Looks like I may have found the problem - It seems in my last update to "improve" the calculation of gap lengths for unknown formats, I completely cocked-up the calculation for single-density (left a variable out of the calculation). The user reports that with the corrected code, he can write the Osborne SD disk images in question on his Adaptec 1522A controller without any problems. I've asked him to run a couple of other tests, and if all goes well, I should have an update to ImageDisk posted on my site by noon tomorrow. Regards, Dave -- dave06a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Collector of vintage computing equipment: http://www.parse.com/~ddunfield/museum/index.html