[Marcelo_20XX]

I am working on a personal project to tweak some aspect of CV3 but I stumbled on this issue. I want to remove the Random dropping of subweapons from enemies, can someone shed some light on it, thank you!

[FAST6191]

I am not so familiar with Castlevania III (I usually go for the GBA and DS entries in the franchise) so going for the more general approach.

Do they drop anything other than sub weapons? It is not particularly troubling if they do but it might change something, or make something marginally more tricky.

Anyway do enemies have health here, or even better regenerating health? If they do then do the infinite health cheat search routine but for their health (might want to nerf your character as best you can to give you more searches). Probably better if you don't do it with a boss character as their drop routines might not be the same.

Once you know the health location for the enemy you can set a breakpoint on the health location. When it is reduced to 0 it will trigger a whole bunch of things ranging from death animation to any experience, loot drops and whatever else.
Hopefully it calculates the loot drop there and then with a random generator but it could go another way. If there are multiple things then you can force it to be one of the others somehow (whether you forcibly add something, set a given return or do the whole "IF blah then do this ELSE carry on as normal" thing). If it is just the one drop type then force the drop or not thing to give you nothing.
On rare occasions games will decide if and what to drop as soon as the enemy is created but the death/zero health thing will still allow you to figure out what you need to do here.

If they don't have health you are still going to want to find out what happens when they die. Score increases, experience points, enemy counter for final report on the game... find something that happens as a result that you can reasonably search for via a cheat and go from there. If there is nothing else then time to play with hit detection but I try not to go there right away if I don't have to.



For the GBA and DS games you do also sometimes have an "increases drop rate" equip which can help narrow things down a bit, or at least provide another approach if it factors such a thing into the calculations somewhere.

[Marcelo_20XX]

Thank you for your advice, regular enemies (not Bosses) have random drops and one of them are subweapons, but they could drop hearths, Big hearths and if the conditions are met the II and III item (which enable to fire 2 or 3 consecutive subweapons at once). They appear to have health as some enemies die in more than one hit...

The cheat search approach is a good start as I managed to change things on SNES with this method followed by good old assembly...

Is NES assembly harder than SNES one?

[FAST6191]

I am not terribly well versed in NES assembly, and as I tend to come from later systems I find some of its limitations and underlying concepts a bit strange* but it is nothing too troubling.  https://wiki.nesdev.com/w/index.php/6502_instructions

*from a PC and GBA/DS where there are dozens of general purpose registers and instructions act like said registers are just part of the command to the NES where there are 3 or so depending upon how you want to view it and instructions are considered as unique to those registers...
Similarly such things are a bit limited compared to later systems with regards to the operations available. Still can do things but you have to build up to it. Some also come to enjoy its simplicity, can't say I do myself but I can see where such people are coming from.

As far as this hack is concerned it should be no great issue as it is not like you are trying to wedge in a whole new routine as much as disable something a game does, tweak within existing parameters or divert existing functionality away from an outcome.

Looking at https://strategywiki.org/wiki/Castlevania_III:_Dracula's_Curse/Items it seems like this might be a slightly more complex than I thought it might be (I was thinking three drops rather than between 7 and 15 depending upon how it is counted -- the NES being 8 bit means that while you could do random, or a biased random which usually means a different range, between 0 and 15 I could also see one bit per drop type and the sub weapons being kicked to another, which might also help with the different characters being denied different things. Still you should see a random calculation somewhere in there for it all and you would have to figure out what means what there. Or at least enough to tell it "if sub weapon do this instead".

I also had a look at http://datacrystal.romhacking.net/wiki/Castlevania_III to see if it might have something. Sadly not, and while some of the hacks messed with item stats they did not necessarily have an easy path to drops. Did tell you where the score was held in RAM though so you can start with that if you like for the search rather than find health. Health might be better as things flow from that, as opposed to score which is probably one of the results of it, but easy enough to carry on working backwards for one or two steps.

[Marcelo_20XX]

I am just "this" close to finally disable the subweapons drops from regular enemies. The thing is that I found the routine on the original Castlevania rev A, but with some luck I hope it will be mostly the same on Castlevania III. I will update this post when I have found the solution along with some tweaks I already made on the first game like:
- Dont lose subweapon, whip power and double/triple when dying

EDIT 1: Regarding the differences between NES and SNES assembly I can tell that, as one would expect, there is less opcodes to work on the NES and the biggest change I miss is that there is not a Branch Always Opcode

[FAST6191]

EDIT 1: Regarding the differences between NES and SNES assembly I can tell that, as one would expect, there is less opcodes to work on the NES and the biggest change I miss is that there is not a Branch Always Opcode

Assuming you don't care to abuse JMP then you could probably define a pseudo instruction to BEQ and BNE back to back (had a quick check and there was no mention of flags resetting when activated but we are somewhat outside my comfort zone at this point). I don't know if any assemblers have such a thing already but I would not be entirely surprised.

Failing that http://www.6502.org/tutorials/6502opcodes.html#BEQ

There is no BRA (BRanch Always) instruction but it can be easily emulated by branching on the basis of a known condition. One of the best flags to use for this purpose is the oVerflow which is unchanged by all but addition and subtraction operations.

[Marcelo_20XX]

I miss the BRA opcode because it makes so easy to quickly browse existing code by modifying a single byte and see if it changes something on the game, JMP is always a 3 length byte opcode so you cant replace any existing branch opcode

[bogaabogaa]

This is actually done in the Curse of the Moon hack. I was asking red x how he had done it bat he lost his notes..

He did explain me two methods how I could go about to find some of the table I was looking for. But I failed at finding them so far. Here is his mail to me.
There are a lot of info around all scattered but so far I was never lucky to find the things I was looking for. Like random drops, Level transition table/values or general item drop tables.

 

Spoiler:

I have an idea for finding the addresses you are looking for. I am certain that the game has tables for candle/enemy drops somewhere in the ROM. The table of drops is what you are looking for. Once you find it, you can eliminate drops by setting all of the values in the table to 00, which almost always means empty, or null. A table is just a list of bytes that have a particular meaning. For example, the documentation I sent you earlier has the following:

Character IDs:
00 Trevor
01 Syfa
02 Grant
03 Alucard

subweapon IDs:
01 axe
02 cross
03 dagger
04 holy water
05 fire book
06 ice book
07 lit book
08 grant dagger
09 grant axe
0A alucard fireball?
0B watch

A table for candle drops is probably indexed based on your character, meaning that your drops change depending on what character you are. In the CPU this is done by loading the base address of the table and adding to it the id the your current character. For example, suppose the following was in the ROM at address 0x3000:

03 05 08 00

these four bytes represent the subweapon IDs that will drop based on your character. Another way to think of it is:

trevor gets knife
syfa gets fire book
grant gets knife
alucard gets nothing

If your character is syfa, the game would do the following:

load address 0x3000
add the id of your character (01)

this will load the byte at 0x3001, containing the value 05, which has the ID of the fire book.

I found two addresses for your current character: $0082 and $054E. I believe that the latter is what the game uses when checking for item drops.

The fact that the game uses the ram address for your current character is something that you can use to your advantage. You can take two approaches to find the code:

1. Find a candle that has drops for multiple characters. Document the items that drop for each character. Then open the game in a hex editor and do a hex search for those four values together. Using the example I made up earlier, you would search the ROM for the values 03 05 08 00. If you find multiple locations that match, change the value that drops for your character at that location to something else, save the change in the hex editor, reload the ROM in your emulator, and see if the drop changes. If it does, that location has one of the tables you are looking for.

2. you can create a log where you hit a candle with a subweapon for your character, then search that log where the address $054E is loaded into the x or y registers. The value you are looking for is the value of the pointer that is being indexed.

Using either of these approaches will allow you to find one of the drop tables. Once you find one, your work is almost done, because all of the drop tables for each candle will be next to each other. As for changing the drops into meat, or money bags, those have their own item codes. You can find them by changing the drops for a candle to a number that hasn't been identified and see which one produces the item you want.

[Cyneprepou4uk]

If drops are based on character's id, there is an easier method. Set a read breakpoint to id ram address during being on a level, try jumping, attacking, whatever. Forbit all these breakpoint's hits. Then kill an enemy that drops something, and the next hit should be what you are looking for.

[Psyklax]

the biggest change I miss is that there is not a Branch Always Opcode

I agree that it's a pity they couldn't include BRA in 6502 assembly, but when I want to do it, I follow the advice I saw in a 6502 assembly explainer:

"There is no BRA (BRanch Always) instruction but it can be easily emulated by branching on the basis of a known condition. One of the best flags to use for this purpose is the oVerflow which is unchanged by all but addition and subtraction operations."

So I use BVC and I've never had an issue.

[bogaabogaa]

Thanks for the suggestion Cynerprepou4uk.

I did try this today for a view hours. It did never occur to me to add breakpoints so I can disable them ^^
I only got a small heart as a drop and it has a chance to be a sub-weapon.. the longer it goes the higher the chance it feels like.
I did poke a lot of addresses but not found one of the tables so far. (guess will try a other time and see if new routines show up that point to the right location in the ROM)

[Cyneprepou4uk]

Code starts at $B57B (bank #0B), it triggers when you kill an enemy. $001A is a frame counter, and you will get a drop with 1/8 chance. If you are lucky, game will increase drop counter $00CE and you will get a heart. When $00CE reaches #05, you will get a random subweapon/big heart at $B5B7.

Maybe I'm wrong about something cause I never played this game and this is what I've learned during a short time. You take it from here.

If you want to know how did I figure this out - I made 2 almost identical savestates where I'm in a middle of attacking an enemy. One save drops a weapon, other doesn't. I usually copy ram from one save to another so I can find addresses which make influence to a certain action, but it did't work for me this time, most likely because rng code is constantly executed before nmi. Anyway it seems like random is involved for drops. I couldn't figure out how to change players here (speaking of players' id and whatever), so I just checked rng addresses $001F and $0020 for some breakpoint hits during a kill with a subweapon drop. Then I tracked executed code with trace logger, and here we are. These are save files if you need them https://www.sendspace.com/file/8tmj9h
May 26, 2019, 06:03:44 pm - (Auto Merged - Double Posts are not allowed before 7 days.)

So I use BVC and I've never had an issue.

Using flag V is Very dangerous. Can you guarantee that all existing ADC/SBC/BIT game's instructions will never get V = 1?

[Psyklax]

Using flag V is Very dangerous. Can you guarantee that all existing ADC/SBC/BIT game's instructions will never get V = 1?

I think "dangerous" is a bit much - it's only a game. But seriously, I would only use such a thing if I knew for sure that the specific scenario in which I used it would never have any connection to V. The flags are generally set by the instructions immediately before, so it's not as if an ADC or SBC somewhere else in the code is going to be affected by this BVC. If there is an ADC, then the V will get reset back to normal the next time something else hits the flags.

If in doubt, test. Otherwise, you could, as the tutorial suggested, branch "on the basis of a known condition", so you could do BEQ on a value you know to be zero. Like, I imagine you could do two instructions: LDA #%00, BEQ xx. Or given the original code has a branch anyway, just change whatever is there.

Obviously an actual BRA command would obviate all of this.

[Cyneprepou4uk]

The flags are generally set by the instructions immediately before, so it's not as if an ADC or SBC somewhere else in the code is going to be affected by this BVC.

I meant that BVC will be affected by ADC/SBC, not the other way around.
May 26, 2019, 07:11:27 pm - (Auto Merged - Double Posts are not allowed before 7 days.)

Can you guarantee that all existing ADC/SBC/BIT game's instructions will never get V = 1?

By "get" I meant "result in" or something like that

[Psyklax]

I meant that BVC will be affected by ADC/SBC, not the other way around.

Sorry, I didn't phrase myself correctly. I meant that the flags are affected by the last operation, so in a situation where I know V = 0, I'll use it, because if there are any ADCs in the code, they'll be in a different place where they won't encounter my new BVC. Basically I check the routine in question and do whatever I know for sure will be true in that situation. Hopefully that makes sense. I certainly wouldn't use an operation like that if I hadn't checked that it would be fine.

[Cyneprepou4uk]

Fine, I'll take your word for it that you know what you are doing, however I still have some doubts 

[Disch]

For what it's worth, I share your doubts, Cyneprepou4uk

Unless you know for a fact which instruction touched that flag and what state it put it in, you absolutely should not rely on it being in any given state.

in a situation where I know V = 0, I'll use it,

If you know for a fact V=0, then yeah that's fine.  The question is HOW do you know V will always be zero?

Short of explicitly setting it yourself with CLV/PLP (which, you might as well just JMP if you're doing that), the only way to know for sure is to look back at previously executing code to find the most recent ADC/SBC/BIT instruction... and know the relative outcome that instruction will have in any case... which can certainly work, but is HIGHLY situational.

[FAST6191]

I am not sure where I sit with this one.

On the one hand games are some of the most unpredictable code out there -- it is not like you are changing one line in a database, doing the next, doing the next... until you are done, or further in the future why games almost require object oriented code and/or similar approaches rather than a straight shot procedural.
The part of me that enjoys clean code and bounds checking also shrinks at this notion.

On the other then for the NES I would make a decent wager on the vast majority of all games not carrying a CPU level state/flag, much less a rarely used one, for more than a few instructions anywhere in their code or keeping them over a "random" branch. General observations of code (my experience is far from extensive but it is not absent), general observations of coding tutorials at the time, general understandings of code flow within games of the time (it was not just game devs having to create how UIs would work in games that sees a lack of minigames and menus that go back to the title screen), and general understandings of the instruction set (it is not like the GBA where ARM and THUMB could crop up randomly within the code and thus blindly inserting code without confirming a switch is silly) all informing this one.
As such it would probably be included in the list of techniques that are not absolutely certain to be successful, or certain within a sane amount of time, but still worth knowing about and worth giving a try, even more so if you truly understand the limitations.

[Vanya]

I am just "this" close to finally disable the subweapons drops from regular enemies. The thing is that I found the routine on the original Castlevania rev A, but with some luck I hope it will be mostly the same on Castlevania III.

I'm interested in this.
That would be a big help to one of my old projects that I have been thinking of resurrecting in the next year or so.
It relies on specific weapons being placed in specific locations, so disabling enemies from dropping them would be great.

[bogaabogaa]

Here for all the people following to get a patch. (It is for the US headered ROM)


Download link: https://drive.google.com/file/d/1MyoAqgVTGNDxi8P6bBbBFqEqLBJuj5q6/view?usp=sharing

Disables Sub-weapon with modding CPU-RAM $CE counter routine at (unheadered ROM) 2f59c E6 CE> EAEA (INC LDA > NOP NOP)
The counter seems not used for anything else and could be used for something else if you need the space.

Thank you Cyneprepou4uk for helping me to find this. It means so much to me 

This was quiet a ride for me to get that far. I am glad when people share there knowledge about coding and debugging. I would had tonnes of questions just simple things how to read debugger lines. For example in this line LDA ($08), y @7334 = FF. Like what does this @ mean? was it picked up by the Y index register earlier? The debugger is confusing the hell  out of me and I would not know anyone I feel constable to bother with this questions I have.

I will share some bad examples how not to go after this problem. It might be helpful for other things:
I was looking for this fix over a year now and invested ..I guess days of try and error. I could  also finally find the level transition tables.

Here my Notes I used for it:

Spoiler:

Level pointer:

0
1 Crossway Tower/woods:
   1 $29ab 01 00 00 ($29ae 000000)??
   2 $29b1 02 00 00
   
2 Crossway Zyklops/swamp
   1 $29b4 02 03 02
   2 $29b7 06 00 01
   
$29bb 07 00 08
$29bd 08 00 00

$2129

Finnal Alucart route:
$2141 0c 00 00


00
01
02
03
04
05
06
-------------------------
Table for subweapon drops
-------------------------
135cc - 1360b ??

Trevor 135cc-135cf
Grant
Symph 135cc-135cf
Alucard
 

2f59c E6 > ae Disable counter increas

Trevor Drops
92 Crash
93 Axe
94 Cross
95 dagger
96 HolyWater
97 StopWatch
98 Crash
A4 Emty
A5 Dagger??
A6 !Crash
A7 !Crash
A8 !Crash
A9 Dagger
B0 Small heart
B1 IceSpell
B2 Dagger
---------------------------
Candle Drop
---------------------------

92 Crash
93 Axe
94 Cross
95 dagger
96 Holy Water
97 Stop Watch
98 Fire Symp
99 Ice Symp
9A Ball Symp
9B Dagger Grant
9A Axe Grant
9C Axe
9D Whip upgrade 1
9E Whip upgrade 2
9F Whip upgrade emty
A0 Meat emty
A1 Potion
A2 Rosary
A3 Money 100
A4 Money 200
A5 Money 400
A6 Money 700
A7 Money 1000
A8 Money 2000
A9 Money 4000
AA Money 7000
AB Money 10 000
AC 1up
AD Big heart
AE Small heart
AF Double
B0 Tipple
B1 Glitched candle
B2

I did find the enemy item drop table too but this in is quiet special. It is the same one for Trevor and every partner. (135cc-135cf) This table is not able to drop anything beside sub-weapons or the game will crash. I also have the candle drop values in my notes.

I started to list the level pointer but it is not finished and all tested. A other Question that did come up was why the health refill of a meat (pork-chop) only works when it drops of a wall. (not candle or enemy)

For my hack I need to disable the partners beeing free of choice since I like to do levels around there ability. If possible hack a faster partner swap too. (also make a standalone patch)


I don't feel constable to add information to the data crystal since I am such a chaotic person and do tons of mistakes all the time. I will add a link to the Speedrun wiki where I will share my Mesen lables for the debugger and tons of extra notes and tutorials. But I need to get to it first.
There will be more SC4 things anyway..

Here some pictures of my hack that I did leave  over a year ago for the view values I had to find to go on..
Link for album: https://imgur.com/a/0Odhk0m