Re: [Simh] PIP10 on PDP-8 SIM
On 2013-03-19 14:56, Timothe Litt wrote:
This communication may not represent my employer's views,
if any, on the matters discussed.
Consider a timesharing system, with 4 users each trying to transfer from
their own DTA. With a TC11, you serviced user 1, user, 3, user 4, user
2 sequentially. The controller was tied up for the whole seek for each
user - potentially from one end of the tape to the other.
Oh. You are talking about overlapped seeks. I thought you meant
something else.
I just checked the TC01 controller (for the PDP-8) and it certainly can
do this too. But you need to programatically time things in this case,
to go back to the drive when you think it is getting close, and start
fiddling. Also checked the TC11, and it too can run several tape units,
as long as you reselect the tape drive when you think you actually want
to start doing any operations. Both can have tapes continue to run in
either direction while doing operations on another tape.
Sounds like exactly the same deal as with the TD10.
The TD8E, which I mentioned being the most stupid controller on earth,
requires this solution all the time, as there is no actual seek, nor is
there any DMA. You either poll the controller all the time, or else you
setup a time interrupt when you think it is appropriate to start polling.
(Of course, OS/8 just polls the darn tape the whole time...)
The TD10-'s dead reckoning allowed the seeks to proceed in parallel.
E.g. we'd start all 4 seeks, allowing the drives to run unsupervised by
the controller. When the shortest seek was near completion, the driver
would tell the controller to pay attention to that drive ('connect'), do
the transfer, and stop. Then the next. Besides being impressive to
watch (8 drives spinning in various directions), the user request
latency was reduced. (Some systems had two controllers, for 16 drives!)
I don't know if any driver for any PDP8 OS, or PDP11 OS ever did
overlapped seeks, but the hardware can definitely do it.
The one OS I can tell about is RSX, and it did not support overlapped
seeks on TC11. (And of course I know OS/8, but the answer there is that
nothing ever did overlapped seeks on anything, since all I/O was polled
anyway.)
The KA, KI and KL (with the IO Bus adapter) all used the TD10
controller. The -6 had another controller - type 551. I think it was a
dumb controller, but didn't use it personally.
Ok.
129 x 12 = 1548 bits/block; 256 x 18 = 4608 bits/block ; 2 formats. Gory
details of the TD10 are at
Oh. You just meant the number of bits in a block. Well, you can do any
size you want, just as you can do any number of blocks you want, withing
physical limits, and probably some other restrictions that I can't think
of right now.
Since PIP10 (the pdp-8 reader for pdp-10 tapes) was the question, the
format info I provided was for the 10. TOPS-10. MAC had another format
for the -6. TOPS-20 didn't officially support DECtapes, but internally
we had systems with them. They used the PDP-10 format.
Makes sense.
Anyway, yes, PIP10 would parse the format you described, once it
actually manages to read the blocks. That is the tricky detail that
seems to not be working...
Much of the pdp-10 format documentation is a mixture of octal and
decimal. I picked decimal because these days, thinking in octal is a
(mostly) lost art.
:-)
IBM and many other vendors used 36-bits, because the (BCD) character
codes of the day were 6-bits, so it packed nicely. The -8 was 12 bits
for the same reason, only it was cheaper to build.
I don't know how much the PDP-8 (or rather, PDP-5) was 12 bits because
of any BCD issues. But it was cheap.
The PDP-10 supported arbitrary byte sizes (1-36 bits), so 7-bit ascii,
8-bit ascii or 9-bit ITS emacs encodings were all easy to deal with.
I know. The PDP-10 is a nice architecture.
The -11 was designed after 8-bit character codes became popular. EBCDIC
was (and is) an ugly mess; ASCII cemented 8-bit character codes. And
machines were then built as multiples of 8 bits, 8, 16, 32, 64 being the
most popular.
I can only agree about EBCDIC. ASCII wasn't really 8-bit though. But
7-bit is close enough.
Johnny
On 19-Mar-13 09:25, Johnny Billquist wrote:
On 2013-03-19 14:03, Timothe Litt wrote:
The DECtape format as such, with all the headers and so on, is the
same on all tapes. A normal PDP-8 formatted tape will have 129
(12-bit) words, however, while a PDP-10 (or any other 18-bitter) would
have 128 18-bit words (if I remember right).
Pretty much right. 129 may be slightly misleading. The format is 129,
but the -8 used only 128 of the 129 12-bit words/block for data.
Right. :-)
The PDP-10 is 36-bit, not 18-bit. A PDP-10 (actually, non-PDP-8)
formatted DECtape would have 578 blocks of 128 36-bit words. (256
18-bit words at the hardware level.)
I know that the PDP-10 is 36 bits. :-) I was talking about the DECtape
as such, which physically always stores 18
Re: [Simh] PIP10 on PDP-8 SIM
This communication may not represent my employer's views,
if any, on the matters discussed.
Consider a timesharing system, with 4 users each trying to transfer from
their own DTA. With a TC11, you serviced user 1, user, 3, user 4, user
2 sequentially. The controller was tied up for the whole seek for each
user - potentially from one end of the tape to the other.
The TD10-'s dead reckoning allowed the seeks to proceed in parallel.
E.g. we'd start all 4 seeks, allowing the drives to run unsupervised by
the controller. When the shortest seek was near completion, the driver
would tell the controller to pay attention to that drive ('connect'), do
the transfer, and stop. Then the next. Besides being impressive to
watch (8 drives spinning in various directions), the user request
latency was reduced. (Some systems had two controllers, for 16 drives!)
The KA, KI and KL (with the IO Bus adapter) all used the TD10
controller. The -6 had another controller - type 551. I think it was a
dumb controller, but didn't use it personally.
129 x 12 = 1548 bits/block; 256 x 18 = 4608 bits/block ; 2 formats.
Gory details of the TD10 are at
http://bitsavers.trailing-edge.com/www.computer.museum.uq.edu.au/pdf/DEC-10-I3AA-D%20TD10%20DECtape%20Control%20Maintenance%20Manual.pdf
Since PIP10 (the pdp-8 reader for pdp-10 tapes) was the question, the
format info I provided was for the 10. TOPS-10. MAC had another format
for the -6. TOPS-20 didn't officially support DECtapes, but internally
we had systems with them. They used the PDP-10 format.
Much of the pdp-10 format documentation is a mixture of octal and
decimal. I picked decimal because these days, thinking in octal is a
(mostly) lost art.
IBM and many other vendors used 36-bits, because the (BCD) character
codes of the day were 6-bits, so it packed nicely. The -8 was 12 bits
for the same reason, only it was cheaper to build.
The PDP-10 supported arbitrary byte sizes (1-36 bits), so 7-bit ascii,
8-bit ascii or 9-bit ITS emacs encodings were all easy to deal with.
The -11 was designed after 8-bit character codes became popular. EBCDIC
was (and is) an ugly mess; ASCII cemented 8-bit character codes. And
machines were then built as multiples of 8 bits, 8, 16, 32, 64 being the
most popular.
This communication may not represent my employer's views,
if any, on the matters discussed.
On 19-Mar-13 09:25, Johnny Billquist wrote:
On 2013-03-19 14:03, Timothe Litt wrote:
The DECtape format as such, with all the headers and so on, is the
same on all tapes. A normal PDP-8 formatted tape will have 129
(12-bit) words, however, while a PDP-10 (or any other 18-bitter) would
have 128 18-bit words (if I remember right).
Pretty much right. 129 may be slightly misleading. The format is 129,
but the -8 used only 128 of the 129 12-bit words/block for data.
Right. :-)
The PDP-10 is 36-bit, not 18-bit. A PDP-10 (actually, non-PDP-8)
formatted DECtape would have 578 blocks of 128 36-bit words. (256
18-bit words at the hardware level.)
I know that the PDP-10 is 36 bits. :-) I was talking about the DECtape
as such, which physically always stores 18 bits. A PDP-10 would
obviously store its 36-bit words using two DECtape words. Any 18-bit
machine is straight forward, while the PDP-11 (as you mention below)
only use 16 bits of the 18-bit word.
I thought it was 128 18-bit words, but I may well remember that wrong,
and the "normal" format is 256 18-bit words. Makes sense, when I think
about it.
The number of blocks is not absolutely fixed, but 578 is the
"standard" except on the PDP-8, I guess.
Blocks 0, 1, 2 are for DTBoot (hardware read-in bootstrap), and didn't
contain user data.
That would be very depending on which machine we're talking about, and
which controller... :-) But I assume you're talking about the PDP-10
here. Did all PDP-10 with DECtapes use the same controller? I assume
both the KA and KI had DECtapes, as well as the PDP-6.
Block 100 is the directory block. Thus 574 blocks for user data. The
directory holds up to 22 files, plus a map of which file owns each
block.
The user data blocks have a one word header (LH = next block of file; RH
= first block & words used in this block) + 127 words of payload. This
differed from disk files, where all 128 words were payload, so
inattentive programmers could make a number of mistakes. (E.g. random
access block isn't word/128; you had to pay attention to the buffer's
word count, etc.)
Data blocks of a file are (usually) not contiguous; this allowed the
drive to stop and restart while reading or writing without having to
reverse direction. The spacing depended on what blocks were free when
files were written, and the data mode. (Files written in 'core dump'
modes were assumed to be read by the monitor without stopping, so the
gap was smaller, allowing larger programs to be read without reversing
direction.)
The gory details of the format are in the Mo
Re: [Simh] PIP10 on PDP-8 SIM
Non-power-of-2 word sizes are in many applications today. 12- and 14-bit instruction width PIC processors are sold by the billions. 24-bit data width DSP's are extremely common, and other sizes including 28-bit, 36-bit, 48-bit, and 56-bit data widths abound in DSP audio/video processing and other applications. Tim. From: simh-boun...@trailing-edge.com [mailto:simh-boun...@trailing-edge.com] On Behalf Of Armistead, Jason Sent: Tuesday, March 19, 2013 9:30 AM To: simh@trailing-edge.com Subject: Re: [Simh] PIP10 on PDP-8 SIM I had trouble with Timothe's link to the USPTO, but found this same patent in PDF form at http://www.brouhaha.com/~eric/retrocomputing/dec/dectape/3387293.pdf As a relative newbie who started my serious journey into computing with an Apple ][ I've never fully understood DEC's fascination with word lengths that weren't multiples of 2 (even though I dabbled with the PDP-11s at the local council my father worked at as a civil engineer - mainly to play Mugwump and Wumpus after giving up on trying to learn FORTRAN). Maybe someone can give a brief history behind the 12-bit, 18-bit and 36-bit sizing of words. All I've ever had to deal with are 8-bit, 16-bit, 32-bit and 64-bit processors and their O/S. (But yes, I do remember the 4004 !!!) From: simh-boun...@trailing-edge.com<mailto:simh-boun...@trailing-edge.com> [mailto:simh-boun...@trailing-edge.com] On Behalf Of Timothe Litt Sent: Tuesday, 19 March 2013 9:03 AM To: simh@trailing-edge.com<mailto:simh@trailing-edge.com> Subject: Re: [Simh] PIP10 on PDP-8 SIM The DECtape format as such, with all the headers and so on, is the same on all tapes. A normal PDP-8 formatted tape will have 129 (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would have 128 18-bit words (if I remember right). Pretty much right. 129 may be slightly misleading. The format is 129, but the -8 used only 128 of the 129 12-bit words/block for data. The PDP-10 is 36-bit, not 18-bit. A PDP-10 (actually, non-PDP-8) formatted DECtape would have 578 blocks of 128 36-bit words. (256 18-bit words at the hardware level.) Blocks 0, 1, 2 are for DTBoot (hardware read-in bootstrap), and didn't contain user data. Block 100 is the directory block. Thus 574 blocks for user data. The directory holds up to 22 files, plus a map of which file owns each block. The user data blocks have a one word header (LH = next block of file; RH = first block & words used in this block) + 127 words of payload. This differed from disk files, where all 128 words were payload, so inattentive programmers could make a number of mistakes. (E.g. random access block isn't word/128; you had to pay attention to the buffer's word count, etc.) Data blocks of a file are (usually) not contiguous; this allowed the drive to stop and restart while reading or writing without having to reverse direction. The spacing depended on what blocks were free when files were written, and the data mode. (Files written in 'core dump' modes were assumed to be read by the monitor without stopping, so the gap was smaller, allowing larger programs to be read without reversing direction.) The gory details of the format are in the Monitor Calls manual (TOPS-10). The PDP-11 used 18-bit format, but ignored the high 2 bits of each word (except when reading PDP-10 tapes; the hardware for that was tricky as the high bits had to be read with programmed IO; the low 16 were DMAed on the TC-11.) The low-level formatting that established the mark track, end zones and block delimiters was done via a stand-alone diagnostic. This differs between the two formats. The directory block could be initialized under timesharing. Directory structure given is for the PDP-10; other OSs used different formats. >From an emulation point of view, the PDP-10's controller was the most >interesting; the driver does dead reckoning; that is, it will start a drive >spinning for a seek, disconnect, service other drives, and reconnect just >before the desired block is expected to be over the read head. So real-world >timing matters. The other controllers (and thus OSs) didn't support this. Oh, all numbers above are radix 10. The link for OS8 that I posted yesterday was via filewatcher; the direct link is ftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8/ Sorry if this was confusing. Of potential interest to low-level folks is http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN/3387293 Hope this is useful. This communication may not represent my employer's views, if any, on the matters discussed. On 18-Mar-13 16:26, Johnny Billquist wrote: On 2013-03-18 17:44, Bob Supnik wrote: I was trying to get a debug setup for PIP10, per Ian Kin
Re: [Simh] PIP10 on PDP-8 SIM
On 2013-03-19 14:30, Armistead, Jason wrote: I had trouble with Timothe’s link to the USPTO, but found this same patent in PDF form at http://www.brouhaha.com/~eric/retrocomputing/dec/dectape/3387293.pdf As a relative newbie who started my serious journey into computing with an Apple ][ I’ve never fully understood DEC’s fascination with word lengths that weren’t multiples of 2 (even though I dabbled with the PDP-11s at the local council my father worked at as a civil engineer – mainly to play Mugwump and Wumpus after giving up on trying to learn FORTRAN). Maybe someone can give a brief history behind the 12-bit, 18-bit and 36-bit sizing of words. All I’ve ever had to deal with are 8-bit, 16-bit, 32-bit and 64-bit processors and their O/S. (But yes, I do remember the 4004 !!!) It wasn't just DEC. Back in the day, most everyone used various word lengths that wasn't a power of two. I can't really make many comments on why other word lengths were more popular. I've seen mentioned that floating point formats was pretty nice to do with something like 60 or 72 bits. Reason being that you had large enough exponents for useful things, and enough precision for most calculations. So a word length that related to this made sense. Number of bits being a power of two started with IBM in the 60s, and became common with the PDP-11 in the 70s. (Or so I'd like to think.) Johnny *From:*simh-boun...@trailing-edge.com [mailto:simh-boun...@trailing-edge.com] *On Behalf Of *Timothe Litt *Sent:* Tuesday, 19 March 2013 9:03 AM *To:* simh@trailing-edge.com *Subject:* Re: [Simh] PIP10 on PDP-8 SIM The DECtape format as such, with all the headers and so on, is the same on all tapes. A normal PDP-8 formatted tape will have 129 (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would have 128 18-bit words (if I remember right). Pretty much right. 129 may be slightly misleading. The format is 129, but the -8 used only 128 of the 129 12-bit words/block for data. The PDP-10 is 36-bit, not 18-bit. A PDP-10 (actually, non-PDP-8) formatted DECtape would have 578 blocks of 128 36-bit words. (256 18-bit words at the hardware level.) Blocks 0, 1, 2 are for DTBoot (hardware read-in bootstrap), and didn't contain user data. Block 100 is the directory block. Thus 574 blocks for user data. The directory holds up to 22 files, plus a map of which file owns each block. The user data blocks have a one word header (LH = next block of file; RH = first block & words used in this block) + 127 words of payload. This differed from disk files, where all 128 words were payload, so inattentive programmers could make a number of mistakes. (E.g. random access block isn't word/128; you had to pay attention to the buffer's word count, etc.) Data blocks of a file are (usually) not contiguous; this allowed the drive to stop and restart while reading or writing without having to reverse direction. The spacing depended on what blocks were free when files were written, and the data mode. (Files written in 'core dump' modes were assumed to be read by the monitor without stopping, so the gap was smaller, allowing larger programs to be read without reversing direction.) The gory details of the format are in the Monitor Calls manual (TOPS-10). The PDP-11 used 18-bit format, but ignored the high 2 bits of each word (except when reading PDP-10 tapes; the hardware for that was tricky as the high bits had to be read with programmed IO; the low 16 were DMAed on the TC-11.) The low-level formatting that established the mark track, end zones and block delimiters was done via a stand-alone diagnostic. This differs between the two formats. The directory block could be initialized under timesharing. Directory structure given is for the PDP-10; other OSs used different formats. From an emulation point of view, the PDP-10's controller was the most interesting; the driver does dead reckoning; that is, it will start a drive spinning for a seek, disconnect, service other drives, and reconnect just before the desired block is expected to be over the read head. So real-world timing matters. The other controllers (and thus OSs) didn't support this. Oh, all numbers above are radix 10. The link for OS8 that I posted yesterday was via filewatcher; the direct link isftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8/ <ftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8/> Sorry if this was confusing. Of potential interest to low-level folks is http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN/3387293 Hope this is useful. This communication may not represent my employer's views, if any, on the matters discussed. On 18-Mar-13 16:26, Johnny Billquist wrote:
Re: [Simh] PIP10 on PDP-8 SIM
I had trouble with Timothe’s link to the USPTO, but found this same patent in PDF form at http://www.brouhaha.com/~eric/retrocomputing/dec/dectape/3387293.pdf As a relative newbie who started my serious journey into computing with an Apple ][ I’ve never fully understood DEC’s fascination with word lengths that weren’t multiples of 2 (even though I dabbled with the PDP-11s at the local council my father worked at as a civil engineer – mainly to play Mugwump and Wumpus after giving up on trying to learn FORTRAN). Maybe someone can give a brief history behind the 12-bit, 18-bit and 36-bit sizing of words. All I’ve ever had to deal with are 8-bit, 16-bit, 32-bit and 64-bit processors and their O/S. (But yes, I do remember the 4004 !!!) From: simh-boun...@trailing-edge.com [mailto:simh-boun...@trailing-edge.com] On Behalf Of Timothe Litt Sent: Tuesday, 19 March 2013 9:03 AM To: simh@trailing-edge.com Subject: Re: [Simh] PIP10 on PDP-8 SIM The DECtape format as such, with all the headers and so on, is the same on all tapes. A normal PDP-8 formatted tape will have 129 (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would have 128 18-bit words (if I remember right). Pretty much right. 129 may be slightly misleading. The format is 129, but the -8 used only 128 of the 129 12-bit words/block for data. The PDP-10 is 36-bit, not 18-bit. A PDP-10 (actually, non-PDP-8) formatted DECtape would have 578 blocks of 128 36-bit words. (256 18-bit words at the hardware level.) Blocks 0, 1, 2 are for DTBoot (hardware read-in bootstrap), and didn't contain user data. Block 100 is the directory block. Thus 574 blocks for user data. The directory holds up to 22 files, plus a map of which file owns each block. The user data blocks have a one word header (LH = next block of file; RH = first block & words used in this block) + 127 words of payload. This differed from disk files, where all 128 words were payload, so inattentive programmers could make a number of mistakes. (E.g. random access block isn't word/128; you had to pay attention to the buffer's word count, etc.) Data blocks of a file are (usually) not contiguous; this allowed the drive to stop and restart while reading or writing without having to reverse direction. The spacing depended on what blocks were free when files were written, and the data mode. (Files written in 'core dump' modes were assumed to be read by the monitor without stopping, so the gap was smaller, allowing larger programs to be read without reversing direction.) The gory details of the format are in the Monitor Calls manual (TOPS-10). The PDP-11 used 18-bit format, but ignored the high 2 bits of each word (except when reading PDP-10 tapes; the hardware for that was tricky as the high bits had to be read with programmed IO; the low 16 were DMAed on the TC-11.) The low-level formatting that established the mark track, end zones and block delimiters was done via a stand-alone diagnostic. This differs between the two formats. The directory block could be initialized under timesharing. Directory structure given is for the PDP-10; other OSs used different formats. >From an emulation point of view, the PDP-10's controller was the most >interesting; the driver does dead reckoning; that is, it will start a drive >spinning for a seek, disconnect, service other drives, and reconnect just >before the desired block is expected to be over the read head. So real-world >timing matters. The other controllers (and thus OSs) didn't support this. Oh, all numbers above are radix 10. The link for OS8 that I posted yesterday was via filewatcher; the direct link is ftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8/ Sorry if this was confusing. Of potential interest to low-level folks is http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN/3387293 Hope this is useful. This communication may not represent my employer's views, if any, on the matters discussed. On 18-Mar-13 16:26, Johnny Billquist wrote: On 2013-03-18 17:44, Bob Supnik wrote: I was trying to get a debug setup for PIP10, per Ian King's mail, when I discovered that none of my OS/8 images have PIP10 on them. This certainly explains why the feature has never been tested before. I suspect that ReadAll and WriteAll either are not working at all, or are not working when the DECtape format is 18b. Another possibility is that PDP-10 DECtape format is not the same as 18b format, at the nitty-gritty level (format of headers and trailers). The DECtape format as such, with all the headers and so on, is the same on all tapes. A normal PDP-8 formatted tape will have 129 (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would have 128 18-bit words (if I rem
Re: [Simh] PIP10 on PDP-8 SIM
On 2013-03-19 14:03, Timothe Litt wrote: The DECtape format as such, with all the headers and so on, is the same on all tapes. A normal PDP-8 formatted tape will have 129 (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would have 128 18-bit words (if I remember right). Pretty much right. 129 may be slightly misleading. The format is 129, but the -8 used only 128 of the 129 12-bit words/block for data. Right. :-) The PDP-10 is 36-bit, not 18-bit. A PDP-10 (actually, non-PDP-8) formatted DECtape would have 578 blocks of 128 36-bit words. (256 18-bit words at the hardware level.) I know that the PDP-10 is 36 bits. :-) I was talking about the DECtape as such, which physically always stores 18 bits. A PDP-10 would obviously store its 36-bit words using two DECtape words. Any 18-bit machine is straight forward, while the PDP-11 (as you mention below) only use 16 bits of the 18-bit word. I thought it was 128 18-bit words, but I may well remember that wrong, and the "normal" format is 256 18-bit words. Makes sense, when I think about it. The number of blocks is not absolutely fixed, but 578 is the "standard" except on the PDP-8, I guess. Blocks 0, 1, 2 are for DTBoot (hardware read-in bootstrap), and didn't contain user data. That would be very depending on which machine we're talking about, and which controller... :-) But I assume you're talking about the PDP-10 here. Did all PDP-10 with DECtapes use the same controller? I assume both the KA and KI had DECtapes, as well as the PDP-6. Block 100 is the directory block. Thus 574 blocks for user data. The directory holds up to 22 files, plus a map of which file owns each block. The user data blocks have a one word header (LH = next block of file; RH = first block & words used in this block) + 127 words of payload. This differed from disk files, where all 128 words were payload, so inattentive programmers could make a number of mistakes. (E.g. random access block isn't word/128; you had to pay attention to the buffer's word count, etc.) Data blocks of a file are (usually) not contiguous; this allowed the drive to stop and restart while reading or writing without having to reverse direction. The spacing depended on what blocks were free when files were written, and the data mode. (Files written in 'core dump' modes were assumed to be read by the monitor without stopping, so the gap was smaller, allowing larger programs to be read without reversing direction.) The gory details of the format are in the Monitor Calls manual (TOPS-10). TOPS-10 DECtape format is definitely not something I know anything about. But thanks for the rundown. The PDP-11 used 18-bit format, but ignored the high 2 bits of each word (except when reading PDP-10 tapes; the hardware for that was tricky as the high bits had to be read with programmed IO; the low 16 were DMAed on the TC-11.) Yes! Thanks for bringing another murky memory. The low-level formatting that established the mark track, end zones and block delimiters was done via a stand-alone diagnostic. This differs between the two formats. The directory block could be initialized under timesharing. Um? What two formats? Directory structure given is for the PDP-10; other OSs used different formats. From an emulation point of view, the PDP-10's controller was the most interesting; the driver does dead reckoning; that is, it will start a drive spinning for a seek, disconnect, service other drives, and reconnect just before the desired block is expected to be over the read head. So real-world timing matters. The other controllers (and thus OSs) didn't support this. Wow. The TC08 actually did seeks while actually looking at the tape, and then did DMA as well. So you didn't have to pay any more attention than to a disk controller. Essentially, you asked it to seek, and it indicated when the seek was done. You asked it to read, and it read. As far as I can remember, the TC11 is the same. Not sure what you mean by "other controllers didn't support this". What is "this". Doing dead reckoning? Why would you actually want to do dead reckoning. It makes much more sense to actually look at the tape the whole time it is spinning by, and not only when you are getting close to where you want to be. And the hardware can do that without your involvement. In a way, however, I'd say that the TD8E is the most "interesting" controller to emulate, since it is so incredibly stupid that you actually have to emulate the low level format of the tape for that controller to work. It is truly ugly. And that controller was a headache if you ever wanted to use it in a timesharing operating system, since it did not do DMA, it did not really do seeks, or in fact anything at all except just feed the bits from the tape to the computer as they whizzed by. Oh, all numbers above are radix 10. What's wrong with you. ;-) The link for OS8 that I posted yesterday was via filewatcher
Re: [Simh] PIP10 on PDP-8 SIM
The DECtape format as such, with all the headers and so on, is the same on all tapes. A normal PDP-8 formatted tape will have 129 (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would have 128 18-bit words (if I remember right). Pretty much right. 129 may be slightly misleading. The format is 129, but the -8 used only 128 of the 129 12-bit words/block for data. The PDP-10 is 36-bit, not 18-bit. A PDP-10 (actually, non-PDP-8) formatted DECtape would have 578 blocks of 128 36-bit words. (256 18-bit words at the hardware level.) Blocks 0, 1, 2 are for DTBoot (hardware read-in bootstrap), and didn't contain user data. Block 100 is the directory block. Thus 574 blocks for user data. The directory holds up to 22 files, plus a map of which file owns each block. The user data blocks have a one word header (LH = next block of file; RH = first block & words used in this block) + 127 words of payload. This differed from disk files, where all 128 words were payload, so inattentive programmers could make a number of mistakes. (E.g. random access block isn't word/128; you had to pay attention to the buffer's word count, etc.) Data blocks of a file are (usually) not contiguous; this allowed the drive to stop and restart while reading or writing without having to reverse direction. The spacing depended on what blocks were free when files were written, and the data mode. (Files written in 'core dump' modes were assumed to be read by the monitor without stopping, so the gap was smaller, allowing larger programs to be read without reversing direction.) The gory details of the format are in the Monitor Calls manual (TOPS-10). The PDP-11 used 18-bit format, but ignored the high 2 bits of each word (except when reading PDP-10 tapes; the hardware for that was tricky as the high bits had to be read with programmed IO; the low 16 were DMAed on the TC-11.) The low-level formatting that established the mark track, end zones and block delimiters was done via a stand-alone diagnostic. This differs between the two formats. The directory block could be initialized under timesharing. Directory structure given is for the PDP-10; other OSs used different formats. From an emulation point of view, the PDP-10's controller was the most interesting; the driver does dead reckoning; that is, it will start a drive spinning for a seek, disconnect, service other drives, and reconnect just before the desired block is expected to be over the read head. So real-world timing matters. The other controllers (and thus OSs) didn't support this. Oh, all numbers above are radix 10. The link for OS8 that I posted yesterday was via filewatcher; the direct link isftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8/ Sorry if this was confusing. Of potential interest to low-level folks is http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN/3387293 Hope this is useful. This communication may not represent my employer's views, if any, on the matters discussed. On 18-Mar-13 16:26, Johnny Billquist wrote: On 2013-03-18 17:44, Bob Supnik wrote: I was trying to get a debug setup for PIP10, per Ian King's mail, when I discovered that none of my OS/8 images have PIP10 on them. This certainly explains why the feature has never been tested before. I suspect that ReadAll and WriteAll either are not working at all, or are not working when the DECtape format is 18b. Another possibility is that PDP-10 DECtape format is not the same as 18b format, at the nitty-gritty level (format of headers and trailers). The DECtape format as such, with all the headers and so on, is the same on all tapes. A normal PDP-8 formatted tape will have 129 (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would have 128 18-bit words (if I remember right). The PDP-8, when doing 12-bit formatted tapes, just packs data in a way that is rather different from an 18-bit machine. But at the tape as such, there is nothing odd about it. But I can see lots of potential for errors when emulating this whole thing. I couldn't give exact details on lots of bits without looking in manuals, but in essence a DECtape is always doing 18-bit words. That is done by doing 6 groups of 3 bits each. A PDP-8 will pack three 12-bit words into two 18-bit words. This means that a DECtape block for a PDP-8 will only have 86 18-bit words. So the blocks are shorter, but you have more of them, when the tape is formatted for a PDP-8. I hope (assume) that you already know all of this. If not, let me know, and I can try helping out some more. I actually did dump a few 18-bit tapes on my PDP-8 only a few months ago, which is when I actually had to dig rather deep into all of this. PIP10 was one of the things I really looked into. But since my tapes had actually been written on a PDP-15, I had to writ
Re: [Simh] PIP10 on PDP-8 SIM
On 2013-03-18 17:44, Bob Supnik wrote: I was trying to get a debug setup for PIP10, per Ian King's mail, when I discovered that none of my OS/8 images have PIP10 on them. This certainly explains why the feature has never been tested before. I suspect that ReadAll and WriteAll either are not working at all, or are not working when the DECtape format is 18b. Another possibility is that PDP-10 DECtape format is not the same as 18b format, at the nitty-gritty level (format of headers and trailers). The DECtape format as such, with all the headers and so on, is the same on all tapes. A normal PDP-8 formatted tape will have 129 (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would have 128 18-bit words (if I remember right). The PDP-8, when doing 12-bit formatted tapes, just packs data in a way that is rather different from an 18-bit machine. But at the tape as such, there is nothing odd about it. But I can see lots of potential for errors when emulating this whole thing. I couldn't give exact details on lots of bits without looking in manuals, but in essence a DECtape is always doing 18-bit words. That is done by doing 6 groups of 3 bits each. A PDP-8 will pack three 12-bit words into two 18-bit words. This means that a DECtape block for a PDP-8 will only have 86 18-bit words. So the blocks are shorter, but you have more of them, when the tape is formatted for a PDP-8. I hope (assume) that you already know all of this. If not, let me know, and I can try helping out some more. I actually did dump a few 18-bit tapes on my PDP-8 only a few months ago, which is when I actually had to dig rather deep into all of this. PIP10 was one of the things I really looked into. But since my tapes had actually been written on a PDP-15, I had to write my own code in the end, to just dump the raw data. If anyone has a canned OS/8 V3C image with PIP10, please post it somewhere (like Mediafire) and let me know by email. I think someone already posted this, but I know I have that software, including sources (if I remember right) somewhere. Let me know if it can't be located anywhere else. Johnny ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] PIP10 on PDP-8 SIM
Well, there's http://www.filewatcher.com/b/ftp/sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8-0.html, which has V3d (and sources)... This communication may not represent my employer's views, if any, on the matters discussed. On 18-Mar-13 12:44, Bob Supnik wrote: I was trying to get a debug setup for PIP10, per Ian King's mail, when I discovered that none of my OS/8 images have PIP10 on them. This certainly explains why the feature has never been tested before. I suspect that ReadAll and WriteAll either are not working at all, or are not working when the DECtape format is 18b. Another possibility is that PDP-10 DECtape format is not the same as 18b format, at the nitty-gritty level (format of headers and trailers). If anyone has a canned OS/8 V3C image with PIP10, please post it somewhere (like Mediafire) and let me know by email. Thanks, /Bob Supnik ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh smime.p7s Description: S/MIME Cryptographic Signature ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] PIP10 on PDP-8 SIM
I was trying to get a debug setup for PIP10, per Ian King's mail, when I discovered that none of my OS/8 images have PIP10 on them. This certainly explains why the feature has never been tested before. I suspect that ReadAll and WriteAll either are not working at all, or are not working when the DECtape format is 18b. Another possibility is that PDP-10 DECtape format is not the same as 18b format, at the nitty-gritty level (format of headers and trailers). If anyone has a canned OS/8 V3C image with PIP10, please post it somewhere (like Mediafire) and let me know by email. Thanks, /Bob Supnik ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
