91–100 of 138 posts
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
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…
Yeah, but the hardware is so limited with weird corner cases that writing a bitblt might be easier. For example, some games have to reconfigure their sprites at the beginning of every horizontal scan line to overcome the hardware limitation on simultaneously displayed sprites (8).
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…
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
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 frameworks model is encroaching there too.
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…
> On the NES however, every line of code is yours. I once stuck my nose into Game Boy Advance homebrew and was happy to find it can be the same there. Every piece of the hardware is memory mapped. That means, given a reference of the mapped addresses and struct definitions, you can do whatever you want with the machine without any magic, black-box external code.
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…
>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. That's precisely why I would qualify ASM as "tricky" and "tedious". You're bogged down in the tiny details that nowadays a compiler would probably solve as well (or even better) than you do. If…
Assuming this is a recurring problem, I'd just use two libraries - a binary tree and a floating point one (I cut my teeth on the Apple II+, so I could count on FP routines already in place in the ROM. If a tree library is not available, writing a tree walker is not a particularly difficult task.
Libraries, subroutines and macros were a huge helper then.
> I need an intermediary register, do I have one available?
If we are talking 6502, the answer is "no". You had page zero, which was almost as good as having 256 8-bit registers.
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.
That's the relaxing part.
Earlier quoted context omitted.
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.
Of course you can pick up old parts which fell off a truck for cheaper but I'd rather not do that when I depend on these parts for many years to come.
Earlier quoted context omitted.
It's the difference between being a plumber and being someone who makes custom jewelry. Both are artisans of a kind, the one is doing production and trying to 'get the job done' the other is making one-offs that will have a vastly inefficient time:product ratio where a lot of the value created will be in the eye of the beholder. Both are valid paths.
It's more like someone making custom jewelry using modern tools vs. somebody making custom jewelry only using methods available in ancient Rome. You might not see any obvious difference looking a the result but once you know how they're made one is definitely more impressive than the other. I'm also sure that one is more "tricky" and "tedious" than the other, which is what I was addressing. If you code something for…
But we are talking about the 6502 inside the NES, running at less than 2 MHz, with one accumulator and two index registers, a couple status flags and an 8-bit stack pointer within a 256-byte stack. It's a simple machine, for simpler problems.
And yet, guys like Paul Lutus were doing real-time 3D wireframes in FORTH, with fast 8-bit scaled trigonometric functions (no floats involved). It was pure badass of a magnitude not heard of since.
My own contribution was a windowing library for the Apple II that did fit in 1024 bytes and ran self-modifying code to display overlapping windows.
Earlier quoted context omitted.
A mechanical solution would be using other languages like C
Using C you cannot get the advantages that 6502 assembly provides. On the other hand, to stay with towers of Hanoi, one can show that the simple mechanical algorithm that one can derive for it, will solve the problem with a minimum possible number of moves.