PDA

View Full Version : SNES Burn-in Test Cart released



nensondubois
07-18-2010, 09:34 PM
The dumper (Thanks to i2a2n2 for dumping it... for free!) stated that it *will* work on hardware using a Powerpak, or a Game Copier. I do have three SNES consoles but no Powerpak or Game Copier to back up his claim, though he is trustworthy so I'm sure he's correct. I tried every the most popular emulators out there with no avail. Here is the unmodified copy sent to me by e-mail from i2a2n2). I'm posting it so someone else can take a look at it to fix so it works flawlessly. I tried a lot of tools, and I tried plenty of assembly hacking but I could not get it working without severe graphic glitches and the Super Scope menu to work.

http://www.mediafire.com/?xn92zq9s09l6vn4

badinsults
07-18-2010, 10:54 PM
Did it not even work in bsnes? It is probably best you talk with him if it doesn't, because there is no reason it should fail in bsnes.

nensondubois
07-18-2010, 11:17 PM
It did not work on Bsnes. I just asked him in the dumbest fashion possible. lol. I'm not as experienced as someone who has had more than a decade's worth of experience in SNES programming knowledge.

electrochip
07-19-2010, 05:36 AM
I just programmed it onto my custom cart and it works great on my SNES. The title says "SuperNES Burn-In Ver. 1.03". At first it comes up with a white screen until I press start then it begins testing work ram, dram...it does it very quickly then music starts up and various colored screens cycle through, while the music plays.

nensondubois
07-20-2010, 08:57 PM
Ok, so it does work on hardware. Thanks for recomfirming it.

OldSchoolGamer
07-20-2010, 11:09 PM
Maybe someone who has the means to download and play this on hardware could you go a step further and record the process or capture the output and upload a video to Youtube or something?

Enigmus
07-20-2010, 11:53 PM
Maybe someone who has the means to download and play this on hardware could you go a step further and record the process or capture the output and upload a video to Youtube or something?

This would be welcome, as the farthest I could reach into the game in SNES9x was the standard controller test, which I only managed to get through because the indicators of the buttons managed to appear, but without the instructions for exiting being visible, the only way out was resetting. That, and it'd be good to hear the Zelda II recording.

nensondubois
07-21-2010, 01:43 AM
It isn't a bad dump; the size of this test cart is too small so emulators just mirror the rom map to fill the space needed to run the game. To hear the Zelda recording just go to the sound module test. Use BSnes to see the Burn-in test in all it's glory. My cart works flawlessly as it should.

byuu
08-02-2010, 02:49 PM
Got a message from LuigiBlood about this as well, so I'll respond here.

It isn't a problem with the SNES hardware emulation, the problem is this game's memory map is weird. During bootup, it transfers in the data from strange memory areas that are beyond the size of this ROM.


06d800(035800) : 0200 : 22 - palette
0c8000(060000) : 4000 : 18 - VRAM tiledata
06da00(035a00) : 0220 : 80 - OAM attributes
0dc000(06c000) : 0800 : 18 - VRAM tiledata

The ROM is only 0x020000 bytes. All emulators simply mirror the ROM repeatedly to fill the whole area. But looking at where that ends up in the ROM, all you see is gibberish there. The actual graphics are stored at 010000 (font) and 014000 (sprites).

bsnes does have the ability to dynamically map any game in any way you like, via XML. Rename this file to snestest.sfc, and then put the below text into a file called snestest.xml:


<?xml version="1.0" encoding="UTF-8"?>
<cartridge region="NTSC">
<rom>
<map mode="linear" address="00-03:8000-ffff"/>
<map mode="linear" address="06:d800-d9ff" offset="035800"/>
<map mode="linear" address="0c:8000-bfff" offset="060000"/>
<map mode="linear" address="06:da00-dcff" offset="035a00"/>
<map mode="linear" address="0d:c000-c7ff" offset="06c000"/>
</rom>
</cartridge>

From here, you can control exactly what's mapped to the extra regions. I tried redirecting the VRAM writes to point to their 'obvious' locations I mentioned before, but to no avail.

If this works on a copier as-is, it's because the copier is performing some really, really strange memory mapping. If someone is really bored and has a SWC DX2, they can look at the ROM inspector and reverse the mapping, make an updated XML file above, and it should run just fine.