Finally on MSU1: Chrono Trigger with anime intro ;-)

Hi there!

This re-implements smkdan's Chrono Trigger anime intro hack made back in 2011 for the "21fx", a SNES multimedia add-on which is known as the MSU1 nowadays. I created this by disassembling smkdan's work (the sourcecode of which apparently got lost over the years) and making it compatible with the latest MSU1 specifications.



While making this patch, no less than four different emulators were used:

• Geiger's Snes9x tracer v1.43ep9r8, for tracing the original boot routine in CT.
• bsnes v058 debugger, which has 21fx support and allowed me to trace close to 99% of smkdan's code.
• bsnes v071 debugger, which supports the MSU1 _and_ has a nice tracer as well.
• higan v094, which is the latest software that supports the MSU1.

It took me a few hours to obtain a file of usable assembly code from the tracelogs. Routines and snippets had to be rearranged in order to restore the original program flow. The few remaining holes -- a couple of missing labels, data tables a tracer naturally omits, and even small bits of code that a branching path hadn't been taken to during tracing -- were filled in the hard way, i.e. by reading and context-based interpreting the corresponding section in the ROM using a hex editor.

Before I started to update smkdan's code, I made sure it assembled just fine, resulting in a byte-perfect copy of his original hacked ROM. This achieved, "porting" the hack to MSU1 was basically a piece of cake. One of the major challenges was to get bsnes v071 to cooperate by finding a suitable template XML file, which is needed for the emulator to actually enable MSU1 support. While the original MSU1 data file simply had to be renamed, the WAV file was converted to PCM using wav2msu.

The original implementation of the 21fx had the data port (and all of its control registers) sitting on the B-bus of the SNES, which required developers to buffer the streamed data in WRAM for DMA. In the course of the transition to the MSU1, ports and registers were thankfully relocated to the A-bus, allowing the data port to be used as a fixed source for DMA. (Fortunately, I had saved copies of nearly all 21fx/MSU1 documentation from byuu's website ...)

Initially, I didn't bother to eliminate the WRAM buffer. Later on, I decided to update the hack in that regard for the sake of simplicity and code readability. Also, the issue that users of sd2snes had to rename the PCM file is now resolved, and the hack should run on both sd2snes and higan out-of-the-box.

So I hope you have just as much fun testing this out as I had disassembling and re-coding it.

Download (UPDATED Sept 28th):
http://manuloewe.de/snestuff/projects/ct_anime_intro_msu1.7z (source is included)

Nice work! I'm going to have to give this a try on my SD2SNES

Rhoo nice !!!

It had been years that I wait for this hack

Go and do it for all the video?

Thank you two!


Who knows?!

Can't seem to get it to work. Neither higan v094 nor SD2SNES seems to just naturally pick up and apply the .bps on its own. I tried looking up "beat v01", all download links I found just point back to the page on byuu's site that no longer exists.

I did a bit more reading and I understand that basically everything that was on that site is now on indefinite hold / dead. But can we at least have the documents and download links to what did exist restored, or can somebody who has it re-host the whole collection somewhere? I promise I will never ask for another thing from byuu as long as I live, I just hate to see work that's already been done get lost and have to be re-done...

http://www.romhacking.net/utilities/893/

I'm just not very good at searching lately... Thanks again!

The video plays just fine now and it looks great! The FMV audio only seems to work in higan though, not on the SD2SNES...

Thank you too, I'll look into this once I get home ...

Oooh, awesome! Thanks for making this! Chrono Trigger's always been one of my favorite demos for the idea, so it was pretty disappointing to lose it.

I also really liked the 21fx name a lot more than MSU1 too, but as I'm sure you're aware ... that WRAM buffering thing really got in the way. Chrono Trigger apparently had the spare space, but a lot of games aren't going to let you pack a whole image frame (~40KB) into WRAM like that.

I've been wanting to do this for Der Langrisser for a while (it has an amazing real-instrument OST, and the PC-FX version has nice FMV), but time constraints, laziness and difficulty making it work with both English and Japanese versions has gotten in the way.

> But can we at least have the documents and download links to what did exist restored

I'll get to it eventually. I can't build new releases at the moment due to toolkit changes, but I've got the old releases archived somewhere ...

All of that boundless energy to accomplish things dried up in my 30s, I'm afraid. "The candle that burns brightest" or something, I suppose?

I appreciate that, and I hope I haven't sounded like I've taken your work for granted. I owe you quite a debt for making the things I've been doing lately possible.

> I hope I haven't sounded like I've taken your work for granted.

Not at all. I'm the one that pushed people to try and use formats like BPS and game folders, and tools like bass and mosaic.

It's inexcusable how lax I've been with providing the proper tooling for people to do so; and shameful that after 10.5 years, I still don't even have a finished debugger. Not to mention all the people waiting on FEoEZ, most of all the translator himself.

I'm totally deserving of actual scorn (which you didn't do.) I took on way more work than a person of my abilities could manage, and then I completely burned out, so now the problem's a dozen times worse than before.

Do you not do anything SNES related at this point?

I'm still hoping to see this. It'd probably make me actually invest in a SD2SNES cartridge. Although I'm just happy Der Langrisser has such an awesome translation available at all. Coincidentally I just started playing it again these past couple days.

Please try renaming ct_msu1.pcm to ct_msu1-0.pcm -- I still haven't been able to test it on my sd2snes myself, but I'm pretty sure the filename's the issue here.


Glad you like it.


True. Actually, I might have to rework the hack in that regard anyway rather soon ...

Sadly, I haven't done anything to the core emulation since January 2014.



I did make the CD-audio patch a long time ago. And it works really well.

For those who haven't heard it, dare to compare:
SNES: https://www.youtube.com/watch?v=NRnwoalthsw
OST: https://www.youtube.com/watch?v=U31qv60ZMIQ



Oooooh, exciting! :D

Where can this patch be found now? The CD audio for Der Langrisser. And is it for MSU-1 or the old 21fx?

@MottZilla, maybe that patch was never released? Care to contribute to the subject of this thread in any way?

Sorry it took me so long to respond - it does indeed work if I change the filename. Thank you for restoring this demo!

Okay, I've done some more work on this, and finally got it to stream data directly into VRAM/CGRAM (no more WRAM buffering). Yay.

Oddly enough, the original hack doesn't even bother to use the active display time window to build the buffer; instead, it fills the buffer on every even frame and copies its content to VRAM/CGRAM on every odd frame, effectively cutting the framerate (at least) in half ... which is probably why I thought I was getting sea-sick upon watching the FMV the first time.

Before another release, I'll do my best to remedy these deficiencies, which of course implies the video will need to be reconverted.

This new version will be awaited with great interest

Huh! So, you mean it goes like this?

Frame 1: Load Frame 1 to WRAM
Frame 2: Transfer WRAM to VRAM
Frame 3: Load Frame 3...

So... That video is actually playing in 30FPS, and you're saying it could be 60FPS? That doesn't seem possible to me at that size. Unless you meant it's skipping every other video frame, but the original video is 30FPS so it's actually playing at 15...

I'm curious to know a bit more about how these Video-Directly-To-SNES demos work. I know very (very) little about video encoding, but it seems to me like decoding the picture in real time would be prohibitively processor-intensive unless it's already pre-formatted for SNES. Does it generate a new palette for every frame, or use a static one for the whole video? Does it translate the image pixel by pixel? Or is it sort of a streaming thing where it only updates pixels that have changed from the last frame?

I'm just curious to have a better understanding of how to compare this video-decoding method to my frame-pre-processing method.

The original video (converted with an ancient tool from STR to AVI) is indeed 30 fps, but as I discovered just today, the odd and even frames are exactly the same -- so ultimately, it's only 15 fps. At least, that explains its choppiness.


I bet it's the same. For example, both ikari's video player and smkdan's implementation simply require a series of Tile data + palettes as the .msu data file; tilemaps are fixed and thus only written once at all.

EDIT: Okay, 2347 frames ready to be converted to SNES format. I've scaled them down to SNES aspect ratio, and cropped them to get rid of the black borders. Each frame is now 256×168 pixels, i.e. the video is intended to look just like it does in the PSX version (nothing removed, no vertical borders added).

There's a catch though: I don't see how this can be achieved in 8 bpp (Mode 3) as the amount of tile data per frame exceeds 32K (i.e., no "page" switching). The only way to do it seems to be via Khaz' Quantomatic (which is already doing its job even as I type), which allows 120 colors per frame instead of 256. We'll see if this is enough to do justice to CT's cutscenes. Personally, I prefer a bigger movie "window" on the screen. What do you guys think?

Any reason not to do both for the intro to compare? Other than being more work.

I'm assuming you're saying 120 colors full screen, or 256 colors and a reduced screen area? It would be nice to compare the result.

Like I said, you could probably do a compromise with a 4bpp layer using 6 palettes and a translucent 2bpp using all the palettes for it over the 4bpp layer. If I'm not mistaken, this could get you 2161 (the 1 being the color 0) colors onscreen total, but you'd have to make a really crazy tool for this, and it would probably take 100x the amount of time to process each frame...

You know, you could make a really awesome splash screen if you had a 4bpp layer using all the palettes and another 4bpp translucent (color addition than halving) layer also using all the palettes over it. You'd do [15x8] x [15x8] - 225 (because the same colors over each other don't look any different, and 15x15=225) + 1 (color 0) and then you'd get 14,176 colors. Wow.

For that last one, you might need to rent something like this.

http://upload.wikimedia.org/wikipedia/c ... mputer.jpg

Good luck! I don't know if it will be a problem for the Chrono Trigger video, but the last version of my program I posted to Github still fails when you have no 8x8 tiles with a full palette of colours, like a frame that's one solid colour for example. I've fixed that (and it'll run faster in those cases too), and I just posted the new version now...

I love a good fullscreen video personally. If the original version was letterboxed and you're going for authenticity then that's fine, but I say go as big as you can without cutting anything out or hurting the overall quality.

Dammit you've got me thinking now. I've never tried doing anything with translucency before but my understanding is it's just bascially averaging the two colours, right? The first paragraph there actually sounds doable. Say you use my program to quantize the image down to 6 palettes. Then, you have another program to scan through and calculate the errors on each pixel. At the most minimal case, you collect a list of the 14 worst colours found and assign them a correction colour in one of the two 2bpp palettes. If you have a tile that needs two different correction palettes just pick the one with more pixels to correct. I don't feel like doing math right now but that miiight get you a slight improvement on just quantizing a straight 8 palettes.

Alternately, you could take a more balanced approach, give each 2bpp palette a couple of tiny corrections (like say 1R,0G,0B and 0R, 1G, 0B), do a quick scan to see which palette will correct the most pixels and assign it, to hopefully give more of a softer effect across the whole image.

The second paragraph is a more fascinating idea. When you're talking 14k colours available at once, that's almost a quarter of the SNES's total colour library. At that point you don't even really need to CALCULATE the optimal arrangement for each frame. You could just find some algorithm that gives you a good spread of colours and use that megapalette for everything. And if you want to get really intense, find some progression of palettes where you can get say four sets of 14k colours, and shift between them depending on which is best for each frame.

HOWEVER though you have a theoretical limit of 14k colours, you can't exactly have them all on screen at once because again you have to weight each tile to see which combination of palettes will come the closest. Trying to think about how badly that impairs the concept hurts my head right now.

I have to give you credit for daring to consider the idea.


EDIT: Oh yeah. If anyone else is doing video with the Quantomatic and you don't have a way to convert the .inc files into a .msu, I have another quick excel file that does that. I should give my python program the option to export raw binary files as well, to make that easier.

What? The hardest part seems to be that both layers use the same 8 palettes. I actually think I did my equation wrong, but I'm having the hardest time figuring things out. I think I fried my brain on this...

Would it be [15x8] x [15x7] + 1 = 12,601? Wait, wouldn't you actually multiply the second 15 by 8 and not 7 because we never calculated actually calculated the color by itself? Then it would be 14401, which is slightly more than I originally thought.

Similarly, I forgot the colors on the 6bpp one could be by themselves, so [15x6] x 24 + [15x6] + 24 + 1 = 2274.

As far as I can tell, if all colours are unique, it's [15x8] x ([15x8] - 1) = 14280. ASSUMING you have a selection of colours where no two combinations create the same result, which sounds absurdly hard to arrange.

The problem though is in rendering the image in those colours. Say you have one tile where one pixel here needs palettes 1 and 2 for its colour, but another pixel needs palettes 3 and 4. So, you have to balance which combination of palettes satisfies the most pixels in that tile and go with that, which will probably make the pixels it DOESN'T cater to look downright awful. I think your idea might look awesome for a gradual smooth gradient of colour or something, but when you get a lot of different colours inside the same tile it probably breaks down unless, like you said, you have one hell of a computer program to work out the best compromise...

Well, it's not impossible. Just leave your computer running for 2 years. Anyway though, even if it isn't the total amount of colors, there is going to be so many colors that it might not even matter anyway.

Oh yeah, one trick I've had that I think would work (I've never actually tried it on real hardware though) would be if say the tile map 512 pixels tall, you could use HDMA to move the vertical scrolling register 4 pixels up every 4 pixels down the screen to make it to where the 512 tile map is fitting in the 224 space. The reason for this is you could have the palette be different for every 8x4 pixel area.

Just based on what I've seen so far, I'm kind of wagering that it will. Just plain reducing an image to the SNES's maximum colour depth can cause visible breaks in the image that were once a smooth transition of colour. Reducing that down another quarter or more could start to look unpleasant. Choosing the palette based on content is important to getting a good result. Just try reducing an image to 256 colours in MSPaint - it uses the same stock palette every time, so even with plenty of colours to work with it looks awful.

You may be right though, I'd have to see the results to know.

No, you're not going to have the palettes be the same for the whole video, you're going use different palettes for every frame. I'm saying that even with the 8x8 attributes, it will still look really colorful.

What would the intro look like if dithered to Arne's 4-bit palette throughout? If I can see the result of that, I might be able to suggest strategies to search for a good 2-bit additive blend palette.

I think the 6bpp option seems much more realistic. It could also be a bigger picture at the same framerate than the 8bpp version, which would be the advantage on the SNES side of things.

Eh, I prefer this one (colors may be tweaked but idea is there) but I imagine it wouldn't work well here:

Where's the skin color though?

(This is a bit random, but I think in Arne's palette, night blue and shade green should be compromised into one dark color, because they are nearly the same. This would leave room for a dark grey, which really appears to be needed.)

Last one, but yeah it may be a bit too pink (but again, may deserve some tweaking, the idea is what colors should go there). To be fair, the original purpose was to use this palette to dither down true color images in a lazy way anyway.

I just feel that with limited palettes, it's best to go for something a little "muted" so you can kind of use colors around other colors and it will look like there are more colors than there really are. A muted dark green could look like a dark grey next to a grey color, and it could also just look like dark green next to a normal green color. If you've ever seen so Commodore 64 artwork, you'll know what I mean.

If the brown isn't good enough, such as for northern ethnicities, try dithering pink and orange.


You ended up figuring it out: Arne's palette is designed for dithering. Dark gray is a checkerboard pattern of black and #999 gray, or dark brown and dark blue, or the like.

There's a trick to this that I came up with a while ago.

Let's say your image takes up 40KB of VRAM space. So you can't get all 40KB of the next frame in without overwriting some of the current frame, right? But you can write ~16KB of the next frame in there while the screen is going to show the current frame. And then on the next frame, inside Vblank, you send the remaining 24KB of the image, and change the VRAM tiledata address between $0000 and $c000. Your tiledata requests can wrap around back to the beginning of VRAM again, so this works fine in practice.

Awesome, thanks for all the valuable feedback, guys!


Thank you!


Indeed, the latter would be great.


Brilliant! I didn't know it wraps around to $0000 again, so that's good to know. I just converted one frame to 8 bpp SNES graphics, it weighs in at 43.008 bytes.

Okay, let me translate your idea into pseudocode to make sure I understand it correctly.



Hmm ... But is one Vblank enough time for a DMA of 26.624 bytes (+512 for the palette)? Apart from that, I'd be really glad if this worked, not only because of the higher number of colors, but also since it'd spare me all that frame processing.

Are you using NTSC or PAL? It should barely work on a PAL system if you load tile data into the unused portions of the tilemaps, but it's a no-go on NTSC because you have to preload too much of the new frame alongside the old frame and it blows past 64 kB. With 168 active scanlines, NTSC gives you a little over 15 kB DMA per frame, and PAL gives you a little over 23 kB.

NTSC:
VBlank n - load 13984 bytes to VRAM
VBlank n+1 - load 13984 bytes to VRAM (which now contains 43008+(2*1344)+27968 = 73664 bytes; oops)
VBlank n+2 - load 512 bytes to CGRAM and 15040 bytes to VRAM, switch tilemaps
20 fps

PAL:
VBlank n - load 19840 bytes to VRAM
VBlank n+1 - load 512 bytes to CGRAM and 23168 bytes to VRAM, switch tilemaps
25 fps

> Okay, let me translate your idea into pseudocode to make sure I understand it correctly.

Hard to be sure with pseudocode, but essentially right, yeah.

Basically, you have frame# 1 in VRAM, and that's ready to draw on the next refresh. So while in Vblank, you write part of frame# 2 to the part of VRAM not used by frame# 1. Frame# 1 is refreshed onto the screen, and now you're in Vblank again. Now you write the remaining portion of frame# 2, and this overwrites part of frame# 1, but it's okay because we are going to finish the transfer. We change the VRAM tiledata address to the start of frame# 2, and the next refresh now draws frame# 2 for us.

As you can imagine, this is a technique that primarily benefits going from 15fps -> 20fps. If you try and push 30fps, then you have to upload frame# 2 and part of frame# 3 once frame# 1 has been drawn on the screen. That's a whole lot of data for one Vblank period.

> Hmm ... But is one Vblank enough time for a DMA of 26.624 bytes (+512 for the palette)?

I don't believe it's possible to draw 256x168(?)@30fps on NTSC, sorry.

I'm sure you know the trick to force-blank the screen during the horizontal blank lines, so you have 262-height lines for transferring tiledata. For each line, you can transfer 165.5 bytes of data to VRAM. So if you have 94 lines, that's a limit of 15,557 bytes. And you really should give yourself a bit more headroom, since you're unlikely to perfectly align your DMA to the start of Vblank and to complete exactly when it finishes (I'd recommend one scanline or so as a buffer.)

Your only options are to:
* reduce color depth, or
* reduce frame rate, or
* reduce resolution (reducing height is much more beneficial; but width still helps), or
* use Picture Always Lousy mode (and only ~1% of PC users will be able to Vsync @ 50hz)

Okay, once again ...

The video is 256×168, 15 fps, NTSC. One 8 bpp frame is 43.008 bytes of tile data plus 512 bytes palette data. As NTSC is ~60 Hz, I have 4 Vblanks to transfer that amount of data in, say, chunks of 12K.


But how does a framerate as low as 15 fps even help with ~43 KB of data having to be transferred and not glitching out by Vblank #n+2 due to data of the last frame getting overwritten?

It appears we're ok for this, but has anyone ever considered pushing a little extra tile data using HDMA? You could probably use all 8 HDMA channels.

(Again though, I really think someone should try a transparent 4bpp BG. It would be the exact same amount of memory as a 8bpp BG, but it would have tons and tons more color.)

> But how does a framerate as low as 15 fps even help with ~43 KB of data having to be transferred and not glitching out by Vblank #n+2 due to data of the last frame getting overwritten?

If the frame size is too much to complete in the final Vblank before displaying, then it won't help. You will be forced to lower the resolution/refresh/depth.

This technique I'm suggesting won't allow perfect 60fps video at 256x224 :P
But it will increase the maximum resolution you can achieve by a moderate amount.
So if you're trying to push things to the absolute limit, this will be something you'll want to do :D

> It appears we're ok for this, but has anyone ever considered pushing a little extra tile data using HDMA? You could probably use all 8 HDMA channels.

That would only work on ZSNES.

Just wrote that in real quick. You can now send it a -b flag to make it output one binary file INSTEAD of the three .inc files, then all you have to do is combine the .bin files into an MSU and you're done. Running a quick test, I'll publish it when it's confirmed working.

Notes: The binary file goes in order of Tile Set, Tile Map, and then Palettes. The tile set and tile map scale in size to the height of the image. The palettes chunk should always contain the target number of palettes and always be the same size, even though there's a slim chance that my program can output less than the target number of palettes if the image is really low on colour. (If you use .inc output, you have to correct for the possibility of not enough palettes when compiling to an MSU...)

EDIT: Test one failed, retrying. I wish Python would actually scan through all the code at the moment you launch it, and not wait until after an hour of processing to tell you "Oh hey you never defined this one variable". (Yes I know variables may or may not be defined depending on conditional branching but clearly it could recognize when a declaration does not exist anywhere)

It doesn't know that another function isn't going to create a global variable by that name.

Binary output confirmed working, code uploaded.

Let me know if you have any problems with it!

Why? What hardware rule am I not respecting?

Video memory write ports ($2006-$2007 on NES, $2116-$2119 on Super NES) do not work during active display. HDMA during forced blanking wouldn't buy you any more speed than normal DMA. And besides, HDMA and normal DMA enabled at the same time will often mess up on 1/1/1 consoles like mine.

When I meant using HDMA, I meant on the area in the middle of the screen with the picture that isn't undergoing forced blanking.


Strange... You know, what's even the point in console reversions? If you play to the new version when designing something, you're just going to lose compatibility to the older one. That'd be like if Nintendo decided to make a reversion of the NES that doubled the amount of overdraw. That would be fine for enhancing the look of older NES games, but if developers had the increased overdraw in mind when designing their new game, you'd have 96 pixel wide bosses and the like that would look fine on the reversion console, but would cause a ton of flicker on anything older. I know I didn't give the best example, but yeah.

Yeah, HDMA to video memory there won't work.

I'll answer your other question elsewhere.

> When I meant using HDMA, I meant on the area in the middle of the screen with the picture that isn't undergoing forced blanking.

I was hoping you'd just trust me; or at least investigate why on your own. But oh well ...

The CPU can't read from nor write to VRAM during active display, and that includes Hblank. Accesses are completely ignored. This is because the PPU is reading VRAM for various things like sprites to be rendered during the next scanline.

> Strange... You know, what's even the point in console reversions? If you play to the new version when designing something, you're just going to lose compatibility to the older one.

I've often asked the same thing.

And then I found this college football game. It detects the CPU revision to choose between using DMA (r2) or block-move (r1) for transfers around WRAM during active display.

It didn't make the game any faster, so all it did was complicate the code development.

But even if it did, would you want half of your users getting the slow version and half getting the fast version? That sounds like a PR nightmare to throw all r1 users under the bus instead of finding a better solution.

Thanks!


Hmmm ... Trying it on a 256×168 frame (= 21.504 bytes of tile data), the tile data size is still 32K (0x8000), with padding zeroes from offset 0x5400 to 0x7FFF. Next, the tilemap should be (less than) 1024 bytes, correct? Yet it seems it's exactly 1344 (0x540) bytes in size. So, palette data starts at offset 0x8540, but this one's fine (256 bytes).

Attached are four frames I tried to process (two of which make Quantomatic hang, btw).

Tilemaps are 16-bit, except in Mode 7. 32 wide x 21 high is 672 tiles, so 1344 bytes.

I forgot to mention.... You have to specify the number of output rows with -o 21 (for 168 pixels tall), or else it defaults to a fullscreen image. Sorry about that.

No idea why the program would be hanging at this point though, I'll look into that

Ah, right ... I knew I was missing something important.


Okay, thanks!

Here are screenshots of all the current options for direct comparison:




(ikari's player. Sorry I got the aspect ratio wrong when I converted the video ... This dates from 2012, and I never bothered to release the .msu file. Frame size is only 224×144 px.)





(The current implementation, as based on smkdan's hack. Frame size is 240×160 px = 38.400 + 512 bytes, which pretty much pushes the bandwidth to its limits.)





(Not from a finished movie, but simply a still image with window masking, namely one of the first few frames I processed with Quantomatic for the biggest movie "window" possible (while still retaining the original movie's letterboxed format), i.e. 256×168 px.)

Personally, I think this makes the decision about FMV resolution vs. color depth an easy one, but I'm still open to comments/suggestions, of course.

8bpp simply beats 4bpp. For this project, I think I'll therefore stick with smkdan's player.

There is one thing - if you aren't using sprites (and Quantomatic doesn't do sprites yet AFAIK), you should only need to write the top byte of the tilemap, the one with the palette selector bits in it. If Khaz's program does what I expect it does, the bottom byte should be the same every other frame, there being no reason to move tiles around other than the double buffering.

But in this case the limiting factor is the aspect ratio rather than the DMA bandwidth, so you probably don't care about that right now...

I haven't attempted sprites yet, just because I'm not enjoying the idea of having to either calculate with a limited number of sprites or use 16x16 sprites requiring 2x2 blocks of the same palette. Also because it would force screen size lower again, just having to update OAM...

You're right though about the tilemap. The tile set is always arranged the same way so only the hi byte should need changing. The problem there is you would have to preserve the bottom two bits of the high byte every time, unless your picture is very small...

EDIT: Should also mention. I'm sad but also confused at the low quality my program outputs compared to the other two. I know all of nothing about Mode 7 or anything 256 colour on SNES, but isn't it just a bigger palette size? If that's the case, in a frame with such a low number of colours already, I wouldn't think you should see such hideous losses from my program....

I think what I can say so far is that the Quantomatic works best for very busy images with lots of colour and contrast. Big slabs of all one colour, or god forbid almost-but-not-quite-the-same colour, tend to look awful. I'm working on ways to address this...

The low OAM table (unless you're using multiple sprite sizes, in which case you need the high table too), the top half of CGRAM and the bottom byte of each tilemap word (since you can no longer guarantee a static BG tile mapping). It's still better than 8bpp, and depending on the use case may not actually affect screen size - fullscreen 12 fps may be too marginal (how long does it take after force blank before VRAM will accept data?), but 256x216 at 15 fps should still be possible with reasonably careful coding, and 256x168 at 15 fps has plenty of extra bandwidth.

But I don't think it would be hard to quantize with 8x8 sprites. You wouldn't have to do any complicated case handling; just set it up so that the 8 most-used palettes are BG, and everything else is sprites. Then keep merging until you have no more than 16 palettes total and no more than 128 sprites. In the absolute worst case, you'd still get 9 palettes this way, because even if they're all used about equally often each one would be used in about 100 tiles out of a full-screen image, so the least common palette is guaranteed to be spritable. And it should be faster, since you don't have to merge down as far...

Am I overlooking something?


I don't see how that's any different from DMAing the whole tilemap, since the tile numbers are in there anyway.

Maybe you could even make it to where it uses a 16x16 if possible so you have more sprite coverage.

You know, I'm stupid. What's the equation for finding how much DMA bandwidth you have?

You mean rather than trying to optimize using just 16x16s, he could use 8x8s by default and just check for 2x2 blocks that happen to use only one palette?

That's the plan. It wouldn't convert whatever 8x8 tiles are together at the end, it would somehow put it into the equation so you could potentially have 128 8x8 and 16x16 sprites.

It strikes me that all you'd need to do would be check for 2x2 blocks before checking the sprite count condition during each iteration.


DMA bandwidth is approximately (262-N)*1324/8. You have 262 scanlines (or 312 on a PAL console), of which N of them are active display. 1364 master cycles per scanline, of which 40 are DRAM refresh. It takes 8 master cycles to transfer one byte.

I believe NMI fires partway through the first VBlank scanline, so that's a bit off the top unless you use an IRQ. Either way the timing isn't exact, so there are a number of cycles you can't count on. There's a short scanline (1360 master cycles) during VBlank on NTSC, and a long one (1368 master cycles) on PAL in interlace mode. And of course there's overhead, like sta $420B, the channel and master overhead for DMA, and anything else that needs to be done during the blanking period. Since OAM is read on the scanline above the first active one, it might be wise to not leave it for last...

It may or may not be possible (I'm not sure, which doesn't mean no one else is) to extend the bandwidth slightly by timing an HV-IRQ to fire in time to blank the screen and start DMA immediately following the end of the last active scanline, adding some fraction of an HBlank to the total available DMA time. This is why I think 256x224@12fps might still work even with sprites...

If you want to make the download run out-of-the-box on both higan and the SD2SNES, rename the .pcm file and then change the name in the manifest file on the track number line. That's probably the better way to handle it rather than making a note in the OP for people to do it after the fact... just a thought.


Edit: Here's a complete manifest.bml that simultaneously supports higan and SD2SNES (rename the .pcm file accordingly)

Here's another: I might not have had the time to update the package yet.


You are aware of the fact though that sd2snes completely ignores .bml files?

Yes, I'm aware that the SD2SNES ignores the manifest files. The point was to name the files in a way that the SD2SNES would accept and then change the filename lines in the manifest to match so you could use the same set of files on either without renaming.

Any news?

I finally took the time to update the package with the new data transfer routines (omitting WRAM buffering). The PCM file was renamed and the manifest updated as well, so the hack now works on both sd2snes and higan out-of-the-box.

Download:
http://manuloewe.de/snestuff/projects/c ... ro_msu1.7z

does this also allows the OST audio from the PSX game or from CT sypmphony orchestra?

byuu changed the format of manifest.bml yet again for the higan v096 release. This completely breaks any and all out-of-the-box support for MSU1 (which has solely relied on correct manifest.bml/xml files ever since).

From a developer's perspective, this is no big deal. You're a user? Sucks to be you, as there's zero documentation of the new format whatsoever, no manifest converter included, and no icarus support for MSU1-based games provided either.

But I'm a developer, not a user, and therefore used to changing standards, and to making educated guesses. Here's an updated manifest.bml for this project, compatible with (only) higan v096(+? ... I wouldn't count on it).


Edit: I forgot to mention that you have to update your entire game library, as higan v096 in its standard settings simply ignores manifest.bml files instead of conveniently updating them. Why? Because in order for this to work at all, you have to go to Settings/Configuration/Advanced and uncheck the "Ignore Manifests" checkbox. Be warned though -- unless you take the time and do the manifest conversions manually, all your other (non-MSU1) games won't work anymore after this!

> byuu changed the format of manifest.bml yet again for the higan v096 release.

Game manifests are an internal convention. I expose them as a way to allow power users to customize things, but they're as volatile as save states. The mistake I made was not having icarus to auto-generate compatible manifests sooner. But I solved that problem as of v095.

> no icarus support for MSU1-based games provided either.

This is incorrect. icarus v096 supports MSU1 game folders without the need for a manifest file at all. It just can't import them because it won't know what file names to look for, and the games are WAY too huge to make copies of anyway. But you already can't distribute MSU1 games as a single ROM file. If you distribute it as a game folder, without a manifest, then it will work out of the box.

I'm hoping to convince ikari to support the file naming convention I use. I am willing to make a promise to -never- change the file names (folder.sfc/{program.rom, msu1.rom, track-#.pcm}) again, so it will give us a universal format for MSU1 games, if he accepts my proposal.

> I wouldn't count on it

You shouldn't. Going forward, manifests should not be used unless there's very good reason for it.

I tried very hard to come up with a stable standard, but ultimately realized it's not possible.

> Edit: I forgot to mention that you have to update your entire game library, as higan v096 in its standard settings simply ignores manifest.bml files instead of conveniently updating them. Why?

Because I don't tag manifests with version numbers, and if people left their old manifests around, the games would fail to play.

I explained all this in the release notes. Everyone should delete all their existing manifest.bml files, because v097+ isn't going to have "ignore manifests" enabled anymore.

But yeah, change sucks, I know. But higan's an experimental emulator that's trying out brand new things. Stuff's going to break. Often. That's part of the deal. And it's higan's willingness to break conventions when new info comes along that allows only higan to run things like the SNES competition carts, neviksti's 96mbit Star Ocean hack, the DSP1 technical demo, etc etc etc. But you pay for that power and adaptability through having your games constantly break if you stay on the bleeding edge.

I'm doing the best I can with icarus now to prevent it from happening again as of v095+.

Being the sneaky little person I am, I actually got the DSP-1 tech demo working on a non-higan system. Had to modify two bytes (Change two bytes at $7FD5 from $FF, $FF to $20, $03, with left-to-right ordering naturally), given that the ROM had no header to begin with, but the program runs with just those modifications.

I had to do a header hack on Rockfall as well, as the title was too long (by one character, even!), overwriting a byte that crashed SNES9X when the ROM was loaded.

These two citations are a good reason for your kind of magic: it prevents the header from crashing your emulator due to bad data.

It would be pretty cool to see this happen without an MSU1. I have an idea of how to speed up converting packed format to planar format. Use an extremely large LUT that takes up 512 kB, with all 65536 combinations of 4 pixels (64kB), for each bit plane (256kB), and shifted left by 4 bits (512kB). The actual compression itself could be just a combination of byte aligned RLE and LZSS. Maybe use tile motion vectors to keep memory size down even more.

> I actually got the DSP-1 tech demo working on a non-higan system

Now try it with the 96mbit Star Ocean hack; or the 16mbit program ROM Tengai Makyou Zero hack ;)

> These two citations are a good reason for your kind of magic: it prevents the header from crashing your emulator due to bad data.

The way I look at it, modifying those two bytes means you're not using the original ROM anymore. It's a ROM hack and the data is no longer verified. As a preservationist, I -very- much don't want to encourage this sort of behavior of monkey patching ROMs.

Further, I consider the internal ROM header's registration data to be something that should be completely ignored (other than the interrupt vector addresses, of course); because that's exactly how real hardware works. It doesn't matter that the ROM registration is completely invalid: real hardware never even looks at it. And neither should an emulator. But because of the way we dump our ROM images, discarding all the important board layout configuration information, we have to. The database I bundle in higan seeks to restore that information. It's not an ideal solution, but nobody wants to adapt game folders as a distribution model, so it's all I can possibly do.

> I had to do a header hack on Rockfall as well, as the title was too long (by one character, even!), overwriting a byte that crashed SNES9X when the ROM was loaded.

Yeah, that's a pretty common one. Blatant mistakes like that are why I laugh when people like Nach in the past have told me the registration information was perfect by Nintendo's mandate and could produce 100% perfect memory maps.

Upon dumping my US set, it turned out that Bazooka Blitzkrieg has a ROM size of 0x00, and RAM size of 0x08. Obviously they messed up and put the bytes backward, as the game has no RAM, and obviously has ROM. But what was interesting was that all the ROMs out on the internet had the bytes swapped around. Someone 'fixed' the header, so the ROM was not legitimate, but hacked.

Lots and lots of prototypes don't bother with the ROM registration header, because the game hasn't been vetted for final approval yet by Nintendo.

> It would be pretty cool to see this happen without an MSU1

Chrono Trigger's already 32mbit. You don't have space to spare. But even if you put it on a new board with 48mbit, you will never make anything remotely pleasing that tries to mimic the FMV intro with that amount of remaining space, no matter how clever you are. At best, you could get the audio track in there at very low quality, but that's about it.

How long is the video?

Separate files for PRG ROM, CHR ROM, and a board manifest were the model for Pasofami and ZapFC formats. I'd be happy with distributing zipped game folders, with the extension .sfz (Super Famicom Zip) to get the file manager to open it in the emulator. It worked for Winamp (wsz), Java (jar), and StepMania (.smzip).


Unless they planned to do it like the NES Action Replay and put the whole thing behind a suicide battery :p


Yet Sonic 3D Blast opened with some sort of FMV. And 63.5 Mbit ExHiROM carts are well defined and available from INL.

I wasn't meaning to ask why higan treats manifest files the way it does. The "why?" was a rhetorical question leading to an explanation of the need to update them manually.


I read them long before posting here. I even read the discussion on your forum. I went ahead and deleted all my manifest files using the batch line you posted. Thereafter, none of my MSU1 games -- e.g. LoZ Deluxe, CT with anime intro, my own audio resume demo -- worked in higan v096 anymore (i.e., they played as if there was no MSU1 support).


But isn't icarus' sole purpose to, well, import your games for use with the higan library? And even if icarus "supports" MSU1 games (though without being able to import them), then why doesn't higan?


No. (See above.)


MSU1 is, IMHO. As are some old homebrewn S-DD1 video ROMs. Etc etc.


That's not what I was getting at. I like higan. A lot. I like the way it has evolved over the years. My point was: The lack of documentation is a bit painful. If the manifest format changes -- fine. But please let your users (who are often developers as well) know what changed. After pulling out my back-up media with the lost manifest files, and lots of fiddling around, I managed to get all of my games working again, thanks to the new manifest viewer. But I assume there are many other users who aren't that lucky (or can't be bothered investing the time and effort).


Thank you.

> Thereafter, none of my MSU1 games -- e.g. LoZ Deluxe, CT with anime intro, my own audio resume demo -- worked in higan v096 anymore

Oh, were the manifests used to rename the files to odd things for support for sd2snes?

Shoot, sorry about the trouble. I didn't consider that use case and imagined anyone using higan (and not sd2snes) would be using the program.rom+msu1.rom+track-#.pcm file naming convention.

From higan's perspective, I hadn't changed the proper filenames.

> But isn't icarus' sole purpose to, well, import your games for use with the higan library?

icarus is meant to get games stored in legacy formats into higan.

The idea was that MSU1 is already a higan format, and people shouldn't be seeding them as "game.sfc+game.msu+game-#.pcm" ... they should come as game folders.

But again, it's hard to justify copying in a huge amount of gigantic files.

In the future, I may add some kind of "MSU1 pack" format, that's an archive full of MP3s and such to expand into a game folder. But that's a ways off.

> And even if icarus "supports" MSU1 games (though without being able to import them), then why doesn't higan?

higan acts like a real SNES. It doesn't try to heuristically figure out what the deal is with a binary blob mess with no context. All of that messy code that has nothing to do with a real SNES is moved into icarus.

It's a pain for you guys, but it's an ideological thing to me. ananke and now icarus are my best attempts at a compromise into giving everyone years of baggage and crap and incorrect mappings and support for ZIP archives and external firmware and on and on and on.

Essentially, higan's the nice store front with the curated products on display, and icarus is the slaughterhouse where the meat gets made.

> No. (See above.)

It will if you name the files the correct way. It can't know what files to look for if you don't name them in a predictable way.

> MSU1 is, IMHO. As are some old homebrewn S-DD1 video ROMs. Etc etc.

I do actually prefer when manifest.bml is used to rename MSU1 audio tracks to their purpose and/or name. Eg "01 - Battle Theme.pcm", "02 - Ein Fahrender Ritter.pcm", etc.

Might even be worth trying to rig higan to search for "track# - *.pcm" when a manifest isn't present, but I think that'd make it far less likely we could talk ikari into supporting the format :P

> My point was: The lack of documentation is a bit painful.

Yes, it definitely would help a lot. I don't have the time or patience for maintaining documentation, but that's one area that someone else who wants to help the higan project could easily participate to great effect.

Hello!
Thank you for your work on this anime intro for Chrono Trigger! I'm really interested in it and wanted to give it a try on my SD2SNES... unfortunately it doesn't seem to work on my console. I downloaded and applied the patch, I tried it on the Bsnes emulator and it worked well. But on the SD2SNES, I have a blurry colored garbage instead of the anime. The sound is OK though. What could be the problem?
For info, I have a PAL (French) modded console with super CIC, and I have a SD2SNES with the most recent firmware (0.1.7b).
Thank you very much for your help!

Hi!


Have you tried disabling the infamous in-game hooks? It should work fine without them. I can't test it out myself right now but will do so some time during the weekend.

Thank you for your answer! Actually yes, the in-game hooks are disabled, I just checked it, so I have no idea about what's wrong...
I took a photo of the problem. Thanks again!

Hmm ... Are you using 50 or 60 Hz mode? Do other MSU1 games with streamed video (like Super Road Blaster) work? Anyway, I'm going to try it once I get home tonight.

I'm using 60Hz mode of course!
And yes Super Road Blaster works fine, and the intro anime of Zelda 3 MSU as well. Maybe something wrong in the SD2SNES 0.1.7 firmware?

Just tried it out, and (EDIT) while buggy (sometimes there's a line of flashing pixels at the top/bottom of the screen, and sometimes audio won't play at all) it still works as expected (i.e., no worse than expected) on v0.1.7b. So ultimately, I can't help you with your specific issue. Sorry about that.

Edit: The flashing line only appears with those goddamn in-game hooks enabled -- no idea why they were enabled when I tried this a few minutes ago, but I suspect it's because I updated to v0.1.7b at the same time. So no, no glitches whatsoever, and I still can't help you, unfortunately.

Edit 2: Come to think of it ... what I always hated about the PSX/DS versions of the game were exactly those borderline ga-ga anime cut scenes anyway, so please, PLEASE don't count on me spending any more time on this than I already have by now. Thanks!

So I suppose the problem comes from my console?
If it is the case that's weird I've never had any other problem with the games I've played... Anyway... Thank you very much for having checked about this on your side. I'll try on another SNES as soon as I have the opportunity.

The project is now on GitHub, lest somebody's source code should get lost ever again.

I managed to combine this with DarkShock's audio patch so you can have the best of both worlds. Enjoy.

https://github.com/qwertymodo/ct-anime-intro/

It would be possible to implement the cutscenes and ending of the psone's version?, or it is limited to introduce a video only one time...

As far as I know, the MSU1 is really just a memory mapper with the extra ability to bypass the SNES's audio hardware, so you can use data however you want, including having multiple cut scenes.

Absolutely possible, not necessarily easy.

Oh man, I was really hoping someone would do just that, thank you! :D

Chrono Trigger is definitely one of the examples where MSU1 really shines. The orchestral music was perfectly made to fit right into the original game, and sounds amazing.

Combined with the animation sequences and no load delays, it's certainly the definitive version of the game.

Uhm, yeah. I agree it is. Or that it would be, if (i.e., IF!) this project had the aim of implementing "animation sequences" (note the plural here).

But it hasn't, and never has. Instead, it was only ever meant to implement THE ONE (!) INTRO SEQUENCE™, and nothing more, just as the thread title says.

Sorry about being rude on this one, but I just can't see why people don't get what this is/was all about, even though it's all been explained over and over again.

Ramsis

Ramsis, I don't think anybody (at least, anybody who actually understands the amount of work involved) actually expects you to continue the project to implement the other FMV's. You've made your point there. However, just as you continued smkdan's work, we can hope that somebody else might pick up the mantle and continue to that end. No need to be rude about it. In fact, I've already made some progress, in addition to merging it with DarkShock's audio patch, tonight I just managed to rip all of the FMV videos directly from their original source in full lossless quality (the audio tracks are MUCH cleaner, the videos only slightly so), and now I'm working on running those all through the video conversion process. The code, obviously, is going to be the harder part, but if I manage to work up the motivation, I intend to look into it.

Just because you're done working on this doesn't mean it's done. Feel free to be clear on the fact that you have no interest in continuing to work on it, but there's no need to get upset because other people are still interested in seeing it happen.

Sorry again. Don't get me wrong, I'm happy to see other people, like yourself, picking up where I left off. After all, that's why I put the code up on GitHub etc.

Maybe it's just the fact that for me personally, this project has yielded nothing but trouble and annoyance. I'm really sick of it.

*unsubscribes from this thread*

I managed to write a working hook into the event scripting engine, so now I'm able to insert all of the videos at the proper event points. The only issue remaining is reloading VRAM after the video completes (notice the black screen after the second video). Also, I have no idea where/when in-game the Fall of Guardia video plays. But hey, progress!

https://www.youtube.com/watch?v=vGkFO0C14-o

Great stuff!

The Fall of Guardia is played after the PS1 credits. If I remember correctly, on the DS it is played right after the ending cutscene.

This video doesn't show it after the credits, it just goes to the save dialog: https://www.youtube.com/watch?v=Ouqig6x-o3c I was able to use that LP to find all 9 of the others though.

Which ending's cutscene? There are several endings.

If anybody is interested in trying this out, I have a project page going at RHDN while I try to iron out the last of the bugs (the Chrono Trigger SPC engine is a lot more... interesting than aLttP's, lots of edge cases to account for). I'm currently holding the video files as something of a perk for people who actually report bugs. I've had over 75 downloads, and so far only 1 person has actually bothered to provide feedback of any kind, which means I pretty much end up having to do all the testing myself, which slows everything down. I've also started work on an alternative track pack for anybody who doesn't want to pay for Blake Robinson's OST, but no ETA on that yet.

http://www.romhacking.net/forum/index.p ... 115.0.html