3 ms·

I strongly recommend playing with this sort of machine. It's an utter education. It will, literally, change the way you think about programming. Also, the ZX81

I strongly recommend playing with this sort of machine. It's an utter education. It will, literally, change the way you think about programming. Also, the ZX81 had the best cover art for any programming manual EVER: http://uknet.com/gallery2/d/16341-2/076_Sinclair_ZX81_Manual.jpg http://uknet.com/gallery2/d/16341-2/076_Sinclair_ZX81_Manual... (Paintings by John Harris. He sells prints! http://www.alisoneldred.com/thumbsJohnHarris-Prints-3-1.html http://www.alisoneldred.com/thumbsJohnHarris-Prints-3-1.html) However, you will be frustrated with the ZX81; the built in BASIC was utterly appalling and also didn't have a tokeniser --- instead each key (plus modifiers) produced a different keyword. And it was stateful, so the keys did different things depending on what you were typing. This made typing on it horribly frustrating even when you had the keywords written on the keyboard, which you won't have with an emulator. It may be of interest to check out the Jupiter Ace --- it's basically the same machine, made by some ex-Sinclair staff, except running Forth instead of Basic; you can at least type on that, and using Forth means you're much closer to the machine. (Plus, Sinclair's Basic was seriously horrifying. Any alternative is better.) There's a bunch of emulators. But it's a much more esoteric machine, so there'll be very limited resources around. There are Javascript emulators for all the above, but they're pretty naff.

Aardwolf 12y ago
How did BASIC work with just 1k of memory? A scripting language interpreter is quite complex, not?
- dugmartin 12y ago
  The BASIC resided in ROM. Here is a complete listing of the ROM: http://www.wearmouth.demon.co.uk/zx81.htm http://www.wearmouth.demon.co.uk/zx81.htm
- david-given 12y ago
  They didn't work like modern interpreters, which basically compile the program into bytecode and then interpret the bytecode. They would do simple very simple parsing of the program, mostly just tokenising it, and then more or less execute each Basic statement directly. (Sinclair Basic's wacky keyword-at-a-time entry system meant they didn't need to ship a tokeniser.) So: 10 LET I = 10 20 LET I = I + 1 30 GOTO 10 The program counter would point at the start of line 10; the interpreter would see LET (mandatory in Sinclair Basic) and know a variable name was next; it'd read that; it'd read the equals sign; then it would read the expression and evaluate it on the fly. Then the program counter would be pointing at the end of line 10, so it just advances over the line number, and it's ready for line 20. etc, etc. Line 30 would read the GOTO, then read the line number, then reset the program counter to the beginning of the program and scan through looking at line number headers until it found the right one. Yes, O(n). Yes, you put most used subroutines at the beginning of the program for speed. So the entire run-time state is a program counter, a couple of fixed-size stacks for FOR...NEXT and GOSUB...RETURN, and your variables. I've no idea how Sinclair Basic stored them, but BBC Basic used a hash table that was immediately after the end of your program. Strings were a problem because they could change size; Commodore Basic had the world's slowest garbage collector. BBC Basic just fragmented and ran out of space. I don't know how Sinclair Basic handled it. If you're interested, the entire ROM is disassembled here: http://www.wearmouth.demon.co.uk/zx81.htm http://www.wearmouth.demon.co.uk/zx81.htm
  - lifeisstillgood 12y ago
    Oh my god - that's we we had line numbers ! To reduce parse complexity - FFS!!! That's amazing. Why am I so blind?
    - gress 12y ago
      Not quite - line numbers were also the text editor.
      - david-given 12y ago
        They actually make for quite a decent IDE --- it's a really cheap and easy way to allow arbitrary insertion at any point without needing the complexity of a full text editor. You really need a RENUMBER command, though (which BBC Basic had) or else you sometimes find yourself unable to subdivide numbers.
  - Someone 12y ago
    "I've no idea how Sinclair Basic stored them, but BBC Basic used a hash table that was immediately after the end of your program." I expected that Sinclair Basic would have a rule that variable names have one significant character, and reserved space for 26 integers A% through Z%, 26 strings A$ through Z$, and forget about floating point, but reading http://www.worldofspectrum.org/ZX81BasicProgramming/chap06.html http://www.worldofspectrum.org/ZX81BasicProgramming/chap06.h..., that isn't true; this language even allowed spaces in identifiers. At the same time, we have (same link): "You will get a report 2/0, & looking up 2 in appendix B, you will see that it means 'variable not found', So. This enormous 8kB ROM wasn't large enough to hold error messages. And, reading http://www.cs.columbia.edu/~%20sedwards/classes/2006/w4115-fall/reports/zx81basic.pdf http://www.cs.columbia.edu/~%20sedwards/classes/2006/w4115-f..., it seems that loop and stir g variables had to be single-letter (yes, your program had at most 26 strings. Not that much of a limit if you have a few hundred bytes of RAM for your program and your data) That PDF also gives some more limitations of the language, claiming that it wouldn't do complex expressions such as 10 let a = 2 * a + 1
    - 12y ago
bootload 12y ago
However, you will be frustrated with the ZX81; Agree with that. The syntax check while you typed programs would break your concentration. Still have my first machine in it's foam box, a zx80 with ROM upgrade. https://www.flickr.com/photos/bootload/tags/zx81 https://www.flickr.com/photos/bootload/tags/zx81 And thank you David for pointing out the John Harris prints, what a bonus.
derefr 12y ago
> This made typing on it horribly frustrating even when you had the keywords written on the keyboard, which you won't have with an emulator. Sounds like a good argument for a software keyboard. Might make a good touchscreen app.
Almaviva 12y ago
> Also, the ZX81 had the best cover art for any programming manual EVER: Nope. http://globalnerdy.com/wordpress/wp-content/uploads/2007/09/forth_on_the_atari.jpg http://globalnerdy.com/wordpress/wp-content/uploads/2007/09/...
- madengr 12y ago
  That made me spit my beer out. Man I miss the 80's sometimes.
- david-given 12y ago
  That's... um... wow. I think I shall resort to a strictly pedantic definition of the word 'best' here.

Aardwolf 12y ago

How did BASIC work with just 1k of memory? A scripting language interpreter is quite complex, not?

dugmartin 12y ago
The BASIC resided in ROM. Here is a complete listing of the ROM: http://www.wearmouth.demon.co.uk/zx81.htm http://www.wearmouth.demon.co.uk/zx81.htm
david-given 12y ago
They didn't work like modern interpreters, which basically compile the program into bytecode and then interpret the bytecode. They would do simple very simple parsing of the program, mostly just tokenising it, and then more or less execute each Basic statement directly. (Sinclair Basic's wacky keyword-at-a-time entry system meant they didn't need to ship a tokeniser.) So: 10 LET I = 10 20 LET I = I + 1 30 GOTO 10 The program counter would point at the start of line 10; the interpreter would see LET (mandatory in Sinclair Basic) and know a variable name was next; it'd read that; it'd read the equals sign; then it would read the expression and evaluate it on the fly. Then the program counter would be pointing at the end of line 10, so it just advances over the line number, and it's ready for line 20. etc, etc. Line 30 would read the GOTO, then read the line number, then reset the program counter to the beginning of the program and scan through looking at line number headers until it found the right one. Yes, O(n). Yes, you put most used subroutines at the beginning of the program for speed. So the entire run-time state is a program counter, a couple of fixed-size stacks for FOR...NEXT and GOSUB...RETURN, and your variables. I've no idea how Sinclair Basic stored them, but BBC Basic used a hash table that was immediately after the end of your program. Strings were a problem because they could change size; Commodore Basic had the world's slowest garbage collector. BBC Basic just fragmented and ran out of space. I don't know how Sinclair Basic handled it. If you're interested, the entire ROM is disassembled here: http://www.wearmouth.demon.co.uk/zx81.htm http://www.wearmouth.demon.co.uk/zx81.htm
- lifeisstillgood 12y ago
  Oh my god - that's we we had line numbers ! To reduce parse complexity - FFS!!! That's amazing. Why am I so blind?
  - gress 12y ago
    Not quite - line numbers were also the text editor.
    - david-given 12y ago
      They actually make for quite a decent IDE --- it's a really cheap and easy way to allow arbitrary insertion at any point without needing the complexity of a full text editor. You really need a RENUMBER command, though (which BBC Basic had) or else you sometimes find yourself unable to subdivide numbers.
- Someone 12y ago
  "I've no idea how Sinclair Basic stored them, but BBC Basic used a hash table that was immediately after the end of your program." I expected that Sinclair Basic would have a rule that variable names have one significant character, and reserved space for 26 integers A% through Z%, 26 strings A$ through Z$, and forget about floating point, but reading http://www.worldofspectrum.org/ZX81BasicProgramming/chap06.html http://www.worldofspectrum.org/ZX81BasicProgramming/chap06.h..., that isn't true; this language even allowed spaces in identifiers. At the same time, we have (same link): "You will get a report 2/0, & looking up 2 in appendix B, you will see that it means 'variable not found', So. This enormous 8kB ROM wasn't large enough to hold error messages. And, reading http://www.cs.columbia.edu/~%20sedwards/classes/2006/w4115-fall/reports/zx81basic.pdf http://www.cs.columbia.edu/~%20sedwards/classes/2006/w4115-f..., it seems that loop and stir g variables had to be single-letter (yes, your program had at most 26 strings. Not that much of a limit if you have a few hundred bytes of RAM for your program and your data) That PDF also gives some more limitations of the language, claiming that it wouldn't do complex expressions such as 10 let a = 2 * a + 1
  - 12y ago

bootload 12y ago

However, you will be frustrated with the ZX81; Agree with that. The syntax check while you typed programs would break your concentration. Still have my first machine in it's foam box, a zx80 with ROM upgrade. https://www.flickr.com/photos/bootload/tags/zx81 https://www.flickr.com/photos/bootload/tags/zx81 And thank you David for pointing out the John Harris prints, what a bonus.

derefr 12y ago

> This made typing on it horribly frustrating even when you had the keywords written on the keyboard, which you won't have with an emulator. Sounds like a good argument for a software keyboard. Might make a good touchscreen app.

Almaviva 12y ago

> Also, the ZX81 had the best cover art for any programming manual EVER: Nope. http://globalnerdy.com/wordpress/wp-content/uploads/2007/09/forth_on_the_atari.jpg http://globalnerdy.com/wordpress/wp-content/uploads/2007/09/...

madengr 12y ago
That made me spit my beer out. Man I miss the 80's sometimes.
david-given 12y ago
That's... um... wow. I think I shall resort to a strictly pedantic definition of the word 'best' here.