BigEd wrote:
Welcome! I'm having trouble accessing visual6502 but I have a local copy (you could download one from the Wayback Machine.) I'm not so familiar with perfect6502 - the model is fine, I'm sure, but I don't know about the inputs or the interpreting of the logs
I've compared visual6502 and perfect6502, and they produce identical result. Pro with perfect6502 is that I could easily modify it to run from the command line and output whatever log I needed. With visual6502 I had to run a few cycles in the browser and copy the table for further adjustments. A con with perfect6502 is that it does not seem to easily allow logging of sync for example. Need to investigate a bit more. Anyway, either work!
One difference is that visual6502 happily starts at 0. I had to "trick" perfect6502 into doing that, using the reset vector. As far as I can see, half-cycles 0+0 in your visual6502 is equal to half-cycle 0+1 in my perfect6502 log (except the registers are not initialized with same values, for whatever reason...).
BigEd wrote:
Note that the updated value of X from the LDA is first seen in the next cycle after the value appears on the bus.
Yes. This is what I would expect:
- Cycle 0: read opcode
- Cycle 1: read value and set x
- Cycle 2: first state with the new x
This is what I would expect from an operation documented to take 2 cycles, and the cycles correspond to what
cpu_6502.txt says about immediate addressing.
BigEd wrote:
But also note that the update of X from DEX is seen in the second cycle of the NOP: the decrement is done during the first cycle of NOP, and the write to X happens at the end of that first cycle, so it is first seen in the second cycle. This is because the ALU is needed and that takes a cycle to operate.
Uhm, this is where it gets strange. Implied addressing mode operations should take 2 cycles to execute, the same as LDX. This is according to both cpu_6502.txt and the W65C02S data sheet (table 4-1). But according to the log, it actually takes three cycles:
- Cycle 0: read opcode
- Cycle 1: (nothing...)
- Cycle 2: decrement X + read next op into IR
- Cycle 3: the first state with a new, decremented X value
Now, I understand that this does not really affect anything, as by the time the next operation can do something with X, it will always be decremented and ready. And it only consumes 2 cycles, as when the third cycle is running, the first cycle of the next operation executes in parallel. Could this be the reason why it's not documented?
This does however make it more complicated to compare logs between my emulator and perfect6502/visual6502. I could of course investigate every type of operation with the great tools we now have, but that's a lot of work!
BigEd wrote:
If you feel you might get lost, add sync to your traced signals.
I think I'd also add the alu inputs and outputs:
logmore=sync,alua,alub,alu
That's great! Will do that for future logs!
Login
Register
FAQ
Search
