Am 01/31/2022 06:33 PM, Roger Hanscom schrieb:
> On Sunday, January 30, 2022 at 8:48:14 PM UTC-8, Martin wrote:
>
>> Bad news.
>>
>> It seems, some archives are not in good shape.
>> Sorry for the noise, didn't know this until now.
>
> Hi Martin,
>
> So, how can I find the "ok" files? I've forgotten how to get to the "emulator".
>
> Roger
>

Rereading your question, I finally understand ...

I have just renamed the files.
The "ok" files are the one from "cb68.zip".

Sorry!

On 2/1/22 12:57 PM, Martin wrote:

> P.S.:
> Do you know?
> The sepulchral voice intones, "The cave is now closed."
>
> It will happen anytime soon!
> Hey, my shiny brass lamp is almost out of fuel!
>

The little bird attacks the green dragon, and in an
astounding flurry gets burnt to a cinder. The ashes blow away.

--
http://davesrocketworks.com
David Schultz

On 1/31/22 17:49, David Schultz wrote:
> On 1/31/22 4:15 PM, Steven Hirsch wrote:
>> On 1/29/22 16:31, Martin wrote:
>>>
>>>  From 2006, now long gone, you know where to look :-)
>>> <http://www.s100-manuals.com/CPM-BootDisks.htm>
>>>
>>
>> Unfortunately, I am not smart enough to know where to look, but would love
>> to get my hands on the CPM68k archive.
>
> The Internet Archive of course: https://archive.org/index.php

For reasons known only to the Internet Archive owners, no hits were returned
from a query on www.s100-manuals.com. Didn't try the CPM-BootDisks section of
the URL...

On Wednesday, February 2, 2022 at 7:46:40 AM UTC-8, Steven Hirsch wrote:
> On 1/31/22 17:49, David Schultz wrote:
> > On 1/31/22 4:15 PM, Steven Hirsch wrote:
> >> On 1/29/22 16:31, Martin wrote:
> >>>
> >>> From 2006, now long gone, you know where to look :-)
> >>> <http://www.s100-manuals.com/CPM-BootDisks.htm>
> >>>
> >>
> >> Unfortunately, I am not smart enough to know where to look, but would love
> >> to get my hands on the CPM68k archive.
> >
> > The Internet Archive of course: https://archive.org/index.php
> For reasons known only to the Internet Archive owners, no hits were returned
> from a query on www.s100-manuals.com. Didn't try the CPM-BootDisks section of
> the URL...

That is not the correct link - go to https://archive.org/web/ (aka the "Wayback Machine") and look at what it archived in 2006.

On Wednesday, February 2, 2022 at 7:46:40 AM UTC-8, Steven Hirsch wrote:

> For reasons known only to the Internet Archive owners, no hits were returned
> from a query on www.s100-manuals.com. Didn't try the CPM-BootDisks section of
> the URL...

Steve --

Go to <http://www.s100-manuals.com/CPM-BootDisks.htm>. You will get a 404 error, but select the "check archives" button in the upper right corner. The WayBack Machine will come up with a page that includes a link to the Tri-Soft archive.

Roger

On 2/2/22 9:46 AM, Steven Hirsch wrote:
> On 1/31/22 17:49, David Schultz wrote:
>> On 1/31/22 4:15 PM, Steven Hirsch wrote:
>>> On 1/29/22 16:31, Martin wrote:
>>>>
>>>>  From 2006, now long gone, you know where to look :-)
>>>> <http://www.s100-manuals.com/CPM-BootDisks.htm>
>>>>
>>>
>>> Unfortunately, I am not smart enough to know where to look, but would
>>> love to get my hands on the CPM68k archive.
>>
>> The Internet Archive of course: https://archive.org/index.php
>
> For reasons known only to the Internet Archive owners, no hits were
> returned from a query on www.s100-manuals.com.  Didn't try the
> CPM-BootDisks section of the URL...
>

Did you click on the search web pages option? I did:

https://web.archive.org/web/20071223175347/http://www.s100-manuals.com:80/CPM-BootDisks.htm

(Note also that the final entry is a page not found error so you have to
back up in time a bit.)

--
http://davesrocketworks.com
David Schultz

> Go to <http://www.s100-manuals.com/CPM-BootDisks.htm>. You will get a 404 error, but select the "check archives" button in the upper right corner. The WayBack Machine will come up with a page that includes a link to the Tri-Soft archive.
>
> Roger

Roger - I think those instructions are system and browser dependent. On MacOS running either the Chrome or Safari browser, for example, the "check archives" button you are referring to does not exist - all you see is the 404 error. I had to go directly to the Wayback Archive web site, and manually enter a search on the URL "http://www.s100-manuals.com/CPM-BootDisks.htm"

In article <4df62e69-b96b-4996-aa82-5ee54fdec120n@googlegroups.com>,
Roger Hanscom <norwestrzh@gmail.com> wrote:
>Go to <http://www.s100-manuals.com/CPM-BootDisks.htm>. You will get a 404 error,
> but select the "check archives" button in the upper right corner.

You must have a browser plugin that provides the "check archives"
button, or use a browser that does that. When I look with Firefox
that doesn't happen.

On 2/2/22 19:08, David Schultz wrote:
> On 2/2/22 9:46 AM, Steven Hirsch wrote:
>> On 1/31/22 17:49, David Schultz wrote:
>>> On 1/31/22 4:15 PM, Steven Hirsch wrote:
>>>> On 1/29/22 16:31, Martin wrote:
>>>>>
>>>>>  From 2006, now long gone, you know where to look :-)
>>>>> <http://www.s100-manuals.com/CPM-BootDisks.htm>
>>>>>
>>>>
>>>> Unfortunately, I am not smart enough to know where to look, but would love
>>>> to get my hands on the CPM68k archive.
>>>
>>> The Internet Archive of course: https://archive.org/index.php
>>
>> For reasons known only to the Internet Archive owners, no hits were returned
>> from a query on www.s100-manuals.com.  Didn't try the CPM-BootDisks section
>> of the URL...
>>
>
> Did you click on the search web pages option? I did:
>
> https://web.archive.org/web/20071223175347/http://www.s100-manuals.com:80/CPM-BootDisks.htm
>
>
> (Note also that the final entry is a page not found error so you have to back
> up in time a bit.)

I'm all set now thanks to some quick help from Larry Kraemer (much appreciated).

Do I understand correctly that some of the archive is corrupted?

On 2/2/22 6:52 PM, Peter Higgins wrote:
>> Go to <http://www.s100-manuals.com/CPM-BootDisks.htm>. You will get a 404 error, but select the "check archives" button in the upper right corner. The WayBack Machine will come up with a page that includes a link to the Tri-Soft archive.
>>
>> Roger
>
> Roger - I think those instructions are system and browser dependent. On MacOS running either the Chrome or Safari browser, for example, the "check archives" button you are referring to does not exist - all you see is the 404 error. I had to go directly to the Wayback Archive web site, and manually enter a search on the URL "http://www.s100-manuals.com/CPM-BootDisks.htm"

I have a plugin on Firefox that does it.

--
http://davesrocketworks.com
David Schultz

Am 02/03/2022 01:57 AM, Steven Hirsch schrieb:
>
> I'm all set now thanks to some quick help from Larry Kraemer (much
> appreciated).
>
> Do I understand correctly that some of the archive is corrupted?

First results while trying to find the cause of oger's problems with CB68:

The http://www.cpm.z80.de/download/cb68.zip:
-rw-r--r-- 1 martin users 13824 Dec 18 1997 CB68.DOC
-rw-r--r-- 1 martin users 93312 Dec 18 1997 CB68.L68
-rw-r--r-- 1 martin users 213632 Dec 18 1997 CB68.REL

Comparing this with the trisoft archive
CPM-68K/Languages/Basic/CBASIC_68K_1.0:
-r--r--r-- 1 martin users 93311 Apr 27 2004 CB68.L68
-r--r--r-- 1 martin users 213629 Apr 27 2004 CB68.REL
-r--r--r-- 1 martin users 69120 Apr 27 2004 LINK68.REL

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

So a first glance it seems the corruption at least follows
some regular schema.

The LINK68.REL looks truncated relative to all other files
of the same name elsewhere.

Looking around searching a comparable LINK68.REL I found
LINK68.68K in CPM-68K/Languages/Pascal/Pascal_MTP_Working:
-r--r--r-- 1 martin users 37631 Apr 27 2004 LINK68.68K

A good version of the file is in rlee peter's cp/m archive
rlee/D/DIGITAL RESEARCH/CPM68K/CO16-68K:
-rwxr-xr-x 1 martin users 37632 Apr 11 1999 LINK68.68K

Same form of curruption, one 01AH somewhere in the middle
is cut out.

Not good... :-(

Martin

> Mostly, I use a GCC cross compiler and run the resulting binaries on CP/M-68k using a little thing I wrote called RUN.68K. It just loads the raw binary, and makes it look like a generic executable that CP/M-68k seems to like. GCC generates very fast code!
>
Roger,

that sound very interesting !
What GCC cross compiler version are You using ?
How do You compile the program (compiler switches) ?
What does RUN.68K exactly ?
Can I have a copy of RUN.68K or RUN.S ?

Regards,

Josef

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.

--
http://davesrocketworks.com
David Schultz

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?

Did we solved the CB68 issues? compile ASCII mandelbrot with CB68 under CP/M68K is part of my test suite. It all worked on my 68K designs from 68008 to 68030 so I think I have the working binaries of CB68.rel and library CB68.L68. I believe I downloaded CB68 from cpm.z80.de
Bill

On Sunday, February 13, 2022 at 7:26:16 AM UTC-8, Bill Shen wrote:
> Did we solved the CB68 issues? compile ASCII mandelbrot with CB68 under CP/M68K is part of my test suite. It all worked on my 68K designs from 68008 to 68030 so I think I have the working binaries of CB68.rel and library CB68.L68. I believe I downloaded CB68 from cpm.z80.de
> Bill

Hi Bill,

I think that the questions about CB68 came up because I was unable to compile "asciiart" with my version of CB68. I thought that perhaps my CB68 (or the library) was corrupt, but it turns out that it was a problem with my CBIOS attempting to set the memory region with an odd number. I fixed it, and was able to compile OK.

As an aside:
CB68 version: 1:04 23k
XGCC version: :13 7k
also ran it with "COM2X" using Micro$lop MBASIC -- so slow I didn't even let it complete!!!

Roger

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

C>AUTOST.SUB

C>INIT.REL M
Do you really want to init disk M ?
C>a:

A>dir
A: EXAMPLE FOR : F SUB
A>
A>
A>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

A>f example

A>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.

A>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

A>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.

A>ERA EXAMPLE.OBJ

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

A>example
[...]

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

[...]

A>c:bbye
CP/M-68K terminating normally

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
>
> C>AUTOST.SUB
>
> C>INIT.REL M
> Do you really want to init disk M ?
> C>a:
>
> A>dir
> A: EXAMPLE FOR : F SUB
> A>
> A>
> A>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
>
> A>f example
>
> A>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.
>
> A>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
>
> A>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.
>
>
> A>ERA EXAMPLE.OBJ
>
> A>C:LO68 -S -O EXAMPLE.68K -T10100 C:S.O EXAMPLE.O C:CLIB
>
> A>example
> [...]
>
> ***********************************************
> ***********************************************
> ** **
> ** FORTRAN-77 is correctly installed !! **
> ** **
> ***********************************************
> ***********************************************
>
> [...]
>
> A>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

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

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):

F>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

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):
>
> F>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:

F>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

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:
>
> F>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

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

>> 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):
>>
>> F>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:
>
> F>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

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

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

That is where it truly belongs.

Randy