4 ms·
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
by 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 agoWhat 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 agoThanks 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.