test-drb July 2000

test-drb@ccmp.vtda.org

155 participants
521 discussions

by dhquebbeman＠theestopinalgroup.com

All I can find out about this drive is that it's a streaming unit. Is this another repackaged Cipher F880 Microstreamer? If so, then yes I just downloaded the complete Volume 1 docs on Saturday; they're in both .TIFF and .PDF format. If the HP is a different beast, well, good luck... somebody's likely got the docs. -dq -----Original Message----- From: Steve Robertson [mailto:steverob@hotoffice.com] Sent: Wednesday, July 05, 2000 10:25 AM To: classiccmp(a)classiccmp.org Subject: Great Finds Hey gang, With some help from Joe Rigdon, I found some really cool stuff this weekend. Located two complete HP 9000/832 minicomputers. After tinkering around for a few hours, I found one of them has a bad CPU and 3 of the 8 (total between two machines) hard drives had failed. So, between them, I managed to build a complete working system with some spares left over. What kind of tapes does the built-in drive use? The find-of-the-day however, was a HP 7980XC 9-track tape drive. Found this beauty in a dumpster at one of the junk dealers. It's god a few minor scratches on the front cover but, otherwise is in extremely good condition. The total asking price 5$. Anyone got spare DOCs for it? I hooked the tape drive up to one of the 832s but, just can't get it to work. Whenever I try to cpio or fbackup to the tape, the drive will try to work but, eventually gives a write error. The same thing happens with my other tape drive (HP7980) which I know is good. So, I suspect the problem is with the drivers, or configuration, or possibly me :-) If anyone can give pointers as to how to make it work, I'd sure appreciate it. See Ya, Steve Robertson <steverob(a)hotoffice.com>

24 years, 5 months

The Original MS-DOS 4.0

by dhquebbeman＠theestopinalgroup.com

> Well, I never heared about the version you are refering to, but > DOS was basicly starting from 2.0 able to do task switching. > All Informations necersary where contained within a series of > structures with a single root. The only missing thing was a > table of task pointers to switch between - and a service to > store and restore the screen content. There have been several > products offering this service. And with DOS 4 MS supplied the > infamous shell, capable of doing this. You could load several > applications and switch via a hot key combination. Windows is > still today (at least Win9x) based on this very same mechanism > for context switching. Also the functions for 'background' > applications/drivers where designed to support application > switching. The famous TSR mechanism was not only ment to steal > some memory for crude interrupt handlers, but also for true > serviceprovider tasks within the OS ... well, I guess most > programmers never realized the potential offered and kept > limited to a simple one programm state of mind. > > All this was already available starting with DOS 2.x, just > it has never been 'official' until DOS 4.x I'd have to differ with you a bit on this. A co-worker and I spent 6 months writing a DOS 2.0-compatible file system for our own application which contained its own home-rolled multitasker; we had to write the file system because the DOS file system calls were (and through at least 3.3) were not serially-reentrant. Even then, the performance was so poor (we had just moved to deploying on iAPX286 machines) that we ditched the full-task model and created what we today would call "threads", although we simply called them lightweight processes back then. The context switching you're referring to revolves around switching some data structures, such as the file handle table; but you have to wait until a file system call is done before you can swap to the next task. Not useful when (like us) you're developing real-time software. As an aside, this was for the last firm for which I worked as a programmer; I left in '90, and dropped in for a visit in '95; at that time, they told me the system I'd designed was running in a DOS box under the Alpha-release of Win95 and was beating a comparable application running on a VAX. I felt very good that day... -doug q

24 years, 5 months

Networking Apple IIc or IIc+

by ethan_dicks＠yahoo.com

--- Mike Ford <mikeford(a)socal.rr.com> wrote: > Many people have told me you can't network the IIc or IIc+ Hmm... I always thought you _could_. > but I am sure I remember somebody telling me the IIc+ could be kludged > to sort of work. Maybe that's what I'm remembering. > Skipping that issue (unless somebody knows more), I wonder if a > slower/dumber protocol than LocalTalk/AppleTalk might work? I _had_ assumed the IIc+ has a Z8530 SIO chip inside. If that is _not_ the case then it's probably some flavor of ACIA 65xx or 68xx UART. The Z8530 is a great chip, found in Suns, Macs, COMBOARDs ;-) For LocalTalk, Apple runs the chip at ~230kbps, IIRC (tangentally, I have the Byte article unveiling the 128K Mac where they describe a "slotless" architecture using virtual slots off the serial port in a manner that sounds like what USB has finally brought to the masses). I do not know if a 4Mhz 65C02 can pull data off the chip fast enough to be practical. We used to use a 4Mhz Z8530 w/an 8Mhz 68000 with plenty of cycles to go around. > The idea would be to plug a PhoneNet adapter into a IIc/IIc+ serial port, > 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? Kermit? That would handle a point-to-point network, any way. You might be able to start with a PPP implementation for the 6502 and retrofit some kind of ARPish protocol on top of it (since PPP lacks that sort of thing) and go >from there. 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? -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/

24 years, 5 months

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.

24 years, 5 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

24 years, 5 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/

24 years, 5 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.

24 years, 5 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

24 years, 5 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/

24 years, 5 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.

24 years, 5 months

← Newer
1
...
40
41
42
43
44
45
46
...
53
Older →

Jump to page:

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 July 2000