>From: "Fred Cisin" <cisin at xenosoft.com>
>
>On Wed, 3 Aug 2005, Allison wrote:
>> Dave, your on track. The CHRN vlaues do not have to corrospond
>> to actual head or cylinder. They do not even have to be in order
>> on the media! The only limits on them are R must be 1 or greater
>> (less than 255).
>
>Which creates some complications with handling 128 byte sectors (R==0).
>
>> My favorite format was sectors 1- 9 (512 DD) on side one and
>> side two was 10-19 with H always set to 0.
>
>Easily handled by 765, but not by Int13h.
>
>I have to be careful to differentiate which complications are
>due to the FDC chip, which to the FDC board/implementation,
>and which are BIOS linitations.
>
>
>Nitpick: don't you mean 0 - 9 on first side? Or did it actually have 9
>sectors on one side and 10 sectors on the other?
>
>I've seen disks with 10h and 20h in the H field.
>
>My favorite was 1 in the H field for the first side and 0 in the H
>field on the second side.
>
>And, of course, there are some formats, such as Superbrain,
>where the data (sector content) is inverted,
>but the headers (CHRN) are not.
Hi
How about the sector number being bit reversed but
the data not ( my Nicolet 1080 ). Actually it is
a record numbers, not sector but used in place of
sector headers. When I was trying to figure out how
to format the disk, this cause me a lot of grief.
The only record I could get to work was 0.
Dwight
Dwight
>
>Subject: Re: Grrr - !%#*^@# Kaypro!
> From: Dave Dunfield <dave04a at dunfield.com>
> Date: Wed, 03 Aug 2005 18:04:39 -0400
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>
>>> Tried ImageDisk on some Kaypro disks this morning...
>>> Buggers recorded side1 as additional sectors of side0.
>>> The different set of sector numbers didn't bother
>>> ImageDisk, but it had a bit of a tantrum with the Head
>>> ids which didn't match the physical head selection.
>>
>>Quite common :-(
>>765 insists on accurate sector headers;
>>WD 179x can ignore the head # field in the sector headers.
>>The Kaypro won't even mind reading/writing a disk,
>>if you FORMAT it with a 765 using valid sector headers!
>
>Actually, the 765 handles it fine ... my original software
>stored only the physical head indicator per track - now I
>can store a map of indicators for each sector, and it
>reads/formats/writes Kaypro (and Zorba which does the same
>thing) disks without issue.
>
>You do have to tell the 765 what "head" you are reading in
>the ID field, but fortunately you can do this imdependantly
>of the physical head select - I determine all the sector
>headers in the analysis phase, so I "know" which heads to
>request now...
Dave, your on track. The CHRN vlaues do not have to corrospond
to actual head or cylinder. They do not even have to be in order
on the media! The only limits on them are R must be 1 or greater
(less than 255).
My favorite format was sectors 1- 9 (512 DD) on side one and
side two was 10-19 with H always set to 0.
Allison
>From: "Fred Cisin" <cisin at xenosoft.com>
>
>On Wed, 3 Aug 2005, Dave Dunfield wrote:
>> Tried ImageDisk on some Kaypro disks this morning...
>> Buggers recorded side1 as additional sectors of side0.
>> The different set of sector numbers didn't bother
>> ImageDisk, but it had a bit of a tantrum with the Head
>> ids which didn't match the physical head selection.
>
>Quite common :-(
>765 insists on accurate sector headers;
>WD 179x can ignore the head # field in the sector headers.
>The Kaypro won't even mind reading/writing a disk,
>if you FORMAT it with a 765 using valid sector headers!
>
>
>> I can imagine that someone somewhere does weird things
>> with the Cylinder ids on a track as well ...
>
>Rare. I've only seen it a few times.
>
Hi
At least for Dave's setup, he could get by with
a bypass switch on the head selector. It is always
funny what different setups have done. At least there
is a potential bypass for this one.
I'd guess the fellow that wrote the driver for the
Kaypro didn't have a problem so he didn't notice the
missing head information in the sector header. He
may have thought the controller took care of this
somehow. I know when I've fiddled with the disk controller
directly, it isn't always clear when and where
each register takes effect. There are a few places
that it seem that there is redundant information.
Dwight
>> Tried ImageDisk on some Kaypro disks this morning...
>> Buggers recorded side1 as additional sectors of side0.
>> The different set of sector numbers didn't bother
>> ImageDisk, but it had a bit of a tantrum with the Head
>> ids which didn't match the physical head selection.
>
>Quite common :-(
>765 insists on accurate sector headers;
>WD 179x can ignore the head # field in the sector headers.
>The Kaypro won't even mind reading/writing a disk,
>if you FORMAT it with a 765 using valid sector headers!
Actually, the 765 handles it fine ... my original software
stored only the physical head indicator per track - now I
can store a map of indicators for each sector, and it
reads/formats/writes Kaypro (and Zorba which does the same
thing) disks without issue.
You do have to tell the 765 what "head" you are reading in
the ID field, but fortunately you can do this imdependantly
of the physical head select - I determine all the sector
headers in the analysis phase, so I "know" which heads to
request now...
Regards,
Dave
--
dave04a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.parse.com/~ddunfield/museum/index.html
Tried ImageDisk on some Kaypro disks this morning...
Buggers recorded side1 as additional sectors of side0.
The different set of sector numbers didn't bother
ImageDisk, but it had a bit of a tantrum with the Head
ids which didn't match the physical head selection.
I can imagine that someone somewhere does weird things
with the Cylinder ids on a track as well ...
So .. as of a few minutes ago, ImageDisk can handle non-
standard Cylinder and Head ids on individual sectors.
I added this in a way which is backward compatible with
the existing image file format - basically, I used two
unused bits at the top of the track Head indicator to
indicate the presence of a "sector Cylinder map", and/or
a "sector Head map" - these maps will be present when the
track contains cylinder/head values which do not match
the physical location of the track.
I'll post the updated version later today after I have done
some further testing.
Regards,
Dave
--
dave04a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.parse.com/~ddunfield/museum/index.html
I was wondering:
I read on vaxennet.com that you can somehow combine a VT220 and VT240 (see
their description of the VT240). This doesn't make any sense to me as I
figured you can only use one or the other, and that you plug a
monitor/keyboard into the VT240, and a VT220 is not a monitor but a
terminal.
Can anyone shed some light on this?
Thanks
Julian
>
>Subject: Re: ImageDisk and some 8" images posted
> From: Dave Dunfield <dave04a at dunfield.com>
> Date: Tue, 02 Aug 2005 23:06:48 -0400
> To: cctalk at classiccmp.org
>
>At 21:13 02/08/2005 -0500, you wrote:
>>On 8/2/05, Dave Dunfield <dave04a at dunfield.com> wrote:
>>> I've posted the latest version of ImageDisk and some 8" images that
>>> I have archived with it on my classic collection page:
>>>
>>> http://www.parse.com/~ddunfield/museum/index.html
>>>
Dave,
Just do it as they say. Even if it's not a 100% solution it's often
much more than many have.
In engineering there is Good, Fast and Cheap, Pick any two.
Now for some opinion:
There are a few groups doing archive(s).
Those that have working systems and a way to transfer off the system to
"something" thereby preserving stuff in case of some failure. Often to
enable other user of same to work with it.
The other has nothing but media and want access to content. That's
more than imaging.
Other than that there are those that have ZXY and need a "disk" and want
it in ZXY format. Often it's a oneshot(or limited use) deal and BTW it
must be cheap.
Did I miss any? Likely only a few and they are so unique that a oneoff is
the likely solution.
Maybe I'm jaded but there are formats that while seemingly worth preserving
they have libilities. For example, NS*, works well lots around but media
is near extinct and when gone it will be gone for ever. Preseriving NS*
media in NS* format has problems, at some point even if you can spit it
out to a drive the media to go in it is a whole nother matter. Sort of
leaves you with climate controlled space so the media literally doesn't
fail solution.
In the end I've worked to save software that can be used off media. For
example I have NS*dos and like it but when the media dies what use is it
as it's unusable with other controllers. Granted I could create a NSdos
look alike that runs using soft sector or even sandisk. But what the
point? Years ago I standardized on a limited subset of formats and media
so I could preserve binaries and sources for use. Why? because back in
the late 70s through early 80s the problem was none of the system could
exchange anything even if the Cpu, OS and all were identical. I needed
that like a hole in the head then and preserving it now strikes as useful
but only to a point. In the end there was only one standard I had and
still have, a serial line to another system. That was archive that
worked for the last 25+ years.
I'm sure I'll get flamed to the max but.. I'm not "facility" or "institution"
I use the stuff and enjoy it as it's possible. Some of that is doing what
I'd have liked to back then when time or money said I could not.
Allison
>> > Speaking of which: are there other people out there who collect
>> > development hardware?
I don't exactly collect them, but being in the business of creating tools
for 8/16-bit devices, I have a BIG pile of assorted evaluation boards,
emulation boards, a few ICE's and also a bunch of in-house built development
boards.
Dave
--
dave04a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.parse.com/~ddunfield/museum/index.html
Out of interest, what's actually changed between the catweasel
revisions? I mean, I thought they always buffered stuff at the track
level and did all the decoding / encoding work in software? So I'm
surprised the hardware isn't pretty simple and able to support pretty
much anything without several revisions...
--
switch from ISA to PCI, then changing from programmed to downloaded
fpga
they also got rid of some problems dealing with hard-sectored discs
the problem with it is both the skanky hardware distribution and
software. the useful stuff was all written by Tim Mann.
its target market really is not for data recovery.
