Fascinating that these scenes are still thriving, just recently saw "8-Bit Guy"'s postmortem video on writing and shipping a game for C64.
The NES Homebrew Scene
121–130 of 138 posts
Re: The NES Homebrew Scene
#122Earlier quoted context omitted.
I hear this argument a lot in the EE community. Yet, the cheapest 8051 part in single quantities on DigiKey: $0.43. Cheapest ARM Cortex-M0 part on DigiKey: $0.47. I'll take the ease of development and features on ARM for $0.05. You can develop without proprietary development environments. I do my development with a basic gcc+make setup. Of course you can pick up old parts which fell off a truck for cheaper but I'd ra…
The cheaper 8051s aren't on digikey (they are usually integrated into something like the custom MCU used for a pregnancy test or tooth brush), and $0.05 is very worth it if you are making 1000000.
8051 is a complete overkill for a pregnancy test or a toothbrush.
That's why those applications use less known 4-bit processors.
Re: The NES Homebrew Scene
#123Earlier quoted context omitted.
Those two panels are well-known as a meme image, over probably the past 4 years. Memes tend to transcend their original source; that's probably why the image wasn't properly cited.
Because clearly nobody working on the web as an artist deserves to get credit for their work once it passes a certain threshold of popularity. That said, when K C Green ran a Kickstarter for a plush This Is Fine dog it took in more than ten times what he was asking for; how much of that went into his bank account as profit, I dunno.
I'm not trying to say whether they deserve credit. I'm just trying to describe something observed about how people treat images that reach the level of "meme".
Re: The NES Homebrew Scene
#124Earlier quoted context omitted.
> Arduino, ESP286, ESP32, . Both the Arduino libs and Espressif SDK are fairly big chunks of code. Yes, you can program AVRs without libs too, but you did specifically say Arduino. It is also my understanding that ESPs are both bit obscure and fairly complex beasts to be managed without SDK. While there are still some nice cases of simplicity in the embedded world, the complexity and layers of libraries and framework…
Here's a sneak peek of something I'm working on http://fingswotidun.com/avr/AvrAsm/Testbed/ It's pretty much a project to scratch the itch being described in this thread. It gives you an in-broswer 8-bit AVR based fantasy console and Assembler.
It looks quite cool.
Re: The NES Homebrew Scene
#125I 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…
> I think writing assembly is a skill any coder should have, especially if you usually deal with close-to-the-metal languages like C, C++ or Rust for instance.
It also applies to using languages like Java and C#.
Occasional devs might not be aware of it, but there are ways to see what the JIT/AOT compilers generate.
Re: The NES Homebrew Scene
#126Earlier 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…
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 in…
> "high level when you can, assembly when you must"
I was already following that on MS-DOS with its 640 KB, with all Basic, Pascal, C and C++ compilers from Borland and Clipper.
Although I did spent one year still focused on using TASM for everything and playing how much I could cram into a COM file.
Re: The NES Homebrew Scene
#127I 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…
What always scares me away from assembly every time I try to learn it is that principle that makes code more dangerous or rigid or difficult to evolve, the more manual work you have to do in it. Like how it’s harder to refactor C code than Python because of how the implementation and algorithms get closer to each other the lower you get. And since assembly gives you almost nothing, changing an algorithm seems to mean…
Assemblers with good macro languages help a lot.
For example using something like MASM or TASM back in the MS-DOS days was like having your own high level language.
So you end up creating a kind of DSL with those macros.
Re: The NES Homebrew Scene
#128Earlier quoted context omitted.
> I remember the 16-bit "real mode" assembly of Intel's 286 CPU very well. Those CPUs already started being complicated enough to make ASM programming less attractive. IIRC, on 286 the string copy instructions were faster than the DMA transfers people used on earlier PCs and, because of that, if you wanted to have optimal performance, you'd need to check which CPU it was running and branch accordingly to the best cod…
I'd blame it more on 286 being trash than actual complexity. I remember doing MIPS ASM in the early 90s, and it was a joy.
When I learned MIPS on the university using SPIM, Pentiums 75 MHz were still fresh and I knew Z80 and x86 Assembly quite well.
The way some instructions were neither macros nor actual CPU instructions always felt strange to me.
Re: The NES Homebrew Scene
#129I literally just wrote my first ROM that displays a green box on a black background working on my retropie machine last night. The NES homebrew scene is pretty cool and the tools and languages have come a long way. One interesting avenue that might be work exploring is to use code generation and CSPs to generate and shrink code. It's a lot of fun. It's why I like the PICO8. Constraints are interesting. I just wish I…
> Constraints are interesting. Constraints are also helpful when working towards a sense of mastery. Look at a modern operating system (or console) for that matter. So much capability, so much complexity. You'll never learn it all, never be able to master it. Heck, just truly understanding the machine code of a modern processor, and knowing everything it does and can do is quite a daunting task. These older 8-bit sys…
Just understanding the intel instruction set is basicallly impossible for a mere mortal. How thick is that reference manual now?
Re: The NES Homebrew Scene
#130Earlier quoted context omitted.
But programming with restrictions like that will make you a better programmer. Nothing brings out creativity better than a limiting environment.
“The enemy of art is the absence of limitations” (attributed to Orson Welles)
The goal of an artist is to push boundaries, overcome restrictions. Absence of limitations is the goal of pretty much everything. That's what would be called perfection. Setting artificial restrictions is a way to learn by reduction of a problem by simplification, and setting boundaries requires creativity, too, but in principle, freedom is not the enemy.
In another reading, absence of limitations would be limiting, still, which would be paradox.