Re: CPU's Timing Question

[Rubywand <rubywand@swbell.net>]

Bryan Parkoff writes ...
> 
>     Why is CPU's timing very important to these Apple II Slots and DMA?  I
> have noticed that most emulators ignore one extra cycle when it has crossed
> page boundary.  For example, BEQ, BNE, BCC, BCS, and other relative branch
> instructions should be 4 cycles WHILE branch is executing across page
> boundary, but emulator only show 3 cycles instead of 4 cycles.
>     Another example, each instruction uses X or Y Indexed such as LDA
> $3FFF,X that they take 5 cycles during it has crossed page boundary, but
> emulator only shows 4 cycles instead of five cycles.
>     Wrong count cycle timing may affect Disk II card, Sound Card, and etc.
> If you intend to write 6502/65C02 assembler code to measure cycle counter on
> real Apple II that it matches real timing.  Take this assembler code to
> emulator and test.  You may find the difference.
>     Do you think that emulator programmer do not care to add only one extra
> cycle that it will be very accuracy?  What is the reason?  I am curious.
> 
 ....

     Don't know, Bryan. My guess is that a page crossing check is moderately
bothersome and, anyway, page crossings are relatively rare. On an emu, most
stuff will not be affected by ignoring page crossings for relative branches.

     A one-cycle change for relative branches almost never matters for
sound stuff because sound rountines usually fit in a single page, typically
the $300 page. Something else is messing up reliable reproduction of 'old 
Apple' (8-bit) sound in many programs when running on an emu-- like PC
hardware may not have a way to do half cycles.

     Disk II access doesn't look very critical. Regular .dsk (.dsk, .do,
.po) images are plain data blocks. Even .nib images are still bytes, not
analog pulses like on a real Disk II drive.

     Maybe someone who has created an emulator can explain better what's
going on with extra cycles for page crossing.



Rubywand