5 ms·

I think it's helpful to consider that this program in 672 bytes of machine code rather than source code or assembler. That helps the comparisons to English text

by astine 12y ago

I think it's helpful to consider that this program in 672 bytes of machine code rather than source code or assembler. That helps the comparisons to English text seem a little less jarring: if my words were expressed as 8bit bytes rather than a series of byte sized chars you'd see a lot of compression in my communication. He also 'cheats' a bit by keeping part of the program on tape and never loading it into memory so it doesn't count toward the 672 byte limit. That's a good trick that I wouldn't have thought to do with display code.

acqq 12y ago
> He also 'cheats' a bit by keeping part of the program on tape and never loading it into memory so it doesn't count toward the 672 byte limit. I'm missing something here, but if something is never loaded in the memory, why should be counted? Why do you consider that a part of the program at all? Can you please also provide more technical details, since I don't understand what you mean?
- astine 12y ago
  In a way you're right, the executable is definitely within bounds and if that is your definition of the program, it's small enough. If you count resources that are necessary to make the program run, however, you'd use a different metric.
  - acqq 12y ago
    What do you mean? The program really plays chess against the user by running in the 1K RAM of the computer that is designed to spend 768 bytes of the said 1K just for the screen content. http://en.wikipedia.org/wiki/ZX81 http://en.wikipedia.org/wiki/ZX81 24 lines of 32 characters. 768 bytes usually cleared and scrolled away as you type. The user just has to load the cassette and play. Even if the program was developed on the Cray (it was not) everything needed for the program to run is less than 1K. Please explain your sentence "If you count resources that are necessary to make the program run, however, you'd use a different metric." See the proof: https://archive.org/stream/popular-computing-weekly-1982-07-15/PopularComputing_Weekly_Issue_1982-07-15#page/n11/mode/2up https://archive.org/stream/popular-computing-weekly-1982-07-... "The tape loads every time, without problems, in about 30 seconds." The cassette speed of ZX 81 was 250 bits per second, 30 seconds is less than 1 KB, and the sync header (the bits that don't carry the program) were certainly also counted in the given 30 seconds by the reviewer.
    - Someone 12y ago
      "the computer that is designed to spend 768 bytes of the said 1K just for the screen content." No, it was designed to use up to 793 bytes (those 768 plus one byte for every line plus, it seems, one extra 'end of screen' byte) for the screen buffer. If you didn't write stuff, the size of the screen buffer was way smaller, down to 25 bytes for an empty screen (http://problemkaputt.de/zxdocs.htm#zx80zx81videomodetextandblockgraphics http://problemkaputt.de/zxdocs.htm#zx80zx81videomodetextandb...) Also note that the main CPU drew the video from an interrupt handler. That's why one had fast and slow mode; fast mode disabled that interrupt, speeding up your program, but losing the screen display. I think it also means that one should interpret the expression 'halt instruction' as used in the description of the contents of video memory literally. I also found this nugget in a disassembly listing: "and although each interrupt interrupts the previous one, there are no stack problems as the 'return address' is discarded each time."
      - acqq 12y ago
        Thanks for explaining the details of the screen handling of ZX81. Still the author of Chess1K managed to use even the bytes of the "used" display lines for his calculations, and that it's still undisputed that the 600-something bytes are really the whole thing the user needed to run the program.
sago 12y ago
There are 4.7 bits per character for Latin text, which means the comment would have 853 bytes of uncompressed information. Estimates of information density for English are as low as 1.5 bits per character, giving 272 bytes in that comment. The information density in machine code isn't 1 bits per bit though, because of the distribution of which opcodes are used, so the 672 would also drop. So I think the analogy is a pretty good one, whether exact or not, some of the comments on this page contain more information than ZX81 chess.
- PhasmaFelis 12y ago
  > Estimates of information density for English are as low as 1.5 bits per character Can you expand on that?
  - sago 12y ago
    I'm not an information scientist, so this maybe a lay understanding, but as I understand it there is a limit to how much you could theoretically compress any piece of content without losing information. So take that 4.7 bits per character: well, not every letter is equally likely, so we could construct an encoding which takes frequency into account, but then not every word is equally likely, so we could use that information to make a tighter encoding, and so on. At some point we would reach a theoretical minimum. At that limit, the size of the compressed data has one bit per bit of information. So, scaling back up, the estimate is (and it has to be an estimate, I guess, since we can't construct the actual theoretically smallest encoding) 1.5 bits of information per character. I searched for this value, and didn't spend long figuring out if it was well calculated, so take it with a big googly pinch of salt.
mattnewport 12y ago
Even zipped your comment is still 867 bytes. It would be difficult to even explain the castling rule alone in English text in 672 bytes.
- a1369209993 12y ago
  castling:req K&R 1st rank,never moved,no pieces between;can't castle out of,through,or into check;single move:Ke>g&Rh>f or Ke>c&Ra>d 134 bytes, not compressed. Did I miss anything?

by astine 12y ago

acqq 12y ago

> He also 'cheats' a bit by keeping part of the program on tape and never loading it into memory so it doesn't count toward the 672 byte limit. I'm missing something here, but if something is never loaded in the memory, why should be counted? Why do you consider that a part of the program at all? Can you please also provide more technical details, since I don't understand what you mean?

astine 12y ago
In a way you're right, the executable is definitely within bounds and if that is your definition of the program, it's small enough. If you count resources that are necessary to make the program run, however, you'd use a different metric.
- acqq 12y ago
  What do you mean? The program really plays chess against the user by running in the 1K RAM of the computer that is designed to spend 768 bytes of the said 1K just for the screen content. http://en.wikipedia.org/wiki/ZX81 http://en.wikipedia.org/wiki/ZX81 24 lines of 32 characters. 768 bytes usually cleared and scrolled away as you type. The user just has to load the cassette and play. Even if the program was developed on the Cray (it was not) everything needed for the program to run is less than 1K. Please explain your sentence "If you count resources that are necessary to make the program run, however, you'd use a different metric." See the proof: https://archive.org/stream/popular-computing-weekly-1982-07-15/PopularComputing_Weekly_Issue_1982-07-15#page/n11/mode/2up https://archive.org/stream/popular-computing-weekly-1982-07-... "The tape loads every time, without problems, in about 30 seconds." The cassette speed of ZX 81 was 250 bits per second, 30 seconds is less than 1 KB, and the sync header (the bits that don't carry the program) were certainly also counted in the given 30 seconds by the reviewer.
  - Someone 12y ago
    "the computer that is designed to spend 768 bytes of the said 1K just for the screen content." No, it was designed to use up to 793 bytes (those 768 plus one byte for every line plus, it seems, one extra 'end of screen' byte) for the screen buffer. If you didn't write stuff, the size of the screen buffer was way smaller, down to 25 bytes for an empty screen (http://problemkaputt.de/zxdocs.htm#zx80zx81videomodetextandblockgraphics http://problemkaputt.de/zxdocs.htm#zx80zx81videomodetextandb...) Also note that the main CPU drew the video from an interrupt handler. That's why one had fast and slow mode; fast mode disabled that interrupt, speeding up your program, but losing the screen display. I think it also means that one should interpret the expression 'halt instruction' as used in the description of the contents of video memory literally. I also found this nugget in a disassembly listing: "and although each interrupt interrupts the previous one, there are no stack problems as the 'return address' is discarded each time."
    - acqq 12y ago
      Thanks for explaining the details of the screen handling of ZX81. Still the author of Chess1K managed to use even the bytes of the "used" display lines for his calculations, and that it's still undisputed that the 600-something bytes are really the whole thing the user needed to run the program.

sago 12y ago

There are 4.7 bits per character for Latin text, which means the comment would have 853 bytes of uncompressed information. Estimates of information density for English are as low as 1.5 bits per character, giving 272 bytes in that comment. The information density in machine code isn't 1 bits per bit though, because of the distribution of which opcodes are used, so the 672 would also drop. So I think the analogy is a pretty good one, whether exact or not, some of the comments on this page contain more information than ZX81 chess.

PhasmaFelis 12y ago
> Estimates of information density for English are as low as 1.5 bits per character Can you expand on that?
- sago 12y ago
  I'm not an information scientist, so this maybe a lay understanding, but as I understand it there is a limit to how much you could theoretically compress any piece of content without losing information. So take that 4.7 bits per character: well, not every letter is equally likely, so we could construct an encoding which takes frequency into account, but then not every word is equally likely, so we could use that information to make a tighter encoding, and so on. At some point we would reach a theoretical minimum. At that limit, the size of the compressed data has one bit per bit of information. So, scaling back up, the estimate is (and it has to be an estimate, I guess, since we can't construct the actual theoretically smallest encoding) 1.5 bits of information per character. I searched for this value, and didn't spend long figuring out if it was well calculated, so take it with a big googly pinch of salt.

mattnewport 12y ago

Even zipped your comment is still 867 bytes. It would be difficult to even explain the castling rule alone in English text in 672 bytes.

a1369209993 12y ago
castling:req K&R 1st rank,never moved,no pieces between;can't castle out of,through,or into check;single move:Ke>g&Rh>f or Ke>c&Ra>d 134 bytes, not compressed. Did I miss anything?