On 9/29/2011 1:24 PM, Rik Bos wrote: oh bummer. would the proud new owner be willing to make copies of the cpm disks..... please.... steve

On 9/29/2011 7:52 PM, Josh Dersch wrote: Thanks! I rescued an Altos 8100 a couple months ago that appears in pristine shape. Disks would be awesome! Steve

On 9/29/2011 7:52 PM, Josh Dersch wrote: The disks arrived yesterday and I attempted to make disk images of them, the ones I was able to read are in IMD format at: http://yahozna.dyndns.org/scratch/altos/ Some neat stuff, a copy of BDS-C, COBOL-80 and MBASIC for the Altos. I am not having much luck capturing images of the CP/M disks, however. They appear to be single-sided, double-density. The first two tracks are SD and have 26 sectors per track, the rest are DD and have 48 sectors/track which is where my system appears to have trouble, ImageDisk just won't read the DD tracks. If anyone has any suggestions, let me know. Otherwise, I'll dig my Altos out of the closet and code up a simple utility to dump the disks over the serial port... eventually. Josh

On 10/13/2011 9:53 PM, Chuck Guzis wrote: Nuts. I have an Adaptec AHA-1542C in my machine which I've had very good luck with thus far. I guess I'll keep my eyes open for a board that uses this controller... - Josh

On 10/13/11 10:27 PM, Chuck Guzis wrote: Here are all of the ISA controllers with a DP8473, extracted from an old controller list AHA-1542Bs show up at Weird Stuff fairly often. If you need one to read the Altos floppies, LMK. ADAPTEC AHA-1522 ISA-SCSI AT 7HD 2FD B 1/2 XT NS DP8473 AIC 6260 (PIO) PROGRAMMED I/O ADAPTEC AHA-1542B ISA-SCSI AT 7HD 2FD B C 3/4 XT NS DP8473 AIC 6250 (BUS MASTER) 1ST PARTY DMA BUSLOGIC BT-542B ISA-SCSI-2 AT 7HD 2FD B C 1/2 AT NS DP8473 NCR 53C94 (BUS MASTER) BUSLOGIC BT-542D ISA-SCSI-2FD AT 7HD 2FD B C FULL AT NS DP8473 NCR 53C94 BUS MASTER, DIFFERENTIAL SCSI BUSLOGIC BT-542S ISA-SCSI-2F AT 7HD 2FD B C FULL AT NS DP8473 NCR 53C94 BUS MASTER, 2.88MB FLOPPY BUSLOGIC BT-742A EISA-SCSI-2 EISA 7HD 2FD B C 1/2 AT NS DP8473 NCR 53C94 BUS MASTER,PASSIVE TERMINATION C.S.C. FASTCACHE 32 ISA-SCSI AT 7HD 4FD B C FULL AT NS DP8473 NCR 53C400 256K-8MB CACHE (STD. SIMMs) FUTURE DOMAIN TMC-1670 ISA-SCSI-2F AT 7HD 2HD B C HALF XT NS DP8473 TMC-1800 (PIO), 8KB DUAL BUFFER FUTURE DOMAIN TMC-1680 ISA-SCSI-2F AT 7HD 4FD B C HALF XT NS DP8473 TMC-1800 (PIO), 8KB BUFFER,*OLD:TMC-950 FUTURE DOMAIN TMC-885[M] ISA-SCSI AT 7HD 4FD B C 3/4 XT NS DP8473 TMC-950 (PIO) GSI 1495-44-V ISA-ESDI AT 1:1 4HD 4FD 2046 RS B 3/4 XT NS DP8473 R/S ECC, CACHE, DISK SHADOWING MACROTRON SYSTEMS MSI-2010 ISA-SCSI-2 AT 7HD 2FD B C 1/2 XT SPI300/16 NS DP8473V MAPLE SYSTEMS MC-1165A ISA-ESDI AT 1:1 2HD 2FD 4096 16 56 B 3/4 XT NS DP8473V 25MHz CHANNEL, 64KB CACHE MAPLE SYSTEMS MC-1175 ISA-ESDI AT 2HD 2FD 4096 16 56 B 2/3 XT NS DP8473V >528MB SUPPORT, 64KB CACHE MAPLE SYSTEMS MC-2068 ISA-IDE(AT) AT 2HD 2FD 4096 16 B 3/4 AT NS DP8473V >528MB SUPPORT, .5-8MB CACHE MAPLE SYSTEMS MC-2068A ISA-IDE(AT) AT 2HD 2FD 4096 16 B 3/4 AT NS DP8473V >528MB SUPPORT, 2-16MB CACHE MAPLE SYSTEMS MC-2078 ISA(LB)-IDE(AT) AT(VESA) 2HD 2FD 4096 16 B 3/4 AT NS DP8473V >528MB SUPPORT, 2-8MB CACHE MAPLE SYSTEMS MC-2078A ISA(LB)-IDE(AT) AT(VESA) 2HD 2FD 4096 16 B 3/4 AT NS DP8473V >528MB SUPPORT, 2-32MB CACHE MAPLE SYSTEMS MC-4000 ISA-SCSI AT 9HD 2FD B 2/3 AT NS DP8473V SCSI & ST412, 2-32MB CACHE PROMISE TECH. DC-2031 ISA-IDE(AT) AT 2HD 2FD 2048 16 B C FULL AT NS DP8473 .5-16MB CACHE, 16MHz ISA BUS PROMISE TECH. DC-2032 ISA-IDE(AT) AT 4HD 2FD 2048 16 B C FULL AT NS DP8473 .5-16MB CACHE, 16MHz ISA BUS SEAGATE TECH. ST02 ISA-SCSI PC,XT,AT 2HD 2FD 1024 16 B C 1/2 XT NS DP8473 TMC-900,950 (PIO) STORAGE PLUS SPI-300 ISA-SCSI-2 AT 7HD 2FD B C 1/2 XT NS DP8473 SPI300/16 (DMA), 16-BIT TRANTOR SYSTEMS T128F ISA-SCSI AT 7HD 4FD B C 1/2 XT NS DP8473 NCR 5380 (DMA)

On 10/15/11 10:31 AM, Chuck Guzis wrote: That's what I found after a quick search. No one else has posted a list here. The DTK card is a PII-151B http://www.ebay.com/itm/200657851555

On 10/15/2011 2:16 PM, Josh Dersch wrote: OK -- found an AHA-1542B in my stash (and a Seagate ST02 for good measure) and I'm happy to report that ImageDisk does seem to cope with 128-byte sectors given a controller that works. (Though it is a bit fussy, occasionally it'd stop reading properly and the only remedy seemed to be to reboot the machine.) And I now have a bunch more images up at: http://yahozna.dyndns.org/scratch/altos/ Including several copies of CP/M (looks like 2.2), images of Multiplan, Wordstar and a diagnostic disk. That should be the lot! Thanks for the advice. - Josh

On 17 Oct 2011 at 16:53, Steven Hirsch wrote: Oddly enough, I don't believe so. The internal operation of the PC8477 is more in line with the Intel 82077 before Intel broke it by adding tape support (i.e. run from the 82077AA-1 as fast as you can). Note that the problem is not 128-byte sectors per se, but rather 128- byte sectors recorded in MFM. Even the NEC uPD 765 is seriously broken in this respect. --Chuck

On Mon, Oct 17, 2011 at 2:11 PM, Chuck Guzis <cclist at sydex.com> wrote: Is there any peculiar with the 128-byte / sector MFM format? Or is it more likely an edge case that probably should have worked in the controller but wasn?t tested until too late? Or was support for that format was intentionally dropped from the controller?

Chuck Guzis wrote: Even though IBM didn't specify 128 bytes for FM, I am rather surprised that an FDC that can handle length code 00 properly in MFM mode wouldn't in FM mode. I can't really imagine what sort of logic design would lead to that. Interpreting the 00 length code as 80 bytes is especially strange, and that makes me wonder if they didn't intentionally do that in order to be compatible with some proprietary system. There's no obvious way to do such a thing as a (somewhat-) compatible extension of the standard formats. The ID field of a sector contains a "physical record length" byte, and the FDC uses the value there to determine how many data bytes to transfer before the CRC. The values IBM defined are: 00 - 128 bytes (FM only) 01 - 256 bytes 02 - 512 bytes 03 - 1024 bytes (MFM only) There are non-IBM formats using the obvious extension: 04 - 2048 bytes 05 - 4096 bytes I wouldn't be the least bit surprised if some FDC chips didn't work properly with those. In particular, I would expect some FDCs to use only the low two bits of the byte, and interpret 04 and 05 as meaning 128 and 256 bytes, respectively. However, I have not tried this.

On 19 Oct 2011 at 10:02, Scott Kevill wrote: Thanks for elaborating my my brief quotes. FWIW, has anyone tried this with the WD1781? --Chuck

Chuck wrote: What systems actually used the 1781? I've got some 1781 chips, but I'd have to design a board with a suitable FM, MFM, or M2FM encoder/decoder in order to actually use them. It would be interesting to see whether the 1781 with a suitable DEC-M2FM encoder/decoder could be used to read/write double density RX02 format.

On 18 Oct 2011 at 17:44, Eric Smith wrote: I assume that you mean "MFM" (the 3740 format is 128 bytes FM and for that matter the 53FD format is 128 FM on the first track. I am rather surprised Hey, I didn't design the darned thing. :) Take a look at the WD1771 data sheet, "Non IBM Formats" that states in part: "Non-IBM formats are very similar to IBM formats except a different algorithm is used to ascertain the sector length from the sector length field in the ID field. This permits a wide range of sector lengths from 16 to 4096 bytes..." In fact, when sending read or write commands to the 765, it's customary to specify DTL in the command as 80 hex for 128-byte sectors. For 256 byte sectors and up, DTL is 00. For the meaning of DTL, read "When the value of N is 00, DTL stands for the number of bytes users are going to read or write into the sector." Whether or not this was intended for handling non-standard sector length is open to speculation. It's worth observing that when the WD 17/27 chips ruled the world, many, if not most systems were not IBM-conforming, choosing to leave out the IAM from their formats. This caused no end to problems when systems with the old 8272 or 765 tried to read such disks, because the NEC design originally had a very long "VCO sync" blind spot after the index. The "A" parts pretty much halved that. But the early 5150 systems used the old 8272 , which created a bit of a problem. --Chuck

On Mon, 17 Oct 2011, Geoffrey Reed wrote: NOT THE ONE THAT I HAD. It was a 765 variant.

On Mon, 17 Oct 2011, Geoffrey Reed wrote: If you ever find one, let us know! I've never been able to find a disk controller for PC that wasn't a 765 variant.

On Mon, 17 Oct 2011, Chuck Guzis wrote: It should be reiterated that the 82077 is, for all practical purposes, a 765. Using a WD1793, or variant thereof, would require a complete rewrite of Int13h. AFAIK, nobody ever got around to doing that, so I kept a TRS80-3 around just for the WD REAL "track read" command. -- Grumpy Ol' Fred cisin at xenosoft.com

On Mon, 17 Oct 2011, Chuck Guzis wrote: Is it too late to start marketing accessory boards for 5150? THAT plus a complete rewrite of Int13h, . . .

On 10/18/11 8:35 AM, "Gene Buckle" <geneb at deltasoft.com> wrote: With the way old HDD's are slowly failing it would be cool to have a CF/IDE adapter that acts like the SASI <-> ST506 interface boards (and related ones)

On 10/17/11 4:30 PM, "Chuck Guzis" <cclist at sydex.com> wrote: Thanks, I don't claim my memory is always correct :) I do know I had a WD xx93 based card in a pc at one point with software drivers to add 4 additional drives... But I have also had compaticard II and IV at various times...

On Fri, 14 Oct 2011, Jerry Wright wrote: It is NOT the interleave. What they did that was odd was 128 byte MFM sectors. Chuck is correct. He KNOWS what he is talking about. MOST 765 based FDC chips can not handle 128 byte MFM sectors. SOME can. Fortunately, there are VERY few disk formats that use 128 byte MFM sectors. XenoCopy did not include any of them, because of the FDC problem. -- Fred Cisin cisin at xenosoft.com XenoSoft http://www.xenosoft.com PO Box 1236 (510) 558-9366 Berkeley, CA 94701-1236

On 14 Oct 2011 at 10:36, Fred Cisin wrote: This is one that Don Maslin and I worked through, checking out a number of controllers until we hit the NS DP8473. It must have been designed by an intern, because it pretty much stands apart from the crowd of 765 clones in that it knows what to do with 128 byte MFM sectors. I haven't tried to use one to format and read sectors smaller than 128 bytes, however. It might be interesting to see what happens. --Chuck