Random Access Tape?

'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" wrote in message
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.


Sounds like the IBM 650.

In message , Peter Flass
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 ,
Michael J Kingston wrote:
In message , Peter Flass
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.

/BAH

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 , Peter Flass
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".

In article ,
Steve O'Hara-Smith wrote:
On Fri, 21 Oct 2005 12:03:09 GMT
Carl Pearson 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


That's how Pyramid would install their dual Universe Unix OS/x and
DC/OSx (the SysVR4 Mips one)... We'd make a ROFS tape (Read Only File
Sytem) and load it up and boot it.

The shoeshine motion when doing directory lookups and file loads was
fun to look at but it did hold up the install a bit.

The trick was to minimize the contents of the ROFS system to the minimum
instruction needed to install the OS. My labs in training also included
my tips on making a recovery ROFS tape with your own site goodies like
password file, group file and any local important binaries on it so the
dump image past the ROFS tape could be a fully customized backup of your
site in case of disaster.

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.

The thing is it was real hard carrying around a 1.2gb 8" SMD drive
as a load device so tape was it (before CD and DVD).

Actually, the worst tape to do the ROFS on was the 1/4 inch QIC SCSI 150
mb tapes... slow... so verrrrrry slow...


--
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/

Bill


--
--
d|i|g|i|t|a|l had it THEN. Don't you wish you could still buy it now!
pechter-at-ureachtechnologies.com

On Tue, 22 Nov 2005 22:06:01 -0600
(Bill Pechter) wrote:

Actually, the worst tape to do the ROFS on was the 1/4 inch QIC SCSI 150
mb tapes... slow... so verrrrrry slow...

I am astonished it was even possible - I can imagine the noise
though

--
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/

In article ,
Steve O'Hara-Smith wrote:
On Tue, 22 Nov 2005 22:06:01 -0600
(Bill Pechter) wrote:

Actually, the worst tape to do the ROFS on was the 1/4 inch QIC SCSI 150
mb tapes... slow... so verrrrrry slow...

I am astonished it was even possible - I can imagine the noise
though

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


Actually pretty silent on the HP88780 (IIRC) 800/1600/6250 bpi streamer
drive.

The anoyance was minimal because of a reasonable tape speed and density
at 1600/6250... But the 1/4 streamer SCSI QIC-150... ugh.

Bill
--
--
d|i|g|i|t|a|l had it THEN. Don't you wish you could still buy it now!
pechter-at-ureachtechnologies.com