nesdev.org

Can't look yet, but I assume thefox/jungle book use vertical mirroring to avoid the horizontal attribute clashing. And two scan line triggers; the obvious one for the status bar, and another for vertical scroll seam wrapping.

Without 8 pixel attribute alignment errors at the edges ? I admit I haven't thought too hard about it but Im thinking status bar requires you to use horizontal mirroring (vertical frame buffer). You can scroll indefinitely horizontally with hardware wrapping, use scan line breaks to reset vertical s...

What is it you are looking for exactly? Status bar really complicates things and makes clean 4 way scrolling impossible without additional 2k CIRAM on the cart. Otherwise it's pretty straight forward using vertical mirroring. The biggest thing though is going to be name table / map compression using...

couldn't they have made it so that the bus was left unused in that 5th cycle? I'm sure they did everything they could to keep costs down when designing the 6502, so you can be certain that this decision was made to reduce the number of transistors. Pretty sure that reads with side-effects were alre...

tepples wrote:Battletoads uses the "funky" pattern and gets away with it.

Really... never noticed anything unusual. Now I want to look when I get home.

Though it's a Sony PVM with a 358 filter enabled so could be why.

STA (xx),Y adds a dummy read. 1 PC R fetch opcode, increment PC 2 PC R fetch pointer address, increment PC 3 pointer R fetch effective address low 4 pointer+1 R fetch effective address high, add Y to low byte of effective address 5 address+Y* R read from effective address, fix high byte of effectiv...

Also, nobody has any insight as to what is special about STA (zp), Y? That was the question I was most interested in. Why does it generate an extra increment? Yeah... not sure. Whats the 6502 bus doing on that opcode? Maybe the ZP accesses for the base address cause dummy bus accesses that confuse ...

thefox wrote:

exdeath wrote:It's doing exactly what you're telling it to. It's compiling array/pointer dereferencing and indexing arithmetic, so an indexed indirect addressing opcode is the most perfect output code.

Most perfect? No way, it should/could know that the address is constant and optimize accordingly.

It's doing exactly what you're telling it to. It's compiling array/pointer dereferencing and indexing arithmetic, so an indexed indirect addressing opcode is the most perfect output code.

Ok so got home and looked at the map again. Two types of data, compressible runs, and 1 offs. Compressible data like "63 water, 13 tree, 16 mountain, 13 water" compresses to almost nothing. Leaves 1 off data to worry about. Of the 1 off data, things like towns, caves, bridges are so infreq...

I think it just makes it a different metatile based on whether or not the surrounding tiles are water/bridges/shoals. And more metatiles doesn't necessarily mean duplicate tiles, since metatiles can share physical tiles. True if you have a mapping table. For simplicity in my current train of throug...

The DW games smooth the shoreline after it's decompressed. Makes sense. The compressed data refers to metatiles. Keeping metatiles of all possible shore combinations would consume a large amount of CHR-ROM with duplicate ocean pixel data. Keeping the shoreline outside of the compressed map data mea...

The way Dragon Warrior 2, 3, and 4 encoded maps: xxxxx... length .....xxx tile number (not 100% sure of the order of the bits, I'd need to look that up) If tile number is 0, instead use the length as the tile number of a single tile. Using a different set of tile numbers than the others. Makes perf...

If metatiles repeat or share physical tiles, you may be able to fit more than 64 distinct metatiles in 256 physical tiles. I thought about this. But that's a matter of just having a lookup table that maps a metatile to 4 physical tiles. So whether it's fixed (eg: metatile 0 = phys tile {0, 1, 2, 3}...

Currently investigating compression and large maps. I'm experimenting with 4096x4096 pixel maps (eg: Dragon Warrior world maps). Messing around on paper and in Photoshop just looking at things. First recognizing that I only need 6 bits per metatile (64 metatiles in CHR-ROM bank at a time), or 5 bits...