video roms

[Near]

I wonder how much this device would cost if it ever reaches the production stage, do you already have an idea of it?

It should not be any more expensive than SNES flash cartridges. So $100-$200. It really just needs a very, very simplistic ASIC / FPGA, a little DRAM for buffering, a memory card connector, and a base unit port connector. Ideally a case would be nice, but worst case you can stand the unit on its side, heh.

The memory spooler is less complex than LoROM / HiROM mapping logic, the data block access is simpler than the cartridge-loading file system drivers, the buffering needs a lot less DRAM than caching entire carts at a time, the card reader was already needed, the custom PCB -> SNES connector portion was already needed, the register logic is way, way less complex than DSP-1 emulation, the CIC is no longer needed from donor carts, casing was already needed. The only addition is audio output, either over the pins on the base connector port or via an audio out jack that you'd combine with an audio splitter.

I don't have much faith that we could ever actually make the device, but we won't know unless we try. Nobody will make it with no software available, so let's start with the software.

Star Ocean apparently doubled in size when the chip was removed but those 4bpp 'traditional' graphics must have been alot easier to deal with.

Yeah ... that's why I was hopeful it would be more useful.

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?

A retail DVD-ROM drive is about $30, you can probably find bargain new ones at $15 or so.

And now you get horrible loading times between scenes and using the device for any kind of reasonable random seeking is now impossible. The disks can be scratched, you can't rewrite them (well, unless it's DVD+RW), etc.

True, a DVD would only cost $1 instead of:
$9 for SD: http://www.newegg.com/Product/Product.a ... 6820208507
$14 for CF: http://www.newegg.com/Product/Product.a ... 6820134514

But I don't expect these to be super high volume devices.

I'm also curious if anyone would find a use in allowing the data port to write to the devices. I can't think of any practical use for 4GB of writable storage, but if someone else can ... :)

Anyway, the 21fx thread on my forum or here would probably be a better place to discuss this.

[tepples]

the data block access is simpler than the cartridge-loading file system drivers

What makes ISO 9660 that much simpler than FAT?

the buffering needs a lot less DRAM than caching entire carts at a time

You'll need to have at least as much DRAM as a Sega CD (about 1 MB), or you'll end up with "LOADING" every damn screen.

And now you get horrible loading times between scenes

The PS2's 4x DVD-ROM drive can fill 4 MB, the size of Donkey Kong Country, in under a second. Even assuming a seek time of a half second, that's still not much longer than the existing loading time to get SPC RAM filled up. This suggests organizing games into 1 MB "sides", much as FDS games were organized into 64 KiB "sides". Each side would be sequentially accessed during a loading period, much like a tar archive.

But I don't expect these to be super high volume devices.

I doubt that they would even be profitable to the point where a developer could pay himself minimum wage for working on a Super NES CD game.

I'm also curious if anyone would find a use in allowing the data port to write to the devices. I can't think of any practical use for 4GB of writable storage, but if someone else can ...

Unless you want to keep all the saves on a battery-backed SRAM inside the adapter, you'll need some way to save and load the state of the player's campaign. Some CD-based games have a campaign of 64 KiB or more.

[Memblers]

If you don't mind working with a 3V flash, you can get a 32 Mbyte one for about $20. That could sit right on the bus and not have to deal with loading and crap. Just all the I/O voltage differences..

[Near]

What makes ISO 9660 that much simpler than FAT?

The file system is irrelevant. Use whatever the media device uses, or use pure, direct indexing into pure NAND chips.

You'll need to have at least as much DRAM as a Sega CD (about 1 MB), or you'll end up with "LOADING" every damn screen.

It depends on your source media's worst-case latency. High-end NAND probably won't even need to buffer at all. It may be worthwhile to just say "no CDs, period." -- high latency would ruin its usefulness for eg streaming in-game graphics during gameplay.

This suggests organizing games into 1 MB "sides", much as FDS games were organized into 64 KiB "sides"

This is meant to be a base unit, the actual games are on the cartridges. 4-6MB for your program should be more than enough.

There's nothing I can do about that. The base unit is an 8-bit bus. You aren't going to be able to map in 1MB of RAM onto it in any useful fashion. That's why I use a data port with fixed DMA transfers to get data off of it.

Ideally, if something really high end was desired like that, there would be a custom cartridge in addition to the custom base unit. The cartridge could house 4MB of fast NVRAM, a nice ARM9 coprocessor, and some bitmap<>bitplane conversion stuff. That would be more for new development, which I don't expect to see. If you added a BIOS to load in 1MB from the 21fx unit, then people could store the entire games in just the 21fx cartridges and have a nice development system.

I suspect the base unit will be much more utilized for extending existing games with FMVs and high quality audio. At the very least, that's exactly what I'm going to do with it.

[MottZilla]

I like your idea and understand now your reasoning for Flash like CF cards and think it's great if it gets developed. But I think if it does it would definitely be worth it to develop a "System Cartridge" or two for homebrew games to be made to run just off a Flash Card like a CF. So the System Cartridge would really just need a Boot Strap Program to load some RAM and then I guess some simple bank switching to allow the loaded RAM to be mapped into bank 0 for vectors. And then I suppose if someone wanted to go further they could make a System Cartridge to use with the base unit that contains flexible mapping and a BIOS rom to load roms like the SNES PowerPAK does.

Anyway I would love to have as an option for a homebrew SNES game to have huge amounts of CF card storage as well as the ability to include music streams as if they were CD audio tracks just being told to play. I hope your idea for the Base Unit proceeds well and you can manage to produce it.

[Near]

smkdan, I have hosting for the completed Lunar video thanks to tukuyomi if you like :D

You'd of course need to upload it on your end, then I could mirror it and post about it for the next bsnes release.

[creaothceann]

Is there still need for video editing? I'd suggest

- CCCP (codecs)
- AviSynth (editing)
- AvsP (editor)
- VirtualDubMod (editor, encoding)

AviSynth has lots of internal and external filters, including pulldown, framerate conversion etc.

[smkd]

If there's any need to video editing, I'm not the one to be doing it!

Compression support went no where, the original plan fell flat because after actually studying the bsnes source it does not advance any sort of internal pointer when reading between writes to 420B or whatever. Atleast, it seems to look at the size parameter and decompress a big block, then feed the processor byte by byte until size is exhausted. Then it resets the appropriate bit in $4801. This is based on addr and addr isn't changing between stores to $420B so the emulator showed the same block of graphics repeatedly, only changing when banks were swtiched or the $4302-$4304 part was changed. The palette was also attempted to be made out of the same tile data.

Then I'll just go with the plan of compressing each 'sub block' of data. A compressed block of data for every frame chunk, or every transfer involved in getting a frame uploaded. 4 for vram, 1 for cgram. I'd have a working compressed ROM but the compressor causes access violations when I give it a 12800 byte file, the primary size I use everywhere. The same compressor had no problem with 532KB (or larger) files, no problem with 200 byte files, but 12800 kills it. I'll try to figure this out tomorrow.

[smkd]

If anyone still cares, the 64MB compressed ROM based on the previous one is here. 7zip shaved off an additonal 1.8MB or so, 700KB of which was padding (since I like round powers of two on roms and all that). byuu I don't know if you wanted it with or without the gamearts intro, just let me know and later I'll upload another without it. If there is another video presented for this I'll remake it using that too. The code is pretty much done, swapping audio or video in/out is easy. I think the palettes were anti-compressed, I saw 519 byte outputs for a full palette but it's no big deal.

http://smkdan.eludevisibility.org/videos/vid15_2.7z

It'll be done uploading within 10 or so minutes at time of posting

I removed the other sizable videos since I don't want to really intrude on Matthew's disk space..

[Near]

Honestly, this is more than good enough. In fact I think it's perfect. 64MB, full video, with the cool little GameArts accreditation intro, perfect audio syncup, and no errors. Video quality is great, too. No sense bugging you and others further with other sources and encodings and recompression and uploading and all that.

I'm happy to say this is perfect. Thank you so very much for making it, it really means a lot to have this :D

If you'll give me until the weekend, I'll get this mirrored to tukuyomi's FTP when I get a chance and free up your disk space.

[mic_]

Mirrored here: http://jiggawatt.org/video/vid15_2.7z

[MottZilla]

That last video is really amazing. Who'd have thought the SNES could do that given enough memory. That's really awesome.

[smkd]

Great glad you like it. And thanks MottZilla I was thinking the ROM would be immediately shunned because of the whole 64MB deal, but realistically there'd be no way to show off the quality of video/audio the SNES can push without giving it a better mapper. You can't push the SNES with this by sticking to the original 4MB limit or whatever. I'm still thinking about the mode7 video ROMs, because that's the only thing that could ever get into a cartridge homebrew but it really does seem like a dead end. 128x64 was barely watchable and the size was awful.

[Near]

I was thinking the ROM would be immediately shunned because of the whole 64MB deal

What I've learned is that there's always someone who's going to complain about anything you do, no matter what. And almost invariably, these people have never contributed anything of value to the public space; just their cynicism.

Ignore them. You've shown the world that the SNES is just as capable as the Sega CD without 20+MHz worth of 68ks :)

The only thing we did was make a one-line change to an existing special chip. This is far less cheating than the SuperFX was, and last I checked people considered Starfox a real game. Or is it just the Nintendo sticker on the box that people find so important?

I'm still thinking about the mode7 video ROMs, because that's the only thing that could ever get into a cartridge homebrew but it really does seem like a dead end. 128x64 was barely watchable and the size was awful.

Unfortunately, I have to agree. If you want to get actual video into homebrew, you are going to have to write the videos as actual programs. In other words, control each element such as mouth movement as sprites, use the scrolling registers, use the brightness registers, use compression, maybe the Mode 7 registers if you can handle 128x128, etc.

It won't look as good, but I think you can do as good as the Lunar games on the Sega CD, and fit them all into a 4MB game.

[tepples]

You've shown the world that the SNES is just as capable as the Sega CD without 20+MHz worth of 68ks

What's the bitrate of this video? Will you be able to fit 90 minutes of footage on a CD like Night Trap did?

The only thing we did was make a one-line change to an existing special chip.

So you added a couple lines to a mapper chip's bank registers, much like the difference between UOROM and the octal D-based variant that iNES emulates. Now you have to figure out how to replicate the ROM chip that the expanded mapper addresses.

This is far less cheating than the SuperFX was, and last I checked people considered Starfox a real game. Or is it just the Nintendo sticker on the box that people find so important?

Yes. People who care about program efficiency, not the inevitable outcome of Moore's law of IC density, want to see what can be done with hardware that was affordable when the platform was designed. Even on the N64, I can't think of any 64 MiB ROMs other than Resident Evil.

If you want to get actual video into homebrew, you are going to have to write the videos as actual programs. In other words, control each element such as mouth movement as sprites

Flash authors are familiar with having to do this. If you write a cut-scene authoring tool that Newgrounds people can figure out how to use, that will help all the 8- and 16-bit homebrew scenes.