Re: TRS-80 Model 16 hard drive replacement woes
> On Aug 13, 2017, at 2:54 AM, Josh Dersch via cctalk > wrote: > > On 8/12/2017 8:45 PM, Fred Cisin via cctalk wrote: > >> Long shot: >> Is this a system (like the 5160), where there are TWO format programs? >> 1) a physical low-level format done by special proprietary "non-user" >> (unobtanium?) software, followed by >> 2) a program named "FORMAT" that only sets up the logical structures, >> DIRectory, etc., and assumes that the low level format was previously done > > No apologies necessary :). The Format I'm running is a low-level format > (I've tried the Xenix "diskutil" program and the format utility included in > the diagnostic routines) so it should be laying out the sectors… To format hard drives on the Model 16 you only need the format program that is provided by the OS, i.e. diskutil in XENIX, FORMAT in TRSDOS-II or HFORMAT in P&T CP/M.
Re: TRS-80 Model 16 hard drive replacement woes
On 8/12/2017 8:45 PM, Fred Cisin via cctalk wrote: On Sat, 12 Aug 2017, Josh Dersch via cctalk wrote: However, I'm unable to format it. The controller doesn't appear to actually be laying down a format and attempts to read sectors after formatting fail with "ID Not Found" errors. I've tried several other known-working drives (another ST-225, a CDC 94025-51, and an ST-238 with the same results. (And yes, the terminator is present and accounted for on all drives.) I've run the Model II/12/16/6000 diagnostics and the controller passes with flying colors, as does the rest of the system. Before I start digging in deeper to figure out what's going on, I'm curious if I've missed a step here. I know I'm not the first person to attempt this, anyone have any ideas? Long shot: Is this a system (like the 5160), where there are TWO format programs? 1) a physical low-level format done by special proprietary "non-user" (unobtanium?) software, followed by 2) a program named "FORMAT" that only sets up the logical structures, DIRectory, etc., and assumes that the low level format was previously done THAT would certainly result in the "logical" format program choking on "ID not found", when the physical low level format wasn't to it's liking. (mutual incompatibility between most computers and controllers) My aplogies if I'm asking granny whether she knows how to suck eggs. . . No apologies necessary :). The Format I'm running is a low-level format (I've tried the Xenix "diskutil" program and the format utility included in the diagnostic routines) so it should be laying out the sectors... I did some probing of the write logic this evening with an oscilloscope, armed with the service manual. I found a 74ls54 in the MFM WRITE DATA +/- signal path that doesn't appear to be passing anything through. I don't happen to have any spares on hand so it'll have to wait a few days before I can replace it, but it seems likely that this is the culprit. I'll keep y'all posted. Thanks, Josh Can you read the drive with the bad bearings (with a flux transition board?), enough to determine what physical low level format it has? (any successful track with sector headers)
Re: TRS-80 Model 16 hard drive replacement woes
On Sat, 12 Aug 2017, Josh Dersch via cctalk wrote: However, I'm unable to format it. The controller doesn't appear to actually be laying down a format and attempts to read sectors after formatting fail with "ID Not Found" errors. I've tried several other known-working drives (another ST-225, a CDC 94025-51, and an ST-238 with the same results. (And yes, the terminator is present and accounted for on all drives.) I've run the Model II/12/16/6000 diagnostics and the controller passes with flying colors, as does the rest of the system. Before I start digging in deeper to figure out what's going on, I'm curious if I've missed a step here. I know I'm not the first person to attempt this, anyone have any ideas? Long shot: Is this a system (like the 5160), where there are TWO format programs? 1) a physical low-level format done by special proprietary "non-user" (unobtanium?) software, followed by 2) a program named "FORMAT" that only sets up the logical structures, DIRectory, etc., and assumes that the low level format was previously done THAT would certainly result in the "logical" format program choking on "ID not found", when the physical low level format wasn't to it's liking. (mutual incompatibility between most computers and controllers) My aplogies if I'm asking granny whether she knows how to suck eggs. . . Can you read the drive with the bad bearings (with a flux transition board?), enough to determine what physical low level format it has? (any successful track with sector headers)
