video roms

[tepples]

The only reason it wouldn't be able to cross a 1MB ROM boundary is if the chip internally uses a 20-bit address register. That would be rather stupid.

But stupid isn't beyond Nintendo, even if it only saves a couple gates. Here are five penny-wise, pound-foolish examples from the NES:

1. DPCM playback wraps from $FFFF to $8000, not $C000 or $0000.
2. The sweep unit on the square wave channels will silence the sound even if sweep is turned off.
3. CPU I/O registers $4000-$4017 are fully decoded yet they overlap $4000 rather than the superfluous mirrors of PPU address space ($2008-$3FFF).
4. PAL NES CPU clock divides by 16 instead of 15.
5. Spurious fetches of nametable data in hblank between sprite pattern fetches instead of adding eight more sprite shift registers.

In that case, modify it to only use MMC3

(tepples makes sure he's still in the SNESdev forum)

I don't think it violates the spirit of the chips though to simply extend their addressable range.

That's what NES people thought about CNROM until we learned about the diodes on D4-D5 used for extra enable signals to thwart early copiers.

A single 8x8 4bit tiles takes 32bytes. A single tilemap entry takes 2 bytes. [...] Wouldn't be updating 8 subpalettes be even smaller than updating an 8bit palette?

I was under the impression that one would try to update subpalettes multiple times per frame. If it's just attributes, not entire subpalettes, that's different, much like the tricks to get photorealistic graphics on a TMS9918 chip (see the Roxette cover in post 8).

[HJRodrigo]

EDIT: I just checked the high quality video again and it's actually 30 fps, but it doesn't look very smooth because it was poorly converted from 24 fps. This means that every 5th frame is the video is a duplicate of the 4th, and this kills all the smoothness. If someone is able (I failed very hard at getting VirtualDub to open the mp4 file) to get rid of the repeated frames they'd probably get a very smooth 24 fps video, which could be properly converted back to 30 fps.

If I remember correctly, you have to use a Non-linear editing program with AVC's. Try VideoSpin with the necesary plugins.

[smkd]

edit: yeah I mixed up the videos, it was the Saturn MPEG one.

I'm having some difficulty with andreas' compressor program, atleast it appears to be outputting inconsistent results for me. I modified the source files with the main routine to take a command line parameter and that's about it.

http://img14.imageshack.us/img14/9014/43426323.png

On the left is the file I tried to compress, on the right is the result after compressing, then decompressing the output. I didn't touch any of the classes that actually compress and decompress.

I'll post the source I cobbled together for this because thee must be something silly I missed. There's not much to see though... I do everything in C# so:

compressor:

Code: Select all

int main(int argc, char* argv[] ) {

	uint8 out_buf[0xc000]; //arbitrary size
  	uint32 out_len;
  	SDD1comp SDD1encoder;

	//open something and grab its size
	ifstream OpenFile(argv[1]);
	uint32 fileSize = 0;
	OpenFile.seekg(0, ios::end);
	fileSize = OpenFile.tellg();
	OpenFile.seekg(0, ios::beg);
	uint8* in_buf = new uint8[fileSize];
	uint32 i;
	for(i=0; !OpenFile.eof(); i++)
		in_buf[i] = OpenFile.get();
	
  	SDD1encoder.compress(fileSize, in_buf, &out_len, out_buf);
	ofstream SaveFile("output.bin");
	for(i=0; i < out_len; i++)	
		SaveFile << out_buf[i];
	SaveFile.close();

  return 0;

}

decompressor:

Code: Select all

int main(int argc, char* argv[]) {
	uint8 out_buf[0xc000]; //arbitrary size
  	uint32 out_len;

	//open something and grab its size
	ifstream OpenFile(argv[1]);
	uint32 fileSize = 0;
	OpenFile.seekg(0, ios::end);
	fileSize = OpenFile.tellg();
	OpenFile.seekg(0, ios::beg);
	uint8* in_buf = new uint8[fileSize];
	uint32 i;
	for(i=0; !OpenFile.eof(); i++)
		in_buf[i] = OpenFile.get();

	SDD1emu SDD1;
	SDD1.decompress(in_buf, fileSize, out_buf);
	//making assumption about outlength, it would be known prior to this what the decompressed size is anyway
	out_len = 5000;
	ofstream SaveFile("output.bin");
	for(i=0; i < out_len; i++)		
		SaveFile << out_buf[i];
	SaveFile.close();

  return 0;

}

I didn't catch any issues before because my test file was only 200 bytes or something, it appears to go crazy after the "world" bit.

----

If that gets all patched up, I will make the program switch banks after crossing a 512KB page of data and set the S-DD1 DMA pointer again. I also noticed the compressor wouldn't do anything over 64KB seemingly because of the uint16 used for length, I just switched it to uint32 in all the relevant parts and it didn't seem to crash, although the odd compression results meant I got impossibly small file sizes. I wondered for a while what was going on.

I also wonder how much the S-DD1 could actually address becuase it's got hundred pin package and the Polish site with the only pinout I can find has an awful lot of "???"s there. The thing has a hundred pins but I can't see Nintendo thinking to themselves in 1996 that someone would require 16MB worth of ROM or something. Or be willing to pay for it, N64 games weren't even that big yet. I wonder if anyone here knows for sure what it could do.

[Near]

I'll post the source I cobbled together for this because thee must be something silly I missed. There's not much to see though... I do everything in C# so:

From your screenshot, it gets mangled after the first \r. It looks like you're reading the file in using ASCII mode instead of binary mode.

I also noticed the compressor wouldn't do anything over 64KB seemingly because of the uint16 used for length

Yeah, that's just the internal limit of a DMA transfer.

I also wonder how much the S-DD1 could actually address becuase it's got hundred pin package and the Polish site with the only pinout I can find has an awful lot of "???"s there. The thing has a hundred pins but I can't see Nintendo thinking to themselves in 1996 that someone would require 16MB worth of ROM or something.

Yeah, as before, extra address bus pins cost money. It'd be like an 8086 chip supporting a 48-bit address bus. Why would you do that?

I really think the S-DD1 was limited to either 6MB or 8MB, and the SPC7110 to 5MB.

We're definitely cheating by using the full 8-bits for the MMC bank pointers.

I've decided to work on an enhancement "base" unit, in the hopes of supporting up to 4GB of storage data (most everything would only use 32MB or so, of course), and allow streaming FMV + CD-quality audio without ADPCM compression. I'm designing it in such a way that it works fully even when the base unit isn't there, and to be technically possible from a hardware standpoint.

I know people are going to throw a fit already, but I honestly don't care. I know it's a nice idea, and I know it will enable some awesome new software with only ~2kb of extra code to existing SNES emulators. If some people don't like it, well, they don't have to use it.

With any luck, we get enough high-profile titles using it and maybe someone will consider making a hardware version =)

[Masterflow]

I converted the intro from the Saturn and the mp4 yesterday...perhaps its still useful.

http://rapidshare.com/files/314670400/l ... o.rar.html

[smkd]

Thanks for that, I'll let byuu be the judge of quality plus my internet blows at the moment.

Yeah ios::binary fixed that up, I haven't had to deal with the sort of stuff since I was making shitty C apps with fopen. It works great now, with the extended compression with uint32 and all. I did quick tests in the decompressor / tilemolestor to see if anything was out of place. It takes its sweet time in compressing it though, must be a really involved algorithm. I compiled it with -O3 but with my pretty much nonexistant experience with the compiler, I'm not sure if there's anything else I could do to speed things up. I don't really mind though, I'm plenty patient.

I initially ran the conversion on the existing video using the compressor source just how it was originally (minus the extension on the size it can compress), but I was forgetting reading andreas' notes about the compression. It mentioned headers for different tile types and I compiled it using the original '00' setting. '01' is what I wanted for 8bpp tiles apparently so I ran it again using that. Just had to change the header parameter in the .cpp. It didn't appear to do anything though, I might have slipped up somewhere in copying or whatever, I will try again tomorrow.

Compressions statistics are:
original uncompressed: 81.6MB
00 header compression: 59.3MB (saved 22.3MB)

Code: Select all

compress(0, in_len, in_buf, out_len, out_buf);

01 header compression: 59.3MB?

Code: Select all

compress(1, in_len, in_buf, out_len, out_buf);

there were an awful lot of unfortunate packs of frames (I compressed 14 frames in a single pack, or 532KB) where it reported 520KB+ compressed size, even with 01 header. Most packs appeared to hover around the 400KB+ mark, I'd just occasionally look at my program's output in the console, stating what the compressed size / saved byte amount was at the time. Ofcourse the less busier frames were compressed quite nicely. It shaved off a decent chunk atleast.

e: I'll just make the header setting a command line parameter and have my program try all in succession and pick the smallest one, I'll do that next time around.

[nintendo2600]

So what are the odds of this SNES video making method being able to fit say a 20 min cartoon onto a chipsize feasable for actual cartridge use? I'd love to see something like an old Heman, Smurfs or *gasp* Super Mario Super Show episode(s) on SNES cart(s). Would it be able to fit on a SCHV pcb you think? I ask about that PCB as it's so common to find on crappy commons.

[Near]

e: I'll just make the header setting a command line parameter and have my program try all in succession and pick the smallest one, I'll do that next time around.

Wow, that's an even worse ratio than I initially imagined. Only ~25% or so :/

Yeah, probably best to just try all three on every frame. That's how I'd do it if I were making a game with this chip.

Overall though, I think it's worth it. We got it under the 64MB mark :D

Thanks for that, I'll let byuu be the judge of quality plus my internet blows at the moment.

I'll have to check later tonight. Hopefully it adds a little motion blur for that annoying side-scrolling thing :D

So what are the odds of this SNES video making method being able to fit say a 20 min cartoon onto a chipsize feasable for actual cartridge use?

0:∞

Sorry. It's about 59MB for 90 seconds of video using compression and 20fps. You'd probably have to do something like 64x64 at one frame per second and 500hz audio to fit all that in.

[MottZilla]

You could do it if a new PCB was produced with a memory mapper implemented to handle large amounts of ROM. Afterall just look at what some pirates will do to stick a ton of bootleg games into a cartridge. Otherwise, no. No regular SNES cartridge PCB will ever support enough ROM. So you best start hoping for a SNES CDROM that can stream data or something.

[Bregalad]

I trought the SNES CDROM was called the PlayStaion

Aside of that the only point in making SNES videos in my opinion is to use them with a SNES homebrew game - which I really hope will happen someday !! But until someone makes a SNES homebrew and want to add a video to it, there is not that much point in doing that.

[Near]

So you best start hoping for a SNES CDROM that can stream data or something.

I'm working on a design mockup for just such a thing, but based around flash storage instead. No reason to be nostalgic with ancient mediums when flash is cheap ;)

If it catches on in software, a hardware-backed device should be possible.

Aside of that the only point in making SNES videos in my opinion is to use them with a SNES homebrew game

Not really. What about embedding the Chrono Trigger FMVs into the SNES game? Same great game, without the loading and seek times, and without the need for a closed source or low quality PSX emulator:

http://www.youtube.com/watch?v=hOmgIZZuI68
http://www.youtube.com/watch?v=_O091Vr3L1M

[Bregalad]

I admit it would be very cool but it's probably the only exeption to what I said.

[MottZilla]

I'm working on a design mockup for just such a thing, but based around flash storage instead. No reason to be nostalgic with ancient mediums when flash is cheap

But I suppose that depends on your intent for such a system. If you just want a free for all I suppose something like Flash Memory (NAND) would be fine but if you wanted to actually sell games and protect them I would think it would be easier to do on CD plus another reason to use CD would be for the Audio.

It would be neat to see a SNES Chrono Trigger running on BSNES with the FMV inserted. Good luck with that.

[naI]

I'm working on a design mockup for just such a thing, but based around flash storage instead. No reason to be nostalgic with ancient mediums when flash is cheap

You do know that CDs are much cheaper than flash (just a few cents per 700MB disc), and a standard CD-ROM drive would only increase the cost of such a unit a few dollars at least?

[smkd]

I wonder how much this device would cost if it ever reaches the production stage, do you already have an idea of it? I don't know much about the overheads involved but a ballpark figure would be cool, if you have the design already thought out.

On a side note, I just realised the compressor tries all 16 combinations of the header (those 2 bits for bitplane mode, those other 2 bits for probability estimation thing) and automatically puts out the smallest size already, that's why it takes so long and why I saw no difference. I should pay more attention to what's going on in that .cpp file, I just ignore it for the most part. Oh well, 64MB ROM is still happening atleast.

edit: yeah I was hoping for better with compression results. I guess the images are just really unforgiving, 8bit with dithering throughout, even if its subtle dithering. Star Ocean apparently doubled in size when the chip was removed but those 4bpp 'traditional' graphics must have been alot easier to deal with.