job que vdc copy

Pretty sophisticated... do you have use for it?

That should be tested on a real machine. I haven't tried it yet, but I know I had probelms on real VDC that never showed up in VICE that have to do with the order that register pairs are accessed. Like it seems you HAVE to read the high byte (lower reg#) first and then read the low byte (higher reg#) first. And same goes for writing. In particular, if you try to read and write the low byte without touching the high byte, the VDC forks stuff up.

I'm not sure what register pairs this applies too, or what the exact "rules" are (I have never seen it documented). Although the problem I personally experienced dealt with RAM access, so I think your code may suffer the same bug.

So it looks the middle of your code (where you write the data), and then end of the code (where restore registers) is okay because the registers are accessed in order, and only one operation (write) is performed on each. But the beginning, where it saves the old registers and sets new values seems to violate both rules: it does a read and write to the same register, and the registers are accessed out-of-order (low byte first).

That is what really annoys me; with 6502 and (other 8-bit processors) it is usually optimal to do the low byte(s) first and follow with the hiher byte(s)... but the VDC requires the opposite order.

I just want the register values, not reading from ram so, Let's see what a real vdc says

Cool. You were reading my mind... I was going to say that reading registers should(!) not matter about the order, but you just pointed that out. With the re-worked write order, it looks it should almost work.

One minor bug I spotted was...

ora $80 ;turn on copy
which should be
ora #$80 ;turn on copy
The # must be most common 6502 error.  Of course I never make that mistake.

Seriously, I don't see any other problem.  On the assumption that reading regs is not dependant on order, you could perform some trivial optimization (dump TAY and TYA) when saving the original value.  But that is small potatoes compared to the rest of the code so not worth the effort/risk.

Now if there was some use for it, it could be tested...