News: 11 March 2016 - Forum Rules

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 - DougRPG

Pages: [1] 2 3 4 5 6 ... 8
ROM Hacking Discussion / Re: Editing text in Shadowrun (SNES)
« on: June 29, 2021, 06:42:53 pm »
The size of the original game is 1MB (8Mbit), so you need to expand to 2MB (16Mbit).
About the expansion, I think you don't need to do anything to run in Bsnes+, but in some cases you'll need a custom manifest file to inform the game's memory map.I don't think it's the case for a simple expansion to 2MB.

ROM Hacking Discussion / Re: Editing text in Shadowrun (SNES)
« on: June 27, 2021, 01:04:22 pm »
I don't know what a jml looks like in machine code so I use this as a reference:

Hi, are you trying to write machine code by hand? You need an assembler like Bass, xkas, wla, etc. I used Bass in this project.

You are in the right direction, but now you need to study the cpu assembly and addressing modes to understand the difference between "lda $cf" and "lda [$cf]".

You can do everything with the assembler, including inserting the new strings.

About the expansion, the game is Lorom with 1MB using the region 80-9f:8000-ffff, so just expand the rom to 2MB (filling with 0) and use the new megabyte at a0-bf:8000:ffff.
I think you can use Lunar Expand to do this expansion, otherwise just create a python script to append a bytearray of zeroes to the rom.

So the next step is to read some articles about assembly and learning how to use the assembler. Regarding the assembler, I always have a original rom and I have a script to copy the original rom to a new file and apply the changes on this new file.

ROM Hacking Discussion / Re: Editing text in Shadowrun (SNES)
« on: June 24, 2021, 09:28:58 pm »
A little help: I read my code here and the Huffman routine starts at $81aec0, but the routine is called from $80fe57. The dialog is located at address $cf.
So you'll need to do something like this:

Code: [Select]
  jml (empty_region_address)
  rep #$20
  lda $cf
  cmp #$1234 //Change to the address you want to monitor
  beq handle_this_dialog
  cmp #$5678 //another dialog. Change to the address you want to monitor
  beq handle_this_another_dialog
  lda [$cf] //optional. If you want to do your own stuff, read the data byte and proceed with you own algorithm and forget Huffman.
  jml 0x81aec0 //optional. Otherwise jump to $81aec0 to continue normally with the huffman routine.

  //here you will copy the new string to $21a0. Why $21a0? Homework. Do some debugging on the Huffman routine.

ROM Hacking Discussion / Re: Editing text in Shadowrun (SNES)
« on: June 23, 2021, 09:07:49 pm »
Hi, you can't change some compressed chars changing some bytes like you described some posts above. Huffman works with bits, not bytes, so you have codewords of different bit sizes and they start and finish anywhere inside a byte.

If you want to change the price of only a few dialogs you can do it "manually". You put these dialogs somewhere in the Rom, uncompressed. At the beginning of the Huffman routine you jump to a new place where you'll put your code. You compare the current dialog pointer with the pointers you want to monitor. If not them, jump back and do the normal flow. If the current pointer is one of the desired dialogs, just copy the uncompressed dialog to the address the Huffman routine copies them and bypass the Huffman decompression.
This is a very good exercise to learn some romhacking and I think you can do it.
Any question just ask.

ROM Hacking Discussion / Re: Editing text in Shadowrun (SNES)
« on: June 23, 2021, 05:37:27 pm »
Hi, I was able to translate this game and you need to be a little more creative to accomplish that.
Here in rhdn you can find a code to extract all the game's dialogs. So the dialogs are together in a single block, and with that code you can extract and find the starting address of every dialog. Right?
Ok, nothing new here.
The problem is that there isn't a single pointer table in this game. You can find some small tables for some related dialogs, but for a lot of dialogs the pointers are hardcoded and spread all around the code. So changing every single pointer would be a nightmare for a long time.
So my solution? Simple, every dialog is compressed with Huffman, right? So the game has a Huffman routine that receives the dialog pointer to extract, right? Remeber this fact. Now I put all my translated dialog in a single block in an expanded area. I know the pointer for each of these new dialogs because I created this new block. So after that I went in all the starting addresses for the original dialogs (I have them when I run the extractor code, remember?) and put there the 3 byte address for the new translated dialog (now in the expanded are). So I overwrote the first 3 bytes of each compressed dialog with the new address (the original dialog is now corrupted). Finally I changed the Huffman routine to, at the beginning, get the first 3 bytes of the dialog, that now is the pointer to the new translated dialog, and get the data from there. So I added a little indirection. And I removed the Huffman and put a new algorithm of my own.
This way I didn't change a single pointer of the game, only added an indirection.

The only problem related to this solution was for the dialogs that had less than 3 bytes of compressed data, because this way I couldn't add the indirection pointer. Fortunately there were less than 5 of such dialogs, and for those I had to do the indirection manually.

But the text was the easiest part. The real problem was the dialog windows, where they are all hardcoded and totally unrelated from the dialogs.

You need to debug the game to understand how the compression works and create your own code to decompress the data you want.
Two games may have the same format for the compressed data, but you'll need to debug anyway to find pointer tables, change routines and/or a lot of other stuff.
So even if you have a generic compressor that could work with some games, it means nothing to you if you don't know how to debug and change the game's code.
You can find a custom tool for some specific games, but in this case someone else did the job for you (it's fine if your goal is only to translate the text).
So focus in programming/debugging if you want to work with compression.

Hi, you first need to understand the Genesis memory map. The Genesis maps the Rom on the first 4MB of memory. This is the best of the worlds, because the Rom addresses starts on 0x0. So, if your Rom has only 1MB, for example, it's because the developers saved some money using only one 1MB chip, instead of a more expensive 4MB chip.
So answering your question, you only need to increase the file size to 4MB to expand. But like the other guys said, you need to be aware of where the game maps the Sram. It's an implementation detail chosen by the developers, but affects the PCB, because the game's hardware needs to know when to access the data chip or the Sram in the cartridge. Most games maps the Sram to 20:0000-ffff. The PS4 also maps the save to 20:0000-ffff, so the developers made some kind of mapper in the cartridge using the !TIME pin because the Rom has 3MB and also uses the 20:0000-ffff for Rom data. But I think to do a translation you don't need to worry about that.

Adding a little info, the Lunar Expand was made because on the Snes the Rom is mapped in several parts of the memory map, so there are several places to put the Rom data, and depending on the Rom size some parts of the Rom will be mapped in different regions. So expanding is not so straightforward like the Genesis, that only maps on 00-3f:0000-ffff.

Another info, actually the Genesis maps the first 10MB to Rom data, and not only the first 4MB. You can use the 40-7f banks if you want, but no one used this region back on the day because this region is used by the Sega CD. So you can make an 8MB cartridge and it will work without a mapper, as long as the Sega CD is not connected. For emulators you can use this region, as long as the emulator implements this behaviour. Most emulators only cares about licensed games, so most emulators don't support this.
The last 2MB, banks 80-9f, you can also use for Rom, but seems that in this region the processes demands a manual manipulation of the DTACK pin, so is a little more work.

Amazing work! You guys made a great team. Keep going  :thumbsup:

Programming / Re: Hacking the Linux Kernel?
« on: September 25, 2018, 07:08:00 pm »
Which programming language do you think Linux should be programmed in?

I think he thinks that if the kernel were programed in a more "recent" language, like go, python, rust, etc, it would be more powerfull.

6MB, the maximum supported SNES ROM size.
Although anything above 4MB required a non-standard cart PCB.

You have 11.9MB of Rom space in the address map, so you can have an 11.9MB rom if you want. You can have any size you want with a mapper (like MSU-1), but without mapping control in you game code you can have up to 11.9MB. Of course you'll need some nasty logic in the Pcb to distribute the rom data in the correct regions, but I'm talking by the code perspective.

Personal Projects / Re: Tengai Makyou Zero translation project
« on: October 31, 2017, 09:57:01 pm »
The random encounter rate is normal compared to others Snes games, in my opinion. It's like Final Fantasy 6 (or less).
Nowadays this type of game is not so commom anymore, but games up to Playstation 2, like Dragon Quest 8, has an even higher encounter rate.
Remember, this is an 1995 game for Snes. You need to play it with a nostalgic feeling in your heart. Don't compare to recent games.
And don't compare with Chrono Trigger either. Chrono Trigger is an aberration. Chrono Trigger is a master piece among master pieces.

Personal Projects / Re: Tengai Makyou Zero translation project
« on: October 21, 2017, 05:31:14 pm »
Congrats on the release! :thumbsup: BTW: Are you planning to submit a news post?

Yes, Tom, do it! I think this way the translation will appears at the first page.

Personal Projects / Re: Tengai Makyou Zero translation project
« on: October 21, 2017, 04:41:32 pm »
Is it really correct to update to the current system date?  Most devices that have an internal clock allow you to set the date to whatever you want, and then they keep time after that.  I think I should be able to set it to 2010 and have time track from there, for instance.

Ok, you could keep saved the date you entered the first time you played the game and just update the time by the offset since then, when you load the game again.
But you should consider the offset at least, otherwise the clock system looses sense. For example, if the last time you played was 01/10/2010 1:00pm, and you play again two weeks later at 2:00am, so the time should advance 2 weeks and be at 2:00am. But if you load the game 2 weeks later at 2:00am and the game is still at the time you last played then it's wrong.

October 21, 2017, 05:00:29 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Bsnes v087 seems to be working fine. It loads a previous Sram save and keeps the correct advanced time. The when you loads a emu savestate it also updates the date.

You can download bsnes v087 here:

Personal Projects / Re: Tengai Makyou Zero translation project
« on: October 21, 2017, 04:24:10 pm »
The Snes9x_tmz is doing the correct thing. Even loading a save state updates the date to the current system date.

So for now you should use a Snes9x core emulator. Seems that Bsnes v087 is working, but we should see if when loading a emulator save state (not the sram save state) the date keeps updated. At least v105 loads the date at the moment you saved, that's not the desired behavior.

Personal Projects / Re: Tengai Makyou Zero translation project
« on: October 21, 2017, 04:12:08 pm »
Higan v105 Rtc feature isn't working. After loading a save the date goes to 0-0-2000.

The problem happens when you load the Sram save. A commom save state restore the state correctly, but with the date at the moment you saved, so not what we want.

Even loading a save state should update the rtc to the current system time.

Personal Projects / Re: Tengai Makyou Zero translation project
« on: October 21, 2017, 03:02:53 pm »
I can't make it run with any emulator, it says "all ok" reset, but nothing.
Tried snes9x_tmz, Tengai Makyou Zero (Japan).rtc
in every folder, nothing.

Nothing with bsnes-classic, it doesn't have folders atleast in root, maybe in some
obscure directory or something

Probably you are using an invalid rom. Try to patch again with the correct japanese rom.

October 21, 2017, 03:23:26 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Guys, here snes9x_tmz seems to be working to me. I save the game, close the emulator, open and reload the save again and the date is the same.

Edit: And the date is even being update to my system date, so it's working as intended here. Tom it didn't work for you? Seems that there is come king of bug. We need to find the trigger.

Here bsnes v086 isn't working. After loading a previous save the date is messed up. But seems that v087 changed some stuff regarding the Spc7110 and rtc, so probably it was fixed in v087. I'll try v105.

Personal Projects / Re: Tengai Makyou Zero translation project
« on: October 21, 2017, 02:21:14 pm »
I'll try to fix RTC of this Snes9x I have here.

Personal Projects / Re: Tengai Makyou Zero translation project
« on: October 21, 2017, 02:05:55 pm »
Here the cartridge is working fine. When I reload a previous saved game it shows the current time, as intended.

In the cartridge the Rtc is a independent chip that keeps turned on when you turn off the console (powered by the game's battery).
But in emulators I don't know how this works. The emulator shoud update the rtc file with the current system time when loading the game.

Personal Projects / Re: Tengai Makyou Zero translation project
« on: October 21, 2017, 12:52:37 pm »

Pages: [1] 2 3 4 5 6 ... 8