5 ms·

I grew up coding assembly for 6502... and you can fit a lot in 1k. the 1k is aided and abetted by the architecture of the computer. * Reading keyboard is read

by tezza 17y ago

I grew up coding assembly for 6502... and you can fit a lot in 1k. the 1k is aided and abetted by the architecture of the computer. * Reading keyboard is reading a register/known address, not loading the keyboard library, allocating a structure and jumping into an OS routine. * Clear screen is writing zeros to a known address space * Drawing is writing a 1 to a known address space * Yours is the only process on the machine * Text compresses well with Huffman With those assumptions a lot more can fit in the 1K

pvg 17y ago
I don't see how these assumptions really help - 'greatest program ever written' is a bit bombastic but working chess program in a few hundred bytes of z80 code is still quite impressive. Reading keyboard is reading a register/known address, not loading the keyboard library, allocating a structure and jumping into an OS routine Or calling a ROM routine. Reading the keyboard directly at the lowest level would probably just make the program bigger Clear screen is writing zeros to a known address space Generally, another ROM routine call. Drawing is writing a 1 to a known address space Not really. Just about all these machines had color. The Apple ][ had a fun non-linear video buffer layout, to boot. Text compresses well with Huffman Not a lot of text in a chess program.
- tezza 17y ago
  It sounds like you're helping my point... thanks. ROM routines is a jump into known addresses... so no extra impact on the 1K. Parameters are read from registers. Color of 4bit? only a slight increase. Often acheivable in 1 instruction. Limit of 2 colors in 8x8 block on ZX81[1] -------------------- [1] http://www.giantbomb.com/zx-spectrum/60-16/ http://www.giantbomb.com/zx-spectrum/60-16/
  - pvg 17y ago
    I suppose if 'just about everything you said to support your point is wrong' is 'helping you', there's probably not much left to discuss.
  - andybak 17y ago
    You're linking to information on a ZX Spectrum which is not a ZX81. The ZX81 had a monochrome character mapped display with no pixel access (well - there were tricks that could sort of give you pixel access but they came much later than the time 1k chess was written)
    - tezza 17y ago
      Sorry about that... i didn't mention colour depth originally, someone else brought it up (trying to look smart). 6502 was my platform, so I missed the exact Z* platform... I was sharing general info on assembly for 8bit, not specific to one platform (ZX81). This seems to have incensed some people who took a narrow view on what sort of comment was permitted.
- olavk 17y ago
  I had a ZX81. Drawing was indeed done by writing directly to a special address space. However, you didn't write pixels directly but rather bytes which where rendered as characters on the screen by the system. The ZX81 did not have colors.
  - jcl 17y ago
    In fact, if you look at the source code in the actual article, you can see the graphical characters used to draw the board right in the Basic code listing. :)
- roundsquare 17y ago
  Reading the keyboard directly at the lowest level would probably just make the program bigger Generally, another ROM routine call. Thats @tezza's point. (Edit For Clarity): Since its just one instruction, you can shrink the size of your program, making fitting it into a small space less impressive (though, not unimpressive). Not a lot of text in a chess program. Fair enough, so that one doesn't help, but the other two do.
  - tezza 17y ago
    Thanks roundsquare. For reference to my original post: I wasn't trying to deny that this program is amazing... it is. I was intending to illustrate that you could do a lot more with 1k historically than you can nowadays, and that some of the worst offenders to bulking out a process don't apply on older computers in assembly. That doesn't take away from the brilliance of AI in 1k, but rather I think the focus should be on that and not the chessy bit.
  - pvg 17y ago
    Except it's not one instruction - you still have to put the result somewhere, potentially save registers (of which there is a great dearth) and so forth. My point is none of the things listed (aside from not really being part of 'the architecture') are significant factors on top of being largely inaccurate. What does make a difference is that the instructions themselves are short, the addresses are short, alignment is on the byte, etc. Can you fit a lot into 1k? Sure, if you're clever, you can apparently fit a whole chess program in less. But the fact that, say, there's just your process or that Huffman encoding is neat has next to nothing to do with it.
    - bch 17y ago
      Some of the 'results' that need storing can be stored on the screen itself. An example of a difference between these 8bit machines and today's machines that @tezza is talking about.
    - roundsquare 17y ago
      I'm really not clear on where we disagree at all. We seem to agree that: 1) Reading keyboard input and clearing the screen can both be executed via a ROM command. 2) Doing these things otherwise would have made the program bigger. Am I right that we agree on these? If so, I don't see how you don't agree that: 3) Having both of these as ROM commands helps make the program smaller. As far as I can tell, we agree on these 3 points. You, however, seem to be bringing up a few more points: 4) Instructions are short. 5) Alignment is on the byte. ... And, from what I can tell, you are saying that these were more helpful in reducing the size of the program. Am I right so far? If so, you maybe right that compared to modern computers, but that doesn't mean that @tezza is wrong that the other factors helped. Also, I believe its already been agreed that Huffman encoding doesn't help...
InclinedPlane 17y ago
While we're on the subject, might as well point out the amazing .kkrieger game: http://en.wikipedia.org/wiki/.kkrieger http://en.wikipedia.org/wiki/.kkrieger A high quality 3D FPS that is a mere 97,280 bytes through the magic of procedural generation.
- knweiss 17y ago
  IMHO this 128 Byte(!) 3d demo is even more impressive: http://pouet.net/prod.php?which=53871 http://pouet.net/prod.php?which=53871 (Click on the Youtube link at the right to see it running)

by tezza 17y ago

pvg 17y ago

I don't see how these assumptions really help - 'greatest program ever written' is a bit bombastic but working chess program in a few hundred bytes of z80 code is still quite impressive. Reading keyboard is reading a register/known address, not loading the keyboard library, allocating a structure and jumping into an OS routine Or calling a ROM routine. Reading the keyboard directly at the lowest level would probably just make the program bigger Clear screen is writing zeros to a known address space Generally, another ROM routine call. Drawing is writing a 1 to a known address space Not really. Just about all these machines had color. The Apple ][ had a fun non-linear video buffer layout, to boot. Text compresses well with Huffman Not a lot of text in a chess program.

tezza 17y ago
It sounds like you're helping my point... thanks. ROM routines is a jump into known addresses... so no extra impact on the 1K. Parameters are read from registers. Color of 4bit? only a slight increase. Often acheivable in 1 instruction. Limit of 2 colors in 8x8 block on ZX81[1] -------------------- [1] http://www.giantbomb.com/zx-spectrum/60-16/ http://www.giantbomb.com/zx-spectrum/60-16/
- pvg 17y ago
  I suppose if 'just about everything you said to support your point is wrong' is 'helping you', there's probably not much left to discuss.
- andybak 17y ago
  You're linking to information on a ZX Spectrum which is not a ZX81. The ZX81 had a monochrome character mapped display with no pixel access (well - there were tricks that could sort of give you pixel access but they came much later than the time 1k chess was written)
  - tezza 17y ago
    Sorry about that... i didn't mention colour depth originally, someone else brought it up (trying to look smart). 6502 was my platform, so I missed the exact Z* platform... I was sharing general info on assembly for 8bit, not specific to one platform (ZX81). This seems to have incensed some people who took a narrow view on what sort of comment was permitted.
olavk 17y ago
I had a ZX81. Drawing was indeed done by writing directly to a special address space. However, you didn't write pixels directly but rather bytes which where rendered as characters on the screen by the system. The ZX81 did not have colors.
- jcl 17y ago
  In fact, if you look at the source code in the actual article, you can see the graphical characters used to draw the board right in the Basic code listing. :)
roundsquare 17y ago
Reading the keyboard directly at the lowest level would probably just make the program bigger Generally, another ROM routine call. Thats @tezza's point. (Edit For Clarity): Since its just one instruction, you can shrink the size of your program, making fitting it into a small space less impressive (though, not unimpressive). Not a lot of text in a chess program. Fair enough, so that one doesn't help, but the other two do.
- tezza 17y ago
  Thanks roundsquare. For reference to my original post: I wasn't trying to deny that this program is amazing... it is. I was intending to illustrate that you could do a lot more with 1k historically than you can nowadays, and that some of the worst offenders to bulking out a process don't apply on older computers in assembly. That doesn't take away from the brilliance of AI in 1k, but rather I think the focus should be on that and not the chessy bit.
- pvg 17y ago
  Except it's not one instruction - you still have to put the result somewhere, potentially save registers (of which there is a great dearth) and so forth. My point is none of the things listed (aside from not really being part of 'the architecture') are significant factors on top of being largely inaccurate. What does make a difference is that the instructions themselves are short, the addresses are short, alignment is on the byte, etc. Can you fit a lot into 1k? Sure, if you're clever, you can apparently fit a whole chess program in less. But the fact that, say, there's just your process or that Huffman encoding is neat has next to nothing to do with it.
  - bch 17y ago
    Some of the 'results' that need storing can be stored on the screen itself. An example of a difference between these 8bit machines and today's machines that @tezza is talking about.
  - roundsquare 17y ago
    I'm really not clear on where we disagree at all. We seem to agree that: 1) Reading keyboard input and clearing the screen can both be executed via a ROM command. 2) Doing these things otherwise would have made the program bigger. Am I right that we agree on these? If so, I don't see how you don't agree that: 3) Having both of these as ROM commands helps make the program smaller. As far as I can tell, we agree on these 3 points. You, however, seem to be bringing up a few more points: 4) Instructions are short. 5) Alignment is on the byte. ... And, from what I can tell, you are saying that these were more helpful in reducing the size of the program. Am I right so far? If so, you maybe right that compared to modern computers, but that doesn't mean that @tezza is wrong that the other factors helped. Also, I believe its already been agreed that Huffman encoding doesn't help...

InclinedPlane 17y ago

While we're on the subject, might as well point out the amazing .kkrieger game: http://en.wikipedia.org/wiki/.kkrieger http://en.wikipedia.org/wiki/.kkrieger A high quality 3D FPS that is a mere 97,280 bytes through the magic of procedural generation.

knweiss 17y ago
IMHO this 128 Byte(!) 3d demo is even more impressive: http://pouet.net/prod.php?which=53871 http://pouet.net/prod.php?which=53871 (Click on the Youtube link at the right to see it running)