nesdev.org

MatthewCallis wrote:Most of these are fixable with a proper software; the SA-1 is also likely fixable through software but without testing I'm not sure. I've already asked about the source and it will be released at some point, and since it is the same chip as the CopyNES USB I already know it will work on OSX which is the biggest plus for me, no more damn parallel port.

Some French guy came up with a method of dumping SA-1 games on the tototek, but the site is long gone. It used to be here:

http://www.google.com/#hl=en&q=tototek+ ... i-R6mbKWrc

http://www.hammerhead.fr/articleDossier ... artsuite=3

All I remember is that there were a few wires involved between the cart and the slot. Something to do with those metal things built into the shell.

shadowkn55 wrote:The added intros in Translation Corporation titles (Dual Orb 2, Wozz) don't work properly when built into a cart. You can hear the music but nothing on the screen. You can get it to show up intermittently by reseting a few times. The strange thing is that the added intro works when using a gd7 or playing on bsnes.

A real system has a lot of random state on power-on. RAM, registers, etc.
Unfortunately, an emulator needs to have a fixed state for many reasons (movie playback, netplay, reproducing bugs experienced by others, ...) Copiers do the same thing, but by a different means. After the BIOS finishes loading a game, they try and "reset" the system to a consistent state. When programmers rely on that, you get broken games on real hardware.

Very hard for a ROM hacker to test on true hardware, but what they can do is properly initialize everything (and I do mean everything) upon startup.

I myself have only recently been able to run tests immediately at true power-on, thanks to a modded cart from blargg. Almost all of bsnes was based upon state from copiers, so your results shouldn't be too surprising that it works like one. That said, I'll see about introducing a dev-only option to randomize the startup state in a future release.

Soul Blazer's screwed up intro music, yay!

As I understand it, the GBA is a more inviting platform than the Super NES with Super FX, and it's still easier to get PowerPak-equivalent hardware for (e.g. EZFlash and SuperCard).

As I understand it, the PC is a more inviting platform than the GBA with EZFlash
I've already done a fair share of ARM-related stuff, so meh.. It's a very nice architecture, but these older systems are generally more interesting.

mic_ wrote:As I understand it, the PC is a more inviting platform than the GBA with EZFlash

But the GBA is smaller

When choosing a platform to develop homebrew apps for, one has to balance a few factors:

1. the physical size of the platform (handheld vs. notebook vs. desktop/set-top)
2. the extent to which the platform is documented
3. the popularity of the platform (e.g. Pandora vs. mainstream PDAs vs. GBA and DS)
4. the availability of rewritable storage media (e.g. pre-PowerPak custom-made flash carts for NES vs. mass-produced flash adapters vs. SD cards)
5. the resolve of the platform's maker to continue to lock out newly produced freeware (PSP and Wii: heavy; DS and classic consoles: not so much)
6. "interesting-ness", or the difference between the platform and current personal computers

The relative importance of these factors varies per person; in fact, some people who like to reverse engineer may prefer a less documented system. But let's analyze a few systems that I considered.

PC: <> Not as portable as a handheld, but plenty of people own notebook PCs, and it just got better when ASUS introduced the Eee PC and opened up the low-cost subnotebook market. + POSIX and Win32 are well-known quantities. It falls down only for peripherals that aren't yet on Linux HCLs. + Everybody's got one. + Takes floppies, CDs, USB memory cards, SD cards, etc. + Wide open on Linux. And apart from Authenticode, Microsoft doesn't want to lock out Win32 app developers. - PCs are old news; the app market is saturated.

GBA: + Portable. + Became well documented. + Popular. + Flash cards were available within months of launch, culminating in the SuperCard adapter that took SD cards. + Lockout was similar to the (legally ineffective) TMSS on the Genesis, defeated in three seconds once the seek/read cart bus interface was reversed. + C on a tiles+sprites 2D graphics system was a new experience for a lot of developers.

Wii: - Not portable. + Documentation is improving. + Popular. + Takes SD cards. - Still being locked down (see Wii firmware 3.3, 3.4, and 4.0). - Really close to a PC in power and programming model. So no thanks.

NES in 2000: - Not portable. - Poorly documented; people tended to use "what Nesticle does" as the reference. + Popular. - You had to solder. - You had to solder. + Interesting.

NES in 2009: - Not portable (ignoring PocketNES and portable Famiclones that suck more juice than a Game Gear). + Well documented, thanks in part to Brad Taylor, loopy, kevtris, blargg, and other dedicated reverse engineers. + Popular. + PowerPak. + CIClone. + Interesting. Now you see why there was such a flurry of activity on Tetramino (now LJ65) once I got my PowerPak.

Super NES with Super FX is where the NES was in 2000.

Super-Hampster wrote:Judging by the prototype board it doesn't look like it will support SuperFX. The prototype is missing the extra cartridge pings on the edges that you find on cartridges with add on chips. I hope it changes in the final version. I'd love a powerpak like cart for SuperNES. Especially if it will play games with add on chips.

I don't think that would be a problem. AFAIK out of the extra pins on SFX carts only one was connected and out of all the SFX carts I have opened (made myself a Starfox, Starfox Competition, Starfox2 combo cart) the trace from that pin isn't connected. In fact, I just opened up my Winter Gold FX. It has the extra pins but they aren't connected AT ALL!

As far as I can tell the main difference between a SFX cart and a normal one is extra grounding supplied by the metal spring contacts inside the cart.

Judging by the prototype board it doesn't look like it will support SuperFX. The prototype is missing the extra cartridge pings on the edges that you find on cartridges with add on chips.

The extra pins are not connected on both of my FX cards. Only one is connected to ground through a small cap.

As far as I can tell the main difference between a SFX cart and a normal one is extra grounding supplied by the metal spring contacts inside the cart.

Yeah, and this may do all the difference. I'm pretty sure the SuperFX draws a lot of power and put the SNES power supply to its limits. That's why the chip couldn't go as high as 21Mhz and had to stick to 10.5 MHz I belive (could be wrong).

There are SuperFX games that use the 21mhz mode.

Also one of the "extra" pins I believe carrys a clock signal. But I think that most but not all Super FX games have their own clock in the cartridge.

MottZilla wrote:There are SuperFX games that use the 21mhz mode.

Also one of the "extra" pins I believe carries a clock signal. But I think that most but not all Super FX games have their own clock in the cartridge.

That's true, but I have only every seen that pin unused in the 'glop top' SFX carts and the only examples I have seen are Starfox and Starwing. Every other SFX cart I have (Vortex, Doom, Winter Gold, Stunt Race & Yoshi's Island) have that pin unconnected. There doesn't seem to be any significant difference between the SFX on either type of cart because I have Starfox running perfectly on a Stunt Race cart (as far as I can tell).

FitzRoy wrote:I just received my programmer and I'm going to do a mini review from a dumper standpoint.

Pros
-----
-Uses USB interface for power and transfer. No dicking with EPP/ECP BIOS settings, no slow transfers, and guaranteed to work on new motherboards.
-Dumps almost any game quickly and reliably in mere seconds.
-Drivers support 64-bit OS.
-Very reasonable price for such a niche product.
-Responsive tech support in native English.

Cons
------
-No rubber feet on the bottom corners to keep it in place like my tototek programmer.
-Dumping software is command prompt only. It works, but a GUI would be faster.
-Can't dump SA-1 games, but neither could my tototek programmer so maybe it's not possible.
-Documentation recommends loading a game in snes9x to obtain internal rom attributes. Using NSRT or GameHeader is a far better way to go about doing that.
-Supports flashing "SWC" and "SMC" copier extensions (which need to die), but not "SFC".
-Uses "BIN" and "SAV" as examples instead of supported emulator extensions "SFC" and "SRM."
-Doesn't include the necessary USB cable and no offering is made on the site.

Current rating: 9/10.

Im glad it came so quick! And thanks for the review.

Rubber feet and offering a USB cable are good ideas.

As for file formats, SWC and SMC just have a 512 byte header which it ignores. Is SFC like this? Since I don't write these headers its just BIN.

I thought about mentioning NSRT too, its just that half my games aren't in the database and it doesn't tell you the correct size from the header.

mic_ wrote: But personally I'm interested in SuperFX support more as a coder than as a gamer. Same goes for other chips like SA-1 and CX4.

SA-1 does sound really impressive, on a side-note I wonder if that's what Nintendo had in mind to use for their CD-ROM expansion? Would've been fun to mess with..

I wasn't aware that most of the extra pins are unconnected. My comment was due to the fact that if I connect star fox to a game genie, which does not pass through the extra connectors, it does not render any SuperFX generated graphics. Maybe it's not so much the extra pins as it is the extra grounding provided by the metal springs which do not make contact if a game genie is attached. I naturally blamed the extra pins because if you do the same with a Super Gameboy the Gameboy graphics do not render either.

cybertron wrote:Im glad it came so quick! And thanks for the review.

No problem, I hope you get lots of sales.

Rubber feet and offering a USB cable are good ideas.

No problem. The feet should be a pretty cheap addition for future production runs. Hopefully you can find some that are small enough to clear the bottom pins.

For myself, I thought about getting these and supergluing them.
http://officemax.com/catalog/sku.jsp?pr ... rod2410282

As for file formats, SWC and SMC just have a 512 byte header which it ignores. Is SFC like this? Since I don't write these headers its just BIN.

An extension is just an extension, it doesn't necessarily reflect the presence of a copier header. I'm trying to get the world to stop using and promoting arbitrary extensions created by unlicensed hardware. The system was the SNES/SFC, so one of them makes sense as an extension for this system's data. And since SAV is not used by emulators, you'd be better off saying SRM to avoid confusion.

I thought about mentioning NSRT too, its just that half my games aren't in the database and it doesn't tell you the correct size from the header.

Interesting, can you post some scan outputs to show me what you mean?

Super-Hampster wrote:I wasn't aware that most of the extra pins are unconnected. My comment was due to the fact that if I connect star fox to a game genie, which does not pass through the extra connectors, it does not render any SuperFX generated graphics. Maybe it's not so much the extra pins as it is the extra grounding provided by the metal springs which do not make contact if a game genie is attached. I naturally blamed the extra pins because if you do the same with a Super Gameboy the Gameboy graphics do not render either.

I can't speak the the Super Gameboy (don't have one) but like I mentioned earlier StarFox is one of the very few (if not only) games that makes use of the extra pins for the SFX chip's clock signal. All other SFX carts I have seen have their own clock generator circuitry on cart. I'm also beginning to think that the extra grounding springs aren't really needed. My reasoning for this is that the only way I can play Starfox on my PAL snes is to run it through my GDSF7 (ran fine BTW) which has all the pins but the connector (barring the pins) is completely plastic and so the spring contacts on the SFX carts don't have any metal to connect to.