nesdev.org

Hey tokumaru thanks for providing this. That's some impressive ratios.

Well the desire for speed and more efficient nesting has led to yet another "rehaul" (though not as big as the last one) and I am thinking of moving to 16-bit "opcodes" (really 16-bit direct threaded code, classic Forth) Right now I'm not sure if it'll be worth the effort to imp...

By the way, how is Forth as a programming language? I've never tried it myself. Seems like it uses RPN extensively, but how different would it be from Basic or C if it used infix notation? It is slower than C (in Eighth's case probably 2x), but faster than Basic. Its big draw is ease of implementat...

Well the desire for speed and more efficient nesting has led to yet another "rehaul" (though not as big as the last one) and I am thinking of moving to 16-bit "opcodes" (really 16-bit direct threaded code, classic Forth) I discovered a way to do the inner loop for threaded code (...

Nestopia does not understand iNES byte 10. Because one of the last 6 bytes were set, it clears all of bytes 7-15, so the part where you're getting PRG-RAM is intrinsic. Really, use NES 2.0 . thanks, doing that solved it. NES_MAPPER=2 ; UNROM .db $4e,$45,$53,$1a ; NES,eof ;4 .db 8 ;NES_PRG_BANKS - 1...

In case anybody is wondering, I went with Mapper 2 with 8 banks for now (128KB), CHR RAM and PRG RAM enabled. It works in Nintendulator and Nestopia. However Nestopia complains about garbage data in the header before starting the program. Here's my header - if anyone can point out anything I'm doing...

Because the 6502 is turing complete Nothing is Turing complete, as a Turing machine has unbounded memory. Adding a physical limitation to a Turing machine results in a linear bounded automaton, and what you probably meant is that the 6502 is LBA-complete. This brings me to the second half of your c...

Heh, I'm the exact opposite. I find it really fun to think of clever ways to accomplish things on simpler hardware. OTOH, I'm not exactly known for finishing my projects! :mrgreen: Horizontal maps can be easily decompressed on the fly. If you mark some spots in the stream you can even scroll backwa...

You are supposed to fully understand how the algorithm you pick works and to write your own decompression code. It is not an "advanced" tools for nothing :) You have a java decompression code available. There is multiple reasons I did it this way. First, I don't want to restrict usage of ...

Hey, this seems pretty neat and I ran the example (which spat out some warnings about unknown escape sequence \*) but I don't understand how I'm supposed to use the files that it outputs. Where is the 6502 decompression code?

I found this cool wizard that helped give me some more confidence. http://pineight.com/nes/mapperwizard.html Looks like what I'm going to be developing for is most likely SNROM. Glad I could be helpful. you made this? it's really nifty! i was wishing for something like this, was kind of surprised w...

Despite what everyone else said, iNES (unfortunately) implied 8KiB of PRG RAM for almost all mappers, in the standard place. I think no extra work is needed from you, although adding error detection ("do I have RAM?") and a message would be clever. NES 2.0 headers have the advantage that ...

Just made the code available, see OP.

Another thing you could do is to make up a mapper something like what I did here ; therefore it can work with a ASIC mapper while also being easy to build a discrete mapper with the subset of features you are using. wow thanks man. i think this looks like exactly what i was looking for. no fancy ma...

In any case, I think you shouldn't worry about the hardware yet (beyond some minimal "is this feasible?"). Making hardware is really a nice capstone to make a project Real, but its difficulty and complexity is notably less* than writing a game. Also, remember that using NES 2.0 headers wi...