Messages

31

FXPAK (SD2SNES) / Re: SD2SNES reads but doesn't write anymore

« on: June 25, 2018, 03:47 PM »

I can think of two scenarios:

1. The contact between the SD card slot's Write Protect pin and the microcontroller is broken.
2. The cards' LOCK sliders have loosened and slide into the LOCK position when inserted into the slot.

Given that you are also getting card detection errors with one of the cards it looks more like a contact problem, not only with the Write Protect pin but also with the Card Detect pin.
The two pins on the SD card slot are located at its right edge, see the attachments for general location and the routing of the PCB traces to check. The pins are named in the second attachment - WP = Write Protect; DT = Card Detect.

32

FXPAK (SD2SNES) / Re: gsu (superfx) support [work in progress]

« on: June 01, 2018, 02:58 PM »

I will start integrating it. It will likely take a week or so.

33

FXPAK (SD2SNES) / Re: Mario All Stars and Mario World problem

« on: May 20, 2018, 11:33 PM »

Are you running the PAL version at 60Hz (or possibly vice versa)? I know SMW has issues with the spot fade in the intro, and All-Stars pretty much everywhere because they adapted HDMA timing specifically to 50Hz for the PAL version and 60Hz for the US/JP version.

34

FXPAK (SD2SNES) / Re: Trouble playing Terranigma and Illusion of Gaia

« on: May 20, 2018, 11:31 PM »

Could be some odd misbehaviour in one of your SNES's components (like CPU or APU). Can you run the "Snes Burn-in Test Cartridge REV D"'s burn-in test and check the results? My gut feeling would be APU...

35

FXPAK (SD2SNES) / Re: gsu (superfx) support [work in progress]

« on: May 01, 2018, 04:24 PM »

But what discord? Where is it published?

36

FXPAK (SD2SNES) / Re: gsu (superfx) support [work in progress]

« on: April 24, 2018, 12:47 AM »

Very interesting. So originally you planned to have a save scheme similar to ED64v3 where it would hold save data until the next power cycle?

Indeed, and I still have it planned as a fallback. Could always happen that the power goes out or the SNES is switched off too soon while saving. Also for games that permanently keep changing the SRAM content it would be probably better to rely on than doing periodic saving.

37

FXPAK (SD2SNES) / Re: gsu (superfx) support [work in progress]

« on: April 23, 2018, 02:40 AM »

It's really great to see that spare 4Mbit RAM chip being dedicated to GSU. This is the first time it has ever been used for anything, isn't it? It's so cool that Ikari left it on the PCB for devs to utilize for projects like this. Keep up the incredible coding, Redguy

Well it's part of the design since day 1
It was intended to serve as a secondary RAM for custom chip architectures having two individual buses (GSU, SA-1) and also as battery backed save RAM to retain the save data until next power-up to be saved to SD card in case of a power outage while real-time saving, etc.
Joke's on me for not having put it to any use yet, of course.

38

FXPAK (SD2SNES) / Re: gsu (superfx) support [work in progress]

« on: April 20, 2018, 10:57 AM »

3. Do you really think sd2snes making cost is 200$? is much much less

Counter question: Do you want to work for free? If you think the manufacturing cost is all that makes up the price you are beyond naive.
Basically, all quality and cost factors aside:
1. you want to fuck me over (and krikzz): buy Chinese. Can't exactly blame you as far as I am concerned. But don't expect any more support or answered questions.
2. you don't want to fuck us over: buy from krikzz. 

39

FXPAK (SD2SNES) / Re: gsu (superfx) support [work in progress]

« on: April 17, 2018, 11:35 AM »

I briefly looked at the menu and can see that some stuff the editor probably relies on got shifted to higher addresses.  One fix would be to revert back to the old menu and use the cx4 speed option to control both the cx4 and gsu.  Another option is updating the menu editor or shifting around where stuff gets compiled into the binary.  I'm not looking to spend a lot of time on this so I may just hijack the cx4 speed option temporarily.

In case dotsarecool wants to adapt his editor, here are the locations of the relevant assets for v0.1.7e-gsu-v07: https://docs.google.com/spreadsheets/d/1ljoD-suzTlEfXzhR3gnzEeHQfPVFrVdpMRm6E_cvZNA/edit?usp=sharing

I also sent him a tweet about it.

40

FXPAK (SD2SNES) / Re: gsu (superfx) support [work in progress]

« on: April 17, 2018, 02:22 AM »

As far as I can see the core is already running at 21.429MHz which is as close an approximation as you will get with the FPGA's PLL. The FPGA gets a 24MHz clock from the MCU which is multiplied by 25/7 in fpga_gsu.bit, resulting in an FPGA clock of 85.714MHz which is in turn divided by 4 using a clock enable signal for the GSU core.

Alternatively you could choose to run from the SNES master clock which could get you intro trouble on PAL consoles because they only run at 21.28MHz instead of 21.477. And the clock signal is super jittery on PAL consoles. After all, even Nintendo soon chose to go with a dedicated on-board oscillator instead of relying on the SNES clock.

41

FXPAK (SD2SNES) / Re: SD2SNES keeps asking for time on boot

« on: April 16, 2018, 02:05 AM »

Maybe the RTC oscillator is stuck somehow. Can you try removing the battery, waiting a couple of minutes, then putting it back in?

42

FXPAK (SD2SNES) / Re: My SD2SNES cannot run ExLoRom game

« on: April 13, 2018, 01:46 PM »

Generally speaking the bit files don't rely on each other at all. It's just important that they all use the same firmware interface that matches the firmware.img

43

FXPAK (SD2SNES) / Re: gsu (superfx) support [work in progress]

« on: April 06, 2018, 10:45 AM »

Hopefully this will be merged with the official branch!

I definitely will if redguy has no objections
(Same goes for the usb2snes features btw but I haven't tried it out yet and I want to make sure it doesn't compromise any other features of the stock firmware)

44

FXPAK (SD2SNES) / Re: gsu (superfx) support [work in progress]

« on: April 05, 2018, 01:08 AM »

@iwasaperson
I had the same problem with a freshly pulled source tree. It now works after commenting out "`define DEBUG" in gsu.v:78.

45

FXPAK (SD2SNES) / Re: Implementing GSU Chip (SuperFX) in Verilog

« on: April 05, 2018, 12:00 AM »

Hi!

For possibly getting more memory for the SuperFX chip, have you thought about sharing the memory between the various cartridge-only chips that the SD2SNES implements?

It's not necessary: The firmware consists of several FPGA bitfiles - depending on the requested game it will reconfigure the FPGA with the corresponding bitfile. There are dedicated bitfiles for DSPx+BS-X+S-RTC, Cx4, OBC1, and now GSU thanks to RedGuy. So each of these cores already has the entire FPGA's resources available to itself.