Writing a game from first principles in 65c02 – Part One
feertech.com
feertech.com
I disagree with this statement, humans use fingers on one hand to represent 0-5 (6 distinct values) and fingers on two hands to represent 0-10 (11 distinct values)
You could check out the Nerdy Nights tutorial for NES development which is fully fleshed out and has a tried and true record of getting people started: https://nerdy-nights.nes.science/
Apologies to the author if this seems harsh and disheartening, but, i've seen too many tutorials both never finish and give out incorrect information.
> Simple NES emulator
The timings get really tough between the PPU / CPU with all of the scanline tricks you can do, even with an NROM setup. Many 6502 instructions don't behave like you think they would with page boundaries, there are some hardware errors. The PPU / registers get all kinds of weird with their behavior too, such as $2003/$2004 (sprite addr / data) basically being broken on real hardware and Sprite DMA only falling on even cycles, etc. Each mapper is it's own unique snowflake as well, the MMC3 and VRC6 scanline interrupts work completely differently in hardware. There are many more examples of strangeness.
I'd love to see someone tackle it and wish you luck.
Right, I agree. The PPU's intricacies are what make it difficult to write a good tutorial. When I wrote my own emulator as a personal learning project in C I did it myself except the background rendering of the PPU which I ported from a popular cycle-accurate Go project. In writing this book, what I've done is go and say "how can I write the absolutely minimum PPU so that the most basic NROM games will play (like Donkey Kong & Tennis)." My rewritten from scratch PPU is as simple as possible, only doing any rendering once per frame (the simplified PPU only does anything 60 times per second). I have it working well on very simple commercial and public domain games in C. Now my challenge is to get it ported and performant enough in pure Python, the language of the book.
Is it possible to sync python up enough to get it to write frames accurately without a significant amount of lag? I'd certainly be interested in how to get it to do that.
Color by bit position repeated every 2 bytes, or 14 pixels.
One can choose to store the data in weird ways that map to the screen, or use table lookups. From there, unrolled code can go damn fast too, and in all those scenarios, RAM is used to cope with goofy addressing.
Then comes 7 pixels per byte!
On the plus side, doing that, plus the high bit shifting pixels a little to provide a basic color attribute bit, meant getting a 6 color display instead of a 4 color one.
6 colors is enough to do basically anything. 4 is not quite enough.
But, that also means having to either shift data prior to blitting it to the screen (slower), or preshifting (faster), and more preshifted data copies are needed because the color by bit position repeats every two bytes, not every byte like pretty much all the other 1bpp + artifact, or 2bpp systems needed.
If one has the RAM, fact is the Apple did not have screen DMA wait states slowing the CPU down. That meant getting the best of 1Mhz.
It also made the system easy to accelerate too.
A 2 to 4Mhz Apple performs very well on software sprites.
But even the stock machine could deliver quite a bit more than one might expect, given things could fit into RAM.
4Mhz can deliver a side scroller on par, BTW. But, that would still be a RAM challenge to hold the diversity of images seen in something like Keen.
Rectangular bitmap sprites may have debuted in consumer hardware with the TI-99/4 in 1979; the term "sprite" comes from the technical documentation for that computer.