Originally published at: A programming language to make NES games without learning Assembly | Boing Boing
…
4 Likes
2 posts were merged into an existing topic: The fantastic facial expressions of the Georgia grand jury forewoman are analyzed by a body language expert
… 6502 is pretty simple actually 
1 Like
That’s what makes it more difficult for people that didn’t start with it. You have to do everything manually, all with that severely limited stack.
My first assembly was 6502. When I learned x86, I was all “This isn’t assembly. Multiply? Divide? String ops?”
2 Likes
“… why would we need all these extra instructions?”
4 Likes
The difficulty of 6502 assembly is probably in the eye of the beholder. But it wasn’t a monumental task to write a simple assembler for the C64 when I couldn’t find a copy of Commodore’s. (OK, technically that’s 6510 but the instruction set is the same.) Programming the Amiga in assembly was more difficult, but that was mostly due to the funky planar graphics, IMO.
1 Like
My first experience with making games was creating my own levels in the Jazz Jackrabbit 2 (graphical) level editor. I’m all for tools that make it easier to make games, even for ancient hardware. So, cool idea!
2 Likes
Commodores? Why? Merlin all the way.
I’d hazard that the limitations of the NES makes it pretty difficult to get results, though. I started with the 68000 on the Amiga 500 and even on that, you run into the architecture and performance trouble as soon as you want to do anything gamey.
Absolutely on topic for thread touching on programming in 8-bit assembly with bank-switching memory.
2 Likes
Yeah, I didn’t think our juries here in GA were assigned by Assembly language or by an NES… 
1 Like
There are elegant ways of mapping memory into processor space, but I’m sure NES didn’t do that. 
2 Likes
I have to humbly disagree with our gracious host here.
Making games on the NES is orders of magnitude easier than other 6502 systems for the simple reason that running games is what it is built to do. You have dedicated sprite hardware, tile rendering hardware with automatic table indirection, scroll registers, an interrupt driven sound chip, vertical blank synchronization, all the goodies. It’s a dream compared to, say, writing a game on an Apple II. On the latter, you have zero help from the hardware. You have to suss out how to push huge numbers of pixels around yourself with vastly too few resources to do so. All while managing the most insane video memory map ever to grace a computer, as well as no sound hardware and no interrupts. That last one is the killer that few people appreciate. It means you have to count cycles in your code to do things like play music. Every branch in every code path must use the same number of CPU clock cycles to keep gameplay and audio consistent. Aside from a few inconsistent tricks like the Vapor Lock method, there is no way to synchronize to the vertical blank, thus ensuring your rendering won’t tear or ripple.
Kids today have it so easy.
Four Yorkshiremen GIF
8 Likes
Were third-party developers dependent on documentation from Nintendo, or were people just able to work everything out themselves by reverse-engineering existing software?
I’m sure there are clever stories out there, but offhand I forget where to find them. (Amateur historians adore the tales of defeating the 10NES lockout chip, but that’s a different matter.)
I took Assembly in College and it was probably my least favorite CS class that I did the worst in. I can’t recall the specific dialect/platform it very well might have been the 6502. The identifier was largely meaningless and the professor never gave us any sort of context how this could be used in real life. The tools we used to write/run the code we wrote were extremely dry. I really kicked myself and felt bad about how I did in that class. In retrospect I wonder if the material had been presented differently, if we could actually do anything meaningful (even as basic as just move a pixel around the screen via kb/controller/anything) if the class would’ve been more enjoyable and accessible.
2 Likes
1 Like
The hardware was very well documented. Official developers didn’t have to reverse engineer anything, same as any other console. The quality of the tools (compilers, assemblers, debuggers, etc) varied a lot. Nintendo’s was pretty good. Microsoft’s are excellent. Sony’s are a dumpster fire. You can tell who are the hardware companies who realize they need software, and who are the software companies that decided to make hardware.
Of course the home brew community has since done a great deal of reverse engineering, since the official documentation was all under NDA (again like any other console).
The documentation and tools available now are amazing compared to what we had back in the day. Full simulators and integrated development environments that make development quite quick and easy. No more cross-assembling from an Apple II over a serial cable to a ROM emulator to test your changes!
3 Likes
This topic was automatically closed after 5 days. New replies are no longer allowed.
