[deleted]
The NES Homebrew Scene
21–30 of 138 posts
Re: The NES Homebrew Scene
#22Earlier quoted context omitted.
Part of the tedium is only having a few registers so programming in assembly begins to resemble solving the towers of Hanoi puzzle. But, it's certainly something every programmer should give a try at some point, if for no other reason than just a mental exercise.
> Part of the tedium is only having a few registers so programming in assembly begins to resemble solving the towers of Hanoi puzzle. Solving the towers of Hanoi puzzle can be done completely mechanically (exercise: derive the really simple algorithm). Programming in such a constrained environment is something where you have to think for yourself, since I am not aware of any mechanical solution.
A mechanical solution would be using other languages like C
Re: The NES Homebrew Scene
#23The 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.
It's really amazing how people keep finding ways to make old hardware do new tricks. Overdrive 2 is my favorite example - it's a Sega Megadrive demo that was released 30 years after the Megadrive launched, but still managed to pull off multiple effects that had never been seen on the system before. It abuses the hardware in such unique ways that no emulator can run it properly. http://www.pouet.net/prod.php?which=696…
That is amazing. My family had one when I was a kid and I loved it, but what they did there is insane. Way more than I would have thought possible, and I hold that console in high regard.
Re: The NES Homebrew Scene
#24The 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…
We haven't forgotten, we choose to put our time and energy into features rather than performance because that's what end users care more about (at least, it's what they vote with their feet for).
Re: The NES Homebrew Scene
#25I recently started work on an NES project, and wrote the first part of it up: https://www.moria.us/blog/2018/03/nes-development It's a lot of work. I've managed to get data from Tiled into my ROM image, and I'm working on figuring out an architecture for scrolling and displaying a status bar. Implementing scrolling and a status bar sounds simple but is actually a total pain. You only have two screens of tiles to work…
But programming with restrictions like that will make you a better programmer. Nothing brings out creativity better than a limiting environment.
Re: The NES Homebrew Scene
#26I 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…
>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.
Re: The NES Homebrew Scene
#27Earlier quoted context omitted.
> Part of the tedium is only having a few registers so programming in assembly begins to resemble solving the towers of Hanoi puzzle. Solving the towers of Hanoi puzzle can be done completely mechanically (exercise: derive the really simple algorithm). Programming in such a constrained environment is something where you have to think for yourself, since I am not aware of any mechanical solution.
A mechanical solution would be using other languages like C
Using C you cannot get the advantages that 6502 assembly provides. On the other hand, to stay with towers of Hanoi, one can show that the simple mechanical algorithm that one can derive for it, will solve the problem with a minimum possible number of moves.
Re: The NES Homebrew Scene
#28https://twitter.com/clearvus streams at 9pm EST on Mondays and Thursdays on Twitch, he has been working through making an NES game from scratch. He is off this week, but people who are interested in seeing this type of work should definitely check out his series, he deserves way more viewers! I've learned a lot from it.
https://www.twitch.tv/clearvus
recordings are posted on youtube: https://www.youtube.com/watch?v=XwGj1ciSAtw
Re: The NES Homebrew Scene
#29My own personal story with the NES didn't last that long, because I was a kid without money, terrible at platformers, and my parents wouldn't buy me a lot of games. You can only play Super Mario Bros so many times before you're tired of not making it past the 2nd level. So I eventually switched to computers (Apple II vintage), and never looked back to consoles.
This past year, however, I decided to take up a little retro project based on the NES. Its best described as a "video game music player alarm clock", using some authentic hardware. It uses the CPU from an actual NES to faithfully synthesize music from actual NES games, while building the surrounding system out of modern components.
First prototype in action: https://www.youtube.com/watch?v=izMFPKmD5ZU
Blog posts detailing the project: http://hecgeek.blogspot.com/2018/02/nestronic-1.html http://hecgeek.blogspot.com/2018/03/nestronic-2.html
Re: The NES Homebrew Scene
#30I 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…
>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…
You've captured exactly what it feels like -- this is the constant tension among asm developers. I love really high performance code, but I also like accomplishing more than one trivial thing per hour. It's hard to even remember the time before I knew C, when coding in assembly was all there was. When it was "normal." But I do remember the first time I wrote for the M68000 chipset and finding a multiply and divide instruction. "What? I don't have to write my own divide routine?" Tears of joy!
I will typically build something out in a high level language, profile to see where the time is going, and take a closer look at the algorithm first to see if it's sensible or some different approach should be taken. If it's an appropriate algo, then it's time to look at the implementation to see where we can shave cycles.
For the most part, even if you're talking to hardware that requires exceedingly precise timing (interface/bus protocols, certain chips), C will probably do the job. (It's no coincidence it was referred to as "universal assembly language".) Only where one is absolutely starved for resources (as the NES, and many 8-bit systems were/are) is ASM necessary.
"high level when you can, assembly when you must"