[yann]

Hi i m a newbie in coding and m'y project is to dejap this great game and change some old gfxs by newer to make a 25th anniversary version . i ve managed to reorder     the team order ( France my country is now first). there is an option ingame to play with the name of the players instead of their numbers.in the original game names are in jap and i want to dejap them. i m pretty sure that they are in compressed gfx format but i cant find them neither with tile éditor nor yychr. i also have to find the ending screens to change them and i have the same problem.( despite  i have found a lot of other sprites of the game). thx for your future help
August 21, 2018, 11:01:16 am - (Auto Merged - Double Posts are not allowed before 7 days.)after reading a few things , i ve seen that vsnes can be used to show decompressed graphics using a save state made with zsnes .And i can see the sprites of the japanese names of the player in VRAM but i dont know what to do with that ...

[bogaabogaa]

If you would ask clear questions it would be easier to help. I don't know what great game you are talking about. It is one thing do decompress SNES graphic a other one would be to compress them again to fit the preexisting space. Emulator Graphic debugger are great to view and copy graphics.
As I understand you like to change and compress them again. We are also not sure if they are compressed or may be in a format you did not know how to view. Like 8bbp Mode7 2bpp.

Tilemolster has more formats then yychr.. here is also a new tool. The creatir might help you with decompression but compressing something to fit into space.. I guess there you would be out of luck. (on yourself)

https://www.romhacking.net/forum/index.php?topic=25707.msg362302#msg362302

GL hacking cya

[yann]

thx for the reply ...The name of the great game is in the title " super formation soccer 2".
And you have understood the project ....I ve found ,i think , where the jap compressed sprites are in the rom ....I will study how the program decompresses  them and will post my report here for future help .

[phonymike]

This topic caught my eye so and I had some free time today so I took a shot at it. While you can figure out the decompression routine, and write a recompression routine as well, I would say it's easier to just expand the ROM and put the uncompressed data into the extra space. Here's some notes:

Code: [Select]

PC file addresses are written as 0x123456
SNES memory addresses are written as $123456

It looks like each on field player name is two 8x8 tiles.
They are stored as an entire graphic (with all names) that is compressed and stored at ROM location 0x024B0C
Once decompressed to WRAM location $7E3C00, total size is 0x4400 bytes
Then each player name graphic is copied from WRAM to a VRAM sprite during play.

The main decompression routine (used for many things) is at $008B48


I did use vSNES to see where the font was located. Usually stuff like that is decompressed to WRAM before being uploaded to VRAM. Upon finding it, I set a write breakpoint in Geiger's Snes9x and found the code that writes to the WRAM. To my surprise it wasn't just a font but all of the player names. I saved the decompressed WRAM data from vSNES to a file. Then wrote some code to put the uncompressed names into WRAM. Below is the code that I wrote for xkas v0.06:

Code: [Select]

;xkas v0.06
lorom

org $1FFFFF ;pad to 1 mbit
db $00


org $0189AE ;hijack original decompression call
NOP #6
JSL skip_onfield_names_decompress


;===============================
;beginning of expanded ROM space
;===============================
org $108000

onfield_names:
incbin decompressed_onfield_names.bin


skip_onfield_names_decompress:
PHP ;save A, XY setting
REP #$30 ;change to 16 bit A, XY

LDX #$4400-2 ;size of image data minus 2

- LDA onfield_names,x ;load word (long, indexed)
STA $7E3C00,x ;save word to memory (long, indexed)
DEX
DEX
BPL -

PLP ;restore A, XY setting

RTL


And here is the source and an .ips file https://files.catbox.moe/p0zu77.zip
ROM must not have a header and filesize must be 524,288 bytes

[yann]

big thanks for the reply .The adress of sprites in wram and in the rom too , despite i m a newbie , i had already discovered it with vsnes .but the adress of the routine i couldn't manage to have it because of my lack of knowledge in using breakpoint.

I m at work and a little busy for today but wednesday i will take a look at your patch and see what it does ....

Thanks again
August 27, 2018, 01:47:06 pm - (Auto Merged - Double Posts are not allowed before 7 days.)Ok i ve taken a look of your ips file and you are my master !!!!!!!!!
You have made a miracle .I can continue to work now on my project ....I think i will need help for the end of the game ( compressed data of ending screens that i want to change with russian world cup screens )

stay tuned

[KingMike]

Code: [Select]

skip_onfield_names_decompress:
PHP ;save A, XY setting
REP #$30 ;change to 16 bit A, XY

LDX #$4400-2 ;size of image data minus 2

- LDA onfield_names,x ;load word (long, indexed)
STA $7E3C00,x ;save word to memory (long, indexed)
DEX
DEX
BPL -

PLP ;restore A, XY setting

RTL


Just to let you know, when you are copying large amounts of data, you may want to learn about either the DMA functions or at least the MVN/MVP instructions. It is very slow to copy bytes one at a time (though maybe not the worst thing when you are only doing one time. Not like Maka-Maka *cough* *cough* where that inefficiency adds up enough to create worse than CD loading times.
I forget which of MVN and MVP is which. One is to copy the data forwards and the other backwards, depending on where the source and destination are (so that the copied data doesn't do an unwanted overwrite of itself in the process.)
Then it's something like (16-bit A,X,Y only):
LDA #size-1 (because it copies until A underflows to FFFF)
LDX #SourceAddress
LDY #DestinationAddress (or maybe X and Y are reversed, can't recall offhand)
MVN (or MVP) SourceBank,DestinationBank (again, or maybe the reverse, some assemblers might expect you to write the bank values as a single 16-bit value as well even though two 8-bit values separated with a comma is the official notation I think)
...and you're done.

Yeah, MVN/MVP is the way to go for WRAM-to-WRAM copies. WRAM-to-VRAM (or less commonly the reverse direction) you would need to use DMA, which is still just a little bit of setup but not too much. Some games might already have a routine set up where you can just feed the values into its own write buffer and then feed it a "ready" flag and it should take care of it.

[phonymike]

Thanks for the tip on MVN and MVP. I found some more information at the NESdev forums, those guys are crazy over there. I never used it but wondered how it works. DMA is definitely faster, one person there says 5-7 times faster than MVN/MVP.

Most of the games I've tinkered with use this simple LDA/STA loop to do the data copying when setting up a title screen or other game preparation. I do see DMA used a lot in-game for sprite updates. I like to keep the code simple so anyone new to it won't be so afraid of trying it out. Though in that sample I would update it to use BNE rather than BPL because that loop will fail if you put a value over $7FFF as the counter (it will then be a negative value.)

[yann]

Hello , back after a long time ,busy with professionnal life and so on ...
With the Covid problem , i m now at home for a feww weeks ( no work )  and i  have decided to continue the hack of super formation soccer 2 , with the help of anyone interrested in this project .

What is done for the moment ?

- changed order of teams according to results of the 2018 world cup ( of course FRANCE is the first team ... lol )

- changed colors of teams (new shirts, socks etc ...)

- intro dejap


Thanks to kingmike the name of players can be dejap ingame ( not done for the moment , it takes a little time but I KNOW HOW TO)

what i need for now is changing the team stats during the line up ( i ve tried with the help of the super formation soccer 1 help and info given in the hack found here but it s like the data are once again compressed ( i can't find it in the rom ).for example the goal keeper of the 2nd team has 20/ 1/ 5 , and when i search it in hexedit i can't find it ( in super soccer 1 it works however ...arggggh ). with snes9xdebug i can see it in 7e0023 7e0024 and 7e0025 and when i change the player during the line up , i can see the walue are changing too...so i suppose there is somewhere a code that decompresses the data of the rom ....but where , and how ....is there a way to do like Kingmike ( put the data uncompressed at the end of the rom ) ?

I think it doesnt change the behavior of the players during the match ( putting a higher value won't make the player really stronger but i will study that after )

Comparing super formation soccer 1 and 2 , i think some of players need to be boosted to make the game more agressive , that s why i think it s interresting .The advantage of super foramtion soccer 2 is the possibility to play with 4 players ( very funny option)

Ready to read you ...Thx for all
   




April 11, 2020, 04:04:33 am - (Auto Merged - Double Posts are not allowed before 7 days.) Ok i ve found by myself where are the players stats and it changes their behavior ingame , so it s cool.I have to change those stats to make players run faster . ( normally not too hard to do )

Now i m gonna try to dejap the 5 or 6 jap sentence in the game to make the hack more pro

[yann]

Hello guys

AFter several days i have to admit that i m beaten trying to dejap the end of the game
.
Jap text is in sprite compressed and i ve found i think where is the routine call ( 52670 code : 22 48 8b) , i ve tried to take the sprites found in wram as phonymike has made copied it in 84500, written the same routine as he did ( changing on-field name adress by mine ) and put 6 nop ,changed at 52670 the 22 48 8b 00 by 22 20 c4 10 ,the adress of the new routine ).

when i test it i see that all the screen is affected by what i ve done ( not only the text , which is not correct ....arrrgh )
In fact , i think that all the sprites of this moment of the game is decompressed by 52670 and i wram i can't see the other gfx ,only the japanese text ......( big guy at the top of the screen )

the other pb is i think the way it s decompressed wich is probably not the same as the first routine phonymike has done and so , i doesn 't work as expected ...

Can you help me a little more ???


 

[phonymike]

Hey yann, I took a swing at it. All the addresses are in SNES memory format. Use Lunar Address LoROM 00:8000 to convert the ROM addresses to file addresses if needed.

It does use the decompression routine at $00:8B48. I CPU log to a file (trace once is set) during the screen change. Then search the log for "JSL $008B48" to see each time something is decompressed. I found 4 or 5 calls before the "WIN" screen shows up. I made a savestate after running each call to see which one decompresses the graphics we need, and looked at the WRAM using vSNES. The 4th decompression call put the graphics into WRAM.

It looks like code will set up addresses before calling the decompression routine.

Code: [Select]

-destination bank $7E-
$0A/A663 A9 7E       LDA #$7E
$0A/A665 85 5A       STA $5A    [$00:005A]
-source address $07:A000-
$0A/A667 A9 07       LDA #$07
$0A/A669 F4 00 A0    PEA $A000
-destination $4000-
$0A/A66C F4 00 40    PEA $4000
$0A/A66F 22 48 8B 00 JSL $008B48[$00:8B48]

The source ROM address is $07:A000, destination WRAM address is $7E:4000.

I just used vSNES to see how big the graphics are, they take up $4000 bytes. I used Snes9X "Show Hex" and set the range to RAM, $7E4000 $7E7FFF, then press Dump and it saves the uncompressed graphics.


To hijack the decompression call we also NOP over the two PEA (Push Effective Absolute address) codes before the jump. They push onto the stack, the decompression code pulls them off. Since we skip the decompression code, these pushes corrupt the stack and the game crashes.

Code: [Select]

$0A/A669 F4 00 A0    PEA $A000
$0A/A66C F4 00 40    PEA $4000
$0A/A66F 22 48 8B 00 JSL $008B48[$00:8B48]

becomes

org $0AA669 ;hijack original decompression call
NOP #3 ;blank out the stack push (PEA $A000)
NOP #3 ;blank out the stack push (PEA $4000)
JSL skip_ending_sequence_decompress

We could leave the PEA, PEA, but we would need PLA, PLA in our copy routine.


Even easier right after the decompression call, the code copies the data from WRAM to VRAM. By simply changing the address, it'll copy straight from ROM into VRAM for you.

Code: [Select]

$0A/A687 BF 00 40 7E LDA $7E4000,x[$7E:4000]
$0A/A68B 8D 18 21    STA $2118  [$03:2118]
$0A/A68E E8          INX
$0A/A68F BF 00 40 7E LDA $7E4000,x[$7E:4001]
$0A/A693 8D 19 21    STA $2119  [$03:2119]
$0A/A696 E8          INX
$0A/A697 E0 00 40    CPX #$4000
$0A/A69A D0 EB       BNE $EB    [$A687]

so it could be as simple as

Code: [Select]

;xkas v0.06
lorom

org $1FFFFF ;pad to 1 mbit
db $00

org $0AA669 ;hijack original decompression call
NOP #3 ;blank out the stack push (PEA $A000)
NOP #3 ;blank out the stack push (PEA $4000)
NOP #4 ;blank out the decompression call

org $0AA687
LDA ending_sequence,x ;load ROM source for VRAM copy

org $0AA68F
LDA ending_sequence,x ;load ROM source for VRAM copy

;===============================
;beginning of expanded ROM space
;===============================
org $108000

ending_sequence:
incbin soccer.RAM.7e4000-7e7fff.dump.bin


Here's the files plus an ips. https://files.catbox.moe/duoaet.zip

[yann]

Thx for the reply.despite i haven t your skills i have managed by myself to do the same thing before your answer. I have now one little problem again. I usé #4400  for name graph.and 4000 for the font decomp and graph we are talking about. I have decided to put the part of #4000 on #10800 ( #83fff) and the graph of players name on 87000 ,( #10f00). My problem is that only the 4th teams have the correct gfxs the others not despite i can se them in my rom at the correct adress. Is it possible that the rom size is too small? In fact i really need space because i want to change after that the gfxs of the ending part.

[phonymike]

I think the problem is with how SNES LoROM mapping works. For this you need to use Lunar Address. SNES ROM memory addresses don't use xx:0000 - xx:7FFF. They go from xx:8000 - xx:FFFF.

Code: [Select]

   PC        SNES
0x000000 = $00:8000
0x008000 = $01:8000
0x010000 = $02:8000
0x018000 = $03:8000
0x020000 = $04:8000
...
0x080000 = $10:8000
0x087000 = $10:F000

So if you have data at $10:F000 - $10:FFFF, the next byte will be at 11:8000, not 11:0000.

The problem is probably that the data crosses banks. If you look at the copy routine, it doesn't change the bank value. To fix this, data must be less than $8000, and stored at the start of a bank.

A better way of doing it like KingMike said would be to use DMA. I think DMA can work across banks. I don't have any DMA code to share at the moment, but there's several documents on it like this one.

[yann]

Hello , once again you are right ....It works now.....I can continue ....thx for all ....my problem was that the way the rom is organized was not very clear for a newbie ( when i was young i coded with an amstrad cpc ,easier.....but it gave me some knowledge useful for what i m doing now with snes ...)
 

[phonymike]

Hey again. This is just something funny I came across on one of dejap's archived webpages. It's at the bottom of the first post. It's in response to what you mentioned earlier.

AFter several days i have to admit that i m beaten trying to dejap the end of the game

Here's a quote from Tomato

P.S. "DeJap" is NOT a verb! Don't make me come over there!

I thought it was funny 

[jvplouvem]

Folks, there is a way to edit tiles and put they back to a rom just using tools ?

I tried to do it in many ways for mk3 and i cant.

[KingMike]

A better way of doing it like KingMike said would be to use DMA. I think DMA can work across banks. I don't have any DMA code to share at the moment, but there's several documents on it like this one.

GIDEON ZHI proposed and wrote the DMA tutorial, not me.

Personally, I actually don't prefer the DMA bypass method. (but of course, Gideon can do what he wants with his translations.)
I prefer to do it the cleaner way and actually decompress and recompress the graphics, rather than separate code jumps for every needed graphic patch. (easier for me since SNES most often each uses some minor variation of LZSS and once I had written a toolset for one game, it was pretty easy to use as a template for other games. I could just pop the specific differences of each variation of LZSS into my source code and get something running quick.)
But I understand that is more advanced and more technical approach.