31 Dec
2001
31 Dec
'01
5:52 a.m.
-----Original Message-----
From: Fred Cisin (XenoSoft) [mailto:cisin@xenosoft.com]
Has anybody ever actually SEEN and USED any software
for the catweasel
that will make an Amiga disk (NOT duplicate one that is present)?
Not me, though, I've seen documents (probably in UAE) that say you can write disks to
images and images to disks if you use it. The linux/netbsd/freebsd drivers, from all
I've seen and heard, should access disks fine for making images and the like.
I think that "MatchPoint" might be their
board that you're
thinkking of.
I was thinking of compati-card, actually. I was un-aware that it had this same
limitation.
I may have to see if I can find one of these "MatchPoint" boards now, though.
What are my chances?
What software is available for Mac to do Amiga disks?
Again, I seem to remember from docs that UAE will use it directly. So you'd be stuck
with a chicken-egg scenario where you need an image of the O/S (or boot disk) to get it
working. :) Otherwise it would work fine.
I have seen mappings for the linux fdparam (I think that's the program..) which will
make your system use the format at a low level, and have heard that catweasel works with
linux. In that case you can image/unimage the disks pretty simply.
As for a program that reads/writes the filesystem (I assume that's what you're
asking...), I don't know of one, but I believe that given the number of people
interested in amiga emulation, somebody must have written one. If they havent, get an
amiga emulator set-up, and chances are that will do it for you. (Again, I seem to remember
mention of this in the UAE docs)
I would, of course, be interested to hear from anyone who's really tried it. :)
Regards,
Chris
Christopher Smith, Perl Developer
Amdocs - Champaign, IL
/usr/bin/perl -e '
print((~"\x95\xc4\xe3"^"Just Another Perl
Hacker.")."\x08!\n");
'
31 Dec
31 Dec
7:34 a.m.
> Has anybody ever actually SEEN and USED any
software for the catweasel
> that will make an Amiga disk (NOT duplicate one that is present)?
On Mon, 31 Dec 2001, Christopher Smith wrote:
Not me, though, I've seen documents (probably in
UAE) that say you can
write disks to images and images to disks if you use it. The
linux/netbsd/freebsd drivers, from all I've seen and heard, should
access disks fine for making images and the like.
That sounds promising. I'd still like to know if anybody has been
successful.
I think that
"MatchPoint" might be their board that you're
thinkking of.
I was thinking of compati-card, actually. I was un-aware that it
had
this same limitation. I may have to see if I can find one of these
"MatchPoint" boards now,
though. What are my chances?
I see them occasionally, but not often.
What software
is available for Mac to do Amiga disks?
Again, I seem to remember from docs that
UAE will use it directly.
So you'd be stuck with a chicken-egg scenario where you need an image
of the O/S (or boot disk) to get it working. :) Otherwise it would
work fine. I have seen mappings for the linux fdparam (I think
that's the
program..) which will make your system use the format at a low level,
and have heard that catweasel works with linux. In that case you can
image/unimage the disks pretty simply.
Certainly the PC hardware, regardless of OS or other software can NOT do
Amiga.
Can the Linux catweasel drivers actually use the catweasel as its disk
controller for the file system? Or is this an issue that the catweasel
software (that does NOT work at a filesystem level) can also RUN under
linux?
As for a program that reads/writes the filesystem (I
assume that's
what you're asking...), I don't know of one, but I believe that given
Yes,
that's exactly what I'm interested in. Sorry, I should have been
clearer.
the number of people interested in amiga emulation,
somebody must have
written one. If they havent, get an amiga emulator set-up, and
chances are that will do it for you. (Again, I seem to remember
mention of this in the UAE docs)
Has anybody, anywhere, EVER gotten a catweasel to work as a controller to
do file system level operations?
I would, of course, be interested to hear from anyone
who's really
tried it. :)
Yes.
I've heard a LOT of people say things like "it can do it" (without having
actually tried) or "it could do it", or "it should be able to do it".
But
never that it DOES do it.
I've yet to see any word from anybody who has successfuly gotten the
catweasel to work in ANY way other than the most low level track read.
It certainly SHOULD be capable. But there seems to be some problems
getting the software working.
--
Grumpy Ol' Fred cisin(a)xenosoft.com
8:29 a.m.
On Mon, 31 Dec 2001, Fred Cisin (XenoSoft) wrote:
Yes. It's a very nice 765 implementation. It can handle single density
(I don't know off-hand whether they used a 37C65, or added extra logic),
can handle 4 drives, can operate at other addresses to permit use as a
second controller, etc.
But it's still a 765. As such, it can not do GCR, can't do hard sectors,
can't do MFM without WD style sector headers (AMIGA!), and can't even do
some WD MFM formats that start the first sector too early.
Allison could tell you EXACTLY what its capabilities and limitations are.
Fred, though I have never seen one, I have heard that they made some of
the CCIVs with the National Semi FDC chips that were a bit more flexible
than the 765.
- don
Hmmm. I'd like to hear if anybody has ever succeeded (as opposed to
theoretical possibilities)
> Has
anybody ever actually SEEN and USED any software for the catweasel
> that will make an Amiga disk (NOT duplicate one that is present)?
On Mon, 31 Dec 2001, Christopher Smith wrote:
Not me, though, I've seen documents (probably
in UAE) that say you can
write disks to images and images to disks if you use it. The
linux/netbsd/freebsd drivers, from all I've seen and heard, should
access disks fine for making images and the like.
That sounds promising. I'd still like to know if anybody has been
successful.
I think
that "MatchPoint" might be their board that you're
thinkking of.
I was thinking of compati-card, actually. I was un-aware that it
had
this same limitation. I may have to
see if I can find one of these "MatchPoint" boards now,
though. What are my chances?
I see them occasionally, but not often.
What
software is available for Mac to do Amiga disks?
Again, I seem to remember from
docs that UAE will use it directly.
So you'd be stuck with a chicken-egg scenario where you need an image
of the O/S (or boot disk) to get it working. :) Otherwise it would
work fine. I have seen mappings for the linux fdparam (I
think that's the
program..) which will make your system use the format at a low level,
and have heard that catweasel works with linux. In that case you can
image/unimage the disks pretty simply.
Certainly the PC hardware, regardless of OS or other software can NOT do
Amiga.
Can the Linux catweasel drivers actually use the catweasel as its disk
controller for the file system? Or is this an issue that the catweasel
software (that does NOT work at a filesystem level) can also RUN under
linux?
As for a program that reads/writes the filesystem
(I assume that's
what you're asking...), I don't know of one, but I believe that given
Yes,
that's exactly what I'm interested in. Sorry, I should have been
clearer.
the number of people interested in amiga
emulation, somebody must have
written one. If they havent, get an amiga emulator set-up, and
chances are that will do it for you. (Again, I seem to remember
mention of this in the UAE docs)
Has anybody, anywhere, EVER gotten a catweasel to work as a controller to
do file system level operations?
I would, of course, be interested to hear from
anyone who's really
tried it. :)
Yes.
I've heard a LOT of people say things like "it can do it" (without having
actually tried) or "it could do it", or "it should be able to do it".
But
never that it DOES do it.
I've yet to see any word from anybody who has successfuly gotten the
catweasel to work in ANY way other than the most low level track read.
It certainly SHOULD be capable. But there seems to be some problems
getting the software working.
--
Grumpy Ol' Fred cisin(a)xenosoft.com
10:16 a.m.
New subject: Compaticard (was: Any AMIGA users?
Yes. It's
a very nice 765 implementation. It can handle single density
(I don't know off-hand whether they used a 37C65, or added extra logic),
can handle 4 drives, can operate at other addresses to permit use as a
second controller, etc.
But it's still a 765. As such, it can not do GCR, can't do hard sectors,
can't do MFM without WD style sector headers (AMIGA!), and can't even do
some WD MFM formats that start the first sector too early.
Allison could tell you EXACTLY what its capabilities and limitations are.
Fred, though I have never seen one, I have heard that
they made some of
the CCIVs with the National Semi FDC chips that were a bit more flexible
than the 765.
But those are still 765s, with the same basic capabilities and
limitations. The added flexibility might help with the "first sector"
issue, but it absolutely will NOT provide the RAW track read that would be
needed for reading Amiga, GCR, etc.
6:44 a.m.
New subject: Compaticard (was: Any AMIGA users?
I may be out of turn here, but I think it's safe to say that the WD chips
will have problems with a track read of GCR and other modulation schemes,
since they're designed for FM and MFM only. A track read does not sample
bits from the medium surface, but, rather looks, with timing synchronized
with the clock presumably extracted from the FM/MFM bitstream, at the data
sream coming from the drive and attempts to make sense of it in the context
of its own track write (format) command. That means that when it thinks it
sees an address mark, it returns the binary token that it accepts as the
command to generate that address mark during a track-write command.
I'd say you'll be disappointed with the WD FDC's ability to interpret GCR.
Here's a description of the READ TRACK command from the data regarding the
179x in the 1983 WD Components Handbook.
"
Upon receipt of the READ TRACK command, the head is loaded and the Busy
Status bit is set. Reading starts with the rising edge of the first
encountered index pulse and continues until the next index pulse. All gap,
header and data bytes are assembled and transferred to the data register and
DRQ's are generated for each byte. The accuulation of bytes is synchronized
to each address mark encounterd. An interrupt is generated at the
completion of the command.
This command has several characteristics which make it suitable for
diagnostic purposes. The are: the Read Gate is not activated during the
commandl; no CRC checking is performed; and the address mark detector is on
for the duration of the command. Because the A.M. detector is always on,
write splices or noise may cause the chip to look for an A.M. If an address
mark does not appear on schedule, the lost data status flag is set.
The ID A.M, ID field, ID CRC bytes, DAM, Data, and Data CRC Bytes for each
sector will be correct. The gap bytes may be read incorrectly diring
write-splice time because of synchronization.
"
Note that this neither confirms or denies my initial remark, but ISTR that I
got that information somewhere else, but still from WD.
Dick
----- Original Message -----
From: "Fred Cisin (XenoSoft)" <cisin(a)xenosoft.com>
To: <classiccmp(a)classiccmp.org>
Sent: Tuesday, January 01, 2002 12:16 AM
Subject: Compaticard (was: Any AMIGA users?
On Mon,
31 Dec 2001, Don Maslin wrote:
> > Yes. It's a very nice 765
implementation. It can handle single
density
> > (I don't know off-hand whether they used
a 37C65, or added extra
logic),
> > can handle 4 drives, can operate at other
addresses to permit use as a
> > second controller, etc.
> > But it's still a 765. As such, it can not do GCR, can't do hard
sectors,
> > can't do MFM without WD style sector
headers (AMIGA!), and can't even
do
> > some WD MFM formats that start the first
sector too early.
> > Allison could tell you EXACTLY what its capabilities and limitations
are.
Fred, though I have never seen one, I have heard
that they made some of
the CCIVs with the National Semi FDC chips that were a bit more flexible
than the 765.
But those are still 765s, with the same basic capabilities and
limitations. The added flexibility might help with the "first sector"
issue, but it absolutely will NOT provide the RAW track read that would be
needed for reading Amiga, GCR, etc.
2:29 p.m.
New subject: Compaticard (was: Any AMIGA users?
On Mon, 31 Dec 2001, Richard Erlacher wrote:
I may be out of turn here,
Only a little, since
you WERE trying to help.
but I think it's safe to say that the WD chips
will have problems with a track read of GCR and other modulation schemes,
since they're designed for FM and MFM only. A track read does not sample
That's nice. But,
WE ARE NOT TALKING ABOUT GCR!!!
WE ARE NOT TALKING ABOUT GCR!!!
The Amiga is NOT GCR!
The Amiga is NOT GCR!
The Amiga IS MFM! But it does not have WD style sector headers.
It reads and writes a track at a time, and parses it in software. There
are no gaps, synchronization issues between sectors, etc.
IFF the Amiga were to be GCR, like other Commodore machines, then your
advice would be entirely correct and valid.
--
Grumpy Ol' Fred cisin(a)xenosoft.com
bits from the medium surface, but, rather looks, with
timing synchronized
with the clock presumably extracted from the FM/MFM bitstream, at the data
sream coming from the drive and attempts to make sense of it in the context
of its own track write (format) command. That means that when it thinks it
sees an address mark, it returns the binary token that it accepts as the
command to generate that address mark during a track-write command.
I'd say you'll be disappointed with the WD FDC's ability to interpret GCR.
Here's a description of the READ TRACK command from the data regarding the
179x in the 1983 WD Components Handbook.
"
Upon receipt of the READ TRACK command, the head is loaded and the Busy
Status bit is set. Reading starts with the rising edge of the first
encountered index pulse and continues until the next index pulse. All gap,
header and data bytes are assembled and transferred to the data register and
DRQ's are generated for each byte. The accuulation of bytes is synchronized
to each address mark encounterd. An interrupt is generated at the
completion of the command.
This command has several characteristics which make it suitable for
diagnostic purposes. The are: the Read Gate is not activated during the
commandl; no CRC checking is performed; and the address mark detector is on
for the duration of the command. Because the A.M. detector is always on,
write splices or noise may cause the chip to look for an A.M. If an address
mark does not appear on schedule, the lost data status flag is set.
The ID A.M, ID field, ID CRC bytes, DAM, Data, and Data CRC Bytes for each
sector will be correct. The gap bytes may be read incorrectly diring
write-splice time because of synchronization.
"
Note that this neither confirms or denies my initial remark, but ISTR that I
got that information somewhere else, but still from WD.
8:11 a.m.
New subject: Compaticard (was: Any AMIGA users?
Then why the statement, " But it's still a 765. As such, it can not do GCR,
...?" That's the only reason I mentioned GCR at all.
Clearly, I misinterpreted the key issue.
Happy New Year!
Dick
----- Original Message -----
From: "Fred Cisin (XenoSoft)" <cisin(a)xenosoft.com>
To: <classiccmp(a)classiccmp.org>
Sent: Tuesday, January 01, 2002 4:29 AM
Subject: Re: Compaticard (was: Any AMIGA users?
On Mon, 31 Dec 2001, Richard Erlacher wrote:
schemes,
I may be out of turn here,
Only a little,
since you WERE trying to help.
> but I think it's safe to say that the WD chips
> will have problems with a track read of GCR and other modulation > since they're designed for FM and MFM only.
A track read does not
sample
That's nice. But,
WE ARE NOT TALKING ABOUT GCR!!!
WE ARE NOT TALKING ABOUT GCR!!!
The Amiga is NOT GCR!
The Amiga is NOT GCR!
The Amiga IS MFM! But it does not have WD style sector headers.
It reads and writes a track at a time, and parses it in software. There
are no gaps, synchronization issues between sectors, etc.
That's almost enough to make one wonder why they used MFM. Had they used
RLL, which requires no complicated, or even simple modulator, they'd have
had half-again the capacity.
IFF the Amiga were to be GCR, like other Commodore machines, then your
advice would be entirely correct and valid.
I'm sure your point is well taken. It's just that I was addressing
another
aspect of the source post.
--
Grumpy Ol' Fred cisin(a)xenosoft.com
> bits from the medium surface, but, rather looks, with timing
synchronized
> with the clock presumably extracted from the
FM/MFM bitstream, at the
data
> sream coming from the drive and attempts to make
sense of it in the
context
> of its own track write (format) command. That
means that when it thinks
it
> sees an address mark, it returns the binary token
that it accepts as the
> command to generate that address mark during a track-write command.
>
> I'd say you'll be disappointed with the WD FDC's ability to interpret
GCR.
>
> Here's a description of the READ TRACK command from the data regarding
the
> 179x in the 1983 WD Components Handbook.
>
> "
> Upon receipt of the READ TRACK command, the head is loaded and the Busy
> Status bit is set. Reading starts with the rising edge of the first
> encountered index pulse and continues until the next index pulse. All
gap,
> header and data bytes are assembled and
transferred to the data register
and
> DRQ's are generated for each byte. The
accuulation of bytes is
synchronized
> to each address mark encounterd. An interrupt is
generated at the
> completion of the command.
>
> This command has several characteristics which make it suitable for
> diagnostic purposes. The are: the Read Gate is not activated during
the
> commandl; no CRC checking is performed; and the
address mark detector
is on
> for the duration of the command. Because the
A.M. detector is always
on,
> write splices or noise may cause the chip to look
for an A.M. If an
address
> mark does not appear on schedule, the lost data
status flag is set.
>
> The ID A.M, ID field, ID CRC bytes, DAM, Data, and Data CRC Bytes for
each
> sector will be correct. The gap bytes may be
read incorrectly diring
> write-splice time because of synchronization.
> "
>
> Note that this neither confirms or denies my initial remark, but ISTR
that I
got that
information somewhere else, but still from WD.
3:34 p.m.
New subject: Compaticard (was: Any AMIGA users?
On Mon, 31 Dec 2001, Richard Erlacher wrote:
Then why the statement, " But it's still a
765. As such, it can not do GCR,
...?" That's the only reason I mentioned GCR at all.
The "only a 765" was in rebuttal to the possibility that the Compaticard
would have "significant" additional capabilities over other disk
controller cards. In other ways besides the issue of Amiga under
discussion.
Neither major family of disk controller chips can do GCR.
GCR, hard sectoring, etc. are merely SOME of the limitations of an FDC.
But the problem with AMiga isn't GCR. It's MFM without the WD structure.
In the case of 765 v WD, the WD "raw" track read v the parsed read of the
765 becomes significant.
The WD can be used to do Amiga, but with a few complications. Handling of
stuff that could be misinterpreted as commands to do address marks might
be one.
Clearly, I misinterpreted the key issue.
Only in
terms of the central issue of R/W Amiga.
Happy New Year!
Have a good one
--
Grumpy Ol' Fred cisin(a)xenosoft.com
1 Jan
1 Jan
12:13 a.m.
New subject: Compaticard (was: Any AMIGA users?
At 10:11 PM 12/31/2001 +0000, Richard Erlacher wrote:
The Amiga did the MFM decoding using software and its
custom chip - the blitter, I believe, which could perform
somewhat complex logical operations. They no doubt did this
to save on hardware, like Woz's disk controller.
- John
The Amiga IS
MFM! But it does not have WD style sector headers.
It reads and writes a track at a time, and parses it in software. There
are no gaps, synchronization issues between sectors, etc.
That's almost enough to make one wonder why they used MFM. Had they used
RLL, which requires no complicated, or even simple modulator, they'd have
had half-again the capacity.
1:51 a.m.
New subject: Compaticard (was: Any AMIGA users?
see below, plz.
Dick
----- Original Message -----
From: "John Foust" <jfoust(a)threedee.com
To: <classiccmp(a)classiccmp.org
Sent: Tuesday, January 01, 2002 7:13 AM
Subject: Re: Compaticard (was: Any AMIGA users?
The Amiga did the MFM decoding using software and its
custom chip - the blitter, I believe, which could perform
somewhat complex logical operations. They no doubt did this
to save on hardware, like Woz's disk controller.
The specific hardware required to do the RLL would have been an 'LS299 shift
register, and little else. I expect the choice was made because it was
considered adequate and considerably easier to use an essentially
hard-sectored (single-sectored) scheme than to introduce the overhead, and
resulting loss in capacity, imposed by multiple sectors. The early
Tallgrass Technologies controllers, e.g. the one for S-100 used that
strategy together with GCR. Once you decide to use a single sector and sort
it out in software, the modulation scheme is quite arbitrary.
At 10:11 PM 12/31/2001 +0000, Richard Erlacher wrote:
please note that I didn't write this, since I'm quite ignorant of AMIGA
matters.
>> The Amiga IS MFM! But it does not have WD
style sector headers.
>> It reads and writes a track at a time, and parses it in software.
There
are no gaps, synchronization issues between sectors,
etc.
That's almost enough to make one wonder why they used MFM. Had they used
RLL, which requires no complicated, or even simple modulator, they'd have
had half-again the capacity. 
2:06 a.m.
New subject: Compaticard (was: Any AMIGA users?
The Amiga did the MFM decoding using software and its
custom chip - the blitter, I believe, which could perform
somewhat complex logical operations. They no doubt did this
to save on hardware, like Woz's disk controller.
Isn't it Paula that handles the interface to me floppy drive?
Jeff
--
Home of the TRS-80 Model 2000 FAQ File
http://www.cchaven.com
http://www.geocities.com/siliconvalley/lakes/6757
1:51 p.m.
New subject: Compaticard (was: Any AMIGA users?
--- Jeff Hellige <jhellige(a)earthlink.net> wrote:
You are both right, but the full answer is more bizarre than that...
Paula has a monster shift-register that imports or emits enough bits
to fill a track of data without dropping bits or running dry (at the
regular rotation speed which is why they chose to make their HD floppies
spin at half the standard rotation rate - so old Paula chips could
keep up and so they wouldn't have to make a new Paula). Effectively,
for a read, you turn on the input circuit and set a timer and hose about
1.1 x the number of raw MFM bits in a track, header bits and all, into
a CHIP RAM buffer. I think the CPU searches for the start of data (but
it could be the Blitter) and then the next stage is all done by the
blitter.
With that RAW bitstream in CHIP RAM where everybody can get to it, and
with knowing where in that buffer the start and end of the track are,
the Blitter moves the stuff before the start of data in RAM to the
end of the buffer, so it's all in order. I wish I could draw a picture,
but ASCII art circles are tough. It's this messy because Paula doesn't
care/know where the disk is when the read starts (or a write, for that
matter, because every sector is re-written on a write).
Once the buffer is in order, the Blitter runs a set of mini-terms on it
to convert it from MFM into binary and the results are handed to the
guy that requested them in the first place.
Your program makes whatever changes to the data are necessary, then
calls the trackdisk.device to reverse the process - the Blitter converts
the binary data into an MFM stream, then Paula hoses about 10% of a track
of header bits, then follows it with the data, ensuring that every bit on
that track has just been set (with a little overlap for safety).
One of the CIAs is also part of this process, but it's used to drive the
positioner motor, check the diskchange bit, etc.
All in all, it takes part of Paula, part of Agnus (the Blitter) and
part of a CIA to drive the floppy drive on an Amiga - three custom
chips (Denise does not take part, AFAIK). I guess Jay Miner decided that
since most of this stuff was in there anyway (everything but the monster
shift-register), why spring for an extra, dedicated FDC? It's not like
the Mac or several other computers of the era had an off-the-shelf FDC
(compare the C= 1541 with the C=1581, among other examples).
-ethan
__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com
The Amiga did
the MFM decoding using software and its
custom chip - the blitter, I believe, which could perform
somewhat complex logical operations. They no doubt did this
to save on hardware, like Woz's disk controller.
Isn't it Paula that handles the interface to me floppy drive?
31 Dec
31 Dec
3:37 p.m.
New subject: Compaticard (was: Any AMIGA users?
On Mon, 31 Dec 2001, Fred Cisin (XenoSoft) wrote:
On Mon, 31 Dec 2001, Don Maslin wrote:
Agreed! But were they not also, perhaps, capable of coping with the
`dreaded' 128byte MFM sector bugaboo?
- don
Yes. It's a very nice 765 implementation. It can
handle single density
(I don't know off-hand whether they used a 37C65, or added extra logic),
can handle 4 drives, can operate at other addresses to permit use as a
second controller, etc.
But it's still a 765. As such, it can not do GCR, can't do hard sectors,
can't do MFM without WD style sector headers (AMIGA!), and can't even do
some WD MFM formats that start the first sector too early.
Allison could tell you EXACTLY what its capabilities and limitations are.
Fred, though I have never seen one, I have heard
that they made some of
the CCIVs with the National Semi FDC chips that were a bit more flexible
than the 765.
But those are still 765s, with the same basic capabilities and
limitations. The added flexibility might help with the "first sector"
issue, but it absolutely will NOT provide the RAW track read that would be
needed for reading Amiga, GCR, etc.
3:57 p.m.
New subject: Compaticard (was: Any AMIGA users?
> But those are still 765s, with the same basic
capabilities and
> limitations. The added flexibility might help with the "first sector"
> issue, but it absolutely will NOT provide the RAW track read that would be
> needed for reading Amiga, GCR, etc.
On Mon, 31 Dec 2001, Don Maslin wrote:
Agreed! But were they not also, perhaps, capable of
coping with the
`dreaded' 128byte MFM sector bugaboo?
That would be sweet.
Now I'm going to have to dig out the totes of extra disk controller cards
and see which ones I have.
--
Grumpy Ol' Fred cisin(a)xenosoft.com
8391
days inactive
8392
days old
13 comments
7 participants
participants (7)
-
cisin＠xenosoft.com -
csmith＠amdocs.com -
donm＠cts.com -
edick＠idcomm.com -
erd_6502＠yahoo.com -
jfoust＠threedee.com -
jhellige＠earthlink.net