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

as Sellam had suggested, the data size we represent the information in is not that important. 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. XML has become a storage format choice for a lot of different commercial packages. My knowledge is more based on the windows world, but I would doubt that other computer software houses are avoiding XML. Sun/Java certainly embraces it. I don't quite understand why representing binary as hex would affect the ability to have command line utilitities. Certainly more cpu cycles are needed for conversion and image file size is larger, but we need a readable format and I would think that cpu cycles is not as much of a concern or file size. A utility to create a disk would only have to run through the conversion once to buffer a representation of the floppy disk (unless we are talking about a hard drive image of course). The file size to re-create a floppy disk is only going to be 2 to 3meg at the most (if thinking about a 1.2meg floppy with fortmatting info). The only difference I see in the sections that were described is that the first one encompasses the format info and the data. My description had the first one as being a big block that contained the two other sections as well as length and CRC info to verify data consistency. Adding author, etc to the big block would make perfect sense. As for GCR, that would have been covered under etc... I am not familiar with GCR, but I would guess that it has to deal at least with physical tracks and heads. In this case, a track would consist of whatever the format needed plus the data blocks required for the track. best regards, Steve Thatcher -----Original Message----- From: Jules Richardson <julesrichardsonuk(a)yahoo.co.uk> Sent: Aug 11, 2004 8:08 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, 2004-08-11 at 10:50, Steve Thatcher wrote: > 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. I haven't done any serious playing with XML in the last couple of years, but back when I did, my experience was that XML is not a good format for mixing human-readable and binary data within the XML structure itself. To make matters worse, the XML spec (at least at the time) did not define whether it was possible to pass several XML documents down the same data stream (or, as we'd likely need for this, XML documents mixed with raw binary). Typically, parsers of the day expected to take control of the data stream and expected it to contain one XML document only - often closing the stream themselves afterwards. I did end up writing my own parser in a couple of KB of code which was a little more flexible in data stream handling (so XML's certainly not a heavyweight format, and could likely be handled on pretty much any machine), but it would be nice to make use of off-the-shelf parsers for platforms that have them where possible. As you've also said, my initial thought for a data format was to keep human-readable config seperate from binary data. The human-readable config would contain a table of lengths/offsets for the binary data giving the actual definition. This does have the advantage that if the binary data happens to be a linear sequence of blocks (sectors in the case of a disk image) then the raw image can easily be extracted if needs be (say, to allow conversion to a different format) Personally, I'm not a fan of mixing binary data in with the human-readable parts because then there are issues of character escaping as well as the structure detracting from the readability. And if encoded binary data is used instead (say, hexadecimal representation) then there's still an issue of readability, plus the archive ends up bloated and extra CPU cycles are needed to decode data. Neither of those two approaches lend themselves to simply being able to use common command-line utilities to extract the data, either. I'm prefectly willing to be convinced, though :) > 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. So, first section is all the 'fuzzy' data (author, date, version info, description etc.), second section describes the layout of the binary data (offsets, surfaces, etc.), and the third section is the raw binary data itself? If so, I'm certainly happy with that :-) One aside - what's the natural way of defining data on a GCR floppy? Do heads/sectors/tracks still make sense as an addressing mode, but it's just that the number of sectors per track varies according to the track number? Or isn't it that simple? cheers Jules

21 years, 1 month

TKQ50 proms

by pete＠dunnington.u-net.com

I'm looking for ROMs (or ROM images would be better) for a TQK50 controller. The ROMs I want are 23-330E5 and 23-331E5. Can anyone help? -- Pete Peter Turnbull Network Manager University of York

21 years, 1 month

Let's develop an open-source media archive standard

by melamy＠earthlink.net

would you rather have one format that allows for easy data access and re-creation of media or only be able to re-create media and have a difficult interface in EVERY emulator that needs to access the data? From a usage standpoint, I think putting the burden on the emulators is not a reasonable approach. There are a variety of emulators available do not have to deal with track sector access of information. One uses an import command to bring ms-dos files in for example. To have to write an outside utility that has to know what the image file type is, know the physical layout of the disk, know how the OS accesses files on the disk just to retrieve file data is not a good idea. leave the OS access to the real platform or emulators that want to deal with actual tracks and sectors. best regards, Steve Thatcher -----Original Message----- From: "Dwight K. Elvey" <dwight.elvey(a)amd.com> Sent: Aug 11, 2004 3:05 PM To: cctalk(a)classiccmp.org Subject: Re: Let's develop an open-source media archive standard >From: spc(a)conman.org > >It was thus said that the Great Vintage Computer Festival once stated: >> >> HOWEVER, this makes it very difficult to use the imagefile on an emulator. >> To use the floppy disk example again, if the emulator wants Track 14 >> Sector 8 (or Block 417) but it has not been explicitly laid out in the >> imagefile because it was originally zeroes, then the emulator, if poorly >> designed, may crap out. > > Are you trying to create an archive format, or a format that is to be used >by emulators? I say skip the emulators and concentrate on archival >purposes. An emulator can then use the archive format to create a disk >image in whatever internal format it requires. > > Don't complicate the problem. I agree. We only need to provide a format that could be converted for a specific emulator, not necessarily one that can be conveniently read by an emulator. Dwight > > -spc (And don't try to become everything for everybody ... ) > > > >

21 years, 1 month

rarest computers. was: RE: Xerox Alto Restoration + Emulation

by Adrian＠beovax.co.uk

> -----Original Message----- > From: cctalk-bounces(a)classiccmp.org > [mailto:cctalk-bounces@classiccmp.org] On Behalf Of Jules Richardson > Sent: 02 August 2004 23:10 > To: General Discussion: On-Topic and Off-Topic Posts > Subject: Re: rarest computers. was: RE: Xerox Alto > Restoration + Emulation > > > On Mon, 2004-08-02 at 19:56, Vintage Computer Festival wrote: > > On Mon, 2 Aug 2004, Jules Richardson wrote: > > > Apple /// (possibly lots worldwide; there don't seem to be many > > > people this side of the pond who have seen one though) > > > > Very common. > > I figured they might be - just not in this part of the world, it seems > :-) Wonder how many were actually sold in the UK... At least 3 - you've got 1, I've got 2 and I bet Tony's got one somewhere... What might be uncommon these days is a *working* /// :) Cheers w

21 years, 1 month

Metal Case Northstar Horizon

by dwight.elvey＠amd.com

Hi I suspect that most metal cased N*'s were destined to be used in rack mount applications. Dwight >From: "Marvin Johnston" <marvin(a)rain.org> > >Actually, it would be nice to have pictures of all three Northstar >chassis styles. Right now, mine are all buried and I won't get a chance >to get near them for another month or so. But I'll keep my eyes open for >one of the beige ones now :). > >Adrian Graham wrote: >> >> > On Wed, 4 Aug 2004, Marvin Johnston wrote: >> > >> > > Someone mentioned some time ago a metal case instead of the >> > standard >> > > case for the Northstar Horizon. Can anyone confirm if they >> > did put out >> > > a computer in a metal case, and if so, (wishful thinking) how many >> > > they might have produced? I have one here in a powder blue >> > metal case >> >> There's at least one of the metal cased ones in 'storage' at Bletchley >> Park - IMSAI blue with an (I assume) aluminium front, 2 vertical floppy >> drives etc. Got a pic somewhere if anyone's interested, I can't attach >> it to this mail 'cos the list software will bin it. >

21 years, 1 month

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

>From: "melamy(a)earthlink.net" <melamy(a)earthlink.net> > ---snip--- > >The image file that you are discussing is only good as a "how to" to write >arbitrary data to arbitrary media. It is only good for creating a final >media image because the format being contemplated (mixing data into the >physical spec) will preclude the file from standing on its own. No, that is not true. The description of the physical data in the archive should be sufficient to recover the system side data. I can state this because the system side data is just a subset of the physical data. I recommend that the archive should include enough information to translate from the physical to the system but for archiving purposes, that is not absolutely necessary. It is not that hard to describe as part of the header what FM looks like. Still, if we restrict all archived information to include this, some unknown formats may not be archived because the person with the data doesn't know that format. It is better to capture the data first. It may also be that the only way that person has to capture the data is the output of a controller chip. The archiving should allow this as well ( more in the format the Steve would like it all to be in ). This file could later be combined with the more physical information when that was available, just as a archive file that originally had only physical information could be appended with the data as seen by the system. What this means is that some of the archived files may not be directly useable by Steve and his tools without some more in depth knowledge about the encoding use. It doesn't make it impossible to use, just difficult. Dwight >I was >proposing identifying data blocks as files if that is what they were. The >data blocks would have been sequential and trivial to retrieve. That is >hardly what I would call defining a file system as part of the image file. > >best regards, Steve Thatcher >

21 years, 1 month

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

>From: "Roger Merchberger" <zmerch(a)30below.com> > >Rumor has it that Vintage Computer Festival may have mentioned these words: >>On Wed, 11 Aug 2004, Steve Thatcher wrote: >> >> > If we create a physical description only and do not abstract the data >> > then any emulator must understand the OS file structure in order to >> > retrieve any internal file representation. > >I don't wanna sound like a doofus, but: > >So? > >> My idea would make the file >> > re-creation simple in that the xml image file would be parsed for the >> > actual file data that an emulator would need. This makes the emulator >> > easier. >> >>You're describing an imagefile that contains a filesystem image, rather >>than, say, a disk image. This can be accomodated in the spec, but it's a >>different type of image than what we've been discussing. > >It could be accommodated, but why should it when it would be easier for >someone to build a converter into an emulator image file? > >This spec (as far as I understand it) is going to be read-only anyway - >this is for archiving after all. What happens when the emulator tries to >rewrite the disk image (say, from saving a modified file)? What will happen >to the original archive? Hi I don't see this as being an issue. Once one knew how to decode the information for such applications that wanted to extract the data, one could import information into the image. It would of course require some knowledge of the data structures used by that system. It would have to know how to resolve things like logical interleaving and allocating space by the allocation methods. > >>It's up to emulator writers to read the spec and adapt to it. > >Bam. That hit the thumbnail right on the head. ;-) > >> We'll make >>the spec as flexible as possible, but first and foremost, the spec is >>intended to archive images of data media, and not to serve as a universal >>emulator image format (though it should be able to be used as such). > >I'd like to add that IMHO it should be "read-only" so the emulator doesn't >destroy the archive when it rewrites certain sectors and/or files. I don't see this as an issue. Once one has the archive file in hand, using it as a method to import external data is surely a valid application. The concept of read-only is just an OS flag that can be overwritten. Surely, someone doing this would rename the file or otherwise indicate that it has change. There is nothing anyone can do to restrict such actions. Why specify something that can not be enforced? We can recommend action. We can recommend that there be a field that indicated any change in the data of an archive and if that change is an overwrite of data or an enhancement of the data. Dwight > >At least that's my take on the deal... >Laterz, >Roger "Merch" Merchberger > >-- >Roger "Merch" Merchberger --- sysadmin, Iceberg Computers >Recycling is good, right??? Randomization is better!!! > >If at first you don't succeed, nuclear warhead >disarmament should *not* be your first career choice. > >

21 years, 1 month

Let's develop an open-source media archive standard

by melamy＠earthlink.net

the emails I received seem to be out of order... I believe what you are saying does satisfy the requirement that I have been proposing. There are different levels of physical to data mapping. I can see target platform code running that creates an image file and might actually send the XML directly out a serial port in zmodem for example. It could send it out as files or strictly embedded data. My point has been to make the file blocks available if the target has them just so the data can be extracted easily. best regards, Steve Original Message: ----------------- From: Vintage Computer Festival vcf(a)siconic.com Date: Thu, 12 Aug 2004 09:39:18 -0700 (PDT) To: cctalk(a)classiccmp.org Subject: RE: Let's develop an open-source media archive standard On Wed, 11 Aug 2004, Steve Thatcher wrote: > I am not assuming anything about the data. The usual use is to have > files... in the case of a paper tape emulator system used for CNC, the > disk structure may not resemble a normal file structure. It still > contains one or more blocks of data. you can apply whatever name to that > you want to. The boot sector on a cp/m 8" disk doesn't have a name, but > it is a block of data that is separate from everything else. Personally, > I would want to be able to "read" the boot sector and potentially even > write it back to an image file. It really doesn't make a difference > whether you access track 0 and sector 1 or a data block inside the image > file that contains the boot code. I see what you're saying now. I suppose another potential format that can be incorporated into the spec is a file-based format, where blocks or "files" are represented inside the archive. I can see this being useful for two purposes: 1) Imaging the filesystem from a medium (as opposed to the medium itself) 2) Incorporating code along the lines of what Dwight has been suggesting that knows how to do special processing of the image it is contained in. The code can be extracted and poked into memory using a very simple algorithm that possibly can be described in comments in the image file. I did suggest that the spec be able to image filesystems in a previous message. I think this comes close enough to what you are describing. It can be modified to also be able to indicate "blocks of data". These blocks could be given an identifier--a name, number, whatever; it doesn't matter, as long as it's an ASCII-representable string--and then extracted >from the image file as needed. Does this satisfy you, Steve? :) -- 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 ] -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ .

21 years, 1 month

RESCUED: pristine systems (DEC)

by waltje＠pdp11.nl

All, Just to let you know I followed up to Lyle's message, and went to see those guys (with Lyle) to see what is there. I am going in there tomorrow morning, and will save the systems from the oven. Basically, we have: - MicroVAX 3600 with RA82 (my new baby ;-) - extra rack filled with 6 pcs RA92 - Cipher magtape unit, frontloader (not in rack) - two VAX 4000(-500A) systems - a stack of BA42 storage expanders with various drives - a stack of MicroVAX 3100 -M38 and -M76 systems - two what seem to be DECsystem 5500 systems - one more VAX 3600 .. and some little things. If you have an interest in any of this (cept the 3600- tis mine!) please contact me off-list so we can work something out. Warning: RA92 dont ship well. This means that it will probably be pickup only, sorry. --f

21 years, 1 month

He shoots... he scores!

by jwest＠classiccmp.org

Just obtained an M4 Data tape drive, model 9914 (800/1600/3200/6250)... just pulled from working service...desktop enclosure... $50 bucks :) I believe it's Differential, not single ended. I haven't kept up with PC technology (hooking this to a PC). Is this older Differential the same as LVD? I believe it had a centronics 50 pin connector labeled "differential". I'm wondering what SCSI card I can use with this... Adaptec 2940? Jay

21 years, 1 month

← Newer
1
...
34
35
36
37
38
39
40
...
67
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 August 2004