> From: Paul Koning
> RSTS/E of course has a bunch of new stuff in it to deal with mapping,
> but the bulk of the code carries over from RSTS-11.
I was assuming that the basic intermal environment was sufficiently different
that not a lot of the OS-level code could carry over, but I guess not.
DId you actually work on RSTS-11 internals (I don't know your exact dates at
DEC), or did you just read the source?
And speaking of which, are any RSTS-11 sources still extant? I found the RSTS
directory on BitSavers, but it seems to have only manuals.
Noel
I'm trying to figure out what were the earliest Type numbers for 3M ?-inch reel-to-reel computer tape
As best I can find, 3M began marketing a Type 777 computer tape about 1967. The Type 700 appears to be somewhat later. But 3M sold computer tape directly to at least government customers (e.g. NSA, Social Security) in the 1950s. The also notably OEMed tape to IBM who rebranded it under an IBM label until the late 1960s at which point with the help of Sony IBM began manufacturing its own computer tape.
Anyone have any idea of the Type number for 3M computer tapes earlier than Type 777?
There might be a place for some of these older Types at the CHM if anyone knows of any still in existence.
Tom
PS: There is a lot of information on 3M audio tape Type numbers as at http://www.aes.org/aeshc/docs/3mtape/aorprod-cust.pdf but computer tape seems to be an orphan
Please copy cctalk/cctech on any responses to Peter.
J
From: Peter Dick <peter at balvine.com>
Sent: Saturday, June 27, 2020 4:34 PM
To: jwest at classiccmp.org
Subject: RSTS/E has just had its 50th Birthday...
Hi. I stumbled on your wonderful PDP11.ORG website.
As I expect you know, RSTS was ?born? on 11th June 1970 as shown when you print DATE$(1%) with Star Date format selected.
This means RSTS/E, the Greatest Operating System ever, has just turned 50 years old.
We would like to mark this historic moment by collecting a total of 50 memories from those of us who used RSTS/E at some time, obviously the earlier the better. Or if you are still running old Basic Plus code, then the later the better! I will then collate these memories and email them out to everyone who takes part.
What memories? It doesn?t matter. Funny / technical / life changing / surprise / show how times have changed / whatever ?
Length? It doesn?t matter. Your name will be included but not your email address unless you specifically want it included.
Please email contributions to 50years at silverware.co.uk <mailto:50years at silverware.co.uk>
Bye/P
Peter Dick, ex Chairman DECUS UK RSTS SIG.
> The file is empty.
Not much I go do except stop trying and advise people to ignore all this.
I've just downloaded the file from my site, and it is NOT empty
and does work.
I did notice a small bug, if you specify names not in it's database
it doesn't tell you, and produces no output. I have corrected it.
Dave
--
----------------------------------------------------------------------------------
Personal site: http://dunfield.maknonsolutions.com
----------------------------------------------------------------------------------
The PROM in my 9114B committed suicide this morning, letting the magic smoke out. It was marked with part number 09114-15521, does anyone happen to have dumped the contents so I can program a new one? Thanks.
Thanks JayI'm am not trying to use DS/1000 just trying to get the 7974 loader going.Grant
-------- Original message --------Grant wrote....------------------------Hi all, i am looking for a loader rom set for my 21mx and does not seem tobe around at the usual places, I am hoping to find a leed.Here is what i am in need of.12992L consisting of12992-8001191740-8007091740-8007191740-80072there is a set of 91740 on bit savers but with a suffix of 67-69 ?------------------------Pretty sure I have a binary copy of all known 12992's, the ones I use I justburn out to a set of blanks. The 7974 loader rom uses the boot loaderextension firmware for DS/1000. Are you actually running ds/1000?? I haven'tseen anyone get that up and running.I'll see if I can dig up the bin (or an already burned chipset).J
This eBait item:
https://www.ebay.com/itm/202989416368
has a number of VAX-11/785 manuals, including /785 Hardware User's Guide. A
bit outside my scope, but /785 docs are very rare (Bitsvers only has prints)
so a VAX person should grab this and then scan them.
Noel
As part of my project to create a Field Programmable Gate Array
implementation (FPGA) of the IBM 1410 Data Processing System based on
Automated Logic Diagrams (ALDs), I decided to look at using the
Instructional Logic Diagrams (ILDs) to guide my testing, rather than
using the ALDs directly.
The ILDs are written completely in ?positive logic?. Going in, I sort of
expected a pretty imperfect match ? that the ILDs would not have all the
signals, and be somewhat superficial in their treatment of the logic.
For the IBM 1410, the circuits were:
AND, OR, Inverter, Indicator (Lamp), Single Shot,
Latch (Reset/Set), Trigger (Flip Flop)
To my surprise I found that the ILDs are *VERY* accurate, and a great
testing guide, providing a second view of the logic ? a kind of
redundancy check against my entry of ALD data into my system. They are
good enough that they have given me considerable confidence that I can
use them to help ?fill in the blanks? related to the handful of ALD
pages I am missing, and also for some of the IBM 1414 peripheral
controllers for which I do not have ALDs.
In 1962 IBM published an article in the IEEE Transactions ?Information
Processing ? from Engineering Drawing to Manufacture? by R. K. Grim that
describes how the data the ended up generated ALDs was entered and the
ALDs produced, but it does not mention where the ILDs come from. They
are definitely artwork ? not machine generated per se. The article did
not address ILDs.
I have corresponded with IBM to see if they might have, in their
archives, the data from these 1960s era engineering systems, but it
seems that they do not (or have lost the pointers to them.)
It seems that the SMS automation was first done using an IBM 709, then
they later added IBM 7090 and IBM 1401 systems (which of course could
not have been there for the original design of the IBM 7090 and 1401,
which used the SMS system), using tape files. The article also describes
future plans to use a 1301 disk drive attached to an IBM 1410 for remote
(tele-processing) access (which was supported by the IBM 1410-PR155
operating system.
The accuracy of the ILDs is such that I expect that they evolved along
with the design of the machine and entry of the data used for the ALDs.
I?d expect that doing it after the fact, from the ALDs, would be quite
error prone ? besides the one difference I have found is in the signal
names, which do not always exactly match those used in the ALDs, but are
close enough that the intent is obvious. But I don?t know the timing:
which came first ? the ILDs or the ALDs, or did they perhaps begin
together in some form and co-evolve?
In summary, it seems to me that one could do a pretty decent positive
logic implementation of IBM machines of that era using these ILDs. This
was a real eye-opener.
If there are any old-time IBMers that read this, I'd love to hear any
enlightening information or stories about this process.
JRJ
A friend kindly searched and found an interesting paper from 1973,
Programming by semantic refinement
<https://dl.acm.org/doi/abs/10.1145/390014.808298> JB Morris - ACM SIGPLAN
Notices, 1973 - dl.acm.org.
https://dl.acm.org/doi/pdf/10.1145/390014.808298
While an interesting paper, it's going the opposite direction (essentially,
going from an English language description down to a final programming
language).
But, using the L1 (highest level language), L2, ..., Ln (lowest level
language) concept, I can phrase my concept better ... so ...
Most programmers write at, say, the level of L3.
They might write something like:
mem [foo].head = something
My "raising the semantic level" would be:
#define HEAD(x). mem [x].head
...
HEAD (foo) = something
With a fair set of macros like that (HEAD, TAIL, etc), the program is now
effectively written in a "new" language, L2 (a higher level language than
L1).
Being written in L2, the resulting code is more readable to everyone,
partially because they aren't continually seeing the implementation of how
".head" / "mem" work/interact.
In effect, the programmer has added a feature (linked list handling,
perhaps) to L3 ... for that particular program, seemingly extending/raising
the level of the language.
It's that concept that I thought I saw sometime in the early 1970s :)
thanks,
Stan
I have the urge to get my Amiga?s back up and running. I?m still trying to find my main Amiga A3000, but have found my A500 and my A600. The problem is, I don?t remember the last time I powered these on. It?s been a long time since I?ve had time. In the case of the A3000, I think it?s been about 17 years. My Atari TT030 has been even longer. :-(
Any advice about powering them up?
Of course another fun challenge will be to figure out where on earth all my Amiga floppies are.
Zane
>this tool is really similar to "rdfind", which compares file sizes and
>content, independently from file name, and is able to create a list of
>correspondence, delete duplicate files, and create symbolic links to the
>single instance.
>This can work on large amounts of files, even on complex directory tree.
Sounds good, don't know that I saw that one (tend not to look too hard
as I enjoy creating stuff, and what I do is usually smaller, easier to
use - at least for me - and more reliable).
Didn't want to go into a lot of detail as this isn't exactly classic
computer related.. although I expect a lot of classic collectors are
like me and have use for it.
Couple things I implemented in DFF which I don't know of in other tools:
It uses an "index" file - first attempt just used the output of windows: DIR/S
but I found it got big and unworkable fast, and changed from one version of
windows to another. DFF creates its own which is small and consistent,
having only the DIR names, and file sizes + names.
This is normally a temp file, but you can Keep it, just Build it without
processing, and process it later. You can also have DFF append to it so you
can deal with as complex dir structure as you like, by /BAing it in various
places. It can deal with files in arbitrary directory trees on multiple drives
quite easily.
You can also have it place and END marker in the file, which means that
anything you append will be treated differently. Anything before the END
marker is scanned and reported as you expect. After the END marker, files are
considered as possible duplicates, but not checked and reported separately.
And since the "index" file is a text file, you can add to it, change it and
retrieve it's content very easily - you don't need special programs provided
by the tool maker to do unusual things. Same is true for it's output.
You can also have it list:
- All files (dups have a dup instance number see below)
- Only duplicate files
- Only single files
- Under each directory, you can get it to list where all the duplicates
are (full path)
This combined with the END marker makes some fairly powerful things possible.
(Show me any files occurring here which are not also occurring there).
Each instance of duplication is assigned a unique "duplicate instance" number
which is shown next to all files which are part of that "duplicate instance".
I thought about an automatic "delete duplicates" feature but didn't implement
it as I am organizing a lot of data, much is duplicated, it's final resting
place may not be one of the original locations and I want control over how the
final archive is organized.
Dave
--
----------------------------------------------------------------------------------
Personal site: http://dunfield.maknonsolutions.com
----------------------------------------------------------------------------------
Hello,
this tool is really similar to "rdfind", which compares file sizes and
content, independently from file name, and is able to create a list of
correspondence, delete duplicate files, and create symbolic links to the
single instance.
This can work on large amounts of files, even on complex directory tree.
Andrea
Sorry, can't respond easily because I read the list on the web, can't deal
with the flood of email from it, and can't respond via the web interface.
>I'm not clear on what "duplicate" really means. Perhaps you can clarify
>things for me.
>
>Duplicate in name and/or size?
>Duplicate in content?
>
>There are lots of duplicate file finders for Windows and some of them
>are quite sophisticated, being able to compare the content of files with
>different encodings and provide "almost the same" type of information.
Duplicate means exact duplicate size and contect, name does not matter.
(I copied lots of stuff around, sometimes renaming it and want to find
all the dups). Yeah, lots of nifty tools, but I needed one where I could
easily control what it looks and and process it's results (text files).
Also had to deal with VERY large sets of data (terabytes) and do it all
in a fairly reasonable time.
So I just wrote one. I'm a bit unusual that way - tend to write stuff that
does exactly what I need instead of trying to use something that sort of
comes close but often also does a lot I don't want.
>Downloading http://dunfield.maknonsolutions.com/dos/sw/ddw2020.zip
>gets flagged by Windows Defender on Windows 10 Pro (1909)
>as "Worm:Win32/Spybot".
Not for me, it's something I compiled from my own source myself, is packed
with UPX - maybe Windows Def doesn't like that but it raises no alarms on
the Win7 Pro system I'm testing on. Have no control of Windows Defender ..
just one of many reasons I don't use Windows much. Not the first time good
clean code of my own has triggered false alarms.
FWIW, I just downloaded DDW2020.ZIP from the site, and it exactly matches
my original one. Contents also exactly match my original files, here is
a DIR listing:
Directory of R:\DDW2020
2020-06-24 09:08 PM 3,255 DDW2020.TXT
2020-06-24 09:08 PM 23,584 DFF.EXE
2020-06-24 09:08 PM 23,584 EDT.EXE
2020-06-24 09:08 PM 31,907 EDT.TXT
2020-06-24 09:08 PM 6,688 FDF.EXE
2020-06-24 09:08 PM 9,760 VLT.EXE
6 File(s) 98,778 bytes
Note, Windows did warn me that this file is not commonly downloaded and
wanted to "discard" it, but I used "Keep" - no defender or antivirus
alarms triggered.
Dave
PS: Noticed and fixed the spelling of "Download" - may need to reload to
see due to browser cache.
--
----------------------------------------------------------------------------------
Personal site: http://dunfield.maknonsolutions.com
----------------------------------------------------------------------------------
Hi all --
I picked up a Tri-Data Cartrifile 4096 at VCF West last year and since I'm
suddenly going to have more time on my hands, I thought it'd be fun to see
if I can get it running again. The Cartrifile is a tape drive that uses
cartridges containing continuous-loop 1/4" tape in various lengths, much
like 8-track tape though in slightly different packaging and with a fixed
head. 10ips, 600bpi. (There's a brochure on Bitsavers at
http://www.bitsavers.org/pdf/tridata/Tri-Data_4096_Brochure_Feb69.pdf)
The unit I have has a PDP-8 compatible interface, though I only have the
cabling and rear-bulkhead for posibus systems. (My 8/I is currently
negibus, so some work will need to be done there.)
It's in pretty decent shape and I think I should be able to get it to work
again. I also have a stack of cartridges and it remains to be seen how
they hold up. If they're anything like 8-track tapes, the EOT marker will
probably fall off and the tape ends will need to be reconnected as well
:). At minimum I hope to be able to recover the data off the tapes I have.
Curious if anyone out there has one of these, has any spare parts, or
interface parts (there was at one point an Omnibus interface available, and
having the negibus interface would be extremely handy.)
Thanks as always,
Josh
At 10:41 AM 6/25/2020, Dave Dunfield via cctalk wrote:
>I originally wrote it for my own use, but it has proven SO useful that I took
>a little time to clean it up and post it at my personal site.:
Downloading http://dunfield.maknonsolutions.com/dos/sw/ddw2020.zip
gets flagged by Windows Defender on Windows 10 Pro (1909)
as "Worm:Win32/Spybot".
- John
Hi,
Don't know if anyone is interested, but I'd guess that a lot of you like
me have collected a big pile of digital "stuff" over the years, and also if
like me, it may have gotten away from you a bit with a lot of duplication
etc.
Having some spare time, I've been organizing my collected documentation,
software, drivers and other files. As part of this process I wrote "Duplicate
File Finder", a WIn32/64 tool which can look at a VERY large file collection
(can even be across many drives etc.) and produce a nice summary of what is
duplicated and where all the duplicates are.
I originally wrote it for my own use, but it has proven SO useful that I took
a little time to clean it up and post it at my personal site.:
http://dunfield.maknonsolutions.com
If this sounds useful, have a look and grab the program. Hopefully it will
be as useful to you as it has to me.
Dave
--
----------------------------------------------------------------------------------
Personal site: http://dunfield.maknonsolutions.com
----------------------------------------------------------------------------------
I've been processing some PDP-11 9 track (800 NRZI) tapes and run across
something that I don't recognize.
Every file on the tape consists of a number of 512 byte blocks (okay,
that's normal) but at the head of each file, there's a short block of 14
bytes.
Usually, a short record like this is discarded as "noise" on many
mainframe tape systems, but here it's consistently present. Here's what
one of the records looks like:
15 34 fe 51 fe 76 01 01 00 00 01 80 10 00
Doesn't seem like a file name in RAD50 format, so I'm puzzled.
Inquiring minds want to know...
Thanks,
Chuck
So I'm working on this RSX11M+ system here and while working I ran
myself out of file headers. Using the HOME /MXF command I was able to
increase the number of headers, but only up to 4090. or so. Trying to go
to 4100 gave me an error saying there were not enough system blocks or
something. Currently I have 830 headers, but that's not enough in the
long term.
The volume has 541,944 blocks total, with 150655 in use. This is a
system I generated on a smaller disk, then copied to the pdp11, then
backed up with BRU MU0:=DU0: then restored to a larger blank disk.
I guess the question is can I extend the number of blocks without having
to re-init the system disk? I suppose I could flatten it by taking the
system down to single user (shutdown, then p to start with the volume
dismounted, mount the volume /for, then BRU mu0:=du0:), then format the
volume with a really big assed MXF value, then restoring the tape, but
would that flatten the volume info? Or do I need to just man up, put a
second ESDI drive on this monster, copy the files to the second drive
then format the first (big) volume right, copy the files with PIP, and
do a VMR again to write the boot block?
Or is there a better way to backup and restore the volume without doing
an image backup using /for?
Been a long time since I've done this stuff. Thanks!
C
I found somewhat fascinating pictures in a PDP8 small computer handbook. It is a KV graphics system. According to the book it was used to design new computer circuit boards. So I got very curious to that KV system. I found a maintenance manual about the system. It even had a joystick! I wonder if any of that PCB software has been rescued?
Regards, Roland
https://ibb.co/WVKCfMzhttps://ibb.co/TvYpP2vhttps://ibb.co/6mSZkdh
While going through my assortment of old vacuum tubes looking for audio
treasures, I found a handful of IBM branded ones. Mostly 5965, but
there's one 5963 mixed in.
These are dual triodes with the same pinout as common small-signal audio
tubes such as 12AX7/7025/ECC83, but characteristics closer to 12AT7 or
12AU7. My RCA Receiving Tube Manual says they're designed to withstand
being held in cutoff for long periods of time, and mentions digital
applications.
Anyone know what kind of IBM machine these would have been used in?