• Please review our updated Terms and Rules here

What did I do to my PDP-8 today.

What I did to "my" pdp8 today:

Built a interface for the MUSIC program - a FlipFlop - calibrated output signal length and wired it to the spare "command" 6750 on the RX8E M8357R floppy controller.

Modified the MUSIC source for IFNDEF NOISE <NOISE=6750>

Tried to transfer the new source to the PDP8, found no way to do so since it seemed to big for every editor and PIP.

Compiled it on the PC with PALBART
Wanted to inject everything into a RX02 image by using PUTR in DOSBOX/Linux. Someone once said this would work, for me it did not. Used a Windows 7 VM in the end.

Transferred everything to a new RX02 image.

Works flawless, will be using it with an old radio from my grandpa once the machine is on display in the museum.



1768991811963.png

1768991671783.png 1768992062465.png
 
Before inserting the BusLoads card I would check all diodes. Particularly the 16 (?) D662 (type), D192 (number), D62+D63.
I have checked 12 cards last time and most that did not work have some broken diodes there.
 
gnupublic said:
Before inserting the BusLoads card I would check all diodes. Particularly the 16 (?) D662 (type), D192 (number), D62+D63.
I have checked 12 cards last time and most that did not work have some broken diodes there.
Click to expand...
Thanks for the suggestion. It is inserted already but I have not powered it up yet so I can easily do this.
 
RolexTM said:
Built a interface for the MUSIC program - a FlipFlop - calibrated output signal length and wired it to the spare "command" 6750 on the RX8E M8357R floppy controller.
Click to expand...
This is not something I considered. The IOT decoding is already done for you making this really convenient. Very clever!

RolexTM said:
Tried to transfer the new source to the PDP8, found no way to do so since it seemed to big for every editor and PIP.
Click to expand...
I have a special mode for this in my Console Serial Disk TTY emulation. It sends a character and waits for the echo. This runs at half the max transfer rate but it does work. This lets it work with PIP which is restricted to files of up to 2k. I still have not got around to fixing the end of line problem when lines are longer than what the TTY handler expects for a max line length. It bails when it sees the unexpected CR/LF pair so you have to limit the max line length to less than 72 characters. This is a feature of the TTY handler that automatically inserts a CR/LF instead of just beating a hole in the paper at the right margin on the teletype.

CSD is available on Github. Console Serial Disk
 
The only difference between the 8/a M8320 and the 8/e M8320 is the removal of R55 from the 8/a modified version. This is a 470 ohm resistor and it connects a signal to test pin AA1. This pin is not bussed and is only a test pin on the regular Omnibus. On the 8/a it looks like this pin is used on the first slot to provide an additional +5v for the M8315 CPU. With this info I should be able to use the M8320 for the 8/a on my e if that becomes necessary since I am not going to look at that pin on the backplane anyway.

An obvious difference between the 1973 boards and the 1977 board is the replacement of Q1 (DEC 4008) with three discreet transistors. The DEC 4008 is a TI manufactured 14 pin DIP package containing at least 3 but probably 4 transistors. This looks like it was manufactured this way as it does not look like anyone did any work after the original soldering. I can't read the part number off the packages because there is a translucent plastic cap on all three components.

I have used the diode test function in my Fluke and all those that don't have a resistor paralleled look good so far. Still have quite a few to look at though,
 
I didn't find any BAD diodes on the board I was using but I have two other M8320 Bus Loads cards that work in the last slot of the rear backplane where it is supposed to be. Ran them for about half an hour each. The flakey board only runs a couple of minutes and then the machine halts (run flipflop clears) and after that It takes a power off to get the Load address switch to work. So something is failing when it gets warmed up.

Next I will move the memory to the rear backplane. Currently only the Bus Loads card is back there. This machine has a pair or 8k core memory board sets for 16k. I would like to find a couple more of these but they have become rare.
 
DougIngraham said:
This is not something I considered. The IOT decoding is already done for you making this really convenient. Very clever!
Click to expand...
Thank you! This was some coincidence, I first would build a decoder myself but realised I have no correct edge connectors.
Next step was attaching myself to the replica RX8E card, and when looking at the card documentation it became apparent that everything is already there :)

6750 - SEL​

For the VT78 and later interfaces for the RX01/RX02, this command loads the least significant bit of AC into the drive pair select register. These machines supported two drive pairs. On the earlier RX01/RX02 interfaces, the drive pair was selected by using a different device address for each pair of disk drives.

as for PIP and CSD, I did not know a solution using only a single port existed (We have no additional port). Using
the RX drive always was planned though since we had multiple drives. No controller though...

So currently I am happy with the RX-only setup. It is reasonably fast and the drive runs like a champ now after being repaired.
klonk .... ka-klonk.... klonk .... I love it :D . Funnily, as long as the drives are in access they are really quiet... compared to the rest of the stuff I mean 😅

The M847 Card from Roland is hands down the best thing that could happen to our /8. I modified the design in omitting the quartz and using the internal oscillator
of the µC and using minicore instead of arduino core. FIY minicore/tinycore/mightcore are alternative arduino cores that let you run the chips with a bare minimum of external components, I have used all of them a lot and never had incompatibilities and do not have to solder in external oscillators :D ....

Alex
 
DougIngraham said:
I didn't find any BAD diodes on the board I was using but I have two other M8320 Bus Loads cards that work in the last slot of the rear backplane where it is supposed to be. Ran them for about half an hour each. The flakey board only runs a couple of minutes and then the machine halts (run flipflop clears) and after that It takes a power off to get the Load address switch to work. So something is failing when it gets warmed up.
Click to expand...

Sounds like a bad diode. I had one on a core memory card that worked find until you ran the memory diag.
 
DougIngraham said:
I did a bunch of benchmarking this afternoon and evening. I've written an analysis of implementing a stack and when I timed the first of the call/return pair implementations the real times were shorter than calculated. What I discovered is that an indirect reference only adds 1.2us to the execution time on the KK8E (8/e, f, m, and some 8/a machines). I previously thought the DEFER (indirect reference) added 1.4us on that CPU.

For the KK8E CPU other than the EAE instructions all instructions are some combination of 1.2 us for the FETCH, 1.2 us for the DEFER (indirect reference) and 1.4 us for the memory reference. Here are some examples.

AND, TAD, ISZ, DCA and JMS are 2.6 us. If any of them have an indirect reference then 1.2us is added bringing the total to 3.8us.
IOT, OPR and JMP are all 1.2us. A JMP I adds 1.2us bringing the total to 2.4us. IOT's can be extended by the device.

All the other CPU's (except the 8/s) have more fixed timing and are easier to do the calculations since all three instruction parts have the same timing. The Straight 8, LINC-8 and KK8A (M8315) have 1.5us for each part. This means the instructions are all some multiple of 1.5us. The 8/i, 8/l and PDP-12 are slightly slower at around 1.6us. The CMOS CPU's have more complicated timings. Additional time is added for a modify type memory cycle.

I will post my stack code and analysis here when I get all the code tested and timed.
Click to expand...
Doug,

Back in the day, I remember both EduSystem 10 Basic and 4K Focal used PSHJMP/POPJMP macros to implement a return stack. You might be able to use those routines as a starting point. Depending on how you handle stack overflow, underflow and whether you use a ring buffer or not, the code might not be too complicated. It's too bad that 0010 - 0017 are auto increment only and not also auto decrement.
 
Last edited:
Playing with the 8/e today. Moved the 2nd 8k of core to the rear backplane. Still seems good. Decided to compile and run some diagnostics. A while back I key in the source for maindec-8e-d0ab because we had the listing and binary but no .PA file for it. There is a listing in the documentation. I got that done and it is available on Vince's site. This is instruction test 1 which is a large program. I set everything up and hit the F6 key on my csd server which should send a text file to pip and handshake with the echoed characters. It got to the line /TAD TEST 14 and then my program errored out because it received a 0252 code instead of the tab. A 0252 is the * character which is the PIP prompt. This should only show up if pip gets an EOF from the TTY handler. It happens sometime after 8k characters have been received after a return character. I thought my program was doing something wrong but it looks like an issue with PIP or the TTY handler. I am using the image GWiley gave me with the RK05 emulator which looks like it came from the Pidp8 build. I will probably boot csd and try it there. The base for my csd distro is also from the Pidp8 build but a couple of years older. RESORC shows the version E of the TTY handler which is the one I have sources for. Of course it doesn't mean someone didn't change something and not change the version number.

So much fun!
 
BitWiz said:
Doug,

Back in the day, I remember both EduSystem 10 Basic and 4K Focal used PSHJMP/POPJMP macros to implement a return stack. You might be able to use those routines as a starting point. Depending on how you handle stack overflow, underflow and whether you use a ring buffer or not, the code might not be too complicated. It's too bad that 0010 - 0017 are auto increment only and not also auto decrement.
Click to expand...
PALIII also has its own set of routines for this sort of thing, although there's a few pieces of symbol indirection before you get to the macro for the JMP I version
 
More on the CSD text file upload issue I was seeing yesterday. Here is the what I do to upload a text file. The text file is in Unix line ending format which is \n (newline) for the line terminator. When you press F6 the file "textfile" is sent one character at a time and then the program waits for the echo of that character. If the character is the newline, then a 0215 (carriage return with MSB set) is sent followed by a wait for the echo. Then a 0212 (linefeed with MSB set) is sent and then wait for that to echo. Normal characters are converted to uppercase and a 0200 is ored against the character to set the MSB which is what an ASR33 or ASR35 would do. When all the characters are sent CSD sends a ^Z which signals an EOF. What you see is something like this:
Code: 
$ ./csd
Console Serial Disk Version 1.2 (Beta)
<at this point you boot the PDP-8>
.R PIP
*FILE.PA<TTY:
<at this point you press F6 and the file is sent>
*^C
.
I was thinking there was something wrong with the 8/e since it was stopping early. I was getting about the first 20 blocks of the file which is a little over 8k. It was always stopping at the same place. I shortened the file to one line before it was stopping and commented out the line sending the ^Z so PIP would let me type. I could type anything I wanted on that last line. It could be just a return or 70 characters. Length didn't matter. When I hit the return I would get a *. The file would contain everything on that line I typed. I shortened the file by one more line and it let me enter a line and then enter a second line. It was the number of lines, not the number of characters. After a bunch more goofing around I realized that the PIP and TTY: handler would only accpet 549 lines and then it was getting an EOF from somewhere. I was able to send my long file as 7 pieces each of which ended up being 549 lines long and the final one being a bit shorter. I was able to use PIP to concatenate all of these together so probably not something in PIP. It almost has to be something in the TTY handler. I talked to Vince and he is looking at the source. I plan to look at this as well.

I generated a a couple of test files with a short C program. The core of it is

for( i=1;i<560;i++) printf("%d\n", i);

That generates a <2k file to be sent. I changed the %d to %70d and made an almost 40k file. When sent both stop at the end of line 549.

The 8/e ran all day long with the cover off. I was able to assemble D0AB.PA (Instruction test 1). I think the machine is mostly working, I will know for sure when it passes all the diags.

I am going to look at the Super TTY handler (KL8E.PA) and see if I can figure out why it is generating an EOF at the end of line 549. I do know that it keeps track of lines so that it can do a form feed so there may be some weird interaction with that code. Does not make a lot of sense.

If it is 50 years old, is it a bug or a feature?
 
It is the same for me, although I don’t remember exactly at which line. No matter how slow, you send, at some point PIP will just return to its prompt. No emulated disk though, real RX02. Must be some buffer limit I thought but I never found anything about a specific limit in the documentation.
 
RolexTM said:
It is the same for me, although I don’t remember exactly at which line. No matter how slow, you send, at some point PIP will just return to its prompt.
Click to expand...
Thanks for giving another data point. I am almost certain the problem is coming from the 2 page super tty handler. If you get a chance could you run RES /E and let me know what the TTY device line looks like. If you fire up your 8 to do this could you also give PIP the /V command which displays its version number. Not critical for solving this but would satisfy curiosity.
RolexTM said:
No emulated disk though, real RX02. Must be some buffer limit I thought but I never found anything about a specific limit in the documentation.
Click to expand...
The RK05 drive is emulated, the controller is real. And it happens on my virtual CSD devices as well. I was originally concerned that it was a bug I introduced but that is not the case. It is not a buffer limit, I am pretty sure if you send 550 CR/LF pairs it will stop after 549 is accepted. My short test printed the line number followed by CR/LF. I did a long line test sending test with 72 character lines which makes the file length 39528 characters. Of course PIP packs these 3 characters per 2 words so the file length ended up 103 blocks. The documentation for PIP gives a maximum line length of 140 characters. Telling it to do tab expansions could pretty easily exceed that length and it would issue an error. PIP itself does not have any problems copying a file with lots of lines. I combined the pieces of the file using PIP and then copied the whole thing from the RK05 device to a CSD image. It looked like this.
Code: 
. R PIP
*D0AB.PA<INS1.PA,INS2.PA,INS3.PA,INS4.PA,INS5.PA,INS6.PA,INS7.PA
*CSD1:D0AB.PA<D0AB.PA
*^C
.
Each one of those pieces was made by letting PIP do its thing and then I deleted the front 549 lines of the file I was trying to send. Repeat until done.
 
I wrote a little program to repeatedly call an instance of KL8E.PA which was modified to call routines which fake KCC, KSF, KRS and KRB, returning the characters CR and LF alternately .

I ran it in SIMH and it stopped at the HLT I put in for block number overflow (4096 blocks read).

Interestingly, the output (echo) was only 4096 lines. Setting breakpoints reveals that the driver is returning after every CR, which ends the input block. ( The comments in the source hint at this.) The first read is one character (CR). Subsequent reads are two characters long (LF, CR). (Rest of the block presumably full of NUL.)

Weird, and doesn't explain what Doug is seeing.
 
Last edited:
I moved my first 8k to the rear backplane and bit MD8 isn't making it to the memory board. I thought it was the M935 because I swapped them and the problem went away. Should have moved to MD4 but instead everything started working. Now I am confused. I am trying to scope that signal to see if it is making it to the rear backplane. Interestingly, the front backplane has gold plated pins while the rear one they look like tinplate. I had thought that this machine might have been originally just a 20 slot chassis and someone tried to expand it before I got it. I wish there was better information about the DECset 8000 configuration as shipped.
 
I have given up trying to figure out what is wrong with the 2nd backplane for now. There may be a cracked foil on the backplane that is marginal.

Went back to work on the issue with the Super TTY handler. I assembled the old default tty handler called ASR33.PA and installed it with BUILD, rebooted and everything works as expected. In fact better than expected because the text is coming in at the expected speed which is about half the full character rate. I had noticed that it was slower and didn't realize just how slow it was with the Super TTY handler.

Next I uploaded my copy of the KL8E.PA from OS8/V3D off of Charles Lasners DECtapes on Ibiblio. Assembled and installed using BUILD. Reboot and try with known sources. Still stops at the 550th line. So probably not a corrupt build.

The fan drone is getting to me so I think I will call it for the evening. Will pick this back up tomorrow looking at the KL8E handler sources.
 
Trying to figure out the 549 line issue when copying ASCII text into PIP. I have verified that the ASR33.PA handler works fine. I just finished reading through the code so I can understand what it does since it does it correctly.

When sending to the TTY device all codes are sent until either the buffer is exhausted or a ^Z is encountered. Either 0032 or 0232 are both considered ^Z. The ^Z is not sent to the teletype. The normal return back to the caller is taken. If a ^C is typed during this operation, then the operation is aborted and control is sent to OS/8. If a ^O is received then control is immediately returned to the calling program. The ^O will still be in the input buffer on successive calls to the handler so an ^O will discard all output until the calling program stops trying. The sending part is not the section that causes the PIP problem but so much code is shared between send and receive I ended up going through the send code as well.

When receiving from the TTY device a ^C is treated as a return to OS/8. All other characters are placed in the buffer using the standard OS/8 three eight bit characters packed into 2 words. The character is echoed back out to the TTY device. If the character was a carriage return then a line feed is also sent out. If the character was a ^Z then the rest of the eight bit characters in the buffer are zeroed and the error return is taken with the AC set to 1. A normal return is taken when the last word of the buffer is filled.

Other than the convoluted coding the above is pretty much exactly what I expected to see, The handler uses every word available and uses tricks like forcing code to be in certain locations in order to be able to use an instruction as a constant. They also use the return address of a couple of the subroutines as a temporary storage location. I tip my hat to whoever spent the time to make this fit.

Next I get to study the much larger and more complex Super TTY handler (KL8E.PA). What I am going to look for specifically is some alternate path that generates an error return from the handler with a positive number in the AC. That is the signal for an EOF. I did have a thought that the issue could be in PIP. Some kind of sanity check. Afterall, 549 calls where the returned data could be as much as 2k words per call is 1.7 megabytes. That would be considered an enormous file on an 8.
 
You must log in or register to reply here.
Back
Top