More curious 6502 behaviour

[Rich Talbot-Watkins]

Hey Tom, this one's for you Perhaps this is the last piece of the puzzle in getting Lunar Jetman to run OK on B-Em?

http://forum.6502.org/viewtopic.php?t=1634

[MartinB]

This prompted me to make sure that all the 6502 addicts on here are aware of and have access to, the original MOS 650x hardware and programming manuals. They really are the best reference works available and are an interesting read for anyone regardless of your particular area of interest. Indeed, if you are trying to teach yourself 6502 assembly language, the programming manual is, in my opinion, a much better source of learning than even the best tutorial books I've seen. Everything is explained clearly and in minute detail and there are plenty of graphically illustrated examples.

I have original copies of these and could never envisage scanning them as they are somewhat on the large side but I recently came accross pdf versions of both manuals on the textfiles site I mentioned elsewhere. You (Rich and Tom) probably already know where to find them but to make sure that everyone on here is aware of these 650x bibles I thought I'd highlight the pdf versions.

The hardware manual is here and the programming manual is here.

Enjoy

(Thanks to Lion for pointing me to the Dropbox host and if it therefore doesn't work you can of course direct all your anger and frustration at him )

[regregex]

Thanks Rich and Martin for the links, that's superb stuff.

Greg

[BeebInC]

I believe I noticed it a while back, and did post about it


BeebInC
Post subject:
PostPosted: Sat Jul 22, 2006 4:35 pm

Joined: Sun Mar 19, 2006 12:58 pm
Posts: 97
After further dabbling I noticed that the documented "interrupt must be enabled at least 2 cycles before the end of the current instruction" for an interrupt to be generated is only a half truth.....

It is correct to a point, I have found out that if the last instruction happened to be a branch instruction, where the branch instruction is performed (ie the test condition is fulfilled), then the "interrupt must be enabled at least 3 cycles before the end of the current instruction". If the branch is not performed then it's 2 cycles as usual.

^^ The above is not documented anywhere (at least not where I can find it)

This is entirely correct and I have the code and results to prove it. This also leads me to suspect that some other instructions may have a similar side effect. I need more experimentation to find out - after these have been isolated my emulator _will_ decode Nightshade

I know I can cheat and only test the instructions that appear in the nightshade decoder but for completeness I need to check every instruction

[Rich Talbot-Watkins]

Oh yeah, I remember you posting this now (it was in the big Nightshade protection thread wasn't it?) but it hadn't made much impact on me until now.

Just to clarify, what is the behaviour? Taking ADC abs as the first example, treating the first cycle as the one with the opcode fetch:

T0: fetch ADC abs opcode
T1: fetch addr lsb, decode ADC abs
T2: fetch addr msb
T3: fetch (addr)
---
T0: fetch next opcode, add (addr) to A
T1: decode next opcode, store result in A

For an IRQ service to commence instead of the next opcode, the IRQ has to be generated at least 2 cycles before the instruction ends, i.e. in T0 or T1 above? If generated at T2 or T3, the next instruction will execute before the IRQ is serviced. Is this right? The pipelining rather fuzzies the behaviour, because in reality the ADC hasn't yet finished (it has two more cycles to go, which are executed at the same time as the opcode fetch and decode for the next instruction).

In the case of a branch (taken, no page crossed), how does this look?