nesdev.org

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

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.

Espozo wrote:somehow put it into the equation

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.

What's the equation for finding how much DMA bandwidth you have?

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)

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

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

qwertymodo wrote:Edit: Here's a complete manifest.bml that simultaneously supports higan and SD2SNES

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

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

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?