On 3/17/12 2:48 PM, Rik Bos wrote: .hpi is just a dump of the sector payload. FDIO is Windows only. http://www.hp9845.net/9845/projects/fdio/ shows the 3.5" SS (9121) as being 16 x 256 so I wonder what the 128 byte sector is, if anything that I'm seeing

I thought thr wear figure, along with the bad track replacement data was stored on an inner track, one that is not used for user data. Certainly the drice seeks to an inner cylinder for some reason every so often, I assume to update the wear count. What would be the reson for storing the wear count on every track? Somebody should disasemble the firmware of these HP drives. It wouldn't be iimpossible, the firmware EPROM is the only programmed IC (no other PROMs or PALs or anyhting like that), there are no custom ICs (the disk controller and HPIB chip are standard, the processor is a 6809) and there are cheamtics so the addresses are all known. Then we'd know for sure what the thing stored where... -tony

Am 18.03.2012 21:45, schrieb Tony Duell: Where is information on this, including the EPROM dump? -- Holger

All the ofifical HP docuemtnation that I have (for example the programming manuals for the 9121, the techref fro the HP150 which used the HP9121) confirm this. 16 sectors/track, but rather fewer tracks than uyou might expect (70, IITC, numbered 0-69). The 9121 was desigend ot be software conmpatible with the older 5.25" drice units, which had 35 cylidners, 2 heads. Ther was a way to tell hem apart, but it was not obvious, so machiens that expected the 5.25" drive could use a 9121 too. I have no idea waht the extra sector you're seeing is. Does it appear to contain data (any readable text?). Or is it jsut 0xE5s or 0s' or something? -tony

On 17 Mar 2012 at 18:27, Eric Smith wrote: Oh, sure it can. Witness the IBM XDF format floppies and the programs that can format and write them. You just have to be a little clever is all. --Chuck

You sure can't *FORMAT* disks with mixed sector sizes on a PC's FDC. To be clear, what I mean by this is that using only the format command to the 765, you can't create a disk with validly formed mixed sized sectors. What you can do when formatting is: - Lie about the sector size when supplying the data for the individual ID headers. - Fill in bogus head/sector data for sectors you don't want to use (and will overwrite) later. - Control the gap3 size for the entire track. - Write fewer sectors than will fill the track - Reset the FDC before it has completed writing the final sector on the track. But you can't actually create (with the format command) sectors of mixed sizes. It *IS* possible to write disks with mixed sector sizes, and it *IS* possible to format a disk such that it can be written with mixed sector sizes - but only in a very few limited cases of usefulness (XDF is one of these). The fact that all sectors have to be formatted the same size means that alll the sector headers have to be evenly spaced, which is usually NOT where you want them for a arbitrary mixed-sector-size disk. You can format the track with smaller sectors, lying about the sizes and filling in the ID data on sectors you won't use with values that won't match ... but due to the additional headers and gaps, you won't be able to overlay larger sectors into these "slots" without extra overhead - two 256 bytes sectors takes more space on the disk than a single 512 byte sector. This means that for most disk formats you will run out of space. It doesn't help that most controllers cannot do 128 bytes sectors in MFM (TESTFDC will check this for you). The last sector is a special case - because it's header will actually be where it is supposed to be. So theoretically you can just give it the required (different) sector size in the last ID field and you should be good. If the last sector is going to be bigger, this is easy - there will be a big gap after the last sector, and when you write the larger sector everything works (assuming the whole track still fits of course). If the last sector is smaller, and the original larger sector won't fit, it gets tricky - One would hope that the FDC would stop formatting at the index hole - you would have "bad data" which would be overwritten by the good smaller sector when you write it and everything would be good ... but that is not the case (at least with the PC I tried this on when I was looking into it). The FDC keeps formatting past the index hole, and overwrites the first sector on the track, So you need to kill the FDC after it has written the header, but before it reaches the end of the disk. If you are running the FDC interrupt driven, this wouldn't be too hard - wait a few microseconds after you feed it the last sector ID information than reset the FDC. But if you are running it DMA (which is what ImageDisk does) you don't have this detail of knowing when the last sector is being written - and since you don't know when it starts writing (depending on the position of the index hole), you don't know how long to wait. Unfortunately the case of the last sector being smaller than the rest, and a full-sized sector not fitting is probably the most common, as it makes sense when trying to fit the most data possible onto a track. In the 7 years since I started the ImageDisk project, I think that Erics request to expand the format to support mixed-sector-sized disks which I received a couple of weeks ago was the first request I've had about mixed sector sizes disks - and his was only for the format specification. Given the rarity of mixed-sector sizes disks in classic systems, the inability to handle arbitrary mixed-sector-sized disks with the PC's FDC, and the difficulty in handling the very few cases that it might be able to recreate, I have so far elected not to try and implement this capability in ImageDisk. IMHO handling of this type of disk is better done with a hardware disk imaging system. At some point if/when I have time, I'll look into adding the ability to read mixed-sector-sized disks into ImageDisk. It would also be fairly simple to allow it to re-write mixed-sector-sized images to disks that are already formatted. Having it try to format disks compatible with arbitrary mixed sector-sized disks would however be difficult, especially given the fact that ImageDisk's FDC driver is DMA. If/when it gets this far, I might then consider creating a separate stand-alone program using the FDC in interrupt mode, and allowing the user to tweak "most everything possible" to try and format a compatible disk on the PC ... or perhaps one of the more clever people on the list would like to take on this as a project ? Dave -- dave12 (at) Dave Dunfield dunfield Firmware development services & tools: www.dunfield.com (dot) com Classic computers: http://www.classiccmp.org/dunfield/

Now that I've added support for variable sector sizes to the spec. When I get some time I'll look into at least getting ImageDisk to read mixed- size disks - reading is much more important that writing when it comes to saving old data - at least you have the data to work with. It will be a while however... Dave -- dave12 (at) Dave Dunfield dunfield Firmware development services & tools: www.dunfield.com (dot) com Classic computers: http://www.classiccmp.org/dunfield/

On 18 Mar 2012 at 12:02, Chuck Guzis wrote: Cool - I didn't know that - I thought it was "all or nothing" when it came to 128/MFM. But don't you run into problems with the header positions in some layouts? To do this on a general basis, you would have to be able to put 256, 512, 1024 etc. byte sectors into some multiple of 128 byte sectors - for some of those it works out to significantly more space than the same sized sector on a normally formatted track... I agree that it might not be too hard to write a program to format a disk with a known layout that works out reasonably with 128 byte sectors "underneath", but I'd like to be able to do the best possible general solution to mixed sector sizes. Have you ever tried resetting the FDC after it has written the last header but before the index hole? If this would work, it would let you have normal sector spacing for the cases where the format is n large sectors followed by 1 small one ... Dave -- dave12 (at) Dave Dunfield dunfield Firmware development services & tools: www.dunfield.com (dot) com Classic computers: http://www.classiccmp.org/dunfield/

On Sun, 18 Mar 2012, Chuck Guzis wrote: I can't help speculating whether that could be something as ridiculously improbably simple as an engineer using too high-level a tool, and leaving off the 'h' in "80h"

On 19 Mar 2012 at 20:29, Tony Duell wrote: Your charity might be misplaced. The 765 works just fine with 128 byte sectors in FM mode. --Chuck

David Riley wrote: How did you reach that conclusion? The 8086 and 8080 have 20 address lines, numbered from A0 (LSB) to A19 (MSB). The 80286 added more address lines, and in "real mode", its address arithmetic was such that the resulting address could be greater than 0xffff, and thus have A20=1. Are you arguing that the 80286 should have internally masked addresses to 20 bits (presumably only in "real mode")? If so, I'd have to disagree. I think Intel made the right choice. I disagree here also. Providing a means to mask A20 seems like a perfectly reasonable thing to do. Putting it on the keyboard controller is admittedly a little strange, but then, it isn't expected that you're going to be turning the A20 mask on and off at high frequency. The big problem with the AT design had nothing to do with A20, but rather with having the only way for software to force a reset (e.g., to get from protected mode to real mode) be via the keyboard controller, which was very slow. If Intel had provided a *documented* way of getting from protected mode to real mode without a hardware reset, that wouldn't have been an issue. The processor architects at Intel assumed that once you entered protected mode, you wouldn't want to go back. Arguably that was a little short-sighted of them, but then, back when the 286 was being designed (starting around 1980) the IBM PC wasn't even on the market, so it clearly wasn't obvious that the IBM PC and its descendants were going to become the most popular general-purpose computing platform on the planet.

No, the A20 "issue" was due to a compatibility issue with some software (can't remember at this point) where the SW was relying on the fact that addresses would wrap around the 1M point on the 8086/8. They were doing something akin to: mov ds, 0ffffh mov si, 501h mov ax, 0(si) That would cause ax to be loaded from 500h. Don't know why they were doing it but it was some important SW and it wouldn't work on the 286 without the "hack" since the 286 had 24 bit addressing. Compatibility?the bane of us all. TTFN - Guy On Mar 19, 2012, at 4:18 PM, David Riley wrote: