General Category > Lisa Troubleshooting and Repair

Sun20 Formatting Issues

<< < (2/3) > >>

sigma7:
Found this email of 11/10/2005 from Larry Parks (now deceased)

>Hi James,
>     I think I have located the problem. The problem is in the
>Proms source code that has something to do with the Sectors
>entry.  By varying the numbers below to see what would give
>me "Hard Disk Install Complete... Ready for MacWorks" or
>" > 30 defects"....   In all cases I had to enter Hex 12 for Sector
>to get anywhere.  Per your information this entry should be
>Hex 10  for 17 sectors ( 0 to 16 ) only.
>
>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>&Lisa Diagnostic Utility Routines Rev. F
>No drives online.....
>Last cylinder number                0266 to 0268   (614 to 616 cyc)
>Number of heads                        4  or  5 only      (4 or 5 heads)
>Number of sectors                       0012  only        (18 sectors )
>Precompensation cylinder      0080 to 0128       (128 to 296)
>Lun status byte                             0000  only                ( 0 )
>Flag byte                                       0000  only                ( 0 )
>Interleave number                         1 to 3 only             (1 to 3)
>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


Larry was very knowledgable about some things (had been a telephone engineer or something like that), but it was difficult communicating with him so the details above may not be as they seem.

We went back and forth about the hex vs decimal vs octal input question and the answer never became clear, so you may need to review the code AND experiment with different styles of input for different parameters if your version is different.

I was told personally about the "subtract 2" thing by Richard (sorry if I've got his name wrong... who seemed second only to Bob at Sun Remarketing), but I've never had a Sun20 so no personal experience with it.

sigma7:
Larry noted that the power supply traces on the Sun Remarketing MFM controller board were inadequate, so had beefed them up (presumably by adding jumper wires at strategic locations in the power nets).

It was rumoured that some (maybe all) SR boards were assembled as piece work by staff in their spare time, with varying levels of success. Re-soldering questionable joints may help in some cases.

AlexTheCat123:
That's really interesting! The stuff that Larry says there contradicts what I've found through testing.

After looking through the code some more, it's pretty clear that everything needs to be entered in decimal. And for further proof of this, I entered the number of cylinders as both 266 (hex) and 614 (decimal) and the hex number caused the heads to only sweep over roughly 1/3 of the disk (which would make sense if it expected a decimal number), while the decimal number made it sweep over the entire surface of the disk as it formatted.

Also, it's interesting that he has to enter 4 or 5 heads and 18 sectors to get things to work. My drive will give the "greater than 30 defects" error message if I use a number of heads greater than 3 or a number of sectors greater than 16. My drive (and presumably his drive) has four heads (0-3) and seventeen sectors per track (0-16), so entering 3 and 16 makes sense to me. But I have no idea how he was able to get it to work with his numbers.

It looks like we're both using revision F, so these discrepancies are a bit weird! I wonder what's going on here? Also, was he able to get into the formatter without removing that JB instruction? If so, then something's definitely not making sense here! From what I've seen in the code (and confirmed through testing), it will only enter diag mode if an error flag is set, so therefore that jump (which jumps if the error flag is set) will always be taken after entering diag mode and thus you should never be able to get access to the formatter without removing it.

sigma7:
Perhaps Larry had a different type of drive and/or perhaps the error flag wasn't set, so the JB instruction wasn't a problem?

FWIW, IIRC, Richard said that one must use the F! command.

It is also quite possible that it didn't work with those numbers; for whatever reason, some of my communications with him were contradictory or unexplainable as if translated incorrectly.

He reported some kind of issue due to his terminal program configured at first to send <CR><LF> instead of only <CR>. It read as though making the adjustment to send <CR> only was key to getting further, but again it wasn't clear... I would have thought it would work or not, but maybe the <LF> doesn't interfere with some parameters and does others.

AlexTheCat123:
Maybe Larry did have another type of drive, but from what I understand, the error flag had to have been set for him too. The controller will only enter diagnostic mode (meaning it will accept commands over serial) if it detects an error (indicated by that error flag) with the drive during initialization, so it seems as if the flag would always be set and therefore the jump would always be taken when diag mode starts up. But maybe I'm just interpreting something wrong.

I've tried both F and F! and neither seems to work for me. F is supposed to format the data tracks and F! is supposed to format the system track (aka the spare table), but I'm not sure how they're able to do that given that they never ask for any of your drive's parameters.

I was having weird issues thanks to my terminal software sending CR LF too, but luckily I figured that out really early in the process and switched it to only send CR. But sadly, that had no effect on my other problems.

Navigation

[0] Message Index

[#] Next page

[*] Previous page