Re: Digest for lisalist_at_email.domain.hidden - 1 update in 1 topic

I confirm that reversing is not needed for an emulator. At the "hardware" level (ie protocol to access floppy sectors from the floppy request sent to io-card). no need to reverse when mapping sector/track/side to DC42 images created with BLU.

So the need for this reverse may be logical in the OS disk driver.

emulator disk module with twiggy support: https://sourceforge.net/p/idle-lisa-emu/code/HEAD/tree/disk/disk_image.c

2016-05-26 0:34 GMT+02:00 <lisalist_at_email.domain.hidden>:

> lisalist_at_email.domain.hidden
> <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/lisalist/topics> Google
> Groups
> <https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!overview>
> <https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!overview>
> Topic digest
> View all topics
> <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/lisalist/topics>
>
> - Interpreting Twiggy images made with BLU - an anomaly
> <#m_6423902857968408579_group_thread_0> - 1 Update
>
> Interpreting Twiggy images made with BLU - an anomaly
> <http://groups.google.com/group/lisalist/t/61d10e5e1e34f113?utm_source=digest&utm_medium=email>
> James MacPhail <gg__at_email.domain.hidden>: 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
> Back to top <#m_6423902857968408579_digest_top>
> You received this digest because you're subscribed to updates for this
> group. You can change your settings on the group membership page
> <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/lisalist/join>
> .
> To unsubscribe from this group and stop receiving emails from it send an
> email to lisalist+unsubscribe_at_googlegroups.com.
>

-- 
-- 
-----
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.



text/html attachment: alternate version of message