From: Andre Fachat (afachat_at_gmx.de)
Date: 2003-06-01 19:03:59
Hi Ruud,
>
> * In1 Wait for DAV low when reading a byte
> * In2 Wait for DAV high when reading a byte
>
> That is part of the normal procedure of reading a byte (see below). So I
> don't see why you consider them as separate states.
I had to use this, as the state engine is not polling all the time as
e.g. a program in the CBM disk drives. Instead the CPU emulation calls
the drivecpu0_atnlo() etc methods to signal the line changes. During
this
method all line outputs (emulated drive 0, drive 1, virtual drive,
as well as maincpu (C64, PET, CBM-II, ...) IEEE488 interface) are
combined
with the Open Collector rule (one is low -> signal is low) and when
a change is detected after this, the state engine atnlo davlo etc
methods are
called to change the state in the state engine.
So the line change is signalled asynchronously by calling methods from
the
CPU emulation, and thus I have to save the state between calling davlo
and davhi
> > AFAIR the control lines are changes one
> > after the other, not all at once.
>
> Data ATN NRFD NDAC DAV EOI
> 00 1 1 1 1 1
> 00 0 0 0 1 1 <---
> 28 0 0 0 1 1
Well, the "one after the other" thing comes from how VICE emulates it.
The CPU calls store_via(), which then detects changes, calls
drivecpu_atnlo(), drivecpu_davhi() etc in turn, and does not change
all at the same time. This also makes the state engine easier, as
you only have to check for one line change at a time. Checking for
two line changes would need to handle many more transitions.
Of course reality is different, but the emulation works nevertheless :-)
Andre
"Baltissen, R (Ruud)" wrote:
>
> Part 1.1.1Type: Plain Text (text/plain)
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.