>From: "Vintage Computer Festival" <vcf_at_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 ]
>
>
Received on Wed Aug 11 2004 - 16:37:42 BST