5 ms·

"The Sinclair ZX81 only had 1 kB RAM with option to upgrade to 16 kB." If you're wondering "what can you do in 1kb of RAM?", how about a complete computer game

"The Sinclair ZX81 only had 1 kB RAM with option to upgrade to 16 kB." If you're wondering "what can you do in 1kb of RAM?", how about a complete computer game of chess? The YouTube channel Nostalgia Nerd compares the 1981 '1K ZX Chess' program with a more modern chess engine. How do they stack up? A game of Chess: 1981 1KB Computer vs. Modern PC https://www.youtube.com/watch?v=R3By_rdwxSg https://www.youtube.com/watch?v=R3By_rdwxSg

rwmj 5y ago
David Given, who posts on here sometimes, did a great video about the process of coding a game on an unexpanded ZX81: http://cowlark.com/2018-09-26-zx81-programming/index.html http://cowlark.com/2018-09-26-zx81-programming/index.html
alanjay 5y ago
That's recently been ported to work as a lichess AI https://fosdem.org/2022/schedule/event/retro_chess/ https://fosdem.org/2022/schedule/event/retro_chess/ (by the same author as the book 20 GOTO 10)
russfink 5y ago
Yes, and it is our lot that decries software bloat. We know what can be done with K bytes, why do we need K * K * K to simply boot?
- retrac 5y ago
  Ever written anything in assembly? We trade cycles and bytes for programmer convenience. Assembly code heavily optimized for size will do things that are absolutely horrifying from a maintenance or general "architectural cleanliness" angle. Terribleness you might encounter: * Reading instructions as constants because the values you need happen to already be in the code. * Self-modification, including writing variables as constants into the instruction stream, generating instructions at run-time, and reusing code space as data space for one-once code. * Using bits in the opcodes to store data, since a single bitflip doesn't affect the interpretation of some instructions. E.g. on the Z80 if Z and C are both always 1 at a particular point, you can use either jrz (0010 1000) or jrc (0011 1000) and use the 5th bit in that instruction as a flag. Free storage! I do find this sort of thing fun. As a hobby. I wouldn't want to write an air traffic control system that way.

rwmj 5y ago

David Given, who posts on here sometimes, did a great video about the process of coding a game on an unexpanded ZX81: http://cowlark.com/2018-09-26-zx81-programming/index.html http://cowlark.com/2018-09-26-zx81-programming/index.html

alanjay 5y ago

That's recently been ported to work as a lichess AI https://fosdem.org/2022/schedule/event/retro_chess/ https://fosdem.org/2022/schedule/event/retro_chess/ (by the same author as the book 20 GOTO 10)

russfink 5y ago

Yes, and it is our lot that decries software bloat. We know what can be done with K bytes, why do we need K * K * K to simply boot?

retrac 5y ago
Ever written anything in assembly? We trade cycles and bytes for programmer convenience. Assembly code heavily optimized for size will do things that are absolutely horrifying from a maintenance or general "architectural cleanliness" angle. Terribleness you might encounter: * Reading instructions as constants because the values you need happen to already be in the code. * Self-modification, including writing variables as constants into the instruction stream, generating instructions at run-time, and reusing code space as data space for one-once code. * Using bits in the opcodes to store data, since a single bitflip doesn't affect the interpretation of some instructions. E.g. on the Z80 if Z and C are both always 1 at a particular point, you can use either jrz (0010 1000) or jrc (0011 1000) and use the 5th bit in that instruction as a flag. Free storage! I do find this sort of thing fun. As a hobby. I wouldn't want to write an air traffic control system that way.