[zombero]

What makes you say armor doesn't do anything?  That's pretty contrary to what I've observed.

[Reiska]

Did a bit of testing today with armor - I can confirm it does *something*, although the effect isn't exactly profound (in chapter 3, naked Rooks was taking about 6-8 more damage from attacks with no armor as compared to Breast Plate + Iron Shield).

[TimeSpaceMage]

OK, so it's not quite nothing. A more accurate statement would be "stats are wack"... which is why down the line I'd like to work out the damage formula and see if it's just using too little of certain stats. I recently learned about the multiplication registers, so maybe now I can make more sense of it. When I'm not looking into the rest of this, lol.

Disassembling the full ROM isn't likely to get it right.
In addition to the 6502 problems in that it can mix code and data, and also indirect JMP (codes that read pointers from a table and then jump to the pointer. That's a problem since disassemblers won't be smart enough to know the table size and thus how many functions they should attempt to disassemble) , but also they may not be smart enough to account for the SEP/REP instructions.
(SEP and REP set certain processor flags. In particular to how they can mess up opcodes is that they can change A and X/Y to be 8-bit or 16-bit registers, which also affects the size of instructions that read them.)

That makes sense! I'm a little fuzzy on JMP addressing modes, but I've seen SEP and REP plenty of times. Also gotta say, really big fan. Your posts have helped me learn so much ASM already!

What I'd do is get a decent sized tracelog of all the important gameplay areas - dungeon, battle, menu, loading. Then parse it for any JSL / JML. Replace with HiRom banks.

We only get the slightly faster memory speed if we read/write/execute from $80-FF region. $00-7F will be default SlowRom.
..
You'll also want to edit the nmi, irq vectors from 00xxxx ==> 80xxxx. They should be somewhere around 7ff0 rom. Maybe some other snes hacker could comment more as I didn't experiment much with SlowRom --> FastRom yet.


edit: Someone could even write a "universal" automated tool that takes geiger / bsnes-plus logs and auto-patches loroms. Though I'm not so confident it'd fully fix up games like Gradius III slowdowns. Or Final Fight (Guy). But it's worth a thought?
(I'm not doing it)

Parsing tracelogs... yeah, I could write a program to look for certain opcodes in a tracelog. I think it'd be safer if it just wrote those lines to a file rather than edit the ROM directly, since I don't trust addressing modes further than I can throw them. If someone wants to add that capability, I could look into putting it on Github later.

Meanwhile, sounds like I need to go research SlowROM->FastROM some more.
EDIT: Okay, I changed the flag in the internal header to $30. So the next step is to write my first ASM jump (*squeeing internally*) to set $420d. Going out on a limb here and presuming the huge block of FF's at 6020h-7FB0h is free.

Code: [Select]

$00/8001 18          CLC                     A:0000 X:0000 Y:0000 D:0000 DB:00 S:01FF P:EnvMXdIZc HC:0190 VC:000 FC:00 I:00
$00/8002 FB          XCE                     A:0000 X:0000 Y:0000 D:0000 DB:00 S:01FF P:EnvMXdIZc HC:0220 VC:000 FC:00 I:00
$00/8003 C2 10       REP #$10                A:0000 X:0000 Y:0000 D:0000 DB:00 S:01FF P:envMXdIZC HC:0250 VC:000 FC:00 I:00
$00/8005 E2 20       SEP #$20                A:0000 X:0000 Y:0000 D:0000 DB:00 S:01FF P:envMxdIZC HC:0288 VC:000 FC:00 I:00
$00/8007 A2 00 01    LDX #$0100              A:0000 X:0000 Y:0000 D:0000 DB:00 S:01FF P:envMxdIZC HC:0326 VC:000 FC:00 I:00
$00/800A 9A          TXS                     A:0000 X:0100 Y:0000 D:0000 DB:00 S:01FF P:envMxdIzC HC:0366 VC:000 FC:00 I:00
$00/800B A9 00       LDA #$00                A:0000 X:0100 Y:0000 D:0000 DB:00 S:0100 P:envMxdIzC HC:0396 VC:000 FC:00 I:00
$00/800D 48          PHA                     A:0000 X:0100 Y:0000 D:0000 DB:00 S:0100 P:envMxdIZC HC:0428 VC:000 FC:00 I:00
$00/800E AB          PLB                     A:0000 X:0100 Y:0000 D:0000 DB:00 S:00FF P:envMxdIZC HC:0466 VC:000 FC:00 I:00
$00/800F A9 8F       LDA #$8F                A:0000 X:0100 Y:0000 D:0000 DB:00 S:0100 P:envMxdIZC HC:0510 VC:000 FC:00 I:00
$00/8011 8D 00 21    STA $2100  [$00:2100]   A:008F X:0100 Y:0000 D:0000 DB:00 S:0100 P:eNvMxdIzC HC:0542 VC:000 FC:00 I:00
$00/8014 A9 00       LDA #$00                A:008F X:0100 Y:0000 D:0000 DB:00 S:0100 P:eNvMxdIzC HC:0628 VC:000 FC:00 I:00
$00/8016 8D 00 42    STA $4200  [$00:4200]   A:0000 X:0100 Y:0000 D:0000 DB:00 S:0100 P:envMxdIZC HC:0660 VC:000 FC:00 I:00

Looks like as good a place as any. So the code I want is...

Code: [Select]

$00/8019 22 30 60 80 JSL $806030
...
$80/6030 A9 01       LDA #$01
$80/6032 8D 0D 42    STA $420D
$80/6035 C2 10       REP #$10 (The 2 lines I'm replacing with the JSL)
$80/6037 E2 20       SEP #$20
$80/6039 6B          RTL

Oh, can I set DB to 80 here? Is there an instruction for that?

[Reiska]

I don't have any real insight on the damage formula mathematically, but some empirical observations of mine:

• Intelligence does seem to have a minor effect on magic damage taken, especially if you pump it with honeys.
• Strength seems to do essentially nothing.
• There's definitely some sort of row system in battle - enemies closer to the top of the screen take less damage from physical attacks if there are enemies below them on the screen.
• I suspect that the defense stat shown on screen lies in some fashion and that the formulas probably only use the raw defense values of the equipment which you can't see in-game, like in Etrian Odyssey.  Which might account for some of the weirdness we're seeing.

[Time/SpaceMage]

Yeah, that matches what I've observed in battle. The thing about finding hidden equipment/monster stats is that the tables are all 1 stat at a time for all items rather than all stats for 1 item at a time. It's hard to tell what's a table and what's not. For instance, monsters have Int values as I've found them in RAM (and given 999 Int to a monster to watch them wipe everyone with spells lol).

Attack power and battle damage are loaded into $16DB, and defense power into $16DD. But, they're shared by other stuff in battle too.

Oh, Alertness comes up a bunch in battle. According to my notes:
-Is read 3x per fighter at the end of the round (probably to determine turn order)   
-Read when an enemy whiffs   
-Read, then Endurance read when an enemy hits   
-Read when attacking   
-When attacking: Alertness/8 + 1, JSR C88B (isn't that the damage formula?)   

[rainponcho]

db starts here.

Code: [Select]

$00/800B A9 00       LDA #$00                A:0000 X:0100 Y:0000 D:0000 DB:00 S:0100 P:envMxdIzC HC:0356 VC:000 FC:00 I:00
$00/800D 48          PHA                     A:0000 X:0100 Y:0000 D:0000 DB:00 S:0100 P:envMxdIZC HC:0380 VC:000 FC:00 I:00
$00/800E AB          PLB                     A:0000 X:0100 Y:0000 D:0000 DB:00 S:00FF P:envMxdIZC HC:0410 VC:000 FC:00 I:00



I think you're choice of free area is probably safe.

Code: [Select]

$00/8019 22 30 E0 80 JSL $80E030
==> JML $80E030


$80/E030 A9 01       LDA #$01
$80/E032 8D 0D 42    STA $420D

$80/E035 C2 10       REP #$10 (The 2 lines I'm replacing with the JSL)
$80/E037 E2 20       SEP #$20
$80/E039 6B          RTL
==> JMP $801D

Your detour works but it'll RTL back to SlowRom area (00). We want to stay in FastRom. So JMP over ($80 -> $80). Then rest of init will go faster.


You might want to hijink the other vectors listed here:
http://www.smwiki.net/wiki/Vector_Info


I might give writing a small fastrom tool a try also, just to see how much it works.

(edit: I'm helping out on some snes projects that run into lorom slowdowns. So I guess I need it too. )


edit2:
Another db here

Code: [Select]

$00/811A F4 00 00    PEA $0000               A:1E00 X:1FFF Y:0000 D:1E00 DB:00 S:1FFF P:envmxdIzC HC:1290 VC:002 FC:01 I:00
$00/811D AB          PLB                     A:1E00 X:1FFF Y:0000 D:1E00 DB:00 S:1FFD P:envmxdIzC HC:1338 VC:002 FC:01 I:00
$00/811E AB          PLB                     A:1E00 X:1FFF Y:0000 D:1E00 DB:00 S:1FFE P:envmxdIZC HC:0010 VC:003 FC:01 I:00


edit3:
Easier detour idea.

Reset vector is @ rom 7ffc. Change that to E030. Write 420d there. Then JML $808001 to finish it off.

Same for NMI, IRQ vectors. Except you just JML to $80xxxx. No hassle.

Use Lunar Address to convert rom  snes address.


edit4:
Tested fastrom. Same 20 frames to walk forward. No difference. Hmm. Stupid me.

Something else.


edit5:
Forgot to turn on Fastrom header. 23 clean -> 20 fastrom to take a step forward. Still slow. :|

[zombero]

Here are some things I remember from my brief time hacking this game:
-The difference between 1 Strength and 255 Strength is something to the tune of 1.5x to 2x damage.  So yeah, VERY minor.  It was definitely multiplicative, though.
-Endurance was in a similar boat, but I think it was even worse.  Compared to Endurance, Defense is actually pretty effective.  When I removed all my equipment in Stavery I started taking ~double damage from enemies.  The difference in Defense stat is the primary reason why humans take less damage than elementals.
-Intelligence reducing magic damage, as Reiska said, sounds right, though I don't really remember for certain.
-Buffs/Debuffs seem to have a rather meager impact, to the tune of maybe ~1/8 increase/decrease for the more observable stats.  The main exception to this is Dodge All which has a much more noticeable result.

[KingMike]

EDIT: Okay, I changed the flag in the internal header to $30. So the next step is to write my first ASM jump (*squeeing internally*) to set $420d. Going out on a limb here and presuming the huge block of FF's at 6020h-7FB0h is free.

Code: [Select]

$00/8001 18          CLC                     A:0000 X:0000 Y:0000 D:0000 DB:00 S:01FF P:EnvMXdIZc HC:0190 VC:000 FC:00 I:00
$00/8002 FB          XCE                     A:0000 X:0000 Y:0000 D:0000 DB:00 S:01FF P:EnvMXdIZc HC:0220 VC:000 FC:00 I:00
$00/8003 C2 10       REP #$10                A:0000 X:0000 Y:0000 D:0000 DB:00 S:01FF P:envMXdIZC HC:0250 VC:000 FC:00 I:00
$00/8005 E2 20       SEP #$20                A:0000 X:0000 Y:0000 D:0000 DB:00 S:01FF P:envMxdIZC HC:0288 VC:000 FC:00 I:00
$00/8007 A2 00 01    LDX #$0100              A:0000 X:0000 Y:0000 D:0000 DB:00 S:01FF P:envMxdIZC HC:0326 VC:000 FC:00 I:00
$00/800A 9A          TXS                     A:0000 X:0100 Y:0000 D:0000 DB:00 S:01FF P:envMxdIzC HC:0366 VC:000 FC:00 I:00
$00/800B A9 00       LDA #$00                A:0000 X:0100 Y:0000 D:0000 DB:00 S:0100 P:envMxdIzC HC:0396 VC:000 FC:00 I:00
$00/800D 48          PHA                     A:0000 X:0100 Y:0000 D:0000 DB:00 S:0100 P:envMxdIZC HC:0428 VC:000 FC:00 I:00
$00/800E AB          PLB                     A:0000 X:0100 Y:0000 D:0000 DB:00 S:00FF P:envMxdIZC HC:0466 VC:000 FC:00 I:00
$00/800F A9 8F       LDA #$8F                A:0000 X:0100 Y:0000 D:0000 DB:00 S:0100 P:envMxdIZC HC:0510 VC:000 FC:00 I:00
$00/8011 8D 00 21    STA $2100  [$00:2100]   A:008F X:0100 Y:0000 D:0000 DB:00 S:0100 P:eNvMxdIzC HC:0542 VC:000 FC:00 I:00
$00/8014 A9 00       LDA #$00                A:008F X:0100 Y:0000 D:0000 DB:00 S:0100 P:eNvMxdIzC HC:0628 VC:000 FC:00 I:00
$00/8016 8D 00 42    STA $4200  [$00:4200]   A:0000 X:0100 Y:0000 D:0000 DB:00 S:0100 P:envMxdIZC HC:0660 VC:000 FC:00 I:00

Looks like as good a place as any. So the code I want is...

Code: [Select]

$00/8019 22 30 60 80 JSL $806030
...
$80/6030 A9 01       LDA #$01
$80/6032 8D 0D 42    STA $420D
$80/6035 C2 10       REP #$10 (The 2 lines I'm replacing with the JSL)
$80/6037 E2 20       SEP #$20
$80/6039 6B          RTL

Oh, can I set DB to 80 here? Is there an instruction for that?

Is this HiROM or LoROM? (Although it can still technically vary between PCBs, it is usually enough to distinguish Hi or Lo ROM?)
Generally in "LoROM" games (SNES9x or ZSNES will tell you when the game loads), ROM is only mapped to address $8000-FFFF (the second part of the address). $6000-7FFF can vary between PCBs but is possibly SRAM.
(bank 00/80:8000 would map to the first 32KB of ROM, bank 01/81:8000 map to the second 32KB, etc.)

[TimeSpaceMage]

Not sure why my posts only have to wait on mod approval when I post on mobile, but I'll just repost this on PC now that I'm home.

Yes, it's LoROM. Oh I see, so those addresses are out of range. Phooey... that's a good lesson though. So I would need free space in one of the banks in the 8000+ range. There's another section of FFs from F990-FFFF.

[rainponcho]

LoROM can be a little funny to understand at first. FuSoYa's tool Lunar Address makes it easier to convert between raw file and snes addresses.

tool
http://fusoya.eludevisibility.org/la/index.html


ex.
Free space located at $6020 rom (file). Lunar Address shows us it's SNES LoROM address 00:E020. Or 80:E020 for FastROM.

Free space F990 (file) = 01:F990 (SNES, SlowRom, LoRom)  81:F990 (SNES, FastRom, LoRom)


Or here's a snippet from FastRom tester

Code: [Select]

arch snes.cpu; lorom


// lorom, fastrom
org $ffd5
db $30


// snes bootup
org $fffc
dw fastrom_start


// todo: snes irq, nmi remap



//$00/9532 A7 10       LDA [$10]  [$01:8CDE]   A:8761 X:000E Y:0001 D:1E00 DB:00 S:1FF6 P:eNvmxdIzc HC:0264 VC:259 FC:59 I:00
//
//$00/9534 29 FF 00    AND #$00FF              A:1103 X:000E Y:0001 D:1E00 DB:00 S:1FF6 P:envmxdIzc HC:0352 VC:259 FC:59 I:00

// snes $9534 = file $1532
org $9534
jsr fastrom_code1



// snes 80e020 = snes 00e020 = file 6020
org $80e020

fastrom_start:
// snes native mode
clc
xce

sep #$20
lda.b #$01
sta $420d

// 00xxxx ==> 808001
jml $808001



fastrom_code1:
and.w #$00ff

cmp.w #$0040
bcs fastrom_code1_done

// 24-bit ptr table code jumps  (00-3F ==> 80-BF)
ora.w #$0080

fastrom_code1_done:
rts


And patch to convert FastRom banks (code analysis).
https://www.sendspace.com/file/60krtf

Although I found a bug with how toll handles plb codes but there weren't many in this game. So I think it was okay - have to recheck.

[TimeSpaceMage]

LoROM can be a little funny to understand at first. FuSoYa's tool Lunar Address makes it easier to convert between raw file and snes addresses.

tool
http://fusoya.eludevisibility.org/la/index.html


ex.
Free space located at $6020 rom (file). Lunar Address shows us it's SNES LoROM address 00:E020. Or 80:E020 for FastROM.

Free space F990 (file) = 01:F990 (SNES, SlowRom, LoRom)  81:F990 (SNES, FastRom, LoRom)


Or here's a snippet from FastRom tester

Code: [Select]

arch snes.cpu; lorom


// lorom, fastrom
org $ffd5
db $30


// snes bootup
org $fffc
dw fastrom_start


// todo: snes irq, nmi remap



//$00/9532 A7 10       LDA [$10]  [$01:8CDE]   A:8761 X:000E Y:0001 D:1E00 DB:00 S:1FF6 P:eNvmxdIzc HC:0264 VC:259 FC:59 I:00
//
//$00/9534 29 FF 00    AND #$00FF              A:1103 X:000E Y:0001 D:1E00 DB:00 S:1FF6 P:envmxdIzc HC:0352 VC:259 FC:59 I:00

// snes $9534 = file $1532
org $9534
jsr fastrom_code1



// snes 80e020 = snes 00e020 = file 6020
org $80e020

fastrom_start:
// snes native mode
clc
xce

sep #$20
lda.b #$01
sta $420d

// 00xxxx ==> 808001
jml $808001



fastrom_code1:
and.w #$00ff

cmp.w #$0040
bcs fastrom_code1_done

// 24-bit ptr table code jumps  (00-3F ==> 80-BF)
ora.w #$0080

fastrom_code1_done:
rts


And patch to convert FastRom banks (code analysis).
https://www.sendspace.com/file/60krtf

Although I found a bug with how toll handles plb codes but there weren't many in this game. So I think it was okay - have to recheck.

Turns out I had Lunar Address; I just forgot about it 
So I've got a few questions. First, which program are you editing that in? (Admittedly I've been going by hand, but most of my changes up til now have just been data tweaks.) Second, what does that patch do? I'm a little confused as to if I still need to write those redirects. IPS files don't really explain what they're changing.

Third, let me see if I got this right.

Code: [Select]

Initial detour for FastROM:
7ffc (Reset vector): 01 80 -> 90 F9

At F990:
A9 01
8D 0D 42
5C 01 80 80

And then I have to redirect these 4 too?
7fea (Native mode NMI): 35 83
7fee (Native mode IRQ): 4E 81
7ffa (Emulation mode NMI): FF FF
7ffe (Emulation mode IRQ): 00 00


[rainponcho]

xkas-plus
https://github.com/devinacker/xkas-plus/releases


Ips patch changes game's 24-bit JSL, JML, LDA, ORA, STA, (lala) opcodes to fastrom banks. And some PEA / PLB ones. You still need redirects, fastrom 420d, etc.

bonus asm code: game hides some 24-bit ptrs as data. So I found the routine and fastrom edit on-the-fly.


These 2 need remapping to $80 fastrom.
7fea (Native mode NMI): 35 83
7fee (Native mode IRQ): 4E 81

A simple JML $808335, JML $80814E redirect will work.


At F990... I guess technically we have no idea (?) what startup snes settings are. So we need to
1. enter native snes mode: clc - xce
(we could be in native or emulation mode??)

2. set 8-bit accumulator mode: sep #$20
(could be 16-bit A register)

3. write $01 to $420d
(slowrom -> fastrom)

4. jml to normal start code but in $80 bank
(slow bank -> fast bank)


I only got ~3 frames faster per walking step. But it's "free" and easy.

You'd have to optimize down the slow loops to get more frames.

[TimeSpaceMage]

Okay, so that's:

Code: [Select]

F990:
18 (clc)
FB (xce)
E2 20 (sep #$20)
A9 01
8D 0D 42
5C 01 80 80

7fea: A0 F9
f9a0: 5C 35 83 80

7FEE: A4 F9
f9a4: 5C 4E 81 80

Wait, am I missing something with xkas? I see where I can use it on the command line to convert .asm to .ips, but I was expecting some sort of editor. Do I just write the .asm file in a text editor?

EDIT: Okay I put the code in, and the reset vector took it to 00/F990... which is still FF's, so it was actually sent to file position $7990. I thought that was part of SRAM? No, I think I get it; the snes address $7990 would be SRAM or w/e, but the file positions $0000-$7FFF are bank $00 and snes addresses $8001-$FFFF.

EDIT2: Okay it doesn't crash Snes9x any more  The startup stats say Mode: 20 though. Hang on...

[KingMike]

You write the code as a text file but did you format it correctly?

First line you need lorom/hirom to tell it the format.

Then you would format the address as something like

Code: [Select]

org $80F990
NewBootCode:
and then your code. To fix the reset vector.

Code: [Select]

org $80FFEC
 .dw NewBootCode
At least, I think $FFEC is the Native Mode Reset vector (the start point of the code) and this should write the address of your new start code.
(.dw is the started instruction to insert a "word", a 2-byte value. I can't recall if xkas support that but it should. Maybe it was "dw")

If you didn't correctly define the address to insert your code in your ASM file, it might have defaulted to address 0 in the ROM, possibly corrupting it. You should probably double-check that.

[TimeSpaceMage]

Code: [Select]

This one's a pretty big offender.
$80/9B0E DC 49 10    JML [$1049][$00:A105]

And this is where the bank for $1049 is stored, so I guess the trick is getting it to store 80's instead?  o.0
$80/9537 8D 4B 10    STA $104B  [$00:104B]   A:0007
$80/9000 8D 4B 10    STA $104B  [$00:104B]   A:0405

Also found this one.
$03/A363 22 47 9C 00 JSL $009C47[$00:9C47]


[rainponcho]

I'd say it depends how much time game spends running those routines. If it hits it a lot, then yeah.. you'll want to manually "run-time" optimize them (00:9532) -- it'd take a long time to dissect each bank ptr correctly through disassembly (data storage).

You'll probably find lots of 24-bit ptrs that I missed, because I never came close to triggering them.
[Bwa ha ha!]



If you keep trace logging, you can run it in this tool:
https://www.sendspace.com/file/9z7g4g

Make sure to backup your rom first. Rename it to 'rom'. Rename your geiger tracelog to 'log'. Run exe. It'll parse it and turn things into fastrom banks.

Be careful about it corrupting your own asm hacks if you keep making (changing) them lots of times. Have to be organized. So I'm not officially releasing it or anything. And turned off PEA - PLB detection since there's situations that mess up.



I'll locate some loop offenders and optimize them first. See what I can get before mentioning them here -- have some ideas to test on them.

But I'm going to back off with explanations (since clearly I did a lousy job at it) and let KingMike help you understanding technical problems.


edit: Doesn't look like FastRom will help much. So maybe no point in continuing further this way. I guess there's just too much raster math which is taking the brunt of the slowdown.

Which maybe is why FastRom conversions aren't that popular to fix slow games.

You could always work on your other todo items. Sorry, guess another game that's defeated me again.


edit2:
Out of curiosity, tried some more. There's a routine that inits the drawing data. Although it uses mvn, dma speeds it up another 2 frames. So 23 -> 20 (fastrom) -> 18 (dma init).

I'll keep poking at it then and upload optimized asm file w/ full ips patch if I can get some more time cut.

[Time/SpaceMage]

(Yeah I'm just not gonna post on mobile any more)
Phantom edit to see if it's still doing that.

[TimeSpaceMage]

I'd say it depends how much time game spends running those routines. If it hits it a lot, then yeah.. you'll want to manually "run-time" optimize them (00:9532) -- it'd take a long time to dissect each bank ptr correctly through disassembly (data storage).

What do you mean by 00:9532 and data storage?

You'll probably find lots of 24-bit ptrs that I missed, because I never came close to triggering them.
[Bwa ha ha!]

I just walked around hitting Step Into to see if the current instruction was in a SlowROM bank :3 Those instructions were from leaving town/Balnea Temple.

If you keep trace logging, you can run it in this tool:
https://www.sendspace.com/file/9z7g4g

Make sure to backup your rom first. Rename it to 'rom'. Rename your geiger tracelog to 'log'. Run exe. It'll parse it and turn things into fastrom banks.

Be careful about it corrupting your own asm hacks if you keep making (changing) them lots of times. Have to be organized. So I'm not officially releasing it or anything. And turned off PEA - PLB detection since there's situations that mess up.

I'm pretty good at keeping track of them. Every version gets backed up in my Backup folder, and my data edits have the byte changes written to a change log for reference. My work, references and tools are all on my Google Drive too in case of hard drive failure. I've been around long enough to know better than to take chances with my projects!

[rainponcho]

This is nearly most I could torture engine. If you generic optimized every single possible thing, maybe you could squeeze another frame.
https://www.sendspace.com/file/kstnbk


Full fastrom ips tester can be applied to vanilla rom. It should give some walking boost (~7-8 frames or ~33%).



The rest of the slowdown comes from running this all the time:
JSR $99FE  [$83:99FE]

That's hard to figure out how to get it better. But that spot would kick it down another 2-3 frames possibly.

[TimeSpaceMage]

Oh wow, that looks like it was a lot of work!
...

// average walking stats
//
// balnia   23 ==> 15
// stavery  23 ==> 15
// bintel   19 ==> 12

Holy f- that's plenty fast! Good job 

Code: [Select]

org $188044

// random encounter cheat
ldx.w #$00ff
I see that!  I'm using $18 for now, unless the faster speed needs something lower.


Oh, I revisited my old mod discussion on GameFAQs and zombero had this to say:

zombero    2 years ago   #31
Yeah, I did my own tests back in the day.

From my memory, Str's effect on your damage is basically (1 + (strength/400))*weapon_based_damage. Though it also seems to have some sort of minimum damage that it must add, apparently something like strength/40. Not sure exactly how the implementation works.

I think the weapon-based portion was a subtractive formula with enemy defense, but I don't recall for certain. But weapon is the main driving force in your damage in general.

...I'm starting to wonder if the Defend command does anything at all, though. Maybe I should rename it to "Wait"