FPP12 and Fortran IV problem

[Christoph C]

Hello to all of you,

thank you for the add to this group :)  I wanted to ask something I found while working with Fortran IV and the PiDP-8:

If you try the following program with simh: set fpp enabled

DOUBLE PRECISION PI

PI=22.D0/7.D0 

END

you can start it and then the PiDP 8 just shuts itself off ... what am I doing wrong?

Greetings, Chris

[Rick Murphy]

I don't see this issue - when I run this, either by compiling/loading/running or by "EXEC DBL.FT".

I suspect you're running a disk image with an incompatible collection of F4 components. 

This is the real value of the work people have done to build pristine OS/8 components from source - what gets built is known to be a proper set of components, each of which is consistent with the others.

(The Fortran runtime has to be the same version as the libraries; if not, things don't work as the libraries and compiler have hard coded addresses of things in the runtime; if those are incorrect, chaos happens.)

    -Rick

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/c70c4837-c17d-48b8-8ea9-4c8f879b68d1n%40googlegroups.com.

--

Rick Murphy, D. Sc., CISSP-ISSAP, K1MU/4, Annandale VA USA

[Christoph C]

Thank you for your fast answer :)    Ok, i built the whole OS8 Image with the classical installation process described on tangentsoft. I did not change anything.

I do the classical way with: .COMPILE <name> and then .EXE <name> but i dont really know what is wrong with my image. Should I rebuild OS8 or insert another F4 compiler or runtine system?

[MogensB]

When I compile FORTRAN, I do the following steps (replace PROG with your program filename):

.R F4

*PROG,PROG,PROG<PROG

After compilation, the program can be loaded and run with:

.EXE PROG

[Rick Murphy]

This program, created as DATAN.FT

        DOUBLE PRECISION PI

        PI=DATAN(0.25)

        STOP

        END

Then

.COMPILE DATAN.FT

.EXEC DATAN

just gives me another OS/8 prompt.

My system details:

PiDP-8/I trunk:id[d80d302db1] [pi3b] [ils] [stdpcb] [gpio] [rt]

PDP-8 simulator V4.0-0  Current       git commit id: ab48f313

Loading OS/8 from the RK05 cartridge disk...

PiDP-8/I Initial throttle = 333000 IPS

PiDP-8/I release id:[280c662a13] - OS/8 V3D - KBM V3Q - CCL V1F

    -RIck

--

You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/f6d13104-4e1c-4c6f-9f16-ae966888b975n%40googlegroups.com.

[Christoph C]

Ok and when you insert: WRITE(4,10) PI   

10 FORMAT(D20.10) or Dw.d    with w<255 and d<w?

[Rick Murphy]

The output is 

  0.3142857143D+01

    -Rick

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/6ddfdaf2-4299-4418-9972-3ad3af9bfda0n%40googlegroups.com.

[Steve Tockey]

All,

I'm not having any problems with F4. See the two attached .txt files, both are F4 programs that calculate E. One is single-precision, the other is double.

BTW, you don't need to explicitly run the compiler (e.g., .R F4) before you use the EXEC command. EXEC automatically re-compiles as part of its process.

Here's what I get with ESGL:

.EX ESGL

I =   1 E = 1.9999998807907
I =   2 E = 2.5000000000000
I =   3 E = 2.6666665077209
I =   4 E = 2.7083331346511
I =   5 E = 2.7166664600372
I =   6 E = 2.7180552482604
I =   7 E = 2.7182537317276
I =   8 E = 2.7182781696319
I =   9 E = 2.7182811498641
I =  10 E = 2.7182817459106
I =  11 E = 2.7182817459106
ALL DONE

.

And here's what I get with EDBL:

.EXEC EDBL

I =   1 E = 0.199999999999999999826527652402D+01
I =   2 E = 0.250000000000000000000000000000D+01
I =   3 E = 0.266666665673255920410156250000D+01
I =   4 E = 0.270833332091569900512695312500D+01
I =   5 E = 0.271666665375232696359730777402D+01
I =   6 E = 0.271805554255843162189676398554D+01
I =   7 E = 0.271825395524501800537109375000D+01
I =   8 E = 0.271827875683084130113698062558D+01
I =   9 E = 0.271828151256249838686740449844D+01
I =  10 E = 0.271828178813564136362401768565D+01
I =  11 E = 0.271828181318774752574241038161D+01
I =  12 E = 0.271828181527542289686039111984D+01
I =  13 E = 0.271828181543601332670334613794D+01
I =  14 E = 0.271828181544748406425759945648D+01
I =  15 E = 0.271828181544824878240751431235D+01
I =  16 E = 0.271828181544829656536566009350D+01
I =  17 E = 0.271828181544829937561769117593D+01
I =  18 E = 0.271828181544829953174280401384D+01
I =  19 E = 0.271828181544829954041642139372D+01
I =  20 E = 0.271828181544829954041642139372D+01
ALL DONE

.

-- steve

[Warren Young]

On Thursday, December 30, 2021 at 12:53:25 AM UTC-7 geni...@gmail.com wrote:

i built the whole OS8 Image with the classical installation process described on tangentsoft. I did not change anything.

Did you start from scratch, or are you upgrading an earlier installation?

If the latter, it's likely you're still running on the old OS/8 media. Details and remedies here.

[Steve Tockey]

Chris,

A while ago I posted some simulated DECTape images of different languages on DropBox:

https://www.dropbox.com/sh/0426m8pjzffe3s7/AADjf9KOSIC8IqAaj3Nbl4LMa?dl=0

The image v3d-F4.tu55 is a SYS: DECTape with a working F4 compiler and run time library set. The image F4src.tu56 is a DSK: is a DSK: tape that has some sample source code.

There's a README.txt file in that DropBox folder as well.

At a minimum you could simh attach the v3d-f4.tu55 image and copy off the compiler and the libraries for a working F4 configuration.

 

-- steve

[Christoph C]

Thank you for this archive. I will try to extract the files and run it!

[Christoph C]

So I tried it out and sadly this Fortran IV Double precision program shuts down the pidp8i simulator:

DOUBLE PRECISION PI

PI = DATAN(0.25)
WRITE(4,10) PI

10 FORMAT(D23.20)
END

I enabled fpp in the simh console and did:

.COMPILE PI

.EXE PI   

with the DECTape Image supplied by Steve. Is there something wrong with my Pi?

Greetings

[MogensB]

FWIW - I tested a similar program on my PiDP8 (which is a "standard installation"), and got the following result, which seems to be accurate compared to the result from my HP calculator doing an atan(0.25) operation:

.VER
OS/8 - KBM V3Q - CCL V1F

.TYPE PITEST.FT

      DOUBLE PRECISION PI
      PI = DATAN(0.25)
      WRITE(4,10) PI

10    FORMAT(D30.20)

      END
     
.EXEC PITEST

   0.24497867113904040967D+00

.

[Steve Tockey]

I will confirm getting the same results as Chris on a most-recent download of the entire PiDP-8/I kit--downloaded just yesterday, in fact. But I will add some detail from my testing. I'm using ESGL.FT, EDBL.FT, (both attached in an earlier post, above) and PITEST.FT as test case F4 programs.

If you use the default OS/8 v3d system disk (att rk0 /opt/pidp8i/share/media/os8/v3d.rk05 in 0.script):

.EXEC ESGL -- works fine with FPP disabled, as expected, giving single precision results

.EXEC EDBL -- works fine with FPP disabled, giving the NO FP error and calculating essentially the same results as single precision

.EXEC PITEST -- works with FPP disabled, giving the NO FP error and outputting 0.24497866630554199218E+00

Next, enabling FPP:

.EXEC ESGL -- works fine with FPP enabled, as expected, giving single precision results

.EXEC EDBL -- works fine with FPP enabled, giving double precision results

.EXEC PITEST -- crashes out of SIMH/PiDP-8/I exactly as Chris reports

If you instead use the OCK (v3t) system disk (change 0.script to att rk0 /opt/pidp8i/share/media/os8/ock.rk05)

.EXEC ESGL -- works fine with FPP disabled, as expected, giving single precision results

.EXEC EDBL -- works fine with FPP disabled, giving the NO FP error and calculating essentially the same results as single precision

.EXEC PITEST -- Gives the NO FP error then USER ERROR MAIN   0003, returning to OS/8 instead of crashing SIMH

Next, enabling FPP:

.EXEC ESGL -- works fine with FPP enabled, as expected, giving single precision results

.EXEC EDBL -- works fine with FPP enabled, giving double precision results

.EXEC PITEST -- Gives USER MAIN   0003, returning to OS/8 instead of crashing

According to the OS/8 (v3d) Error Messages manual (AA-H610A-TA), FRTS USER ERROR means an "Illegal subroutine call, or call to undefined subroutine. Execution continues only if the E option was requested:

So now, with FPP enabled:

.EXEC PITEST/E


USER ERROR MAIN   0003
   0.21995619999999999928D+07

.

And, with FPP disabled:

.EXEC PITEST/E
CAUTION - NO DP


USER ERROR MAIN   0003
   0.52441644668579101562E+00

.

So,

Message #1 to Chris: try running different F4 programs instead of just PITEST. It seems to be a special case. Try ESGL and EDBL, they will probably work, as will probably a lot of other Double Precision F4 code.

Message #2 to whoever cares: it looks like the OCK system may have a related problem but it's got far more benign behavior than v3d in that at least it doesn't crash SIMH/PiDP-8/I entirely.

Message #3, again to whoever cares: maybe the underlying root cause is a call to some missing library function, but OCK doesn't crash SIMH while v3d does. This might help narrow down to the root cause.

Cheers,

-- steve

 

[Christoph C]

Hello Steve,

thanks for your very detailed analysis. In fact I can (because of previous tests done by me) confirm your results with the recent build too. 

Sadly I wanted to write some programs to approximate Pi with the Wallis Product in single and double precision but the source always crashes the machine. So I don't know what are the essential steps to write a working double precision program ... :(

[Rick Murphy]

USER ERROR MAIN 0003 

This means that you don't have DATAN in your FORTRAN library.

Compile the code with a listing to see the line numbers, and 0003 is the "PI = DATAN(0.25)" line.

Looking at the V3D disk, I see a 73 block FORLIB.RL.

Looking at the OCK disk, I see a 165 block FORLIB.RL 

Listing the contents of the smaller library, I don't see any of the DOUBLE PRECISION routines - which may mean that it's not part of the v3d distribution.  So, Christoph, try using the OCK disk.

To list the library:
.R LIBRA

*RKA0:FORLIB.RL,TTY:<

    -Rick

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/0544b27b-6d73-430f-9604-51bad6f0a29dn%40googlegroups.com.

[Christoph C]

Even with another FORLIB.RL file where DATAN is included the Simulator will just stop...

[Steve Tockey]

What if you write your own implementation of a DATAN() function and link it in explicitly?

[Christoph C]

Steve,

this was also an Idea which I thought of but somehow even some simple tasks like Pi approximating with the wallis product crashes SimH

Another rather silly but cool Idea would be to implement my own Double precision calculation routines ... 

[Steve Tockey]

Chris,

I was playing around with implementing my own DATAN() function. I think I've figured out the root of the problem. The most likely implementations of ATAN() and DATAN() use a Maclaurin Series approximation (e.g., https://www.emathzone.com/tutorials/calculus/maclaurin-series-of-arctanx.html). To write than in straightforward Fortran IV, you need a statement something like this:

        RSLT = RSLT + ISGN * ( X**I / I )

The problem is that while X**Y is implemented for single precision, it's missing in double precision. Specifically, this very simple test program

C       EXPTST.FT
C       TEST EXPONENTIATION (**) IN F4

        DOUBLE PRECISION X

        X = 2.0
        X = X**3
        WRITE( 4, 10 ) X
        STOP

10      FORMAT( ' ', D30.20 )

        END

works fine with FPP disabled but crashes out of SIMH entirely with FPP enabled. So it looks like whatever the double precision X**Y function is called is missing in FORLIB.RL. The permanent fix should be to track down the original double precision exponentiation function and add it to FORLIB.RL. A work around could be to implement your own double precision X**Y.

And Rick, I'm seeing the opposite of what you're seeing with FORLIB.RL. I'm seeing the big (173 block) one on the v3d.rk05 disk image and the small (73 block) one on the ock.rk05 disk image.

Cheers,

-- steve

[Rick Murphy]

That crash is not reproducible. 

Only you and Chris seem to have the problem. What kind of Raspberry Pi are you using? 

Mine is 

$ cat /proc/cpuinfo | grep Model

Model           : Raspberry Pi 3 Model B Plus Rev 1.3

Evidence showing this working for me:

 .TYPE EXPTST.FT

C       EXPTST.FT
C       TEST EXPONENTIATION (**) IN F4

        DOUBLE PRECISION X

        X = 2.0
        X = X**3
        WRITE( 4, 10 ) X
        STOP

10      FORMAT( ' ', D30.20 )

        END

.EXEC EXPTST.FT
CAUTION - NO DP

    0.79999995231628417968E+01
.
Simulation stopped, PC: 01210 (JMP 1207)
sim> set fpp ena
sim> c
PiDP-8/I initial throttle = 333000 IPS
EXEC EXPTST.FT

    0.79999999999999999930D+01

So, it is not the compiler, libraries, etc. They're all just fine.

This is a SIMH bug of some kind which only exhibits for particular configurations.  We just need to figure out which ones :)

(SIMH should never crash out, regardless of what code is run on the emulated side.)

And yes - the v3d.rk05 (which is apparently what I'm using by default?) has the 173-block DP-enabled FORLIB.RL

Getting logs of what is happening here will probably require running the SIMH pdp8 emulator in a shell after killing the service so errors can be captured, not running under systemd.

    -Rick

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/8b6091e7-71ee-49fa-9600-2fb194040888n%40googlegroups.com.

[Steve Tockey]

Rick,

"Only you and Chris seem to have the problem. What kind of Raspberry Pi are you using? 

Mine is 

$ cat /proc/cpuinfo | grep Model

Model           : Raspberry Pi 3 Model B Plus Rev 1.3"

For me:

$ cat /proc/cpuinfo | grep Model

Model                : Raspberry Pi 3 Model B Rev 1.2

But, there's no guarantee it's limited to hardware. Pi OS version might be relevant. I believe that for Chris and I, we are both very recent. For me:

pi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

-- steve

[Steve Tockey]

Rick,

I actually have 3 PiDP-8/I in various configurations. My last report was from #1, on which I was developing the cycle-realistic version. This is from #2:

$ cat /proc/device-tree/model

Raspberry Pi 3 Model B Plus Rev 1.3

$ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
VERSION_CODENAME=stretch

ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

On this one EXPTST also crashes with FPP enabled.

-- steve

[Steve Tockey]

Rick,

Very interesting ...  Here is PiDP-8/I #3:

$ cat /proc/device-tree/model
Raspberry Pi 2 Model B Rev 1.1

$ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster

ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

EXPTST runs fine on this one with FPP enabled:

.
Simulation stopped, PC: 01207 (KSF)
sim> set fpp ena
sim> g
PiDP-8/I initial throttle = 416000 IPS

.
.EX EXPTST

    0.79999999999999999930D+01

.

-- steve

[Christoph C]

This whole probem gets more and more interesting wiith every post. I have a Raspberry Pi Model 3 Rev 1.3 and also did a complete reinstallation of SimH with fossil even the newest version has this problem. I think i will try to install everything onto my Pi 2 and test it there

How do I record errors in SimH when its crashing?

[Rick Murphy]

For me:

PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

So we have a data point here - Buster works. Stretch and Bullseye do not.

Time for me to upgrade to Bullseye and try this out.

    -Rick

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/67f47912-c855-43a8-8092-418afeec0c35n%40googlegroups.com.

[Rick Murphy]

Even more interesting. Upgraded to bullseye:

PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye

ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

Still not failing. I'm going to wipe and recompile in case it's some compiler optimization glitch.

    -Rick

[Rick Murphy]

That was the difference. Building using the tools on Bullseye and I'm getting a crash (segmentation fault) when running a DP program.

I'm looking into it, but it's going to be a bit of a challenge as apparently it's corrupting the stack so a backtrace will not work.

    -Rick

[Rick Murphy]

This is a bug in the SIMH fpp emulator. It's a fencepost error where it's writing past the end of an array. This is in the fractional multiply code, and would only go past the end of that array for a double precision argument.

I have a simple fix, but it's kind of a hack (essentially padding that array so the overwrite is not going past the end.)

Now that I know what the issue is, I'll come up with a better "fix" and submit to the SIMH folks. More later.

Thanks for the persistence on this. It's been broken for some time, and only luck about stack layout has allowed this to work.

    -Rick

[Rick Murphy]

Problem solved. Here's the patch. (Attached to avoid mail corrupting it.)
There were two problems, one of which was hidden by the compiler optimizing a bit too much.

This runs the various test programs in this thread, plus runs the FPP diagnostic (DJFPB-C) without error.

Scary: This has been latent since at least 2009 and just found due to this particular compiler being a bit more aggressive about optimizations. (It's not a c\ompiler bug, this is clearly a fpp simulator bug.)

Now: where do I submit SIMH patches? How do I get this fix into the pidp8i fossil repository?

    -RIck

 $ fossil diff PDP8/pdp8_fpp.c
Index: src/SIMH/PDP8/pdp8_fpp.c
==================================================================
--- src/SIMH/PDP8/pdp8_fpp.c
+++ src/SIMH/PDP8/pdp8_fpp.c
@@ -23,10 +23,12 @@
    used in advertising or otherwise to promote the sale, use or other dealings
    in this Software without prior written authorization from Robert M Supnik.

    fpp          FPP8A floating point processor

+   05-Jan-22    RHM     Fix fencepost error in FP multiply for extended
+                        precision
    03-Jan-10    RMS     Initialized variables statically, for VMS compiler
    19-Apr-09    RHM     FPICL does not clear all command and status reg bits
                             modify fpp_reset to conform with FPP
    27-Mar-09    RHM     Fixed handling of Underflow fix (zero FAC on underflow)
                         Implemented FPP division and multiplication algorithms
@@ -1176,11 +1178,12 @@
 for (i = 0; i < cnt; i++) {
     if ((i % 12) == 0) {
         wc++;                                       /* do another word */
         lo--;                                       /* and next mpyr word */
         fpp_fr_algn (c, 24, wc + 1);
-        c[wc] = 0;
+        if (wc < FPN_NFR_MDS)                       /* Don't assume guard word */
+            c[wc] = 0;
         c[0] = c[1] = fill;                         /* propagate sign */
         }
     if (b[lo] & FPN_FRSIGN)                         /* mpyr bit set? */
         fpp_fr_add(c, a, c, wc);
     fill = ((c[0] & FPN_FRSIGN) ? 07777 : 0);       /* remember sign */
@@ -1366,11 +1369,12 @@
     fpp_fr_fill (a, sign, cnt);
     return;
     }
 while (sc >= 12) {
     for (i = cnt - 1; i > 0; i--)
-        a[i] = a[i - 1];
+        if (i <= FPN_NFR_MDS)                       /* Don't overwrite if EP */
+            a[i] = a[i - 1];
     a[0] = sign;
     sc = sc - 12;
     }
 if (sc == 0)
     return;

On Wed, Jan 5, 2022 at 5:22 PM Mike Katz <mike...@nucurrent.com> wrote:

As a software developer I know how difficult these kind of bugs are to find.

Congratulations to all who helped and a big thank you for all of your efforts.

I would extend these thanks to all of those who help keep SiMH and the PiDP-8 current, evolving and improving.

Happy New Year and may 2022 bring us health, wealth and happiness.

Shout out to Oscar for his amazing work and prayers for the health of his mother.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/CAPdDV0gdwgsumUThNP8J3fA6V3DV5v%2BnqukUjmFNenW6%2BHn4Ug%40mail.gmail.com.

The preceding email message may be confidential or contain protected information. Neither the message nor the content herein are intended for transmission to, or receipt by, any unauthorized persons. If you have received this message in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the message.

[Warren Young]

On Wednesday, January 5, 2022 at 6:40:40 PM UTC-7 k1mu....@gmail.com wrote:

the compiler optimizing a bit too much….not a c\ompiler bug, this is clearly a fpp simulator bug

So, UB, then?

 

Now: where do I submit SIMH patches?

The upstream project accepts PRs.

If you aren't up on the GitHub stuff and don't want to bother setting it up, something this small could be posted inline in an issue via a fenced code block.

 

How do I get this fix into the pidp8i fossil repository?

Once it lands upstream, let us know, and I'll merge the latest SIMH changes in. I typically do that shortly before one of our major releases, but I've done it mid-span before as well, when I know there's something worth merging down.

[Christoph C]

Hello guys,

you are all absolute genius! It's fascinating to see how fast someone finds the patches for such a deep problem so also a big thanks to Rick!

I only need to know when an update is possible :)

Greetings, Chris

[Steve Tockey]

Chris,

I'll happily give Rick 100% of the credit for fixing it. He totally deserves it, awesome job really. The most I could ever do is claim credit for an assist in helping narrow down the source.

You don't need to wait until an update is published. You can use the Linux "patch" utility with Rick's pdp8_fpp.diff attachment above to update your SIMH source code, recompile, then you'll be back running with the corrected FPP. It's just a matter of knowing:

1) where in the directory structure the SIMH FPP source code is

2) how to run patch

3) how to trigger a rebuild

I'm not at my PiDP-8/I right now so I may be off somewhat but:

1) should be pretty close to something like /home/pi/src/pidp8i/trunk/src/simh/PDP8. If it's not exactly that, this path should be close enough that you can find it. The file name is pdp8_fpp.c

2) there are plenty of descriptions of patch on the web, or check out the MAN page for it

3) something very much like

$ cd /home/pi/src/pidp8i/trunk/

$ ./configure && tools/mmake && sudo make install

Cheers,

-- steve

[Rick Murphy]

I've submitted the patch for this to the SIMH repository, and I'm waiting on that to be accepted. Once that's done, it'll get incorporated into the Fossil repository so a rebuild should get the update.

   -Rick

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/e679d68f-dc3e-40e6-bf3e-e91a85c3afb4n%40googlegroups.com.

[Warren Young]

The FPP fix is merged down. Thanks for chasing this, Rick!

This brought along several other upstream SIMH changes.

The standard updating method should suffice, since this fix doesn't affect the built disk images.

[Rick Murphy]

Rebuilt and verified that this fixes the reported issue.

Warren, thanks for your assistance with getting this fix upstreamed.

    -Rick

--

You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/dfba008a-980d-40cd-9c7d-0119bfe882d4n%40googlegroups.com.