Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The NES Homebrew Scene

tedium.co

Post reply on HN
Print view View original

101–110 of 138 posts

Re: The NES Homebrew Scene

#101

Post by AdamJacobMuller »

makapuf wrote: post #90
airforce1 wrote: post #37

Earlier quoted context omitted.

> Nothing brings out creativity better than a limiting environment. This is so true as a life principle! I once read a book about the development of laser guided bombs [1], and in it it talked about how Texas Instruments made the first viable prototype [2] on a shoe-string budget even though they were competing against a large government contractor with a huge budget. Because of the budgetary constraints, TI couldn't…

I'd find completely awesome if it weren't for tools aimed at killing people. I'm not sure I enjoy advances in that area.

It's just as easy to say it is a tool designed to save lives. Ultimately it's a tool, it's how you use it that's important.

Re: The NES Homebrew Scene

#102

Post by annywhey »

drewying wrote: post #82
pubby wrote: post #46

Nowdays, 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 agree with you in general, but I think it's worth pointing out that programming the NES's PPU is actually very similar to programming with a 2D graphics library today. NES games never wrote their own scrolling logic, or there own graphics logic. They wrote tile values into a background table and then told the NES how much to scroll the playing field, and the NES rendered and scrolled everything automagically. NES g…

This is only sort of true in that while there are hardware supported things, the way in which you work with them is both more finicky than most APIs, and they get you relatively less close to a finished renderer.

For example, concepts like a scroll register don't typically appear in an abstracted API. They're a hardware detail that happens to assist in implementing a smooth scroll by reducing the necessary computation. But they aren't a "smooth scrolling API" because it works on the tilemap data only - you can also have sprites scroll. That necessitates a software implementation specifically for the task of sprite rendering. Witness the numerous NES games that either let sprites disappear when they hit negative X coordinates or put up a convenient black bar to hide it.

Re: The NES Homebrew Scene

#103

Post by janekm »

morio wrote: post #97
magduf wrote: post #86

Earlier quoted context omitted.

An ARM might be overkill (and a bit expensive) for something that can be done with an 8051. A better choice might be something like an Atmel AVR or Microchip PIC(16 or 32 probably). Those are dirt-cheap, and specifically designed for microcontroller applications with features like on-board ADCs, comparators, timers, GPIOs, etc.

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.

Re: The NES Homebrew Scene

#104

Post by s_m_t »

zokier wrote: post #93
pjmlp wrote: 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…

The core of the esp-idf is like a wrapper + a tiny bit of logic over the registers, there is a ton of extra stuff packed in there but you don't need to use it if you don't want to and it is pretty clearly separated in the source directory. I really like it because it gets out of my way when I don't want it, and when I do want it there is usually something there to help.

Re: The NES Homebrew Scene

#105

Post by ythn »

makapuf wrote: post #90
airforce1 wrote: post #37

Earlier quoted context omitted.

> Nothing brings out creativity better than a limiting environment. This is so true as a life principle! I once read a book about the development of laser guided bombs [1], and in it it talked about how Texas Instruments made the first viable prototype [2] on a shoe-string budget even though they were competing against a large government contractor with a huge budget. Because of the budgetary constraints, TI couldn't…

I'd find completely awesome if it weren't for tools aimed at killing people. I'm not sure I enjoy advances in that area.

Well, the alternative to PGMs is a lot more collateral damage. Want to take out that bridge? Carpet bomb or dive bomb and hope too many civilians/pilots don't die. Want to take out that factory? Carpet bomb or dive bomb and hope too many civilians/pilots don't die.

With PGMs you can take out a bridge with pinpoint accuracy in the middle of the night and nobody dies at all (directly, at least).

Re: The NES Homebrew Scene

#106

Post by SilasX »

JustSomeNobody wrote: post #13
rbanffy wrote: post #11

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

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.

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

Re: The NES Homebrew Scene

#107

Post by rbanffy »

SilasX wrote: post #106
JustSomeNobody wrote: post #13

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

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" programming techniques, but it seems doable.

But remember: there is always a lot of state flying around that's not exposed to the programmer through architectural registers.

Re: The NES Homebrew Scene

#108

Post by phs »

jimmaswell wrote: post #66

A while ago I wanted to try some NES ROM hacking but I couldn't find any tools for it that were really convenient - I ended up typing 6502 into some online assembler to copy the output into HxD and other processes like that. So, I wrote something more to my liking that was more like an IDE. I couldn't think of a good name, but I was modding Kid Icarus at the time, and it's in .NET, so I just called it IcarusNet. It w…

As someone who simply wanted a NES assembler, I've found cc65 [0] to be great, for example wrapped as a docker image in [1].

[0]: https://github.com/cc65/cc65 [1]: https://hub.docker.com/r/philhsmith/cc65/

Re: The NES Homebrew Scene

#109

Post by rbanffy »

bad_user wrote: post #81
jstewartmobile wrote: post #68

Earlier quoted context omitted.

It is a little misleading isn't it? I miss the old assembler. It could just be that I have a poor memory, but with 8/16-bit assembly, I could remember almost everything about my toolset and focus on the problem. With modern APIs and languages--even modern assembly languages--I spend more time googling than anything else.

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

Re: The NES Homebrew Scene

#110

Post by khedoros1 »

fenwick67 wrote: post #75
coding123 wrote: post #69

Earlier quoted context omitted.

The graphic on there is brilliant.

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