Compiling Fortran on the PDP-12

[Dawson Rosell]

Hey all!

I got a moment to go and try to run some code on the PDP-12 but I'm having problems compiling it (again haha).

I am trying to compile a simple test program I wrote, as well as some of the other .FT files that are on the .rk05 image.

Mike, I am using one of the images you gave us over the summer. There is a file called TRIAL2.FT that will list squares and roots of some numbers. I have tried to compile it a variety of ways:

R F4

TRIAL2,TRIAL2,TRIAL2<TRIAL2.FT/G$

R F4

TRIAL2/G

R F4

TRIAL2.FT

And others...

It either runs through the compiling process and then goes back to the . prompt, or it hangs on the line I hit $ (esc) on. When it goes back to the prompt it doesn't appear that there is any sort of runnable file anywhere.

Is there something I'm missing?

I have attached the disk image below. It also has my test program on it, called SUB.FT. I was using this to try and test subroutine calls on Simh as I have narrowed down the problems I having with Whetstones to subroutine calls. It attempts the call and then throws out a USER ERROR (if I recall correctly), pointing to the line the subroutine was called. Could this be a problem with Simh?

Thank you,

Dawson

[Michael Thompson]

I can give it a try on our 12 tomorrow.

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.

<Mike_PDP-12.rk05>

[Michael Thompson]

Charles,

Maybe you could help us with this.

I get the same behavior on our PDP-12, the FORTRAN-IV program compiles and runs, but has no output.

If I single step the FORTRAN program, I see IOT instructions 6551, 6661, 6041, 6031, 6021 6011, and 6244. It seems a little strange all of these different IOTs.

What are we doing wrong?.

--

Michael Thompson

[CLASystems]

For starters, take this to your 8/E and repeat everything.

The FRTS is interrupt-driven and like FOCAL needs to clear "the usual suspects" so the interrupt-handler can work.  If you have a "rogue" non-standard device, it could hang this up, so it could be an attempt to "clear the world" re interrupts.

Depending on what's happening, remember the 8/E has the CAF instruction while only the -12 has an equivalent using the special functions register which if you set the right bit is equivalent to the clear on the front panel [not counting mode change, but the essence of I/O Preset.  Mostly CLEAR on most machines, but the point is these are the only two that have any support whatsoever.  And of course, it could b e something that doesn't conform at all, preset could SET a flag, but hopefully clear an interrept-enable making it moot.  the TC01/08 work that way.  One of the loadable status bits is clear the ability for an interrupt from the device, a separate topic from the clearing of the actual flags.  So, if I am correct this is a routine trying to get past the problem , and sounds like it isn't succeeding.

As long as none of these machines actually have FPP-12 or FPP-8/E-a, all is simulated the same way and it has to be the interrupt handling in FRTS.  If it works on your home machine, its a matter if finding out why you are interrupted, and then restoring it leads to yet another interrupt because you aren't able to dismiss it.  [Isn't there some "home-brew" stuff in the RICM -12, and I have no idea what Dawson etc. have [beyond a bare machine and I assume 8K].

I modified FOCAL, 1969  in the P/S/8 version to have a more comprehensive table so "bad" devices could  be tamed by patching it in.  Over the years, a few stupid devices lack the notion of interrupt-enable in the device, and certainly things Rick Merrill encountered back in the day.  Since it is stand-alone, FOCAL, 1969 only has I think three locations for a tentative patch.  Look at the source code of FRTS to see if they have any, etc.

But in P?S/8 FOCAL, there is tons of once-only initialization code space, so I added a 64-word table to be able to kill interrupts from any conceivable device, etc.

And of course, all of this assumes the hardware is working, and stray interrupts from such devices is expectable, as opposed to being caused by being broken.

BTW, serial interfaces which are current-loop when the loop is open will do it; Remember, Rick was working with machines with up to three additional teletypes, all on PT08s thus, four-user FOCAL, etc. so he was one of the few to early on have to deal with pesky stray interupts. [Turn off the teletype and it interrupts forever!]  This is why all the newer stuff has interrupt-enable per AC[11] instructions on the Omnibus, but SOL on nigibus and posibus stuff, etc.

BTW, if you remember I had to debug the serial-disk handler because it wouldn't work on the -12 [actually on all pre-8/E].  The instruction was the disable per AC[11] for I believe the device most likely to be used on the output side of the remote port back to the server.  I never got any info as to why he wanted that, but presumably because the server is weak in spots, and in any case, the code says it's there so the FRTS doesn't hang!

I suspect these are all somehow related.

Food for thought,

cjl

ps:  Another topic:

Because I have been swamped, I haven't finished a project I started:  I am cleaning up Doug Wrege's SPACEWAR source code.  It is very problematic because he wrote it before he became a far better programmer and learned to avoid generated links.  They cause problems and should NEVER be used, and I believe I even located a bug in the code that may just work by the skin of its teeth, and could easily blow up if things are moved; it's poor technique intertwined with generated links.  It will have to work, but in the meantime, I am putting the finishing touches on the P?S/8 PAL handbook/guide document which is turning into a serious-size document, most of which is useful regardless of which system, and there are PAL versus PAL8 issues and options throughout, etc.

One four page section is essentially a beginner's guide to why you should never use generated links, and I think I can extract that out almost immediately; it is likely done and in fact the document is likely 99.5% done overall, just in the state of essentially proof-reading typo-finding, etc. [It already passes a spell-check!].

So, if there is current interest in working on that source file, I can at least orient anyone looking at it as to what to look out for, etc.

Already a bunch of people have requested a copy, and of course I will put it out on various places when completely done [PiDP8, alt.PiDP8, pepswin and P?S/8 Google groups, etc.  and of course the long-term goal is a set of online manuals for all of P?S/8.  It takes me some time and effort, but when I have a chance [and enough sleep] I am working on this, etc.

--

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

Bill Gates, 1992

[Michael Thompson]

This works...

.R F4

*TRIAL2/G$

TEST OF FORTRAN IV (F4.SV), LIST OF SQUARES AND ROOTS

THE SQUARE OF  1 IS   1 AND THE ROOT IS   1.000002

THE SQUARE OF  2 IS   4 AND THE ROOT IS   1.414215

THE SQUARE OF  3 IS   9 AND THE ROOT IS   1.732053

THE SQUARE OF  4 IS  16 AND THE ROOT IS   2.000002

THE SQUARE OF  5 IS  25 AND THE ROOT IS   2.236070

THE SQUARE OF  6 IS  36 AND THE ROOT IS   2.449491

THE SQUARE OF  7 IS  49 AND THE ROOT IS   2.645753

THE SQUARE OF  8 IS  64 AND THE ROOT IS   2.828429

.R F4

*PRIMEP/G$MORE CORE REQUIRED

The $ is actually the ESC key, so type in the command up to the "G" and then hit the ESC key. It will then print the "$".

Michael Thompson

[Dawson Rosell]

Hmm. I'll give that a shot when I'm in front of the -12 next. I might be able to run over tonight and check (I live across the street conveniently).

Thanks for the suggestions and help so far everyone! I'll update with results when I have them. 

[Dawson Rosell]

I tried "TRIAL2/G$" on the -12 and it compiled and then hung. It sounded like it finished compiling, and then the lights on the front of the machine stopped changing and nothing printed out. The AC was 0 and the Link bit was 0. It didn't look like it was stopped (as the lights for the IR, PC, MA, and MB either on, off, or partially on. So it looked like it was thinking about something). I hit CTRL-C and it came back to life and went back to the prompt.

I tried to run it in Simh, but that disk image doesn't boot in Simh for some reason. I am working on trying to transfer the program to another disk I can use in SIMH.

[CLASystems]

On Sun, Jan 21, 2018 at 12:32 PM, Dawson Rosell <rose...@d.umn.edu> wrote:

I tried "TRIAL2/G$" on the -12 and it compiled and then hung. It sounded like it finished compiling, and then the lights on the front of the machine stopped changing and nothing printed out. The AC was 0 and the Link bit was 0. It didn't look like it was stopped (as the lights for the IR, PC, MA, and MB either on, off, or partially on. So it looked like it was thinking about something). I hit CTRL-C and it came back to life and went back to the prompt.

​Not stopped, just hung.

Consistent with my last post.

​

I tried to run it in Simh, but that disk image doesn't boot in Simh for some reason. I am working on trying to transfer the program to another disk I can use in SIMH.

​I'm confused.  I thought you didn't have an RK05 like RICM?

All bootable RK disk images boot on SIMH.  The problem is some of them cannot boot on other machines [Version 8T OS/8 monitor head is for 8/E and up only].

In any case, is it corrupt or merely it's not a system disk [which never boots.  Remember in OS/8 all media is not obligated to be bootable, one of the confusiing things about OS/8. P/S/8 always is bootable, unless it's an image for an alternate device [such as say for the TD8E trying on TC08 hardware or vice-versa].

And of course an image can me converted from another imagee.  For example, we have made TC12-oriented images on DECtapes intending for them to be passed through the TC12F program to become a lLINCtape, etc.​

​In any case, my theory is you will get it to work on SIMH, and the problem will be something on the -12.  Also, it has to be an old enough release so it is not 8/E and up!  This is why I am so angry about mixed systems that "almost work" when used not where intended.

OS/8 V3D [aka Q] the original release runs on all machines.  The V3D extensions DO NOT.  The handlers from the extension kit may or many not either.  Also, some of them are missing [in terms of source code].

Even newer than tne V3D extensions kit ]V3R or V3S or Ve t]  is OS/78 V4.  It only runs on DECmates and worse, cannot support certain features such as non-system handlers that support Control-C had the code removed, etc.  and of course, MANY of the programs there are suspect in terms of just how much of which can run on less than either DECmate hardware and/or 8/E and up hardware versus older hardware [such as the PDP-12].

To say this is a bloody mess is an understatement, but too many fools ASSUMING things is the problem.

The RL and RX02 and related handlers that came out with the extensions kit probably do not work pre-8/A.  It's moot for the RL because that requires an 8/A.  But the RX8E interface can find itself on a DW8E on any machine all the way back to the straight-=8.  The code in OS/78 V4 cares  not and becase it is on a DECmate [intended so at least] it might "nearly" work with things missing, such as all the ramiifcations of lack of Control-C support, etc.

Anyway, it will help if you prove your program can work on SIMH, and why I asked Mchael to run it on his 8/E.

Let's remove as any unknowns as possible, etc.

cjl

--

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

Bill Gates, 1992

Virus-free. www.avast.com

[Michael Thompson]

I think that you missed the last line in an earlier email.

The $ is actually the ESC key, so type in the command up to the "G" and then hit the ESC key. It will then print the "$".

Then it will compile and run.

--

Michael Thompson

[Dawson Rosell]

I think that you missed the last line in an earlier email.

I hit ESC and it still didn't compile.

I just tried typing it into a blank file, converting it, and then reading it into an image on Simh (disk2.fortran.rk05). The original program "TRIAL2.FT" compiled in Simh with: TRIAL2/G$

I will try reading in that file I created through the PTR on the PDP-12 and see if it will work that way.

​I'm confused.  I thought you didn't have an RK05 like RICM?

We don't have one. I'm using Kyles diskserver program. Maybe it has to do with that?

I will update in a minute about whether or not reading in a file and compiling that one works on the -12.

[Dawson Rosell]

Update: I tried reading in the file I wrote (TEST.FT) Which has the same contents as TRIAL2.FT. It reads into Simh just fine and displays correctly, compiles and runs. I read it into the -12 and it only has the first couple of lines and then some garbage characters and symbols. I am using PIP (*TEST.FT<PTR:) to read it in to Simh and the -12.

The difference between the two scenarios is the on the 12 I am running Mike_PDP-12.rk05 (as it will not boot in Simh) and in Simh I am using disk2.fortran.rk05 (as it will not boot on the -12). I don't know enough about the structure of the images to know what changes need to be made so they boot on either (if they can be changed. I assume it's something with SYS BUILD?)

[CLASystems]

On Sun, Jan 21, 2018 at 1:31 PM, Dawson Rosell <rose...@d.umn.edu> wrote:

I think that you missed the last line in an earlier email.

I hit ESC and it still didn't compile.

I just tried typing it into a blank file, converting it, and then reading it into an image on Simh (disk2.fortran.rk05). The original program "TRIAL2.FT" compiled in Simh with: TRIAL2/G$

I will try reading in that file I created through the PTR on the PDP-12 and see if it will work that way.

​I'm confused.  I thought you didn't have an RK05 like RICM?

We don't have one. I'm using Kyles diskserver program. Maybe it has to do with that?

I will update in a minute about whether or not reading in a file and compiling that one works on the -12.

​OK, very bad form to use shortcuts when explaining exactly what you're doing, lose the forest for the trees, etc.

OK.  I assume Michael can verify what I am saying here:

You need to be running the following:

1)  You have OS/8 booted to LINCtapes, correct.

2)  On that system you added non-system serialdisk handlers.  Remember, the system handler is the one that really boots, so unless you boot the serialdisk system itself, that's the way it works

Alternatively, you in fact are booting the serial disk program and you do need a bootable serialdisk handler-based system  Pick one! :-)

3) You have to be running what was originally Kyle's server-side program for pc linux or Windows. which just adds the standard Cygwin1.dll file.

OK, all that said, the serial disk handlers should be the correct choice from the ones I wrote; I am the author of the latest system and nonsystem serialdisk handler.  These are the only ones that run on the PDP-12 and are used at RICM.

Additionally, you should be running Bob Adamson's server program, which is the one what I wrote matches up with, and it adds support for twice as many ersatz RK disks so each half disk sized faked RK05 half having a partner increases from a total ot  two [four devices] to four [8 devices].  There is no reason whatsoever to run the earlier ones and likely they cannot work on other than an 8/E anyway, etc.

Do you even have functioning LINCtapes there?  Mike's are still flakey although when I was there a few months back we got some of my tapes read with a LOT of effort.  That is still unfinished work.  We have to schedule more time together when this ghastly winter is on the wane and something resembling Spring happens on the east coast.  [And that includes Mike and Dan coming to me, likely first if the schedule works out, etc.]

If you are running the serial disk system handler, you should at least have a way to read in the bootstrap without toggling it in.  That's why I suggested you might nave a LINCtape-based OS/8 so you can run the OS/8 boot program Mike modified to include serialdisk support in liew of some more obscure device [in empty space defined in the program].  Also, the code that matches the newer code can be one word shorter, but it is compatible with the first attempt., albeit needlessly one word longer than now necessary, etc.

In any case, you have to get that image file into SIM but yo do NOT have to make it the bootable RK image in SIMH, as SIMH simulates REAL RK05 RK8#, and supports all four drives.

Just to make you all a bit more batty, All RK8E=bootable systems are supposed to support booting to any of the four drives; you change a minor SIMH parameter to do this [BO RK3 for example].

When I get a bit more advanced, I will be supplying P?S/8 for REALRK as well.  Then on SIMH I can boot P?S/8 on one set of the RK drives, and OS/8 on another :-).

For now, I boot P?S/8 on the 8 TC08 DECtape drives and I let OS/8 have all four of the RK05 drives, because that's a viable way to go for both systems.  But when I get some other things done, this will change.  There already does exist such a system, but I want it to embrace the disks as larger than OS/8.  The need to split drives in half is an OS/8 crutch because OS/8 runs out of gas.  Thus the need for EIGHT handlers to address all four drives.  P?S/8 will handler ALL of then with ONE handler using 4 of the maximum 8 logical units.  While SIMH doesn't support this, I need some contact with a working RKS8E system and then I can support the other 4 logical units.  OS/8 cheats on this one.  Handlers for ONLY the RKS8E are used and itASSUMES you won't use them on reguar RK8E hardware because it is easily spoofed.  Because P?S/8 has vastly superior system device handler design, all I need is to add initialization code to determine to return an error or not if addressing the "upper" 4 logical units [the other 4 drives on a real RKS8E].  They are all totally compatible on drives 0 through 3, but if you spoof it, it will APPEAR to work on drives 4-7 when infact it is accessing 0 through 3.​ [Once I add the initialization support, then literally one handler does them all regardless of what you have.] [It would be nice to get the RKS8E support into SIMH!]

cjl

--

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

Bill Gates, 1992

Virus-free. www.avast.com

[Dawson Rosell]

​OK, very bad form to use shortcuts when explaining exactly what you're doing, lose the forest for the trees, etc.

Yes, my bad. I'll try to be more clear.

To sum up how I am doing everything: I toggle in RIM, start the disk server with Mike_PDP-12.rk05 attached. I send the bootloader.rim from the TTY program. (MTTTY in this case. I tried to get minicom to work, but didn't have time to finish before the Fall semester took off). Once the bootloader is sent, I stop RIM, I/O PRESET, and START 20. MTTTY shows the prompt and I am running OS/8. If I change disks I hit STOP on the PDP-12 and then I stop the disk server. I attach a new .rk05 image, and then set the Left Switches to 7605, I/O PRESET, and START LS. I am then back at the prompt for the new disk. Should I be resending the bootloader each time as it is a different disk image its booting from? Thats something that I didn't consider until as of now.

When compiling Fortran programs on the disk server using Mike_PDP-12.rk05 as the booted image, I run R F4 and then TRIAL2.FT/G$ (the escape key). I type out by hand the exact same program and read it into the PTR on Simh using the disk disk2.fortran.rk05. It read in fine and compiled and worked perfectly. I do the exact same thing with the PDP-12 and it reads it in, but when I display it it only shows the first few lines and then some random characters. The process for reading in the file, or the file, did not change between the two. All that changed was what .rk05 image I was using at that moment (as I haven't gotten the PDP-12 to boot disk2.fortran.rk05, or simh to boot Mike_PDP-12.rk05)

1)  You have OS/8 booted to LINCtapes, correct.

I have the original LINCtapes with all the old files still on them (all backed up thanks to Warrens program). I have 4 blank tapes for testing and things like this. I have not been using the TU55 for anything related to OS/8 though. I have been booting OS/8 from a .rk05 image using Kyle's diskserver program. Would it be more reliable to be using a tape?

How would I create a new tape, then that can be booted, on one of the blank tapes I have? I can transfer files I need over from the disk server to the tape.

2)  On that system you added non-system serialdisk handlers

I'll be honest, I'm not sure if I did or not. I haven't been able to work on this for quite a few months and I don't remember what Warren vs what I did when things got set up.

Alternatively, you in fact are booting the serial disk program and you do need a bootable serialdisk handler-based system  Pick one! :-)

So, if I'm following correctly, I can do this one of two ways? I can either be running from a LINCtape, or I can be running from serial disk?

OK, all that said, the serial disk handlers should be the correct choice from the ones I wrote; I am the author of the latest system and nonsystem serialdisk handler.  These are the only ones that run on the PDP-12 and are used at RICM

Where can I acquire a copy of these to make sure I am using the right ones? The same for Bob Adamson's server program?

Do you even have functioning LINCtapes there?

Yes, we do... sort of... The top drive works great, and the bottom one is flaky. The bottom one has problems with the Brake Enable on the right hub. Checking the R111 in B06 has been on my to do list for a while. Might do that if I can't get anything else working here...But the top drive has been working fine.

Forgive the many questions, I'll eventually get the hang of all of this. (it'd be easier if I had a PDP-8 of my own at home to play with haha, but across the street is as good it will get for now. ;) )

Thanks everyone for the help and quick responses!

Dawson

[CLASystems]

OK, a lot to go over, but done right, you will be "set straight" [I hope!]:

On Sun, Jan 21, 2018 at 5:39 PM, Dawson Rosell <rose...@d.umn.edu> wrote:

​OK, very bad form to use shortcuts when explaining exactly what you're doing, lose the forest for the trees, etc.

Yes, my bad. I'll try to be more clear.

​Good, the first step to enlightenment is the admission of ignorance :-).​

To sum up how I am doing everything: I toggle in RIM,

​Ugh!  Hopefully what is  below will eventually put an end to that!

Total aside, the RIM loader is NOT the shortest loader; it's the shortest GENERAL-PURPOSE loader, but there is a shorter toggled-in loader called the "Help Loader".  You load in a limited modification data tape in Help format.  It generally makes the contents of 07600-07777 into whatever you want it to be.  That can be as much as the P?S/8 device-dependent bootstrap, the P?S/8 modified version of the BIN loader and your choice of the two standard RIM loaders, all at once.

[Note:  The P?S/8 modifications include:

1)  Much tighter code so it fits with the other two.

2) Removal of the feature of the BIN loader that has to read the switch register to determine low speed versus high speed.  In P?S/8, since you are already starting from an operating system, that choice is inherently already made; thus, both the BIN and RIM loader are chosen even before you type in the command [command-line options].

Apparently you don't even have a high-speed reader, so the choice for you is moot.  Thus, the ideal thing would be a boot starting at 07600 [depending on the device, it may be more universal than just P?S/8, but each configuration has its own destiny on that part/  Then the low-speed only BIN [which doesn't care about the switch register or even if you even have a switch register; some DEC machines did NOT have a front panel!] and the matching RIM, etc.

The HELP loader itself is about 4 words shorter than RIM.  It's a standard DEC product from way, way back.  I have the real source code that actually explains how it works.  It is diabolical and genius.  The DEC source code just includes the body of the thing in octal words.  I invented source code that explains what it is really doing. [Note: When the HELP loader was written, all there was to assemble with was PAL III.  It's too feeble to express what I have to do symbolically, which are assembled words bit-shifted and extracted; it would not be until PAL10 and then P?S/8 PAL and then PAL8 that there was a utility to express my source code, etc.]

Anyway, digression nearly over; anyone seriously repetitively toggling something in should clearly use the HELP loader.  [but read below to end run around the entire problem].

 

start the disk server with Mike_PDP-12.rk05 attached.

​I assume this is the image that has all that Mike and I discussed; he can confirm this, etc.

​

I send the bootloader.rim from the TTY program. (MTTTY in this case. I tried to get minicom to work, but didn't have time to finish before the Fall semester took off). Once the bootloader is sent, I stop RIM, I/O PRESET, and START 20. MTTTY shows the prompt and I am running OS/8. If I change disks I hit STOP on the PDP-12 and then I stop the disk server. I attach a new .rk05 image, and then set the Left Switches to 7605, I/O PRESET, and START LS. I am then back at the prompt for the new disk. Should I be resending the bootloader each time as it is a different disk image its booting from? Thats something that I didn't consider until as of now.

​Not good at all.

What you should be doing is taking advantage of a boot program because what you are doing is a complete system restart; things might only work by coincidence, and they may not.

The OS/8 Boot program is decent [not unique, but it is a feature of OS/8 to have a standard one;but it is not suitable for the SeriakDisk.  That said, Mike modified it so it does that.

I believe the two letter code in Boot program parlance is SD.  Let Mike correct me if I am wrong.  So, assuming I am correct:

At the prompt type

BOOT/SD.

Again, the SD is my guess.  I think for PDP-12 LINCtapes it is LT.

The trailing . means to halt before doing it, so you can change the diskserver end and then just press Continue.

​

When compiling Fortran programs on the disk server using Mike_PDP-12.rk05 as the booted image, I run R F4 and then TRIAL2.FT/G$ (the escape key). I type out by hand the exact same program and read it into the PTR on Simh using the disk disk2.fortran.rk05. It read in fine and compiled and worked perfectly.

​There is no point to doing that.  It's already an OS/8 text file[s].  In SIMH you need a REAL RK8E bootable image, not serialdisk with this unfortunate parlance that just confuses:

The .RK05 is an IMAGE format used in SIMH to mean an image of an RK05.  The diskserver PROGRAM uses image files that are the same overall format, but NOT compatible.  But because SIMH supports all four drives, you can mount that disk image on one of the other drives.  Presumably that would mean for instance that the real RK8E RKA0: and RKB0: would  be the real image and your stuff would for instance be references as RKA1: and RKB1: while on that booted up SIMH OS/8 system.  What you were trying to do is impossible.  [I hope you now know why.]

So, when you are doing it correctly, the file is already there.  And if you make changes, they are permanent and will be reflected when you use the image again with the diskserver program back at the PDP-12, etc.

​

 

I do the exact same thing with the PDP-12 and it reads it in, but when I display it it only shows the first few lines and then some random characters. The process for reading in the file, or the file, did not change between the two. All that changed was what .rk05 image I was using at that moment (as I haven't gotten the PDP-12 to boot disk2.fortran.rk05, or simh to boot Mike_PDP-12.rk05)

​So, there are multiple opportunities to determine what you specifically did wrong while doing it the long way around.  I have no clue as to what exactly is being done, but it sounds like something is dropping characters.  Again, totally unnecessary.  You must solve the SIMH problem to boot another image in the first place.  We can get you an appropriate real image in e-mail, etc.

​

1)  You have OS/8 booted to LINCtapes, correct.

I have the original LINCtapes with all the old files still on them (all backed up thanks to Warrens program).

​I already don't trust the specifics of this.  I do know from what little I heard that that was an effort to backup DIAL-type LINCtapes which are totally unsuitable for OS/8 stuff.  They would have to be formatted [see below however].​

 

I have 4 blank tapes for testing and things like this. I have not been using the TU55 for anything related to OS/8 though. I have been booting OS/8 from a .rk05 image using Kyle's diskserver program. Would it be more reliable to be using a tape?

​If the one drive is reliable, god damn yes!

​

How would I create a new tape, then that can be booted, on one of the blank tapes I have? I can transfer files I need over from the disk server to the tape.

​The first problem you have to solve is getting them formatted NOT in DIAL format, meaning NOT 256 words/block [and thus less overall longer blocks].  The DIAL format is in "standard" format which just means the ONLY format the original LINC can handle  The LINC-8 and PDP-12 are not limited to that.  Also, as an aside, DIAL tapes are longer than the old standard [because those were only 150 foot long tapes.  With the 260 ft you get a lot more.

Now back to the logistic problem.

DIAL is unfortunately the usual place tapes are formatted.  It is unfortunate because DIAL programmers got bum steers as to what PDP-8 formatted tapes should be out of a combination of conventional wisdom and ignorance synergistically getting things screwed up.​

Here is the base problem:

ALL software on the PDP-8 WITH THE EXCEPTION of the 4K Disk Monitor System uses 128 12-bit word LOGICAL blocks.  OS/8 uses them in pairs, but ONLY the Disk Monitor System has the need for the 129th word, which on DECtape is otherwise a nuisance, but required on DECtape hardware for compatibility with the PDP-9/15 and PDP-10 [and even PDP-11].  In essence, PDP-8 DECtape is the "other" and all the rest agree with each other.  Because it has to be a multiple of 18-bit words, that means that in 12-bit word terms, it has to be 129 words.  The Disk Monitor People took advantage of the 129th word to their demise; no newer hardware supports 129 words while everything else does 128 word multiples.  And the only other two devices the Disk Monitor System can run is on the RF08 and DF32 because they do not actually have any block structure intrinsically.  They are WORD-transfer disks [but are fast].

There are NO APPLICATIONS WHATSOEVER on the PDP-12 that can take advantage of the 129th word.  It gets in the way.  the CORRECT format is 128 words, so that the logical size and the physical size are identical.

That said, P?S/8 and OS/8 device handlers can TOLERATE the presence of the 129th word, but would prefer it not be there.  In the case of OS/8, it creates a theoretical weak spot.  If you stop the machine at the perfectly wrong time [a couple of milliseconds window] you can destroy the system device handler!

When the LINCtapes have 129 words instead of 128 words, they run slightly SLOWER and are slightly less capable of being EXTENDED to extra length.

In OS/8, the definition of the length of the tape is determined as a total kludge inside of the core image PIP.SV [yes, it is inside of PIP and this comes into play when you use the PIP /Z ZERO command that then just uses the value present.  [This is an idiotic kludge! But that's all they ever did.  To make matters worse, the DEFAULT setting is to make LINCtapes no longer than DECtapes' standard value.  The disconnect here is that even if the tapes ARE 129 words long, they are ALWAYS capable of much longer, typically 3300 or 3400 or even as much as 4000 blocks]  All you have to do is experiment with what works and then custom patch the one word, even if temporarily and create a proper empty directory that accounts for all the actual blocks.

Many savvy OS/8 PDP-12 users did not accept the silly number based on 2702 blocks.  [the OS/8 DIR command would show 730 decimal free records [erroneously called "blocks" to confuse everyone even more.  the CORRECT term is RECORDS. BLOCKS may mean DECtape blocks or LINCtape blocks and there are always twice as many, etc.]  So, it is not uncommon to see far longer tapes, and this is very important so you can put more programs and files on the LINCtapes!

Now, to bring all of this back to relevance.  Unfortunately there are no standard FORMATTING programs for OS/8 LINCtapes.  You have to use DIAL and select their P oriented options.  As I stated above, bad info, etc.  The only choice is to make 129 words [or 256 words].  so, you get the TOLERATED format not the PREFERRED format.  But you have to start somewhere.

As a separate topic, my recent trip to RICM was to try to recover some early P?S/8 tapes that have the CORRECTIONS applied to the program that was once in DIAL with all the values correct AND you can type in the tape length.

I did not write that program [certainly none of us wrote the base DIAL program, but my friends mostly cobbled up the appropriate changes, not me].  Then I adapted it to run under P?S/8 using techniques that are compatible with OS/8.  [It runs in 4K and destroys 07600-07777 while running, so you have to manually boot when done.  OS/8 has the same problem in field 0, etc.  So Recovey of this program will be useful to OS/8 as well, etc.]

Because of many reasons i won't go into, a growing pain of P?S/8 is that it needs OS/8 to assemble the programs so I can put it together into a running system.  [In the future, i will wean myself 100% of OS/8].

To accomplish this, a user-written program called PAL12 was used.  Unfortunately, some presumptive naive people ASSUMED a newer version was necessarily better;  It IS NOT!

Fortunately, we located a proper copy on a tape we were able to read, so when I get to it, I can use the correct PAL12 in OS/8 to TRY to assemble the proper formatting program for use with OS/8 and P?S/8.

But I am not certain the source files for the formatter [and the companion TC12F program] are the accurate source code.  one of the other reasons for my recent trip to RICM was to get copies of very old P?S/8 for TC12 LINCtapes because on these tapes are the binary image of the proper code in question.

Thus, with some work, I can put together the proper source code and use the intended assembly program PAL12 pre-V5.  V5 is newer and DOES NOT WORK.  Yes, you can assemble SOME dual-assembly code.  It gets HUNDREDS of errors with these source files!  As I said, fools ASSUMED it was better.  The fallacy is that both are based on versions of PAL8.  The one that works has an inferior PAL8 base [irrelevant because the features present or not aren't used in the source code.].  That V5 is a better PDP-8 assembler is an irrelevance.  It mis-assembles LINC code, it's primary mission.

So, when I get to this project, I have my work cut out for me.  When i get that far, then I can distribute MARK12 for OS/8 ANd MARK12 for P?S/8 both based on these lost core-image binaries on the old P?S/8 tapes, etc.

So, for now, you have to use the inferior DIAL version and settle for inherently shorter slightly slower tapes, but it will work.  From your point of view, this is going to  be only about a 15-20% improvement, so  not so bad for now, etc.

So, go format you tapes with the stock DIAL MARK12 program, and select the 129 word PDP-8 type FORMAT, etc.  [Note:  As I remember it, a real limitation of the original is you cannot even specify the blocks created, so are stuck with the shorter tapes that are no longer than DECtapes.  And more to the point, this is FAR better than what you do now!

Once you have that, the system on the serialdisk has to have added at least one non-system LINCtape handler, and the reboot and now it supports LINCtapes.  Once formatted you should be able to read and write them [and ZERO the directory with PIP to the stock length without patching.]  Note:  It is not uncommon to have many BUILD and PIP variant image files, each only different on what is discussed here, etc.]

Adding the System device handler for TC12 you can create LINCtapes right on your machine and it will boot to it immediately.

Then copy on to the LINCtape the Mike-modified BOOT program at least, etc.

Booting LINCtapes is as simple as this:

1) Set LMODE

2) I/O PRESET.

3) Set the switches to 0700 left and 0000 right.

4) Press DO

5) Press START20.

A lot easier than a RIM loader!

And of course, the LINCtape BUILD should include some serialdisk non-system handlers  Everything can talk to everything, etc.

2)  On that system you added non-system serialdisk handlers

I'll be honest, I'm not sure if I did or not. I haven't been able to work on this for quite a few months and I don't remember what Warren vs what I did when things got set up.

Alternatively, you in fact are booting the serial disk program and you do need a bootable serialdisk handler-based system  Pick one! :-)

So, if I'm following correctly, I can do this one of two ways? I can either be running from a LINCtape, or I can be running from serial disk?

​Yes, and it is inherently more reliable from LINCtape.  You can get screwed up with serialdisk, but you can restart both ends and a trivial bootup.

​

OK, all that said, the serial disk handlers should be the correct choice from the ones I wrote; I am the author of the latest system and nonsystem serialdisk handler.  These are the only ones that run on the PDP-12 and are used at RICM

Where can I acquire a copy of these to make sure I am using the right ones? The same for Bob Adamson's server program?

​Ask Mike.
​

Do you even have functioning LINCtapes there?

Yes, we do... sort of... The top drive works great, and the bottom one is flaky. The bottom one has problems with the Brake Enable on the right hub. Checking the R111 in B06 has been on my to do list for a while. Might do that if I can't get anything else working here...But the top drive has been working fine.

​Good, then all of the above applies! :-)​

Forgive the many questions, I'll eventually get the hang of all of this. (it'd be easier if I had a PDP-8 of my own at home to play with haha, but across the street is as good it will get for now. ;) )

​OK.  These days, all I have is the enhanced SIMH I will be releasing.  It is FAR better than the "bare" one you use now. It requires Windows XP or newer.

​

Thanks everyone for the help and quick responses!

Dawson

​cjl

[Michael Thompson]

Charles,

The RK05 image that Dawson is using has the serialdisk system and non-system handlers installed. It can be booted using a serialdisk boot program. It was tested on both the RICM and the UMD PDP-12 systems, and seems to work just fine.

The problem that Dawson has been having is likely with the FORTRAN tools, not the OS/8 operating system.

Last week I found in my notes that the example commands in the OS/8 languages don't work on the PDP-12 booting from serialdisk, and RK05, or on my 8/e booting from an RK05. The program seems to compile and run, but there is no output. if you hit the ESC key, the program will run. I have seen other example commands that show a "$" at the end of the command. The "$" should not be entered as part of the command. The "$" is output from OS/8 when you enter the ESC key.

It is possible that all of these disk images have some problem. If so, how do we fix it?

--

Michael Thompson

[Dawson Rosell]

I'm going through the steps you gave about booting OS/8 LINCtape, Charles. I got a tape formatted to 129 blocks. It took a while as the mark12 program was being difficult. One time it said the tape failed, the other time it shoe shined the tape and then the third time it worked. 

I figure I'll try and get a tape set up for it anyway so we can use that in the future for things. 

But, yes, I wonder if it's a problem with he Fortran tools them selves. 

I hit the escape key in place of the Dollar sign and it seems to make no difference. 

Am I correct in thinking that making an OS/8 LINCtape with all the Fortran tools on it and the code would (most likely) compile and run? That this eliminates problems with the serial disk images I'm using?

[Maury Pepper]

Regarding marking tapes ... before marking a tape that had been previously marked, we always degaussed it in order to totally erase the prior markings. If you didn't degauss first, it's not surprising it took multiple tries to get the tape marked. I would suggest getting or building a simple degausser and starting over.

[CLASystems]

On Mon, Jan 22, 2018 at 10:23 AM, Dawson Rosell <rose...@d.umn.edu> wrote:

I'm going through the steps you gave about booting OS/8 LINCtape, Charles. I got a tape formatted to 129 blocks. It took a while as the mark12 program was being difficult. One time it said the tape failed, the other time it shoe shined the tape and then the third time it worked. 

​Sounds like something is marginal [not surprised].  There is a whole litanny of potential issues, but we'll assume for now you have something to work with.  The use of it and it working will instill confidence on all our parts, etc.

One of the problems with the PDP-12 is that it is the least prepared to deal with problems because  it is too automatic, and OS/8 is the system least caring about errors, a rather deadly combination when there really are problems.

​

I figure I'll try and get a tape set up for it anyway so we can use that in the future for things. 

​Yes, as I refer to above.​

But, yes, I wonder if it's a problem with he Fortran tools them selves. 

​Mike says there is, and once you get to this level, we are all on the same "plane"  as all I have is SIMH.

​

I hit the escape key in place of the Dollar sign and it seems to make no difference. 

​There is no dollar, that is a documentation character to MEAN you pressed escape.

​

Am I correct in thinking that making an OS/8 LINCtape with all the Fortran tools on it and the code would (most likely) compile and run? That this eliminates problems with the serial disk images I'm using?

​Exactly.

And as I said before, saves you booting grief.

cjl​

[CLASystems]

On Mon, Jan 22, 2018 at 11:11 AM, Maury Pepper <mpe...@ieee.org> wrote:

Regarding marking tapes ... before marking a tape that had been previously marked, we always degaussed it in order to totally erase the prior markings. If you didn't degauss first, it's not surprising it took multiple tries to get the tape marked. I would suggest getting or building a simple degausser and starting over.

​That is never a bad idea, can't hurt.  I would do it with some wire coiled up and connected to a transformer.

cjl​

[Dawson Rosell]

Perfect. I'll work on making a bootable OS/8 LINCtape. I have the tape formated now and I'm reading up on BUILD and the related commands. I hope to have a bootable tape in the next few days (class and work allowing).

Maury, thanks for the degaussing suggestion. We have one at work I could probably use.

[Kyle Owen]

Peter just added me to the group (thanks, Peter!). 

I wrote DISINT.PA to disable interrupts for SerialDisk. I just get in a habit of running it before I run FRTS, otherwise it'll just hang. I suspect that might be your issue, assuming I'm caught up to speed on this matter. The proper fix would be to disable interrupts in the system handler, but I seem to recall not having room for that.

Attached is a SerialDisk image that you can try FRTS with, by running DISINT first. "LOAD DISINT /G" should do the trick.

Thanks,

Kyle

[CLASystems]

On Tue, Jan 30, 2018 at 1:31 PM, Kyle Owen <kyle...@gmail.com> wrote:

Peter just added me to the group (thanks, Peter!). 

​Good!  Hi Kyle!  I hope you now have some time to deal with 12-bit issues again.  I'll followup in separate e-mail, etc.
​

I wrote DISINT.PA to disable interrupts for SerialDisk. I just get in a habit of running it before I run FRTS, otherwise it'll just hang. I suspect that might be your issue, assuming I'm caught up to speed on this matter. The proper fix would be to disable interrupts in the system handler, but I seem to recall not having room for that.

​Unfortunately, you are just enough out of the loop [ironically] that I have to bring *YOU* up to speed!


1) Bob Adamson has done a lot of work on your server, but says there is [I think in the source code] a laundry list about things that are of concern to him.  I would appreciate if you check out what he did, etc.  [I want to talk to you about unrelated changes as well]

2) Bob made a stab at an attempt [that didn't quite work] to deal with the interrupt problem.  His code did what your little pre-execution patch does.  The problem is two-fold:

a) Between what he did and then I did, it DOES fit into the handler, so your patch program is obsolete.

b) Bob was attempting to eliminate dependencies on 8/E and up instructions.  In the process of a partial attempt to do so, he added a step backwards [which I fixed].

The problem has to do with the way IOT instructions are decoded on older machines UNLESS you go out of your way to get PART OF THE WAY to what is easy on the Omnibus.

The 6405 instruction on for example the PDP-12 does NOT mean to interrupt enable per AC[11] as on the 8/E.  Rather this is what it does.

First it skips on the flag.

Then it .OR. into the AC the input buffer in the interface.

So, you not only don't get any improvement, the program logic is totally at risk b y data values nearly at random.

What I did was revamp the code to EXPECT the AC might be hosed, and eventually by clever placement of code and constants clear the AC so the rest of the logic works as intended.  This is why at all their PDP-12 and the RICM PDP-12 are both working.  I debugged it with Michael Thompson months ago until I stumbled upon what is wrong.  The present release fixes that problem.

Thus, the latest handle supports Bob's changes so it supports eight entry points for four logical RK05 drives worth of OS/8 half-drive handlers, etc. which doubles what you started with.

And FRTS aside, it now runs on all models from the "straight" -8 on up.

BUT, the interrupt-disable cannot be done on any of these machines, so all attempts are useless.

I assume this PDP-12 is the same hardware as the RICM one; the second serial port is built into the backplane of the PDP-12, thus, the instruction set reduces to essentially the same as the 03/04 console except for device code, etc.

I'm sure Michael is reading this [he usually does!] and can send you the latest files [mine for the handler, Bob's for the server]. But any practical improvement has to deal with the fact that these machines are NOT 8/E-based.

I don't know enough about the FRTS to decide how best to get around this, but the point is that on the older machines, interrupts are always enabled and you cannot depend on things such as raised flags or flags known to be in the process of raising if there is also a general interrupt handler at work.  There has to be some better communications.

What I would do is attack it in the FRTS and have some internal table which decides that based on patches, don't dare call particular handlers unless you do IOF first.  That way, it would know it has to do ION on the return from the call.

Because this is again pre-Omnibus, the handler has no way to re-enable interrupts.  I could make it do a general IOF and just leave it off, but I cannot know to do an ION on the way back to the caller.

[Note:  P?S/8 does that for the TD8E handler.  The difference is that the TD8E is ALWAYS on Omnibus hardware so I do SKON and manufacture an exit instruction that becomes either IOF or ION depending; SKON turns interrupts off, etc.  But that cannot apply here.]

So, this seems to not be fixable without some patches in FRTS.  Any ideas?

However, I think some of the problems are totally unrelated; Mike I believe can reproduce the errors on his 8/E, etc.  But clearly, this is as far as we got regarding where we are on your program's descendants.

cjl

​

Attached is a SerialDisk image that you can try FRTS with, by running DISINT first. "LOAD DISINT /G" should do the trick.

​Only on an 8/E where it is now redundant to the new handlers.

​

Thanks,

Kyle

--

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

Bill Gates, 1992

Virus-free. www.avast.com

[Kyle Owen]

Thanks Charlie! Yes, I'd like to get caught up on other things; I may have some time to discuss next week when I'm in Seattle and Portland visiting with Jack, Vince, et al. 

Is anyone willing to take on the task of getting the SerialDisk GitHub repository up-to-date? If not, I may be able to work on that some next week as well.

While I admire having *one* system handler to rule them all, it seems as though there are enough functional differences between systems to warrant making some system-specific changes via macros or such. Thoughts?

Kyle

[CLASystems]

On Tue, Jan 30, 2018 at 7:38 PM, Kyle Owen <kyle...@gmail.com> wrote:

Thanks Charlie! Yes, I'd like to get caught up on other things; I may have some time to discuss next week when I'm in Seattle and Portland visiting with Jack, Vince, et al. 

​OK;  Feel free to e-mail when that time is "real".  I can adjust what I am doing; I am busier than ever but I can change the order of what I do when because now my time is my own;  I know you have to report to various "masters" etc.

​

Is anyone willing to take on the task of getting the SerialDisk GitHub repository up-to-date? If not, I may be able to work on that some next week as well.

​That is a world alien to me and I want no part of it.  That said, I can place anything deemed important enough on ibiblio.org in the usual place.​

While I admire having *one* system handler to rule them all, it seems as though there are enough functional differences between systems to warrant making some system-specific changes via macros or such. Thoughts?

​Nope, I don't see that as a problem at all.  This is just one of those problems you cannot do anything but fact the fact that OS/8 is hopelessly flawed and the only way is to do what we have always done:

Interrupt-driven programs are responsible for providing various "outs" so they can interface with the reality of a non-interrupt system that runs things.  Many of the things I have done over the years are totally unsuitable for OS/8 and also P?S/8; as such, they are stand-alone bootable environments.  But for any O/S, just fully understand the need for the customizable, etc.  Thus, if someone wants to start fixing FRTS, I can advise, but what long-term effect it has on any of my goals has to be put where it belongs, behind many dozens of things more important.

You can't "paper" this over with ornate mechanisms you've heard of.  I've written enough handlers in both systems to know what is the problem and where it is.

You came here with the premise that you couldn't fit that needed code in so you ran it separately in the easier environment of the Omnibus where you can on a one-off device disable interrupts.  I added the code so that it does exactly what you did in the space provided and the far more difficult problem of not screwing up when the hardware is an earlier machine.   [But also it cannot help because of the hardware reality.]  The handler already solves this as best as possible.  The future is to fix what is broken, which clearly is NOT any aspect of the device handlers.

The ONLY small point to add would be a global parameter to put back using the 8/E and up-specific instructions.  That's one global parameter within the handler.  Macros, nope.  You've been over-exposed to too much irrelevant overhead used on other machines!

I can trivially do that but it won't solve any of the current problems.  But it has its selling point in the realm of OTHER users only:

a) Want it to run as fast as possible.  Virtually meaningless to most users who do not have the USB version.  By far, the lack of speed of the serial interface is the main problem, but for those with the USB Omnibus board, since they are constrained to be an 8/E and up anyway, then their version can get that extra few percent speed.  That would be to use the BSW instructions that are for now removed but can come back conditionally.

b) The band-aid that cannot help:  Use the 6405 instruction as I have already done.  It is low overhead and does work if on an 8/E, innocuous on the other machines the way I did it.  Thus, this is a non-change.

Thus, it reduces down to a speed versus dependency minor option.

So I can easily add something like

IFNDEF SPEED <SPEED=0>

and where relevant

IFZERO SPEED <what we have now, three double rotate instructions in several places>

IFNZRO SPEED <BSW> etc.

I doubt if anything else can be posited that matters.

In any case, please learn an important point here:

All of us have limited time and commitments to other things.  Learn to work with others who may have better skills than you do for certain parts of a problem best solved in a cooperative manner.  Your approach is too "lone wolf" in a sense as it applies here.  That way your limited time is used only where really needed and everyone benefits.

It's a totally hind-sight argument, but no one ever asked me about this project while you were defining it.  Thus, you were "reinventing wheels" so to speak.  Apparently no one ever told you about the Inter-Processor Buffer project I did years ago for two straight-8 machines that has the very same hardware reality being they are for negative buss.  You can't make FRTS work on that either for the same reasons.  The point is we would not be having this conversation here and now.

Moreover, I don't expect you to fix FRTS at all either.  I will work on that with others when they have the time as I mostly advise.  My extensive experience with FOCAL will come in handy, just to show another example of a program that needed help with interrupt-related matters.  And that is but a tiny speck on the list of interrupt-driven things I have done over the years, so a little of my time and a lot of someone else's time will get that part solved with some semi-ugly kludge, but that's the fault of my friends who wrote all this mediocre code.  They too were too close to the problem and used to the PDP-8/E and loathe to even discuss problems caused by  their total lack of familiarity with the quirks of the older machines.


Back in the day, I had a major problem with them actually not believing me with a repeatable problem:.  PAL8 ALWAYS fails to work on a PDP-8/L.  [Their ridiculous responses I won't dignify repeating, but the short version is they ASSUMED that the 8/L was the same as the PDP-12 they were using!]  Eventually they got some other analogous complaints and realized that they had to go back and rethink what the problems are.  The ultimate fix was a rewrite of the memory sizing routine used throughout OS/8 to solve several problems including another one unique to the straight-8.

[The quick answer is:  ALWAYS reset to field 0 before testing the potential of another field.  And you have to do it in a VERY CAREFUL way to avoid a problem unique to the straight-8 and LINC-8; and also be prepared for different wrong answers in the 8K 8/L versus the 4K 8/L versus the 12K 8/L versus the "blown-up" 8/L that uses another box and 8/E core stacks, etc.  Fortunately, it isn't important that they are differently wrong, what matters is that they all ARE wrong, etc.]

Unfortunately, for the most part they were at best badly reactive to problems because they forgot the "family of 8" rules they started out on and instead just used Omnibus rules.  It didn't help then that management seized on this to drop support and force people into new hardware as their new "business model" etc.  I and others have fixed some of these problems such as making the RK8E formatting program run on all machines again and remove the code some bozo added that actually hangs the machine on the earliest models and hangs the program on the rest, but they were easy to fix.  Over the years I have worked on many of these with others, so I am confident I can find someone who is motivated to fix this one, etc.



Now what you are needed for is to review what Bob Adamson did to the server program, "beat it up" so to speak and then revamp it if you deem it not quite right, or just embrace it.  That's not my field and I yield completely to you and Bob, etc.  But I have my own short list of things I want to see added for a variety of reasons, and the best time to discuss them is when you are reviewing what the current state of the server is, etc.  Hopefully we will have spoken by then.

cjl​

Kyle

--

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

Bill Gates, 1992

Virus-free. www.avast.com

[Dawson Rosell]

Thanks for all the good info everyone. I will update as soon as I've had time to go up to the lab and try some things. Homework and internship application have been my focus this week.

Kyle, I'll definitely see if DISINT.PA works for me and report back. Thanks again!

[CLASystems]

On Wed, Jan 31, 2018 at 9:47 PM, Dawson Rosell <rose...@d.umn.edu> wrote:

Thanks for all the good info everyone. I will update as soon as I've had time to go up to the lab and try some things. Homework and internship application have been my focus this week.

Kyle, I'll definitely see if DISINT.PA works for me and report back. Thanks again!

​This is 100% GUARANTEED TO NOT WORK!

You do not understand the problem..

I will summarized for you:

1)  Michael Thompson apparently can reproduce what problem you are having on a PDP-8/E.

2) This is a patch that is only useful on the PDP-8/E to prevent a problem that is a valid limitation and well-known.

It would be nice to fix this problem on the PDP-8/E.  Kyle's original code wasn't capable of solving it directly, thus the patch described [arbitrarily as DISINT in an external program] CAN be useful to eliminate this theoretical problem, but only on an 8/E.

3) You should already be running my latest version of the OS/8 handler which is compatible with the latest version of the server from Bob Adamson.
Bob wrote the original attempt at adding in what DISINT.PA does.  But it is defective as HE wrote it.  The bug is that on earlier machines such as the PDP-12 it ruins the logic when it used on other than PDP-8/E and newer.
4) I fixed the problem so that when it is used on the PDP-12 and older, it is INNOCUOUS instead of harmful..
5) The problem cannot be fixed due to hardware limitations of the serial interface on machines earlier than the PDP-8/E.  This is a very old problem that wasn't addressed until; the PDP-8 came out.  Because of the underlying use of serial interfaces, it is not fixable per se on all older machines.
6) The only way to actually fix this problem rests within rewriting part of the FRTS runtime system of Fortran itself.  It is a valid major criticism in general because interrupt-driven programming on the PDP-8 must be done with great care; it was done quite sloppily in FRTS because they did not fix the problem.  Instead they copped out and declared all machines prior to the PDP-8/E obsolete.  They even invented the term "no support for pre-Omnibus machines" thus preventing getting it fixed OFFICIALLY.

All that said, there are quite a few problems that have been fixed in general.  At least four of them have been found personally by me.  In general, they are ignorant add-ons done by then-newbies which only made the problem worse.  This was 100% caused by BAD management.  There really is NO EXCUSE for FRTS not having a documented method around this problem.  It is not in my to-do list to spend time fixing it; Fortran is just "not my thing".  I have too many current commitments ​[including several that affect your operation collectively with others that also benefit] so I cannot suddenly make this problem a priority for me.

That said, I may be able to recruit others to deal with it and could play an advisory role to point out the particulars, etc.  But I cannot speak for others.  Interrupt-driven PDP-8 programming is a specialty and there are literally dozens of different ways to do it [not a matter of right or wrong; it's essentially relatively speaking an "art form"  anyone who doesn't realize this automatically is disqualified for not knowing so.]

When Michael Thompson confirms that in fact this isn't the problem at all you are having, this entire discussion can be tabled.  Moreover, you remember that I pointed out you should instead work on getting OS/8 to work on LINCtape.  Once you are there, this entire problem is avoidable by you, as the serialdisk handler is then not a requirement at all.  Moreover you should find that LINCtape is faster; that has to be tested because the performance trade-offs are different.  But the removal of this as a consideration is clear!

I understand this is all confusing to you, so I hope I have straightened you out on it, etc.

My long-term goal is to 100% eliminate OS/8 entirely and "lift" all of its applications.  Once I get miles in front of me done, that first appears on my personal horizon.  Hopefully,by then, this problem will have already been solved by a partial rewrite of FRTS and not by me.  If at that late future date, no one else has, then it will be a higher priority for me; at this point, I have too many other commitments that benefit a wider audience [some aspects affect you in a different sense].

In any case, by avoiding "non-standard" things such as the serialdisk handler, OS/8 FRTS will work fine  It just so happens that this is a sore point of the PDP-8 design, and was fixed in the 8/E, but not in earlier machines.  All other handlers do not have an analogous problem, most especially using LINCtape.

I hope that helps.  If you still have questions, don't hesitate to raise them now.  All that said, I would like Michael to chime in on your original problem in light of recent conversations, etc.

cjl

[Dawson Rosell]

Thanks Charles!

That helps a lot. I see now why Kyle's program wouldn't work on the PDP-12.

You should already be running my latest version of the OS/8 handler which is compatible with the latest version of the server from Bob Adamson

 

 Where should I look to find copies of these? If they were sent to me on an earlier email I must have missed them...

Moreover, you remember that I pointed out you should instead work on getting OS/8 to work on LINCtape

I worked a bit on this last week. I got a tape marked. I then used BUILD on the Serial Disk program I have been using (using Mike_PDP-12.rk05 as the attached image). I used BUILD (RUN SYS BUILD) to load the LINCtape system handlers from disk (I used the diagpack2 disk). I then ran INSERT LINC,SYS,LTA0, changed DSK to LINC:SYS and ran BO. After that finished I ran SAVE SYS BUILD.

I know I didn't do this 100% correct. I can boot from the tape (following the instructions to boot from LINCtape, DO 0700... etc.), the tape spins and then I get a prompt on the terminal. It accepts my input but crashes when I try to run a command. For example, running DIR (or RUN DIRECT and other variations) the tape will spin and search for DIRECT, but it will crash when it can't find it... So I assume that the tape is blank besides boot information. How do I go about getting the needed programs and files on there? Is using PIP all I have to do? Or did I miss a step somewhere?

I understand this is all confusing to you, so I hope I have straightened you out on it, etc.

Yes, this is a little confusing, but slowly things are starting to make more sense. Thank you for being willing to explain things :)

Dawson

[CLASystems]

On Thu, Feb 1, 2018 at 11:02 AM, Dawson Rosell <rose...@d.umn.edu> wrote:

Thanks Charles!

That helps a lot. I see now why Kyle's program wouldn't work on the PDP-12.

​Correct; it's basically obsolete; ironic when you have to tell the original author he's been out of the loop just a bit too long; fortunately, Kyle is if nothing else a quick study :-).

​

You should already be running my latest version of the OS/8 handler which is compatible with the latest version of the server from Bob Adamson

 

 Where should I look to find copies of these? If they were sent to me on an earlier email I must have missed them...

​Michael Thompson must have sent them to you likely in an image file [.rko5] on the 12-bit side, I suspect a link to something along the lines of github for the rest of it, if not from his own system; ask him.

What I can say is they are a pair; I never run them.

I purchased the cables for USB serial ports so that I can do two things:

1) Put up SIMH on two adjacent PCs and run my Kermit-12 between them.

2) Run the server on one and put the handler into SIMH on the other.​

I am backed up to the point I can't get to that project, but it is in the "top ten" etc.

Once I have that in place, I will even have a foot in the door so to speak to even start to care about the server.

Remember, I have no hardware setup here at all, just simulators!  And the simulator does simulate a PDP-8/E so it won't have the problem when I get there, etc.

Moreover, you remember that I pointed out you should instead work on getting OS/8 to work on LINCtape

I worked a bit on this last week. I got a tape marked. I then used BUILD on the Serial Disk program I have been using (using Mike_PDP-12.rk05 as the attached image). I used BUILD (RUN SYS BUILD) to load the LINCtape system handlers from disk (I used the diagpack2 disk). I then ran INSERT LINC,SYS,LTA0, changed DSK to LINC:SYS and ran BO. After that finished I ran SAVE SYS BUILD.

​Saving it from a run command is in my experience not 100% reliable; you don't want to be the one where it fails!

the fully reliable way is

.GET device BUILD
make the changes and exit.
.SAVE device BUILD or another name reminiscent of "BUILD".

Then with nothing to worry about

r or run that new up to date image

.BO

This separates the functionality from the prep to guarantee it is repeatable.

It's a bit complicated to explain, but what you did depends on it not failing or else the updated image may not be accurate, so why not avoid risk?

Moreover, you can have multiple copies set with handlers and the boot device for every variant you might need, and can then deploy them quickly as necessary.

As you use OS/8 you will start to feel the "crowding" effect where the seemingly vast 15 devices starts looking [properly puny].

Depending on what you are doing, you might need more than one LINCtape handler even if you have to fake it with putting a drive off-line and changing tapes [it will wait], and then there is the issue of just how many serial disk handlers you want.  Presently there are EIGHT handlers one for each half-a-disk image.  If you were to need RKA3: that's not RKB3:, etc.

Then there is the further problem:

DSK is not a handler slot, it is a stand-in for whatever you assign it into to make commands have a default so you don't have to explicitly type said device.,  Thus, in reality it is only 14 actual distincy handlers, max.

If you use the KL8E handler, that gets you the console and is recommended.  it does not require the new hardware as the name suggests, it is do distinguish it from the older inferior handlers that are still supported.

If you should need paper-tape read or write, that's two more handlers either low-speed or high-speed.

And if you ever got a lineprinter [which could be attached to the serial port when that is NOT in serialdisk use] that's yet another one.  [That would require using the internal parameters to be changed in the KL8E.PA source file.  I used that one a lot myself to change it to serially talk to device 40/41 not for serial disk and not for Kermit [which occasionally I used it for back in the day] but also to talk to a terminal equivalent to the LA-180 [digression:  the head of the LA36 project quit DEC and made his own far cheaper equivalent as a speed-up board; either way, you MUST use an interface that supports the Control-S/Control-Q protocol or else you have to run at a mighty 300 baud.​

There are a few others in theory, but the main point is suddenly there is no "one size fits all" scenario.

On one of my systems I had a hard disk that was about thirty-odd devices each the largest OS/8 can handle.  [And also several actual RK05s.  Note that each half-a-RK05 is only about 2/3 the max size OS/8 can handle.  This disk lent itself to the larger size so each of them was about 160% of the half-RK05.  I think you can see how I tended to have at least EIGHT copies of similar yet different BUILD equivalent images.

You often have to boot from one to the other, and in some cases it might be by a boot command directly, but mostly the BO command of BUILD because you are not moving to a different device, rather to a different configuration [of handlers] on the same device, etc.

I hope you understand this.  It's one of the [many] sore points which add up to my clear justification for eliminating OS/8 to become either something on the shelf, or just a bad habit.  Since I am "retired" now, I have the time to actually get there instead of "merely" being its most vocal critic for purely technical reasons, etc.

cjl

[CLASystems]

Just a thought for someone else with time now to follow up:

When FRTS is run on the PDP-8/E, there is ONE device that CANNOT WORK if interrupts are on, and that is the TD8E.

The underlying reason is that there is a critical timing loop in the handler virtually all the time transfers are happening which is nominally 133 microseconds.  The code is not merely waiting, it is crunching a numerical checksum doing an .EQ formula of a running "sum" etc.  Then the 12-bit number has to be .EQ to itself by halves.  [.EQ the left six bits with the right six bits] and then that has to be written out to the tape [if writing, the inverse is going on if reading].

As such, interrupts are FATAL to this handler!

Thus, there MUST be an internal interrupt disable before calling TD8E handlers and then a re-enable of interrupts in FRTS after the fact.

It won't be general purpose, but it does mean that a patch should be possible for older machines for the serialDisk handler patched in over the TD8E-specific code.

The reasoning is totally different:  The TD8E doesn't even have an interrupt structure but it is essentially a "fragile" handler that must be protected.  The problem with the serialDisk handler is that has to maintain flags being up as part of protocols going on within the serial devices between the two machines.  It takes advantage of the fact you can read the data and NOT clear the flag [or you can if you want to].  Thus, at times the flag will be on for a long time, and that prevents any forward progress in the interrupt-driven runtime system because it has no expectations of working with the serialdisk handler.

Thus, there has to be some sort of code sorta like this:

IOF  /TURN OFF INTERRUPTS

JMS I (HANDLER)  CALL THE HANDLER

arg1

arf2,

arg3

/ERRORS RETURN HERE

/SUCCESS RETURNS HERE

ION  /RESTORE iINTERRUPTS> etc.

Where the IOF [at least] is USUALLY prevented for the rest of the devices where interrupts during a handler is not a problem.

In P?S/8 TD8E handler, I use the SKON instruction [skip the next instruction if interrupts are on and then turn interrupts off] at the entry of the handler.  This causes an in-line IOF or ION instruction at the exit side.  Thus, this 8/E and up device is not a problem in P?S/8, but the OS/8 handlers have no room to do this [and do not]  Ironically, the feebility may just find an avenue to fix the problem!

cjl [now I can stop thinking about it and do other things]

Virus-free. www.avast.com

[Dawson Rosell]

Sorry for such a late response.

I tried building the tape like you said.

the fully reliable way is

.GET device BUILD
make the changes and exit.
.SAVE device BUILD or another name reminiscent of "BUILD".

But I get  "MONITOR ERROR 2 AT 00524 (DIRECTORY I/O ERROR)" after typing GET LTA1: BUILD. The tape spins as if it's looking for something and then stops and gives the error I mentioned.

What could be causing this? I reformatted the tape that I used before so I had a fresh start with a blank tape.

Thanks,

Dawson

[CLASystems]

On Tue, Feb 6, 2018 at 5:38 PM, Dawson Rosell <rose...@d.umn.edu> wrote:

Sorry for such a late response.

I tried building the tape like you said.

the fully reliable way is

.GET device BUILD
make the changes and exit.
.SAVE device BUILD or another name reminiscent of "BUILD".

​That is of course generic.

What was the device part for the GET command?

I am confused.  I thought you only have one trustworthy drive and that would be LTA0:.

Again, I have to assume a few things:

1) You set the system device to LINCtape

2) You apparently added an LTA1: handler [which does not mean it works, it means you can TRY it].

3) You booted it to the LINCtape system on 0 and that apparently works.

Now there are two problems:

a) The instructions were to make the changes AND NOT USE A BOot  COMMAND INSIDE OF BUILD.

b) SAVE IT as you have my quote.

c) Later when you want to actually boot a new system, do NOT expect to save it at that point; the saving should have been done earlier.

d) I thought LTA1: when you set the other drive to unit 1 is NOT RELIABLE.

As such, your message arises from d)  Does seem correct?

Again, to be crystal-clear:

The configuration is serialdisk handlers and the PC-based server, and as long as we avoid interrupts such as FRTS we can use these serialdisk handlers.

AND we have ONLY LTA0: that can be accessed through a non-system handler as LTA0: when the system device is NOT the linctape drive 0.  Apparently what you've been doing other than the inclusion of the LINCtape drive for ZERO and NOT ONE!

Thus, starting from booted to the serialdisk handler:

.GET SYS BUILD
now perform changes so the new monitor will be for system device LINCtape.  This MIGHT include LTA1:on the theory you will fix LTA1: in the future, but for now it is not reliable, correct?
.SAVE SYS LTBLD

of something like that.  that means that later running LTBLD will boot to the LINCtape 0 to become sys WHEN IT IS DONE WORKING AND BOOTED TO.

And from that vantage point, you SHOULD add non-system serialdisk handlers so you can also access them at the point you are booted to LINCtape.

Notice that this instance of running LTBLD is NOT INTENDED TO BE SAVED.  That's the entire point.

In theory, if EVERYTHING WORKED, it MIGHT work do so a SAVE, but noting tne way you used it, you are expecting the image of the running BUILD image to be saved on the NEWLY BOOTED-TO LINCtape-based system, or worse, apparently you tried to trust unverified LTA1:  As I understand it, you have no business using LTA1: YET [and maybe a lot of work to go before-hand.]

A CONFIGURATION attempting to access a device doesn't mean the device is trustworthy!

Now,to be on the safe side, I would go back many steps.

Continue to boot to the serialdisk system, but in BUILD add the non-system LTA0: handler [and if you wish, the non-system LTA1: handler].

At that point, you can try out both drives, using such as ZERO LTA0: then copy files to it, and get directory listings, try to read back the files [if they are text; binary files can only be trusted if using a direct compare program.  Not standard in OS/8, but I do have one, but first see if simple stuff seems trustworthy.

I suspect you have a good shot at it working on LTA0: from what you said, and not the same for LTA1:

So, do that sort of thing FIRST.

Then, if things seem OK, indeed boot a PRESAVED copy of BUILD that boots to the linctape, and why I suggested using a slightly different name, since you do need several and it's easy to have multiple similar yet different ones, so you just run and BO and be done for the moment, etc.

Let me put together an image with the CMPR30 program on it.  Then you can check out every file including binary.  But first get back to me that transfering some text files you can just visually confirm on the way back work.  Baby steps....

cjl​

[Dawson Rosell]

I used LTA1: as the device name because I had the working drive set to unit number 1 so I could run MARK12 and format the tape.

When I have time, I will use LTA0: and see if that works. I suspect it might work as well...

I will go through the steps outlined in your email when I try that as well and report back with my findings.

Day by day I'm getting a better understanding of these things.

Thank you!

[CLASystems]

This will have to be brief;on cellphone.

The new system must be drive 0;1 is data only;OS/8 restriction!

Cjl

[CLASystems]

Sorry for my brief answer, but I was having my quinti-weekly treatment and all I had available was my cellphone [which I hate].

The good news is that I now have a mini keyboard with build-in trackpad that works by BT 4.0 and to the phone it is not only a keyboard [wtih tiny but real keys!] but also adds MOUSE support to the cellphone!  [It's a subset of Samsun deX support].  So, if I remember, I can stick the phone in front of me and actually type vaguely normally in G-mail!

Now back to some tutorials you need to understand.

Every PDP-8 operating system supports its own peculiar devices in various ways.  Sticking for the moment to OS/8, there is a small collection of POTENTIALLY bootable devices to chose from.  In general, each of them can support some form of logical unit on some basis; that said, bootable support is not likely for any unit other than unit 0.

There area small number of exceptions:

The REAL RK8E [or RK8F at the RICM PDP-12] can be booted to drives 3 or 2 or 1 [and also 0] by the use of a somewhat longer bootstrap in memory to have it brought up from.  The RK8E and 8" diskettes can so either drive 0 or 1.

The real TC01/TC08 DECtape only supports a universal bootstrap convention for drive unit 0 only.  Various bootstraps have been written all similar, but different.  This one is special in that many people have attempted to make the code shorter because it is often necessary to toggle it in.  The P?S [of which I am a member] developed an especially short one that can bring up ALL PDP-8 systems with the exception of the Disk Monitor System configured for DECtape [which does not support standard-sized devices;  It's only available for 129 words/block DECtape and the DF32 or RF08 fixed disk.  The reason it can work on those small fixed-head disks is because there is no block structure at all.  You can actually transfer exactly ONE word if you wish.  Needless to say, ir never went anywhere for the simple reason that no other devices were to be brought forth with 129 words/block structures.

Analogous to the RK8E with the possibility of a bootup from drives 9-3, I wrote a special extended bootstrap for P?S/8 to boot to any drive 0-7.  But only when it is set for drive zero is it compatible with all the other systems [except the Disk Monitor System].  Despite the extra support, the code is still shorter than the standard code which must be as long as it is merely to support the Disk Monitor System.  Note: I doubt if you will be seeing the Disk Monitor System to have the intense "pleasure" of running it [NOT!] because they never wrote a LINCtape version.  [There are issues that make this highly unlikely.]  Not being a masochist, I will not contribute to that on any basis, etc.

To my knowledge, for ALL other devices, it is only possible to [directly] boot to a non-zero logical unit or drive on all of the other devices.  Most importantly for you, this includes the SerailDisk and the TC12 LINCtape.

A side issue:  The manual bootstrap for the serial disk is now one shorter due to my recent efforts; it is still compatible with the longer one, but wastes a little bit of time.  Consult recent versions of the OS/8 system device handler for serialdisk  to see the slightly shorter code.

The bootstrap to PDP-8-type PDP-12 LINCtapes is set the switches to 0700 and 0000, LMODE I/O preset, press DO and ten START 20.  The exact value for other than OS/8 and P?S/8 is slightly different;  no one set is truly universal because all things LAP6 have a disparate legacy, etc.

When OS/8 is in the process of BOoting from within a running copy of BUILD [regardless of name] the system running AND the target system to become operational must be on drive 0 in general.  This is certainly true of TC12 LINCtape because only unit 0 can be booted to.

Note: Even on the systems that can be booted to other drives, the act of the boot event self-modifies the few systems that support multiple unit bootup.  As such, since BUILD only uses the image of the handlers themselves which cannot self-modify unless and until they self-boot, it must be used on unit 0.

Thus, when you use BUILD for LINCtape, you have to have drive 0 ready to be written on.

How the tape got formatted and the drive-specific circumstances are beyond irrelevant.  It has to be drive 0 at the time of the attempt to boot to the next system using BUILD, etc.

Once a system is up, additional drives can be referenced from the booted system assuming you configure the system for these additional drives. In OS/8 there is no hard and fast requirement.  All beyond the system drive are optional because you have to load into memory a device handler before you can access any aspect of the device [especially its directory].

P?S/8 works on an entirely different principle.  You always have a "smarter" system device handler in memory which generally supports all of the logical units the hardware support exists for.  Thus, on TC12 LINCtape, that means P?S/8 can access up to drives 0 through 7.  [Remember, a drive is the unique one you set the switches to for selection, so you can fake multiple drives on a machine with less physically available; the software conditions that apply vary depending on the device.  TC12 LINCtape is generally "forgiving" and the machine will hand until you dial in the corresponding unit being sought ant any moment.  This can be quite a juggling act for more than say sharing one drive as unit zero and unit one at times, but in theory, you can play with all eight values in P?S/8.  OS/8 would require you to install all 8 handlers to play an analogous game, and in OS/8 the max number of handlers is too dear to allow that., etc.

Since you are really just a beginner in terms of understanding the reliability of your machine, I would recommend first adding the LTA0: driver to the system via BUILD so you create a system from within a copy of BUILD which is essentially a boot from and also to the serialdisk.  In the process, the handler table is changed and nothing else.  [BUILD understands that the from and the to device are the same and doesn't waste time copying in place.]

Then using PIP zero out the LTA0: directory and attempt to move some files there.  Start with ASCII files you can read back and visually confirm are accurate.  Once you get some confidence we can then verity that binary files copied as well.

OS/8 does not have "native" a file compare program but I have a user-written one called COMPARE Version 3.0 or CMPR30.SV the executable form.  You specify two devices and files and the two are compared to each other.  You should get an EOF M [it matched from beginning to end of file] message if all is fine. even a single comparison shows the first of who knows how many that DO NOT match.

Once an entire tapeful has been exercised that way, we can declare it tentatively reliable and then use a BUILD descendant to boot an LTA0:-based system that also includes non-system serialdisk handlers.  Then you can use the much shorter bootstrap as I wrote above.  That can be the basis of a system to run FRTS from that will definitely NOT have the interrupt problem.  [If the running program references programs on the serialdisk that still can be a problem.  I doubt if any of your projects, any one of them at least, cannot fit on a LINCtape.  You may have to leave out certain other things, but it's not really all that bad.  [Note: The RX01 diskette holds LESS than a LINCtape].

Once we get that far, we can then start on the topic of using even longer LINCtapes; the DEFAULT value within OS/8 is pathetically inadequate.  By nature LINCtaps are longer than DECtapes for the simple reason that the simpler block structure of LINCtapes allows more blocks per foot than DECtapes.  [DECtapes have to be 129 words long because they have to be a whole multiple of 18-bit words by design.  LINCtapes have a final mark on the block.  DECTapes have a prefinal and a final mark on BOTH ends of a block and can read and write backwards; LINCtapes can only read and write forwards; both can search for blocks both ways.  DECtapes have elongated end zones to allow a programmed turnaround when looking for tine block values.  LINCtapes cheat and have tiny length extra blocks on both ends that are just block marks to fool the hardware, there really isn't any data there, just a block mark.  So, when you are searching for block 0 going backwards, the tape hardware finds block -1 and -2 etc. and realizes to turn the tape around by itself.  On DECtapes we have to program all of that and deal with that extra end-zone inter-block code area to accomplish it in.

It is totally realistic to create a LINCtape with at least 3300 octal blocks, but the default value in OS/8 PIP is the same as for DECtape, the nominal 2702 blocks.

To see these numbers in action, start with the basic logical block count, and divide by two because OS/8 actually uses two-block pairing PROPER callked RECORDS but too many sloppy uses also call them blocks.  Thus this is all needlessly confusing.  All the other systems use logical 128 words as blocks, etc.

Thus, for example, 2702 octal in decimal is 1474 decimal.  Diving by two you get 737 OS/8 records.  OS/8 really doesn't use record 0 [other than the overhead of booting if it should apply] and the directory is records 1-6, so subtrack 7 records and you get 730 free records.  Unfortunately, the sloppy habits are in your face everywhere, so the DIR command calls them blocks instead of records!  But you will see the number 730, etc.

Once we all get our respective aspects of our acts together, you should routinely see 857 and more.  Using extremely rare "premium" tapes I have achieved 1017 !  Thus, there is a potential upside of nearly 30% longer tapes.]  Many users routinely got 3400 blocks without really trying.

Needless to say, a very important caveat here:

NEVER CHOP OFF ANY PART OF THE TAPE!!!!!!!

All you need is that the barest first single wrap binds on the take-up reel.  The tape formatting process writes out an over six-boot long end zone and you need the physical tape there to accomplish it; if you cut the tape shorter, it won't be able to be used eventually, and eve the first cut invalidates the tape for even the hope of extra length.

Also, by doing some Rube Goldberg tricks, it is possible to wind the tape backwards so the "inside" end is not on the outside.  the shiny side is still up, but the surface that faces the head is the same one as before the change.  [Note:  There is also an easier way: perform a "prisoner exchange" with DECtape users; the tapes are inherently moving in opposite directions for all purposes.  A simple wind-off to another reel gets you what you want, etc.

Also, the inside end of a tape is often in virgin condition having "never seen the light of day" so to speak and is factory-fresh smooth.  The often "gnarrly" end now on the inside will, with time completely iron out!

The missing part of the equation is of course, how to get the tape format different; that's part of my self-appointed tasks.  I will be reporting when I make some forward progress on that, but it is not one of my current projects.  We'll see in the future who is waiting for whom.  The simple answer at this point is "it's complicated".  Hopefully the fruits of my last visit to RICM will " bear fruit" in this endeavor.

For the moment, I am assuming you are using the standard DIAL MARK12 program specifying the 129 words/block tapes.  Please tell me what on the screen it says regarding the block count.  Maybe in the shorter term some improvement can be accomplished, etc.

Now onto some newer work I have done:

I have sent to Michael Thompson for testing the newest version of the serialDisk device handlers which are revision H.  This will clear the air regarding versions as of now all prior ones are obsolete.  The changes are only preliminary to what Kyle Owen was discussing; it's not yet actually implemented, but I had to clean a few things up first.  Thus, even this version will run on all "family of 8" machines etc.  This will  not help you with the FRTS interrupts problem with serialDisk because the code, while present, is only functional on the PDP-8/E and up.   [Older versions the code was NON-functional on older machines; my previous and this new one are the only releases that fix the problem on the 8/E and up yet do not mess up on the PDP-12 and back.]

If Michael can prove they completely function on both his 8/E system and the RICM PDP-12, we will send them out to everyone.  [I will put them on my archive site in ibiblio.org.]  I assume Michael will be catching up over this weekend, etc.

I am available for additional questions, but I have to spend most of my time on the PEPS package user guide, my main project of the moment.  This is turning into a lttle bit of War and Peace as opposed to a pamphlet.  [Reality is of course somewhere in between: :-).

If you told me 10 years ago I would be spending serious time as a tech writer, I would say you would be nuts.  But truth is stranger than fiction.

cjl

[CLASystems]

I suspect [some of] you don't have this:

Attached is the shortest manual bootstrap code for the Serial Disk System handler.  Starts loading at location 20 in PMODE and starts there as well.

Somewhat longer versions have been circulating, but this one takes additional advantage of the later releases to get the length down somewhat.

cjl

[Dawson Rosell]

Here is where I've gotten so far...

I added the non system handler to the BUILD for the serialdisk (for LTA0). I saved this and did not run BO.

I ran ZERO LTA0: and it reported an empty tape with 730 blocks free.

Next I ran PIP and copied over a fortran file to LTA0: from SDA0:

      *LTA0:TEST.FT<SDA0:TRIAL1.FT

This ran fine.

I then ran DIR LTA0: which reported a file called TEST.FT and 729 blocks free. (TRIAl1.FT was 1 block in size). Next I ran TYPE LTA0:TEST.FT and it correctly printed the contents of the fortran file. Everything seems fine in terms of transferring text files.

I then tried to transfer a .SV file (F4.SV in particular). This did not work. I ran PIP, LTA0:F4.SV<F4.SV and it seemed to transfer... But the tape reported a file called F4.SV that only took up 1 block, whereas the original took up 20 blocks.

I think that I missed a step somewhere here... Does PIP have an option I am supposed to enable for transferring files besides text/ASCII? That could be it?

I am assuming you are using the standard DIAL MARK12 program specifying the 129 words/block tapes.

This is true. It says 129 word format.

Thank you,

Dawson

[Kyle Owen]

On Feb 11, 2018 14:24, "Dawson Rosell" <rose...@d.umn.edu> wrote: 

I then tried to transfer a .SV file (F4.SV in particular). This did not work. I ran PIP, LTA0:F4.SV<F4.SV and it seemed to transfer... But the tape reported a file called F4.SV that only took up 1 block, whereas the original took up 20 blocks.

I think that I missed a step somewhere here... Does PIP have an option I am supposed to enable for transferring files besides text/ASCII? That could be it?

Yes, add a /B to the end of the command for binary. 

[CLASystems]

We're getting somewhere...

On Sun, Feb 11, 2018 at 5:23 PM, Dawson Rosell <rose...@d.umn.edu> wrote:

Here is where I've gotten so far...

I added the non system handler to the BUILD for the serialdisk (for LTA0). I saved this and did not run BO.

​You mean that it is built generally so it boots to the serial disk SDA0: device as the system, and you added the non-system device handler for LTA0:

Good.

​

​

I ran ZERO LTA0: and it reported an empty tape with 730 blocks free.

​After clearly the tape moved!​

Next I ran PIP and copied over a fortran file to LTA0: from SDA0:

      *LTA0:TEST.FT<SDA0:TRIAL1.FT

This ran fine.

​That's fine, but the long way around as long as CCL is enabled [which it is because you used the ZERO command].  OS/8 also has an "excuse" program for the limitations of PIP called FOTP.SV [File-Oriented Transfer Program] and the COPY command calls that up using the advantage of CCL to simplfy what you type.  [Or you could have the overhead of using the same sub-command to FOTP, but why bother; see below.
​

I then ran DIR LTA0: which reported a file called TEST.FT and 729 blocks free. (TRIAl1.FT was 1 block in size). Next I ran TYPE LTA0:TEST.FT and it correctly printed the contents of the fortran file. Everything seems fine in terms of transferring text files.

​That's all good and is as expected.

​

I then tried to transfer a .SV file (F4.SV in particular). This did not work. I ran PIP, LTA0:F4.SV<F4.SV and it seemed to transfer... But the tape reported a file called F4.SV that only took up 1 block, whereas the original took up 20 blocks.

​That's because you need to use IMAGE mode to transfer binary core image files, not to be confused with binary files [,bn] or ASCII text files [.PAL, .FT, .BI, etc. are all ASCII text context, but the extensions are there to imply other aspects of how the files get used, not merely how to copy them correctly, etc.

All of this confusion is why they wrote FOTP.  It just copies files from their entries and doesn't delve into the innards.  It was too much to fix PIP, so this is a band-aid program because no one wanted to rewrite PIP.  And the DIRECT program is another one because of the limited nature of how PIP can create a non-adorned directory listing.  Instead of fixing anything, they piled on other programs logically gutting the program by doing nearly nothing, so it mainly becomes the device length reposiitory and the ZERO command is in fact PIP /Z. 

But you could freely intermix and just used COPY [to invoke FOTP].

So, that''s why it created a junk descendant a​nd not anything useful.

If you use COPY, then you can try RUN LTA0 the program and it might work.  [if it does not, it definitely didn't work, if it did, it's still only conditionally trustworthy].  This is why I have to send you the CMPR30 program because that is foolproof, etc.

I think that I missed a step somewhere here... Does PIP have an option I am supposed to enable for transferring files besides text/ASCII? That could be it?

​Yes, the problem is it has too many of them, each of limited purpose and not exactly what we are attempting to do.  There is a difference between COPYING a file and REPROCESSING the file to perhaps get a slightly shorter or maybe longer result.    This is the nature of PIP.  It's not "wrong" but it's trying to be one size fits them all [and that never worked].

​

I am assuming you are using the standard DIAL MARK12 program specifying the 129 words/block tapes.

This is true. It says 129 word format.

Thank you,

Dawson

​OK, we can proceed with caution; i have to dig up that program and put it [wastefully] on an .RK05 image file for you to then copy the one file [USING COPY] and then toss the image , etc.

[CLASystems]

​I don't think that will work for an image file, but /I definitely will.  Actually it will handle both formats.  /B's purpose is to process the binary file and in the process the checksum is calculated so you can get a bad file or not.   Additionally, it is processing for leader and trailer so you get standardized lengths of both instead of whatever was there.  That might matter after for example an image transfer of a binary paper tape which has paper-tape standard leader and trailer lengths.  OS/8 .BN files prefer to have very short leader and trailer and a trailing Control-Z character at the very end.  ABSLDR may or may not be able to handle binary files unless pre-processed by PIP, so it's never a bad idea IF the file is a .BN file.

cjl​

--

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

Bill Gates, 1992

Virus-free. www.avast.com

[Peter Peterson]

Hi all,

Long time listener, first time caller.

First, I have to say thank you to all of you for contributing and helping with this project. The community surrounding these machines is pretty incredible and I appreciate the time that you've given to us (and others).

Also, I have to say at the outset that I have worked with the PDP-12 a tiny fraction of the time that Dawson has; he understands a lot of the details of these conversations that I don't. So, please forgive me for stupid questions. I have read all these threads, but I am sure that I have not understood everything.

I have a little more free time this semester than usual due to a course release, while Dawson has less time than usual due to a grading job, so I'm trying to get up to speed on the challenges that he is facing and try to help him make some headway. I am also trying to document all this stuff for our machine, since one of the reasons I feel like it is worthwhile for a University to take on a PDP-12 is for posterity (in addition to the educational value, etc.). If we don't document, then we don't have posterity. That's another reason that I am so grateful for people like Warren and the rest of you... there is such a tremendous wealth of knowledge in this community, both facts that are not well-documented and and expertly filtered facts from the mountain of documentation that exists (but is often hard to find).

So, thank you. 

I'm going to send another email shortly, but I just wanted to say this here and now.

Best,

Peter

--

Peter A. H. Peterson, Ph.D.

Assistant Professor
Department of Computer Science

University of Minnesota Duluth

[Maury Pepper]

This group has been silent for almost 14 months. Has anything been
happening? Has the conversation moved to a new place. Is the PDP-12
considered fully stable and usable?

    -maury-

[Peter Peterson]

Hi Maury,

The project is definitely not dead -- we have been active here at UMD, but we haven't really been using the mailing list much. (That could change at some point -- not sure.) Dawson just graduated, actually, and we're taking time this week to work on the machine before he moves away.

If you're interested, you can see more here:

Blog: https://umdpdp12.blogspot.com/

YouTube: https://www.youtube.com/playlist?list=PLHnc49MScQBBIlVIirpZ1Zjdh91U5Q6-6

I'm also @tastytronic on Twitter and I usually post about what we're doing on there.

Peter

[Michael Thompson]

We made SpaceWar control boxes for the PDP-12 at the RICM, and then modified the game to use them. Otherwise, nothing new on the RICM PDP-12.

--
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

[clasystems]

On Tuesday, May 14, 2019 at 5:09:28 PM UTC-4, Michael Thompson wrote:

We made SpaceWar control boxes for the PDP-12 at the RICM, and then modified the game to use them. Otherwise, nothing new on the RICM PDP-12.

Michael:  I forgot to ask:  Have you checked out the noise level that you suspect gets into the LINCtapes now that the machine has been moved?  There are still tapes that need to be read for the LINC-8 project and more.

CJL

ps:  I am getting closer to dealing with the DECtape image that I suspect has POLY SPACEWAR source code on it.  Remember, you can't just casually say "spacewar" because there are so many different versions, some rather lame, some better.

The best for 8K is likely Kyle Owen's, but he likely used mode B which locks out all but the 8/E.  Doug Wrege's needs 8K, but only the original 8/I EAE.  POLY SPACEWAR runs in 4K and uses straight-8 EAE.  That is deficient compared to the 8/I  and -12 in one minor way:   The SWP in one instruction doesn't work.  I think in the POLY SPACEWAR code, it might make it ever so slightly faster if SWP were functional and of course slightly smaller, always a plus.

 

On Tue, May 14, 2019 at 4:34 PM Maury Pepper <mpe...@ieee.org> wrote:

This group has been silent for almost 14 months. Has anything been
happening? Has the conversation moved to a new place. Is the PDP-12
considered fully stable and usable?

     -maury-

--
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 p...@d.umn.edu.

--

Michael Thompson

[Kyle Owen]

On Tue, May 14, 2019, 18:21 clasystems <clasy...@gmail.com> wrote:

The best for 8K is likely Kyle Owen's, but he likely used mode B which locks out all but the 8/E.  Doug Wrege's needs 8K, but only the original 8/I EAE.  POLY SPACEWAR runs in 4K and uses straight-8 EAE.  That is deficient compared to the 8/I  and -12 in one minor way:   The SWP in one instruction doesn't work.  I think in the POLY SPACEWAR code, it might make it ever so slightly faster if SWP were functional and of course slightly smaller, always a plus.

"My" SPACEWAR is just Wrege's code, slightly modified to use a second serial port for a simulated VC8-E. I don't recall having to add any EAE instructions for that. Vince and I also fixed a bug where velocity overflows, causing the ship to "bounce." Same thing; no EAE instructions required for that. 

Charlie, I'm hoping to pick up an 8/I soon, so rest assured, I'll try to not use any 8/E-specific instructions henceforth. If I do, I'll use conditional assembly.

Kyle

[Peter Peterson]

Hi all,

We are hoping to do a Spacewar tournament this coming school year, so we'd love to get copies of the code with the bugfixed velocity issue (we've seen that, too) and the modifications for the remote boxes. 

Today, Dawson and I are hoping to track down an issue we're having with the Tape Data Test diagnostic... we suspect there might be an issue with our tape accumulator or related hardware -- the program fails the checksum checks. The drives themselves work and have been cleaned and are able to successfully mark tapes.

Peter