Am 02/06/2022 08:40 PM, Martin schrieb:

Am 02/04/2022 06:35 PM, David Schultz schrieb:

On 2/2/22 8:20 PM, Martin wrote:

The odd filesizes were first alarm signals,
further examination shows, that every 01AH byte is missing
from the trisoft files.

Looks like a dumb EOF mark (^Z, 0x1A) scrubber was used on binary files.

A smart one would look only in the final record. An even smarter one
would check for binary files first.


It should be possible, if tedious, to undo some of the damage.

Load the binary (this only works if it is executable) using DDT. Then
starting from the beginning, scan the code. Deletion of a byte should
cause significant weirdness in the following code. Insert a 0x1A in what
looks like the appropriate spot. Reload with DDT and repeat.

You would have to be pretty motivated.

And patient.

This was also my first idea.
Thanks for confirming that.

Or Create a simple automatic tool to quickly detect the first illegal position in a binary. Then hand fix it directly or insert a dummy byte
and continue. At the end return to all the unclear points and retry.

The 68k has a word oriented architecture, a shift by one quickly leads
to illegal opcodes. But data areas will require some disassembly.

For plain binary files, this could work.

Is there somewhere a documentation of all the object formats
(standard or not?) used by the compilers?

I was motivated enough :-)

Success !!!

I realized how easy it would be to fix the corruption.
while studying the CP/M-68K executable format in the hope
to find a quick way to automate the process.

1) Only 01ah bytes were deleted
2) Only the last position in an 128 byte block was affected

Finding the positions was relatively easy by converting every file
into a single byte per line form with "xxd -c1", then using the
byte pattern 4eh as a guide

68000 is big endian, 4e75h is the opcode for "RTS", and
the first byte of it is found often enough in binaries.

If the pattern appeares on an odd address, then a deletion
must have happend on one of the few block boundaries before.

I started with the files in "ERG_68K_Fortran_2p1a" with very
few deletions, and a few hours later ...


I made the following diffs by converting every file with
"xxd -p -c1", the line numbers also are byte offsets.

As noted above, every 1ah is inserted as the last
byte of an 128 byte block.

diff CODE0.REL.xxd CODE.REL.xxd
10879a10880

1a

39934a39936

1a

diff FORTRAN0.REL.xxd FORTRAN.REL.xxd
57471a57472

1a

diff FTNLIB0.OBJ.xxd FTNLIB.OBJ.xxd
47103a47104

1a

diff PASLIB0.OBJ.xxd PASLIB.OBJ.xxd
45311a45312

1a

diff ULINKER0.REL.xxd ULINKER.REL.xxd
6143a6144

1a

13822a13824

1a

Here is a session compiling and running "example.for".


$ ./cpmsim -a transfer.img
Read 32768 bytes from boot track


CP/M-68K(tm) Version 1.2 03/20/84
Copyright (c) 1984 Digital Research, Inc.

CP/M-68K BIOS Version 1.0
Simulated system of April 2014
TPA =16251 K

AUTOST.SUB

INIT.REL M

Do you really want to init disk M ?

a:

dir

A: EXAMPLE FOR : F SUB

type f.sub

c:fortran.rel $1.for
c:code.rel $1.i
c:ulinker.rel -l $1.o $1.obj c:ftnlib.obj c:paslib.obj
era $1.obj
c:lo68 -s -o $1.68k -t10100 c:s.o $1.o c:clib

f example

C:FORTRAN.REL EXAMPLE.FOR

MC68000 Fortran77 Compiler V2.1 01-Dec-83
(C) Copyright 1983 Silicon Valley Software, Inc.

EXAMPL [16522260 bytes]
{16521484 bytes}


0 errors. 25 lines. File example.for
Smallest available space: 16522260 bytes.

C:CODE.REL EXAMPLE.I

MC68000 Code Generator V2.1 01-Dec-83
(C) Copyright 1983 Silicon Valley Software, Inc.

EXAMPL - EXAMPL Code size = 570
Total code size = 570

C:ULINKER.REL -L EXAMPLE.O EXAMPLE.OBJ C:FTNLIB.OBJ C:PASLIB.OBJ

MC68000 CPM Object Code Formatter V2.1 01-Dec-83
(C) Copyright 1983 Silicon Valley Software, Inc.

ERA EXAMPLE.OBJ

C:LO68 -S -O EXAMPLE.68K -T10100 C:S.O EXAMPLE.O C:CLIB

example

[...]

***********************************************
***********************************************
** **
** FORTRAN-77 is correctly installed !! **
** **
***********************************************
***********************************************

[...]

c:bbye

CP/M-68K terminating normally

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

onsdag den 9. marts 2022 kl. 06.20.35 UTC+1 skrev Martin:

Am 02/06/2022 08:40 PM, Martin schrieb:

Am 02/04/2022 06:35 PM, David Schultz schrieb:

On 2/2/22 8:20 PM, Martin wrote:

The odd filesizes were first alarm signals,
further examination shows, that every 01AH byte is missing
from the trisoft files.

Looks like a dumb EOF mark (^Z, 0x1A) scrubber was used on binary files. >>
A smart one would look only in the final record. An even smarter one
would check for binary files first.


It should be possible, if tedious, to undo some of the damage.

Load the binary (this only works if it is executable) using DDT. Then
starting from the beginning, scan the code. Deletion of a byte should
cause significant weirdness in the following code. Insert a 0x1A in what >> looks like the appropriate spot. Reload with DDT and repeat.

You would have to be pretty motivated.

And patient.

This was also my first idea.
Thanks for confirming that.

Or Create a simple automatic tool to quickly detect the first illegal position in a binary. Then hand fix it directly or insert a dummy byte
and continue. At the end return to all the unclear points and retry.

The 68k has a word oriented architecture, a shift by one quickly leads
to illegal opcodes. But data areas will require some disassembly.

For plain binary files, this could work.

Is there somewhere a documentation of all the object formats
(standard or not?) used by the compilers?

I was motivated enough :-)

Success !!!

I realized how easy it would be to fix the corruption.
while studying the CP/M-68K executable format in the hope
to find a quick way to automate the process.

1) Only 01ah bytes were deleted
2) Only the last position in an 128 byte block was affected

Finding the positions was relatively easy by converting every file
into a single byte per line form with "xxd -c1", then using the
byte pattern 4eh as a guide

68000 is big endian, 4e75h is the opcode for "RTS", and
the first byte of it is found often enough in binaries.

If the pattern appeares on an odd address, then a deletion
must have happend on one of the few block boundaries before.

I started with the files in "ERG_68K_Fortran_2p1a" with very
few deletions, and a few hours later ...

I made the following diffs by converting every file with
"xxd -p -c1", the line numbers also are byte offsets.

As noted above, every 1ah is inserted as the last
byte of an 128 byte block.

diff CODE0.REL.xxd CODE.REL.xxd
10879a10880

1a

39934a39936

1a

diff FORTRAN0.REL.xxd FORTRAN.REL.xxd
57471a57472

1a

diff FTNLIB0.OBJ.xxd FTNLIB.OBJ.xxd
47103a47104

1a

diff PASLIB0.OBJ.xxd PASLIB.OBJ.xxd
45311a45312

1a

diff ULINKER0.REL.xxd ULINKER.REL.xxd
6143a6144

1a

13822a13824

1a

Here is a session compiling and running "example.for".

$ ./cpmsim -a transfer.img
Read 32768 bytes from boot track

CP/M-68K(tm) Version 1.2 03/20/84
Copyright (c) 1984 Digital Research, Inc.

CP/M-68K BIOS Version 1.0
Simulated system of April 2014
TPA =16251 K

AUTOST.SUB

INIT.REL M

Do you really want to init disk M ?

a:

dir

A: EXAMPLE FOR : F SUB

type f.sub

c:fortran.rel $1.for
c:code.rel $1.i
c:ulinker.rel -l $1.o $1.obj c:ftnlib.obj c:paslib.obj
era $1.obj
c:lo68 -s -o $1.68k -t10100 c:s.o $1.o c:clib

f example

C:FORTRAN.REL EXAMPLE.FOR

MC68000 Fortran77 Compiler V2.1 01-Dec-83
(C) Copyright 1983 Silicon Valley Software, Inc.

EXAMPL [16522260 bytes]
{16521484 bytes}

0 errors. 25 lines. File example.for
Smallest available space: 16522260 bytes.

C:CODE.REL EXAMPLE.I

MC68000 Code Generator V2.1 01-Dec-83
(C) Copyright 1983 Silicon Valley Software, Inc.

EXAMPL - EXAMPL Code size = 570
Total code size = 570

C:ULINKER.REL -L EXAMPLE.O EXAMPLE.OBJ C:FTNLIB.OBJ C:PASLIB.OBJ

MC68000 CPM Object Code Formatter V2.1 01-Dec-83
(C) Copyright 1983 Silicon Valley Software, Inc.

ERA EXAMPLE.OBJ

C:LO68 -S -O EXAMPLE.68K -T10100 C:S.O EXAMPLE.O C:CLIB

example

[...]

*********************************************** ***********************************************
** **
** FORTRAN-77 is correctly installed !! **
** **
*********************************************** ***********************************************

[...]

c:bbye

CP/M-68K terminating normally

Extremely well done! I have tried a few things, but I failed :-/

Is there any way you can share the corrected files?
Or an even more detailed description of how to do the fix; I am not sure I know how to follow your "recipe" to fix the files?

Regards,
MogensB

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 03/09/2022 07:55 PM, MogensB schrieb:

Extremely well done! I have tried a few things, but I failed :-/

Is there any way you can share the corrected files?
Or an even more detailed description of how to do the fix; I am not sure I know how to follow your "recipe" to fix the files?

Regards,
MogensB

I take CODE.REL, one of the two obviously more complicated files
as an example, and try to describe the procedure.

You need "xxd" to convert the file to/from text format and
the "patch" utility to apply the diff below,
or alternatively, a text editor with "goto line".


Variante A with "xxd" and "patch" or an editor:

1) Convert all files into an ascii byte stream with.

xxd -p -c1 CODE.REL >CODE.REL.xxd
xxd -p -c1 FORTRAN.REL >FORTRAN.REL.xxd
xxd -p -c1 FTNLIB.OBJ >FTNLIB.OBJ.xxd
xxd -p -c1 PASLIB.OBJ >PASLIB.OBJ.xxd
xxd -p -c1 ULINKER.REL >ULINKER.REL.xxd


2a) Apply the following patch "xxd.diff" with

$ patch -p0 <xxd.diff
patching file CODE.REL.xxd
patching file FORTRAN.REL.xxd
patching file FTNLIB.OBJ.xxd
patching file PASLIB.OBJ.xxd
patching file ULINKER.REL.xxd

2b) Edit every file and insert the two bytes

To illustrate it, I describe CODE.REL.xxx in detail.
Edit from bottom to top, so you have not to compensate the
increased line numbers further down caused by your own inserts.

Goto line 39934 and insert the 1a after it:
ff
1a
66
Goto line 10879 and insert the 1a after it:
60
1a
20


3) Convert all files back to binary with.

xxd -r -p -c1 CODE.REL.xxd >CODE.REL.fixed
xxd -r -p -c1 FORTRAN.REL.xxd >FORTRAN.REL.fixed
xxd -r -p -c1 FTNLIB.OBJ.xxd >FTNLIB.OBJ.fixed
xxd -r -p -c1 PASLIB.OBJ.xxd >PASLIB.OBJ.fixed
xxd -r -p -c1 ULINKER.REL.xxd >ULINKER.REL.fixed


Here is the "unified diff", I call it "xxd.diff".

NOTE: There is a "space" at the beginning of the lines
before and after the one beginning with "+".

xxx.diff:
==== 8< ====
--- CODE.REL.xxd
+++ CODE.REL.xxd
@@ -10879,2 +10879,3 @@
60
+1a
20
@@ -39934,2 +39935,3 @@
ff
+1a
66
--- FORTRAN.REL.xxd
+++ FORTRAN.REL.xxd
@@ -57471,2 +57471,3 @@
66
+1a
3f
--- FTNLIB.OBJ.xxd
+++ FTNLIB.OBJ.xxd
@@ -47103,2 +47103,3 @@
00
+1a
48
--- PASLIB.OBJ.xxd
+++ PASLIB.OBJ.xxd
@@ -45311,2 +45311,3 @@
60
+1a
2f
--- ULINKER.REL.xxd
+++ ULINKER.REL.xxd
@@ -6143,2 +6143,3 @@
60
+1a
41
@@ -13822,2 +13823,3 @@
ff
+1a
2a
==== 8< ====


Variante B with an hexeditor:

If nothing works, you can modify the binary files directly
using a binary editor with *insert* capability.


HTH
Martin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

onsdag den 9. marts 2022 kl. 23.01.51 UTC+1 skrev Martin:

Am 03/09/2022 07:55 PM, MogensB schrieb:

Extremely well done! I have tried a few things, but I failed :-/

Is there any way you can share the corrected files?
Or an even more detailed description of how to do the fix; I am not sure I know how to follow your "recipe" to fix the files?

Regards,
MogensB

I take CODE.REL, one of the two obviously more complicated files
as an example, and try to describe the procedure.

You need "xxd" to convert the file to/from text format and
the "patch" utility to apply the diff below,
or alternatively, a text editor with "goto line".

Variante A with "xxd" and "patch" or an editor:

1) Convert all files into an ascii byte stream with.

xxd -p -c1 CODE.REL >CODE.REL.xxd
xxd -p -c1 FORTRAN.REL >FORTRAN.REL.xxd
xxd -p -c1 FTNLIB.OBJ >FTNLIB.OBJ.xxd
xxd -p -c1 PASLIB.OBJ >PASLIB.OBJ.xxd
xxd -p -c1 ULINKER.REL >ULINKER.REL.xxd

2a) Apply the following patch "xxd.diff" with

$ patch -p0 <xxd.diff
patching file CODE.REL.xxd
patching file FORTRAN.REL.xxd
patching file FTNLIB.OBJ.xxd
patching file PASLIB.OBJ.xxd
patching file ULINKER.REL.xxd

2b) Edit every file and insert the two bytes

To illustrate it, I describe CODE.REL.xxx in detail.
Edit from bottom to top, so you have not to compensate the
increased line numbers further down caused by your own inserts.

Goto line 39934 and insert the 1a after it:
ff
1a
66
Goto line 10879 and insert the 1a after it:
60
1a
20

3) Convert all files back to binary with.

xxd -r -p -c1 CODE.REL.xxd >CODE.REL.fixed
xxd -r -p -c1 FORTRAN.REL.xxd >FORTRAN.REL.fixed
xxd -r -p -c1 FTNLIB.OBJ.xxd >FTNLIB.OBJ.fixed
xxd -r -p -c1 PASLIB.OBJ.xxd >PASLIB.OBJ.fixed
xxd -r -p -c1 ULINKER.REL.xxd >ULINKER.REL.fixed

Here is the "unified diff", I call it "xxd.diff".

NOTE: There is a "space" at the beginning of the lines
before and after the one beginning with "+".

xxx.diff:
==== 8< ====
--- CODE.REL.xxd
+++ CODE.REL.xxd
@@ -10879,2 +10879,3 @@
60
+1a
20
@@ -39934,2 +39935,3 @@
ff
+1a
66
--- FORTRAN.REL.xxd
+++ FORTRAN.REL.xxd
@@ -57471,2 +57471,3 @@
66
+1a
3f
--- FTNLIB.OBJ.xxd
+++ FTNLIB.OBJ.xxd
@@ -47103,2 +47103,3 @@
00
+1a
48
--- PASLIB.OBJ.xxd
+++ PASLIB.OBJ.xxd
@@ -45311,2 +45311,3 @@
60
+1a
2f
--- ULINKER.REL.xxd
+++ ULINKER.REL.xxd
@@ -6143,2 +6143,3 @@
60
+1a
41
@@ -13822,2 +13823,3 @@
ff
+1a
2a
==== 8< ====

Variante B with an hexeditor:

If nothing works, you can modify the binary files directly
using a binary editor with *insert* capability.

HTH
Martin

Thank you Martin for the extra help - I appreciate your effort very much!
I finally got the SVS compiler running on my 68k-MBC system, and I am very happy about that :-D
It produced the EXAMPLE.68K and it runs; I have a small problem yet to solve, but I am not sure if this is the compiler, or something else - I got this message from the linker/loader about __optoff being an undefined symbol (but the executable runs
anyway):

C:LO68 -S -O EXAMPLE.68K -T10100 C:S.O EXAMPLE.O C:CLIB

: Undefined symbol(s)
__optoff

But I guess that is something else to look for - not sure which library is supposed to have the __optoff definition.

Best regards,
MogensB


--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

torsdag den 10. marts 2022 kl. 20.48.49 UTC+1 skrev MogensB:

onsdag den 9. marts 2022 kl. 23.01.51 UTC+1 skrev Martin:

Am 03/09/2022 07:55 PM, MogensB schrieb:

Extremely well done! I have tried a few things, but I failed :-/

Is there any way you can share the corrected files?
Or an even more detailed description of how to do the fix; I am not sure I know how to follow your "recipe" to fix the files?

Regards,
MogensB

I take CODE.REL, one of the two obviously more complicated files
as an example, and try to describe the procedure.

You need "xxd" to convert the file to/from text format and
the "patch" utility to apply the diff below,
or alternatively, a text editor with "goto line".

Variante A with "xxd" and "patch" or an editor:

1) Convert all files into an ascii byte stream with.

xxd -p -c1 CODE.REL >CODE.REL.xxd
xxd -p -c1 FORTRAN.REL >FORTRAN.REL.xxd
xxd -p -c1 FTNLIB.OBJ >FTNLIB.OBJ.xxd
xxd -p -c1 PASLIB.OBJ >PASLIB.OBJ.xxd
xxd -p -c1 ULINKER.REL >ULINKER.REL.xxd

2a) Apply the following patch "xxd.diff" with

$ patch -p0 <xxd.diff
patching file CODE.REL.xxd
patching file FORTRAN.REL.xxd
patching file FTNLIB.OBJ.xxd
patching file PASLIB.OBJ.xxd
patching file ULINKER.REL.xxd

2b) Edit every file and insert the two bytes

To illustrate it, I describe CODE.REL.xxx in detail.
Edit from bottom to top, so you have not to compensate the
increased line numbers further down caused by your own inserts.

Goto line 39934 and insert the 1a after it:
ff
1a
66
Goto line 10879 and insert the 1a after it:
60
1a
20

3) Convert all files back to binary with.

xxd -r -p -c1 CODE.REL.xxd >CODE.REL.fixed
xxd -r -p -c1 FORTRAN.REL.xxd >FORTRAN.REL.fixed
xxd -r -p -c1 FTNLIB.OBJ.xxd >FTNLIB.OBJ.fixed
xxd -r -p -c1 PASLIB.OBJ.xxd >PASLIB.OBJ.fixed
xxd -r -p -c1 ULINKER.REL.xxd >ULINKER.REL.fixed

Here is the "unified diff", I call it "xxd.diff".

NOTE: There is a "space" at the beginning of the lines
before and after the one beginning with "+".

xxx.diff:
==== 8< ====
--- CODE.REL.xxd
+++ CODE.REL.xxd
@@ -10879,2 +10879,3 @@
60
+1a
20
@@ -39934,2 +39935,3 @@
ff
+1a
66
--- FORTRAN.REL.xxd
+++ FORTRAN.REL.xxd
@@ -57471,2 +57471,3 @@
66
+1a
3f
--- FTNLIB.OBJ.xxd
+++ FTNLIB.OBJ.xxd
@@ -47103,2 +47103,3 @@
00
+1a
48
--- PASLIB.OBJ.xxd
+++ PASLIB.OBJ.xxd
@@ -45311,2 +45311,3 @@
60
+1a
2f
--- ULINKER.REL.xxd
+++ ULINKER.REL.xxd
@@ -6143,2 +6143,3 @@
60
+1a
41
@@ -13822,2 +13823,3 @@
ff
+1a
2a
==== 8< ====

Variante B with an hexeditor:

If nothing works, you can modify the binary files directly
using a binary editor with *insert* capability.

HTH
Martin

Thank you Martin for the extra help - I appreciate your effort very much!
I finally got the SVS compiler running on my 68k-MBC system, and I am very happy about that :-D
It produced the EXAMPLE.68K and it runs; I have a small problem yet to solve, but I am not sure if this is the compiler, or something else - I got this message from the linker/loader about __optoff being an undefined symbol (but the executable runs

anyway):

C:LO68 -S -O EXAMPLE.68K -T10100 C:S.O EXAMPLE.O C:CLIB

: Undefined symbol(s)
__optoff

But I guess that is something else to look for - not sure which library is supposed to have the __optoff definition.

Best regards,
MogensB

The FORTRAN-77 compiler is most likely not the cause of this problem.
The problem is somehow related to the C library CLIB, I believe - I found a german magazine from 1986 mentioning a similar problem. The workaround was to extract OPTOFF.O from the CLIB file, and link directly with the OPTOFF.O file:

C:LO68 -S -O EXAMPLE.68K -T10100 C:S.O OPTOFF.O EXAMPLE.O C:CLIB

And this is successful without any undefined symbol errors. Maybe this is a "known bug" for experienced users of the linker LO68 in CP/M-68K? Or the bug may be in the CLIB file?

The article I am referring to is available on https://www.ndr-nkc.de/download/mc/1986.04_mc_C-Programme%20CPM68K.pdf

Regards,
MogensB

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/10/22 3:03 PM, MogensB wrote:

The FORTRAN-77 compiler is most likely not the cause of this problem.
The problem is somehow related to the C library CLIB, I believe - I found a german magazine from 1986 mentioning a similar problem. The workaround was to extract OPTOFF.O from the CLIB file, and link directly with the OPTOFF.O file:

C:LO68 -S -O EXAMPLE.68K -T10100 C:S.O OPTOFF.O EXAMPLE.O C:CLIB

And this is successful without any undefined symbol errors. Maybe this is a "known bug" for experienced users of the linker LO68 in CP/M-68K? Or the bug may be in the CLIB file?

This is trying to tickle a memory but I can't remember what. :-)

But it looks like a library ordering problem. The linker makes one pass
through the library trying to resolve symbols. If it finds a symbol it
doesn't know about late in the list that is resolved by an object
earlier, it will not go back and look at it again.

So you could list CLIB twice or move optoff.o later in the list. Which
may cause more trouble if it references other things.

A check of the published source code turns up:

/* OPTOFF.C: prints a message in case someone tries to use a part of the
*/
/* RTL which was OPTIONally linked out.
*/

#include "portab.h"
#include "osif.h"

_optoff(msg)
BYTE *msg;
{
BYTE buf[200]; /* ought to be big
enough */

strcpy(buf,"C RTL - program not linked for ");
strcat(buf,msg);
strcat(buf,"\r\nProgram terminating\r\n$");
__OSIF(C_WRITESTR,buf);
_exit(FAILURE);
}


It seems a little odd seeing a FORTRAN program linked to CLIB but not
LIBE or LIBF. Perhaps it has its own floating point library.


--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

A little grep through the source code shows that references to optoff
happen in only a few places in CLIB. Mostly in the noXXXXX.o files at
the head of CLIB. But there is one straggler in ttyin.o which occurs
well after optoff.o. So if FORTRAN pulls that in, it will cause trouble.

optoff.o should be after ttyin but before the stuff it references.

Or add -u__optoff to the lo68 command line.


--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thank you Martin for the extra help - I appreciate your effort very much!
I finally got the SVS compiler running on my 68k-MBC system, and I am very happy about that :-D
It produced the EXAMPLE.68K and it runs; I have a small problem yet to solve, but I am not sure if this is the compiler, or something else - I got this message from the linker/loader about __optoff being an undefined symbol (but the executable runs

anyway):

C:LO68 -S -O EXAMPLE.68K -T10100 C:S.O EXAMPLE.O C:CLIB

: Undefined symbol(s)
__optoff

But I guess that is something else to look for - not sure which library is supposed to have the __optoff definition.

Best regards,
MogensB

The FORTRAN-77 compiler is most likely not the cause of this problem.
The problem is somehow related to the C library CLIB, I believe - I found a german magazine from 1986 mentioning a similar problem. The workaround was to extract OPTOFF.O from the CLIB file, and link directly with the OPTOFF..O file:

C:LO68 -S -O EXAMPLE.68K -T10100 C:S.O OPTOFF.O EXAMPLE.O C:CLIB

And this is successful without any undefined symbol errors. Maybe this is a "known bug" for experienced users of the linker LO68 in CP/M-68K? Or the bug may be in the CLIB file?

The article I am referring to is available on https://www.ndr-nkc.de/download/mc/1986.04_mc_C-Programme%20CPM68K.pdf

Regards,
MogensB

I found the following:

The compiler works with the CLIB from CP/M-68K 1.1.

With CLIB from 1.2, just specify CLIB a second time.
In that second pass, the __optoff is linked in.

I also believe, it is a known problem.

Martin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Please consider sending complete copies of the patched code to Gaby:

http://www.cpm.z80.de/

That is where it truly belongs.


Randy

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

fredag den 11. marts 2022 kl. 08.18.19 UTC+1 skrev Randy McLaughlin:

Please consider sending complete copies of the patched code to Gaby:

http://www.cpm.z80.de/

That is where it truly belongs.

Randy

I Agree - I wrote a mail to Gaby.

Regards,
MogensB

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

fredag den 11. marts 2022 kl. 18.20.32 UTC+1 skrev MogensB:

fredag den 11. marts 2022 kl. 08.18.19 UTC+1 skrev Randy McLaughlin:

Please consider sending complete copies of the patched code to Gaby:

http://www.cpm.z80.de/

That is where it truly belongs.

Randy

I Agree - I wrote a mail to Gaby.

Regards,
MogensB

I am happy to tell you that I was able to contact the founder of Silicon Valley Software, Inc. (which dissolved back in 1988) who is also the author of the compilers. He kindly granted permission to freely use and distribute the SVS Compilers for CP/M-
68K at no cost, only request is that we maintain the original copyright notice in the software. Gaby is informed, and is about to make the SVS FORTRAN-77 compiler available on the website.
I gave credits to you guys in this forum for your help getting the binary files patched back into working condition. The original binaries for the compilers were unfortunately lost, also with the founder of Silicon Valley Software. He told me, that the
SVS Pascal compiler was the tool used for developing the SVS FORTRAN compiler, so it would be great if that one could be fixed as well ;-) - and for Gaby to make available this compiler too!

Regards,
MogensB

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

søndag den 13. marts 2022 kl. 12.41.16 UTC+1 skrev MogensB:

fredag den 11. marts 2022 kl. 18.20.32 UTC+1 skrev MogensB:

fredag den 11. marts 2022 kl. 08.18.19 UTC+1 skrev Randy McLaughlin:

Please consider sending complete copies of the patched code to Gaby:

http://www.cpm.z80.de/

That is where it truly belongs.

Randy

I Agree - I wrote a mail to Gaby.

Regards,
MogensB

I am happy to tell you that I was able to contact the founder of Silicon Valley Software, Inc. (which dissolved back in 1988) who is also the author of the compilers. He kindly granted permission to freely use and distribute the SVS Compilers for CP/M-

68K at no cost, only request is that we maintain the original copyright notice in the software. Gaby is informed, and is about to make the SVS FORTRAN-77 compiler available on the website.

I gave credits to you guys in this forum for your help getting the binary files patched back into working condition. The original binaries for the compilers were unfortunately lost, also with the founder of Silicon Valley Software. He told me, that the

SVS Pascal compiler was the tool used for developing the SVS FORTRAN compiler, so it would be great if that one could be fixed as well ;-) - and for Gaby to make available this compiler too!

Regards,
MogensB

The FORTRAN compiler binaries are now available on http://www.cpm.z80.de/binary.html - just look for "SVS FORTRAN".
@Martin and @David - you got credited for your effort to patch the corrupt binaries - I hope you are OK with being mentioned in Gaby's website :-) if not, just drop a line to Gaby about it.

Regards,
MogensB

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

søndag den 13. marts 2022 kl. 17.49.09 UTC+1 skrev David Schultz:

On 3/13/22 9:57 AM, MogensB wrote:

@Martin and @David - you got credited for your effort to patch the corrupt binaries - I hope you are OK with being mentioned in Gaby's website :-) if not, just drop a line to Gaby about it.

I know that memory is supposed to get a bit flaky with age but I do not recall doing anything to patch those binaries. Other than suggesting
that it might be possible.
--
http://davesrocketworks.com
David Schultz

Hi David - I am sorry if I misunderstood your comments in this thread, I was just thinking you were the one correctly identifying the root cause of the problem with the files - the EOF markers being deleted from the files? This was why I thought I would
mention your name to Gaby. Please let me know, I can of course ask Gaby to remove your name from the site, if you don't feel it belongs there! I just wanted to make it clear that I was not the one capable of fixing the files :-)

Best Regards,
MogensB

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/13/22 9:57 AM, MogensB wrote:

@Martin and @David - you got credited for your effort to patch the corrupt binaries - I hope you are OK with being mentioned in Gaby's website :-) if not, just drop a line to Gaby about it.

I know that memory is supposed to get a bit flaky with age but I do not
recall doing anything to patch those binaries. Other than suggesting
that it might be possible.

--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 03/13/2022 12:41 PM, MogensB schrieb:

fredag den 11. marts 2022 kl. 18.20.32 UTC+1 skrev MogensB:

fredag den 11. marts 2022 kl. 08.18.19 UTC+1 skrev Randy McLaughlin:

Please consider sending complete copies of the patched code to Gaby:

http://www.cpm.z80.de/

That is where it truly belongs.


Randy

I Agree - I wrote a mail to Gaby.

Regards,
MogensB

I am happy to tell you that I was able to contact the founder of Silicon Valley Software, Inc. (which dissolved back in 1988) who is also the author of the compilers. He kindly granted permission to freely use and distribute the SVS Compilers for CP/M-

68K at no cost, only request is that we maintain the original copyright notice in the software. Gaby is informed, and is about to make the SVS FORTRAN-77 compiler available on the website.

I gave credits to you guys in this forum for your help getting the binary files patched back into working condition. The original binaries for the compilers were unfortunately lost, also with the founder of Silicon Valley Software. He told me, that the

SVS Pascal compiler was the tool used for developing the SVS FORTRAN compiler, so it would be great if that one could be fixed as well ;-) - and for Gaby to make available this compiler too!

Regards,
MogensB

This are *fantastic* news!

And just in time, I finished the repair of SVS-Pascal :-D

I used the files in "ERG_68K_Pascal",
the same explanations as for the SVS-Fortran patches:

1) Convert all files into an ascii byte stream
2) Apply the following patch
3) Convert all files back to binary



==== 8< ====
--- CODE.REL.xxd
+++ CODE.REL.xxd
@@ -10879,2 +10879,3 @@
60
+1a
20
@@ -39934,2 +39935,3 @@
ff
+1a
66
@@ -66941,2 +66943,3 @@
00
+1a
00
--- PASCAL.REL.xxd
+++ PASCAL.REL.xxd
@@ -4863,2 +4863,3 @@
60
+1a
42
@@ -7038,2 +7039,3 @@
60
+1a
2f
@@ -42749,2 +42751,3 @@
00
+1a
70
@@ -68988,2 +68991,3 @@
00
+1a
ff
@@ -88955,2 +88959,3 @@
66
+1a
2f
@@ -94970,2 +94975,3 @@
67
+1a
4a
@@ -96633,2 +96639,3 @@
01
+1a
4a
--- FTNLIB.OBJ.xxd
+++ FTNLIB.OBJ.xxd
@@ -50431,2 +50431,3 @@
00
+1a
b0
@@ -83454,2 +83455,3 @@
00
+1a
20
--- PASLIB.OBJ.xxd
+++ PASLIB.OBJ.xxd
@@ -11391,2 +11391,3 @@
6e
+1a
48
@@ -11902,2 +11903,3 @@
00
+1a
4e
@@ -17661,2 +17663,3 @@
08
+1a
00
--- ULINKER.REL.xxd
+++ ULINKER.REL.xxd
@@ -6143,2 +6143,3 @@
60
+1a
41
@@ -13822,2 +13823,3 @@
ff
+1a
2a
==== 8< ====


Have fun !!!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 03/13/2022 05:59 PM, MogensB schrieb:

søndag den 13. marts 2022 kl. 17.49.09 UTC+1 skrev David Schultz:

On 3/13/22 9:57 AM, MogensB wrote:

@Martin and @David - you got credited for your effort to patch the corrupt binaries - I hope you are OK with being mentioned in Gaby's website :-) if not, just drop a line to Gaby about it.

I know that memory is supposed to get a bit flaky with age but I do not
recall doing anything to patch those binaries. Other than suggesting
that it might be possible.
--
http://davesrocketworks.com
David Schultz

Hi David - I am sorry if I misunderstood your comments in this thread, I was just thinking you were the one correctly identifying the root cause of the problem with the files - the EOF markers being deleted from the files? This was why I thought I

would mention your name to Gaby. Please let me know, I can of course ask Gaby to remove your name from the site, if you don't feel it belongs there! I just wanted to make it clear that I was not the one capable of fixing the files :-)

Best Regards,
MogensB

No offence please, this is my view of the things,
he has not much to do with the restoration

*BUT*

Without his emulator, I never had finished this project !!!

I also have to thank *Randy McLaughlin* to make this possible,
because of his efforts to not only archive these files, but many, many more!

And finally the founder of Silicon Valley Software, Inc., to make his
compiler available to us.

And please forgive me, if I have forgotten onyone else :-)

Martin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/13/22 5:19 PM, MogensB wrote:

Thx to *everyone* helping to make these important contribution to the CP/M software collections. It is amazing to see how I started with posting a question in search of a FORTRAN compiler, and now we have two almost "lost" significant compilers working

on CP/M-68K.

/MogensB

There is another, kind of. The sources for the PLM compiler hosted on a
VAX were made available some time ago. In FORTRAN. I tried to get it to
compile using the GCC version of FORTRAN but didn't get very far.

Perhaps it would work better with the native FORTRAN? If so, then it
would be possible to compile the few CP/M-68K tools (ed, etc.) that are
in PLM.

--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

søndag den 13. marts 2022 kl. 18.56.02 UTC+1 skrev Martin:

Am 03/13/2022 05:59 PM, MogensB schrieb:

søndag den 13. marts 2022 kl. 17.49.09 UTC+1 skrev David Schultz:

On 3/13/22 9:57 AM, MogensB wrote:

@Martin and @David - you got credited for your effort to patch the corrupt binaries - I hope you are OK with being mentioned in Gaby's website :-) if not, just drop a line to Gaby about it.

I know that memory is supposed to get a bit flaky with age but I do not >> recall doing anything to patch those binaries. Other than suggesting
that it might be possible.
--
http://davesrocketworks.com
David Schultz

Hi David - I am sorry if I misunderstood your comments in this thread, I was just thinking you were the one correctly identifying the root cause of the problem with the files - the EOF markers being deleted from the files? This was why I thought I

would mention your name to Gaby. Please let me know, I can of course ask Gaby to remove your name from the site, if you don't feel it belongs there! I just wanted to make it clear that I was not the one capable of fixing the files :-)

Best Regards,
MogensB

No offence please, this is my view of the things,
he has not much to do with the restoration

*BUT*

Without his emulator, I never had finished this project !!!

I also have to thank *Randy McLaughlin* to make this possible,
because of his efforts to not only archive these files, but many, many more!

And finally the founder of Silicon Valley Software, Inc., to make his compiler available to us.

And please forgive me, if I have forgotten onyone else :-)

Martin

Once again, very well done, Martin! Using your patches, I can also confirm that the SVS Pascal compiler seems to be running smoothly in my 68k-mbc CP/M-68k system :-)

I am very happy that both compilers are in working condition. I will arrange that Gaby receives the patched set of files for the Pascal compiler too, and offer those along with the FORTRAN compiler.

Thx to *everyone* helping to make these important contribution to the CP/M software collections. It is amazing to see how I started with posting a question in search of a FORTRAN compiler, and now we have two almost "lost" significant compilers working
on CP/M-68K.

/MogensB

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

David Schultz schrieb am Sonntag, 13. März 2022 um 23:35:37 UTC+1:

There is another, kind of. The sources for the PLM compiler hosted on a
VAX were made available some time ago. In FORTRAN. I tried to get it to compile using the GCC version of FORTRAN but didn't get very far.

Sources for the PL/M compiler that build with GNU FORTRAN are available
in the z80pack repository:
https://www.autometer.de/unix4fun/z80pack/#download

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, 13 March 2022 at 22:35:37 UTC, David Schultz wrote:

On 3/13/22 5:19 PM, MogensB wrote:

Thx to *everyone* helping to make these important contribution to the CP/M software collections. It is amazing to see how I started with posting a question in search of a FORTRAN compiler, and now we have two almost "lost" significant compilers

working on CP/M-68K.

/MogensB

There is another, kind of. The sources for the PLM compiler hosted on a
VAX were made available some time ago. In FORTRAN. I tried to get it to compile using the GCC version of FORTRAN but didn't get very far.

Perhaps it would work better with the native FORTRAN? If so, then it
would be possible to compile the few CP/M-68K tools (ed, etc.) that are
in PLM.
--
http://davesrocketworks.com
David Schultz

David
I was not aware of a PL/M 68k, where can it be found?
On the internet you can find FORTRAN source for a PL/M 80 cross compiler, which is relatively clean FORTRAN 66 and does work, however you need the later version as the original V2 generates incorrect code. I have also done a conversion to C with some
clean-up to remove most of the gotos. It is available on my GitHub site.
Note the version of PL/M supported lacks features of the later resident versions and it is not linkable with other code.

There is also FORTRAN source for PL/M VAX compiler, which I have not managed to build as it appears to use some VAX specific extensions. Looking at the source it seems to support additional key words compared to other PL/M variants.

Mark

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

ogd...@gmail.com schrieb am Montag, 14. März 2022 um 12:01:47 UTC+1:

On the internet you can find FORTRAN source for a PL/M 80 cross compiler, which is relatively clean
FORTRAN 66 and does work, however you need the later version as the original V2 generates incorrect code.

We have versions 2 and 4 of the cross compiler.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

mandag den 14. marts 2022 kl. 16.41.01 UTC+1 skrev Udo Munk:

ogd...@gmail.com schrieb am Montag, 14. März 2022 um 12:01:47 UTC+1:

On the internet you can find FORTRAN source for a PL/M 80 cross compiler, which is relatively clean
FORTRAN 66 and does work, however you need the later version as the original V2 generates incorrect code.

We have versions 2 and 4 of the cross compiler.

The reconstructed SVS Pascal compiler for CP/M-68K has been posted online on Gaby's website, we got the permission to publish the compiler on the same terms as the SVS FORTRAN-77 compiler (free to use and distribute at no cost, provided the original
copyright notice is maintained).

/MogensB

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/14/22 6:01 AM, ogd...@gmail.com wrote:

I was not aware of a PL/M 68k, where can it be found?

It has been several years so I don't recall. Digging out the remains of
what I tried...

After looking at the gencode.for file it appears to target an abstract processor. The comments say it puts out MACRO assembly code. The
mnemonic table starts:

C BYTE WORD INTEGER POINTER REAL LONG DOUBLE QUAD

DATA MNEM/
#'ADDB2','ADDW2','ADDW2','ADDL2','ADDF2','ADDL2','ADDD2','---- ',

So even if that were made to work, a suitable package of macros would be required.

According to the build instructions for ed in the CP/M-68K sources, the
VAX would put out a binary (I think) that was massaged into a .68K
format on an ALTOS using a program called reconv.com.

A hell of a way to run things. Perhaps best forgotten. :-)


--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)