ZX Spectrum was one of the few inexpensive options, especially with color support. However terrible it was, it was also very enticing, or just the only thing you had at home, and could tinker with.

I still remember getting a USSR clone(Leningrad) at 5 years old. It is probably earliest memory I have.

Did not know English, could not read anything, but still spent hundreds of hours first playing, and then tinkering with it.

There was no OS to mess up, and it booted instantly to a Sinclair BASIC prompt.

We had no alternatives, it was either whatever we managed to get hold of, with whatever information that we could gather from the provided manuals, a few magazines, and if lucky, the local library.

Ironically, the BASIC + Assembly combo continues to this day, even if done in different tongues.

Playing a devil's advocate - if you have to scrap by with little memory and few services, you focus on your mission, not distractions like code elegance, library choices and build systems.

I was in high school (about 14-15 years old) when I recall drawing lines and circles with BASIC on ZX-Spectrum and it was horribly slow. Was thinking of making some simple games and tried graphics mode but it was just too slow to achieve anything.

So I switched to HiSoft Pascal and line and circle became instantaneous but still I didn't dare program Tetris in graphics mode. So I used text/character mode, compiled from Pascal and was fast enough to play. (In regular BASIC, I couldn't make it work).

Then I installed HiSoft BASIC compiler and my regular BASIC was now fast enough for TETRIS. On the other hand if you think that in 48Kb of RAM they had to fit the video RAM about 8 Kb, the BASIC compiler, my BASIC code, the compiled code and use some RAM for stack and variables ... crazy. Fun times...

> On the other hand if you think that in 48Kb of RAM they had to fit the video RAM about 8 Kb, the BASIC compiler, my BASIC code, the compiled code and use some RAM for stack and variables ... crazy. Fun times...

I had a Spectrum, and then when the QL got relatively cheap, I got one too. Loved 68K assembly.

Given that the 68K instructions were always a multiple of 2 bytes, in its 48K ROM you could have a maximum of 24576 instructions. Now remove the space needed for the bitmap font and some lookup tables, and in the remaining space you had:

- A multitasking operating system (no memory protection, of course), with networking (not TCP/IP of course) and media (microdrive) management, and generic channels kind of in the Unix file spirit

- A (non-re-entrant, single instance) “SuperBASIC” with procedures and functions with LOCal variables, a switch construct (SELect ON), FOR loops with epilogues that would run if not broken out of the loop, and other goodies, which SuperBASIC was also the system shell

- A collection of system calls and a system library, from windowing functions to software floating point (the 40-bit format) operations

Not having a lot of money for software but with the help of some book from the library (titled something like Assembly Programming on the Sinclair QL, don't remember exactly) I even wrote a disassembler in SuperBASIC to decode and grok the ROM. My mind was blown with the density of the ROM code.

QDOS even had non-blocking I/O at the individual read/write call level.

I had to mention this when I learned of Daniel J. Bernstein advocating, almost 20 years after QDOS, non-blocking nonblock_read()/nonblock_write() additions to the POSIX model, so that your I/O model wasn't something that you had to coördinate and share with every process that might have the same open file descriptor.

* https://jdebp.uk/FGA/dont-set-shared-file-descriptors-to-non...

There were all sorts of little innovations in the operating systems world back then. Helios was another interesting one, with capabilities.

The spectrum only had one mode: 256x192 1-but pixels, 32x24 palette (each 8x8 box had two colors, “paper” for a 0 pixel and “ink” for a 1 pixel).

Other computers of the time (C64, Apple II, BBC / Acorn) had distinct text vs graphics modes, although some had a user-defined font which kind of makes the distinction less firm.

But the spectrum only had a graphics mode.

It wasn't that bad if you put in context of its era: for example, the computer that landed on the moon just 10 or so years earlier, had 4 KiB RAM, 72 KiB ROM and was running at a speed of 40k instructions per second.

In retrospect, it was the limitations that made it so fun. The system was so simple that it was entirely knowable by a single brain, which has become enormously more challenging nowadays.

I recently ported my teaching raytracer to the Spectrum [0], not even using assembler, but the horribly slow native BASIC. It was a ton of fun! It's super slow especially when run on the original hardware, but even then I can't remember something like this from back in the day (and I'd bet something like Microhobby would have listed this as some kind of curiosity); makes me think the Spectrum's limitations weren't even fully explored. Raytracing people were probably working on beefier machines and more serious projects.

[0] https://gabrielgambetta.com/zx-raytracer.html

I was never into the Spectrum or any vintage computer like that, but the pico-8 fits that same gap of having an (artificially) limited system, so your code is ugly and uses two-letter variable names because you can only fit 40 characters on screen and the graphics are pixelart. But you can make something and since there's simply not the space for it, bikeshedding is discouraged.

+1 to this: pico-8 is great. it is so low-res that it is relatively cheap to use it with led panels (e.g. [1]).

[1] https://www.youtube.com/watch?v=OTc3VmBBwMw

Commercial developers could afford cross development setups where the actual development happened on PCs and the code was transferred to the Spectrum, see for example:

https://bizzley.42web.io/assets/it_s_behind_you___the_making...

Tbf, even a simple macro assembler gets you closer to a proper high level language dev-experience than programming in machine code. We're just not used to the idea of macro assemblers anymore because our only contact with assembly code is when staring at the messy disassembly of high-level-language compiler output.

But that's very different from working in a properly commented and 'macro-assisted' Z80 or 6502 assembly code base.

> It's still inconceivable to me how people developed for these platforms.

Well, we didn't have Visual Studio Code, and we couldn't summon Claude to help us through the tricky bits. We used whatever tools were available and a LOT of trial and error in order to master the machine. Because computers were amazing, and having one on your desk you could play with was even more amazing.

I didn't have a Spectrum, because I'm a bloody Yank. I had a VIC-20 and later a TI-99/4A. In the States we had Apple, IBM, Tandy, TI, and Commodore, with Apple pretty much the dominant force in home computing until PCs got cheap enough. Everybody else was pretty niche, so even when affordable computers came out -- like the Timex Sinclair and Timex Sinclair 2068 (which was based on, but not broadly compatible with the Spectrum), there wasn't a huge library of software nor a large programmer/hobbyist community like there was with the Spectrum in the UK. The "bedroom coder" phenomenon was still a thing, but I think the wide availability and low price of the Spectrum enabled more Brits from a variety of backgrounds and socioeconomic strata to become "bedroom coders" than Americans, for whom home computers were pretty much expensive toys.

> Timex Sinclair 2068 (which was based on, but not broadly compatible with the Spectrum),

I had one and it came with a spectrum 48K emulator cartridge that was pretty good but had a bug in the graphics emulation.

The keyboard was much better.