In search of a CP/M-68K FORTRAN compiler

[MogensB]

Hi Everyone,

I recently built a CP/M-68K system (the 68K-MBC), and I would very much like to have a FORTRAN compiler running natively on the system.
Searching the Internet, it seems that some FORTRAN compilers were made for CP/M-68K.

I can't find one on the "usual" CP/M sites and archives, though.

Maybe you can help me locate one?

Best regards,
Mogens

[Roger Hanscom]

On Saturday, January 29, 2022 at 2:58:37 AM UTC-8, MogensB wrote:

> Searching the Internet, it seems that some FORTRAN compilers were made for CP/M-68K.

Hi Mogens --

The best archive for CP/M-68K stuff, and lots of Cromemco stuff as well, is the old Maben site. Marcus moved it to GitHub, and made it inaccessible unless you are granted permission. I find that getting permission to the GitHub repository is a *real* challenge. Your experience might vary?

Roger

[Peter Higgins]

The files Marcus moved to the GitHub site are almost exclusively limited to Cromemco stuff. Cromemco's Fortran compilers for Cromix are archived there, but no software for CPM-68K.
To the best of my knowledge the only Fortran compiler for CPM-68K was produced by a company called "Silicon Valley Software", and I have never seen copy of that product archived on the internet.

[Martin]

From 2006, now long gone, you know where to look :-)
<http://www.s100-manuals.com/CPM-BootDisks.htm>

[MogensB]

Thank you very much for this most useful tip/hint! I appreciate your help.

Best regards,
Mogens

[Peter Higgins]

On Saturday, January 29, 2022 at 1:34:13 PM UTC-8, Martin wrote:
> From 2006, now long gone, you know where to look :-)
> <http://www.s100-manuals.com/CPM-BootDisks.htm>

Thank you Martin. I must admit it took me a few minutes to figure out your cryptic hint but yes... what we were looking for it there!

[Roger Hanscom]

> On Saturday, January 29, 2022 at 1:34:13 PM UTC-8, Martin wrote:
> > From 2006, now long gone, you know where to look :-)
> > <http://www.s100-manuals.com/CPM-BootDisks.htm>

WOW!!! Thanks Martin!! What a "gold mine"!! I designed and built a 68K SBC (68000 running at 18.4 MHz, 2MB SRAM, 1MB EPROM, compact flash interface via 8255, and 2 serial ports via 68681(38.4k baud)). Got some things working in CP/M-68k, but found software to be a limiting factor. That archive has 3,000+ files --> endless fun!

I see that CB68 (BASIC compiler) is in the archive. I have copies of it on my SBC, but although it seems to work OK for simple things, anything more complex just generates "exception $03". Anybody find it useful? What am I doing wrong? The compile works OK (no errors), and the link too -- "LINK68".

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!

I can post a photo of the SBC if anybody is interested.

Roger

[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!

>
> I can post a photo of the SBC if anybody is interested.
>
> Roger
>

I'm collecting M68K material for a long time now.

Always hoping to find ssytem disks for a nice coprocessor card I got
in the late 1990s without any software or docs.

So nothing to learn from, everything had to be found out from the
ground by trial and error.

Its a definicon DSI-780 with 12MHz, see
<http://www.spiess.ch/emme2/e2news/news02/node2.html>

The information found here helped me to get is running.
<http://cini.classiccmp.org/pdf/byte/Definicon%2068020.pdf>

I can reset the processor and load a memory image to the card.


Martin

[Martin]

Am 01/30/2022 08:02 PM, Roger Hanscom schrieb:

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

>
> I can post a photo of the SBC if anybody is interested.
>
> Roger
>

Oh, I really enjoyed your site!
68000, z80, firmwares, etc., everything the technical heart ever wants.
I'm glad to be of help now and then :-)

[David Schultz]

On 1/30/22 1:02 PM, Roger Hanscom wrote:
> I see that CB68 (BASIC compiler) is in the archive. I have copies of it on my SBC, but although it seems to work OK for simple things, anything more complex just generates "exception $03". Anybody find it useful? What am I doing wrong? The compile works OK (no errors), and the link too -- "LINK68".
>

Exception 3 is an address error. As in the program attempted to fetch a
word/long using an odd address. But you knew that...

Run using DDT to find out more.

--
http://davesrocketworks.com
David Schultz

[Roger Hanscom]

On Sunday, January 30, 2022 at 12:36:28 PM UTC-8, Martin wrote:

> Oh, I really enjoyed your site!

Thanks! Google pulled the rug out from under me when they switched over to a new format. IMO, the new format is pretty useless, and they froze the content on my original page when they did the switch, so I can't add to it. Since their freeze, I've managed to build a 68020 SBC that runs at 20 MHz. It's a *real* kludge (for example it is hard-wired for an 8-bit data bus), but I discovered that the 68020 runs quite well that way (I originally thought that it would be "dog-slow"). It has 512k SRAM and 64k EEPROM with 2 serial ports via a 68681. BUT, there is no on-board mass storage (such as a compact flash), so all I can do is download S-records to it and run them. The PCB is small (about 14 cm. x 12 cm.). I've been thinking about trying to build a more full-featured version, but so far I've been reluctant (mostly because the size of the PCB would make it expen$ive!).

> I'm glad to be of help now and then :-)

Much more than "now and then"!

I took a look at the Byte articles on the Definicon. Pretty complete schematics! I'd love to see the equations for the PALs/GALs. I hope you can get yours running!

Roger

[Martin]

Am 01/30/2022 08:02 PM, Roger Hanscom schrieb:

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

>
> I can post a photo of the SBC if anybody is interested.
>
> Roger
>

I think, the CB68 files are somewhat corrupt :-(
The difference to the files below are missing 1AH bytes.

Try the ones from <http://www.cpm.z80.de/download/cb68.zip>

Hth Martin

[Roger Hanscom]

On Sunday, January 30, 2022 at 1:59:34 PM UTC-8, Martin wrote:

> I think, the CB68 files are somewhat corrupt :-(

I think you're 100% correct. Why would a compiler produce an addressing error? Aren't they supposed to catch things like that? Or at least flag it as an error during compile or link?

> Try the ones from <http://www.cpm.z80.de/download/cb68.zip>

Yes, I want to do that. Something must be wrong with the files I have.

and I said:
> I can post a photo of the SBC if anybody is interested.

I lied!! I can't see any way to do that on this thread.

Roger

[Roger Hanscom]

> > Try the ones from <http://www.cpm.z80.de/download/cb68.zip>

No joy! Same result. I guess I need to take David's advice, and probe around with the debugger.

Here' the output from the compile:
--------------------------------------------------
CB68 CBASIC Compiler Version 1.0
Serial No. 3123-0000-000061 All Rights Reserved
Copyright (c) 1983 Digital Research, Inc.
--------------------------------------------------
end of pass 1
end of pass 2
1: FOR Y% = -12 TO 12
2: FOR X% = -39 TO 39
3: CA=FLOAT(X%)*0.0458
4: CB=FLOAT(Y%)*0.08333
5: A=CA
6: B=CB
7: K%=99
8: FOR I% = 0 TO 15
9: IF K% <> 99 THEN GOTO 10
10: T=A*A-B*B+CA
11: B=2.0*A*B+CB
12: A=T
13: IF (A*A+B*B) > 4.0 THEN K%=I%
14: 10 NEXT I%
15: IF K% > 9 THEN K%=K%+7
16: IF K% > 99 THEN PRINT " ";
17: IF K% < 99 THEN PRINT CHR$(48+K%);
18: NEXT X%
19: PRINT
20: NEXT Y%
21: STOP
end of compilation
no errors detected
code area size: 576 00000240h
data area size: 96 00000060h
common area size: 0 00000000h
symbol table space remaining: 49955

Guess I've forgotten how to write BASIC?

Roger

[Martin]

Roger, I cannot reproduce your problem with David's emulator.

I used *both* the CB68.REL and CB68.L68 from
<http://www.cpm.z80.de/download/cb68.zip>

I used the existing linker LINK68.68K in his "diskc.cpm.fs".
The good files are called cb68ok.68k and cb68ok.l68.


C>cb68ok demo

Linking with the bad Library failed:

C>link68 demo.o,cb68.l68
--------------------------------------------------
LINK68 Overlay Linker Release 0.f
Serial No. XXXX-0000 All Rights Reserved

Copyright (c) 1983 Digital Research, Inc.
--------------------------------------------------

demo.o,cb68.l68
LINK68: FILE FORMAT ERROR IN entinp.o


2nd try, now with the good one:

C>link68 demo.o,cb68ok.l68
--------------------------------------------------
LINK68 Overlay Linker Release 0.f
Serial No. XXXX-0000 All Rights Reserved

Copyright (c) 1983 Digital Research, Inc.
--------------------------------------------------

demo.o,cb68ok.l68

C>dir demo*.*
C: DEMO BAS : DEMO 68K : DEMO O


Test with the emulator....

C>demo
000000011111111111111111122222233347E7AB322222111100000000000000000000000000000
000001111111111111111122222222333557BF75433222211111000000000000000000000000000
000111111111111111112222222233445C 643332222111110000000000000000000000000
011111111111111111222222233444556C 654433332211111100000000000000000000000
11111111111111112222233346 D978 BCF DF9 6556F4221111110000000000000000000000
111111111111122223333334469 D 6322111111000000000000000000000
1111111111222333333334457DB 85332111111100000000000000000000
11111122234B744444455556A 96532211111110000000000000000000
122222233347BAA7AB776679 A32211111110000000000000000000
2222233334567 9A A532221111111000000000000000000
222333346679 9432221111111000000000000000000
234445568 F B5432221111111000000000000000000
864332221111111000000000000000000
234445568 F B5432221111111000000000000000000
222333346679 9432221111111000000000000000000
2222233334567 9A A532221111111000000000000000000
122222233347BAA7AB776679 A32211111110000000000000000000
11111122234B744444455556A 96532211111110000000000000000000
1111111111222333333334457DB 85332111111100000000000000000000
111111111111122223333334469 D 6322111111000000000000000000000
11111111111111112222233346 D978 BCF DF9 6556F4221111110000000000000000000000
011111111111111111222222233444556C 654433332211111100000000000000000000000
000111111111111111112222222233445C 643332222111110000000000000000000000000
000001111111111111111122222222333557BF75433222211111000000000000000000000000000
000000011111111111111111122222233347E7AB322222111100000000000000000000000000000

C>

WOW !!!!

[Martin]

Bad news.

It seems, some archives are not in good shape.
Sorry for the noise, didn't know this until now.

[Roger Hanscom]

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

[Martin]

See here for CP/M-68K on his MEX68KECB
<http://davesrocketworks.com/electronics/cpm68/>

The simulator is here
<http://davesrocketworks.com/electronics/cpm68/simulator.html>

I have only compiled the simulator under 32-bit Linux, 64-bit is
not very useful, if you want to run a lot of old utilities :-)

Doing everything under Slackware Linux since +20 years,
I can only really help you to get it running on Linux.

Can the simulator even run on any other OS?


If nothing else, you can at lest copy files out of the HD image
"diskc.cpm.fs" with "cpmtools".

I'm at this time a little bit overwhelmed, to describe everything from
start to end.

But I will try to help you over any difficulties when they arise.

[Steven Hirsch]

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.

[David Schultz]

On 1/31/22 12:45 PM, Martin wrote:
> See here for CP/M-68K on his MEX68KECB
> <http://davesrocketworks.com/electronics/cpm68/>
>
> The simulator is here
> <http://davesrocketworks.com/electronics/cpm68/simulator.html>
>
> I have only compiled the simulator under 32-bit Linux, 64-bit is
> not very useful, if you want to run a lot of old utilities :-)
>
> Doing everything under Slackware Linux since +20 years,
> I can only really help you to get it running on Linux.
>
> Can the simulator even run on any other OS?

That would depend on the 68K sim used as a base: Musashi. Which has
turned out to be a bit of a moving target. I really hated it when the
source files were rearranged which broke existing code (like mine).

Console I/O might need a bit of work.

[David Schultz]

The Internet Archive of course: https://archive.org/index.php

[josef]

> Roger#

I had exactly the same Problem with CB68 (Exception $03) on my 68000 boards.
(On my 68020/030/040/060 CP/M-68k boards there was no error).

After changing the memory region size in my CP/M Bios it worked fine.

* Note: All the Memory Region sizes are rounded to 0xYYYY0 to avoid a problem
* with the executables generated with the CB68 CBASIC compiler.
* For more info see here:
* https://www.retrobrewcomputers.org/forum/index.php?t=msg&th=576&start=0&

Regards,

Josef

[Roger Hanscom]

On Monday, January 31, 2022 at 10:48:20 AM UTC-8, Martin wrote:
...<snip>.....

> See here for CP/M-68K on his MEX68KECB

Thanks for the links, Martin.

> Doing everything under Slackware Linux since +20 years,

You too!! I have been using Slackware for a similar period of time. Best Linux distribution!
If I have *real* work to do, Linux is the only way to go.

> I'm at this time a little bit overwhelmed, to describe everything from start to end.

I understand. I think I can figure it out myself. *grin*

Josef --

>> After changing the memory region size in my CP/M Bios it worked fine.

Thanks for the pointer. I'll check my memory region sizes.

Roger

[Roger Hanscom]

Thanks Josef -- that fixed my problem!

Roger

[Martin]

Am 02/01/2022 06:48 PM, Roger Hanscom schrieb:
> On Monday, January 31, 2022 at 10:48:20 AM UTC-8, Martin wrote:

> ....<snip>.....

The simulator is easy to build. Use the following version of musashi, which works well:
<http://caesar.logiqx.com/zips/libs/cpu/musashi/musashi331.zip>

Go into an empty subdirectory(!), extract both, but don't overwrite the
"m68kconf.h" from cpmsim.zip.

"make"... and a few moments later, you have a running simulator :-)
Just did it, works well under Slackware 14.2 64-bit!

$ make
mkdir obj
gcc -Wall -O2 -c -Iobj -I. cpmsim.c -o obj/sim.o
gcc -Wall m68kmake.c -o obj/m68kmake
obj/m68kmake obj m68k_in.c

Musashi v3.3 68000, 68010, 68EC020, 68020 emulator
Copyright 1998-2000 Karl Stenerud (ka...@mame.net)

Generated 1962 opcode handlers from 503 primitives
gcc -Wall -O2 -c -Iobj -I. m68kcpu.c -o obj/m68kcpu.o
gcc -Wall -O2 -c -Iobj -I. obj/m68kops.c -o obj/m68kops.o
gcc -Wall -O2 -c -Iobj -I. obj/m68kopac.c -o obj/m68kopac.o
gcc -Wall -O2 -c -Iobj -I. obj/m68kopdm.c -o obj/m68kopdm.o
gcc -Wall -O2 -c -Iobj -I. obj/m68kopnz.c -o obj/m68kopnz.o
gcc -Wall -O2 -c -Iobj -I. m68kdasm.c
gcc -Wall obj/sim.o obj/m68kcpu.o obj/m68kops.o obj/m68kopac.o obj/m68kopdm.o obj/m68kopnz.o m68kdasm.o -o cpmsim
$
$ ./cpmsim
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>
C>
C>dir
C: RELOC 68K : DUMP 68K : PIP 68K : STAT 68K : INIT REL
C: SENDC68 68K : DDT 68K : AS68 68K : CP68 68K : AS68INIT
C: C068 68K : C168 68K : AR68 68K : CONFIG 68K : LO68 68K
C: MORE 68K : NM68 68K : SIZE68 68K : COPY SUB : CC REL
C: CC 68K : AS68SYMB DAT : ED 68K : SID 68K : WHEREIS 68K
C: BBYE 68K : UEMACS 68K : F83 BIN : PUTBOOT 68K : AUTOST SUB
C: GREEN 68K : MAKE REL : ARC 68K : EMACS 68K : F83 68K
C: SPLIT 68K : CPM SYS : MAKE 68K : EMACS HLP : DDT68000 68K
C: SID68K 68K : EMACS RC : TAIL 68K : ROBOTS21 68K : PIP REL
C: ERAQ 68K : LINK68 68K
C>bbye
CP/M-68K terminating normally

$


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!

[Martin]

Am 01/31/2022 06:33 PM, Roger Hanscom schrieb:

Rereading your question, I finally understand ...

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

Sorry!

[David Schultz]

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.

[Steven Hirsch]

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

[Peter Higgins]

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

[Roger Hanscom]

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

[David Schultz]

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

[Peter Higgins]

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

[Craig Ruff]

In article <4df62e69-b96b-4996...@googlegroups.com>,

Roger Hanscom <norwe...@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.

[Steven Hirsch]

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?

[David Schultz]

I have a plugin on Firefox that does it.

[Martin]

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

[Josef]

> 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

[David Schultz]

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.

[Martin]

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?

[Bill Shen]

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

[Roger Hanscom]

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

[Martin]

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

[MogensB]

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

[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

[MogensB]

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

[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

[David Schultz]

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.

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

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

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

[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

[MogensB]

I Agree - I wrote a mail to Gaby.

Regards,
MogensB

[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

[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

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

[MogensB]

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

[Martin]

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

[Martin]

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

[MogensB]

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

[David Schultz]

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.

[Udo Munk]

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

[ogd...@gmail.com]

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

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

[MogensB]

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

[David Schultz]

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