- This topic has 401 replies, 18 voices, and was last updated 3 years, 7 months ago by
.
-
Posts
-
After my vanilla play through I'll debate a RoI repeat. 3 DoaE play throughs back to back is kinda harsh :)
Hi guys do u think u can give me a 4 shared link to download rise of lu bu 2.0 mod the links here arent working on this one either in cursed i guess lol
Vanilla play through finished… wow. Kinda boring.
Lu Sun, Cao Zhang, Jiang Wei, Zhao Yun, Guan Xing, *Zhu Ge Liang, Zhou Yu. 154 MTP
Zhao Yun was only up to 22k soldiers.
Wu party was … mostly under powered Shu guys for the area but it did fine…
Pang Tong, Gan Ning (got him immediately by luck), Zhang Ren, Yan Yan, Ma Dai, * Zhu Ge Liang, Ma Liang
Annnndddd… as is typical of EVERY FUCKING PLAYTHROUGH, i ran into Taishi Ci before making it to the first castle (of course).
At Sun Quan it was:
Zhang Zhao, Gan Ning, Guan Xing, Zhao Yun, Zhou Yu, * Zhu Ge Liang, (some an-sha capable guy)
The use of non tiger generals was generally very awesome. By Sun Quan, their soldier counts became more useful. Pang Tong / Zhang Zhao / Lu Sun in the lead with chituma made the game quite a bit easier than what I remember as well. Zhou Yu fight was the hardest, as usual.
I am utterly amazed at how critical and game changing Focus TP regen is. In the vanilla play through with near maximizing MTP, it wasn't critical, but did cause a lot of running on the way to next spiked tile. Did an-sha my way through several of the weaker gates to save on TP.
Anyway… I'll give a revamped RoI a try starting later in the week prolly. If War Edge has been nerfed a bit or fewer ppl get it or something… it'll make Jing Zhou entirely different. I'll be attempting a no-run-ever play through btw :).
I found a bug in the bonus section it seems like when u use evade and thwart in one round they wear off with it telling u that they wore off also the game sometimes freezes but very rarely i played it start to finish its great to play
Quote:I found a bug in the bonus section it seems like when u use evade and thwart in one round they wear off with it telling u that they wore offThat is intentional to prevent a MAJOR imbalance. You can only use Thwart OR Evade OR Guard OR Protect. The previous two trump Guard and Protect but they will both cancel each other out if used in the same turn, just whichever is used last.
Quote:also the game sometimes freezes but very rarely i played it start to finish its great to playThis is a pervasive bug and is pervasive in Rise of Ieyasu and I've found it in Flames of Wu. It was introduced via the IPS patch I think and MiDKnighT is working on a fix for it as we speak! (hopefully its out before a release of the FOW mod!)
Quote:More progress on the infamous bug today but it's still very baffling. The problem is it ends up on ROM page 1 when it shouldn't. The "01" is getting pulled from the stack. It ends up getting pushed onto the stack from the $ED variable which gets populated by the first section below. But…the ROM does this all the time with no problems so trying to figure out what's so different when it goes wrong…which has been very tough so far…Storing into $ED:
$A947:4C 00 80 JMP $8000 A:00 X:09 Y:5E S:1C P:nvUBdIZC
$8000:A9 01 LDA #$01 A:00 X:09 Y:5E S:1C P:nvUBdIZC
$8002:20 82 C4 JSR $C482 A:01 X:09 Y:5E S:1C P:nvUBdIzC
$C482:85 44 STA $0044 = #$1E A:01 X:09 Y:5E S:1A P:nvUBdIzC
$C484:85 ED STA $00ED = #$1E A:01 X:09 Y:5E S:1A P:nvUBdIzC
Pushing onto stack:
$EF08:A5 ED LDA $00ED = #$01 A:00 X:FC Y:00 S:09 P:nvUBdIZC
$EF0A:48 PHA A:01 X:FC Y:00 S:09 P:nvUBdIzC
Chased this further. Definitely a stack issue and I think I've narrowed it down to three places were the stack pops to $EE79 for unknown reasons. I actually see three places where this (occasionally) happens:
$84BE:A9 01 LDA #$01 A:00 X:D5 Y:00 S:12 P:nvUBdIZc
$84C0:C5 CE CMP $00CE = #$02 A:01 X:D5 Y:00 S:12 P:nvUBdIzc
$84C2:D0 19 BNE $84DD A:01 X:D5 Y:00 S:12 P:NvUBdIzc
$EE79:08 PHP A:01 X:D5 Y:00 S:0F P:NvUBdIzc
$EE7A:48 PHA A:01 X:D5 Y:00 S:0E P:NvUBdIzc
and
$86BB:A0 05 LDY #$05 A:00 X:0A Y:0E S:10 P:nvUBdIZc
$86BD:B1 CC LDA ($CC),Y @ $0762 = #$00 A:00 X:0A Y:05 S:10 P:nvUBdIzc
$EE79:08 PHP A:00 X:0A Y:05 S:0D P:nvUBdIZc
$EE7A:48 PHA A:00 X:0A Y:05 S:0C P:nvUBdIZc
and
$825E:A5 CF LDA $00CF = #$00 A:08 X:00 Y:1D S:1E P:nvUBdIzc
$8260:4A LSR A:00 X:00 Y:1D S:1E P:nvUBdIZc
$8261:90 03 BCC $8266 A:00 X:00 Y:1D S:1E P:nvUBdIZc
$EE79:08 PHP A:00 X:00 Y:1D S:1B P:nvUBdIZc
$EE7A:48 PHA A:00 X:00 Y:1D S:1A P:nvUBdIZc
There is no instruction telling it to go to $EE79 but it does anyway. Baffling. I'm wondering if it has to do with the Z and N flags. I have a breakpoint condition that seems to catch it before it dies:
EE79 execute:
(Z == #01&&X == #0A)||(N == #01&&X == #D5)
So far this is triggering the breakpoint before the freeze 100% of the time in my testing. Next step is to figure out how the heck it's popping to $EE79 for no apparent reason.
Good to hear! It probably doesn't help simply because it happens so rarely.
Not a 6502 programmer, but doing a quick bit of reading and look at what ya got…
Is the PC reg truly jumping to EE79 in the traces ?
Cause… the only way I can possibly see that ever happening is an interrupt or similar.
$84BE:A9 01 LDA #$01 A:00 X:D5 Y:00 S:12 P:nvUBdIZc
$84C0:C5 CE CMP $00CE = #$02 A:01 X:D5 Y:00 S:12 P:nvUBdIzc
$84C2:D0 19 BNE $84DD A:01 X:D5 Y:00 S:12 P:NvUBdIzc
LDA doesnt write to memory any and doesn't write to the PC
CMP is a read instruction changing SR but still readonly…
The addressing on BNE is relative, no ? So…. you can't go from 8xxx to Exxx from a single byte.
$86BD:B1 CC LDA ($CC),Y @ $0762 = #$00 A:00 X:0A Y:05 S:10 P:nvUBdIzc
There is zero way this could effect the PC out of normal ? Loading from mem to A shouldn't affect a damn thing.
$8260:4A LSR A:00 X:00 Y:1D S:1E P:nvUBdIZc
$8261:90 03 BCC $8266 A:00 X:00 Y:1D S:1E P:nvUBdIZc
LSR / 4A = just an A shift….
BCC is also relative and can't get to Exxx in a single byte (8xxx -> Exxx).
EE79 being PHP really seems to hint it's an IRQ or interrupt or something.
Quote:Is the PC reg truly jumping to EE79 in the traces ?Yes, and it makes no damn sense at all.
Quote:EE79 being PHP really seems to hint it's an IRQ or interrupt or something.I'll have to read up more on that.
Thanks unfy.
Dunno how 6502 code is typically written.. but 8051 and other stuff… there's a dedicated block of code near the front of the ROM that has the interrupt entry points. They typically only exist as a 'long jump interrupt_handler0/1/2/whatever' kind of instruction. And each of the front-of-rom entry points are typically only long enough to include this immediate jmp spring board.
Of course, why on god's green earth would an ISR push things and not restore them properly is a bit beyond me.
My only possible guess would be if somehow there was an instruction timing thing going on …. where…. designers knew that every X often, an interrupt triggers and does stuff. Thus they designed their code so that each block of shit they were doing would finish within X amount of time and be kinda idle waiting for it to occur. But that makes little sense really. I dunno if I've ever seen DoaE ever have lag problems, but it just aint sane.
If ya look further down from EE79… it looks like it does ISR style stuff… pushes registers … does a bunch of stuff… then:
0F:EF2D:68 PLA
0F:EF2E:20 AA C4 JSR $C4AA
0F:EF31:68 PLA
0F:EF32:A8 TAY
0F:EF33:68 PLA
0F:EF34:AA TAX
0F:EF35:68 PLA
0F:EF36:28 PLP
0F:EF37:40 RTI
pops all those registers and RTI (return from interrupt).
i've not looked at the register push and pop (pull? sorry, silly 6502 nomenclature) to make sure it's correct… but …. assuming the last PLA is correct…. A should have been reset to what whatever it was supposed to be.
I'm not entirely sure what this ISR does, it's got a few 'gosubs' within it… which would be more pushing/popping…
Given that it's an ISR, given that the ISR appears to push / pull a bit on the stack on it's own (and who knows how much the sub routines do) …
what happens in 6502 if you try to push too much on the stack ? what happens to the stack pointer / counter / whatever the fuck 6502 calls it ? heh.
with the new code that's been written, is it possible that in rare circumstances that a fair amount of stuff has been pushed on to the stack by new code…. then while the stack is kinda full an INT triggers… and the stack gets overflowed or something ?
in your traces, keep an eye on the stack pointer basically on a crash replay ?
I've had stack overflow issues before. This bug isn't overflowing the stack…but it gets fairly close. Ie…it gets within 10 bytes or so of overflowing the stack. Perhaps I should try limiting it further.
To understand the bug more let me show you what is happening. There are a handful of flavors of the bug but they basically end up doing the same kind of thing… Here's a different variation of the same problem:
It's enemy 09's turn:
Code:$A92C:A6 78 LDX $0078 = #$09 A:06 X:12 Y:5E S:1C P:nvUBdIZC
$A92E:B9 A0 65 LDA $65A0,Y @ $65FE = #$12 A:06 X:09 Y:5E S:1C P:nvUBdIzCSwitch to page 08:
Code:$C4B6:68 PLA A:00 X:FC Y:00 S:11 P:nvUBdIZC
$C4B7:8D F9 FF STA $FFF9 = #$AC A:08 X:FC Y:00 S:12 P:nvUBdIzCPC jumps to EE79:
Code:$86AE:F0 0B BEQ $86BB A:00 X:0A Y:0E S:10 P:nvUBdIZc
$86BB:A0 05 LDY #$05 A:00 X:0A Y:0E S:10 P:nvUBdIZc
$86BD:B1 CC LDA ($CC),Y @ $0762 = #$00 A:00 X:0A Y:05 S:10 P:nvUBdIzc
$EE79:08 PHP A:00 X:0A Y:05 S:0D P:nvUBdIZc
$EE7A:48 PHA A:00 X:0A Y:05 S:0C P:nvUBdIZcSwitch to page 08:
Code:$C4B6:68 PLA A:00 X:FC Y:00 S:05 P:nvUBdIZC
$C4B7:8D F9 FF STA $FFF9 = #$AC A:08 X:FC Y:00 S:06 P:nvUBdIzCGoing to switch pages to page 01:
Code:$8000:A9 01 LDA #$01 A:00 X:09 Y:5E S:1C P:nvUBdIZC
$8002:20 82 C4 JSR $C482 A:01 X:09 Y:5E S:1C P:nvUBdIzC
$C482:85 44 STA $0044 = #$1E A:01 X:09 Y:5E S:1A P:nvUBdIzC
$C484:85 ED STA $00ED = #$1E A:01 X:09 Y:5E S:1A P:nvUBdIzCPush "01" to the stack:
Code:$EF08:A5 ED LDA $00ED = #$01 A:00 X:FC Y:00 S:09 P:nvUBdIZC
$EF0A:48 PHA A:01 X:FC Y:00 S:09 P:nvUBdIzCPulling "01" from the stack and switching to that ROM page:
Code:$C4B6:68 PLA A:00 X:0E Y:1C S:06 P:nvUBdIZc
$C4B7:8D F9 FF STA $FFF9 = #$AC A:01 X:0E Y:1C S:07 P:nvUBdIzcThe RTI here dumps us back to $86BF on ROM page 1 which is invalid.
Code:$EF37:40 RTI A:00 X:0A Y:05 S:0D P:nvUBdIZc
$86BF:C4 AD CPY $00AD = #$85 A:00 X:0A Y:05 S:10 P:nvUbdIZc
$86C1:73 UNDEFINED A:00 X:0A Y:05 S:10 P:NvUbdIzcSo the whole bug is that it's executing code on the wrong page (01). I guess it expects to be on the original page which is page 08.
Regarding the IRQ stuff, the bottom of each ROM page references EE79 but not sure how that all works with IRQ just yet:
Code:000000004804000008AC79EED8FF79EEWriting this all out has helped me understand it a bit more but not sure how to fix just yet.
…. do you have a free byte somewhere?
do you have space to store which page you're on in it ?
can you set up the ISR to do this page switch before all of the pulls and iret ? (page, pull pull pull iret) ?
i'm… not entirely sure how nes memory mappers work, not entirely sure blah blah blah….
but… i imagine my suggestion aint easily feasible due to working with binaries rather than source .. thus no room to squeeze instructions into…
the ee79 is the interrupt address vector the processor will jump to handle NMI interrupts. if you replaced fffa/fffab with something other than ee79, it'd jump there instead.
looking at 6502 docs, the isr setup stuff internal to the processor does PHP already. dunno if nes 6502 is the same… but… this would make the php's at the start of each ISR pointless?
Quote:the ee79 is the interrupt address vector the processor will jump to handle NMI interrupts.The biggest mystery to me is what is triggering the NMI interrupt.
Quote:NMI (Non-Maskable Interrupt) is the type of interrupt generated by the PPU when V-Blank
occurs at the end of each frame. NMIs are not affected by the interrupt disable bit in the
status register, so execution is always interrupted when they occur [31]. However, triggering
of a NMI can be prevented if bit 7 of PPU Control Register 1 ($2000) is clear. When a NMI
occurs the system jumps to the address located at $FFFA and $FFFB. The handling of NMIs
is shown in figure 2-4.
And then looking at a schematic:
http://nesdev.com/Ntd_8bit.jpg
CPU NMI is a direct connect to the PPU.
Soooo the above quote is undoubtedly correct.
- You must be logged in to reply to this topic.