15 May
2002
15 May
'02
5:45 a.m.
I'm trying to get one, and wondering what success people have had with
connecting them to a PC using "X-Cables" and "Star commander" to
transfer
data ( http://sta.c64.org/sc.html ). Also, is there any chance of making
a 1541 read an Apple ][ disk? I know they both use GCR encodings for
their disks, and it'd be really useful if I could read disks on my PC.
Also, does anyone know anywhere I could get a Compaticard (and any
necessary drivers to make it useful)? I've looked on ebay a few times now
and still haven't seen one...
-- Pat
15 May
15 May
5:54 a.m.
And thusly Pat Finnegan spake:
I'm trying to get one, and wondering what success people have had with
connecting them to a PC using "X-Cables" and "Star commander" to
transfer
data ( http://sta.c64.org/sc.html ). Also, is there any chance of making
I have had no problem - I even built my own XE1541 cable. I use the cable
with a 128 and 64HDD and with a 1571 and Star Commander.
Cheers,
Bryan
6:42 a.m.
I built one of the standard X1541 cables, very easy even for a soldering
screw-up like myself.
I was unable to make Star Commander do its thing, it would hang everytime
I tried to write a disk image, I ended up using Trans64 which works
beautifully.
JP
On Wed, 15 May 2002, Pat Finnegan wrote:
I'm trying to get one, and wondering what success
people have had with
connecting them to a PC using "X-Cables" and "Star commander" to
transfer
data ( http://sta.c64.org/sc.html ). Also, is there any chance of making
a 1541 read an Apple ][ disk? I know they both use GCR encodings for
their disks, and it'd be really useful if I could read disks on my PC.
7:46 a.m.
--- Pat Finnegan <pat(a)purdueriots.com> wrote:
I'm trying to get one, and wondering what success
people have had with
connecting them to a PC using "X-Cables" and "Star commander" to
transfer
data ( http://sta.c64.org/sc.html ).
I have a homemade cable that is the model *before* the X cables were
devised. I keep a 486 around for reading 1541 disks.
Also, is there any chance of making
a 1541 read an Apple ][ disk? I know they both use GCR encodings for
their disks, and it'd be really useful if I could read disks on my PC.
Not as far as I know. I think the lowest bit density on the 1541
is identical to what the Apple ][ uses over the entire surface (it's
17 sectors of 256 bytes on the 1541, vs 16 on the Apple ][, but
due to header/trailer differences), but I do not recall a single
program or trick to read an Apple disk in a 1541.
I was a beta tester for the Spartan Mimic, the expensive and unpopular
Apple "emulator" for the C-64 (co-processor is more like it). One of
the boards that came in the box was a card that sat inside the 1541,
between the drive mech and the 1541 mainboard. It had lots of relays
and stole the drive mech out from under the 1541 board. That was
the only Commodore drive I ever saw read an Apple ][ disk, and it
still needed an Apple controller to do it (there was a 20-pin connector
on the Spartan drive board).
Among other differences (smart vs dumb peripherals), the 1541 depends
on a certain header design - there's an 8-input NAND hooked to a shift
register on the input side, and the Set Overflow pin of the 6502 on
the other. When a bunch of 1s go streaming past the head, this logic
kicks the processor out of a tight loop where it branches to itself
while the overflow bit is clear. This, coupled with precise timing,
lets the 6502 in the drive know when to grab the data from the sector
header. I can't describe how the Apple ][ state machine PROM works,
but it is its own flavor of beast, resembling nothing else in the
home-computer arena. I'm not surprised that nobody ever got things
to read in other brands of computer.
Also, does anyone know anywhere I could get a
Compaticard (and any
necessary drivers to make it useful)? I've looked on ebay a few times now
and still haven't seen one...
Can't help you there.
-ethan
__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com
9:43 a.m.
it's well to remember the "GCR" stands for group-coded-recording, which can
mean a lot of things, and that it's a form of "RLL," or
run-length-limited"
encoding. Both operate in a way that generates, typically, more transitions
in the aggregate, than the original (NRZ) data stream, but locates the
transitions propitiously in a way that limits their density so that it remains
within the head-media combination's capability to resolve those transitons
accurately enough to allow data recovery. That leaves LOTS of room, and it's
in this room where both the Apple scheme and the Commodore scheme live. My
Apple-targeted HDC from back in the early '80's used ANSI standard
group-codes, which, certainly isn't the only uesable scheme one could use, but
it was established, and I could hand it to someone to build a lookup table for
me, which is what I did.
Woz did something different, and so, probably, did the Commodore guys. To
qualify for group-coded-recording, all one required was a unique mapping from
one pattern to another, and and back again, and both schemes accomplish that.
The purpose of the scheme is to rearrange the flux transitions so the system
can tolerate them, yet allow more of them to be represented within a given
linear distance of head travel with respect to the media.
Dick
----- Original Message -----
From: "Ethan Dicks" <erd_6502(a)yahoo.com>
To: <cctalk(a)classiccmp.org>
Sent: Wednesday, May 15, 2002 10:46 AM
Subject: Re: [CCTALK] Commodore 1541 Drive
--- Pat Finnegan <pat(a)purdueriots.com> wrote:
I'm trying to get one, and wondering what
success people have had with
connecting them to a PC using "X-Cables" and "Star commander" to
transfer
data ( http://sta.c64.org/sc.html ).
I have a homemade cable that is the model *before* the X cables were
devised. I keep a 486 around for reading 1541 disks.
Also, is there any chance of making
a 1541 read an Apple ][ disk? I know they both use GCR encodings for
their disks, and it'd be really useful if I could read disks on my PC.
Not as far as I know. I think the lowest bit density on the 1541
is identical to what the Apple ][ uses over the entire surface (it's
17 sectors of 256 bytes on the 1541, vs 16 on the Apple ][, but
due to header/trailer differences), but I do not recall a single
program or trick to read an Apple disk in a 1541.
I was a beta tester for the Spartan Mimic, the expensive and unpopular
Apple "emulator" for the C-64 (co-processor is more like it). One of
the boards that came in the box was a card that sat inside the 1541,
between the drive mech and the 1541 mainboard. It had lots of relays
and stole the drive mech out from under the 1541 board. That was
the only Commodore drive I ever saw read an Apple ][ disk, and it
still needed an Apple controller to do it (there was a 20-pin connector
on the Spartan drive board).
Among other differences (smart vs dumb peripherals), the 1541 depends
on a certain header design - there's an 8-input NAND hooked to a shift
register on the input side, and the Set Overflow pin of the 6502 on
the other. When a bunch of 1s go streaming past the head, this logic
kicks the processor out of a tight loop where it branches to itself
while the overflow bit is clear. This, coupled with precise timing,
lets the 6502 in the drive know when to grab the data from the sector
header. I can't describe how the Apple ][ state machine PROM works,
but it is its own flavor of beast, resembling nothing else in the
home-computer arena. I'm not surprised that nobody ever got things
to read in other brands of computer.
Also, does anyone know anywhere I could get a
Compaticard (and any
necessary drivers to make it useful)? I've looked on ebay a few times now
and still haven't seen one...
Can't help you there.
-ethan
__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com
_______________________________________________
cctalk mailing list
cctalk(a)classiccmp.org
http://www.classiccmp.org/mailman/listinfo/cctalk
10:40 a.m.
--- Richard Erlacher <edick(a)idcomm.com> wrote:
it's well to remember the "GCR" stands
for group-coded-recording, which
can mean a lot of things, and that it's a form of "RLL," or
run-length-limited" encoding. Both operate in a way that generates,
typically, more transitions in the aggregate, than the original (NRZ)
data stream, but locates the transitions propitiously in a way that
limits their density so that it remains within the head-media
combination's capability to resolve those transitons accurately enough
to allow data recovery.
To summarize: (from 1541 tech docs)... you can't have more than two
adjacent physical zero bits on the media because the clocking of the
third bit and beyond gets to be too much guesswork. You can't have
too many (7? 8?) one bits in a row because that triggers the circuit
I described earlier that detects start of header data. Remember, also,
that it's a serial bit stream, so the zeros or ones of one GCR group
have to be considered when placed next to any other GCR group, front
or back.
The GCR used by Commdore is a 5-to-4 arrangement - five bits on the
disks (32 possibilities) are used to encode 4 data bits (16 possibilities).
I don't have the docs right in front of me, but I think I can take a stab
at what patterns aren't used just based on following those two rules above
Too many 0s in front, back or middle...
00000 00001 00010 00011 00100 00101 00110 00111
01000 01100 10000 10001 10100 11000 11100
Too many 1s in front, back or middle...
11111
Good patterns
01001 01010 01011 01101 01110 01111 10010 10011
10101 10110 10111 11001 11010 11011 11101 11110
If I had a copy of "Inside the 1541" or the like, I'd look it up, but I
don't have one in front of me. Essentally, the disk stores those GCR
codes and the 1541 processor translates buffers back and forth manually,
kinda like an Amiga with MFM, but without a coprocessor.
That leaves LOTS of room, and it's in this room
where both the Apple
scheme and the Commodore scheme live.
Agreed. I do not know how Apple does it. At least the 1541 converts
GCR<->binary in software.
-ethan
__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com
1:04 p.m.
The ways in which Apple and Commodore do it are well documented today. Back
in the '80's it was much easier to think of it as a table lookup. Some
controllers used a more conventional approach, i.e. using a standard
controller\formatter to generate the track format, then writing the data
fields in a different modulation, simply substituting the input/output from
one serializer/deserializer for another for a precisely prescribed bit count.
On floppy disk interfaces, the data rate was plenty slow enough to allow that
sort of thing.
I personally preferred the table lookup. That enabled me to put half-again
the usual amount of data on the disk simply by looking up the 5-bit pattern
corresponding to each 4-bits of data. The resulting data could be written at
nearly twice the data rate, resulting in an 8:5 appreciation in capacity.
Various RLL schemes work that way. That's why the RLL controllers provide 9/5
the capacity
Dick
----- Original Message -----
From: "Ethan Dicks" <erd_6502(a)yahoo.com>
To: <cctalk(a)classiccmp.org>
Sent: Wednesday, May 15, 2002 1:40 PM
Subject: Re: [CCTALK] Commodore 1541 Drive
--- Richard Erlacher <edick(a)idcomm.com> wrote:
it's well to remember the "GCR"
stands for group-coded-recording, which
can mean a lot of things, and that it's a form of "RLL," or
run-length-limited" encoding. Both operate in a way that generates,
typically, more transitions in the aggregate, than the original (NRZ)
data stream, but locates the transitions propitiously in a way that
limits their density so that it remains within the head-media
combination's capability to resolve those transitons accurately enough
to allow data recovery.
To summarize: (from 1541 tech docs)... you can't have more than two
adjacent physical zero bits on the media because the clocking of the
third bit and beyond gets to be too much guesswork. You can't have
too many (7? 8?) one bits in a row because that triggers the circuit
I described earlier that detects start of header data. Remember, also,
that it's a serial bit stream, so the zeros or ones of one GCR group
have to be considered when placed next to any other GCR group, front
or back.
The GCR used by Commdore is a 5-to-4 arrangement - five bits on the
disks (32 possibilities) are used to encode 4 data bits (16 possibilities).
I don't have the docs right in front of me, but I think I can take a stab
at what patterns aren't used just based on following those two rules above
Too many 0s in front, back or middle...
00000 00001 00010 00011 00100 00101 00110 00111
01000 01100 10000 10001 10100 11000 11100
Too many 1s in front, back or middle...
11111
Good patterns
01001 01010 01011 01101 01110 01111 10010 10011
10101 10110 10111 11001 11010 11011 11101 11110
If I had a copy of "Inside the 1541" or the like, I'd look it up, but I
don't have one in front of me. Essentally, the disk stores those GCR
codes and the 1541 processor translates buffers back and forth manually,
kinda like an Amiga with MFM, but without a coprocessor.
That leaves LOTS of room, and it's in this
room where both the Apple
scheme and the Commodore scheme live.
Agreed. I do not know how Apple does it. At least the 1541 converts
GCR<->binary in software.
-ethan
__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com
_______________________________________________
cctalk mailing list
cctalk(a)classiccmp.org
http://www.classiccmp.org/mailman/listinfo/cctalk
2:07 p.m.
On Wed, 15 May 2002, Ethan Dicks wrote:
The GCR used by Commdore is a 5-to-4 arrangement -
five bits on the
disks (32 possibilities) are used to encode 4 data bits (16 possibilities).
Very similar to how the Apple disk drive works. But the description of
encoding is different (though the mechanism probably the same).
On the Apple we have 6&2 encoding and 4&4. What this means is that 6 bits
of an 8-bit byte are stored in one group of data inside a sector and the
remaining 2-bits are shared with the remaining 2-bits of 2 other bytes (to
come up with another 6-bit value). A translation table is used to map the
6-bit value to an 8-bit value than can be legally written onto disk.
I don't have the docs right in front of me, but I
think I can take a stab
at what patterns aren't used just based on following those two rules above
Too many 0s in front, back or middle...
00000 00001 00010 00011 00100 00101 00110 00111
01000 01100 10000 10001 10100 11000 11100
Too many 1s in front, back or middle...
11111
Good patterns
01001 01010 01011 01101 01110 01111 10010 10011
10101 10110 10111 11001 11010 11011 11101 11110
The translation table contains 8-bit bytes that would generally be
equivalent to what Ethan has posted. I.E. bytes that do not violate the
rule that no more than two consecutive zero bits can be written and no
more than (some number) of one bits (I am not quite sure how many
consecutive 1-bits are legal on the Apple Disk ][, or if there is a
limitation. I know that there are special bytes called "sync bytes" that
are 8 1-bits followed by two 0-bits, the idea being that a mess of them
are written at the beginning of a track and the beginning of sectors, so
that no matter where they begin being read, they will always eventually
"sync up" to a pattern of eight 1-bits followed by two 0-bits).
The 4&4 encoding is simple. One 8-bit byte is stored inside two 8-bit
bytes. Each bit of the byte is interleaved inside a series of 1 bits. So
for example, the value 10001100 which contains at least one obvious
example of an illegal bit string would be encoded as such:
11101010 11111010
^ ^ ^ ^ ^ ^ ^ ^
1 0 0 0 1 1 0 0
This is how sector header and trailer data is written on an Apple ][
formatted disk.
If I had a copy of "Inside the 1541" or the
like, I'd look it up, but I
don't have one in front of me. Essentally, the disk stores those GCR
codes and the 1541 processor translates buffers back and forth manually,
kinda like an Amiga with MFM, but without a coprocessor.
The same thing goes on in Apple DOS and ProDOS, except it's all done in
software (in the main machine). The equivalent reference book would be
_Beneath Apple DOS_ or _Beneath Apple ProDOS_ both by Quality Software,
and both highly recommended.
Also, the manual for Bag of Tricks (an excellent early disk repair tool)
has lots of relevant and very worthwhile information.
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
* Old computing resources for business and academia at www.VintageTech.com *
2:26 p.m.
New subject: [CCTALK] OT? (was: Commodore 1541 Drive
I thought that cctalk was supposed to have all of the off-topic stuff.
But, with the arguable exception of some silliness about processors being
named after how many transistors they have, it has been all ON topic!
Where is Dick when we need him?
BTW, I'll second the recommendation of Beneath Apple-Dos. It really saved
me when I was trying to figure out the Apple GCR for writing the Apple
Turnover software.
--
Grumpy Ol' Fred cisin(a)xenosoft.com
2:39 p.m.
New subject: [CCTALK] Be picture posted
If anyone is interested in the scan I did of the Be
prototype's video card, it can be found at:
http://www.geocities.com/j_hellige/images/hobbit_video.jpg
It's a JPG (roughly 800x600) converted/downgraded from a 600dpi TIFF.
Jeff
--
Home of the TRS-80 Model 2000 FAQ File
http://www.cchaven.com
http://www.geocities.com/siliconvalley/lakes/6757
2:54 p.m.
New subject: [CCTALK] Be picture posted
If anyone is interested in the scan I did of the Be
prototype's video card, it can be found at:
http://www.geocities.com/j_hellige/images/hobbit_video.jpg
It's a JPG (roughly 800x600) converted/downgraded from a 600dpi TIFF.
Sometimes I hate Geocities....this one should work better:
http://www.geocities.com/siliconvalley/lakes/6757/images/hobbit_video.jpg
Jeff
--
Home of the TRS-80 Model 2000 FAQ File
http://www.cchaven.com
http://www.geocities.com/siliconvalley/lakes/6757
9:18 a.m.
Pat Finnegan wrote:
I'm trying to get one, and wondering what success people have had with
connecting them to a PC using "X-Cables" and "Star commander" to
transfer
data ( http://sta.c64.org/sc.html ). Also, is there any chance of making
a 1541 read an Apple ][ disk? I know they both use GCR encodings for
their disks, and it'd be really useful if I could read disks on my PC.
Also, does anyone know anywhere I could get a Compaticard (and any
necessary drivers to make it useful)? I've looked on ebay a few times now
and still haven't seen one...
-- Pat
AFAIK, the 1541 only does its own SSSD disks. The 1571 OTOH does
several cp/m MFM formats. You could do some limited changing of DOS in
the controller, but it is very limited. If you can lay your hands on
"Inside Commodore DOS" by Richard Inmers & Gerald Neufeld (ISBN
0-88190-266) you might be able to hack it to read Apple disks.
3:47 p.m.
I'm trying to get one, and wondering what success
people have had with
connecting them to a PC using "X-Cables" and "Star commander" to
transfer
data ( http://sta.c64.org/sc.html ).
I use it all the time and it works 100%. Great utility. SC likes older PCs
better due to motherboard and Windows issues (I run it on a 486DX/40 with
DOS 6), but it should work okay on most modern PCs fine.
Also, is there any chance of making
a 1541 read an Apple ][ disk? I know they both use GCR encodings for
their disks, and it'd be really useful if I could read disks on my PC.
Completely different encoding format as others have explained. GCR is more
a philosophy than a true encoding standard.
That being said, since the 1541 is an intelligent peripheral I suppose you
could reprogram it to read Apple floppies, but this would require a lot of
work and is certainly beyond my non-white-hat-consciousness.
--
----------------------------- personal page: http://www.armory.com/~spectre/ --
Cameron Kaiser, Point Loma Nazarene University * ckaiser(a)stockholm.ptloma.edu
-- Time flies like an arrow, but fruit flies like a banana. -------------------
4:36 p.m.
On Wed, 15 May 2002, Cameron Kaiser wrote:
That being said, since the 1541 is an intelligent
peripheral I suppose
you could reprogram it to read Apple floppies, but this would require a
lot of work and is certainly beyond my non-white-hat-consciousness.
I remember once sticking a Commodore 64 disk into an Apple drive and using
a low-level disk utility to read a track and the data did not seem to be
random, unintelligible data, but in fact seemed to have some order to it.
My recollection could be hazy and I could have just been seeing things way
back when.
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
* Old computing resources for business and academia at www.VintageTech.com *
16 May
16 May
1:21 p.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 497 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20020516/befc9f4d/at…
11:31 p.m.
That being
said, since the 1541 is an intelligent peripheral I suppose you
could reprogram it to read Apple floppies, but this would require a lot of
I'm not convinced you can. The lowest levels of the GCR encoding/decoding
are done in hardware both for the Apple Disk II and the 1541, and I don't
think they're compatible. And on most 1541s the logic is inside a
Commodore gate array chip (There is a version which uses TTL + ROM,
though), so it would be non-trivial to modify.
17 May
17 May
5:19 a.m.
On Fri, 17 May 2002, Cameron Kaiser wrote:
That being said, you'd have to resort to driving
the 6522s yourself to
manipulate the bitstream directly -- very low-level, and of course with the
small amount of RAM in the 1541 this would require impressively tight code.
But it is, theoretically, possible at least on some level, even if it's
merely decoding the bytes and handing them off to the C64 for processing
(putting the "DOS" in the 64).
Programming 6522's is not that difficult (I've done it before and I'm
working on a project right now that uses one). Isn't there 4K of RAM
inside each 1541? That's a goodly amount of RAM for disk drivers.
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
* Old computing resources for business and academia at www.VintageTech.com *
7:16 a.m.
That being
said, you'd have to resort to driving the 6522s yourself to
manipulate the bitstream directly -- very low-level, and of course with the
small amount of RAM in the 1541 this would require impressively tight code.
But it is, theoretically, possible at least on some level, even if it's
merely decoding the bytes and handing them off to the C64 for processing
(putting the "DOS" in the 64).
Programming 6522's is not that difficult (I've done it before and I'm
working on a project right now that uses one). Isn't there 4K of RAM
inside each 1541? That's a goodly amount of RAM for disk drivers.
7:47 a.m.
On Fri, 17 May 2002, Cameron Kaiser wrote:
2K, actually, and some of that space is microprocessor
stack and various
work areas for the ROM routines for the FDC's tasks, some of which you
would probably want to use for space reasons. The safest place is in the
buffers from $0300-$07ff, which is only 1.25K.
Ok, but to me, that's still a decent amount of memory ;)
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
* Old computing resources for business and academia at www.VintageTech.com *
2:02 p.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 1066 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20020518/816b6f68/at…
8103
days inactive
8105
days old
19 comments
11 participants
participants (11)
-
ard＠p850ug1.demon.co.uk -
bpope＠wordstock.com -
cisin＠xenosoft.com -
edick＠idcomm.com -
erd_6502＠yahoo.com -
foo＠siconic.com -
ghldbrd＠ccp.com -
jhellige＠earthlink.net -
jplist＠globe.net.nz -
pat＠purdueriots.com -
spectre＠stockholm.ptloma.edu