mjlef wrote:I took used an Ohio Scientific (C1P I think). It had a "massive" 4k bytes, and I wrote a chess program in interpreted BASIC for it. This was about 1980. When I had a co-op job during a break in college for GE, a boss there gave me some used memory chips allowing me to upgrade it to 8k! Wow! To fit the program I had to use direct peek and poke statements (to allow byte access since and INT would be too big!). And you had to put multiple lines together since breaking them up took too much memory. Even spaces took up memory so it was all squashed together. It only did 3-4 ply searches. I remember after a long drive on icy roads, a chess playing friend, very tired from the drive, agreed to play it. And for the first time, my program won a game!
I tried a couple of time to write a chess program in basic, but did not succeed due to the small memory size of the TRS-80 I had which was 4k. The program as well as all data had to fit in 4k. I don't even know if that was even possible to do in Basic, but it was definitely not possible for my skill level at the time. 4k was the entire RAM in the machine and some of this was needed for the operating system (which was essentially the basic interpreter.)
My start was also on the TRS-80 (1980) running at 1.77 Mhz and 16Kb RAM. The basic interpreter was incredible slow doing only 50 instructions per second and it took 10 minutes to finish a one ply search from the start position, that's about 0.03 NPS When I moved the thing to ASM a got a speed-up with a factor of around 4000 and could do 100-150 NPS. Another royal pain was the cassette recorder to save the sources. Although the source code was split into several parts the bigger ones could take up to 15 minutes to save and then on many occasions the verification check (which took about the same time) reported the save-file was broken. Cleaning the heads of the cassette-recorder for the xx time mostly solved the problem else throw the cassette away and insert a new one. The thing was eating cassettes for breakfast. Crazy times.
Harald wrote:I wrote my first chess program "HLSchach" 1990 on the Atari ST.
It had a nice GEM GUI but the engine was poor and slow.
It was never released.
- The static evaluation was ok
- Alpha-beta search without any tricks
- No hash table
- Poor move ordering, but I tried to dynamically sort good moves to the top.
- The move generator kind of selected valid moves from the sorted list.
- Coded in C and German with a little English
Is anybody interested in the code? The zipped folder includes some pictures
and binaries and has about 400 kByte. Uncompressed source about 300 kByte.
Harald
ah,Atari ST I had one too
You used metacomco C too?
I once ported the basic code from "Das grosse ComputerschachBuch" to C on the Atari.
Data Becker had some real good books those days...
I started with GFA-Basic and Megamax-C on the Atari 1040STF.
Later I changed to TurboC and PureC.
I just found a paper copy of the same chess book and I think it influenced me a lot.
Some code from the book may be found in HLSchach also.
My first thought was, that i wrote HLSchach after reading "Schach am PC" but
that book came later. Perhaps it influenced my other program "Elephant".
Oh, i just see that I have "Das große Computerschachbuch" on my computer
as 233 jpeg files. Together 60 MByte.
mjlef wrote:I took used an Ohio Scientific (C1P I think). It had a "massive" 4k bytes, and I wrote a chess program in interpreted BASIC for it. This was about 1980. When I had a co-op job during a break in college for GE, a boss there gave me some used memory chips allowing me to upgrade it to 8k! Wow! To fit the program I had to use direct peek and poke statements (to allow byte access since and INT would be too big!). And you had to put multiple lines together since breaking them up took too much memory. Even spaces took up memory so it was all squashed together. It only did 3-4 ply searches. I remember after a long drive on icy roads, a chess playing friend, very tired from the drive, agreed to play it. And for the first time, my program won a game!
I tried a couple of time to write a chess program in basic, but did not succeed due to the small memory size of the TRS-80 I had which was 4k. The program as well as all data had to fit in 4k. I don't even know if that was even possible to do in Basic, but it was definitely not possible for my skill level at the time. 4k was the entire RAM in the machine and some of this was needed for the operating system (which was essentially the basic interpreter.)
My start was also on the TRS-80 (1980) running at 1.77 Mhz and 16Kb RAM. The basic interpreter was incredible slow doing only 50 instructions per second and it took 10 minutes to finish a one ply search from the start position, that's about 0.03 NPS When I moved the thing to ASM a got a speed-up with a factor of around 4000 and could do 100-150 NPS. Another royal pain was the cassette recorder to save the sources. Although the source code was split into several parts the bigger ones could take up to 15 minutes to save and then on many occasions the verification check (which took about the same time) reported the save-file was broken. Cleaning the heads of the cassette-recorder for the xx time mostly solved the problem else throw the cassette away and insert a new one. The thing was eating cassettes for breakfast. Crazy times.
I hated that cassette system, but it was all we had for saving files. The Sargon 2 I had purchased loaded from cassette but could not be backed up - until I wrote an assembly program that could make back up copies of things. I put Sargon on 3 or 4 cassettes because I was terrified of losing it. My backups were more reliable than the originals, but when I would play it on the speaker it sounded a lot different. which I thought was odd.
I remember that a for/next loop could count to 500 in about 1 second. I did eventually get a 16k system and there was a way to overclock it which I did.
Don
Capital punishment would be more effective as a preventive measure if it were administered prior to the crime.
Rebel wrote:
My start was also on the TRS-80 (1980) running at 1.77 Mhz and 16Kb RAM. The basic interpreter was incredible slow doing only 50 instructions per second and it took 10 minutes to finish a one ply search from the start position, that's about 0.03 NPS When I moved the thing to ASM a got a speed-up with a factor of around 4000 and could do 100-150 NPS. Another royal pain was the cassette recorder to save the sources. Although the source code was split into several parts the bigger ones could take up to 15 minutes to save and then on many occasions the verification check (which took about the same time) reported the save-file was broken. Cleaning the heads of the cassette-recorder for the xx time mostly solved the problem else throw the cassette away and insert a new one. The thing was eating cassettes for breakfast. Crazy times.
I remember that in the beginning I was using two cassette recorders on the Heatkit H8, first I had to load the assembler with one recorder and after loading the assembler I could load the source, the object code was written to the second cassette recorder. I never used BASIC for chess programming because it was way to slow. Somewhere around 1981 Zortech C became available for CP/M and I translated the whole program to C. It was about two times slower than the ASM version but much easier to code. Nowadays the optimizers in the C/C++ compilers are incredibly efficient and it is virtually impossible to get better results with assembler.
Rebel wrote:
My start was also on the TRS-80 (1980) running at 1.77 Mhz and 16Kb RAM. The basic interpreter was incredible slow doing only 50 instructions per second and it took 10 minutes to finish a one ply search from the start position, that's about 0.03 NPS When I moved the thing to ASM a got a speed-up with a factor of around 4000 and could do 100-150 NPS. Another royal pain was the cassette recorder to save the sources. Although the source code was split into several parts the bigger ones could take up to 15 minutes to save and then on many occasions the verification check (which took about the same time) reported the save-file was broken. Cleaning the heads of the cassette-recorder for the xx time mostly solved the problem else throw the cassette away and insert a new one. The thing was eating cassettes for breakfast. Crazy times.
I remember that in the beginning I was using two cassette recorders on the Heatkit H8, first I had to load the assembler with one recorder and after loading the assembler I could load the source, the object code was written to the second cassette recorder. I never used BASIC for chess programming because it was way to slow. Somewhere around 1981 Zortech C became available for CP/M and I translated the whole program to C. It was about two times slower than the ASM version but much easier to code. Nowadays the optimizers in the C/C++ compilers are incredibly efficient and it is virtually impossible to get better results with assembler.
I knew that basic wouldn't cut it for chess, but I learned how to program from the excellent tutorial manual that came with the TSR-80. I don't know if I have ever seen such a well presented manual in my life since. When Radio Shack called me it just happened that I was starting my 4 day break from work as a crane operator at a steel mill. I picked up the machine, locked myself in my room for 4 days and came out knowing how to program!
I later purchased the assembler and learned how to program z-80 assembly.
I had written a fun "reaction test" program in basic, something would pop up on the screen and you had to react as quickly as possible by hitting a key. testing for keyboard input while counting made the resolution of this timer very low. So I coded it in machine code, in those days it was common practice to load it into a string and there was a basic keyword which would execute the code stored there I think. I still remember that after this change the resolution of the timer was about 1/60000 - in other words I could test for keyboard input 60,000 times per second! It was orders of magnitude more than in basic. I don't remember the resolution in basic but it was pathetic - something in the double digits, perhaps 15 or 20 time per second.
Capital punishment would be more effective as a preventive measure if it were administered prior to the crime.
Don wrote:So I coded it in machine code, in those days it was common practice to load it into a string and there was a basic keyword which would execute the code stored there I think.
Ahhh, the good old TRS-80 days. VARPTR() would tell you the address of your string and you then POKE'd your assembly code into it. I can't remember the command to 'execute' the string, I think it was a form of GOSUB with the address. You had to use only relative addresses and your assembly subroutine couldn't be too long - strings were limited to 256 bytes IIRC - but a few well placed packed strings could really give your program a boost.
I started with the 16k Level II machine so I never had the 4k limitation. As soon as I could afford to I bought the expansion kit so I could attach a floppy drive. Man, was that great, that %$@# cassette tape would load programs just slightly faster than you could type them in.
Don wrote:So I coded it in machine code, in those days it was common practice to load it into a string and there was a basic keyword which would execute the code stored there I think.
Ahhh, the good old TRS-80 days. VARPTR() would tell you the address of your string and you then POKE'd your assembly code into it. I can't remember the command to 'execute' the string, I think it was a form of GOSUB with the address. You had to use only relative addresses and your assembly subroutine couldn't be too long - strings were limited to 256 bytes IIRC - but a few well placed packed strings could really give your program a boost.
I started with the 16k Level II machine so I never had the 4k limitation. As soon as I could afford to I bought the expansion kit so I could attach a floppy drive. Man, was that great, that %$@# cassette tape would load programs just slightly faster than you could type them in.
Best
Dan H.
It's all coming back to me now! I found this on the web:
USR ( I1 ) returns I2
Calls an assembly-language routine. Prior to calling USR, the address of the routine must be stored (using, e.g., POKE), little-endian, in addresses 16526 and 16527. Within the assembly-language program, "CALL 0A7FH" loads I1 into the HL register pair, and "JP 0A9AH" returns the HL register pair as I2. Note that an assembly-language routine called by USR is only allocated 8 stack entries.
Capital punishment would be more effective as a preventive measure if it were administered prior to the crime.
Don wrote:It's all coming back to me now! I found this on the web:
USR ( I1 ) returns I2
Calls an assembly-language routine. Prior to calling USR, the address of the routine must be stored (using, e.g., POKE), little-endian, in addresses 16526 and 16527. Within the assembly-language program, "CALL 0A7FH" loads I1 into the HL register pair, and "JP 0A9AH" returns the HL register pair as I2. Note that an assembly-language routine called by USR is only allocated 8 stack entries.
Yes! USR() - how could I forget. It really made a pretty good system; use BASIC to get your input and parse it then call an assembly routine to do screen animation or other functions that would bog BASIC down.
When I moved the thing to ASM a got a speed-up with a factor of around 4000 and could do 100-150 NPS. Another royal pain was the cassette recorder to save the sources. Although the source code was split into several parts the bigger ones could take up to 15 minutes to save and then on many occasions the verification check (which took about the same time) reported the save-file was broken. Cleaning the heads of the cassette-recorder for the xx time mostly solved the problem else throw the cassette away and insert a new one. The thing was eating cassettes for breakfast. Crazy times.
I had one too 
