Recent Posts

Pages: 1 [2] 3 4 ... 10
General Discussion / Re: SNES Enhanced Cart Support (FW v0.22)
« Last post by corralblack on 12/Apr/2019 02:41:50 AM »
Were the PCB files and/or BOM ever released? I would love to build my own.

Keep up the great work!
Support / What is the extent of GBA support with the GB Plugin?
« Last post by Cadethian on 10/Apr/2019 04:43:19 PM »
I recently got my Retrode 2 and now I'm thinking of getting the Gameboy plugin. It will be useful for my old Pokemon saves to be able to back them up before changing the battery.
The question I have is to what extent is this supported for GBA games? Would I be able to dump and then restore the save files for games like Pokemon Emerald or Leafgreen? From what I can see poking around the boards, the answer seems to be "no", but I want to ask to confirm.
If it's not possible to rip or restore saves for GBA games, what are the prospects of this being supported with a firmware update in the future?
Thanks for the help!
Nice work documenting the issues.  I haven't worked on any of the GB/GBC/GBA code.  There are a lot of things that could be improved.  If you're up to fixing the code, then definitely contact Matthias.

If you start working on those consoles, then you'll see the missing support for the various mappers and save types.  The small project can become a large one very quickly.
I suppose… In a way, I don't want to implement the fix myself, since I'd be tempted to make it properly correct and not just put a band-aid on it – which might take a lot of time and work. But… on the other hand, I guess I wouldn't be opposed to making sure it gets done right, and I do know the ins and outs of the issue.

Where can I get in contact with Matthias?
You may want to reach out to Matthias to see if you can get the Retrode's source code to implement the fix. That is, of course, if you have the time/desire to do so.
The problem

Lately, I've been researching an as of yet obscure Game Boy cartridge mod, where you switch out the SRAM chip for a non-volatile FRAM chip, effectively making the cartridge's saves immortal. Long story short, to make this mod compatible with some of the more obscure features of the Game Boy, the memory's chip enable pin has to be connected to an OR of the normal signal (the MBC's ¬RAMCS) and the cartridge bus's clock signal (CLK), meaning that the RAM chip (¬CE) is only active when both of those are low. This works A-OK on console – both saving and loading work perfectly! However, the Retrode (firmware version 0.25) can neither read nor write successfully to the saves of these modded cartridges.

The symptoms are awfully strange: writing overwrites every byte with 0xFF, and reading turns all 0x00s (and only 0x00s!) into 0x02! This screamed "timing issue" to me, so I checked out the signals, and indeed – the Retrode pulses the signals completely unlike the Game Boy does!


I connected up an oscilloscope up to both a Game Boy Advance and to the Retrode to compare how they pulse the signals when reading and writing SRAM. Check out the results!

YellowCLKThe console's generated clock signal. Constantly pulses on console. Pin 2 of the cartridge connector.
Pink¬RAMCSThe MBC's "activate SRAM" signal. Active low. A pin on the MBC (which one depends on the MBC).
Blue¬RDPuts the save memory into read mode (or not, depending on MBC). Active low. Pin 4 of the cartridge connector.
Green¬WRPuts the save memory into write mode (or not, depending on MBC). Active low. Pin 3 of the cartridge connector.



A one-byte read from an MBC5 game on console running in double-speed mode:

¬WR is constantly inactive, ¬RD is constantly active, and CLK pulses at a constant rate of ~2.1 MHz (as it always does). ¬RAMCS goes active for ~400 ns. Not pictured is that the Game Boy samples the data lines at the midpoint of CLK being low while ¬RAMCS is active.


In comparison, two bytes (I think?) read from an MBC5 game on a Retrode:

As you can see, it looks quite different. For starters, ¬WR is constantly asserted active alongside ¬RD, which is a bit befuddling – ¬WR shouldn't be active when reading. ¬RAMCS goes active for ~9 µs, during which CLK pulses 10 times. CLK doesn't pulse outside of ¬RAMCS being active. When the Retrode samples the data lines I don't know, but given that CLK pulses ten times, I wouldn't think it's in the middle of any specific one of those.



A one-byte write to an MBC5 game on console running in double-speed mode:

CLK pulses at a constant rate of ~2.1 MHz (as usual). ¬RD goes inactive at the same time ¬RAMCS goes active. The next time CLK goes low, ¬WR goes active with it. ¬WR goes inactive a little bit later, after which ¬CLK goes high and brings ¬RAMCS to inactive and ¬RD active with it. Not pictured is that the Game Boy makes data available on the data lines at the same time as ¬WR goes active.


A one-byte (I think?) write to an MBC5 game on a Retrode:

I don't quite know what's going on here. At the beginning of the entire length of bytes written, ¬RD briefly goes active (probably just incidentally), after which it goes inactive again and stays that way for the rest of the write. ¬WR is constantly active. ¬RAMCS goes active for ~10 µs, during which CLK pulses 10 times. ¬RAMCS then goes inactive again, and… CLK pulses 10 more times? When the Retrode makes the data available I haven't checked.

For a more formal reference for the console timings, see appendix C of GB-CTR. To note is that GB-CTR uses the name "PHI" for the signal called "CLK" above, and that it documents normal-speed mode – multiply the frequencies by 2 to get the timings for double-speed mode.

The fix

The technically correct fix for this is, of course, to rewrite a bunch of code and make the Retrode's timings more or less match those of the Game Boy. The specific lengths of the pulses aren't immensely important – after all, the Game Boy Color can run at twice the speed of the Game Boy – but the order of rises and falls is. This way, the Retrode is guaranteed to be timing-compatible with anything that works on console. However, the particular case I mentioned can be solved with smaller modifications.

The reason reading doesn't work is probably because the data lines are sampled either while CLK is high or hasn't been low for very long (thus trying to read while the chip is disabled or not ready) – so moving that sampling to a time when CLK is low (and has been low for at least 100 ns) would fix reading.

As for writing, I'm not sure what exactly the issue is! It may be the same thing there – the Retrode could be making data available while CLK is high or similar.

I'd also recommend only one CLK pulse per byte read/write – it's not strictly necessary for this case, but… the current 10× pulse behavior is weird, and might waste memory write cycles when that's wired up to CLK.

I hope that this can be fixed soon! As the batteries of MBC5 games run out in greater and greater numbers, and word of this mod gets out, I expect mods like these to become more pervasive. It'd be nice if the Retrode could handle it correctly!
Support / Re: Cannot get n64 plugin to work.
« Last post by newbie2 on 05/Apr/2019 01:29:56 AM »
Nothing additional comes to mind. I just updated to .25a and tested on a mac, but mine is working fine. Maybe reach out to dragonbox and ask them to verify that the plugin is working for them?
Support / Re: Cannot get n64 plugin to work.
« Last post by mrhappyasthma on 04/Apr/2019 04:59:01 AM »
My existing configuration is:

Code: [Select]
; Retrode .25a-beta - Config
; Remove any line to revert setting to factory default

[HIDMode] 2 ; 0: Off; 1: 4Joy+Mouse; 2: 2Joy; 3: KB; 4: iCade
[blinkControllers] 1

[nesMode] 0         ; 1: NES gamepads; 0: SNES

[filenameChksum] 1  ; checksum in filename? 0=no, 1=yes
[detectionDelay] 5  ; how long to wait after cart insertion/removal
[saveReadonly] 1    ; write protect save? 0=no, 1=yes
[segaSram16bit] 1   ; 0=no, 1=yes, 2=y+large
[sramExt] srm
[snesRomExt] sfc
[snesOverdump] 1    ; overdump correction? 0=no, 1=yes
[snesRomVer] 0      ; version instead of checksum? 0=no, 1=yes
[segaRomExt] bin
; Override autodetect:
[forceSystem] auto
[forceSize] 0
[forceMapper] 0
; Optional plug-ins:
[n64RomExt] z64
[gbRomExt] gb
[gbaRomExt] gba
[smsRomExt] sms
[ggRomExt] gg

Updating the forceSystem to n64 does not do anything different:
Code: [Select]
[forceSystem] n64.

Support / Re: Cannot get n64 plugin to work.
« Last post by newbie2 on 03/Apr/2019 12:54:32 PM »
Sorry I was thinking of another system. Regarding orientation, at least on the ones Matthias made the instructions were correct and the n64 game works oriented with its label on the same side as the label on the plugin (so label facing out).

This should be more pertinent: Is [forceSystem] set to anything other than auto? Could you see what happens to set it to n64?
Support / I need help getting Final Fantasy Tactics Advance to work
« Last post by cpwzhr on 03/Apr/2019 08:34:41 AM »
I am not able to get Final Fantasy Tactics Advance (for GBA) to boot in an emulator. The game worked fine on an actual GBA so I went searching for an answer. The solution that has worked for many people encountering issues with GBA games is to edit the RETRODE.CFG and set [forceSystem] to "auto" and [forceSize] to "16" (16 MB in my case Final Fantasy Tactics Advance is a 128mbit game). I still can't get the game to boot I just encounter a black screen. Any suggestions?
Pages: 1 [2] 3 4 ... 10