Re: Data transfer methods

From: fachat (
Date: 2005-05-12 19:04:16

On Thu, May 12, 2005 at 04:30:52PM +0200, Baltissen, GJPAA (Ruud) wrote:
> I do wonder as well. The funny thing is that even if I don't insert those
> delays, the CBM neatly accepts all the bytes I send. But when displaying the
> result on screen, it is clear that the received are not used. Receiving a

I faintly remember that I had similar problems. I had another look at the
lptiec source, it seems I directly "copied" the IEEE handling loop from 
the drive to the PC (translating it from 6502 to C :-)

I don't know your hardware, but my hardware interface is a single file.
Maybe you could adopt it to your system to see if it works.
(My source is for Linux, but coming from VICE, it should compile 
on Win/Dos(?) as well)

> >  *      OldPet          The PET 3032 doesn't set NRFD and NDAC low
> >  *                      before releasing ATN after a TALK command,
> >  *                      wait for a NDAC low first!
> Before sending (the next part of) a directory, I wait for ATN to become (H).
> In all other circumstances I just gather the data and send it back with my
> ByteOut command. And this command handles sending the byte using the
> standard IEEE protocol. Certainly no extra checking of NRFD and/or NDAC
> after a TALK and/or ATN.

IIRC, in some cases the "normal" ByteOut is interrupted by ATN from the
drive. Depending on where the ByteOut is interrupted, the PET has accepted
the byte or not.
If you look into iec_loop.c (in lptiec from )
you see that in the function "talkloop" the function to retrieve
the byte from the PC disk (named "parallelreceivebyte") is called
twice. Once to get the byte to send it to the PET, the second
time to actually confirm the PC disk code that the byte has really been
sent. And in between there are two loops with escapes for ATN low.

BTW, you should get the very same problems when using programs with
GET# and INPUT# file handling, as this is the very same technique as
used in the DIR command.


       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.