News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - phonymike

Pages: [1] 2
1
Once you figure out where the value in RAM is, you'll want to take that value from RAM and display it as a BG tile, so you're going to want to know where the BG map data is stored and how to change it. BG map data can be placed at different places in RAM, and you can use no$gba's Vram Viewer to see the BG maps 0, 1, 2, and 3. It will show you the actual map address, like 6001036 for example. Addresses for the GBA that start with 6xxxxxx are VRAM addresses. Memory that's used to display data on the screen. If the variable that you want to display is from 02038E7C, memory at 2xxxxxx is WRAM (Work RAM) also general purpose RAM. So you'd need to read data from 02038E7C and copy it to 6001036 for example. These are probably not the exact memory addresses but that's for you to figure out.

Using the example assembly code from [Unknown] (because my gba assembly is rusty), your code might look something like this
Code: [Select]
ldr r1,=2038E7Ch ;load address of variable into r1
ldr r0,[r1] ;load what's at address r1, put it into r0
ldr r1,=6001036 ;load address of map spot for new tile into r1
str r0,[r1] ;store value from r0 to address in r1

It looks like you can use xkas-plus v14+1 to assemble the commands and insert into the ROM pretty easy. Locations starting with 8xxxxxx are ROM cartridge locations and that's where your hack will be stored.

You'll also need to insert a jump into the game's code. This will interrupt the code, make it execute your code, and then return to the game code.

2
Newcomer's Board / Re: I have MSCOMCTL.OCX but...
« on: September 12, 2020, 05:58:42 am »
I'm pretty sure I found the problem.

I know its there. I followed the instructions to the letter too.

MSCOMCTL.OCX in SysWOW64
open the command window (right click, run as administrator)
go to C:\WINDOWS\SYSWOW64
Run: regsvr32 mscomctl.ocx

Same error message.

I got xenoscript working, but it bugged me about a few other things. I had to register comdlg32.ocx and richtx32.ocx also (got them from a website called ocxdump). Check the properties of .ocx files you download, click digital signatures, and details to make sure the signature is OK. You don't want any dirty ActiveX applications running on your machine  :)

Then when you get the 429 ActiveX component can't create object and Run-time error '91' Object variable or With block variable not set errors, you gotta do the same thing and register sqlite3.dll which would be done with the run_me.bat but fails. Just edit run_me.bat to include the full path to sqlite3.dll like below, save, then right click and run run_me.bat as administrator:

Code: [Select]
:run_me.bat

c:\windows\syswow64\regsvr32 "c:\program files (x86)\Xenoscript\sqlite3.dll"

Side note: you want to put the .ocx files into the SysWOW64 (Windows 32-bit on Windows 64-bit) folder, and run the regsvr32 from the SysWOW64 folder. Which is exactly what you did I'm just pointing out the significance for other readers. sqlite3.dll can stay in the xenogrears folder because it probably isn't used by anything else if you didn't have to register it. Good luck  :thumbsup:

3
There's an old program called SNESSOR v2.1 which can rip and insert SNES sound samples. It's a DOS command line program (from over 22 years ago lol), it will not run under Windows so you'll need to run a DOS emulator first like DOSBox to run the program. It's not an easy task, but it's another option for you. SNESSOR 95 might run in Windows, but it can't insert sound samples.

4
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
Quote
P.S. "DeJap" is NOT a verb! Don't make me come over there!

I thought it was funny  :laugh:

5
I have an old "Lufia (US).smc" that has the CRC32 of 087FCACF. With the header removed it is 5E1AA1A6. So it's the same game. If you add a header (so it's 1,049,088 bytes), then it's the correct file to patch. After patching and removing the header, I got CRC32 of 55FF8A59 for Restored 2.4.1 and 27E5A7A3 for Restored VANILLA FONT 2.4.1 which should match yours if you remove the header.

Here are the 512 bytes (0x200 hex) from the beginning of the file (the header). These bytes are not part of the game, they are settings for HiROM/LoROM, SRAM size etc that are used by an old copier device. They can safely be removed after patching. If your ROM is 1,049,088 bytes, overwrite the first 512 bytes with the following. If you have the nointro ROM with a size of 1,048,576 bytes and CRC32 5E1AA1A6, insert these 512 bytes at the beginning. Then you will have the CRC32 087FCACF file.

Spoiler:
Code: [Select]
00000000 80 00 00 00 00 00 00 00 AA BB 04 00 00 00 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 01 ................

This is the problem with SNES ROMs and old copier/backup unit headers. The header is metadata from the copier saved along with the ROM data from the cartridge. Backup units could also dump the saveram to a separate file. Different units have different headers which result in different file checksums, even though the ROM data is the same in all of them. 512 is the sector size of the 3.5 inch floppy disk. So if you don't have a backup unit, you don't need the copier header.

If I find a patch that needs a headered ROM, I add a header, apply the patch, then remove the header, then rename to .sfc. If you do remove the header, make sure the ROM has a different filename than the .ips so your emulator doesn't auto-patch the ROM again and cause corruption. The patched ROM should show up as checksum OK in some emulators because the authors fixed the internal checksum (I use ucon64 for this).

6
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.

7
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


8
Newcomer's Board / Re: Help With Super Mario Kart SNES
« on: November 28, 2019, 12:40:45 am »
Hello KurohaBecher. I found the graphics with Lunar Compress.

Put "decomp.exe", "recomp.exe", "Lunar Compress.dll", and "Super Mario Kart (US).sfc" into a folder. The Mario Kart ROM must be 524,288 bytes in size (no header)


Using Windows, hold the shift key and right click inside the folder, select "open command window here". Use the command line:

Code: [Select]
decomp "Super Mario Kart (US).sfc" graphics.bin 71996 4 0

Change the "graphics.bin" file using a graphics editor, then insert into the ROM:

Code: [Select]
recomp graphics.bin "Super Mario Kart (US).sfc" 71996 4 0
Use "sniff.exe" to find other locations like 70000, 70B29



You might want to change the colors and map data which is more work  :thumbsup:

9
Just wanted to pop in and say that it's amazing how much you all were able to get done over the past few days!  :cookie:

Yeah TheDanaAddams and Reld have put together an excellent translation. Great work!

10
Hey TheDanaAddams I don't follow, you can't find all of the script (the extra parts)? How did you translate so far, just screen by screen? Maybe a code could unlock the extra script easier.

Yeah Reld that looks awesome. I wouldn't have thought that the data wasn't finished properly. Maybe there's a size value somewhere. I tried bsnes-plus debugger and I like it, thanks for mentioning it.

11
Maybe I'll upgrade to bsnes plus's debugger. Key binding? I always click "step into" and then hold enter :'(

See if you can figure it out, you're getting close. It seems Geiger was just copying raw data into the buffer without decoding it, then at some point it catches and decompression goes normally. Maybe I saw an NMI in the middle of the decompression.

12
Ah good thinking on inhal not being bugged if it works second time around.

Looking at the original game right now (I really should go to bed) it looks like the timing is perfect, but I see Geiger decompressing the wrong data into work RAM, then correctly uploading that bad data into VRAM. I'm thinking the easiest way to do it is just have the game copy the uncompressed map directly from ROM and into VRAM. It's hard to debug it because Geiger isn't emulating it properly to begin with.

13
A few things to note on the title screen corruption. I don't know about you, but the stock rom title screen shows up corrupt every time for me in Geiger. It shows fine in zsnes and bsnes for me. So I test stuff in Geiger, zsnes (yeah I use zsnes come at me bro lol), and bsnes is the final test for me. I've had title screens show up bad in Geiger or zsnes, but if it's good in bsnes then I say good enough, but also I'd like it to work on snes classic.

Have you tried recompressing the original map data with inhal and seeing if it's identical to original? Maybe a bug in inhal. I have seen a timing issue before where I added a short delay before decompressing the data, if it's writing to VRAM while the screen is being drawn nothing gets uploaded, as you see the map works after a certain amount. I can add a small ASM hack to try to fix that.

Lastly I wonder if it's uninitialized data, and after the demo plays the game initializes it properly (I doubt it because you see it starts off bad then sets itself right).

I'll try to make a patch, probably tomorrow to wait for vsync before sending to VRAM.

14
Hey viloen, I think you're in luck. The Gameboy Advance uses the same palette format as the SNES (I think). There's a great SNES palette editor called SNES Palette Editor.

I use VisualBoyAdvance as my GBA emulator, and it has a palette viewer. Each red, green, and blue can have a value of 0 to 31. That's five bits per color which are combined into a 16 bit value, the 16th bit is set to zero, and that's how each color is stored in ROM. So pick a color in VisualBoyAdvance or another emulator, and then type those values (0-31) into Palette Editor to search for. Hopefully it'll find the color and the surrounding colors will match as well.

If you need to convert a SNES/GBA color of say white (31, 31, 31), then multiply each number by 8, getting 248, 248, 248 would be usable in modern color formats.

15
Excellent title screens, I like them both. I see the game copies the uncompressed kirby sprites below from 0x0E5F11



Is that a crown that goes on his head? Are these tiles used elsewhere in the game it has his whole body.

16
Okay I knew there was something going on when I saw two logos in VRAM. I had one of the compressed data locations wrong, here's the update

Code: [Select]
*stars title screen*
$B8:9458 0x1C1458 map data: BG1 title screen logo

*uncompressed*
$9B:C0A9 0x0DC0A9 graphics: stars background
$9E:AB47 0x0F2B47 graphics: title screen logo (stars background) (336 tiles?)

So yeah the tiles are sitting there uncompressed in ROM. But you see there are two separate logos, each slightly different if you look side by side. So if you want to make another awesome title screen just slightly different, you can put it in the game. I would recommend just reusing the same tiles because nobody's going to know  ;D

So a few things to note. Even though we can shove lots of new stuff into expanded ROM space, the programmers packed the RAM quite well, which would require more deep ASM mods to overcome. So there's enough room for 348 unique logo tiles on the blimp screen (not counting the blimp tiles, just for the logo). Since we have the map data it's actually pretty easy to put tiles anywhere you want on screen. You could even use the blimp tiles for the logo, but you'd have to get creative to have the blimp show up with missing tiles. So make sure there's no more than 348 tiles on the blimp logo.

On the stars background I counted 336 unique logo tiles (including the TM) but I could be wrong. Just make sure to not use more tiles than the original because they won't fit into VRAM without more creative mods.

Also you see the logo uses 3 palettes total. Each tile can be told to use a different palette in the map data. Map data is 2 bytes per tile. Lower 10 bits are the tile number, next two bits is palette etc like this: yxPppptt tttttttt vSNES can really help show you all the data in a savestate on either title screen.

from fullsnes:
Code: [Select]
Each BG Map Entry consists of a 16bit value as such:

  Bit 0-9   - Character Number (000h-3FFh)
  Bit 10-12 - Palette Number   (0-7)
  Bit 13    - BG Priority      (0=Lower, 1=Higher)
  Bit 14    - X-Flip           (0=Normal, 1=Mirror horizontally)
  Bit 15    - Y-Flip           (0=Normal, 1=Mirror vertically)

There are many talented romhackers around here, maybe someone else has some good ideas to help too?

Keep up the great work!

17
Hey TheDanaAddams this translation looks really cool. I like doing title screens so I was messing around and came up with a preview like this



I like your title screen better, it has more charm.



Luckily there's a program that compresses/decompresses HAL games called exhal. Using Geiger's Snes9X and vSNES I figured out some graphics and map data. Didn't see any palettes but those are easy with SNESpal since they don't look compressed. It looks like most tiles are used on the blimp screen, then the map changes a bit and uses the faux shadow tiles for the logo on the stars screen.

Here's the compressed data I found from the beginning of the game up to the title screen. The first address is the snes mem address, the second is the pc file address you can use in exhal. Use Lunar Address set for LoROM 80:8000 (because this game is fastrom) to convert snes memory locations to pc file addresses.

Code: [Select]
$80/89DF decompression routine?

$91:F400 0x08F400 graphics: Nintendo/Halken
$BB:D011 0x1DD011 map data: BG1 (Nintendo)
$BB:A2A4 0x1DA2A4 map data: BG1 (Halken)

*blimp titlescreen*
$98:CC00 0x0C4C00 graphics: title screen logo and blimp (pointer at $88:80D1 0x0400D1)
$9B:8000 0x0D8000 graphics: background hills
$9F:CF3D 0x0FCF3D graphics: sprites small Kirby, blimp, clouds
$B5:D50B 0x1AD50B map data: BG1 64x32 (logo with blimp background)
$B1:8000 0x188000 map data: BG2 32x32 (pink and green hills)

*stars title screen*
$B8:9458 0x1C1458 graphics: stars background
$B4:CFC6 0x1A4FC6 map data: BG2 32x32 (stars background)

If you are able to compress the new logo tiles and they don't fit, you should be able to append the compressed data to the end of the rom, and change the pointer at 0x0400D1 to point to the new location (pointers are byte swapped so $98CC00 shows as 00 CC 98). The end of the rom would be 0x200000 in a hex editor, or $C0:8000 as a snes location. So the new pointer would be 00 80 C0

18
Hello, would you perhaps be talking about my post here about Mystical Ninja, or this one about Super Formation Soccer? I like Psyklax's description of how graphics are stored uncompressed in rom, or decompressed from rom into work ram, and then "blasted via DMA" into VRAM, that's a great way to put it.

I have had great luck in simply bypassing compressed graphics by inserting the uncompressed data at the end of the rom, then inserting an assembly jump to DMA the graphics into ram myself, instead of the game decompressing then DMAing them to vram. This requires a log to see when the game jumps to the decompression routine, so you can jump to your own. I get the uncompressed data by letting the game decompress the data to work ram, then exporting the data before it copies it to vram. I use the snes9x debugger or Vsnes (using a savestate). The Super Formation Soccer is an example with some assembly code as well. With that I didn't use DMA, but looping assembly code to copy byte by byte. DMA is way faster but hey I'm still learning too.

Oh, and you can go and reverse engineer the decompression routine. That's not fun to me, but if you'd like to see the results I did the NBA Jam TE graphics decompression routine. I wrote a little program to decompress the data from rom and it doesn't even work on 100% of the graphics. Maybe like 26 out of 28 graphics it'll work lol.

19
Hey Psyklax, sounds like a cool project. Could you possibly post a series of output bytes that you'd expect (say 4 bytes), and also the initial .wav input bytes that produce it? I would understand the output and input data better. Your pseudo code helps, but each higher level programming language would have a different structure than the 6502 assembly, so the raw data might help us more.

This sounds fun, like the kind of thing for a programming challenge! See how many different languages we can make it in  :thumbsup:

20
Okay so somehow I did the whole patching job for Special Tee Shot by myself without knowing of any similar attempts in the past.

Hey LuigiBlood, I saw your name a few times when I looked around for romhacking BS games. I like your method of just patching the long address rather than including the assembly opcode. I was just copying a pasting from snes9x and changing the address  :-[

The patches look similar, we got tons of long addresses, the 16 bit ADC address, and the MVN. I didn't patch any two player stuff either, and mine does work in a single player playthrough. I don't think I've ever used that many savestates before lol.

Additional snes hardware always interested me, and now I know a little bit more about why BS games may have issues in older emulators, fullsnes has a lot of BS info, plus emulator source code. I hope our work can help others figure out what needs to be done to convert BS games. I think I did see some reads from the BS bios, but I didn't follow up to see what they could do. Snes9x geiger was just popping up reads and writes from unknown registers so that helped a lot. I wrote a quick program that searches for long addresses and shows them. It does show more addresses (and surely some false positives) in the game so there is more patching that can be done. Thanks for your good work!

Pages: [1] 2