Re: Patching Xenix with the X/ProFile patches using lisafsh-tool

From: James MacPhail <gg__at_email.domain.hidden>
Date: Sat, 18 Aug 2007 11:47:21 -0700

[Andreas_210 wrote:]
>It should be :
>editsector 0x86 4E 71 08 EB 00 04 00 01 60 80
>editsector 0x70 4E 71 08 EB 00 04 00 01 60 80
>editsector 0x16E 4E 71 08 EB 00 04 00 01 60 80

Those look good to me, I'll see if I can get Ray to confirm.

>Iīve tried it with FEdit 2 times using this instructions :
>But that doesnīt work here ...
>"pfcmd: handshake err 0103"
>"pfcmd: handshake err 0102"

Those are some of the symptoms of an unpatched (or, I suppose, a partially/incorrectly patched) xenix boot disk. (This is not exclusively an X/ProFile problem: if the patches are not applied, the handshake errors can also occur with a real Apple ProFile.)

>Then XProFile 7seg. Display doesnīt run along the outer 6 segments any
>longer, it runs / flashes around the left 4 segments in circles.
>Canīt find that in the operation manual.

There is a brief description of the chase sequences in "Run Mode Display" on page 18 of the X/ProFile Operation Manual. I apologize for making that hard to find.

In summary:

  1. the larger clockwise chase sequence indicates the normal "idle" condition. ie. the X/ProFile is running and waiting for a command from the computer.
  2. the smaller counter-clockwise chase sequence indicates the computer is holding either the RESET signal, or the "COMMAND" signal (typically indicating the computer is about to send a command), and the X/ProFile is waiting for the computer to indicate it has finished sending the command (or resetting).

It is rare that (B) will persist for enough time that one can see it happen. It may be displayed for an extended period when the CMD or RESET signal appears to be asserted only because the computer is turned off, or if the computer crashes or is reset at just the right point in the middle of a disk access.

In the booting-xenix case, the perpetual "command-asserted" state may also be a symptom of one or more of the xenix boot-disk patches having been missed or applied incorrectly (eg. typo).


  1. If you applied the patches with the original set of lisafsh commands that had the typos, I suggest you should start over with a fresh image of the boot disk (rather than try to undo the incorrect changes).
  2. When using FEdit, it is easy to forget to "write" your changes to disk. This must be done for each modified sector before viewing another sector or your changes are lost.

To verify all your changes were written, open the disk in FEdit again, and perform each of the 4 searches. When FEdit finds any of the search strings on the patched disk, then that indicates a change that was not performed/written.

Since FEdit searches only from the currently-displayed sector to the end of the disk, you should go back to the first sector before looking for a new search string.

As a double-check, you could also search for the replacement strings and count the number of times they appear (if the count does not match the number of changes required, then it seems likely that a data entry error occurred).

3) Another source of communication failure is a bad data cable/connection. If you check another CF card/STAR and find that the Lisa can still boot/run from it, then this obviously isn't the problem. If you don't have another CF card to test, then double-check the data cable is fully connected at each end and undamaged.

HTH, James

James MacPhail                   "Think not of engineering as art,
uo957_at_email.domain.hidden                 but of art as engineering"
Sigma Seven Systems Ltd.
james_at_email.domain.hidden        <>

--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "LisaList" group. To post to this group, send email to lisalist_at_email.domain.hidden To unsubscribe from this group, send email to lisalist-unsubscribe_at_email.domain.hidden For more options, visit this group at -~----------~----~----~----~------~----~------~--~--- Received on 2007-08-18 14:53:35

This archive was generated by hypermail 2.4.0 : 2020-01-13 12:15:13 EST