nesdev.com

Having a quite a few unfinished projects and/or games that never got to see the light of day to my name, I'll second this.

Iirc, when I was 11 or 12 I was hard at work trying to create a remake of FF4 in C++ in DOS - and I was in way over my head, not really understanding the majority of what I was doing, and not really learning anything in the process. Like others have said, it's a lot easier to stay motivated and actually learn when you're doing attempting something that's a decent challenge, without it being way beyond your abilities.

Which is why I made a NES emulator, rather than a PS3 emulator :)

I just thought about this: do we even know if he/she even knows any 6502 assembly or assembly of any kind? That's obviously the first step.

I think the most important thing is feedback. Write, compile, test. I had no goddamn clue what I was doing when I started working on MC-FRUC, but after I spent an afternoon slapping together the cruddiest motion-compensation algorithm ever devised, I had something to work on. I tweaked and tweaked and tweaked until I'd rewritten every line at least a hundred times, the result looked nothing like what I started with, and I'd researched half a dozen different ways of achieving the end result.

The key point was it did something. I could fire up my movie player any time I like, see the code in action, and every time it screwed up, I'd get the itch to dive back into the code, find out why and fix it. It's been three years almost to the day now and I'm still not done, but every now and then I walk into a store selling flashy 120hz TVs and spot one of them proudly showing off the same glitches I've already solved. Results are one hell of a motivator, even when you're only halfway there.

Yeah, I'm programming a Space Invaders like game, that works so far.

All depends on how ambitious and precocious you are at age 12 I suppose, but good luck whatever you try! Have you heard of this?

Pico 8
Pico 8 tutorial series on youtube

I get the feeling kids would love it. I love it, and I never grew up, so I think that's pretty good evidence. Might be a great place to start before moving to NES. There are actually a couple of really nice raycasters in the featured games section (you can download others' games for free from WITHIN pico 8) Nothing wrong with playing around with one even if you might not make your own just yet. You'll be able to view the code right away, too.

The PICO-8 is based on the virtual machine of Lua, which has floating-point instructions. An FPU makes ray casting a lot more efficient than it'd ever be on an unassisted 1.8 MHz MOS 6502 CPU.

I remember, when I had zero prior programming experience of any kind, reading the introductions to SNES programming tutorials, all of which recommended learning assembly for more manageable 2D systems (almost anything) first. "How hard could it be?"


Not to be confused with PICO-6.

Interesting.
How hard and how much benefit would an added NES-era processor (such as Z80 or V30) bring?
Does any NES game ever use a co-processor, like the Super FX for the SNES?

Not a (single) game, but rather a system on a cart, the WideBoy when attached to the cartridge port of a Famicom, would display GB games on a TV through the Famicom output, not unlike the SFC's Super GB. In actuality the Famicom is more like a dummy connector though, as it does nothing besides displaying a fixed name table with tiles taken from CHR RAM on the WB that is essentially used as a bitmap to show the GB screen (and that since the 256 tiles of one CHR table is not enough to hold the whole GB screen as a bitmap, the WB also tells the FC to switch to another CHR table mid-screen to show the rest of the tiles).

From what I recall, the WB used the MMC5 in its "extended nametable" mode to effectively perform CHR bankswitching automatically.

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

In ccovell's ROM dump, I see MMC1 register writes ($F⇝[$8000], $0⇝[$A000], $16⇝[$E000]), but no obvious evidence of any custom mapper IC in his pictures ...

Programmable logic: two PLS100s, and one PAL16L8
Discrete logic: four 74'161, three 74'164, one 74'08, one 74'374, one 74'367(?), one 74'244, one 74'14(?)
Three RAMs: TC5585
Other: U16 (can't decipher the part number), U6 (no visible part number), DMG CPU (U23)

I'm pretty certain that the relaying of serial LCD data to the tilebuffer is entirely handled in hardware...

Apparently, I was thinking of the Demo Vision (which was also dumped as "Demo Boy 2"), which definitely used an MMC5.

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

So, a bit of a late reply, I know, but I came up with a way to pull of ray casting and wire frame graphics. My ray casting works by having one vertice at the camera, and then another vertice a certain distance away. It makes a slope intercept form equation out of the two points, and executes it, incremeting x each time, and checks if it collides with a wall. If it does, it gets the X and Y coordinates in that wall to find what pixel it lands on. It then changes the second vertices Y position by one and sends another ray and then sees what pixel it lands on. Then it knows how many pixels to skip in scaling the texture. However, if it gets the same coordinates as last time, it continues incrementing the second vertices Y position until it lands on a new pixel, and it knows then how many times to repeat that pixel in scaling the texture. If there is no wall within a certain distance, it increments the X position of the second vertice. However, after decoding the one vertical strip of the wall, it then increments the second vertices X position, makes a slope equation form function, and wash rinse repeat until you have scanned a screen’s worth of data.Feel free to ask me any questions about this. I’ll share my wireframe engine if you want.