test-drb May 2002

test-drb@ccmp.vtda.org

246 participants
947 discussions

by fmc＠reanimators.org

> Here you are talking about a data tape with fields that make up records > where the records are all the same size and the fields being varaible > length inside the record but repeating in all the other records. No, I am talking about a data tape with a physical structure that can be interpreted as a sequence of physical records (each of which has a length) and end-of-file (EOF) marks. The physical records can be blocks of multiple logical records as well. There are also inter-record gaps that separate the physical records and EOFs from each other, and I suppose the information about how long those are may be of interest to someone too, it just hasn't been of interest to me yet and I certainly don't see an obvious way to get that information using common hardware and software. > But a tape like this, from the days when tapes was used as random > access devices is not the format of a system archive tape is it ? Just because tapes were used as random access devices, that doesn't mean they were always used that way or were particularly good for it. And a system archive tape didn't need to be structured for random access. So, take classic MPE :STORE format. I'm thinking that it defaults to having a maximum on-tape block (physical tape record) length of 8192 bytes, but that's overrideable by the user and variable in any case. A single-volume (single-reel) :STORE set has several parts: (a) two files that could actually contain useful bits if this is really a :SYSDUMP tape (each is followed by its own EOF, even if not present); if this isn't a :SYSDUMP tape then there are two consecutive EOFs at the start (b) a :STORE label, which is a single 80-byte tape block followed by an EOF (c) a :STORE directory, which is written as blocks of up to the maximum block length; each block contains a number of 24-byte logical records which give the names of the files to be stored on this volumeset; again, this is followed by an EOF (Note this presents the order in which the files are stored on the volumeset) (d) user files, each of which is written as one 256-byte block containing a copy of the MPE file label followed by more blocks of actual file data, and finished off with an EOF (Note I may be forgetting some things about how user files are written to the tape; in particular I can't remember how user labels are stored; Stan may know more) (e) a :STORE trailer label, which is another 80-byte tape block followed by three EOFs A multi-volume :STORE set makes for some additional complexity. Volumes after the first don't have the two files and EOFs and just start with the :STORE directory, plus once you get to multi-volume you also need to deal with whether a file was split across volumes. OK, maybe I could kinda sorta do this by cat'ing the tape files to disk files and writing some code to kludge around the lost physical-record boundaries. I'm not sure about the user files but I have some ideas to try. But frankly I'd rather have a container file format and tools to collect and preserve the information. Then I can treat the container file like a tape. If I can write some descriptive text in the container file as well, that would be like sticking a label on the tape to me. > If it was me i would spool the whole raw image to disk, and work > with it there ,, it can certainly be massaged into any format you > like after that ... That is what I want too. The problem is, the "raw image" includes information other than the bytestream. If you use bytestream-oriented tools like cat, you lose that other information. -Frank McConnell

23 years

Hauppauge 4860 mboard question

by cpg＠aladdin.de

Hi, don't know whether this is appropriate for this list, but I'll ask anyway (it's over 10 years old). I've got a machine which has a 4860 motherboard, this a combi 80486/80860 with EISA slots. Overall it works fine, but there is a small problem enabling the cache. The battery is broken, so after turning off it loses it's BIOS and EISA configuration. When this happens I can go into the BIOS and setup everything, *enable the cache*, and boot from ide disk. Problem is since the EISA configuration is still invalid, the SCSI controller does not work. After I setup the EISA configuration with the DOS CF.EXE utility, the SCSI controller works, but the cache is disabled, and I cannot re-enable it in the BIOS menu (menu item is disabled). What can the problem be? Anyone experienced s/th similar? regards, chris

23 years

Request for Help with the Definicon DSI-32 (NS32032 PC Coprocessor board)

by morgarws＠mh.us.sbphrd.com

I'm looking for any documentation and software for the Definicon DSI-32 (NS32032 PC/XT coprocessor board). ... anything would be useful! Thanks in Advance, Bill Morgart morgarws(a)Molbio.sbphrd.com

23 years

Tape dumping programs for Unix/Linux..

by csmith＠amdocs.com

> -----Original Message----- > From: Raymond Moyers [mailto:rmoyers@nop.org] > If i might use the 1991 mips 3k sysVr4 unix thats on my old sony > NeWS again as an example, its tar program cant write > or read from a file. its only provided function is to/from > the tape device to the file system,, how absurd ! Absurd? It is for making "tape archives..." :) On the other hand, I'm sure there must be some way to make it work, though, if you wanted an on-disk archive, I'm sure they would have expected you to use ar. ;) Chris Christopher Smith, Perl Developer Amdocs - Champaign, IL /usr/bin/perl -e ' print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n"); '

23 years

Need IDT 7M624 Info

by Innfogra＠aol.com

In a message dated 5/3/02 2:22:42 AM Pacific Daylight Time, tothwolf(a)concentric.net writes: > http://members.aol.com/innfogra/idt624a1.jpg > > Based on looks alone, I'd guess it is some type of RAM. IIRC, IDT did make > some RAM, but also made quite a few other special purpose chips. > > > http://members.aol.com/innfogra/idt624a2.jpg > > This link didn't work btw. > > Fixed the broken link, thanks Toth. The bottom is the same as the top, 8 more small gold caps. I remember something about them being 1 Meg something or other. That something or other is what I am trying to figure out of course. I wonder if they could be an EEPROM like another smaller chip I have. That one is listed on ebay at the moment as a SEEQ EEPROM. It uses a similar but smaller IDT chip like this as a controller. <A HREF="http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=1728103123">eBay item 1728103123 (Ends May-09-02 12:53:43 PDT ) - Unusual Gold SEEQ 1 Meg E</A> Maybe these are a 1 Meg EEPROM based on 64K cores? Anyone got a book out there? Thanks for the help. Paxton Astoria, OR

23 years

Mac SE PC Drive Card

by mythtech＠mac.com

>I picked up another Mac SE today, and it's got a "Macintosh SE PC Drive >Card" installed in it, with a big connector on the back of the SE. What is >the card for? Apple made a PC compatible drive that worked with the SE and the Mac II. It needed a special card to connect to the computer (why they couldn't just use the already present Floppy port I have no idea). There was an SE PDS slot card (the one you have), and a NuBus version for the Mac II. They made this for the era before they were shipping the "SuperDrives" that could read/write 1.44 disks, and PC format disks. It ONLY works with the SE or the Mac II. I don't know if it will work with the SE FDHD. If you had the Mac II NuBus card, I would ask you for it, but I already have the SE version. -chris <http://www.mythtech.net>

23 years

Need IDT 7M624 Info

by Innfogra＠aol.com

I bought 6 of these chips about 8 or 9 years ago, IIRC. However I have exhausted all of my resources to identify them at the moment. I would like to know what they are. The numbers are: IDT 7M624 S45C (Delta symbol) 8738G1 Pretty chip, 8 gold caps mounted on a large purple ceramic substrate. 40 pin wide DIP. 7/8 inch by 2 7/16 inch in size, large like a 68000 but not as long. Pictures at: http://members.aol.com/innfogra/idt624a1.jpg http://members.aol.com/innfogra/idt624a2.jpg Paxton Astoria, OR

23 years

pdp 11/44 terminating UNIBUS

by huglhuglhugl＠gmx.net

Hi! Now that my pdp11/44 is talking to me (switched from current loop to rs232), i'd like to use it, of course. But i'm missing a unibus-terminator. Does someone have a spare one ? i do have some cards (unibus and qbus) to trade... btw. i live in Belgium / Europe. Or is there a way to make a unibus-terminator, AFAIK they only contain resistors. Did someone do this before, or maybe someone has scematics of a terminator ? regards, lothar. -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net

23 years

Tape dumping programs for Unix/Linux...

by cdl＠proxima.ucsd.edu

> From: Raymond Moyers <rmoyers(a)nop.org> > To: classiccmp(a)classiccmp.org > Subject: Re: Tape dumping programs for Unix/Linux... > Date: Thu, 2 May 2002 21:56:13 -0500 > In-Reply-To: <000501c1f245$6a304ca0$1aefffcc@Shadow> > > You really have me going about the 9 track behavior tho > null portion of tape as record delimiters "crap in the gap" > problems of the past, and other such things. > > So far what ive learned about those things is nothing as > many years around this stuff conditioned me to expect. > > If i spool the whole raw tape using a driver that knows > nothing of any null gaps and simply spool all bytes that > are bytes to a file .... could not i then pull the desired content > out of the spool if i knew the format of the data ? > > If random access is what they are doing, how did they deal > with a rewritten record, pad the unused portion of the record > to overwrite trailing garbage ? or was the bytecount in a rewritten > headder so that the controller knew the valid byte count ? By its physical nature, a magtape is a sequential-access device. One can of course keep track of position on the tape and use it as a "random-access" input device. Standard magtapes as block-replaceable devices were not at all common, and were really sort of a stunt, "see what I can do" phenomenon. > a tape with blank as delimiter/filler and records with no or > painfully terse descriptors seems to me very .... um something. That's the way it is when hardware is not very clever. Back in the olden days. However, the record mark delimiter was more sophisticated than just blank tape. It was actually a pair of characters surrounded by blank tape, a two-character record, that could be detected by analog circuitry. carl

23 years

Tape dumping programs for Unix/Linux...

by cdl＠proxima.ucsd.edu

> From: Raymond Moyers <rmoyers(a)nop.org> > To: classiccmp(a)classiccmp.org > Subject: Re: Tape dumping programs for Unix/Linux... > Date: Thu, 2 May 2002 16:37:30 -0500 > In-Reply-To: <200205021718.g42HI9X7086853(a)daemonweed.reanimators.org> > > On Thursday 02 May 2002 12:18, you wrote: > > > > Whats wrong with cat ? > > > > What's wrong with cat (and dd, and arguably the whole Un*x concept of > > files-as-bytestreams for that matter) is that it loses information. A > > magnetic tape is not an ordered stream of bytes, it is an ordered > > stream of files of records, and each record has a length. > > Here you are talking about a data tape with fields that make up records > where the records are all the same size and the fields being varaible > length inside the record but repeating in all the other records. > > But a tape like this, from the days when tapes was used as random > access devices is not the format of a system archive tape is it ? > > > So you are forced to result to multiple disk files to maintain the file > > structure. > > (which adds to your hassle because now you need to manage collections > > of files instead of a single tape), > > Like with a tarball ? > > > and as you are copying the files to bytestreams you lose the record > > length information. > > Unless you are going to resurrect some old general ledger program > why is this important ? For the same reason it is important to resurrect old computer hardware. I thought that would be obvious to people who read this mailing list. carl -- carl lowenstein marine physical lab u.c. san diego clowenstein(a)ucsd.edu

23 years

← Newer
1
...
80
81
82
83
84
85
86
...
95
Older →

Jump to page:

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 May 2002