In article <1O46f.7809$GQ.5314@tornado.texas.rr.com>,
Carl Pearson <jman@hal_no_spam_pc.org> wrote:
>Howdy, Group,
>
>Been having a conversation with this guy regarding tape vs disc.
>
>He asked if a hard or floppy disk was more like a tape recorder, or a
>record player.
Neither. A tape recorder and a record player have the same
geometry; Both were one long string of info packets
packaged in a spiral.
>I'm siding with record player, due to tape's inability to have random
>access.
>
>I know, record players are WORM drives, and they don't record with metal
>oxide, but the random access feature seems so important that it
>outweighs tape's next-bit-in-line way of reading data.
>
>(Or, it's at least *as* important. But in my view, if tape could really
>have random access, we wouldn't be using the current much more expensive
>disc drive technology. On another front, imagine the wait time involved
>in getting to the last sector of a 50 terrabyte file with tape!)
Been having a conversation with this guy regarding tape vs disc.
He asked if a hard or floppy disk was more like a tape recorder, or a
record player.
I'm siding with record player, due to tape's inability to have random
access.
I know, record players are WORM drives, and they don't record with metal
oxide, but the random access feature seems so important that it
outweighs tape's next-bit-in-line way of reading data.
(Or, it's at least *as* important. But in my view, if tape could really
have random access, we wouldn't be using the current much more expensive
disc drive technology. On another front, imagine the wait time involved
in getting to the last sector of a 50 terrabyte file with tape!)
And yes, I understand that a traditional analog record player is
actually reading sequentially, (as does tape, further muddying the
distinction between the two), but at least it's *possible* to pick up
the needle & jump straight to another point on the record. With tape
you have to wade through the intervening portions to get to that next
read point.
He keeps claiming that tape *can* have random access. Were this the
case, of course discs would be more like a tape recorder, as the random
vs sequential access argument would be thrown out of the discussion.
Supposing that I am wrong, is there any place one could look to show how
tape could have random access?
I don't mean some backup companies sales text *calling* it random, I
mean the actual ability for a tape to jump straight from one block to
another without moving past all intervening data.
Sure, you can *call* it random if you fast-forward or reverse to the
next block, but there are many examples in our society of folks claiming
something with one term while it really means another.
As a brief example, say you want to go from block 100 to block 200 on a
tape device. How could one possibly do that without having to at least
go past blocks 101 through 199 on your way?
Given the constraints of three-dimensional space, I just don't see how
it can be done.
Good point about the similarity in geometry, I had mentioned that in the
original post.
I think the old DEC drives are what's hanging this guy up, though given
that they held less than a meg of data, I really don't see how they in
any way correspond to a modern disc drive.
jmfbahciv@aol.com wrote:
> In article <1O46f.7809$GQ.5314@tornado.texas.rr.com>,
> Carl Pearson <jman@hal_no_spam_pc.org> wrote:
>> Howdy, Group,
>>
>> Been having a conversation with this guy regarding tape vs disc.
>>
>> He asked if a hard or floppy disk was more like a tape recorder, or a
>> record player.
>
> Neither. A tape recorder and a record player have the same
> geometry; Both were one long string of info packets
> packaged in a spiral.
>
>> I'm siding with record player, due to tape's inability to have random
>> access.
>>
>> I know, record players are WORM drives, and they don't record with metal
>> oxide, but the random access feature seems so important that it
>> outweighs tape's next-bit-in-line way of reading data.
>>
>> (Or, it's at least *as* important. But in my view, if tape could really
>> have random access, we wouldn't be using the current much more expensive
>> disc drive technology. On another front, imagine the wait time involved
>> in getting to the last sector of a 50 terrabyte file with tape!)
>
> DECtapes had random access.
>
> <snip>
>
> /BAH
On Fri, 21 Oct 2005 12:35:17 GMT, Carl Pearson
<jman@hal_no_spam_pc.org> wrote:
>Good point about the similarity in geometry, I had mentioned that in the
>original post.
>
>I think the old DEC drives are what's hanging this guy up, though given
>that they held less than a meg of data, I really don't see how they in
>any way correspond to a modern disc drive.
On Fri, 21 Oct 2005 12:03:09 GMT
Carl Pearson <jman@hal_no_spam_pc.org> wrote:
> He keeps claiming that tape *can* have random access. Were this the
> case, of course discs would be more like a tape recorder, as the random
> vs sequential access argument would be thrown out of the discussion.
Well I have heard of a UNIX file system being mounted directly
from a DEC tape drive - apparently the superblock accesses became very
visible :)
Strictly speaking random access should imply that the time taken
to access any data item is independent of the location of that data item.
A tape is clearly not random access nor is a disc, but a disc is a closer
approximation to random access than a tape.
--
C:>WIN | Directable Mirror Arrays
The computer obeys and wins. | A better way to focus the sun
You lose and Bill collects. | licences available see
| http://www.sohara.org/
"Carl Pearson" <jman@hal_no_spam_pc.org> skrev i en meddelelse
news:1O46f.7809$GQ.5314@tornado.texas.rr.com...
>
> He keeps claiming that tape *can* have random access. Were this the
> case, of course discs would be more like a tape recorder, as the random
> vs sequential access argument would be thrown out of the discussion.
>
Truely random is not possible on a tape, as you (as you said) still have
to
read the blocks inbetween. That you dont _use_ the data for anything, is
beside the point.
Some kind of semi-random is possible, but it is a stretch of the
imagination.
I have come across a program running on a (IIRC) Tandberg streamerdrive.
This drive makes multiple passes when writing the data. When the tape
changes direction, the program (I believe it was a backup program)
remembers
the blocknumber of the first block on the track, together with the name of
the file being written. When the program finishes, all this data is saved
somewhere.
When you then want to restore a specific file, the program checks this
table, and sees on which track it is located. It will then go directly to
the correct track and find the program. However, you can only "jump" whole
tracks. You still have to read past all irrelevant blocks.
[Followups restricted to alt.folklore.computers. My server doesn't
carry "alt.computers", so this is only posted to AFC and
alt.comp.hardware.]
In article <djaicv$8qk_004@s963.apx1.sbo.ma.dialup.rcn.com> , jmfbahciv@aol.com writes:
> In article <1O46f.7809$GQ.5314@tornado.texas.rr.com>,
> Carl Pearson <jman@hal_no_spam_pc.org> wrote:
>
> >I'm siding with record player, due to tape's inability to have random
> >access.
>
> DECtapes had random access.
Yes, but they still were physically sequential devices. The format
was clever and versatile (Mike Ross called it "the floppy disk of its
time" in another post, which seems like a good description), and it
did permit logical random access - but seek times were long (relative
to disk designs), since the tape was basically used as a "long thin
disk".
IMO, for Carl's purposes, DECtape isn't a counterexample; its random
access is logical, not physical, and isn't equivalent to a disk's.
You don't have to read the data you're seeking past, but it has to go
under the head position.
I'd say that by definition a tape device has to be sequential. For
me, the term "tape" refers not only to the physical geometry of the
medium (ie long and thin) but to its notional use - it runs along a
single dimension under a fixed head. If the head can be repositioned
from point A on the tape to point B without passing over the inter-
vening media, then it's not a tape device, as far as I'm concerned.
Pseudoscientific Nonsense Quote o' the Day:
From the scientific standpoint, until these energies are directly
sensed by the evolving perceptions of the individual, via the right
brain, inner-conscious, intuitive faculties, scientists will never
grasp the true workings of the universe's ubiquitous computer system.
-- Noel Huntley
> In article <1O46f.7809$GQ.5314@tornado.texas.rr.com>,
> Carl Pearson <jman@hal_no_spam_pc.org> wrote:
>
>>Howdy, Group,
>>
>>Been having a conversation with this guy regarding tape vs disc.
>>
>>He asked if a hard or floppy disk was more like a tape recorder, or a
>>record player.
>
>
> Neither. A tape recorder and a record player have the same
> geometry; Both were one long string of info packets
> packaged in a spiral.
A better analogy is a blackboard. You can write anywhere
you want in any order that you want.
Carl Pearson wrote:
> Howdy, Group,
>
> Been having a conversation with this guy regarding tape vs disc.
>
> He asked if a hard or floppy disk was more like a tape recorder, or a
> record player.
>
> I'm siding with record player, due to tape's inability to have random
> access.
>
> I know, record players are WORM drives, and they don't record with metal
> oxide, but the random access feature seems so important that it
> outweighs tape's next-bit-in-line way of reading data.
>
> In article <1O46f.7809$GQ.5314@tornado.texas.rr.com>,
> Carl Pearson <jman@hal_no_spam_pc.org> wrote:
> >Howdy, Group,
> >
> >Been having a conversation with this guy regarding tape vs disc.
> >
> >He asked if a hard or floppy disk was more like a tape recorder, or a
> >record player.
>
> Neither. A tape recorder and a record player have the same
> geometry; Both were one long string of info packets
> packaged in a spiral.
But a hard or floppy disk is "more like" a record player, since you
can pick up the tone arm and drop it someplace else on the disk
relatively quickly. With a tape, you have to fast-forward or rewind
past all the data you're not interested in.
> >I'm siding with record player, due to tape's inability to have random
> >access.
> >
> >I know, record players are WORM drives, and they don't record with metal
> >oxide, but the random access feature seems so important that it
> >outweighs tape's next-bit-in-line way of reading data.
> >
> >(Or, it's at least *as* important. But in my view, if tape could really
> >have random access, we wouldn't be using the current much more expensive
> >disc drive technology. On another front, imagine the wait time involved
> >in getting to the last sector of a 50 terrabyte file with tape!)
>
> DECtapes had random access.
Not as the term is normally used. For that matter, disks don't really
have random access (which would be uniform access time to the words of
data regardless of the current location of the head; seek time and
latency keep the disk from being truly random access).
While you could request any block on a DECtape, the time to get that
block was determined by how far away it was from where you currently
were on the tape.
--
Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
Department of Computer Science FAX -- (505) 646-1002
New Mexico State University http://www.cs.nmsu.edu/~pfeiffer
skype: jjpfeifferjr
Nico de Jong wrote:
>
> Truely random is not possible on a tape, as you (as you said) still have
> to
> read the blocks inbetween.
Or not. 3480's have a locate funstion in the control unit that finds a
block by block ID. The CPU doesn't read the data, The CU probably does.
That you dont _use_ the data for anything, is
> beside the point.
>
> Some kind of semi-random is possible, but it is a stretch of the
> imagination.
>
> I have come across a program running on a (IIRC) Tandberg streamerdrive.
> This drive makes multiple passes when writing the data. When the tape
> changes direction, the program (I believe it was a backup program)
> remembers
> the blocknumber of the first block on the track, together with the name of
> the file being written. When the program finishes, all this data is saved
> somewhere.
> When you then want to restore a specific file, the program checks this
> table, and sees on which track it is located. It will then go directly to
> the correct track and find the program. However, you can only "jump" whole
> tracks. You still have to read past all irrelevant blocks.
I believe the Multics backup worked this way. Multics tapes had
software-assigned block numbers, and the backup recorded the starting
block number for each file.
> jmfbahciv@aol.com writes:
>
> [snip...] [snip...] [snip...]
> >
> > DECtapes had random access.
>
> Not as the term is normally used. For that matter, disks don't really
> have random access (which would be uniform access time to the words of
> data regardless of the current location of the head; seek time and
> latency keep the disk from being truly random access).
>
> While you could request any block on a DECtape, the time to get that
> block was determined by how far away it was from where you currently
> were on the tape.
>
Yes, and dynamic RAM memory units are *not* random acess by this criteron.
While the contents of any memory location can be delivered within a specified
maximum time (memory cycle time), the memory units farther from the output
actually take longer to acess, because even electrons traveling at the speed
of
light *do* take time based on the distance traveled.
For me, if I can access a "black box" device to acquire data by giving a file
name,
and I do *not* have to care how the device retrieves that file...then it's
random
access. DECtapes and Stringy Floppies will automatically position the heads
relative
to the tape, and read the requested data. A hard disk or floppy disk will
position the
heads and read the requested data. I don't have to care. I issue the
command...I get
my data.
In article <9g56f.7815$GQ.5408@tornado.texas.rr.com>,
Carl Pearson <jman@hal_no_spam_pc.org> wrote:
Please don't toppost. I've fixed it for you...once.
>jmfbahciv@aol.com wrote:
>> In article <1O46f.7809$GQ.5314@tornado.texas.rr.com>,
>> Carl Pearson <jman@hal_no_spam_pc.org> wrote:
>>> Howdy, Group,
>>>
>>> Been having a conversation with this guy regarding tape vs disc.
>>>
>>> He asked if a hard or floppy disk was more like a tape recorder, or a
>>> record player.
>>
>> Neither. A tape recorder and a record player have the same
>> geometry; Both were one long string of info packets
>> packaged in a spiral.
>>
>>> I'm siding with record player, due to tape's inability to have random
>>> access.
>>>
>>> I know, record players are WORM drives, and they don't record with metal
>>> oxide, but the random access feature seems so important that it
>>> outweighs tape's next-bit-in-line way of reading data.
>>>
>>> (Or, it's at least *as* important. But in my view, if tape could really
>>> have random access, we wouldn't be using the current much more expensive
>>> disc drive technology. On another front, imagine the wait time involved
>>> in getting to the last sector of a 50 terrabyte file with tape!)
>>
>> DECtapes had random access.
>Good point about the similarity in geometry, I had mentioned that in the
>original post.
Not quite. There is the physical geometry and then there is the
paths the heads have to travel before getting to the location
where the data is stored. I think you also are confusing the
two "geometries". I can't recall the term used for the actions
needed to get at a location.
>
>I think the old DEC drives are what's hanging this guy up, though given
>that they held less than a meg of data, I really don't see how they in
>any way correspond to a modern disc drive.
It's not clear to me what your friend is trying to teach himself.
I'll hazard a guess that he's trying to distinguish a "one-way"
device with an "any-way" device. With most magtapes to get at
any set of bits, you started at the beginning of the tape and
kept reading until you hit what you wanted. If the next
set of bits were located "earlier" on the magtape, one had
to rewind the tape to beginning of the tape and start all over
even if the bits you wanted were at the end of the tape.
With a disk or floppy, there are round circle of "tape"; each
circle has a diminishing diameter. So getting at a location
is "faster" because the disks can start at the point where
the last access was done. There are two "ways" these devices
can physically travel to get from here to there; it's rather
like walking around a city on an island whose roads intersect.
I can't tell you a thing about how CDs work; those critters
are magic spinning saucers to me. :-)
Note to others: something just exploded outside; sounded about
a block away and the lights flicked. I may not be online
later.
In article <djb7v4$eef$1@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com>,
Andrew Swallow <am.swallow@btopenworld.com> wrote:
>jmfbahciv@aol.com wrote:
>
>> In article <1O46f.7809$GQ.5314@tornado.texas.rr.com>,
>> Carl Pearson <jman@hal_no_spam_pc.org> wrote:
>>
>>>Howdy, Group,
>>>
>>>Been having a conversation with this guy regarding tape vs disc.
>>>
>>>He asked if a hard or floppy disk was more like a tape recorder, or a
>>>record player.
>>
>>
>> Neither. A tape recorder and a record player have the same
>> geometry; Both were one long string of info packets
>> packaged in a spiral.
>
>A better analogy is a blackboard. You can write anywhere
>you want in any order that you want.
Yours is better but I think the one I just posted is better
than yours. It takes lots of tries to get a good
description so that our unwashed ;-) can begin to understand.
In article <1bfyqug2i9.fsf@viper.cs.nmsu.edu>,
Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
>jmfbahciv@aol.com writes:
>
>> In article <1O46f.7809$GQ.5314@tornado.texas.rr.com>,
>> Carl Pearson <jman@hal_no_spam_pc.org> wrote:
>> >Howdy, Group,
>> >
>> >Been having a conversation with this guy regarding tape vs disc.
>> >
>> >He asked if a hard or floppy disk was more like a tape recorder, or a
>> >record player.
>>
>> Neither. A tape recorder and a record player have the same
>> geometry; Both were one long string of info packets
>> packaged in a spiral.
>
>But a hard or floppy disk is "more like" a record player, since you
>can pick up the tone arm and drop it someplace else on the disk
>relatively quickly.
For reads, sure. But I didn't think a floppy was a single stream
of bits. A record player position (if it's not started at
the beginning) is a hit and miss type of seek. You can reduce
the time of the seek by starting in the middle but you still have
read everything after that to get the data you want.
> ..With a tape, you have to fast-forward or rewind
>past all the data you're not interested in.
Those were added "features" to smooth operator feathers :-).
But you still had to start somewhere before the spot you
wanted and then sequentially walk down the track.
>
>> >I'm siding with record player, due to tape's inability to have random
>> >access.
>> >
>> >I know, record players are WORM drives, and they don't record with metal
>> >oxide, but the random access feature seems so important that it
>> >outweighs tape's next-bit-in-line way of reading data.
>> >
>> >(Or, it's at least *as* important. But in my view, if tape could really
>> >have random access, we wouldn't be using the current much more expensive
>> >disc drive technology. On another front, imagine the wait time involved
>> >in getting to the last sector of a 50 terrabyte file with tape!)
>>
>> DECtapes had random access.
>
>Not as the term is normally used. For that matter, disks don't really
>have random access (which would be uniform access time to the words of
>data regardless of the current location of the head; seek time and
>latency keep the disk from being truly random access).
Yea, I thought about that term when I typed it but left it in.
I've probably drifted the thread by being this careless.
>
>While you could request any block on a DECtape, the time to get that
>block was determined by how far away it was from where you currently
>were on the tape.
But you could backup and stop and then rocker arm the tape
until you find the location. Magtape drives didn't seem
to have this ability. I never understood why that function
didn't get into them.
In article <20051021144030.4fc4794c.steveo@eircom.net>,
Steve O'Hara-Smith <steveo@eircom.net> wrote:
>On Fri, 21 Oct 2005 12:03:09 GMT
>Carl Pearson <jman@hal_no_spam_pc.org> wrote:
>
>> He keeps claiming that tape *can* have random access. Were this the
>> case, of course discs would be more like a tape recorder, as the random
>> vs sequential access argument would be thrown out of the discussion.
>
> Well I have heard of a UNIX file system being mounted directly
>from a DEC tape drive - apparently the superblock accesses became very
>visible :)
I recall a case where a -10 was run from a DECtape to make room
for a program and data that couldn't fit. It took all night
and stand alone to do the computing job.
>
> Strictly speaking random access should imply that the time taken
>to access any data item is independent of the location of that data item.
>A tape is clearly not random access nor is a disc, but a disc is a closer
>approximation to random access than a tape.
We're not talking about any old tape, but a DECtape.
> In article <20051021144030.4fc4794c.steveo@eircom.net>,
> Steve O'Hara-Smith <steveo@eircom.net> wrote:
> > Strictly speaking random access should imply that the time taken
> >to access any data item is independent of the location of that data item.
> >A tape is clearly not random access nor is a disc, but a disc is a closer
> >approximation to random access than a tape.
>
> We're not talking about any old tape, but a DECtape.
Not even a DECtape achieved anything like constant time to find
a word.
--
C:>WIN | Directable Mirror Arrays
The computer obeys and wins. | A better way to focus the sun
You lose and Bill collects. | licences available see
| http://www.sohara.org/
Peter Flass wrote:
> I believe the Multics backup worked this way. Multics tapes had
> software-assigned block numbers, and the backup recorded
> the starting block number for each file.
Not to my knowledge. Yes, Multics standard tape format had
a block number in each block, and the tape DIM noticed an error if
the number was not monotone increasing. It did not provide
this block number to its caller, and the hierarchy backup
software did not record the block number in the dump map,
and the retriever/reloader software did not try fancy positioning
tricks to find a particular file.
The tape format described in http://www.multicians.org/mspm-bb-3-01.html
had some cool attributes though. If an error occurred when writing
a tape block, the tape DIM just wrote the block again, with the
same block number. To read a block, it read until past the desired
block. This meant that while a tape was reading, an operator could
put the drive in standby, dismount the tape, mount it on another
drive, switch unit numbers, and ready the new drive: and the
tape DIM would notice the block number mismatch, resynch, and
continue> reading without indicating an error.
Multics tape format was also specified to have a single tape mark
every 128 blocks, so that spacing forward to a given record number
would be fast. We never used this feature and I think after a while
eliminated it: it just made it difficult to copy a Multics tape on a
360.
Carl Pearson <jman@hal_no_spam_pc.org> writes:
>Howdy, Group,
>
>Been having a conversation with this guy regarding tape vs disc.
>
>He asked if a hard or floppy disk was more like a tape recorder, or a
>record player.
>
>I'm siding with record player, due to tape's inability to have random
>access.
Of course the LGP-30 had main memory AND the accumulator on DRUM, and
addresses were NOT sequentially assigned. A good programmer located
his working storage so that it could be most often fetched in the same
revolution as the instruction, then fetch the next instruction wihout
wasting a whole revolution of the drum. There was a chart showing what
memory locations could be accessed from an instruction at any location,
without losing a revolution. It had 4096 words of memory, IIRC.
Don't modern tape drives have multiple tracks, going to the end and
back multiple times, so if you want to get to something 95% through the
complete linear image, you only have to scan down one track part way to
get it, not through 95% of the data?
'sqrfolkdnc' worte, in part:
| Of course the LGP-30 had main memory AND the accumulator on DRUM, and
| addresses were NOT sequentially assigned.
_____
While I never worked with an LGP-30, though I helped get replacement systems
for it up and running. In 1965-66 Pittsburgh Plate Glass Company replaced
the LGP-30 in each of their 5 paint plants with Univac 1050 systems (24 to
32 K 6-bit core memory.) I remember discussions of placing data and
instructions to avoid rotational delay. For the 1050 replacements we had
severe memory limitations even with the much larger size; we used very
complex instructions (that took a very long time to execute) to compress the
code. The main I/O was 800 bit-per-inch tape; even sequential access was
slow.
Phil Weldon
"sqrfolkdnc" <carey.schug@gmail.com> wrote in message
news:1130603164.345010.260910@g14g2000cwa.googlegr oups.com...
| Of course the LGP-30 had main memory AND the accumulator on DRUM, and
| addresses were NOT sequentially assigned. A good programmer located
| his working storage so that it could be most often fetched in the same
| revolution as the instruction, then fetch the next instruction wihout
| wasting a whole revolution of the drum. There was a chart showing what
| memory locations could be accessed from an instruction at any location,
| without losing a revolution. It had 4096 words of memory, IIRC.
|
| Don't modern tape drives have multiple tracks, going to the end and
| back multiple times, so if you want to get to something 95% through the
| complete linear image, you only have to scan down one track part way to
| get it, not through 95% of the data?
|
sqrfolkdnc wrote:
> Of course the LGP-30 had main memory AND the accumulator on DRUM, and
> addresses were NOT sequentially assigned. A good programmer located
> his working storage so that it could be most often fetched in the same
> revolution as the instruction, then fetch the next instruction wihout
> wasting a whole revolution of the drum. There was a chart showing what
> memory locations could be accessed from an instruction at any location,
> without losing a revolution. It had 4096 words of memory, IIRC.
>
In message <OTS8f.28348$Bv6.232@twister.nyroc.rr.com>, Peter Flass
<Peter_Flass@Yahoo.com> writes
>
>sqrfolkdnc wrote:
>> Of course the LGP-30 had main memory AND the accumulator on DRUM, and
>> addresses were NOT sequentially assigned. A good programmer located
>> his working storage so that it could be most often fetched in the same
>> revolution as the instruction, then fetch the next instruction wihout
>> wasting a whole revolution of the drum. There was a chart showing what
>> memory locations could be accessed from an instruction at any location,
>> without losing a revolution. It had 4096 words of memory, IIRC.
>>
>
>Sounds like the IBM 650.
>
My recollection is that IBM 650 drum had sequential addresses. Ferranti
Pegasus drum had addresses in a sequence arranged so as to optimise
continuous reading of 8-word blocks.
--
Michael J Kingston
In article <NZyVADDV+LZDFA$R@digweed2.demon.co.uk>,
Michael J Kingston <mike.kingston@digweed2.demon.co.uk> wrote:
>In message <OTS8f.28348$Bv6.232@twister.nyroc.rr.com>, Peter Flass
><Peter_Flass@Yahoo.com> writes
>>
>>sqrfolkdnc wrote:
>>> Of course the LGP-30 had main memory AND the accumulator on DRUM, and
>>> addresses were NOT sequentially assigned. A good programmer located
>>> his working storage so that it could be most often fetched in the same
>>> revolution as the instruction, then fetch the next instruction wihout
>>> wasting a whole revolution of the drum. There was a chart showing what
>>> memory locations could be accessed from an instruction at any location,
>>> without losing a revolution. It had 4096 words of memory, IIRC.
>>>
>>
>>Sounds like the IBM 650.
>>
>My recollection is that IBM 650 drum had sequential addresses. Ferranti
>Pegasus drum had addresses in a sequence arranged so as to optimise
>continuous reading of 8-word blocks.
Could you be confusing retrieval addressing and physcial addressing?
There is a huge difference.
Part of the art of writing disk device drivers is to
arrange the retrieval/storage addressing so that the
physical specs of the device don't interfere with
efficiency. This is where the seek times, revolution
rates and controller specs are used.
jmfbahciv@aol.com wrote:
> Part of the art of writing disk device drivers is to
> arrange the retrieval/storage addressing so that the
> physical specs of the device don't interfere with
> efficiency. This is where the seek times, revolution
> rates and controller specs are used.
recnet posting in bit.listserv.bim-main on redoing the implementation
for multiple transfers per revolution http://www.garlic.com/~lynn/2005s.html#22 MVCIN instruction
one was redoing the cp67 implemention supporting the 2301 "drum"
increasing the peak 4k page transfers from about 80/sec to 300/sec. the
other was the handling of the 3330 disk when trying to do sequential
transfers of 4k pages that might reside on different track ... but at
the same arm/cyl. position.
i also did some further stuff when doing the page mapped filesystem
support ... playing games with re-ordering requests for optimal
revolution and arm motion ... even when the requests were originally
presented in some totally different ordering. recent post in the same
referenced thread http://www.garlic.com/~lynn/2005s.html#25 MVCIN instruction
note that the cms filesystem i/o was something left over from real i/o
paradigm ... that then had to be simulated in a virtual memory
environment. the "simulation" process would execute the disk i/o in the
order pass to it. the changes for page mapping allowed the i/o ordering
to be re-organized for optimal execution. some more on that subject http://www.garlic.com/~lynn/2005s.html#28 MVCIN instruction
Michael J Kingston wrote:
> In message <OTS8f.28348$Bv6.232@twister.nyroc.rr.com>, Peter Flass
> <Peter_Flass@Yahoo.com> writes
>
>>
>> sqrfolkdnc wrote:
>>
>>> Of course the LGP-30 had main memory AND the accumulator on DRUM, and
>>> addresses were NOT sequentially assigned. A good programmer located
>>> his working storage so that it could be most often fetched in the same
>>> revolution as the instruction, then fetch the next instruction wihout
>>> wasting a whole revolution of the drum. There was a chart showing what
>>> memory locations could be accessed from an instruction at any location,
>>> without losing a revolution. It had 4096 words of memory, IIRC.
>>>
>>
>> Sounds like the IBM 650.
>>
> My recollection is that IBM 650 drum had sequential addresses. Ferranti
> Pegasus drum had addresses in a sequence arranged so as to optimise
> continuous reading of 8-word blocks.
I think that's correct, but what I was alluding to was that each 650
instruction included the drum (disk?) address of the "next" instruction.
I guess it must have been quite an art to organize your program so that
the system was ready for the next instruction just as that location
passed under the R/W head so as not to lose a rotation.
>>> Of course the LGP-30 had main memory AND the accumulator on DRUM, and
>>> addresses were NOT sequentially assigned. A good programmer located
>>> his working storage so that it could be most often fetched in the same
>>> revolution as the instruction, then fetch the next instruction wihout
>>> wasting a whole revolution of the drum. There was a chart showing what
>>> memory locations could be accessed from an instruction at any location,
>>> without losing a revolution. It had 4096 words of memory, IIRC.
I played with a LGP-21 for a while: same architecture, etc.
but transistorized and a fixed head single surface disk PLATTER instead of a drum.
The 4 "registers" were continuously read/written on the outermost tracks
by heads that were a word apart.
Yes, the disk was used as a delay line,
kinda like the way 3-head tapes read/erase/record.
That led me to appreciate what my dad said about drum programming
and the marvels of "SOAP": the self-optimizing assembler.
And a deeper appreciation of "The Story Of Mel".
Re: Random Access Tape? 
Linear Mode
