• Please review our updated Terms and Rules here

What did I do to my PDP-8 today.

Roland Huisman said:
There is one thing which I don't really understand. DEC used resistors in the PDP front panels to
preheat the bulbs. This was to lengthen the life of the bulbs. But these resistors were not used
in peripherals like the RK05. Probably because the blink rate on the PDP is much higher?
Click to expand...
I suspect that the wear & tear on the bulbs in disk drives was mostly from the vibration.
 
While Vince and Kyle are consolidating Serial Disk for an update to Github I decided to work on a shorter boot for the older machines that do not have a bootstrap board and of course this will also work on machines that could have a boot board but which do not. I based it on the help loader which is the shortest non Data Break loader known. Because we don't have to worry about skipping paper tape leader I was able to remove 2 instructions. This is what it looks like although where it ends up in memory might move around.
Code: 
   80 00035  6416  GO,     STLS            /SEND A ZERO TO  WAKE UP THE SERVER FOR BOOTING
   81 00036  6401          SKSF            /SKIP IF SERVER HAS SENT US A CHARACTER
   82 00037  5036          JMP .-1         /WAIT FOR A CHARACTER
   83 00040  6406          SKRB            /READ THE CHARACTER
   84 00041  7012          RTR             /MOVE BITS INTO POSITION
   85 00042  7010          RAR
   86 00043  3000          DCA 0           /STORE ADDRESS
   87 00044  2043          ISZ .-1         /BUMP STORE ADDRESS
   88 00045  5036          JMP GO+1
That is only 9 instructions and if you wanted to make it 8 you could by removing the STLS on the first line. This instruction sends the server wake up code of 0 which will tell the server to send the helper boot code and then send the handler and resident code in field 1. If you get rid of this the alternative would be to manually restart the server with an option flag to force it into this mode. Personally I think toggling in one extra instruction takes less time than restarting the server would.

It looks like the boot block transfer will take about a half a second if the serial interface is running at 9600 baud.

If you have never seen the help loader and the code above doesn't make any sense I will be glad to go through how it works. I will leave that for another post to give you time to think about it and the limitations this boot imposes.
 
Hi Doug,

Just to be 100% sure is your boot loader meant to be for SerialDisk?
If I read the code correctly it works by depositing 035 words received starting from address 0 where eventually address 035 becomes a jump somewhere into the just loaded 035 word sequence?
I have not found that 035 word sequence that is actually loaded. It must be some kind of boot sector. Where do I find the source or source listing of that?

Thanks and best regards
Tom Hunter
 
thunter0512 said:
Hi Doug,

Just to be 100% sure is your boot loader meant to be for SerialDisk?
If I read the code correctly it works by depositing 035 words received starting from address 0 where eventually address 035 becomes a jump somewhere into the just loaded 035 word sequence?
I have not found that 035 word sequence that is actually loaded. It must be some kind of boot sector. Where do I find the source or source listing of that?

Thanks and best regards
Tom Hunter
Click to expand...
The intention is that this will be a shorter boot sequence for those who do not have a boot board with the serial disk boot in it. I am thinking of Roland's board here. We will have to add this to the server. The current one does not know what to do when sent a 0 as the wake up code. I realize that we need to keep the existing server functionality which uses 0100 as the boot wake up code.

I only posted the part of the loader that a person would toggle in. I call this part boot 1. In this case boot 1 loads in a more capable program which is called boot 2. Here is what you should expect to see in memory once boot 1 is done. You will see several *.-1's in the code. These come at points that need to be fixed up before they work properly. The help loader has some limitations. Hopefully the comments are enough to let you understand. The instruction before the *.-1 is what will eventually be there. The one after the *.-1 is what the boot 1 code loads in that location.
Code: 
/SERIAL DISK BOOT

/ THIS CODE WILL SEND A 000 TO THE SERVER TO INDICATE BOOT.
/ THE SERVER WILL SEND THE HELPER CODE AS FOLLOWS:

/   INSERT HELPER CODE HERE CONSISTING OF THE 8 BIT VALUES.

/ THEN THE SERVER WILL SEND A 5402 (JMP I GETNUM) TO PATCH
/ THE RETURN FROM GETNUM.

/ AT THIS POINT THE BOOT 2 CODE EXPECTS TO SEE PAIRS OF 12 BIT WORDS
/ CONSISTING OF AN ADDRESS AND THE DATA TO GO AT THAT ADDRESS.  THE
/ INITIAL ADDRESS WILL BE IGNORED SINCE WE STILL NEED TO PATCH IN A 3401
/ (DCA I STRADR) OVER THE DCA .
/ AT THIS POINT THE SERVER WILL SEND AN ADDRESS FOLLOWED BY THE DATA.
/ WHEN ALL WORDS HAVE BEEN SENT WE FORCE THE BOOT 2 CODE TO JUMP TO OS/8

/BY POKEING A 7605 INTO ADDRESS 0002 AND POKEING A 5402 (JMP I 2) OVER
/THE JMP POKELP AT THE END OF POKELP.

/POSSIBLE IMPROVEMENTS:

/ ADD A WORD COUNT SUCH THAT BLOCK TRANSFERS OCCUR INSTEAD OF ADDRESS
/ DATA PAIRS.

/ DO A 3 BYTE TO 2 WORD UNPACKING.

/ WITH THE ADDRESS DATA PAIR SCHEME THIS WILL SEND AROUND 1024
/ CHARACTERS.  AT 9600 BAUD THIS WOULD TAKE A LITTLE OVER A SECOND TO
/ BOOT.  WITH THE BLOCK TRANSFER CHANGE IT SHOULD TAKE ABOUT HALF A
/ SECOND.  WITH THE BLOCK TRANSFER AND 3 BYTE TO 2 WORD MAPPING IT
/ SHOULD BOOT IN ABOUT 0.4 SECONDS.  PROBABLY NOT WORTH IT FOR THE
/ ADDITIONAL BOOT COMPLEXITY.

SKSF=6401
SKRB=6406
STLS=6416

        *0000
TEMP,   0               /UPPER HALF OF 12 BITS GETS STORED HERE
STRADR, 7777            /STORE ADDRESS USED INDIRECTLY
/WE START OUT HERE AND PATCH THE IOT'S FROM WHAT WE KNOW IS IN MEM
PATCH,  TAD KSFCD       /COPY THE SKSF INTO PLACE
        DCA SKSF1
        TAD KSFCD
        DCA SKSF2
        TAD KRBCD       /NOW COPY THE SKRB INTO PLACE
        DCA SKRB1
        TAD KRBCD
        DCA SKRB2
/WE INITIALLY FALL INTO GETNUM WHICH WILL PATCH THE DCA . WITH JMP I GETNUM
/THE FIRST TIME THROUGH.
GETNUM, NOP             /ROUTINE TO FETCH A 12 BIT NUMBER FROM THE SERVER
SKSF1,  HLT             /WILL BECOME SKSF
        JMP .-1         /WAIT FOR CHARACTER
SKRB1,  HLT             /WILL BECOME SKRB
        RTL             /LEFT SHIFT 6 BITS TO BUILD UPPER HALF
        RTL
        RTL
        DCA TEMP        /SAVE UPPER 6 BITS
SKSF2,  HLT             /WILL BECOME SKSF
        JMP .-1         /WAIT FOR CHARACTER
SKRB2,  HLT             /WILL BECOME SKRB
        TAD TEMP        /BUILD 12 BIT WORD
        JMP I GETNUM    /RETURN
*.-1                    /THE NEXT INS WILL BE PATCHED BY THE JMP I GETNUM ABOVE
        DCA .           /THIS BECOMES THE GETNUM RETURN POINT
POKELP, JMS GETNUM      /GET THE 12 BIT ADDRESS
        DCA STRADR      /SAVE IT FOR THE POKE
        JMS GETNUM      /GET THE 12 BIT DATA
        CDF 00          /SERVER CAN PATCH THIS TO WRITE TO DIFFERENT FIELDS
        DCA I STRADR    /STORE IT
*.-1                    /NEXT INS GETS PATCHED BY A DCA I STRADR ON FIRST POKE
        DCA .           /POKE IT
        CDF 00          /FORCE BACK TO FIELD 0
        JMP POKELP      /REPEAT UNTIL THIS GETS OVERWRITTEN WITH A JMP I STRADR
        JMP PATCH       /WHEN THIS OVERWRITES THE SKSF AT KSFCD BOOT 2 STARTS
*.-2                    /THE JMP PATCH ABOVE WILL OVERWRITE THE SKSF AT KSDCD
/THE FOLLOWING IS THE PORTION THAT GETS TOGGLED IN CALLED BOOT 1
GO,     STLS            /SEND A ZERO TO  WAKE UP THE SERVER FOR BOOTING
KSFCD,  SKSF            /SKIP IF SERVER HAS SENT US A CHARACTER
        JMP .-1         /WAIT FOR A CHARACTER
KRBCD,  SKRB            /READ THE CHARACTER
        RTR             /MOVE BITS INTO POSITION
        RAR
        DCA 0           /STORE ADDRESS
        ISZ .-1         /BUMP STORE ADDRESS
        JMP KSFCD

        $
This has not been tested. And I have not generated the character sequence that the boot 1 will need to load the initial version of boot 2.

Enjoy!
 
Thanks Doug. I misunderstood and thought this would already work with my existing SerialDisk setup using Kyle's disk images.

Toggling in the current 025 words of Kyle's bootloader is not too much fun if you have to do it over and over.
After figuring out that I can warm-boot it has become not such a big deal, but a shorter boot loader is definitely desirable.

The character sequence for "boot 2" will presumable have to be patched into Kyle's disk images?
I would be glad to test this out when you have worked it out.

Eventually I would like to make my Raspberry Pi based SerialDisk setup headless, but for that I would need to create a small shutdown program under OS/8 which tells SerialDisk to close the disk image, sync and initiate a clean shutdown of the Raspberry Pi OS (Raspbian).

Best regards
Tom Hunter
 
thunter0512 said:
Toggling in the current 025 words of Kyle's bootloader is not too much fun if you have to do it over and over.
After figuring out that I can warm-boot it has become not such a big deal, but a shorter boot loader is definitely desirable.
Click to expand...

This is my whole reason for doing it. I have a Straight 8 and an 8/i neither of which have boot boards. Toggling in the RIM loader used to be fun. RIM is 16 words. The current Serial Disk boot is 22 words long and it could be changed to 20 as I found two instructions that are not necessary for correct operation. Dropping to 9 is a pretty good reduction.

thunter0512 said:
The character sequence for "boot 2" will presumable have to be patched into Kyle's disk images?
I would be glad to test this out when you have worked it out.
Click to expand...

The server will need to change, the boot block on the media can stay the same. Makes this a lot less painful than it could be.

thunter0512 said:
Eventually I would like to make my Raspberry Pi based SerialDisk setup headless, but for that I would need to create a small shutdown program under OS/8 which tells SerialDisk to close the disk image, sync and initiate a clean shutdown of the Raspberry Pi OS (Raspbian).
Click to expand...

This would just require coding up a different wakeup code for the server. I doubt it would take much time to add to the server. From memory the wakeup codes that have been defined are "@", "A" through "H", and more recently for the purposes of this boot a NULL or 0 code. To be certain I would have to go look at the server code.
 
I hope this Intersil/Harris based PDP-8 is on-topic enough for the hardcore members. :)

My SBC6120 with its FP6120 front panel did not quite behave as expected.
The rotary switch seemed to show the AC in the MQ position and neither Flags or MD showed meaningful values.
The basic system worked fine tough.

As it turned out there was some disconnected between the BTS6120 firmware and revision 1D of the FP6120 front panel.
The order of the rotary switch bits must have changed (simply reversed) sometime during the evolutiion of the system and mine was non-matching (using the latest published revision 266 of BTS6122).
If somebody else with Revision 1D of the FP6120 has this problem PM me with your email address and I will send you the fix.

Best regards
Tom Hunter
 
Hopefully I will beat the avid reader of my boot code when they want to point out how I messed up. I have found two issues. First one is that the GETNUM routine entry point is at address 0013. Because 0013 is an auto index location the return from GETNUM will go to the wrong place. The auto index registers increment before they are used when used indirectly. On the PDP-8 a subroutine return is usually a JMP I <subroutine entry point>. The return would be to to the word after the one you expected. The memory locations 0010 through 0017 in every field are auto index. The second problem comes from the way the help loader works. I will explain now what I hinted at in the first post. Here is the original help loader code.
Code: 
*0027
        KSF             /skip if a character is received
        JMP .-1         /wait for a character
        KRB             /read the character
        SNA             /skip if not leader code
        JMP 0027        /if leader ignore it
        RTR             /rotate right 3 to build a help INS
        RAR
        DCA 7           /store the instruction in memory
        ISZ .-1         /bump the store address
        JMP 0027        /go do the next one
The point of all this is to build a 12 bit instruction from an 8 bit character found on the paper tape. A useful 8 bit to 12 bit translation. The PDP-8 must have the upper 3 bits of an instruction. Those bits form the opcode. The lower 7 bits of a memory reference instruction directly reference a memory location on page 0 or the current execution page depending on a bit. With the RTR and RAR we have moved the lower 3 bits into the opcode and the upper 5 bits into the lower bits of the address field. The remaining 4 bits are set to zero. This means that we can perform any direct reference to a memory location between 000 and 037. The IOT instruction uses the lower 3 bits to identify the function and the middle 6 bits are the device code. That means that the help transform can only generate IOT's that use device codes 0, 1, 2, 3 because only two bits get expressed in the device code field. Because serial disk uses device codes 040 and 041 I have to get these instructions from somewhere in memory and they are present in memory at known locations in the boot 1 code we hand toggled in. However, the boot 2 code is long enough that those instructions ended up above address 037 so they cannot be reached. I discovered this when I tried to hand generate the first couple of 8 bit help codes. I need to move GETNUM and decrease the size of the code by 5 words. This might not be possible. The next way to deal with it would be to change the functionality of boot 2 and use it to load in a boot 3 with more capability. I would dislike that but it is a possible solution. I hope that makes sense. In fact it is more convoluted when you realize that one of the three bits that shows up in the opcode was stored in the link from the previous character. In essence that bit is time shifted. And I thought it was going so well!

Wish me luck even though I don't think there will be any luck involved.
 
thunter0512 said:
Eventually I would like to make my Raspberry Pi based SerialDisk setup headless, but for that I would need to create a small shutdown program under OS/8 which tells SerialDisk to close the disk image, sync and initiate a clean shutdown of the Raspberry Pi OS (Raspbian).
Click to expand...

As it turns out, there is a 'Q' command to the server, which causes it to attempt an immediate shutdown. As far as I know, nothing actually uses it yet, but it is intended for just this use case.

Vince
 
DougIngraham said:
With the RTR and RAR we have moved the lower 3 bits into the opcode and the upper 5 bits into the lower bits of the address field. The remaining 4 bits are set to zero. This means that we can perform any direct reference to a memory location between 000 and 037.
Click to expand...

I was just going to point out the fallacy here, but based on the later text, it seems you did realize it as well.
RTR;RAR will not move the three low bits into the top three bits, since the LINK is in between.
RTR;RTR would do that, but then you have also reduced the rest of the usable bits to only the low 4, which could give you more headaches. And of course, you get whatever the link was in there as well. You can explicitly clear or set the link in the first RTR to at least have it controlled, which probably is a good idea.
But I somehow suspect you're going to have to correct this a bit more...

One trick you could do if the code only will run on 8/E or newer is to use BSW instead. But it would leave you with bits 6-9 zeroed instead, which might be a headache too...
 
bqt said:
I was just going to point out the fallacy here, but based on the later text, it seems you did realize it as well.
RTR;RAR will not move the three low bits into the top three bits, since the LINK is in between.
RTR;RTR would do that, but then you have also reduced the rest of the usable bits to only the low 4, which could give you more headaches. And of course, you get whatever the link was in there as well. You can explicitly clear or set the link in the first RTR to at least have it controlled, which probably is a good idea.
But I somehow suspect you're going to have to correct this a bit more...

One trick you could do if the code only will run on 8/E or newer is to use BSW instead. But it would leave you with bits 6-9 zeroed instead, which might be a headache too...
Click to expand...
I didn't invent this. It is the way the old help loader works (DEC-08-LHAA-D). There is a PDF of the writeup on Vince's site. dec-08-lhaa-d.pdf
There is a program called the help generator which would create the paper tapes. I never used the help loader or the generator because the machine I used had a DF-32 usually with PS/8 in place or I could boot from DECtape if the DF-32 was left unusable. I am writing a little C program today to generate the help code from an assembler listing.

The limitations on help code are:
  • IOT's can only use device codes 0 through 3. This was not a problem for the help loader because it only talked to device code 3 the console TTY.
  • Only direct references to locations 0 through 037. No indirect or current page references.
  • The OPeRate microinstructions cannot use the CLA, CMA, or CLL bits and only group 1 can be generated. This means you can use RAR, RAL, RTR, RTL, and IAC. I guess you could also use BSW and R3L (HD-6120 CPU only) encodings for those machines that understand them if you really wanted to.
This is a bit of a challenge to work with the largest one being the IOT device code issue. I had to use the codes that were hand toggled in because the Serial Disk serial port is on device codes 40 and 41. Subroutines are tough because you have to fixup the return or do a return without using JMP I.

Thanks looking at it.
 
vrs42 said:
OK, so I cloned Kyle's repository, checked in and tested each of Bob's revision and CJL's three revisions. Then I created a revision of my own with the changes mentioned above, and tested that. So some progress there :). Also a minor fix for a server bug which caused a hang if you accessed a drive for which you had a driver, but no pack was configured there when the server was started.
Click to expand...

Kyle has pulled the changes, so his GitHub repo at https://github.com/drovak/os8diskserver has the latest SerialDisk code I know about, with the exception of Doug's current work on the boot loader.

There are a few other forks around, so maybe there is more code out there that hasn't made it to GitHub? (I should perhaps ping the owners of the other forks.)

Vince
 
vrs42 said:
As it turns out, there is a 'Q' command to the server, which causes it to attempt an immediate shutdown. As far as I know, nothing actually uses it yet, but it is intended for just this use case.

Vince
Click to expand...

I added a ‘Q’ command when I hacked my driver and server mods which I guess propagated through CJL’s mods. The server mod for this was specifically for a Raspberry Pi (Debian/Raspbian) which is what I use; closing the files is standard but the system shutdown commands aren’t really standard across Unixes (unices?) so YMMV. I just wrote a little PAL program to shut the server down from OS/8.
 
vrs42 said:
There are a few other forks around, so maybe there is more code out there that hasn't made it to GitHub? (I should perhaps ping the owners of the other forks.)
Click to expand...

I made a modified OS/8 BOOT program that included the serialdisk bootloader. It added the option BOOT /SD.
I should find the source code and send it to Kyle.
 
Vince found a couple of bugs in my help loader inspired serial disk boot loader so I corrected those. This is very close. Vince is working on adding the server side pieces. Should hear from him when it works.

I looked at the schematics for Vince's memory board that is having troubles with one of the "compatible memory chips". It is such a straightforward circuit I don't see what it could be. It doesn't look like there should be any timing issues. This may be what we work on when I am in his area in March.

Accepted the bulbs for my 8/e front panel from the UPS delivery person.

Probably made a funny face when looking at the excessive starting prices for some omnibus boards offered on Ebay. I should add these to my watch list.
 
m_thompson said:
I made a modified OS/8 BOOT program that included the serialdisk bootloader. It added the option BOOT /SD.
I should find the source code and send it to Kyle.
Click to expand...

I could probably include your program with Doug's boot loader and the corresponding server changes that I am doing. (Hopefully I can get the boot stuff checked in later this week.)

Vince
 
DougIngraham said:
Vince found a couple of bugs in my help loader inspired serial disk boot loader so I corrected those. This is very close. Vince is working on adding the server side pieces. Should hear from him when it works.
Click to expand...

It works, at least in the sense that it has booted OS/8 :). There are still some issues to clarify and code to clean up.

There seems to be a bug/mis-feature in SIMH, though, in that then when I use 'RUN', it doesn't send the NUL byte for the STLS that's supposed to kick things off. It works fine when I use the SIMH 'GO' command instead.

I feel quite certain that a TLS as the first instruction after the START key is pressed will send a NUL on real hardware.

Vince
 
Today I finally pulled apart the dual RX01 from the LAB-8/e rack. After further cleaning it and applying some teflon spray to the lead shaft and the stepper motor bearings the heads move smoothly. One of the drive motors makes an unpleasant sound which may be a bad bearing or may also need some teflon spray treatment.

Interestingly one of the drives is a made by Calcomp and the second one by Century Data. They are almost identical except the head of the Century data is (for me) unusual. I am familiar with the black plastic carrier with the glass head with embedded ferrites/coils. This one is just a plain polished metal dome shaped gadget. This is the first floppy drive head I see that looks like this. I cleaned both heads with cotton buds and IPA. The wiring is a bit different too between the two drives.

I suspect the Cenury Data drive was retrofitted (it looks newer and was less filthy). Somebody butchered a 80 x 80 mm fan onto the back of it using a very roughly made aluminium carrier plate. The older Calcomp drive also has a similar fan, but it is neatly done factory job. Rather unusually the Calcomp fan runs from the standard Australian 240V AC but the Century data fan runs from 110V AC using the huge rackmount transformer mounted to the back door of the rack. The wiring was made by someone with suicidal or homicidal ideas. There are some crazy people out there.

I am wondering about the noisy spindle motor. Removing it is not easy. I first have to get the fan blades off the top of it which is tricky because it seems to be fitted with a grub screw requiring a US size allen key which I don't have. Also once I removed the motor you are meant to reassemble it with the correct distance between the two pulleys using an adjustment tool I don't have. I guess I can just take a measurement with my vernier caliper and use the distance measured when reassembling it.

Two important question arose:

1) where would I found replacement 50 Hz drive belts?
2) where would I find replacement R/W heads?

Tomorrow I will reform the power supply caps and then check out the power supply voltages before reassembly.

Best regards
Tom Hunter
 
thunter0512 said:
Interestingly one of the drives is a made by Calcomp and the second one by Century Data. They are almost identical except the head of the Century data is (for me) unusual. I am familiar with the black plastic carrier with the glass head with embedded ferrites/coils. This one is just a plain polished metal dome shaped gadget. This is the first floppy drive head I see that looks like this.
Click to expand...
Calcomp is Century Data, for all intents and purposes. From CalComp 25 - 1959-1984:

1968 * The Company embarks on a planned diversification program by gaining control of or acquiring ownership of industry related companies. Acquisitions include [...] Century Data Systems (CDS) [...].

1971 * CalComp acquires 100% of stock of Century Data Systems and merges the two companies.
 
vrs42 said:
It works, at least in the sense that it has booted OS/8 :). There are still some issues to clarify and code to clean up.
Click to expand...

I have committed Doug's bootstrap and my server support for it in my fork, and generated a pull request for Kyle's repo.

So, less toggling could be in your future, if you happen not to have a boot card!

Vince
 
You must log in or register to reply here.
Back
Top