27 Jul
2023
27 Jul
'23
8:38 p.m.
On Jul 27, 2023, at 4:24 PM, Fred Cisin via cctalk
<cctalk(a)classiccmp.org> wrote:
On Thu, 27 Jul 2023, Chris Zach via cctalk wrote:
Agreed. The SIMH logic is that the container file addressing matches the addressing
exposed at the interface between device and driver. In the RX50 case, that is
"logical order" because the MSCP controllers work that way. Conversely, in
XHomer it's physical order, because the Pro RX controller works that way.
Really? So SIMH doesn't work with the images,
or it's "slow"?
I prefer to keep images close to "real" as I may want to write them back to
physical floppies. For reference, these images do work with um.... the Goteks which is
what I would use to load onto real equipment.
Why in the name of heaven would SIMH not support proper disk formats?
When transferring files, often the sequence of sectors must be rearranged so that the
data on the disk properly creates the information of the files.
However, when making IMAGES OF DISKS, what is the "proper" sequence?
Should the imaging prograam re-arrange the sectors into their logical order?
Or should the imaging prograam maintain the physical sequence of the sectors?
This is not entirely a rhetorical question.
(Don't you hate rhetorical questions?)
If using the information from the disk, obviously you want "logical" order.
If using the image as data to recreate a disk, obviously you want physical order. Of course, ideally, imaging programs should support
both outputs, and programs working from images should support both inputs.
Sure, which is why I mentioned that it would make a worth while new feature for SIMH.
paul