Live data from Hacker News

The NES Homebrew Scene

tedium.co

111–120 of 138 posts

Re: The NES Homebrew Scene

#111

Can anyone recommend any particular enjoyable home brew games? I can see a few already listed in comments, but it would be nice to gather up a short list.

Blade Buster, fast paced modern time attack shmup; very pretty, don’t forget to hit select to increase speed.

My top score in 2min is 500,000+.

Re: The NES Homebrew Scene

#112

Can anyone recommend any particular enjoyable home brew games? I can see a few already listed in comments, but it would be nice to gather up a short list.

Blade Buster, fast paced modern time attack shmup; very pretty, don’t forget to hit select to increase speed. My top score in 2min is 500,000+.

That's great! (and difficult).... 100,000 is initial best.

Having recently discovered OpenEmu, I'm trying to track down good homebrew/freeware games.

Re: The NES Homebrew Scene

#113
post #54

Earlier quoted context omitted.

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. https://arduboy.com

Even worse than that, people still use legacy devices like 8051 MCUs in modern products. I'm currently working on an assembly codebase for a SiLabs part. Like... Please move to an ARM MCU with a C codebase.

You can program 8051 in c using tinycc. It functions great as an assembler as well. You can structure the parts that must be in assembly as c functions using inline assembly. Very convenient!

Using c does come at the cost of some code compactness, but you can selectively optimize as the need arises.

Re: The NES Homebrew Scene

#114
post #93
post #54

Earlier quoted context omitted.

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. https://arduboy.com

> 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.

Re: The NES Homebrew Scene

#115
Maan, I envy the homebrew scenes in the US so much. In Japan there are a few people who're doing homebrew, but because of the constant intimidation by Nintendo and marginalization by the society ("they're technically criminals.") they're not as open or organized as the US. I think we're killing our own talents.

Re: The NES Homebrew Scene

#116
post #106

Earlier quoted context omitted.

Have you done http://nand2tetris.org ? It involves (virtually) building up a CPU that has two registers, which I'm guessing the minimum possible.

You'll need some internal state (one register?) and a program counter. If instructions are long enough, you can encode the address of the next instruction in the instruction itself (sort of a perverse VLIW where everything ends with a jump to a given address) and ditch the program counter. You can make tests destructive, so your status bits end up overwriting the register - it would force some "interesting" programmi…

You could make every operation of the form (op src dst nxt). Something like https://codegolf.stackexchange.com/questions/11880/build-a-w..., where results are always written to ram and 'register' indexes are just addresses. You'd still need some transient/architectural registers to hold the current instruction/memory address/alu input-output on its way though the cpu though.

Re: The NES Homebrew Scene

#117

Earlier quoted context omitted.

They couldn't bother to cite the image apparently but it's from a web comic called Gunshow

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.

Re: The NES Homebrew Scene

#118

I 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…

I liked this video explanation of NES scrolling ("The Nintendo Entertainment System's Loading Seam" by Retro Game Mechanics Explained) https://www.youtube.com/watch?v=wfrNnwJrujw

Wow! I just watched his video on the PacMan kill screen, and it finally made sense. I’ve read multiple posts about it before, but having it all presented in a video format with animations made it all make sense.

Re: The NES Homebrew Scene

#119

Earlier quoted context omitted.

I remember the 16-bit " real mode " assembly of Intel's 286 CPU very well. > focus on the problem Think harder, you might remember that you weren't solving many problems either.

> 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…

> if you wanted to have optimal performance, you'd need to check which CPU it was running and branch accordingly to the best code path.

The Intel C Compiler still does that. It compiles multiple versions of your code, each optimized for different processor versions.

Re: The NES Homebrew Scene

#120

Earlier quoted context omitted.

I remember the 16-bit " real mode " assembly of Intel's 286 CPU very well. > focus on the problem Think harder, you might remember that you weren't solving many problems either.

> 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.
Post reply on HN