The catch about developing things back then is that you were working with duct tape and chicken wire. The 6502 CPU was developed literally by creating a hand drawn design. Each transistor laid out created additional complexity that humans had to understand. Therefore, making it as simple as possible by reducing the gates used to a minimum was important. This also meant that not all combinations inputs were valid (or event checked).

The 6502 has a few "undocumented" instructions due the fact that if you have certain on/off input pin set, you're actually crossing gates used for multiple instructions. These may crash the chip or do non-useful things, but a few do something useful in vary specific circumstances. The trick to developing on these old systems is to experiment with the chips to understand what the system does in various circumstances.

What I liked about that time was that it was possible to truly understand everything about a system because nothing is hidden from you by software drivers. The were good times.

> The 6502 CPU was developed literally by creating a hand drawn design. Each transistor laid out created additional complexity that humans had to understand.

Want to understand a tiny chunk of that complexity yourself? Check out how the addition operation overflow flag is implemented in silicon on the 6502: http://www.righto.com/2013/01/a-small-part-of-6502-chip-expl...

This reminder of undocumented behavior reminded me of The story of Mel, a Real Programmer.

See

http://www.pbm.com/~lindahl/mel.html

I'd never seen that photo before. Mel looks a bit like Brad Pitt from far away.

Until very recently, I assumed the story was mostly apocryphal, but I happened to look it up about a year ago and learned that the actual Mel had been identified, and that there was even that picture. Really cool, considering I first saw the story of Mel in probably 1989.

You still have to be clever like that today depending on what kind of problems you're working on.

Which was also true back then. Not all programmers back then had to derive arcanely clever tricks to get their job done.

There's also a part of it that is underappreciated, which is that sometimes the cool effect wasn't necessarily an original design goal, but instead was sometimes something that was stumbled upon one way or another, and then it was having that little trick in one's pocket which informed how the design would be.

One good example of this: Space Invaders was, AFAIK, the first game to feature escalating difficulty over time (because the aliens speed up the more of them you shoot). This wasn't originally part of the design; the system just couldn't run at the same framerate while managing 30 sprites as it could at 5, and there weren't any enforced timing checks.

There were quite a few “professional” software packages written in BASIC at the time. Of course most software needed assembly in the early days.

Harder to do tasks we take for granted now, sure. But today's games are EXTREMELY complex in comparison. Old games were intentionally made extremely difficult, to counter their simplicity in design. Else you'd be done with the whole game in 15 minutes.

I’m currently doing a bit of Gameboy Advance programming for fun and I’m actually surprised by how simple most of it is at least for the basics. While some games on the platform do incredibly clever stuff (Super Monkey Ball Jr. being especially impressive), most of the popular titles use the standard tiled sprite rendering mode which is quite easy to understand and fast by default.

Wow, I just googled for a youtube video of gameplay [0] and I'm genuinely at a loss at how they pulled off that 3d engine. The sound fidelity is still pretty high given the lack of dedicated sound hardware on the GBA, and somehow they still have time left over for texture-mapped polygons.

I love reading about how programmers pulled off these tricks on such limited hardware, hopefully there are some notes about it somewhere on the internet.

[0] https://www.youtube.com/watch?v=K-AZQKTlUMs

> You not only had to figure out the program logic, but you had to work within very tight hardware constraints.

Try programming microcontrollers and you can enjoy that feeling today! Get comfy with the relatively powerful ARM Cortex-M variants, which typically sports 10s of kB of RAM. Then if you feel frisky, try your hand at some 8-bit uC's with less than 64 bytes of RAM (spend your bits wisely).

https://jaycarlson.net/microcontrollers/

Idk man. Just to make a useful app I need to understand servers, databases, backend frameworks (for security), and front end.

Maybe it's finding creative solutions, but today there is a lot to know.

If by "understand" you mean glue together all of the high-level abstractions of each of those domains, each of which have mountains of tutorials / blog posts / StackOveflow answers, then sure.

Gluing them is only 1 step.

You still need to write the logic that each layer needs to be useful.

This is true, and I don't mean to trivialize the work of today's programmer.

However, I suppose somewhat subjectively in reviewing or writing any of this glue or logic layer code using modern web frameworks I've never had the sort of WOW response that I do when I see what the programmers of yore were coming up with.

I think the real reason for this might be that clever hacks using current technology are looked on with disdain, whereas yesterday's hacks are seen as impressive ways of making the most of limited hardware and tooling.

To me, that's a sign of the engineering discipline having matured (as well as average computational needs not keeping pace with computational power). My first job out of college was at Google, and I remember being somewhat disappointed the first time I was told to replace some elegant, dense logic with something more readable. After years of having to read other people's prematurely optimized or unnecessarily compact code in large engineering systems in complex problem domains, I'm more than bought into the idea that readability is one of the primary goals of good code.

This doesn't preclude compromising readability for hacks when you need to squeeze performance out of some logic (just look at Tensorflow code), but you'd expect a maturing computational environment and engineering culture to reduce the number of clever hacks needed or present.

That can be the difference in how the software is deployed. At Google, most things are horizontally scaled and machines are cheaper than engineers. When I worked on Windows, it was the opposite: I was told to refactor clean multithreaded code to reduce the thread count by one. The rationale was that Windows scales vertically and every developer wasting a thread is how Windows gets slower over time.

On the other hand you had all the hardware under your direct control. And right now I'm trying to find why kernel stashed 17MB of RAM, I really need.

Survivor bias. Plenty of shite code got written for the 6508 but only clever crap gets blog posts 30+ years after the fact.

Zelda survived partially because it was so revolutionary. It was the first game so complex that it invented game saves.

https://www.vice.com/amp/en_us/article/9a3b8y/why-zelda-was-...

It was much easier then to become experienced in programming because it was way less to learn.

Not only more constraints but you had to use languages that took more work to do things, like C or Assembly.