https://github.com/ratboy666/stringIV. I completed a "quick and dirty" implementation which I am publishing as STRLIB.REL
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
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 ?
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
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 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.
fridtjof.ma...@gmail.com schrieb am Freitag, 27. August 2021 um 15:04:36 UTC+2:Udo
I was shocked to see that over 2000 people had visited the fortran string library!I would be careful with such statements ;-) You see, F80 3.44 is a very efficient compiler
What the heck was going on? Because, um... FORTRAN-80 is a bit dead, you know.
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.
Can you post an example of FORTRAN IV that doesn't work with F80? I am curious.
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.
fridtjof.ma...@gmail.com schrieb am Freitag, 3. September 2021 um 17:50:49 UTC+2:Udo
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 INCLUDEWell, the lack of COMPLEX is OK, because it implements subset G.
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.
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:Udo
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 INCLUDEWell, the lack of COMPLEX is OK, because it implements subset G.
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.
But the not properly implemented features of the subset are annoying.
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:Udo
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 INCLUDEWell, the lack of COMPLEX is OK, because it implements subset G.
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.
But the not properly implemented features of the subset are annoying.
Thanks.
I am going to compile it and see what is going on!
FredI 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
chess
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:Udo
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 INCLUDEWell, the lack of COMPLEX is OK, because it implements subset G.
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.
But the not properly implemented features of the subset are annoying.
Thanks.
I am going to compile it and see what is going on!
FredI 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.
FredNow, with the three changes indicated, link and run:
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...And it plays -- very weak chess. But it plays!
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
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.
I don't actually know how to use this program...
BLOCKDATA becomes BLOCKDATA DATA
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.
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".
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> ....
But I think I remember being highly disappointed by Sargon? I got the book (with the code listed), and triedLater programs like MyChess and Sargon are much better.
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.
Both, Sargon and Sargon 2 still are available for CP/M,
On Saturday, September 4, 2021 at 11:49:09 AM UTC-7, Udo Munk wrote: .....<snip>......
Udo, do you know, offhand, what the difference is between Sargon and Sargon 2 ??Both, Sargon and Sargon 2 still are available for CP/M,
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.
On Saturday, September 4, 2021 at 11:49:09 AM UTC-7, Udo Munk wrote: .....<snip>......
Udo, do you know, offhand, what the difference is between Sargon and Sargon 2 ??Both, Sargon and Sargon 2 still are available for CP/M,
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 285 |
Nodes: | 16 (2 / 14) |
Uptime: | 70:00:17 |
Calls: | 6,488 |
Calls today: | 1 |
Files: | 12,096 |
Messages: | 5,275,483 |