test-drb August 2004

test-drb@ccmp.vtda.org

283 participants
661 discussions

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

>From: "Cini, Richard" <RCini(a)congressfinancial.com> > >This example represents the block data using metatags...I guess along the >"XML" part of the thread. > >I was thinking similarly to you but not using XML metadata: > >;Hardware descriptor >MFGR >MACHINE >SUBTYPE >DRIVETYPE (this of course defines what follows) >;for floppy >DRIVESIZE >ENCODING >TRACKS >SECTORS >SECTSIZE >;HexData >; Each record or group of records contains the related media data. The >address record would be used for encoding the metadata >00TTSSHH: (00-track-sector-head) > >I looked to Intel Hex (or Motorola) because it had built-in CRC facilities >and it was human-readable ASCII. The drive and machine description could be >encoded in special MOT records probably. > >XML is more a more "current" technology but I was trying to keep with the >platform neutrality by sticking to text-only and not assuming the use of any >other technology like XML. > >Rich > Hi I like the use of OpenBoot like languages better than more natural languages like XML or such. My primary reason is that the Forth like languages are one of the few languages that syntax rules are simple enough that anyone ( with some programming skills ) can implement an interpreter. Also, the language is rich enough that one can even include various converters and even things like directory printout and file extractors inside the archive file it self ( with minimal overhead ). This is the concept of a postscript file. The file it self defines how to be printed with only a few initial primitives that directly correspond to printing. Without too much to go on, one could take the actual printout of a postscript file and the file itself and be able to determine the general rules for how do decode any postscript file. Kind of like the rosetta stone concept. We are talking about the maximum information in the smallest human readable form. Dwight

20 years, 4 months

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

>From: "Steve Thatcher" <melamy(a)earthlink.net> > >I agree with Sellam on the point about using it both for media re-creation and emulation. The trouble with the approach below of just using raw data on a track sector basis is that now you have created a file that can only be used with an emulator that understands the physical format and OS access for the computer system you are emulating. My earlier point of separating the data and the format information allows a single file (that would not be much bigger that the one described below) to contain multiple platform specific files that can be "read" by a simple utility that does not require any knowledge of the OS or the platform. > >best regards, Steve Thatcher Hi Steve You seem to be assuming that the particular disk you are archiving has a file structure. This is not always the case. Dwight

20 years, 4 months

Let's develop an open-source media archive standard

by melamy＠earthlink.net

no, I have only talked about data represented in xml ascii, that has three distinct sections. A overall structure that contains author, and other info. A data section that contains multiple data blocks with subsections that are identified as files, and finally, a third which describes the physical arrangement of the data blocks on some type of media. best regards, Steve Thatcher -----Original Message----- From: Vintage Computer Festival <vcf(a)siconic.com> Sent: Aug 11, 2004 2:53 PM To: Steve Thatcher <melamy(a)earthlink.net>, "General Discussion: On-Topic and Off-Topic Posts" <cctalk(a)classiccmp.org> Subject: RE: Let's develop an open-source media archive standard On Wed, 11 Aug 2004, Steve Thatcher wrote: > 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. What you're discussing here are binary images. -- 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

XML is platform neutral, ascii and provides a structure to information rather than just an INI file type of dump - the start and end keywords let you define as many sub structures as you need. best regards, Steve Thatcher -----Original Message----- From: Vintage Computer Festival <vcf(a)siconic.com> Sent: Aug 11, 2004 3:23 PM To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk(a)classiccmp.org> Subject: RE: Let's develop an open-source media archive standard On Wed, 11 Aug 2004, Cini, Richard wrote: > This example represents the block data using metatags...I guess along the > "XML" part of the thread. > > I was thinking similarly to you but not using XML metadata: > > ;Hardware descriptor > MFGR > MACHINE > SUBTYPE > DRIVETYPE (this of course defines what follows) > ;for floppy > DRIVESIZE > ENCODING > TRACKS > SECTORS > SECTSIZE > ;HexData > ; Each record or group of records contains the related media data. The > address record would be used for encoding the metadata > 00TTSSHH: (00-track-sector-head) > > I looked to Intel Hex (or Motorola) because it had built-in CRC facilities > and it was human-readable ASCII. The drive and machine description could be > encoded in special MOT records probably. I like the XML style because it's more explicit; more human-readable. > XML is more a more "current" technology but I was trying to keep with the > platform neutrality by sticking to text-only and not assuming the use of any > other technology like XML. XML is platform neutral because it's basically ASCII, right? -- 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 dwight.elvey＠amd.com

>From: "Jules Richardson" <julesrichardsonuk(a)yahoo.co.uk> ---snip--- > >As for file size, if encoding as hex that at least doubles the size of >your archive file compared to the original media (whatever it may be). >That's assuming no padding between hex characters. Seems like a big >waste to me :-( > ---snip--- >Jules > > Hi It mightseem a waste but i would expect to see a proper archive file to be 200% to 500% larger than the original data. Having the data in something that can be printed directly on paper is a must. This means something like HEX values or binary or whatever. Still, anything as non-printable bits is useless. JMHO Dwight

20 years, 4 months

List problems?

by healyzh＠aracnet.com

Have there been any sort of list problems? I noticed a couple days ago that I'd not gotten any messages since Saturday, but hadn't had time to do anything about it. Well, about 370 so far just showed up. Zane

20 years, 4 months

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

>From: "Vintage Computer Festival" <vcf(a)siconic.com> > >On Tue, 10 Aug 2004, John Foust wrote: > >> Astounding! Will that computer never die? And I say that >> as someone who Believed, '85-92. > >The Amiga is still going strong in some circles. More power to them. > >> I'm tempted to say that we should leave copy protection >> hacks out of the spec for now, but if it was extensible, >> that would be great. > >Yes, copy protection will defintely be able to be described naturally in >the specification I have in mind. The spec should be able to define >several layers of bit storage: logical (files, directories, etc.), byte >(e.g. tracks, sectors), and raw (bit streams). In this way, copy >protection schemes can be preserved by storing the image in the raw >format. > >This will of course have to be thought out, and it may not even be >included in the first revision of the spec, but as I declared originally, >the spec will be extensible. > >-- > >Sellam Ismail Vintage Computer Festival Hi Sellam I can understand the need for both raw bit stream and extracted data. I propose that it should always include both types of information. The raw bits are needed to actually rebuild a particular format but often the information in the data is all that one needs to extract. In the case of the H8/89, we have working machines to read and write the format. We just need the data that fills the sectors. In the case of the H8/89, I've written a bootstrap that can be entered through the monitor commands. In some cases, the machine has no monitor or bootstrapping method. In these cases, it would be necessary to create the disk on another machine. Having the raw bits of clock and data would then be valuable. I'm currently looking at using a DSP chip to extract raw data from disk. The biggest problem so far is that one needs to do one of two things. One either needs to extract clocking operations with something like a PLL or simply oversample the bit stream from the drive. To do the PLL method, one needs to understand the disk format used and have hardware to handle that particular format. The oversampling has the advantage that one can capture all that is needed and post process it to normalize the data. The disadvantage here is that it takes a lot of data space. The DSP chip I'm looking at doesn't have enough RAM space to capture an entire track. Capturing track fragments has the issue that one needs realign things later. Knowing when the two fragments are properly connected is not easy. It looks like the newer DSP chips do have enough speed to capture raw data with little or no external hardware. This means that one can get one of the manufacture's development boards ( usually in the $50-$150 range ) and wire it up to the disk drive by connector. The disadvantage here is that as newer chips come out, the older development boards are obsoleted. Still, having the raw data means that one can recreate the disk in the future, with some effort. Dwight

20 years, 4 months

Osborne / TRS-80 III wanted for British TV show- can you help?

by tosteve＠yahoo.com

This was posted on oldcomputers.net comments page, can anyone help? Please email rosy thomas directly: rosy.thomas(a)talkbackthames.tv hello, we are working on a comedy series over here at talkback - basically a pastiche of the old British technology programme "Tomorrow's World" specifically circa 1980. A script is currently being written which includes a fictitious military super computer - interest has been expressed in the stylistic beauty of the Osbourne 1 and also the TRS-80 model III... I expect you would not be interested in hiring your computers to our production but I wonder if you could advise me of any easy way to get hold of such rare computers for our temporary purposes. We do have full insurance public liability and otherwise. We start filming on the 13th September for 6 weeks. I will attempt e-bay and also explore all your links but if you could advise me in any way I would be very grateful. If you are interested there is information about our first series on the www.bbc.co.uk. This was a slightly different format in that it was a pastiche on the open university programmes of the late seventies. Thanking you in anticipation for any help you can give me. __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail

20 years, 4 months

Let's develop an open-source media archive standard

by RCini＠congressfinancial.com

I don't mean "machine address" but rather some sort of block address on the media. I was thinking more on the lines of how data sectors on a hard drive are numbered...not CHS numbering but "absolute sector" numbering from 0 to something. -----Original Message----- From: cctalk-bounces(a)classiccmp.org [mailto:cctalk-bounces@classiccmp.org]On Behalf Of Vintage Computer Festival Sent: Wednesday, August 11, 2004 2:00 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 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. The data should be structured in a way where address size does not even come into consideration. Why would we encode platform specific information into a media archive? -- 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

I agree with Sellam on the point about using it both for media re-creation and emulation. The trouble with the approach below of just using raw data on a track sector basis is that now you have created a file that can only be used with an emulator that understands the physical format and OS access for the computer system you are emulating. My earlier point of separating the data and the format information allows a single file (that would not be much bigger that the one described below) to contain multiple platform specific files that can be "read" by a simple utility that does not require any knowledge of the OS or the platform. best regards, Steve Thatcher -----Original Message----- From: Vintage Computer Festival <vcf(a)siconic.com> Sent: Aug 11, 2004 10:56 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 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

← Newer
1
...
38
39
40
41
42
43
44
...
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