test-drb August 2004

test-drb@ccmp.vtda.org

283 participants
661 discussions

Let's develop an open-source media archive standard

by RCini＠congressfinancial.com

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

8" floppy project

by dwight.elvey＠amd.com

Hi I sure that there was a FIG-86 listing done( would run on a 8088 ). There is also a large Forth that runs under DOS called FPC that is available over the net. For those that want to create there own smaller '86 Forth, there is a tool called TCOM ( by the same author ) that creates COM files. Since these are just code, they can be made to work on any '86 compatible platform. With minor changes, any target processor can be used( I've used it to create 8051 and Z80 code ). As I recall, the release comes with a number of examples of targeting for other machines. It was mentioned that a Forth could be as small as 32K. I've done quite a few that run in less that 8K of space ( 6K ROM and 2K RAM ). If one doesn't need the interpreter and compiler, 2K systems are quite practical for many applications. These are often done as tethered systems where something like a PC has the compiler and interpreter. The application machine only needs a way to read/write memory, execute and break execution. Dwight >From: "Stan Barr" <stanb(a)dial.pipex.com> > >Hi, > >ben franchuk <bfranchuk(a)jetnet.ab.ca> said: >> Tony Duell wrote: >> >> > Cheating a bit, but how about FIGforth? I believe it is truely public >> > domain, and as it runs on the bare metal, it could be claimed to include >> > the OS. I assume there was/is a version of the 8088. >> >> Yes, but try and find it today. Fig forth is for the 8080 and 6502 with I/O >> supplied by the user and ASM source. While I suspect you can get a >> version for the 8088 I don't expect you can get the source for it. >> Read keyboard, test keyboard ready, print to screen, read disk block, >> write disk block I think is all that is needed. >> Ben. > >Versions of FIGForth were available for quite a few processors. >I've got it running on simh emulating a PDP-11 and I'll copy it >to my Micro 11/73 as soon as I can persuade it to read floppys >written by putr. I'm running it under RT-11 but it can be compiled >to run stand-alone. > >It's quite possible that FigUK may have a FIG listing in their library >and I've possibly got a TRS-80 version somewhere. >-- >Cheers, >Stan Barr stanb(a)dial.pipex.com > >The future was never like this! > > >

20 years, 4 months

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

Hi Again, these are archive files. First preserve the media information. If ones wants, one can add other features. Emulators that don't provide some level of I/O interface at a low level usually don't work well for all programs. Emulators should as a minimum, provide a BIOS level interface ( if such exist ). Even this may not be low level enough. If someone writes an emulator that sees things at such a high level as simply files, it will most likely be useless for anything but the simplest programs that could have run on almost any platform. None of the emulators that I've used so far have been at such a high level of I/O. They have all understood drive, track and sector. If you wish to create such an emulator, you can alway post process the archive data ( once ) into whatever format is convenient. There is no particular reason to make archive files emulator friendly. As I've proposed, adding built in language definitions, one could add special purpose functions to do things like extract files based on directory entries. Even if not directly used, existing as source in the archive could provide the emulator writer the methods needed to do such them selves. I'm not saying that we should specifically restrict such from being in the archive file, just that I still don't see why a proper emulator would require such. IMHO Dwight >From: "Steve Thatcher" <melamy(a)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 ... ) >> >> >> >> > > > >

20 years, 4 months

Anyone need greenbar paper?

by zmerch＠30below.com

Just for grins, I went to google & typed in "greenbar paper" - and the 3rd or 4th link was this: http://www.business-supply.com/dept/2005280/sparco-1-2-green-bar-computer-p… They have 18 & 20 lb. greenbar paper, 8.5" and 11" deep, narrow & widecarriage (in each) and they even carry carbonless 2-part! Prices range >from $33/carton to $90/carton. Dunno if the prices are any good or not, but I did notice their "over $25 order gets free shipping" banner prominently displayed - I'm sure shipping this schtuff ain't cheap, so it might be a decent deal... Me? Don't need it... even all my dot-matrix printers had cut-sheet feeders on 'em... ;-) =-=-=-=-= That said, what I *have* been looking for (and google turned up nothing the last 3 times I checked) is a set of: Greenbar Bedsheets. I'd doubt they're still made, and it seems they weren't that popular when they were, as they certainly didn't make a big mark on google or history, it seems. Ah well... one can dream, right? Laterz, Roger "Merch" Merchberger -- Roger "Merch" Merchberger --- sysadmin, Iceberg Computers zmerch(a)30below.com Hi! I am a .signature virus. Copy me into your .signature to join in!

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 realize that the idea is to create a format to make re-creation >of media possible for a variety of platforms. We can certainly do >that and have its only function be to maintain a physical data format. >My added idea is that the data and the formatting be separated so >that a simple utility on a non-target platform could extract data >from the image file. > >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. 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. No, this is to archive the disk, not to make life easy for emulators. Again, you assume that the data is files. Also, anyone making such an emulator will surely know how to find files ( if they exist ) in an image of the disk. Most emulators include the BIOS and such. The emulator that we have in the H8 group simply uses the BIOS code and the boot code from the disk to find file ( as it should ). It just needs raw data. The emulator I/O is just tracks and sectors, not files. >To retrieve a file from the physical layout that it at the end of this >message, >the emulator must know the actual disk format that is used on >the target system (the one the image file was made for). I have seen >cp/m systems where the actual physical sectors were sequential on disk >and the OS file sector was actually virtual to increase speed. Not my >idea of the way to do it. It is much easier to make the physical >sectors slewed so that a physical sector is a file sector. These >are the types of issues you will have to overcome if an emulator >must totally understand each and every file system for a cp/m >version for example. Like I said, the archive file can include sufficient information to extract the data in any form that you'd like but it must as a minimum be able to recreate the physical disk. It may take some human to actually make the physical media generator but the data in the file should be sufficient to do that. This is not an easy task and goes beyond simply finding files in the raw data. Dwight > >Sellam, let me know if you would like to discuss this via telephone > so I can convery the idea that I am proposing. > >best regards, Steve Thatcher > >-----Original Message----- >From: Vintage Computer Festival <vcf(a)siconic.com> >Sent: Aug 11, 2004 3:00 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 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. > >That is the point, really. What we are attempting to do is describe as >faithfully as possible a physical media with logical data in a purely >logical form. The goal would be that the physical media could be >re-created from the imagefile if need be. The parameters of the physcial >media are specified so that this can be possible. > >> 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. > >I'm not quite understanding you here. Or maybe I am. An image in the >format shown below could be read by any emulator. Making sense of the >data with respect to that emulator is a different issue altogether, but it >does make it possible for, say, a Northstar Horizon emulator to load up an >Apple ][ disk image and then try to access it. > >Anyway, I don't think I am quite getting the point you are trying to make. > > >> <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> > >-- > >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: "Vintage Computer Festival" <vcf(a)siconic.com> ---snip--- >> >> or E5h? (fill byte for "no data" on CP/M formatting) >> or F6h? >> rather than "leave out" any sections that are just zeroes, >> put in a tag that says "x 00's", "x E5's", etc. > >Well, sure. But then I went on to imply that this method has problems >(one of which you just pointed out). > >Still, it bears consideration. > Hi Using the Postscript like concept, one would have a compactor word defined earlier in the file such that simple syntax like: EXPAND 512 E5 would be able to create a block of 512 E5's Of course one might want to keep a consistant radix like: EXPAND 200 E5 But that is not neccessary if the word EXPAND was first defined as such. Also such things as copy protection where a sector size has been changed on a track might be encoded as: SECTOR_SIZE 512 SECTOR_DATA 0 xxx..xxx SECTOR_SIZE 256 SECTOR_DATA 1 xx....xxx etc. The Archive file could include a simple glossary of the externally defined words that are in common use while still being internally extended to cover special cases. Dwight

20 years, 4 months

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

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

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 Wed, 11 Aug 2004, Dwight K. Elvey wrote: > >> One thing that could be done but I'm sure many will think >> I'm crazy. If the files contained OpenBoot source code to describe >> the data, one can then create almost anything one wants. > >I'm not familiar with OpenBoot. Can you explain this a bit more? Hi OpenBoot is the coding method used to bring up Sun workstations. It is normally used to interpret byte codes stored in the ROMs of various boards that plug into a SUN box. The idea is that the board configures itself by executing a non-platform dependent code. The platform supplies the information, such as where the next avaialble address space is and the board then allocates what it needs. One doesn't need to encode as byte code because there is also and interpreter. This is the part I think is most valuable. Unlike XML, Forth like languages are truly extendable to a greater degree. The richness of the primitives is what counts here. There is also the fact that even a mediocre programmer can implement a Forth like interpreter where as something like XML is easier to read but because it contains higher level syntactical rules needs a more complicated interpreter. The problem is that in the future, one needs to provide the simplest method of describing that can be implemented the easiest. Forth like interpreters follow simple rules: 1. Every thing that is separated with white space is a word. 2. As one comes across a word, left to right, one executes it. Forth adds one more step that I don't necessarily recommend. If it comes to a word that it doesn't understand, it tries to read it as a number. I believe that this is not necessary. The advantages are such that most any form of encoded data ( in ASCII ) can follow. The file itself can then convert to other formats. Things like simple compaction can even be added. > >> We need to remember that what normally comes out of a floppy >> controller chip is not the actual data on the disk. The information >> on the disk is a more complex. It contains things like special >> marks for indexing, headers and even errors. These need to >> be represented as well. We need to be looking at capturing the >> raw data from the disk. And at methods of post processing this >> to a form similar to what comes from the floppy controller. > >There are multiple levels at which someone may want to archive a medium. >There's the physical level, as you describe above. Then there's the level >in between physical and logical, which is, to use the example of floppy >disks again, tracks and sectors. And then there's the logical level which >is an actual filesystem with a directory and filenames, etc. > >This spec should be designed to be able to handle all three types >simultaneously within the same image file. Agreed. > >What I mean is that it might be useful to have (to use a floppy disk as an >example again) most of the disk encoded in a track/sector representation, >but then have one particular track encoded at a bit level, because perhaps >it contains special signatures that are part of a copy protection scheme. >If the image is ever used to re-create the original physical disk, the >binary data will be essential if the disk is going to actually be expected >to work (unless the copy protection scheme is removed at that point). Yep Dwight > >-- > >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: "Vintage Computer Festival" <vcf(a)siconic.com> > >On Wed, 11 Aug 2004, Dwight K. Elvey wrote: > >> 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 > >Sure. You can always take the imagefile and process it into a binary file >that you then upload to the machine. > >I am not liking the concept of mixing ASCII and binary. I'm not proposing the have raw binary. I agree that it all should be in ASCII. What I'm talking about here is just the data as compared with all of the actual information related to the format of the transitions on the disk surface. The archive needs both or an easy way to separate them. Emulators only need the data where as recreating a disk needs much more information. Dwight ---snip--- >Sellam Ismail Vintage Computer Festival

20 years, 4 months

What is it? Prometheus Versacard

by rigdonj＠cfl.rr.com

Anybody know what this card is? It appears to be for an Apple II and has two N-cell battery holders on it and a 20 pin and a 26 IDC header along the top edge. Joe

20 years, 4 months

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