test-drb June 2000

test-drb@ccmp.vtda.org

160 participants
580 discussions

by mgregory＠vantageresearch.com

-----Original Message----- From: Sellam Ismail <foo(a)siconic.com> To: classiccmp(a)classiccmp.org <classiccmp(a)classiccmp.org> Date: Thursday, June 01, 2000 3:49 PM Subject: Re: Tech Rumors/Legends? > >When did Jay Miner pass away? > June 20, 1994. For a full bio, see http://www.jms.org/jay-miner.html Mark.

24 years, 1 month

OT: Archiving data (LONG)

by CLASSICCMP＠trailing-edge.com

>I like the ideas about digitizing the stream of raw disk data. >I imagine it would be possible to perform some software-based >analysis and repair, rendering previously scrogged disks readable. >Or perhaps the forensic-style recovery of erased data, reading >and averaging adjacent off-center track information. > >I seem to remember a PDP guy on this list who recovers reel tape >data this way, digitizing the raw tracks and processing with >software, as opposed to relying on antique hardware methods for >decoding the stream. That would've been me, I think :-). It really is straightforward to do today - a PC, a few hundred dollars of investment for the A/D hardware and cabling, an old 9-track or 7-track drive that you can set up to spool forward at a constant rate, and you've got the hardware side done. The analysis software is where the real magic occurs - look up "PRML" in a good engineering or math bookstore and you'll be on the right path. Incorporating the data from non-flaky channels to recover the data in the flaky channel is easy for 1/2" magtapes because of the existence of both longitudinal and horizontal parity bits. The same techniques work for 8", 5.25", and 3.5" floppies, too. You don't have the luxury of parity channels there, but PRML techniques put you way ahead of traditional data separators. -- 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, 1 month

OT: Archiving data (LONG)

by CLASSICCMP＠trailing-edge.com

>> >Yes, but how long can we expect the film to last? >> >> Decades, if processed sloppily, or centuries, if processed archivally. > >Sounds great, but how readily available is the process of film archiving >to hobbyists, how easy is it to master, and how much does it cost? This isn't rocket science; archival-quality film processing has been studied for most of a century already. Anyone capable of following the Kodak (or Ilford, or Agfa) directions and who has a kitchen sink, about $25 for hardware, and about $10 for photo chemicals can do it. No, it isn't the point-and-click interface you're used to, but some of us actually enjoy mixing chemicals and processing film and paper by hand. -- 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, 1 month

Defining Disk Image Dump Standard

by foo＠siconic.com

Current iteration: Desk Descriptor Header 1. Host computer type (2 bytes allowing up to 65536 models to be specified) 2. Hard/soft sector flag (1 byte) 3. Number of tracks (1 byte) 4. Disk drive RPM (2 bytes: 1 for whole number, 1 for fraction) [1] Optional: 5. Archiver Name (24 bytes) 6. Archiver E-mail Address (48 bytes) 7. Disk Title (64 bytes) 8. Publisher (if applicable) (24 bytes) 9. Year of Publication (2 bytes) A. Archive Description (256-512 bytes) B. Archive Date (4 bytes: 2 bytes = year, 1 byte = month, 1 byte = day) C. Archive Time (3 bytes: hour, minute, second) ***Does it make sense to have separate fields as specified #7-9 or should we rely upon the archivist to include that data in the description? I think so since this is important information that should be forced to be included with the archive. Maximum size: 685 bytes [1] If applicable Note: Encoding type moved to Track Descriptor Header A Track Descriptor Header will precede each track and give an overall description of the track: Track Descriptor Header 1. Track number (2 bytes: 1 for whole number, 1 for fraction) [1] 2. Disk Side (1 byte) 3. Track format (logical or raw; host computer specific) (1 byte) [2] 4. Track size in bytes (2 bytes) [3] 5. Sector format (single-density, double-density, etc) (1 byte) 6. Encoding type (1 byte) 7. Sectors in this track (1 byte) 8. Interleave (1 byte) 9. Bytes per sector (2 bytes) A. Bits per byte (1 byte) B. Offset to next Track Descriptor Header (2 bytes) Size: 15 bytes [1] Fraction allows for specifying half- or quarter-track. [2] If the track is in "raw" format then fields 3-9 are ignored. [3] The total size in bytes of the raw track image. I can start to see where the flexibility afforded by a markup language makes sense. I just can't figure out why I am still resisting it though. So, are we on the right track? The wrong track? Sellam International Man of Intrigue and Danger ------------------------------------------------------------------------------- Looking for a six in a pile of nines... Coming soon: VCF 4.0! VCF East: Planning in Progress See http://www.vintage.org for details!

24 years, 1 month

Defining Disk Image Dump Standard

by pete＠dunnington.u-net.com

On May 31, 22:05, Sellam Ismail wrote: > > Responding to an older message... > On Tue, 30 May 2000, Tony Duell wrote: [...] > > Which means the archive format would have to allow for : [...] > > It may be a _very_ unusual format, but a proposed archive format should > > be able to handle _anything_. Wel, I agree with that, so far as it's possible. > I suppose a sub-format byte wouldn't hurt. What I don't like about it is > that it will require that someone be maintaining a database of all the > sub-formats. But I guess since we have a machine identifier and this will > have to be maintained as well, a sub-format byte is not too demanding. > Of course, there will have to be a central person who is responsible for > receiving input for new machine and sub-format types, updating the > database with the new computer types and sub-format types, and > disseminating this from a website. That's part of the reason I think an encoded format is a bad idea. Hans' suggestion of a tagged format using XML (or something else) is much better. It allows for decoding without referring to a central archive, and it's much more flexible and extensible. Sure, it takes more space, but is that a problem? The tags don't all need to be ASCII text, things like the sector size could be integers, and field lengths could be limited. I'd envisage something like nested objects (borrowing from Sellam's slightly later mail): { Disk Descriptor Header, containing: Host computer type string "Hard"/"soft" sector flag Number of tracks (1 byte) Disk drive RPM ... { Track Descriptor Header, containing: Track number (with fraction) Track format "logical"/"raw" Track size in bytes Sectors in this track (1 byte) Offset to next Track Descriptor Header ... { Sector header descriptor, containing: Sector header format FM/MFM/GCR/... Sector data format FM/MFM/GCR/... [1] Sector number as encoded on the original disk Track number as encoded on original disk Head number as encoded on original disk Physical sector number Sector size ... { sector data (binary, hex-coded, whatever) } { Sector header descriptor } { sector data } } } The nesting tagging allows you to specify things like RX02 floppies, where the headers are FM but the data is MFM. It also allows you to specify different sector sizes on different tracks, or data written in the headers that doesn't match physical track/sector/side on the original. It also means that if the database is lost, damaged, incomplete or otherwise inaccesible, an archive can still be understood, and there's no chance of inconsistency because two people tried to add new formats at about the same time, or someone rolled their own. I've seen too many data formats where the decoding information was unavailable, or was hard to get, or was "location unknown at this time", or the prospective user simply didn't now where to look. If the information is in the archive itself, anyone can work out what do do with it, any time. -- Pete Peter Turnbull Dept. of Computer Science University of York

24 years, 1 month

OT: Archiving data (LONG)

by dhquebbeman＠theestopinalgroup.com

> I'm one of the people who still does use paper tape for backup. Not for Any chance you have a spare reader you'd be willing to load? I'd be willing to put up a security desposit for its safe return... -dq p.s. Oh, it's 8-level paper tape, not 5-level (just making sure)...

24 years, 1 month

IBM I/O Selectric/Posting Machine (Was RE: Atari 800 keyboard s)

by dhquebbeman＠theestopinalgroup.com

> How much do you want for it, and where is it? It sounds neat. I dunno... lemme think about it. Shipping is likely to be expensive! -dq

24 years, 1 month

Papertape and Mylar variant

by dhquebbeman＠theestopinalgroup.com

> > Right-o... teletypes with the reader/punch used rolls of paper tape. > > I have a copy of DEC Monopoly on papertape that I punched myself, as > > well as a copy of Intel's INTERP-80 (8080a simulator) and a > Star Trek > > game called BIGMES (from an HP 2000). > > What machine did INTERP-80 run on? Was it written in BASIC? No, it was written in Fortan-IV. I ported it from its original generic source code to run on the CDC6600 under Kronos 2.1, a DEC-10 running TOPS-10, and lastly, a Prime P400 running Primos. > I'm currently writing a simulation of the hardware that HP 2000 TSB ran > on (a pair of HP 21xx minicomputers with a pair of bidirectional parallel > interfaces between them). I've typed in most of the source code to > 2000C' from a printed listing, and have written an assembler in Perl. I must say, that's pretty cool. I used to have some other HP2000 programs, but the only one I found the other day was a listing that I'd printed on a Silent 700 terminal. Environmental effects have darkened the thermal paper to make it nearly unreadable. A bit of squinting for a day or two might surmount that problem. > I'd be interested in getting copies of those paper tapes, and anything > else you might have that could be run on a 2000. Naturally I'm willing > to pay copying and postage costs. As I consider the paper tapes priceless, you'd have to be willing to put up a serious chunk of change in escrow in case anything happened to them. Better that you wait for me stage them to a newer format. > I'll make accounts on the simulated 2000 available once it's running. If you need BASIC programs to run on your simulator, keep a close watch on E-Bay for books of BASIC games. I saw David Ahl's book 101 BAsic Games the other day; that's for DEC-10 BASIC, but I recall there were some books on HP BASIC back way back when, so one of those books will doubtlessly surface. Another resource for HP 2000 programs would be old issues of Creative Computing (another wonderful magazine killed by the evil Ziff-Davis empire). Good luck; I'll file your message to me in my hobby folder so that I'll have your e-mail address, and once I finally get BIGMES on disk, I'll let you know. -doug q

24 years, 1 month

Defining Disk Image Dump Standard

by pete＠dunnington.u-net.com

On May 31, 17:27, Mark Gregory wrote: > From: Pete Turnbull <pete(a)dunnington.u-net.com> > >Can I encode mine on knotted string? My mother has a box with an *awful* > >lot of string. Should I use the thicker string for DD disk archives? > If you want increase your data storage capacity, you could colour code the > string, too. > > Everything old is new again ... we've just re-invented the Inca quipu, a > few centuries on. I know. Aside from jibes at those who so vehemently insist that there should be one particular form of archive, I'm not sure anyone really knows how to read quipus, though. -- Pete Peter Turnbull Dept. of Computer Science University of York

24 years, 1 month

New Vintage Computer Festival Website!

by vcf＠siconic.com

The new Vintage Computer Festival website is now up. http://www.vintage.org Yes, there are still some broken links (none of the foreign language links work for instance...translators needed) but these will be fixed shortly. I invite anyone and everyone to submit articles for publication on the VCF website on any topic having to do with vintage computers and computer history. A link to the article will appear on the home page guaranteeing you exposure. Much thanks goes to Hans Franke for developing the new design! VCF 4.0 dates should be announced within a week or so. Sellam International Man of Intrigue and Danger ------------------------------------------------------------------------------- Looking for a six in a pile of nines... Coming soon: VCF 4.0! VCF East: Planning in Progress See http://www.vintage.org for details!

24 years, 1 month

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