NES Apocalypse Engine (Milestone 2)

So this is all background tile stuff? Or are you using sprites for this?

Yes, it's just "animated" background tiles. The sprites I'll need for the game itself

I just figured a way (aka total rewrite) that should make the engine fast enough to either plot twice as many dots or update the current number with 60Hz. Maybe even faster. I hope I find some time on sunday to type it in

I just updated the attachment in the main entry - the engine got almost twice as fast with the rewrite, it's now moving 94 pixels at 30Hz

I still know a couple of things I could do now to make it a bit faster, but nothing significant anymore and nothing without other trade-offs like upping RAM/ROM usage.

So this project can now rest in a solid state, until my next vacation

Looks good.

There are some overlap issues, though - sometimes particles disappear.

vdub_bobby, on Thu Jun 18, 2009 5:26 PM, said:

Thanks for taking a look!

The engine only works with one dot per tile and so the last dot always wins the tile. I won't do anything about it though, this little sacrifice is part of the compromise I choose to optimize vblank usage

Cybergoth, on Thu Jun 18, 2009 10:12 AM, said:

I figured it was one of those compromises you have to make. What's the overall flow of the plotting routine? Curious.

vdub_bobby, on Thu Jun 18, 2009 10:33 PM, said:

The current code is quite simple now, I started with a way more complicated approach.

Now I just have 64 predefined (ROM-) tiles with a dot in each possible position

I move the the dots, calculate their positions in the tilemap and pick the correct tile during the display time, then during vblank I clear the previous tile for each dot and set the new one.

It's insane, the NES can write less than 100 bytes into the video RAM during vblank, even with zero code overhead

	LDA LIFETIH,X
	STA $2006
	LDA LIFETIL,X
	STA $2006
	LDA CURRVAL,X
	STA $2007

A sequence like this is required to update one single byte, which is only half the code required for updating one of my dots

Yeah, I know - I remember looking into NES programming and finding out how slooooow access is to video RAM. Did you try figuring if it would be faster to use the DMA fast copy?

...

Oh. Just reread specs and DMA ($4014) is only for sprites (I think). So I guess for background tiles you have to do things the slow way. Hmm. That means you can't do character set (page flipping) animation, can you?

vdub_bobby, on Fri Jun 19, 2009 8:36 PM, said:

I'm pretty noobish here. I think you can toggle between two different tile layouts (aka name tables), so you should at least get 2-phase animation rather cheap out of it. (A problem is that you can update the inactive table only during vblank just as well , so I haven't seen a real benefit in using it yet. Perhaps it's somehow usefull for scrolling... )

And if you use a mapper with CHR RAM, you can animate tiles there as well (That's how I did the dots in the slower version.). Of course, at 16 byte per tile you're limited to animate a handfull of them per frame.

Cybergoth, on Fri Jun 19, 2009 12:33 PM, said:

The name tables are used for scrolling; the name tables are side by side (or on top of each other) and you can move the visible display over them.

With extra memory (on cart) you can use four name tables and scroll in all four directions.

See here: http://nocash.emubas...m#ppubackground
I suppose you could flip the two name tables to get some animation, though I've never heard of anyone doing it.

I think you can flip pattern tables (bits 3 and 4 of $2000) to get animation, but then you run into problems with your sprites, though they wouldn't be insurmountable. Mainly it would really chew up the VRAM in a hurry. That really is a huge advantage of, e.g., the 800/XL/XE (and I think C64) architecture where you can point the display at any piece of RAM/ROM. Of course, the NES has other advantages.

vdub_bobby, on Fri Jun 19, 2009 4:58 PM, said:

The VIC-II (video chip) only has a 14 bit address line, so it's restricted to 16K. However, one of the CIAs is used to control which of the four 16K banks it sees. The built in Character ROM only appears in 2 of the 4 banks.

Commodore 64 Video - A Guided Tour

The MOS 6567/6569 video controller (VIC-II) and its application in the Commodore 64 - see section 2.4.2 Memory map as seen by the VIC

SpiceWare, on Sat Jun 20, 2009 2:27 AM, said:

The key is that CPU and GPU are working with the same RAM and that the CPU can access it any time. As long as the CPU is ahead of the raster beam, you're fine drawing whatever you want, whenever you want