I think cycle-exact can only be important for games: either used for timing or used for copy-protection. (OK, or real-time software of other kinds[*])

Rob Finch posted that he took a year to make his 6502 and another year (elapsed) to make it cycle accurate. (That's a post worth reading)

[*] Edit: as pointed out below, may include device driving code too

If you're using this processor with the Apple series of hardware, you'll find that the disk subsystem won't work with altered timings.

For Commodore equipment, I'm thinking the only impact will be on the IEC-bus timing, but fundamentally, nothing else in the KERNAL seems dependent on CPU timing that I can see.

Never having used or coded for the Atari platform, I cannot say.

Which means there is still hope for me and my design :) So far the timing is either exact or faster. In most cases it is a matter of adding some empty cycles. In case a page boundary is crossed, I have a small problem. In the 6502 IMHO the ALU does all the adding. In case of a Carry (= page boundary crossed) the Instruction decoder can decide to add an extra cycle to increase the high-byte of the Program Counter. In my case the Address Adder I mentioned before does the trick in one go using four 74ls83 4-bit adders. Letting the ALU do all the work involves a lot of extra work for me :( and I'm already such a lazy person.
Hmm, this idea just popped up: there is a Carry between 74LS83 #2 and #3 that can replace the ALU generated one :)

_________________

I have built a 65816 card that I can run at 1MHz, but speed up (and hide in the next cycle) bogus opcodes (detected by VPA/VDA being low). A crude timing measurement (print TI$ before and after a BASIC loop from 0 to 65000) shows about 10% or so speedup. I haven't tried IEEE488 yet.

Running at 8MHz definitely breaks IEEE488.

And most probably both methods break serial IEC.

That's why I implemented a configuration option to ignore bogus cycles or not.

André

I don't follow. Your 65816 card, if this is the same device I'm thinking of, actually uses a real 65816, which retains all the 6502 instruction timings, bogus cycles and all. I don't understand what you mean by "speed up" in this case. Can you elaborate?

However, I'm pretty confident that if you substitute a 65CE02 or other CPU which eliminates bogus cycles, which is Ruud's original point, that positively will result in instruction timing changes, and that will alter IEC bus timings.

Am I missing something?

Sorry, I was too quick answering that.

Yes, my 65816 card can run the CPU at 8MHz with its own fast RAM, and slow down to 1MHz for bus accesses. If the CPU accesses a slow (1MHz) location, it can run ("hide") two or three fast (8MHz) cycles in Phi1 and still access another 1MHz location in the next Phi2 1MHz cycle, so that the slow bus sees two consecutive memory accesses.

I can also run the (upcoming version of my) 65816 card on a 1Mhz memory, and let it hide the bogus cycles - which gives the speedup mentioned above.



No, I am completely with you. I was just pointing out another example where I actually measured the timing changes due to removing the bogus cycles.

André