A little follow up on my LED project. The little jackets were made with heat shrinkable tubing it completely eliminated any light escaping to the other LED's. View attachment 4115 View attachment 4116 View attachment 4117
Haha, you realize that the problem with light escaping for me is because the actual LEDs are maybe a half-centimeter removed from where the light comes out, right? If you have the actual LEDs coming out of the front of the unit, I can't see it being that much of an issue. Anyway, great job. How did you get the SD card slot cut so smoothly?
I went at it very gently, cut down the cart to the depth of the SD slot, scored a line the length of the slot a few times over till I had a deep line, used some linesman pliers to fold it over till it snapped off and sanded to finish.
Weird issue popped up. I'm not sure if it's the SD2SNES or a quirk in the game itself. I was playing Rockman & Forte (with English MMB patch) and saved. It saved just fine. Later on when prompted to save again I accidentally clicked no. From then on anytime I clicked yes to save the lights on the SD2SNES didn't flash and upon restarting I saw that the save file remained as it was prior to accidentally clicking no. Further saves didn't register during that play session.
Well, I had another corrupt save with Dragon Quest V. This time, though, I snapped the power off as soon as the ominous music played and the message box started to come up (so it couldn't write the reinitialized SRAM to SD), and when I tried turning it back on again, my saves were all right. So I'm thinking SD->SRAM is the problem here. I have been backing up my saves pretty frequently (up to 22 files now ), so it's not a major problem, but... Edit: ...And it just happened again not five minutes after the last time. Yikes. Once again, a quick hard reset stopped it from writing though.
@veggav: still working on SuperFX. Had to take a couple-weeks break to save my relationship though. At the moment I'm trying to figure out what still causes data corruption from SD to RAM (the SRAM corruption issue reported in this thread). As usual I can't reproduce it with my own hardware. @Eyedunno: Do you sometimes get intermediate text corruption in the sd2snes menu, which is positionally stable, like a certain corrupted file name that stays corrupted in the same way until you do a hard reset? Or maybe something that disappears when you browse back and forth? I'm trying to figure out whether it's SD->RAM or RAM->SNES that fails occasionally. Either way the problem with your sd2snes probably isn't limited to SRAM but will affect the ROM area too. I'm going to prepare a test ROM that calculates its own checksum. Meanwhile, although I know it's probably hard to reproduce, can you try and provoke the error with this bitfile? http://sd2snes.de/files/v0.1.5test1/fpga_base.bit Also it would be great if anyone could check that this doesn't break Star Ocean again.
Thanks, man! SuperFX would make a bunch of people happy as hell! hahaha BTW, finished Zelda Link to the Past on the SD2SNES latest firmware. Not a single bug whatsoever. The SD2SNES is stable as a rock under a bunch of rocks.
Am I the only one who would like to hear more information about how the process of making sd2snes superfx compatible proceeds and what goes into it and what is the projected outcome? Is the aim to make it very near or exactly 100% speed of original superfx games or is the aim lower, like emulating the games but at slower speed or with details removed? Is the hardware powerful enough for superfx? I honestly have no idea so please inform me was the sd2snes parts chosen with superfx in mind or is it just a possible bonus feature? I only know from machines that I´ve tried to emulate snes with that superfx games seem to be very challenging. Even my pc runs them only so-so, xbox is okayish but not perfect, dreamcast is definitely too slow... so sd2snes? I dont know. What do you think?
@Mendel Once Ikari said to me he had to rebuild SD2SNES pcb desing from scratch to be able to support all the enhancement chips. I know this may sound a lot of a challenge but the guy proved himself. Wait for the release of the super fx firmware test and ask for necessary fix. Until there just relax.
Okay, that sounds like a plan. One thing that I maybe didn't consider when comparing to emulators is that the sd2snes only has to emulate the special chip as of course the real snes the sd2snes is attached to will do a lot of things too
I don't remember seeing anything like that. I had the issue in the SPC player early on, but the newer firmware fixed that. And then since the SSFII graphics fix, I've had the weird graphics for a fraction of a second that I took to be the result of DMA initialization. But no, I don't remember any text corruption in menus that matches your description. I tried it around 30 times with no issues. Is this supposed to do something to detect the issue when/if it occurs, or is it an attempted fix? I will try it another 100 times or so later, but I'd say that it's pretty unlikely to happen based on my experiences so far, and I don't know if even 100 times is enough to replicate the results. If anyone else would like to try, here's a link to my latest srm file: http://www.filedropper.com/dragonquestv-tenkuunohanayomej Note that you'll need a clean, untranslated rom, obviously with the same name as this srm file. If, after a hard reset, running the game, and pressing A to get to the file menu, you get some music playing that sounds like something bad happening, followed by a box at the bottom that says then congratulations (?), you've replicated the problem. Otherwise, it will show a flashing cursor and which is the regular file menu (when 3 saves exist). Edit: Okay! Replicated the problem again with the new bitfile after about 60 or 70 tries (since the last time I tried)! I hope I wasn't supposed to leave it be and let it save the incorrect data or something; I instinctively shut it off as soon as I heard the "you're screwed" music and saw the big text box come up at the bottom, even though my save data has long since been safely backed up.
We're not talking software emulation in the same sense as the examples you've mentioned though. Mega Man X2 runs slowly for me in bsnes accuracy profile and more importantly X dies in attract mode after running around like a moron. And that's the most accurate emulator out there. On the latest SD2SNES firmware, he lives to kill the boss! This is actually emulating the internal logic of the chip in question and sending the results to the SNES with as correct of timing as possible. There has even been some talk of emulating an overclocked Super FX chip, though not from ikari_01 himself that I can recall. I think getting the correct timing (or very close to it) is the first step. Edit: Here is YouTube video of the Megaman X2 (or Rockman X2 in this case) attract mode. The first part is in ZSNES (though bsnes gives the same result, just that it runs much slower), while the second part is on a Super Famicom via SD2SNES:
Thanks! Next question I have is about SA-1. I mean, who wouldn´t want to play Super Mario RPG. When will it be... "determined"? It´s a pretty complex chip, I reckon. More so than superfx? oh and I think I now found a sort of an answer to one of my questions about superfx from the comments section of the sd2snes project status page So, more worried about it being too fast, that´s good! Always easier to slow it down than to bring extra performance.
Yep. And if you want to read through 38 pages of thread, several of us have already brought up SA-1. I consider it somewhat more important than Super FX, as there are more total games that use it, including Mario RPG and Marvelous, both of which are good games that basically require battery saves, and moreover the saves are not easy to dump from a cart to back up (unlike Super FX saves which can be dumped by normal means - old-school copier, Retrode, whatever). I personally own 5 SA-1 games, and every single one has a battery-backed save (as compared to one out of three FX games I own that has a battery - Yoshi's Island, and again, I can already back that up) - it would be nice to migrate to SD. But yes, it's probably more powerful/harder to implement than Super FX.
What is it that makes the save files unable to dump? Dezaemon save files are also unable to be dumped and that game uses no special chips, it also has a large SRAM.
