From mo09@badbit.math2.nat.tu-bs.de Wed Jan 11 10:07:45 EST 1995
Article: 1126 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!hookup!kinky.eng.gtefsd.com!europa.eng.gtefsd.com!howland.reston.ans.net!Germany.EU.net!news.dfn.de!gs.dfn.de!tubsibr!news.ibr.cs.tu-bs.de!pueschel
From: pueschel@math2.nat.tu-bs.de (Olaf Pueschel)
Newsgroups: alt.sys.pdp8
Subject: pdp8 tad instruction
Date: 10 Jan 1995 16:52:20 GMT
Organization: Institut fuer Angewandte Mathematik, TU Braunschweig
Lines: 29
Distribution: world
Message-ID: <PUESCHEL.95Jan10165220@badbit.math2.nat.tu-bs.de>
Reply-To: mo09@badbit.math2.nat.tu-bs.de
NNTP-Posting-Host: badbit.math2.nat.tu-bs.de

Hi folks!
Over X-mas I have been building my small own pdp8 assembler/simulator system.
It is quite workable now (yet not finished) and was quit some fun.
The only source of information I could usewas the pdp8-faq (posted here) and
this left open a few questions:
first (and most urgent): how does the TAD instruction *exactly* work with
negative numbers. As I understand the -8 has negative numbers stored as 2s
complement. How does this work with <l,ac> beeing treated as a 13 Bit unit?

Further, on which condition do the several skip instruction dealing with
ac negative/non-negative trigger? Is a number negative if its MSB is set?

In addition if someone could provide me with the functionality of the EAE
and the Memory extinsion units, on day I could impement these to :)

And - in the farer future - I am planing to add a X11 based front panel 
emulation. I have a GIF of a pdp8 front panel, but no desciption. If anyone
could provide any information, I'd be very happy :)

Of course all this stuff will be made public-avaialble when It's finished.

thanks to anyone providing *any* information
-olf
___
Olaf P"uschel, Broitzemer Str. 10, 38118 Braunschweig, Germany, +49-531-895643
--
  Olaf P"uschel Broitzemer Str. 10 38118 Braunschweig Germany +49 531 895643
-------------------------------------------------------------------------------
*** this is NOT a random-generated signature :-)


From lasner@sunSITE.unc.edu Wed Jan 11 10:08:15 EST 1995
Article: 1127 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: comp.sys.dec.micro,alt.sys.pdp8
Subject: Re: DECmate diskettes (ARRGGG!!)
Date: 11 Jan 1995 14:36:06 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 138
Message-ID: <3f0qcm$175q@bigblue.oit.unc.edu>
References: <3ejseo$kvt@hobbit.gandalf.ca>
NNTP-Posting-Host: president.oit.unc.edu
Xref: bigblue.oit.unc.edu comp.sys.dec.micro:3522 alt.sys.pdp8:1127

In article <3ejseo$kvt@hobbit.gandalf.ca>,
David Huddleson <dhuddleson@krypton.gandalf.ca> wrote:
>I hate when this happens...
>
>Out of someone's deep deep archives in the company, I have been presented
>with a box of RX50 diskettes once used on a DECmate (I have books for
>DECmate II as well as DECmate III, if it matters!!).
>
>We "unloaded" the last of our DECmates probably 2 years ago, so what
>to do??

There are many different ways to get partial recovery of the data.  How 
much you want to pay for how much of it is a factor.

>
>We still have a Rainbow or two around, but trying to read the diskettes 
>in the Rainbow failed (with both MS-DOS and CP/M). I don't know if
>the Rainbow actually can read the DECmate disks anyway, but I tried!

Wrong path to the wrong place.

>
>Can anyone suggest if or how I might be able to see what's on these diskettes,
>because of course the user feels there may be important info on the old
>diskettes (yeah!)
>
>Any help or suggestions would be appreciated.
>
>Thanks,
>
>David Huddleson		Gandalf Technologies Inc., Nepean, Ontario
>			dhuddleson@krypton.gandalf.ca


First of all, the disks clearly are *NOT* CP/M disks because all Rainbow 
and DECmate CP/M disks are in the same format.  MS-DOS disks for the 
DECmate are obscure and also compatible with Rainbow MS-DOS thus the same 
proof applies that they aren't MS-DOS RX50 disks either.

By and large WPS was what people used on DECmates.  Many of our readers 
would think otherwise, but I am talking about the original sold purpose 
of the hardware, not our collective thoughts on doing it differently, etc.

On the Rainbow itself there is a DEC package called WPS+.  Allegedly it 
can convert WPS/DM disks into its format, which are at the least files 
that live in the Rainbow (and thus DECmate!) MS-DOS file structure with 
innards of a presumably similar nature.  Some people have attempted to 
run parts of WPS+ on the DECmate MS-DOS only to find that the conversion 
part doesn't work there :-(.

On the DECmate there are three ways to get WPS files to somewhere else 
using DEC-suppled utilities, and at least one additional from a non-DEC 
source.

1)	Use DECmate MS-DOS CONVERT to move files between MS-DOS, CP/M-80 
and WPS format.

2)	Use DECmate CP/M-80 WPSCONV to move files between CP/M-80 and WPS format.

3)	Use DECmate OS/278 WPFLOP to move files between OS/278 and WPS format.

The first two can give document directory listings directly.  The third 
can indirectly because in WPS, document #1 *IS* the directory of all of 
the other documents.  All three methods suffer from the fact that the 
converted result is ASCII text sans WP-isms, etc.

The non-DEC method is to run WPS80 from EBS.  There is a version of it 
for both the Rainbow and DECmate w/CPM-80.  The result is converted files 
that live in a CP/M file structure whose innards are presumably similar 
to the original WPS innards.  Such CP/M diskettes can then be read 
wherever RX50 CP/M diskettes can be so read (22DISK on PC's, DECmate 
CP/M-80, Rainbow CP/M-86/80, etc.) but only WPS80 knows what to do with 
the file innards, etc.

Moving to a PC may or may not help.  While 22DISK can certainly move 
files from CP/M-80 RX50 per se, this does not help to deal with the 
actual file contents taken from any of the intermediary systems (such as 
WPS80).  DEC sold a package called WPS+PC that presumably can convert 
WPS+ (Rainbow) files.  The source are the WPS+ innards RX50 MS-DOS and 
the destination is WPS+PC MS-DOS PC files.  In any case you would have to 
deal with the PC-DOS files in WPS+PC innards format to move them to 
somewhere else.

An available somewhere else is to use Software Bridge for Windows.  As a 
source it likes so-called "DX" files (what WPS+PC normally creates) and 
as destination it likes things like WordPerfect, etc.

(Also I believe the same (different?) vendor sells a lesser product that
can only read a few different input formats, while the lone output format
is WordPerfect. The word "Perfect" is part of this product's name?  In 
any case, the so-called "DX" format is the relevant input format, etc.)

There also may be another way to get the files in that direction: use EBS'
WPS-DOS, which reportedly can convert the original WPS-DM disks directly. 
Presumably, WPS-DOS is also "DX" compatible, and seems to be a competing
compatible product with DEC's WPS+PC, but better in certain ways. 
(Questions: Does WPS-DOS and WPS+PC freely like each other's primary
format directly, or do you need some additional form of file import/export
conversion between them?  Even if so, it would still make DX files so
Software Bridge could move them to WordPerfect, etc. Does WPS-DOS like
WPS+ files? Does WPS-DOS like WPS80 files? Does WPS+PC and/or WPS-DOS
write any of the older formats (WPS/DM, WPS+, WPS80/CP/M) or just read
them?)

Finally, there is a sure-fire way to do it.  For likely far more money 
than its worth, there exists an "anything-to-anything" convertor 
subsystem for PC's from Shaftstall.  This consists of a hardware and 
software kit that adds various forms of flopy support to a PC including 
hard-sectored floppies and 8" drives, etc.  The programs themselves are 
written in the hard-sectored format so forget about copying them!  And of 
course it can't run without the supplied hardware, etc.

I have seen the Shaftstall helpout Video, and it uses as the primary 
example the conversion of WPS/DM documents directly to Wordperfect in one 
step.

If the person involved has a spare $15,000 to devote to this project, 
then it's real easy to get done :-).  Additionally, there are companies 
in the conversion business that charge similar rates to use their 
Shaftstall machines.  (Apparently they want about 1% of the cost of the 
hardware per diskette :-(.)

Lastly, all WPS-type systems support communications in "DX" format (not 
to be confused with that notion of what the file format for WPs+PC is 
called!) which means in theory that the files could be sent from where 
they are already loaded to another site with a different WPS-type system, 
etc.  Over the years, there have been various -11, -10/20, VAX, etc. 
systems that are compatible with this, as well as virtually all of the 
aforementioned, etc.  (However, this does not necessarily represent 
forward progress in the conversion process!  Just moving the problem 
around a little :-).)

OR of course you could scan the printouts (if available) and then have it 
in yet another system, etc. :-).

cjl


From lasner@sunSITE.unc.edu Wed Jan 11 10:08:24 EST 1995
Article: 1128 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: pdp8 tad instruction
Date: 11 Jan 1995 15:08:30 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 62
Message-ID: <3f0s9e$nn9@bigblue.oit.unc.edu>
References: <PUESCHEL.95Jan10165220@badbit.math2.nat.tu-bs.de>
NNTP-Posting-Host: president.oit.unc.edu

In article <PUESCHEL.95Jan10165220@badbit.math2.nat.tu-bs.de>,
Olaf Pueschel <mo09@badbit.math2.nat.tu-bs.de> wrote:
>Hi folks!
>Over X-mas I have been building my small own pdp8 assembler/simulator system.
>It is quite workable now (yet not finished) and was quit some fun.
>The only source of information I could usewas the pdp8-faq (posted here) and
>this left open a few questions:
>first (and most urgent): how does the TAD instruction *exactly* work with
>negative numbers. As I understand the -8 has negative numbers stored as 2s
>complement. How does this work with <l,ac> beeing treated as a 13 Bit unit?

Two's complement numbers are merely added.  The interpretation is what 
makes the numbers negative!  The Link gets complemented whenever a carry 
occurs, making the significence of the event user-defined, although 
totally predictable.  If the entire quantity is treated as a 13-bit 
unsigned number, then the user must preset the L and AC to whatever 
initial state makes sense for the problem at hand etc.  Instructions are 
available to clear, complement, and test the AC and L separately and 
together to form any useful manipulation.  If you decide that negative 
numbers are those with the high-order bit set, then test with SMA or SPA 
accordingly.  The arithmetic will conform to this, but there is no 
hardware present forcing the issue; you have to test for it.

>
>Further, on which condition do the several skip instruction dealing with
>ac negative/non-negative trigger? Is a number negative if its MSB is set?

SMA is skip if AC[0] is set.  Negativity is in the eye of the beholder :-).
SPA is skip if AC[0] is not set.  Same consideration otherwise.  OF 
course the instructions are there to encourage the use of two's 
complement 12-bit numbers, but nothing is forced, etc.

>
>In addition if someone could provide me with the functionality of the EAE
>and the Memory extinsion units, on day I could impement these to :)

The memory extension to 32K is quite important.  Emulation of a PDP-8 
disk device and 03/04 console support vastly enlarges the usefulness of 
the project.  This allows "real" PDP-8 software to run on the simulator, etc.

>
>And - in the farer future - I am planing to add a X11 based front panel 
>emulation. I have a GIF of a pdp8 front panel, but no desciption. If anyone
>could provide any information, I'd be very happy :)

Would be real cute, especially for beginners.  But pdp-8 people need the 
fully-fledged simulator features more than the "show" :-).)

>
>Of course all this stuff will be made public-avaialble when It's finished.
>
>thanks to anyone providing *any* information
>-olf
>___
>Olaf P"uschel, Broitzemer Str. 10, 38118 Braunschweig, Germany, +49-531-895643
>--
>  Olaf P"uschel Broitzemer Str. 10 38118 Braunschweig Germany +49 531 895643
>-------------------------------------------------------------------------------
>*** this is NOT a random-generated signature :-)

cjl


From jones@pyrite.cs.uiowa.edu Wed Jan 11 15:59:04 EST 1995
Article: 1129 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!news.mathworks.com!europa.eng.gtefsd.com!howland.reston.ans.net!spool.mu.edu!uwm.edu!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Newsgroups: alt.sys.pdp8
Subject: Re: pdp8 tad instruction
Date: 10 Jan 1995 17:53:29 GMT
Organization: University of Iowa, Iowa City, IA, USA
Lines: 67
Distribution: world
Message-ID: <3euhip$54r@nexus.uiowa.edu>
References: <PUESCHEL.95Jan10165220@badbit.math2.nat.tu-bs.de>
NNTP-Posting-Host: pyrite.cs.uiowa.edu

>From  article <PUESCHEL.95Jan10165220@badbit.math2.nat.tu-bs.de>, by pueschel@math2.nat.tu-bs.de (Olaf Pueschel):

> first (and most urgent): how does the TAD instruction *exactly* work with
> negative numbers. As I understand the -8 has negative numbers stored as 2s
> complement. How does this work with <l,ac> beeing treated as a 13 Bit unit?

Negative numbers are stored as 12 bit 2's complement numbers.

In adding numbers to the accumulator, a carry out of the high bit of the
accumulator causes the link bit to be complemented.  If it was zero, it
will be one; if it was one, it will be zero.

Here are some examples:

   L/AC    0 000000000001 =  1
         +   111111111111 = -1
     --------------------------
           1 000000000000 =  0
             
   L/AC    1 000000000001 =  1
         +   111111111111 = -1
     --------------------------
           0 000000000000 =  0

You, the programmer, are responsible for priming the link bit with an
appropriate value, where the initial value matters.

> Further, on which condition do the several skip instruction dealing with
> ac negative/non-negative trigger? Is a number negative if its MSB is set?

In the table below, I've marked the bits in L/AC that each skip instruction
tests:

  OR GROUP
           0 X00000000000   SMA   - skip if AC is negative
           0 XXXXXXXXXXXX   SZA   - skip if all bits of AC are zero
           X 000000000000   SNL   - skip if the link is nonzero
  AND GROUP
           0 X00000000000   SPA   - skip if AC is positive
           0 XXXXXXXXXXXX   SNA   - skip if some bit of AC is nonzero
           X 000000000000   SZL   - skip if the link is zero

> In addition if someone could provide me with the functionality of the EAE
> and the Memory extinsion units, on day I could impement these to :)

These are messy, and they vary depending on the PDP-8 model that
interests you.  You can find a short summary of some of the key
EAE instructions in the pdp-8 reference card collection available
by WWW from

   http://www.cs.uiowa.edu/~jones/pdp8/index.html

Someday, I'll sift through my piles of documentation and try to put
together a more complete definition in the WWW programmer's reference
manual that's in the same collection.

> And - in the farer future - I am planing to add a X11 based front panel 
> emulation. I have a GIF of a pdp8 front panel, but no desciption. If anyone
> could provide any information, I'd be very happy :)

You're welcome to borrow the X-11 front panel from my emulator.  It has
one rather substantial bug in the way it handles single-stepping, but
otherwise, it works well.  That emulator is indexed under the web page
mentioned above.
				Doug Jones
				jones@cs.uiowa.edu
				http://www.cs.uiowa.edu/~jones/


From lasner@sunSITE.unc.edu Fri Jan 13 13:36:57 EST 1995
Article: 1130 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: comp.sys.dec.micro,alt.sys.pdp8
Subject: Re: DECMATE III, I've forgot what it is.
Date: 13 Jan 1995 18:00:53 GMT
Organization: SunSITE, University of North Carolina, Chapel Hill
Lines: 28
Message-ID: <3f6f4l$142c@bigblue.oit.unc.edu>
References: <3f1no6$16b@ball.datastorm.com>
NNTP-Posting-Host: calzone.oit.unc.edu
Xref: bigblue.oit.unc.edu comp.sys.dec.micro:3529 alt.sys.pdp8:1130

In article <3f1no6$16b@ball.datastorm.com>,
John A. Maier <johnam@datastorm.com> wrote:
>I just bought a DECMATE III for the large amount of free.  Please help
>me remember what this beast is?  I want to think it's a 286 or was it a
>PDP-8 word processor and or CP/M machine.  There have been so may DEC
>micros I get confused.  Anyway, this is the one the size of a bread box
>with a RX-50 drive.  At the least I'll yank the RX-50 drive as a spare
>in case the on in my PRO-350 goes.  Hey, for those interested, I found the
>guy who wrote Uniforth (for you Forth fans of old).  He had (has) a
>version for the PDP-11, Pro-350 and VAX.  I bought a copy and am very
>happy.
>
>thanks
>jam
>johnam@datastorm.com (John A. Maier)
>


Please be advised that there are readers of a.s.p that need spare parts 
desperately for various projects, including maintaining other DECmates, 
etc.  You sound like someone who has no committment to the hardware you 
currently have.  Please give some others a chance who have a demonstrated 
need, etc.

Thank You

cjl


From jones@pyrite.cs.uiowa.edu Thu Jan 19 07:43:00 EST 1995
Article: 1131 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!news.mathworks.com!europa.eng.gtefsd.com!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Newsgroups: alt.jokes.pentium,alt.sys.pdp8
Subject: Re: Valuable Offer!
Date: 13 Jan 1995 19:19:40 GMT
Organization: University of Iowa, Iowa City, IA, USA
Lines: 21
Distribution: world
Message-ID: <3f6joc$qvj@nexus.uiowa.edu>
References: <D2CtLo.q0@maestro.maestro.com>
NNTP-Posting-Host: pyrite.cs.uiowa.edu
Xref: bigblue.oit.unc.edu alt.jokes.pentium:483 alt.sys.pdp8:1131

>From  article <D2CtLo.q0@maestro.maestro.com>, by cjl@maestro.maestro.com (Charles Lasner):
> In article <3eaq0k$lgh@paperboy.ids.net> Philip Chien <Pchien@ids.net> writes:

>>Anybody interested in a DEC PDP-8/S????  The first 'personal' (e.g. under
>>$10,000) computer ever made.  Makes a *GREAT* paperweight.  I don't think
>>it has the Pentium bug (tm) though - it could only add and subtract
>>integers - never could handle those division signs!

If you're serious, the machine is a museum piece, and I do have the complete
maintenance manual for it.  Unlike the pentium, it's an open architecture
machine, albeit a bit on the very slow side, even when compared with other
members of the PDP-8 family.

Note, however, that it doesn't subtract.  All arithmetic is done with the
TAD instruction (Two's Complement Add).  There is another instruction with
a microcoded format that includes bits to one's complement and increment
the accumulator -- if both bits are set, it does a two's complement, and
that plus TAD gives you subtraction.

				Doug Jones
				jones@cs.uiowa.edu


From mo09@badbit.math2.nat.tu-bs.de Thu Jan 19 07:43:20 EST 1995
Article: 1132 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!news.mathworks.com!europa.eng.gtefsd.com!howland.reston.ans.net!swrinde!pipex!news.oleane.net!oleane!jussieu.fr!univ-lyon1.fr!swidir.switch.ch!scsing.switch.ch!news.dfn.de!zeus.rbi.informatik.uni-frankfurt.de!terra.wiwi.uni-frankfurt.de!news.th-darmstadt.de!zib-berlin.de!gs.dfn.de!tubsibr!news.ibr.cs.tu-bs.de!pueschel
From: pueschel@math2.nat.tu-bs.de (Olaf Pueschel)
Newsgroups: alt.sys.pdp8
Subject: tad instaruction / thanks!
Date: 13 Jan 1995 14:27:19 GMT
Organization: Institut fuer Angewandte Mathematik, TU Braunschweig
Lines: 8
Distribution: world
Message-ID: <PUESCHEL.95Jan13142719@badbit.math2.nat.tu-bs.de>
Reply-To: mo09@badbit.math2.nat.tu-bs.de
NNTP-Posting-Host: badbit.math2.nat.tu-bs.de

I would like to express many thanks to Doug Jones, Charles Lasner and 
Bob Supnik for the prompt reply to my question. They helped me quite a lot.
tnx
-olf
--
  Olaf P"uschel Broitzemer Str. 10 38118 Braunschweig Germany +49 531 895643
-------------------------------------------------------------------------------
*** this is NOT a random-generated signature :-)


From stan@MathPro.com Thu Jan 19 07:43:42 EST 1995
Article: 1133 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!agate!howland.reston.ans.net!news.sprintlink.net!sundog.tiac.net!usenet
From: Stanley Rabinowitz <stan@MathPro.com>
Newsgroups: alt.sys.pdp8
Subject: Re: pdp8 tad instruction
Date: 15 Jan 1995 16:40:00 GMT
Organization: The Internet Access Company
Lines: 5
Message-ID: <3fbj50$nq6@sundog.tiac.net>
References: <PUESCHEL.95Jan10165220@badbit.math2.nat.tu-bs.de> <3f0s9e$nn9@bigblue.oit.unc.edu>
NNTP-Posting-Host: mathpro.com

So, if you implement TAD as if it were only adding unsigned
integers, you won't be going wrong.

- stan -


From rozee@elec.canterbury.ac.nz Thu Jan 19 07:44:36 EST 1995
Article: 1134 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!taco.cc.ncsu.edu!hsdndev!yale!yale!yale.edu!noc.near.net!bigboote.WPI.EDU!news.mathworks.com!europa.eng.gtefsd.com!howland.reston.ans.net!news.starnet.net!wupost!waikato!comp.vuw.ac.nz!canterbury.ac.nz!aldebaran!rozee
From: rozee@elec.canterbury.ac.nz (Robert Rozee)
Newsgroups: alt.sys.pdp8
Subject: decmate III bits
Date: 16 Jan 1995 02:53:16 GMT
Organization: Electrical Engineering, University of Canterbury, New Zealand
Lines: 32
Message-ID: <3fcn2s$c72@cantua.canterbury.ac.nz>
NNTP-Posting-Host: aldebaran.canterbury.ac.nz
X-Newsreader: TIN [version 1.2 PL2]

hi,
    just been having a bit of a clean out, and as a result i have some
'bits' of decmate III to get rid of.

  the decmate III is labeled pc238-ab on the back. there is no keyboard or
monitor. the rx-50 drive is faulty, and the case looks like it might make a
fine disk enclosure (as well as being a bit too heavy to post anywhere).

  as a consequence the 'bits' consist of the logic board and expansion bus
card. useful spares perhaps?

  in addition there are some disks and manuals.

bl-da82a-mv dm system test disk drive 0
bl-p115e-bv cbi - intro to wps - drive 0  training
bl-p116e-bv  "  -   "   "   "  - drive 1     "
bl-n354g-bv dm/wps system diskette v 2.0
options guide, aa-dj94a-tv, list processing/sort/maths/comms/sys mgr guide.
wps 'quick reference' guide.
the wps full manual (if there ever was one) is _not_ there (missing).

  all the above is 'free to a good home'. let me know if anything is of use
to you.


regards,
rob.

--
we are so blinded by our own existence that we
fail to see what is there when we are not.


From cjl@maestro.maestro.com Thu Jan 19 07:44:56 EST 1995
Article: 1135 of alt.sys.pdp8
Newsgroups: alt.jokes.pentium,alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!rutgers!dziuxsolim.rutgers.edu!uunet!maestro!cjl
From: cjl@maestro.maestro.com (Charles Lasner)
Subject: Re: Valuable Offer!
Message-ID: <D2CtLo.q0@maestro.maestro.com>
Organization: Maestro Technologies, Inc.
References: <3e437p$4ecs@usenetp1.news.prodigy.com> <3eaq0k$lgh@paperboy.ids.net>
Date: Fri, 13 Jan 1995 17:22:35 GMT
Lines: 13
Xref: bigblue.oit.unc.edu alt.jokes.pentium:507 alt.sys.pdp8:1135

In article <3eaq0k$lgh@paperboy.ids.net> Philip Chien <Pchien@ids.net> writes:
>
>Anybody interested in a DEC PDP-8/S????  The first 'personal' (e.g. under
>$10,000) computer ever made.  Makes a *GREAT* paperweight.  I don't think
>it has the Pentium bug (tm) though - it could only add and subtract
>integers - never could handle those division signs!
>
>Philip Chien, Earth News - space writer and consultant  PCHIEN@IDS.NET

Are you serious.  We at a.s.p want to know!

cjl


From ben@lonestar.jpl.utsa.edu Thu Jan 19 08:19:21 EST 1995
Article: 1136 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!rutgers!koriel!cs.utexas.edu!news.sprintlink.net!howland.reston.ans.net!swrinde!ringer.cs.utsa.edu!lonestar.jpl.utsa.edu!ben
From: ben@lonestar.jpl.utsa.edu (Ben A. Fairbank)
Newsgroups: alt.sys.pdp8
Subject: DEC-Tape Cacacity?
Date: 16 Jan 1995 21:56:52 GMT
Organization: University of Texas at San Antonio
Lines: 11
Distribution: world
Message-ID: <3feq34$ho8@ringer.cs.utsa.edu>
NNTP-Posting-Host: lonestar.jpl.utsa.edu

Twenty years ago, give or take a few, I worked as a PDP-8 assembly 
language programmer in addition to some scientific duties.  My OS/8 
manual is long gone, but I was recently wondering how the DEC-Tape 
minireels compare to our current diskettes.  Can anyone tell me the 
capacity of one small reel?  128 K of 12-bit words seems about right, 
but it is a figure pulled from the air.

Ben Fairbank


From johnam@datastorm.com Thu Jan 19 08:24:19 EST 1995
Article: 1137 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!gatech!swrinde!hookup!news.mathworks.com!zombie.ncsc.mil!golf!news
From: johnam@datastorm.com (John A. Maier)
Newsgroups: comp.sys.dec.micro,alt.sys.pdp8
Subject: Re: DECMATE III, I've forgot what it is.
Date: Tue, 17 Jan 95 16:28:55 PST
Organization: Datastorm Technologies Inc.
Lines: 22
Message-ID: <3fhfog$71a@golf.ustores.missouri.edu>
References: <3f1no6$16b@ball.datastorm.com> <3f3rt7$c9d@nexus.uiowa.edu>
NNTP-Posting-Host: 198.209.154.126
Mime-Version: 1.0
X-Newsreader: WinVN 0.93.0
Xref: bigblue.oit.unc.edu comp.sys.dec.micro:3545 alt.sys.pdp8:1137

In article <3f6f4l$142c@bigblue.oit.unc.edu>, lasner@sunSITE.unc.edu says...
>
>Please be advised that there are readers of a.s.p that need spare parts 
>desperately for various projects, including maintaining other DECmates, 
>etc.  You sound like someone who has no committment to the hardware you 
>currently have.  Please give some others a chance who have a demonstrated 
>need, etc.
>
I am just going to tinker around on it a bit just for fun.  Once I have 
had my fill, I'll be happy to put it up on the auction block.  If any
of you are interested or know of an interested party, drop me a note. I'll
put in a folder for future reference.  BTW, I have a number of OS/278
manuals that I got from a guy a number of years ago, so if anyone is
interested in these too, they will be up for grabs.  I always admired the
PDP-8, so this will just be one of those, just for the hell of it things,
so it will be a few months.  If you don't hear from me, just drop me a note
in case I forget.

thanks,
jam
johnam@datastorm.com (John A. Maier)


From yankus@ITD.Sterling.COM Thu Jan 19 08:28:41 EST 1995
Article: 1138 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!agate!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!dunix.drake.edu!sparky!yankus
From: yankus@ITD.Sterling.COM (Mike Yankus)
Newsgroups: alt.sys.pdp8
Subject: Re: DEC-Tape Cacacity?
Date: 17 Jan 1995 16:29:46 GMT
Organization: Sterling Software
Lines: 16
Message-ID: <3fgr9q$8h1@sparky.sterling.com>
References: <3feq34$ho8@ringer.cs.utsa.edu>
NNTP-Posting-Host: ssbell.itd.sterling.com

In article <3feq34$ho8@ringer.cs.utsa.edu>,
Ben A. Fairbank <ben@lonestar.jpl.utsa.edu> wrote:
>Twenty years ago, give or take a few, I worked as a PDP-8 assembly 
>language programmer in addition to some scientific duties.  My OS/8 
>manual is long gone, but I was recently wondering how the DEC-Tape 
>minireels compare to our current diskettes.  Can anyone tell me the 
>capacity of one small reel?  128 K of 12-bit words seems about right, 
>but it is a figure pulled from the air.
>
On a PDP-11 the TU56 DECtapes held 578 512-byte blocks or 289K bytes.

-- 
Mike Yankus	             
PRC Inc.                     INTERNET: yankus@ITD.Sterling.COM
1410 Wall St.                Phone:    (402) 291-8300 
Bellevue, NE. 68005-3687     FAX:      (402) 291-4362


From jones@pyrite.cs.uiowa.edu Thu Jan 19 08:29:09 EST 1995
Article: 1139 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!eff!news.umbc.edu!europa.eng.gtefsd.com!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Newsgroups: alt.sys.pdp8
Subject: Re: DEC-Tape Cacacity?
Date: 17 Jan 1995 16:29:47 GMT
Organization: University of Iowa, Iowa City, IA, USA
Lines: 19
Distribution: world
Message-ID: <3fgr9r$qjo@nexus.uiowa.edu>
References: <3feq34$ho8@ringer.cs.utsa.edu>
NNTP-Posting-Host: pyrite.cs.uiowa.edu

ben@lonestar.jpl.utsa.edu (Ben A. Fairbank):

> Twenty years ago, give or take a few, I worked as a PDP-8 assembly
> language programmer in addition to some scientific duties.  My OS/8
> manual is long gone, but I was recently wondering how the DEC-Tape
> minireels compare to our current diskettes.

Unformatted, a standard DECtape held 849,036 lines of 3 bits each, or
2,547,108 bits.  Formatted in 129 word blocks (as was standard on a
PDP-8, where only 128 of the 129 words were typically used), the
standard formatted tape contained 1464 blocks.

1464 x 128 = 187,392 words per tape, 12 bits each.  Converting to 8 bit
bytes, this is 281,088 bytes.

Someday, I've got to get my DECtape drives working!

                                        Doug Jones
                                        jones@cs.uiowa.edu


From johnam@datastorm.com Thu Jan 19 08:29:28 EST 1995
Article: 1140 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!rutgers!utcsri!newsflash.concordia.ca!news.mcgill.ca!mcrcim.mcgill.edu!bloom-beacon.mit.edu!satisfied.elf.com!news.mathworks.com!zombie.ncsc.mil!golf!news
From: johnam@datastorm.com (John A. Maier)
Newsgroups: comp.sys.dec.micro,alt.sys.pdp8
Subject: Re: DECMATE III, I've forgot what it is.
Date: Tue, 17 Jan 95 16:32:25 PST
Organization: Datastorm Technologies Inc.
Lines: 29
Message-ID: <3fhfv0$71a@golf.ustores.missouri.edu>
References: <3f1no6$16b@ball.datastorm.com> <3f3rt7$c9d@nexus.uiowa.edu> <3fhfog$71a@golf.ustores.missouri.edu>
NNTP-Posting-Host: 198.209.154.126
Mime-Version: 1.0
X-Newsreader: WinVN 0.93.0
Xref: bigblue.oit.unc.edu comp.sys.dec.micro:3547 alt.sys.pdp8:1140

In article <3fhfog$71a@golf.ustores.missouri.edu>, johnam@datastorm.com 
says...

>I am just going to tinker around on it a bit just for fun.  Once I have 
>had my fill, I'll be happy to put it up on the auction block.  If any
>of you are interested or know of an interested party, drop me a note. 
I'll
>put in a folder for future reference.  BTW, I have a number of OS/278
>manuals that I got from a guy a number of years ago, so if anyone is
>interested in these too, they will be up for grabs.  I always admired 
the
>PDP-8, so this will just be one of those, just for the hell of it 
things,
>so it will be a few months.  If you don't hear from me, just drop me a 
note
>in case I forget.
>
>thanks,
>jam
>johnam@datastorm.com (John A. Maier)
>
Oh yes, if any one has a good TK-50 around, I might be pursuaded to drop 
the whole lot into a box and ship it all off in exchange...hint, hint.

Yea, I have my price.

jam
johnam@datastorm.com (John A. Maier)


From mo09@badbit.math2.nat.tu-bs.de Thu Jan 19 08:38:54 EST 1995
Article: 1141 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!godot.cc.duq.edu!hudson.lm.com!news.pop.psu.edu!news.cac.psu.edu!howland.reston.ans.net!Germany.EU.net!news.dfn.de!zeus.rbi.informatik.uni-frankfurt.de!terra.wiwi.uni-frankfurt.de!news.th-darmstadt.de!fauern!gs.dfn.de!tubsibr!news.ibr.cs.tu-bs.de!pueschel
From: pueschel@math2.nat.tu-bs.de (Olaf Pueschel)
Newsgroups: alt.sys.pdp8
Subject: -8 memory managment question
Date: 17 Jan 1995 17:24:07 GMT
Organization: Institut fuer Angewandte Mathematik, TU Braunschweig
Lines: 20
Distribution: world
Message-ID: <PUESCHEL.95Jan17172407@badbit.math2.nat.tu-bs.de>
Reply-To: mo09@badbit.math2.nat.tu-bs.de
NNTP-Posting-Host: badbit.math2.nat.tu-bs.de

Hi folks!
When reading some of the documentation located on Doug Jones *great*
www pages, I ran into the following question:

How are the instruction/data field values handled to form a physical address?

are they a) used to select one of 8 mutually excusive memory banks
         b) prepended to the mem addr to form some sort of segment register
            (yes I worked on 80x86 machines :( )
         c) used in som other magical way?

-olf

PS: are there any other germans out here?
---
Olaf P"uschel, Broitzemer Str. 10, 38118 Braunschweig, Germany, +49-531-895643
--
  Olaf P"uschel Broitzemer Str. 10 38118 Braunschweig Germany +49 531 895643
-------------------------------------------------------------------------------
*** this is NOT a random-generated signature :-)


From lasner@sunSITE.unc.edu Thu Jan 19 08:39:16 EST 1995
Article: 1142 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: DEC-Tape Cacacity?
Date: 19 Jan 1995 13:26:02 GMT
Organization: SunSITE, University of North Carolina, Chapel Hill
Lines: 97
Message-ID: <3flp9a$mbj@bigblue.oit.unc.edu>
References: <3feq34$ho8@ringer.cs.utsa.edu>
NNTP-Posting-Host: calzone.oit.unc.edu

In article <3feq34$ho8@ringer.cs.utsa.edu>,
Ben A. Fairbank <ben@lonestar.jpl.utsa.edu> wrote:
>Twenty years ago, give or take a few, I worked as a PDP-8 assembly 
>language programmer in addition to some scientific duties.  My OS/8 
>manual is long gone, but I was recently wondering how the DEC-Tape 
>minireels compare to our current diskettes.  Can anyone tell me the 
>capacity of one small reel?  128 K of 12-bit words seems about right, 
>but it is a figure pulled from the air.
>
>Ben Fairbank
>
>
>


A *standard* PDP-8 DECtape *officially* holds 2702 octal blocks of 129 
decimal words each.  Other than the Disk Monitor and related software, 
most PDP-8 software ignores the 129th word.

There is a hardware restriction that since the mark-track design is a 
multiple of 6 info bits over 3 data bits each, the tape block length must 
be a multiple of 18 bits.  However, the only two official formats that 
DEC ever official endorsed are the PDP-8 format (derived from an 
arbitrary formula that is quite conservative) and the PDP-10/20/7/9/15/11 
format which is 384 decimal words each block and a total of 1102 blocks.  
Note that this format gives a whole lot more data, but is only considered 
an archival format on the PDP-8 (except for OS8 (no slash there!), see 
below).

The DECtape formatting program uses MARK384 as a special exception case 
that "violates" the formula to allow the extra data.  MARK129 just plugs 
into the formula producing the standard result, etc.

The extra capacity is there because there are far fewer inter-block 
zones, and additionally all of the tape is used.  Thus, while the tape 
was sold as a *nominal* 260 feet, you really need 10-20 feet more to 
properly support the MARK384 format.  Unfortunately, later DECtape sales 
were for shortened tape (sometimes to less than 260 feet; people measured 
it :-( !), and caused tapes to be relegated to MARK129 format strictly, 
or worse, when the worn end was cut off, it was then too short and was 
trashed :-(.

The older tapes that could format MARK384 with ease were often set aside 
for use as "extra-long" PDP-8 DECtapes formatted using a patched version 
of the format program that made MARK129 perform a format of 3000 blocks.  
P?S/8's version of the formatter has option switches to set this mode 
more easily, etc.

When the same media is used as LINCtape, even more blocks can be had.  
The reasons are as follows:

Other than for use on the PDP-12 version of the Disk Monitor, there is no 
sane reason to have 129 words/block, since LINC hardware only demands 
multiples of 12-bits, etc.  (Note: P?S/8 and OS/8 LINCtape PDP-12 
handlers all check for the possible presence of the nuisance 129th word.  
The potentially destroyed 129th word is stored before the DMA is started, 
and restored afterwards!)  Thus, using 128 words/block gets more blocks.

LINCtape has less overhead in the inter-block zone.  As a consequence, it 
cannot transfer backwards (but can search backwards; most PDP-8 software 
transfers forwards-only anyway.)  But this also contributes to higher 
tape block count.

LINCtape writes at a marginally higher density than DECtape.  As a 
defense against the ever-shortening tape lengths, some users cranked up 
the mark clock on their DECtape controllers (especially TC08) to get 
proper tape lengths anyway.  This could lead to trouble on TD8E-based 
systems.

As an alternative to tweaking the clock, "laying on of hands" (usually a 
thumb) is often used to get a little more tape usage on marginal length 
tapes.  Again, the TD8E consequences could be bad.

The best possible tape length achieved is 4000 octal blocks of 128 
decimal 12-bit words on a LINC-8.  However, there is an anomaly there:

The LINCtape format doesn't use end-zone sensing to turn the tape 
around!  Instead, dummy blocks -1, -2, -3, -4 etc. are written so the 
arithmetic search works the turn-around instead.  Additionally, the inner 
end should have blocks higher than the largest desired for the same 
reason.  However, on the PDP-12, the end-zone will tend to make the tape 
reverse, so this isn't a problem region, etc.

But on the LINC-8, if a block 4000 is searched forward after a transfer 
of block 3777, the search algorithm is blown, i.e., it will tend to make 
the tape turn *further* into the inner end, only to have the end-zone 
sensing reverse the tape direction.  Thus, the tape can get trapped in a 
search loop unless manually overridden.  Good tape handlers can avoid 
this assuming the next block transferred is a lower-numbered block,e tc.

So, the most optimistic PDP-8 capacity for this media is 4000 blocks or 
2048x128x12 bits.  I think that works out to 384 KBytes for those who 
can't count higher than 8.

cjl


From lasner@sunSITE.unc.edu Thu Jan 19 08:39:24 EST 1995
Article: 1143 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: comp.sys.dec.micro,alt.sys.pdp8
Subject: Re: DECMATE III, I've forgot what it is.
Date: 19 Jan 1995 13:31:08 GMT
Organization: SunSITE, University of North Carolina, Chapel Hill
Lines: 18
Message-ID: <3flpis$1ekn@bigblue.oit.unc.edu>
References: <3f1no6$16b@ball.datastorm.com> <3f3rt7$c9d@nexus.uiowa.edu> <3fhfog$71a@golf.ustores.missouri.edu>
NNTP-Posting-Host: calzone.oit.unc.edu
Xref: bigblue.oit.unc.edu comp.sys.dec.micro:3550 alt.sys.pdp8:1143

In article <3fhfog$71a@golf.ustores.missouri.edu>,
John A. Maier <johnam@datastorm.com> wrote:

<I am just going to tinker around on it a bit just for fun.  Once I have 
<had my fill, I'll be happy to put it up on the auction block.  If any
<of you are interested or know of an interested party, drop me a note. I'll
<put in a folder for future reference.  BTW, I have a number of OS/278
<manuals that I got from a guy a number of years ago, so if anyone is
<interested in these too, they will be up for grabs.  I always admired the
<PDP-8, so this will just be one of those, just for the hell of it things,
<so it will be a few months.  If you don't hear from me, just drop me a note
<in case I forget.

We will appropriately "bug" you :-).  However, you refer to "OS/278 
manuals".  Can you be a little more specific?

cjl


From lasner@sunSITE.unc.edu Thu Jan 19 08:39:41 EST 1995
Article: 1144 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: DEC-Tape Cacacity?
Date: 19 Jan 1995 13:35:38 GMT
Organization: SunSITE, University of North Carolina, Chapel Hill
Lines: 12
Message-ID: <3flpra$1bfc@bigblue.oit.unc.edu>
References: <3feq34$ho8@ringer.cs.utsa.edu> <3fgr9q$8h1@sparky.sterling.com>
NNTP-Posting-Host: calzone.oit.unc.edu

In article <3fgr9q$8h1@sparky.sterling.com>,
Mike Yankus <yankus@ITD.Sterling.COM> wrote:

>On a PDP-11 the TU56 DECtapes held 578 512-byte blocks or 289K bytes.

Nope.  There are 578 blocks, but each holds 256 18-bit words.  The PDP-11 
just chooses to waste some of the bits for most storage purposes.  Thus, 
your figure should be inflated by 1/8th.  (Unless you are referring to 
9-bit bytes :-).)

cjl


From lasner@sunSITE.unc.edu Thu Jan 19 08:39:51 EST 1995
Article: 1145 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: -8 memory managment question
Date: 19 Jan 1995 13:45:44 GMT
Organization: SunSITE, University of North Carolina, Chapel Hill
Lines: 53
Message-ID: <3flqe8$nhq@bigblue.oit.unc.edu>
References: <PUESCHEL.95Jan17172407@badbit.math2.nat.tu-bs.de>
NNTP-Posting-Host: calzone.oit.unc.edu

In article <PUESCHEL.95Jan17172407@badbit.math2.nat.tu-bs.de>,
Olaf Pueschel <mo09@badbit.math2.nat.tu-bs.de> wrote:
>Hi folks!
>When reading some of the documentation located on Doug Jones *great*
>www pages, I ran into the following question:
>
>How are the instruction/data field values handled to form a physical address?
>
>are they a) used to select one of 8 mutually excusive memory banks

On a 32K machine model this is the case.

>         b) prepended to the mem addr to form some sort of segment register
>            (yes I worked on 80x86 machines :( )
>         c) used in som other magical way?

There are two different forms of memory beyond 32K.  One is supported by 
two different (incompatible) memory controllers; the second is only 
supported by one of them.

The first is from DEC.  Memory is decoded further into "banks" each 
uniquely containing 32K of 8 fields as in the smaller model.  By careful 
redefinition, an additional addressing bit was inserted into the CIF and 
CDF instructions, and the additional support was added in other 
instructions.  The further additional bit to raise the addressing space 
to 128K is obtained by taking away all IOT's in the range of 630x-637x.  
For compatibility, this second part can be disabled, limiting the 
addressing to 64K.

The second is from CESI.  There are bank registers you have to load with 
additional instructions.  32K remains compatible, as long as you zero out 
the bank extensions.  Again, this gets you to 128K and it is hardware 
compatible with DEC's collections of up-to 128K memory boards.

However, it also supports a different buss decode for up to 512K using 
boards DEC never made.  The programming is essentially the same, only 
"wider" thus occupying more "bank" bits, etc.  (The KT8A buss was defined 
as a 1-of-4 select; the CESI 512K mode makes it a 4-bit encode, etc.)

>
>-olf
>
>PS: are there any other germans out here?
>---
>Olaf P"uschel, Broitzemer Str. 10, 38118 Braunschweig, Germany, +49-531-895643
>--
>  Olaf P"uschel Broitzemer Str. 10 38118 Braunschweig Germany +49 531 895643
>-------------------------------------------------------------------------------
>*** this is NOT a random-generated signature :-)

cjl


From kgg@mv.mv.com Tue Jan 24 11:48:36 EST 1995
Article: 1146 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!news.mathworks.com!udel!news.sprintlink.net!mv!mv.mv.com!kgg
From: kgg@mv.mv.com (Kenn Goutal)
Subject: Re: DEC-Tape Cacacity?
Message-ID: <D2L6xv.E8q@mv.mv.com>
Nntp-Posting-Host: mv.mv.com
Sender: usenet@mv.mv.com (System Administrator)
Organization: MV Communications, Inc.
Date: Wed, 18 Jan 1995 05:51:31 GMT
References: <3feq34$ho8@ringer.cs.utsa.edu> <3fgr9r$qjo@nexus.uiowa.edu>
Lines: 15

In article <3fgr9r$qjo@nexus.uiowa.edu>,
Douglas W. Jones,201H MLH,3193350740,3193382879 <jones@pyrite.cs.uiowa.edu> wrote:
>Someday, I've got to get my DECtape drives working!

When you do, I've got some files that need converting!

Actually, most of mine are LINCtape, though I also have a couple DECtapes.
I remember being impressed when, after my box of tapes had sat in the back
of my VW through 3 or 4 freezing winters and blazing summers, I plopped
some of them onto a drive, and after a few "warm-up" spins, they read in
just fine!

-- Kenn Goutal
kenn@mv.mv.com
http://www.mv.com/users/kgg/kenn.html


From ben@lonestar.jpl.utsa.edu Tue Jan 24 11:49:01 EST 1995
Article: 1147 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!agate!howland.reston.ans.net!swrinde!ringer.cs.utsa.edu!lonestar.jpl.utsa.edu!ben
From: ben@lonestar.jpl.utsa.edu (Ben A. Fairbank)
Newsgroups: alt.sys.pdp8
Subject: Was Re: DEC-Tape Cacacity?  Now gravitational interaction.
Date: 18 Jan 1995 14:02:41 GMT
Organization: University of Texas at San Antonio
Lines: 19
Message-ID: <3fj721$71b@ringer.cs.utsa.edu>
References: <3feq34$ho8@ringer.cs.utsa.edu> <3fgr9r$qjo@nexus.uiowa.edu> <D2L6xv.E8q@mv.mv.com>
NNTP-Posting-Host: lonestar.jpl.utsa.edu

In article <D2L6xv.E8q@mv.mv.com> kgg@mv.mv.com (Kenn Goutal) writes:

snip
>I remember being impressed when, after my box of tapes had sat in the back
>of my VW through 3 or 4 freezing winters and blazing summers, I plopped
>some of them onto a drive, and after a few "warm-up" spins, they read in
>just fine!
>
>-- Kenn Goutal
>kenn@mv.mv.com
 
Which reminds me that in '73 or so our lab had retreaded a 
clerk/administrator into a PDP-8 programmer (and a damn good one).  Her 
husband was our electonics technician and had explained to her that the 
magnetic dots on the tape tended to accumulate at the edges of the tape 
unless they were regularly rotated.  For months we, not knowing what he 
had told her, watched her every Monday picking up the tapes and turning
them over.  Finally someone asked her what she was doing...   


From rla@rahul.net Tue Jan 24 11:49:11 EST 1995
Article: 1148 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!gatech!howland.reston.ans.net!swrinde!sgiblab!rahul.net!a2i!rla.a2i!rla
From: Bob Armstrong <rla@rahul.net>
Newsgroups: comp.os.vms,alt.sys.pdp11,alt.sys.pdp8,vmsnet.misc
Subject: RX01/2 drive needed!
Followup-To: poster
Date: 19 Jan 1995 21:09:02 GMT
Organization: a2i network
Lines: 7
Distribution: usa
Message-ID: <3fmkde$prt@hustle.rahul.net>
NNTP-Posting-Host: foxtrot.rahul.net
NNTP-Posting-User: rla
Keywords: RX01 RX02
Xref: bigblue.oit.unc.edu comp.os.vms:84462 alt.sys.pdp8:1148 vmsnet.misc:3190

  I need a RX01 or RX02 drive unit.  I already have the controller.
Any offers or suggestions would be appreciated!

Thanks,

-- 
Bob Armstrong <rla@rahul.net>


From hassinger@eisner.decus.org Tue Jan 24 11:49:36 EST 1995
Article: 1149 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!rutgers!koriel!lll-winken.llnl.gov!uwm.edu!news.alpha.net!news.mathworks.com!noc.near.net!eisner!hassinger
From: hassinger@eisner.decus.org (Bob Hassinger)
Newsgroups: alt.sys.pdp8
Subject: Re: DEC-Tape Cacacity?
Message-ID: <1995Jan19.000834.8760@eisner>
Date: 19 Jan 95 00:08:33 -0500
References: <3feq34$ho8@ringer.cs.utsa.edu> <3fgr9r$qjo@nexus.uiowa.edu>
Distribution: world
Organization: DECUServe
Lines: 23

In article <3fgr9r$qjo@nexus.uiowa.edu>, jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) writes:
> ben@lonestar.jpl.utsa.edu (Ben A. Fairbank):
> 
>> Twenty years ago, give or take a few, I worked as a PDP-8 assembly
>> language programmer in addition to some scientific duties.  My OS/8
>> manual is long gone, but I was recently wondering how the DEC-Tape
>> minireels compare to our current diskettes.
> 
> Unformatted, a standard DECtape held 849,036 lines of 3 bits each, or
> 2,547,108 bits.  Formatted in 129 word blocks (as was standard on a
> PDP-8, where only 128 of the 129 words were typically used), the
> standard formatted tape contained 1464 blocks.
> 
> 1464 x 128 = 187,392 words per tape, 12 bits each.  Converting to 8 bit
> bytes, this is 281,088 bytes.

Not as well know where schemes to get more than the standard on a tape.  I
recall Jim VanZee telling me about using schemes as extreme as pressing on the
edge of the reel while the tape was being formatted to slow it down.  That let
him get more blocks on the tape.

Bob Hassinger
hassinger@merlin.lmig.com


From bqt@Krille.Update.UU.SE Tue Jan 24 11:50:03 EST 1995
Article: 1150 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!godot.cc.duq.edu!hudson.lm.com!news.pop.psu.edu!news.cac.psu.edu!howland.reston.ans.net!Germany.EU.net!EU.net!sunic!columba.udac.uu.se!Krille.Update.UU.SE!Krille.Update.UU.SE!not-for-mail
From: bqt@Krille.Update.UU.SE (Johnny Billquist)
Newsgroups: alt.sys.pdp8
Subject: Re: -8 memory managment question
Date: 18 Jan 1995 14:40:28 +0100
Organization: Update Computer Club
Lines: 26
Message-ID: <3fj5oq$jcq@Krille.Update.UU.SE>
References: <PUESCHEL.95Jan17172407@badbit.math2.nat.tu-bs.de>
NNTP-Posting-Host: krille.update.uu.se

In <PUESCHEL.95Jan17172407@badbit.math2.nat.tu-bs.de> pueschel@math2.nat.tu-bs.de (Olaf Pueschel) writes:

>Hi folks!
>When reading some of the documentation located on Doug Jones *great*
>www pages, I ran into the following question:

>How are the instruction/data field values handled to form a physical address?

>are they a) used to select one of 8 mutually excusive memory banks
>         b) prepended to the mem addr to form some sort of segment register
>            (yes I worked on 80x86 machines :( )
>         c) used in som other magical way?

Answer is a and b. They are really the same thing.
80x86 machines are a third variety, where the segment is shifted,
and *added* to the virtual address to get the physical address.
(The MMU on the pdp-11 works this way too, as do most modern machines,
the difference being that modern machines have the same size for
virtual and physical addresses).

	Johnny
-- 
Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: bqt@minsk.docs.uu.se       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From billh@haygood.com Tue Jan 24 11:51:12 EST 1995
Article: 1151 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!godot.cc.duq.edu!hudson.lm.com!news.pop.psu.edu!news.cac.psu.edu!howland.reston.ans.net!news.sprintlink.net!nwnexus!krel.iea.com!comtch!billh
From: billh@comtch.iea.com (Bill Haygood)
Newsgroups: alt.sys.pdp8
Subject: Re: -8 memory managment question
Date: 20 Jan 1995 00:27:00 GMT
Organization: home
Lines: 38
Distribution: world
Message-ID: <3fn00k$cj9@krel.iea.com>
References: <PUESCHEL.95Jan17172407@badbit.math2.nat.tu-bs.de>
Reply-To: billh@haygood.com
NNTP-Posting-Host: comtch.iea.com
X-Newsreader: TIN [version 1.2 PL1]

Olaf Pueschel (pueschel@math2.nat.tu-bs.de) wrote:

: How are the instruction/data field values handled to form a physical address?
: are they a) used to select one of 8 mutually excusive memory banks

On *indirect* AND, TAD, ISZ and DCA instructions only, the PDP-8 locates 
the field relative address (low order 12 bits) of the operand by fetching 
it either from the current instruction field page or page zero of the 
current instruction field.  The machine then prepends the DF to this 
12-bit address and the operand gets fetched from that address.  For all 
other *indirect* (and *all* direct instructions), the DF does not come 
into play.

:          b) prepended to the mem addr to form some sort of segment register
:             (yes I worked on 80x86 machines :( )

In the PDP-8, since the DF always gets "prepended" rather than shifted a 
few bits (as in the 80x86 uprocs), I personally find the PDP-8 scheme 
much easier to understand.  For example, in the PDP-8, one specifies an 
absolute address as a 5-digit octal number: 41600 (field 4, relative 
address 1600).  We generally don't use any other way to specify an 
absolute address.  In the Intel 80x86 uprocs, OTOH, you could specify 
absolute address 45678 as segment 4000, offset 5678 or as segment 4001,
offset 5668, or as segment 4002, offset 5658, or as segment 4100, 
offset 4678, ... (this could really get tedious after a while!).  (I once 
has to write a subroutine to return a true or false as to whether two 
80x86 addresses matched or not [given segment,offset as input]!)

:          c) used in som other magical way?

To many of us, the PDP-8 == pure magic!  After all, some consider 
the -8 as the very first RISC machine!

If either Bob Supnik at DEC and/or cjl at sunsite and/or anyone else 
read(s) this post, please feel free to critique my understanding of 
the DF register as outlined above.

Bill


From jones@pyrite.cs.uiowa.edu Tue Jan 24 11:52:28 EST 1995
Article: 1152 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!godot.cc.duq.edu!hudson.lm.com!news.pop.psu.edu!news.cac.psu.edu!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Newsgroups: alt.sys.pdp8
Subject: Re: DEC-Tape Cacacity?
Date: 18 Jan 1995 19:46:15 GMT
Organization: University of Iowa, Iowa City, IA, USA
Lines: 46
Distribution: world
Message-ID: <3fjr67$qes@nexus.uiowa.edu>
References: <D2L6xv.E8q@mv.mv.com>
NNTP-Posting-Host: pyrite.cs.uiowa.edu

>From article <D2L6xv.E8q@mv.mv.com>, by kgg@mv.mv.com (Kenn Goutal):
> 
> Actually, most of mine are LINCtape, though I also have a couple DECtapes.
> I remember being impressed when, after my box of tapes had sat in the back
> of my VW through 3 or 4 freezing winters and blazing summers, I plopped
> some of them onto a drive, and after a few "warm-up" spins, they read in
> just fine!

DECtape is an archivist's dream.  The sandwich mylar construction of the
tape makes it far less sensitive than normal mag-tape to such environmental
considerations such as humidity, and the massive redundancy of the
recording format (all bits recorded twice) makes it resistant to the
random flaking and dropout problems that plague those who try to read
ancient conventional tapes.

You can take a hole punch to a DECtape (the kind you'd use to punc a
ticket or make a hole in a page you wanted to put in a binder), and there's
a good chance you won't damage any data.  You lose out, though, if you're
unlucky enough to punch a hole opposite a bad spot in the tape that wiped
out the other copy of the bits you punched out.

I know some wonderful DECtape stories, the best being from a friend of mine
who loaded a DECtape on his PDP-10 upside down, then hit the load switch,
at which point, the whole reel of tape was dumped on the floor at high
speed.  He must have lost a bit too much sleep, but anyway, his reaction
was to pull the reels, pop them on right side up, and hit the load switch
again, at which point the tape was snapped back onto the reels at high
speed, complete with many folds, dirt from the floor, and various crumples.

His solution to the folds and crumples was to rock the tape quickly back
and forth over its whole length.  That got out most of the wrinkles, but
it set the others even harder.  Then, he pressed the tape down over the
head with his finger and wound the tape back and forth again to get it all
flat.

When he tried to read the tape, there were plenty of bad bits, but he
figured that they were just places where the wrinkles were holding the
tape away from the head, so he pressed his finger against the head while
he read the tape.  The friction was too much, but by hand cranking the
tape reels with a pencil while he held it against the head with a finger,
he successfully read the tape, without errors.

That was a good thing, it was the only tape he had with that data on it.

					Doug Jones
					jones@cs.uiowa.edu


From alexs@cyberquest.com Tue Jan 24 11:53:08 EST 1995
Article: 1153 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!agate!howland.reston.ans.net!swiss.ans.net!news.cyberquest.com!usenet
From: alexs@cyberquest.com
Newsgroups: alt.sys.pdp8
Subject: PDP-8 spare parts/systems.
Date: 20 Jan 1995 06:34:35 GMT
Organization: CyberQuest BBS
Lines: 15
Message-ID: <3fnlhr$jn8@starbug.cyberquest.com>
NNTP-Posting-Host: godfatherttyp8.cyberquest.com
X-Newsreader: AIR News 3.X (SPRY, Inc.)

I was in the last class year at the University of Michigan
Engin School to have logic lab/assembly programming class
on an old LINC/8 machine.  They switched to Z80s the next
semester.

I also did work study programming on various PDP-8s at the
Cooley Laboratory on the U of M's North Campus.  I recall
now that they had lots of those pesky plug-in circuit cards,
just enough to keep their systems in repair.  You might look
up Ted Birdsall or Kurt Metzger at the U of M to see whatever
became of their PDP-8 systems.  They might be long surplused,
but it's worth a try.

-Alexander Stoll, U of M class of 1980.


From wilsonj@alum01.its.rpi.edu Tue Jan 24 11:53:31 EST 1995
Article: 1154 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!news.mathworks.com!news2.near.net!howland.reston.ans.net!news.sprintlink.net!pipex!sunic!psinntp!psinntp!psinntp!rebecca!rpi!wilsonj
From: wilsonj@alum01.its.rpi.edu (John Wilson)
Newsgroups: alt.sys.pdp8
Subject: Re: DEC-Tape Cacacity?
Date: 17 Jan 1995 04:25:28 GMT
Organization: Rensselaer Polytechnic Institute, Troy NY
Lines: 16
Message-ID: <3ffgro$rhj@usenet.rpi.edu>
References: <3feq34$ho8@ringer.cs.utsa.edu>
NNTP-Posting-Host: alum01.its.rpi.edu

In article <3feq34$ho8@ringer.cs.utsa.edu>,
Ben A. Fairbank <ben@lonestar.jpl.utsa.edu> wrote:
>Can anyone tell me the 
>capacity of one small reel?  128 K of 12-bit words seems about right, 
>but it is a figure pulled from the air.

Right ballpark, it's actually a little more.  The "standard" format was
1474. blocks (somehow that's easier to remember in octal) of 129. words
each.  I think TOG-8 would let you mess around with weird formats but
at your own risk, the hardware requires a block to be a multiple of 36
bits but otherwise you could pretty much do your own thing and it would
work, with your own driver.  Even with stock format the tape would spin
off the end of the reel while formatting the end zone unless you had only
threaded it just enough to barely stay on the reel at the beginning.

John Wilson


From supnik@human.enet.dec.com Tue Jan 24 11:53:50 EST 1995
Article: 1155 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!taco.cc.ncsu.edu!lll-winken.llnl.gov!decwrl!pa.dec.com!sousa.tay1.dec.com!human.enet.dec.com!supnik
From: supnik@human.enet.dec.com (Bob Supnik)
Newsgroups: alt.sys.pdp8
Subject: Re: pdp8 tad instruction
Date: 12 JAN 95 14:18:24
Organization: Digital Equipment Corporation
Lines: 13
Distribution: world
Message-ID: <3f3vck$9te@sousa.tay1.dec.com>
References: <PUESCHEL.95Jan10165220@badbit.math2.nat.tu-bs.de>
NNTP-Posting-Host: human.enet.dec.com


In article <PUESCHEL.95Jan10165220@badbit.math2.nat.tu-bs.de>, pueschel@math2.nat.tu-bs.de (Olaf Pueschel) writes...
> [text deleted]
>In addition if someone could provide me with the functionality of the EAE
>and the Memory extinsion units, on day I could impement these to :)
> 
I realize it takes the fun out, but check one of the published simulators
(mine or Bill Haygood's) for the memory extension and EAE.  I wrote mine
from the maintenance manual and code checked Bill's for compliance.

Bob Supnik	>Supnik@human.enet.dec.com
		>All opinions expressed are those of a hardline microcoder
		>and do not reflect those of Digital Equipment Corporation


From Pchien@ids.net Tue Jan 24 11:54:17 EST 1995
Article: 1156 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!taco.cc.ncsu.edu!lll-winken.llnl.gov!sol.ctr.columbia.edu!howland.reston.ans.net!pipex!uunet!paperboy.ids.net!pslip016.ksc-fl.ids.net!Pchien
From: Philip Chien <Pchien@ids.net>
Newsgroups: alt.jokes.pentium,alt.sys.pdp8
Subject: Re: Valuable Offer!
Date: 16 Jan 1995 20:21:06 GMT
Organization: Earth News
Lines: 28
Distribution: world
Message-ID: <3fekfi$2i8@paperboy.ids.net>
References: <D2CtLo.q0@maestro.maestro.com>
NNTP-Posting-Host: pslip016.ksc-fl.ids.net
X-Newsreader: Nuntius Version 1.2
X-XXMessage-ID: <AB403F8BA1021510@pslip016.ksc-fl.ids.net>
X-XXDate: Mon, 16 Jan 1995 20:21:47 GMT
Xref: bigblue.oit.unc.edu alt.jokes.pentium:559 alt.sys.pdp8:1156

In article <D2CtLo.q0@maestro.maestro.com> Charles Lasner,
cjl@maestro.maestro.com writes:
>In article <3eaq0k$lgh@paperboy.ids.net> Philip Chien <Pchien@ids.net>
writes:
>>
>>Anybody interested in a DEC PDP-8/S????  The first 'personal' (e.g.
under
>>$10,000) computer ever made.  Makes a *GREAT* paperweight.  I don't
think
>>it has the Pentium bug (tm) though - it could only add and subtract
>>integers - never could handle those division signs!
>>
>>Philip Chien, Earth News - space writer and consultant  PCHIEN@IDS.NET
>
>Are you serious.  We at a.s.p want to know!

Actually, considering that I just had to carry the 200 lb. monster 20
miles to my new home, yes I am serious - I've got a DEC PDP-8/S here. 
Makes a great paperweight ...

Philip Chien, Earth News - space writer and consultant  PCHIEN@IDS.NET
   __                                 __^__          __________
  |   \                          +---/     \---+    (=========
  |____\___________              +---\_____/---+     //
  >____)|        | \__                    \  \______//___
 >/     |________|    \                   [         _____\
 >|____________________\                   \_______/
 Roger, go at throttle up         CHR$(32) the final frontier


From rtschalaer@cvax.psi.ch Tue Jan 24 11:54:38 EST 1995
Article: 1157 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!news.mathworks.com!news.alpha.net!uwm.edu!math.ohio-state.edu!howland.reston.ans.net!pipex!news.oleane.net!oleane!jussieu.fr!univ-lyon1.fr!swidir.switch.ch!scsing.switch.ch!pss100.psi.ch!psiclu.psi.ch!rtschalaer
From: rtschalaer@cvax.psi.ch (Life is hard... and then you die!)
Newsgroups: alt.sys.pdp8
Subject: circuit diagrams for the VT78
Date: 23 Jan 95 16:26:07 +0200
Organization: Paul Scherrer Institute
Lines: 16
Message-ID: <1995Jan23.162607.1@psiclu.psi.ch>
NNTP-Posting-Host: psiclb.psi.ch


  Hi,

Does anybody happen to have circuit diagrams for the VT78? The power supply
is bust, and I'm having trouble fixing it because many of the parts are
labeled in an unconventional (for me) way. Since the power supply is
switchable for 110V and 230V, I assume they used the same one for models
sold in the states. If anybody has access to these diagrams and could send
me photocopies (postage and packing will be paid) or if anybody could give
me some pointers as to where these could be attained (DEC here wasn't very
helpful) I'd be grateful.

  TIA,

  Ronald


From Owie@ix.netcom.com Sat Jan 28 12:44:05 EST 1995
Article: 1158 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!news.mathworks.com!news.alpha.net!uwm.edu!cs.utexas.edu!howland.reston.ans.net!ix.netcom.com!netnews
From: Owie@ix.netcom.com (Owen Fisk)
Newsgroups: alt.sys.pdp8
Subject: Re: circuit diagrams for the VT78
Date: 24 Jan 1995 01:03:44 GMT
Organization: Netcom
Lines: 28
Distribution: world
Message-ID: <3g1jlg$4h3@ixnews2.ix.netcom.com>
References: <1995Jan23.162607.1@psiclu.psi.ch>
NNTP-Posting-Host: ix-sac1-25.ix.netcom.com

In <1995Jan23.162607.1@psiclu.psi.ch> rtschalaer@cvax.psi.ch (Life is 
hard... and then you die!) writes: 

>
>
>  Hi,
>
>Does anybody happen to have circuit diagrams for the VT78? The power 
supply
>is bust, and I'm having trouble fixing it because many of the parts are
>labeled in an unconventional (for me) way. Since the power supply is
>switchable for 110V and 230V, I assume they used the same one for 
models
>sold in the states. If anybody has access to these diagrams and could 
send
>me photocopies (postage and packing will be paid) or if anybody could 
give
>me some pointers as to where these could be attained (DEC here wasn't 
very
>helpful) I'd be grateful.
>
>  TIA,
>
>  Ronald
>
>

Try Jerrasic Park - this thing is a real dinasaur


From russ@cs.indiana.edu Sat Jan 28 14:16:55 EST 1995
Article: 1159 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!news.mathworks.com!news.alpha.net!uwm.edu!spool.mu.edu!news.cs.indiana.edu!russ@cs.indiana.edu
From: "J Russ" <russ@cs.indiana.edu>
Subject: Re: PDP-8 spare parts/systems.
Message-ID: <1995Jan23.194547.28781@news.cs.indiana.edu>
Organization: Computer Science, Indiana University
References: <3fnlhr$jn8@starbug.cyberquest.com>
Date: Mon, 23 Jan 1995 19:45:43 -0500
Lines: 29

In article <3fnlhr$jn8@starbug.cyberquest.com>,  <alexs@cyberquest.com> wrote:
>I also did work study programming on various PDP-8s at the
>Cooley Laboratory on the U of M's North Campus.  I recall
>now that they had lots of those pesky plug-in circuit cards,
>just enough to keep their systems in repair.  You might look
>up Ted Birdsall or Kurt Metzger at the U of M to see whatever
>became of their PDP-8 systems.  They might be long surplused,
>but it's worth a try.

I bought all the PDP8/LINC8 stuff at the Cooley Laboratory back in 1987.  It
was an interesting collection of stuff.  One of the machines was an old LINC8
down in the basement buried away in a back room.  Near the machine was a copy
of a radical newspaper from the late 1960's so the machine may have been
there for a long time.  The LINC8 was missing the core memory and various odds
& ends but eventually I was able to rebuild the machine and run the SUDSY
diagnostics and demo programs.  Another interesting artifact was a box of smoke
damaged A series modules that were out of a LINC8 in Florida that had caught on
fire.  I also got a couple of the cloned DECTAPE drives (I can't remember the
name of the manufacturer) but haven't tried firing them up yet.

U of M and Ann Arbor are interesting places to visit.  If you're ever up there
stop in at the university surplus building and check out all of the interesting
junk they have for sale.  When I was there in November I picked up a couple of
junked Apollo workstations for use as parts in my Apollo workstation collection.
I didn't see any PDP8 stuff but it may pass through occassionly.  Before you
head out of town be sure to check out the new and used book stores in downtown
Ann Arbor. 
					Jeff Russ
					Bloomington, IN


From frank@rover.uchicago.edu Sat Jan 28 15:17:46 EST 1995
Article: 1160 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!news.mathworks.com!usenet.eel.ufl.edu!usenet.cis.ufl.edu!caen!msunews!uchinews!rover.uchicago.edu!frank
From: frank@rover.uchicago.edu (Frank R. Borger)
Subject: Re: DEC-Tape Cacacity?
Message-ID: <frank.166.2F259A3D@rover.uchicago.edu>
Lines: 23
Sender: news@uchinews.uchicago.edu (News System)
Organization: Radiation Therapy, Michael Reese Hospital
References: <3feq34$ho8@ringer.cs.utsa.edu> <3ffgro$rhj@usenet.rpi.edu>
Date: Wed, 25 Jan 1995 00:24:29 GMT

In article <3ffgro$rhj@usenet.rpi.edu> wilsonj@alum01.its.rpi.edu (John Wilson) writes:

>... Even with stock format the tape would spin
>off the end of the reel while formatting the end zone unless you had only
>threaded it just enough to barely stay on the reel at the beginning.

	That was a commony symptom of a mal-adjsted formatter.

	The interface used an adjustable oscillator to determine how
	OFTEN you wrote formatting data, with the tape moving at constant
	reel speed. If the frequency of the oscillator was a little low,
	the format marks were too far apart and you ended up running off
	the end of the reel.

	I remember an article that actually made it into DECUScope that
	described how one software specialist re-wrote the formatter to
	only do 6' instead of 10' leader/trailer sections.

Frank R. Borger - Physicist     ___      What's the difference between:
Michael Reese - U of Chicago   |___      (1) having a baby and 
Center for Radiation Therapy   | |_) _   (2) doing an RSX11M sysgen?
net: Frank@rover.uchicago.edu    | \|_)
ph: 312-791-8075 fa: 791-2517       |_)  Having a baby only takes 9 months!


From rla@rahul.net Sat Jan 28 15:18:03 EST 1995
Article: 1161 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!gatech!howland.reston.ans.net!news.sprintlink.net!news.clark.net!rahul.net!a2i!rla.a2i!rla
From: Bob Armstrong <rla@rahul.net>
Newsgroups: comp.os.vms,alt.sys.pdp11,alt.sys.pdp8
Subject: DEC part number for RL02 unit number plugs ?
Followup-To: poster
Date: 26 Jan 1995 20:10:31 GMT
Organization: a2i network
Lines: 12
Distribution: usa
Message-ID: <3g8vjn$rbu@hustle.rahul.net>
NNTP-Posting-Host: bolero.rahul.net
NNTP-Posting-User: rla
Xref: bigblue.oit.unc.edu comp.os.vms:84972 alt.sys.pdp8:1161

  Can someone tell me the part number for the unit select plugs on
the front of a RL02 ?  I have an RL02 that would work if I just had
the right numbered plug for it!  I need a #2 if it makes a difference.

  DEC part number assistance has not been able to figure this out -
the best they could do was to come up with the part number for the
entire front panel!

Thanks,

-- 
Bob Armstrong <rla@rahul.net>


From prep@yarrow.wt.uwa.edu.au Sat Jan 28 15:19:34 EST 1995
Article: 1162 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!taco.cc.ncsu.edu!lll-winken.llnl.gov!noc.near.net!bigboote.WPI.EDU!news.mathworks.com!zombie.ncsc.mil!news.duke.edu!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!swrinde!ihnp4.ucsd.edu!munnari.oz.au!news.uwa.edu.au!news!prep
From: prep@yarrow.wt.uwa.edu.au (Paul Repacholi)
Newsgroups: alt.sys.pdp8
Subject: Re: circuit diagrams for the VT78
Date: 24 Jan 1995 22:53:20 GMT
Organization: Winthrop Technology
Lines: 9
Distribution: world
Message-ID: <PREP.95Jan25065320@yarrow.wt.uwa.edu.au>
References: <1995Jan23.162607.1@psiclu.psi.ch> <3g1jlg$4h3@ixnews2.ix.netcom.com>
NNTP-Posting-Host: yarrow.wt.uwa.edu.au
In-reply-to: Owie@ix.netcom.com's message of 24 Jan 1995 01:03:44 GMT

Or try a vt100 print set, or vt5x...

--
~Paul
                                                       +61 (09) 257-1001
prep@yarrow.wt.uwa.edu.au ( preferred )                1 Crescent Rd,
zrepachol@cc.curtin.edu.au                             Kalamunda,
                                                       West Aust    6076


From seymour@u.washington.edu Sat Jan 28 15:20:04 EST 1995
Article: 1163 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!gatech!howland.reston.ans.net!news.sprintlink.net!pipex!uunet!news.u.washington.edu!seymour
From: seymour@u.washington.edu (Richard Seymour)
Newsgroups: comp.os.vms,alt.sys.pdp11,alt.sys.pdp8
Subject: Re: DEC part number for RL02 unit number plugs ?
Date: 27 Jan 1995 23:03:58 GMT
Organization: University of Washington
Lines: 18
Distribution: usa
Message-ID: <3gbu4u$bui@nntp1.u.washington.edu>
References: <3g8vjn$rbu@hustle.rahul.net>
NNTP-Posting-Host: saul2.u.washington.edu
Xref: bigblue.oit.unc.edu comp.os.vms:85072 alt.sys.pdp8:1163

In article <3g8vjn$rbu@hustle.rahul.net>, Bob Armstrong  <rla@rahul.net> wrote:
>  Can someone tell me the part number for the unit select plugs on
>the front of a RL02 ?  I have an RL02 that would work if I just had
>the right numbered plug for it!  I need a #2 if it makes a difference.
>
>  DEC part number assistance has not been able to figure this out -
>the best they could do was to come up with the part number for the
>entire front panel!

 it's 12-12691-00   (for unit zero... break pins for other numbers)

 ??? can't DEC use IPB fiche anymore??
--dick (from the land of obsolete parts...)

hmmm... i just looked it up in a 1993 catalog... the "-00" denotes
 unit zero, -01 unit one, etc. but the prices are interesting:
 zero and one are $2 each.  two and three are $4 each.  five and six are $1.


From ivie@cc.usu.edu Sat Jan 28 15:20:30 EST 1995
Article: 1164 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!rutgers!rochester!galileo.cc.rochester.edu!ub!news.kei.com!news.mathworks.com!udel!news.sprintlink.net!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!ivie
From: ivie@cc.usu.edu
Newsgroups: alt.sys.pdp8
Subject: Re: circuit diagrams for the VT78
Message-ID: <1995Jan25.095613.39182@cc.usu.edu>
Date: 25 Jan 95 09:56:13 MDT
References: <1995Jan23.162607.1@psiclu.psi.ch> <3g1jlg$4h3@ixnews2.ix.netcom.com> <PREP.95Jan25065320@yarrow.wt.uwa.edu.au>
Distribution: world
Organization: Utah State University
Lines: 14

In article <PREP.95Jan25065320@yarrow.wt.uwa.edu.au>, prep@yarrow.wt.uwa.edu.au (Paul Repacholi) writes:
> Or try a vt100 print set, or vt5x...
> 
The power supply on a VT78 is different from the power supply on the VT5x.
The VT52 has a large transformer in the "printer" area which, presumably,
had to be moved to put the PDP-8 in there. The VT78 has a power supply
module in the back of the terminal.

I have a print set for the VT52, but it certainly did _me_ no good when my
VT78's power supply decided to become a paperweight.
-- 
----------------+------------------------------------------------------
Roger Ivie      | Don't think of it as a 'new' computer, think of it as
ivie@cc.usu.edu |     'obsolete-ready'


From lasner@sunSITE.unc.edu Sat Jan 28 15:21:07 EST 1995
Article: 1165 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: PDP-8 spare parts/systems.
Date: 28 Jan 1995 19:15:59 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 175
Message-ID: <3ge55f$lke@bigblue.oit.unc.edu>
References: <3fnlhr$jn8@starbug.cyberquest.com> <1995Jan23.194547.28781@news.cs.indiana.edu>
NNTP-Posting-Host: president.oit.unc.edu

In article <1995Jan23.194547.28781@news.cs.indiana.edu>,
J Russ <russ@cs.indiana.edu> wrote:

>I bought all the PDP8/LINC8 stuff at the Cooley Laboratory back in 1987.  It
>was an interesting collection of stuff.  One of the machines was an old LINC8
>down in the basement buried away in a back room.  Near the machine was a copy
>of a radical newspaper from the late 1960's so the machine may have been
>there for a long time.  The LINC8 was missing the core memory and various odds
>& ends but eventually I was able to rebuild the machine and run the SUDSY
>diagnostics and demo programs.  Another interesting artifact was a box of smoke
>damaged A series modules that were out of a LINC8 in Florida that had caught on
>fire.  I also got a couple of the cloned DECTAPE drives (I can't remember the
>name of the manufacturer) but haven't tried firing them up yet.

The Cooley Labs LINC-8 collection is the original source of quite a few 
LINC8-specific things.

The unmodified 4-K LINC-8 cannot support running P?S/8 due to the 
complexity of the LINCtape control.  (Similarly, you cannot run OS/8 on 
an unmodified 8K LINC-8.)

By making a few hardware changes, it's possible to run a kludgy P?S/8 
and/or (if you have 8K!) OS/8 system with some limitations:

1)	Inadequate error recovery (sorely needed on a tape system)

2)	Always searches forwards first, even though statistically, 99.99% 
of the time backwards search is best.  (Quite pessimized :-).)

(Note: there is the possibility of a P?S/8 handler for an 8K 
*un-modified* machine and an OS/8 system handler for a 12K unmodified 
machine.  Also, one LINC-8 was definitely used with a DF32 using the 
standard system handler for the DF32 and two-page non-system handlers for 
the LINCtapes, etc.  An item being sought towards this and related ends 
is the modifications to the LINC-8 so that you could have DMA devices 
past 4K.  The stock LINC-8 doesn't support this!  Yet, apparently DEC 
came up with ECO's to the machine to support it for at least this very 
site.  (LINCtape isn't DMA, and the buss is taken over for DMA purposes 
by the LINC CPU, etc. so there isn't available a DMA channel for extended 
memory, etc.)  Anyone with any info about these hardware mod's?  I 
suspect the machine was installed at WVU at one point, etc.)

Several individuals at Syracuse University and I participated in an 
"upgrade" to the Cooley-defined changes.  As a requirement of our spec, 
we incorporate other changes from Cooley that allow DECtape to be 
read/written on the LINC-8 (as well as NOVA LINCtapes.  BTW, NOVA 
LINCtapes also use the strange drives Jeff mentioned; they were made by 
Computer Operations in Beltsville, MD.)

The DECtape changes are useful, but are somewhat unreliable for the 
purpose.  We expanded on both sets of changes to add additional features:

i)	Faster access to the registers that mattered, such as a direct 
skip-on-flag-up set instead of the longer ICON interface that multiplexes 
several registers with sense bits, etc.

ii)	One instruction to force tape searching mode directly.

iii)	Coupled with ii, a means of forcing an initial tape search 
direction "guess" where it self-clears when a transfer is initiated thus 
all subsequent transfers are forwards, but the search ls (likely) backwards.

The DECtape-oriented changes involve adding a device selector to get 
three IOT's.  We added 4 extra instructions using full decoding to get 
all of the above improvements.  Thus, the net result is compatible with 
the un-modified machine, the slightly modified machine with or without 
the DECtape-oriented enhancements, and of course itself.

Using all of the improvements, the following have been successfully written:

1)	A 4K P?S/8 system handler which I use on my 4K LINC-8.  It can 
handle up to 8 drives (if you implement them!  I have heard of machines 
with drives 4,5 added, but never the other 4 drives!), and can search 
with an intelligent guess ala the P?S/8 DECtape TC01/08 system handler.  
Additionally, no compromise is needed regarding DMA devices such as 
DF32.  (Note: when the minimal change version was used, we compromised 
the handler such that if the DF32 were also present, it would destroy the 
tape handler!  Both P?S/8 and OS/8 share a common rule that had been 
broken in this case: Always use locations 07750-07755 as temporaries only 
since these could be DMA locations for TC01/08 or TC58 or DF32/RF08.  
That older handler stuck code and/or constants into this area and thus 
was in jeopardy, etc.  This newer handler that depends on all of the 
hardware mods now obeys this rule, etc.)

2)	A similarly equipped OS/8 handler for 8K machines.

The mods have been applied to both my 4K LINC-8 and also an 8K LINC-8 now 
residing in my basement.

3)	one-page non-system handlers without compromise are now possible 
for both systems.  (Note: even without hardware mods, it's possible to 
produce a slightly compromised one-page handler, and no problem in 
two-pages.)

4)	Much more reliable DECtape <-> LINCtape transfers.  I wrote a 
block-oriented utility (a fore-runner of the more generic P?S/8 utility 
BLKCPY) to move DECtape blocks around on the modified LINC-8.  The 
following commands are typical of usage: (Note: the "*" is the prompt char!)

.R BLKCPY
*DTA1:0-2701>LTA0:0		{transfer an entire DECtape to a LINCtape}
*LTA0:0-2701<DTA1:0		{same}
*LTA0:0<DTA1:0=2702		{same}
*LTA0:0=2702!DTA1:0		{same blocks, but compare only}

The handler convention is a three-leter named device followed by a 
mandatory digit 0-7 used as a unit number.  Handlers handle unit numbers 
in a device-dependent way.  (Such as complaining of illegal values or 
partially ignoring unit numbers on a bit basis.  For example, on a 
two-drive LINC-8, the high-order bits of the unit number are ignored, 
essentially meaning you merely have an "odd" and an "even" unit, simply 
expressed as 1 and 0 respectively.)

Commands with "!" as an interdevice separator mean to perform a read-only 
block-by-block compare.  Using "<" and ">" imply a read then write 
operation to perform a copy.  The direction is "pointed" to by the arrow 
key used.  Either an input or output range must be specified, or 
alternatively an explicit block count using "=".  A command line option 
exists to specify whether to verify the write with a readback-compare 
after the write, etc.

The LINC-8 version of this program can run on the 4K LINC-8.  The 
LINCtape handlers can be one page if the hardware mods are used, else are 
two pages.  The DECtape handler is 6 pages including lookup tables for 
the data conversion.  (Note: DECtape bit directions are "sideways" 
compared to LINCtape conventions!  Invariably, this means that some sort 
of lookup table is required.)  All P?S/8 non-system handlers are page and 
field relocatable, and can be up to an entire field long unlke the OS/8 
two-page max restriction, etc.  As a practical consideration, since the 
hardware mods are required for the DECtape conversion, the modified 
LINC-8 LINCtape handler appies as a likely system device to run the 
program from, etc.  (But it could also be something else such as a DF32, 
RF08, or an IPB such as on my home machine.  In that case, the "boot 
device" is actually a disk or real TC01/08 DECtape on the "other" side of 
the IPB on my -8/e, etc.  This allows both drives of the LINC-8 to be 
available to the program without changing tapes, etc.)


Cooley Labs is also responsible for CPS and CPS-4K.  These are systems 
that run on LINCtape as usually found on the LINC-8.  However, the LINC-8 
tape hardware is actually a PDP-8 peripheral!  (PROGOFOP is a trap 
simulator that helps to "fool" LINC programs into believing they are 
running on complete LINC hardware, which is actually partially simulated, 
especially the tape portion, etc.)

The actual mechanism for the tape is to appropriate the LINC CPU 
registers as tape registers during the time the LINC CPU is shut down 
(during normal PDP-8 operations, which in LINC mode are only true during 
interrupts, such as interrupts generated from trapping LINC instructions, 
etc.).  Kurt Metzger and company defined an interface for the Posibus (on 
an -8/l) that essentially is the LINC-8 register sequence for tape only.  
Thus, LINc-8 software for the PDP-8 such as the Library System, CPS 
(-4K), P?S/8 for LINC-8, OS/8 for LINC-8, etc. can run on LINCtapes on 
PDP-8's.  (Of course you cannot run systems for LINC such as LAP6, since 
these run primarily in LINC mode, although you can write file conversion 
utilities for these machines, etc.)

These "transplanted" drives were actually Computer Operations tape drives 
with a Cooley-designed interface.  Undoubtedly, this is what Jeff has 
recovered, etc.

Note to Jeff:  I have sent you e-mail months ago but you never responded 
regarding archive site "synchronization" etc.  If you are reading this, 
please e-mail me at lasner@sunsite.unc.edu etc.

Further note to Jeff:  The smoked LINC-8 in Florida: was it at the 
Miami-based Mt Sinai Medical Center?  (They also had a research division, 
but I don't remember their title, etc.)  I have the "other" machine from 
there, etc.  Please contact me about that as well, etc.

Sorry to use the a.s.p group for private correspondance, but there 
doesn't seem any other way (why?) etc.

cjl


From lasner@sunSITE.unc.edu Sat Jan 28 15:21:29 EST 1995
Article: 1166 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: DEC-Tape Cacacity?
Date: 28 Jan 1995 20:18:28 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 112
Message-ID: <3ge8qk$ob2@bigblue.oit.unc.edu>
References: <3feq34$ho8@ringer.cs.utsa.edu> <3ffgro$rhj@usenet.rpi.edu> <frank.166.2F259A3D@rover.uchicago.edu>
NNTP-Posting-Host: president.oit.unc.edu

In article <frank.166.2F259A3D@rover.uchicago.edu>,
Frank R. Borger <frank@rover.uchicago.edu> wrote:
>In article <3ffgro$rhj@usenet.rpi.edu> wilsonj@alum01.its.rpi.edu (John Wilson) writes:
>
>>... Even with stock format the tape would spin
>>off the end of the reel while formatting the end zone unless you had only
>>threaded it just enough to barely stay on the reel at the beginning.
>
>	That was a commony symptom of a mal-adjsted formatter.

Not necessarily.

>
>	The interface used an adjustable oscillator to determine how
>	OFTEN you wrote formatting data, with the tape moving at constant
>	reel speed. If the frequency of the oscillator was a little low,
>	the format marks were too far apart and you ended up running off
>	the end of the reel.

True.  But the problem is that DEC mis-specified the tape length so that 
later when 3M sold *correctly-specified* tapes, they were too short for 
the intended purpose(s) many of the time, etc.  As a bandaid, many people 
upped the density either with fingers on the hubs or by increasing the 
mark clock on the various controllers, since the clock speed was quite 
conservative.  Thus, you often could get away with a little marginal 
reliability (other than on the TD8E!) to get more density and thus fit 
what you wanted on less tape, etc.

>
>	I remember an article that actually made it into DECUScope that
>	described how one software specialist re-wrote the formatter to
>	only do 6' instead of 10' leader/trailer sections.

No, that happened earlier.  The standard PDP-8 DECtape formatter has two 
modes of operation:

1)	Anything other than MARK384 uses a stated conservative formula 
found in some early DEC manuals that will calculate out to 2702 blocks 
octal of 129 words with 10 foot leader/trailers and will completely 
succeed if the tapes really are a bit longer than the nominal 260 foot 
claimed (instead of really being about 10-15 feet longer as they usually 
were at the beginning!).  Other selected values will give corresponding 
variations that use the same amount of tape.  As the tapes started being 
made shorter (some even being *less* than thenominal 260 feet!), more and 
more tapes couldn't be formatted correctly.  Note that this effect is 
compounded by too-slow mark clock adjustments, and the tendancy of some 
ignorant lusers who erroneously assumed the program needed "help" so they 
wound the tape on some number of turns before starting the formatting 
operation (which is dead wrong - the program writes its own leader.  An 
additional variant: Lusers would cut off the leader because it was "worn 
out" or something perceived but incorrect.  The truth is that the tape 
format requires nothing of the leader other than to exist; the writing 
occurs further down the tape.  All that could happen is that a tape could 
move to the inner-most portion of the end-zone, and be turned around back 
towards the data.

During the PDP-8 formatting process, you turn on the mark clock, and do a 
first pass over the tape.  The tape could fall off, but is usually not 
fatal, although many lusers didn't realize that, etc.  You turn off the 
mark clock, remount the tape if necessary, then enter the next phase (hit 
a CR to continue).  The tape is first rewound about 20-30 feet, then 
turned around to write forward the pattern "BLOCK 2701" an indefinite 
number of times (resulting in an anomalous tape so far!) until the end 
zone is hit at its inner end.  At this point, the last-written block *IS* 
block 2701.  Previous block patterns can then be written in descending 
order from 2700 down to 0000 at which point another end zone error should 
occur at the tape beginning, hitting the inner end of the front end zone, 
etc.

Thus, as long as the tape can successfully not fall off a second time, 
the tape is valid, albeit possibly with a short inner end zone, etc.

2)	When the specific command MARK384 is given, the formula is 
bypassed and constants plugged in to create the variant PDP-10 format 
tape.  The end zones are written as 6 feet instead of 10 feet to 
accomodate getting 1102 blocks of 600 words (600=384 decimal).  Were the 
standard formula used, far less blocks would be written, etc.

Thus, from the beginning, the notion of 6 ft end zones was standard.  
Since the standard PDP-8 format (from the formula) didn't require as much 
tape, 10 ft end zones were written.

The P?S/8 version of the formatter has an option to run such that MARK129 
is the command that uses the plug-in values.  The number of blocks is 
taken from the =xxxx user-specified and the end-zone is shorteded to 6 
ft.  As a result, "extra-long" DECtapes can be created as long as the 
tapes are truly full-length, etc.  A common semi-standard was to achieve 
3300 blocks instead of 2702.

When some late-production tapes were sold that were too short, the P?S/8 
method was the only way to achieve 2702 blocks!  The MARK384 command 
invariably failed.  The tape falling off only once became the standard as 
never falling off ceased to exist, and falling off twice (and flunking 
the formatter!) become all too common :-(.

Some people then purchased tapes directly from 3M.  If they stated "DIGL 
WIND" then they are DECtapes right out of the box.  Else they are wound 
as LINCtapes and need to be reversed, etc.  Unfortunately, most of these 
tapes were accurately 260 ft long, thus guaranteeing no further too-short 
tape problems, but also preventing any more extra-long tapes either.


>
>Frank R. Borger - Physicist     ___      What's the difference between:
>Michael Reese - U of Chicago   |___      (1) having a baby and 
>Center for Radiation Therapy   | |_) _   (2) doing an RSX11M sysgen?
>net: Frank@rover.uchicago.edu    | \|_)
>ph: 312-791-8075 fa: 791-2517       |_)  Having a baby only takes 9 months!


cjl


From wilsonj@alum01.its.rpi.edu Mon Jan 30 18:00:11 EST 1995
Article: 1167 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!gatech!udel!news.mathworks.com!solaris.cc.vt.edu!swiss.ans.net!emi.com!pauling.wadsworth.org!rebecca!rpi!wilsonj
From: wilsonj@alum01.its.rpi.edu (John Wilson)
Newsgroups: comp.os.vms,alt.sys.pdp11,alt.sys.pdp8
Subject: Re: DEC part number for RL02 unit number plugs ?
Date: 28 Jan 1995 16:25:14 GMT
Organization: Rensselaer Polytechnic Institute, Troy NY
Lines: 13
Distribution: usa
Message-ID: <3gdr5b$npu@usenet.rpi.edu>
References: <3g8vjn$rbu@hustle.rahul.net> <3gbu4u$bui@nntp1.u.washington.edu>
NNTP-Posting-Host: alum01.its.rpi.edu
Xref: bigblue.oit.unc.edu comp.os.vms:85126 alt.sys.pdp8:1167

In article <3gbu4u$bui@nntp1.u.washington.edu>,
Richard Seymour <seymour@u.washington.edu> wrote:
>hmmm... i just looked it up in a 1993 catalog... the "-00" denotes
> unit zero, -01 unit one, etc. but the prices are interesting:
> zero and one are $2 each.  two and three are $4 each.  five and six are $1.

The pricing weirdness is probably due to demand or rarity or something.
Note that RL controllers support only drives 0-3, the numbers >=4 are for
RK06/RK07 drives, which use the same plugs, but are less common.

John


From m.bischoff@tu-bs.de Mon Jan 30 18:00:46 EST 1995
Article: 1168 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!agate!howland.reston.ans.net!Germany.EU.net!netmbx.de!CNB.CompuNet.DE!zrz.TU-Berlin.DE!math.fu-berlin.de!zib-berlin.de!gs.dfn.de!tubsibr!news.ibr.cs.tu-bs.de!mbi
From: mbi@mo.math.nat.tu-bs.de (Michael Bischoff)
Newsgroups: alt.sys.pdp8
Subject: page wrap for PDP-8?
Date: 25 Jan 1995 13:44:42 GMT
Organization: Institut fuer Angewandte Mathematik, TU Braunschweig
Lines: 11
Distribution: world
Message-ID: <MBI.95Jan25144442@mo.math.nat.tu-bs.de>
Reply-To: m.bischoff@tu-bs.de
NNTP-Posting-Host: mo.math.nat.tu-bs.de

Hi,
to which page does a 'TAD addr' instruction refer, if
the opcode is at memory address 128*n+127 (decimal)?

Is it the page of the instruction, or the next?

    Michael
--
Michael Bischoff, Abt. Mathematische Optimierung, Pockelsstrasse 14
TU Braunschweig, 38106 Braunschweig, Germany.
e-mail: m.bischoff@tu-bs.de  Tel: +49-531-391-7555, Fax: +49-531-391-7559


From jones@pyrite.cs.uiowa.edu Mon Jan 30 18:01:21 EST 1995
Article: 1169 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!news.mathworks.com!udel!news.sprintlink.net!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Newsgroups: alt.sys.pdp8
Subject: Re: page wrap for PDP-8?
Date: 27 Jan 1995 17:50:31 GMT
Organization: University of Iowa, Iowa City, IA, USA
Lines: 33
Distribution: world
Message-ID: <3gbbp7$b02@nexus.uiowa.edu>
References: <MBI.95Jan25144442@mo.math.nat.tu-bs.de>
NNTP-Posting-Host: pyrite.cs.uiowa.edu

>From article <MBI.95Jan25144442@mo.math.nat.tu-bs.de>,
by mbi@mo.math.nat.tu-bs.de (Michael Bischoff):

> to which page does a 'TAD addr' instruction refer, if
> the opcode is at memory address 128*n+127 (decimal)?

If you examine the flowcharts of the CPU logic for any PDP-8 model,
you'll find something like this:

    Fetch:
         CPMA = PC
         PC = PC + 1
         MB = MEMORY[CPMA]
         IR = MB<bits 0..2>
         CPMA<bits 5..11> = MB<bits 5..11>
         if MB<bit 4> = 0
           then CPMA<bits 0..5> = 0    -- page zero mode
         if MB<bit 3> = 1
           then begin
             MB = MEMORY[CPMA]
             CPMA = MB
           end

There, PC is the program counter, CPMA is the central processor memory
address register, MB is the memory buffer, and IR is the instruction
register.

As a result of the above, current page mode refers to the page from
which the instruction was fetched.

				Doug Jones
				jones@cs.uiowa.edu
             


From bqt@Krille.Update.UU.SE Mon Jan 30 18:01:37 EST 1995
Article: 1170 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!agate!howland.reston.ans.net!pipex!sunic!columba.udac.uu.se!Krille.Update.UU.SE!Krille.Update.UU.SE!not-for-mail
From: bqt@Krille.Update.UU.SE (Johnny Billquist)
Newsgroups: alt.sys.pdp8
Subject: Re: page wrap for PDP-8?
Date: 28 Jan 1995 12:16:31 +0100
Organization: Update Computer Club
Lines: 21
Message-ID: <3gd92t$qcd@Krille.Update.UU.SE>
References: <MBI.95Jan25144442@mo.math.nat.tu-bs.de>
NNTP-Posting-Host: krille.update.uu.se

In <MBI.95Jan25144442@mo.math.nat.tu-bs.de> mbi@mo.math.nat.tu-bs.de (Michael Bischoff) writes:

>Hi,
>to which page does a 'TAD addr' instruction refer, if
>the opcode is at memory address 128*n+127 (decimal)?

>Is it the page of the instruction, or the next?

It refers to an address on the same page as the instruction.

I think the PC, as all other auto-incrementing stuff is incremented
before it is used.
(Well, okay, the only other auto-incrementing stuff I can remember
off hand is the index registers.)

	Johnny
-- 
Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: bqt@minsk.docs.uu.se       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From aek@wiretap.spies.com Mon Jan 30 18:02:06 EST 1995
Article: 1171 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!godot.cc.duq.edu!hudson.lm.com!netline-fddi.jpl.nasa.gov!wiretap.spies.com!aek
From: aek@wiretap.spies.com (Al Kossow)
Subject: whereabouts of Gary Coleman
Message-ID: <D356ou.An7@wiretap.spies.com>
Organization: The Internet Wiretap
Date: Sun, 29 Jan 1995 00:58:05 GMT
Lines: 6

Has anyone heard from Gary Coleman?
I thought if there was anyone who might know if Gary Coleman of
Allen Bradley in Cleveland was, it would be here. He was a BIG
8 collector in the early 80's, had a pdp12 in his basement.


From ivie@cc.usu.edu Mon Jan 30 18:02:46 EST 1995
Article: 1172 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!news.mathworks.com!udel!news.sprintlink.net!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!ivie
From: ivie@cc.usu.edu
Newsgroups: alt.sys.pdp8
Subject: Re: page wrap for PDP-8?
Message-ID: <1995Jan28.193148.39659@cc.usu.edu>
Date: 28 Jan 95 19:31:48 MDT
References: <MBI.95Jan25144442@mo.math.nat.tu-bs.de> <3gd92t$qcd@Krille.Update.UU.SE>
Organization: Utah State University
Lines: 18

In article <3gd92t$qcd@Krille.Update.UU.SE>, bqt@Krille.Update.UU.SE (Johnny Billquist) writes:
> I think the PC, as all other auto-incrementing stuff is incremented
> before it is used.

If that were the case, you would have to enter the address of the 
instruction before the instruction you wanted to start into the switches.

I thought about that sort of thing because on a PDP-5-like processor, if
you extended the autoincrement to include Z 0, you could have immediate
constants. However, it wound up as a special case because of loading
addresses into the PC through the console.

Not that I've done more than think about my PDP-5-in-a-Xilinx mind you
(I've estimated it would take about 300 CLBs).
-- 
----------------+------------------------------------------------------
Roger Ivie      | Don't think of it as a 'new' computer, think of it as
ivie@cc.usu.edu |     'obsolete-ready'


From ard@siva.bris.ac.uk Mon Jan 30 18:03:16 EST 1995
Article: 1173 of alt.sys.pdp8
Newsgroups: comp.os.vms,alt.sys.pdp11,alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!gatech!howland.reston.ans.net!pipex!warwick!bsmail!siva.bris.ac.uk!ard
From: ard@siva.bris.ac.uk (PDP11 Hacker .....)
Subject: Re: DEC part number for RL02 unit number plugs ?
Message-ID: <30JAN199518581687@siva.bris.ac.uk>
News-Software: VAX/VMS VNEWS 1.41    
Sender: usenet@info.bris.ac.uk (Usenet news owner)
Nntp-Posting-Host: siva.bris.ac.uk
Organization: University of Bristol Physics Department
References: <3g8vjn$rbu@hustle.rahul.net> <3gbu4u$bui@nntp1.u.washington.edu>
Distribution: usa
Date: Mon, 30 Jan 1995 17:58:00 GMT
Lines: 25
Xref: bigblue.oit.unc.edu comp.os.vms:85254 alt.sys.pdp8:1173

In article <3gbu4u$bui@nntp1.u.washington.edu>, seymour@u.washington.edu (Richard Seymour) writes...
> it's 12-12691-00   (for unit zero... break pins for other numbers)

Not on an RL-drive. There are 2 pins that encode what number it is, and the
shape of the top and bottom edges of these pins is what matters. There is no
easy way of converting one plug into another.

Mind you, it's possible to cut/jumper the switch board in the RL-drive in an
emergency

>hmmm... i just looked it up in a 1993 catalog... the "-00" denotes
> unit zero, -01 unit one, etc. but the prices are interesting:
> zero and one are $2 each.  two and three are $4 each.  five and six are $1.

RL's are only 0-3 - there are only 2 drive select lines in the hardware. The
same plugs fit RK06's/07's, and also some CDC drives, like the 9448

RK06's/7's have numbers 0-7

> 
-tony

Bristol University takes no responsibility for the views expressed in this
posting. They are the personal views of the user concerned.


From lasner@sunSITE.unc.edu Mon Jan 30 18:10:12 EST 1995
Article: 1174 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: whereabouts of Gary Coleman
Date: 30 Jan 1995 23:10:54 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 19
Message-ID: <3gjrlu$19fj@bigblue.oit.unc.edu>
References: <D356ou.An7@wiretap.spies.com>
NNTP-Posting-Host: president.oit.unc.edu

In article <D356ou.An7@wiretap.spies.com>,
Al Kossow <aek@wiretap.spies.com> wrote:
>Has anyone heard from Gary Coleman?
>I thought if there was anyone who might know if Gary Coleman of
>Allen Bradley in Cleveland was, it would be here. He was a BIG
>8 collector in the early 80's, had a pdp12 in his basement.
>

I haven't heard of Gary Coleman in years.

However, I and several people I know have far larger collections.

cj "What, you only have *one* PDP-12 in your basement?" l

ps: Jeff Russ, who still hasn't contacted me, might know his 
whereabouts.  If someone can get Jeff to contact me, it would be 
appreciated. (Gary too :-).)


From ivie@cc.usu.edu Tue Jan 31 08:01:41 EST 1995
Article: 1175 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-server.ncren.net!news.duke.edu!agate!dog.ee.lbl.gov!news.cs.utah.edu!cc.usu.edu!ivie
From: ivie@cc.usu.edu (Roger Ivie)
Newsgroups: alt.sys.pdp8
Subject: DM2 formatter for RD53?
Message-ID: <1995Jan29.211618.39752@cc.usu.edu>
Date: 29 Jan 95 21:16:18 MDT
Organization: Utah State University
Lines: 15

Greetings!

I suddenly and unexpectedly find myself with a surplus of large MFM hard disks,
including a couple of RD53 70 MB drives. This, of course, has me dreaming of
stashing them in my DECmate IIs. Does anyone have a formatter for the DM2
capable of doing RD53s that they are willing to send my way, or do I have to
write one?

Also, once I have them formatted, what do I do with all the space? I know I
can suck up 32MB for CP/M (four 8MB partitions). Can OS/278 handle more than
two partitions connected at once?
-- 
----------------+------------------------------------------------------
Roger Ivie      | Don't think of it as a 'new' computer, think of it as
ivie@cc.usu.edu |     'obsolete-ready'


From lasner@sunSITE.unc.edu Tue Jan 31 09:15:56 EST 1995
Article: 1176 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: DM2 formatter for RD53?
Date: 31 Jan 1995 14:16:22 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 168
Message-ID: <3glgnm$17rr@bigblue.oit.unc.edu>
References: <1995Jan29.211618.39752@cc.usu.edu>
NNTP-Posting-Host: president.oit.unc.edu

In article <1995Jan29.211618.39752@cc.usu.edu>,
Roger Ivie <ivie@cc.usu.edu> wrote:
>Greetings!
>
>I suddenly and unexpectedly find myself with a surplus of large MFM hard disks,
>including a couple of RD53 70 MB drives. This, of course, has me dreaming of
>stashing them in my DECmate IIs. Does anyone have a formatter for the DM2
>capable of doing RD53s that they are willing to send my way, or do I have to
>write one?

I have the so-called "clandestine" formatter in binary executable form. 
It's apparently standalone, thus can be wrapped around any form of
OS/(27)8 system or could even be transferred to COS or P?S/8 accordingly,
etc.  It's "distributed" on an OS/278 RX50 without documentation, but all
you need to give it (manually on the keyboard) are the # of cylinders and
heads.  It does (most of) the rest. 

There are several problems:

1)	It doesn't apply the slushware, but that's easily done from the 
System Test Diskette.  (Note: the STD has two functions: one formats the 
disk and applies slushware automatically, the other *just* applies the 
slushware.  The catch with the STD is that it will *ONLY* format 5,10,20 
MB disks to one head shy of their respective sizes, and will do no other 
sizes at all.  These sizes are in turn "sacred" (see below).)

2)	It cannot make any "sacred" disk sizes which leads to a problem 
with Master Menu.  Master Menu pragmatically checks for the three sacred 
sizes of one head shy of 5 or 10 or 20 MB, the three normally used disk 
sizes on DM II/III+.  Anything else is claimed to be "corrupted" when you 
attempt to use the "X" option to compress the disk.  Thus, the use of 
these disks demands manual volume placement, which means a whole lot of 
backup/restore, etc. :-(.  (My present situation: I use an ST-4096 
wasting a head to get exactly 64 MB of formatted space.  And a whole lot 
of RX50's of volume backups, although backing up per se isn't that bad an 
idea :-).)  (Note: obtaining the sources to Master Menu will likely allow 
fixing this.  Older prerelease versions of MM actually didn't mind 
alternate sizes, but cannot be used due to other internal problems.  All 
are warned not to attempt to use old MM copies to get around this - it 
will permanently corrupt your entire disk!!!)

Other than that, arbitrary disk sizes can be used.  The maximum number of 
heads is 8, even though newer disks allow up to 16.  It is rumored that 
the controller can handle more than the Rainbow limit of 1024 cylinders; 
it would be nice if an RD54 was attempted to see if you can get to 1224 
cylinders (even if wasting all of those other heads!).  If that's true, 
anyone have any leads where to find larger disks by cylinders, but with 
less heads (Microscience?).

3)	There is no facility to lockout bad blocks.  Even Master Menu's 
facility is a non-workable kludge.  What's needed is a routine to read 
test the disk and find and mark bad blocks/replacements.  (Better yet, a 
read/write test used just after the clandestine formatter even before 
systems are applied, but after the slushware is in place so there even is 
a bad block table to mark!)

I so far have been lucky in that I've found disks with no apparent 
problems.  Perhaps it's because DEC writes lower-density disks than the 
rest of the industry?  (Remember, DEC formats for 16 512 byte 
sectors/track, not 17 as in PC's, etc.)

>
>Also, once I have them formatted, what do I do with all the space? I know I
>can suck up 32MB for CP/M (four 8MB partitions). Can OS/278 handle more than
>two partitions connected at once?

There are several problems for each system:

1)	MS-DOS for some reason cannot boot a volume larger than about 10.5 MB. 
However, non-system volumes of up to 32 MB each work fine for drive F:,
G:, H:.

2)	I cannot confirm how large CP/M-80 volumes can be, but again I 
would check if the non-system size is different max than the bootable 
system size, or if there's a problem referencing different sizes from a 
bootable floppy system.

However, there is a specific problem with CP/M-80: You cannot directly
create a volume that starts past the first 10-20 MB of disk address.  The
install diskette gets confused by the extra set high-order bits.  Thus,
the workaround is to place a CP/M-80 system on a near-empty disk or
smaller hard disk system and then use backup/restore to place the
now-existent system where you want it.  (Note: see how this couples well
with the MM limitations :-( :-).)

While both CP/M-80 and MS-DOS allow the same configuration of A:, B: RX50 
and E:,F:,G:,H: hard disk volumes (booted to E: on the hard disk 
version), a bug in the CP/M configuration prevents C: and D: from being 
accessed even if you have the second RX50.  (MS-DOS does it correctly.)  
Only up-to-8 all-floppy CP/M systems can access the second drive pair.

A side note for CP/M-80 users:  The install diskette is for any APU or 
XPU configuration, yet the systems it creates are for APU or XPU only, 
and can never be "crossed".  This even applies to bootable volumes!  
Additionally, the installation of DM II-oriented CP/M-80 must be 
performed on the DM III+ by first modifying the machine to have two 
diskette drives.  Afterwards, all will work except the HD utility's 
backup/restore feature since that only addresses the B: drive.  (Unless 
you make the second drive permanent!)

3)	COS volumes can be created by Master Menu, but are created 
corrupted.  Apparently there are COS commands to correct this after the 
fact.  However, COS is distributed with a second diskette that contains a 
"stub" version of Master Menu that redundantly includes a facility to 
delete and add volumes in COS format.  Volumes created this way are 
acceptable to COS directly.  I haven't tried any of this on a 
non-standard disk size though (used a 10 MB machine standardly formatted 
at the time).  The diskette itself is actually a bootable pre-release 
OS/278 diskette that auto-executes the COS-oriented stub derivative from 
MM.  I would not trust either the overall worthiness of the underlying 
OS/278 system compared to the released system, nor would I attempt to 
move the executable to OS/278 V2.  (This inadvertant "lock-in" is 
characteristic of a lot of early install software; apparently these 
programs were written for the "OS/278 system of the week" back then, 
etc.  Once OS/278 stabilized as more like OS/8 (as it should be!) these 
programs with their dependent kludges became as orphaned as the systems 
they were released with, etc.)

4)	OS/278 as distributed only specifically addresses RD50: and 
RD51:.  While CP/M and MS-DOS are limited to 4 logical volumes, WPS and 
OS/278 are able to access all 8 logical volumes, at least in theory.  
OS/278 needs to be reconfigured with more handlers using the SET HANDLER 
utility.  (Note: BUILD is not compatible with OS/278 specifically, but 
this can eventually be overcome!)

Distributed with OS/278 is the handler for RD52: and RD53:.  This can be 
applied directly as a replacement for the RX02 handlers (RX20: and RX21: 
for example, since hard disks and RX01/02 never meet :-).)

The designated way to create additional OS/278 volumes is through Master 
Menu directly.  The "A" command will allocate any of the other systems as 
advertised on the screen.  However, you can also indicate "OS278" as an 
undocumented choice!

There are a few problems acquiring access to the other four volumes: The 
OS/278 MOUNT program as distributed is limited to accessing logical 
drives 1-3 only (0-3 from diskette-based systems; the improvement makes 
sense; you don't want to dismount the system boot drive from a hard disk 
system!).  However, Master Menu allows you to pre-mount all 8 volumes 
(btw, this is required for WPS normally), thus this would at least allow a 
half-fixed and half remountable system, etc.

However, as distributed, there are no handlers for RD54: through RD57:.  
>From the sources, it should be fairly easy to modify for the extended 
logical volumes.

I haven't ever bothered merely because I just use a lot of MOUNT commands 
on the four available logical volumes.  This allows me to designate RD53: 
as the WPSVOL1 normally associated with WPS documents, and still have a 
system volume and two additional data volumes.  WPFLOP can convert 
document files in either direction to/from OS/278, thus allowing text 
files to go between OS/278 and WPS format.  Since both CP/M-80 and MS-DOS 
allow local conversions to/from those systems and WPS, this allows WPS 
format used as an intermediary to be the means of file conversion between 
all of these systems, etc. without resorting to floppies.

There are higher priority issues to be dealt with in improving OS/278, so 
we'll all have to "suffer along" with "only" four volumes for now :-).


>-- 
>----------------+------------------------------------------------------
>Roger Ivie      | Don't think of it as a 'new' computer, think of it as
>ivie@cc.usu.edu |     'obsolete-ready'


cjl


From jlothian@castle.ed.ac.uk Tue Jan 31 23:11:17 EST 1995
Article: 1177 of alt.sys.pdp8
Newsgroups: comp.os.vms,alt.sys.pdp11,alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!gatech!swrinde!howland.reston.ans.net!pipex!exnet2!exnet!dcs.ed.ac.uk!festival!jlothian
From: jlothian@castle.ed.ac.uk (J Lothian)
Subject: Re: DEC part number for RL02 unit number plugs ?
X-Newsreader: TIN [version 1.1 PL8]
References: <30JAN199518581687@siva.bris.ac.uk>
Message-ID: <D3A3t3.AE6@festival.ed.ac.uk>
Sender: news@festival.ed.ac.uk (remote news read deamon)
Followup-To: comp.os.vms,alt.sys.pdp11,alt.sys.pdp8
Organization: Edinburgh University
Date: Tue, 31 Jan 1995 16:43:47 GMT
Lines: 20
Xref: bigblue.oit.unc.edu comp.os.vms:85288 alt.sys.pdp8:1177

PDP11 Hacker ..... (ard@siva.bris.ac.uk) wrote:
: In article <3gbu4u$bui@nntp1.u.washington.edu>, seymour@u.washington.edu (Richard Seymour) writes...
: > it's 12-12691-00   (for unit zero... break pins for other numbers)

: Not on an RL-drive. There are 2 pins that encode what number it is, and the
: shape of the top and bottom edges of these pins is what matters. There is no
: easy way of converting one plug into another.

A nail-file, he said darkly, works wonders...

James

--

-------------------------------------------------------
James Lothian        |      "It's life, Jim, 
james@uk.ac.ed.caad  |   but not as we know it"
-------------------------------------------------------
          These opinions have nothing to do 
             with Edinburgh University.


