I haven't read the article yet but, judging by the title, I thinks this is relevant:
https://www.kickstarter.com/projects/1316851183/nesmaker-mak...
The NES Homebrew Scene
51–60 of 138 posts
Re: The NES Homebrew Scene
#52Earlier quoted context omitted.
>Assembly (specially on the 6502) is conceptually very simple and, while it may not be trivial to translate higher-level concepts to its simplicity, as long as what you want can be readily expressed in it, it's trivially easy. That's precisely why I would qualify ASM as "tricky" and "tedious". You're bogged down in the tiny details that nowadays a compiler would probably solve as well (or even better) than you do. If…
It's the difference between being a plumber and being someone who makes custom jewelry. Both are artisans of a kind, the one is doing production and trying to 'get the job done' the other is making one-offs that will have a vastly inefficient time:product ratio where a lot of the value created will be in the eye of the beholder. Both are valid paths.
It's more like someone making custom jewelry using modern tools vs. somebody making custom jewelry only using methods available in ancient Rome. You might not see any obvious difference looking a the result but once you know how they're made one is definitely more impressive than the other. I'm also sure that one is more "tricky" and "tedious" than the other, which is what I was addressing.
If you code something for artistic or "competitive" reasons then of course it makes complete sense. Like people making 4KB demos, speedrunners or people folding thousands of paper cranes. There are no invalid paths if you're an artist.
On the other hand if you consider it from a practical engineering perspective then there are few use cases where I'd go with ASM nowadays, well optimized C code will be easier to write, probably nearly as fast, way easier to modify and maintain and much more portable. Some paths are wildly superior to others if you're an engineer.
Re: The NES Homebrew Scene
#53Nowdays, it's impossible to do modern programming without relying on millions of lines of other people's code. It's frameworks and libraries all the way down. On the NES however, every line of code is yours. There's no such thing as libraries, operating systems, or frameworks. They don't exist. It's refreshing. One of the big problems of modern programming is how easy it is to add complexity. As Charles Moore once sa…
Steve Woz in his autobiography said a similar thing about growing up in the Apple II era vs the kids he teaches today; there’s a lot more you can do today, but what you miss is the insight and power that comes from understanding the system as a whole, and being able to leverage all of its parts.
Re: The NES Homebrew Scene
#54Nowdays, it's impossible to do modern programming without relying on millions of lines of other people's code. It's frameworks and libraries all the way down. On the NES however, every line of code is yours. There's no such thing as libraries, operating systems, or frameworks. They don't exist. It's refreshing. One of the big problems of modern programming is how easy it is to add complexity. As Charles Moore once sa…
Not necessarily, there are hundreds of embedded devices that can be programmed just like in the old days.
Arduino, ESP286, ESP32, .
And since we are in the context of games and Nintendo, something like Arduboy.
Re: The NES Homebrew Scene
#55The existence of phenomena like this and the demoscene made me realize that there are levels of programming skill that I will never be able to reach. Kind of disheartening, but still neat to watch other people do it.
Re: The NES Homebrew Scene
#56Earlier quoted context omitted.
I used to do a lot of dev against the NES. 6502 for the NES was my first language, wrote my own assembler, built games, cartridges, etc. etc. Hell, I even have a PCB, minus the PRG and CHR ROMs, from an old Ice Hockey cartridge on my desk in front of me as I write this. Never had an NES growing up, never played one until I got into NES dev. I was turned onto it by a classmate. We're both too young to have had the NES…
Nostalgia doesn't have to be purely about one's childhood interests, although it frequently is. In your case, your interest still seems a product of nostalgia. I don't really understand why people view interests based on nostalgia as a weakness. Being nostalgic doesn't have to mean that life isn't good or that things were better once upon a time. Like what you like, do what you do, and enjoy what you enjoy without ap…
> Nostalgia: a sentimental longing or wistful affection for the past, typically for a period or place with happy personal associations.
Nothing about what I did, nor wrote was driven by a longing for the days of yore, mine or otherwise. I enjoyed learning to write software for the 6502, it was a simple instruction set, fairly clear, concise, and simple.
I haven't written 6502 in a number of years, and gave my NES collection to a friend last year. That I have an old PCB on my desk, yes, is nostalgia.
Re: The NES Homebrew Scene
#57Nowdays, it's impossible to do modern programming without relying on millions of lines of other people's code. It's frameworks and libraries all the way down. On the NES however, every line of code is yours. There's no such thing as libraries, operating systems, or frameworks. They don't exist. It's refreshing. One of the big problems of modern programming is how easy it is to add complexity. As Charles Moore once sa…
I also adore old programs for their simplicity. However, I've come to terms with "unnecessary" complexity as a necessary cost of growth and abstraction. Each part of a bacteria, relative to its mass, may be more cost effective than that of a mammal. I'd much rather be the latter.
It's true insofar you also count in the evolutionary, worse-is-better nature of software development. I.e. there's lots more of complexity than it's necessary for the level of abstraction and capabilities you want, but that complexity was accrued as people developed and iterated on every layer, mostly leaving it be as it got good enough, and moving on to something else.
Re: The NES Homebrew Scene
#58The appeal of retro console/computer dev is essentially an exercise in constrained programming. Systems of these era had extremely constrained specifications, and making the most of them is an art in itself.
Sometimes I wish we had more constraints because I fear we've all forgotten how to write fast and lean code in favor of semi-fast but very bloated code. I remember back when I first used Windows 95, opening programs was very snappy and I was impressed. I imagined Windows of the future being even snappier, but somehow the opposite has happened. Now every application takes a long time to boot up, check for updates, etc…
On a related note, video games today seem to take forever to load. Plus you have to go through several menus to customize your experience before playing. For the NES Mario, you simply power on, start.
Re: The NES Homebrew Scene
#59I was a bit turned off by the way assembly is described as "tricky" and "tedious"... All programming languages can be tricky and tedious. Assembly (specially on the 6502) is conceptually very simple and, while it may not be trivial to translate higher-level concepts to its simplicity, as long as what you want can be readily expressed in it, it's trivially easy. You will, of course, need to know what bits to set at wh…
Whenever i see people talk about languages (and CPU assembly is a language, each CPU arch has its own dialect), what it comes down to seems to be how "verbose" the programmer has to be about things.
Meaning that if they have to care about memory structures, or even variable types (just look at how popular JS and Python is), they see it as a bothersome language to work with.
End result though is software that balloons to multiple gigs and maxes out a gigahertz CPU just by being launched and sitting idle.
Re: The NES Homebrew Scene
#60Slightly related, but for GameBoy Homebrew, I've been working on a Javascript implementation of GBDK, a C library for GameBoy dev, and am using Emscripten to build a React debug tool allowing you to check out the state of the different graphics buffers and registers and print to the browser console. Bit early days but it's really helping speed up a game I'm working on.
Got an example project at