From: A. Fachat (afachat_at_gmx.de)
Date: 2005-05-10 20:59:23
Hi Ruud,
Baltissen, GJPAA (Ruud) wrote:
>>It does not use any artificial delays at all, but
>>only reacts on the line changes,
>>
>>
I'm sorry I have to correct myself a bit at least. The software contains
delays when it has to access the LPT hardware, as my old PC was very slow
in that respect.
However, it is still a HW issue and not anything that has to do with
line changes.
>There is no artificial delay between (re-)setting NDAC, NRFD, DAV etc. when
>sending or receveing a byte. At this moment I have to place two artificial
>delays:
>1) between sending bytes when sending a directory. The same routine is used
>for LOAD "$",x as well as DIRECTORY. The trick is checking ATN every time
>
>
This is what the drive does IIRC
>after sending a byte. This delay is only needed for DIRECTORY, not for LOAD
>"$",x !!! But I cannot see that when the actual command is send [*], so the
>dealy is used for LOAD as well. FYI, the dealy is about 220 uSecs.
>
>
Actually the IEEE488 bus protocol is designed to explicitely not need
such delays. I still wonder why
you need them. (Even though CBM did a really bad implementation, they
managed to keep that)
>Where did I give the impression that it only works with the 8032? I have
>
>
I think you only mentioned the 8032, so I stand corrected, sorry.
>>(the 3032 was especially dirty...)
>>
>>
>Could you be so kind explaining this, please?
>
>
I had to explicitely code an extra state in the diagram because the
order how the lines were changed
was different from the 3032 and later models. Don't remember the details
though. You may want to
look at the VICE source, in parallel.c. Here is a comment on that
"feature" state in the state engine:
* OldPet The PET 3032 doesn't set NRFD and NDAC low
* before releasing ATN after a TALK command,
* wait for a NDAC low first!
Andre
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.