## News:

11 March 2016 - Forum Rules

Main Menu

## Battle of Olympus - Rebalanced + SRAM Saving

Started by 8.bit.fan, July 19, 2017, 02:54:39 PM

#### nesrocks

#20
But the game has these sub routines to help you, remember?

First you take the tens digit and load it to the accumulator, then you use the routine that goes dec to hex. This will give your olive count in hex. Now you can manipulate this value easily however you want without worrying about digits. When you're done, use the sub routine that does hex to dec just how they did. So it is exactly the same as it was before, with the difference that instead of LSR it is your new math in there.

Leave this block as it was:
` 07:C265:A5 E1     LDA \$00E1 07:C267:A2 0A     LDX #\$0A 07:C269:20 6A D7  JSR dec to hex 07:C26C:A5 03     LDA \$0003 07:C26E:18        CLC 07:C26F:65 E0     ADC \$00E0`
Now the accumulator has your olive count in hex. Add the jump to your new sbr here.
On your sbr do your new math to the accumulator.
At the end of your sbr do the rest of the original code, and jump back:
`A2 0A     LDX #\$0A85 D7     JSR hex to dec85 E0     STA \$00E0A5 02     LDA \$000285 E1     STA \$00E160        RTS `

I mean, this is of course if you want to take a proportional value instead of just 10. If you just want to take 10 you can do how Psyklax described it, but it won't take anything if the player has 9 or less, which can be weird.

Wouldn't it be better to take 25% for example?
On your subroutine:
Push A to stack (this means storing the current A for later use. we need to "free" A because math can only be done on the accumulator)
Divide A by 2
Divide A by 2 again
Store A on \$0003 (now address \$3 contains 25% of original A)
Pull A from stack
Set carry
Subtract A with \$0003
Now A contains 75% of original A

There may be a better way to do 75% but that will work. edit: I think this may give you 255 olives if you had 0, so you just need to break right at the start if A is 0.

#### 8.bit.fan

Always great to wake up to see new posts!
Thanks again nesrocks and Psyklax for your amazing help on this!
I have to get going to work for now, but I'll settle in later and start working on this again.

And agreed. After thinking about taking 10 olives, that might actually make the game harder in the beginning. Taking 25% might be just a bit too much, but I like the percentage idea. So I have a few other ideas:

1) Remove 10% olives.
2) Remove 10 olives if player has 20 or more upon death.
3) Remove 5 olives.

What do you guys think? I think I still like taking 10% the most.

Also, I looked into the drop rate mechanism and I was also playing with that last night. I can't seem to do much as I don't understand where the table is stored. The only thing I was able to do was to change the table of 7 to 3, effectively removing the lower chances as you grind in the same area.

Anyhow, I'll check back in later.

Cheers!
In the year of 200X, a super robot named Mega Man...
http://www.8bitfan.info/
FF4 Ultima Discord: https://discord.gg/4MqjwJt

#### nesrocks

#22
After a quick google search I couldn't find a 10% math guide to 6502 assembly, so why not 12.5%? That is just an extra LSR
Found it (I knew I had seen it before) https://forums.nesdev.com/viewtopic.php?f=2&t=11336

#### Psyklax

Quote from: nesrocks on July 20, 2017, 10:22:24 AM
If you just want to take 10 you can do how Psyklax described it, but it won't take anything if the player has 9 or less, which can be weird.

That was intentional, I figured if you had less than ten then you need a bit of a chance. Though it means dying with 18 is worse than dying with 9, which I agree is weird.

Changing it to only remove 10 if you have 20 or more would be trivial, given that you'd just have to add a CoMPare command to my routine to check if the tens digit is at least 2. But you're probably worth going the extra effort for 10%, because like I always say, when it's done, it's done.

Quote from: 8.bit.fan on July 20, 2017, 02:22:25 PM
The only thing I was able to do was to change the table of 7 to 3, effectively removing the lower chances as you grind in the same area.

Personally - and I'm sure there are some JRPG nuts who will disagree - I think grinding is the work of the devil, so anything that reduces (or removes!) the need for it is good in my book.

#### nesrocks

To be honest I like zelda 2 style, where every enemy gives experience and when you die you lose it, but there's no chance that the enemy won't give anything. So I'd first adjust that the enemies have a 3/4 chance of dropping olives, and 1/4 chance of dropping extra health (there being no way they'd drop nothing), and then work from there to balance the rest with death and item cost.

#### 8.bit.fan

#25
Yes I did it!!!!
I've successfully implemented the instructions to remove 12.5% of the olives! I tested this thoroughly and it works on any amount! And since this is a LSR, no nee to check for below zero number.
Thank you SO MUCH for the guidance nesrocks and Psyklax!!

Here's the code:
Quote*************************************
07:C265:20 70 FC (removed the rest with EA's)
07:FC70:A5 E1 A2 0A 20 6A D7 A5 03 18 65 E0 48 4A 4A 4A 85 03 68 38 E5 03 A2 0A 20 85 D7 85 E0 A5 02 85 E1 60
*************************************

Quote from: Psyklax on July 20, 2017, 04:31:02 PM
Personally - and I'm sure there are some JRPG nuts who will disagree - I think grinding is the work of the devil, so anything that reduces (or removes!) the need for it is good in my book.
Agreed! But I don't mind the little bit of grinding in BoO because I enjoy the action and the music is good, it just frustrates the heck out of me when I'm about to purchase an item for 80 olives just to die right at the door...then I'm down to 40!! But a little penalty is good for the game hence this hack!
Quote from: nesrocks on July 20, 2017, 04:45:53 PM
To be honest I like zelda 2 style, where every enemy gives experience and when you die you lose it, but there's no chance that the enemy won't give anything. So I'd first adjust that the enemies have a 3/4 chance of dropping olives, and 1/4 chance of dropping extra health (there being no way they'd drop nothing), and then work from there to balance the rest with death and item cost.
Oh I love Zelda 2's gameplay and style! That's why I like this game so much also.
Yesterday when I just started out hacking, I didn't know much of assembly operations, the best I did was the penalize the player by stripping any olives in the singles digit back to zero. In a sense, that's kind of similar to how Zelda 2's level work...where you get to keep your exp/level at the baseline.

And yes, that is exactly how I wanted to make the olives drop rate. 3/4 olives and 1/4 bay leaves. But I don't know how to access the drop table. Since you made that page nesrocks, can you shed some light on how I can manipulate the drop table?

Any help would be awesome!

8-bit fan

July 20, 2017, 06:20:17 PM - (Auto Merged - Double Posts are not allowed before 7 days.)

Oh one other issue I've always had with the game, and since you guys seem to know about this game, I'd like to ask for your opinions:

Do you know why Argolis has a rock in the far right shore that prevents you from using the dolphin?

I mean logically, if you can access the shore in this area it would make traversing the map much easier and more fun especially towards the end.

Was there any reason for the blockage? Is it to prevent the player from advancing to areas they shouldn't have at that point in the game? Because if not, I'd like to remove that rock and open up the shore for this hack also!

In the year of 200X, a super robot named Mega Man...
http://www.8bitfan.info/
FF4 Ultima Discord: https://discord.gg/4MqjwJt

#### nesrocks

#26
I didn't write the page, it must have been Arc and others! Probably Bisqwit too at some point.

Looking at reads from 6C-6D when an enemy is killed it goes to some code that does what the page describes. I'd remove the whole thing that checks if the player has been farming too much on one room (why not let him do that?) and so use only table #1.

So this whole thing
` 00:80DC:A2 03     LDX #\$03>00:80DE:A5 6C     LDA \$006C = #\$4B 00:80E0:65 6D     ADC \$006D = #\$4B 00:80E2:C9 32     CMP #\$32 00:80E4:B0 02     BCS \$80E8 00:80E6:A2 07     LDX #\$07`

Becomes
` 00:80DC:A2 03     LDX #\$03`
and the rest filled with EA. So now it is always "table 1" (indicated by X holding the value #3).

EDIT: the table is located at 0x136 and it is this:
00 01 00 02 00 00 00 00

So it is actually quite simple to do this, you don't need to edit anything that I said before, just change it to 01 02 02 02 01 02 02 02 if you want 75% chance of olives with 25% chance of bay leaves at all times.

To find the table I went to this line:
`00:80F0:BD 26 81  LDA \$8126,X @ \$812C = #\$02`
As you can see, it loads a value from ROM address \$8126 + X. So, in this case X is 6 (this is just after the RNG sub routine is used to generate a X value). So the table is at \$8126 (X = 0) up to \$812D (X = 7). You can click on the \$812C address on the debugger, click the "seek to" button, then right click to the left of the code and it will bring you exactly to the position on the hex editor. Don't forget to always work with the code/data logger running if you aren't already. It helps a lot. It will highlight bytes in yellow if they are code and blue if they are data on the hex editor. The table should be all blue after a bit of playing the game.

Indeed, the way you had done it resembles Zelda 2, each full 10 olives is a milestone that secures collected olives. It's a good way to do it too, although maybe 10 units is too little for that thrill of dying just after securing it.

#### abw

It looks like you've got everything under control (congratulations!), but just in case anybody else wanders in here at some point in the future, I'd like to clarify that the routines at \$D76A and \$D785 in bank 7 are actually general-purpose multiplication (A * X = high byte in A, low byte in \$03) and division (A / X = quotient in \$02, remainder in A) routines respectively rather than specialized decimal-to-hexadecimal and hexadecimal-to-decimal routines.

#### nesrocks

Quote from: abw on July 20, 2017, 07:07:02 PM
It looks like you've got everything under control (congratulations!), but just in case anybody else wanders in here at some point in the future, I'd like to clarify that the routines at \$D76A and \$D785 in bank 7 are actually general-purpose multiplication (A * X = high byte in A, low byte in \$03) and division (A / X = quotient in \$02, remainder in A) routines respectively rather than specialized decimal-to-hexadecimal and hexadecimal-to-decimal routines.
Oh, nice! Thanks, that helps, I'll study those later to see exactly what you mean (assembly math isn't my strength)

By the way, if you want to change how many olives and bay leaves each screen can drop, change the byte at 0x1C162 to whatever number you like. So now it always drops an item from an enemy but at some point it would run out sooner or later and the player must move on the next screen. The original value is #4B (75 in dec).

#### 8.bit.fan

#29
Quote from: abw on July 20, 2017, 07:07:02 PM
It looks like you've got everything under control (congratulations!), but just in case anybody else wanders in here at some point in the future, I'd like to clarify that the routines at \$D76A and \$D785 in bank 7 are actually general-purpose multiplication (A * X = high byte in A, low byte in \$03) and division (A / X = quotient in \$02, remainder in A) routines respectively rather than specialized decimal-to-hexadecimal and hexadecimal-to-decimal routines.
Thanks abw and thanks for the info!
Always good to know that routines are for more usage than one instance so that we don't accidentally remove them thinking that they're no longer needed.

Quote from: nesrocks on July 20, 2017, 06:57:49 PM
I didn't write the page, it must have been Arc and others! Probably Bisqwit too at some point.

Looking at reads from 6C-6D when an enemy is killed it goes to some code that does what the page describes. I'd remove the whole thing that checks if the player has been farming too much on one room (why not let him do that?) and so use only table #1.

So this whole thing
` 00:80DC:A2 03     LDX #\$03>00:80DE:A5 6C     LDA \$006C = #\$4B 00:80E0:65 6D     ADC \$006D = #\$4B 00:80E2:C9 32     CMP #\$32 00:80E4:B0 02     BCS \$80E8 00:80E6:A2 07     LDX #\$07`

Becomes
` 00:80DC:A2 03     LDX #\$03`
and the rest filled with EA. So now it is always "table 1" (indicated by X holding the value #3).

EDIT: the table is located at 0x136 and it is this:
00 01 00 02 00 00 00 00

So it is actually quite simple to do this, you don't need to edit anything that I said before, just change it to 01 02 02 02 01 02 02 02 if you want 75% chance of olives with 25% chance of bay leaves at all times.

To find the table I went to this line:
`00:80F0:BD 26 81  LDA \$8126,X @ \$812C = #\$02`
As you can see, it loads a value from ROM address \$8126 + X. So, in this case X is 6 (this is just after the RNG sub routine is used to generate a X value). So the table is at \$8126 (X = 0) up to \$812D (X = 7). You can click on the \$812C address on the debugger, click the "seek to" button, then right click to the left of the code and it will bring you exactly to the position on the hex editor. Don't forget to always work with the code/data logger running if you aren't already. It helps a lot. It will highlight bytes in yellow if they are code and blue if they are data on the hex editor. The table should be all blue after a bit of playing the game.

Indeed, the way you had done it resembles Zelda 2, each full 10 olives is a milestone that secures collected olives. It's a good way to do it too, although maybe 10 units is too little for that thrill of dying just after securing it.
Quote from: nesrocks on July 20, 2017, 07:11:21 PM
Oh, nice! Thanks, that helps, I'll study those later to see exactly what you mean (assembly math isn't my strength)

By the way, if you want to change how many olives and bay leaves each screen can drop, change the byte at 0x1C162 to whatever number you like. So now it always drops an item from an enemy but at some point it would run out sooner or later and the player must move on the next screen. The original value is #4B (75 in dec).
Awesome nesrocks! Thanks again!!
I updated the code and now enemies always have drops! I opted to keep the table of 7 as I wanted to add the same amount of bay leaves and olives in the 2nd half of the table. I figured in later stages where you'll be in the same areas for a while, raising the drop of health would probably be helpful! I increased the total of health to 3 and olives to 5, so it shouldn't break the game by making it too easy. Here's the updated table:
02 01 02 02 02 01 01 02

This is wonderful and great progress so far, thanks to you and everybody else that came in here and helped! Much appreciated!!

I have to get off work and hit the road now. Later when I get back on, here are the 2 items that I still want to do for this hack:

1) Remove the gap that separates your access to the Dolphin by the shore in Argolis.
2) Add SRAM saving. (This might be impossible due to my skill level, and it just might not be possible with this ROM  )

Cheers!

8-bit fan

July 20, 2017, 10:54:21 PM - (Auto Merged - Double Posts are not allowed before 7 days.)

A quick look at the RAM on FCEUX while speaking to Zeus, it seems the password is at location:
0x014A-0x0182

nesrocks, since you brilliantly implemented SRAM saves for Super Pitfall, is this something that would be useful if I were to implement it for BoO? Just trying to figure out what would entail an SRAM save implementation...
In the year of 200X, a super robot named Mega Man...
http://www.8bitfan.info/
FF4 Ultima Discord: https://discord.gg/4MqjwJt

#### nesrocks

#30
I've been studying this for the past hour. It doesn't seem trivial to me, looking at this page https://wiki.nesdev.com/w/index.php/MMC1
Super Pitfall was converted to MMC3 for the save feature and it was quite simple to enable PRG RAM there, a simple write of #80 to \$A001 as pointed out by Disch.
But Battle of Olympus is MMC1, more specifically MMC1B2 apparently and it seems a little more steps are required. The funny thing is, I looked at other MMC1B2 boards and out of those the one that I know that has a save feature is... Zelda 2... So I think it is probably a good idea to just copy the register setting routines from the reset vector on zelda 2. Someone more versed on this may respond here to confirm or deny this before I finish my tests, but it's a fun learning experience nonetheless.

To answer your question, yes of course. A good way to save the game is to store the password bytes to wram on save, and then read those on load. But replacing a password system with a save system means changing the menus to reflect the change too, so it is quite a bit of work.

edit: "MMC1B: PRG RAM is enabled by default." so maybe nothing else needs to be done other than setting the header bit to sram enabled.

#### 8.bit.fan

Quote from: nesrocks on July 21, 2017, 01:10:30 AM
I've been studying this for the past hour. It doesn't seem trivial to me, looking at this page https://wiki.nesdev.com/w/index.php/MMC1
Super Pitfall was converted to MMC3 for the save feature and it was quite simple to enable PRG RAM there, a simple write of #80 to \$A001 as pointed out by Disch.
But Battle of Olympus is MMC1, more specifically MMC1B2 apparently and it seems a little more steps are required. The funny thing is, I looked at other MMC1B2 boards and out of those the one that I know that has a save feature is... Zelda 2... So I think it is probably a good idea to just copy the register setting routines from the reset vector on zelda 2. Someone more versed on this may respond here to confirm or deny this before I finish my tests, but it's a fun learning experience nonetheless.

To answer your question, yes of course. A good way to save the game is to store the password bytes to wram on save, and then read those on load. But replacing a password system with a save system means changing the menus to reflect the change too, so it is quite a bit of work.

edit: "MMC1B: PRG RAM is enabled by default." so maybe nothing else needs to be done other than setting the header bit to sram enabled.
Thanks nesrocks!
Something came up last night and I had to take care of my kid so I didn't have that much time to look into this. I'll definitely dive into this today and see how far I can get!

And that's great to hear that BoO uses MMC1B as you've mentioned since Zelda 2 uses the same mapper and could be simpler than storing and restoring the password for the SRAM function! Now looks like I need to read up on this and learn how to set the header bit to enable the SRAM. But even then, I'll still need to include some sort of option in the title screen to "Continue" the game, much like how you and others did to add SRAM to hacks, right?

I'll take a look at this more once I get settled at work later today.

Thanks again for your pointers!

If anyone's familiar with adding SRAM to an MMC1B game, any help would be much appreciated!

Cheers!
In the year of 200X, a super robot named Mega Man...
http://www.8bitfan.info/
FF4 Ultima Discord: https://discord.gg/4MqjwJt

#### nesrocks

#32
Use neshead tool to easily add sram to the header.  http://www.romhacking.net/utilities/665/
You can use it to add 1 8k bank for PRG RAM but I have no idea if this is needed.

I think that this is all you need to do for MMC1B, but like you said, if someone knows better please share! Ideally if you test on punes emulator and on an everdrive and it works on both, then it works.

Now what you need to do is store values on addresses \$6000-\$7FFF when you want to save. Then read from exactly the same addresses for loading.
For continuing there already is that option on the title screen. Just go straight to the game when selecting it instead of taking you to the password screen. Saving is different, you need to change the gods message to "your progress was saved" and not display a password there.

#### abw

If you're going to add SRAM and the player is never going to see a password, you could just write \$00DF-\$00F4 (the data that gets saved into the password) to SRAM directly, so the password encryption and decryption code/auxiliary data (which covers all of \$DF7B-\$E09A, among other places) and password entry screen (which I've never looked at) all become useless and you can cannibalize them for free space if needed. If that goes well, you could get fancier and add multiple save files with a selection screen as in Zelda 2, but it's probably good to stay focused on one thing at a time .

As for updating the text... I haven't actually tested this, but possibly the least disruptive approach would be to overwrite the existing text (starting at \$9A6B) with some new text that's no longer than the original text (i.e. at most 50 5-bit tokens, where each token is either a character or a table switch/formatting command. You can get the total number of tokens by counting the number of characters and manual line breaks [not including automatic line breaks after the 24th character on a line], adding 1 for every punctuation mark, and then, starting from uppercase, adding 1 more for every time you switch between numbers, upper-, and lower-case; hero/heroine names take up 2 tokens and page breaks have a side effect of resetting the current encoding to uppercase), update the text length if necessary (\$9A6A), and then redirect the call to the password generation/display routine (index \$0D) from \$DBE7 to \$DB99 (which the game actually uses as index \$04) by updating the jump table starting at \$DB23 (i.e. set \$DB3D-\$DB3E to 0x99 0xDB).

#### 8.bit.fan

Thanks nesrocks and abw for the pointers!
I got swamped at work all day and didn't have time to look into this. But I'll definitely try to find time over the weekend for this. I'll keep you guys posted!

OK, so let me repeat what you guys said, so that I understand what I'll have to do:

1) First, I'll need to grab the neshead tool and add SRAM to the header. Add 1 8k bank for PRG RAM.
2) Write routine when talking to the gods to store data from \$00DF-\$00F4 to SRAM location at \$6000-\$7FFF.
3) Write routine to load the data from SRAM location at \$6000-\$7FFF to \$00DF-\$00F4 on load/continue.

Extra(once I'm able to do the above):
4) Edit texts.
5) Multiple save files.
6) Dual save and password system.
7) Argolis.

Do the steps sound about right(especially 1-3)?

Thanks!

8-bit fan
In the year of 200X, a super robot named Mega Man...
http://www.8bitfan.info/
FF4 Ultima Discord: https://discord.gg/4MqjwJt

#### KingMike

Quote from: nesrocks on July 21, 2017, 01:10:30 AM
I've been studying this for the past hour. It doesn't seem trivial to me, looking at this page https://wiki.nesdev.com/w/index.php/MMC1
Super Pitfall was converted to MMC3 for the save feature and it was quite simple to enable PRG RAM there, a simple write of #80 to \$A001 as pointed out by Disch.
But Battle of Olympus is MMC1, more specifically MMC1B2 apparently and it seems a little more steps are required. The funny thing is, I looked at other MMC1B2 boards and out of those the one that I know that has a save feature is... Zelda 2... So I think it is probably a good idea to just copy the register setting routines from the reset vector on zelda 2. Someone more versed on this may respond here to confirm or deny this before I finish my tests, but it's a fun learning experience nonetheless.

To answer your question, yes of course. A good way to save the game is to store the password bytes to wram on save, and then read those on load. But replacing a password system with a save system means changing the menus to reflect the change too, so it is quite a bit of work.

edit: "MMC1B: PRG RAM is enabled by default." so maybe nothing else needs to be done other than setting the header bit to sram enabled.

MMC1 is a bit trickier. Some board variants have RAM write-protection while others don't.
I haven't looked at Zelda 2 much, but I wouldn't be surprised if it uses the RAM to run code, since it's an FDS port, thus needed PRG-RAM enabled. (I know Zelda 1 used PRG-RAM for code, since I encountered it in just the little bit of hacking I did.)
"My watch says 30 chickens" Google, 2018

#### abw

I played around with this a little bit earlier today and was able to get 1) and 2) done without much trouble.

1) You can use a dedicated tool for making header changes, but this step boils down to taking whatever's at file address 0x6 and bitwise OR-ing it with \$02. In this case, BoO starts with \$10, so \$10 | \$02 = \$12.
`0x000006: 12`

2) After thinking about it further, I realized that redirecting the password generation call was a dumb suggestion - we should just use that call for writing to SRAM instead. Something like this does the trick:
`LDX #\$16LDA \$DF,XSTA \$6000,XDEXBNE \$DBE9RTS`
`0x01DBF9: A2 16 B5 DF 9D 00 60 CA D0 F8 60`

After loading up the modified ROM, talking to Zeus, and closing the emulator, I did end up with an 8k SRAM file containing my save data, so yay!

3) That's right too. Once you find the continue code, replacing it with something like this should work:
`LDX #\$16LDA \$6000,XSTA \$DF,XDEXBNE -8RTS`
`0x??????: A2 16 BD 00 60 95 DF CA D0 F8 60`

At some point you'll also want to handle the case where there is no SRAM yet (first time playing).

#### 8.bit.fan

#37
Thanks KingMike and abw for the advice and pointers!
And thanks so much abw for sharing what you found in regards to steps 1-3! I'll definitely take a look at this as soon as I find time to do so this weekend! I really want to make this hack happen...just really hard to find time to fit into my super busy schedule!

In the meantime, anyone else have any other good ideas and/or pointers regarding adding SRAM to this game with saving and loading function though, keep them coming!

Cheers!!

8-bit fan

July 23, 2017, 04:18:20 AM - (Auto Merged - Double Posts are not allowed before 7 days.)

Update! (finally  )
I have completed steps 1 and 2! Thanks again for all the SRAM help nesrocks and abw!

I turned on SRAM using NESHead tool, it is as you said nesrocks, MMC1B has PRG RAM enabled and is as easy as turning it on! And like you've mentioned abw, it's at 0x000006 and just simply changing it from \$10 to \$12.

Step 2 was as you've suggested, replacing the password display routine and replacing it with a write to SRAM. It generated the SRAM file from the emulator(fecux and nestopia) and looks like I'm on the right track! Very exciting!!

(BTW, I did as abw had suggested and put the write to SRAM routine at 0x01DBF9...is this where the password display routine was originally? The reason I ask is perhaps eventually, I might want to have a dual save+password system, like the Castlevania II English Re-translation (+Map) hack http://www.romhacking.net/hacks/1032/)

OK! Just one more step now!! I need to somehow LOAD the SRAM by selecting "CONTINUE" at the title screen instead of taking the player to the password screen...

Any good suggestions?

8-bit fan

July 23, 2017, 02:42:31 PM - (Auto Merged - Double Posts are not allowed before 7 days.)

Ok so I've tried to add the routine to load the SRAM upon selecting "START" at the title screen. It garbled up the screen and it weirdly took me to the password input screen instead. I'm probably doing something wrong, as I still don't fully understand how to use FCEUX's debug tools such as the trace logger, etc.

With that said, I wonder if my original idea would actually be easier to implement...which is to save the password to SRAM upon speaking with the gods, and then write a routine on selecting "CONTINUE" at the title screen so that the password would get loaded from the SRAM and autofill at the password screen.

I've been starring at this for about 5 hours now, I need to rest my eyes for a bit!

What do you guys think? Should I stick with the "load" function? Or should I redo the whole thing and do the "password autofill" function instead?

Any help and/or suggestions would be much appreciated!

Thanks!!

8-bit fan

July 23, 2017, 09:47:01 PM - (Auto Merged - Double Posts are not allowed before 7 days.)

Update!
I was able to store the password to SRAM!
Here's the code:
Quote07:E008:9D 69 01
to
07:E008:9D 00 60

0x01E019-A: 69 01
to
0x01E019-A: 00 60
I haven't tested out if this would break anything yet, but I simply changed the STA from \$0169 to \$6000 where the SRAM is located.

Now I need a routine to autofill the password upon "CONTINUE" at the title screen...

8-bit fan

July 23, 2017, 10:27:55 PM - (Auto Merged - Double Posts are not allowed before 7 days.)

OK!
I tested this out by copy/pasting the password from \$6000 to \$0169 manually at the password screen using the Hex Editor and then press start, and it worked! So right now I just need a routine that paste/autofill that password on the screen after pressing start on "CONTINUE".

I added a write breakpoint at \$0169 and found some instructions around 07:E966. I tried to write a routine to have the password autofill but I can't seem to get it working...I'm probably doing something wrong. This is what I tried to replace:

Quote07:E962:A9 FF     LDA #\$FF
07:E964:A0 1A     LDY #\$1A
07:E966:99 69 01  STA \$0169,Y @ \$0191 = #\$00
I tried to change "A9 FF A0 1A" to "A2 18 BD 00 60":
Quote07:E962:20 70 FC  JSR \$FC80
07:E965:EA        NOP

07:FC70:A2 18     LDX #\$18
07:FC72:BD 00 60  LDA \$6000,X @ \$6001 = #\$0C
07:FC75:60        RTS ----
...thinking to replace the autofill FF's with autofull the stored password in the SRAM. But it didn't work...

What am I doing wrong? I added the subroutine because the instructions I wrote needed more space. But either way, it didn't seem to work either...

I've been going at this the whole afternoon and going to take a break...
In the meantime, anyone has any suggestions?

Thanks!

July 24, 2017, 01:29:39 AM - (Auto Merged - Double Posts are not allowed before 7 days.)

After thinking about this more, I figured a "LOAD GAME" at the title screen should function similarly, if not the same, as the "RETRY" option upon death. Here's what I'm thinking...

1) Load SRAM(password) to RAM \$0169 at bootup
2) Then have option to "LOAD GAME", which uses the same routine as "RETRY".

This should work. I tried manipulating the password at \$0169 RAM before I hit "RETRY", and it takes you to the correct point in the game according to the password.

However, I'm such a newbie at hacking and using fceux, I need some help.
What do I need to do to check, or catch, the routine in the ROM that activates when the player hits "RETRY"?
Can someone that's more familiar with fceux give me some pointers? I tried using the Trace Logger but the results are so massive that I don't even know where to look!

Also, how would I add the "LOAD GAME" option(that functions the same as "RETRY") at the title screen in between "START" and "CONTINUE"? Or would I have to remove "CONTINUE"? Because I do want to keep the option to use the password as well.

Any help would be much appreciated!

8-bit fan

July 24, 2017, 03:58:06 AM - (Auto Merged - Double Posts are not allowed before 7 days.)

Ok, more progress...on generating password autofill at the password screen. (yes, I'm going back and forth in different methods to accomplish this, I'm trying everything to make this work.)

I am able to retrieve the password from SRAM #6000 and loading it to the password screen. However, because of my little knowledge in assembly, I am only able to autofill the password with only 1 of the characters from the string of 24. So...instead of the default autofill of FF's, I can autofill with 1 of the 24 characters from #6000 repeatedly...

Here's my code:
Quote07:E962:20 70 FC  JSR \$FC70
07:E965:EA        NOP
07:E966:99 69 01  STA \$0169,Y @ \$0191 = #\$00

07:FC70:A2 18     LDX #\$18
07:FC72:BD 00 60  LDA \$6000,X @ \$6004 = #\$1E
07:FC75:A0 1A     LDY #\$1A
07:FC77:60        RTS ----
So right here "07:FC70:A2 18", this decides which of the characters from the 24 to autofill. At first I thought it means the length to load from #6000...but instead, it only loads that one character! If I can somehow populate the stored password #6000 in its entirety, then this would be done!

What's wrong with my code? Any help would be great!

8-bit fan

July 24, 2017, 03:46:33 PM - (Auto Merged - Double Posts are not allowed before 7 days.)

Looks like....I did it...!!!!
I was able to load/autofill the password to the password screen but the characters don't show up...they're invisible! ...but all you need to do is press start again, and you're back where you last talked to the gods!!

Now because of my lack of assembly skills, my code is UGLY. I pretty much brute forced it.
Here it is:
QuoteOriginal code:

07:E962:A9 FF     LDA #\$FF
07:E964:A0 1A     LDY #\$1A
07:E966:99 69 01  STA \$0169,Y @ \$0169 = #\$00

Change to:

07:E962:20 80 FC  JSR \$FC80
07:E965:EA        NOP
07:E966:EA        NOP
07:E967:EA        NOP
07:E968:EA        NOP

07:FD40:BD 00 60  LDA \$6000,X @ \$6000 = #\$0B
07:FD43:A0 00     LDY #\$00
07:FD45:99 7C 01  STA \$017C,Y @ \$018B = #\$00
07:FD48:A2 14     LDX #\$14
07:FD4A:BD 00 60  LDA \$6000,X @ \$6000 = #\$0B
07:FD4D:A0 00     LDY #\$00
07:FD4F:99 7D 01  STA \$017D,Y @ \$018C = #\$00
07:FD52:A2 15     LDX #\$15
07:FD54:BD 00 60  LDA \$6000,X @ \$6000 = #\$0B
07:FD57:A0 00     LDY #\$00
07:FD59:99 7E 01  STA \$017E,Y @ \$018D = #\$00
07:FD5C:A2 16     LDX #\$16
07:FD5E:BD 00 60  LDA \$6000,X @ \$6000 = #\$0B
07:FD61:A0 00     LDY #\$00
07:FD63:99 7F 01  STA \$017F,Y @ \$018E = #\$00
07:FD66:A2 17     LDX #\$17
07:FD68:BD 00 60  LDA \$6000,X @ \$6000 = #\$0B
07:FD6B:A0 00     LDY #\$00
07:FD6D:99 80 01  STA \$0180,Y @ \$018F = #\$00
07:FD70:A2 18     LDX #\$18
07:FD72:BD 00 60  LDA \$6000,X @ \$6000 = #\$0B
07:FD75:A0 00     LDY #\$00
07:FD77:99 81 01  STA \$0181,Y @ \$0190 = #\$00
07:FD7A:A2 19     LDX #\$19
07:FD7C:BD 00 60  LDA \$6000,X @ \$6000 = #\$0B
07:FD7F:A0 00     LDY #\$00
07:FD81:99 82 01  STA \$0182,Y @ \$0191 = #\$00
07:FD84:60        RTS ----------------------

**********************************************
0x01E972: 20 80 FC EA EA EA EA
0x01FC90: A2 00 BD 00 60 A0 00 99 69 01 A2 01 BD 00 60 A0 00 99 6A 01 A2 02 BD 00 60 A0 00 99 6B 01 A2 03 BD 00 60 A0 00 99 6C 01 A2 04 BD 00 60 A0 00 99 6D 01 A2 05 BD 00 60 A0 00 99 6E 01 A2 06 BD 00 60 A0 00 99 6F 01 A2 07 BD 00 60 A0 00 99 70 01 A2 08 BD 00 60 A0 00 99 71 01 A2 09 BD 00 60 A0 00 99 72 01 A2 0A BD 00 60 A0 00 99 73 01 A2 0B BD 00 60 A0 00 99 74 01 A2 0C BD 00 60 A0 00 99 75 01 A2 0D BD 00 60 A0 00 99 76 01 A2 0E BD 00 60 A0 00 99 77 01 A2 0F BD 00 60 A0 00 99 78 01 A2 10 BD 00 60 A0 00 99 79 01 A2 11 BD 00 60 A0 00 99 7A 01 A2 12 BD 00 60 A0 00 99 7B 01 A2 13 BD 00 60 A0 00 99 7C 01 A2 14 BD 00 60 A0 00 99 7D 01 A2 15 BD 00 60 A0 00 99 7E 01 A2 16 BD 00 60 A0 00 99 7F 01 A2 17 BD 00 60 A0 00 99 80 01 A2 18 BD 00 60 A0 00 99 81 01 A2 19 BD 00 60 A0 00 99 82 01 60
**********************************************

If any of you know how to refine/simplify the code, feel free to let me know!
Until then, good thing there are lots of empty spaces in this ROM!

I'll post a beta ips patch later today for anyone that wants to check it out!

Cheers!!

8-bit fan

July 24, 2017, 07:39:18 PM - (Auto Merged - Double Posts are not allowed before 7 days.)

Here's the IPS:
http://www.romhacking.net/scratchpad/8112/

Things done so far:
1) 1/8 of olives taken away instead of 1/2 upon death.
2) Increased olives/bay leaves drop rate.
3) Save Game when speaking to the gods.
4) Load Game by hitting START at the password input screen.

I was able to change the text at the password screen to tell the player to hit START to LOAD GAME. I wanted to change the text while speaking to the gods to tell the user that the game has been saved as well, but I haven't found where in the ROM it's located yet.

Any suggestions and/or input are welcomed and much appreciated!

Cheers!

8-bit fan
In the year of 200X, a super robot named Mega Man...
http://www.8bitfan.info/
FF4 Ultima Discord: https://discord.gg/4MqjwJt

#### nesrocks

#38
I'll read it througly later, but I say don't change the look or amount of options of the title screen. Meaning, get rid of passwords entirely (user point of view). Continue = load the saved game.

edit: alright, since you managed to do it, it's great to have both

#### 8.bit.fan

#39
Thanks KingMike for moving my topic!
Quote from: nesrocks on July 24, 2017, 09:43:02 PM
I'll read it througly later, but I say don't change the look or amount of options of the title screen. Meaning, get rid of passwords entirely (user point of view). Continue = load the saved game.

Hey nesrocks!
Sure you can look through my notes above if you'd like, I just documented my success and fail progress. But looks like I've already done it!

Since this topic got moved, I'll reiterate my last post to get everyone up to speed:

The beta is ready for anyone that wants to check it out.
Here's the IPS:
http://www.romhacking.net/scratchpad/8112/
https://drive.google.com/open?id=0B3c4zWxe_g5ONmVjY0pyVGxKb0E

Things done so far:
1) 1/8 of olives taken away instead of 1/2 upon death.
2) Increased olives/bay leaves drop rate.
3) Save Game when speaking to the gods.
4) Load Game by hitting START at the password input screen.

I was able to change the text at the password screen to tell the player to hit START to LOAD GAME. I also wanted to change the text when speaking to the gods to tell the user that the game has been saved, but I can't seem to find where in the ROM that's located.

Does anyone know how to change:
Quote"Hear the word of the gods. Don't forget it."
to:
Quote"Hear the word of the gods. Game Saved."
?

I've also play tested it for a while and everything seems to be in working order, and you still have the option to use your own passwords!

What I'd like to do still:
1) Further optimize the LOAD function. Having an empty password screen while hitting START to LOAD the game seems a little weird. Because I do want to keep the option to input your own password, I'd like to somehow have the saved game password autofill on the password screen.
2) Text change at the gods from "Don't forget it" to "Game Saved".
3) Remove gap at the shore in Argolis so that the player can access the Dolphin in the area.

Any suggestions and/or input are welcomed and much appreciated!

Thanks!!

8-bit fan
In the year of 200X, a super robot named Mega Man...
http://www.8bitfan.info/
FF4 Ultima Discord: https://discord.gg/4MqjwJt