getting source files to an environment to compile / execute

[Peter Peterson]

Hi all,

A quick introduction to my student Chandler Swift, who has taken on the task of making controllers for the PDP-12 for Spacewar! Our goal is to use the 8 analog inputs on the PDP-12 and the sampling instructions to control the ships in the game. 

He's made a prototype controller: https://twitter.com/tastytronic/status/903341436376162305

... we may eventually use joysticks.

Anyway, we are hoping to modify the assembly source to use the sampling instructions. This should also serve as a good test case for our analog samplers. However, we've realized that we don't know how to get a text file of assembly over to a disk image (or really to load it in any other way). 

What is the best way to take a text file of assembly from a modern machine and execute it on a PDP? 

Relatedly, any tips about using the analog inputs?

Thanks very much, and welcome to Chandler!

Peter

--

Peter A. H. Peterson, Ph.D.

Assistant Professor
Department of Computer Science

University of Minnesota Duluth

[Michael Thompson]

I believe that the original controllers design just used switches and uses the sense instruction to read the switch state. There is a backplane connector that is wired in parallel with the sense switches on the console. Just plug a ribbon cable flip-chip into the slot and wire it to the switches.

I use a program named putr to move files to and from RK05 disk image. Then you can boot OS/8 from SIMH or the PDP-12 to compile the program.

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "PDP-12 Restoration Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pdp+uns...@d.umn.edu.

[Maury Pepper]

A simple way to test an analog channel (includes the knobs) is a three instruction loop which you can easily toggle into memory from the console switches (in LINC mode). This will display a horizontal line on the screen and the vertical position is determined by the analog input.

LOC    INSTR
0020    SAM n    ; n is any one of the analog channels
0021    DIS i 1   ;  Register 1 is arbitrary -- any index register will work.
0022    JMP 20  ;

Can't help with the source file transfer, but I'm sure others can and will.
------
Maury Pepper

[CLASystems]

As more of you get to know me [from either reputation or interaction], the better you will understand to ask me about how to do these things BEFORE you embark on any such project for my input.  That said, I can help you in all your endeavors, but you will find that what I will say will largely challenge some of your notions.  When you don't know much, seek out expert advise.  Specifics below.  And I am always available for any reasonable questions, etc.  [At least on this one, not too much commitment has been made before seeking my input.

On Fri, Sep 1, 2017 at 5:48 PM, Peter Peterson <pa...@d.umn.edu> wrote:

Hi all,

A quick introduction to my student Chandler Swift, who has taken on the task of making controllers for the PDP-12 for Spacewar! Our goal is to use the 8 analog inputs on the PDP-12 and the sampling instructions to control the ships in the game. 

​This is not necessarily the best way to even approach this.  However, this problem has been worked over completely well over 40 years ago.​

First of all, I haven't seen this attempt at a program with the generic name "spacewar"; back in the day, we laughed at this baby program that was pretty pathetic, but it was included in one of the DIAL-based demo-12 tapes.  I think the binary only.  In any case, when you are from Brooklyn Poly, you already have an advantage.  We created POLY SPACEWAR which was very well-known back in the day; it created a problem for us as so many came to play the game that we coudn't get anything done!

The shortest version.  this one is [at the time, perhaps now not accurate on some basis] the original PDP-8 version that ran on a 4K "straight" PDP-8 with EAE.  A few dissective details will be helpful:

1) PDP-8 EAE lacks an important instruction SWP to interchange the AC and the MQ register contents.  The code can here and there be optimized if you can take advantage of that. But this is only available on the PDP-8/I and the PDP-12 [which is based on the PDP-8/I].  [Note:  This also applies to the PDP-8/E family; there is also MODE B which adds a lot of nice double-precision instructions that are very useful, but this would be a major rewrite of the code that works in the "rock-bottom" world of EAE of the "straight-8".

2) As in the PDP-1 very famous SPACEWAR, the opponents have 4-button boxes.  There is no analog aspect to the controllers; at most values such as acceleration are increased by holding down the button.  As each cycle of input scan shows the button is still down, it causes another small increment in the parameter; values tend to decay just be no further input.  This is exactly what the PDP-1 version did and it is quite effective.

3) The very first "controller" was two people facing each other, one "owning" the high-order 4 bits of the front panel switches and the other the low-order four, etc.  The good thing about this is the scan for input is just one instruction and then check each bit out accordingly, etc.  Of course, the playeres would always get in each other's way, especially if both were right-handed!  [This lead to "external cheating" by inflicting small amounts of bodily harm.]

4) Eventually, I had to explain to them that you can use external boxes with a battery in each.  The machine also had an AF01A 8-channel A-D convertor.  And it could be set on the front panel as to how imprecise a conversion you could get to speed it up.  12-iot conversions take too long, so we set it to the minimum six-bits.

Now the scan was a series of 8 A-D instruction sequences, takes longer, but it was tolerable.  That way, the players could be on long cables and away from each other, etc.  Also, we sometimes hooked up two scopes so they could even be in quite different "stations" to avoid conflict, etc.

Of course, the scan was just the sign-bit of the conversions.  No press and the value was very close to 0V, the highest possible; through the  battery and resistors and isolation diodes, it would go to a nice negative number [The AA01A without preamps takes values in the range -5V plus/minus 5V/]

Not the fastest way to go, but the "safest".

5) This machine also had the POLY MUSIC REGISTER which I have the software documentation for.  In essence, it outputs a specific frequency for an adjustable amount of time.  Stan Rabinowitz [who among other things was the final maintainer of OS/8 before he quit and the "young turks" came along and ruined it; see OS/78 V4 and worse OS/278 V2] wrote a somewhat famous checker game for this same machine.  It displays on the same output, which in this case is the three-channel AA01A D-A convertor, with one channel used as a poor-man's intensity circuit  When it is waiting for its opponents, it plays the song Love is Blue on the music register.  The SPACEWAR collision blowup routine has some great sound effects!]  I never had an opportunity to modify the code for the PDP-12 where the AC[0] is on the speaker to try to work something equivalent out, etc.

6) On the PDP-12, you can do a whole lot better by using several methods available only there:

a) You have two sets of switch registers.  Now the opponents can be a lot further apart.  LSW high-order 4 for one, and RSW low-order 4 for the other one.

b) You can use the SAM instructions and do more or less what we did, but these are much slower instructions and not adjustable.

c) This is clearly the way to go:  There are designated inputs on the backplane for the so-called external levels.,  In essence, they are floating open pulled up TTL signals that if grounded or not forms the basis for the bit.  The SXL or SXL I instructions are truly elegant for this purpose [since you can even reverse the logic in the instruction to make it the lowest overhead of all.]  [Note:  DO NOT confuse this with the sense switches on the front panel.]

Since various programs might want more or less input, construct an appropriate cable that allows two control boxes to have 1/2 of the available SXL lines as possible.  [Note:  On the LAB-8/E, the DR8E has 12 inputs on one connector.]

I don't know where to "rate" the program you are familiar with on the scale of program capability for all things named SPACEWAR, but I would bet it's at best in the lower 1/3 of what exists.  Best to be familiar with the entire gamut of what makes sense for the purpose of designing a controller.

He's made a prototype controller: https://twitter.com/tastytronic/status/903341436376162305

​Shows that he is up to making nice prototypes.  But prototypes by nature never become production models.​

 

... we may eventually use joysticks.

​I would strongly advise against that given we are speaking about existent programs for 12-bit machines.

 

​

Anyway, we are hoping to modify the assembly source to use the sampling instructions. This should also serve as a good test case for our analog samplers. However, we've realized that we don't know how to get a text file of assembly over to a disk image (or really to load it in any other way). 

What is the best way to take a text file of assembly from a modern machine and execute it on a PDP? 

​I am the one-stop shopping for all of your needs.  Since I am in the death throes of finishing the manual [and you can always ask ME questions!] you need to be running my P?S Extended PDP-8 Simulator [PEPS] for Windows on an available machine running Windows XP through Windows 10.  As long as you promise not to distribute it to others [as it is not quite done, consider yourself "beta" testers] I can send you a copy.

The overall method is to start with OS/8 on the PDP-12 with the ersatz SerialDisk "handler" that I wrote from the earlier ones that didnt' work on the PDP-12 among other systems.  [Kyle Owen's version was only for the 8/E, some others changed it, but were not up on what to do for an earlier machine as they THOUGHT they did.  As such, you should be running my version using the Adamson version of the server that supports 4 drives].  Note: I will eventually be releasing new handlers when I get a chance to talk to Kyle about changes​  [He is scheduled to come here, but no specifics yet.]  Also, Kyle's version of SPACEWAR is pretty good as well.  However, it is HEAVILY dependent on things we never had:  a) needs 8K, b) uses the PDP-8/E EAE to great advantage.  No way to get it to be useful on a PDP-12, etc.  POLY SPACEWAR has already been run on the PDP-12 using the LSW/RSW method and no support for the sound.  This was accomplished in an unexpected real-time event of converting the source from R-L Monitor DECtapes to OS/8 on the PDP-12 in about 3 hours accomplished by me and Richard Lary at a DECUS symposium, etc.  It as usual, drew a crowd.  Note:  DEC never told any of us what would be at these shows.  The only reason it even was a PDP-12 is this was the first showing of the only PDP-12 every built into three low PDP-8/I-type cabinets instead of the extra-wide usual one.  It is truly unique and as I understand it, they never put another one of them together again that way, so it was DEC CSS doings that even made the decision as to what to bring there.  We all were expecting a PDP-8/E with DECtapes, etc.  But we did get it converted getting beyond latyers of obstacles, etc.

The basic "path" for any software work is what I do daily.  In your case, you start by placing any files you have on an OS/8 device and it should be put on a NON-SYSTEM device that is handled by the SerialDisk handler.  From there, it can be introduced as one of the 4 RK05 images on SIMH and specifically PEPS for Windows.  this will give you an impressive set of ways to go with regard to development and processing of the program.  And of course you have to get it back as binary to OS/8 to execute it, as for the moment that is the only choice you have on the PDP-12 that makes sense.

While I have released P?S/8 for the TC01/TC08 DECtape already to Michael Thompson and it is also available in the PEPS package and it co-exists with OS/8 there, I cannot get the PDP-12 LINCtape version of P/S/8 up until Michael can get his PDP-12 to read LINCtapes.  I can create a copy of the software and write it out on images of DECtapes, but at some point in the process, it also has to go through the PRTC12F program to be block-for-block copied from DECtape to LINCtape.  Maybe your machine actually works in that regard, which will help.

However, part of the P?S/8 for PDP-12 LINCtape system involved more suitable versions of the MARK12 and TC12F programs that were derived from DIAL-MS.  It is a bit "messy" to make them function outside of the DIAL environment which has conventions dramatically different from P?S/8 and OS/8 which are far more inter-operable.

Also, you have to solve a different problem I suspect.  This program is on a DIAL LINCtape, correct?  P?S/8 on LINCtape supports the L6DCON program that bi-directionally transfers P?S/8 programs to/from DIAL tapes.  It can only run on the LINC-8 and PDP-12 because it has to have internal dedicated tape handlers, etc. due to the incompatible 256-word format, etc.  [Note:  OS/8 will confuse anyone on this point about logical record size.  Despite what you may have heard, OS/8 DOES NOT RUN ON 256-word record devices.  It requires a KLUDGE so that you can read only the first-half of a record.  Thus, the 256 word format used  by DIAL, etc. is NOT SUPPORTABLE for OS/8.  Thus, P?S/8 and OS/8 use 128 words/block LINCtapes universally and special-purpose conversion programs are needed such as L6DCON to access the DIAL files, etc.  With regard to OS/8 and P/S/8, the P/S/8 OS8CON program bi-directionally converts text files to/from either system, etc.  But there is no equivalent to this for OS/8 itself.  [I am accustomed to having both systems on the same hardware.  That way I can choose what is best for any task.  As P?S/8 gets more developed, I find myself less dependent on OS/8, etc.]

Thus, in theory, with some effort, I can cobble together P?S/8 for PDP-12 LINCtape but have to leave out the two vital programs.  You will have to do all of the following at least temporarily.

a) You have to get the PRTC12F program to work from DIAL.  It unfortunately wants 129 words/block LINCtapes, not 128 words/block.  The custom versions of these programs was in part designed to overcome this.  It was only due to miscommunications that at the time that they who wrote the code assumed the 129th DECtape word needed to be preserved.  This is a fallacy:  the ONLY PDP-8 software that uses this aspect of DECtape is the Disk Monitor on DECtape. Not only is this system quite inferior, it only runs on the DF32, the RF08 and the TC01/TC08 DECtape and NOT on the PDP-12 [unless it coincidentally has a DF32 or an RF08!].  Thus, this was at least pointless, but it also degrades LINCtape performance for both OS/8 and P?S/8.  Both systems TOLERATE and ACCOMMODATE 129 word format, but prefer 128 word format.  But until I can get to you the binaries on the tape[s] in question, this aspect of P?S/8 remains unavailable.  [The short story:  Warren Stearnes took this tape from RICM but never had a chance to try to develop anything that did anything about it.  At the moment, we are awaiting the return of the tape to RICM from Warren's friend Doug Ingraham, who is also a straight PDP-8 owner, etc.]  Michael Thompson will update all of us when the tape arrives, etc.]

Thus, you have to use DIAL to do all of the tape formatting at 129 words/block.  OK for the meantime, but I can give all of the details why this is wrong at another time, etc.

From that program, you can copy the DECtape to LINCtape, etc.

Michael Thompson can turn my DECtape image of any tape I send him into an actual DECtape and then send that DECtape to you.  He has a machine with RK05 and TD8E DECtape on it we have been using to recover some of my DECtapes, including apparently the SOURCE CODE of POLY SPACEWAR recently.  I am a little backed up at the moment [too many balls in the air, but soon] so that shouldn't be too much of a problem.  [More specifics when I get to that, etc.].

We have programs to convert .TU56 files from SIMH to actual DECtape snd vice-versa.

But if I can get to you some of the Kermit-12 utilities I wrote, I think we can do this from e-mail and end-run most of the process!

Have you determined if your system works on at least one of the LINCtapes completely.  From what I heard there is a problem on at least one drive, but you do have to be able to format; pretty much a prerequisite for the PRTC12F program, etc. [necessary, but not sufficient].

Now back to your immediate problem.  I assume this source file is on a DIAL tape.  Possibly, it was imaged by Dave Gesswein who can provide the file to me in a format I can work with on the PEPS package.

If this is so, I can get you a full listing of the source file, etc.  Note: Depending on the complexity, it may be true the only way to work on it is in P?S/8 because it has the best bar none dual mode assembler that is a large super-set of both PAL8 and the DIAL-MS assembler.  There is an inferior version of a dual-assembler for OS/8, but the only recovered version of this may not even be the best available [Very long story, and it will involve my going to RICM once there is a ghost of a chance the PDP-12 there can read LINCtapes!].

Regardless, this is not really a good assembler, and I have numerous examples of programs the available variant CANNOT ASSEMBLE PROPERLY [including the two relevant sources of the variant MARK12 and variant PRTC12F programs modified to work with either OS/8 or P?S/8]'.  It would be best that I get ahole of the source code first and get you a proper listing of it to ensure you won't be walking into a nest of vipers so to speak, etc.

Fortunately, the ability to run the L6DCON program does not depend on programs I cannot provide [at this time] proper source code for. [I can build nearly every P?S/8 program now except for some stragglers we are working on.  Michael has been very instrumental in helping me with the logistics so I can recover ALL of P?S/8 at the source code.  It's down to a manageable level and I posted the current status on the P?S/8 Google Group which you are all welcome to join, etc.

There are all sorts of tricks to get the BINARY of a program from P?S/8 to OS/8.  I am about six levels of priority removed from writing a program [but I did already write a tentative spec document!] that will forever bury this problem entirely, and also solve a whole bunch of other problems that interfere with my ability to develop more of P?S/8.  [Not a problem at the moment, but I want to change the way the system is created from the binaries, and that way, it is easier for me to distribute the system as well, etc.  More people will be able to create it or variants than at present, a way even difficult for me to use!  But that work will "float all boats" with regard to a bunch of things.  But I do have immediate tricks to easily get binaries from one system to another, and some are a consequence of the way that PEPS works, while others are more direct, meaning can be done on the real hardware as well.  Use whichever is more convenient, since we all now have this complex of methods to chose from, etc.  But the short version is that if I can get a proper source file for you, the binary can be gotten to OS/8 using some easily accomplished tricks, etc.

 

Relatedly, any tips about using the analog inputs?

​No, it will slow down the result, but if you want to just play with something, go for it, THEN come back when you are ready to do it properly.​

Thanks very much, and welcome to Chandler!

​I hope he knows what he is in for!

cjl [I know, a lot of things to consider!]​

 

Peter

​cjl​

--

Peter A. H. Peterson, Ph.D.

Assistant Professor
Department of Computer Science

University of Minnesota Duluth

--

You received this message because you are subscribed to the Google Groups "PDP-12 Restoration Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pdp+uns...@d.umn.edu.

--

"In the future, OS/2 will be on everyone's desktop"

Bill Gates, 1992

[CLASystems]

On Fri, Sep 1, 2017 at 6:09 PM, Michael Thompson <michael.9...@gmail.com> wrote:

I believe that the original controllers design just used switches and uses the sense instruction to read the switch state. There is a backplane connector that is wired in parallel with the sense switches on the console. Just plug a ribbon cable flip-chip into the slot and wire it to the switches.

​The external levels are not the same as the sense switches.
​

 

I use a program named putr to move files to and from RK05 disk image. Then you can boot OS/8 from SIMH or the PDP-12 to compile the program.

​From my vantage point, that is more work than using what I wrote.  But please document what you are using from John's program for this.  Unfortunately, John wrote the​

 

​code so long ago, he doesn't remember much of what he did!  Maybe you can get me some info I seek:  The program also supports various RT-11 format stuff; I want to know the sector interleave/stagger arrangement of how RT-11 uses RX01 and also RX02 diskettes; that is two questions as they are different.  John sells hardware to hookup 8" diskette drives to PCs, etc.  In theory, it's somewhere in the PUTR source code, but I don't know enough myself to find it, etc.  [He has no intention of working on it ever again, etc.]

cjl

​

Sent from my iPhone

On Sep 1, 2017, at 5:48 PM, Peter Peterson <pa...@d.umn.edu> wrote:

Hi all,

A quick introduction to my student Chandler Swift, who has taken on the task of making controllers for the PDP-12 for Spacewar! Our goal is to use the 8 analog inputs on the PDP-12 and the sampling instructions to control the ships in the game. 

He's made a prototype controller: https://twitter.com/tastytronic/status/903341436376162305

... we may eventually use joysticks.

Anyway, we are hoping to modify the assembly source to use the sampling instructions. This should also serve as a good test case for our analog samplers. However, we've realized that we don't know how to get a text file of assembly over to a disk image (or really to load it in any other way). 

What is the best way to take a text file of assembly from a modern machine and execute it on a PDP? 

Relatedly, any tips about using the analog inputs?

Thanks very much, and welcome to Chandler!

Peter

--

Peter A. H. Peterson, Ph.D.

Assistant Professor
Department of Computer Science

University of Minnesota Duluth

--
You received this message because you are subscribed to the Google Groups "PDP-12 Restoration Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pdp+uns...@d.umn.edu.

--
You received this message because you are subscribed to the Google Groups "PDP-12 Restoration Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pdp+uns...@d.umn.edu.

[Michael Thompson]

Here are two files that might be of interest for people that are new to the PDP-8/PDP-12.

--

Michael Thompson

[Michael Thompson]

I found the original DECUS 8-213 ALGOL paper tapes and will make binary images of them. They have the decus labels on them so we will have a better idea of what they are then the ones that are circulating now.

--

Michael Thompson

[Michael Thompson]

An easy way to get source code files to the PDP-12, is to edit the source code file and do a save-as and specify both CR and LF in the resulting file, then boot SIMH from an RK05 image, attach the PDP-12 RK05 image as SD1, attach the source code file to PTR:, and then:

R PIP<CR>

*RKA1:SOURCE.PA<PTR:<CR>

^<CR>

*<CTRL-C>

.

Now you can kill SIMH, start serialdisk server on the PDP-12 RK05 image, and boot the PDP-12 from serialdisk.

--

Michael Thompson

[CLASystems]

On Sat, Sep 2, 2017 at 10:23 AM, Michael Thompson <michael.9...@gmail.com> wrote:

An easy way to get source code files to the PDP-12, is to edit the source code file and do a save-as and specify both CR and LF in the resulting file, then boot SIMH from an RK05 image, attach the PDP-12 RK05 image as SD1, attach the source code file to PTR:, and then:

R PIP<CR>

*RKA1:SOURCE.PA<PTR:<CR>

^<CR>

*<CTRL-C>

.

Now you can kill SIMH, start serialdisk server on the PDP-12 RK05 image, and boot the PDP-12 from serialdisk.

​I thought that we had established that already.  And no need to point out the CR/LF issue.  It is just the standard.  What was being done to make this NOT happen?  I assume by not doing this totally straight-forward procedure which is just garden-variety usage of OS/8, etc.​

 

​As long as you leave out outlier systems such as unix, it does just work that way.  The underlying reason is that wisely MS-DOS conventions are identical to the DEC standard.  And that includes the notion of horizontal tabs always imply multiples of 8 spaces.  And at the time, virtually every terminal was DEC compatible, so that was a consideration at the time.  There was also the optional ANSI.SYS that went further so that the major ESC sequences of the VT-100 were also available, etc.

As such, programs like Windows Notepad are fully compatible, etc. and why I use it heavily in the PEPS version of SIMH; it just flows naturally, etc.  In fact, I have had to reject certain 3rd party text editors for Windows because they are either NOT really totally compatble in some way OR they involve some leap into personal preference that can have negative consequences, such as tabbing which sounds find, that is until you start using it.  Many situations really want several separate open windows, etc.  In any case, PEPS can be modified on a case by case basis to work with such as EditPad7 Lite, a freeware version​ that is a good example of a tabbed editor, useful in some circumstances, not so useful in others.  There are many "moving parts" in this package, and some should be left as they are, but you are always welcome to try any variation.

About the only downside to Notepad I have found is that Windows XP Notepad uses a generic small box on the screen to display any and all variations of control characters it does not support, thus no easy way to tell from that vantage point.  However, inevitably you get some listing file and all such characters not only look the same, but you can trust they ACTUALLY are <FF> so you can copy one from a listing file and insert it into a source file all you want.  The assemblers in both P?S/8 and OS/8 do not output anything but <FF between pages [well, after they are cleaned up with STRIP.TEC, easily applied as part of another section of the package].That cleans up all the junk that happens in bizarre ways [and not just because of the PTP: handler, which is bizarre in and of itself.

In Vista and up, it displays a funny "upside down Nabisco" symbol same as SIMH does if you enable upper/lower case in SIMH.  Many use the model 33 mode in OS/8 in SIMH to cover up a multitude of sens in OS/8's junk-laden output.  Most thus, don't see what I do.  But if you do enable full ASCII, P?S/8 works fine, and in OS/8 it sometimes dumps funny characters just because.  [Very sloppy.  For example, every DIR command outputs at the end a <FF> as a kludge because in DEC at the time, their PDP-12, the most used for obvious reasons, best debugging model ever, etc. happened to have a model 35 teletype for the console.  Thus, they could be lazy about tearing off paper, etc.  It has no business being there, you cannot disable it and it is not documented as far as I know, but the code survived.  Anyone using a full character set terminal will see this; but the default in SIMH is set to upper-case terminals only, and this is then ignored.  Also, OS/8 cannot take lower-case input the way P?S/8 always has. Ironically that was on the short list of fixes in OS/278 that actually were productive! [the other is making the date permanent the way P?S/8 does; prevents a lot of consequencial anomaly in OS/8, etc.]

So, if you use a newer Windows, no flaws whatsoever in Notepad.  You may not be happy with the provided features [I also use TECO] but it can be trusted to do no harm [I can't say the same with some other programs!].

Hidden within your comments above, am I reading that an editor is being used where you have to specify this?  Sounds like someone is trying to use a unix or related system.  In the case of SIMH, and given what I am doing with it, it just seems totally backward to have to do editing in an incompatible environment with less choices than one with more choices that are hassle-free.  If this has any meaning, I seriously suggest you redefine the term

"editing" because no one should adopt the thinking of others on the "right" way of doing things.  For the record, I have been cursing about unix bizarre behavior since 1975.  Since the overarching subject is working in a DEC environment, this is counter-productive.  And nothing in unix is better than TECO assuming as I have decades ago, mastered it from the original DEC environment, the TOPS-10 system on the PDP-10.  I never developed any "bad habits" etc.

In any case, I have offered PEPS here and I am finally in the death throes of both the user guide and the documentation of getting around the third-parry vendor problems so that PDF files can be generated properly.  From my vantage point, let's use the best tools available, not just something out of an uninformed decision process, etc.

On Sat, Sep 2, 2017 at 10:18 AM, Michael Thompson <michael.9...@gmail.com> wrote:

I found the original DECUS 8-213 ALGOL paper tapes and will make binary images of them. They have the decus labels on them so we will have a better idea of what they are then the ones that are circulating now.

​I have no idea about ALGOT issues; first I hear of it.

cjl

​

 

[CLASystems]

On Sat, Sep 2, 2017 at 10:16 AM, Michael Thompson <michael.9...@gmail.com> wrote:

Here are two files that might be of interest for people that are new to the PDP-8/PDP-12.

​A few words of guidance here:

1) These are VERY OLD routines; unlike fine wine, sometimes software DOES rot.

A lot of this work was the deaf leading the dumb leading the blind.  Well-intention-ed, but ultimately counter-productive.​

Why learn to imitate some mediocrity when others did wonderful programming gems that were far better?  This document would clearly generate the notion of "this is THE WAY to do this" when in fact often it is merely A WAY that unfortunately was not updated into what this collection thusiltimately is a pretender to be, etc.  Take them with a grain of salt.  If you need help point it out to me and then let me verify it really makes sense and is not either an embarrassment or just not well documented [or both].

Please note that the attitude of DECUS was anything goes, we need to show now MANY submissions were published, not how GOOD the submissions were, etc.

2) A lot of damage was done by one of the Introduction to Programming handbooks in that while the PROPER way to type up PDP-8 code was established long before that manual, many PRESUMED it was "the way" again in the same sense I mentioned above.  Clearly, the damage extended to the people who created these documents!  [arguably not their fault, but you all know what happens when you ASSUME!]

The simple answer is this:  A program was written and submitted to DECUS.  The program is amateurish and imcomplete, and clearly borne out of lack of expertise coupled with very likely no contact with the TOPS10 system and PAL10.  Thus, many developed a backward style based solely on the limitations of their hardware.

The emphasis is clearly on doing what can be printed out the FASTEST when your terminal is a model 33 teletype and is 10 characters/second.  You forgo the cosmetics because it is faster, especially if the environment is shared, etvc.  While this is understandable, it is not the way to go in a world where there is no material reason to continue that way, letting hardware limitations overshadow programming style.  Thus, those people inadvertently did a major disservice and you can see it in the needlessly poor style of imitating that program instead of rational and common sense.

And of course, again, this goes back to the low bar of submission standards of DECUS, as indeed the culprit program has a partial source listing on this cover and mentions DECUS.  What did we do when we saw this nonsense?  We IGNORED IT.

Fortunately, for us at Brooklyn Poly, we had a model 35 teletype to use daily.  It not only was a more rugged device, but we wisely tossed out DEC field circus.  In the NY area at the time, there were good service companies for teletypes, run by ex-employees of Western Electric.  They knew these things inside and out, and of course their charges were far more reasonable without all of the overhead that comes with DEC's semi-competent field service at overprice.

As a total aside, many know my vast collection of hardware.  Much of it was obtained because I DID NOT CHARGE the way DEC field service wanted to charge a "deinstallation fee" as a prerequisite for installing [at no charge if you wanted nothing additional] a new machine there.  Thus, I became well known as essentially from their point of view, a "junk collector" etc.  [But actually, their demands were totally arrogant.  You were NOT ALLOWED to actually  throw it away; they felt that might affect the company''s "image" so they insisted they be told of what happened next, etc.  In reality not only were these people charged a fee, the machine might be RESOLD possibly in parts, etc.  The NY  field circus office was caught in several scams at the time regarding using used equipment in other people's machines under contract!  In any case, they could honestly point DEC to me, and I would guarantee the company's good name would not be dragged asunder, etc.  In fact, in some cases, the final resting place of the machines was to be reconfigured and then be guaranteed my me to be elegible for field service, and in fact a few actually did.  I had many "runins" with these fools over the years.  One insisted that an entire machine had to be changed in his mind, when it was just a software problem; the user had no proper use of his machine for NEARLY AN ENITRE YEAR, but of course they paid fully and top dollar and got NOTHING TO SHOW FOR IT.  Who today would put up with such nonsense!

Thus, I made a lot of field circus people angry at me, and some feared me because I was always right while they guessed wrong, etc.  They only liucked out because many of their customers were complacent research scientists who just went into another direction, etc.  I actually helped them while DEC field circus just BS'ed them, etc.

In any case, beware of things created by the naivete of others.  Like everything from the past, there are both good and bad.  You need me as a "guide" to tell the difference.  [Sometimes I feel like an expert on which mushrooms are edible and which are poison!]

I did notice a small step in the right direction with a casual perusal.  They fixed a few routines that were the wrong way to go, and the replacements are nominally correct.  But the way some of them are dicumented is very hard for anyone but an expert to follow.  Clearly, documentation was not a strong suit for them at the code level at least.

I will give credit and a dig at the same time to them:

Very badly documented, and hard to read, their basic console output routine is in essence the correct way do do that function [this ASSUMES the console device is not on a modern terminal; this will not work for example on newer terminals where you have to support start-stop protocol; this is often why you have to use very slow terminal emulators, to avoid the problem, but this is at a different level of the problem.]

The actual implementation can be argued both ways as to is this the right way to write the code itself.  But the source is quite unclear as to WHY you are doing what they do, and that is a very limiting factor for beginners.  But on a binary scale, this gets the one, and many get the 0.

And just to make things more "interesting" OS/8 generally gets the 0 on virtually ALL of the programs that run there.  In fact, I daresay there are few that get the 1 other than the programs in the Kermit-12 package I wrote!  This is NOt an inherent limitation of OS/8 [which is why my programs do it correctly] but just the general slop of the programmers who worked on it either out of ignorance or laziness [or both; for the record, most of those who wrote it are personal friends of mine.  I can tell them they are lazy to their faces!].  And right behind that, some of them also do not type up the source code properly either!  [I would say it's about 50/50 when looking at all of the source code of OS/8.  I can assure you that ALL of the originated code in every P?S/8 source file is 100% proper.  More importantly, the correct way is ALWAYS used in P/S/8, and beyond that, the start-stop protocol is supported as well universally in all supported programs.  [And beyond that, P/S/8 also runs on DECMATES, something OS/8 CANNOT; variants such as OS/78 sorta work there, but it is by deleting reatures, so you really only get a subset of OS/8 and it shows, etc.]  By better system design, P?S/8 just works fine on all supported hardware, etc. without limits.

But if your purpose for now is to just support a teletype, the basics of the method is a proper subset of the overall method of doing all things correctly.

That said, when you are ready to learn the completely correct way to do basic outputting, I can give you some examples.  Again, this is not a requirement of the operating system which can support the sloppy way as well, but rather that there is discipline here to always do it right.  The DECmate issues is a layer beyond that because you can only apply DECmate compatibility in P?S/8; OS/8 cannot be modified to support the feature; this is why ALL attempts at OS/8 on the DECmates a) had to be a variant system, b) don't actually work on this sore point.  As such, I can provide two different variations where the latter one can only be used on P?S/8.  But there is no reason not to use at least the former for ALL cases.  As poorly descibed as it is in these documents, at least they have the rudiments of it correct.

The best way to explain that fundamental yet important issue is by a series of routines, each better than the previous, so you can understand the derivation.  At the primitive level provided, the code in these submission gets it right while all the examples in those DEC handbooks generally get it all wrong,etc.

Give me a little time and I will create some source code that ties all of this together.  The end-point gives you the skills to work with both systems properly, etc.  Needless to say, the cosmetics will be the proper way, and the commentary will be profuse and instructive, as well as the easiest to read by conforming to the proper standards worked out so many years ago, even before these documents [that mangle it somewhat].

cjl

 

[Peter Peterson]

Hi all,

Thanks for all the ideas and information.

The version of Spacewar that we are using is the D. E. Wrege & Assoc. version:

https://www.pdp8online.com/pdp8cgi/os8_html/SPCWR3.PA?act=file;fn=images/jby/jbyos8.tu56;blk=510,131,0;to=auto

... I think this is the one that was on the demo-12 tape, but I'm not sure.

One advantage of using the analog inputs on the 12 is not having to modify or touch the internals of the machine. There's something satisfying about taking a machine with analog inputs, using them as control inputs, and being able to disconnect and put the controllers away without any further ado.

That said, It's quite possible that the slowdown from using the sampler will be onerous, in which case we will look at using the switch inputs.

The information in this thread about how to get source files to our machine (and how to test the analog inputs) is all very valuable and I'm sure we will use it in one way or another.

Thanks again -- we really appreciate it!

Peter

[Michael Thompson]

That is the same source that I started with. I added some comments to the source, and fixed some problems with the console menus.

No modifications to the PDP-12 are required to use the 12 digital inputs. Looks like the logic levels are 3V and ground. A single LINC instruction is used to test the digital inputs and skip if the test condition is met.

The logic is described in section 5.5 of the Maintenance Manual Volume I.

The digital input in slot L17 is shown on page EP-12-IOB of  the Maintenance Manual Volume III. The SKIP logic is shown on the bottom half of page EP-12-SKL. The normal power and ground are probably wired in slot L17, so it would be easy to wire two button boxes (the same as on the PDP-1) to a single ribbon cable that plugs into slot L17. I should have the right paddle card to connect to the ribbon cable.

It looks like it would be easy to modify the two locations where it reads the console switches and the single subroutine that interprets the switches to enable the digital inputs.

--

Michael Thompson

[CLASystems]

On Wed, Sep 6, 2017 at 1:24 PM, Peter Peterson <pa...@d.umn.edu> wrote:

Hi all,

Thanks for all the ideas and information.

​More within this followup.
​

 

The version of Spacewar that we are using is the D. E. Wrege & Assoc. version:

https://www.pdp8online.com/pdp8cgi/os8_html/SPCWR3.PA?act=file;fn=images/jby/jbyos8.tu56;blk=510,131,0;to=auto

... I think this is the one that was on the demo-12 tape, but I'm not sure.

​I have a bunch of things to say on this one, some good, some not so good.  [I calls 'em as I sees 'em/]

1)  Doug and I know each other, having crossed paths many times, on such issues as FOCAL, 1969 [he wrote FOCAL-17, which anyone who wants to modify FOCAL needs as a starting point; I have it on-line on my archive site].

2)  When he started, he learned some of the bad habits I have warned about before.  As such, this particular file is NOT a good example of PDP-8 assembly language technique on several levels.  As an academic, you should especialy be made aware of this.  We don't want to reinvent broken wheels, etc.  [more on this later].

3) In terms of SPACEWAR "ratings", I put this one in the middle of the pack.

4) In terms of memory usage, clearly this was started to be O/S independent, which is always recommended for a program having no "connection".  The attached assembly listing shows the P?S/8 bitmap output that reveals this.  Only the text messages [and likely nothing else] is put into field 1.  This is what happens when you have 8K.  If you acknowledge this cannot run on a base 4K machine, you punt and use extended memory.  At least, only the text routines use cross-field access.  That means the overhead is minimized; badly organized code has too much cross-field calling.  It makes speed games like this become VERY slow, not what you want in this sort of game.  [Contrast this with the somewhat better POLY SPACEWAR which runs in 4K, but admittedly has no messages whatsoever.​  That said, if we made it into a P?S/8 system program, it could support overlay structures, and then it could have scads of messages and still run in 4K AND have the same overall "cosmetics".]  You can ascribe importance to messages on-screen [as opposed to a companion document file] but this is at least the lesser of several evils.  I would go with just the documentation separately.  Also, making the program P?S/8-dependent isn't all that helpful [even in the future].

Now back to 2):

There are several layers of programming pitfalls to avoid here.  Be advised to NOT imitate many of the PAL usage in this program!  The prevailing "rules" of programming practice were not created out of anything arbitrary, but rather many creature-decades of experience and how to avoid confusion, pitfalls and other potential problems.

After I get a chance, I will take the trouble to isolate a few printed pages of the code [without changing it in the binary sense] and show how people ought to be taught to program for the PDP-8, etc.

There is another much more serious problem here of a mixture of laziness and sloppiness that are not often co-resident with each other; each being sufficiently poor to be warned about.

The "upper" of the two obfuscates the "lower" one., so I will start at the top:

a)  This program generates links.  Links are actually errors from people who do not understand the PDP-8 architecture and are too lazy to bother learning it properly.  Inevitably, it backfires on them, most typically when a program gets involved with extended memory [!].

This misfeature was originally a part of an assembler that few actually used; the DIAL assembly ironically was based on it, but the misfeature was fortunately TOTALLY REMOVED!

ALL assemblers will always flag it and in the inevitable final summary page of both PAL8 and P?S/8 PAL, it is pointed out.  [Thus, this is NOT a casual remark!].

First the theory behind the misfeature, and then the harsh reality of why it in general DOES NOT WORK!

The PDP-8 is a machine where any one instruction can only DIRECTLY address two pages of memory:

i)  The page it is on [aka the "current page"].

ii) Page Zero meaning locations 00000-0177.

Since there are 31 such current pages [and page zero] in a 4K memory field, you have to be aware and program for the way the hardware actually works.  Of course, various revisionists have come along and played abstractionist  games,, [all of which fail].  There was once a cheap-shot attempt to pretend this is not true.

Consider the following few examples.

     *200  /NEED TO PICK TWO PAGES, MIGHT AS WELL START HERE AS IS COMMONLY DONE.

     JMS     4OO     /THIS CANNOT WORK, BUT GENERATED LINKS PRETEND IT WORKS ANYWAY.

     TAD      500     /THIS IS NASTIER, THE GENERATED LINK ONLY *MIGHT* WORK AND IT CANNOT KNOW WHEN IT FAILS!

To simplify the matter, I have left out symbols, which only means too many things to learn at once.  A symbolic assembler is helpful, but it cannot assemble into code that does not work!  Thus, I am avoiding this concept entirely here as it does not advance the discussion.

The ACTUAL code this source code creates is a function of passed command-line option switches, and the two prevailing assemblers handle the error aspect of things differently, but the actual code generated is this:

  At 0200 what is actually generated is 4777.  that means it is in actually the same as:

    JMS I (400)

The problem for the moment [it gets worse!] is that now the fledgling programmer is led to believe the fantasy that the PDP-8 has magic properties that skirt around its own architectural rules.  But when you inspect the actual code generated, you see the reality is not what you used.  The point is you should have gotten an ILLEGAL REFERENCE error trying to do the impossible.  Then,,the programmer learns that you have to change your way of approaching PDP-8 programming: Direct references have to be for close-by code that didn't "spill" into another page.  And the fix is to make some form of intelligent decision:

a)  Make it an INDIRECT reference acknowledging the program "grew" a bit too quickly, and redesign accordingly.

b) Take something off the current page to make enough room to avoid the problem.  There are all sorts of techniques to justify moving something to somewhere else such as:

aa) There is some subroutine that is used in so many places, you should move it to some other page where similar routines are located and they are ALWAYS referenced indirectly.  Additionally, it is likely that a page zero pointer to the routine is appropriate because it is efficient to do so that way.  That is the most likely scenario of how a program evolves, etc.

ab) Maybe a variable on the page should be moved to page zero. Especially if the contents is needed in other places.

There are more than these two, but the overall point is THINK of what you want your program to do, and organize it accordingly.

Letting the assembler just so happens it can kludge something is LAZY and eventually this will come back to bite you!

Thus, repeated dependence on this feature will inevitably backfire.  [But in the short-term, it sorta works, but now on to the next example that DOES NOT work in general].

The PDP-8 instruction set has some rules when extended memory is in effect. Generated Links break down into two groups:

aaa) The ones that sorta work>

aab)  The ones that flat out DO NOT work!

The first group is when the instruction involved is either a JMP or JMS instruction.  These do not change even if there is extended memory unless you deliberately use an instruction extension.  Thus, you would have to know to do so and do it correctly.  [Obviously, lazy programmers don't know and don't care!]

The other group applies to all other memory reference instructions [AND, TAD, DCA, ISZ).  This discussion is irrelevant to IOT and OPT class instructions, etc.

For those four types, when they become indirect, they DO NOT WORK the same way!

The data field is set to the field for these four instructions only when they are used INDIRECTLY only.  Thus.this form of link flies in the face of the actual hardware!  The data field is a DYNAMIC condition; it is NOT KNOWABLE in advance and it may easily CHANGE depending on many factors [including program blunder].

Thus, this form of link is the first one that bites lazy programmers when their code is suddenly needing to run in a larger program that inhabits some part of extended memory.  The 4K sloppiness turns into the nightmare of not knowing what doesn't work all at once!

Worse still, the assembler DOES NOT DISCRIMINATE!  Thus, you also have to go back and hand-comb the entire program looking for what was violated.  But if the assembler switches are set to minimize the problem, then you are not even aware of where the problem comes from!

Thus, I STRONGLY suggest this aspect of the program be eliminated.  If it is [as is most likely in MOST cases] just a case of lazy subroutine call, then fix it.

Bother to use the indirect form:

     JMS     FOO

just becomes

       JMS I  (FOO)

Then you are SURE that it works and can pay attention to any further links you didn't fix.  Then eliminate them as well [if any].

Then the norms of program development can continue without the arrival of unexpected pitfalls, etc.

There are well over  100 links generated in this program!  This is really sloppy!

If you want me to spend the time, I can clean this up for you, etc.

Now to the other problem obfuscated  by the links problem.

For all I know, this one is causing a CURRENT BUG!  I haven't researched whether or not it actually makes something break down.  [But that's the whole point, isn't it, why should it have to matter, when better programming technique makes this NEVER HAPPEN!]

The dead giveaway to me was that at the end of pass 1, there are still three unresolved errors.  After subsequent passes, there SEEMS to be no errors.  But that is NO GUARANTEE the code is functional because the LISTING won't show you what is going on in PAL8.  In P/S/8 PAL there are only two passes, so you can look at the octal and be sure or not of the blunder.

The problem is that he wanted to use some symbols related to the notion in LINC mode of the SCR intruction [Scale Right] which is a shift to the right where the new bit on the left for each rotate to the right is the same as the high-order bit.  This means it is a signed shift to the right some stated number of places.  A normal rotate to the right is inherently unsigned and rotates into high bits always zeros bits, etc.

Some programmers, especially ones with "bad habits" from other machines learned earlier corrupting PDP-8 knowledge, like to use symbolic names for pet subroutines.  Also, I do know that Doug was influenced by FOCAL, 1969.  The problem is not the concept but rather the implementation.

In FOCAL, the technique is not the problem.  What he did INSTEAD is problematic!

He defines some symbols in terms of a subroutine call to a routine.  The problem is that, unlike FOCAL on these few instances alone, the definitions are just at the point of the subroutine itself!  [FOCAL ALWAYS places it on page zero, a pointer to the routine.  The definition has nothing to do with the subroutine in actuality, rather it is an instruction accessing the page zero location itself.  The VALUE that will go in there is the assembler's problem and will be properly set during pass 2.

Thus, this symbol was defined JUST BEFORE the value of the referenced literal address [he did it in that form, FOCAL didn't use literals at all, thus not a problem!] thus, the symbol is partially undefined and no proper definition can be obtained for usage until the defining line just in front of the actual subroutine!  [Note:  The subroutine is nearly halfway through the program!  That means that during the second pass, the actual code generated if used BEFORE that point is GARBAGE!  Yet, because PAL8 does a THIRD-PASS listing, the LISTING shows the INTENDED CODE!

This is a really bad sore point and has been brought up many times before, first by my late friend Jim Roth, who for part of his career worked for DEC and modified the symbol table sort routines of PAL8. Since he had to look at that mediocre code that plagues me, he saw the problem for what it was [I had been telling him PAL8 is crap, and he agreed, but at that point he was living in the Maynard Ma area and he only had in mind the symbol sort stuff, which is excellent but in an ironic sense is "too good" for PAL8, etc.  For reference, the original P/S/8 PAL assembler was 100% written by Jim as a complete replacement for the PAL III paper-tape assembler, but with far better programming technique.  PAL III has some nice features, and P?S/8 PAL maintains them.  But all the other assemblers ignore those features.  But PAL III and his replacement are both "no frills" and then I took over and wrote literally all of the "fills" including Literal and Link generation support, dual-mode assembly for the LINC-8 and the PDP-12, and about 2 dozen assorted more nuanced features and the xref dumpout routines.  [Note: PAL8 does NOT support cross-referencing; this is a myth!  What happens INSTEAD is that CREF is a post-processsing program that ASSUMES that what you see in the listing is what was in the program that was assembled.  This is a crock!  Only TOPS-10 and P?S/8 PAL do their own reference dump.  That way you get the STATEMENT cross references, not what is seen in the listing!  The differences can be staggering!  I have some source code of programs with pages of failed-conditional COMMENTS and stupid CREF cross-references the words in the comments [because it is too feeble to know they ARE comments![  Because of conditional assembly, you don't get to see a lot in a well-defined source program.  By way of example in this SPCWAR3, there are large sections of unassembled code that doesn't apply to what you want.  Had this been done CLEVERLY instead of AMATEURISHLY, you would see it in the listing, it only serves to distract, etc.  But as I said, Doug started out with some bad habits, this is just one of lack of experience at the time he wrote this program.  Stuff he wrote later is better, etc.]

Thus, i have to check to make sure these symbols are NOT referenced earlier in the program.  Unless you have P?S/8 PAL, you cannot even know there is a problem [other than the program crashes] because unless you examine the code in memory directly, you don't realize what is running is NOT what you see in the listing!  Jim warned us all so many years ago, but not everyone got the message.  [I was one of the first to hear it from the horse's mouth.]

Thus, I would label this as they upgraded the definition of the earth in the Hitchhiker's guide from HARMLESS to MOSTLY HARMLESS.  It needs to be checked out, etc.

I have created a listing file for you [attached] that has the command-line switches set to not complain about generated links.  However, they are ALWAYS tallied up at the end in both assemblers, and each occurrence is flagged with a ' character so it does stand out.  Any work on the file, I need time, but you certainly can start today with this, etc.

I have also attached the source file for OS/8 usage in an .RK05 file.  Just add this to the list of RK05 files supported by the seraldisk server.  You can have up to four drives if you are using the newest Adamson version of the server, and my version of the handlers.  [I assume Mike gave these to you, etc.]  That way, we have a means of going back and forth via email for any and all things that come about.  And when you can get to run my PEPS package, you can run both on the same Windows machine.  [unix systems are not doing you any favors; Windows runs not only the server, but my version of SIMH has far better development tools on many levels hands down.  No reason not to run Windows if you have a PC; if you insist they can coexist in a dual-boot arrangement, etc.]

Also, of course this is NOT that demo-12 "spacewar" that I mentioned.  that's a baby program and it came from DEC.  With this one, at least you get into the "ballpark" of a game that actually "does something" etc.  [Note:  Pretty much all DIAL-based things are LINC-centric from LINC/LINC-8 prior versions.  LINC-based programs are handicapped because the LINC instruction set does not support the math hardware needed, especially there is no divide instruction.  [Thank you Maury Pepper for your insight as to why].  But this program is NOT PDP-12-centric, so as is typical, no LINC code at all except briefly when necessary, etc.]

cjl [get back to me if any questions, etc.]

 

​ps:   The first page is an inside joke.  Doug was not really a "business" in the normal sense, thus the D.E. Wrege and assoc. etc.  the point is that language is lifted from the typical boilerplate lines in the beginning of every DEC source code file.   I think he should have just changed DEC to DEW where applicable :-)
​

 

Virus-free. www.avast.com

[CLASystems]

On Wed, Sep 6, 2017 at 8:14 PM, Michael Thompson <michael.9...@gmail.com> wrote:

That is the same source that I started with. I added some comments to the source, and fixed some problems with the console menus.

​That code could be beefed up.  BTW, I invented the upper/lower-case text technique and it is in my source code for Kermit-12.

The idea is that you substitute two characters that can never be in the text messages [I use ^ and %].  When you want to case shift, you insert an ^ and when you want CR/LF you use the %.  That way you can easily get multiple line messages in upper-lower case and also not waste bits for more memory, etc.  And if you need to, a one-word patch makes it all uppers again.  [Note: Real Teletypes fold lower to upper, P?S/8 system programs do include a switch to fold in the software if you have some strange incompatible terminal, etc.]  any rewrite of that stuff, I strongly recommend that be used to easily get a nicer result, etc.
​

 

No modifications to the PDP-12 are required to use the 12 digital inputs. Looks like the logic levels are 3V and ground. A single LINC instruction is used to test the digital inputs and skip if the test condition is met.

​Actually, it is more elegant than that,.  The assertion of  the level is to ground that pin.  The instruction can be either skip if set OR skip if clear.  That makes it really easy to use because you never have to do some program inversion for one "flavor" input, etc.​

The logic is described in section 5.5 of the Maintenance Manual Volume I.

The digital input in slot L17 is shown on page EP-12-IOB of  the Maintenance Manual Volume III. The SKIP logic is shown on the bottom half of page EP-12-SKL. The normal power and ground are probably wired in slot L17, so it would be easy to wire two button boxes (the same as on the PDP-1) to a single ribbon cable that plugs into slot L17. I should have the right paddle card to connect to the ribbon cable.

​If you put in termination resistors, then this is safe to remove, even if the machine is running.  The terminators will prevent transients from zapping the input gates, etc.

[Note: The DR8E already has the resistors on it!]

cjl​

Virus-free. www.avast.com

[Nick Moffitt]

Peter, if you have a moment at the UMN 12's console some time, could you try loading different data into the AC and MQ in 8 mode and see if executing opcode 7521 swaps them?

Explanation below:

On 01Sep2017 08:06pm (-0400), CLASystems wrote:
> 1) PDP-8 EAE lacks an important instruction SWP to interchange the AC and
> the MQ register contents. The code can here and there be optimized if you
> can take advantage of that. But this is only available on the PDP-8/I and
> the PDP-12 [which is based on the PDP-8/I]. [Note: This also applies to
> the PDP-8/E family; there is also MODE B which adds a lot of nice
> double-precision instructions that are very useful, but this would be a
> major rewrite of the code that works in the "rock-bottom" world of EAE of
> the "straight-8".

I have been re-reading the above paragraph rather extensively, and wanted to make sure I understood this.

I've been looking at the KE12 documentation here: https://archive.org/details/bitsavers_decpdp12DE_17124053/page/n97/mode/2up

This document suggests that the PDP12 only has the following EAE instructions:

First:
CLA Clear AC
Second:
MQA Place MQ in AC (leaving MQ)
MQL Load MQ from AC
SCA Step Counter to AC (ORed, so CLA SCA to load)
Third (pick one):
SCL Load Step Counter
MUY Multiply
DVI Divide
NMI Normalise (Shift repeated bits off AC and MQ, and count)
SHL Shift Left (double precision: AC and MQ both)
ASR Arithmetic Shift Right (Sign-preserving double right-shift)
LSR Logical Shift Right (double right-shift with leading zeroes)

It also lists CAM to clear AC and MQ, but near as I can tell that's just CLA MQL.

I can't find any mention of SWP anywhere in the PDP-12 manual, but the opcode for the 8/E's SWP seems to map to EAE instruction MQA MQL (7521). I wonder if this is truly available on the 8/I and 12, or if it was introduced with the 8/E. Various documents suggest there was built-in load/store logic for MQ on systems that didn't have an EAE, so it could be an undocumented part of that.

Sadly, simh pdp8 seems to only implement an 8/E (for good reasons), so I'm going to the top of this mail now to beg a test from the UMN machine.

[Nick Moffitt]

On 08Dec2021 03:52pm (+0000), Nick Moffitt wrote:
> I can't find any mention of SWP anywhere in the PDP-12 manual, but the opcode
> for the 8/E's SWP seems to map to EAE instruction MQA MQL (7521). I wonder
> if this is truly available on the 8/I and 12, or if it was introduced with
> the 8/E. Various documents suggest there was built-in load/store logic for
> MQ on systems that didn't have an EAE, so it could be an undocumented part of
> that.

Of course the moment I actually ask about this, I find the following:

http://homepage.cs.uiowa.edu/~dwjones/pdp8/man/micro.html#group3

| On the PDP-8/E and following models, CLA, MQA and MQL instructions are
| implemented in the standard CPU, while the other operations are implemented
| in the optional EAE. Portable code should avoid relying on the availability
| of any of these instructions.
[...]
| The microcoded combination MQA MQL swaps the contents of AC and MQ. Some
| assemblers supply the mnemonic SWP for this combined operation.

So I guess that answers my question. Thank you all for being the teddy bear in the hallway for this!

[Peter Peterson]

Glad to be of service!

[Vincent Slyngstad]

I can't seem to start a new message in a thread -- everything I do seems to be construed as a reply to the latest post.

Anyway, I'm interested in what you guys are using to get files back and forth between your PDP-12 and the network connected machines you presumably use otherwise.

There are advancements that I haven't seen talked about here.  The current SerialDisk, for instance, no longer has that Fortran incompatibility.  Also, there are tools to quickly and easily move files in and out of an OS/8 disk image without at that PTR: and PTP: SIMH foolishness.

Are you using the latest SerialDisk from Kyle's repository?

Have you seen or considered the 8tools from my site?

https://svn.so-much-stuff.com/svn/trunk/pdp8/8tools/

https://svn.so-much-stuff.com/svn/trunk/pdp8/8tools/doc

Thanks,

Vince

[Peter Peterson]

Hi Vince,

We haven't updated our serialdisk nor have we upgraded our approach for moving files. We are interested in both! They both sound absolutely fantastic. Most of our work recently has been on chasing down a tape drive issue (including flipchip tester stuff) and working on the memory expansion. The pandemic really slowed us down because everyone was spread thin and it was harder to work together in person.

But we're getting back up and running.

I'll message you separately to debug the mailing list issue.

Thanks,

Peter

--

Peter A. H. Peterson, Ph.D. (he/him)

Assistant Professor
Department of Computer Science

University of Minnesota Duluth