And also, that assembler for an 8 bit processor is very much easier to handle then modern asm. You can fit the entire instruction set on a single page, and it was not uncommon to know the hex opcodes for all of them by heart.

True. I used to program the 6502 by hex code. Still remember a few instructions. That was fun, but a waste of memory today.

Only way to update the code was to replace buggy code with a jump to the first free memory, add corrected instructions, and then a jump back again. That was true spaghetti programming. My first game was a Asteroid look-a-like, but using character graphics.

I remember the day I could afford an upgrade of the RAM from 4K to 8K.

Wow, old memories coming back. I implemented my first programming language at that time, being a Lisp-look-a-like (implemented using the string functions in the built-in Basic). Didn't work very well, due to a memory management in the Basic interpreter that would eventually hang. I complained to the retailer, and they said it was "normal behavior".

It was possible to save the binary code to a tape recorder, but I don't remember the details.

I'd recognise that computer anywhere - Ohio Superboard or UK101 (in the UK) a computer sold in kit form in the 70s - My mum convinced my dad to buy one :) I never programmed it beyond basic but got into 6502 once she convinced my dad to buy an Acorn BBC-B. Nice job with the case! We actually bought a case to go around it but my dad added a PSU that sat on top and got so hot it required a massive fan which didn't have a cage and affected the video output making it go wavy.

I'm not sure if other platforms did this but when Acorn implemented their version of the Basic language they made it incredibly easy to drop in and out of 6502 assembler within the basic program - IIRC it was as simple as putting a control code and then getting on with using the values you were passing in and out.

I think that was a big step in getting early coders into assembler easily on the BBC.

Personally my first steps in 6502 were disassembling the code for a game until I figured out how the game was drawing the sprites. Due to the fact that computers only had video memory and no buffer to draw a sprite that didn't destroy the background you first had to save the background onto a stack. Draw the sprites, calculate new positions, then draw the background back onto the sprites by pulling off the stack (to preserve any multiple overwrites with other sprites), push the new location backgrounds onto the stack - repeat.

That's about as much as I can remember!