test-drb July 2000

test-drb@ccmp.vtda.org

155 participants
521 discussions

who knows: Celerity [GEI Rechnersysteme] ?

by xds_sigma7＠hotmail.com

This should do it: (sent to the list for everyone's benefit) DATELINE: San Diego, CA March 3, 1986 Word Count:440 Celerity Computing 9692 Via Excelencia San Diego, CA 92126 619-271-9940 CELERITY SIGNS MAJOR OEM PACT WITH LEADING EUROPEAN DISTRIBUTOR SAN DIEGO, March 3, 1986 -- Less than a month after Celerity Computing's introduction of two new superminicomputer design systems, the company has signed a $3 million agreement to supply OEM configurations of the systems to GEI Rechnersysteme GmbH, Aachen, West Germany, a leading European systems house and distributor of of computer systems. Under terms of the two-year agreement, Celerity equipment, including its proprietary 32-bit ACCEL (TM) processor, will be incorporated into systems GEI manufactures and distributes to end-users in industrial automation, engineering design and simulation, and communications. GEI sells both customized and turnkey solutions throughout West Germany and Switzerland to customers including BMW, Audi, Volkswagen, Porsche, Ford, Philips and the German government. "This agreement with GEI represents not only a significant expansion of our presence into the European market, but also a major third- party endorsement of the performance and capabilities of our systems in the mechanical engineering arena," said Stephen Vallender, President of Celerity Computing. GEI installed more than 400 computer systems in 1985. The company is 50 percent-owned by AEG, which recently was acquired by Daimler- Benz/Mercedes. "We want to deliver the highest-quality, top-performance computer products to our customers," said Michael Emrich, President of GEI Rechnersysteme. "We ran benchmarks with all the players in the supermini and CAD/CAM markets, and Celerity clearly beat the others in performance and price." Celerity's UNIX (R) - and reducted instruction set (RISC)-based supermini design systems are the fastest and most powerful office_ environment systems in their price class for engineering and scientific applications. The Celerity C1260, introduced in January, 1986, is a dual-processor system with a benchmarked throughput of 6.15 million Whetstone instructions per second (W/MIPS). It is priced at $110,000 for a functional system configuration. The mid- range C1230, also introduced in January delivers 3.25 W/MIPS for $75,000. Both are deskside systems, allowing engineers to complete design tasks and compute-intensive analysis operations without off- loading to more expensive, remote computers. Three-year old Celerity Computing delivered its first computer system, the C1200, in November 1984. The company has installed more than 60 systems in leading corporations, research centers and universities throughout the United States. Its supermini design systems provide advanced design and analysis capabilities to professionals in a variety of fields, including automotive, manufacturing, aviation and aerospace, molecular modeling, animation, and research. ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

24 years, 5 months

(Fwd) [HP3000-L] Old 960 out to pasture.

by ss＠allegro.com

For anyone out there with an HP 3000/960 (or 960 or 980), or an HP 9000/860 (or 850 or 880?): ------- Forwarded message follows ------- Subject: [HP3000-L] Old 960 out to pasture. From: Debus-David(a)AER.ARAMARK.COM Greetings All, I am finally decommissioning my old and trusty 960. I have gutted the chassis for of all usable boards. They are all available to anyone interested in spare parts for the cost of shipping. One hard to find item is a SCSI bootable CA. There are numerous FL cards and the usual HP-IB cards. I need to move this quickly due to floor space problems. First interested party takes all. Thanks ------- End of forwarded message ------- No...I don't know where he is! (Please don't flame him) Stan Stan Sieler sieler(a)allegro.com www.allegro.com/sieler/wanted/index.html www.allegro.com/sieler

24 years, 5 months

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

by allisonp＠world.std.com

From: Tony Duell <ard(a)p850ug1.demon.co.uk> >> That's so true! I was surprised to read in the spec's for my first ones >> (and last, by the way) that the capacitance between adjacent contacts is 5 >> pf, I don't remember much else about them. > >And that's probably being somewhat optimistic!... > >I have certainly seen microcontrollers fail to clock properly when >they've been used on these breadboards. Hang a xtal and the 2 33pF (or >whatever) capacitors off them and the strays will mess things up. Often it's not the breadboard but the crude oscillator circuit that was used. the basic osc used in theory should never work but crystals are less deterministic and don't know that. The side effect is hard starting and a slight offset from the marked frequency. >Since soldering is so much more reliable, and just as fast once you get >used to using the soldering iron, I don't see the point of said >breadboards. But anyway... Different issue. FYI I breadboard on a peice of cheapo copper clad AKA dead bug or as the RAH calls it "ugly" construction. Works well and the groundplane is hard to beat. Either name, you lay the bugs upside down and point to point wire them (solder, programming language #1). Copper is ground and everything else aint. Goes together fast and tends to be fast logic and UHF friendly. Allison

24 years, 5 months

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

by mmcfadden＠cmh.edu

I suggest it be named "TIMBER - Data Logger" both for the creator and function. Mike mmcfadden(a)cmh.edu May be intoxicated from too much screen cleaner

24 years, 5 months

Looking for....

by steverob＠hotoffice.com

Get a couple more guys/gals and we could have our own mini-VCF. Steve Robertson <steverob(a)hotoffice.com> > -----Original Message----- > From: LFessen106(a)aol.com [mailto:LFessen106@aol.com] > Sent: Wednesday, July 05, 2000 3:39 PM > To: classiccmp(a)classiccmp.org > Subject: Re: Looking for.... > > > Well let me know if you want to come down here for a shopping > trip/vacation. I can take you to a lot better places than > Dismal World. > > Joe > > >> > > You're on :-) I occasionally get down to Orlando..! > -Linc. > >

24 years, 5 months

Great Finds

by steverob＠hotoffice.com

> 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?) > > work. Whenever I try to cpio or fbackup to the tape, the > drive will try to > > What version of HP-UX? Jeesh... I'm not even sure what versions are installed. One system hadn't been booted since 1996 the other hadn't been booted since 1994 so, the OS isn't exactly current. I've got the install CDs for HP-UX 10.20 Series 800 but am having trouble with the CD-ROM. Once I get the OS reinstalled, it should be a lot easier to diagnose the tape drive problem. > How did you configure the tape drive (ls -l /dev/...whatever...) I tried using some of the existing devices (ioscan -fn) but that didn't work. It looks like the system is using the driver "tape1". Not sure if that's correct or not? I also tried creating special files (mksf -H 52.0 /dev/...whatever...) with a variety of parameters but, just haven't hit the right combo yet. When I try to write to the tape, the drive displays "Write, Read, Write, Read, blah, blah...). Then the console says something like "Write error in tape header...). I don't believe it wrote any data but, I do think the setup is pretty close. At this point, I'm suspicious of the driver. Thanks, Steve Roberson

24 years, 5 months

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

by CLASSICCMP＠trailing-edge.com

>> Dealing with the >> different modulations, as you've named, is a software post-processing task. >You prefer software solutions. I prefer hardware. It doesn't make either >of us wrong. When you close your eyes, you see pseudocode. I see schematics. I've been using variants on "raw data capture" for years, and I find it *most* flexible when the data is captured in its rawest forms. In some cases this means running the signal from the head through an A/D converter and logging. This gives the most opportunities to apply funky data recovery techniques in software in case the media is old and rotting away. Taking the data from multiple reads passes - in some cases with the head stepped a fraction of track in and out - is a very powerful technique. Not everyone has floppy drives that are capable of stepping in 1/16th track increments, I realize :-). (I use a heavily hacked up pair of Persci's for this.) Tim.

24 years, 5 months

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

by CLASSICCMP＠trailing-edge.com

>>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). IMHO it's very misleading - or even worse, foolish - to worry about errors in the ppm range when the instantaneous rotation speed of the floppy can vary a few percent. Most data recovery circuits - even the most simplistic one-shot FM decoder - can take a 25% change in data rate in stride. Sure, they don't have as much error margin if you stray that far, but my point is that we're not dealing with National Bureau of Standards platinum-iridium references here. >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. Look up "PRML" or "Partial Response Maximum Likelihood". It's a branch of signal decoding for use in situations where adjacent pulses most definitely have measureable effects on each other. >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. Most uses of PRML look both forward *and* backwards. -- Tim Shoppa Email: shoppa(a)trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927

24 years, 5 months

ODT tutorial / online docs?

by mrbill＠mrbill.net

Anybody know where I can find an ODT tutorial/documentation (for a PDP 11/02) online? I'm having trouble booting a system... (http://www.pdp11.org/pics/pdp1102.jpg) Bill -- +-------------------\ /-----------------+ | Bill Bradford | www.sunhelp.org | | mrbill(a)mrbill.net | www.decvax.org | | Austin, Texas USA | www.pdp11.org | +-------------------/ \-----------------+

24 years, 5 months

Reading disks with Catweasel

by mann＠pa.dec.com

I noticed that someone forwarded one of my early messages about the Catweasel software I was working on to the list. I've made a lot more progress since then, so in case anyone is interested, below are a few more messages giving the latest news. Basically, it's working well, even on 8" disks. My program (cw2dmk) reads disks into a file format that represents decoded FM or MFM data, with the location of ID address marks noted, but no other indication of missing clocks or other odd stuff. This might be useful beyond the two TRS-80 emulators that currently support it, but it isn't the universal format that folks on this list were trying to design a month or two ago. Designing a format like that is an interesting problem. After my experience reading disks with the Catweasel, I'm not sure that simply recording the raw sample data is a good archival format. After my program decodes the FM or MFM data and checks for things like CRC errors and missing/unexpected data address marks, there are a fair number of errors that go away if I do a few retries at resampling the track. (Most disks have none, but they happen often enough to be noticeable when I'm reading a lot of disks.) So an archiver that just blindly sampled each track once without trying to decode it might end up recording data that could not be decoded later. Also, writing a good decoder is a bit of a pain, and some (what appears to me) black magic to reconstruct the data after bit-shifting has occurred. It would be nice to do the decoding once, up front, and archive decoded data. On the other hand, really strangely copy-protected disks from systems with disk controllers that are partly implemented in software might not be decodable using a general-purpose algorithm. Maybe it would be best to *try* to decode the data, do some retries if it can't be decoded, and archive both the result of decoding and the raw samples just for maximum safety.... --Tim ========Message 1======== From: mann(a)pa.dec.com (Tim Mann) Date: Thu, 22 Jun 2000 19:47:28 -0700 (PDT) To: trs80(a)cs.ubc.ca Subject: Announcing cw2dmk: read any TRS-80 floppy with a Catweasel ----- Background: The Catweasel ISA floppy disk controller is an add-in card for the PC ISA bus. It uses specialized hardware, not a standard floppy disk controller chip, and it can be programmed to read and write just about any disk format. Catweasel cards were in short supply for a while, but as of July 2000 they should be available for purchase again. See http://www.jschoenfeld.com/ and http://apd2.tripod.com/catweasl.htm. I've written a free program for the Catweasel called cw2dmk that can read any disk written by a TRS-80, including single-density and copy-protected disks. The disk is saved as a DMK image file, suitable for use in either the xtrs TRS-80 emulator for Unix, or David Keil's TRS-80 emulator for MS-DOS. cw2dmk runs on Linux, MS-DOS, or Windows 95/98. You can download it from http://www.tim-mann.org/trs80resources.html. Source code is included. My program uses some code from Michael Krause's Linux drivers for the Catweasel (which work with Amiga and MS-DOS diskettes). Besides TRS-80 disks, cw2dmk should be able to read any disk written by a WD177x/179x or by a standard PC (NEC765-compatible) disk controller. Currently it's not too useful to have non-TRS-80 disks in DMK format, but perhaps additional tools that work with this format will become available in the future. For example, I'd like to write a program that uses a Catweasel to write a DMK image back to a real floppy disk. This would provide a nice way of archiving disks from many old machines and making physical copies when needed. Another likely future direction for cw2dmk is to be able to write JV1 and JV3 disk images, when the disk being read can be represented in one of those formats. Those are the formats that Jeff Vavasour's and Matthew Reed's TRS-80 emulators need. By the way, I don't get a cut of Catweasel sales. :-) ========Message 2======== From: mann(a)pa.dec.com (Tim Mann) Date: Thu, 22 Jun 2000 21:33:59 -0700 (PDT) Newsgroups: comp.sys.tandy, comp.os.cpm Subject: Re: Announcing cw2dmk: read any TRS-80 floppy with a Catweasel ----- Oops. In that announcement, I forgot to say "TRS-80 Model I, III, 4, or 4P". These are the models that are currently supported by the emulators that use DMK format. Disks written by other computers that used the TRS-80 brand name will probably be readable too, but the images aren't currently too useful since there is not yet any software that uses DMK format other than these emulators. I do plan to read some Model II/12 disks for archival purposes when I get my 8" drive plugged in, and I'm also going to take a shot at reading some 3.5" Model 100 disks that someone is mailing me, but I don't have any results to report on that yet. ========Message 3======== From: Gary Shanafelt <...> Date: Thu, 22 Jun 2000 22:02:21 -0500 To: trs80(a)cs.ubc.ca Subject: Re: Announcing cw2dmk: read any TRS-80 floppy with a Catweasel ----- Tim, In your last message about the Catweasel board, you mentioned David Keil's emulator using DMK image files while Jeff Vavasour's and Matt Reed's used JV1 and JV3 format files. What's the difference? All the emulators call their files .DSK files; I recently downloaded David's program, set it up with some of the .DSK files from the Vavasour/Reed emulators, and it worked with them without further ado. I thought all these .DSK files were a single standard TRS-80 emulator format, but I guess not? ========Message 4======== From: mann(a)pa.dec.com (Tim Mann) Date: Thu, 22 Jun 2000 21:27:01 -0700 (PDT) To: Gary Shanafelt <...> Cc: trs80(a)cs.ubc.ca Subject: Re: Announcing cw2dmk: read any TRS-80 floppy with a Catweasel ----- The emulators all give the .DSK extension to their files, but they are using several different formats, which I've given the names DMK, JV1, and JV3. Full details are on http://www.tim-mann.org/trs80/dskspec.html, but here is a summary. JV1 can only handle single density disks with directory on track 17. Jeff Vavasour's Model I emulator works only with JV1 images. Jeff's Model III/4 emulator doesn't support JV1 images at all, but all the other major emulators will work with a JV1 image if you give one to them. JV3 can handle normal single and double density disks, but most forms of copy-protected disk are not representable. Almost all of the images on Ira Goldklang's site (www.trs-80.com) are in JV3. All the major emulators except Jeff's Model I emulator will work with JV3 images. Jeff originated this format in his Model III/4 emulator. DMK can handle anything that a TRS-80 disk controller can write to the disk, including all the copy-protected formats. Even protected game disks where the program does a Read Track and looks for specific data in the gaps between sectors can be recorded in DMK format and will run in emulators that support it. Currently only David Keil's emulator and xtrs support this format. David originated the format. Ira now has a small collection of images in DMK format that can't be represented in JV3 format. ========Message 5======== From: mann(a)pa.dec.com (Tim Mann) Date: Wed, 28 Jun 2000 16:17:10 -0700 (PDT) To: ... Subject: Early 8" results with Catweasel on LS-DOS disks ----- Thought you might be interested to hear that I tried reading a few 8" disks with a Catweasel last night, using my custom program (cw2dmk). They were mostly TRS-80 Model II LS-DOS disks with an FM track 0 and MFM on the rest of the disk. The FM was easy to read; the MFM required tweaking the thresholds in my program because the bit-shifting effect (that write precompensation is meant to adjust for) varies so much from the outer to inner tracks, and makes a sudden jump backward at track 44 where write precomp was turned on when the disks were written. I found a setting that worked, but it's touchy; a few retries were needed on tracks near 43 and 76. I might try to devise an algorithm that sets the thresholds automatically for each track by doing a histogram and looking for the exact location of the peaks and valleys, or I might try doing something that emulates a phase locked loop in software instead of using fixed thresholds.... The main disks I tried reading were copies of Model II/12 LS-DOS that Lamar Owen and Fred Dolan sent. The disk Fred sent had CRC errors on about half the tracks (usually one error per track), no matter what I did. I'm going to poke a bit more to see if it's a problem with my software or if the disk is really bad. The disks Lamar sent read OK once I got the thresholds right. ========Message 6======== From: mann(a)pa.dec.com (Tim Mann) Date: Mon, 3 Jul 2000 20:30:21 -0700 (PDT) To: ... Subject: Re: Early 8" results with Catweasel on LS-DOS disks ----- An update for those who may be interested: I found a heuristic to make up for insufficient write-precompensation (or for flux transitions that were close together moving farther apart over time). With this added to cw2dmk, I was able to read most of the 8" disks that I have without getting errors, including the one from Fred Dolan that previously showed CRC errors on about half the tracks. Here's the idea. When decoding MFM, the interval between each two successive flux transitions should be either short (2 cycles), medium (3), or long (4). Because of a physical effect, short transitions that come next to medium or long ones tend to spread out into their space. So after I classify a transition, I compute how long it ideally should have been and save the difference between the real and ideal lengths. I then add k times the difference to the next transition before classifying it, where k is a tuning parameter. With k=0, we have the old algorithm. A value of k around 0.5 to 0.8 made the difficult disks readable. Usually the exact value wasn't too critical, but on the really bad disks I had to experiment a bit to find the best setting. I imagine this technique (or something better) is well known in the disk drive industry, but it was a kick to me when I thought of it and it worked so well. I might go back to some 5.25" disks I have that showed CRC errors when read on a normal PC controller, and see if this trick will let me read some of them. Tim Mann tim.mann(a)compaq.com http://www.tim-mann.org Compaq Computer Corporation, Systems Research Center, Palo Alto, CA

24 years, 5 months

← Newer
1
...
42
43
44
45
46
47
48
...
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