nesdev.org

Hojo_Norem wrote: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).

Perhaps the earlier SFX games can run on the later revision SFX chips (the ones called "FX2" by Nintendo Power), but the later games can't necessarily run on the older SFX chips.

cybertron wrote:Since I don't write these headers its just BIN.

A lot of file managers, such as Windows Explorer, look only at the last few characters of a file's name to determine its content type. For example, all .bin files might get associated with a Sega Genesis emulator. The Game Boy Advance ROM format has no header (apart from the data actually on the cart, which has a fairly standardized first 192 bytes), and ROM dumps used to be distributed with a .bin extension. But nowadays, it's most often .gba so that it can get associated with VisualBoyAdvance (as long as you don't have GrabIt installed).

FitzRoy wrote:And since SAV is not used by emulators

GBA and DS emulators use .sav files, which are headerless files that contain the data on the emulated cart's flash or SRAM. I believe .sav was used over .srm because a lot of GBA games have serial EEPROM, parallel flash, or FeRAM instead of actual SRAM, and all DS games have EEPROM or flash over an SPI port.

tepples wrote:GBA and DS emulators use .sav files, which are headerless files that contain the data on the emulated cart's flash or SRAM. I believe .sav was used over .srm because a lot of GBA games have serial EEPROM, parallel flash, or FeRAM instead of actual SRAM, and all DS games have EEPROM or flash over an SPI port.

Obviously, I'm referring to SNES emulators because it's the SNES I was talking about.

SNES looks like the only platform to save in .srm files instead of .sav filesn (altough I belive both are raw data without header or footer).

From what I remember all Super FX chips have the same instruction set. The only differences are their clocking method, maximum speed, and maximum ROM. Some clock with the pin signal on the cart port. Others have it inside the cart. Mario Chip and GSU-1 support only 8 Megabits of ROM. GSU-2 supports 16 Megabits. I believe Mario Chip and GSU-1 can only run at 10.5mhz while GSU-2 can run at 21mhz.

So games that use the 21mhz speed may not run very well on Mario Chip or GSU-1 boards, other not run at all if they are bigger than 8mbits. The other issue is WRAM on the board. Not all games have the same amount, some is battery backed.

Why is half of this thread about a hypothetical SuperFX flash cart? As if it's even practical or desirable. You're seriously going to need emulation or the actual cart for the myriad of SNES special chip games. The only possible purpose one would have is if it could help someone improve the emulation of a chip.

Because deep down inside we all want to play Star Fox 2 on real SNES carts. Duh. :p Atleast that's my guess.

yeah that's pretty much it! lol

Or because we'd like to create a SNES game pushing the hardware to hard limit allowing mode 7 style effects on sprites, and large background 2D or 3D effects.

Bregalad wrote:Or because we'd like to create a SNES game pushing the hardware to hard limit allowing mode 7 style effects on sprites, and large background 2D or 3D effects.

It's easy to say that. Do you have any idea how much of a pain in the ass the SuperFX is?

- cannot simultaneously access ROM+RAM on both CPU and SFX
- no call / return
- no stack
- no division
- separate opcodes to specify source and dest registers + alternate modes:
from r1
to r2
alt3
add r3 //same as adc r3,r1,r2; an assembler can reduce, but have fun with a debugger
- insanity-incuding ROM+RAM buffers and L1 instruction cache (good luck profiling your code)
- pipeline that executes the next instruction no matter what, eg:
beq next
inc r0 //this gets called regardless of whether or not the branch was taken
...
next:
stop //supposed to stop the GSU, and yet ...
getc //this gets executed no matter what

The SuperFX is a waste of time. The SA-1 is vastly superior, it's just that no games using it really bothered to utilize the chip, whereas they pushed the SuperFX well beyond its limits (as evidenced by the ~5fps framerates of most games.)

byuu wrote:Do you have any idea how much of a pain in the ass the SuperFX is?

A lot of the allegedly painful features you describe are common in RISC designs of the era.

- cannot simultaneously access ROM+RAM on both CPU and SFX

What exactly do you mean? Can't the CPU just enter a RAM loop?

- no call / return

Not even copying between the program counter and another register?

- no stack
- no division

ARM doesn't really have a dedicated stack pointer either. The ABI specifies R13, and Thumb mode has special instructions to treat R13 as a stack pointer, but the PUSH (i.e. STMDB) and POP (i.e. LDMIA) instructions can use any register R0-R14 as the stack pointer.

- separate opcodes to specify source and dest registers + alternate modes:
from r1
to r2
alt3
add r3 //same as adc r3,r1,r2; an assembler can reduce, but have fun with a debugger

You mean like x86 instruction prefixes?

- pipeline that executes the next instruction no matter what

The CPUs in the Nintendo 64 and Sony's PS1, PS2, and PSP systems are based on the MIPS architecture. It has a similar branch delay slot. MIPS assemblers can be set to a mode where they swap the last two instructions if there is no dependency; otherwise, they insert a nop (e.g. ORI $at, $at, 0).

But Super FX or no Super FX, easier access to Super NES homebrew can only be a good thing.

Bregalad wrote:Or because we'd like to create a SNES game pushing the hardware to hard limit allowing mode 7 style effects on sprites, and large background 2D or 3D effects.

Yeah, SNES homebrew is about to take off any minute now. Aaaaany minute now....

There are far friendlier platforms for creators to work with today, with greater mobility, exposure, and sales potential to boot. There will always be interest in playing or modifying the SNES' existing library, but it will never be a magnet for homebrew. Tech demos, sure, but good luck creating something I would actually play.

MottZilla wrote:Because deep down inside we all want to play Star Fox 2 on real SNES carts. Duh. :p Atleast that's my guess.

Emulation can be just as good, and better with digital audio and video, it's just a matter of improving the emulation.

FitzRoy wrote:

Bregalad wrote:Or because we'd like to create a SNES game pushing the hardware to hard limit allowing mode 7 style effects on sprites, and large background 2D or 3D effects.

Yeah, SNES homebrew is about to take off any minute now. Aaaaany minute now....

I'm glad to see someone sees it similarly to how I do -- like I said, these flash carts are something we needed 10-15 years ago. People really aren't doing much with the SNES/SFC at this point in time. The NES/FC gets a lot more attention because, well, fanboyism.

The SNES/SFC is probably at least as much popluar as the NES/FC and got probably better games. The only issue I could see is that it should be hard to make 16-color graphics when you're used to 4 colors. (It's already hard with 4 colors for me )

Start with the 3 colors that you would normally use in a sprite, add black and white, and then add every color intermediate between any two. This gives you

• The 3 colors
• Dark versions of the 3 colors for shading
• Light versions of the 3 colors for highlights
• Halfway colors for smoothing edges
• Black, gray, and white

Some people use only 7 colors in each sprite so that they can get more palettes and/or store the sprite cels smaller. This is common on the Genesis where there are only four lines of 16 colors, and I've seen it in Super Mario World too.

What you say is exactly what I do when drawing sprites. Yet it's not easy to have them shaped like you do them on paper.

The SNES can have 7 color sprites (if the last bitplane is filled automatically by the programm by OR-ing the 3 other bitplanes) or 15 color sprites. I guess I could do SNES-dev and draw everything in 7 colors to make the transition smoother (and pretext I need to save ROM).