On 12/26/12 10:36 AM, Chuck Guzis wrote: There was also UCSD Pascal, from looking at the press from the time. I would guess they do EBCDIC translation when talking to printers, etc. The display logic looks like it could be similar to the PC MDA. Will have to see if they offer to image it. Apparently LCM has some as well.

On 12/26/12 11:10 AM, Guy Sotomayor wrote: I was pretty surprised that CHM has almost nothing for the Displaywriter and System/23 compared to how much we have for the 51x0. We don't even have a System/23 according to the catalog.

On Dec 26, 2012, at 11:40 AM, Chuck Guzis wrote: Same IBM keyboard technology used in DW, S/23, original IBM PC (I'm sure there were other products in the '79-82 range that also used it). Miss those keyboards. TTFN - Guy

From: Al Kossow <aek at bitsavers.org> If you are going to read old floppies, find a Shugart 851 and a Adaptec AHA-1522 ISA host adapter, and/or a PCI Catweasel if you need to image esoteric formats. C: what about the S* 801? Do you mean the AHA-1522A or -B or does it not matter?

From: Chuck Guzis <cclist at sydex.com> On 12/26/2012 02:48 PM, Chris Tofu wrote: Is 5"? what you get when you wash an SA-801 in hot water and then tumble-dry it?? (That's okay--I found a forum that identified the DW floppies as 12"...)? :) ?C: Oi whatever model we were talking about the other day. 802? Whatever the Intel MDS box has. What Al means is a controller with a DP8473 FDC in it.? The SCSI part doesn't matter.? But the 8473 handles FM quite nicely--and it's available on standalone FDCs such as the DTK Mini-micro as well as numerous MFM, RLL, SCSI and ESDI hard disk controllers with support for floppies.? Ultrastor is another brand that comes to mind. C: is the feature necessary for reading likely hum drum ms-dos (*not* IBM compatible) formats? Neither the NEC APC, Canon AS-100, nor IBM Displaywriter used that nasty little thing.

On Wed, 26 Dec 2012, Chris Tofu wrote: Do you wish to read any disks that are FM/"Single Density"? Do you wish to read any disks that are MFM, with 128 byte sectors?

On 12/26/2012 06:13 PM, Al Kossow wrote: Take a look at the Jade definition (JAD1). A related one is SUP5 which gets 30 128-byte MFM sectors on a 5.25" floppy. I've probably got the Altos one somewhere stashed away. Generally, since the format required special hardware setups, I left it out. But I'm sure that I've seen it. Don and I exchanged a fair amount of email about the issue. --Chuck

From: Fred Cisin <cisin at xenosoft.com> On Wed, 26 Dec 2012, Chris Tofu wrote: Do you wish to read any disks that are FM/"Single Density"? Do you wish to read any disks that are MFM, with 128 byte sectors? BZZZZZ WHIIIIIIIIR *BANG* *POP POP* I DO NOT KNOW DOES NOT COMPUTE I HAVE NO DOCS I ONLY KNOW THAT THEY BELONG TO THE CANON AS-100 NEC APC AND THE IBM DISPLAYWRITER UNIT ARE YOU THE KREATOR

From: Al Kossow <aek at bitsavers.org> I really did find a problem with the non-A version of the 8473. I was using a Seagate ST-01 and Imagedisk was having problems recognizing the address mark on Track 0 of System/36 disks that went away when I switched to the AHA-1522 with a 8473A. I'll double-check that there really was a problem with S36 disks and non-A 8473's.. C: Is the adapter you used similar to what Dave Dunfield describes on his site?

the adapter as in the connection between the cable from the controller and the 8" drive. How do you bridge that gap.

On 12/26/12 5:12 PM, Chris Tofu wrote: I use John Wilson's adapter board http://www.dbit.com/fdadap.html

From: Al Kossow <aek at bitsavers.org> On Wed, 26 Dec 2012, Chris Tofu wrote: ADAPTER??!? WHAT ADAPTER? Or are you CHANGING the subject to ask about how to cable it? (which is NOT mentioned nor even implied in what you just quoted)

On Dec 27, 2012, at 6:33 PM, Chris Tofu <rampaginggreenhulk at yahoo.com> wrote: Here's a crazy idea: CHANGE THE SUBJECT LINE IN THE E-MAIL. - Josh

From: Fred Cisin <cisin at xenosoft.com> From: Al Kossow <aek at bitsavers.org>: On Wed, 26 Dec 2012, Chris Tofu wrote: SHUGART 801 is SINGLE sided SHUGART 851 is DOUBLE sided. C: But we already discussed the Option Board s/w's ability to specify whether you're reading single sided or double sided disks (I think), so there's no reason for me searching for a double sided model. I don't think...

From: Fred Cisin <cisin at xenosoft.com> On Thu, 27 Dec 2012, Chris Tofu wrote: ONCE MORE! Do you want to read double sided disks? If so, then you need the 851.? Option board will certainly not give you capability of reading double sided disks in a single sided drive. C: But the option board just reads flux. Why couldn't you put a double sided disk in a single sided drive and read it off. My Commie 1541-II used to read the one side of a single sided disk. Maybe I don't have an acceptable understanding of what the Option Board/software does.

Why specifically the AHA1522, Al?

Sorry :oO I should have read more <:o( Dumb hat for me :)

On 12/28/12 3:11 PM, John Wilson wrote: http://www.xcore.com/projects/isaflop How sophisticated is the data separator? I assume it takes care of TK43 for 8"?

On 12/28/2012 04:03 PM, John Wilson wrote: One thing that helps is to implement a bandpass filter on your pulses--just reject everything outside of the pass band. If you can determine the data rate (and hence the average interval between pulses), it appears to work even better. I tried a bunch of PLL software simulations and found that in nearly all cases, the bandpass approach worked better on FM, MFM and MMFM as well as GCR. YM of course MV. --Chuck

On 12/28/2012 05:28 PM, John Wilson wrote: Nope, nothing really wonderful--just slots in a temporal wall. If a pulse falls through the slot, you use it; if it hits the wall, you reject it. It's been far more effective than I anticipated after using all sorts of far more complicated algorithms. --Chuck

On Fri, Dec 28, 2012 at 10:21:43PM -0500, Mouse wrote: Sounds like good nerding! :-) Interesting... This is nicely evil! *Documented* is certainly the way to go. In that case it would help if the interface were a lot easier than the uPD765 (which is needlessly unpleasant to program). I'm thinking mainly of percentages. I'd like something which 90% of users can use with existing drivers, and only have things get ugly 10% of the time. Yeah I was talking blearily... I didn't mean that the FDC will be for use under emulation (although of course I'll use it that way), but that since what I do all day is emulation anyway I like cases where the new thing works just like the old thing, only better, unless there's a good reason for it not to. So I'd rather make a new ISA FDC that works like old ISA FDCs, and a new USB FDC that works like any USB drive, rather than a new thing that doesn't work like anything and only talks to the one utility program that knows about it. John Wilson D Bit

On Sat, Dec 29, 2012 at 08:36:38AM -0800, Al Kossow wrote: No argument there. Plus you don't even have to be on the same continent as the drive you're reading! Blocks of MAC addresses do cost money, but Microchip sells them a la carte nice and cheap. A few years ago the sensible thing would be to use SCSI. SCSI-1 isn't hard at all, and *that* crowd is totally cool about vendor IDs! Email them your 8-character name, they say OK, and now you're safely unique, for free. But it seems like these days everything everywhere is about making people keep paying you fees forever. They must teach that in business school... Looks like fun and the price sure is right. John Wilson D Bit

On 12/29/2012 04:41 PM, Fred Cisin wrote: Remote controllability is a good thing. A truly standardized interface that most anything can talk to is even better. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

On Sat, 29 Dec 2012, John Wilson wrote: THAT could be useful. Even internet access to my thermostat might be handy, although I'd have a hard time not worrying about errors, or unauthorized resetting. But, to put the disk drive elsewhere, then I would also need a remotely accessible robot arm to take the disk out of the package and put it into the drive. -- Grumpy Ol' Fred cisin at xenosoft.com

On 12/30/2012 05:48 PM, Dave McGuire wrote: In the bad old PCI days, you could program a CPLD to handle the interface. I've got a 3x8255 digital interface board done that way with a Xilinx XC95xx on it that reports a vendor ID of something like 00000000. It works anyway. --Chuck

But what happens if you put a pair of them into a machine?

On 12/30/2012 05:48 PM, Dave McGuire wrote: And pretty much all it gets you is a Vendor ID. It'd be a different matter if the PCISIG charged a one-time fee or kept a detailed database of specifications for every PCI device, to insure against loss of information when a vendor went belly-up. But just keeping your VID around will run you $3K per year. --Chuck

On 12/28/2012 4:31 PM, Al Kossow wrote: There used to be chips that would 'bridge' a PCI bus to an ISA bus. If the chips are still available, it wouldn't be huge design change. When PCI was young, they were common. Rob.

Very interesting! Manual with photo and schematics on http://www-corot.obspm.fr/COROT-ETC/Files/rdkmanver1.2_98doc.PDF

On 12/28/2012 05:05 PM, Fred Cisin wrote: Yes, it's annoying to be working with a WD17xx-created format without the IAM and have a 765-type FDC "go blind" during the "PLL sync" period. There was a NEC uPD7265 that omitted the IAM for so-called "Sony Mode" recording, but those are exceedingly rare. NEC has sort of a "Read Track - read multiple sectors without looking at the IDAM" command; it starts after the index and reads subsequent sectors starting at each DAM. You can have an unreadable IDAM and still recover the sector data if the DAM is readable. You also can feed the 765 a "Read Track" with a phony datalength specified. The 765 will suck up all of the data after the first DAM after the index until the transfer count is exhausted. Thus, you get gaps, AMs, headers, all "in the raw", meaning that the 765 does not resync during the transfer. Great if you're using original floppies made using a Formaster that writes an entire track in one swell foop, not so much for tracks where the sectors are written individually. The WD17xx and 27xx type controllers, OTOH, resync at every address mark during a "Read Track". Harvard Presentation Graphics used this technique to read their "HGC" stashed in the gap bytes between sectors. Also, consider implementing some of the 82078 added commands, particularly "Format and Write" (can make copying go very fast) as well as the PM functions. Personally, I'd do the board as a USB card, given the difficulty of finding ISA-equipped motherboards or dealing with the nuances of PCI/PCIE, etc. You should also be aware that Andrew has been testing prototypes of an ISA FDC that can use either the I82077AA, PC8477 or DP8473 chips. --Chuck

On 12/28/2012 06:30 PM, John Wilson wrote: The original 8272/765 non-A parts were worse--the darned FDC was blind for a full millisecond after the index. This created problems with reading some 9 sector media on very early IBM 5150s. I've never run into a program that actually used the SCAN commands. They'd be the first thing that I'd throw overboard. Well, since a "306K" floppy has 6250 "raw" bytes per track, try issuing a "Read Track" with a sector length of 8192 bytes for just a single sector. Note that if you format a track substituting very large sector sizes (say, 8192 bytes) in the headers, then write one of them, the write will wrap around the index and "eat its tail", leaving a track with no address marks. Very useful for faking a blank track. Most systems made after about 2004 or so have an option to boot from a USB floppy, so emulating that for starters would be an option. Even running DOS 6.22 with a USB floppy still allows for read/writing and formatting--the more esoteric operations, of course, aren't there. As far as the Catweasel, I use both the ISA and PCI variety--and my code works with both--it's just a matter of figuring out which you have and setting up some tables. THe CW is useful for a lot of oddball formats. Right now, I've got a batch of hard-sectored floppies to retrieve data from that were written using a Zilog MCZ. Care for 132-byte sectors? But then, I can emulate a Catweasel just fine--and get a USB interface using just about any modern MCU. I prefer the PIC32 chips but an ARM would do just fine also. --Chuck

On 12/28/2012 10:55 PM, John Wilson wrote: That may be true for the CW MK4, but that was not the case for MK3 PCI. I suspect that if you try to implement this with a PCI-ISA bridge chip, you'll be in for agony supporting legacy DMA correctly. I've got a couple of P3 mobos with Intel 810 and 815 chipsets that use the National bridge chip to support ISA slots. Legacy 8-bit DMA absolutely fails on both of them from the ISA slots. Oddly, the built-in floppy support (Super I/O chip) works just fine, but ISA DMA doesn't work at all. I haven't the faintest idea why--the chip datasheet says that it shouldn't be a problem. Earlier Intel chips (e.g., 440) don't have this issue, as ISA support is part of the deal. --Chuck

On Sat, 29 Dec 2012, Christian Corti wrote: Two different things, although they both involve "index" Oversimplification (for those not familiar, or accustomed to disk formats (Atari, Commode, Apple ][), where the index of the disk is not used): There is a small hole in the disk. On most formats (other than the above), there is a small hole through the medai and a light and photocell. When light shines through the hole, a pulse is sent back to the disk controller, called an "index pulse". It is a hard mark of the start of the track. In addition, a few drives, including some Teac 55's use that to determine whether the disk is spinning. The stock Option Board software relies on the index pulse. NEC chose to resync their PLL when it sees that pulse. That means that the NEC chip is "blind" or "deaf", and can not see ANYTHING for a little while after the pulse, "but is fully enabled in plenty of time for the start of data." WD does NOT do that. Some disk formats, that use WD controllers, in order to squeeze the maximum capacity on the disk end up starting their first sector during that time. Therefore, there can be some difficulties reading such disks (such as Cromemco, TRS80, etc.) The index hole and its resulting pulse are used for identifying the start of the track for formatting, but are generally not needed for normal successful reads and writes. Therefore, many of the problems reading such disks can be circumvented by covering the index hole. Except for some drives, AND an unsuccessful read may generate the wrong error code. PLEASE don't design controllers that "go blind" after index. "Index Address Mark" is a completely different issue! The IBM/WD disk formatting pattern was originally called "IBM Soft Sector Disk Format", but when the 5150 came into existence, too many people thought that "IBM Format" meant PC-DOS. Without going into the full blather about splice gaps, resynchronization, etc., . . . Each sector has a special byte (with non-standard timing pulses) ("ID address mark"/IDAM) to mark the beginning of the sector header, and a "Data Address Mark"/DAM (a different byte with non-standard timing pulses) to mark the start of the data. In addition, there is an INDEX address mark/IAM (a different byte with non-standard timing pulse) to mark the start of the track. Since a read attempt might start anywhere in the track, to avoid excessive latency, most systems do NOT wait to see index. They will start reading as soon as they see what appears to be data, and wait for the desired sector header to come around. Accordingly, if everything is going smoothly, index is never really needed other than to know where to start a track when formatting. If that wasn't more than you want to know about it, or if you are offended by the oversimplifications, we could go through the reasons and structures of every part of the IBM/WD soft-sector disk format. -- Grumpy Ol' Fred cisin at xenosoft.com

On Mon, 31 Dec 2012, Alexandre Souza - Listas wrote: I don't have any of my class handouts any more (I looked). (page from Bill Barden's plus annotations for format, plus a page with examples for NRZ, FM, MFM, RLL/GCR) I could write up description, BUT, some people would be annoyed at "remedial" content (I tend to be patronizing/condescending), AND, there are many here, such as Tony and/or Chuck, who could do a much better job than I can. If people want. But, my mother reacted badly to the [now discontinued] Parkinson's med, fell and broke her back. Now it's 24 hour care. -- Grumpy Ol' Fred cisin at xenosoft.com

On Mon, 31 Dec 2012, Christian Corti wrote: No problem with that! YOU seem to know what you are talking about. But, there are some others here who are unfamiliar with that track structure and reasons for address marks, and I just naturally slipped into part of my (3 hour!) class lecture, that starts with FM, and goes to RLL, with detailed examination of the reasons behind the IBM/WD track format. There also seemed to be some conflation of index pulse (hardware) and Index Address Mark (software and format). BOTH of which can complicate reading weird alien disks,