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

81–90 of 138 posts

Re: The NES Homebrew Scene

#81

Post by bad_user »

jstewartmobile wrote: post #68
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…

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.

Re: The NES Homebrew Scene

#82

Post by drewying »

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 games never drew their own sprites. They just said "Hey NES, write the sprite at this x and y location" and the NES did it.

Audio worked the same way.

Honestly, coding for the NES would be similar to working with a simple 2D graphics library. So I don't know if it would be accurate to say "every line of code is yours" on the NES. It's more just that the "libraries" used were implemented in hardware instead of software.

Re: The NES Homebrew Scene

#83

Post by jstewartmobile »

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.

Not true. Programmed micros for practical things--many of which are still in service. Modest hardware forced us to focus on the task rather than presentation.

Modern hardware raised the stakes and forced us to spend more time (in some cases, the majority of the time) on packaging and presentation--even where it didn't really matter that much after the sale.

I'm not talking iPhones were a human interacts with it constantly. I'm talking control systems, where after the sale, human interaction is simple and rare.

Re: The NES Homebrew Scene

#84

Post by pkaye »

falcrist wrote: post #63
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

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.

There is C available for an 8051. The Keil 8051 compiler (now owned by ARM) was pretty good and it had a nice GUI environment. The 8051 is pretty good for certain tasks but when you push it beyond the limits, your effort switches from solving the core problem to managing memory and micro optimization to make things work. Meanwhile with an ARM MCU you don't have to worry about a lot of things. I once spent a couple days optimizing a 32-bit divide for an 8051 to squeeze a couple % improvement in product performance.

Re: The NES Homebrew Scene

#85

Post by lmm »

chongli wrote: post #64
lmm wrote: post #24

Earlier quoted context omitted.

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

Some things have been lost, though, and I'm not even referring to the usual claim about constraints facilitating creativity. Games of the 8- and 16-bit console generations, as well as all arcade games up until that point, were written with CRT monitors in mind and often used 'racing the beam' techniques. This resulted in games with extremely low latency, something you never find in a game of any sort today. The diffe…

> Games of the 8- and 16-bit console generations, as well as all arcade games up until that point, were written with CRT monitors in mind and often used 'racing the beam' techniques. This resulted in games with extremely low latency, something you never find in a game of any sort today.

The techniques haven't been lost - if anything there are probably more people who know how to do those things today than there were in the past.

Typical LCD monitors are undeniably worse in many ways than the CRTs they replaced, but again, most customers turned out to prefer the convenience of the LCD on the whole. Nowadays with the rise of 144Hz monitors those rare users who care a lot about gaming latency do have an option.

Re: The NES Homebrew Scene

#86

Post by magduf »

falcrist wrote: post #63
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

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.

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.

Re: The NES Homebrew Scene

#88

Post by xfer »

wgerard wrote: post #5

Somewhat related: I'm always thoroughly impressed with how complicated and knowledgeable the people who work on these topics are. I don't even use the product, but I love reading the Dolphin blog [0] because they write about fairly complicated topics in a way that's pretty approachable, and it always makes me appreciate how much I don't know about these topics. While I feel like it would be difficult-but-not-impossib…

The difference is domain knowledge, it takes time. You might feel that way about kernel because the high level concept of resource management is pervasive in programming. So you might feel you can easily dive into it, but it will take you equally long to say port the kernel to a new architecture/write drivers for a new platform.

Re: The NES Homebrew Scene

#89

Post by tluyben2 »

pjmlp wrote: post #76
ashleyn wrote: post #40

Earlier quoted context omitted.

It's a dying art because now even the cheapest SoCs are capable of running full Linux with a big stack like Node. The Pi Zero is $5 and capable of all these things. Perhaps the last refuge is battery-powered microcontrollers.

Not necessarily, when you need to have something that will last 5 years on battery power and not cost more than $1 per piece, a Pi Zero won't do. But even then, if they have up to 512 KB, is like having the same tooling as on the Amiga, Atari, PC (MS-DOS) on a needle size CPU. For younger generations, you can check on YouTube what we managed to do with 512 KB on those systems, even when using higher level languages.

Depending on the market you can save millions in production picking a cheaper, less powerful mcu. Sure it takes some extra work to squeeze in more features in less flash and every cycle counts, but on runs of millions of devices, this is easily paid back by the extra profits.

Re: The NES Homebrew Scene

#90

Post by makapuf »

airforce1 wrote: post #37
jacquesm wrote: post #25

Earlier quoted context omitted.

But programming with restrictions like that will make you a better programmer. Nothing brings out creativity better than a limiting environment.

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