RE: IEEE protocol under BASIC V4

From: Baltissen, R (Ruud) (
Date: 2003-05-30 10:32:28

Hallo Andre en anderen,

> you may try to look at how VICE emulates it.

I have indeed thought about it. But yesterday I managed to make 'directory'
work :) That is, about two of four runs goes fine.

The reason things goes wrong sometimes must be a matter of timing IMHO. The
strange thing about it is that when it goes wrong, my routine hangs in
'ByteOut' at the point where it waits for the computer to acknowledge the
reception of the data.

I already noticed that, when it matters timing, the 8032-SK is less
forgiving then the C64. I use PC-Disk, my old 1541 emulator, as base. There
I didn't search for the directory until I had to send it. The 8032-SK simply
didn't accept this delay and timed out. So I had to shift the actual search
to the point where the 1001 start searching, right after receiving the name
of the file (in this case "$").

> I remember I had to do some ugly hacks to make it work with 
> all CBMs....

I did two things:
- I added a boolean that is set when the first byte sent by the computer is
$3F (= BASIC V4). 
- I added the needed number of 'ReadByte' after each one or two sent bytes.
Only to be executed if this boolean is set of course.

Not that ugly I think :)

But I'm thinking about one other timing 'improvement': I collect all needed
data and store it in memory. So the only thing left to do when I have to
send the directory is to read it from memory and send it. Thus no more
looking for track/sectors and other things that consume time in between.

 * State engine for the parallel bus
 * Names here are as seen from a device, not from the PET
 * Possible States
 *      WaitATN         Wait for ATN, ignore everything else

Only when awaiting a command. I don't check ATN during those in between
'ReadByte's mentioned above.

 *      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.

 *      OldPet          The PET 3032 doesn't set NRFD and NDAC low
 *                      before releasing ATN after a TALK command,
 *                      wait for a NDAC low first!

I only look for ATN when in idle mode. When executing a command, I don't
check for ATN at all AFAIK. 
Two days ago I actually thought about using the LPT-interrupt for detecting
ATN but decided not to do it for two reasons:
- This particular input of my laptop is blown up and cannot be used anymore
- What is the advantage? When running ML in a real 1001 you can execute the
IRQ-routine, dispose the original address and jump to the ByteOut routine.
If the interrupt occurs in the middle of my ByteOut routine, I have no means
to tell my program to restart this ByteOut again. No, I cannot use a flag.
If I use a flag, I need to test it from time to time. And if I have to test
a flag, I could check ATN for the same money. 

 *      Out1            Wait for NRFD high when sending a byte
 *      Out1a           Wait for NRFD low when sending a byte
 *                      Trying to save this didn't work
 *      Out2            Wait for NDAC high when sending a byte

All part of the normal procedure of sending a byte (see below). 

 *      atnlo, atnhi, ndaclo, ndachi, nrfdlo, nrfdhi, davlo, davhi

I use the same procedures and names.

> AFAIR the control lines are changes one
> after the other, not all at once.

 3F    0   0    1    0   1
 3F    0   0    1    1   1
 00    0   0    1    1   1
 00    1   0    1    1   1
 00    1   0    0    1   1  <---
 00    1   1    1    1   1
 00    0   0    0    1   1  <---
 28    0   0    0    1   1
 28    0   1    0    1   1
 28    0   1    0    0   1
 28    0   0    0    0   1

For those who are interested, my ByteOut and ByteIn:

    boEOI := DoEOI;

    call NdacHi;
    call NrfdHi;

{ Output data }
    call ParallelOutput;

    mov  al, Value;                     { Value = byte to be send }
    not  al;
    mov  dx, wLPTaddr;
    out  dx, al;

    cmp boEOI, False;                   {activate EOI-line?}
    je @23;                             {No, ->}

    call EoiLo;

{ Wait for NRFD = (H) }
    mov  dx, wLPTaddr;
    add  dx, 2;
    in   al, dx;
    and  al, 4;
    je   @21;

{ Wait for NDAC = (L) }
    in   al, dx;
    and  al, 2;
    je   @22;

    call DavLo;

{Wait for NDAC = (H)}
    mov  dx, wLPTaddr;
    add  dx, 2;
    in   al, dx;
    and  al, 2;
    jne  @25;

    call ParallelInput;
    call DavHi;
    call EoiHi;
 end; {ASM}

    boEOI := False;

    call ParallelInput;
    call NdacLo;
    call NrfdHi;

{Wait for DAV = (L)}
    mov  dx, wLPTaddr;
    add  dx, 2;
    in   al, dx;
    and  al, 8;
    je   @21

    call NrfdLo;

{Read databyte}
    mov  dx, wLPTaddr;
    in   al, dx;                {read byte}
    mov  DByte, al;
    in   al, dx;                {read again...}
    cmp  al, DByte              {... and check}
    jne  @22                    {if not equal, again}

    add  dx, 2
    in   al, dx
    and  al, 1                  {EOI?}
    je   @23                    {no, ->}

    mov  boEOI, True;
    or   bStatus, ssEOF;

    call NrfdLo;
    call NdacHi;

{Wait for DAV = (H)}
    mov  dx, wLPTaddr;
    add  dx, 2;
    in   al, dx;
    and  al, 8;
    jne  @25

    call NdacLo;

    mov  al, DByte
    not  al
    mov  DByte, al

  EOI := boEOI;
  ByteIn := DByte;

   / __|__
  / /  |_/     Groetjes, Ruud
  \ \__|_\



De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken. Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij overgebrachte virussen.

The information contained in this e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact the sender immediately by return e-mail; please delete in this case the e-mail and do not disclose its contents to any person. We don't accept liability for any errors, omissions, delays of receipt or viruses in the contents of this message which arise as a result of e-mail transmission.

       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.