27 May
2000
27 May
'00
9:52 a.m.
> This is a good start. The header should include a
byte that contains a
> flag indicating the status of the sector (good, bad, etc).
Other things that are 'missing' from that
header are whether the sector
is single or double density, what sort of Data Marker came before it
(some TRS-80 disks use strange data markers, and just about all TRS-80
M1/M3/M4 OSes use deleted data markers on the directory track).
Then there are some *real* oddballs, such as disks with 18 or 12 or 9
bits per byte.
It's very, very common for double-density CP/M disks to have the boot
sector - and in some cases the first few tracks - in single density.
For these odd formats, I just record the waveform from the head
for each track for a couple of revolutions, just to make real
sure that I'm not missing anything :-).
Tim.
27 May
27 May
10:19 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 1487 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000527/04b9d230/at…
29 May
29 May
6:19 p.m.
On Sat, 27 May 2000 CLASSICCMP(a)trailing-edge.com wrote:
It's very, very common for double-density CP/M
disks to have the boot
sector - and in some cases the first few tracks - in single density.
Broderbund came out with an 18-sector format for the Apple ][, but in
order for the disk to be readble the first track is encoded as standard
16-sector format.
This 18-sector format provided two benefits: 1) increased storage space
and 2) a form of copy protection.
For these odd formats, I just record the waveform from
the head
for each track for a couple of revolutions, just to make real
sure that I'm not missing anything :-).
What do you record it to? I don't think this is a very good solution for
mass archiving and distribution.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
6:50 p.m.
Let's start sort of from scratch here.
So far we have the following (high level) criterion for a disk archive
standard:
1. Host computer type (2 bytes allowing up to 65536 models to be
specified)
2. Track format (host computer specific)
3. Sector format (single-density, double-density, etc)
4. Sector data format - this will specify what format the archived sector
is in (raw data? logical bytes?)
5. Bytes per sector
6. Bits per byte
What else?
I will be the first to say that this is may not be very logically
structured. What I am attempting to do is give a suggestion for a high
level header that identifies what each chunk of data in the archive can
represent. In this way, disks that are formatted with several different
formats can be described.
I think what this may evolve into is a Data Definition Language. The DDL
will be encoded along with the disk data and will describe the format of
the data on the disk as it is being read.
This comes back to the fact that utilities will have to be written for
each computer we decide to support (I assume it will be all of them) to
both read and write native diskettes. I also assume the data will be
passed between the archive host and the target machine via serial link?
In case my mostly random thoughts above don't make sense, here is what I
would have in mind for the Apple ][:
The disk can be read in either standard, logical format (13 or 16 sectors
per track, 256 bytes per sector) or "raw" format (raw disk bytes are read
from the track). There would also have to be format
descriptions for
specially formatted tracks such as the 18-sector type I mentioned.
As for reading the raw bytes, the Apple ][ had what were called
"synchronization" bytes, which were 10 bits long, the two extra bits being
used to synchronize the head with the start of the track. I could go into
a technical discussion of this but would have to pull out some reference
material to refresh my memory of how it all worked. Anyway, these bytes
would have to be specially encoded in the archive.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
30 May
30 May
2:54 a.m.
On Mon, 29 May 2000, Sellam Ismail wrote:
Let's start sort of from scratch here.
So far we have the following (high level) criterion for a disk archive
standard:
1. Host computer type (2 bytes allowing up to 65536 models to be
specified)
2. Track format (host computer specific)
3. Sector format (single-density, double-density, etc)
4. Sector data format - this will specify what format the archived sector
is in (raw data? logical bytes?)
5. Bytes per sector
6. Bits per byte
What else?
Hmmm...
Hard sector vs. SOft sector (for ctrlr emulations)
Interleaving - yes/no/offset value
Sectors per track
# of Tracks
Surfaces (heads) per cylinder
...?
-jim
---
jimw(a)computergarage.org || jimw(a)agora.rdrop.com
The Computer Garage - http://www.computergarage.org
Computer Garage Fax - (503) 646-0174
3:17 a.m.
WARNING: There's evidence of "creeping featurism" here. That's what
kills
most standards, or at least manages to make them useless.
Example: if your goal is to make the medium universally readable, why
bother to put a source identifier into it? Who cares what system wrote it,
so long as it can be read by any machine capable of dealing with the
physical medium. It seems MUCH more important to choose a medium that's
universally available and useable by a large number of systems.
This would rule out such things as tape, whether paper or mylar/magnetic,
diskettes, and most other magnetic media. The most important feature is
ready availablility, right? If you can't go down to the 7-11 and buy it,
it's not readily available, now, is it:?
If you're defining an exchange medium, it doesn't matter whether your 1970's
computer had that medium back when it was a pup. It doesn't matter that
they used the little dectapes then if you can't go to CompUSA and buy them
now and in the future.
If you consider genuine requirements, you'll probably not end up with
magnetic media, though portable hard disk might be worthy of consideration.
You'll probably end up with something that requires nearly everyone to build
an interface of some sort just to be able to use it. That's the problem
you're trying to solve, doncha know ... If the guys who designed the systems
had provided for this sort of interchange, you'd not have to solve the
problem now.
Dick.
----- Original Message -----
From: James Willing <jimw(a)agora.rdrop.com>
To: <classiccmp(a)classiccmp.org>
Sent: Tuesday, May 30, 2000 8:54 AM
Subject: Re: Defining Disk Image Dump Standard
On Mon, 29 May 2000, Sellam Ismail wrote:
> Let's start sort of from scratch here.
>
> So far we have the following (high level) criterion for a disk archive
> standard:
>
> 1. Host computer type (2 bytes allowing up to 65536 models to be
> specified)
> 2. Track format (host computer specific)
> 3. Sector format (single-density, double-density, etc)
> 4. Sector data format - this will specify what format the archived
sector
is in (raw
data? logical bytes?)
5. Bytes per sector
6. Bits per byte
What else?
Hmmm...
Hard sector vs. SOft sector (for ctrlr emulations)
Interleaving - yes/no/offset value
Sectors per track
# of Tracks
Surfaces (heads) per cylinder
...?
-jim
---
jimw(a)computergarage.org || jimw(a)agora.rdrop.com
The Computer Garage - http://www.computergarage.org
Computer Garage Fax - (503) 646-0174
3:31 a.m.
Adding Jim Willing's input to the fray:
1. Host computer type (2 bytes allowing up to 65536 models to be
specified)
2. Hard/soft sector flag
3. Number of tracks
4. Track format (host computer specific)
5. Sector format (single-density, double-density, etc)
5. Sector data format - this will specify what format the archived sector
is in (raw data? logical bytes?)
6. Sectors per track
7. Bytes per sector
8. Bits per byte
I think the measure of usefulness of this standard will be if it can
easily define the format of a standard disk from most any platform as well
as being able to handle different exceptions.
What I mean is, can one take a regularly formatted diskette from any
computer that has T number of tracks and S number of sectors per track and
B number of bytes per sector and describe it with the same header as a
disk with some totally hardware specific formatting?
The Archive Description Header should be able to easily describe standard
disk formats so as to be easily implementable across multiple platforms,
while also being powerful enough to describe exotic platform
specific formats that would allow reconstruction of an original disk back
to the original platform.
The reading and writing of the disks will obviously have to be done with
applications running on the actual hardware, that will be able to analyze
the format of the disk and pass information about any special formatting
to the machine where the archive is to be processed and stored.
We are NOT creating a description for hardware that can read any disk
format ever put out. That is wholly unfeasible. We are creating a
software standard that will allow the contents of a diskette to be
universally defined in a manner that allows complete reconstruction of a
diskette on the original platform.
So for disks that cannot be read by PC hardware (which is what I currently
consider to be "universal") utilities will have to be created on the
original platform to both read and write the diskette. The best example
would be the Apple ][. A utility will have to be written for the Apple ][
that can read the raw disk data, analyze the contents, and return the
sector (or track) data back to the "universal" host over a serial port
along with a description of how that data was formatted on the disk. That
description will then get encoded into the Archive Description Header.
Which leads me to this thought: is preserving the actual format of the
disk even necessary for posterity? Is the goal here to be able to make
exact copies of the disk to be able to run on the hardware well into the
future? Or is the actual data itself more important?
This is getting too complicated, but what I mean is, instead of trying to
archive an oddball format from, say, the Apple ][ that was designed to
thwart copying of the disk and making archiving it a challenge, would it
be better to just take the software contained on that disk and convert it
to a standard format that can be more easily archived?
Is there historical value to preserving the original format? I think so.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
10:13 a.m.
1. Host computer type (2 bytes allowing up to 65536
models to be
specified)
2. Hard/soft sector flag
3. Number of tracks
4. Track format (host computer specific)
5. Sector format (single-density, double-density, etc)
5. Sector data format - this will specify what format the archived sector
is in (raw data? logical bytes?)
6. Sectors per track
7. Bytes per sector
8. Bits per byte
You like to have a standard for data description in relation to medias ?
So, why going for a stone age aproach like fixed numbers and fields ?
Why not a tagged format ?
And if we talk about a tagged format, XML should be first choice.
In fact, some time ago I did think about almost the same idea.
I did develop a first draft of an XML based scheme to describe
a mainframe storage situation, to run possible emulators from
a complex but detailed defined storage setup.
This format can be used also to describe data structured of
simple micro computer media. At the moment the DTD is only
defined for the data structures - I have not started to
define meta informations vor formats and hardware (like
your soft/hard sectored flag).
I'll post the DTD and two sample configurations in a seperate
mail. The first one to recognize the Disk Format described in
the second example (And names the content) will get 'prefered
helper' state during eVCF 2.0 :)) Or something similar...
Basicly the structure is defined as:
Channel/Device/Media/Head/Track/Block/Data
Chanel/Device ma be omited.
Instead of Data, Raw may be used to descrive a 'Physical' content
(like Nibble data, as needed to store copy protected data).
Raw may also exist not only on Block level, but also on
Track, Head or Media Level.
Data itself may be encoded in different ways, either Binary,
or as 'Hex', or in classic (readable) loader formats, to allow
easy transmission of these files across system boundries.
Please see the DTD for details.
Decoding a XML file is not not a big difference to a fixed format,
but _way_ more flexible.
Gruss
H.
P.S.: The DTD is named CCDD for ClassicComputerDeviceData
--
VCF Europa 2.0 am 28./29. April 2001 in Muenchen
http://www.vintage.org/vcfe
http://www.homecomputer.de/vcfe
2:56 a.m.
I never understood why the double density CP/M diskettes were not bootable,
and why "distribution-standard" diskettes had to be bootable. These are two
different features, and what's important about the "standard" is not that
it's bootable but that it's defined so as to be universally readable.
The thing that made 5-1/4" "standard" diskettes unachievable back in the
CP/M days was that people couldn't let go of the notion that every diskette
had to be bootable. Frankly, I got fine mileage out of diskettes which
couldn't be booted, yet I never had a problem booting up.
It's silly to mix these two desirables. They're not bound together. Let's
not require something that's counterproductive as this is. If you make a
distribution standard for media, then use it for distribution. Let the OS
determine what's suitable for booting.
Dick
----- Original Message -----
From: Sellam Ismail <foo(a)siconic.com>
To: <classiccmp(a)classiccmp.org>
Sent: Tuesday, May 30, 2000 12:50 AM
Subject: Re: Defining Disk Image Dump Standard
Let's start sort of from scratch here.
So far we have the following (high level) criterion for a disk archive
standard:
1. Host computer type (2 bytes allowing up to 65536 models to be
specified)
2. Track format (host computer specific)
3. Sector format (single-density, double-density, etc)
4. Sector data format - this will specify what format the archived sector
is in (raw data? logical bytes?)
5. Bytes per sector
6. Bits per byte
What else?
I will be the first to say that this is may not be very logically
structured. What I am attempting to do is give a suggestion for a high
level header that identifies what each chunk of data in the archive can
represent. In this way, disks that are formatted with several different
formats can be described.
I think what this may evolve into is a Data Definition Language. The DDL
will be encoded along with the disk data and will describe the format of
the data on the disk as it is being read.
This comes back to the fact that utilities will have to be written for
each computer we decide to support (I assume it will be all of them) to
both read and write native diskettes. I also assume the data will be
passed between the archive host and the target machine via serial link?
In case my mostly random thoughts above don't make sense, here is what I
would have in mind for the Apple ][:
The disk can be read in either standard, logical format (13 or 16 sectors
per track, 256 bytes per sector) or "raw" format (raw disk bytes are read
from the track). There would also have to be format descriptions for
specially formatted tracks such as the 18-sector type I mentioned.
As for reading the raw bytes, the Apple ][ had what were called
"synchronization" bytes, which were 10 bits long, the two extra bits being
used to synchronize the head with the start of the track. I could go into
a technical discussion of this but would have to pull out some reference
material to refresh my memory of how it all worked. Anyway, these bytes
would have to be specially encoded in the archive.
Sellam International Man of Intrigue and
Danger
--------------------------------------------------------------------------
-----
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
2:51 a.m.
On Tue, 30 May 2000, Richard Erlacher wrote:
It's silly to mix these two desirables.
They're not bound together. Let's
not require something that's counterproductive as this is. If you make a
distribution standard for media, then use it for distribution. Let the OS
determine what's suitable for booting.
Dick, once again with raging gradeur you have brought forth an entirely
non-sequitur point of issue to the discussion at hand. Assuming you did
understand what this thread is about, how does one separate the operating
system from the programs and data on the disk (across disparate platforms)
to be able to make a determination as to what becomes part of the archive?
No, I really don't want to hear your reply, but something tells me you
have nothing better to do anyway.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
7:24 a.m.
It must be tough to process such difficult issues with a single flip-flop .
. .
See my comments below, plz.
Dick
----- Original Message -----
From: Sellam Ismail <foo(a)siconic.com>
To: <classiccmp(a)classiccmp.org>
Sent: Tuesday, May 30, 2000 8:51 AM
Subject: Re: Defining Disk Image Dump Standard
The way you separate the operating system from the executables is by never,
Never, NEVER, mixing them on the same medium, particularly if it's intended
for dissemination. If the platforms are disparate, you certainly don't need
to distribute the OS. A generalized and "universal" medium has to be just
that. Keep in mind that what equipment was available back in the old days
when these old machines were relevant doesn't matter. What you need is a
way to put the material you wish to convey to some other party on a medium
which is likely to be readable today and in the future by the intended
destinee.
I'd not be surprised to find that every diskette you own has an OS on it,
else you wouldn't frame this issue as you have. For you, though not for
anyone else, I'd recommend you get a chisel and put your distribution data
on a stone slab. Most everyone else is smart enough to figure out how to
avoid writing the OS to a diskette or tape. I'd have thought you had run
into the problems with media exchange long enough ago to realize that since
it's YOUR computer, YOU can tell it what to write to the medium, just as YOU
can tell it how that material is to be organized and how it is to be
represented.
IIRC YOU were the primary opponent when this sort of issue was raised with
respect to documentation archival. You opposed the common and virtually
universally accepted file format used throughout the industry for exchange
of documents. You wanted to reduce everything to bitmapped images 100x as
large and 1% as easy to use as PDF's, just so you didn't have to use a PC to
process the data into something your odd-ball system could display. Now you
want to do something else that's quite similar.
I'm just raising the issue that not every system has floppy disks or mag
tape, and, certainly fewer have both. Then there's the issue of how to read
them on system A when written on system B. The latter's inherently
solvable, but if you want to archive data about or useful with a given OS,
you don't have to write the data to a medium capable of reading or
interpreting the OS image. The primary concern is finding a medium that's
available so whoever wants to participate in the process can get it here,
now, and in the future, and not by digging in a dumpster. That rules out
floppy disk, mag-tape, and a lot of other media, since their longevity on
the market is coming to an end. If you don't deal with that issue, you'll
have to start over again with it in another 5 years. The other warts you
design into the exchange process won't matter if you can't rely on getting
the physical media and both generating and accepting it at each end of the
process.
As far as I'm concerned, until you resolve the media issue, the format of
the content is a non-issue. Have you tried to read an LS120 diskette on
your Apple-][ lately?
On Tue, 30 May 2000, Richard Erlacher wrote:
> It's silly to mix these two desirables. They're not bound together.
Let's
> not require something that's
counterproductive as this is. If you make
a
> distribution standard for media, then use it for
distribution. Let the
OS
determine
what's suitable for booting.
Dick, once again with raging gradeur you have brought forth an entirely
non-sequitur point of issue to the discussion at hand. Assuming you did
understand what this thread is about, how does one separate the operating
system from the programs and data on the disk (across disparate platforms)
to be able to make a determination as to what becomes part of the archive?
No, I really don't want to hear your reply, but something tells me you
have nothing better to do anyway.
It's just as I said before: You simply want to transmit, but you don't
want
to receive.
Sellam International Man of Intrigue and
Danger
--------------------------------------------------------------------------
-----
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
8:17 a.m.
On Tue, 30 May 2000, Richard Erlacher wrote:
The way you separate the operating system from the
executables is by never,
Never, NEVER, mixing them on the same medium, particularly if it's intended
for dissemination. If the platforms are disparate, you certainly don't need
Ok, Mr. Wizard. Build a time machine, travel back in time, and urge all
the various computer manufacturers to never, NEVER mix their OS with the
rest of the program space on the disk. Fortunately, we are not trying to
revise the reality of our world, but are merely trying to deal with what
it has become, which is a much simpler procedure.
At this point I would say it's time for Dick's nap and be done with him
but it seems he has a few more hundred lines of useless spewage as usual.
when these old machines were relevant doesn't
matter. What you need is a
way to put the material you wish to convey to some other party on a medium
which is likely to be readable today and in the future by the intended
destinee.
Really? I thought we were trying to build a perpetual motion machine
here. Thanks for getting me back on track, Dick!
<senseless babbling expunged>
<more enigmatic blather deleted>
I'm just raising the issue that not every system
has floppy disks or mag
tape, and, certainly fewer have both. Then there's the issue of how to read
Well, correct me if I'm wrong, but I *THINK*, not sure, but I THINK, we
were, in fact, talking about creating floppy disk archives. Correct me if
I'm wrong, Dick.
them on system A when written on system B. The
latter's inherently
solvable, but if you want to archive data about or useful with a given OS,
you don't have to write the data to a medium capable of reading or
interpreting the OS image. The primary concern is finding a medium that's
Dick, why do you propose problems that you just end up arguing against?
Are you even aware that there are other people on this mailing list that
you are communicating with, or do you think this entire conversation is
going on in your head? No one ever proposed what you are railing against
right now. Are you insane? No, really. I'm being serious. Do you
suffer from a mental condition?
<more worthless drivel ignored>
It's just as I said before: You simply want to
transmit, but you don't want
to receive.
No, Dick. The problem here is you are transmitting, then receiving it
yourself, getting angry at what you read, and then associating it with
whatever hapless fool happens to be in the vicinity at the moment, and
then blaming them for it.
EARTH TO DICK: GET A CLUE.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
9:55 a.m.
Just because system makers wanted to reduce the number of disks the sent out
with their systems doesn't mean that their mistake has to be repeated. Just
because they used to do it wrong, perhaps for a good reason (I'm sure they
thought economics made their reason good). If you're trying to send a bit
of information, and this is information, isn't it, you need merely find a
way to distribute the information. You don't need to include unnecessary
pieces of stuff that, in many cases, doesn't even belong to you.
Are you saying that you don't know how to write a diskette without including
the OS on it?
see other comments below, plz.
Dick
----- Original Message -----
From: Sellam Ismail <foo(a)siconic.com>
To: <classiccmp(a)classiccmp.org>
Sent: Tuesday, May 30, 2000 2:17 PM
Subject: Re: Defining Disk Image Dump Standard
Well, what it looked like was exactly that, a perpetual motion machine.
You'd perpetually be trying to deal with all the superflous information
included due to your inability NOT to include the OS on a diskette.
Well, I believe you're probably more worked up than I. I doubt floppies
will be around in 10-15 years, though they may be. However, if you don't
find a way to avoid this built-in obsolescence, you'll be solving this
problem again and again. I don't know what you're thinking about, but, the
use of mechanical media of a type that's already been around as long as
floppies, and, for that matter, other rotating media. Why not examine some
other alternatives?
What interested me about this thread was that a decision leading to as many
problems as it solved was beginning to emerge. What puzzles me is why it's
important that the originating system's identification data has to be
included in a file of information, probably otherwise unrelated to the
process of recording it. Once you have the means to read that data, it
becomes suprefluous, since all that's needed once you're able to read that
info is to figure out where the data block you're wanting to transmit begins
and ends.
If you want to be simple, you write absolutely nothing on the medium other
than what you want to pass along. So long as you choose a medium that will
be available later on when you want to use it, nothing could be simpler.
The key is to use a data format that is easily understood, either because
it's already a standard, or because you do things very simply by using one
file per diskette, in a compressed format that is easily specified or
standardized. With floppies, I don't know how you're going to use your
Apple][ to read a diskette from a Kaypro.
What's more, I don't know how you'll write a file with your PDP-5 such that
a MacIntosh can read it.
On Tue, 30 May 2000, Richard Erlacher wrote:
> The way you separate the operating system from the executables is by
never,
> Never, NEVER, mixing them on the same medium,
particularly if it's
intended
> for dissemination. If the platforms are
disparate, you certainly don't
need
Ok, Mr. Wizard. Build a time machine, travel back in time, and urge all
the various computer manufacturers to never, NEVER mix their OS with the
rest of the program space on the disk. Fortunately, we are not trying to
revise the reality of our world, but are merely trying to deal with what
it has become, which is a much simpler procedure.
At this point I would say it's time for Dick's nap and be done with him
Too late! I already had my nap.
but it seems he has a few more hundred lines of useless spewage as usual.
> when these old machines were relevant doesn't matter. What you need is
a
> way to put the material you wish to convey to
some other party on a
medium
which is
likely to be readable today and in the future by the intended
destinee.
Really? I thought we were trying to build a perpetual motion machine
here. Thanks for getting me back on track, Dick!
<senseless babbling expunged>
<more enigmatic blather deleted>
> I'm just raising the issue that not every system has floppy disks or mag
> tape, and, certainly fewer have both. Then there's the issue of how to
read
Well, correct me if I'm wrong, but I *THINK*, not sure, but I THINK, we
were, in fact, talking about creating floppy disk archives. Correct me if
I'm wrong, Dick.
> them on system A when written on system B. The latter's inherently
> solvable, but if you want to archive data about or useful with a given
OS,
> you don't have to write the data to a medium
capable of reading or
> interpreting the OS image. The primary concern is finding a medium
that's
Dick, why do you propose problems that you just end up arguing against?
Are you even aware that there are other people on this mailing list that
you are communicating with, or do you think this entire conversation is
going on in your head? No one ever proposed what you are railing against
right now. Are you insane? No, really. I'm being serious. Do you
suffer from a mental condition?
<more worthless drivel ignored>
> It's just as I said before: You simply want to transmit, but you don't
want
to receive.
No, Dick. The problem here is you are transmitting, then receiving it
yourself, getting angry at what you read, and then associating it with
whatever hapless fool happens to be in the vicinity at the moment, and
then blaming them for it.
EARTH TO DICK: GET A CLUE.
Sellam International Man of Intrigue and
Danger
--------------------------------------------------------------------------
-----
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
10:13 a.m.
New subject: DTD and examples for CCDD (6kB)
<?xml version="1.0" standalone='yes' ?>
<!DOCTYPE CCDD [
<!ELEMENT CCDD (VORSPANN?, META?, (CHANNEL* | DEVICE* |
MEDIA))>
<!ELEMENT VORSPANN (#PCDATA)>
<!ELEMENT META (#PCDATA | SYSTEM | OS)*>
<!ELEMENT SYSTEM (#PCDATA)>
<!ELEMENT OS (#PCDATA)>
<!ELEMENT CHANNEL (META?, DEVICE*)>
<!ELEMENT DEVICE (META?, MEDIA*)>
<!ELEMENT MEDIA (META?, (RAW | HEAD*) )>
<!ELEMENT HEAD (RAW | TRACK*)>
<!ELEMENT TRACK (RAW | BLOCK*)>
<!ELEMENT BLOCK (RAW | DATA*)>
<!ELEMENT DATA (#PCDATA)>
<!ELEMENT RAW (#PCDATA)>
<!ATTLIST CHANNEL
ID ID #IMPLIED>
<!ATTLIST DEVICE
ID ID #IMPLIED>
<!ATTLIST MEDIA
ID ID #IMPLIED
LFD CDATA #IMPLIED
SIZE CDATA #IMPLIED
FILLER CDATA #IMPLIED
FORMAT CDATA #IMPLIED>
<!ATTLIST HEAD
LFD CDATA #IMPLIED
SIZE CDATA #IMPLIED
FILLER CDATA #IMPLIED
FORMAT CDATA #IMPLIED>
<!ATTLIST TRACK
LFD CDATA #IMPLIED
SIZE CDATA #IMPLIED
FILLER CDATA #IMPLIED
FORMAT CDATA #IMPLIED>
<!ATTLIST BLOCK
LFD CDATA #IMPLIED
SIZE CDATA #IMPLIED
FILLER CDATA #IMPLIED
TYPE (DATA|HEADER|UNDEF) "DATA">
<!ATTLIST DATA
SIZE CDATA #IMPLIED
FILLER CDATA #IMPLIED
ENCODING (CHAR|BIN|SED|INTEL) "SED">
<!ATTLIST RAW
SIZE CDATA #IMPLIED
FILLER CDATA #IMPLIED
CONTENT (DATA|PYSICAL) "DATA"
ENCODING (CHAR|BIN|SED|INTEL) "SED">
]>
<CCDD>
<META>
Example for a tape mounted on Drive D0 on Channel 1.
</META>
<CHANNEL ID="C_1">
<META>
Standard type 1 channel
</META>
<DEVICE ID="D_D0">
<META>
T9G (6250bpi)
</META>
<MEDIA LFD="0" FORMAT="T6250">
<META>
First Tape in Device
</META>
<HEAD LFD="0" SIZE="36" FILLER="00">
<TRACK LFD="16" SIZE="16" FILLER="00">
<BLOCK TYPE="HEADER">
<DATA SIZE="80" ENCODING="CHAR" FILLER="
">VOL1TAPE001 BS2000 TSOS
4</DATA>
</BLOCK>
<BLOCK TYPE="HEADER">
<DATA SIZE="80" ENCODING="CHAR" FILLER="
">UVL1PRIVATE LABEL</DATA>
</BLOCK>
<BLOCK TYPE="HEADER">
<DATA SIZE="80" ENCODING="CHAR" FILLER="
">HDR1FILE1 00010001000100000102000102 000000BS2000</DATA>
</BLOCK>
<BLOCK TYPE="HEADER">
<DATA SIZE="80" ENCODING="CHAR" FILLER="
">HDR2U020480204841 00</DATA>
</BLOCK>
<BLOCK TYPE="HEADER">
<DATA SIZE="80" ENCODING="CHAR" FILLER="
">HDR3TSOS COMPLETE.FILE.NAME.OF.FILE1
0</DATA>
</BLOCK>
<BLOCK TYPE="DATA">
<DATA SIZE="2048" ENCODING="CHAR"
FILLER="�">NO REAL DATA INSIDE THIS BLOCK</DATA>
</BLOCK>
<BLOCK TYPE="HEADER">
<DATA SIZE="80" ENCODING="CHAR" FILLER="
">EOF1FILE1 00010001000100000102000102 000001BS2000</DATA>
</BLOCK>
<BLOCK TYPE="HEADER">
<DATA SIZE="80" ENCODING="CHAR" FILLER="
">EOF2U020480204841 00</DATA>
</BLOCK>
<BLOCK TYPE="HEADER">
<DATA SIZE="80" ENCODING="CHAR" FILLER="
">EOF33TSOS COMPLETE.FILE.NAME.OF.FILE1
0</DATA>
</BLOCK>
</TRACK>
</HEAD>
</MEDIA>
</DEVICE>
</CHANNEL>
</CCDD>
<CCDD>
<META>
This is another CCDD File for a FD of
<SYSTEM>XXXXX</SYSTEM> running under <OS>yyyy</OS>.
</META>
<MEDIA LFD="0" SIZE="2" FORMAT="GCR">
<META>
Floppy disk for xxxxxx
</META>
<HEAD LFD="0" SIZE="36" FILLER="00">
<TRACK LFD="16" SIZE="16" FILLER="00">
<BLOCK LFD="14">
<DATA SIZE="256" ENCODING="SED" FILLER="00">
</DATA>
</BLOCK>
<BLOCK LFD="15">
<DATA SIZE="256" ENCODING="SED" FILLER="00">
000000000000000000000000100E
</DATA>
</BLOCK>
</TRACK>
<TRACK LFD="17" SIZE="16" FILLER="00">
<BLOCK LFD="0">
<DATA SIZE="256" ENCODING="SED" FILLER="00">
04110F030000FE000000000000000000
00000000000000000000000000000000
000000000000007A0000000000000000
23010000231001000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
000000000000000380010000
</DATA>
</BLOCK>
<BLOCK LFD="15">
<DATA SIZE="256" ENCODING="SED" FILLER="00">
0000000000000000000000100F02C8C5
CCCCCFA0A0A0A0A0A0A0A0A0A0A0A0A0
A0A0A0A0A0A0A0A0A0A0A00001
</DATA>
</BLOCK>
</TRACK>
</HEAD>
</MEDIA>
</CCDD>
--
VCF Europa 2.0 am 28./29. April 2001 in Muenchen
http://www.vintage.org/vcfe
http://www.homecomputer.de/vcfe
7:01 a.m.
On Tue, 30 May 2000, Richard Erlacher wrote:
I never understood why the double density CP/M
diskettes were not bootable,
and why "distribution-standard" diskettes had to be bootable. These are two
different features, and what's important about the "standard" is not that
it's bootable but that it's defined so as to be universally readable.
But that is/was not always true! There were a number of 8" CP/M systems
that used bootable DD formats, and most all 5.25" CP/M systems were in a
bootable DSDD format.
8" SSDD:
Altos Avtek
Heurikon MLZ-90
Ithaca Intersystems
Octagon 8/16
Ohio Scientific Turbo
Tektronix 8
Vista A-800
8" DSDD:
Heath Magnolia
Heurikon MLZ-90
Ithaca Intersystems
MDS-80
Prolog APL-2
System Group 2800
W.J. Engineering
In the 5.25" bunch, the two obvious ones that immediately come to mind
as using the SD boot track are Osborne and Xerox.
- don
The thing that made 5-1/4" "standard"
diskettes unachievable back in the
CP/M days was that people couldn't let go of the notion that every diskette
had to be bootable. Frankly, I got fine mileage out of diskettes which
couldn't be booted, yet I never had a problem booting up.
It's silly to mix these two desirables. They're not bound together. Let's
not require something that's counterproductive as this is. If you make a
distribution standard for media, then use it for distribution. Let the OS
determine what's suitable for booting.
Dick
----- Original Message -----
From: Sellam Ismail <foo(a)siconic.com>
To: <classiccmp(a)classiccmp.org>
Sent: Tuesday, May 30, 2000 12:50 AM
Subject: Re: Defining Disk Image Dump Standard
Let's start sort of from scratch here.
So far we have the following (high level) criterion for a disk archive
standard:
1. Host computer type (2 bytes allowing up to 65536 models to be
specified)
2. Track format (host computer specific)
3. Sector format (single-density, double-density, etc)
4. Sector data format - this will specify what format the archived sector
is in (raw data? logical bytes?)
5. Bytes per sector
6. Bits per byte
What else?
I will be the first to say that this is may not be very logically
structured. What I am attempting to do is give a suggestion for a high
level header that identifies what each chunk of data in the archive can
represent. In this way, disks that are formatted with several different
formats can be described.
I think what this may evolve into is a Data Definition Language. The DDL
will be encoded along with the disk data and will describe the format of
the data on the disk as it is being read.
This comes back to the fact that utilities will have to be written for
each computer we decide to support (I assume it will be all of them) to
both read and write native diskettes. I also assume the data will be
passed between the archive host and the target machine via serial link?
In case my mostly random thoughts above don't make sense, here is what I
would have in mind for the Apple ][:
The disk can be read in either standard, logical format (13 or 16 sectors
per track, 256 bytes per sector) or "raw" format (raw disk bytes are read
from the track). There would also have to be format descriptions for
specially formatted tracks such as the 18-sector type I mentioned.
As for reading the raw bytes, the Apple ][ had what were called
"synchronization" bytes, which were 10 bits long, the two extra bits being
used to synchronize the head with the start of the track. I could go into
a technical discussion of this but would have to pull out some reference
material to refresh my memory of how it all worked. Anyway, these bytes
would have to be specially encoded in the archive.
Sellam International Man of Intrigue and
Danger
--------------------------------------------------------------------------
-----
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
7:20 a.m.
On Tue, May 30, 2000 at 12:01:30PM -0700, Don Maslin wrote:
But that is/was not always true! There were a number
of 8" CP/M systems
that used bootable DD formats, and most all 5.25" CP/M systems were in a
bootable DSDD format.
I always figured the reason for the restriction was dumb boot PROMs, which
only know how to do programmed I/O to the FDC, and 8" DD comes in too fast
for typical 8-bit CPUs of the time to handle with PIO. If the boot PROM on
a particular system is smart enough to set up DMA, no need to require SD.
John Wilson
D Bit
7:47 a.m.
Yes, and what several vendors recommended so their "dumb" loader prom would
work with DD media was to write the boot tracks in SD. Unfortunately I
never found one that provided a utility to do that for you, so I had to
create my own formatter with which to do that. It always bothered me to
take that approach, so I ultimately fixed my CCS box to do it "correctly" in
my view. With a 4 MHz processor it was no problem to transfer either single
or double density. The DMA was only needed if you ran a slower CPU.
However, if you needed to read the WORDSTAR software from distribution
diskettes, it was not necessary to put any low-level OS-specific materials
on the distribution medium. It didn't need to boot from MicroPro's
diskettes.
Dick
----- Original Message -----
From: John Wilson <wilson(a)dbit.dbit.com>
To: <classiccmp(a)classiccmp.org>
Sent: Tuesday, May 30, 2000 1:20 PM
Subject: Re: Defining Disk Image Dump Standard
On Tue, May 30, 2000 at 12:01:30PM -0700, Don Maslin
wrote:
on
But that is/was not always true! There were a
number of 8" CP/M systems
that used bootable DD formats, and most all 5.25" CP/M systems were in a
bootable DSDD format.
I always figured the reason for the restriction was dumb boot PROMs, which
only know how to do programmed I/O to the FDC, and 8" DD comes in too fast
for typical 8-bit CPUs of the time to handle with PIO. If the boot PROM a particular system is smart enough to set up DMA, no
need to require SD.
John Wilson
D Bit
8:08 a.m.
Yes, and what several vendors recommended so their
"dumb" loader prom would
work with DD media was to write the boot tracks in SD. Unfortunately I
never found one that provided a utility to do that for you, so I had to
create my own formatter with which to do that. It always bothered me to
take that approach, so I ultimately fixed my CCS box to do it "correctly" in
my view. With a 4 MHz processor it was no problem to transfer either single
or double density. The DMA was only needed if you ran a slower CPU.
Well, within some unixes this was fairly common and the default
formating utils would do the trick... Side 0 / Track 0 has been
done in SD, while the rest was DD.
Nice history fact:
The SIEMENS PC-D, a 186 DOS machine, was due the boot ROM
still able to boot a SD DOS floppy _and_ the BIOS did
support DOS disks with T/S 0/0 as SD... I never found a
disk using this feature other than a special diagnostics
disk made to test it...
Gruss
H.
--
VCF Europa 2.0 am 28./29. April 2001 in Muenchen
http://www.vintage.org/vcfe
http://www.homecomputer.de/vcfe
7:42 a.m.
Clearly, I was insufficiently clear about what I meant. Bootability is not
an issue when exchange of media is the goal. I know there are systems that
boot from EITHER density and will do so from either single-side or
double-sided media, since I have a couple of them running. There are even
systems that will boot from single-sided or double-side, either FM or MFM,
and either 5-1/4" or 8" diskettes, e.g. my CCS system, though it was not
equipped with a booter that did that when I got it.
More importantly, however, I remember that in the CP/M days, but prior to
the TRS-80, CP/M software was distributed on "standard" 8" SSSD media with
no trace of the OS on them, and that arrangement worked perfectly well. The
problem of media exchange was not a problem until the 5-1/4" diskettes
became popular enough to exclude 8" drives and media from a large share of
the systems on the market.
What puzzled me was why, given that many systems were quite capable of
handling various media, they didn't write their code so it would load a
booter from the first sector, and make that booter deal with the low-level
details of the medium. My old SMS controller would read nearly any type of
sector it could write with a "read-sector" command. It didn't matter
whether it was 128-bytes or 2048, nor did it matter whether it was FM or
MFM.
Just as an aside, I recently encountered a datasheet for the WD 1773 FDC
(similar to 1770/72). Do you know of any systems in which it was used?
Dick
----- Original Message -----
From: Don Maslin <donm(a)cts.com>
To: <classiccmp(a)classiccmp.org>
Sent: Tuesday, May 30, 2000 1:01 PM
Subject: Re: Defining Disk Image Dump Standard
diskette
On Tue, 30 May 2000, Richard Erlacher wrote:
> I never understood why the double density CP/M diskettes were not
bootable,
> and why "distribution-standard"
diskettes had to be bootable. These are
two
> different features, and what's important
about the "standard" is not
that
it's
bootable but that it's defined so as to be universally readable.
But that is/was not always true! There were a number of 8" CP/M systems
that used bootable DD formats, and most all 5.25" CP/M systems were in a
bootable DSDD format.
8" SSDD:
Altos Avtek
Heurikon MLZ-90
Ithaca Intersystems
Octagon 8/16
Ohio Scientific Turbo
Tektronix 8
Vista A-800
8" DSDD:
Heath Magnolia
Heurikon MLZ-90
Ithaca Intersystems
MDS-80
Prolog APL-2
System Group 2800
W.J. Engineering
In the 5.25" bunch, the two obvious ones that immediately come to mind
as using the SD boot track are Osborne and Xerox.
- don
> The thing that made 5-1/4" "standard" diskettes unachievable back in
the
> CP/M days was that people couldn't let go of the notion that every
> had to be bootable. Frankly, I got fine mileage
out of diskettes which
> couldn't be booted, yet I never had a problem booting up.
>
> It's silly to mix these two desirables. They're not bound together.
Let's
> not require something that's
counterproductive as this is. If you make
a
> distribution standard for media, then use it for
distribution. Let the
OS
> determine what's suitable for booting.
>
> Dick
>
> ----- Original Message -----
> From: Sellam Ismail <foo(a)siconic.com>
> To: <classiccmp(a)classiccmp.org>
> Sent: Tuesday, May 30, 2000 12:50 AM
> Subject: Re: Defining Disk Image Dump Standard
>
>
> >
> > Let's start sort of from scratch here.
> >
> > So far we have the following (high level) criterion for a disk archive
> > standard:
> >
> > 1. Host computer type (2 bytes allowing up to 65536 models to be
> > specified)
> > 2. Track format (host computer specific)
> > 3. Sector format (single-density, double-density, etc)
> > 4. Sector data format - this will specify what format the archived
sector
> > is in (raw data? logical bytes?)
> > 5. Bytes per sector
> > 6. Bits per byte
> >
> > What else?
> >
> > I will be the first to say that this is may not be very logically
> > structured. What I am attempting to do is give a suggestion for a
high
> > level header that identifies what each chunk
of data in the archive
can
> > represent. In this way, disks that are
formatted with several
different
> > formats can be described.
> >
> > I think what this may evolve into is a Data Definition Language. The
DDL
> > will be encoded along with the disk data and
will describe the format
of
> > the data on the disk as it is being read.
> >
> > This comes back to the fact that utilities will have to be written for
> > each computer we decide to support (I assume it will be all of them)
to
> > both read and write native diskettes. I
also assume the data will be
> > passed between the archive host and the target machine via serial
link?
> >
> > In case my mostly random thoughts above don't make sense, here is what
I
> > would have in mind for the Apple ][:
> >
> > The disk can be read in either standard, logical format (13 or 16
sectors
> > per track, 256 bytes per sector) or
"raw" format (raw disk bytes are
read
> > from the track). There would also have to
be format descriptions for
> > specially formatted tracks such as the 18-sector type I mentioned.
> >
> > As for reading the raw bytes, the Apple ][ had what were called
> > "synchronization" bytes, which were 10 bits long, the two extra bits
being
> > used to synchronize the head with the start
of the track. I could go
into
> > a technical discussion of this but would
have to pull out some
reference
> > material to refresh my memory of how it all
worked. Anyway, these
bytes
> > would have to be specially encoded in the
archive.
> >
> > Sellam International Man of Intrigue
and
Danger
--------------------------------------------------------------------------
-----
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
8:20 a.m.
Ok, since certain individual(s) don't seem to understand what this project
is about, what we are discussing here is DEFINING A STANDARD FILE FORMAT
FOR ARCHIVING FLOPPY DISKETTES FROM DIFFERENT COMPUTING PLATFORMS.
It is, amazingly, the very same project that was proposed when this
discussion first began.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
9:58 a.m.
----- Original Message -----
From: Sellam Ismail <foo(a)siconic.com>
To: <classiccmp(a)classiccmp.org>
Sent: Tuesday, May 30, 2000 2:20 PM
Subject: Re: Defining Disk Image Dump Standard
Ok, since certain individual(s) don't seem to understand what this project
is about, what we are discussing here is DEFINING A STANDARD FILE FORMAT
FOR ARCHIVING FLOPPY DISKETTES FROM DIFFERENT COMPUTING PLATFORMS.
It is, amazingly, the very same project that was proposed when this
discussion first began.
Sellam International Man of Intrigue and
Danger
--------------------------------------------------------------------------
-----
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
11:19 a.m.
You don't get it, do you?
I'm saying it's probably a bad idea to use floppy media. This is because
it's mechanical, (2) because it's organic, and (3) because it is soon to
become obsolete. Aside from problems of data format incompatibility, you
have to deal with the mechanism to be able to read/write the archive's
constituent elements.
If an element of any medium has more than one file on it, not necessarily a
bad thing though I'd say it's risky and inconvenient, that file can identify
itself at its beginning and end, Begin <filename.ext>, End <filename.ext>.
That way it doesn't matter over time what the medium is, at least insofar as
your file format is concerned. The choice of medium is important, since
floppies, however handy, are not going to be around forever. CD's are
probably too small for some things, but maybe they're a better format.
They're organic, too, however, so they'll be unduly sensitive to heat, not
to mention chemicals, etc. Floppies are much less stabile over varying
environmental conditions. OTP EPROMS are pretty stabile, however, and
they're VERY small.
If you're serious about creating an archive. It needs to be permanent, so
it's essentially requisite that the media be write-once. I'd say you're
better off with an OTP EPROM. Hardware to create them is dirt-simple to
create, eraseable/rewritable equivalents are readily available, and even if
the OTP's (very inexpensive, by the way) become scarce, there will still be
rewritables available which can be write protected by removing the VPP or
program pin. Use those and you'll have a real archive. What's more, there
are no mechanical components, nothing to rust, become misaligned, or wear
out.
If you build your own archival system you have the option of choosing a
different medium. That's what I'm recommending.
I say that the following points are under consideration:
1. Host computer type (2 bytes allowing up to 65536
models to be
specified)
1a. Host computer format, to allow for machines that
support several
native formats (e.g. PERQ POS floppy/PERQ PNX floppy/PERQ
interchange
floppy)
2. Track format (host computer specific) I assume
things like the
interleave order go in here.
3. Sector format (single-density, double-density, etc)
4. Sector data format - this will specify what format
the archived sector
is in (raw data? logical bytes?)
5. Bytes per sector
6. Bits per byte
None of these need be an issue if you use another medium, e.g. OTP EPROM.
Dick
----- Original Message -----
From: Sellam Ismail <foo(a)siconic.com>
To: <classiccmp(a)classiccmp.org>
Sent: Tuesday, May 30, 2000 2:20 PM
Subject: Re: Defining Disk Image Dump Standard
Ok, since certain individual(s) don't seem to understand what this project
is about, what we are discussing here is DEFINING A STANDARD FILE FORMAT
FOR ARCHIVING FLOPPY DISKETTES FROM DIFFERENT COMPUTING PLATFORMS.
It is, amazingly, the very same project that was proposed when this
discussion first began.
Sellam International Man of Intrigue and
Danger
--------------------------------------------------------------------------
-----
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
11:52 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 2471 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000531/47d4aa8c/at…
12:24 p.m.
ard(a)p850ug1.demon.co.uk (Tony Duell) wrote:
Hi
I like soldered diode arrays. Even if one diode burns
out, one takes a polaroid picture to use as a reference
and solders in another diode. Overlapping of the polaroid
with a negative of the fixed array confirms correct
repair.............
Oops, sorry, I got carried away. I agree with Tony
that most magnetic media is at least as reliable
if stored in the right environment than a charge
on a floating gate.
This does go back to what I said about using multiple
types of media. It is necessary to use more than one
type. The types should be as varied as current technology
would allow. Also, the multiple copies on any particular
media should also be done on different manufactures
of that same media type.
I was just, barely, able to recover some original data from
distribution disk that were for a Kaypro II because the
adhesive used to hold the pads in the disk, bled through
the pads and got on the disk. This most likely was a problem
with only one manufacture.
Dwight
environmental conditions. OTP EPROMS are pretty stabile, however, and
they're VERY small.
Rubbish!.
I am _not_ going to trust my data to charges stored on the floating gates
of some chip. No way. Even the manufacturers quote data lifetimes of a
few 10s of years at most. That is not archival storage. Nor are EPROMs
particularly robust -- they can be damaged by static, head, misapplied
voltages, etc.
4:20 p.m.
On Tue, 30 May 2000, Dwight Elvey wrote:
This does go back to what I said about using
multiple
types of media. It is necessary to use more than one
type. The types should be as varied as current technology
would allow. Also, the multiple copies on any particular
media should also be done on different manufactures
of that same media type.
My hope is that a central repository on the net can be founded where these
disk images can be stored. I'm hoping to provide that repository once I
get more bandwidth into my server. I will then make periodic backups of
the archive on various media (CD ROM of course). Also, mirror sites can
be created, thus ensuring the archive is not susceptible to one
catastrophe.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
31 May
31 May
6:05 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 2968 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000531/b53abf1b/at…
30 May
30 May
12:28 p.m.
You're right, you can DESTROY data recorded on an EPROM. You have to set
about to do that, however, and I know few archives where that's likely to be
tolerated.
If you put floppy diskettes on the shelf and wait 20 years, you'll see
what's left of your archive.
Dick
----- Original Message -----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: <classiccmp(a)classiccmp.org>
Sent: Tuesday, May 30, 2000 5:52 PM
Subject: Re: Defining Disk Image Dump Standard
so
if
You don't get it, do you?
No, _You_ don't get it.
We're not talking about making an archive _on_ floppy disks. We're
talking about defining a format for a file to be used to store the
contents of floppy disks.
This file can be stored on just about anything. Magnetic disks, magnetic
tape, multiple reels of paper tape, EPROMs, Bubble memory, you name it.
The idea is that floppy disks (that's real floppy disks) from classic
computers (which, like it or not are what this list is about :-)) can
then be archived on something a little easier to preserve and a little
easier to transfer around the world than the physical disks.
environmental conditions. OTP EPROMS are pretty
stabile, however, and
they're VERY small.
Rubbish!.
I am _not_ going to trust my data to charges stored on the floating gates
of some chip. No way. Even the manufacturers quote data lifetimes of a
few 10s of years at most. That is not archival storage. Nor are EPROMs
particularly robust -- they can be damaged by static, head, misapplied
voltages, etc.
I back up EPROMs to other media, not the reverse...
>
> If you're serious about creating an archive. It needs to be permanent,
it's
essentially requisite that the media be write-once. I'd say you're
Actually, OTP EPROMs are not write-once. You can write them as many times
as you like. The only thing is you can only change a '1' into a '0', and
never the reverse. So you could 'erase' the archive (simply fill the
EPROM with 0s). Or corrupt it (flip a few odd 1's to 0's).
FWIW, the Psion Organiser (an early UK-made PDA) had plug-in EPROM
cartridges. These were used as file storage devices. A file could be
'deleted' by setting a bit in its header to 0, whereupon the system would
no longer find the file, but obviously it would still take up space on
the EPROM. The Datapak (EPROM module) could be 'reformatted' in a special
formatter, which was nothing more than a UV-eraser.
> better off with an OTP EPROM. Hardware to create them is dirt-simple to
> create, eraseable/rewritable equivalents are readily available, and even > the OTP's (very inexpensive, by the way)
become scarce, there will still
be
> rewritables available which can be write
protected by removing the VPP
or
> program pin. Use those and you'll have a
real archive. What's more,
there
Incidentally, a lot of EPROMs don't like having Vpp floating, they want
it tied to Vcc (normally). Ditto for PGM/
-tony
2:08 p.m.
On Tue, May 30, 2000 at 06:28:42PM -0600, Richard Erlacher wrote:
If you put floppy diskettes on the shelf and wait 20
years, you'll see
what's left of your archive.
[replying to:]
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
[...]
> We're not talking about making an archive _on_
floppy disks. We're
> talking about defining a format for a file to be used to store the
> contents of floppy disks.
Oh for chrissake, did you even read Tony's post, which you thoughtfully
quoted in its entirety to clog everyone's mailbox AS USUAL?
This has been a long time coming -- Dick, welcome to my email filter.
John Wilson
D Bit
31 May
31 May
6:12 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 1369 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000531/dda7c6ff/at…
8:34 a.m.
I just considered another bit of data that might be useful to store in the
Archive Header.
If one were to have to read the raw bytes off of a track due to some
non-standard format, it would be helpful to know at what rate the disk
drive that read the disk was spinning so that if and when that archive was
used to re-create the original disk, the writing drive could be adjusted
to match the speed at which it was read. This is pretty imperative.
A quick test can be done before the disk is read to determine the RPM. Of
course, having an optimally tuned drive would be recommended if one is to
be serious about creating software archives for posterity.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
1:58 p.m.
If you acquire the data by manifold oversampling, you can infer the speed
and deviations in it from the acquired data. Fortunately, this can all be
handled in software after the goodies are in captivity. You do have to have
some baseline statistics, though, such as FD size.
Dick
----- Original Message -----
From: Sellam Ismail <foo(a)siconic.com>
To: <classiccmp(a)classiccmp.org>
Sent: Wednesday, May 31, 2000 2:34 PM
Subject: Re: Defining Disk Image Dump Standard
I just considered another bit of data that might be useful to store in the
Archive Header.
If one were to have to read the raw bytes off of a track due to some
non-standard format, it would be helpful to know at what rate the disk
drive that read the disk was spinning so that if and when that archive was
used to re-create the original disk, the writing drive could be adjusted
to match the speed at which it was read. This is pretty imperative.
A quick test can be done before the disk is read to determine the RPM. Of
course, having an optimally tuned drive would be recommended if one is to
be serious about creating software archives for posterity.
Sellam International Man of Intrigue and
Danger
--------------------------------------------------------------------------
-----
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
10:36 a.m.
ard(a)p850ug1.demon.co.uk (Tony Duell) wrote:
And most people (I am not one, but) tend to _read_
unknown EPROMs in an
EPROM _programmer_. Most programmers have this facility, and it saves
them having to wire up ZIF sockets, a PSU, buffers back to I/O ports on a
host computer, etc. Which means that finger trouble, or a fault in the
programmer, could wipe the EPROM.
Which is why I always used to leave my EPROM programmer set for a
Vpp of 5V (back when devices used Vcc=5V and Vpp typically of 12.5V, 21V,
or 25V). That way even if I accidentally told it to program, nothing
would happen (unless the part was a 5V-only EEPROM).
However, the more recent EPROM programmers I'm using don't have such
an option.
Anyhow, there are lots of ways to accidentally damage a part, even if
you don't put it in an EPROM programmer and tell it to program.
30 May
30 May
11:57 a.m.
On Tue, May 30, 2000 at 05:19:45PM -0600, Richard Erlacher (richard(a)idcomm.com) wrote:
You don't get it, do you?
I'm saying it's probably a bad idea to use floppy media. This is because
it's mechanical, (2) because it's organic, and (3) because it is soon to
become obsolete. Aside from problems of data format incompatibility, you
have to deal with the mechanism to be able to read/write the archive's
constituent elements.
[snip]
If you're serious about creating an archive. It
needs to be permanent, so
it's essentially requisite that the media be write-once.
I haven't been following this thread, but I happened to notice this
post. I happened to be speaking to the chief archivist here at the
University today about electronic archiving, and the one thing that
came across in the conversation is that the bottom line regarding
digital archives is that archiving has become a continuous process.
From her perspective, it was simply that one could no
longer store
away paper and expect it to last hundreds of years; relevant to this
discussion is that the new approach to archiving revolves around not
only choosing media that will both last and not-be-obsolete for N
years, but also arranging the process such that in N minus epsilon
years, the media choice is re-evaluated and the archives rewritten in
the new media, and repeat.
Permanent digital archives, in other words, are the holy grail of the
archivist's realm. :-)
Of course, IANAArchivist.
-Rich
--
------------------------------ Rich Lafferty ---------------------------
Sysadmin/Programmer, Instructional and Information Technology Services
Concordia University, Montreal, QC (514) 848-7625
------------------------- rich(a)alcor.concordia.ca ----------------------
12:26 p.m.
Unfortunately, too few people have had floppy "archives" for over 20 years
and seen what they have left.
Dick
----- Original Message -----
From: Rich Lafferty <rich(a)alcor.concordia.ca>
To: <classiccmp(a)classiccmp.org>
Sent: Tuesday, May 30, 2000 5:57 PM
Subject: Re: Defining Disk Image Dump Standard
so
On Tue, May 30, 2000 at 05:19:45PM -0600, Richard
Erlacher
(richard(a)idcomm.com) wrote:
> You don't get it, do you?
>
> I'm saying it's probably a bad idea to use floppy media. This is
because
> it's mechanical, (2) because it's
organic, and (3) because it is soon to
> become obsolete. Aside from problems of data format incompatibility,
you
have to deal
with the mechanism to be able to read/write the archive's
constituent elements.
[snip]
> If you're serious about creating an archive. It needs to be permanent,
it's
essentially requisite that the media be write-once.
I haven't been following this thread, but I happened to notice this
post. I happened to be speaking to the chief archivist here at the
University today about electronic archiving, and the one thing that
came across in the conversation is that the bottom line regarding
digital archives is that archiving has become a continuous process.
From her perspective, it was simply that one could
no longer store
away paper and expect it to last hundreds of years; relevant to
this
discussion is that the new approach to archiving revolves around not
only choosing media that will both last and not-be-obsolete for N
years, but also arranging the process such that in N minus epsilon
years, the media choice is re-evaluated and the archives rewritten in
the new media, and repeat.
Permanent digital archives, in other words, are the holy grail of the
archivist's realm. :-)
Of course, IANAArchivist.
-Rich
--
------------------------------ Rich Lafferty ---------------------------
Sysadmin/Programmer, Instructional and Information Technology Services
Concordia University, Montreal, QC (514) 848-7625
------------------------- rich(a)alcor.concordia.ca ----------------------
8:29 a.m.
On Tue, 30 May 2000, Richard Erlacher wrote:
Clearly, I was insufficiently clear about what I
meant. Bootability is not
an issue when exchange of media is the goal. I know there are systems that
boot from EITHER density and will do so from either single-side or
double-sided media, since I have a couple of them running. There are even
systems that will boot from single-sided or double-side, either FM or MFM,
and either 5-1/4" or 8" diskettes, e.g. my CCS system, though it was not
equipped with a booter that did that when I got it.
More importantly, however, I remember that in the CP/M days, but prior to
the TRS-80, CP/M software was distributed on "standard" 8" SSSD media
with
no trace of the OS on them, and that arrangement worked perfectly well. The
problem of media exchange was not a problem until the 5-1/4" diskettes
became popular enough to exclude 8" drives and media from a large share of
the systems on the market.
What puzzled me was why, given that many systems were quite capable of
handling various media, they didn't write their code so it would load a
booter from the first sector, and make that booter deal with the low-level
details of the medium. My old SMS controller would read nearly any type of
sector it could write with a "read-sector" command. It didn't matter
whether it was 128-bytes or 2048, nor did it matter whether it was FM or
MFM.
Just as an aside, I recently encountered a datasheet for the WD 1773 FDC
(similar to 1770/72). Do you know of any systems in which it was used?
No, sorry, not off the top of my head.
- don
Dick
----- Original Message -----
From: Don Maslin <donm(a)cts.com>
To: <classiccmp(a)classiccmp.org>
Sent: Tuesday, May 30, 2000 1:01 PM
Subject: Re: Defining Disk Image Dump Standard
diskette
On Tue, 30 May 2000, Richard Erlacher wrote:
> I never understood why the double density CP/M diskettes were not
bootable,
> and why "distribution-standard"
diskettes had to be bootable. These are
two
> different features, and what's important
about the "standard" is not
that
it's
bootable but that it's defined so as to be universally readable.
But that is/was not always true! There were a number of 8" CP/M systems
that used bootable DD formats, and most all 5.25" CP/M systems were in a
bootable DSDD format.
8" SSDD:
Altos Avtek
Heurikon MLZ-90
Ithaca Intersystems
Octagon 8/16
Ohio Scientific Turbo
Tektronix 8
Vista A-800
8" DSDD:
Heath Magnolia
Heurikon MLZ-90
Ithaca Intersystems
MDS-80
Prolog APL-2
System Group 2800
W.J. Engineering
In the 5.25" bunch, the two obvious ones that immediately come to mind
as using the SD boot track are Osborne and Xerox.
- don
> The thing that made 5-1/4" "standard" diskettes unachievable back in
the
> CP/M days was that people couldn't let go of the notion that every > had to be bootable. Frankly, I got fine
mileage out of diskettes which
> couldn't be booted, yet I never had a problem booting up.
>
> It's silly to mix these two desirables. They're not bound together.
Let's
> not require something that's
counterproductive as this is. If you make
a
> distribution standard for media, then use it
for distribution. Let the
OS
> determine what's suitable for booting.
>
> Dick
>
> ----- Original Message -----
> From: Sellam Ismail <foo(a)siconic.com>
> To: <classiccmp(a)classiccmp.org>
> Sent: Tuesday, May 30, 2000 12:50 AM
> Subject: Re: Defining Disk Image Dump Standard
>
>
> >
> > Let's start sort of from scratch here.
> >
> > So far we have the following (high level) criterion for a disk archive
> > standard:
> >
> > 1. Host computer type (2 bytes allowing up to 65536 models to be
> > specified)
> > 2. Track format (host computer specific)
> > 3. Sector format (single-density, double-density, etc)
> > 4. Sector data format - this will specify what format the archived
sector
> > is in (raw data? logical bytes?)
> > 5. Bytes per sector
> > 6. Bits per byte
> >
> > What else?
> >
> > I will be the first to say that this is may not be very logically
> > structured. What I am attempting to do is give a suggestion for a
high
> > level header that identifies what each
chunk of data in the archive
can
> > represent. In this way, disks that are
formatted with several
different
> > formats can be described.
> >
> > I think what this may evolve into is a Data Definition Language. The
DDL
> > will be encoded along with the disk
data and will describe the format
of
> > the data on the disk as it is being
read.
> >
> > This comes back to the fact that utilities will have to be written for
> > each computer we decide to support (I assume it will be all of them)
to
> > both read and write native diskettes.
I also assume the data will be
> > passed between the archive host and the target machine via serial
link?
> >
> > In case my mostly random thoughts above don't make sense, here is what
I
> > would have in mind for the Apple ][:
> >
> > The disk can be read in either standard, logical format (13 or 16
sectors
> > per track, 256 bytes per sector) or
"raw" format (raw disk bytes are
read
> > from the track). There would also have
to be format descriptions for
> > specially formatted tracks such as the 18-sector type I mentioned.
> >
> > As for reading the raw bytes, the Apple ][ had what were called
> > "synchronization" bytes, which were 10 bits long, the two extra bits
being
> > used to synchronize the head with the
start of the track. I could go
into
> > a technical discussion of this but
would have to pull out some
reference
> > material to refresh my memory of how it
all worked. Anyway, these
bytes
> > would have to be specially encoded in
the archive.
> >
> > Sellam International Man of Intrigue
and
Danger
--------------------------------------------------------------------------
-----
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
10:11 a.m.
Rumor has it that Richard Erlacher may have mentioned these words:
Just as an aside, I recently encountered a datasheet
for the WD 1773 FDC
(similar to 1770/72). Do you know of any systems in which it was used?
Wasn't the 1773 a single-chip version of the 1793, or am I out in Left
Field? The early Tandy controllers that required 12V were based on the
1793, and weren't the later 5Vonly ones based on the 1773?
I can't remember the numbers anymore... have to go home and look! ;-)
See ya,
Roger "Merch" Merchberger
--
Roger "Merch" Merchberger --- sysadmin, Iceberg Computers
Recycling is good, right??? Ok, so I'll recycle an old .sig.
If at first you don't succeed, nuclear warhead
disarmament should *not* be your first career choice.
11:10 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 1118 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000531/987b2cb9/at…
12:15 p.m.
In general, Western numbered their FDC's such, that their parts had odd
numbers on the "normal" parts. The mainstream FM-only part was the 1771,
which is what was in the RS Model 1 and which used +12 on one of its 40
pins. It had an inverted data bus.
The 179x series was more fully developed, in that the 1791 was a 40-pin part
using +12 but which was MFM-and-FM-capable, but required external data
processing to apply precomp on writes and to extract clock from the raw data
stream on reads. Like the 1771, it had an inverting data bus.
Western also made a 179x member or two that had non-inverting data ports.
These were the 1793 and 1797. These were like the 1791, and 1795, which had
the inverting data port, but of which the 1795/97 was intended for use with
two-sided drives. The 1793 and '97 had noninverted busses, while the 1791
and 1795 had inverted busses, and the '97 and '95 had a head-select
provision not provided internally in the other (lower) numbers.
The 1770,1772, and 1773 are/were 28-pin parts, using 5-volts only, and
equipped with heavy duty drivers capable of driving the FDD cable, while the
40-pin parts required external buffering. The 1770/72/73 had internal
data/clock separators and write precompensation logic. They were clearly
intended for use only with 5-1/4" drives, as they had provision for the
motor-on signal, with the exception of the 1773, which differs slightly.
There was also a 1774 that I read about at one time, intended for use with
M^2FM which didn't make it to market. I've never seen one, however.
Dick
----- Original Message -----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: <classiccmp(a)classiccmp.org>
Sent: Tuesday, May 30, 2000 5:10 PM
Subject: Re: Defining Disk Image Dump Standard
Basically, yes. I know I have the data sheets in my Western Digital
Databook (along with the 1770, 1771, 1772, 179x, 279x, and some hard
disk controller chipsets). But I'm not going to go and find said book
unless you need things like pinouts, etc.
>
> Rumor has it that Richard Erlacher may have mentioned these words:
>
> >Just as an aside, I recently encountered a datasheet for the WD 1773
FDC
(similar to 1770/72). Do you know of any systems in
which it was used?
Wasn't the 1773 a single-chip version of the 1793, or am I out in Left Field? The early Tandy controllers that required
12V were based on the
1793, and weren't the later 5Vonly ones based on the 1773?
For the CoCo, yes. The older one had a 1793, and needed 12V (which means
it didn't work on a CoCo 2 or 3 without a hardware mod to the computer,
or the use of a multipak interface). The later ones used the 1773 and
only needed +5V.
But other TRS-80s used other controllers :
Model 1 : 1771 (together with a 1791 if you had a double density mod)
Model 2 : 1791 (I think -- it was a 179x series)
Model 3/4 : 1793
-tony
11:27 a.m.
The 1770/72/73 were 28-pin parts with output buffers suitable for driving a
cable and with internal data/clock separator, and a few other features, but
still code-compatible (sort-of) with the 179x series. The 177x series of
which I write were for 5-1/4" diskettes only.
The 1773 has slightly different pins, two of them, than the other two
members of its family.
Dick
----- Original Message -----
From: Roger Merchberger <zmerch(a)30below.com>
To: <classiccmp(a)classiccmp.org>
Sent: Tuesday, May 30, 2000 4:11 PM
Subject: Re: Defining Disk Image Dump Standard
Rumor has it that Richard Erlacher may have mentioned
these words:
Just as an aside, I recently encountered a
datasheet for the WD 1773 FDC
(similar to 1770/72). Do you know of any systems in which it was used?
Wasn't the 1773 a single-chip version of the 1793, or am I out in Left
Field? The early Tandy controllers that required 12V were based on the
1793, and weren't the later 5Vonly ones based on the 1773?
I can't remember the numbers anymore... have to go home and look! ;-)
See ya,
Roger "Merch" Merchberger
--
Roger "Merch" Merchberger --- sysadmin, Iceberg Computers
Recycling is good, right??? Ok, so I'll recycle an old .sig.
If at first you don't succeed, nuclear warhead
disarmament should *not* be your first career choice.
6:16 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 2261 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000530/4faf737b/at…
8:56 a.m.
On Tue, 30 May 2000, Tony Duell wrote:
In what ways do the formats differ? Are you talking logical format or
physical format? If it is physical then I would agree. If it's logical
then that's more detail than we want to get into. We only need concern
ourselves to the level of organized blocks of data on the diskette (i.e.
sectors & tracks).
Yes, see followup posting after Jim's input.
Not necessarily. It's entirely possible to write 20-bit bytes on the
Apple Disk ][ hardware if one wanted for instance. Not that I know of
anyone who's ever done that. I included the bits-per-byte field at the
behest of someone (sorry, forgot who) who suggested that a disk "byte" is
not always "eight bits".
1. Host
computer type (2 bytes allowing up to 65536 models to be
specified)
1a. Host computer format, to allow for machines that support several native
formats (e.g. PERQ POS floppy/PERQ PNX floppy/PERQ interchange floppy) 2. Track
format (host computer specific)
I assume things like the interleave order go in
here. It's probably best to regard the sector as a
stream of bits, suitably
packed into the bytes on whatever machine is doing the imaging
But only if necessary. I think it would be far more useful to simply
store the bytes of each sector on the original disk. I would only want to
archive the bit stream of a track if the format was unusual.
5. Bytes per
sector
6. Bits per byte
Isn't that rather defined by 1 and 2 above? Wouldn't it be possible to store the data from a
particular track in
several formats? As logical sectors, or as a stream of bytes _in the same
image file_. Using a pseudo-notation :
That is what I am advocating the standard should be able to support,
although I hadn't thought about being able to support the same image in
two separate formats (logical sectors vs. physical bytes) in the same
archive.
Machine : Apple ][
Machine-specifc format : DOS 3.3 16 sector disk, standard format
Track layout : 35 tracks, 1 head
Track 0 Hd 0: Logical data. Sectors are 1 (GCR), 3 (GCR),
5(GCR),...2(GCR),4(GCR),6(GCR)... (or whatever the
interleave order is)
Track 0, Hd 0, Sector 0 : <Stream of bytes from that sector>
Track 0, Hd 0, Sector 1 : <Stream of bytes from that sector>
etc
Track 0 Hd 0 Physical data : <Stream of raw bytes representing the pulses
on the disk. This would include GCR sync
bytes, FM/MFM clock and data pulses, etc.
Basically saying: Pulse, gap of 250uS, pulse,
gap of 500us, etc>
Repeat for track 1, etc....
I would be more inclined to create two separate images for each format.
But that's just my preferred method of organization.
As far as encoding the level of detail that Tony suggests above, I don't
know that you'd want to have a header for each sector in the archive
image.
Unless there was a header for each sector that perhaps contained the
following:
Track/Head/Sector/Density/#Bytes/<sector data> (...etc...)
In this way you could specify a change in the format of each sector and it
would be very flexible. There would be an 8-12 byte header for each
sector. It would then render some of the fields stored in the overall
header worthless then.
Another way to do this is to have a chain of Description Headers that are
stored at the beginning of each "chunk" of similar disk data. So for a
standard diskette, you'd need only one header that describes the format
for the entire disk (35 tracks, 16 sectors per track, 256 bytes per
sector, etc). If the disk format varies on the disk, say track 0 is 16
sectors and tracks 1-34 are 18 sectors, you would have the header for the
first track including an offset to the beginning of the next Description
Header, then the first track's worth of data, then the next Description
Header and the offset link to the next one, followed by the chunk of
sectors defined by this header, etc.
Know what I mean?
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
10:52 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 7639 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000530/78f6115a/at…
31 May
31 May
5:05 p.m.
Responding to an older message...
On Tue, 30 May 2000, Tony Duell wrote:
However, I've just thought of a better example : I
once saw a card for an
Apple ][ containing a 1771 and associated components (and probably a
ROM). It linked to an external box containing 2 8" drives. The official
purpose was to allow an Apple with a Z80 Softcard to read standard SSSD
CP/M disks. But I am _sure_ it could have been used from Apple DOS given
the right software.
Which means the archive format would have to allow for :
Apple ][, 16 sector 5.25" GCR-encoded disk
and
Apple ][, 26 sector, 8", FM encoded disk.
It may be a _very_ unusual format, but a proposed archive format should
be able to handle _anything_. In any case, I would think that 256
sub-formats for each machine would be plenty, which means this adds _1
byte_ to the archive size. Not really a problem IMHO.
I suppose a sub-format byte wouldn't hurt. What I don't like about it is
that it will require that someone be maintaining a database of all the
sub-formats. But I guess since we have a machine identifier and this will
have to be maintained as well, a sub-format byte is not too demanding.
Of course, there will have to be a central person who is responsible for
receiving input for new machine and sub-format types, updating the
database with the new computer types and sub-format types, and
disseminating this from a website.
This is something that can be hosted from the VCF server.
The header could also include a text description entered in by the
archiver that could describe anything special about the archive. In fact,
I envision the archiving program having a section where the archiver
inputs his/her name and e-mail address, which will get encoded along with
the archive.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
1 Jun
1 Jun
8:04 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 789 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000601/97da7e24/at…
30 May
30 May
11:48 a.m.
Hi
It was not specifically mentioned but I also think
we should archive a method to boot strap the machine
from ground zero, were this can be done with things
like front panels or ROM monitors. I realize that this
may not always be provided by the original manufacture
but I am currently in the process of doing just that
to the second machine. This may even need the inclussion
of special hardware or blowing of custom ROM's but
it is also needed.
As was stated by others, the
media for archiving needs to be in a currently common
format that is supported by todays machines. It has
also been generally recognized that it should be occasionally
brought up to date by moving to newer media. It is my
opinion that this should be done on an overlapping basis,
such as today, we might use both floppies and CD ROM's.
Multiple copies stored in multiple locations is also
needed as well as some form of scheduled refreshing,
with overlapping copies on the same media.
I don't think that we should even try to save data in the
original format as long as there is a method such as I
mentions above to restore data to the original media.
Saving the data in DOS files is a proper method and
meets the needs of archiving. One also has to consider
that some software is composed of a number of elements.
As was mentioned, even in CPM, part of the OS might
be in a file. This means that the method of saving
must include the ability to link a number of pieces
that were not necessarily tied together as a single
data stream.
Another thing that wasn't talked about was CRC's. Even
though most media has built in CRC's, there is no way
to detect a failure in the communications between the
new and old media. I suggest that this be at least a
two level CRC. The first level would be on small blocks
of data that the CRC could do error correction on with
a reasonable burst size compared to the block size.
The next level would have a larger CRC with a burst correction
size that would be greater than two times the lower
levels CRC. This last level of CRC would have several
copies of the CRC value scattered through the data stream.
As an example, CRC-32 can fix a burst of 12 bad bits.
I would limit the block size for this CRC to about
512 bytes. A larger CRC would be needed for the top
level CRC.
I also doubt, that most people realize that there are
other types of data encoding than MFM and FM. Intels
M2FM comes to mind, as well as the Apple format. It was
stated that people felt that it would not be practical
to make a piece of hardware that could read any arbitrary
format. I contend that as long as that format could
have been read or written through that drive that a
simple DSP chip could be used to make a universal controller
chip. Vary little hardware, other than a simple development
board, would be needed. I find it hard to believe that
one couldn't cover 99% of what is out there. At least,
as long as we where talking about floppies or some of
the raw media hard drives.
To show the variety of things, the machine I'm working on
has two sectors per track of 20480 bits. This is on
32 hard sectored media. It is regular FM, though.
Just my thoughts
Dwight
12:10 p.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 2761 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000531/7f4318d2/at…
12:37 p.m.
ard(a)p850ug1.demon.co.uk (Tony Duell) wrote:
Hi
And why not? I brought up a CPM machine from ground
zero with just such a method. It wasn't easy but
I just think it is wise to include these types of
operations in the archive.
I don't think in these cases
that keeping original media is as good an idea.
When the last original machine fails with the
blowing of the last SN7400, do you expect to quickly
transfer the data to a new media? The software it self
has future value, even without the original machine.
We should be looking at long term methods of preserving
as much as we can. As you stated, things like schematics
are of that type but I think what Sam is worried about
is that we are loosing software faster than other elements
of computers because, like the old metal toys, people
seem to place less value on that information and
it is destroyed more often.
Dwight
I don't
think that we should even try to save data in the
original format as long as there is a method such as I
Well, there's no reason not to. And a lot of us here use the old
computers that _need_ the data on the original media. You can't exactly
boot a home micro from an image file on a unix box, you know :-)
[....]
31 May
31 May
6:17 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 1942 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000531/88b26e43/at…
8:26 a.m.
On Wed, 31 May 2000, Tony Duell wrote:
I see no reason not to keep the original disks. For
one thing, they're a
backup of the archive. Maybe not a very good one, but still a possible
backup. For another thing, they might be of interest to historians (how
the disks of the period were made, how they were labelled, etc).
I awlays keep the original diskettes, and always grab whatever original
disks I find in thrift (charity) shops for the labelling and boxes. They
are artifacts that represent the culture surrounding computing.
My desire to archive the software is of course dervied from the knowledge
that someday those disks will simply be interesting pieces of plastic:
mere representations of the software they used to hold.
On a somewhat related note, there's a great website--the Disk Sleeve
Archive. Unfortunately, the URL I have for it is no longer valid?
http://www.cyberden.com/sleeves/index.html
I'm not saying don't make the archive. I'm
saying make the archive, look
after it, but keep the original disks _as well_. Then use those to run
the machine they were designed to run. If necessary, make a new disk from
the archived data (which doesn't damage the archive, of course).
I see no problem using the original diskette for demonstration purposes.
It's not like the data will stick around if you don't use it. But I'd
still make a copy of the disk for general use.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
5:30 p.m.
Here's the next iteration of our standard in progress. I've decided to
split the header into two separate ones--a Disk Descriptor Header and a
Track Descriptor Header--as the discussion has been moving us towards.
Desk Descriptor Header
1. Host computer type (2 bytes allowing up to 65536 models to be specified)
2. Hard/soft sector flag (1 byte)
3. Number of tracks (1 byte)
4. Encoding type (1 byte)
5. Disk drive RPM (2 bytes: 1 for whole number, 1 for fraction) [1]
Optional:
6. Archiver Name (24 bytes)
7. Archiver E-mail Address (48 bytes)
8. Archive Description (256-512 bytes)
9. Archive Date (4 bytes: 2 bytes = year, 1 byte = month, 1 byte = day)
A. Archive Time (3 bytes: hour, minute, second)
Maximum size: 598 bytes
[1] If applicable
A Track Descriptor Header will precede each track and give an overall
description of the track:
Track Descriptor Header
1. Track number (2 bytes: 1 for whole number, 1 for fraction) [1]
1. Track format (logical or raw; host computer specific) (1 byte) [2]
2. Track size in bytes (2 bytes) [3]
3. Sector format (single-density, double-density, etc) (1 byte)
4. Sectors in this track (1 byte)
5. Bytes per sector (2 bytes)
6. Bits per byte (1 byte)
7. Offset to next Track Descriptor Header (2 bytes)
Size: 12 bytes
[1] Fraction allows for specifying half- or quarter-track.
[2] If the track is in "raw" format then fields 3-7 are ignored.
[3] The total size in bytes of the raw track image.
As we can see, so far the addition of the headers adds no significant
size to the archive.
Comments?
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
1 Jun
1 Jun
5:35 a.m.
On Wed, 31 May 2000, Sellam Ismail wrote:
Track Descriptor Header
1. Track number (2 bytes: 1 for whole number, 1 for fraction) [1]
1. Track format (logical or raw; host computer specific) (1 byte) [2]
2. Track size in bytes (2 bytes) [3]
3. Sector format (single-density, double-density, etc) (1 byte)
Insert "Sector Interleave" (will 1 byte suffice = 2 4-bit values?)
4. Sectors in this track (1 byte)
5. Bytes per sector (2 bytes)
6. Bits per byte (1 byte)
7. Offset to next Track Descriptor Header (2 bytes)
Special raw disk bytes such as synchronization bytes (as on the Apple ][)
will have to be denoted in some fashion. But how?
There were anywhere from 8 to 16 8-bit sync bytes (having the value 255)
found at the beginning of each track and before each sector that contained
two additional zero bits at the end (so they looked like 1111111100).
How will these get stored? Perhaps a map could be included with raw track
data to specify sync bytes. The map would be a series of bits, each bit
corresponding to a byte in the raw track image, a 1 bit meaning the byte
is a sync byte and a 0 meaning normal. The bits can be packed into bytes
so that a track of 5,472 bytes (roughly the theoretical size of a raw
16-sector Apple ][ disk track) would take 684 additional bytes.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
6:12 a.m.
One more thing I forgot to add...
On Thu, 1 Jun 2000, Sellam Ismail wrote:
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
> Track Descriptor Header
>
> 1. Track number (2 bytes: 1 for whole number, 1 for fraction) [1]
> 1. Track format (logical or raw; host computer specific) (1 byte) [2]
> 2. Track size in bytes (2 bytes) [3]
Insert "Disk Side (Head)" (1 byte)
3. Sector
format (single-density, double-density, etc) (1 byte)
Insert "Sector Interleave" (will 1 byte suffice = 2 4-bit values?)
> 4. Sectors in this track (1 byte)
> 5. Bytes per sector (2 bytes)
> 6. Bits per byte (1 byte)
> 7. Offset to next Track Descriptor Header (2 bytes)
8:34 a.m.
On Thu, Jun 01, 2000 at 11:12:11AM -0700, Sellam Ismail wrote:
Insert "Disk Side (Head)" (1 byte)
Hard or soft head number? I feel sure I ran into a format (Commodore?) where
the sector headers had the opposite head numbers to the side on which they
were actually recorded.
Also, re having a field that denotes the source machine, this seems dangerous.
What if the disk has dual directories and is supposed to work on more than one
dir structure? What if it's a generic format that works on lots of different
machines (like FAT or RT-11, these disks have become de facto interchange
standards and often exist w/o ever touching the machines for whom that's a
native format)? Also, even if there is a source architecture specifier, I'd
rather see this as a short ASCII string rather than a magic number, so that
we won't need a central authority to assign the numbers, in most cases it's
obvious what short string uniquely identifies the architecture (like with
SCSI vendor and device IDs).
In any case, this is more information than *real* floppies have! All you
(i.e. the computer) need to know in any given instance, is whether this disk
is in *your* format, and you'll find that out when you try to read it. Just
like a real floppy.
The complexity seems to be rapidly getting out of hand, and I wonder
whether this is solving problems that don't really come up that often?
Having something which treats floppies as a black box, like Teledisk, is
handy in some circumstances, but I already dislike Teledisk because it gets
you in the silly situation of being unable to reproduce the disk even on
the machine for which it is intended. In this regard, an open standard is
a big step up from Teledisk, but now that means that in order to reproduce
a floppy on its native machine, you have to grab the spec and write a big
disk copier utility for that machine, which knows how to parse text tags
(please tell me I misunderstood that part) and double-check header formats
to make sure they're really vanilla. All instead of simply writing the
contiguous binary data out in the native format.
I think a nice compromise might be to represent each floppy disk with two
files, one of which contains all the data as a straight binary image in
whatever's the most sensible order for that machine, which would be convenient
for use on the original machine (not to mention emulators), and the other one
contains all the fancy headers and sector descriptors, with pointers into the
binary image. That would make the images easy to move to/from real disks on
the original machine, they'd be easy to manipulate with file system utilities
(or something like the Linux loopback device), and you could use the same
descriptor file with an arbitrary number of binary image files so there'd
be less work involved in cooking up the image files, and they'd use a lot
less disk space. The only down side I can think of is how to make sure the
matching descriptor file and image file don't get separated from one another.
John Wilson
D Bit
8:08 a.m.
On Thu, 1 Jun 2000, John Wilson wrote:
Hard or soft head number? I feel sure I ran into a
format (Commodore?) where
the sector headers had the opposite head numbers to the side on which they
were actually recorded.
I know that's true on the Apple ][. Side "1" is actually the backside of
the diskette and vice versa.
Also, re having a field that denotes the source
machine, this seems
dangerous. What if the disk has dual directories and is supposed to
work on more than one dir structure? What if it's a generic format
that works on lots of different machines (like FAT or RT-11, these
disks have become de facto interchange standards and often exist w/o
ever touching the machines for whom that's a native format)? Also,
Then the machine descriptor would reflect the actual machine that the
software was designed to run on. Providing I understand what you are
saying, I don't see a problem here.
even if there is a source architecture specifier,
I'd rather see this
as a short ASCII string rather than a magic number, so that we won't
need a central authority to assign the numbers, in most cases it's
I don't like that because it allows for too much variation in the naming
convention.
I suppose we can include a database of pre-defined Computer Type strings
in the archive creation software but still allow the archiver to type in
his/her own to allow for new computers. The Computer Typer strings can be
contained in a textfile that can be updated regularly and downloaded from
the homepage for the project.
obvious what short string uniquely identifies the
architecture (like
with SCSI vendor and device IDs).
That works because each SCSI vendor creates one string that they use. If
we have multiple people creating their own strings for computer names then
it gets messy.
Something to ponder though...
In any case, this is more information than *real*
floppies have! All you
(i.e. the computer) need to know in any given instance, is whether this disk
is in *your* format, and you'll find that out when you try to read it. Just
like a real floppy.
This is not just for the computer's sake but for the humans who are
archiving it as well. We need to know what this disk is (hmmm, need to
add a Title string) rather than have to make silly guesses. Besides,
diskettes DO have this information, generally on the label :)
The complexity seems to be rapidly getting out of
hand, and I wonder
whether this is solving problems that don't really come up that often?
I don't think it's getting out of hand at all. I see a clear end to the
current design process. I'd hate to make a "standard" that doesn't
address all the various needs of every different floppy format and then
end up having to extend the standard later or not have it adopted due to
it's limited usefulness. We have the ability right now to think, argue,
recommend, specify and commit and so we might as well try to do it as
rightly as possible.
Having something which treats floppies as a black box,
like Teledisk, is
handy in some circumstances, but I already dislike Teledisk because it gets
you in the silly situation of being unable to reproduce the disk even on
the machine for which it is intended. In this regard, an open standard is
Well, we are trying to create an archive standard that does allow a
physical disk to be re-created from an archive.
a big step up from Teledisk, but now that means that
in order to reproduce
a floppy on its native machine, you have to grab the spec and write a big
disk copier utility for that machine, which knows how to parse text tags
(please tell me I misunderstood that part) and double-check header formats
to make sure they're really vanilla. All instead of simply writing the
contiguous binary data out in the native format.
What I envision is that the software component on the target machine will
only require the following abilities:
a) read floppy in logical or raw format
b) write floppy in logical or raw format
c) send/receive archive data over a serial or parallel port
I envision all the post- and pre-processing will be done on a more modern
host, such as a standard PC running Linux or whatnot. I would never want
the processing done on the target machine, especially if this standard
turns into a big messy markup language.
Once this standard is close to complete I intend to develop either a Linux
or DOS-based demo archival application as well as the utility software for
the Apple ][ to evaluate the workability of the standard before it is
committed to.
I think a nice compromise might be to represent each
floppy disk with
two files, one of which contains all the data as a straight binary
image in whatever's the most sensible order for that machine, which
would be convenient for use on the original machine (not to mention
emulators), and the other one contains all the fancy headers and
sector descriptors, with pointers into the binary image. That would
This is a circular specification. What you need in order to create a
"no-nonsense" archive IS the standard we are attempting to define, because
every machine will invariably have some wacky formats that won't allow a
sensible, straight-forward archive to be made. This needs to be taken
into account.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
9:39 a.m.
John Wilson wrote:
Hard or soft head number? I feel sure I ran into a
format (Commodore?) where
the sector headers had the opposite head numbers to the side on which they
were actually recorded.
Sellam Ismail <foo(a)siconic.com> wrote:
I know that's true on the Apple ][. Side
"1" is actually the backside of
the diskette and vice versa.
I have no idea what you mean by that. The Apple ][ disk format has no
concept of "side". There's no field in the address mark for a side
designation.
9:08 a.m.
On 1 Jun 2000, Eric Smith wrote:
Sellam Ismail <foo(a)siconic.com> wrote:
Of course not. But because of the head orientation on Apple disk drives,
the backside of the disk is what actually holds the "side 1" data.
Say for instance you had a bad sector on a "one-sided" diskette caused by
a physical defect and you looked at the front surface of the disk through
the head notch looking for the defect. You wouldn't see it. You'd have
to flip the disk over to see the defect.
But of course, you knew this :)
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
I know that's true on the Apple ][. Side
"1" is actually the backside of
the diskette and vice versa.
I have no idea what you mean by that. The Apple ][ disk format has no
concept of "side". There's no field in the address mark for a side
designation.
11:38 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 961 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000602/ce763b76/at…
10:28 a.m.
On Thu, Jun 01, 2000 at 01:08:47PM -0700, Sellam Ismail wrote:
Then the machine descriptor would reflect the actual
machine that the
software was designed to run on.
Who says it's software? What if it's a data disk? Or a totally unknown one?
Or something that's portable (e.g. an interpreted language). It just seems
like it could cause trouble if the image were hard-wired to claim it's
from one particular place. Especially if they get
tagged incorrectly, then
utilities which *could* read the disk will refuse, and ones
which *can't*
will screw themselves up trying because they believe the header.
I'd hate to make a "standard" that
doesn't
address all the various needs of every different floppy format and then
end up having to extend the standard later or not have it adopted due to
it's limited usefulness.
The opposite extreme is to not have it adopted because it's too complex to
be practical. It's definitely a good thing to anticipate future needs, but
I wouldn't get too hung up with the notion that this format will be all
things to all people. There will always be a few oddballs out there which
won't fit the framework, whatever it is.
We have the ability right now to think, argue,
recommend, specify and commit and so we might as well try to do it as
rightly as possible.
Absolutely, that's why I jumped in. I've written a bunch of floppy
utilities, and picturing extending any of them to work with verbose tagged
free-form text files with redundant header descriptors and lots of magic
numbers, is giving me a headache. One aspect of doing it right, is doing
it so that it can be implemented cleanly.
I envision all the post- and pre-processing will be
done on a more modern
host, such as a standard PC running Linux or whatnot. I would never want
the processing done on the target machine, especially if this standard
turns into a big messy markup language.
Careful, this is a *very* common pitfall these days. "I'll just assume
that everyone in the world has access to the same modern hardware and
software that I do."
This was my point about Teledisk (especially since it's a bit flakey even
on a real PC). If I have a Pro/350 and I want to write a DECmate II disk,
there's no technical reason why I can't do it (the low-level format is the
same so it's trivial), so why create an artificial limitation by depending
on a big complicated C program which doesn't run on the Pro?
This is a circular specification. What you need in
order to create a
"no-nonsense" archive IS the standard we are attempting to define, because
every machine will invariably have some wacky formats that won't allow a
sensible, straight-forward archive to be made. This needs to be taken
into account.
IMHO, that's *their* problem. If a disk format is so weird that there isn't
even any way to decide what would come first in a binary snapshot, then *that*
format should have a big tangled mass of header descriptors etc. But that
doesn't mean that *every* format needs to have a hairy wad of descriptors
intermingled with the data.
As an analogy, I *really* like the Kermit file transfer protocol.
It's designed to be a very good compromise between capability and ease of
implementation. There are lots of possible bells and whistles but most of
the time you can get away without them. It has a few basic assumptions which
don't hold true for *all* systems (files are a linear sequence of 8-bit bytes,
filenames can be represented in ASCII, the serial line can pass any ASCII
printing character through), but they fit the vast majority of real systems.
It works around most of the common problems in file transfer, but it's simple
enough that you can write a basic native Kermit implementation for almost
any architecture in a few days.
John Wilson
D Bit
10 a.m.
On Thu, 1 Jun 2000, John Wilson wrote:
I don't imagine anyone will be attempting to create a multi-gigabyte
archive on a Sinclair ZX80. The point is this archive will be carried
forward onto ever more powerful computers, and limiting it to be feasible
on technology that has long been passed by makes no sense to me.
Linux will run on a 386, a 68K Mac, an Atari ST, and the Amiga. I'm
satisfied with that.
Who says it's software? What if it's a data
disk? Or a totally
unknown one? Or something that's portable (e.g. an interpreted
language). It just seems like it could cause trouble if the image
were hard-wired to claim it's from one particular place. Especially
if they get tagged incorrectly, then utilities which *could* read the
disk will refuse, and ones which *can't* will screw themselves up
trying because they believe the header.
In that case perhaps we can have generic group meta codes, such as "CP/M",
etc.
The opposite extreme is to not have it adopted because
it's too complex to
be practical. It's definitely a good thing to anticipate future needs, but
I wouldn't get too hung up with the notion that this format will be all
things to all people. There will always be a few oddballs out there which
won't fit the framework, whatever it is.
Yes, but in it's current iteration it is not very complex at all.
Detailed, yes. Complex, no. It's being designed to allow a very simple,
straight foward archive to be created in the case of no special
considerations (i.e. a "standard" floppy disk) while still being powerful
enough to allow a very bizarre format to be described as well. I think
the balance is being achieved.
Absolutely, that's why I jumped in. I've
written a bunch of floppy
utilities, and picturing extending any of them to work with verbose tagged
free-form text files with redundant header descriptors and lots of magic
numbers, is giving me a headache. One aspect of doing it right, is doing
it so that it can be implemented cleanly.
Agreed.
I envision all
the post- and pre-processing will be done on a more modern
host, such as a standard PC running Linux or whatnot. I would never want
the processing done on the target machine, especially if this standard
turns into a big messy markup language.
Careful, this is a *very* common pitfall these days. "I'll just assume
that everyone in the world has access to the same modern hardware and
software that I do." This was my point about Teledisk (especially since
it's a bit flakey even
on a real PC). If I have a Pro/350 and I want to write a DECmate II disk,
there's no technical reason why I can't do it (the low-level format is the
same so it's trivial), so why create an artificial limitation by depending
on a big complicated C program which doesn't run on the Pro?
Take the specification and write an archive application that will run on
the Pro/350. As stated above, the standard as it is being defined is not
difficult to implement. And as I mentioned before, I'm considering
writing a DOS application to implement the standrad once it's near
completion. The point is I don't see this as a legitimate concern. The
standard is not currently constructed to require a computer with gobs of
memory, even if it does evolve into a markup language.
IMHO, that's *their* problem. If a disk format is
so weird that there isn't
even any way to decide what would come first in a binary snapshot, then *that*
format should have a big tangled mass of header descriptors etc. But that
doesn't mean that *every* format needs to have a hairy wad of descriptors
intermingled with the data.
I agree, and the way I am seeing the standard evolve will not require
massive headers for standard formatted disks. It may not look like it now
but that is what is in the back of my mind as we move forward with this.
We're still really in the gathering phase so don't get frustrated just
yet.
As statedin so many words before, the standard will be designed
intelligently enough to archive a standard diskette in a simple, straight
forward manner, but also allow the complexity to archive a completely
non-standard diskette.
As an analogy, I *really* like the Kermit file
transfer protocol. It's
designed to be a very good compromise between capability and ease of
implementation. There are lots of possible bells and whistles but
most of the time you can get away without them. It has a few basic
assumptions which don't hold true for *all* systems (files are a
linear sequence of 8-bit bytes, filenames can be represented in ASCII,
the serial line can pass any ASCII printing character through), but
they fit the vast majority of real systems. It works around most of
the common problems in file transfer, but it's simple enough that you
can write a basic native Kermit implementation for almost any
architecture in a few days.
We'll try to develop this standard in the same spirit.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
11:45 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 1037 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000602/88cccad7/at…
30 May
30 May
4:07 p.m.
On Tue, 30 May 2000, Dwight Elvey wrote:
It was not specifically mentioned but I also think
we should archive a method to boot strap the machine
from ground zero, were this can be done with things
like front panels or ROM monitors. I realize that this
This is useful, however I think it is a totally different endeavor.
As was stated by others, the
media for archiving needs to be in a currently common
format that is supported by todays machines. It has
also been generally recognized that it should be occasionally
brought up to date by moving to newer media. It is my
It was always my assumption (and I thought it was a fairly obvious one)
that the archives would be stored on either hard drives or CD ROM or
whatever modern day media makes sense. I would not store the archives on
floppies, although that is entirely up to whomever wants to create an
archive. Where the archive gets stored is not of concern to the standard.
The standard is simply there to provide a common, DOCUMENTED format by
which we store archived floppy diskettes.
As was mentioned, even in CPM, part of the OS might
be in a file. This means that the method of saving
must include the ability to link a number of pieces
that were not necessarily tied together as a single
data stream.
Which is why one would archive the diskette as a whole, as opposed to
getting into high levels and attempting to interpret the data on the
diskette. We don't want to do that. We just want to look at the disk as
a bunch of bytes and archive the whole thing.
Another thing that wasn't talked about was
CRC's. Even
though most media has built in CRC's, there is no way
to detect a failure in the communications between the
new and old media. I suggest that this be at least a
two level CRC. The first level would be on small blocks
of data that the CRC could do error correction on with
a reasonable burst size compared to the block size.
The next level would have a larger CRC with a burst correction
size that would be greater than two times the lower
levels CRC. This last level of CRC would have several
Good point. I hadn't considered error checking. That can be added to the
header.
I also doubt, that most people realize that there
are
other types of data encoding than MFM and FM. Intels
M2FM comes to mind, as well as the Apple format. It was
stated that people felt that it would not be practical
to make a piece of hardware that could read any arbitrary
format. I contend that as long as that format could
have been read or written through that drive that a
simple DSP chip could be used to make a universal controller
chip. Vary little hardware, other than a simple development
board, would be needed. I find it hard to believe that
That would certainly be one way to do it, but I think it's more feasible
to attempt to do this by a combination of using the actual hardware and
the software that does the archiving. The usefulness of archiving old
diskettes is to make them available in perpetuity. Whether we are
archiving them so that we can always create a physical disk from the
archive to run on the original machine or use the archive as a "virtual
diskette" for an emulator, having an actual disk image archived on a long
term storage medium is my goal.
To show the variety of things, the machine I'm
working on
has two sectors per track of 20480 bits. This is on
32 hard sectored media. It is regular FM, though.
And the standard we are trying to define would be able to accomodate such
a funky format!
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
31 May
31 May
1:37 a.m.
At 09:07 PM 5/30/00 -0700, Sellam Ismail wrote:
That would certainly be one way to do it, but I think
it's more feasible
to attempt to do this by a combination of using the actual hardware and
the software that does the archiving. The usefulness of archiving old
diskettes is to make them available in perpetuity. Whether we are
archiving them so that we can always create a physical disk from the
archive to run on the original machine or use the archive as a "virtual
diskette" for an emulator, having an actual disk image archived on a long
term storage medium is my goal.
I agree. Before we get too deep in the details of the file format
(XML? Whew, so cutting edge. I was hoping for a simple tagged
format, with plenty of extensibility) it might be good to consider
how this file format will be used. Emulators, yes. Simple command
line tools to create disk images and manipulate files, yes. Simple
enough that an antique computer could read sectors and emit this
file format out the serial or parallel port, sure.
Never mind Emily Litella.
- John
30 May
30 May
10:50 p.m.
New subject: HPFS 386 HELP!
My warp4 machine ate it'self the other day. At restart it runs checkdisk,
indicates that it has relocated information stored on a bad sector then says
it cannot continue. After this the driver reports that the disk is dirty and
needs to be checked in order to function.
I pulled the drive and mounted it on another machine I have which is running
an identical version and service level of warp 4. It is also running
HPFS386. Checkdisk/F gives the same error as it does when I try to boot the
disk on the machine it belongs to.
The drive passes diagnostics. I am running Linux from another partition right
now (it was a dual-boot OS/2, Linux drive but OS/2 won't boot now....).
I've searched the web like crazy for more advanced tools which will work on an
HPFS386 filesystem to no avail. Any help is appreciated.
Thanks in advance
Jeff
(technoid(a)cheta.net)
31 May
31 May
2:08 a.m.
New subject: HPFS 386 HELP!
Sounds like there might be a bad block in the FAT, or superblock, or
whatever OS/2 calls it. If bootcode or FAT information gets corrupt there
isn't a whole lot you can do about it. You could try hooking it up to a
linux machine and mount it read-only to get your files off. If the FAT is
corrupt the only way to get the drive back is a low level format.
----- Original Message -----
From: "Technoid Mutant" <Technoid(a)cheta.net>
To: <classiccmp(a)classiccmp.org>
Sent: Wednesday, May 31, 2000 6:50 AM
Subject: HPFS 386 HELP!
My warp4 machine ate it'self the other day. At
restart it runs checkdisk,
indicates that it has relocated information stored on a bad sector then
says
it cannot continue. After this the driver reports that
the disk is dirty
and
needs to be checked in order to function.
I pulled the drive and mounted it on another machine I have which is
running
an identical version and service level of warp 4. It
is also running
HPFS386. Checkdisk/F gives the same error as it does when I try to boot
the
disk on the machine it belongs to.
The drive passes diagnostics. I am running Linux from another partition
right
now (it was a dual-boot OS/2, Linux drive but OS/2
won't boot now....).
I've searched the web like crazy for more advanced tools which will work
on an
HPFS386 filesystem to no avail. Any help is
appreciated.
Thanks in advance
Jeff
(technoid(a)cheta.net)
2:26 a.m.
New subject: Finds
Cheapo bonanza! Grabbed a TRS-80 Model 100 Portable, in the deluxe hard case
with tape drive and accoustic coupler modem for $5! Works like a charm.
Snagged a Network General "The Sniffer" Protocol
Analyzer, looks to be a modified Compaq Portable II, can't find any info on
the sniffer program though (NAI bought out Network General, and doesn't take
kindly to supporting older apps) Also grabbed a stripped RS/6000 320H for
$1, a few odd cables, and a loaded Sun SPARCStation 10 for $25 (It was in
with the SPARC 1's, so someone must have missed the 0, I know I did :) Good
luck hunting!
2:31 a.m.
New subject: Finds
Cheapo bonanza! Grabbed a TRS-80 Model 100 Portable,
in the deluxe hard case
with tape drive and accoustic coupler modem for $5! Works like a charm.
Snagged a Network General "The Sniffer" Protocol
Analyzer, looks to be a modified Compaq Portable II, can't find any info on
the sniffer program though (NAI bought out Network General, and doesn't take
kindly to supporting older apps)
A great grab. It's a great tool for ethernet troubleshooting.
Also grabbed a stripped RS/6000 320H for $1
Good
machine -- but a bit slow.
, a few odd cables, and a loaded Sun SPARCStation 10
for $25 (It was in
with the SPARC 1's, so someone must have missed the 0, I know I did :) Good
luck hunting!
A Sparcstation 10 -- Fantastic. Got to find something like that for
Solaris 8.
Bill
--
bpechter(a)monmouth.com | Microsoft: Where do you want to go today?
| Linux: Where do you want to go tomorrow?
| BSD: Are you guys coming, or what?
5:32 a.m.
New subject: Finds
A Sparcstation 10 -- Fantastic. Got to find something
like that for
Solaris 8.
Will 8 run on a 10, my wife wants a home system to play with instead of the
E250 she has at the office, and told me she needs at least a 5 (which is a
much newer system than a 10 or 20 right?).
5:10 a.m.
New subject: Finds
::Will 8 run on a 10, my wife wants a home system to play with instead of the
::E250 she has at the office, and told me she needs at least a 5 (which is a
::much newer system than a 10 or 20 right?).
Speaking of finds, I'd love to find a girlfriend who even knows what a
Sparc 5 is. *sigh* ;-)
--
----------------------------- personal page: http://www.armory.com/~spectre/ --
Cameron Kaiser * Point Loma Nazarene University * ckaiser(a)ptloma.edu
-- Do you think I could buy back my introduction to you? -- Groucho Marx ------
5:12 a.m.
New subject: Finds
Mike Ford wrote:
Will 8 run on a 10, my wife wants a home system to
play with instead of the
E250 she has at the office, and told me she needs at least a 5 (which is a
much newer system than a 10 or 20 right?).
It's not age, it's architecture. The 4c family (1, 1+, 2, SLC/ELC/IPC/IPX)
are not supported, but the 4m (5, 10 and 20 -- the 10 and 20 in both
SuperSparc and HyperSparc) are supported.
Saftey Hint: If upgrading from 7 to 8 *do not* blindly start with
the "Solaris 8 Installation" CD -- it is the road to damntaion.
Boot "Solaris 8 Software, 1 of 2" and you won't spend two hours
questioning the parentage of the people responsible as I did.
--
Chris Kennedy
chris(a)mainecoon.com
http://www.mainecoon.com
PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97
5:51 a.m.
New subject: Finds
A Sparcstation
10 -- Fantastic. Got to find something like that for
Solaris 8.
Will 8 run on a 10, my wife wants a home system to play with instead of the
E250 she has at the office, and told me she needs at least a 5 (which is a
much newer system than a 10 or 20 right?). 
7:21 a.m.
New subject: Finds
I sure wish I could find a Sparc 10 for $25! My Sparc 2 cost me over $200
(although it has the 32MB S-Bus card in it for a total of 96MB :^).
I'll sell you my sparc 2 for $200 any day. Heck, I MIGHT even sell you
my SPARCclassic X (converted back to a SPARCclassic), with 96 meg ram,
for $200... I have too much stuff as it is...
Of course, if anyone is serious, and is interested in some IPX's, I
would definitely consider offers. I have several IPX's. And for the
serously deranged, if you need Sun 3 mice, i'm your man... i have a
small box full of them, something like 25-30 mice or so... No, i dont
have optical mouse pads.
Ah well, I'm digressing from the topic. Nothing good can come of that...
-Lawrence LeMay
7:41 a.m.
New subject: Finds
I sure wish I could find a Sparc 10 for $25! My Sparc 2 cost me over $200
(although it has the 32MB S-Bus card in it for a total of 96MB :^).
I'll sell you my sparc 2 for $200 any day. Heck, I MIGHT even sell you
my SPARCclassic X (converted back to a SPARCclassic), with 96 meg ram,
for $200... I have too much stuff as it is...
Of course, if anyone is serious, and is interested in some IPX's, I
would definitely consider offers. I have several IPX's. And for the
serously deranged, if you need Sun 3 mice, i'm your man... i have a
small box full of them, something like 25-30 mice or so... No, i dont
have optical mouse pads.
Ah well, I'm digressing from the topic. Nothing good can come of that...
-Lawrence LeMay
7:50 a.m.
New subject: Finds
I sure wish I could find a Sparc 10 for $25! My Sparc
2 cost me over $200
(although it has the 32MB S-Bus card in it for a total of 96MB :^).
I really feel sorry for you poor souls lost out in the boonies. Couple
weeks ago I was at a scrap place with TWO pallets of Tatung UltraSparcs
(not $25, but not too bad either. Didn't last long too.). I wish I had
known it was OK to bring a few home.
8:20 a.m.
New subject: Finds
I sure wish I
could find a Sparc 10 for $25! My Sparc 2 cost me over $200
(although it has the 32MB S-Bus card in it for a total of 96MB :^).
I really feel sorry for you poor souls lost out in the boonies. Couple
weeks ago I was at a scrap place with TWO pallets of Tatung UltraSparcs
(not $25, but not too bad either. Didn't last long too.). I wish I had
known it was OK to bring a few home.
9:14 a.m.
New subject: Finds
I don't know, those Ultra 80 Quad 450MHz CPU Boxes look niiiiccceee. You're
right about the overall cost/performance ratio of the older hardware, but
you also have to take into consideration how stable the machines are. Take a
$100 low end SPARCStation and $100 of used pentium hardware. You'd probably
get a faster Pentium machine (Maybe a P-90) but take a close look at the
craftsmanship of the machine. Sun's run FOREVER, they just don't fail due to
shoddy hardware designs. Early Pentium designs were REALLY buggy, even the
later models had nasty bugs (f00f anyone?) I know several companies that
kept their 486 servers, even when they were terribly out of date, because
the 486 design had been battle tested for so many years. Keep in mind that
the performance in price/performance also includes multitasking and
stability concerns.
Well, I didn't just buy it for that, I got it when
that's about what they
were worth. The only reason I payed as much as I did was because of the
SCSI S-Bus card in it.
I *really* want a SS20 w/dual SM71's or SM81's, and something like 192MB
RAM, but then I look at what I can get in an x86 box for that price and
just
shake my head. I might like Sparcs, but x86 is the
only platform Solaris
makes sense on!
Of course my dream Sparc would be a Dual Ultra 2 :^)
Zane
10:08 a.m.
New subject: Finds
I'm actually talking about the fact that for what a nice used Dual Processor
Sparc 20 would cost I can go out and buy a far better NEW Dual Celeron system
(probably a better PIII system, but I've not priced that). The going price
for a Ultra 1 or a Dual Sparc 20 is going to be in the $600-1200 range,
depending on the configuration (and if it includes a monitor).
Sure an Ultra 80 Quad 450MHz would be nice, BUT what's the price performance
to a top of the line Dual Pentium III or Quad Xeon?
Also in both examples I'm talking about using *good* parts, not el'cheapo
trash.
At one point Sun's made sense. However, for home use, and in some/most cases
for business use, they're a horrible value. You can get so much more for so
much less that it isn't funny. Any idea how a 450Mhz Ultra2 CPU compares to
something like a 700Mhz Pentium III? The main reason I can see to go with
UltraSparc is if that's what the apps you need run on, or you need a 64-bit
CPU today.
Trust me, I've argued with myself a *lot* on this :^) The end result is
both Sparc and x86 boxes will run Solaris, so unless you can get a *killer*
deal on a very nice Sparc system you're going to be better off building a
nice Celeron or Pentium III box to run it.
Zane
I don't know, those Ultra 80 Quad 450MHz CPU Boxes
look niiiiccceee. You're
right about the overall cost/performance ratio of the older hardware, but
you also have to take into consideration how stable the machines are. Take a
$100 low end SPARCStation and $100 of used pentium hardware. You'd probably
get a faster Pentium machine (Maybe a P-90) but take a close look at the
craftsmanship of the machine. Sun's run FOREVER, they just don't fail due to
shoddy hardware designs. Early Pentium designs were REALLY buggy, even the
later models had nasty bugs (f00f anyone?) I know several companies that
kept their 486 servers, even when they were terribly out of date, because
the 486 design had been battle tested for so many years. Keep in mind that
the performance in price/performance also includes multitasking and
stability concerns.
Well, I didn't just buy it for that, I got it
when that's about what they
were worth. The only reason I payed as much as I did was because of the
SCSI S-Bus card in it.
I *really* want a SS20 w/dual SM71's or SM81's, and something like 192MB
RAM, but then I look at what I can get in an x86 box for that price and
just
shake my head. I might like Sparcs, but x86 is
the only platform Solaris
makes sense on!
Of course my dream Sparc would be a Dual Ultra 2 :^)
Zane
11:11 a.m.
New subject: Finds
I'm actually talking about the fact that for what a nice used Dual Processor
Sparc 20 would cost I can go out and buy a far better NEW Dual Celeron system
(probably a better PIII system, but I've not priced that). The going price
for a Ultra 1 or a Dual Sparc 20 is going to be in the $600-1200 range,
depending on the configuration (and if it includes a monitor).
At one point Sun's made sense. However, for home use, and in some/most cases
for business use, they're a horrible value. You can get so much more for so
much less that it isn't funny. Any idea how a 450Mhz Ultra2 CPU compares to
something like a 700Mhz Pentium III? The main reason I can see to go with
UltraSparc is if that's what the apps you need run on, or you need a 64-bit
CPU today.
Trust me, I've argued with myself a *lot* on this :^) The end result is
both Sparc and x86 boxes will run Solaris, so unless you can get a *killer*
deal on a very nice Sparc system you're going to be better off building a
nice Celeron or Pentium III box to run it.
Zane
Well, the x86 Solaris doesn't seem as solid as the Sparc version...
(at least at v7... I haven't run v8 yet at home).
And if you support Solaris Sparc at work a home system for a testbed
is a good thing.
And yes, you can't kill Sparc machines or AIX boxes or VaxStations like
you can cheap PC's... although the Seagate in my main Sparcstation20
departmental server did blow chunks on Friday. The 2gb'cuda sounded
like a metal lathe.
> >
> > Zane
Bill
--
bpechter(a)monmouth.com | Microsoft: Where do you want to go today?
| Linux: Where do you want to go tomorrow?
| BSD: Are you guys coming, or what?
11:31 a.m.
New subject: Finds
Bill Pechter wrote:
Well, the x86 Solaris doesn't seem as solid as the
Sparc version...
(at least at v7... I haven't run v8 yet at home).
Eh? I run 2.7 on both Sparc and x86 machines, and both are absolutly
reliable. I have a bunch of customers where Solaris X86 machines are
used in mission critical settings precisely because they're demonstrably
as reliable as Sparc hardware and win hands-down from a price-performance
standpoint. Despite the fact that I'm typing this on my dual hypersparc
running 2.8, the only reason we deploy Sparcs these days is when we're
using third-party code that's only available on the Sparc.
And if you support Solaris Sparc at work a home system
for a testbed
is a good thing.
Yep; that's why I have some of each -- although the number of things that
we work with which are only available for Sparc Solaris are dwindling.
--
Chris Kennedy
chris(a)mainecoon.com
http://www.mainecoon.com
PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97
8:46 a.m.
New subject: SPARC machines wanted (was Re: Finds)
At 11:50 AM 5/31/00 -0800, Mike wrote:
I wish I had known it was OK to bring a few home.
Ok, for all you surplus hounds out there, in my wish list are a
SPARCStation LX and a SPARCServer 1000 w/4 CPUs. I'm pretty sure they are
both 4m architecture although the former was a single CPU only. If you find
one and are wondering if someone could use it, let me know.
--Chuck
9:06 a.m.
New subject: SPARC machines wanted (was Re: Finds)
At 11:50 AM 5/31/00 -0800, Mike wrote:
Well, I'll settle for an LX, or a Classic or a 10 or 20.
I'll be willing to unload an Opus Sparcstation2 clone, Color Montitor,
and IPX and ELC.
Bill
--
bpechter(a)monmouth.com | Microsoft: Where do you want to go today?
| Linux: Where do you want to go tomorrow?
| BSD: Are you guys coming, or what?
I wish I had known it was OK to bring a few home.
Ok, for all you surplus hounds out there, in my wish list are a
SPARCStation LX and a SPARCServer 1000 w/4 CPUs. I'm pretty sure they are
both 4m architecture although the former was a single CPU only. If you find
one and are wondering if someone could use it, let me know.
--Chuck
9:26 a.m.
New subject: SPARC machines wanted (was Re: Finds)
Chuck McManis wrote:
Ok, for all you surplus hounds out there, in my wish
list are a
SPARCStation LX and a SPARCServer 1000 w/4 CPUs. I'm pretty sure they are
both 4m architecture although the former was a single CPU only.
Actually, the SPARCserver 1000 is a 4d. It's on the "may no longer
be supported in a future release" list in the Solaris 8
Hardware Supplement....
--
Chris Kennedy
chris(a)mainecoon.com
http://www.mainecoon.com
PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97
7:49 a.m.
New subject: Finds
A Sparcstation
10 -- Fantastic. Got to find something like that for
Solaris 8.
Will 8 run on a 10, my wife wants a home system to play with instead of the
E250 she has at the office, and told me she needs at least a 5 (which is a
much newer system than a 10 or 20 right?).
30 May
30 May
6:05 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 1689 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000530/f3bd1079/at…
8:34 a.m.
On Tue, 30 May 2000, Tony Duell wrote:
[Odd Apple ][ format]
This 18-sector format provided two benefits: 1)
increased storage space
and 2) a form of copy protection.
In what way is 'copy protection' a benefit? From Broderbund's perspective it was a benefit :)
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
11:06 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 509 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000531/50653dee/at…
31 May
31 May
9:57 a.m.
Sellam wrote:
Broderbund came out with an 18-sector format for the
Apple ][, but in
order for the disk to be readble the first track is encoded as standard
16-sector format.
This 18-sector format provided two benefits: 1) increased storage space
and 2) a form of copy protection.
On some later Infocom titles for the Apple ][ family, they went to two
disk sides, and in order to maximize the amount of data on the second
size (and hence minimize flipping), they went to *one* sector per track.
This does away with the "wasted space" of intersector gaps.
Where they screwed up, though, was in sticking to a single byte of XOR
checksum over the entire "sector". The checksum scheme Apple used was
arguably inadequate for 256-byte sectors; it was truly horrible for
5.5 Kbyte sectors.
9:29 a.m.
On 31 May 2000, Eric Smith wrote:
On some later Infocom titles for the Apple ][ family,
they went to two
disk sides, and in order to maximize the amount of data on the second
size (and hence minimize flipping), they went to *one* sector per track.
This does away with the "wasted space" of intersector gaps.
Interesting. I never came across any of those. It probably also had the
added advantage of allowing for very quick reads.
Do you know of any specific titles that used such formatting? I probably
have a few of the originals and I'd like to check it out.
Where they screwed up, though, was in sticking to a
single byte of XOR
checksum over the entire "sector". The checksum scheme Apple used was
arguably inadequate for 256-byte sectors; it was truly horrible for
>5.5 Kbyte sectors.
Truly.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
10:48 a.m.
I wrote:
On some later Infocom titles for the Apple ][ family,
they went to two
disk sides, and in order to maximize the amount of data on the second
size (and hence minimize flipping), they went to *one* sector per track.
This does away with the "wasted space" of intersector gaps.
Sellam wrote:
Interesting. I never came across any of those. It
probably also had the
added advantage of allowing for very quick reads.
They did denibblize it on-the-fly, which normal RWTS did not. In that
sense, since they sustained the equivalent of 1:1 interleave, it was
pretty good. However, there was no reason why the same performance (but
not density) couldn't be achieved with standard sectors. The Apple ///
SOS disk driver pioneered this, and IIRC Prodos did it as well.
Do you know of any specific titles that used such
formatting? I probably
have a few of the originals and I'd like to check it out.
I'm not 100% certain, but it would be on later titles that used versions
5 and 6 of the Infocom virtual machine to support large game images.
So it was probably used on Beyond Zork, among others.
10:10 a.m.
On 31 May 2000, Eric Smith wrote:
They did denibblize it on-the-fly, which normal RWTS
did not. In that
sense, since they sustained the equivalent of 1:1 interleave, it was
What encoding method did it use? 4&4 or 6&2? I'll assume 6&2?
pretty good. However, there was no reason why the
same performance (but
not density) couldn't be achieved with standard sectors. The Apple ///
SOS disk driver pioneered this, and IIRC Prodos did it as well.
Sure, read the raw track into a buffer in memory and then process it. The
only drawback is the requirement for a relatively large buffer.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
12:21 p.m.
What encoding method did it use? 4&4 or 6&2?
I'll assume 6&2?
6&2.
pretty good.
However, there was no reason why the same performance (but
not density) couldn't be achieved with standard sectors. The Apple ///
SOS disk driver pioneered this, and IIRC Prodos did it as well.
Sure, read the raw track into a buffer in memory and then process it. The
only drawback is the requirement for a relatively large buffer.
3:08 p.m.
On 1 Jun 2000, Eric Smith wrote:
No, the trick (as used in SOS, and in the Lisa I/O
card ROM) is to
do 1:1 interleave *without8 a track buffer. They directly denibblize
as they're reading the bits from the disk.
I didn't think the ][ was fast enough to do that?
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
1 Jun
1 Jun
9:32 a.m.
I wrote:
No, the trick (as used in SOS, and in the Lisa I/O
card ROM) is to
do 1:1 interleave *without8 a track buffer. They directly denibblize
as they're reading the bits from the disk.
Sellam Ismail <foo(a)siconic.com> wrote:
I didn't think the ][ was fast enough to do that?
That's why I called it a "trick".
After all, everyone knows that a 1 MHz 6502 isn't fast enough to do disk
control in software at all! :-) Woz's design is a classic example of
"thinking outside the box". IIRC, he was quoted somewhere as saying
that he didn't previously have any knowledge of the design of disk
controllers, so he just designed what he thought would be necessary.
Once the Intel 8271, WD 1771, and similar FDC chips became available,
any idiot could "design a disk controller". But if you compare Woz's
design with other pre-FDC-chip designs, Woz's has 1/10 as many chips
as some of them.
9:03 a.m.
On 1 Jun 2000, Eric Smith wrote:
After all, everyone knows that a 1 MHz 6502 isn't fast enough to do disk
control in software at all! :-) Woz's design is a classic example of
"thinking outside the box". IIRC, he was quoted somewhere as saying
that he didn't previously have any knowledge of the design of disk
controllers, so he just designed what he thought would be necessary.
But can you dedcode 6&2 encoded bytes in realtime on a 6502? Something
tells me it's not fast enough to do this.
Once the Intel 8271, WD 1771, and similar FDC chips
became available,
any idiot could "design a disk controller". But if you compare Woz's
design with other pre-FDC-chip designs, Woz's has 1/10 as many chips
as some of them.
6 to be exact.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
10:39 a.m.
Sellam Ismail <foo(a)siconic.com> writes:
But can you dedcode 6&2 encoded bytes in realtime
on a 6502? Something
tells me it's not fast enough to do this.
If you're clever enough, you can do it. I previously cited several packages
that did it.
I wrote:
> Once the Intel 8271, WD 1771, and similar FDC
chips became available,
> any idiot could "design a disk controller". But if you compare Woz's
> design with other pre-FDC-chip designs, Woz's has 1/10 as many chips
> as some of them.
Sellam wrote:
6 to be exact.
7 to be exact, if you don't count the boot PROM, which isn't really
part of the disk controller.
10:02 a.m.
On 1 Jun 2000, Eric Smith wrote:
Sellam Ismail <foo(a)siconic.com> writes:
I'll take your word for it.
But can you dedcode 6&2 encoded bytes in
realtime on a 6502? Something
tells me it's not fast enough to do this.
If you're clever enough, you can do it. I previously cited several packages
that did it. Sellam wrote:
Oh well, I usually get the number wrong no matter how many times I look at
a ][ controller. At any rate, it's amazing.
I still maintain that the less than 256 byte Disk ][ boot ROM code is one
of the most amazing pieces of code ever written for a computing device.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
6 to be exact.
7 to be exact, if you don't count the boot PROM, which isn't really
part of the disk controller. 
3:03 p.m.
The Apple ][ floppy controller/6502 doesn't decode the bytes at the
floppy rotation speed. The 6502 copies the encoded bytes (de-serialized
by the controller) into memory, then decodes them after the sector
has been read. The sector interleave guarantees enough time to decode
the data before the next sector is available to be read.
I agree, it is an interesting piece of code...
clint
On Thu, 1 Jun 2000, Sellam Ismail wrote:
On 1 Jun 2000, Eric Smith wrote:
Sellam Ismail <foo(a)siconic.com> writes:
I'll take your word for it.
But can you dedcode 6&2 encoded bytes in
realtime on a 6502? Something
tells me it's not fast enough to do this.
If you're clever enough, you can do it. I previously cited several packages
that did it. Sellam wrote:
Oh well, I usually get the number wrong no matter how many times I look at
a ][ controller. At any rate, it's amazing.
I still maintain that the less than 256 byte Disk ][ boot ROM code is one
of the most amazing pieces of code ever written for a computing device.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
6 to be exact.
7 to be exact, if you don't count the boot PROM, which isn't really
part of the disk controller.
6:01 p.m.
The Apple ][ floppy controller/6502 doesn't decode
the bytes at the
floppy rotation speed. The 6502 copies the encoded bytes (de-serialized
by the controller) into memory, then decodes them after the sector
has been read. The sector interleave guarantees enough time to decode
the data before the next sector is available to be read.
The whole point of this thread is that it *IS* possible for cleverly
written code to do 1:1 interleave without the bounce buffer.
I agree, it is an interesting piece of code...
It's even *more* interesting.
5 Jun
5 Jun
2:45 p.m.
New subject: MSCP Boot Block Code Size for PDP-11 (Was: Defining Disk Image Dump Standard)
Sellam Ismail wrote:
I still maintain that the less than 256 byte Disk ][
boot ROM code is one
of the most amazing pieces of code ever written for a computing device.
Jerome Fine replies:
I am not sure if we are considering the same thing, but the single block
(512 bytes) of code for the secondary MSCP boot program on a PDP-11
(the primary MSCP boot program being the code in the BOOT ROM which
is much less than 256 bytes - actually one that can be entered by hand using
ODT is only 110 bytes) which is on block zero on the hard disk drive of a
PDP-11 for RT-11 is also a squeeze. And while including the mapping table
for eight RT-11 partitions made life difficult (only a 16 word table was used), I
challenge anyone to manage to add the other 56 available partitions and make
all 64 RT-11 partitions allowable for boot purposes since it would seem that
a 128 word mapping table would be required. I don't think it is possible to fit
the rest of the code, data and buffers into just the remaining 128 words even
when just one controller or host adapter is allowed and still manage to utilize
many hard disk drives each with a maximum total of 8 GBytes - obviously
not all physical partitions could be booted from one 64 entry mapping table
since even just one 8 GByte drive has 256 physical partitions (as mentioned
by Tim Shoppa - how do you even keep track of what is on all 256 partitions,
let alone use them all? - envy!!!). But at least with a 64 entry mapping table
in the boot block, all 64 partitions mapped for data use can also be booted
from inside RT-11 using DUP if they have the necessary
system files on
those partitions. The problem is to squeeze an extra 56 entries
into the
mapping table so that DUP can boot all 64 possible partitions (D00: => D77:).
From what I can understand of what the MSCP boot
requires, it is not
possible to do the rest using just the other 128 words for code
and data
(buffers can occupy the same space as the mapping table).
Sincerely yours,
Jerome Fine
3:02 p.m.
New subject: MSCP Boot Block Code Size for PDP-11 (Was: Defining Disk Image Dump Standard)
On Mon, 5 Jun 2000, Jerome Fine wrote:
PDP-11 for RT-11 is also a squeeze. And while
including the mapping
table for eight RT-11 partitions made life difficult (only a 16 word
table was used), I challenge anyone to manage to add the other 56
available partitions and make all 64 RT-11 partitions allowable for
boot purposes since it would seem that a 128 word mapping table would
be required. I don't think it is possible to fit
HA! The Woz's boot code generates the requisite table on the fly!
;)
(but it sounds like we're talking about a different kind of table :)
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See http://www.vintage.org for details!
7 Jun
7 Jun
1:36 a.m.
New subject: MSCP Boot Block Code Size for PDP-11 (Was: Defining Disk Image Dump Standard)
Sellam Ismail wrote:
On Mon, 5 Jun
2000, Jerome Fine wrote:
PDP-11 for RT-11 is also a squeeze. And while including the mapping
table for eight RT-11 partitions made life difficult (only a 16 word
table was used), I challenge anyone to manage to add the other 56
available partitions and make all 64 RT-11 partitions allowable for
boot purposes since it would seem that a 128 word mapping table would
be required. I don't think it is possible to fit
HA! The Woz's boot code
generates the requisite table on the fly! ;)
(but it sounds like we're talking about a different kind of table :)
1 Jun
1 Jun
11:35 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 672 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20000602/da280158/at…
8732
days inactive
8743
days old
103 comments
24 participants
participants (24)
-
ard＠p850ug1.demon.co.uk -
chris＠mainecoon.com -
ckaiser＠oa.ptloma.edu -
CLASSICCMP＠trailing-edge.com -
cmcmanis＠mcmanis.com -
donm＠cts.com -
elvey＠hal.com -
eric＠brouhaha.com -
foo＠siconic.com -
Hans.Franke＠mch20.sbs.de -
healyzh＠aracnet.com -
jbmcb＠hotmail.com -
jfoust＠threedee.com -
jhfine＠idirect.com -
jimw＠agora.rdrop.com -
lemay＠cs.umn.edu -
mikeford＠socal.rr.com -
pechter＠pechter.dyndns.org -
rich＠alcor.concordia.ca -
richard＠idcomm.com -
Technoid＠cheta.net -
vaxman＠uswest.net -
wilson＠dbit.dbit.com -
zmerch＠30below.com