Re: CPU's Timing Question

[kadickey@alumni.princeton.edu (Kent Dickey)]

In article <d3c5fce1.0405240517.4502b826@posting.google.com>, Tom Charlesworth <tomcharlesworth@blueyonder.co.uk> wrote:
>"Bryan Parkoff" <bryan.nospam.parkoff@nospam.com> wrote in message news:<r6Orc.12675$Hh.12325@fe1.texas.rr.com>...
>> 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.

KEGS, an Apple IIgs emulator available at kegs.sourceforge.net, gets all
of the above cases right for 6502-mode and 65816-mode.  It also has to deal
with a bunch of 65816-specific timing oddities (unaligned direct page,
16-bit sized registers, etc).

KEGS does not accurately emulate the bank 0xe0 and 0xe1 slow memory
timings, or the IIgs fast memory refresh timings.  The slow memory was
slowing KEGS down a great deal (not to calculate it, but KEGS can push
data to the screen at > 1MB/sec, but not if it's emulating slow
memory being just 1MHz), and I'm not aware of anything that cares about
the fast memory refresh timings.

>>     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.
>
>AppleWin certainly has this problem (1.10.4 & 1.12.3). When it was
>written 10 years ago(!) the speed of the x86 was poor so shortcuts
>were made to the 6502 emu code (which is written in asm) to squeeze as
>much performance from it as possible.

KEGS was written 10 years ago as well, in assembly at the time.

>Off the top of my head, I can think of a few things the could be
>affected by this emu limitation:
>- Mockingboard detection routines that time some 6502 opcodes using
>the 6522's timer. Eg. Skyfox - but this doesn't use page crossing
>opcodes.
>- AppleWin's speaker emulation creates a square-wave in realtime using
>the cycle count. If a game's sound driver uses page-crossing opcodes,
>then it could play back at the wrong pitch. Michael has already
>expanded on this.
>
>I'll get this fixed.
>
>Tom

Some Apple IIgs demos, especially those with border effects, will crash
or hang if the emulator is not cycle accurate at 1MHz.  The XMAS demo has
a fast case statement based on the video counters, and if the emulator
don't return one of the four (I think) valid values, it crashes.

Emulator writers have different goals--some might go for great compatibility
and trade off speed when necessary to get it, and some might go for speed
over compatibility.  Clever design can get both usually, but it's always
more work to do both.

Kent