5 Jul
2000
5 Jul
'00
4:15 p.m.
From: Richard Erlacher <richard(a)idcomm.com>
To: classiccmp(a)classiccmp.org <classiccmp(a)classiccmp.org>
Date: Wednesday, July 05, 2000 7:30 PM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
You may be onto something, Tim, but I'd make one
observation here. The
signal on pin2 of the 8" drive cable, though often driven with the
1793's TG43 signal, does not turn write precomp on and off, but, rather,
reduces the write current to the heads. This reduces the amplitude of
the
signal
In many cases it's also used to alter write precomp. Most all have some
precomp (Esp DD controllers) and for the TG43 case they alter the precomp
to further compensate for bit shift due to the close magnetic domains.
driving the heads, hence reduces the overall amplitude
of the recovered
signal as well. That same signal is used to enable write
precompensation on
Bogus. the levels are dealt with in the read amps with margin as well.
What's changing of the write current really impacts is the read bit shift
(aka peak shift) as the bit density goes up (inner tracks are shorter
than
outer).
some controllers, many of which use a less-than-ideal
timebase to define
the precompensation offsets imposed on the data stream.
This is true, or worse used oneshots. generally the time base for the
bit encoding was always a crystal with not worse than 200ppm error
and less than 50ppm drift. The typical system was usually within
50ppm of exact and drifted less than 25ppm over temperature extremes.
Often the actual data rate was far lower than that reference(usually 1/4
or 1/8th).
Do you think you could take a stab at swapping the
timebase on your
Catweasel board with a 32 MHz crystal? I think that would be VERY
illuminating, particularly where these precomp/write-current-related
effects
are concerned, because phase noise introduced by the deviation of the
Catweasel timebase from a harmonic of the data rate adds confusion.
There lies a connundrum, study the media and the magnetic domains therein
or get the data? A lower clock would be adaquate for getting the data.
Further, while I was studying digital PLL state machines I found a point
where increasing the clock (greater resolution) produced sharply reduced
improvement. Signal processing theory (analog) suggests the same.
From: Tim Mann <mann(a)pa.dec.com>om>:
> So, what's the heuristic? It's quite
crude and oversimplified too,
> seems to work pretty well. The general idea is that if an interval is
> a bit off from what you were expecting it to be, multiply the error by
> some factor around 0.5 to 0.8 (you sometimes have to tune it for each
> disk if they are particularly bad), and add that to the next interval
I'd suggest some factor less than .5, flux shift errors on floppies
rarely move a great amount unless the spindle bearings are rattling
loose. Actually based on media and expected recording rate it's
possible to plug in a set of expected timing windows and add/subtract
a "precompenstation" window amount based on adjacent bits. For
example adjacent ones or zeros (especially more than two bits)
tend to spread or compress over patterns like alternating ones
and zeros.
Further with all the "timing image" in a memory it should be possible
to look at longer strings of transistions and do simple predictive
forcasting (software PLL). Add to that the encoding form (FM,
MFM, M2FM, RLL or GCR), and previous bits history it should be
straightforward enough to predict the likely next transistion(s)
be they one or zero.
It is serediptious that the code you have effectively accomplishes
a tracking filter (type of PLL). Why, many of the parameters on
the media like peakshift and other behavours tend to average
themselves and cancle. Most of this stuff is not rocket science,
it does however require seeing into the set of abstractions to
make them obvious.
Allison
5 Jul
5 Jul
8:02 p.m.
This is great, I was hoping for comments like this.
I'd suggest some factor less than .5, flux shift
errors on floppies
rarely move a great amount unless the spindle bearings are rattling
loose.
For the particular 8" floppies I was trying to read, a few seemed to need
a factor of 0.6 or even 0.75 to be read. Many worked fine with 0.0.
Actually based on media and expected recording rate
it's
possible to plug in a set of expected timing windows and add/subtract
a "precompenstation" window amount based on adjacent bits. For
example adjacent ones or zeros (especially more than two bits)
tend to spread or compress over patterns like alternating ones
and zeros.
Further with all the "timing image" in a memory it should be possible
to look at longer strings of transistions and do simple predictive
forcasting (software PLL). Add to that the encoding form (FM,
MFM, M2FM, RLL or GCR), and previous bits history it should be
straightforward enough to predict the likely next transistion(s)
be they one or zero.
This sounds like just the thing to do. Do you have any references where
I could read up on this kind of algorithm? I've never studied signal
processing -- I have a mathematics and computer science background, not
engineering -- so I've been working by intuition up to this point.
(Hmm, looking at Tim Shoppa's later response gives me the keywords "partial
response maximum likelihood" to look for. That should help.)
Another neat trick might be to notice when there is a CRC error and/or
a clock violation, and in that case backtrack to a recent past decision
where the second most likely alternative was close to the most likely,
try it the other way, and see if the result looks better. Obviously one
can't overdo that or you'll just generate random data with a CRC that
matches by chance, but since the CRC is 16 bits, I'd think it should be
OK to try a few different likely guesses to get it to match.
Tim Mann tim.mann(a)compaq.com http://www.tim-mann.org
Compaq Computer Corporation, Systems Research Center, Palo Alto, CA
8:31 p.m.
Please see my embedded remarks below.
Dick
----- Original Message -----
From: Tim Mann <mann(a)pa.dec.com>
To: <classiccmp(a)classiccmp.org>
Cc: allisonp <allisonp(a)world.std.com>
Sent: Wednesday, July 05, 2000 11:02 PM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
If you sample the data at a harmonic of the rate at
which its transitions
were written, ever mindful of the way in which FDC's work, you should be
able to do accurate prediction/correction of the sampled data in accordance
with the model. It's more difficult if you write the data at 500 KHz,
precomp it at 6 MHz and then recover it at 7 MHz. It just makes sense to
use a harmonic of the frequencies involved. It makes the data stream
larger, perhaps, but the patterns, such as they are, with their random
errors due to noise, and systematic error due to mechanical components'
influence, should be much more easily detectable. What's more, if you
really want to eliminate unwanted signal components, you could carefully
make four readings, having rotated the spindle 90 degrees in the same
direction between insertions of the diskette, and then sum the data samples,
aligning to index each time for rough alignment and then to the first ID
address mark once it's found. That may help correllate out the random
error. It should also make the mechanically generated error easily
detectable.
This is great, I was hoping for comments like this.
In reality, you should not be able to detect the precompensation
windows at
all, if they'r properly applied. The purpose of the precomp is to
anticipate and pre-correct for peak shift due to crowding of the bits. As I
wrote before, since the peaks are of opposite sign, in cases where they are
"too" close together, meaning that one pulse is still decaying while the
other begins to present itself, (detectable by examining the slope of the
signal) the addition of the two values subtacts from the two somewhat
linearly from the theoretical peaks, forcing the peaks themselves to occur
farther apart than they were written. This is helped by the lower
write-current, resulting in detection of the inreasing current in the head
somewhat later than if it had been written at full current, and secondly by
the fact that it is written earlier at the leading end of a pulse train, and
later at the trailing end. The upshot of all this is that the peak detector
senses these peaks at their nominal location even though they were not
written that way. Though it may appear that way, I doubt that consistently
readable diskettes have a great deal of error in their position in the pulse
train. It's important to keep in mind, however, that it's the level and not
the edges that contain the information. But for that, the FM data/clock
separators using one-shots would never have worked at all, with their wide
error margin.
I'd suggest some factor less than .5, flux
shift errors on floppies
rarely move a great amount unless the spindle bearings are rattling
loose.
For the particular 8" floppies I was trying to read, a few seemed to need
a factor of 0.6 or even 0.75 to be read. Many worked fine with 0.0.
Actually based on media and expected recording
rate it's
possible to plug in a set of expected timing windows and add/subtract
a "precompenstation" window amount based on adjacent bits. For
example adjacent ones or zeros (especially more than two bits)
tend to spread or compress over patterns like alternating ones
and zeros.
Further with all the "timing image" in
a memory it should be possible
to look at longer strings of transistions and do simple predictive
forecasting (software PLL). Add to that the encoding form (FM,
MFM, M2FM, RLL or GCR), and previous bits history it should be
straightforward enough to predict the likely next transistion(s)
be they one or zero.
This sounds like just the thing to do. Do you have any references where
I could read up on this kind of algorithm? I've never studied signal
processing -- I have a mathematics and computer science background, not
engineering -- so I've been working by intuition up to this point.
(Hmm, looking at Tim Shoppa's later response gives me the keywords
"partial
response maximum likelihood" to look for. That
should help.)
Another neat trick might be to notice when there is a CRC error and/or
a clock violation, and in that case backtrack to a recent past decision
where the second most likely alternative was close to the most likely,
try it the other way, and see if the result looks better. Obviously one
can't overdo that or you'll just generate random data with a CRC that
matches by chance, but since the CRC is 16 bits, I'd think it should be
OK to try a few different likely guesses to get it to match.
Tim Mann tim.mann(a)compaq.com http://www.tim-mann.org
Compaq Computer Corporation, Systems Research Center, Palo Alto, CA
6 Jul
6 Jul
3:22 a.m.
This sounds like just the thing to do. Do you have
any references where
I could read up on this kind of algorithm? I've never studied signal
processing -- I have a mathematics and computer science background, not
engineering -- so I've been working by intuition up to this point.
(Hmm, looking at Tim Shoppa's later response gives me the keywords "partial
response maximum likelihood" to look for. That should help.)
Tim's reference is a very good one for this. It should also lead to a few
others that will help directly. He's certainly knowledgable on this.
a clock violation, and in that case backtrack to a
recent past decision
where the second most likely alternative was close to the most likely,
try it the other way, and see if the result looks better. Obviously one
can't overdo that or you'll just generate random data with a CRC that
matches by chance, but since the CRC is 16 bits, I'd think it should be
OK to try a few different likely guesses to get it to match.
This is a possible way to approach it. Also it would allow extracting
data from a floppy that was stapled to the wall!
Allison
1:54 p.m.
mann(a)pa.dec.com (Tim Mann) wrote:
Another neat trick might be to notice when there is a CRC error and/or
a clock violation, and in that case backtrack to a recent past decision
where the second most likely alternative was close to the most likely,
try it the other way, and see if the result looks better. Obviously one
can't overdo that or you'll just generate random data with a CRC that
matches by chance, but since the CRC is 16 bits, I'd think it should be
OK to try a few different likely guesses to get it to match.
Hi
CRC's are quite good at fixing a single small burst. As I recall,
CRC32 can fix a single error burst up to 12 bits long. The
error correcting method is based on the cycle length of the original
polynomial relative to the length of the data block. What this
means is that if you have a burst longer than 12 bits, it is
more likely that the errors will appear to be outside the data
block than within the data block. In this case, you would have
what is called an uncorrectable error. No amount of fiddling
will give you a correction. If there is an error in the CRC
data, you have the same ratio. As an example, using CRC32 and
a data block of 512, the probability of an error looking correctable
that was not is 512/(2^32 -1) or 1.2X10^-7 of errors greater
than 12 bits will seem correctable. All errors that happen
within a 12 bit window are 100% correctable.
Does this make any sense?
Dwight
2:25 p.m.
New subject: CRC errors (was:Tim's own version of the Catweasel/Compaticard/whatever)
No, Dwight, there is a difference between CRC and ECC. CRC will detect
errors, but ECC can correct errors, too.
For single bit correction, the number of extra bits required is M+1 (M is
the log2(# of bits)); so if you have a 16-bit memory, 21 bits will correct
single-bit errors (and will detect most multi-bit errors).
There are also games that you can do to interleave your bits, so that a
burst error (that you describe, 12 bits in a row) can in fact be corrected.
Coding Theory is a deep subject with many advanced types of codes possible
for particular error probability density functions. And I'm certainly no
expert at it!.
-Mike Cheponis
On Thu, 6 Jul 2000, Dwight Elvey wrote:
mann(a)pa.dec.com (Tim Mann) wrote:
Another neat trick might be to notice when there is a CRC error and/or
a clock violation, and in that case backtrack to a recent past decision
where the second most likely alternative was close to the most likely,
try it the other way, and see if the result looks better. Obviously one
can't overdo that or you'll just generate random data with a CRC that
matches by chance, but since the CRC is 16 bits, I'd think it should be
OK to try a few different likely guesses to get it to match.
Hi
CRC's are quite good at fixing a single small burst. As I recall,
CRC32 can fix a single error burst up to 12 bits long. The
error correcting method is based on the cycle length of the original
polynomial relative to the length of the data block. What this
means is that if you have a burst longer than 12 bits, it is
more likely that the errors will appear to be outside the data
block than within the data block. In this case, you would have
what is called an uncorrectable error. No amount of fiddling
will give you a correction. If there is an error in the CRC
data, you have the same ratio. As an example, using CRC32 and
a data block of 512, the probability of an error looking correctable
that was not is 512/(2^32 -1) or 1.2X10^-7 of errors greater
than 12 bits will seem correctable. All errors that happen
within a 12 bit window are 100% correctable.
Does this make any sense?
Dwight
3:05 p.m.
New subject: CRC errors
The general idea makes sense, but the details don't sound quite right.
Here's an oversimplified back-of-the-envelope calculation:
If you allow for 12-bit burst errors in a 512-bit block (you did mean
bits, not bytes, right?), it takes 9 bits of information (512 = 2**9)
to say where the error is, and 12 bits of information to say what the
data in the burst should have been. This uses 21 of our 32 bits of CRC
information, leaving 11 bits to help us be sure this isn't a spurious
correction. That is, if we do have an error that's something other than
a 12-bit burst, the probability should be about 2**(-11) = 1/2048 that
the CRC will be one of the 2**21 values that says the block has only a
12-bit burst error. You said 512/(2**32 - 1), which is 2**(-23).
One oversimplified part of this is that someone has to show that the CRCs
that indicate two different 12-bit burst errors in the same data never
collide. I presume that's been done, and that's where the magic number
12 comes from. Otherwise you could safely correct errors of 13 or more
bits, just with a somewhat higher probability of spurious correction when
you really got some other error.
Of course, with floppy disks we have sectors of 128 to 1024 *bytes*, not
bits, and the CRC is only 16 bits, not 32, so I don't think we can do
much correction. With a 1024 byte sector, it already takes 13 bits of
information to say where a 1-bit error is. So if we use a CRC16 to correct
it, we have about a 2^(-3) = 1/8 probability that if more than one bit
is in error, we'll make a spurious correction.
Tim Mann tim.mann(a)compaq.com http://www.tim-mann.org
Compaq Computer Corporation, Systems Research Center, Palo Alto, CA
5:56 p.m.
New subject: Question for NW Apple II users.
I was just sorting through, and attempting to organize my Apple II
collection of systems, parts, manuals, and software, and I realized how much
of this stuff I don't use, or really need. I like ebay but I don't have a
lot of extra time to deal with cleaning, sorting, packaging, and shipping
items -in fact, I'm behind on this as it is, to people that I've promised
items. Still, I have these A2 items, that I would rather trade for other A2
items than sell on ebay but I don't want to deal with shipping either way.
So I have a question. Are there any other Apple II users out there, who live
in the Pacific NW, that might be interested in getting together some weekend
(this summer) to have an informal swap meet? I'm open to it, and the way
that I see it, even if there were only a few of us but we each got one
really cool item, then it would be worth it to me. "Cool" is in the eye of
the beholder of course, and it wouldn't have to be limited to A2 items.
That's just what I'm most interested in. We could meet at some park around
here, have a barbecue, hang out, and just have our swap stuff in our cars.
Nothing big but still fun.
Is anyone else interested in doing this?
Ernest
Seattle, WA
8:31 p.m.
New subject: Question for NW Apple II users.
I was just sorting through, and attempting to organize
my Apple II
collection of systems, parts, manuals, and software, and I realized how much
of this stuff I don't use, or really need. I like ebay but I don't have a
lot of extra time to deal with cleaning, sorting, packaging, and shipping
items -in fact, I'm behind on this as it is, to people that I've promised
items. Still, I have these A2 items, that I would rather trade for other A2
items than sell on ebay but I don't want to deal with shipping either way.
The only catch I really see with this is that there are only a handfull of
"really" cool Apple items, with a very sharp knee in the price curve
between them and everything else.
Cool stuff that everybody wants:
Transwarp accelerator
Vulcan hard drive
Focus hard drive
Fast SCSI card
SCSI card
Workstation localtalk card for IIe
Cool stuff that I want;
Transwarp accelerator
Vulcan hard drive
Focus hard drive
Eventide spectrum analyzer board
McMill or any 68000 boards, maybe even a 6809, ok anything weird. ;)
All the cheap stuff that most everybody has:
Whole A2 units
Woz IIgs
floppy drives and controllers
etc. etc.
Makes trading very difficult with maybe half a dozen items worth more than
$20, and handfull of rare items difficult to put any price on, and the rest
generally $5 or so depending on the marketplace. Add to that in finding any
of the "good" items, most people end up with boxes of the other stuff. How
and what do you end up trading? The only reason I cut loose of a couple of
my SCSI cards is that they sell for $100 and I clearly had more than I
needed.
8:41 p.m.
New subject: Question for NW Apple II users.
On Thu, 6 Jul 2000, Mike Ford wrote:
Cool stuff that everybody wants:
Transwarp accelerator
Vulcan hard drive
Focus hard drive
Fast SCSI card
SCSI card
Workstation localtalk card for IIe
Add to that:
Apple //c LCD portable display
Makes trading very difficult with maybe half a dozen
items worth more than
$20, and handfull of rare items difficult to put any price on, and the rest
generally $5 or so depending on the marketplace. Add to that in finding any
of the "good" items, most people end up with boxes of the other stuff. How
and what do you end up trading? The only reason I cut loose of a couple of
my SCSI cards is that they sell for $100 and I clearly had more than I
needed.
I collect whatever //c's I can find for cheap because I'm standardizing on
them as my VCF utility terminal of choice (for taking attendee
registration information, keeping books at the consignment table, etc).
They're nice and self-contained, only needing a display (//c+'s would be
much nicer but they're harder to come across). I have around 10 //c's and
2 //c+'s.
I also take whatever free //e's I get my hands on. They'll come in handy
for something someday (maybe when Hans finishes the C64 super-computer
project we can do one with Apples :)
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
VCF 4.0 is September 30-October 1
San Jose Convention Center, San Jose, California
See http://www.vintage.org for details!
10:26 p.m.
New subject: Question for NW Apple II users.
Sellam Ismail wrote:
I also take whatever free //e's I get my hands on. They'll come in handy
for something someday (maybe when Hans finishes the C64 super-computer
project we can do one with Apples :)
I had a call a day or so about someone with about 100 //e's to get rid of.
They are looking for some money, but not much (at least that is my
understanding.) If you are interested, let me know and I'll pursue it a bit
harder.
9:52 p.m.
New subject: Question for NW Apple II users.
On Fri, 7 Jul 2000, Marvin wrote:
I had a call a day or so about someone with about 100
//e's to get rid of.
They are looking for some money, but not much (at least that is my
understanding.) If you are interested, let me know and I'll pursue it a bit
harder.
If I had someplace to stick them I would maybe take them for $1 a unit.
Even then I don't know if I'd want them all. Right now is not the right
time for me though...I have enough crap I have to move in the next 10 days
as it is. 100 more Apple //e's is the last thing I want at this point :)
Still, it'd be interesting to get details. Namely, where the hell did
they get 100 //e's from?
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
VCF 4.0 is September 30-October 1
San Jose Convention Center, San Jose, California
See http://www.vintage.org for details!
7 Jul
7 Jul
5:57 a.m.
New subject: Question for NW Apple II users.
Sellam Ismail wrote:
On Fri, 7 Jul 2000, Marvin wrote:
> I had a call a day or so about someone with about 100 //e's to get rid of.
Still, it'd be interesting to get details.
Namely, where the hell did
they get 100 //e's from?
I am not sure, but I think these came or are coming from the school system.
The stuff that schools/universities have in storage can be fascinating!
12:01 a.m.
New subject: Question for NW Apple II users.
Sellam Ismail wrote:
Where are they?
What are they, ie a pallet of smashed from stacking too high bare bones ex
school district Apple IIe's does not have a lot of value. OTOH I would be
fairly interested in going through a bunch of perhaps interestingly
configured ex industrial Apple II's. A quick look at the back of a few
tells most of the story, If you see a;
Weird little box with a couple serial ports, thats a workstation card.
DB25 on a mounting plate (not end of ribbon cable) and maybe its a SCSI card.
When I can I still open each one and fully strip it, but the list of what I
keep is getting smaller and smaller. Last batch I paid $25 to take all I
wanted from two pallets, which was a grocery sack sized box of cards and a
dozen or so floppy drives. Of course add to that the 4 hours and numerous
punctures getting the cards out etc.
Perhaps the unfortunate thing is that I can think of nothing to do with a
100 old Apple II computers other than pull interesting cards and look for
hard drives (the Vulcan is inside the powersupply). There are a couple
models I would like to have in my personal collection, a plain II and a
platinum II whatever it is, but thats about it. Otherwise they are just too
common and too indestructible (what else could you call machines that
routinely still work just fine after 20 years of elementary school use?)
I also take whatever free //e's I get my hands on. They'll come in handy
for something someday (maybe when Hans finishes the C64 super-computer
project we can do one with Apples :)
I had a call a day or so about someone with about 100 //e's to get rid of.
They are looking for some money, but not much (at least that is my
understanding.) If you are interested, let me know and I'll pursue it a bit
harder.
6:06 a.m.
New subject: Question for NW Apple II users.
Mike Ford wrote:
> >I had a call a day or so about someone with about 100 //e's to get rid of.
> What are they, ie a pallet of smashed from
stacking too high bare bones ex
> school district Apple IIe's does not have a lot of value. OTOH I would be
hard drives (the Vulcan is inside the powersupply).
There are a couple
models I would like to have in my personal collection, a plain II and a
platinum II whatever it is, but thats about it. Otherwise they are just too
These came from a school district (I think), and I told them they were
probably worth more as parts than as a complete machine. I asked for more
info about a week ago, and if it goes through, will most likely strip out
down the machines for parts ... and interesting cards :). There is some
possibility that a computer class at one of the local schools will strip
them, but I don't know at this point.
I also am looking for a plain // since I *think* that is the only one
(except for the Apple I) that I am missing from that line. The Platinum //e
is an enhanced machine with a numeric keyboard built into the machine
instead of being an add-on.
7:42 a.m.
New subject: Question for NW Apple II users.
On Fri, 7 Jul 2000, Mike Ford wrote:
Perhaps the unfortunate thing is that I can think of
nothing to do with a
100 old Apple II computers other than pull interesting cards and look for
hard drives (the Vulcan is inside the powersupply). There are a couple
models I would like to have in my personal collection, a plain II and a
platinum II whatever it is, but thats about it. Otherwise they are just too
A Platinum //e is an enhanced Apple //e with a built-in numeric keypad on
the right hand side. It's also got the "platinum" covering. Nothing
special.
There was also a Platinum //c. It had an extremely nice keyboard (a major
improvement over the //c's crap keyboard).
common and too indestructible (what else could you
call machines that
routinely still work just fine after 20 years of elementary school use?)
They are definitely work horses. I've never met an Apple //e that was so
fargone it wouldn't work anymore. I even have Apple ][+'s that have sat
in horrible conditions still work 20 years later, with just a few faulty
keys on the keyboard.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
VCF 4.0 is September 30-October 1
San Jose Convention Center, San Jose, California
See http://www.vintage.org for details!
6 Jul
6 Jul
11:24 p.m.
New subject: Question for NW Apple II users.
Add to that:
Apple //c LCD portable display
I have only seen ONE, still kicking myself for not buying it immediately,
but also wondering why I would really want it (quality not good I hear).
I collect whatever //c's I can find for cheap
because I'm standardizing on
I agree, I have about half a dozen of each, IIc and IIc+, and they have a
LOT of appeal. Looking at one for just a few minutes makes you think wow,
Apple really did this one right. The form factor is perfect for kids in a
way that is hard to explain, its much more appealing to me at least than
something like a C64 or the later "large" keyboard designs. Its a cute
little briefcase kind of looking thing.
See related post for idea that just rattled out of my head.
11:34 p.m.
New subject: Networking Apple IIc or IIc+
Many people have told me you can't network the IIc or IIc+, but I am sure I
remember somebody telling me the IIc+ could be kludged to sort of work.
Skipping that issue (unless somebody knows more), I wonder if a
slower/dumber protocol than LocalTalk/AppleTalk might work?
The idea would be to plug a PhoneNet adapter into a IIc/IIc+ serial port,
and write a simple data transfer program of some sort regardless of how
slow it might be. For example what would happen if you plug in the
PhoneNets and just ran a normal terminal program of some sort to a host
computer (mac etc.)?
Now add a second IIc/IIc+ to the "network" and run a normal terminal
program on it. Seems to me all you need to add is some kind of protocol for
a packet with an address field and it should work. Ideas, opinions?
7 Jul
7 Jul
7:47 a.m.
New subject: Networking Apple IIc or IIc+
On Fri, 7 Jul 2000, Mike Ford wrote:
Now add a second IIc/IIc+ to the "network"
and run a normal terminal
program on it. Seems to me all you need to add is some kind of protocol for
a packet with an address field and it should work. Ideas, opinions?
I was working on a loose internet-based "team", started by a K-12 teacher
in Michigan (I think), a couple years back on developing a lightweight
network protocol for the Apple to connect it to a Linux server to give it
internet access. The teacher wanted to make the Apple //e's in his
computer lab accessible to the internet.
One idea was just to create a simple dumb terminal program that allowed
e-mail access (no-brainer). But I went about designing a protocol that
would install under ProDOS and make a virtual ProDOS volume on the Apple
that actually sat on the Linux server. It was going to be serial-based
(we determined the workstation cards were too hard to come across but
super serial cards are plentiful) and there would be a server application
sitting on the Linux side handling the Apple's over a multi-port serial
card.
Anyway, simplicity (and lack of time) won out over my complex scheming. I
dropped out and eventually some 18 year old kid came up with a pretty nice
system that worked for them.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
VCF 4.0 is September 30-October 1
San Jose Convention Center, San Jose, California
See http://www.vintage.org for details!
5:33 p.m.
New subject: Question for NW Apple II users.
I wish you guys would list want you are looking for more often as I had
to just trash over 50 Apple II, IIe, and related items like ext. floppy
drive, printers, and monitors. Some times I come across a shit load of
stuff that I can not use or save for the trash. If I see your want/wish
list I can email you when something comes up. I see the IIc+ around
here and in St. Louis, MO all the time but I already have three working
units. They sell for around $2 to $10 without a monitor.
John Keys
----- Original Message -----
From: Sellam Ismail <foo(a)siconic.com>
To: <classiccmp(a)classiccmp.org>
Sent: Friday, July 07, 2000 12:41 AM
Subject: Re: Question for NW Apple II users.
standardizing on
On Thu, 6 Jul 2000, Mike Ford wrote:
more than
Cool stuff that everybody wants:
Transwarp accelerator
Vulcan hard drive
Focus hard drive
Fast SCSI card
SCSI card
Workstation localtalk card for IIe
Add to that:
Apple file://c LCD portable display
> Makes trading very difficult with maybe half a dozen items worth > $20, and handfull of rare items difficult to put
any price on, and
the rest
> generally $5 or so depending on the marketplace.
Add to that in
finding any
> of the "good" items, most people end up
with boxes of the other
stuff. How
> and what do you end up trading? The only reason I
cut loose of a
couple of
> my SCSI cards is that they sell for $100 and I
clearly had more than
I
needed.
I collect whatever file://c's I can find for cheap because I'm
them as my VCF utility terminal of choice (for taking
attendee
registration information, keeping books at the consignment table,
etc).
They're nice and self-contained, only needing a
display (//c+'s would
be
much nicer but they're harder to come across). I
have around 10
file://c's and
2 file://c+'s.
I also take whatever free file://e's I get my hands on. They'll come
in
handy
for something someday (maybe when Hans finishes the
C64 super-computer
project we can do one with Apples :)
Sellam International Man of Intrigue
and Danger
----------------------------------------------------------------------
---------
Looking for a six in a pile of nines...
VCF 4.0 is September 30-October 1
San Jose Convention Center, San Jose, California
See http://www.vintage.org for details!
5:34 p.m.
New subject: Question for NW Apple II users.
On Fri, 7 Jul 2000, John R. Keys Jr. wrote:
I wish you guys would list want you are looking for
more often as I had
to just trash over 50 Apple II, IIe, and related items like ext. floppy
drive, printers, and monitors. Some times I come across a shit load of
Why did you trash them before posting to the list? It would be inconvient
for everyone to post their wants to the list (who would remember it all?
who would keep track of this? certainly not I...) so posting what you are
about to trash to the list is basic classic computer etiquette :)
stuff that I can not use or save for the trash. If I
see your want/wish
list I can email you when something comes up. I see the IIc+ around
here and in St. Louis, MO all the time but I already have three working
units. They sell for around $2 to $10 without a monitor.
Cool. The next time one comes up at that price buy it for me. I'll be
happy to pay that amount.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
VCF 4.0 is September 30-October 1
San Jose Convention Center, San Jose, California
See http://www.vintage.org for details!
8 Jul
8 Jul
12:53 p.m.
New subject: Question for NW Apple II users.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 837 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000708/0f922efc/at…
7 Jul
7 Jul
9 p.m.
New subject: Question for NW Apple II users.
I wish you guys would list want you are looking for
more often as I had
to just trash over 50 Apple II, IIe, and related items like ext. floppy
Take some heart in that in a random lot of 50 machines, there may not have
been ANY of the good cards. But now you have at least a short list of the
"good" stuff. ;)
8 Jul
8 Jul
12:26 a.m.
New subject: Apple II keep list
Mikes generalized Apple II keep list, kindly correct me for dumb stuff.
Systems
They have to be pretty nice looking, systems with school ID engraved an
inch high on the front are not desirable.
Apple II, the orginal machine
Apple II+, still not too common
Not the IIe, sorry parts only, too many of them.
IIgs, not rare, but people still actively use them more than any other II.
Look for Woz editions and rom 3.
IIc, cute and complete systems with monitor still sell for $35 or so.
IIc+, more powerfull than the IIc, but in some ways less collectible (no
idea why), still $45 for a complete system is fairly common.
Drives (mostly I mean external)
Any external hard drive, or even case.
DuoDisk floppy drives (two drives in a box) with cable.
Unidisk floppy drives
White IIc drives
400k floppy drives
1.44 MB floppy drives
Keyboards
A9M0330 is the IIgs original keyboard, and VERY popular because it is the
smallest mac keyboard (and its the original.
Any mac keyboard, I even pile broken ones in a box for parts. This comes
from actually paying $169 for one once.
Mice
Early DB9 mice, M0100 with the black ball retaining ring is the original.
All the mice too.
Misc
IIc LCD display
IIc 9" green monitor AND matching stand.
Kensington system saver fans.
Cards and other innerds
Accelerator boards, Applied Engineering Transwarp about the most desired.
Fast SCSI cards, much faster, only card that supports removable media.
Apple Rev C SCSI cards, but much less so than Fast SCSI.
Workstation cards
Vulcan hard drive inside power supply
Focus IDE drive on a card
Anything curious
I/O controller cards (for later floppy drives)
Mouse cards for IIe
1:59 a.m.
New subject: Apple II sprite boards
Around 1985 or so, a couple of manufacturers developed "sprite boards"
for the Apple II series (except the IIc, for obvious reasons)
These boards featured a video chip (probably a TMS 9918, same as used
in the TI home computer) that allowed for up to 32 sprites to be displayed
on the screen. One of these boards may have had a sound chip on it as
well. (A veritable TI 99/4 on an Apple card, almost!) Of course, the
sprites, and any other graphics from the 9918
could be superimposed over regular Apple graphics, due to the external
video input on the 9918.
Did anyone ever play with one of these? I recall them being rather
expensive, not well supported by third party software makers, and (of
course) different brands of sprite card were incompatible with each other.
12:59 p.m.
New subject: Apple II sprite boards
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 558 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000708/afbd86bc/at…
9:16 p.m.
New subject: Barcode readers: Cauzin Softstrip and Oscar Databar
These came out in the mid-80's to provide an alternative to
typing in program listings (say, from a magazine), As far
as I can tell, neither system really caught on...
10:57 p.m.
New subject: Barcode readers: Cauzin Softstrip and Oscar Databar
These came out in the mid-80's to provide an
alternative to
typing in program listings (say, from a magazine), As far
as I can tell, neither system really caught on...
Cauzin is still around and supplies systems used at many trade shows for
encoding and reading 2d data patches on badges.
I found a Cauzin reader for my Apple II, but haven't played with it. Years
ago I wrote a couple letters to Cauzin asking about using the technology
minus the reader, but they had no interest.
9 Jul
9 Jul
8:01 p.m.
New subject: Barcode readers: Cauzin Softstrip and Oscar Databar
At 01:16 AM 7/9/00 -0500, Charles P. Hobbs (SoCalTip) wrote:
These came out in the mid-80's to provide an
alternative to
typing in program listings (say, from a magazine), As far
as I can tell, neither system really caught on...
There's a really groovy new video-cam based system
for transmitting data via a printed page, at http://www.digimarc.com/ .
- John
8 Jul
8 Jul
3:34 a.m.
New subject: Apple II keep list
On Sat, 8 Jul 2000, Mike Ford wrote:
IIc+, more powerfull than the IIc, but in some ways
less collectible (no
idea why), still $45 for a complete system is fairly common.
I don't know where you get that impression from. How so?
They're just not as common as the //c, which makes them more scarce.
Non-Apple people might not know the difference between a //c and a //c+
and realize the //c+ is a way cool machine.
Fast SCSI cards, much faster, only card that supports
removable media.
Apple Rev C SCSI cards, but much less so than Fast SCSI.
Workstation cards
I'd like a SCSI and Workstation card too (make that two so I can at least
connect two machines together).
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
VCF 4.0 is September 30-October 1
San Jose Convention Center, San Jose, California
See http://www.vintage.org for details!
8:42 a.m.
New subject: Apple II keep list
On Sat, 8 Jul 2000, Mike Ford wrote:
The biggest collectors of the IIc are in Japan, and for reasons I don't
follow, the IIc seems prefered to the IIc+. US buyers prefer the IIc+, but
the number of buyers is a fraction of the machines being sold in Japan.
IIc+, more powerfull than the IIc, but in some
ways less collectible (no
idea why), still $45 for a complete system is fairly common.
I don't know where you get that impression from. How so?
They're just not as common as the //c, which makes them more scarce.
Non-Apple people might not know the difference between a //c and a //c+
and realize the //c+ is a way cool machine.
2:54 p.m.
New subject: Apple II keep list
On Sat, 8 Jul 2000, Mike Ford wrote:
The biggest collectors of the IIc are in Japan, and
for reasons I don't
follow, the IIc seems prefered to the IIc+. US buyers prefer the IIc+, but
the number of buyers is a fraction of the machines being sold in Japan.
I can't think of any logical reason why the //c ould be more popular than
the //c+ anywhere. The //c+ is so much better than the //c on so many
levels.
Any idea what the deal is?
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
VCF 4.0 is September 30-October 1
San Jose Convention Center, San Jose, California
See http://www.vintage.org for details!
10:41 p.m.
New subject: Apple II keep list
On Sat, 8 Jul 2000, Mike Ford wrote:
Well the hard core collectors seem to know "where" many Apple items were
manufactured, and those made in Japan are prized above some others. Not
saying this is the case with the IIc/IIc+. but its something I have had
buyers mention to me.
The biggest collectors of the IIc are in Japan,
and for reasons I don't
follow, the IIc seems prefered to the IIc+. US buyers prefer the IIc+, but
the number of buyers is a fraction of the machines being sold in Japan.
I can't think of any logical reason why the //c ould be more popular than
the //c+ anywhere. The //c+ is so much better than the //c on so many
levels.
Any idea what the deal is? 
9 Jul
9 Jul
1:03 p.m.
New subject: Apple II keep list
Sellam wrote:
I can't think of any logical reason why the //c
ould be more popular than
the //c+ anywhere. The //c+ is so much better than the //c on so many
levels.
Any idea what the deal is?
The //c+ would be less useful to someone that only wants to
use software on 5.25 inch diskettes.
8 Jul
8 Jul
6:13 p.m.
New subject: Apple II keep list
On Sat, 8 Jul 2000, Sellam Ismail wrote:
> IIc+, more powerfull than the IIc, but in some
ways less collectible (no
> idea why), still $45 for a complete system is fairly common.
For some odd reason, I saw a IIe system in a thrift shop that was
priced even higher: US$75 for a IIe with Apple composite monitor
(monochrome, I think) and three floppy drives. I thougt it seemed a
bit too high and didn't buy it, buying nearly 20 vinyl LPs at 75-cents
apiece instead.
There was also a beautiful 1950s (I think) GE console TV with a wooden
cabinet that was in excellent condition, like it just came from
someone's living roomq - beautiful! Alas, I have no space for it and
had to pass it up. :-(
--
R. D. Davis
rdd(a)perqlogic.com
http://www.perqlogic.com/rdd
410-744-4900
11:35 p.m.
New subject: Apple II keep list
-> On Sat, 8 Jul 2000, Sellam Ismail wrote:
-> > > IIc+, more powerfull than the IIc, but in some ways less
-> collectible (no
-> > > idea why), still $45 for a complete system is fairly common.
->
-> For some odd reason, I saw a IIe system in a thrift shop that was
-> priced even higher: US$75 for a IIe with Apple composite monitor
-> (monochrome, I think) and three floppy drives. I thougt it seemed a
-> bit too high and didn't buy it, buying nearly 20 vinyl LPs
-> at 75-cents
-> apiece instead.
Today in a local thrift shop I picked up a //e, 3 floppy drives, a IIe
color monitor and some Apple software for $8.00. Haven't gotten around
to checking it all out yet, though. Having too much fun playing with
the Amstrad PCW d8^)
Bill
whdawson(a)mlynk.com <mailto:whdawson@mlynk.com>
?
Be not the first by whom the new are tried,
Nor yet the last to lay the old aside.
Essay on Criticism, Alexander Pope
12:58 p.m.
New subject: Apple II keep list
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 833 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000708/6a10f372/at…
3:23 p.m.
New subject: Apple II keep list
I have printed off your list and will carry it with me in the van on my
hunting trips.
John Keys
----- Original Message -----
From: Mike Ford <mikeford(a)socal.rr.com>
To: <classiccmp(a)classiccmp.org>
Sent: Saturday, July 08, 2000 4:26 AM
Subject: Apple II keep list
Mikes generalized Apple II keep list, kindly correct
me for dumb
stuff.
Systems
They have to be pretty nice looking, systems with school ID engraved
an
inch high on the front are not desirable.
Apple II, the orginal machine
Apple II+, still not too common
Not the IIe, sorry parts only, too many of them.
IIgs, not rare, but people still actively use them more than any other
II.
Look for Woz editions and rom 3.
IIc, cute and complete systems with monitor still sell for $35 or so.
IIc+, more powerfull than the IIc, but in some ways less collectible
(no
idea why), still $45 for a complete system is fairly
common.
Drives (mostly I mean external)
Any external hard drive, or even case.
DuoDisk floppy drives (two drives in a box) with cable.
Unidisk floppy drives
White IIc drives
400k floppy drives
1.44 MB floppy drives
Keyboards
A9M0330 is the IIgs original keyboard, and VERY popular because it is
the
smallest mac keyboard (and its the original.
Any mac keyboard, I even pile broken ones in a box for parts. This
comes
from actually paying $169 for one once.
Mice
Early DB9 mice, M0100 with the black ball retaining ring is the
original.
All the mice too.
Misc
IIc LCD display
IIc 9" green monitor AND matching stand.
Kensington system saver fans.
Cards and other innerds
Accelerator boards, Applied Engineering Transwarp about the most
desired.
Fast SCSI cards, much faster, only card that supports
removable media.
Apple Rev C SCSI cards, but much less so than Fast SCSI.
Workstation cards
Vulcan hard drive inside power supply
Focus IDE drive on a card
Anything curious
I/O controller cards (for later floppy drives)
Mouse cards for IIe
14 Jul
14 Jul
7:24 a.m.
New subject: Question for NW Apple II users.
Sellam Ismail wrote:
On Thu, 6 Jul 2000, Mike Ford wrote:
Also add to that the ZipChip - similar to the Transwarp accelerator, but
(according to some), faster. Lately, they seem to harder to find, as
well.
Mike
Cool stuff that everybody wants:
Transwarp accelerator
Vulcan hard drive
Focus hard drive
Fast SCSI card
SCSI card
Workstation localtalk card for IIe
Add to that:
Apple //c LCD portable display
Makes trading very difficult with maybe half a
dozen items worth more than
$20, and handfull of rare items difficult to put any price on, and the rest
generally $5 or so depending on the marketplace. Add to that in finding any
of the "good" items, most people end up with boxes of the other stuff. How
and what do you end up trading? The only reason I cut loose of a couple of
my SCSI cards is that they sell for $100 and I clearly had more than I
needed.
I collect whatever //c's I can find for cheap because I'm standardizing on
them as my VCF utility terminal of choice (for taking attendee
registration information, keeping books at the consignment table, etc).
They're nice and self-contained, only needing a display (//c+'s would be
much nicer but they're harder to come across). I have around 10 //c's and
2 //c+'s.
I also take whatever free //e's I get my hands on. They'll come in handy
for something someday (maybe when Hans finishes the C64 super-computer
project we can do one with Apples :)
Sellam International Man of Intrigue and Danger 
7 Jul
7 Jul
6:10 a.m.
New subject: Question for NW Apple II users.
Having just moved and realizing how much A][ stuff I have that is
redundant I'd be interested in such a swap meet. My problem is that it
will take a while to unpack and sort things out so while I'm interested in
a swap meet it might be next spring before I am ready.
George
=========================================================
George L. Rachor Jr. george(a)racsys.rt.rain.com
Beaverton, Oregon http://racsys.rt.rain.com
United States of America Amateur Radio : KD7DCX
On Thu, 6 Jul 2000, Ernest wrote:
I was just sorting through, and attempting to organize
my Apple II
collection of systems, parts, manuals, and software, and I realized how much
of this stuff I don't use, or really need. I like ebay but I don't have a
lot of extra time to deal with cleaning, sorting, packaging, and shipping
items -in fact, I'm behind on this as it is, to people that I've promised
items. Still, I have these A2 items, that I would rather trade for other A2
items than sell on ebay but I don't want to deal with shipping either way.
So I have a question. Are there any other Apple II users out there, who live
in the Pacific NW, that might be interested in getting together some weekend
(this summer) to have an informal swap meet? I'm open to it, and the way
that I see it, even if there were only a few of us but we each got one
really cool item, then it would be worth it to me. "Cool" is in the eye of
the beholder of course, and it wouldn't have to be limited to A2 items.
That's just what I'm most interested in. We could meet at some park around
here, have a barbecue, hang out, and just have our swap stuff in our cars.
Nothing big but still fun.
Is anyone else interested in doing this?
Ernest
Seattle, WA
9 Aug
9 Aug
8:44 p.m.
New subject: Question for NW Apple II users.
Having just moved and realizing how much A][ stuff I have that is
redundant I'd be interested in such a swap meet. My problem is that it
will take a while to unpack and sort things out so while I'm interested in
a swap meet it might be next spring before I am ready.
George
Hello. Let me know when you feel like making some trades. I keep collecting
more and more A2 stuff -mostly cards, software, and manuals so I could bring
plenty of stuff.
Ernest
11 Aug
11 Aug
4:24 a.m.
New subject: 3b2\600 OS needed.
I'm looking for the setup\OS disks and tape for a 3b2\600. Will buy or trade
for it.
Ernest.
7:51 a.m.
New subject: 3b2\600 OS needed.
Ernest wrote:
I'm looking for the setup\OS disks and tape for a 3b2\600. Will buy or trade
for it.
Ernest.
You wouldn't happen to have a spare nic? I'll check around here I think
have to OS etal.
--
Linux Home Automation Neil Cherry ncherry(a)home.net
http://members.home.net/ncherry (Text only)
http://meltingpot.fortunecity.com/lightsey/52 (Graphics)
http://linuxha.sourceforge.net/ (SourceForge)
10 Aug
10 Aug
6:40 p.m.
New subject: Morrow MD2 FS at Seattle store
FYI
There's a very nice Morrow MD2 available at REPC in Seattle if anyone is
interested. It has a Qume terminal, full set of system disk masters, full
set of user manuals for each program, the "correct" printer and terminal
cables... I fired it up and it seems to work OK but some of the keys seem to
be a little sticky.
He didn't have price on it yet since they just got it. I guess that someone
just dropped it off for scrap.
If you're interested, go check it out and make them an offer.
Oh, it also has the cool Shugart floppy drives, instead of those crappy half
height types. It also doesn't have that ugly yellow color like my MD3. It's
still original creamy white.
Ernest
5 Jul
5 Jul
8:09 p.m.
Please see comments embedded below.
Dick
----- Original Message -----
From: allisonp <allisonp(a)world.std.com>
To: Classic Computers <classiccmp(a)classiccmp.org>
Sent: Wednesday, July 05, 2000 7:15 PM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
Gee, if reducing the write current is done to reduce the signal amplitude on
the heads, I wonder why they say that . . .
Commercial standard for crystal oscillators has been 100 ppm since back in
the mid '70's. There were cheap ones at 1000 ppm, though, but most floppy
drives didn't have need for oscillators. That's where the one-shots lived.
A clock as slow as 4 MHz would be quite adequate for reading, Allison, but
if you want the optimal relationship between write data and precomp,
ensuring best likelihood of recovering the data, you need to have 16x
resolution as a minimum, and somewhere on the order or 12x as the interval
by which you precompensate. This can vary considerably with the drive, but
it's a typical value for 1980-generation heads and media. SMC and Western
Digital both made parts, rather late in the game, that performed these
functions digitally but used a 32x clock.
From: Richard Erlacher <richard(a)idcomm.com>
To: classiccmp(a)classiccmp.org <classiccmp(a)classiccmp.org>
Date: Wednesday, July 05, 2000 7:30 PM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
That's precisely what I said, isn't it? The only thing is that driving
pin
2 (RWC) of the cable doesn't do anything on the controller unless you've
provided circuitry to do that. I did say the TG43 flag on the 179x is used
to enable precomp, right?
You may be onto something, Tim, but I'd make
one observation here. The
signal on pin2 of the 8" drive cable, though often driven with the
1793's TG43 signal, does not turn write precomp on and off, but, rather,
reduces the write current to the heads. This reduces the amplitude of
the
signal
In many cases it's also used to alter write precomp. Most all have some
precomp (Esp DD controllers) and for the TG43 case they alter the precomp
to further compensate for bit shift due to the close magnetic domains.
driving the heads, hence reduces the overall
amplitude of the recovered
signal as well. That same signal is used to enable write
precompensation on
Bogus. the levels are dealt with in the read amps with margin as well.
What's changing of the write current really impacts is the read bit shift
(aka peak shift) as the bit density goes up (inner tracks are shorter
than
outer).
some controllers, many of which use a
less-than-ideal timebase to define
the precompensation offsets imposed on the data stream.
This is true, or worse used oneshots. generally the time base for the
bit encoding was always a crystal with not worse than 200ppm error and less than 50ppm drift. The typical system was
usually within
50ppm of exact and drifted less than 25ppm over temperature extremes.
Often the actual data rate was far lower than that reference(usually 1/4
or 1/8th).
The one-shots were often timed with 5% resistors and 10% capacitors.
Do you think you could take a stab at swapping the
timebase on your
Catweasel board with a 32 MHz crystal? I think that would be VERY
illuminating, particularly where these precomp/write-current-related
effects
are concerned, because phase noise introduced by the deviation of the
Catweasel timebase from a harmonic of the data rate adds confusion.
There lies a connundrum, study the media and the magnetic domains therein
or get the data? A lower clock would be adaquate for getting the data.
Further, while I was studying digital PLL state machines I found a point
where increasing the clock (greater resolution) produced sharply reduced
improvement. Signal processing theory (analog) suggests the same.
That's true and the knee to which you refer lies around 6% jitter. That's
16x the data rate. The phase noise from a digital PLL is quite tolerable
and the tracking accurate and reasonably continuous at that level. Below
that you have capture and tracking error and above that you're squandering
resources if there's no more compelling reason to have the frequency
available.
From: Tim Mann <mann(a)pa.dec.com>om>:
> So, what's the heuristic? It's quite
crude and oversimplified too,
> seems to work pretty well. The general idea is that if an interval is
> a bit off from what you were expecting it to be, multiply the error by
> some factor around 0.5 to 0.8 (you sometimes have to tune it for each
> disk if they are particularly bad), and add that to the next interval
I'd suggest some factor less than .5, flux shift errors on floppies
rarely move a great amount unless the spindle bearings are rattling
loose. Actually based on media and expected recording rate it's
possible to plug in a set of expected timing windows and add/subtract
a "precompenstation" window amount based on adjacent bits. For
example adjacent ones or zeros (especially more than two bits)
tend to spread or compress over patterns like alternating ones
and zeros.
Further with all the "timing image" in a memory it should be possible
to look at longer strings of transistions and do simple predictive
forcasting (software PLL). Add to that the encoding form (FM,
MFM, M2FM, RLL or GCR), and previous bits history it should be
straightforward enough to predict the likely next transistion(s)
be they one or zero.
It is serediptious that the code you have effectively accomplishes
a tracking filter (type of PLL). Why, many of the parameters on
the media like peakshift and other behavours tend to average
themselves and cancle. Most of this stuff is not rocket science,
it does however require seeing into the set of abstractions to
make them obvious.
Allison
6 Jul
6 Jul
3:31 a.m.
here you wade through the comments...
On Wed, 5 Jul 2000, Richard Erlacher wrote:
Commercial standard for crystal oscillators has been 100 ppm since back in
the mid '70's. There were cheap ones at 1000 ppm, though, but most floppy
drives didn't have need for oscillators. That's where the one-shots lived.
I said crystals not complete oscilators. Many of the cheap cpu clock
rocks were really low accuracy parts. Like Tim said, in the world of
mechanical slop 200ppm is nothing!
They were temperature and voltage sensitive as all hell. Most of the caps
were not good quality and the resistors while within 5% of stated value
said little about their thermal characteristics.
A clock as slow as 4 MHz would be quite adequate for reading, Allison, but
if you want the optimal relationship between write data and precomp,
ensuring best likelihood of recovering the data, you need to have 16x
resolution as a minimum, and somewhere on the order or 12x as the interval
by which you precompensate. This can vary considerably with the drive, but
it's a typical value for 1980-generation heads and media. SMC and Western
Digital both made parts, rather late in the game, that performed these
functions digitally but used a 32x clock.
I'm quite aware of them, since the early 80s.
Yep.
Please see comments embedded below.
Dick
----- Original Message -----
From: allisonp <allisonp(a)world.std.com>
To: Classic Computers <classiccmp(a)classiccmp.org>
Sent: Wednesday, July 05, 2000 7:15 PM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
Gee, if reducing the write current is done to reduce the signal amplitude on
the heads, I wonder why they say that . . .
It does but the peak shift is what is of more interest and the lower read
signal is less of a concern than mashed flux trasistions.
From: Richard Erlacher
<richard(a)idcomm.com>
To: classiccmp(a)classiccmp.org <classiccmp(a)classiccmp.org>
Date: Wednesday, July 05, 2000 7:30 PM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
That's precisely what I said, isn't it? The only thing is that driving
pin
2 (RWC) of the cable doesn't do anything on the controller unless you've
provided circuitry to do that. I did say the TG43 flag on the 179x is used
to enable precomp, right?
You may be onto something, Tim, but I'd make
one observation here. The
signal on pin2 of the 8" drive cable, though often driven with the
1793's TG43 signal, does not turn write precomp on and off, but, rather,
reduces the write current to the heads. This reduces the amplitude of
the
signal
In many cases it's also used to alter write precomp. Most all have some
precomp (Esp DD controllers) and for the TG43 case they alter the precomp
to further compensate for bit shift due to the close magnetic domains.
driving the heads, hence reduces the overall
amplitude of the recovered
signal as well. That same signal is used to enable write
precompensation on
Bogus. the levels are dealt with in the read amps with margin as well.
What's changing of the write current really impacts is the read bit shift
(aka peak shift) as the bit density goes up (inner tracks are shorter
than
outer).
some controllers, many of which use a
less-than-ideal timebase to define
the precompensation offsets imposed on the data stream.
This is true, or worse used oneshots. generally the time base for the
bit encoding was always a crystal with not worse than 200ppm error and less than 50ppm drift. The typical system
was usually within
50ppm of exact and drifted less than 25ppm over temperature extremes.
Often the actual data rate was far lower than that reference(usually 1/4
or 1/8th).
The one-shots were often timed with 5% resistors and 10% capacitors. Do you think you could take a stab at swapping the
timebase on your
Catweasel board with a 32 MHz crystal? I think that would be VERY
illuminating, particularly where these precomp/write-current-related
effects
are concerned, because phase noise introduced by the deviation of the
Catweasel timebase from a harmonic of the data rate adds confusion.
There lies a connundrum, study the media and the magnetic domains therein
or get the data? A lower clock would be adaquate for getting the data.
>
> Further, while I was studying digital PLLd state machines I found a
point
where
increasing the clock (greater resolution) produced sharply reduced
improvement. Signal processing theory (analog) suggests the same.
That's true and the knee to which you refer lies around 6% jitter.
That's
16x the data rate. The phase noise from a digital PLL is quite tolerable
and the tracking accurate and reasonably continuous at that level. Below
that you have capture and tracking error and above that you're squandering
resources if there's no more compelling reason to have the frequency
available.
From: Tim Mann <mann(a)pa.dec.com>om>:
> So, what's the heuristic? It's quite
crude and oversimplified too,
> seems to work pretty well. The general idea is that if an interval is
> a bit off from what you were expecting it to be, multiply the error by
> some factor around 0.5 to 0.8 (you sometimes have to tune it for each
> disk if they are particularly bad), and add that to the next interval
I'd suggest some factor less than .5, flux shift errors on floppies
rarely move a great amount unless the spindle bearings are rattling
loose. Actually based on media and expected recording rate it's
possible to plug in a set of expected timing windows and add/subtract
a "precompenstation" window amount based on adjacent bits. For
example adjacent ones or zeros (especially more than two bits)
tend to spread or compress over patterns like alternating ones
and zeros.
Further with all the "timing image" in a memory it should be possible
to look at longer strings of transistions and do simple predictive
forcasting (software PLL). Add to that the encoding form (FM,
MFM, M2FM, RLL or GCR), and previous bits history it should be
straightforward enough to predict the likely next transistion(s)
be they one or zero.
It is serediptious that the code you have effectively accomplishes
a tracking filter (type of PLL). Why, many of the parameters on
the media like peakshift and other behavours tend to average
themselves and cancle. Most of this stuff is not rocket science,
it does however require seeing into the set of abstractions to
make them obvious.
Allison
11:45 a.m.
There's no point in confusing you withthe facts, Allison, is there . . .
Dick
----- Original Message -----
From: <allisonp(a)world.std.com>
To: <classiccmp(a)classiccmp.org>
Sent: Thursday, July 06, 2000 6:31 AM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
define
They were temperature and voltage sensitive as all hell. Most of the caps
were not good quality and the resistors while within 5% of stated value
said little about their thermal characteristics.
> >
> > >Do you think you could take a stab at swapping the timebase on your
> > >Catweasel board with a 32 MHz crystal? I think that would be VERY
> > >illuminating, particularly where these precomp/write-current-related
> > >effects
> > >are concerned, because phase noise introduced by the deviation of the
> > >Catweasel timebase from a harmonic of the data rate adds confusion.
> >
> > There lies a connundrum, study the media and the magnetic domains
therein
reduced
is
here you wade through the comments...
On Wed, 5 Jul 2000, Richard Erlacher wrote:
> Please see comments embedded below.
>
> Dick
>
> ----- Original Message -----
> From: allisonp <allisonp(a)world.std.com>
> To: Classic Computers <classiccmp(a)classiccmp.org>
> Sent: Wednesday, July 05, 2000 7:15 PM
> Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
>
>
> > From: Richard Erlacher <richard(a)idcomm.com>
> > To: classiccmp(a)classiccmp.org <classiccmp(a)classiccmp.org>
> > Date: Wednesday, July 05, 2000 7:30 PM
> > Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
> >
> >
> > >You may be onto something, Tim, but I'd make one observation here.
The
> > >signal on pin2 of the 8" drive
cable, though often driven with the
> > >1793's TG43 signal, does not turn write precomp on and off, but,
rather,
> > >reduces the write current to the heads.
This reduces the amplitude
of
> > the
> > >signal
> >
> >
> > In many cases it's also used to alter write precomp. Most all have
some
> > precomp (Esp DD controllers) and for the
TG43 case they alter the
precomp
> > to further compensate for bit shift due to
the close magnetic domains.
> >
> That's precisely what I said, isn't it? The only thing is that driving
pin
> 2 (RWC) of the cable doesn't do anything on
the controller unless you've
> provided circuitry to do that. I did say the TG43 flag on the 179x is
used
> to enable precomp, right?
> >
> > >driving the heads, hence reduces the overall amplitude of the
recovered
> > >signal as well. That same signal is
used to enable write
> > precompensation on
> >
> > Bogus. the levels are dealt with in the read amps with margin as
well.
> > What's changing of the write current
really impacts is the read bit
shift
> > (aka peak shift) as the bit density goes up
(inner tracks are shorter
> > than
> > outer).
> >
> Gee, if reducing the write current is done to reduce the signal
amplitude on
the heads, I
wonder why they say that . . .
It does but the peak shift is what is of more interest and the lower read
signal is less of a concern than mashed flux trasistions.
> >
> > >some controllers, many of which use a less-than-ideal timebase to
> > >the precompensation offsets imposed on
the data stream.
> >
> > This is true, or worse used oneshots. generally the time base for the
> > bit encoding was always a crystal with not worse than 200ppm error
>
> Commercial standard for crystal oscillators has been 100 ppm since back
in
> the mid '70's. There were cheap ones at
1000 ppm, though, but most
floppy
> drives didn't have need for oscillators.
That's where the one-shots
lived.
I said crystals not complete oscilators. Many of the cheap cpu clock
rocks were really low accuracy parts. Like Tim said, in the world of
mechanical slop 200ppm is nothing!
>
> > and less than 50ppm drift. The typical system was usually within
> > 50ppm of exact and drifted less than 25ppm over temperature extremes.
> > Often the actual data rate was far lower than that reference(usually
1/4
or 1/8th).
The one-shots were often timed with 5% resistors and 10% capacitors. > > or get the data? A lower clock would be
adaquate for getting the
data.
> >
> A clock as slow as 4 MHz would be quite adequate for reading, Allison,
but
> if you want the optimal relationship between
write data and precomp,
> ensuring best likelihood of recovering the data, you need to have 16x
> resolution as a minimum, and somewhere on the order or 12x as the
interval
> by which you precompensate. This can vary
considerably with the drive,
but
> it's a typical value for 1980-generation
heads and media. SMC and
Western
Digital both
made parts, rather late in the game, that performed these
functions digitally but used a 32x clock.
I'm quite aware of them, since the early 80s.
>
> Further, while I was studying digital PLLd state machines I found a
point
> > where increasing the clock (greater resolution) produced sharply > > improvement. Signal processing theory
(analog) suggests the same.
> >
> That's true and the knee to which you refer lies around 6% jitter.
That's
> 16x the data rate. The phase noise from a
digital PLL is quite
tolerable
> and the tracking accurate and reasonably
continuous at that level.
Below
> that you have capture and tracking error and
above that you're
squandering
resources if
there's no more compelling reason to have the frequency
available.
Yep.
> >
> > From: Tim Mann <mann(a)pa.dec.com>om>:
> >
> > >> So, what's the heuristic? It's quite crude and oversimplified
too,
> > >> seems to work pretty well. The general idea is that if an interval
> > >> a bit off from what you were
expecting it to be, multiply the error
by
> > >> some factor around 0.5 to 0.8 (you
sometimes have to tune it for
each
> > >> disk if they are particularly bad),
and add that to the next
interval
I'd suggest some factor less than .5, flux shift errors on floppies
rarely move a great amount unless the spindle bearings are rattling
loose. Actually based on media and expected recording rate it's
possible to plug in a set of expected timing windows and add/subtract
a "precompenstation" window amount based on adjacent bits. For
example adjacent ones or zeros (especially more than two bits)
tend to spread or compress over patterns like alternating ones
and zeros.
Further with all the "timing image" in a memory it should be possible
to look at longer strings of transistions and do simple predictive
forcasting (software PLL). Add to that the encoding form (FM,
MFM, M2FM, RLL or GCR), and previous bits history it should be
straightforward enough to predict the likely next transistion(s)
be they one or zero.
It is serediptious that the code you have effectively accomplishes
a tracking filter (type of PLL). Why, many of the parameters on
the media like peakshift and other behavours tend to average
themselves and cancle. Most of this stuff is not rocket science,
it does however require seeing into the set of abstractions to
make them obvious.
Allison
8:41 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 1079 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000706/d56be49a/at…
1:01 p.m.
My point here was that the important effect downstream of the controller is
that write current is reduced in some cases. Most post 1980 drives kept
track of the track on which the heads were sitting and didn't use the signal
on Pin 2. I'm glad that SOMEONE caught that!
Since floppy dives typically reduce the write current on the inner tracks in
order to make the write precompensation done by the controller effective,
the two effects are not separable. What's interesting about this is that
they do reduce the write current irrespective of the modulation being used
to record the data. Consequently, it's important that one KNOW whether or
not a given drive uses the signal pin 2 of the cable to reduce write current
or whether it's simply a spare. One can conclude from the presence of track
counters on disk drives with the sole purpose of modifying the write current
suggests it's important. Drive makers used to charge extra for every little
option. They didn't think this feature was an option.
It's important, therefore, that reduced write current be implemented on
drives requiring it, whether from the controller or from the drive itself.
How does this impact the current topic? Well it means that effort needs to
go into the write side of the task, i.e. the computation of the bitstream
going to the write head, precisely timed at as nearly the nominal rate as
possible, with proper precompensation. It's difficult to compute the
nominal location and duration of each pulse if your data rate is not a
precise harmonic of the nominal data rate. This does not apply to reading,
but it's critical for writing, unless you believe you can deal with a
certain amount of of misalignment of the physical transitions with respect
to the theoretical ones. That is pretty likely if your write clock is fast
enough, since, as I mentioned yesterday, the typical disk controller looks
for the levels at certain times rather than the edges. Consequently the
pulse train can have considerable variation from the nominal transition
times and still be "close enough." That will require study, however, since
between every write clock frequency that's not a harrmonic of the
theoretical bit rate, there can occur pattern sensitivities that will make
the process break down under certain circumstances. This could be
simulated in software easily enough, playing a theoretical sample rate
against all possible combinations of, say 4K bits. It would take a while,
but might be worth it for its educational value. Naturally it's more
practical simply to use a common harmonic frequency and be done with it.
Dick
----- Original Message -----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: <classiccmp(a)classiccmp.org>
Sent: Thursday, July 06, 2000 11:41 AM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
> >You may be onto something, Tim, but I'd
make one observation here. The
> >signal on pin2 of the 8" drive cable, though often driven with the
> >1793's TG43 signal, does not turn write precomp on and off, but,
rather,
> >reduces the write current to the heads. This
reduces the amplitude of
> the
> >signal
>
>
> In many cases it's also used to alter write precomp. Most all have some
> precomp (Esp DD controllers) and for the TG43 case they alter the
precomp
to further
compensate for bit shift due to the close magnetic domains.
To clarify (I hope) this somewhat. The TG43 output of the controller may
well also be used to enable write precompensation _in the controller_.
I've never seen a floppy drive that does write precompenstation internally
-- it always seems to be a controller issue.
So in a sense, the signal on pin 2 of an 8" drive does not enable write
precompensation. It reduces the write current. The fact that the signal
that produces the signal on pin 2 also happens to enable precompenstation
in the controller is a separate issue.
-tony
2:30 p.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 3085 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000707/b5a88e30/at…
5:05 p.m.
What you say seems to wash with what I've seen even on later model drives,
Tony, but my main concern is that several of the jumper options on later
(after 1981) 8" drives used pin 2 for various options having to do with
overlapping seeks between two or more drives, radial head-loads, and things
like that. Shugart drives and Siemens drives all seem to direct the user to
Pin 2 for such options, but they all seem to have on-board track counters
for their write current control logic. It's likely the Qume's have, too,
since they're called out in one of my standalone FDC/FDD boxes as an option,
and I know them to use those options via Pin 2.
Hooking it up is necessary, but not sufficient in such cases as I've
mentioned, to ensure that the signal gets through. Careful examination is
called for in this case.
Dick
----- Original Message -----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: <classiccmp(a)classiccmp.org>
Sent: Thursday, July 06, 2000 5:30 PM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
use
>
> My point here was that the important effect downstream of the controller
is
> that write current is reduced in some cases.
Most post 1980 drives kept
> track of the track on which the heads were sitting and didn't use the
signal
on Pin 2.
I'm glad that SOMEONE caught that!
I guess I'm used to the older 8" drives, because just about all of mine
the Reduce Write Current (RWC) signal on pin 2. The
only exception I can
think of is the Elcomatics I have on my PC/XT. Those have a second
slotted optoswitch on the head positioner which is set to operate at
cylinder 43 and all higher cylinders. It's a jumper-selectable option
whether this, or pin 2, is used for RWC.
<snip>
-tony
Dick
8741
days inactive
8778
days old
51 comments
19 participants
participants (19)
-
allisonp＠world.std.com -
ard＠p850ug1.demon.co.uk -
celt＠chisp.net -
elvey＠hal.com -
eric＠brouhaha.com -
ernestls＠home.com -
foo＠siconic.com -
george＠racsys.rt.rain.com -
jfoust＠threedee.com -
jrkeys＠concentric.net -
mac＠Wireless.Com -
mann＠pa.dec.com -
marvin＠rain.org -
mikeford＠socal.rr.com -
ncherry＠home.net -
rdd＠smart.net -
richard＠idcomm.com -
transit＠lerctr.org -
whdawson＠mlynk.com