video roms

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic

video roms
by smkd on 2009-11-24 (#52981)

I was recently messing around with trying to get the SNES to display smooth video, I had to make huge comprimises but I got a clip of me playing F-Zero at full speed running here.

Process was PJ64->fraps->vdub->irfanview->a program I made to convert / interleave pixels->incbin in xkas.

Random stats are 7.12MB for the 64x56 4bit video, 830KB for the 22khz audio (thanks snesbrr) and about 40kbish or something for the code. It takes about 55% of a frame or so to unpack video and prepare the audio, I couldn't get stuff to fit in a frame until I realised I could shave off a huge amount of code just by interleaving and duplicating the 16 color palette throughout.

It's a 8MB ROM, all but about 64KB or something is used. I didn't want to mess with screwy Ex ROM mappings so I picked S-DD1 to be my mapper. If I knew enough about it to make a codec I definitely would've, I could've bumped the resolution up to about double and maintain the framerate if ROM size permitted..bsnes source make it clear how $48xx worked and it was a hirom friendly chip so integrating it was no problem. Aslong as an emulator can play Star Ocean it should play this.

ZSNES doesn't work at all, it seems to look at the 8MB filesize and dismiss it instantly. snes9x works but I had to make it spool a byte more audio per frame or it crackled and looped incorrectly. bsnes works fine with the latest I just grabbed from byuu.org and a slightly older debugger. snes9x also seems to drift slightly with the audio sync but bsnes didn't, so I left that alone.

snes homebrew seems rather dead so here you go, I made a clunkier version before with a smw ad but it couldn't manage 60FPS without a bit of extra work on the source.

by tokumaru on 2009-11-24 (#52982)

Very cool! I would very much like to see a video of something that's not a game though (preferably ripped from a high quality source, not a VHS or YouTube). Are you taking requests? =)

by naI on 2009-11-24 (#52983)

That's amazing! Is this all uncompressed video?

Now you can amaze your friends when they see you 'playing' a Nintendo 64 game on a Super Nintendo.

by smkd on 2009-11-25 (#52985)

@tokumaru: yeah I can do requests, they're easy enough to throw together. Aslong as I can open the video properly in virtual dub (since adobe flash gave me hell with anything but flv files) then it's all good. Ofcourse if the source video is 30FPS or something then almost double the length is possible, 20FPS a bit under tripple etc. I'm not sure that with such low res that a YT vid will look all that bad, the reason I recorded the OP video myself is that they don't host 60FPS video.

@naI: It's all uncompressed pretty much, the code just splits a byte containing two 4bit pixels into two bytes, sends it to a mode7 tilemap after that. Mess around with the d-pad for generic effects, I didn't put anything fancy in though. haha yeah I'd like to throw it on a SNES cart if I could just for kicks, although realistically the only way that'd ever happen is if SNES powerpak had the MMC portion of the special chip, or there's a widely adopted method for getting ridiculously large ROMs that actually work in emulators + a real SNES that I don't know of.

I'd like to improve this but I'm not sure what to do. After all that optimizing, the processor sits on its ass doing nothing for nearly half a frame, but if I used that time for higher res video at larger frame rates I'd have like 30 seconds of playback lol.

by tokumaru on 2009-11-25 (#52987)

smkd wrote:
@tokumaru: yeah I can do requests, they're easy enough to throw together.

I imagine that real life stuff wouldn't look very good because of all the colors, there would be too much dithering that doesn't work very well in such a low resolution. Maybe you could try a cartoon or an anime, I guess that would work out well. For anime they usually use 24fps, so you could fit a lot more, maybe an entire opening. 60 fps is overkill IMO, only games run at that speed, all other sources should look good with 30 fps or even less.

Quote:
I'd like to improve this but I'm not sure what to do. After all that optimizing, the processor sits on its ass doing nothing for nearly half a frame, but if I used that time for higher res video at larger frame rates I'd have like 30 seconds of playback lol.

You could try adding some compression, nothing too sophisticated... Since you're not using any, even RLE should allow for a bit more video in there.

by MottZilla on 2009-11-25 (#52989)

That's a pretty impressive project. It would be interesting to see what else you can do with it.

by MatthewCallis on 2009-11-25 (#52995)

It'd be awesome to see what you could fit into a movie for the PowerPak, you'd have to undo the SDD-1 like the Star Ocean hack but it would be fun to see.

by smkd on 2009-11-25 (#52998)

@tokumaru: yeah a cartoon is a good idea, i just shuffled a bunch of things around and double buffer in the mode7 tilemap. Since the NES TMNT demo featured the song and I always liked that one, I did the intro video. 30FPS, with increased resolution I liked how it turned out. Might've looked better without the dither though, I don't know.

http://smkdan.eludevisibility.org/vidtmnt.zip

RLE would help, thing is the routine is very sensitive to anything you add to it. It's an unrolled loop repeated about 1800 times, add even a few cycles and its alot of extra effort. Even something simple like RLE has to be carefully put in or else performance goes to shit. Then again, at 20FPS or something, 2.5 full frame time is provided extra for all of this. Something is definitely workable here, there's just a ton of ways to do it. Will think it over, ofcourse if anyone has suggestions than go ahead.

I want to release the source but its pretty offensive to look at right now, just want to make it a little less ugly before uploading all of that.

Matthew: I read it has 16Mbytes of RAM but I wonder how its mapped to the SNES. Custom mappings would be neat, where you specify your imaginary PCB layout and it maps accordingly, definitely better than my S-DD1 hack.

by tokumaru on 2009-11-25 (#53001)

smkd wrote:
http://smkdan.eludevisibility.org/vidtmnt.zip

Coo! The sound is very good, and most of the times it's easy to tell what's going on in the video.

by MottZilla on 2009-11-25 (#53005)

Wow! The TMNT video turned out really well I think. Never thought I'd see and hear the TMNT intro on SNES (well BSNES actually).

by byuu on 2009-11-25 (#53008)

This has pretty much been a dream of mine for a long time. I loved your SMW commercial one, too.

I have many ideas to greatly improve upon this:

1. ROM size: I believe I cap the S-DD1 mapper at 8MB, but it would be trivial to allow up to 256MB ROMs. I'm happy to do this if you'd take advantage of it :)

2. Data size: since you are using the S-DD1 chip anyway, we can compress each video frame using the S-DD1 coprocessor, and you can stream DMA decompress that into video RAM. That should allow you to fit almost twice the amount of video data into the ROM, with no CPU overhead whatsoever.
Alternative: we may also be able to use the SPC7110's compression and MMC in the same way. Whichever works better, I suppose.

3. Use Mode 3: this will give you 256-color video, so you can make it look really sharp, and it's in tile format. This will make S-DD1 transfers possible via direct DMA, and you won't have to mess with interleaved tilemap stuff. Just set it up once and be done with it. Yes, this will "letterbox" the game, but I think it's okay. Better than overly pixellated with Mode 7.

4. Use PAL mode: this cuts the video rate from 60hz to 50hz, and greatly increases your Vblank time from lines 225-261 to 225-311.

5. Use video banking and halve the frame rate. Again, Mode 3 makes this possible. You can transfer half of the video frame on one frame, and the other half on the second. After the second frame, switch the VRAM base pointer between $0000 and $8000. There won't be any visible tearing by this method and you've doubled the video data you can transfer, eg doubled your possible output size.

6. Use part of the "active" display area. Another advantage to Mode 3 over Mode 7. Since the screen is letterboxed, you can take the height of your video, center it in the screen, and use HDMA to turn the screen off. For instance, if your height is 128, then turn the screen off from scanlines 0-63, and then from 192-311. Now you have even more time, and you can send even more video data.

7. Focus on widescreen instead of height. This will let you fit more video data since you have more scanlines with the screen turned off.

8. Again, use Mode 3. Create an RGB332 palette and store that into CGRAM one time. Now transcode your video to this format, and you no longer have to transfer any palette data ever.

9. If you do all of the above, and you get a really high quality video playing; I will work with you to take advantage of the 32KHz 16-bit PCM streaming via the SNES hardware's cartridge connector pins. I have already emulated these pins to allow Super Game Boy audio output to mix with the SNES' internal audio.
We can make a pseudo-special-chip that lets you stream raw PCM data (or ADPCM data) through these pins, giving you up to redbook quality audio, without requiring any CPU time. This will give us even more time to send more video data.

9a. I've also considered creating a pseudo-CD player base unit. Send the track commands to $21xx and it will start "streaming" via the base units' audio mixer pins the red book audio. The idea was for ROM hackers to then go and patch out song playback commands on the S-SMP to instead start playing from redbook tracks. This would allow a days' work to implement full orchestral soundtracks into existing SNES games like Chrono Trigger, Final Fantasy 6, etc. The same concept could be used here.

I'm very confident that we could push something like 192x144 video at 25fps in RGB332 with redbook audio in realtime.

Again, just let me know if you're interested in making it happen; and I'll do what I can to help :D

by magno on 2009-11-25 (#53009)

Astonishing post, byuu!! A incredible practical application of SNES modes and resources

BTW, what is "redbook"?

by byuu on 2009-11-25 (#53010)

Redbook is what CD audio tracks use.

Anyway, I did some proof calculations again: we can do 240x176x256color@25hz in real time.

240*176=42,240 bytes/frame

Scanlines are 1364 clocks long, and 40 are used by DRAM refresh. DMA eats 8 clocks per byte.

We double our bandwidth (and halve our framerate) using VRAM bank switching.

312-176=136

136*1324*2=360,128
360,128/8=45,016 bytes can be transferred per frame

We could push it farther, but I choose not to. That gives us 2,776 clocks to initiate the DMA transfers and swap the VRAM pointer every other frame. Similarly, we can reduce to 240x160 and gain a lot of additional clocks if we need more processing time.

Don't exceed 240 for the width, it will just be cut off by overscan anyway.

Now, bandwidth. I won't lie, it's massive.
At 42,240 bytes * 25 = 1,056,000 bytes per second. Let's round to 1MB/sec. We can cut that in half with the S-DD1, to reach 512KB/sec. That's roughly ~30MB/minute, so we'd have about eight minutes worth of TV-quality video at 256MB.

There are lots of options from here to increase that: utilize the SA-1 to compress data even more, fall back on 16-color mode (at which point we could easily do full 256x224 video), lower the output resolution, halve the framerate again to 12.5fps (really not that bad for animation), raise the mapper range to 512MB or even 1GB, detect "still" sections and omit their video data, detect "identical" frames (eg mouth moving is usually only two alternating frames) and re-use existing data, etc.

-----

This is about the quality we could expect, though perhaps a bit higher by using a better 24-bit -> 8-bit downsampler and a lossless source:

by tepples on 2009-11-25 (#53012)

smkd wrote:
Aslong as I can open the video properly in virtual dub (since adobe flash gave me hell with anything but flv files) then it's all good.

And if not, you can always use ffmpeg to convert things to a Huffyuv or Xvid AVI, which Vdub will have no problems opening.

byuu wrote:
Use PAL mode: this cuts the video rate from 60hz to 50hz, and greatly increases your Vblank time from lines 225-261 to 225-311.

But if you make something exclusively for the European market, don't you have to have English, Spanish, French, and German dubs?

240x160 could work. That's the much res GBA Video uses, but then GBA Video uses what would be a "special chip" (ARM7TDMI clocked at 16.8 MHz) compared to the Super NES.

by tokumaru on 2009-11-25 (#53013)

byuu wrote:
4. Use PAL mode

I thought I'd express my objection to this particular suggestion. I'm really against PAL-exclusive games/demos, because that excludes a huge deal of users.

by byuu on 2009-11-25 (#53017)

tokumaru wrote:
I thought I'd express my objection to this particular suggestion. I'm really against PAL-exclusive games/demos, because that excludes a huge deal of users.

This is only going to work in emulators anyway. How is PAL mode excluding you from using it in bsnes?

by tepples on 2009-11-25 (#53018)

If you'll make something that "only works in emulators", and it will need an emulated special chip, why not just emulate a TV tuner cartridge like that for the Game Gear or the GBA (or for that matter, a Game Boy Camera in a Super Game Boy) and then emulate a DVD player connected to it? You could make something like the Mega LD.

by tokumaru on 2009-11-25 (#53021)

byuu wrote:
This is only going to work in emulators anyway. How is PAL mode excluding you from using it in bsnes?

If all I wanted was to watch videos on my PC I'd go to YouTube watch some HD videos, not open an emulator and stare at low-color blocky images.

What interests me in this project is the potential of it. Maybe as it progresses and becomes more refined it will be feasible for real carts, even if it's for a small intro to a game or something. If that happens, I wouldn't like to be excluded from the group of people who can play that on their consoles.

by byuu on 2009-11-25 (#53023)

It's never going to be useful for real carts, they are too small. The current examples already need 8MB (using the S-DD1) and that covers absolutely no actual game content.

The best you'll ever see is maybe half of the TMNT video on a really small game.

Quote:
If you'll make something that "only works in emulators", and it will need an emulated special chip, why not just emulate a TV tuner cartridge like that for the Game Gear or the GBA (or for that matter, a Game Boy Camera in a Super Game Boy) and then emulate a DVD player connected to it?

Why not just port Chrono Trigger to the PC?

Because making a few very minor 2-line changes to enable something awesome that is theoretically within the limits of the real hardware is vastly more gratifying and useful than totally making things up.

A simple FPGA could easily support a 256MB mapper, and perhaps if a demoscene game were popular enough we'd see it one day. Now an entire DVD player? Probably not.

Anyway, whatever. If you want to cripple the video resolution by a good 60+ scanlines to make tokumaru's TV happy (and PAL TV people unhappy), you can do that too.

by tokumaru on 2009-11-25 (#53024)

tepples wrote:
If you'll make something that "only works in emulators", and it will need an emulated special chip, why not just emulate a TV tuner cartridge like that for the Game Gear or the GBA (or for that matter, a Game Boy Camera in a Super Game Boy) and then emulate a DVD player connected to it? You could make something like the Mega LD.

Are you suggesting someone implements a realtime video downsampler in their emulator? Seems like an awful lot of trouble for something so pointless. I bet that the coolness of playing your PlayStation games through your SNES emulator will wear off rather quickly.

by tokumaru on 2009-11-25 (#53025)

byuu wrote:
The best you'll ever see is maybe half of the TMNT video on a really small game.

I'd actually like that. Sonic 3D Blast on the Genesis/MD is 4MB, and it has a very interesting FMV intro. I don't know how much space it uses, but I guess there is a lot of it left for the game.

by byuu on 2009-11-25 (#53026)

To be quite honest, transcoding is the absolute wrong way to go for making video fit into existing SNES carts. Transcoding is a way to show existing, pre-made video. Eg it would be great for putting the opening FMV from Tales of Phantasia PSX into the SNES game, at a huge cost to file size.

What you should be doing is hand drawing the video to get it designed for low color, lossless form, and then relying on things like sprites to simulate mouth movements and clouds, and scroll registers for panning.

Take a look at the opening animation for Wonder Project J for a good example here :)

by tokumaru on 2009-11-25 (#53028)

byuu wrote:
Anyway, whatever. If you want to cripple the video resolution by a good 60+ scanlines to make tokumaru's TV happy (and PAL TV people unhappy), you can do that too.

Hey, this is not about me. I just think that excluding half the people that have the console is not a very "polite" (for the lack of a better word) thing for a developer to do. I know that sometimes it's hard to make both PAL and NTSC crowds happy, but as a game developer I think that's something everyone should aim for.

If smkd feels that this is just something to use in emulators, well, then so be it, but that would be throwing the potential of an engine like this in the garbage if you ask me.

by tepples on 2009-11-25 (#53029)

byuu wrote:
Take a look at the opening animation for Wonder Project J for a good example here

"Don't just watch the cricket, BE the cricket." I wonder if Disney had anything to do with Enix not bringing it over.

by byuu on 2009-11-25 (#53030)

tokumaru wrote:
Hey, this is not about me. I just think that excluding half the people that have the console is not a very "polite" (for the lack of a better word) thing for a developer to do.

Using NTSC would exclude half of the people using real hardware, too :P
But using PAL gives a lot more time to make a higher quality video with lower bandwidth requirements :D

by MatthewCallis on 2009-11-25 (#53031)

Am I just buying weird TVs?

Every TV I have bought in the last 6 years has been able to switch from PAL to NTSC and back with no user interaction.

by tokumaru on 2009-11-25 (#53034)

byuu wrote:
Using NTSC would exclude half of the people using real hardware, too

Not at all. AFAIK, if something works on NTSC it will probably work on PAL too, with minor or no modifications at all.

Quote:
But using PAL gives a lot more time to make a higher quality video with lower bandwidth requirements

I'm well aware of the benefits, but IMO a "SNES program" that only works on half of the consoles carrying that name and offers no possibility of being converted to work on the other half doesn't deserve that title.

MatthewCallis wrote:
Every TV I have bought in the last 6 years has been able to switch from PAL to NTSC and back with no user interaction.

Do your consoles from the 80's and 90's switch just as easily?

Guys, I hope I'm not comming off as some kind of ass about this... If people decide to make PAL-only (as in "heavily relies on characteristics of the PAL console that can't be simulated on an NTSC one") demos or games because they don't really care about real hardware or don't care about shutting half of their audience off, there is nothing I can do, it's their call. But it is my opinion as a developer that this is not a very nice thing thing to do, that's all.

by tepples on 2009-11-25 (#53037)

tokumaru wrote:
IMO a "SNES program" that only works on half of the consoles carrying that name and offers no possibility of being converted to work on the other half doesn't deserve that title.

Asterix for NES is not an NES game by your standards because it uses more than 21 lines of vblank time.

Quote:
If people decide to make PAL-only (as in "heavily relies on characteristics of the PAL console that can't be simulated on an NTSC one") demos or games because they don't really care about real hardware or don't care about shutting half of their audience off, there is nothing I can do

If a video playback engine provides 256x240 pixels on 50 Hz but 256x192 pixels on 60 Hz, that's fine; the size of the letterbox will be comparable.

by tokumaru on 2009-11-25 (#53040)

tepples wrote:
Asterix for NES is not an NES game by your standards because it uses more than 21 lines of vblank time.

Just because a game wasn't released for both types of consoles we can't say that the programmers haven't considered the other type during development. I didn't play much of that game, but there is a good portion of black at the bottom of the screen that could possibly be used for some extra blanking time, for example.

It might even be possible that a professional developer back then would make a game for just one type of console, but I think that is unlikely as I'm sure companies were interested in making profit from as many regions as they could, so I'm sure they were interested in keeping their options open.

But if you did actually find a game that couldn't possibly be converted to NTSC I would think it's unfair to call it a NES game.

Quote:
If a video playback engine provides 256x240 pixels on 50 Hz but 256x192 pixels on 60 Hz, that's fine; the size of the letterbox will be comparable.

See? You are thinking of a way to handle both consoles, this is nice.

by MottZilla on 2009-11-25 (#53042)

byuu wrote:
Now, bandwidth. I won't lie, it's massive.
At 42,240 bytes * 25 = 1,056,000 bytes per second. Let's round to 1MB/sec. We can cut that in half with the S-DD1, to reach 512KB/sec. That's roughly ~30MB/minute, so we'd have about eight minutes worth of TV-quality video at 256MB.

Well then all you need is to make a SNES CD addon that streams the data off the CD.

I'll be interested in anything that comes out of this. The BSNES CD player idea for adding CD quality sound to games sounds like a fun feature in general.

by tepples on 2009-11-25 (#53044)

MottZilla wrote:
Well then all you need is to make a SNES CD addon that streams the data off the CD.

If you do that, you'll probably end up putting so much processing power on the interface card between the Super NES and the CD-ROM drive that it can almost emulate the Super NES. The original PlayStation was born in exactly this way.

by MottZilla on 2009-11-25 (#53045)

A friend of mine was saying that it may be possible to interface the SNES with a CDROM without anything fancy and that if you could hook it up to B-Bus you could DMA from the CDROM's buffer into A-Bus very quickly. Ofcourse neither of us are electrical engineers.

Or do you mean that it would require something with alot of processing power to stream data to the SNES for the application of video playback?

by tepples on 2009-11-25 (#53047)

Both CompactFlash and CD-ROM drives are parallel ATA devices. PowerPak would need only a few changes to read ROMs from CDs:
support for ATAPI variant of ATA wire protocol
support for ISO 9660 file system
12 V and 5 V power for the drive motor

The Sega CD offered a bit of coprocessor power to make better use of those megabytes of data that were streaming off the disc. Nintendo wanted to incorporate some sort of coprocessor into the "Play Station" peripheral it was developing with Sony.

by smkd on 2009-11-26 (#53051)

cool, didn't expect this much discussion for this forum.

@byuu: Mode 3 would've been way easier to implement than what I showed in the TMNT demo, I just didn't like the savage ROM requirements since I wanted something to show that I could present with the resources currently available. The 256MB S-DD1 ROM idea sounds so out there, but it'd actually be pretty fun to mess around with. I'd definitely use it, and even though the audio doesn't take up as much space it'd help out there too. I assume you could just extend the mmc[] array in your S-DD1 code to not have the &3? I don't know what else you'd have to do to get a 256MB ROM loaded...

About the PAL vs NTSC issue, I really don't want to make anything tied to one format. Just personal preference, I mean if I buy another console to replace my busted one it'd definitely be an NTSC one, I never want to target PAL for homebrew, but I don't want to eliminate chances of compatibility with both. 240x176 in NTSC sounds good to me actually. It would be good for 20FPS anyway, but I might have to shave off a line or two to fit the palette upload, no big deal.

@tokumaru: I don't think this video (ones from myself anyway) have practical purpose in any games outside of novelty. Wouldn't it feel wierd having an 8MB ROM with a small intro video, and 300kb of actual game content? I say 300kb as en example because that's how much is vacant in the TMNT video. I don't think much can be done without special chips to make it fit practically in any game, even then it's a major stretch.

------

Speaking of the audio end of it, I would've liked to make all of this powered by just the spc + '816, no fantasy hardware or anything complicated added to it. I wanted to make something that if you were to give a snes oodles of ROM and a simple bank switching setup, nothing more than that, it'd work no problem. I want the original hardware to do most of the heavy lifting.

I currently use 22khz mono, I don't think 32khz stereo software driven is far from reach, the SPC routine I have already spends a decent amount of time waiting for the next 2 samples bytes (1 byte for control, 1 byte for audio which I don't need at all).

So there are roughly 64 spc cyles between scanlines over on the snes end, I only transfer every 2 lines. The SPC routine looks like this:

Code:
MainLoopX:
cmp x,$f6 ;wait for matching index
bne MainLoopX
inc x    ;protocol count++

mov a,$f4 ;get data byte #1
mov ($00)+y,a ;store to ARAM at appropriate spot
incw $00 ;increment entire 16bit pointer
mov a,$f5 ;get data byte #2
mov ($00)+y,a
incw $00

bbs0 $03,skip ;playback started? skip if so
mov a, $00 ;after 256 bytes uploaded, key on
bne skip

mov $03,#$01 ;set bit 0 of playback started flag, then key on ONE TIME ONLY

mov $f2,#$4c ;KON CH0
mov $f3,#$01
skip:
;cmp $00,#$00    ;once next byte pointed to is $C000, then the last address written was $BFFF
;bne UpdateVolume ;unecessary due to high byte changing immediately upon reaching the end
cmp $01,#$C0
bne UpdateVolume

mov a,$BFF7 ;read header byte of final block
or a,#$03 ;set loop/end
mov $BFF7,a

mov $00,#$00 ;reset pointer back to $3000 for another bunch of blocks
mov $01,#$30

jmp MainLoopX

UpdateVolume:    ;help balance the load between cases
mov $f2,#$0c ;update mvoll
mov a,$f7
mov $f3,a

mov $f2,#$1c ;mvolr
mov $f3,a

jmp MainLoopX

it's very generic and the bbs0 could be removed just by having another routine that operates without that check. It's not pressed for time or anything though so I left it as is. It works every 2 scanlines for 2 bytes.

If I were to make something resembling this:

Code:
;$F7 is for sync (A only) sometimes and the rest are for data
;$00 and $02 point to two samples that are 9 * 8 * 256 bytes large ($4800 each)
;assuming $6000 and $A800

;(3 bytes)
ScanlineA:
cmp x,$f7 ;wait for matching index
bne MainLoopX
inc x

mov a,$f4 ;data byte #1
mov ($00)+y,a
inc y    ;saves 4 cycles over incw $00, no page boundary cross checking required as long as it's incremented by power of two between checks
mov a,$f5 ;data byte #2
mov ($02)+y,a
inc y
mov a,$f6 ;data byte #3
mov ($00)+y,a
inc y    ;43 cycles passed since the CMP loop

;need to stall for time a little bit so may aswell throw this check in here
bbs0 $04,wait ;playback not yet started?
bbc0 $01,wait ;256 bytes have already been buffered?
mov $f2,#$4c ;KON CH0/CH1
mov $f3,#$03
mov $04,#$01 ;only do this once
jmp ScanlineB ;71 cycles elapsed including this jump
wait:
push a    ;waste 20 cycles before allowing further stuff (68 altogether, including 5 cycle branch taken bbs0)
pop a
push a
pop a
push a
pop a
nop

;(4 bytes)
ScanlineB:
mov a,$f4 ;data byte #4
mov ($02)+y,a
inc y
mov a,$f5 ;data byte #5
mov ($00)+y,a
inc y
mov a,$f6 ;data byte #6
mov ($02)+y,a
inc y
mov a,$f7 ;data byte #7
mov ($00)+y,a
inc y    ;48 cycles for this block

;*insert meaningful activity here*
push a    ;18 cycles + 48 = 66
pop a
push a
pop a
nop

;scanline C (1 byte):
ScanlineC:
mov a,$f4 ;data byte #8, $f7 now contains the next control byte for next iteration
mov ($02)+y,a
inc y
bne ScanlineA ;no page crossing means just loop again

inc $01 ;advance page pointers and check if the end is reached
inc $03
cmp $01,#$A8 ;once high byte of first sample points to the start of the second, it has reached the end (for both)
bne ScanlineA

mov a,$A7F7 ;final header first sample..
or a,#$03
mov $A7F7,a
mov a,$EFF7 ;likewise second sample
or a,#$03
mov a,$EFF7
jmp ScanlineA ;52 cycles after this block

Not tested or used or anything. Over 3 scanlines, it will accept 8 bytes of data. 8 bytes so I only need to test for Y crossing page boundary at the end of all of this.

224 / 3 * 8 = 592 bytes a frame after rounding, which is 8 (or 2.6) short of the 600 I need for 64000 samples a sec. Don't really care, I'll make it JUST a tad lower in rate and you won't tell the difference. Ofcourse there is overscan but meh.

My current 22khz mono code takes 10-11 scanlines per frame, trippling gives 33 which is still plenty of time for any videos to run. With the cycle counting and everything I'll probably destroy and shreds of compatibility this ever had with zsnes/snes9x but I don't care. I'll be debugging this with simulatneous spc+cpu trace logs in bsnes anyway.

I don't modify volume in the new routine I just posted, I can just assume max volume until the end where the snes just starts feeding it silence.

------

also byuu since you sound interested with videos and all of that, have you made any of these before? This must all be small potatoes to you so I assume you've done it many times over.

Also, I don't feel like touching anything related to the S-DD1 compression because I feel it'd be really challenging trying to make a compressor for something that obscure. It would help massively though...Regardless, a 128mbit powerpak with potential MMC support would be my ideal target cartridge, except I don't own one or a NTSC SNES, or a SNES that actually functions.

edit: I realise there's tons of issues with the spc code I posted although I don't want anyone to go out of their way to fix something I already covered, disregard the horrors in that snippet.

by smkd on 2009-11-26 (#53059)

splitting this up because I don't want to add to an already huge post.

new rom to demonstrate the 32khz stereo idea. Got the cycle counts right, also destroyed snes9x compatibility, awesome. thank god for bsnes or I'd have nothing to test my screwy roms on. Unfortunately, it needs S-DD1 again. The interleaved brr file with both tracks is like 7.6MB, so I still don't have something I can just slap into a powerpak and play on the real deal. If I could like hear/see a snes playing this that'd be sweet but it looks like that's not happening for some time.

Random stuff:
-needed to make the uploader use fixed point for uploads per frame, the DSP pointer and SPC pointer kept colliding without.
-overscan was the difference between 31750hz and 32000hz, since I'm not playing video, why not?
-the code which handles this is unoptimized, but it won't be much trouble getting it going alot faster.

Just happy to have 32khz stereo streams running smoothly through software entirely. For 1989 it's a great combination of chips. It's not CD-quality byuu but I still like what I hear. Also sorry about the song of choice, it's the only CD quality source material I have around at the moment.

by byuu on 2009-11-26 (#53063)

Quote:
I assume you could just extend the mmc[] array in your S-DD1 code to not have the &3?

Yes, exactly. When I have a WIP ready, I'll message you on my forum about it.
Would probably be tomorrow afternoon or so.

Quote:
240x176 in NTSC sounds good to me actually. It would be good for 20FPS anyway, but I might have to shave off a line or two to fit the palette upload, no big deal.

Maybe. Let's see. Need 42,240. 86*1324*3/8=42,699.
You're cutting it way too close, as you still need to transfer audio data and set up all the DMAs and such. Go for 240x160@20Hz NTSC.
Need 38,400. 102*1324*3/8=50,643.

Also, you don't need to transfer a palette if you use RGB332. But if it looks better with a custom 256-color palette, then that works I suppose. Maybe try 240x144?

Quote:
also byuu since you sound interested with videos and all of that, have you made any of these before? This must all be small potatoes to you so I assume you've done it many times over.

No, I've never had a good, lossless, decompressed video feed necessary to make it happen. I just knew it was possible was all.

Quote:
Also, I don't feel like touching anything related to the S-DD1 compression because I feel it'd be really challenging trying to make a compressor for something that obscure. It would help massively though...

Andreas Naive already made one. I believe RHDN cached it, too.
It works great. I used it when I was trying to figure out why a bug in DF's Star Ocean allowed it to work in ZSNES but not other emulators. Turned out to be a bug in ZSNES and a misunderstanding of how the chip worked that allowed it to work on real hardware. Fun.
Anyway, it's pretty easy. neviksti also has compressors for the SPC7110.

Quote:
For 1989 it's a great combination of chips. It's not CD-quality byuu but I still like what I hear.

Yes, it's exceptionally good quality. I'm amazed the SNES can sound that good, actually. The problem is that you have no time left for displaying video now ;)

---

If I could make a request for the 256MB video, do you think you could try the Lunar: Silver Star Story opening? :D
http://www.rpgamer.com/games/lunar/lsss/lsssmov.html
(Japanese version, please. Higher quality and no caption-overs)
(need IV41 - Intel Indeo Video 4.1 codec for that particular file)
(lower quality: http://www.youtube.com/watch?v=OahHMRT4n3c)

If not, no big deal. But I would love to show off a ROM like that to others :D

by smkd on 2009-11-26 (#53101)

I had no clue about the pre-existing compressor, I grabbed mingw and it worked great. I compressed a random ASCII file and tried the following:

Code:
PHP
REP #$10
SEP #$20

LDX #$F000 ;last chunk of ram
STX $2181
LDA #$01
STA $2183

LDA #$01 ;enable the chip itself
STA $4800

LDA #$08 ;one reg no inc
STA $4300
LDA #$80 ;$2180
STA $4301
LDX.w #testfile
STX $4302
LDA.b #testfile>>16
STA $4304
LDX #$0100
STX $4305

LDA #$01 ;CH0
STA $4801
PHA    ;same timewaster star ocean uses
PLA
STA $420B
STZ $4800

PLP
RTS

works great, having the chip moitor reads to $43x0 makes it real inuitive to implement. I assume after the few cycles the push/pop burns it's ready to stream, however much you want.

It looks like it starts preparing decopressed data depending on what it internally has in its 43x2-43x4 mirror after a write to $4801, I guess if I reserve one channel and set the address ONCE at reset, then I could do DMA for constant sized blocks of data, and the chip would automatically advance its own internal pointer depending on the variable sized compressed data. But then I wouldn't know when to switch banks because I can't see the address it stores, unless I missed something in your source. Seems I have to set the source address manually when crossing banks but that's cool.

I still have to remake the batch converter thing I have here to output mode3 stuff, but the plan as of now is something like:

-modify andreas' compressor to take command line arguments, no problem
-have my converter program detect where the compressed stream crosses a 1MB bank and then store these values to some table in ROM. The frame counter would be compared to the next bank cross frame # coming up and once there's a crossing, $4806 and $4807 source values in RAM get incremented. Would also store an offset into the new bank based on the compressed piece of data that crossed over. Like if the final piece of bank data 'overflowed' the current 1MB bank by $60 bytes (last byte read was $F0:005F), it'll access from $E0:0060 from the next frame. $The E0 and F0 banks in my ROMs are where the swtiching occurs.
-make the 32khz streamer less shit in performance department.

i'm still using overscan but I'd shut off the screen just as early as I would without.

---

Also, I couldn't get the high quality video opening here a tall, I download Iv5play.exe or whatever it was that installs Indeo Video 4,5 and whatever else. No luck in media player or virtual dub, irfan view is the only thing here the plays it, although it refuses to extract bitmaps because 'it can't find the video data' despite the fact it has no problems playing it?

Unless I could get that high quality one into a workable format (for myself, I don't know why it won't play even with codecs installed). I will use the youtube one since I had no problem working with that.

edit: forgot to post, youtube audio since SPC end doesn't stand to change at the moment: here, while I don't care for any of that its still better listening than the other demo for sure

by tepples on 2009-11-27 (#53113)

If VLC media player can play it, ffmpeg can convert it.

by byuu on 2009-11-27 (#53135)

Aw, well hopefully ffmpeg works. Would be a shame to store the video in a lossless format after Youtube mangled it :(

As a last resort, http://www.rpgdreamers.com/rpgmovie/lunar.wmv
That's the English version and it has some overlay bullshit from their website, plus the ear bleeding US vocals. But since we have the JP vocals, with a little video clipping on the first few frames it could potentially work. Subtitles are probably better than Youtube quality ...

And yeah, crossing a bank boundary is fine for the S-DD1, but obviously you have to have the right banks mapped in via 4804-4807.

Anyway, thanks a million for making the Lunar version for me. Going to be absolutely amazing to finally show off what the SNES is really capable of :D

Going out to get dinner now, when I get back in a few hours I'll start on the 256MB S-DD1 mode. Need to get rewind up and working too, so tomorrow morning at the latest. I'll make it public so everyone here can try it out.

by byuu on 2009-11-27 (#53164)

Okay, this is public so that NESdev people can try it out. Please don't go seeding it everywhere. Get it now if you want it, though. May be gone after the next WIP is out.

You need the Qt DLLs from the official release, and it also lacks profiling, so it's about 15% slower than official releases.

But it allows up to 256MB for S-DD1 games, and 257MB for SPC7110 games (the MMC doesn't index the 1MB program ROM chip.)

http://byuu.org/temp/bsnes_v057_wip02.tar.bz2

Also, mplayer seems to want ir41_32.dll for IV41 playback, and FFmpeg can supposedly go through avisynth if needed.

by smkd on 2009-11-28 (#53176)

The IV41 bullshit is resolved, though I had to use an old XP machine to get irfanview to do a BMP extraction. VLC crashed, although I know where to go if I need more IV41 vids dumped. The mov is 15FPS though, you sure you want that? I didn't realise it sucked that bad until I saw I needed to throttle playback (at only 20hz too) before it timed correctly against a youtube playing in parallel. The youtube has more FPS although it probably has worse artefacts or whatever.

The garbage on the sides I'll kill with windowing or something, the odd rows of pixels on the bottom must just be me getting the scroll wrong / shutting off screen too late. That pic is from the mov, no "floyd steinberg" dither when chopped down to 256 PNG files and converted. If you can suggest a conversion setting to make it look better than great. The 64MB ROM works fine with the bsnes you posted. Not using compression yet because I don't even have the base player working 100%, have to do overlapping transfers and two tilemaps to fit a 38KB screen pair in there, or atleast that's the approach I'm going for at the moment.

by byuu on 2009-11-28 (#53195)

Oh wow, the screenshot looks even better than I imagined!

Really, it's only 15fps? Damn. I'll leave it to you then, does it look better at 15fps HQ or 20fps LQ? Or maybe the WMV is a little better? :(

I even have the Sega Saturn MPEG version of Lunar, but I have no idea how to extract the movie from it. Need to find someone with the PSX version, there's 82 billion movie extractors for that system.

Quote:
have to do overlapping transfers and two tilemaps

Why do you need to send any tilemaps? Just set it to a linear 0-599 range once at poweron, and then transfer the video like that each frame. Leave the tilemap at $f000+, and tiledata at $000-efff. Or is your code optimizing out repeating tiles?

Quote:
The 64MB ROM works fine with the bsnes you posted.

Hahah, awesome. The world is either going to love us or hate us for this :D

by tokumaru on 2009-11-28 (#53198)

I just wanted to comment that Saturn and PSX videos usually didn't have much quality to begin with.

Most Saturn videos I've seen had very little color resolution and were very mean to gradients, in addition to being very wiggly. PSX videos usually have severe JPG artifacts, and pretty bad color resolution too. And most of the videos from either system ran at 15 fps.

I know that the SNES has it's own limitations, but when they are combined with pre-existing issues the final result suffers. Look at the yellow collar the guy in the screenshot has. When it meets the sky you can see some very bad blocking. The original codec has poor color resolution, and this becomes apparent when it tries to represent two opposing colors (blue and yellow) next to each other. Red is another color that usually suffers because of this (look at how the red in his chest bleeds).

Based on this, I believe that whatever result you achieve from this particular video will be sub optimum. Unless there is a better source for it than the actual game it's from. I've seen Saturn and PSX videos re-released in better quality as extras in PS2 games and things like that.

by byuu on 2009-11-28 (#53200)

Hmm actually, let's go with this one, then:
http://fmv.thehylia.com/lunar-silver-star-story
12.6MB in DivX format, it's supposedly a direct rip from the PSX version. The JP audio should sync over it just fine. If it ends up being 15fps, I guess that's okay. More time for the audio and such, and a smaller resultant file size. I think this video looks just fine when played back on my PC.

And yes, unfortunately using any lossy video source is going to give sub-optimal results. The only benefit is that the S-DD1 can most likely take advantage of some of the artifact crushing to compress better. But if we really want to show off, we need a lossless source video. Or maybe second best, with a Blu-ray anime/cartoon opening or something.

Thanks again for making this, I really really appreciate it :D

by Bregalad on 2009-11-28 (#53201)

Well, I gues it's possible to make your own vids with blender, altough I myself don't know how to use it yet.

by tepples on 2009-11-28 (#53220)

byuu wrote:
The only benefit is that the S-DD1 can most likely take advantage of some of the artifact crushing to compress better. But if we really want to show off, we need a lossless source video. Or maybe second best, with a Blu-ray anime/cartoon opening or something.

Or just take some random YouTube Poop video of Adventures of Sonic the Hedgehog. YouTube's HQ mode uses H.264 codec, which has much less noticeable artifacts than the Cinepak/MJPEG codecs of the CD-ROM based consoles.

Another idea: Instead of using 256-color tiles, encode each frame with eight different 15-color palettes. See Quither to learn what's possible.

by smkd on 2009-11-29 (#53248)

I worded the thing about tilemaps badly, I do send them at reset and not at any other time. $F600+ is where they sit and yscroll gets alternated.

haha I'd put artefacted anime videos way above any youtube poop =). I think DKC series used the 16 palettes and 4bpp tiles to get its very colourful overworld images drawn, it looked pretty decent. If there was any pressure to cut down on ROM size it'd be alot more appealing.

I have a video ROM here but it has some issues:
-I still haven't made the audio code less shit, although there's no pressure in terms of frame time
-no compression, I just wanted to get something working before involving all of that. It won't be hard to add it into the current source.
-it uses the frames from the mov, not the divx you just posted there. You want the video to have the entire intro from the divx, with the JP audio delayed until it syncs with the JP vid? I mean, should there be silence for the first few moments?

Matthew if you don't want me putting these on your server just say so, I don't mind uploading big videos even with the horrors of *Australian Internet* but I don't know about you.

7zip 'ultra' compression got the video down to 43MB, I wonder how the S-DD1 will measure up to that.

by byuu on 2009-11-29 (#53257)

Wooooooooooooow!! Looking absolutely amazing so far!! :O
You're absolutely amazing, thank you so much.

Quote:
-I still haven't made the audio code less shit, although there's no pressure in terms of frame time

Sounds really good so far to me at least :)
But yeah, may as well show off the full power of the system since we have plenty of extra time at these frame rates.

Quote:
-it uses the frames from the mov, not the divx you just posted there. You want the video to have the entire intro from the divx, with the JP audio delayed until it syncs with the JP vid? I mean, should there be silence for the first few moments?

Yes, that should be fine. The 15fps actually does look a little choppy, so hopefully 20fps will be a marked improvement, but we'll see :D

Quote:
Matthew if you don't want me putting these on your server just say so, I don't mind uploading big videos even with the horrors of *Australian Internet* but I don't know about you.

Indeed, I'd love to link to this on my site if at all possible, but I know Derrick would have a coronary when he saw the bandwidth logs >_<

Quote:
7zip 'ultra' compression got the video down to 43MB, I wonder how the S-DD1 will measure up to that.

Given the way compression works, I'm sure the SFC file will be smaller, but once compressed with 7-zip, that file will likely be even bigger. S-DD1 is nowhere near as good as 7-zip, even though it's optimized for tiledata. Once it's applied, 7-zip won't be able to find patterns anymore.

I still think it's worth using. Smaller ROMs load in emulators faster, and it looks more impressive from a technical standpoint. Either way though, it looks like we have plenty of space left.

by tomaitheous on 2009-11-29 (#53264)

tepples wrote:
byuu wrote:
Another idea: Instead of using 256-color tiles, encode each frame with eight different 15-color palettes. See Quither to learn what's possible.

You can also interlace (not to be confused with an interlaced TV output) the tilemap with HDMA to break the 15 colors per tile limit. This'll add a little overhead for uploading more palette associations for multiple tilemaps, but the trade off is worth it. You can do palette association for 8x4, or 8x2 , etc pseudo tiles. 4bit tiles are half the bandwidth for transferring to vram, half the storage space too in rom too.

Side note: I couldn't get that last rom to work in bsnes Shows about second or so of video, then shows junk onscreen.

by byuu on 2009-11-29 (#53265)

You need wip02, posted in this thread. It extends ROM support to 256MB.
I was able to play the entire video.

by smkd on 2009-11-29 (#53266)

I'll work in the compression soon. the DivX one has much better quality, there's so much less artefacting although it stutters just the same. I made it drop frames to fit the 30hz->20hz conversion (in my batch converter not the SNES code) but it is just as fluid as the mov. It stutters in media players too, there's no smoothness, take any section with scrolling and its so apparent. Then I see the low quality youtube one posted earlier and it's so smooth. The part where they scroll through all those characters stutters pretty badly in every movie file I've seen except the youtube, but ofcourse the youtube one has extremely shit quality at the same time. What a tease haha.

edit:
Quote:
But yeah, may as well show off the full power of the system since we have plenty of extra time at these frame rates.

Any suggestions on what to do? Time with the screen disabled is limited though, thanks to having to double buffer a pair of 38KB frames with less than 64KB of VRAM. If missed something just say so, was late when I actually made the thing work. There's plenty of nothing happening during the active display time, the audio code runs, the pointer setup code runs, then it does nothing for quite a while.

by byuu on 2009-11-29 (#53267)

Oh, this is absolutely maddening. The chance of a lifetime and I can't find a good quality version :(

I even have the Sega Saturn MPEG version but no way to rip it (SSF doesn't emulate the MPEG card, so even screen capture is out, as if I had a way to upload such a large file.)

How about this one? This is the Saturn MPEG version on Youtube as a high quality version: http://www.youtube.com/watch?v=aDOE8GUlIAA&fmt=18

And this one at least appears smooth for that one scene, but is lower quality: http://www.youtube.com/watch?v=flDD6xRbuKo

Does anyone know where to get a higher quality version of this video?

Bleh. I give up :(
Whatever works best in your opinion, I'm just happy to see it done, and I'm already floored by the previous version you posted.

Quote:
I'll work in the compression soon.

By all means, no hurry here.

Quote:
Any suggestions on what to do?

If you already have 32KHz stereo output, not sure. Maybe push for 30fps? :P
Bandwidth calculations tell me it's not possible though. Plus our sources for this particular video are too low framerate. It'd be a waste.

You may want to show off the power better by picking a video you like that we have in actual high quality, 60fps action. It would also be fun to utilize all 256MB, which would mean using a really long video and sending Matthew several thank you cards in the mail in advance :)

by Bregalad on 2009-11-30 (#53268)

To be honnest 20FPS is ok for vids (as long as they are made with motion blur). Even 15FPS is decent (don't forget that movies were originally 18FPS). The reason anything below 50-60FPS looks choppy for games is that there is no motion blur.

by tokumaru on 2009-11-30 (#53269)

15 fps will look fine if it's properly downsampled from a smoother original (which might include motion blur), something that videos from Saturn and PSX games were not.

You can see that that opening sequence was made by a professional animation studio, probably at 24 fps because that's what anime usually is. Then the software company just chopped it down to 15 fps without much care, this is why it looks choppy.

This is usually true for any Saturn/PSX game that has anime sequences at 15 fps.

by tokumaru on 2009-11-30 (#53270)

byuu wrote:
How about this one? This is the Saturn MPEG version on Youtube as a high quality version: http://www.youtube.com/watch?v=aDOE8GUlIAA&fmt=18

Wow, this is much better than the previous versions. If cropped properly to be full screen (should be easy with VirtualDub) it might end up looking pretty good.

Quote:
And this one at least appears smooth for that one scene, but is lower quality: http://www.youtube.com/watch?v=flDD6xRbuKo

This appears to have gone through a video filter to make it smoother (a filter that VirtualDub has), but it looks a bit overdone. If it's applied not so heavily on the video above it might make it a bit better.

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.

by smkd on 2009-11-30 (#53272)

Is anyone here good enough with video editing to turn one of those into something tolerable when played at 20hz?

edit: for the time being, I am using the DivX video. It definitely has alot less artefacts than the mov one and is a bit smoother. I had to use dithering in irfan view because otherwise the color banding was absolutely fucking killer, although I think it looks prettier than the 64MB one I uploaded.

I only recently modified andreas compressor to work when my batch converter invokes it. I'll feed it compressed streams whenever it crosses a 1MB bank boundary, since you said S-DD1 can read properly between 64KB boundaries right? Even 1MB boundaries? After crossing a 1MB bank of data, it'll reconfigure $4806 and $4807, setup another DMA source address, then keep doing fixed address reads from said address. Should be just fine if my knowledge of the chip is in check. Will probably get a start tomorrow.

edit2: I should've posted the divx example ROM. Out of sync audio and unecessary bits at the start, but you can atleast watch for the quality, let me know what you think. There are glitches on the sides of the borders with very bright colors in view but that's just because I wrote the wrong value to $2131 and I don't feel like uploading another 80MB ROM just for that =)

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

by byuu on 2009-11-30 (#53277)

Quote:
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.

I'd say to use PAL at 25fps, but I know we want NTSC, so we'd probably want to do a 6:5 pulldown and output at 20fps.

And my sentiments echoed, I'd be hugely appreciative if anyone here could clean up the video for streaming smoothly. I'll be happy to commission this if it's a lot of trouble.

Quote:
edit: for the time being, I am using the DivX video.

You sure? It's the JP version with the intro I only saw in the HQ Saturn MPEG rip on Youtube. Regardless, what you're using now is stunningly brilliant, and I love that it lacks the Working Designs captions.

Quote:
Out of sync audio and unecessary bits at the start, but you can atleast watch for the quality, let me know what you think.

Wow, major major improvement to quality indeed. Really the only place I even notice an issue is that left-to-right panning scene. I'm honestly very happy with the file as-is. And in fact, I almost don't mind keeping that short Game Arts intro, it's kind of funny and makes it look like the actual Saturn game :D

I'd say if its no trouble to just pad empty audio onto the start of the PCM stream, or just mirror the video's audio source. Whatever's best.

This is just gorgeous, it really shows off that the SNES really can be a first-class citizen even in terms of full motion video and near-CD-quality audio. Its biggest caveat was the extremely expensive (at the time) ROM data.

Thanks to this example ROM, perhaps we can encourage one of the flash cart makers to support such a mapper; or at least get some demo coders to create enhancements like this for existing games.

by tepples on 2009-11-30 (#53278)

tomaitheous wrote:
You can do palette association for 8x4, or 8x2 , etc pseudo tiles. 4bit tiles are half the bandwidth for transferring to vram, half the storage space too in rom too.

But a single 8x8 pixel tile takes the same amount of space as a palette, so it might not be a gain to try rewriting all eight background palettes all the time.

by byuu on 2009-11-30 (#53281)

Here's a screen grab of the new video for those who don't want to download it+bsnes:
http://img228.imageshack.us/img228/9104/videoj.png

smkd wrote:
I'll feed it compressed streams whenever it crosses a 1MB bank boundary, since you said S-DD1 can read properly between 64KB boundaries right? Even 1MB boundaries?

It can definitely cross 64KB boundaries. To be sure, I modified the emulator to log transfers. If the real game does it, you can be confident that you can too. And it does:

Code:
printf("* S-DD1: %.6x : %.4x [%u]\n", addr, buffer.size, (addr & 0xff0000) != ((addr + buffer.size) & 0xff0000));
sdd1emu.decompress(addr, buffer.size, buffer.data);

Code:
* S-DD1: ffd0ab : 0824 [0]
* S-DD1: fed27f : 1800 [0]
* S-DD1: de84ac : 0300 [0]
* S-DD1: de9af5 : 0380 [0]
* S-DD1: d4f159 : 8000 [1]
* S-DD1: daf458 : 1c00 [1]
* S-DD1: dbe8ed : 0800 [0]
* S-DD1: dce0e8 : 1080 [0]
* S-DD1: ddc615 : 04e0 [0]

Just from the start, it crosses a 64KB boundary fairly quickly.

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.

I can't 100% verify it since the two S-DD1 games out there don't actually transfer across a 1MB boundary. Given that you have to change banks anyway, you may as well play it safe and assume the chip can only transfer within the current 1MB mapped block.

You probably already have code to detect bank crossing that splits the DMA into two partial transfers, so it shouldn't require any changes unless you're mapping 4MB at a time and streaming to the end. In that case, modify it to only use MMC3:$f00000-$ffffff and we'll be certain the hardware was capable of that.

Now unfortunately, I strongly doubt the real S-DD1 and SPC7110 were capable of accessing more than 6/8MB for the S-DD1 and 1MB+4MB for the SPC7110. Doing so would've required more address bus pins, which would be a pointless expense just to tie them all to ground.

I don't think it violates the spirit of the chips though to simply extend their addressable range. This is very different from making up an MMC + PCM streaming device from scratch.

by tomaitheous on 2009-11-30 (#53283)

tepples wrote:
tomaitheous wrote:
You can do palette association for 8x4, or 8x2 , etc pseudo tiles. 4bit tiles are half the bandwidth for transferring to vram, half the storage space too in rom too.

But a single 8x8 pixel tile takes the same amount of space as a palette, so it might not be a gain to try rewriting all eight background palettes all the time.

I'm not sure I follow you. A single 8x8 4bit tiles takes 32bytes. A single tilemap entry takes 2 bytes. If he uses 4 tilemaps for an 8x2 pseudo tile, that an extra 6bytes on top of the normal 8x8 and tilemap, per 8x8 area. 38bytes per 8x8 < 64bytes of 8x8 8bit tile. And if I'm not mistaken, he's already updating the 256 color palette of 8bit tile mode on every frame (unless he's using direct 332 RGB mode). Wouldn't be updating 8 subpalettes be even smaller than updating an 8bit palette? (not that it's a large amount to begin with in comparison with all the tiles being updated).

by tepples on 2009-11-30 (#53284)

byuu wrote:
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:
DPCM playback wraps from $FFFF to $8000, not $C000 or $0000.
The sweep unit on the square wave channels will silence the sound even if sweep is turned off.
CPU I/O registers $4000-$4017 are fully decoded yet they overlap $4000 rather than the superfluous mirrors of PPU address space ($2008-$3FFF).
PAL NES CPU clock divides by 16 instead of 15.
Spurious fetches of nametable data in hblank between sprite pattern fetches instead of adding eight more sprite shift registers.
Quote:
In that case, modify it to only use MMC3

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

Quote:
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.

tomaitheous wrote:
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).

by HJRodrigo on 2009-11-30 (#53285)

tokumaru wrote:

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.

by smkd on 2009-11-30 (#53295)

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:
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:
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.

by byuu on 2009-12-01 (#53296)

Quote:
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.

Quote:
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.

Quote:
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 =)

by Masterflow on 2009-12-01 (#53298)

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

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

by smkd on 2009-12-01 (#53300)

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:
compress(0, in_len, in_buf, out_len, out_buf);

01 header compression: 59.3MB?
Code:
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.

by nintendo2600 on 2009-12-01 (#53301)

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.

by byuu on 2009-12-01 (#53304)

Quote:
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

Quote:
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

Quote:
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.

by MottZilla on 2009-12-01 (#53305)

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.

by Bregalad on 2009-12-01 (#53306)

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.

by byuu on 2009-12-01 (#53307)

Quote:
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.

Quote:
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

by Bregalad on 2009-12-01 (#53309)

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

by MottZilla on 2009-12-01 (#53319)

byuu wrote:
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.

by naI on 2009-12-01 (#53324)

byuu wrote:
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?

by smkd on 2009-12-01 (#53325)

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.

by byuu on 2009-12-01 (#53327)

Quote:
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.

Quote:
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.

Quote:
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.

by tepples on 2009-12-01 (#53328)

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

What makes ISO 9660 that much simpler than FAT?

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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.

by Memblers on 2009-12-01 (#53331)

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..

by byuu on 2009-12-01 (#53334)

Quote:
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.

Quote:
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.

Quote:
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.

by MottZilla on 2009-12-01 (#53337)

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.

by byuu on 2009-12-01 (#53341)

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.

by creaothceann on 2009-12-02 (#53346)

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.

by smkd on 2009-12-02 (#53349)

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.

by smkd on 2009-12-02 (#53376)

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..

by byuu on 2009-12-03 (#53380)

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.

by mic_ on 2009-12-03 (#53381)

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

by MottZilla on 2009-12-03 (#53407)

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

by smkd on 2009-12-04 (#53474)

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.

by byuu on 2009-12-04 (#53482)

Quote:
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?

Quote:
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.

by tepples on 2009-12-04 (#53487)

byuu wrote:
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?

Quote:
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.

Quote:
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.

Quote:
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.

by byuu on 2009-12-04 (#53490)

For reference, NTSC aspect correction is roughly 1.148936:1. Varies per TV and all that. With that in mind, here's some aspect ratios for input video:

184x160 = 1.31875:1 (closest to 4:3 = 1.333)
224x160 = 1.60625:1 (closest to 16:10 = 1.600)
248x160 = 1.78125:1 (closest to 16:9 = 1.777)

And of course you can cut off individual pixels to get it even closer, but you're still using the same tile sizes.

tepples wrote:
Will you be able to fit 90 minutes of footage on a CD like Night Trap did?

I can easily fit that on a DVD for an extra few pennies a copy. Otherwise no, I'd have to add a video codec.

tepples wrote:
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.

And nothing's stopping you from making more 90-second Mode 7 128x64 videos while the rest of us make awesome improvements to existing classics and potentially even entirely new software titles that should hopefully be possible on the real thing (and cheap to produce) as soon as we can find a willing hardware dev :)

by johannesmutlu on 2011-03-16 (#75508)

it sounds cool to run a video on snes,too bad since the powerpak has not more then 16mB rom/ram and also lacks the sdd1 chip,i can never run it on the powerpak.
i wish they had put 4 gb rom/ram inside since it also accepts cf flashcards up to 4 gb,
i wish they also had put the sdd1 chip inside to increase amount data.
but now it will be quit challanging to fit a video into 16mB,or splitting it into sections of 16mB and play one after another section etc,,,

by 3gengames on 2011-03-16 (#75526)

You could run it on the SNES powerpak, but it'd be as slow as crap.You use the ROM to buffer and just read it from the flash card. You don't need a RAM for the size of the flash card you have to support. >.< I really agree with the this guy is a bot thing.....or he's trying to troll just by playing smart/dumb.

by tepples on 2011-03-16 (#75528)

Apart from the lack of capital letters, I was almost that dumb when I first joined NESdev, back when it was on ONElist. For those playing at home:
NESdev was started as a mailing list on ONElist.
eGroups bought ONElist.
In mid-2000, Yahoo! bought eGroups.
A WWWThreads board opened up here in the fourth quarter of 2000.
In the fourth quarter of 2004, WWWThreads was shut down in favor of the phpBB 2 instance that we use to this day.

by KungFuFurby on 2011-03-19 (#75613)

You really impressed me with these videos... I didn't think someone would go for it. ^_^