VOGONS


UniPCemu 8088 cycle accuracy

Topic actions

Reply 120 of 122, by GloriousCow

User metadata
Rank Member
Rank
Member
superfury wrote on 2023-10-06, 18:11:

So basically, I need to do the inverse in my case: tick an extra cycle (NOP cycle on the EU) if an instruction ends without said flag set?

When is an instruction going to end without fetching the next instruction?

MartyPC: A cycle-accurate IBM PC/XT emulator | https://github.com/dbalsom/martypc

Reply 121 of 122, by superfury

User metadata
Rank l33t++
Rank
l33t++
GloriousCow wrote on 2023-10-06, 19:46:
superfury wrote on 2023-10-06, 18:11:

So basically, I need to do the inverse in my case: tick an extra cycle (NOP cycle on the EU) if an instruction ends without said flag set?

When is an instruction going to end without fetching the next instruction?

So, basically, all instructions end with that RNI instruction?

So that means that since that 'extra cycle' on the next instruction is the fetch for the next instruction itself, but it's counted as one extra cycle (or is it?), thus the deal with your cycle_nx function essentially is that nothing changes?

So basically, I should either add 1 cycle to the cycles_nx* count or leave it alone? And take all other instruction cycles literally? And no new logic on the fetching of the first byte of the next instruction (as that's done immediately after the EU finishes anyway in UniPCemu, directly after initializing the instruction states for the new instruction)?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 122 of 122, by GloriousCow

User metadata
Rank Member
Rank
Member
superfury wrote on 2023-10-06, 20:07:

So, basically, all instructions end with that RNI instruction?

Yes.

superfury wrote on 2023-10-06, 20:07:

So that means that since that 'extra cycle' on the next instruction is the fetch for the next instruction itself, but it's counted as one extra cycle (or is it?), thus the deal with your cycle_nx function essentially is that nothing changes?

So basically, I should either add 1 cycle to the cycles_nx* count or leave it alone? And take all other instruction cycles literally? And no new logic on the fetching of the first byte of the next instruction (as that's done immediately after the EU finishes anyway in UniPCemu, directly after initializing the instruction states for the new instruction)?

I'm sorry, I'm not following.

You have a several ways to get cycle traces of arbitrary code execution on an 8088 - you have reenigne's xtserver or xtce emulator, and you have MartyPC's cycle log facilities. If you are willing to do some tests with them, the timings should become clear to you.

EDIT: If I think I understand what you are asking, you would subtract 1 cycle from any calls to cycle_nx - they allow for the terminating microcode instruction line # to be passed through but not executed. A lot of what MartyPC does is complicated by my desire to produce microcode listings in cycle traces (a feature that still isn't quite working right). To that aim, i wanted a facility to indicate the microcode line # to be executed in the future. Unfortunately this does make following my source code more confusing, maybe I should revisit my approach.

MartyPC: A cycle-accurate IBM PC/XT emulator | https://github.com/dbalsom/martypc