mrehkopf / sd2snes Goto Github PK

ikari_01 has told me that currently Satellaview ROMs load with a hard-set time.
I think it'd be a significantly better idea to allow the clock to sync with the sd2snes's built-in clock, which is adjustable from the menu, and thus be able to manipulate the time as you wish.

This is mostly impotant to the Satellaview Soundlink games, which all would "begin play" (as in the actual gameplay portion) at times ranging from 18:04 to 18:11, rendering a "standard" preset time to be not necessarily proper. This may also hopefully resolve many of the games that appear to take forever to start playing because their clocks are 00:00 or do not initialize.

A skin-able UI would be awesome. It doesn't have to be made easy to maintain all the feature, but being able to build the tilemap / graphics would be awesome.

My SNES is a PAL one with SuperCIC and IGR installed. The SuperCIC is wired with REG_TIMEOUT set to high, and i normally use it with force 60 Hz. Since the sd2snes detects the SNES as being a PAL one (I assume) it identifies as a PAL game, thus making the timeout trigger and show the sd2snes menu in 50 Hz for ~9 seconds on every boot.

This is quite annoying, and it would be awesome to be able to force the sd2snes menu to identify as a particular region, through a menu item or the like. (I could of course open the SNES up and rewire REG_TIMEOUT to low, but I quite like it this way when playing original cassettes.)

I assume this is sort of related to "supports software 50/60Hz switching on SuperCIC enhanced consoles only (to be performed by sd2snes firmware, not yet implemented there)", and perhaps will get added when that is implemented.

When Zero tries to use the ride armor, the whole sprite (zero + ride armor) is replaced by a small garbaged graphic. If he dies in this state, the game freezes showing alot of artifacts/garbaged graphics.
If he leaves the armor, everything returns to normal.

On emulator, this part plays fine, with no problem.

I apllied the ips patch with the Lunar IPS on an unheadered rom (CRC: FA0FE671)
Played on Super Famicom (first model).

When compiling the snes part, the snes/makefile complain about missing "sysinfo.o65" needed by "menu.bin"

Games that require a supplementary DSP ROM to be loaded from card will not run properly if the required file is missing. Display a warning message containing the name of the required file instead of just running the game and leaving it to crash.

Many sd2snes sold on the market have shells that conceal the LEDs so the LED blink codes cannot be seen. Attempt to play an acoustic warning when auto-saving fails for some reason.

When playing SPC files on Super Famicom consoles with 2/1/3 chipset and 1-chip design the first note is cut off a bit, in the same kind of way if the song had a very fast fade-in.
Older 2/1/3 PAL consoles do not exhibit this issue, neither do 1/1/1 Super Famicoms.

The other issue is the music sounding like the echo being stuck at maximum delay and volume values when playing SPC files dumped from "Kaite Tsukutte Asoberu Dezaemon" with a 1/1/1 chipset Super Famicom.

When trying to load "BS-X Shooting", after the Athena soft logo it will prevent me from playing with a "THIS GAME PAK IS NOT DESIGNED FOR YOUR SUPER FAMICOM OR SUPER NES" message.

The new 0.1.5 firmware seems to be having trouble with BS-X data packs with more than one software title. More specifically, only the first title of a data pack will boot correctly, all others will bring up the "Error 09" screen. Both PSRAM and FLASH-configured games are behaving the same.

Non-standard controllers like the Super Scope receiver input garbage data, making the menu uncontrollable when connected. Ignore input from such devices when detected.

As per the title, IGR works fine for all other games I have tested - just not with this one.

The Ultra16 has its own region patching circuitry that the sd2snes interferes with, producing an Error 6 or Error 7 on startup. This does not harm normal operation and can be safely ignored, but is annoying.
Detect the Ultra16 hardware and disable the sd2snes's region patching accordingly.

Despite the high resolution text display some file names are still too long to show completely in the menu. Implement autoscrolling of the selected file entry if it doesn't fit the screen.

Originally submitted by redeemer665, split from #26:

"The other issue is the music sounding like the echo being stuck at maximum delay and volume values when playing SPC files dumped from "Kaite Tsukutte Asoberu Dezaemon" with a 1/1/1 chipset Super Famicom."

Some error conditions, such as "card full" and "file not found" errors are not handled gracefully and are not reported to the user. This can result in unsaved games without the user noticing.

n Tetris Attack, in 1 Player Stage Clear mode, there is a wild flickering while you play, it’s strange, ’cause some foreground elements stay normal, while the background and other parts flicker. Only happens in this 1 Player Stage Clear.

All other modes look fine.

It’s reproducible.

I don’t have a real Tetris Attack cart to compare.

Seems strange, this is the only game I’ve play on SD2SNES that has weird flicker issues.

I'm using this firmware:
Firmware v0.1.7 preview 3

The src/Makefile reference a "cfg.c" file that does not exist in the repository.

This particular one crashes as soon as you try to get it to load from the BS-X.

As it's one that's very difficult to emulate (To the best of my knowledge only SNES9XPP XE emulates it), it's understandable, but... well, yeah.

The title pretty much says it.

As I just got this ROM to play on no$sns I was curious to see if it'd play on here, so I was pretty surprised to have it just... not... show.

Since the ROM itself doesn't seem to normally circulate in DATs (perhaps due to how it was previously unidentifiable), I will provide a ROM link here;
http://kiddocabbusses.tryhappy.net/BSZelda/BS%20Satella2%201%20(J).smc

Although I've heard mixed reports on it's compatibility, I myself have only seen it truly "play" on no$sns.

0.1.3. is fine but this has appeared in 0.1.4. (also present in the pre 0.1.4. release). During a match when the fighters get close to each other (it seems) there is a little bit of sprite glitching.

Some users report that the auto-saved Save RAM dump is empty (file size 0 bytes). Probably a file system issue but could not reproduce yet.

I've discussed this with ikari_01 over IRC already, but here it is up here so anyone else who wants to discuss it may know.

Certain ROMs may behave differently depending on whether or not the sd2snes is connected to a Super Famicom with a Satellaview hardware base attached, or a more standard setup.
Currently the known examples are the "BS The Legend of Zelda: Ancient Stone Tablets" ROM hacks, where they operate as expected on a sd2snes, but bug out when a Satellaview hardware base is plugged in.
I will note that on my previous ROM loader, the SFC Neo Myth, whether or not the Satellaview hardware was plugged in had no effect on the compatibility.

http://z9.invisionfree.com/bszelda/index.php?showtopic=1275&view=findpost&p=22000060

Add a menu option to start the previously run game.

The game should actually have 32 kilobytes of SRAM.
Other ways of spelling used in DATs: Ongaku Tsukuru Kanaderu, Ongaku Tsukuuru: Kanaderu

In pair mode the SuperCIC doesn't translate a double reset into a long reset. Hence, it has to be detected by the sd2snes. Detecting double reset is not a problem. The normal reset (combination L+R+Sel+Start) becomes a problem as a game resets while combination is pressed and hence the reset is retriggered if the games turn on automatic joypad read...

Some ideas from #44 :

• timeout, where no further reset pushes are allowed to occur after the second push (currently implemented in develop branch, but buggy)
• sd2snes pulls the reset line once a reset push is detected and releases just before reading the reset line again (dirty)
• Hijacking reset vector (might be difficult)
• Inject NOPs -> add an FPGA command that will cause the data lines to always return $EA when read (a bit overkill)

Even though this is just a straight redux of the original Super Bomberman with no discernible change from the original SNES release, which I think works fine on the sdsnes, no? ... For some reason the dump of Super Bomberman for the Satellaview crashes on sd2snes after selecting it from the BS-X Memory Pack loader.

When checking and calculating the checksum of BS-X software upon booting it should be done only on the data banks indicated by the size byte at 0x7FD0 (or 0xFFD0), instead of simply summing all bytes in the ROM image. This is especially crucial with 8M cartridge images which have more than one program.

However there might be something else as well as I did a quick test with "BS Satesupo DX Dai-4-Gou" (MD5: 442384ED70AF69F594C8CEC93E6DE81E) which has a size byte of 07h meaning the data is in the first three banks (3 Mb). Checksum is correct but it won't boot on sd2snes, it isn't giving me "Error 09" though.

When I change the internal size (0x7FD0) to FFh, ROM type byte (0x7FD9) to Full size (10h) and calculate a new checksum (5AD2, inverse A52D) everything works perfectly.

SRAM seems to be inaccessible to Ys III: Wanderers from Ys (and possibly others). Saving results in no change to the existing save slot; loading an existing save slow results in a crash.

Sd2snes menu is only controllable by controller 1 or 2, and not 3 through 5 with a multitap connected to port 2 (at least not with my HORI Multitap HSM-07).

This might seem like a non issue, but when my 3 years old son plays Super Bomberman 2 through 5, he usually wants to play as player 3, 4, or 5 (i.e. the fun colors red, blue, and green, as opposed to boring white and black) and does thus quite often play with a solitaire controller connected to port 3, 4, or 5, and nothing else. I haven't been able to teach him to switch controller port to 2 on the multitap for the menu and then switch back, which leads to lots of frustration, and I can't really see any reason why the menu couldn't be controlled by players 1-5 compared to today's 1-2.

It seems a good amount of Satellaview ROMs seem to have clock issues.
For my "Satellaview Stress Test" of sorts I've tried loading BS Tantei Club Kouhen, for example. I was excited to see the first screen from it, but it did not go beyond that - the timer stayed stuck on "??:??".
"BS Fire Emblem: Akanea Senki Hen Dai-1-wa: Palace Kanryaku" started at 00:00 which suggests an uninitialized timer.

Likewise, "Sound Journal for Lovers Valentine's Special Vol. 1" did not move an inch from it's first screen, although it's theoretically possible this may be from issues besides the timer, but I'm placing my bets on this.

It would be nice if the menu system would use the information in the rom header to figure out if the selected file has a chance of running on sd2snes or if it (seems to) require coprocessors that are not implemented yet. In the latter case it should display a warning message, giving the user a chance to run the file anyway in case the header is wrong or the user has some reason to try anyway.

It would be awesome to have the possibility to flag certain roms as favorites, and then to be able to filter by that. This would significantly help when browsing a large rom collection, so you could just flag what you for example currently play to find it quickly in the list instead of moving stuff around physically on the file system to a "currently playing" or favorites folder.

Easy way to implement this UI-wise would be to for example toggle favorite status with one button in the file browser, and then have another button switch between the file browser and a sorted list of favorites. Favorite status could be indicated with anything subtile in the file browser, like a small asterisk next to rom size, or anything similar. Toggling favorite status wile browsing the favorites list would also remove the rom from the list instantaneously.

(By the way, the sd2snes is awesome! Got mine yesterday and couldn't be more satisfied.)

With the recent font upgrade, the three dots in this line

text_spcload    .byt "Loading SPC data to SPC700...", 0

could be replaced like so:

text_spcload    .byt "Loading SPC data to SPC700", 127, 128, 0

Also, the status bar should adapt to the user's input:

• When the menu is opened, X:Menu should disappear.
• With an SPC playing, A:Select and X:Menu should disappear.

Probably related to e33fbdf
The menu cannot be controlled when run on the SHARP SF1.

This is in reference to Mottzilla's BS Zelda patch, which is designed to run on Real Hardware.
The hack has been previously tested on both the SFC Neo Myth and the SNES Powerpak, and as such to my knowledge this issue is specific to running it on the sd2snes.

A logged chat with Mottzilla has been provided in case it's helpful;

(09:52:42 PM) Kiddo: Hey Mottzilla... oh, wait, actually, I'll get back to you on what I was gonna say after I do an extra test, actually.
(09:55:15 PM) Kiddo: Ok, done the double-check.
(09:55:56 PM) Kiddo: Ok, so, on sd2snes your patch crashes before going into the save menu. You may want to discuss this with ikari.
(09:56:14 PM) Kiddo: Actually let me send that to him as well.
(09:57:10 PM) Kiddo: "<Kiddo|Laptop> hey ikari_01 highlight: BS Zelda Mottzilla patch crashes before going into the save menu on the sd2snes. This is yet another behavior that never happened on the Neo Myth."
(10:17:14 PM) [MottZilla]: you mean going to the main menu, after the title screen?
(10:17:22 PM) [MottZilla]: if so, thats the same behavior as ZSNES
(10:17:34 PM) [MottZilla]: which means its not mapping sram probably/as intended

Make it possible to delete files through the menu.

The bottom status line in the menu (currently showing button mapping and date+time) is far to the bottom of the screen. Some users report that it's not entirely visible.
Try to rearrange the menu screen layout so the bottom line can be moved up a bit.

Most cards support a 50MHz 3.3V interface. Use it when possible to gain a bit of headroom on MSU1 (and improve loading times).
This probably requires a rewrite of SD handling at firmware and FPGA level.

I noticed that the MSU1 video player included in the sd2snes source package doesn't work correctly on higan 094 (there's no sound to be heard). This seems due to the fact that the code doesn't set the volume.

Adding these lines somewhere in the msu1init routine (e.g. after line 15) fixed it:

    lda #$FF
    sta MSU_VOLUME

We should be aware that this means there exists a discrepancy in MSU1 implementation between sd2snes (where the music is played even without the volume register being set) and higan 094. ;-)

It would be nice if SD2SNES would support PAR/GG codes on games. Krikzz has been also implementing a load cheats from txt file on his everdrives as of recent which is extremely handy for lengthy codes. What would be ideal would be to setup a large flat file with identifiers such as the CRC or the header content and use YAML or something similar to have something much easier to manage.

close me

Implement a means to soft-patch ROMs using IPS patches before running.

Implement a function to select one of multiple SRAM slots when loading a game.

I get the "Error 09" screen when trying to boot this ROM through the BS-X.
This screen usually means the ROM failed it's checksum check or something like that, but checking this one in ucon64, and after having run it in bsnes once before if I recall right - I see no reason this should be happening.
I also got this issue on BS Dragon Quest, by the way, although I wouldn't prioritize that one as much due to it's "Strange" nature.

Shin Megami Tensei II on SD2SNES flickers on the world map walking near the buildings. This issue happens whether the game is patched for english or a clean rom. The patching however seems to make the flicker get worst.
It does not seem to flicker on any emulator however.
Thank you.

See http://youtu.be/VOkQUVGdh2k?t=1m24s
Thanks to kogami for recording.

First field reports indicate that with some cards the video player example application displays corrupted graphics. This is due to long response times after a READ_MULTIPLE_BLOCK command restart depending on the card.
Such restarts are currently abundant because non-sector-aligned reads trigger a restart even if they are sequential. Implement an access strategy to eliminate these double reads to alleviate this issue at least.

Probably not a good idea as you can play spc files too