From: Baltissen, R (Ruud) (ruud.baltissen_at_abp.nl)
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.
Data ATN NRFD NDAC DAV EOI
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:
ByteOut:
begin
boEOI := DoEOI;
asm
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;
@23:
{ Wait for NRFD = (H) }
mov dx, wLPTaddr;
add dx, 2;
@21:
in al, dx;
and al, 4;
je @21;
{ Wait for NDAC = (L) }
@22:
in al, dx;
and al, 2;
je @22;
call DavLo;
{Wait for NDAC = (H)}
mov dx, wLPTaddr;
add dx, 2;
@25:
in al, dx;
and al, 2;
jne @25;
call ParallelInput;
call DavHi;
call EoiHi;
@1:
end; {ASM}
end;
ByteIn:
boEOI := False;
asm
call ParallelInput;
call NdacLo;
call NrfdHi;
{Wait for DAV = (L)}
@21:
mov dx, wLPTaddr;
add dx, 2;
in al, dx;
and al, 8;
je @21
call NrfdLo;
{Read databyte}
@22:
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;
@23:
call NrfdLo;
call NdacHi;
@25:
{Wait for DAV = (H)}
mov dx, wLPTaddr;
add dx, 2;
in al, dx;
and al, 8;
jne @25
call NdacLo;
@26:
mov al, DByte
not al
@1:
mov DByte, al
end;
end;
EOI := boEOI;
ByteIn := DByte;
--
___
/ __|__
/ / |_/ Groetjes, Ruud
\ \__|_\
\___| http://Ruud.C64.org
=====DISCLAIMER=================================================================
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.