test-drb August 2004

test-drb@ccmp.vtda.org

283 participants
661 discussions

Let's develop an open-source media archive standard

by melamy＠earthlink.net

actually both Intel and Motorola use a checksum which is just the negative value of the summation of all bytes. A CRC check actually was used in zmodem for example and it is a mathematical value derived from a polynomial function (do a search for CRC onm the web). There are CRC code snippets for creation of this type of data. I know a three section approach that I was proposing is more complicated, but from a code standpoint allows total freedom of data access without having to create a target media let alone have the computer system to then read the media just to get at the data that was on a floppy disk. The beauty is that if you need to create a Northstar system diskette then you can, but if all you need is a copy of the dump.asm program then you can get that also without having to go any further than the file you started with. best regards, Steve Thatcher -----Original Message----- From: "Cini, Richard" <RCini(a)congressfinancial.com> Sent: Aug 11, 2004 7:37 AM To: "'General Discussion: On-Topic and Off-Topic Posts'" <cctalk(a)classiccmp.org> Subject: RE: Let's develop an open-source media archive standard Dave: I tend to forget about the Motorola format (call me an Intel snob). The 16mb would be enough for many systems, and I would hope that 4gb would be enough, at least for now, to represent the largest of the media types we want to represent. Rich -----Original Message----- From: cctalk-bounces(a)classiccmp.org [mailto:cctalk-bounces@classiccmp.org]On Behalf Of David V. Corbin Sent: Wednesday, August 11, 2004 10:34 AM To: 'General Discussion: On-Topic and Off-Topic Posts' Subject: RE: Let's develop an open-source media archive standard You might want to consider Motorola rather than Intel. The only reason I suggest this is the motorola format alread has a (semi) extensible record type description [the second char of each line]. S2 and S3 are already defined for 16MB and 4GB memory spaces... A (non-standard) record type "could" be used for media format, etc... Just my 16.3875 milli-EUR comment... >>> -----Original Message----- >>> From: cctalk-bounces(a)classiccmp.org >>> [mailto:cctalk-bounces@classiccmp.org] On Behalf Of Cini, Richard >>> Sent: Wednesday, August 11, 2004 10:02 AM >>> To: 'General Discussion: On-Topic and Off-Topic Posts' >>> Subject: RE: Let's develop an open-source media archive standard >>> >>> I haven't read the entire thread on this but I did read >>> Steve Thatcher's idea and it describes about where I was >>> coming out on this myself. >>> >>> I might have missed what the ultimate use of this archive >>> would be. Will the archive be used to (1) re-generate >>> original media; (2) operate with emualtors; (3) both? >>> >>> To ensure integrity of the data I would propose recording >>> the data in the Intel Hex format -- it's text-based and has >>> built-in CRC. Now, we'd have to modify the standard format >>> a bit to accommodate a larger address space and to add some >>> sort of standardized header (a "Hardware Descriptor"). This >>> data would be used by the de-archiver to interpret the >>> stream of data read from the data area (the "Hex Block"). >>> >>> I agree that a multi-layer approach offers the best >>> combination of platform neutrality and portability. I don't >>> really know if we need two or three layers as Steve >>> described to describe the file in a standard fashion. Using >>> an Intel Hex-like format would increase the "de-archiving" >>> time, but in my view it's a fair trade-off. De-archiving >>> software could translate the platform-neutral file into >>> another format better suited for use in emulators. >>> >>> I think that we should start compiling a list of the >>> various media we want represented and how that media is >>> organized natively. I don't mean "well, it has blocks and >>> sectors" either. We should examine the exact format down to >>> the actual numbers (i.e., "2048 blocks of 256-bytes >>> recorded twice"). Seeing how the various data stores are >>> organized should bring some clarity to how we should represent it. >>> >>> Just my $0.02. >>> >>> Rich >>>

20 years, 4 months

Let's develop an open-source media archive standard

by melamy＠earthlink.net

to clarify my comment about using zip, this was suggested as a way for a person to reduce the size of their archive for their own purposes. I was not proposing that data be compressed with zip for the actual archive file. The only assumption I made for data continuity was that the data needed to be ascii and to have some error detection ability to let the person accessing the data have an idea of validity. Keeping an image file in an error checked ascii file in a purely sequential form seems to me to not rely on any technology or special information other than accessing a pure data file from some type of computer system. As someone else suggested, ascii text could even be contained in archive files to explain how to get teh data back. My thought of having the data accessible as well as the formatting information would allow a single transmission of a group of files to be sent with information contained within to either get just the data or be able to actually create media copies. best regards, Steve Thatcher -----Original Message----- From: Doc Shipley <doc(a)mdrconsult.com> Sent: Aug 11, 2004 10:20 AM To: General(a)mdrconsult.com, Discussion@mdrconsult.com@null, On-Topic and Off-Topic Posts <cctalk(a)classiccmp.org>, null@null Subject: Re: Let's develop an open-source media archive standard Jules Richardson wrote: > On Wed, 2004-08-11 at 13:13, Steve Thatcher wrote: > > >> I would encode binary data as hex to keep everything ascii. Data size would expand, >>but the data would also be compressable so things could be kept in ZIP files of >>whatever choice a person would want to for their archiving purposes. > > > "could be kept" in zip files, yes - but then that's no use in 50 years > time if someone stumbles across a compressed file and has no idea how to > decompress it in order to read it and see what it is :-) There's going to have to be _some_ assumption of continuity or this project is hopeless. It's my opinion that short-term or long-term, anyone who wants or needs access to the data** will have some historical understanding of the computing environment contemporary to that data. Provisions for changing technology and loss of continuity are good, but we still need to draw the line at some point, especially concerning "external" archival of the archived data, i.e. zipped arcives and storage media. To go to an extreme example, even printed ASCII on paper or mylar isn't reliable. Paper may be just as archaic as hieroglyphics when the data is wanted. We have to depend on ongoing maintenance of these archives. If they are not periodically migrated to current media, and if the attached/imbedded documentation is not augmented to account for social and technical "loss of memory", future retrieval will be difficult, if not impossible, no matter what we do now. Doc ** Technically speaking. We can't provide for, say a non-technical attorney who wants recorded files as evidence. That example will end up in the hands of someone like us.

20 years, 4 months

Let's develop an open-source media archive standard

by RCini＠congressfinancial.com

I forgot to answer one part of the original post. If you need someone to act as the consolidator of the media data, I can do that. -----Original Message----- From: cctalk-bounces(a)classiccmp.org [mailto:cctalk-bounces@classiccmp.org]On Behalf Of Vintage Computer Festival Sent: Wednesday, August 11, 2004 1:56 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: RE: Let's develop an open-source media archive standard On Wed, 11 Aug 2004, Cini, Richard wrote: > I might have missed what the ultimate use of this archive would be. Will the > archive be used to (1) re-generate original media; (2) operate with > emualtors; (3) both? Both. Emulators will certainly be able to make use of the archive by having parsers built-in that can translate the archive data into something the emulator can use. So instead of point the emulator to a binary disk image, you would point it to an archive file and it would translate the file back into tracks/sectors, or punch cards, or whatever. > To ensure integrity of the data I would propose recording the data in the > Intel Hex format -- it's text-based and has built-in CRC. Now, we'd have to > modify the standard format a bit to accommodate a larger address space and > to add some sort of standardized header (a "Hardware Descriptor"). This data > would be used by the de-archiver to interpret the stream of data read from > the data area (the "Hex Block"). I think you're thinking of this in terms of a large binary file encoded as ASCII hex. If so, this is not what's being proposed. What is being discussed is a format which actually describes the physical medium. For example, on floppy: <MEDIA TYPE=FLOPPY SIZE=5.25 SIDES=1 DENSITY=SINGLE FORMAT=GCR TRACKS=35 SECTORS=16 SECTORSIZE=256> <VOLUME>Apple ][ System Disk</VOLUME> </MEDIA> <DATA> <TRACK 0><SECTOR 0> HERE WOULD BE THE ASCII HEX DATA FOR TRACK 0, SECTOR 0 </SECTOR></TRACK> ... <TRACK 34><SECTOR 15> HERE WOULD BE THE ASCII HEX DATA FOR TRACK 34, SECTOR 15 </SECTOR></TRACK> </DATA> > I think that we should start compiling a list of the various media we want > represented and how that media is organized natively. I don't mean "well, it > has blocks and sectors" either. We should examine the exact format down to > the actual numbers (i.e., "2048 blocks of 256-bytes recorded twice"). Seeing > how the various data stores are organized should bring some clarity to how > we should represent it. I agree. This would be useful. Does someone want to volunteer to do this? -- Sellam Ismail Vintage Computer Festival ---------------------------------------------------------------------------- -- International Man of Intrigue and Danger http://www.vintage.org [ Old computing resources for business || Buy/Sell/Trade Vintage Computers ] [ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]

20 years, 4 months

Let's develop an open-source media archive standard

by melamy＠earthlink.net

my concept of splitting the data and the formatting information relies on the data blocks being the correct size for whatever media you are creating. In other words, you could see 128, 256, 512, and 1024 "sectors" for floppies. Each data block is assigned a number (virtual or real) that is then used to put the data in the correct physical location on whatever media it was supposed to be put in. The addressing of the hex formats in less important that the ability to have a block size of the required length. A paper tape data block would be whatever arbitrary length the tape was a be sequential. Same goes for a cassette tapel recording that might have been converted to mp3 for storage. best regards, Steve Thatcher -----Original Message----- From: "David V. Corbin" <dvcorbin(a)optonline.net> Sent: Aug 11, 2004 8:46 AM To: "'General Discussion: On-Topic and Off-Topic Posts'" <cctalk(a)classiccmp.org> Subject: RE: Let's develop an open-source media archive standard S1 = 16 bit address in each record.. S2 = 24 bit address in each record.. S3 = 32 bit address in each record.. Hence the maximum sizes..... >>> -----Original Message----- >>> From: cctalk-bounces(a)classiccmp.org >>> [mailto:cctalk-bounces@classiccmp.org] On Behalf Of Jules Richardson >>> Sent: Wednesday, August 11, 2004 10:52 AM >>> To: 'General Discussion: On-Topic and Off-Topic Posts' >>> Subject: RE: Let's develop an open-source media archive standard >>> >>> On Wed, 2004-08-11 at 14:37, Cini, Richard wrote: >>> > Dave: >>> > >>> > I tend to forget about the Motorola format (call me an >>> Intel snob). >>> > The 16mb would be enough for many systems, and I would >>> hope that 4gb >>> > would be enough, at least for now, to represent the >>> largest of the >>> > media types we want to represent. >>> >>> I don't know about 4GB, but I'd really like to archive hard >>> disk images in the 20-30MB range using the same format if >>> possible... >>> >>> cheers >>> >>> Jules >>> >>> >>>

20 years, 4 months

DEC/PDP-11 ROMs -- was Re: TKQ50 proms

by pete＠dunnington.u-net.com

On Aug 9 2004, 21:58, trash3(a)splab.cas.neu.edu wrote: > I have three boards. Two of them are Rev. K3. One of the boards has PROMS > on it, and no readable version, but the second has the 330-E5 and the > 331-E5. Thanks, Joe. I've got images now. For those who may be interested, I've added a few more images to my DEC ROM collection, including those. In an effort to make it slightly more user-friendly, I've also added a 00ReadMe file and one called "ROMlist", which lists ROM numbers I know, with the modules they belong to, and some (occasionally cryptic) notes. The whole lot is at http://www.dunnington.u-net.com/public/DECROMs/ Further contributions welcome :-) Did anyone sort out a repository for the small PROMs used in Unibus bootstraps and the like? I know Henk has a nice (if you don't mind Javascript) list of the common ones, but I don't know if dumps are around anywhere. -- Pete Peter Turnbull Network Manager University of York

20 years, 4 months

5362 SSP Diskettes

by rfama＠deltacomputergroup.com

Hello, My name is Rick Fama from Delta Computer Group. We are in need of the SSP diskettes for a IBM 5362. Any idea of where I can obtain these? Thanks

20 years, 4 months

Let's develop an open-source media archive standard

by melamy＠earthlink.net

Hi all, after reading all this morning's posts, I thought I would throw out some thoughts. XML as a readable format is a great idea. There is plenty of software available on most platforms to deal with this format. I looked at the CAPS format and in part that would be okay. I would like to throw in an idea of whatever we create as a standard actually have three sections to it. The first would be a data description and subsequent data (i.e. Data Container contains Data Items). Block size, number of blocks, and block data... The second would be a physical format description that would tell how the data description data is actually stored on whatever media is being targeted (Format Container contains Format Items). Device type (sequential, random), track, sector, virtual sector, head, bad sectors, etc would be needed and then a mapping from each Data Item to each Format Item. The third would simply be a "image file" that would simply be a sequential block of data with length and CRC that contained the Data Container and Format Container. This type of arrangement would give us a single file to send around that not only allowed for the recreation of the physical format, but also allowed for direct file access (read only of course). I suppose one could think of it as a smart library file that not only contained one or more files, but also gave physical re-creation information. best regards, Steve Thatcher -----Original Message----- From: Vintage Computer Festival <vcf(a)siconic.com> Sent: Aug 10, 2004 7:04 PM To: Classic Computers Mailing List <cctalk(a)classiccmp.org> Subject: Let's develop an open-source media archive standard Ok, instead of all the unproductive bickering over semantics (most of which is illogical...come on, admit it) I'd rather we actually discuss developing further an open-source, public domain, free (in every sense of the word) standard for archiving data media of all types (magentic, paper, or otherwise). This is basically going to be a continuation of what we've already discussed on the list, and what Hans and I have discussed in private. First, let's start with the goals. The format should be: 1) Well Documented (with such documentation actively preserved in all four corners of the globe and beyond) 2) Not constrained to any particular hardware 3) Be inclusive of all physical (and logical?) manner of recording media 4) Be implementable on even the simplest architectures (because the original media source will in many cases have to be read on the hardware it is connected to) 5) Open source, public domain, etc. (although a copyright may be held if it makes sense to do so) 6) Adaptable, expandable, revisable (for future extensions) 7) Text-based and storable in commonly accessible character formats (i.e. a suitable subset of Unicode, i.e. ASCII) 8) Allow for the representation of media in either logical or physical (raw bit stream) formats This is a good start. Someone please continue adding to the definition. I will establish a special session at the next VCF (November 6-7) where we can commence a committee for formalizing this standard and getting it recognized internationally in all the various relevant groups (i.e. ANSI or ISO/IEC). -- Sellam Ismail Vintage Computer Festival ------------------------------------------------------------------------------ International Man of Intrigue and Danger http://www.vintage.org [ Old computing resources for business || Buy/Sell/Trade Vintage Computers ] [ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]

20 years, 4 months

Matrox graphic card

by Trevor.Wright＠metronetbcv.com

********************************************************************************* Before acting on this e-mail or opening any attachment you are advised to read Metronet Rail BCV Limited's disclaimer at the end of this e-mail. ********************************************************************************* Hi lee I found this discussion thread recently and would be interested in the Matrox Graphic cards - have you still got? Best Regards Trevor Wright Recently rescued .. HP 9000/300 - 68010 CPU, 1MB RAM + video (so it says) HP 9153A - 2 of, floppy + HD (probably 10MB) HP 35731A - 12" 512x400 monochrome monitor (some burn) HP 46021A - keyboard HP 46083A - HP-HIL rotary control HP 46084A - HP-HIL ID module One of the 9153A drives is alleged to contain the software to dribe a gas chromatograph (written in PASCAL) the other is alleged to contain the PASCAL compiller environment. Not tested as yet. Also .. MEM/340 - 4MB multibus II(?) memory card And bought recently .. Heurikon M220 - 5 of, VME, 68020/68881, 4MB DRAM, SCSI, 2 x SERIAL Matrox MMG640 - 2 of, VME, graphics, ?? I need info for the Matrox and Heurikon boards, and possibly ROM images, and I could use a VME backplane or two (or other VME cards such as ethernet) so the HP stuff and the multibus card are available for swap/sale. I can probably deliver/collect within the UK. Cheers Lee. ********************************************************************************* Any opinions expressed in this e-mail are those of the individual and not necessarily the company. This e-mail and any files transmitted with it are confidential and solely for the use of the intended recipient. It may contain material protected by attorney-client privilege. If you are not the intended recipient or the person responsible for delivering to the intended recipient, be advised that you have received this e-mail in error and that any use is strictly prohibited. If you have received this e-mail in error please notify the sender or Metronet Rail BCV Limited's service desk on 0870 458 3862 and then delete this message. Unencrypted e-mail is intrinsically insecure and Metronet Rail BCV Limited does not accept responsibility for any changes made to this e-mail or attachments during its transmission. If you are unsure of the authenticity of this e-mail then please contact the sender. Virus Disclaimer: Every effort has been made to ensure that this e-mail is virus free. However Metronet Rail BCV Limited does not accept any liability in respect to an undetected virus and recommends that the recipient(s) use an up to date virus scanner. Metronet Rail BCV Limited Registered Office: Templar House, 81-87 High Holborn, London WC1V 6NU. Company Number: 3923496 **********************************************************************************

20 years, 4 months

Beg, Borrow, or Steal OpenVMS media.

by eric＠redrouteone.net

Hello, I recently got an Alphaserver 2000 4/200 and I want to run OpenVMS on it. I have signed up for the Hobbyist program but I do not have the money to purchase the media. If someone has a set that I can borrow or get a copy of I would be very grateful. Thanks, Eric Moody

20 years, 4 months

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

Hi There is a format that has been used with the H8/89 hard sectored disk called SVD. I like it in some ways but not in others. Things I like: It is in a human readable format Sectors are separated by white space and/or comments comments can be added Things I don't like: Format is octal ( I prefer hexadecimal ) Header contains various bit of information that are not decoded in a human readable form( still encoded as octal values ). I use a straight binary image file to transfer disk images to my H8's and H89. Converting the SVD format to one that I can use is trivial. The issue of reading the actual file from an image and placing that into a file is another issue. Each disk system uses a different directory structure and allocation method. How this could be simply encoded into the image files is more than I'd like to think about unless one would just settle for a textual description in the comment space. As an example, the H8/89 hard sectored disk have a volume number encoded in the header field ( that isn't part of the data ). The directory and allocation tables are pointed to by specific locations on track 0. They are not at specific locations. Other issues that might be a problem are things like the actual encoding methods used. Not all data is in nice 8 bit chunks ( my Nicolet does 20 bit chunks ). Inter leaving is usually not a great issue since it often only effects speed but it might be important. Dwight >From: "Paul Koning" <pkoning(a)equallogic.com> > >>>>>> "Vintage" == Vintage Computer Festival <vcf(a)siconic.com> writes: > > Vintage> Ok, instead of all the unproductive bickering over semantics > Vintage> (most of which is illogical...come on, admit it) I'd rather > Vintage> we actually discuss developing further an open-source, > Vintage> public domain, free (in every sense of the word) standard > Vintage> for archiving data media of all types (magentic, paper, or > Vintage> otherwise). > > Vintage> This is basically going to be a continuation of what we've > Vintage> already discussed on the list, and what Hans and I have > Vintage> discussed in private. > > Vintage> First, let's start with the goals. > >When you say "archiving" what span of time do you mean? A year? A >decade? A century? Longer? > >You will get completely different answers depending on how you answer >that question. > >(See also www.longnow.org) > > paul > >

20 years, 4 months

← Newer
1
...
39
40
41
42
43
44
45
...
67
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 August 2004