Re: CPU's Timing Question

[mjmahon@aol.com (Michael J. Mahon)]

Rubywand wrote:

>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.

I think you'll find that in most cases, being "spot on" with the elapsed
cycle counter was judged not worth the cost in emulator performance
to get it right.  There are some cases, such as fancy sound generation
(Like DAC522, for example ;-), where complete accuracy is required for
faithful reconstruction of the speaker waveform.  (Then, to do that waveform
justice with modern sound hardware, it must be digitally filtered and then
virtually "sampled" at, say, 44.1kHz and then the samples double-buffered
into a sound card.)

DAC522 uses 22kHz rectangular waves of varying duty cycles to generate
5-bit accurate sound on an Apple II speaker (or headphones).  Fiddling a
few cycles to produce exact timings is the name of the game, and I use
always-page-crossing indexing occasionally to get a single extra cycle.

For those who haven't played the cycle counting game on the 6502,
it is easy to modify a path by 2, 3, 4, or more cycles, but adding just
one can be a little tricky (since the shortest op execution time is 2 cycles).
As a result, one learns to use tricks like page-crossing to get the single-
cycle delta.

These days, with >2GHz processors the norm, emulator performance is
not such a big deal, and an emulator writer can easily afford the extra
work to keep an accurate cycle count.

-michael

Check out amazing quality sound for 8-bit Apples on my
Home page:  http://members.aol.com/MJMahon/