https://github.com/ratboy666/string

After I published APU.REL for FORTRAN-80 AM9511 support, I started using more Microsoft FORTRAN-80. The problem? String handling is very poor when
compared to BASIC-80 (MBASIC or BASCOM). I did a little research, and found an article by D R Hanson. Hanson is known more for his work with SNOBOL4, but I found an article from November 1974, describing a technique for implementing strings in FORTRAN IV. I completed a "quick and dirty" implementation which I am publishing as STRLIB.REL

Enjoy! (this library was of great help to me in writing FORTRAN test routines)

Fred Weigel

PS. Feel free to suggest more or different routines for this library. I just implemented a string library that would help me.

On 25/08/21 20:38, fridtjof.ma...@gmail.com wrote:
> https://github.com/ratboy666/string
>
> After I published APU.REL for FORTRAN-80 AM9511 support, I started using more Microsoft FORTRAN-80. The problem? String handling is very poor when
> compared to BASIC-80 (MBASIC or BASCOM). I did a little research, and found an article by D R Hanson. Hanson is known more for his work with SNOBOL4, but I found an article from November 1974, describing a technique for implementing strings in FORTRAN IV. I completed a "quick and dirty" implementation which I am publishing as STRLIB.REL
>
> Enjoy! (this library was of great help to me in writing FORTRAN test routines)
>
> Fred Weigel
>
> PS. Feel free to suggest more or different routines for this library. I just implemented a string library that would help me.

you can give pointers and/or bibliographical reference for that Hanson's
1974 article ?

Best regards from Italy,
dott. Piergiorgio.

dott.Piergiorgio schrieb am Donnerstag, 26. August 2021 um 10:13:42 UTC+2:
> you can give pointers and/or bibliographical reference for that Hanson's
> 1974 article ?

It is in Communications of the ACM, November 1974.

On Thu, 26 Aug 2021 03:04:05 -0700, Udo Munk wrote:

> dott.Piergiorgio schrieb am Donnerstag, 26. August 2021 um 10:13:42
> UTC+2:
>> you can give pointers and/or bibliographical reference for that
>> Hanson's 1974 article ?
>
> It is in Communications of the ACM, November 1974.

A PDF of the article is available for free here:
https://www.researchgate.net/publication/
220427150_A_Simple_Technique_for_Representing_Strings_in_Fortran_IV

On Thursday, August 26, 2021 at 4:25:38 PM UTC-4, Captain Nemo wrote:
> On Thu, 26 Aug 2021 03:04:05 -0700, Udo Munk wrote:
>
> > dott.Piergiorgio schrieb am Donnerstag, 26. August 2021 um 10:13:42
> > UTC+2:
> >> you can give pointers and/or bibliographical reference for that
> >> Hanson's 1974 article ?
> >
> > It is in Communications of the ACM, November 1974.
> A PDF of the article is available for free here:
> https://www.researchgate.net/publication/
> 220427150_A_Simple_Technique_for_Representing_Strings_in_Fortran_IV

Thanks, Captain Nemo!

Strange thing happened... And, it amused me, so I am sharing with the group here.
Someone (user CTOsian - and I don't know who that is) posted my strlib link in github
to hacker news (https://news.ycombinator.com/).

Normally, I will get a few visits to github, and a few downloads. I look to see if there
is any interest. Don't expect much, because my stuff is not that popular. I mean, my most
popular work is my qjs-ffi (foreign function interface for fabrice bellards quick js). That
one has been forked three times, and may get as many as15 views in a day.

I was shocked to see that over 2000 people had visited the fortran string library!
What the heck was going on? Because, um... FORTRAN-80 is a bit dead, you know.
Turns out that people were coming from hacker news.

Fascinating, and amusing. Maybe some of them will become retro computing
enthusiasts. We will see...

Fred

fridtjof.ma...@gmail.com schrieb am Freitag, 27. August 2021 um 15:04:36 UTC+2:
> I was shocked to see that over 2000 people had visited the fortran string library!
> What the heck was going on? Because, um... FORTRAN-80 is a bit dead, you know.

I would be careful with such statements ;-) You see, F80 3.44 is a very efficient compiler
for 8080 systems, no C compiler and the like produces so dense code. Is as good as
Intel's PLM compiler for 8080. Unfortunately it is not fully standard compatible as
Microsoft claims, I have example code that compiles and works OK with any other
FORTRAN IV compiler than the one from Microsoft.

For example, when people look into my GSX-80 stuff they start to wonder why the hell
I implemented the Tek GSX driver in FORTRAN instead of using a modern language.
Here is your answers:

1. because I can, or lets say I wanted to know if I still can write low level driver code
in FORTRAN.
2. the GSX drivers are loadable, GSX needs to reserve space for the largest driver in
the configuration in case you switch workstations. I clearly did not want to be the
largest guy and with using FORTRAN-80 instead of another language compiler
I managed to do that.
3. Good example to show that low level driver code can be written structured
well even in FORTRAN IV, if used properly it won't result in unreadable spaghetti
code.

On Fri, 27 Aug 2021 06:04:35 -0700, fridtjof.ma...@gmail.com wrote:

> I was shocked to see that over 2000 people had visited the fortran
> string library!
> What the heck was going on? Because, um... FORTRAN-80 is a bit dead, you
> know.
> Turns out that people were coming from hacker news.

In my case, I actually use (play with, more than anything) FORTRAN-80 on
my TRS-80 4P and Kaypros.

On Friday, August 27, 2021 at 9:50:56 AM UTC-4, Udo Munk wrote:
> fridtjof.ma...@gmail.com schrieb am Freitag, 27. August 2021 um 15:04:36 UTC+2:
> > I was shocked to see that over 2000 people had visited the fortran string library!
> > What the heck was going on? Because, um... FORTRAN-80 is a bit dead, you know.
> I would be careful with such statements ;-) You see, F80 3.44 is a very efficient compiler
> for 8080 systems, no C compiler and the like produces so dense code. Is as good as
> Intel's PLM compiler for 8080. Unfortunately it is not fully standard compatible as
> Microsoft claims, I have example code that compiles and works OK with any other
> FORTRAN IV compiler than the one from Microsoft.
>
> For example, when people look into my GSX-80 stuff they start to wonder why the hell
> I implemented the Tek GSX driver in FORTRAN instead of using a modern language.
> Here is your answers:
>
> 1. because I can, or lets say I wanted to know if I still can write low level driver code
> in FORTRAN.
> 2. the GSX drivers are loadable, GSX needs to reserve space for the largest driver in
> the configuration in case you switch workstations. I clearly did not want to be the
> largest guy and with using FORTRAN-80 instead of another language compiler
> I managed to do that.
> 3. Good example to show that low level driver code can be written structured
> well even in FORTRAN IV, if used properly it won't result in unreadable spaghetti
> code.
Udo

Can you post an example of FORTRAN IV that doesn't work with F80? I am curious.
So far, except for INTEGER is only 1/2 storage unit, not 1, everything appears ok
(when looking at code generation). IBM 1130 FORTRAN did the same thing (but you
needed *ONE WORD INTEGERS control card to turn that behaviour on).

I don't like the forced ordering of statements in F80. That prevents using INCLUDE
to bring in COMMON definitions (the type and COMMON need to be split).
Same deal with EQUIVALENCE. Just plain annoying. That, and the lack
of COMPLEX.

Also, I just updated STRLIB. Added Command Line access, prompted string input,
some functions to help with using ENCODE/DECODE. I think it is now "feature
complete" as they say.

Fred

fridtjof.ma...@gmail.com schrieb am Freitag, 3. September 2021 um 17:50:49 UTC+2:
> Can you post an example of FORTRAN IV that doesn't work with F80? I am curious.

The chess program here:
https://www.autometer.de/unix4fun/z80pack/ftp/sources/stuff/
On Z80 systems you can use Cromemco FORTRAN-IV but not F80.
Also compiles OK with modern GNU FORTRAN compilers, or the old f77 one.
> I don't like the forced ordering of statements in F80. That prevents using INCLUDE
> to bring in COMMON definitions (the type and COMMON need to be split).
> Same deal with EQUIVALENCE. Just plain annoying. That, and the lack
> of COMPLEX.

Well, the lack of COMPLEX is OK, because it implements subset G.
But the not properly implemented features of the subset are annoying.

On Friday, September 3, 2021 at 12:23:03 PM UTC-4, Udo Munk wrote:
> fridtjof.ma...@gmail.com schrieb am Freitag, 3. September 2021 um 17:50:49 UTC+2:
> > Can you post an example of FORTRAN IV that doesn't work with F80? I am curious.
> The chess program here:
> https://www.autometer.de/unix4fun/z80pack/ftp/sources/stuff/
> On Z80 systems you can use Cromemco FORTRAN-IV but not F80.
> Also compiles OK with modern GNU FORTRAN compilers, or the old f77 one.
> > I don't like the forced ordering of statements in F80. That prevents using INCLUDE
> > to bring in COMMON definitions (the type and COMMON need to be split).
> > Same deal with EQUIVALENCE. Just plain annoying. That, and the lack
> > of COMPLEX.
> Well, the lack of COMPLEX is OK, because it implements subset G.
> But the not properly implemented features of the subset are annoying.
Udo

Thanks.

I am going to compile it and see what is going on!

Fred

On Friday, September 3, 2021 at 2:29:38 PM UTC-4, fridtjof.ma...@gmail.com wrote:
> On Friday, September 3, 2021 at 12:23:03 PM UTC-4, Udo Munk wrote:
> > fridtjof.ma...@gmail.com schrieb am Freitag, 3. September 2021 um 17:50:49 UTC+2:
> > > Can you post an example of FORTRAN IV that doesn't work with F80? I am curious.
> > The chess program here:
> > https://www.autometer.de/unix4fun/z80pack/ftp/sources/stuff/
> > On Z80 systems you can use Cromemco FORTRAN-IV but not F80.
> > Also compiles OK with modern GNU FORTRAN compilers, or the old f77 one.
> > > I don't like the forced ordering of statements in F80. That prevents using INCLUDE
> > > to bring in COMMON definitions (the type and COMMON need to be split).
> > > Same deal with EQUIVALENCE. Just plain annoying. That, and the lack
> > > of COMPLEX.
> > Well, the lack of COMPLEX is OK, because it implements subset G.
> > But the not properly implemented features of the subset are annoying.
> Udo
>
> Thanks.
>
> I am going to compile it and see what is going on!
>
> Fred

I added a name to the BLOCK DATA, change LP and LR to both be 1, compiling for second time,
will then link and attempt a run. This FORTRAN code predates FORTRAN 66 - maybe started with
a FORTRAN II program? (heavily arithmetic IF). EQUIVALENCE is not used, nor are REAL or INTEGER, so its not
a size unit issue. Some logical IF, but they appear added later. Lots of COMMON, *and* 12 parameters
for WMOVE(). FUNCTION is not used, only SUBROUTINE.

Fred

On Friday, September 3, 2021 at 3:24:47 PM UTC-4, fridtjof.ma...@gmail.com wrote:
> On Friday, September 3, 2021 at 2:29:38 PM UTC-4, fridtjof.ma...@gmail.com wrote:
> > On Friday, September 3, 2021 at 12:23:03 PM UTC-4, Udo Munk wrote:
> > > fridtjof.ma...@gmail.com schrieb am Freitag, 3. September 2021 um 17:50:49 UTC+2:
> > > > Can you post an example of FORTRAN IV that doesn't work with F80? I am curious.
> > > The chess program here:
> > > https://www.autometer.de/unix4fun/z80pack/ftp/sources/stuff/
> > > On Z80 systems you can use Cromemco FORTRAN-IV but not F80.
> > > Also compiles OK with modern GNU FORTRAN compilers, or the old f77 one.
> > > > I don't like the forced ordering of statements in F80. That prevents using INCLUDE
> > > > to bring in COMMON definitions (the type and COMMON need to be split).
> > > > Same deal with EQUIVALENCE. Just plain annoying. That, and the lack
> > > > of COMPLEX.
> > > Well, the lack of COMPLEX is OK, because it implements subset G.
> > > But the not properly implemented features of the subset are annoying.
> > Udo
> >
> > Thanks.
> >
> > I am going to compile it and see what is going on!
> >
> > Fred
> I added a name to the BLOCK DATA, change LP and LR to both be 1, compiling for second time,
> will then link and attempt a run. This FORTRAN code predates FORTRAN 66 - maybe started with
> a FORTRAN II program? (heavily arithmetic IF). EQUIVALENCE is not used, nor are REAL or INTEGER, so its not
> a size unit issue. Some logical IF, but they appear added later. Lots of COMMON, *and* 12 parameters
> for WMOVE(). FUNCTION is not used, only SUBROUTINE.
>
> Fred

Now, with the three changes indicated, link and run:

B>chess

MIKES CHESS PROGRAM

LEVEL 0 OR 1 ?0

COMPUTER TO PLAY WHITE (0) OR BLACK (1) ? 0

1. MY MOVE:-
E2-E4
YOUR MOVE:- ?

YOUR MOVE:-

I don't actually know how to use this program...

Fred

To summarize

BLOCKDATA becomes BLOCKDATA DATA

LP=1 and LR=1

compile, link and run!

What did you see as the issue? I will try a deeper game later, once I figure out how to make it print a board out...

Fred

On Friday, September 3, 2021 at 3:34:08 PM UTC-4, fridtjof.ma...@gmail.com wrote:
> On Friday, September 3, 2021 at 3:24:47 PM UTC-4, fridtjof.ma...@gmail.com wrote:
> > On Friday, September 3, 2021 at 2:29:38 PM UTC-4, fridtjof.ma...@gmail.com wrote:
> > > On Friday, September 3, 2021 at 12:23:03 PM UTC-4, Udo Munk wrote:
> > > > fridtjof.ma...@gmail.com schrieb am Freitag, 3. September 2021 um 17:50:49 UTC+2:
> > > > > Can you post an example of FORTRAN IV that doesn't work with F80? I am curious.
> > > > The chess program here:
> > > > https://www.autometer.de/unix4fun/z80pack/ftp/sources/stuff/
> > > > On Z80 systems you can use Cromemco FORTRAN-IV but not F80.
> > > > Also compiles OK with modern GNU FORTRAN compilers, or the old f77 one.
> > > > > I don't like the forced ordering of statements in F80. That prevents using INCLUDE
> > > > > to bring in COMMON definitions (the type and COMMON need to be split).
> > > > > Same deal with EQUIVALENCE. Just plain annoying. That, and the lack
> > > > > of COMPLEX.
> > > > Well, the lack of COMPLEX is OK, because it implements subset G.
> > > > But the not properly implemented features of the subset are annoying.
> > > Udo
> > >
> > > Thanks.
> > >
> > > I am going to compile it and see what is going on!
> > >
> > > Fred
> > I added a name to the BLOCK DATA, change LP and LR to both be 1, compiling for second time,
> > will then link and attempt a run. This FORTRAN code predates FORTRAN 66 - maybe started with
> > a FORTRAN II program? (heavily arithmetic IF). EQUIVALENCE is not used, nor are REAL or INTEGER, so its not
> > a size unit issue. Some logical IF, but they appear added later. Lots of COMMON, *and* 12 parameters
> > for WMOVE(). FUNCTION is not used, only SUBROUTINE.
> >
> > Fred
> Now, with the three changes indicated, link and run:
>
> B>chess
>
>
>
> MIKES CHESS PROGRAM
>
>
> LEVEL 0 OR 1 ?0
>
> COMPUTER TO PLAY WHITE (0) OR BLACK (1) ? 0
>
>
>
> 1. MY MOVE:-
> E2-E4
> YOUR MOVE:- ?
>
> YOUR MOVE:-
>
>
> I don't actually know how to use this program...
>
> Fred
>
> To summarize
>
> BLOCKDATA becomes BLOCKDATA DATA
>
> LP=1 and LR=1
>
> compile, link and run!
>
> What did you see as the issue? I will try a deeper game later, once I figure out how to make it print a board out...
>
> Fred
And it plays -- very weak chess. But it plays!

The lack of a name on the BLOCK DATA may have been a mess-up:
Just tried it - leads to multiple definition of $MAIN
The first is the real $MAIN, so the second is not loaded. Which happens to be
all the initialization data! The fix is to put a name on the BLOCKDATA line (pretty much any name
will do: I used DATA, and that should work for gfortran as well)

Fred

fridtjof.ma...@gmail.com schrieb am Freitag, 3. September 2021 um 21:24:47 UTC+2:
> I added a name to the BLOCK DATA, change LP and LR to both be 1, compiling for second time,
> will then link and attempt a run. This FORTRAN code predates FORTRAN 66 - maybe started with
> a FORTRAN II program? (heavily arithmetic IF). EQUIVALENCE is not used, nor are REAL or INTEGER, so its not
> a size unit issue. Some logical IF, but they appear added later. Lots of COMMON, *and* 12 parameters
> for WMOVE(). FUNCTION is not used, only SUBROUTINE.

Yes, that predates FORTRAN 66, we used it decades ago on IBM mainframes with FORTRAN or FORTRAN II,
and later was modified for IBM's FORTRAN IV.

fridtjof.ma...@gmail.com schrieb am Freitag, 3. September 2021 um 21:34:08 UTC+2:
> I don't actually know how to use this program...

There also is a textile that explains how to play.

> BLOCKDATA becomes BLOCKDATA DATA

Yep, but unnamed BLOCKDATA is valid in the standard.

fridtjof.ma...@gmail.com schrieb am Freitag, 3. September 2021 um 22:38:12 UTC+2:
> And it plays -- very weak chess. But it plays!
Yep, but it is pretty much the first chess program that can play a complete game.

On Friday, September 3, 2021 at 5:13:19 PM UTC-4, Udo Munk wrote:
> fridtjof.ma...@gmail.com schrieb am Freitag, 3. September 2021 um 21:34:08 UTC+2:
> > I don't actually know how to use this program...
> There also is a textile that explains how to play.
>
> > BLOCKDATA becomes BLOCKDATA DATA
>
> Yep, but unnamed BLOCKDATA is valid in the standard.

Yes, that is a violation of F80. But it was a "quick fix". It doesn't seem play quite as well
as Microchess. I think I'll have to arrange a competition (have you tried that?).

It does suffer from "position blindness". I convinced it to give up 2 bishops and a knight to
protect its queen. That was a problem with Microchess as well, "back in the day".

Fred

fridtjof.ma...@gmail.com schrieb am Samstag, 4. September 2021 um 03:37:54 UTC+2:
> Yes, that is a violation of F80. But it was a "quick fix". It doesn't seem play quite as well
> as Microchess. I think I'll have to arrange a competition (have you tried that?).

I know, I just left as is to show the false claims of Microsoft about their implementation
compatible to the subset G standard.

Yes, it plays worse than even Microchess. It gets better at level 1, but that requires a much
faster modern system, on a 2-4 MHz 8 bit processor it takes ages to compute a move.

> It does suffer from "position blindness". I convinced it to give up 2 bishops and a knight to
> protect its queen. That was a problem with Microchess as well, "back in the day".

This is the problem of all the early chess programs, no position awareness, just an implementation
based on the Claude Shannon paper. Later programs like MyChess and Sargon are much better.

On Saturday, September 4, 2021 at 1:13:27 AM UTC-7, Udo Munk wrote:
..... <snip> ....
>> Later programs like MyChess and Sargon are much better.

But I think I remember being highly disappointed by Sargon? I got the book (with the code listed), and tried to get it working on my Z80. I couldn't afford to purchase the actual program. I found that it cheated!! But, maybe I just broke the code in porting it to my system? The book version utilized graphics, and I had no graphics capability on my (then) primitive Z80..

Roger

norwe...@gmail.com schrieb am Samstag, 4. September 2021 um 19:02:47 UTC+2:
> On Saturday, September 4, 2021 at 1:13:27 AM UTC-7, Udo Munk wrote:
> .... <snip> ....
> >> Later programs like MyChess and Sargon are much better.
> But I think I remember being highly disappointed by Sargon? I got the book (with the code listed), and tried
> to get it working on my Z80. I couldn't afford to purchase the actual program. I found that it cheated!! But,
> maybe I just broke the code in porting it to my system? The book version utilized graphics, and I had no
> graphics capability on my (then) primitive Z80.

No the program didn't cheat, but the listing from the book has two known bugs that later were fixed.
The initial program was for a Z80 systems with pseudo graphics character set, but it also got ported
to CP/M utilising the usual board printout with ASCII characters. Both, Sargon and Sargon 2 still
are available for CP/M, you can find copies on the chess disk in the z80pack repository here:

https://www.autometer.de/unix4fun/z80pack/ftp/

On Saturday, September 4, 2021 at 11:49:09 AM UTC-7, Udo Munk wrote:
......<snip>......
>> Both, Sargon and Sargon 2 still are available for CP/M,

Udo, do you know, offhand, what the difference is between Sargon and Sargon 2 ??

Roger

On Sunday, September 5, 2021 at 3:58:05 PM UTC-4, norwe...@gmail.com wrote:
> On Saturday, September 4, 2021 at 11:49:09 AM UTC-7, Udo Munk wrote:
> .....<snip>......
> >> Both, Sargon and Sargon 2 still are available for CP/M,
> Udo, do you know, offhand, what the difference is between Sargon and Sargon 2 ??
>
> Roger

Sargon was the original program released in 1978, Sargon 2 was an improvement, released in 1979.
Sargon 2 is much stronger. But, hey, I was coding for Microchess (TRS-80 and PET displays) back then,
so I *am* biased. My comment was about CHESS.FOR, which Sargon would east for breakfast
(I just played a game or two with CHESS.FOR).

As a PS for Udo: how about "ASSIGN 1 TO I", then later "GOTO I" in Microsoft F80. Nicely generates
"LHLD I, PCHL"! That is rather sweet. Since I does not have to be declared "label associated" as there
is no way to do that in FORTRAN IV anyway, this allow us to implement jump vectors and threaded
code directly! Maybe I'll play with it a bit -- but, consider. A RETURN is just that: RET. No stack parameters
are used. Which means that pushing some INTEGER labels into COMMON then F80 gains some "hyper"
flow control. Amuses me... Didn't use this "back in the day" -- we kind of frowned on assigned goto.
Fred

norwe...@gmail.com schrieb am Sonntag, 5. September 2021 um 21:58:05 UTC+2:
> On Saturday, September 4, 2021 at 11:49:09 AM UTC-7, Udo Munk wrote:
> .....<snip>......
> >> Both, Sargon and Sargon 2 still are available for CP/M,
> Udo, do you know, offhand, what the difference is between Sargon and Sargon 2 ??

Sargon 2 is much stronger, average players will have problems to beat it even at lower settings.

fridtjof.ma...@gmail.com schrieb am Montag, 6. September 2021 um 00:21:15 UTC+2:
> Sargon was the original program released in 1978, Sargon 2 was an improvement, released in 1979.
> Sargon 2 is much stronger. But, hey, I was coding for Microchess (TRS-80 and PET displays) back then,

Cool, I had Microchess 2.0 for the PET and Apple, loved to play against these due to lack
of human opponents.

> so I *am* biased. My comment was about CHESS.FOR, which Sargon would east for breakfast
> (I just played a game or two with CHESS.FOR).

Playing against CHESS.FOR is not a challenge, but the source is interesting.

> As a PS for Udo: how about "ASSIGN 1 TO I", then later "GOTO I" in Microsoft F80. Nicely generates
> "LHLD I, PCHL"! That is rather sweet. Since I does not have to be declared "label associated" as there
> is no way to do that in FORTRAN IV anyway, this allow us to implement jump vectors and threaded
> code directly! Maybe I'll play with it a bit -- but, consider. A RETURN is just that: RET. No stack parameters
> are used. Which means that pushing some INTEGER labels into COMMON then F80 gains some "hyper"
> flow control. Amuses me... Didn't use this "back in the day" -- we kind of frowned on assigned goto.

Computed GO TO's, don't know why they frowned on it, properly used it allows to write very fast dispatcher
code, like for example I did in the Tektronix gsx80 driver:

C
C DISPATCH ON OPCODE
C GOTO(1100,1200,1300,1400,1500,1600,1700,1800,1900,2000,
1 2100,2200,2300,2400,2500,2600,2700,2800,2900,3000,
2 3100,3200,3300,3400,3500,3600,3700,3800,3900,4000,
3 4100,4200,4300),OPCODE
RETURN

This is not different from a case in C and the compiler generates very efficient code. Can be
abused of course for really hard to understand spaghetti code jumping forth and back all over
the place.