nesdev.org

Tested with SD2SNES, just a black screen.

I wonder if these flash adapters are having trouble with the memory mapping.

Anyway, I did the top 256 slivers thing. The topd file contains frames encoded as described, while the tops contains the top 256 slivers. It didn't save as much as I'd thought (lossless: 6,070,886 bytes), possibly because of twice as many control words. Again, I've attached a 1-frame test and a larger test, not broken into 32K chunks. Do you want me to continue breaking it into 32K chunks?

Don't break it into 32k chunks, I'm using $400000-$7DFFFF and $C00000-$FFFFFF regions. I just need separate files for both halves of the video.

So you're not afraid to take the cycle penalty of frames whose decoding indexes across 64K bank boundaries. So anyway, I changed the "top 256" transcoder to produce 4 MiB chunks where no frame straddles a chunk boundary. The first file, which currently has the first 4360 frames, can go in $C0-$FF and the second in $41-$7D.

Now about the blank screens some of you are getting: The emulator or flash cart might not be loading the .sfc into memory in the same order as intended. This could be my impetus to write Holy Striker Batman, which helps the user determine how the emulator or flash cart is arranging the ROM image into the S-CPU's address space.

I can't figure out how to create a working 64mb ROM. How do emulators know the ROM mapping scheme anyway? I'm thinking they don't support sizes bigger than 48mb.

Not even the "all mighty" bsnes?

How are you currently assembling it? Mode 25h, theoretically, should have the 4MiB portion resident in $C00000-$FFFFFF first, followed by the 3.8MiB portion resident from $400000-$7DFFFF (and including the canonical header, which should be mirrored into $00FFB0-$00FFFF by hardware), followed by the last 64 KiB resident from $3E8000-$3FFFFF (maybe with two missing holes in the file? maybe not?).

Espozo wrote:Not even the "all mighty" bsnes?

Older versions work. I tried it first in v072 and it was fine. And it's not the only one; no$sns works too.

Does the chipless hack of Star Ocean work in higan? Back in 2012, byuu posted a memory map for it (XML, not BML). What about other emulators? I know it works on both SD2SNES and PowerPak, but how?

When you say "older versions work" are you implying that it doesn't work on newer ones?

I already said that on the previous page. I tried it in higan v094 and it gave me garbage.

The thing is, bsnes underwent a change a while back whereby it ceased to support community standards natively and switched to a "cartridge folder" format with a complete description of the contents of the cartridge, including the memory map, packed in along with the ROM. It can still import normal ROMs, but apparently it isn't as compatible with whatever psycopathicteen is doing as the old interface was.

...

Mode 25 seems like it should be fine as long as the whole thing stays below 63 Mbit. I suppose that depends on what ends up being done with the music...

93143 wrote:I already said that on the previous page.

In other words, I might have to put codec development on hold to make a tool that displays what's going on in these emulators' memory maps.

Am I supposed to change the header? Would that fix it?

BTW, it does work in bsnes, but some parts of memory are inaccessible.

For mode 25h ("ExHiROM"), in the .sfc image, the header should begin at 0x40FFB0 (or 0x40FFC0 if it's not an extended header); the mode byte should be at 0x40FFD5, and it should either have the value 0x25 (2.7MHz = "SlowROM") or 0x35 (3.6MHz = "FastROM"). The rest of the bytes should be as I said in the previous post.

In contrast, Mode 21h "should" be limited to just 4MiB.

Espozo wrote:

93143 wrote:Difference between Mb and MB. The video data, as matters now stand, takes up more than 64 Mb (8 MB), and 32 kHz stereo BRR would take almost as much. So the lazy ideal case doesn't even fit in the memory map.

Oh... Well, I guess you could compress the video, but leave the audio in tact and it would maybe fit in a 96 megabit cartridge? (I'm not basing this on anything.)

You could create a version using the MSU-1 extension supported by SD2SNES, BSNES, and possibly NO$SNS?