ALDL (8192) command timing (sort of longish)

[Dig <turbodig@yahoo.com>]

For those of you who are/have been working with
the 8192 (high speed) ALDL commands, a question...

Have you experienced the same timing difficulties 
I have? In order to get things to talk (both from
DOS code and VB/VC++), I've had to do some weird
things with the timing of the ALDL request in 
relation to the constant HB. (this is in the context
of the $58/Sunbird/Syty code, but the TGP code seems
to require similar timing funkiness) XDE-9063 makes
it sound really easy to respond to the HB, but in 
reality you have a very fine-grained window to operate
in.

I'm using a self-powered MAX-232 for a cable; soon to
be a self-powered 3 transistor design.

My pseudocode for the DOS app (tested on 286 - 486)
would go like this:

Set up the PC serial PIC channel to interrupt on
an incoming char

On an incoming char, check the data.
If 0x55, delay 7 and transmit mode one.
Else, wait until next rx interrupt.

Data processing code...


In the VB version, I essentially poll the incoming 
data until I see 0x55, then I do the send, setting 
up the serial buffer event to fire when I have 72
bytes in it (I don't shut off recieve when I transmit)

I've got the VB stuff working pretty solid, but it 
bothers me that I don't understand why. To me, as the
document reads, you should be able to send any old 
time in the 180+ mS that the bus is "free" after a
HB. I've never been able to make it work that way.
I'm fairly sure of when I'm transmitting, I have 
an old TEK 2213 scope hooked up to the ALDL data.

I'm running the $58 code on a '730 running off a 
RS 12v supply... no inputs/outputs of any sort, just
ALDL traffic. 

Also, Is it just my stuff, or does the data drop out
a lot? The VB version takes a few Kbytes, and then
gets an RX serial error. I drop that packet, and 
then resend mode one, and it takes right off again,
but it makes me wonder about the noise immunity of 
all this. I've seen Diacom do similar things; losing 
the connection stream.

Finally, has anybody been able to make Mode 2 work
at all? My original work with it was to use it to 
dump a "Protected" (snicker) EPROM, but I couldn't
get it to dump a clean block. The first few bytes
were ok, but then the next ones showed repeating 
data patterns.  I can make modes 1,3, and 4 work
nicely, but 2 escapes me.

Section 5 of the XDE kinda looks like it was cut-n-
pasted out of another document, possibly XDE 5024,
so it wouldn't surprise me to learn that the docs
don't match the code 100%.

Thanks,

Dig
turbodig@yahoo.com