Debugging the C2N232 serial bus add-on

From: Marko Mäkelä (marko.makela_at_hut.fi)
Date: 2004-05-24 15:08:28

Adrian,

> Ok, I have a working c2n232 now, or at least the IEC part

Great! I guess you can successfully SAVE data to any device whose number
you have passed to the "pay attention" command.

> I'm kinda stuck now though.  What exactly am I supposed to be running on 
> the 'big' computer side?

A terminal program.  (Yes, it would be easier to have a program
running on the PC that implements higher-level operations using the
available primitives, but I haven't come around to that.)  Once you
can LOAD or GET# data from the device, you should be ready to test
the C2N232 as a controller talking to a 1541.

I now found the test case document.  First, you should ensure that you can
input the NUL character (code 0, ctrl-@) in your terminal program.  Below,
lines ending in "->" mean data you send to the C2N232, and lines starting
with "<-" mean the expected response.  ^x means ctrl-x (i.e., the ASCII
code of x minus 64).

ensuring that NUL character works:
                                                                                
^J ->
 <- ':'
^@^@^@^@
 <- (no response)
^@
 <- '0'

(This is the "pay attention" command with 32 zero bits as the parameter,
i.e., do not listen to any device number, only to broadcasts.  The command
is followed by a "go idle" command.)

disk load emulation:
                                                                                
^J^I^I^I^I ->
 <- ':'
LOAD"FILE",8
 <- (~p^@^BFI2^@^D?^@^B^@^AH`^@^C
^LZ ->
 <- '<'
^A^B^C^D^E^FABC^@^@^@^@^@^A^@^@ ->
 <- ^@
 <- ~^@_^@^B^@^A(~`?^@^B
^@^J ->
 <- ':'
LIST
1541 ABC

(Hmm, above it looks like the file name was FI2 and not FILE.)
Note that above, the first command tells the C2N232 to listen to
many other devices than just 8.  It's just easier to type ctrl-i (TAB).

sending command to 1541 disk drive as device #8:
                                                                                
^LZ ->
 <- '<'
^@^B(  (TALK, device 8)
 <- ^A^@ (device not present after sending 0 bytes)
^@^J ->
 <- ':'

measurement from the above test case taken from a screenshot from a
Tektronix memory scope:

ATN  ¯¯¯________________________________________¯¯¯¯
                                                                                
CLK  ¯¯¯¯___________¯_¯_¯_¯_¯_¯_¯_¯_¯___________¯¯¯¯
             1ms                         1ms
DATA ¯¯¯¯____________¯_¯_¯_¯¯¯_¯¯¯_¯_¯¯¯¯¯¯¯¯¯¯¯_¯¯¯
                      0 0 0 1 0 1 0 0

¯ represents high state, _ represents low state.
The diagram is not drawn to scale; the parts "1ms" are much wider than
the region where the TALK command ($28) is sent.

As you see, for some reason, the drive won't drop the DATA line.
When the timeout occurs in the C2N232, the C2N232 raises ATN, and
the XOR gate in the 1541 will toggle DATA.  Shortly after that, the
6502 in the 1541 will toggle DATA again to release the bus.

> I assume it's different programs to act as a slave device or as a bus 
> master/controller?

At the moment, it's only different parameters to commands.  In the future,
they would be different programs: a file/print server program, and a
client for accessing peripheral devices.  Or it could be integrated in
the same program.

	Marko


       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.