2016-05-26 0:34 GMT+02:00 <lisalist@googlegroups.com>:
James MacPhail <gg_@sigmasevensystems.com>: May 25 10:30AM -0700
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 digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to lisalist+unsubscribe@googlegroups.com.
