Interpreting Twiggy images made with BLU - an anomaly

Hi Folks,

David Ryskalczyk has reported an anomaly with Twiggy images created by BLU.

During his efforts to write software to interpret the images, he discovered that the tracks on the second side of the Twiggy appear to be in reverse order in the (second half of the) images made by BLU.

This anomaly affects _interpretation_ of Twiggy disk images only (not those for 3.5" disks), and it does not create a problem for typical/common use of BLU to read and write Twiggy disks.

Recall that for the Twiggy drive:

(1) To maximize disk capacity, the disk turns slowest when using the
outer tracks, and progressively faster when using tracks closer to the spindle.

(2) The heads on the carriage are on opposite sides of the spindle:
when one side is at the innermost track, the other side is at the outermost track. Thus, in combination with (1), at most carriage positions, reading one side of the disk requires a different spindle RPM than the other side.

(3) It takes longer to change rotation speed than to step to an adjacent track.

Consequently, all of the data for the second side comes after all of the data for the entire first side -- the sides do not alternate for each track in the fashion used by non-Twiggy floppy disk drives which have heads that directly oppose each other.

BLU reads/writes images considering the outermost track to be the first logical track on each side (corresponding to track #0 of the physical order/numbering used by the Floppy Disk Controller). ie. BLU starts at high speed at the outermost track (#0) on the first side, steps towards the innermost track (#45) on the same side while decreasing speed, then without moving the carriage, changes to high speed to use the outermost track (#0) on the second side, and steps towards the innermost track (#45) on the second side while decreasing speed. The FDC formats a disk in this sequence too.

However, it appears that the Monitor, Office System, and Workshop
(and Xenix too, I think) operating environments consider the
outermost track to be the first track on the first side, and the *innermost* track (FDC track #45) to be the first logical track on the second side. (ie. a contiguous file that crosses sides continues from the last sector of the innermost track on the first side to the first sector of the innermost track on the second side.)

As a result (when using these operating systems), reading a contiguous file that crosses sides requires moving the carriage across the entire disk instead of changing speed without moving the carriage.

It is unclear to me how this logical track order evolved in the Twiggy Lisa operating systems. Perhaps a programmer was not aware that as one head on the Twiggy carriage moves in, the other moves out, or perhaps there was a dictum that speed should not be changed if there is an alternative, or perhaps it is optimized for a different situation.

I do not think that a change in the FDC ROM is involved as the driver needs to know how many sectors are in each track. (Which brings up the point that, as of BLU V0.90, the Twiggy image format does not contain the sub-version of the FDC ROM in use. It is possible that I/O Board ROM versions earlier than "C" are not compatible with BLU and/or the Twiggy images or Twiggy disks currently in distribution if they number tracks differently. If you have a Lisa 1 Twiggy I/O Board ROM other than Rev. C, please let me know!)

This anomaly does not affect using BLU for reading/writing Twiggy images created by BLU as it puts sectors back where it found them.

It does affect creating other software to read/write Twiggy images when using the same format used by BLU.

David addressed this issue with a track re-ordering routine included in his code here:

https://github.com/d235j/lisa-utilities/blob/master/extract_lisamonitor_image.py#L87

The crucial complication being that the number of sectors per track varies as described in the Lisa Hardware Reference Manual Figure 6-11, so reversing the order of the tracks in the second half of the image involves a varying number of bytes per track:

*Track Sectors
  0-3 22
  4-10 21

11-16    20
17-22    19
23-28    18
29-34    17
35-41    16
42-45    15

*Track number as used by BLU and the floppy disk controller hardware: Track 0 is the outermost track and is considered the first for each side.

Warning: The graphic in Figure 6-11 contradicts itself in more than one way (which could be the source of this anomaly); interpret with care!

It appears the Macintosh Twiggy images do not have this track reversal, but consider the "second" side to be the first side.

In conclusion: if one is to create new software to read/write a Twiggy image in the format used by BLU, one MAY need to remap tracks in the second half of the image accordingly. (A Lisa 1 emulator likely would not need to remap tracks as the OS's driver is responsible for this re-ordering of logical tracks.)

This anomaly applies to _interpretation_ of Twiggy disk images only, not those for 3.5" disks, and it does not create a problem for typical/common use of BLU to read and write Twiggy disks.

James

-- 
-- 
-----
You received this message because you are a member of the LisaList group.
The group FAQ is at http://lowendmac.com/lists/lisa.html
To post to this group, send email to lisalist_at_email.domain.hidden
To leave this group, send email to lisalist+unsubscribe_at_email.domain.hidden
For more options, visit this group at http://groups.google.com/group/lisalist
--- 
You received this message because you are subscribed to the Google Groups "LisaList" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lisalist+unsubscribe_at_googlegroups.com.
For more options, visit https://groups.google.com/d/optout.