[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Apple emulators that support "floating bus" video sensing?

Dirk Thierbach wrote:

Michael J. Mahon <mjmahon@aol.com> wrote:


Dirk Thierbach wrote:


sicklittlemonkey <Nick.Westgate@gmail.com> wrote:


On Mar 19, 7:03 pm, Dirk Thierbach <dthierb...@usenet.arcornews.de>
wrote:




So how did they do that?




By slowing down to 1MHz when certain I/O locations were accessed.




That's what I thought. So, in other words, hardware accelerators can't
do it correctly, either, unless they run at 1MHz.




No, by automatically controlling their speed (which emulators apparently
aren't smart enough to do) they work correctly.



If you can specify exactly *how* they should do that, than emulators
can do that, too. Having a list of address that slow them down automatically to 1MHz is easy to implement. But then, it's not necessary -- the user 
can just manually switch to 1 MHz.


The objective is to switch speed automatically *only when needed* so
that in most of the execution of the program, the accelerated speed
is available.

Here's an extract from the Zip Chip technical description.
(The whole thing is a text file on the Zip Chip Utilities disk.)

===============================================================

            ZIP CHIP REGISTERS DESCRIPTION


$C05A SOFTSWITCH REGISTER - ZIP CHIP softswitch $C05A
allows access to all other ZIP CHIP registers.  This is done
through the Lock/Unlock feature.

To lock the ZIP CHIP registers write a $A5 to address $C05A.
Unlocking ZIP CHIP is a little more difficult.  To prevent
accidental unlocking by programs, at least four writes of
$5A in succession must be done.  Any other program write
instruction coming between the first four $5A writes will
invalidate the unlock. More than four $5A writes are ignored
by the softswitch.  Recommended assembler code to unlock ZIP
CHIP is:

         LDA  #$5A
         STA  $C05A
         STA  $C05A
         STA  $C05A
         STA  $C05A

While the ZIP CHIP is unlocked, any value other than a $5A
or a $A5 will cause an indefinite Synchronous Sequence,
(turns off the High Speed Mode) setting the system to normal
Apple speed of 1.0204 megahertz.

$C05B SOFTSWITCH REGISTER - This softswitch is used for a
variety of functions.  Primarily it is used to turn on the
ZIP CHIP to high speed.  This is done by any write to $C05B
while the ZIP CHIP is unlocked.  Reads of this softswitch
obtain data on a variety of ZIP CHIP functions.  Of
particular interest to those needing a precise timing
signal, is the one (1.0035) millisecond clock pulse at bit
seven of this register.  The bits of this register are used
as follows:

Bit 0 and bit 1 show the size of cache memory.

Bit two is unused.

Bit three is a one if the delay circuitry is active.  A slot
delay begins when an access is done to the I/O memory area
of a slot set for Synchronous Sequence   ($C0nX - where 'n'
is the slot number plus 8 and 'X' is a number from $0 to
$F).  The access begins a 52 to 54 millisecond period during
which all Reads come from the Apple to keep the computer at
Normal speed (1.0204 megahertz).  When the paddle or the
speaker is set for synchronous sequence, a softswitch access
results in a delay of 5 milliseconds.  A zero in bit three
indicates that no delay is in effect.

When bit four is a one, it shows that the ZIP CHIP cannot
cache code.  This bit will be set if the user presses the
ESCape key during boot or if a byte other than $A5 or $5A is
entered into register $C05A while the ZIP CHIP is unlocked.
A zero in bit four indicates that caching is enabled and the
ZIP CHIP can run at set system speed.

Bit five indicates whether or not Language Card accesses can
be cached.  If the bit is a zero then it is enabled.  If the
bit is a one then it is disabled.

Bit six confirms that a data read has updated the cache
memory.  A one indicates that cache has been updated; a zero
indicates that it has not.

Bit seven is a tap on the Apple Phase 0 clock. divided by
1024.  This bit oscillates at a one (1.0035)millisecond
rate.  The pulse edges occur at .50175 millisecond
intervals.  This signal can be used for precise timing
applications.


$C05C SOFTSWITCH REGISTER - The softswitch register at
$C05C indicates and determines which slots will run at the
speed set in ZIP CHIP or at normal Apple speed.  The speaker
is also controlled from this register.  Reads of this
register show the current condition of the speaker and
slots.

To enable a slot (or the speaker) to run a synchronous
sequence, a one is written to the appropriate bit.  Bit 0
controls the speaker. Bits 1 through bit 7 control slots 1
through 7 respectively.  A one written to bit 0 will allow a
five millisecond synchronous sequence for softswitch access
of $C030.

CAUTION: If an I/O device such as the Apple Floppy Disk
Drive is in a slot defined for other than normal access,
disks in that drive may be rendered unreadable.  Be sure
that a device can safely run at speeds above normal Apple
speed before setting its slot to a higher speed.
...<snip>...

$C05E SOFTSWITCH REGISTER - The $C05E softswitch register
has greatly different functions between Read and Write.  A
$C05E read is similar to a simultaneous read of eight
softswitches (for determining whether the Apple is in
AltZP or MainZP, etc.).  See table 2 for the exact switches
tested.

Only bit 7 of $C05E is functional in a write.  Bit 7 is the
delay switch controlling Synchronous Sequences.  If this is
a zero then Synchronous Sequences are enabled.  If this bit
is set to one while a delay is active then the delay is
terminated immediately.and Synchronous Sequences are
disabled.  Control of this register can ensure that a piece
of code will run at set system speed.

$C05F SOFTSWITCH REGISTER - This register controls
compatibility with bank switched memory cards and determines
if Paddle accesses cause Synchronous Sequences.  The two
active bits in this register control the caching of language
card memory and the slowing of the system for paddle use.
Bit 7 (normally zero), when set to one, disables caching of
language card memory.  This will allow large memory cards to
run with ZIP CHIP.  Bit 6 controls paddle softswitch access.
When set to one, accesses to $C070 cause a 5 millisecond
synchronous sequence.  When set to zero accesses to $C070
cause no Synchronous Sequence.

==============================================================

As you can see, this shows how it is configured selectively to slow
down on 1) reference to a "slow" slot /DEVSEL address, 2) reference
to the joystick/paddle trigger address, or 3) reference to the
speaker toggle address.  For completeness, one could do the same
with the cassette toggle address.

In fact, it would be most complete to have a 256-byte map of the
C0xx space, where a byte not zero indicates a slowdown for a
value-selected period of time, the table to be configurable by
the user.  (It's not clear that having it programmable through the
emulator is a significant feature, though providing Zip Chip
compatibility would have the advantage of supporting bootable
images set up to run on real hardware.)

I agree that it should be easy to implement, since it simply means
that a reference to certain addresses (as set by configuration) causes
the emulator to run at "1MHz" for a certain number of cycles before
returning to accelerated speed.

Frankly, I'm surprised that it hasn't been done, since hardware
accelerators were the only models for faster Apple II's.


In the specific case I'm trying to use, an accelerated machine correctly
samples floating video data and can pace itself to the video framerate.



Which would be still possible in the scheme outlined. It's just the
fact that the "emulated" video framerate isn't constant (to ensure the
correct behaviour for most programs, it would vary with acceleration
speed), and is not related to the real world.


It's easy to run anything at a constant pace at a fixed 1MHz--in fact,
you can't do otherwise!  The trick is to allow a machine capable of
higher speed to run fast while still permitting real-time to be
sensed to pace animations or desired delays.

Animations and desired (human-scale) delays are *always* related
to the real world--that is, people--they have no other purpose.


Among other things, this allows a simple subroutine to "wait for
X frames" before returning, allowing constant time delays for users
to do something human, 


If you're writing a new program anyway, and if all you want is constant
time delay and not something fancy like split-screen, then it would be
much better to just use an "emulated" clock with sufficient precision
in a "pseudo"-card as provided for example by one of the Linux apple
emulators.


I'm not writing this code for just an emulator.  I'm writing it for
*all* Apple II's--many of which do not have a real-time clock of any
kind--*except* the video generator!  Do you see what I mean?

"Being standard is *better* than being better!"

My objective is quite simple:  to provide the best possible experience
on the widest possible range of Apple II implementations--including
emulators--that can be achieved with simple methods.  (And by that,
I mean not doing seven different things based on the machine it's
running on.  ;-)

-michael

NadaPong: Network game demo for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."