sadly haven't put an emulator on this rig yet, do you has screenshots? 
I hope Nestopia doesn't let programs running in Nestopia brick my PC. We all know about what happened with "taihen" on the DS...
haha! That's really awesome! What are those from, anyway? That is alot of CHR!! Well done : )
They work on Nesticle for me exept there is a few glitchy scanlines that are fixed if you reduce HBlank cycles from 115 to 114.
Nice demo, altrough I'd like it to be done with PolyNES engine (no just kidding).
Nice demo, altrough I'd like it to be done with PolyNES engine (no just kidding).
Awesome. 
All we need now is a new mapper that is capable of bankswitching a few hundred MB worth of data, both PRG and CHR. Toss in some code to play PCM data, and you could watch movies (or at least short cartoons) on the NES!
All we need now is a new mapper that is capable of bankswitching a few hundred MB worth of data, both PRG and CHR. Toss in some code to play PCM data, and you could watch movies (or at least short cartoons) on the NES!
Possible? Yes. Efficient? Not very. A full screen with no repeated tiles (how would you find them in dithered data?) needs 256*224*2 = 114688 bits of CHR. At 12 fps (typical cartoon frame rate), that's an inefficient 1376 kbps just for the video.
If we want to make FMV's on the NES a reality, what we really need is CHR-RAM and a good codec that takes into account temporal and spacial redundancy, for which a decoder can be efficiently programmed for the 6502 so that a video frame can be decompressed in no more than 4 or 5 hardware frames.
The problem is that with just 8KB of CHR-RAM it would not be posible to fill the whole screen (although a wide-screen image wouldn't look so bad). It would also be impossible to double buffer the tiles of the new frame as they are decompressed.
I while ago I was thinking about a codec that allowed a maximum number of tiles to be updated every frame, probaly tiles that weren't used by the current video frame. A codec like this would be heavily based on spacial redundancy, because the same video frame would use a very limited number of tiles.
Well, I'm not sure what kind of compression would work better. This has always been one of my plans, to code a compressor/decompressor for NES videos, so that small cutscenes that fit in regular carts could be used during games. I always give up though, because I can't think of a way that would actually work (and look acceptable).
The problem is that with just 8KB of CHR-RAM it would not be posible to fill the whole screen (although a wide-screen image wouldn't look so bad). It would also be impossible to double buffer the tiles of the new frame as they are decompressed.
I while ago I was thinking about a codec that allowed a maximum number of tiles to be updated every frame, probaly tiles that weren't used by the current video frame. A codec like this would be heavily based on spacial redundancy, because the same video frame would use a very limited number of tiles.
Well, I'm not sure what kind of compression would work better. This has always been one of my plans, to code a compressor/decompressor for NES videos, so that small cutscenes that fit in regular carts could be used during games. I always give up though, because I can't think of a way that would actually work (and look acceptable).
If you really want compression for NES video, just use something LZ based, with a maximum window size of the previously displayed frame. Depending on the stream format used, LZ can be can be just as fast as memcpy, depending on memory access times.
Dwedit wrote:
Depending on the stream format used, LZ can be can be just as fast as memcpy, depending on memory access times.
CHR RAM writing and especially reading through PPUADDR/PPUDATA are slow. If we use a special mapper to make CHR RAM pseudo-dual-ported, we might as well implement compression in hardware too.
"LZ" is just too generic for video... Some combination of block-based schemes should be used. Also, I don't think you need constant access to CHR RAM, as most of the work could be done in WRAM. If the video is displayed as "widescreen" the borders would provide some decent time for copying the data to CHR RAM and name tables once it's ready. A common cart can be used for that.
...yes, and the output could be even black and white. 
Dwedit:
A while ago I made a NES/Fami song called "Kittens n' Shit, I Guess."
http://2a03.free.fr/?p=pub&dir=B00daW
If you were to open the FTM and drop the speed down to '2', I think it would be fitting; especially since there is no DPCM.
Just File, and then Create NSF.
You won't hurt my feelings if you don't use it.
*THUMBS UP* on the mania.
Update:
Please include JARGON BANNED in celebration to your lolicats demo.
A while ago I made a NES/Fami song called "Kittens n' Shit, I Guess."
http://2a03.free.fr/?p=pub&dir=B00daW
If you were to open the FTM and drop the speed down to '2', I think it would be fitting; especially since there is no DPCM.
Just File, and then Create NSF.
You won't hurt my feelings if you don't use it.
*THUMBS UP* on the mania.
Update:
Please include JARGON BANNED in celebration to your lolicats demo.
On a nes with PowerPak, it starts frozen on s single frame. Pushing reset gets it going, but with a strange rolling effect.
That's insane and pretty impressive. I had no idea CNROM supported 1MB of CHR-ROM. o.O
MottZilla wrote:
That's insane and pretty impressive. I had no idea CNROM supported 1MB of CHR-ROM. o.O
CNROM boards manufactured by Nintendo don't support more than 32 KiB (four 8 KiB banks) of CHR. But some unlicensed CNROM-compatible boards have 128 KiB, and I'm guessing the emulators replace the 74HC161 binary counter with an 8-bit latch as described here.
jason_m wrote:
On a nes with PowerPak, it starts frozen on s single frame. Pushing reset gets it going, but with a strange rolling effect.
The PowerPak has 512KB of VRAM. This ROM needs 1MB.
Updated with music.