test-drb

test-drb@ccmp.vtda.org

101090 discussions

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!

25 years, 11 months

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

25 years, 11 months

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)...

25 years, 11 months

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

25 years, 11 months

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

25 years, 11 months

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

25 years, 11 months

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!

25 years, 11 months

VAX-11? and some C64 stuff

by mcguire＠neurotica.com

On May 31, Kenn Humborg wrote: > > Also, you'll need the special > > DEC monitor that goes with whatever station you are buying, you > > can't use a > > chincy PC compatable monitor with a VAXStation. > > However, a good quality multi-sync (i.e. modern) PC monitor > with BNC inputs will probably work fine. I'm using an > Iiyama Visionmaster 17 with a VAXstation 3500 (VCB02 video > adapter) with no trouble. > > (And I have my PC plugged into the VGA input, so I can switch > between VAX and PC using the monitor's front panel buttons.) The good thing, though, about using "original" DEC monitors on machines like those is that you can get a wonderfully HUGE tube with a deliriously tight dot pitch and fabulous video quality for next to nothing because they're fixed-frequency. The PeeCee world's inability to develop video systems that don't require changing sync rates every time the wind blows has afforded the Real Workstation world a wonderful advantage...a plethora of gorgeous, huge monitors that can be had for a song. :-) -Dave McGuire

25 years, 11 months

Fw: VMS media availability for VAX 8530

by geoffrob＠stmarks.pp.catholic.edu.au

Following post from comp.sys.dec reposted to classic computers at request of originator. Anyone on the list that can help him? I have the Pro380 console and 5.25" media for an 8530 console, (and an 8530 - minus the console to vax cables) even VMS on 9 track, but I'm a bit far away... I initially thought this place was in Europe somewhere, but it seems it's actually in New York USA. I've mentioned the room heater effects of ECL based systems. ----- Original Message ----- From: "Derek Konigsberg" <konigd(a)rpi.edu> Newsgroups: comp.sys.dec Sent: Sunday, May 28, 2000 1:31 AM Subject: VMS media availability for VAX 8530 > Hello, > In the Electronics Club at RPI (Rensselaer Polytechnic Institute), > we've come across a number of old DEC machines. It all started with a > PDP-11/45, then we got a VAX 8530 that was being dumped. We also have > a VAXstation 4 (doesn't exist, but we have one, and it looks like a II > by the case design) and a VAXstation 3100. Anyways, the main problem > is the 8530. Our main RA82 hard drive doesn't spin up, and we can't > find the problem. We have other functional hard drives, but no means > of installing VMS on them. Basically, we need the tape for our TU81+ > tape drive (6250bpi, I think), and the 5-1/4" floppy disk to put in > the console to bootstrap the machine. Yes, for anyone who didn't > know, this machine requires a special "VAX Console" (no, it's not a > terminal) to tell the machine to power up and to download the > microcode. Anyways, right now the machine is an impressive metal > obstruction in the room until we get it operational. So, does anyone > have or know where we can find the right VMS media for this beast? > > P.S. Just wondering, but anyone know what thing thing sold for back in > '87 when it was new? > > Thanks, > Derek Konigsberg > RPI Electronics Club, President > konigd(a)rpi.edu > >

25 years, 11 months

Defining Disk Image Dump Standard

by allisonp＠world.std.com

>> The way you separate the operating system from the executables is by never, >> Never, NEVER, mixing them on the same medium, particularly if it's intended >> for dissemination. If the platforms are disparate, you certainly don't need > >Ok, Mr. Wizard. Build a time machine, travel back in time, and urge all >the various computer manufacturers to never, NEVER mix their OS with the >rest of the program space on the disk. Fortunately, we are not trying to >revise the reality of our world, but are merely trying to deal with what >it has become, which is a much simpler procedure. Done! the OS was never mixed with data on CPM disks until CPM3 and CPM86. the system booted off OS specific tracks and DATA was never stored there and SYSTEM was never stored on DATA tracks. This applies to CP/M {1.3, 1.4, 2.0, 2.2} explicitly and many others as well. It makes little difference though. as then only reason is to make the boot easier as the booter then doesn't have to know the file system to read and launch the system which for cpm wasn't defined until boot completed (as the system tables were part of the boot image). Allison

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