• Please review our updated Terms and Rules here

Have a DEC Professional? Please run it for me!

vol.litwr

Experienced Member
Joined
Mar 22, 2016
Messages
325
I have recently got results for number pi calculator runs on the Soviet clone (Elektronika 85) of the Pro-350. The results under RT-11FB 5.01 are: for 100 digits - 0.92s, for 1000 digits - 56.15s, for 3000 digits - 486.28s.
It would be very interesting to compare these results with results from genuine machines (Pro-325, -350, and -380). Screenshots are optional but they are welcome. The number π calculator page is here. This page contains sources for RT-11, RSX-11, 2.11BSD, and AT&T Unix v7. I gather results for EIS-of and noEIS driver versions. Many thanks in advance.
 
interesting project, how did your soviet clone perform ? does it come close to the J11? I dont have one of those systems but maybe someone here can help you
 
I dare to repeat my request. It would be great to get results from a genuine machine.
interesting project, how did your soviet clone perform ? does it come close to the J11? I dont have one of those systems but maybe someone here can help you
The first Soviet personal PDP-11 was the DVK that was released in 1981. They used the original Soviet processor K1801VM1 that doesn't support protected mode, FIS or even EIS. But it was faster than the F11 for integer computations. So the DVK was faster for integer computations than the Pro 325 and 350.
The Elektronika-85 was released in 1985 and it was an almost exact copy of the Pro 350.
The Pro 380 was superior to the all Soviet personal PDP-11. The later DVK used the K1801VM2 (EIS was added), K1801VM3 (protected mode was added), K1801V4 (it is a FIS co-pro). But they were slower than the Pro 380.
 
Here are results for the DEC PRO 380 with RT-11 v5.3. I used the pdp-11/rt-11/pieis macro code (extended instruction set) from the rosetta-pi-spigot github. I hand typed the macro-11 code, manually reviewed it several times and confirmed the PI value is consistent and at least the first 10 or so digits match my calculator. Unless I typed in something wrong, there is a small issue with the printing of the time. I gather from runs with a small number of digits that the time is printed after the value of PI on the same line. However, as the number of digits grow, the value of PI hits the edge of the screen, does not wrap and the time is smashed in the last digit, which seems to overwrite. I fixed this in my version by introducing a .print #eol in the printsec routine after the moves of r1 and r0 and then I restore r0 from r1. I don't think this will affect the results.

With three runs all with consistent results:
100 digits: 0.43 - 0.45 sec
1000 digits: 22.98 sec
3000 digits: 192.70 sec

How does this compare?
 
Here are results for the DEC PRO 380 with RT-11 v5.3. I used the pdp-11/rt-11/pieis macro code (extended instruction set) from the rosetta-pi-spigot github. I hand typed the macro-11 code, manually reviewed it several times and confirmed the PI value is consistent and at least the first 10 or so digits match my calculator. Unless I typed in something wrong, there is a small issue with the printing of the time. I gather from runs with a small number of digits that the time is printed after the value of PI on the same line. However, as the number of digits grow, the value of PI hits the edge of the screen, does not wrap and the time is smashed in the last digit, which seems to overwrite. I fixed this in my version by introducing a .print #eol in the printsec routine after the moves of r1 and r0 and then I restore r0 from r1. I don't think this will affect the results.

With three runs all with consistent results:
100 digits: 0.43 - 0.45 sec
1000 digits: 22.98 sec
3000 digits: 192.70 sec

How does this compare?
Thank you very much for your valuable results! However, you have made me quite embarrassed. Why are you writing code by hand? Why didn't you use a transfer file utility? You can use PUTR. It is for DOS, but the emulator DOSBOX is available for every platform and is very easy to use. Just run DOSBOX from a command line in a directory where the disk image, your RT-11 files and PUTR.COM are located. The sequence of commands may look like this:

Code:
dd if=rt11v53.rd of=rt11v53.rdx bs=512 skip=1
dosbox
mount . c
c:
putr
mount a: rt11v53.rdx /rt11
dir a:
dir c:
copy/binary c:pieiso.sav a:
copy c:pieis.mac a:
dismount a:
dd if=/dev/null of=zero512 bs=512 count=1
cat zero512 rt11v53.rdx >rt11v53.rd

dd is a standard Unix/Linux/MacOS-utility but it may be installed under Microsoft Windows too. We must trim the first 512 bytes before using PUTR.

However, instead of PUTR, I dare to recommend the use of RT11DSK, which is specifically designed for RT-11 disk images. Instead of the previous sequence you can just use one command:

Code:
rt11dsk a -o512 rt11v53.rd pieiso.sav pieis.mac

You can also use this utility to show the directory

Code:
rt11dsk l -o512 rt11v53.rd

and to do other useful actions.

Of course it is rather odd that they turned the automatic wrapping off on the Pro. This gives you a strong feeling of a mainframe user where the automatic wrapping is not possible. :) You can turn the wrapping on by the next command

Code:
setup wrap

or you can print the control code sequence using the attached program.

EDIT. Would you like to run PIEISO (PIEIS DIVOF=1) again? The absent of the automatic wrapping is a kind of cheating for me. The results of PENOEI will be very valuable too. The compiled executables for RT-11 are already present in the xz-archive. Many thanks in advance.
 

Attachments

  • AUTOWR.zip
    474 bytes · Views: 4
Last edited:
Thank you for the file transfer education and info on the line wrap. This is exactly what I needed to move files between systems. I built the rt11dsk utility on a modern Windows system, updating the platform version from 2013 to my 2022 Visual Studio. I found the option flag was a "/" instead of a "-" on my system. Although I found this through debug, the command line help will show the proper flag for the system. Also, rt11dsk only takes one file at a time when adding to the disk image. Thanks for including the directory list option to confirm a good file addition.

Code:
rt11dsk a /o512 <dskimage> <filename>.sav

I found the archive .sav (executable) files and tested all 5. Below are the results for 3 runs of each.

File1000 Digits (sec)1000 Digits
(sec)
3000 Digits
(sec)
pieis.sav0.45 - 0.4724.33 - 24.35204.82 - 204.83
pieiso.sav0.45 - 0.4723.00192.75
pieisn.sav0.68 - 0.7035.88 - 35.91300.69
pinoeh0.80 - 0.8357.07485.15
(2960 max digits)
pinoei.sav0.83 - 0.8560.48512.30 - 512.32
(2952 max digits)

So, my earlier results with the pieis.mac that I typed in match pieso.sav. That pieis.mac source file does have DIVOF = 1 even though it is not labelled as "pieiso.mac". The pieisn.sav results are probably not meaningful since it fixes a timer issue not on this machine. When I tried to move the .mac source files, they did not open well in the editor. I could see the ACSII text, but the lines were not formatted correctly and there were some graphic characters. It looks like a line return issue. Is there a quick fix for this? They do assemble, link and run.

What is your take on the PRO 380 results?
 
I think I missed something. Your explantion of using PUTR or rt11dsk does what? Creates a file system that rt-11 can read (I assume). How does not get that to the Pro? I would like to be able to put files on my Pro, but so far nothing I have tried works for me.
 
That was the same problem I faced. RT11DSK allows me to add, extract, and delete a file in a disk image file (DSK). I then take the DSK and insert it into my DREM drive. The SD card in my DREM is the portable memory device that works with my Windows system. Although I have a vintage drive for the DEC, the DREM is very handy for this type of thing.
 
Ok, this now makes sense. I no longer use Windows but believe rt11dsk can be built on Mac and Linux too. I have Dave's MFM device. Don't know if it supports that. I don't plan on buying a DREM. Thanks for the info.
 
Thank you for the file transfer education and info on the line wrap. This is exactly what I needed to move files between systems. I built the rt11dsk utility on a modern Windows system, updating the platform version from 2013 to my 2022 Visual Studio. I found the option flag was a "/" instead of a "-" on my system. Although I found this through debug, the command line help will show the proper flag for the system. Also, rt11dsk only takes one file at a time when adding to the disk image. Thanks for including the directory list option to confirm a good file addition.

Code:
rt11dsk a /o512 <dskimage> <filename>.sav

I found the archive .sav (executable) files and tested all 5. Below are the results for 3 runs of each.

File1000 Digits (sec)1000 Digits
(sec)
3000 Digits
(sec)
pieis.sav0.45 - 0.4724.33 - 24.35204.82 - 204.83
pieiso.sav0.45 - 0.4723.00192.75
pieisn.sav0.68 - 0.7035.88 - 35.91300.69
pinoeh0.80 - 0.8357.07485.15
(2960 max digits)
pinoei.sav0.83 - 0.8560.48512.30 - 512.32
(2952 max digits)

So, my earlier results with the pieis.mac that I typed in match pieso.sav. That pieis.mac source file does have DIVOF = 1 even though it is not labelled as "pieiso.mac". The pieisn.sav results are probably not meaningful since it fixes a timer issue not on this machine. When I tried to move the .mac source files, they did not open well in the editor. I could see the ACSII text, but the lines were not formatted correctly and there were some graphic characters. It looks like a line return issue. Is there a quick fix for this? They do assemble, link and run.

What is your take on the PRO 380 results?
What a great day! I've got results from such an interesting and rare machine. Please ignore all SAV-files except PIEISO and PINOEI. You can try to compile them to get newer versions but their speed is the same. The only difference is that the newest PINOEI can print 4 more digits. The results are entered into the table. It is surprising that the results of the 11/73 are slower: the 11/73 has the J11@15MHz while the Pro-380 uses the J11@10MHz. IMHO this is because the 380 has faster RAM.
It is a shame on me that I missed that there is no room for 3000 digits. Sorry about that. Actually it is very odd that RT-11 gives us so little amount of free memory. The 11/73 can print more than 7100 digits. Actually I am very confused by this fact. Maybe the PDP-11 experts can explain it.
However I have some means that let us free some amount of memory. We have to edit STARTX.COM. Let's comment the spooler lines
Code:
!SRUN SPOOL/PAUSE
!LOAD LS=SPOOL
!RESUME SPOOL
!ASS SP0 LP
!ASS SP0 LP0
!ASS SP0 LS
!ASS SP0 LS0
I've also added a useful line
Code:
SETUP WRAP
Would you like to make one more test of PINOEI?
You can also try to use the FB monitor, this can even affect the performance slightly. Just issue the next command.
Code:
COPY/BOOT RT11FB.SYS SY:
You can also add the SETUP WRAP line into STARTF.COM and reboot. You can return the more advanced default XM monitor with
Code:
COPY/BOOT RT11XM.SYS SY:
It is odd that I can't use the SJ monitor. It causes the system to hang. :( Only experts can explain this too.
It would be great if you could make a screenshot with one of the results.
It seems we have the old text conversion problem. I use Linux and this suggests the NL code in the end of lines. RT-11 (like Microsoft Systems) uses the sequence CR and NL. Under Linux I use the sed utility to fix this
Code:
sed 's/\r\$/' infile >outfile
Under Microsoft Windows you can install sed or use other means for instance the Notepad++ editor which is a free and very powerful tool for programming.
Ok, this now makes sense. I no longer use Windows but believe rt11dsk can be built on Mac and Linux too. I have Dave's MFM device. Don't know if it supports that. I don't plan on buying a DREM. Thanks for the info.
I hope to get results from your system soon. ;)
 
I commented out all the spooler and printer stuff, which freed up memory, allowing up to 3592 digits with PINOEI. I tested PINOEI again and got a surprising result. The new 3000 digit time was less than the 2952 digit time of 512.32 that I previously reported. The machine got faster. I tested PIEISO with the same result. Below are the new results:

File100 Digits1000 Digits3000 Digits
pieiso0.42 - 0.4321.95 - 21.98184.05 - 184.07
pinoei0.80 - 0.8257.75505.07 - 505.08

Less context switching or interrupt servicing? I restored the spoolers and confirmed the prior results for PIEISO (100, 1000, 3000 digits). Attached is a screen shot of the new 184.07 result.
 

Attachments

  • PIEISO_380.JPG
    PIEISO_380.JPG
    339.8 KB · Views: 11
I commented out all the spooler and printer stuff, which freed up memory, allowing up to 3592 digits with PINOEI. I tested PINOEI again and got a surprising result. The new 3000 digit time was less than the 2952 digit time of 512.32 that I previously reported. The machine got faster. I tested PIEISO with the same result. Below are the new results:

File100 Digits1000 Digits3000 Digits
pieiso0.42 - 0.4321.95 - 21.98184.05 - 184.07
pinoei0.80 - 0.8257.75505.07 - 505.08

Less context switching or interrupt servicing? I restored the spoolers and confirmed the prior results for PIEISO (100, 1000, 3000 digits). Attached is a screen shot of the new 184.07 result.
Thank you very much. The table has been updated and the screenshot added there. Your results are fantastic. They show that the Pro 380 can be faster than the fastest PDP-11 (like 11/70 or 11/93)! This result is hard to understand. Of course, the 11/70 and 11/93 results came from systems that have more overhead for system tasks but the overhead can't be that much! So I am just very perplexed. I am going to start a new thread about several mysteries around the Pro that have been discovered thanks to your tests.
Would you like to make the last test? I request this because I got several complaints that the system character output routine affects results too much. So my code allows to disable the use of this routine. You just need to set IO=0. However I prepared the executable PIEISY.SAV that is PIEISO compiled with IO=0.
The pi-spigot algorithm speed depends heavily on the division implementation speed. So it can't be considered as a comprehensive system performance test. I also have a program that can show results for a more balanced mix of instructions. I need some time to make a variant for the Pro, the success of our experiments around the Pro graphics is also a necessity.
 

Attachments

  • PIEIY.zip
    880 bytes · Views: 1
Last edited:
Because of the great performance shown by the 380, I am beginning to think that there may be something wrong with my timing code... IMHO it would be useful to check a run with a stopwatch.
 
I performed the stopwatch test on the PIEISO code, both with and without the spooling tasks. In both cases, the stopwatch time was within a few tenths of a second of what was reported, and that difference is probably my reaction time. I would say your time estimate is accurate. Below are the results for PIEIY. The results keep getting faster. It makes me wonder now if monochrome or color video makes a difference because of the additional planes - probably not, especially with PIEIY because there is no printing of the numbers, just the time. All results to date have been with color video.

File100 Digits1000 Digits3000 Digits
pieiy0.22 - 0.2319.82 - 19.83177.65 - 177.67
 
I performed the stopwatch test on the PIEISO code, both with and without the spooling tasks. In both cases, the stopwatch time was within a few tenths of a second of what was reported, and that difference is probably my reaction time. I would say your time estimate is accurate. Below are the results for PIEIY. The results keep getting faster. It makes me wonder now if monochrome or color video makes a difference because of the additional planes - probably not, especially with PIEIY because there is no printing of the numbers, just the time. All results to date have been with color video.

File100 Digits1000 Digits3000 Digits
pieiy0.22 - 0.2319.82 - 19.83177.65 - 177.67
Thank you! Your results show that my formula, which automatically separates times of the calculation and character output, is quite good for this case. It gives us 177.5, this is less than 0.01% of error.
BTW is there any chance that your Pro is somehow overclocked? Wikipedia mentions that the design of the 380 suggested 16-18 MHz. I still can't imagine how the 10 MHz Pro can be faster than the 11/93.
EDIT. Would @czunit like to add some help around your super-fast results? It would be great if he would run PIEISO on his 380 and post the results.
 
Last edited:
I am the original owner and have not modified my PRO 380 outside of adding option cards and replacing the hard disk. There is talk of a clocking issue on the motherboard that forced DEC to reduce the clock speed to 10 MHz, but I have yet to find this problem described in official DEC literature. In the tech manual, there is a diagram showing a 20 MHz clock feeding a J11 gate array that serves main memory and feeds a 10.06 MHz clock to the J11.
 
I am the original owner and have not modified my PRO 380 outside of adding option cards and replacing the hard disk. There is talk of a clocking issue on the motherboard that forced DEC to reduce the clock speed to 10 MHz, but I have yet to find this problem described in official DEC literature. In the tech manual, there is a diagram showing a 20 MHz clock feeding a J11 gate array that serves main memory and feeds a 10.06 MHz clock to the J11.
Thank you. It was my miss again. :( I compared the NOIES version on the 11/93 and the EISO version on the Pro 380! So your results are quite consistent with other measurements.
 
Back
Top