From: Baltissen, R (Ruud) (ruud.baltissen_at_abp.nl)
Date: 2003-05-26 15:14:52
Hallo allemaal,
Some time ago I mentioned that there is a difference between 'load "$",8' en
'directory'.
load "$",8 (V2):
$28 ( $F0 p $24 $ $3F ? $48 h $60 ` $01 . $04 . $01 . $01
.
$00 . $00 . $12 . $22 " $52 r $55 u $55 u $44 d $54 t $45
e
directory (V4):
$3F ? $28 ( $F0 p $24 $ $3F ? $48 h $60 ` $01 . $04 . $00
.
$48 h $60 ` $01 . $01 . $00 . $48 h $60 ` $00 . $00 . $5F
_
$48 h $60 ` $12 . $5F _ $48 h $60 ` $22 " $5F _ $48 h $60
`
$52 r $5F _ $48 h $60 ` $55 u $5F _ $48 h $60 ` $55 u $5F
_
From the 11th byte on in V2 all bytes are preceeded by the three bytes $5f
(untalk) and $48/$60 (device 8 talk). Before the 11th byte it isn't after
every byte and $5F is missing. Instead you'll find $00 but I have my doubts
about this byte. My 'ReadIEEE' reads the data on the bus when DAV goes (L)
and after pulling NDAC and NRFD (L). But my sniffer, which records every
change, sees this:
00 0 1 0 1 1
60 0 1 0 1 1 V4 7th byte
60 0 1 0 0 1
Data ATN NRFD NDAC DAV EOI
60 0 0 0 0 1
60 0 0 1 0 1
60 0 0 1 1 1
00 0 0 1 1 1
00 0 0 0 1 1
00 1 0 0 1 1
00 1 1 0 1 1
01 1 1 0 1 1
01 1 1 0 0 1
01 1 0 0 0 1
01 1 0 1 0 1
00 1 0 1 0 1
00 1 0 1 1 1
00 1 0 0 1 1
00 1 1 0 1 1
04 1 1 0 1 1
04 1 1 0 0 1
04 1 0 0 0 1
04 1 0 1 0 1
00 1 0 1 0 1
Data ATN NRFD NDAC DAV EOI
00 1 0 1 1 1
00 1 0 0 1 1
00 1 1 0 1 1
00 1 1 1 1 1
01 1 1 1 1 1
01 1 1 1 0 1 <-- [1]
00 0 0 0 0 1 <-- the read $00
48 0 0 0 0 1
48 0 0 0 1 1
48 0 1 0 1 1
48 0 1 0 0 1
48 0 0 0 0 1
48 0 0 1 0 1
48 0 0 1 1 1
00 0 0 1 1 1
00 0 1 0 1 1
60 0 1 0 1 1
60 0 1 0 0 1
60 0 0 0 0 1
60 0 0 1 0 1
Data ATN NRFD NDAC DAV EOI
60 0 0 1 1 1
00 0 0 1 1 1
00 0 0 0 1 1
00 1 0 0 1 1
00 1 1 0 1 1
01 1 1 0 1 1
01 1 1 0 0 1
01 1 0 0 0 1
01 1 0 1 0 1
00 1 0 1 0 1
00 1 0 1 1 1
00 1 0 0 1 1
00 1 1 0 1 1
01 1 1 0 1 1
01 1 1 0 0 1
01 1 0 0 0 1
01 1 0 1 0 1
00 1 0 1 0 1
00 1 0 1 1 1
00 1 0 0 1 1
Data ATN NRFD NDAC DAV EOI
00 1 1 0 1 1
00 1 1 1 1 1
00 1 1 1 0 1
00 0 0 0 0 1
48 0 0 0 1 1
48 0 1 0 1 1
48 0 1 0 0 1
48 0 0 0 0 1
48 0 0 1 0 1
48 0 0 1 1 1
00 0 0 1 1 1
00 0 1 0 1 1
60 0 1 0 1 1
60 0 1 0 0 1
60 0 0 0 0 1
60 0 0 1 0 1
60 0 0 1 1 1
00 0 0 1 1 1
00 0 0 0 1 1
00 1 0 0 1 1
Data ATN NRFD NDAC DAV EOI
00 1 1 0 1 1
00 1 1 0 0 1
00 1 0 0 0 1
00 1 0 1 0 1
00 1 0 1 1 1
00 1 0 0 1 1
00 1 1 0 1 1 <-- [3]
00 1 1 0 0 1
00 1 0 0 0 1
00 1 0 1 0 1
00 1 0 1 1 1
00 1 0 0 1 1
00 0 0 0 1 1
00 0 1 0 1 1
5F 0 1 0 1 1
5F 0 1 0 0 1
5F 0 0 0 0 1
5F 0 0 1 0 1
5F 0 0 1 1 1
00 0 0 1 1 1
Data ATN NRFD NDAC DAV EOI
00 1 0 0 1 1
00 1 1 1 1 1
00 0 0 0 1 1
48 0 0 0 1 1
48 0 1 0 1 1
48 0 1 0 0 1
48 0 0 0 0 1
48 0 0 1 0 1
48 0 0 1 1 1
00 0 0 1 1 1
00 0 1 0 1 1
60 0 1 0 1 1
60 0 1 0 0 1
60 0 0 0 0 1
60 0 0 1 0 1
60 0 0 1 1 1
00 0 0 1 1 1
00 0 0 0 1 1
00 1 0 0 1 1
00 1 1 0 1 1
Data ATN NRFD NDAC DAV EOI
12 1 1 0 1 1
12 1 1 0 0 1
12 1 0 0 0 1
12 1 0 1 0 1
00 1 0 1 0 1
00 1 0 1 1 1
00 1 0 0 1 1 <-- [2]
00 0 0 0 1 1
00 0 1 0 1 1
5F 0 1 0 1 1
5F 0 1 0 0 1
5F 0 0 0 0 1
5F 0 0 1 0 1
5F 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
48 0 0 0 1 1
Data ATN NRFD NDAC DAV EOI
48 0 1 0 1 1
At point 2 you can see what IMHO one can expect: a byte has been transferred
by the drive and the computer interrupts the transmission with an ATN.
But what is going on at [1]? Normally the sender waits for NDAC = (L) and
NRFD = (H) and then negates DAV. As you can see, DAV goes (L) without NDAC
being (L). Then again, who negates DAV? Looking at the Data = $01 I think it
is the drive but that goes against the above statements.
Next problem: what triggers the computer to drive ATN (L)? When ignoring the
ATN my emulator is able to transfer 4 bytes before the communication hangs.
Then I inserted a quite crude line that kept reading the bus while ATN was
(L) but that didn't work out either. And I rather prefer a intelligent
solution and not this 'just-ignore-it' method.
Any comment, ideas or whatever is welcome.
TIA.
--
___
/ __|__
/ / |_/ 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.