1k zx chess sources question

[maksimKorzh]

Hi guys, I have a few questions on 1k zx chess by David Horne:
1. 1K means 1K of RAM?
2. Were there any limitations on source code size?
3. Is it written in assembly because BASIC interpreter takes some RAM on it's own?
4. Are there any ports of 1k zx chess from assembly to whatever languages?
I'm just really interested how one of the pioneer programs look liked in terms of design patterns
and it would be great to figure that out without learning zx assembly)
But if there's no other choice than any references on zx assembly docs?

[hgm]

Things like BASIC interpreters and I/O routines (the equivalent of the BIOS in PCs) were always in ROM in those days. My first chess program was written for an AMICOS 6800-based build-it-yourself computer with 2.125KB RAM, but there was 8KB EPROM with routines to output a character to the video display, or return a character from the keyboard.

[mvanthoor]

Hi guys, I have a few questions on 1k zx chess by David Horne:
1. 1K means 1K of RAM?
2. Were there any limitations on source code size?
3. Is it written in assembly because BASIC interpreter takes some RAM on it's own?
4. Are there any ports of 1k zx chess from assembly to whatever languages?
I'm just really interested how one of the pioneer programs look liked in terms of design patterns
and it would be great to figure that out without learning zx assembly)
But if there's no other choice than any references on zx assembly docs?

If you're interested in this, Sargon from 1978 has been ported / emulated to run on modern computers. It's 5 years older than 1K ZX, and it seems more is known about it.

[maksimKorzh]

Hi guys, I have a few questions on 1k zx chess by David Horne:
1. 1K means 1K of RAM?
2. Were there any limitations on source code size?
3. Is it written in assembly because BASIC interpreter takes some RAM on it's own?
4. Are there any ports of 1k zx chess from assembly to whatever languages?
I'm just really interested how one of the pioneer programs look liked in terms of design patterns
and it would be great to figure that out without learning zx assembly)
But if there's no other choice than any references on zx assembly docs?

If you're interested in this, Sargon from 1978 has been ported / emulated to run on modern computers. It's 5 years older than 1K ZX, and it seems more is known about it.

Oh Marcel!
Sargon!
That's the name!
I was trying to recall it but totally forgot!
There was an entire thread here dedicated to it!
Thank you!

[maksimKorzh]

Things like BASIC interpreters and I/O routines (the equivalent of the BIOS in PCs) were always in ROM in those days. My first chess program was written for an AMICOS 6800-based build-it-yourself computer with 2.125KB RAM, but there was 8KB EPROM with routines to output a character to the video display, or return a character from the keyboard.

Mr. Muller I just confused about the following thing: fit program to certain amount of RAM and source code size.
So this is my current understanding:
1. In RAM we load things like board array, piece offsets, evaluation weights - literally all the variables/constants needed for program to run
2. In EEPROM we store the source code, I guess no matter if it's written in assembly or not
3. BASIC interpreter is also loaded to RAM (You said ROM - is it a typo or otherwise what is ROM?)
Now the idea to write in assembly is to free the RAM from running interpreter.
Is above correct?

Also I guess using minimum amount of ram doesn't mean that the source code would be shorter
and obviously program in assembly would always be longer compared to say same program in C
Is that true?

[mvanthoor]

Oh Marcel!
Sargon!
That's the name!
I was trying to recall it but totally forgot!
There was an entire thread here dedicated to it!
Thank you!

Have fun with it I had Sargon 5 in the beginning of the 90's, before I switched to Fritz. It was a good program, great graphics for its time.

[hgm]

Is above correct?

No.

The ROM contains the 'factory settings' of the computer ('firmware'). So a dedicated chess computer might contain a chess program (as machine code) in ROM, but a general-purpose computer will only contain some kind of operating system in ROM, to access the I/O devices (serial port for connection to a terminal, keyboard, LED display, video interface, if any...). At the very minimum there should be some 'bootstrap loader' that accesses some kind of permanent storage (casette tape, floppy disk), and is able to load the remainder of the OS from that secondary storage into RAM.

Every program that does not belong to the hard-wired fatory set must be loaded into RAM before it can be exectuted. Both the executable machine code, and the data that it uses. For an interpreted language the program is just data as far as the interpreter is concerned. Often the BASIC interpreter's machine code was in ROM (which somethimes was sold separately as an add-on), and the 'BASIC code' (that sometimes was the literal source code, but often had undergone some precompilation, which was more like a compression) resulting from the BASIC program was in RAM.

The 6800 program I was talking about (Usurpator I) had its machine code from memory address 0x100 to 0x707, its global variables from 0 to 0xFF, and its stack from 0x708 to 0x7FF. It interfaced (through subroutine calls) with routines in the system ROM for printing a character, printing a string, printing CR+LF, and reading a character from the keyboard (with echo).

[mvanthoor]

I hope you and HGM doesn't mind that I'm answering this, as I happen to be in this thread now.

Mr. Muller I just confused about the following thing: fit program to certain amount of RAM and source code size.
So this is my current understanding:
1. In RAM we load things like board array, piece offsets, evaluation weights - literally all the variables/constants needed for program to run

Yes.

2. In EEPROM we store the source code, I guess no matter if it's written in assembly or not

No. EEPROM = Electrically Eraseable Programmable Read Only Memory.

This memory can be ereased by running electricity through it, and then it can be reprogrammed. Older computers had (parts of) their operating system, and sometimes also some software, programmed into the EEPROM. You could just turn on the computer and it would work, even without any diskettes or drives. (Obviously, saving stuff in that case would not be possible.)

3. BASIC interpreter is also loaded to RAM (You said ROM - is it a typo or otherwise what is ROM?)

In older computers, as said, the ROM contained the OS and some software. In many computers, a BASIC interpreter was started from the ROM. For some computers, that was the only thing they did; you could then load and run BASIC programs, and that was it. Other computers had this mode of operation, but they could also load other operating systems from floppy, diskette, or drive, if an operating system was available.

Now the idea to write in assembly is to free the RAM from running interpreter.
Is above correct?

There are multiple options:

- Have an assembler that runs in the interpreter (think like a compiler written in BASIC), which loads the ASM source, assembles it, and puts it into RAM to execute it.
- Start an operating system (such as CPM, DOS, whaterver...), which has an assembler program that can convert ASM to executable code (much like a C compiler compiles code).
- Write the ASM code on a different computer, assemble it, and flash it into the ROM, so you can run it from there.

It depends on the computer.

Also I guess using minimum amount of ram doesn't mean that the source code would be shorter
and obviously program in assembly would always be longer compared to say same program in C
Is that true?

ASM programs are very long (many lines), but take very little space. You'd need to do everything by hand.

Play a bit with this: https://godbolt.org/

C-code:

Code: Select all

int square(int num) {
    return num * num;
}

ASM-version:

Code: Select all

square(int):
        push    rbp
        mov     rbp, rsp
        mov     DWORD PTR [rbp-4], edi
        mov     eax, DWORD PTR [rbp-4]
        imul    eax, eax
        pop     rbp
        ret

So the compiler translates the C-code into the ASM-version and in the end the linker links everything together (code can be in multiple files). When writing assembler, you would write the ASM-version by hand. If I had to start like that, I would possibly never have gotten into computers... and then, when you think about it, the ASM version was the "easy" version of setting all the opcodes by hand using mechanical switch boards.

I wrote some ASM on microcontrollers in university in CPU architecture classes, but never had to use it since.

[maksimKorzh]

Is above correct?

No.

The ROM contains the 'factory settings' of the computer ('firmware'). So a dedicated chess computer might contain a chess program (as machine code) in ROM, but a general-purpose computer will only contain some kind of operating system in ROM, to access the I/O devices (serial port for connection to a terminal, keyboard, LED display, video interface, if any...). At the very minimum there should be some 'bootstrap loader' that accesses some kind of permanent storage (casette tape, floppy disk), and is able to load the remainder of the OS from that secondary storage into RAM.

Every program that does not belong to the hard-wired fatory set must be loaded into RAM before it can be exectuted. Both the executable machine code, and the data that it uses. For an interpreted language the program is just data as far as the interpreter is concerned. Often the BASIC interpreter's machine code was in ROM (which somethimes was sold separately as an add-on), and the 'BASIC code' (that sometimes was the literal source code, but often had undergone some precompilation, which was more like a compression) resulting from the BASIC program was in RAM.

The 6800 program I was talking about (Usurpator I) had its machine code from memory address 0x100 to 0x707, its global variables from 0 to 0xFF, and its stack from 0x708 to 0x7FF. It interfaced (through subroutine calls) with routines in the system ROM for printing a character, printing a string, printing CR+LF, and reading a character from the keyboard (with echo).

Thank you for clarifications!

Every program that does not belong to the hard-wired fatory set must be loaded into RAM before it can be exectuted. Both the executable machine code, and the data that it uses.

This is what I've missed!
So say for 1k zx chess both source code and chess data structures (like board array) were fitting only 1k of RAM!
OMG! Now I see why is it so cool!

P.S. Memory layout for Usurpator you've provided reminds me "real mode" OS's layout)

[maksimKorzh]

I hope you and HGM doesn't mind that I'm answering this, as I happen to be in this thread now.

Mr. Muller I just confused about the following thing: fit program to certain amount of RAM and source code size.
So this is my current understanding:
1. In RAM we load things like board array, piece offsets, evaluation weights - literally all the variables/constants needed for program to run

Yes.

2. In EEPROM we store the source code, I guess no matter if it's written in assembly or not

No. EEPROM = Electrically Eraseable Programmable Read Only Memory.

This memory can be ereased by running electricity through it, and then it can be reprogrammed. Older computers had (parts of) their operating system, and sometimes also some software, programmed into the EEPROM. You could just turn on the computer and it would work, even without any diskettes or drives. (Obviously, saving stuff in that case would not be possible.)

3. BASIC interpreter is also loaded to RAM (You said ROM - is it a typo or otherwise what is ROM?)

In older computers, as said, the ROM contained the OS and some software. In many computers, a BASIC interpreter was started from the ROM. For some computers, that was the only thing they did; you could then load and run BASIC programs, and that was it. Other computers had this mode of operation, but they could also load other operating systems from floppy, diskette, or drive, if an operating system was available.

Now the idea to write in assembly is to free the RAM from running interpreter.
Is above correct?

There are multiple options:

- Have an assembler that runs in the interpreter (think like a compiler written in BASIC), which loads the ASM source, assembles it, and puts it into RAM to execute it.
- Start an operating system (such as CPM, DOS, whaterver...), which has an assembler program that can convert ASM to executable code (much like a C compiler compiles code).
- Write the ASM code on a different computer, assemble it, and flash it into the ROM, so you can run it from there.

It depends on the computer.

Also I guess using minimum amount of ram doesn't mean that the source code would be shorter
and obviously program in assembly would always be longer compared to say same program in C
Is that true?

ASM programs are very long (many lines), but take very little space. You'd need to do everything by hand.

Play a bit with this: https://godbolt.org/

C-code:

Code: Select all

int square(int num) {
    return num * num;
}

ASM-version:

Code: Select all

square(int):
        push    rbp
        mov     rbp, rsp
        mov     DWORD PTR [rbp-4], edi
        mov     eax, DWORD PTR [rbp-4]
        imul    eax, eax
        pop     rbp
        ret

So the compiler translates the C-code into the ASM-version and in the end the linker links everything together (code can be in multiple files). When writing assembler, you would write the ASM-version by hand. If I had to start like that, I would possibly never have gotten into computers... and then, when you think about it, the ASM version was the "easy" version of setting all the opcodes by hand using mechanical switch boards.

I wrote some ASM on microcontrollers in university in CPU architecture classes, but never had to use it since.

Thanks for a detailed explanations, Marcel!
I tried assembly myself a bit, here's a micro-Max's movegen port to NASM assembly:
https://github.com/maksimKorzh/nibble-c ... bly/MG.asm
It's weird but works believe it or not)

I was messing up RAM and ROM, now when the difference is pointed out it gets clear)
And the fact that machine code (produced from the source code) is getting loaded into RAM was a bit of a surprise to me)
Definitely it's really logical because otherwise how else it could work but I've completely missed that point)))