Register | Login
Views: 19364387
Main | Memberlist | Active users | ACS | Commons | Calendar | Online users
Ranks | FAQ | Color Chart | Photo album | IRC Chat
11-02-05 12:59 PM
1 user currently in Super Mario World hacking: labmaster | 3 guests
Acmlm's Board - I2 Archive - Super Mario World hacking - Enhancement chips?
  
User name:
Password:
Reply:
 

UserPost
HyperLamer
Posts: 1217/8210
Well I know adding an SFX isn't gonna do anything on its own. That'd be like buying a new CPU and expecting your computer to go faster without installing it. I did indeed plan to do some ASM hacks to use it. I'll figure out all the DMA stuff when I get there. (SMW using up the vblank cycles won't be a problem, I don't intend to do anything major, except maybe as a minigame which will be a subroutine itself and not use SMW's code at all...
d4s
Posts: 43/325
of course you can edit the rom info-sector to enable a chip like the dsp1 or the superfx when you load the game in emulators, you can even take a super fx cartridge and solder a normal lorom 8mbit game in, it will work flawlessy on a real snes(checked it myself already).

however, the question is:
of what use would this be?

im afraid the game wont magically transform into 3d and wont go faster, either.
the super fx and the dsp are after all just co-cpus and without proper input(your program code, that is), they wont do ANYTHING.
and believe me, even if you could drive these babys,
i doubt that you could improve a game like mario world AT ALL.

take the super fx for example:

1. there is basically NO info available on how to code that thing (besides its us-patent, and this is far from enough)
2. even if you had all programming docs for this chip, youd have to know
65816 AND super fx asm perfectly, and you know that even the first of these two is a major problem for most boardmembers despite the available info.
3. consider you have a routine hooked up that makes the sfx render some polys,
after raw bitmap to tile conversion, it will save the rendered screen to its work ram and you'll have to manually DMA it to the snes's vram. the problem here is that you can only do it during vblank and i'm almost sure mario worlds routines already use up most of the cpu-cycles during vblank cause the game wants to upload it own stuff to vram, too.

doing scaling or poly rendering on the super fx is ALOT different from, say, just setting up 6 matrix values for mode7 with a sine-table to make it rotate and youre all set.
the super fx contains of mainly a very fast ALU (arithmetic-logical unit),
the raw bitmap to snes tile hardware converter and a very fast pixelplotter (useful for drawing polys).
its not like telling the chip: take sprite X and scale it around for value Y and there you go.
you have to write EVERYTHING yourself.

if you cant do a routine that rotates a sprite in mario world in software(on the 65816, that is), then you have no chance of doing this on the super fx.
im not talking about speed here, its all about technique and experience.

after all, you could maybe write some code that makes the dsp1 or superfx calculate some stuff , but without proper use this would be a major waste of time.
however, you could then have the super fx logo on your titlescreen, wich would be
a cool show-off.
HyperLamer
Posts: 1176/8210
I was hoping to do some rotation, maybe a bit of scaling, the rest really depends what the chip can do. I'm thinking I'll prolly use SFX, but I can't find programming info on any of these.
Escherial
Posts: 28/90
Yeah, can't really vouch for the correctness of that particular list; I found it on an ancient document describing the memory map of some game. Anyhow, interesting findings there -- I'm interested in any other information on the subject, so keep posting, please

Just out of curiousity, what do you plan to do with an SFX chip in SMW (or any of the other enhancement chips, for that matter)? Sounds pretty exciting, at any rate keep it up, whatever it is.
HyperLamer
Posts: 1157/8210
Ooh, nasty Nintendo. The name is padded with space (0x20) and the first byte after it is also 0x20, so I changed the wrong thing. I figured it out, but I think your list is wrong. I changed it to 05, and ZSnes says it's DSP-2. (The game runs fine, though. ) I'll compile my own list of what ZSnes reports it as being and what happens when I play it...
00 - Normal, runs (even the SRAM )
01 - Normal, runs
02 - Normal, runs
03 - DSP-1, runs
04 - Normal, runs
05 - DSP-2, runs
06 - Normal, runs
07 - Normal, runs
08 - Normal, runs
09 - Normal, runs
0A - Normal, runs
0B - Normal, runs
0C - Normal, runs
0D - Normal, runs
0E - Normal, runs
0F - Normal, runs
10 - Normal, runs
11 - Normal, runs
12 - Normal, runs
13 - SuperFX, runs*
14 - SuperFX, runs
15 - SuperFX, runs (this is what Yoshi's Island uses)
E3 (just out of curiosity) - SGB, runs

*This I find especially odd. I tried a level from every world (went all the way through Chocolate Island 2) and a modified one, and everything worked perfectly. Working with Yoshi's Island, I found that it had a strange ROM map that was half LoROM and half HiROM, switching back and forth. The only reason I see for this would be the use of the SuperFX, if that's the case, shouldn't SMW have crashed? (YI has the same 'ROM Type' byte. The next byte is 0B compared to 0A in SMW, but changing it in SMW had no visible effect.)
Escherial
Posts: 27/90
Huh, you're right, of course; I actually did some research on the subject and came up with this table. This byte is located one byte after the game title, which is 21 bytes (the byte in between is the ROM type byte - either LoROM, HiROM, FastROM, SloROM, etc.):

Byte ROM type
0 ROM only
1 ROM and RAM
2 ROM and Save RAM
3 ROM and DSP1 chip
4 ROM, RAM and DSP1 chip
5 ROM, Save RAM and DSP1 chip
19 ROM and Super FX chip
227 ROM, RAM and GameBoy data
246 ROM and DSP2 chip
I hope that helps; my apologies for my previously uneducated post. As far as messing things up goes, trying can't hurt just make sure it's with an expendable ROM, heh.

EDIT:
Also, I read something in the ZSNES changelist that mentioned that SFX support was autodetected from the ROM header.
HyperLamer
Posts: 1150/8210
Well, I imagine the SNES header has a byte that tells what sort of hardware is in it, which an emulator would use for that exact purpose, so just by changing it to the appropriate value for one of the chips, it should be enabled. The question is if the game will still function.
Escherial
Posts: 26/90
I would assume that the inputs/outputs of any chip supported by the emulator would be mapped to a usable address, regardless of the ROM.

I have a sketchy understanding of memory-mapped IO, so this is a bit of a guess.
KATW
Posts: 986/3959
Well... It really depends on how the chips are triggered.

Im going with a hunch on this, but It would seem unlikely that just one or two bytes would be able to run a whole chip. This could be an interesting idea to look into HH
HyperLamer
Posts: 1143/8210
No offense, but that post was completely useless.
Drake Solarice
Posts: 9/12
It May be possible. Yet in not 100% sure.
HyperLamer
Posts: 1137/8210
Is it possible to change a flag in the ROM header or something to enable some special enhancement chips like the DSP-1 or SuperFX, without having to change huge parts of the ROM?
Acmlm's Board - I2 Archive - Super Mario World hacking - Enhancement chips?


ABII


AcmlmBoard vl.ol (11-01-05)
© 2000-2005 Acmlm, Emuz, et al



Page rendered in 0.012 seconds.