Amazing to see this alive and kicking in this day and age.
I grew up programming the 8-bit Atari and it was such a great time to experience. Information was scarce without internet, so magazines and word-of-mouth was so important. Once you collected enough information, you could pretty much hold a mental model of the entire machine in your head, and the only limitations were the number of cycles you had per second or the effort you were willing to put in. I firmly believe this is how I developed the mindset of stepping outside of the problem and readily looking for out-of-the-box solutions that pays dividends to this day.
Programming was a mix of BASIC and machine language routines (not even assembly as you hand-assembled to machine bytes) similar to how someone might use Python with C calls but at lower levels of both. Later on I tried compiled languages like Pascal but it ran like a dog, not tuned for the slow floppy or memory constraints of these machines. Getting a macro assembler was next-level, where you could write everything to be as fast or small as possible. Self-modifying code for wasn't only common practice, it was quite necessary for performance.
Other great pastimes were reverse-engineering games and copy protection in an arms-race. Most were pretty simple and it was always exciting to see completely new techniques or super-complicated multi-pass self-modifying or otherwise obfuscated code.
The filesystem on the floppy disks were also easily understood with sector chaining and a free sector bitmap, so you could write low-level routines like undelete or a defragger. Modifying the floppy drive with custom sector sequencing and RPM tuning could improve timings to get higher throughput and finding that you can add SRAM to buffer an entire track really sped things up. The simplest and cheapest thing was to punch a hole in floppy disks and write to the other side (of a single-sided floppy).
Having this level of understanding made you believe that you could do pretty much anything and everything (just not always fast enough) and makes you program without boundaries except the hardware. Even then it was simple enough to modify parts of the hardware like ROMs or extend it with helpers plugged into the bus or PIO (parallel I/O joystick) ports much like the GPIO on a Raspberry Pi.
The graphics system on the Atari was really something else, with 'display lists' of data that defined memory addresses and display modes (character or raster) that could be defined for each (character or raster) row, along with color palette lookup tables that you could modify to change all the colors using those values. Even the serial SIO daisy chain on the Atari was the basis of what is now how USB enumeration and command/reply works.
Shout-out to Bill Budge's Pinball Construction Set (PCS) originally for the Apple ][ and also on Atari. Of course being a kid I mostly made video games and tools for making video games like sprite editors, character/tileset editors, font editors, and level editors. PCS blew my mind and later got me into making programs that build applications, following the likes of Visual Basic (but running on OS/2 PM).
> Having this level of understanding made you believe that you could do pretty much anything and everything (just not always fast enough) and makes you program without boundaries except the hardware. Even then it was simple enough to modify parts of the hardware like ROMs or extend it with helpers plugged into the bus or PIO (parallel I/O joystick) ports much like the GPIO on a Raspberry Pi.
Some of my favorite bits of The 8 Bit Guy's channel involve when he explains how the NES and SNES controllers work, and to demonstrate he goes "I wrote a little program on my C64 to poll the NES controller through the user port..." and proceeds to run it and what do you know, the C64 can read NES controller input, it just needs to be taught how.
I'm still a bit miffed about him dremeling out the screws on that rare IBM prototype, but he's still done some really cool stuff.
I grew up programming the 8-bit Atari and it was such a great time to experience. Information was scarce without internet, so magazines and word-of-mouth was so important. Once you collected enough information, you could pretty much hold a mental model of the entire machine in your head, and the only limitations were the number of cycles you had per second or the effort you were willing to put in. I firmly believe this is how I developed the mindset of stepping outside of the problem and readily looking for out-of-the-box solutions that pays dividends to this day.
Programming was a mix of BASIC and machine language routines (not even assembly as you hand-assembled to machine bytes) similar to how someone might use Python with C calls but at lower levels of both. Later on I tried compiled languages like Pascal but it ran like a dog, not tuned for the slow floppy or memory constraints of these machines. Getting a macro assembler was next-level, where you could write everything to be as fast or small as possible. Self-modifying code for wasn't only common practice, it was quite necessary for performance.
Other great pastimes were reverse-engineering games and copy protection in an arms-race. Most were pretty simple and it was always exciting to see completely new techniques or super-complicated multi-pass self-modifying or otherwise obfuscated code.
The filesystem on the floppy disks were also easily understood with sector chaining and a free sector bitmap, so you could write low-level routines like undelete or a defragger. Modifying the floppy drive with custom sector sequencing and RPM tuning could improve timings to get higher throughput and finding that you can add SRAM to buffer an entire track really sped things up. The simplest and cheapest thing was to punch a hole in floppy disks and write to the other side (of a single-sided floppy).
Having this level of understanding made you believe that you could do pretty much anything and everything (just not always fast enough) and makes you program without boundaries except the hardware. Even then it was simple enough to modify parts of the hardware like ROMs or extend it with helpers plugged into the bus or PIO (parallel I/O joystick) ports much like the GPIO on a Raspberry Pi.
The graphics system on the Atari was really something else, with 'display lists' of data that defined memory addresses and display modes (character or raster) that could be defined for each (character or raster) row, along with color palette lookup tables that you could modify to change all the colors using those values. Even the serial SIO daisy chain on the Atari was the basis of what is now how USB enumeration and command/reply works.
Shout-out to Bill Budge's Pinball Construction Set (PCS) originally for the Apple ][ and also on Atari. Of course being a kid I mostly made video games and tools for making video games like sprite editors, character/tileset editors, font editors, and level editors. PCS blew my mind and later got me into making programs that build applications, following the likes of Visual Basic (but running on OS/2 PM).