Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Wannado

Pages: [1] 2 3 ... 7
Support / Re: Gameboy saves no longer transfering to the Retrode
« on: 01/Apr/2018 08:21:19 PM »
Hi Nori, I just noticed that I have the FFA game, too, only with its European title "Mystic Quest".

The game's mapper chip has exactly 512 half-bytes of RAM built-in. They appear as 512 bytes, with only the lower half of each byte having actual storage on the chip. The Retrode detects that correctly.

I'm using the KiGB emulator, version 2.05, which too creates an 8 kiB save file for that game. The game still only uses the first 512 bytes of it, so the rest of the file is garbage (it's quite obvious in the file that I had once saved).

Long story short, to copy your emulator save game of FFA to the cartridge, try using a hex editor to copy only the first 512 bytes from the emulator save file to the Retrode save file.

Note: IIRC, the Retrode shows the unused upper half of each byte as hex F while KiGB seems to prefer 0. This should have no effect when copying from the emulator file to the Retrode file. I don't remember if it's a problem when copying in the other direction, from the Retrode to the emulator file.

Support / Re: Gameboy saves no longer transfering to the Retrode
« on: 25/Mar/2018 07:58:41 PM »
Edit: Nori posted reply #3 while I was still typing the text below. So the problem seems to be the file size and not what I had guessed.

The problem might be this: For the transfer to work, the save file that exists on the Retrode must be overwritten "in place": Open file X, overwrite data, close file X.
Your PC might instead be trying to create a new file Y, fill it with the data, close file Y, delete file X and finally rename file Y to X.

The latter does not work with the Retrode. It fails in the first step (create new file Y) because there is no free space. The Retrode has not enough memory to buffer a temporary file, and it cannot tell where else the data should go (config? save? ...).

Please try the following and tell us if it worked:
First, check that the save file on the Retrode is exactly the same size as the save file that you want to copy over.
If the sizes match, "delete" the save file on the Retrode. This will only remove the file's directory entry and mark the area where the file is mapped into the Retrode's virtual volume as free. The actual save on the cartridge will not be harmed.
Finally, copy your new save file to the Retrode. This should cause the PC to write the data to the proper area.

Warning: In the time between deleting the Retrode save file and copying the new one, do not edit anything else on the Retrode.

General Discussion / Re: Remapping the buttons?
« on: 04/Mar/2018 11:42:41 PM »
Sorry, while I still have this thread bookmarked, I don't know if and when I will contribute to the firmware again.

But maybe someone else might implement this. So if I understand you correctly now, you're asking for a config option that enables you to assign the buttons to different positions in the list.

First idea: Listing the button positions for Start Mode A B C X Y Z in that order.
The configuration from your first screenshot would look like this:
Code: [Select]
[mdButtons] 3 2 1 0 4 6 5 7And for the second screenshot:
Code: [Select]
[mdButtons] 6 7 2 0 1 3 5 4
Second idea: Listing the buttons in the requested order (first = button 0, last = button 7), using the letter S for Start and M for Mode/Select:
First screenshot:
Code: [Select]
[mdButtons] BAMSCYXZSecond screenshot:
Code: [Select]
[mdButtons] BCAXZYSM
Is that what you're asking for? Which idea do you like better?

Support / Re: Cannot grab sram from Game Boy Camera
« on: 01/Feb/2018 10:32:46 PM »
Yes, Gameboy Camera was tricky and handled different from normal carts.

From my notes on my Arduino GB reader:
WR, RD, CS must be low to get valid header
Hold CS low for read/write operations

That's a strange combination, pulling WR and RD both low. Do you know if (and why) a real GB would do that? Before v0.19 beta, the Retrode actually did it, but I'm sure that was unintentional.
Anyway, this interesting feature would explain why v0.19 beta and later cannot read the GB Camera. Quoting myself from the commit log:

Fixed issues with GB SRAM access: (...)
- Pulling /CS low when writing to mapper register address 0x1EFF caused SRAM to be corrupted. I read on the internet that /CS is required for SRAM access, but optional for ROM access. It seems that some MBCs take /CS to select SRAM even if the address is outside the SRAM range. I therefore guess that the real GB pulls /CS low only when accessing SRAM, not when reading ROM or writing mapper registers. And so does the Retrode now.
- Due to confusion about the port bits assigned to /CS and /RD, gbWriteByte allowed /RD to stay low while pulling /WR low as well. This caused SRAM writing to fail on MBC2.

Note that the SRAM corruption was hard to spot (only one byte changed, often an unused one). But my Kid Icarus savegame was affected noticeably.

Since reading the header neither requires writing to 0x1EFF nor to SRAM: Could the solution be to let auto-detection read the header as if it were a GB Camera, then chose the appropriate r/w methods based on the detected cartridge type (from the header)?

Support / Re: Cannot grab sram from Game Boy Camera
« on: 28/Jan/2018 10:46:48 PM »
@hadess: Wren's broken plug-in also worked for quite a few things. The GB camera may just be more picky about some input voltage than your other cartridges.

@hadess, skaman: Since even the ROM header appears as garbage, the only firmware issue I could imagine here is something about the control signals like /CS etc. (timings, ...?). But why would only the GB camera notice it?
I remember that in v0.19 beta, I fixed GB SRAM bugs related to the control signals (see my commit message).

Support / Re: Cannot grab sram from Game Boy Camera
« on: 01/Jan/2018 09:11:04 PM »
I couldn't get the SRAM file at all from mine. Using the 0.20 Beta firmware that my Retrode 2 came with, I could only see a 1.2 megs "" file on the Retrode. It works in 3 different Game Boy types, and I cleaned the contacts with alcohol first, then contact cleaner as a second pass, having removed the cartridge shell.
This is hexdump's output for those values:
00000140  59 7f 7f 7f 36 31 7b fc  75 76 7d 33 7f 9d ba f9  |Y...61{.uv}3....|
No .sav file, the ROM is "".
00004000  f2 59 fb 59 76 5a 6d 5a  56 5a 4f 5a aa 5a d1 5a  |.Y.YvZmZVZOZ.Z.Z|
00004010  6a 53 53 53 4a 53 4d 53  52 53 57 53 74 53 8d 53  |jSSSJSMSRSWStS.S|

The data you posted doesn't look like a valid GB ROM to me (though I'm not a GB ROM expert). The only value that looks good to me is "fc" at offset 147, which identifies the GB Camera as such.

Since you cleaned the cartridge's contacts, please also check the other connectors involved for dirt and damage: both connectors of the plug-in as well as the connector of the Retrode.

For example, Wren had a plug-in with broken ground pin on the GB connector. See gb-pins-small.jpg attached to the post,338.msg2296.html#msg2296 (reply #8 in that thread). See also my reply (#10) in the same thread.

Is anybody developing a NES cart adapter for the Retrode2?
I know another forum mentioned it, but I believe this should have its own topic. EPIC want!

I once created a prototype and a special firmware for a Retrode NES plug-in. It works well, but the prototype's design is not ready for production of even a small batch. My progress became slower and slower until I finally halted my work on everything Retrode related earlier this year. And I still cannot tell you if and when I will resume it.

If anyone wants to pick up where I left off, see these posts:

General Discussion / Re: Adaptors
« on: 01/Nov/2017 11:28:10 AM »
I apologize if this has been asked before, but does the N64 adapter support Rumble Paks?

When I added firmware support for the N64 Controller Paks (memory cards) years ago, I also tried to implement detection of Rumble Paks. But I didn't get it to work. My Rumble Pak was always detected as an empty memory card.

I'm not aware of anyone trying to add Rumble Pak support, so it probably still doesn't exist in the Retrode firmware.

To implement it, one would need to know what commands the Rumble Paks accept (transmission of commands should work the same as for the memory cards), and also how to make the rumbling functions available through the USB HID interface so that they work with appropriate APIs (Force Feedback?). And finally, emulators would need to use those APIs to emulate Rumble Paks. Even if all that was done, the rumble might still not feel the same (literally) as on original hardware.

Another solution might be to work together with emulator devs and create some kind of tunnel through the Retrode for an emulator to communicate with an N64 Controller and its attachments directly. This would provide the most accurate experience, I guess.

Sadly, I don't have time to explore this interesting topic any further. Anyone else?

General Discussion / Re: Finally: New Plugins in stock
« on: 27/Jul/2017 10:05:43 PM »
Well, if it was only the PCB layout, I'd probably have done it myself long ago. But there are a few issues with the prototype design that I wanted to solve before creating the production PCB:
  • The prototype connects NES signals CPU R/W, PRG /CE, PPU /R and CPU M2 (cartridge) to MD signals VA20 .. VA17 (Retrode). The Retrode can change all of those signals at once. IIRC, connecting M2 to VA17 also had the reason to minimize the total wire length of the M2 connection in the prototype.

    The problem here is that CPU M2 is high active. The current initial state of the Retrode has VA20 .. VA17 all high, which could cause a NES cartridge to enable outputs of an SRAM chip, if present (connected to the lower data byte MD pins). Initializing VA17 to low might not be ideal either, because that would enable something on SMS cartridges (/MC-F). So, VA17 wasn't the best choice for M2.

    The Retrode 1 has gamepad signals on VA20 .. VA17. They are also connected on the N64 plug-in.

  • In the prototype, NES signal PPU /W is pulled high, not connected to any MD signal. But there's a game which uses CHR RAM for savegames, and PPU /W would be required for writing to that CHR RAM. So I wanted to add a connection for PPU /W. It might also be useful for detecting whether a game has CHR ROM or CHR RAM.

  • I considered connecting the NES signal CIRAM A10 to the GND pin A32 of the MD connector, which the Retrode uses for cartridge detection. This might allow the Retrode to quickly and easily detect that the connected cartridge is a NES game, and which mode of "nametable mirroring/arrangement" it uses (an information for the .nes file header). But I can't say for sure that it would work with all NES games. E. g., some mapper might block the signal until initialized.

  • I considered reordering some of the address and data lines to make routing easier (more parallel, less crossing wires). The firmware would have to reorder the address and data bits accordingly.

  • I never measured the power consumption of the Retrode with a NES cartridge inserted.

Nevertheless, having a professional designer create the new PCB layout seems like the only realistic way to get it done soon. So, go ahead. Maybe the designer can prepare the PCB for later modding with respect to the above mentioned issues. Or maybe someone else with good knowledge of the NES and Retrode has suggestions how to address those issues.

I'll try and help as much as I can. I'll send you a PM with additional information.

See the files attached to my original post about the prototype. The relevant schematic is "retrode-sega-to-nes-without-ics-v2a.sch". The "... pin assignments.txt" file contains roughly the same information. The lbr files will be required for making the PCB (brd file), too.
The files "nes-and-sega-to-pads-v3a.*" describe the prototype PCB and are quite useless for the new design.

General Discussion / Re: Things I'm currently working on
« on: 14/May/2017 12:29:47 PM »
Hi, this is Wannado again.

The bad news

My plans have once again been defeated by reality. I've been incapable of working on the firmware code for the past two weeks and have no idea when I will be able to resume my work on this project. I didn't even finish the config file optimization so far. :(

The good news

In the meantime, two other people have started/resumed work on the code. One of them is skaman, who has made quick progress expanding SNES game support (see his post for details). Great job, skaman! :)

skaman's fixes regarding HiROM/LoROM SRAM bank switching (for Brain Lord, The 7th Saga, ...) will probably render features 1 and 2 from justin89's patch obsolete. Features 3 and 4 (see my OP) are still worth merging.

Dear Retrode community,

in this post, I'd like to tell you about my recent activities and my plans regarding the Retrode firmware.

justin89's patch

You may have heard about the patch that justin89 submitted long time ago. I want to finally try and merge it into the firmware, step by step. To simplify that, I've split the patch up by the features it contains:
  • A way to force HiRom or LoRom addressing for SNES games.
  • A way to read/write the saves of the SNES games Brain Lord and Robotrek.
  • Support for reading/writing SRAM and Flash saves of GBA games. (Also FRAM saves, but with issues.)
  • Support for reading/writing SRAM saves of N64 games. (Also reading FRAM saves, but the results don't seem correct.)

The small features 1 and 2 will be included (in a modified form) in the next release I'll publish. Superseded by skaman's work. See also "Plans" below.

Config file optimization

At the moment, I'm optimizing the config file. This is motivated by justin89's patch (which includes new config options) and other things.

To save buffer space, I've removed most of the help comments from the config file. As a replacement, I want to add a separate help file with more detailled descriptions (compressed, read-only). However, the current draft is still rather large even in compressed form. Apart from that, I've reduced the size of the parsing and printing code significantly.

Still issues saving to Phantasy Star IV and Shining Force from Kega Fusion

After the release of v0.21-beta, gliitch had reported that saving in above Mega Drive games still doesn't fully work for him (using Kega Fusion). The issues are the same as with v0.20-beta. Despite gliitch's assistance, I haven't been able to find the cause of the problems yet. See also below.


These are the things I'll try and do in the near future when possible (see reply #7 below), approximately in that order:
  • Finish the config file optimization (hopefully this weekend).
  • Add diagnostic features to help analyze the Kega saving issues (maybe this weekend or the next).
  • Make a new release before the end of April.
  • Take a closer look at features 3 and 4 of justin89's patch and maybe merge them (hopefully in May). Make a new release afterwards.
  • Continue work on the NES plug-in (possibly starting in May):
    • Design improved PCB.
    • Attempt to integrate support into the standard firmware.
    • Maybe improve SRAM battery detection.

Support / Re: Using the Retrode2 with a 32X and a 32X game
« on: 19/Feb/2017 12:29:46 PM »
Because the 32X was designed to fit onto a Mega Drive, and because the shapes of the Retrode's and Mega Drive's cases are different, plugging the 32X into the Retrode (with case) might fail. For example, if the 32X extends too far back, it will collide with the Retrode's lid. Or the Retrode's case might be too high for the 32X to reach the slot contacts.

So you might be forced to take the Retrode's PCB out of its case in order to be able and plug the 32X in. I guess that's what Aleron Ives was trying to tell you.

There are screws on the bottom of the Retrode that allow you to open the case without harm. I suggest that you handle the bare PCB carefully (avoid touching contacts/solder points with your fingers). Maybe you can leave the PCB in the bottom half of the case, only removing the top and lid. Of course, unplugging the 32X may not work without touching the PCB directly.
If the problem is only the lid, you can close the case again after removing the lid.

Another advice: Connect the 32X and cartridge to the Retrode before connecting the Retrode to the computer. Disconnect the Retrode from the computer before disconnecting the 32X or cartridge.

When you're done dumping the 32X games, you can put all the Retrode's parts back together and it should be as great-working as before. ;)

Since one of the threads you linked refers to Brain Lord: A long time ago, justin89 provided a patch which he said includes "a way to read/write SNES Brain Lord and Robotrek saves" (among other things). I didn't manage to merge that patch yet.

A lot has changed in the firmware architecture since the revision that justin89's patch is based on, so the merge isn't trivial.

And there, I'm right out of time for another week.

General Discussion / Re: Feature suggestions
« on: 05/Feb/2017 11:31:30 PM »
Note that "deleting" the ROM file from the Retrode's file system (e. g. by "moving" the file) may cause issues when trying to write the config or SRAM file afterwards.

Nevertheless, I'll consider adding a config option to control the ROM file's read-only attribute.

The Retrode is easy to use. It's the games that cause trouble. ;)

Saves: The issues with the Mega Drive/Genesis saves have been discussed recently, and I have just uploaded my second attempt to resolve them: v0.21-beta
Remember to set "[sramReadonly] 0" in RETRODE.CFG if you want to modify the saves on any cartridge.
And you will need to set "[segaSram16bit]" as appropriate for your emulator/the format of the file you are trying to copy.

Sonic 3 & Knuckles: The Retrode firmware includes special code for that game, so it has probably worked once. The save size for it has been wrong, but I've hopefully fixed that in v0.21-beta. I cannot test it though.

Pages: [1] 2 3 ... 7