27 Apr
2013
27 Apr
'13
7:49 a.m.
All;
I'm curious as to what other manufacturers/systems supported the use of
block-oriented magnetic tape media along the lines of the DECtape (TU56)
and DECassette (TU60) drives.
In particular, what about the use of standard 1/2" tape media under such
circumstances? A wear-n-tear problem given the multi-pass nature of this
use (especially if being used to store temp-files for the OS), but if that
scenario were avoided ...
I'd like to play around with some, but acquiring either a DECtape or
DECassette unit looks to be somewhere between impossible and merely
seriously unaffordable -- not to mention obtaining media for use with
either. So I'm thinking about whether there are possibly other drives out
there for which I might construct a suitable controller to mediate between
the raw(er) mechanism and the OS.
Unlike a streaming tape unit I'd expect that a major consideration would be
keeping the moment-of-inertia of the reels as low as possible, consistent
with holding a sufficiently long tape at sufficient bit-density to achieve
an economically-viable amount of storage per tape (*e.g*., 256Kb --
DECtape was 184K 12-bit words or 144K 18-bit words).
DEC managed it; did anyone else?
(Of course, if anyone has a lead on a DEC unit -- DECtape preferred -- I'm
very interested.)
Thanks for your thoughts!
-----
paul
27 Apr
27 Apr
12:11 p.m.
On 27 April 2013 10:49, Paul Birkel <pbirkel at gmail.com> wrote:
All;
I'm curious as to what other manufacturers/systems supported the use of
block-oriented magnetic tape media along the lines of the DECtape (TU56)
and DECassette (TU60) drives.
Well, there is LINCtape, which DECtape is a modified derivative of
(and which DEC even made drives of, see the DEC made LINCs, LINC-8 and
PDP-12). There's also DECtape II (TU58), which is the thing that
everyone and their mother has an emulator for (it's the one that plugs
into a serial port, and holds 256KB on a tape).
Correct me if I'm wrong, but TU60 DECassette isn't a block format
media like the DECtape or DECtape II.
In particular, what about the use of standard
1/2" tape media under such
circumstances? A wear-n-tear problem given the multi-pass nature of this
use (especially if being used to store temp-files for the OS), but if that
scenario were avoided ...
That's why DECtape (the original) was rather thick and had much
redundancy of its tracks (two copies of all the tracks), same as
LINCtape did it; though I do believe that the LINCtape did have the
format different, LINCtape also ran "backwards" to DECtape.
I'd like to play around with some, but acquiring
either a DECtape or
DECassette unit looks to be somewhere between impossible and merely
seriously unaffordable -- not to mention obtaining media for use with
either. So I'm thinking about whether there are possibly other drives out
there for which I might construct a suitable controller to mediate between
the raw(er) mechanism and the OS.
TU58 DECtape II, all it needs is a serial port; it's compact, and the
protocol of the controllers is relatively well documented. You can
find all sorts of implementations of DECtape II; ranging from the real
thing, to the "we made a small bit of IC and flash look like a pair of
DECtape IIs", to "what hardware? My PC *IS* the drive."
Fun fact about the software emulation of the DECtape II, is that there
is no limit on the size (beyond the addressable range of the protocol
of course). Hilariously, you *CAN* boot RT-11 off of a DECtape II that
thinks it's the size of an RL02 pack... Being it's running off a
serial port, it's as fast as you would think it is. (At least no
rewind time like on the actual DECtape II!)
I'm rambling, so I'm going to apply the magical power of "shutting up"
now.
Cheers,
Christian Gauger-Cosgrove
28 Apr
28 Apr
2:51 a.m.
On Sat, Apr 27, 2013 at 3:11 PM, Christian Gauger-Cosgrove <
captainkirk359 at gmail.com> wrote:
Anyone have one of the "real things" lying around with which they'd care to
part, along with some media?
On 27 April 2013 10:49, Paul Birkel <pbirkel at
gmail.com> wrote:
Right. I was subconsciously lumping them with "regular" DECtape.
All;
I'm curious as to what other manufacturers/systems supported the use of
block-oriented magnetic tape media along the lines of the DECtape (TU56)
and DECassette (TU60) drives.
Well, there is LINCtape, which DECtape is a modified derivative of
(and which DEC even made drives of, see the DEC made LINCs, LINC-8 and
PDP-12). There's also DECtape II (TU58), which is the thing
that
everyone and their mother has an emulator for (it's the one that plugs
into a serial port, and holds 256KB on a tape).
Ah, cartridge-based. I was thinking about the open-reel (really ancient
:->) drives.
Correct me if I'm wrong, but TU60 DECassette
isn't a block format
media like the DECtape or DECtape II.
I stand corrected WRT the TU60, as the TA11 controller states "Capacity:
Full tape 93,000 bytes minimum; with 256 byte blocks, 87,000 bytes minimum.
Subtract 300 bytes for each file gap." but also "Data format: Variable
block length, 1 byte minimum, no maximum, hardware-formatted with length
software-controlled".
So it's more like a blocked form of standard sequential access than DECtape
(which has a timing/format track enabling pseudo-random access). It does
appear as if one can seek to a specific data file based on counting file
gaps (and one can "Space Reverse/Forward Block" as well as "Space
Reverse/Forward File"), but if you want to lay down new content then one
has to rewrite the entire tape (or possibly append to the end if room
remains). I presume that in combination with the block-level CRC the
"Space Reverse/Forward Block" enables sufficient error-handling.
Thanks for keeping me straight!
In particular,
what about the use of standard 1/2" tape media under such
circumstances? A wear-n-tear problem given the multi-pass nature of this
use (especially if being used to store temp-files for the OS), but if
that
scenario were avoided ...
That's why DECtape (the original) was rather thick and had much
redundancy of its tracks (two copies of all the tracks), same as
LINCtape did it; though I do believe that the LINCtape did have the
format different, LINCtape also ran "backwards" to DECtape.
I'd like to play around with some, but
acquiring either a DECtape or
DECassette unit looks to be somewhere between impossible and merely
seriously unaffordable -- not to mention obtaining media for use with
either. So I'm thinking about whether there are possibly other drives
out
there for which I might construct a suitable
controller to mediate
between
the raw(er) mechanism and the OS.
TU58 DECtape II, all it needs is a serial port; it's compact, and the
protocol of the controllers is relatively well documented. You can
find all sorts of implementations of DECtape II; ranging from the real
thing, to the "we made a small bit of IC and flash look like a pair of
DECtape IIs", to "what hardware? My PC *IS* the drive."
Fun fact about the software emulation of the DECtape
II, is that there
is no limit on the size (beyond the addressable range of the protocol
of course). Hilariously, you *CAN* boot RT-11 off of a DECtape II that
thinks it's the size of an RL02 pack... Being it's running off a
serial port, it's as fast as you would think it is. (At least no
rewind time like on the actual DECtape II!)
I'm rambling, so I'm going to apply the magical power of "shutting up"
now.
Heck no, keep 'em coming :->.
Cheers,
Christian Gauger-Cosgrove
1:34 p.m.
The Ferranti Atlas (1962) had block addressable magnetic tapes:
"The tape mechanism used on Atlas is the Ampex TM2 (improved FR 300) using
one inch wide magnetic tape. There are sixteen tracks across the tape -
twelve information tracks, two clock tracks, and two tracks used for
reference purposes. The tapes are used in a fixed-block, pre-addressed mode.
Information is stored on tape in blocks of 512 forty-eight bit words,
together with a twenty-four bit checksum with end around carry. Each block
is preceded by a block address and block marker and terminated by a block
marker; the leading block address is sequential along the tape, and what is
effectively the trailing block address is always zero. Tapes are tested and
pre-addressed by special routines before being put into use, and the fixed
position of the addresses permits selective overwriting and simple omission
of faulty patches on the tape. Blocks can be read when the tape is moving
either in the forward or reverse direction, but writing is only possible
when the tape is moving forward. The double read and write head is used to
check read when writing on the tape. When not operating the tape stops with
the read head midway between blocks."
Quoted from
The Atlas Supervisor
T Kilburn, R B Payne, D J Howarth
1962
Of course, these drives and media are likely to be even harder to obtain (to
say the least!) than DECtape :)
While on the subject of Atlas and referencing another thread on this list it
would be a /real/ challenge to implement on an FPGA -
Not for the lack of circuit diagrams (I understand several copies still
exist)
Not for the use of "wired-or" (don't know if Atlas used this logic
technique, but several later Ferranti machines did)
But because it used asynchronous logic which is contrary to the design
philosophy of FPGAs (and almost all other modern logic for that matter)
Andy
29 Apr
29 Apr
7:36 a.m.
On 4/28/2013 2:34 PM, Andy Holt wrote:
While on the subject of Atlas and referencing another
thread on this list it
would be a /real/ challenge to implement on an FPGA -
Not for the lack of circuit diagrams (I understand several copies still
exist)
Not for the use of "wired-or" (don't know if Atlas used this logic
technique, but several later Ferranti machines did)
But because it used asynchronous logic which is contrary to the design
philosophy of FPGAs (and almost all other modern logic for that matter)
It justs fucks up the timing routines. I have allways thought the async
logic requires glitch free gates, and that may be a problem.
Andy
Ben.
8:59 a.m.
On Apr 29, 2013, at 10:36 AM, ben <bfranchuk at jetnet.ab.ca> wrote:
On 4/28/2013 2:34 PM, Andy Holt wrote:
Yes, the static timing analyzers are really built for synchronous
designs. You can do asynchronous logic with glitches, but you
then have to carry a strobe with you, which almost defeats the
point. There's an FPGA company called Achronix whose first FPGA
offerings claimed to be reaping the benefits of clockless logic,
but I don't see that anywhere in their literature now (their name
still belies their origins, though).
Clockless logic is something that comes up now and then in ASIC
and FPGA circles, but it never seems to pan out (I remember Sun
doing something with it about a decade ago as well). I don't
know if it's because the tools are too hard to design or what,
but there must be some reason it never comes to anything (or at
least hasn't since the late '60s).
- Dave
While on the subject of Atlas and referencing
another thread on this list it
would be a /real/ challenge to implement on an FPGA -
Not for the lack of circuit diagrams (I understand several copies still
exist)
Not for the use of "wired-or" (don't know if Atlas used this logic
technique, but several later Ferranti machines did)
But because it used asynchronous logic which is contrary to the design
philosophy of FPGAs (and almost all other modern logic for that matter)
It justs fucks up the timing routines. I have allways thought the async
logic requires glitch free gates, and that may be a problem.
9:02 a.m.
On Apr 29, 2013, at 11:59 AM, David Riley <fraveydank at gmail.com> wrote:
Yes, the static timing analyzers are really built for
synchronous
designs. You can do asynchronous logic with glitches, but you
then have to carry a strobe with you, which almost defeats the
point. There's an FPGA company called Achronix whose first FPGA
offerings claimed to be reaping the benefits of clockless logic,
but I don't see that anywhere in their literature now (their name
still belies their origins, though).
Whoops, spoke too soon. They're still talking about it.
http://www.achronix.com/technology/picopipe.html
Wonder how well it integrates with traditional HDLs. I've never
actually worked with Achronix devices, but they certainly seem to
occupy the high end and have things like 100Gbps Ethernet hard
IP MAC cores built in; that's some pretty serious stuff.
- Dave
10:30 a.m.
Probably the "big daddy" of all of the block-addressable tape systems
would be the Control Data SCROLL device. Never made it to production
and mentioned here only:
http://special.lib.umn.edu/findaid/xml/cbi00080-07.xml
There might be other mentions in publications of the time (ca. 1971-75);
I know that it was attached as boilerplate for several proposals that I
worked on.
Basically, a very wide tape, where between the supply and takeup spools
was positioned a head-per-track spinning drum, with the tape being
wrapped, VHS-style, around the drum. The block accessed by the head
could be accessed by simply moving the tape under the heads.
Another one of those whacky ADL projects, I never saw an operating one,
but doubtless there are patents on it. Maybe CHM has some documents on
it--and the STAR Drum, a freaky ultra-high-speed drum spinning on
magnetic bearings in vacuo.
Were the tapes used in the IBM 3850 block-addressable?
--Chuck
10:45 a.m.
Found a mention of CDC SCROLL here:
http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA034437
A few other interesting large-storage devices described as well. By
1975, SCROLL was a dead project.
--Chuck
12:56 p.m.
On 4/29/2013 8:59 AM, David Riley wrote:
On Apr 29, 2013, at 10:36 AM, ben <bfranchuk at
jetnet.ab.ca> wrote:
There is an IBM1130 CPU that is accurately implemented using
asynchronous logic in a standard FPGA.
See: http://ibm1130.blogspot.com/
This technique is probably not for the timid.
Rob.
On 4/28/2013 2:34 PM, Andy Holt wrote:
Yes, the static timing analyzers are really built for synchronous
designs. You can do asynchronous logic with glitches, but you
then have to carry a strobe with you, which almost defeats the
point. There's an FPGA company called Achronix whose first FPGA
offerings claimed to be reaping the benefits of clockless logic,
but I don't see that anywhere in their literature now (their name
still belies their origins, though).
Clockless logic is something that comes up now and then in ASIC
and FPGA circles, but it never seems to pan out (I remember Sun
doing something with it about a decade ago as well). I don't
know if it's because the tools are too hard to design or what,
but there must be some reason it never comes to anything (or at
least hasn't since the late '60s).
While on the subject of Atlas and referencing
another thread on this list it
would be a /real/ challenge to implement on an FPGA -
Not for the lack of circuit diagrams (I understand several copies still
exist)
Not for the use of "wired-or" (don't know if Atlas used this logic
technique, but several later Ferranti machines did)
But because it used asynchronous logic which is contrary to the design
philosophy of FPGAs (and almost all other modern logic for that matter)
It justs fucks up the timing routines. I have allways thought the async
logic requires glitch free gates, and that may be a problem.
1:11 p.m.
On Apr 29, 2013, at 3:56 PM, Rob Doyle <radioengr at gmail.com> wrote:
On 4/29/2013 8:59 AM, David Riley wrote:
I think the 360/30 FPGA (http://www.ljw.me.uk/ibm360/vhdl/) does the
same. To be clear, it's DOABLE on an FPGA, but the timing analyzers
don't like it very much. Add to that the fact that the built-in
flip flops are strictly edge triggered in most technologies and you
have a hard time doing something as simple as an RS latch (some of
the true CPLDs around, like Xilinx's CoolRunner line, still have
true RS options available, but they're very small).
In general, if you're looking to implement something that was
originally designed around asynchronous logic in a modern FPGA,
you're generally better off trying to figure out how to make it run
with synchronous logic instead of implementing it 100% faithfully to
the schematic. A lot of the time, it's actually not particularly
hard to do; for example, microprocessor RD and WR lines often
implicitly act as clocks, which you can use to your advantage when
coding bus interfaces that use them.
- Dave
Clockless logic is something that comes up now
and then in ASIC
and FPGA circles, but it never seems to pan out (I remember Sun
doing something with it about a decade ago as well). I don't
know if it's because the tools are too hard to design or what,
but there must be some reason it never comes to anything (or at
least hasn't since the late '60s).
There is an IBM1130 CPU that is accurately implemented using
asynchronous logic in a standard FPGA.
See: http://ibm1130.blogspot.com/
This technique is probably not for the timid. 
30 Apr
30 Apr
3:41 p.m.
On 29/04/13 21:11, David Riley wrote:
On Apr 29, 2013, at 3:56 PM, Rob Doyle <radioengr
at gmail.com> wrote:
The speed of the /30 is so
much lower than the capability of the FPGA
(1.5MHz vs 50MHz) that it wasn't really an issue. However, I have gone
On 4/29/2013 8:59 AM, David Riley wrote:
I think the 360/30 FPGA
(http://www.ljw.me.uk/ibm360/vhdl/) does the
same. To be clear, it's DOABLE on an FPGA, but the timing analyzers
don't like it very much. Add to that the fact that the built-in
flip flops are strictly edge triggered in most technologies and you
have a hard time doing something as simple as an RS latch (some of
the true CPLDs around, like Xilinx's CoolRunner line, still have
true RS options available, but they're very small). Clockless logic is something that comes up now
and then in ASIC
and FPGA circles, but it never seems to pan out (I remember Sun
doing something with it about a decade ago as well). I don't
know if it's because the tools are too hard to design or what,
but there must be some reason it never comes to anything (or at
least hasn't since the late '60s).
There is an IBM1130 CPU that is accurately implemented using
asynchronous logic in a standard FPGA.
See: http://ibm1130.blogspot.com/
This technique is probably not for the timid. from asynchronous S/R FFs and transparent latches to
synchronous
(edge-triggered) versions running from the global 50MHz clock (so
effectively the same thing, but with a 0-20ns delay). I think this has
got rid of a some inconsistent behaviour, possibly caused by routing
delays which change from build to build.
In general, if you're looking to implement something that was
originally designed around asynchronous logic in a modern FPGA,
you're generally better off trying to figure out how to make it run
with synchronous logic instead of implementing it 100% faithfully to
the schematic. A lot of the time, it's actually not particularly
hard to do; for example, microprocessor RD and WR lines often
implicitly act as clocks, which you can use to your advantage when
coding bus interfaces that use them.
- Dave
I didn't want to get into redesigning things to work synchronously, but
if I wanted to crank the speed up then I would have to. Luckily there
is no reason to make it run faster!
For anyone that's interested in a progress report, I'm currently working
on a SD card interface to emulate the 2311 (7MB) drives, using Hercules
CKD files. So far the SD/SDHC interface is working, and it can mount
the FAT16/32 filesystem, find the CKD files in the root directory, and
read the first cluster. Next step is the cluster chaining and CKD file
parsing. Everything is in VHDL inside the same Spartan3 FPGA as the CPU.
--
Lawrence Wilkinson lawrence at ljw.me.uk
The IBM 360/30 page http://www.ljw.me.uk/ibm360
29 Apr
29 Apr
3:39 p.m.
New subject: Asynchronous logic, was ? Re: Block-oriented Magnetic Tape Drives
On 04/29/2013 08:59 AM, David Riley wrote:
Yes, the static timing analyzers are really built for synchronous
designs. You can do asynchronous logic with glitches, but you
then have to carry a strobe with you, which almost defeats the
point. There's an FPGA company called Achronix whose first FPGA
offerings claimed to be reaping the benefits of clockless logic,
but I don't see that anywhere in their literature now (their name
still belies their origins, though).
Is this an accidental a cross-post from the FPGA-SIMH discussion? If
not, I can't figure out how the subject of block-addressable tape swung
around to embrace the subject of clockless logic.
Wasn't the Philco System 2000 an asynchronous system? And weren't there
certain bipolar multipliers (TRW?) that operated clocklessly and had a
"done" status line?
Just trying to remember.
--Chuck
2 May
2 May
2:56 p.m.
While on the subject of Atlas and referencing another
thread on this list it
would be a /real/ challenge to implement on an FPGA -
Not for the lack of circuit diagrams (I understand several copies still
exist)
Not for the use of "wired-or" (don't know if Atlas used this logic
technique, but several later Ferranti machines did)
But because it used asynchronous logic which is contrary to the design
philosophy of FPGAs (and almost all other modern logic for that matter)
You can model than in synchronous logic as well. I'm very sure.
More important question: Is there anyone out there having the computer to hook
up the simulated tape system?!?
:-)
--
Dipl.-Inf. (FH) Philipp Hachtmann
Buchdruck, Bleisatz, Spezialit?ten
Alemannstr. 21, D-30165 Hannover
Tel. 0511/3522222, Mobil 0171/2632239
Fax. 0511/3500439
hachti at hachti.de
www.tiegeldruck.de
UStdID DE 202668329
27 Apr
27 Apr
2:24 p.m.
On 04/27/2013 10:49 AM, Paul Birkel wrote:
All;
I'm curious as to what other manufacturers/systems supported the use of
block-oriented magnetic tape media along the lines of the DECtape (TU56)
and DECassette (TU60) drives.
You forgot TU58, 256K per drive x 2 drives using preformatted DC100 size
tapes.
In particular, what about the use of standard
1/2" tape media under such
circumstances? A wear-n-tear problem given the multi-pass nature of this
use (especially if being used to store temp-files for the OS), but if that
scenario were avoided ...
I'd like to play around with some, but acquiring either a DECtape or
DECassette unit looks to be somewhere between impossible and merely
seriously unaffordable -- not to mention obtaining media for use with
either. So I'm thinking about whether there are possibly other drives out
there for which I might construct a suitable controller to mediate between
the raw(er) mechanism and the OS.
Tu58s are around, the usual problem si dead capstan roller but they can be
remade easily using a peice of flexible plastic (Tygon) tubing.
Tapes can be found and the interface is serial line using a protocal for
commands and data packets.
There are TU58 emulators for PCs as well.
Unlike a streaming tape unit I'd expect that a major consideration would be
keeping the moment-of-inertia of the reels as low as possible, consistent
with holding a sufficiently long tape at sufficient bit-density to achieve
an economically-viable amount of storage per tape (*e.g*., 256Kb --
DECtape was 184K 12-bit words or 144K 18-bit words).
DEC managed it; did anyone else?
I'm certain there were many others but not any I tended to play with
being DEC based.
Allison
9:52 p.m.
On 04/27/2013 10:49 AM, Paul Birkel wrote:
All;
I'm curious as to what other manufacturers/systems supported the use of
block-oriented magnetic tape media along the lines of the DECtape (TU56)
and DECassette (TU60) drives.
There was a bunch in QIC-format, including Apple. 3M sold not only
blank tapes, but "<Greek Letter>-mat" preformatted tapes (e.g. Kappamat,
Iotamat, Zetamat...) Some of these tapes did not use optical BOT/EOT
sensing, but rather patterns on a preformatted tape. I have a 3M-made
ADIC drive that is such a beast.
--Chuck
28 Apr
28 Apr
11:22 a.m.
All;
I'm curious as to what other manufacturers/systems supported the use of
block-oriented magnetic tape media along the lines of the DECtape (TU56)
and DECassette (TU60) drives.
One example that springs to my mind (although somewhat later -- mid
1980s) are the HP9142, 9144 and 9145 drives. These took QIC cartridges,
the HP9142 using stnadard DC600 tapes, the toer 2 using special
pre-formatted tapes (which I am told were actualyl sort-of stnadard at
the time)
These drives have internal controllers with an HPIB host interface and
accept the SS/80 or CS/80 command set IIRC. The first 2 units contain a
6809 processor and a couple of ASICs for data handling. The last one has
a 68000 (!) iside.
-tony
11:34 a.m.
All;
I'm curious as to what other manufacturers/systems supported the use of
block-oriented magnetic tape media along the lines of the DECtape (TU56)
and DECassette (TU60) drives.
Just rememebred another HP one, the HP82161. This takes special
cassettes, a bit liek a Philips Minicassette (not a microcassette), but
not quite the same (the minicassettes do not fit). It has an HPIL host
interface and uses something called the 'Filbert Protocol' (FIlbert beign
the code name for the HP82161) which is reasonably well docuemanted.
-tony
4252
days inactive
4257
days old
17 comments
11 participants
participants (11)
-
ajp166＠verizon.net -
andyh＠andyh-rayleigh.freeserve.co.uk -
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
captainkirk359＠gmail.com -
cclist＠sydex.com -
cctech＠ljw.me.uk -
fraveydank＠gmail.com -
hachti＠hachti.de -
pbirkel＠gmail.com -
radioengr＠gmail.com