Python programming for Nintendo 8 bits (2018) | Hacker News Reader

Python programming for Nintendo 8 bits (2018)

github.com

103 pointsraytopia25 comments

Ooh, I wasn't aware of this, but I recently wrote something conceptually similar (albeit slightly lower-level - it's more of a "macro assembler with python syntax"):

https://github.com/DavidBuchanan314/p65a

It needs a bit of a refactor, and there aren't any docs except for my example code (which is a serial bootloader, complete with crc checks, for my SBC)

Looking closer at OP, it uses AST introspection to do its magic, whereas mine just uses operator overload hacks.

Kind of off topic, but it's a real shame that Nintendo is so aggressively proprietary and litigious. If you read the (excellent) book "Super Mario: How Nintendo Conquered America" by Jeff Ryan, you'll see that Nintendo is that to its core and always has been, so I don't expect a change. But it's one of the big tragedies of the world IMHO.

So is Disney and Apple.

Nintendo can't use strategies like IBM or Google to keep their revenue flowing. Aggressively protecting their IP and preventing people from distributing information on piracy is how they protect their business.

For as large and old as Nintendo is, a bad decade could crush them.

Nintendo has a massive war chest. They'd definitely be fine for a while. But I agree that that got there by protecting their most valuable asset: their IP.

Part of that was because of the video game industry crash of 1983. Companies would make all kinds of shitty games for the 8-bit consoles of that time.

https://en.wikipedia.org/wiki/Video_game_crash_of_1983

I think a lot of gaming and computer companies were like this, especially early on. If you read Console Wars (about Sega during the 3rd generation of consoles) you run into loads of aggressive practices while they all try to build out their market dominance.

You're not wrong, but most companies that achieve critical success eventually become rather protective of their IP.

I wouldn't be so hyperbolic as to call it a tragedy of the world, it's just kind of a shame.

I mean, read up on the history of Activision and how they got started. Atari did everything they could to stop them from producing cartridges for the 2600.

> I wouldn't be so hyperbolic as to call it a tragedy of the world, it's just kind of a shame.

Thank you, and agreed, that's very fair analysis. It was pretty hyperbolic.

Similar, but in Haskell: https://github.com/DataKinds/sixty-five-oh-two

It's a DSL for writing 6502 assembly.

I'm very interested in this topic, but currently ignorant enough about NES game dev to make this repo fairly cryptic. Is there anyone here with more knowledge that can explain what exactly this does (more deeply than "enable writing NES games in Python, kind of"), and how it compares to other tooling out there?

Looks like it compiles a subset of python code into NES assembly code.

This is fricken awesome. Wish I understood more about NES game dev to make some sense of this repo but that is likely the point of this project :)

I wrote an NES game in 6502 assembly back in 2020. It was a school capstone project and I intentionally wanted to do it “close to the metal”. Outside of that I had seen some people writing NES games in C++, but had heard that it compiled pretty inefficiently. I’m pleased to see projects like this because even if it is a higher level language, it’s important to learn to operate in constrained environments. And it brings more folks into the NES homebrew scene.

Ooh, I remember this project just from the video released by the creator :) It gives me an almost-ASMR feel - https://www.youtube.com/watch?v=Y-o3pJEhwD4 ("pyNES - First preview")

If I learned anything from fighting with MicroPython on far more powerful "limited environments" it would be that this is just a curious study, not a feasible choice.

This isn't MicroPython though, and it's not similar either.

I fail to see how it is dissimilar enough to avoid apprehension. Same language (Python) on limited hardware (8-bit NES, microcontrollers.) So what makes pyNES so different from MicroPython that someone with apprehension due to the latter should have no apprehension toward the former?

Wheras micropython involves running a lightweight python virtual machine, this is a compiler. It parses a subset of python and emits assembly, which then can be run on the NES.

It is sort of like a scheme to asm dsl, but rather than via macros, this appears to operate via decorators.

For future reference, though it may be unintended, the tone of your comments does seem aggressive. This probably wouldn't be a problem if they weren't so assertively wrong/misguided.

There is no python runtime running on the 6502 hardware, and no Python semantics at runtime whatsoever. Python code is only executed on the host system during compilation. Python's role here is a glorified macro assembler.

Because this is an assembler with python being used as the macro language. No actual python code runs on the target.

Please expand, thanks.

I kept thinking to myself, someone really should design a language that compiles down to ASM so we don't have to write it by hand. Finally.

Compilers for the 6502 are tricky, because of its limitations and idiosyncracies. There was a well-received port of a language called Micro-SPL to the 6502 for the Atari 8-bit computers called Action!. The original incarnation of Micro-SPL, on the Xerox Alto, compiled to Alto microcode.

Don’t tell this guy about the thing that Ritchie made in 1972.

So, like C?

Reply on news.ycombinator.com