test-drb

test-drb@ccmp.vtda.org

101090 discussions

Tim's own version of the Catweasel/Compaticard/whatever

by CLASSICCMP＠trailing-edge.com

>First of all, what, in the sampled bitstream tells you that a bit is "flaky" >or in any sense questionable? If it's different on multiple read passes, then it's flaky. If it's different when read on different drives, then it's flaky. But since this particular circuit samples the data after it's gone through the AGC and discriminator section in the drive, you can't look at an individual pulse and say that it's flaky. A circuit which recorded the analog signal from the head (or one of the preamp stages) would be far better for spotting flaky bits. > Since your sampler is working at a harmonic >of the theoretical data rate, you should be able to find anomalies easier >than one who's sampling at some other frequency, but these frequencies >aren't terribly precise because of mechanical variations and the general >fact that even closely specified crystals still aren't identical in >frequency. I don't think there's any magic that results from me working at a harmonic of the nominal data frequency. I could be sampling at 14.353773 or 3.5798 or 4.00 MHz and it's all the same, because none of them are "locked" in any way to the actual data rate. >How can you tell that your error correction is of the bit that caused the >error? There are, in every sample, some bits that will fix the CRC that >weren't necessarily wrong in the first place. True, but if there's a flaky bit then it's more likely to be causing the CRC error. If I go to the two flaky bits in a sector and fiddle them by hand, and all of a sudden I match the CRC, then we're doing pretty well. Keep in mind that even with more-bits ECC's there are also multiple ways you can fiddle bits in the data section and still match up with the error correcting codes. > Since you're looking for read >errors not necessarily written incorrectly, I assume you have some means for >making a decision? Do you simply plow through the file, inverting every bit >and retesting the CRC? Again, I look for bits that read differently on different read passes, and fiddle those by hand. > How do you decide where the bit boundaries really >are? I've got a "software PLL". It synchronizes on both data and clock pulses, and when it senses that it's seriously out of whack it can adjust more rapidly than a traditional one-time-constant hardware PLL. > How do you interpret the chaos in the write-splices? I pretty much ignore the chaos. I've developed some graphing techniques that help me decide where the write-splices are for a particular low-level data format. (Remember, I'm mainly concerned with hard-sectored formats which vary a lot from one controller to the next. Many have *no* address information recorded magnetically.) >Do you operate your sampler in parallel with an FDC in order to ensure that >you've gotten a sample that's readable by the FDC? No, mostly I'm looking at oddball hard-sectored formats that a normal IBM3740-derived FDC chip can't handle. And if I had the real hard-sectored random-logic controller, I wouldn't need my analyzer circuit :-). >Have you, in general, considered using a PLL e.g. 4046 or some similar >device for generating a precise multiple of the detected data rate and >"tracking-out" the mechanical influences of your drive on speed? I thought about it, but I don't think it's necessary. My 8x oversampling seems to be just fine for both FM and MFM data formats. When I start making the descriptive web pages this weekend, I'll show some graphs that indicate how I find write splice areas and track data rate frequency from my analysis software. (I do no analysis in real-time, it's all done post-acquisition.) Tim.

25 years, 11 months

Tim's own version of the Catweasel/Compaticard/whatever

by pete＠dunnington.u-net.com

On Jul 6, 15:54, 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. > CRC's are quite good at fixing a single small burst. Dwight, I think you're confusing CRC (Cyclic Redundancy Check) with ECC (Error Correction Code). CRC is very good at detecting errors, including bursts of errors that might slip by simpler checks, but AFAIK tells you next to nothing about where they occurred. ECC tells you enough to correct small errors. I've not heard of anyone using CRCs for correction (not directly, anyway). > 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. Although disks use the V41 polynomial (X^16 + X^12 + X^5 + 1) not CRC32. > All errors that happen > within a 12 bit window are 100% correctable. Depends how large the data covered by the check is. For amounts of data larger than a certain size (dependant on the number of check bits and the algorithm used) there are several errors that will produce the same change in the ECC or CRC. So the window size is meaningless unless you also specify the data size and number of check bits. -- Pete Peter Turnbull Dept. of Computer Science University of York

25 years, 11 months

Networking Apple IIc or IIc+

by ethan_dicks＠yahoo.com

--- Mike Ford <mikeford(a)socal.rr.com> wrote: > >On a side note, I recently aquired an older IIgs. It works and I have no > >software for it except my 1978-1983 era stuff for my old II. Did people > >ever network the IIgs to a Mac? If so, how? > > The IIgs is a full localtalk ready Appleshare client machine, might be a > rom version issue... As mentioned previously on this list, I have a version 1.0 ROM in my IIgs. What is the "best" version? Are they for sale or for download to burn my own? -ethan ===== Even though my old e-mail address is no longer going to vanish, please note my new public address: erd(a)iname.com The original webpage address is still going away. The permanent home is: http://penguincentral.com/ See http://ohio.voyager.net/ for details. __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/

25 years, 11 months

Question for NW Apple II users.

by SUPRDAVE＠aol.com

In a message dated Fri, 7 Jul 2000 1:51:59 PM Eastern Daylight Time, Sellam Ismail <foo(a)siconic.com> writes: << 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 the platinum //e does have some differences from the regular enhanced //e besides the keyboard. for one, the extended 80 column card was now built into the planar so you didnt have to install a card in slot 3 anymore. I believe also the power switch was a little better than before. I remember our computer science teacher tell us to use the apple's power switch as little as possible since it would eventually quit working.

25 years, 11 months

Free Tektronix 4014 manuals

by mark.champion＠am.sony.com

I have an official Tektronix 4014 service manual and a photocopy of a 4014 user's manual. If someone wants them, they can have them for free. Mark Champion Sony Electronics 206-524-0014 mark.champion(a)am.sony.com

25 years, 11 months

Free Heathkit H19 manuals

by ethan_dicks＠yahoo.com

--- Mark Champion <mark.champion(a)am.sony.com> wrote: > I have several Heathkit H19 and Zenith Z19 manuals if various conditions. > > Does anyone want them? > > Mark Champion > Sony Electronics > 206-524-0014 > mark.champion(a)am.sony.com I've got an H19 terminal and no docs. Is this an all-or-nothing, or do you have multiple people clamoring for these? -ethan ===== Even though my old e-mail address is no longer going to vanish, please note my new public address: erd(a)iname.com The original webpage address is still going away. The permanent home is: http://penguincentral.com/ See http://ohio.voyager.net/ for details. __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/

25 years, 11 months

Tim's own version of the Catweasel/Compaticard/whatever

by CLASSICCMP＠trailing-edge.com

>CRC's are chosen for their immunity to pattern-sensitivity, among other >things, and ECC's, likewise are chosen on the basis of their suitability for >the sector-size, types of errors anticipated, etc. CRC-16, the one chosen >for FDC use, was chosen because it was already an established "standard." >There were, in fact, standard TTL devices commonly used to append CRC-16 to >data blocks in communication and disk/tape applications. There are a few >bitwise corrections that will make CRC-16 yield a zero, but there's no >reason to believe that introducing a bitwise change at one place or another >will yield the correct data just because CRC-16 yields a zero. True, the CRC-16 wasn't chosen for correctibility, but if you make multiple read passes over the data and spot a couple of "flaky" bits (changing >from read to read) and find a combination of 1's and 0's that matches the CRC, you're far ahead of someone with a hardware-only controller that doesn't allow access to the raw data for such "human judgement" error correction. Remember, you have to know how to do it yourself before you can do it on a computer! Schematic and code this afternoon folks! Tim.

25 years, 11 months

Free Tektronix 4014 manuals

by dhquebbeman＠theestopinalgroup.com

If any of the people who maintaining archives of these kind of docs ask first, go with them, but if not, rather than see them in the dump, I'll take 'em. let me know... -dq > -----Original Message----- > From: Mark Champion [mailto:mark.champion@am.sony.com] > Sent: Friday, July 07, 2000 1:01 PM > To: classiccmp(a)classiccmp.org > Subject: Free Tektronix 4014 manuals > > > I have an official Tektronix 4014 service manual and a > photocopy of a 4014 user's manual. > If someone wants them, they can have them for free. > > Mark Champion > Sony Electronics > 206-524-0014 > mark.champion(a)am.sony.com > >

25 years, 11 months

Free Vax Tapes

by mark.champion＠am.sony.com

I have 30 small (6" dia) VAX tapes (Opus 6250) and 12 large (7" dia) VAX tapes (Scotch 700). I believe the small tapes are 600' x 1/2" and the large tapes are 700' x 1/2". I think they have all been written on once with data - no executible files. Tapes are free if you can pick them up in the Northend of Seattle. Mark Champion 206-524-0014 mark.champion(a)am.sony.com

25 years, 11 months

Great Finds

by rigdonj＠intellistar.net

At 10:45 AM 7/6/00 -0400, you wrote: >> That's probably a DDS (aka "DAT") drive ... at least, that's >> the only drive >> I've ever seen built-in to any HP 9000/8x2 or HP 3000/9x2. >> (It'll be a DDS-1, most likely) > >That's what I suspected but, wasn't sure. I'll get some so that I'll have a >system backup. Any idea how much data fits on one? > > >> How much memory do you have? (The 8x2 and 9x2 could have >> memory plugged into >> just about any slots (front or back!). > >One of the systems is configured with 4 X 8MB of memory. The other has 1 X >32 MB. I also have 8 additional 8MB modules that were pulled from the system >with the bad CPU. Haven't had a chance to check them out yet. > >Between the two system (and spares), I have 6 HPIB interface cards, 10 I/O >MUX cards, 9 hard drives, 2 LAN cards, and 2 optical interface cards. > >We also found a short rack of hard drives at the junk dealers place but, I >didn't get them. I noticed that they had the fibre connectors but, at the >time didn't realize the computers had fibre interfaces :-( > >I might go back later and get the rack. If it's still there (Joe?) Nope, he scrapped it the next day. It's on it's way to China now. :-( Art has some fiber drives but I don't know if he'll part with them. I'll probably see him today. If I do I'll ask. Sorry I haven't answered your messages soooner. We went and picked up three more loads yesterday and I didn't get back till late. I'll try to pack the CD drive and get it in the mail today. BTW we got a SGI Onyx Reality Engine2 yesterday. It's HUGE!!!!! I'm taking Bob R. out to look at it this morning. Joe >

25 years, 11 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb