5 ms·

Reading the keyboard directly at the lowest level would probably just make the program bigger Generally, another ROM routine call. Thats @tezza's point. (Edi

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...
  - pvg 17y ago
    Heh, well, I'm not clear what is unclear. The poster said 'well, the program is short because of these N things'. Except none of the N things were accurate or relevant. There are architectural factors that much more significantly affect the size of the program, but poster didn't mention any of them. My point is tezza either didn't know or didn't think what s/he was posting about. It's sort of like having the discussion "So, airplanes fly because of magic" - "Well, no actually airplanes fly because of [a bunch of physics]" - "Right, you're making my point, airplanes fly!".
    - roundsquare 17y ago
      Okay, I feel like there is a real break in communication and I'm curious to explore it. If it gets too tedious for you, feel free to ignore me. Going back to the N = 5 things. Three seem to help, two don't. The helpful ones: * Reading keyboard is reading a register/known address, not loading the keyboard library, allocating a structure and jumping into an OS routine. * Doens't this make make the program smaller? Getting the key entered is just a read instruction. Sure, there maybe things that happen afterwards (as you said) but just getting the key is one instruction i.e. read <some memory spot> * Clear screen is writing zeros to a known address space * Again, instead of doing a number of instructions to clear the screen (I have no idea how many this takes on a modern computer) you just need to write do write 0 <memory location> * Drawing is writing a 1 to a known address space * My understanding is that on modern computers this is a complex operation. But, in this it appears that drawing is again a single operation. In each case, the point @tezza is making is: Hey, all you people who haven't ever used these crazy old machines, these are the types of things that make it easier to create a very small chess program (in terms of size of the program itself, not the resources it uses). All these things that nowadays require a lot of instructions only required a single instruction on this machine. The other two points, I agree, are probably not helpful. Using the keyboard reading as an example, it seems whoever designed this machine said "one way to reduce the size of programs is to make it easy to read keyboard inputs. Lets have the hardeware store that in a known address." Thus, the fact that you can do this does help reduce the size of the program. Am I wrong? Let me know. I've never worked on these machines so I could be completely off base. A friend of mine used to wonder if it would be instructive to learn about programming under these limitations so I'm genuinly curious. Note: I'm not objecting to your points about what reduced the size of the program. I'm just trying to figure out why you think @tezza's points don't help.

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...
- pvg 17y ago
  Heh, well, I'm not clear what is unclear. The poster said 'well, the program is short because of these N things'. Except none of the N things were accurate or relevant. There are architectural factors that much more significantly affect the size of the program, but poster didn't mention any of them. My point is tezza either didn't know or didn't think what s/he was posting about. It's sort of like having the discussion "So, airplanes fly because of magic" - "Well, no actually airplanes fly because of [a bunch of physics]" - "Right, you're making my point, airplanes fly!".
  - roundsquare 17y ago
    Okay, I feel like there is a real break in communication and I'm curious to explore it. If it gets too tedious for you, feel free to ignore me. Going back to the N = 5 things. Three seem to help, two don't. The helpful ones: * Reading keyboard is reading a register/known address, not loading the keyboard library, allocating a structure and jumping into an OS routine. * Doens't this make make the program smaller? Getting the key entered is just a read instruction. Sure, there maybe things that happen afterwards (as you said) but just getting the key is one instruction i.e. read <some memory spot> * Clear screen is writing zeros to a known address space * Again, instead of doing a number of instructions to clear the screen (I have no idea how many this takes on a modern computer) you just need to write do write 0 <memory location> * Drawing is writing a 1 to a known address space * My understanding is that on modern computers this is a complex operation. But, in this it appears that drawing is again a single operation. In each case, the point @tezza is making is: Hey, all you people who haven't ever used these crazy old machines, these are the types of things that make it easier to create a very small chess program (in terms of size of the program itself, not the resources it uses). All these things that nowadays require a lot of instructions only required a single instruction on this machine. The other two points, I agree, are probably not helpful. Using the keyboard reading as an example, it seems whoever designed this machine said "one way to reduce the size of programs is to make it easy to read keyboard inputs. Lets have the hardeware store that in a known address." Thus, the fact that you can do this does help reduce the size of the program. Am I wrong? Let me know. I've never worked on these machines so I could be completely off base. A friend of mine used to wonder if it would be instructive to learn about programming under these limitations so I'm genuinly curious. Note: I'm not objecting to your points about what reduced the size of the program. I'm just trying to figure out why you think @tezza's points don't help.