Essentially, the CPU executes each line of video, jumping to the start of each line of cells. The video system latches each byte onto a shift register and displays it.
But the CPU is tricked -- NOPs are forced onto its data bus right before it decodes the instruction. So it merrily marches along fetching successive bytes for the video subsystem, without interpreting them.
That is, until a certain bit of the character code is seen, then the CPU is allowed to execute the instruction and terminate the scanline (usually HALT on the ZX). This process repeats over and over for each scanline.
As a result, it's pretty tricky to program animations. There's not much CPU time left for anything while a frame is being displayed.
This was very nicely done and a really enjoyable time travel video. I learned to program on a ZX81 at a young age. With the manual (shown), the Usborne 1980s programming books that actually taught kids how to do machine code (all now released free: https://usborne.com/browse-books/features/computer-and-codin... ) and then also the Rodney Zak's Z80 book (also available free somewhere). What a great start to a career as a hacker! Cost my parents something like a hundred bucks down here in New Zealand, but I also had to mow my neighbour's lawn to get my hands on an old black and white TV set to plug it into. How I loved that machine, but also hated it (they keyboard was terrible, and the 16kb "RAM pack" would crash the machine if you wobbled it). I envied the more feature-rich Commodore 64s etc that other kids had, but they tended to use them in a more passive way: playing games only. I think the austerity of the ZX81 either produced or at least selected for a curiosity about how code works.
Author here. Thanks for the kind words. It was fun to do, and I just wish I could have touched on stuff like FAST vs SLOW, more about the weird display system, etc... but TBH FAST doesn't really get on well with modern monitors and video capture systems and I was terrified of getting 40 minutes into it and then discovering that all my captured video was unusable!
Oh, yeah: ZX81 BASIC doesn't support multiple statements per line, and the IF...THEN statement doesn't support ELSE. Writing complex logic on it can be a challenge!
The "canonical" FOR loop variables were always F and N (not Z!), because you could type "FOR F" and "NEXT N" quickly (F F and N N respectively).
What I really liked about the ZX81 and I think you demonstrated well is how interactive programming is. Just run your program at any point to see progress. Commonly used modern programming environments aren't as good in this respect.
Is there any advantage in using A, B, C etc. as variable names? W and H seemed to be potentially more readable for the with and height, X and Y for the ball position and in particular O and I for 0 and 1 etc.? Also, I think I have spotted a few remaining 0s in the saved file?
The practice version did, but name collisions got too confusing (W and H is fine for width and height, but then I wanted horizontal and vertical velocity...). I thought it was clearer to give up completely and use the notepad instead.
And yes, some optimisations are left as an exercise for the reader.
Back in the day I hand dis-assembled the code for https://en.wikipedia.org/wiki/Jetpac
It is beautiful. Without the 80/81 it would not exist. Seriously have a look.
I've always wanted to make something on the Sinclair Spectrum but I was too young back then and computers advanced too fast (it was exciting, watching the future materialize in real-time, though.)
I wish I had this when I was a kid. I basically had a ZX-Spectrum from Sinclair and all I learnt was by reverse engineering things. I'd load a tape or whatever and try figure out how it does what it does.
Although it taught me from an early age to dig to find things, you can't beat having learning material...
I am happy I learned it via reverse engineering. It gave me skills that allow me to learn new things fast and it showed me that nothing is magic. You would be surprised how many uni cs graduates find a lot of computer things magic but do not have the tools in their head to discover they are not.
I am also of the opinion videos are the worst and laziest way to convey deep technical information; yet it is really popular. If someone wrote this into a post, I would he able to digest and try out in a very short period of time, with videos it is pretty uncomfortable. I wonder why it is so popular aside that most people who watch it will never try it out to begin with.
It's true about videos, but this was never intended as a technical resource. Instead I wanted to show how working on one of these machines felt.
I showed this video to some work-mates, mostly younger than I am, and some of the questions I got were really revealing: 'Does it boot into Basic?' 'But if there's no disk, where does it put the compiled program?' These machines are _completely alien_ to the modern mindset, and so I wanted to actually demonstrate working on one in practice, rather than just write it up. There's plenty of technical docs out there already.
With you there, though I didn't start with the Sinclairs. Videos are such low bandwidth compared to listings in the back of a magazine with an article breaking it down step by step, or figuring it out from reverse engineering and messing around the memory map. With nowhere to turn for instant answers you had to. I'm glad I did.
YT works for game reviews, and the odd conference presentation, for everything else I'll seek out a post.
Sure, I agree with you. But I find sometimes my lack of deep understanding and why things are the way they are. For that you often need to have learning material.
The ZX81 was actually my first computer, and I loved it. I pretty much read the manual in a weekend, and spent hours upon hours learning how to program (and getting stuff in and out cassette tapes).
Essentially, the CPU executes each line of video, jumping to the start of each line of cells. The video system latches each byte onto a shift register and displays it.
But the CPU is tricked -- NOPs are forced onto its data bus right before it decodes the instruction. So it merrily marches along fetching successive bytes for the video subsystem, without interpreting them.
That is, until a certain bit of the character code is seen, then the CPU is allowed to execute the instruction and terminate the scanline (usually HALT on the ZX). This process repeats over and over for each scanline.
As a result, it's pretty tricky to program animations. There's not much CPU time left for anything while a frame is being displayed.