22 May
2014
22 May
'14
10:02 p.m.
I've been reading the SIMH TAP file specification and there's something
that's not clear to me. Perhaps someone can volunteer their knowledge.
I've got a tape where about half the records (blocks) are an odd number
of bytes long. The SIMH document says that a block is padded to an even
number of bytes in this case. However, it doesn't say if the record
length (32-bit) word is adjusted to reflect this--or if the byte count
is rounded up to the nearest even byte.
It seems to me that the former would be the way to go, but I'm not sure.
If the latter course is taken, the information that the block is an
odd number of bytes long is gone.
Does anyone know for certain?
Thanks,
Chuck
22 May
22 May
10:17 p.m.
On Thu, May 22, 2014 at 10:02 PM, Chuck Guzis <cclist at sydex.com> wrote:
I've been reading the SIMH TAP file specification
and there's something
that's not clear to me. Perhaps someone can volunteer their knowledge.
I've got a tape where about half the records (blocks) are an odd number of
bytes long. The SIMH document says that a block is padded to an even number
of bytes in this case. However, it doesn't say if the record length
(32-bit) word is adjusted to reflect this--or if the byte count is rounded
up to the nearest even byte.
It seems to me that the former would be the way to go, but I'm not sure. If
the latter course is taken, the information that the block is an odd number
of bytes long is gone.
Does anyone know for certain?
Thanks,
Chuck
If I have this correct, I think the difference between standard SIMH
.TAP format and E11 format is that E11 format does not pad blocks to
an even boundary in the file, while the SIMH format does, however in
both formats the block length in the block header in the file reflects
the original block length.
Some relevant code snippets:
http://simh.trailing-edge.com/sources/simhv39-0.zip
sim_tape.c
/* Read record length forward */
sim_tape_rdlntf()
case MTUF_F_STD: case MTUF_F_E11:
uptr->pos = uptr->pos + sizeof (t_mtrlnt) + /* spc
over record */
((f == MTUF_F_STD)? ((sbc + 1) & ~1): sbc);
/* Write record forward */
sim_tape_wrrecf()
case MTUF_F_STD: /* standard */
sbc = MTR_L ((bc + 1) & ~1); /* pad odd length */
case MTUF_F_E11: /* E11 */
sim_fwrite (&bc, sizeof (t_mtrlnt), 1, uptr->fileref);
sim_fwrite (buf, sizeof (uint8), sbc, uptr->fileref);
sim_fwrite (&bc, sizeof (t_mtrlnt), 1, uptr->fileref);
11:04 p.m.
On 05/22/2014 10:17 PM, Glen Slick wrote:
If I have this correct, I think the difference between
standard SIMH
.TAP format and E11 format is that E11 format does not pad blocks to
an even boundary in the file, while the SIMH format does, however in
both formats the block length in the block header in the file reflects
the original block length.
So if I understand correctly--and from this:
http://simh.trailing-edge.com/docs/simh_magtape.pdf
A block byte count is always a 32-bit little-endian quantity that occurs
on an even byte address boundary (i.e. aligned to 16 bits). The block
byte count itself always represents the actual byte count of the block
read and not the padded length of the block.
Do I have this right?
--Chuck
23 May
23 May
7:03 a.m.
On May 23, 2014, at 2:04 AM, Chuck Guzis <cclist at sydex.com> wrote:
On 05/22/2014 10:17 PM, Glen Slick wrote:
Yes, and that is critical. As you observed. it has to be the original length, otherwise
odd length blocks are corrupted.
paul
If I have this correct, I think the difference
between standard SIMH
.TAP format and E11 format is that E11 format does not pad blocks to
an even boundary in the file, while the SIMH format does, however in
both formats the block length in the block header in the file reflects
the original block length.
So if I understand correctly--and from this:
http://simh.trailing-edge.com/docs/simh_magtape.pdf
A block byte count is always a 32-bit little-endian quantity that occurs on an even byte
address boundary (i.e. aligned to 16 bits). The block byte count itself always represents
the actual byte count of the block read and not the padded length of the block.
Do I have this right?
10:07 a.m.
On 05/23/2014 07:03 AM, Paul Koning wrote:
Yes, and that is critical. As you observed. it has to
be the
original length, otherwise odd length blocks are corrupted.
I've been using Mark Riordan's CDCTap utility over at 60bits.net to
examine these things. It turns out that it requires the "unpadded" TAP
file. (I guess that's E11). Nothing like a standard...
At any rate, I've come up against another issue--an unknown archiving
program. here's a dump of the first few words of the tape:
Record 4 contains 1971 8-bit bytes (262 60-bit words):
77 00 00 16 00 00 00 00 00 00 ; N
01 22 03 10 11 26 05 00 00 00 ARCHIVE
55 43 41 50 33 36 50 35 41 57 86/03/26.
36 13 13 27 21 06 17 55 55 55 3KKWQFO
25 23 05 22 55 01 22 03 10 11 USER ARCHI
26 05 55 26 05 22 23 11 17 16 VE VERSION
55 35 57 34 57 35 55 55 55 55 2.1.2
03 17 20 31 22 11 07 10 24 55 COPYRIGHT
10 04 22 55 23 31 23 24 05 15 HDR SYSTEM
23 55 11 16 03 57 55 55 55 55 S INC.
00 00 00 00 00 00 00 00 00 00
The first word looks very much like the header to a W-type record, but
the archive format is nothing that I've ever run into. Does "HDR
Systems" ring any bells for anyone? I can probably unravel all of this,
but appreciate any light to be shed.
In my wildest nightmares, I never thought that 6RM would come back to
haunt me...
--Chuck
10:18 a.m.
On 5/23/14 10:07 AM, Chuck Guzis wrote:
It turns out that it requires the "unpadded"
TAP file. (I guess that's E11). Nothing like a standard...
Supnik did that in SIMH with his extensions to .tap
Of course, no one bothered to put a version or magic number in .tap images. I had argued
to put a trailer record
with more information after the physical EOF record that was added, but was ignored.
There is also .tpc which only has a 16 bit record length at the front, and AWSTAPE that
the IBM guys use.
In my wildest nightmares, I never thought that 6RM
would come back to haunt me...
Welcome to my world.
10:42 a.m.
On 05/23/2014 10:18 AM, Al Kossow wrote:
On 5/23/14 10:07 AM, Chuck Guzis wrote:
If you google "TAP file format" you are pretty much overwhelmed with
hits on C64 and ZX81 and CPC files, all of which are mutually compatible
and not the SIMH variety.
I did wonder why the SIMH TAP had no header, basically saying what's in
the file. It would only seem to be common sense. Too late now.
Well, at least I've got something to work with. Now on to the PRIMOS
tapes...
--Chuck
It turns out that it requires the
"unpadded" TAP file. (I guess that's
E11). Nothing like a standard...
Supnik did that in SIMH with his extensions to .tap
Of course, no one bothered to put a version or magic number in .tap
images. I had argued to put a trailer record
with more information after the physical EOF record that was added, but
was ignored.
There is also .tpc which only has a 16 bit record length at the front,
and AWSTAPE that the IBM guys use. In my wildest nightmares, I never thought that
6RM would come back to
haunt me...
Welcome to my world.
11:15 a.m.
On 5/23/14 10:42 AM, Chuck Guzis wrote:
I did wonder why the SIMH TAP had no header, basically
saying what's in the file.
I guess it is all due to it just being hacks upon DECUS .tpc format.
It is completely inadequate for archival purposes because of the lack of metadata
and fixity information in the file.
I had heard several years ago that there was some work on a proper archival container
format for variable-block length magnetic media but I've never seen a spec for it.
I would think one exists by now at the Library of Congress with all of the media
conversion work they've been doing.
After finishing my seemingly annual move of media lab locations at CHM, I'm hoping I
can get back to magnetic media recovery soon.
11:28 a.m.
On May 23, 2014, at 2:15 PM, Al Kossow <aek at bitsavers.org> wrote:
On 5/23/14 10:42 AM, Chuck Guzis wrote:
Was it you, or Paul Pierce, who proposed a format that includes a way to represent errors
rather than only good data? That would seem to be the right starting point.
If there doesn?t seem to be a suitable spec, it might be best just to propose one. We can
all jump on the bandwagon if we like it.
paul
I did wonder why the SIMH TAP had no header,
basically saying what's in the file.
I guess it is all due to it just being hacks upon DECUS .tpc format.
It is completely inadequate for archival purposes because of the lack of metadata
and fixity information in the file.
I had heard several years ago that there was some work on a proper archival container
format for variable-block length magnetic media but I've never seen a spec for it.
I would think one exists by now at the Library of Congress with all of the media
conversion work they've been doing.
After finishing my seemingly annual move of media lab locations at CHM, I'm hoping I
can get back to magnetic media recovery soon. 
12:23 p.m.
On Fri, May 23, 2014 at 12:28 PM, Paul Koning <paulkoning at comcast.net>wrote:
Was it you, or Paul Pierce, who proposed a format that
includes a way to
represent errors rather than only good data?
They may have. I proposed one, which went nowhere. I proposed a metadata
record of:
32-bit 0xffffffff (metadata indicator)
32-bit length (of data between the two length fields, not inclusive)
32-bit metadata type (needs to be a process for uniquely assigning
them)
metadata ((length - 4) bytes)
32-bit length (same as previous length field)
32-bit 0xffffffff
I proposed a metadata record for bad tape areas, with a flag word that
would contain flags for:
unknown record count - clear for single bad record, set for unknown
number of bad records
unknown record length
approximate record length
(For bad records of known length, neither the unknown record length nor the
approximate record length flags would be set.)
If I were writing such a proposal today, I'd replace the 32-bit metadata
type with a counted string containing a reversed-DNS name (as used for Java
package namespace), so that anyone with a registered DNS domain can assign
their own metadata record types.
Eric
6:58 p.m.
On 05/23/2014 11:15 AM, Al Kossow wrote:
After finishing my seemingly annual move of media lab
locations at CHM,
I'm hoping I can get back to magnetic media recovery soon.
Okay, this brings up a question.
What format is preferred when archiving tapes without any bias toward
the original system? In other words, what format is acceptable to
archivists?
I can convert to just about any imaging format, but which one is the
best-documented?
--Chuck
24 May
24 May
7:01 a.m.
On 5/23/14 6:58 PM, Chuck Guzis wrote:
In other words, what format is acceptable to
archivists?
Like I said in my previous post, none that I know of.
What many arhivists do is take whatever they get and "bag" it.
http://www.digitalpreservation.gov/multimedia/videos/bagit0609.html
There was some work that I heard about indirectly that was going on
at NASA. I don't know what they decided on. The two that I know of
that were being used by one data recovery service was AWSTAPE and an
extended SIMH .tap with error recovery information added, that I was
never able to get a detailed description of.
Google searches are incredibly noisy because of all the "we lost the
Apollo 11" tape and "Lunar Orbiter tapes found in abandoned McDonalds"
nonsense, and the dominance of audio and telemetry tape archiving.
9:29 a.m.
On 5/23/14 6:58 PM, Chuck Guzis wrote:
What format is preferred when archiving tapes without
any bias toward the original system? In other words, what format is acceptable to
archivists?
I thought about your question a bit more, and we actually had a discussion about this last
week as we
just hired a new digital archivist at CHM.
Archivists would prefer to have the contents of the tape, not the image itself, since that
would
be of the most use to researchers in the future. Ideally, what would be saved is a picture
of the
container where all of the markings are visible, the image, a description of the image
format, and
the decoded and verfied contents of the image, along with SHA1 or better checksums for
fixity checking
http://tools.ietf.org/html/draft-kunze-bagit-05
http://sourceforge.net/projects/loc-xferutils/files/loc-bagger/2.1.3/
Is the description and code for the current version of bagit, developed by the California
Digital Library,
Stanford, and the Library of Congress as a transfer standard.
10:06 a.m.
On 05/24/2014 09:29 AM, Al Kossow wrote:
Archivists would prefer to have the contents of the
tape, not the
image itself, since that would be of the most use to researchers in
the future. Ideally, what would be saved is a picture of the
container where all of the markings are visible, the image, a
description of the image format, and the decoded and verfied contents
of the image, along with SHA1 or better checksums for fixity checking
http://tools.ietf.org/html/draft-kunze-bagit-05
http://sourceforge.net/projects/loc-xferutils/files/loc-bagger/2.1.3/
Is the description and code for the current version of bagit,
developed by the California Digital Library, Stanford, and the
Library of Congress as a transfer standard.
Thanks, Al. I'll pass this on to my contact--she's pretty new at this
archiving stuff.
--Chuck
1:07 p.m.
On May 24, 2014, at 12:29 PM, Al Kossow <aek at bitsavers.org> wrote:
On 5/23/14 6:58 PM, Chuck Guzis wrote:
That?s one level of abstraction. Another possibility would be to view ?digital? data as
analog, which of course it actually is, and capture it at that level. It would take more
specilized hardware to do that, and the files would be a great deal larger, but it would
also capture detail that a digital representation hides. For example, damaged spots might
be recoverable if that is done. Something like the DSP based tape drive Paul Pierce built
(if I remember that one right) would be a way to capture old media at that level.
paul
What format is preferred when archiving tapes
without any bias toward the original system? In other words, what format is acceptable to
archivists?
I thought about your question a bit more, and we actually had a discussion about this
last week as we
just hired a new digital archivist at CHM.
Archivists would prefer to have the contents of the tape, not the image itself, since
that would
be of the most use to researchers in the future. Ideally, what would be saved is a
picture of the
container where all of the markings are visible, the image, a description of the image
format, and
the decoded and verfied contents of the image, along with SHA1 or better checksums for
fixity checking
1:34 p.m.
On 05/24/2014 01:07 PM, Paul Koning wrote:
That?s one level of abstraction. Another possibility
would be to
view ?digital? data as analog, which of course it actually is, and
capture it at that level. It would take more specilized hardware to
do that, and the files would be a great deal larger, but it would
also capture detail that a digital representation hides. For
example, damaged spots might be recoverable if that is done.
Something like the DSP based tape drive Paul Pierce built (if I
remember that one right) would be a way to capture old media at that
level.
That might be useful if the tape couldn't be successfully read using
conventional means, but in cases where the tape reads BOT-to-EOT
correctly, there's no additional information to be obtained and the
extra effort is of little value.
--Chuck
26 May
26 May
3:59 a.m.
On Sat, 24 May 2014 13:34:33 -0700, Chuck Guzis <cclist at sydex.com> wrote:
On 05/24/2014 01:07 PM, Paul Koning wrote:
What I'd worry about is an error or omission in the imaging process which
is not detected or maybe not even detectable at imaging time. If the data
is obscure and there are no running or emulated systems which dealt with it
available, there may be no way of verifying that a correct and complete image
has been obtained.
Even an analogue representation of the data may suffer from this problem and
some years down the line it could be discovered that some vital parameter has
not been preserved and the original media is no longer available.
On the other hand, we cannot stop media from deteriorating so having any sort
of an image of the contents is more helpful than relying solely on the
original media.
Regards,
Peter Coghlan.
Thats one level of abstraction. Another
possibility would be to
view digital data as analog, which of course it actually is, and
capture it at that level. It would take more specilized hardware to
do that, and the files would be a great deal larger, but it would
also capture detail that a digital representation hides. For
example, damaged spots might be recoverable if that is done.
Something like the DSP based tape drive Paul Pierce built (if I
remember that one right) would be a way to capture old media at that
level.
That might be useful if the tape couldn't be successfully read using
conventional means, but in cases where the tape reads BOT-to-EOT
correctly, there's no additional information to be obtained and the
extra effort is of little value.
7:24 a.m.
On 5/26/14 3:59 AM, Peter Coghlan wrote:
If the data
is obscure and there are no running or emulated systems which dealt with it
available, there may be no way of verifying that a correct and complete image
has been obtained.
If it is tape, there is a high probability there will be dropouts. If you can't
verify what you've read, you save the tape until you can, perhaps with better
data recovery equipment. If the tape is so bad physically that a second pass is
impractical, you do the best you can in tape prep (baking, retensioning) or if
it is a large batch, you weigh recovery probabilities with the value of the data
you're recovering. Some batches aren't worth it (accounting records with no
provenance) and some are (Doug Englebart's SRI lab backup tapes).
At least in the case of 1/2" magnetic data tape, there is at least parity and a
block check character, and established standards for on-tape block formats, so if
you can get a decent image of the flux levels and where they were on the tape you
have a pretty good idea if what you read was what was recorded even if you can't
decode it past the block level. The best luck I've had with tape recovery has been
with the self-clocking formats (1600/6250). The last generations of drives were quite
good. I wish the same were true for 800, and in 20+ years I've never had a working
solution for 7-track media.
What you don't know at that point is if what is on the tape or diskette matches
what the paper label says should be there. This is one of the reasons I read multiple
physical copies of what should be the same thing from different tapes/disks.
Copy-protection is another rathole. The best I can do is try to identify if something
is known to be copy-protected or not. This tends to be PC software, and there is no
shortage of hobbyists dealing in that space.
24 May
24 May
2:54 p.m.
On 5/24/14 1:07 PM, Paul Koning wrote:
Something like the DSP based tape drive Paul Pierce
built (if I remember that one right)
Paul's drive just has A/D converters and a PC, no hardware DSP
Several years ago, John Bordynuik sent me one of the transports he used in his tape
recovery business. It uses an M4 data transport, 3480 head stack (16 tracks) custom
preamp
and a custom A/D DSP board to capture and convert the data. The preamp board arrived with
one of the SMT resistors in the MR bias supply cracked, and he never sent me enough
documentation
to make it work. I spent several weeks late last year trying to get it to do something.
The whole project has been incredibly frustrating. At the same time, I sent two M4 data
head
stacks to have the capstan wheels redone, and after two months they came back with nothing
having
been done to them because the stacks had parts missing. As far
as I can tell, they never even touched them, and I TOLD them that all I wanted them to do
was
to install new capstan wheels since they would only sell them at the "less
expensive" exchange
price of $150 ea. if they got old ones, which I didn't feel comfortable trying to
remove (they
are a bitch to take out w/o bending the encoder wheel).
This all started when I called them to try to get schematics for the M4 drive motor
control board
which John had added his own interface onto to drive the tape.
Anyway, one of the magic bits of sauce you can do when recovering data with direct A/D is
to monitor
the exact position of the tape wrt the heads by watching the encoder on the capstan. And,
if you're
using magnetorestrictive heads, you can directly sense the magnetic flux level on the
tape. With those
two bits of information, you can get a very good idea of what was the surviving levels of
magentic flux
are at any spot on the tape.
27 May
27 May
11:52 a.m.
From: Al Kossow
Sent: Friday, May 23, 2014 11:15 AM
On 5/23/14 10:42 AM, Chuck Guzis wrote:
> I did wonder why the SIMH TAP had no header,
basically saying what's in the
> file.
I guess it is all due to it just being hacks upon
DECUS .tpc format.
It is completely inadequate for archival purposes
because of the lack of
metadata and fixity information in the file.
I had heard several years ago that there was some work
on a proper archival
container format for variable-block length magnetic media but I've never seen
a spec for it.
I would think one exists by now at the Library of
Congress with all of the
media conversion work they've been doing.
http://www.boogles.com/local/papers/tcfs-thesis/thesis.html
I had great hopes at one time for the Time Capsule File System designed at MIT
by Alan Bawden and Brian Zuzga. The URL is for an on-line version of the
latter's senior thesis describing it.
The only system using it at all of which I'm aware is the KLH10 emulator (which
can read all of .tpc, .tps, and .tap, as well); TCFS was used for some of the
ITS instantiation on the kn10-ks emulated processor.
It now seems less adequate, but it was designed to be extensible. The addition
of pictures of the physical medium is something I came up with for a project
here. I'm glad to know others have had the same idea in other projects.
Rich
Rich Alderson
Sr. Systems Engineer
Living Computer Museum
2245 1st Avenue S
Seattle, WA 98134
mailto:RichA at LivingComputerMuseum.org
http://www.LivingComputerMuseum.org/
23 May
23 May
10:27 a.m.
On Fri, May 23, 2014 at 10:07:21AM -0700, Chuck Guzis wrote:
It turns out that it requires the "unpadded"
TAP file. (I guess that's E11). Nothing like a standard...
It *so* almost was a standard. When I wrote up my format (which I stole
from, I think, MS FORTRAN V3.2's method of storing unformatted binary files),
I emphasized that the length longwords are NOT padded to an even boundary,
because I didn't want any confusion with .TPC (which was popular at the
time but makes backspacing needlessly difficult since it's not intended
for live use). And I guess someone somewhere kind of half-read that part
and thought I meant the opposite.
Luckily it doesn't matter in the 99% of cases (on PDP-11s anyway) where
the lengths are all even ... annoying the rest of the time though.
John Wilson
D Bit
11:22 a.m.
On May 23, 2014, at 1:07 PM, Chuck Guzis <cclist at sydex.com> wrote:
On 05/23/2014 07:03 AM, Paul Koning wrote:
That may be because DtCyber uses unpadded TAP.
Yes, and that is critical. As you observed. it
has to be the
original length, otherwise odd length blocks are corrupted.
I've been using Mark Riordan's CDCTap utility over at 60bits.net to examine these
things. It turns out that it requires the "unpadded" TAP file. (I guess
that's E11). Nothing like a standard? At any rate, I've come up against another
issue--an unknown archiving program. here's a dump of the first few words of the
tape:
Record 4 contains 1971 8-bit bytes (262 60-bit words):
77 00 00 16 00 00 00 00 00 00 ; N
01 22 03 10 11 26 05 00 00 00 ARCHIVE
55 43 41 50 33 36 50 35 41 57 86/03/26.
36 13 13 27 21 06 17 55 55 55 3KKWQFO
25 23 05 22 55 01 22 03 10 11 USER ARCHI
26 05 55 26 05 22 23 11 17 16 VE VERSION
55 35 57 34 57 35 55 55 55 55 2.1.2
03 17 20 31 22 11 07 10 24 55 COPYRIGHT
10 04 22 55 23 31 23 24 05 15 HDR SYSTEM
23 55 11 16 03 57 55 55 55 55 S INC.
00 00 00 00 00 00 00 00 00 00
The first word looks very much like the header to a W-type record, but the archive format
is nothing that I've ever run into. Does "HDR Systems" ring any bells for
anyone? I can probably unravel all of this, but appreciate any light to be shed.
Joe Cychosz might know. The 4th word looks like the sort of usernames that University of
Illinois inflicted on its students (derived from student ID numbers).
paul
4:46 p.m.
Hi Paul,
Yes that defiantly is a CSO user name (at least has the right pattern if not). HDR had
the own pfdump/load programs. This is different than dumppf/loadpf. I didn't really
like the HDR package and never used it. Stuck with the CDC utilities since they would
work everywhere. The attraction of the other utilities was that you could us them as a
user. Pfdump/pfload were SYOT.
Sent from my iPad
On May 23, 2014, at 2:22 PM, Paul Koning <paulkoning at comcast.net> wrote:
On May 23, 2014, at 1:07 PM, Chuck Guzis <cclist at sydex.com> wrote:
On 05/23/2014 07:03 AM, Paul Koning wrote:
That may be because DtCyber uses unpadded TAP.
Yes, and that is critical. As you observed. it
has to be the
original length, otherwise odd length blocks are corrupted.
I've been using Mark Riordan's CDCTap utility over at 60bits.net to examine these
things. It turns out that it requires the "unpadded" TAP file. (I guess
that's E11). Nothing like a standard? At any rate, I've come up against another
issue--an unknown archiving program. here's a dump of the first few words of the
tape:
Record 4 contains 1971 8-bit bytes (262 60-bit words):
77 00 00 16 00 00 00 00 00 00 ; N
01 22 03 10 11 26 05 00 00 00 ARCHIVE
55 43 41 50 33 36 50 35 41 57 86/03/26.
36 13 13 27 21 06 17 55 55 55 3KKWQFO
25 23 05 22 55 01 22 03 10 11 USER ARCHI
26 05 55 26 05 22 23 11 17 16 VE VERSION
55 35 57 34 57 35 55 55 55 55 2.1.2
03 17 20 31 22 11 07 10 24 55 COPYRIGHT
10 04 22 55 23 31 23 24 05 15 HDR SYSTEM
23 55 11 16 03 57 55 55 55 55 S INC.
00 00 00 00 00 00 00 00 00 00
The first word looks very much like the header to a W-type record, but the archive format
is nothing that I've ever run into. Does "HDR Systems" ring any bells for
anyone? I can probably unravel all of this, but appreciate any light to be shed.
Joe Cychosz might know. The 4th word looks like the sort of usernames that University of
Illinois inflicted on its students (derived from student ID numbers).
paul
24 May
24 May
9:47 a.m.
On 05/23/2014 04:46 PM, Joe Cychosz wrote:
Hi Paul,
Yes that defiantly is a CSO user name (at least has the right pattern
if not). HDR had the own pfdump/load programs. This is different
than dumppf/loadpf. I didn't really like the HDR package and never
used it. Stuck with the CDC utilities since they would work
everywhere. The attraction of the other utilities was that you could
us them as a user. Pfdump/pfload were SYOT.
Okay, that settles that. Easy enough to figure out--there's no fancy
compression. That there's no PF names or user names/passwords pretty
much cinches that this was for user, not system application.
---------------------
Did anyone ever offer a Prime 50-series emulator for SIMH? I've got
what appears to be a PRIMOS boot tape here. It might be interesting to
try to run it on an emulator.
The only Prime emulator that I can find so far seems to be a telnet-sort
of affair running on someone's server.
--Chuck
10:03 a.m.
On 5/24/14 9:47 AM, Chuck Guzis wrote:
Did anyone ever offer a Prime 50-series emulator for
SIMH? I've got what appears to be a PRIMOS boot tape here. It might be interesting
to try to run it on an emulator.
The only Prime emulator that I can find so far seems to be a telnet-sort of affair
running on someone's server.
nope. Jim Wilcoxson did the work and never shared it with anyone.
There isn't quite enough information or interest for anyone else to have bothered.
Primos is interesting because they maintained binary compatibility all the way back to
when it was a Honeywell 516 clone.
http://en.wikipedia.org/wiki/PRIMOS
10:11 a.m.
On 24/05/2014 18:03, Al Kossow wrote:
On 5/24/14 9:47 AM, Chuck Guzis wrote:
We used to have Primes when I worked at the University of Salford. As
well as having binary compatability the system also seemed to contain
lots of the original Honeywell software. I guess that like the old IBM
Mainframe software, the Honeywell software was not copyright...
Dave
G4UGM
Did anyone ever offer a Prime 50-series emulator
for SIMH? I've got
what appears to be a PRIMOS boot tape here. It might be interesting
to try to run it on an emulator.
The only Prime emulator that I can find so far seems to be a
telnet-sort of affair running on someone's server.
nope. Jim Wilcoxson did the work and never shared it with anyone.
There isn't quite enough information or interest for anyone else to
have bothered.
Primos is interesting because they maintained binary compatibility all
the way back to
when it was a Honeywell 516 clone.
http://en.wikipedia.org/wiki/PRIMOS
11:19 a.m.
On 05/24/2014 10:11 AM, Dave wrote:
We used to have Primes when I worked at the University
of Salford. As
well as having binary compatability the system also seemed to contain
lots of the original Honeywell software. I guess that like the old IBM
Mainframe software, the Honeywell software was not copyright...
Somewhere, I seem to remember that software copyright didn't kick in
until about 1978, officially in the US.
Do I remember correctly?
--Chuck
1:03 p.m.
On May 24, 2014, at 2:19 PM, Chuck Guzis <cclist at sydex.com> wrote:
On 05/24/2014 10:11 AM, Dave wrote:
No. But before that time, lack of a copyright notice would put the work in the public
domain, which is no longer the case. That?s why some old software is in the public domain
? the creators neglected to label it properly.
See Wikipedia for a lot more.
paul
We used to have Primes when I worked at the
University of Salford. As
well as having binary compatability the system also seemed to contain
lots of the original Honeywell software. I guess that like the old IBM
Mainframe software, the Honeywell software was not copyright...
Somewhere, I seem to remember that software copyright didn't kick in until about
1978, officially in the US.
Do I remember correctly?
1:43 p.m.
On 05/24/2014 01:03 PM, Paul Koning wrote:
Do I remember correctly?
No. But before that time, lack of a copyright notice would put the
work in the public domain, which is no longer the case. That?s why
some old software is in the public domain ? the creators neglected to
label it properly.
See Wikipedia for a lot more.
I don't ever remember putting a copyright notice in software in the
early 1970s. I thought that the 1978 URAAs changed the picture,
especially wrt what was valid deposit medium.
I'll do a bit of research, particularly with respect to a compiled
software product being copyright-material versus the source code
considered as a literary work.
--Chuck
27 May
27 May
1:08 a.m.
On Sun, May 25, 2014 at 3:03 AM, Al Kossow <aek at bitsavers.org> wrote:
On 5/24/14 9:47 AM, Chuck Guzis wrote:
To elaborate a little on this (perhaps more knowledgeable Pr1me
enthusiasts could jump in?), Jim offers an OS X (Macintosh) PowerPC
binary containing his Prime emulator on request for hobbyist use. I
understand his emulator was being sold commercially so I assume this
diverted him from releasing the SIMH implementation as open-source?
Did anyone ever offer a Prime 50-series emulator
for SIMH?
nope. Jim Wilcoxson did the work and never shared it with anyone. Primos is interesting because they maintained binary
compatibility all the
way back to
when it was a Honeywell 516 clone.
How intriguing! How good was the compatibility? has anyone tested
H316/516 software on Primos? This fellow has software from those
machines: http://www.series16.adrianwise.co.uk/emulator/index.html
3645
days inactive
3649
days old
30 comments
11 participants
participants (11)
-
3ksnn64＠ecn.purdue.edu -
aek＠bitsavers.org -
cclist＠sydex.com -
cctech＠beyondthepale.ie -
dave.g4ugm＠gmail.com -
glen.slick＠gmail.com -
nw＠retrocomputingtasmania.com -
paulkoning＠comcast.net -
RichA＠LivingComputerMuseum.org -
spacewar＠gmail.com -
wilson＠dbit.com