NES cart dumping/plug-in

[Muzer]

Is the firmware written in C, or have you been coding directly in whatever assembly language it uses? If the former, that would make it a whole lot easier - I was always just assuming it was the latter, and I've no idea why I was .



I'm reasonably competent with C, and I have used a microcontroller (but cheating a little, an Arduino, and nothing nearly as complex as cart dumping). Perhaps I should have a go once I've learnt a bit more - I'll stick with making this DB first as it should prove a lot easier.

[Matthias_H]

The source is 99.9% C (pretty much everything apart from some NOPs, that is).

[nitro322]

Is the firmware source code available?  I only recall seeing the binaries on the website.

[andwhyisit]

Peter C
March 20th, 2012 at 6:48 pm

Those look awesome. I can't wait to give you money for the production version.

Out of curiosity what were the technical limitations for NES plugin that you mentioned?

PC

Matthias_H
March 20th, 2012 at 6:58 pm

None of the autodetection would work. You would have to manually specify PRG ROM size, CHR ROM size, mapper chip and SRAM size for each cartridge you put in. Doesn't sound like you'd actually want to do that — and if you would, you could probably build your own plug-in too.

Ness and Sonic
March 22nd, 2012 at 5:23 am

I can see your point about NES being a pain. If anyone's wanting an idea about the games and their mappers, I came across this incomplete database: http://tuxnes.sourceforge.net/nesmapper.txt

Matthias_H
March 22nd, 2012 at 5:35 am

Yeah, I'm aware of this database. Still, I can't seem to think of a smart way to look up table entries without knowing the game title. A camera + OCR processor integrated into the plug-in (to read cartridge labels) seems like a bit of overkill.

Muzer
March 22nd, 2012 at 7:09 pm

Is there no game title in some easy-to-access place in the ROM, then? Or any other uniquely identifiable information?

Actually, just looked it up a bit more – looks like you should be able to checksum the first few KB of the NES ROMs (which, the internet implies, are read in the same way), and compare it with a list that someone (could be me) has generated. The only issue is, would such a database actually fit into the limited memory capacity of the Retrode device?

Matthias_H
March 22nd, 2012 at 7:53 pm

Memory shouldn't be an issue – the plug-in itself could contain an additional flash ROM / EEPROM chip for this purpose. Still, sounds like a horrible lot of work to me.

Muzer
March 22nd, 2012 at 8:41 pm

Generating the DB shouldn't be particularly hard, though – I think I'll give it a try some time soon. I'll just use some simple checksum on the first couple of kilobytes, hopefully enough to be unique.

andwhyisit
March 28th, 2012 at 12:36 am

I can see this creating any number of false positives. Plus a database would be annoying to maintain.

Just dump only the first bank by default, place the checksum in the filename, then allow up to 10 NES filename/PRG ROM size/CHR ROM size/mapper chip number/SRAM size configurations in the config file. You can check what the generated filename would be, then you can look up the configuration to see if the filename was recorded and then load the associated configuration for dumping the file. This preserves the plug and play aspect for up to 10 different carts.

Muzer
March 30th, 2012 at 8:02 am

Annoying to maintain? How many NES games are being released nowadays?

Your suggestion would work, but I don't see how a database would be much harder. It will be relatively-speaking trivial for me to generate one without any human input.

andwhyisit
April 3rd, 2012 at 2:15 pm

To obtain the checksums for the database you would have to dump the beginning of the game, calculate the checksums yourself, send it to Matthias, and wait for him to submit an update to the plugin's firmware, which would now be much more expensive because of the additional hardware to store the required database. It's inefficient. If you want a database then how about adding one to the site? This way retrode users can look up their NES configuation sets and can just copy them to their retrode config.

Matthias certainly isn't going to go out and buy or pirate the entire NES library for the sake of creating a database, nor will he accept a dump of the first bank of a game to calculate checksums, so it is down to users to dump the first bank and calculate the checksums, so the database will always be incomplete.

The way I suggested is more efficient, cheaper, easier to implement, flexible, more user friendly, doesn't require constant updates to some database (which may or may not be possible under the current retrode hardware) that will fail you the moment you insert some cart into the retrode that shares its checksum with more than one database entry, and will work for every single cart whose mapper is supported by the retrode.

Plus, unlicenced NES games are still released to this day if that answers your question.

Muzer
April 4th, 2012 at 11:01 am

I never at any point stated nor implied that Matthias would be the one making the initial database. In fact, I've already said that I will try to make one at some point in the near future.

Homebrew NES games have been released, true, but few on actual cartridges – and besides, those aren't exactly in the scope of what the Retrode was intended for.

andwhyisit
April 5th, 2012 at 1:00 am

I wasn't only talking about homebrew titles but also the stuff that is churned out of taiwan or china. But regardless the problem is, as I said before, that the database requires additional hardware (so it would be more expensive to produce the plugin), that we don't even know how the damn thing would be updated, the risk of false positives in the database, and if the game isn't in the database or you get a false positive then you would have to override default plug and play functionality with your own settings, rendering the whole exercise useless since you would need to mess with settings to switch between games, a notion that Matthias was trying to avoid.

Can you state even one flaw with my suggestion?

Matthias_H
April 5th, 2012 at 3:00 am

Guys. This fistfight of yours could amuse a much larger audience if presented in the right venue. Why don't you take it to the forum?

Aaaand here we are.

[Matthias_H]

And here comes his challenger, Muuuuuuuuuuuuuzerrrrrrrrrrrrrr....

(crowd cheering)

[splitzjc]

I'm just curious as to what skills are needed to take such a project on. Is it just C programming and soldering skills? Am I missing anything?

[Muzer]

(Sorry I took so long to reply, but I'm on holiday with limited access - I was about to make a post just yesterday, but my account timed out and I almost lost it. Luckily I grepped through my RAM and the message was almost all still there. Ah, the power of Linux, couldn't have done that easily on Windows )


It requires knowledge of how the NES works and ability to code in C to make the software side, and it requires soldering skills to make connector prototypes. Finally, it requires electronics knowledge if you're going to implement a flash chip too, and PCB-making knowledge to make the final design. I don't have many of those






Anyway, back to the database issue - I think it's simpler for the users not to have to know/know how to extract that information from their cartridges. Plus, I believe it was stated recently that the config file is fast running out of room, so even 20 lines for custom games might be too much.


In fact, I would suggest a combination of both solutions - the database-on-a-flash-chip for most games, then your solution for anything not in the DB.


Anyway, Matthias is right - it's all trivial if we can't find someone to actually make the hardware/Retrode firmware. I'm sure I could probably help a little bit but I highly doubt I'd be able to make the firmware side all by myself. As for the hardware side, I barely have a clue. It's the database part that I would be able to do well










Matthias_H: As for solutions for the config file running out of room (if, of course, you need them, I can't remember whether I'm right or not about what you said, I could be imagining things) - how about making it a binary file with a simple open-source editor for it? (Open source so that it can be ported to platforms other than your favourite one )

[emuDrache]

i am not sure how the retrode fw source is written, or if it would even allow it,
but i saw a project once where you select what bits and pieces you need, and click on
download, and it downloads a firmware with only the bits & pieces that you need.

simple to do with #ifdef

//F

[andwhyisit]

Matthias_H: As for solutions for the config file running out of room (if, of course, you need them, I can't remember whether I'm right or not about what you said, I could be imagining things) - how about making it a binary file with a simple open-source editor for it? (Open source so that it can be ported to platforms other than your favourite one )

I always thought it was translated to binary by the firmware. But if it is stored in the raw then no wonder Matthias_H is running out of room. The config need only take up 63 bytes at the most when stored in a binary format.

I second this motion.

Although every minor change to the config would warrant a new editor revision, which needs to be ported to two other operating systems.

A better notion would be if the binary format config was translated to a plaintext config file by the firmware, and then you can translate that backwards into the internal binary format config by the firmware upon saving the text config, assuming there's no OS related issues in doing so. But hey, it could be updated upon hitting reset as a fallback if it can't be updated upon saving the text config.

[Matthias_H]

The config is stored in binary but buffered in text form for the whole trick to work at all.

[Muzer]

Might just buffering one line at a time work, assuming no line is dependent on any other?

[andwhyisit]

Might just buffering one line at a time work, assuming no line is dependent on any other?

None of the lines appear to be dependent on each other, and the longest line in config is 68 bytes in length (or 70 if you include linebreak chars) if that helps.

[Matthias_H]

Even so, a single line of text could still span multiple sectors on the storage medium. Believe me: there are reasons why it is the way it is

[andwhyisit]

Use buffer to generate a comment, setting value (or a single part of a multi value set), setting header, or whitespace one at a time, commit it to the end of your virtual config file (is it loaded into ram when the file is read, or when the USB device is read, or both?), then clear the buffer of any data that isn't required to generate the rest of the config, then repeat for the rest of the config.

Of course I am making assumptions about how this all works.

[Matthias_H]

I'd rather wait with such fundamental changes to the config handling until there's an actual reason for it -- i.e., until someone actually builds a NES plugin.