Do those dots show how far the packets make their way through the receiver? What I want to find out is where the packet gets stuck so I can fix that part of the sender.
Let's call the groups 1, 2, 3 and 4, from leftmost to rightmost.
On the 83+/84+ side, I see, using Netpong:
* 83+/84+ connected together and having detected each other within one second: fast movement in group 1, slow movement in groups 2 and 3 (group 2 seemingly slower), group 4 usually white;
* 83+/86 or 84+/86: fast movement in group 1, average movement in groups 2 and 3 (somewhat faster than in 83+/84+ connection), group 4 usually white (but sometimes solid black);
* 83+/89T or 84+/89T: fast movement in group 1, fast movement in group 2, solid black in group 3, group 4 usually white.

The groups of pixels show something about the wires and/or packets, but I don't know what exactly Smile
Here's the definitions:

Group 1: Rotates once per interrupt trigger. Run an iFastCopy (LCD buffer memory to LCD copy) fast enough, and you can see it at close to its full trigger speed of ~110Hz.
Group 2: Rotates once for each receive frame start event, ie, passes the 8.1ms-ish pause and is getting ready to receive the actual data.
Group 3: Rotates once for each send frame start event, ie, the network is not too busy for us to send, and we are about to start jamming to start the frame.
Group 4 (far right): Changes from full black to full white or vice versa once per collision detected on the network and resolved with a jam.
So, IIUC:
* 83+/86 or 84+/86: the 83+/84+ often puts itself in receiving mode, and does send packets.
* 83+/89T or 84+/89T: the 83+/84+ very often puts itself in receiving mode (fast group 2), but the network is always too busy for the 83+/84+ to send anything (solid black group 3). IOW, my dumb frame sender is over-using the network (?!), and I need to 1) check my frames' length and 2) reduce the packet send rate Smile
Yup, that sounds about right to me. To avoid monopolizing the network, my Cn2.2 reference implementation will only try sending at most once every two interrupts, or at most at 55Hz. Perhaps limiting your test driver to at most that rate would help?
Definitely, but my test driver should already be sending at no more than ~19.32 Hz (default AUTO_INT_5 rate), since the code that changes the rate to 110 Hz is commented out Smile
Hence the "?!" in my previous post.
My next suggestion then would be that perhaps the driver mistakenly holds or leaves a line held low somewhere, causing the TI-83+/84+ to think that a frame is being constantly sent?
Yes, a spurious "move.b %d2,(%a1)" before the 2: loop in the SEND_BIT macro (smells like copy & paste & forget to modify Very Happy) had the unfortunate effect of often leaving one of the lines low.

After removing it, on the 84+ running Netpong, groups 2 and 3 both move rather quickly (i.e. there is some room for both sending and receiving), and group 4 blinks (which is normal, because the sender on the 89T doesn't care about what's going on the wire, so there are collisions when the 84+ is sending something).
Progress, but no dice: the 84+ doesn't detect the 89T's ID.
Wait, the 89T _should_ care what's going on on the wire and not try to send unless the wire is silent for a certain amount of time, the exact duration of which currently escapes me.
Yes, the sender should listen for up to ~833us. If it hears anything on the network in that time, it starts the timer over and listens again for up to ~833us. If the network is still busy after 3 times, the sender aborts and waits for the next interrupt to try sending again.

I don't see this listening phase in calcnet.c. It goes straight to the jamming phase.

Also, my driver doesn't jam the line when a collision is detected. This is an easy fix, but it won't fix the problem with the 83+/84+ not receiving the 86's frames at all.

By the way, what signal is sent for jamming when a collision is detected? Is it the same as the first jamming phase, that is, just pulling the clock low and leaving the data high?
It's clock low, data low (grounding both lines). You almost have the starting listen write, but you missed a nuance. It listens for up to 2500us for 833 continuous microseconds of silence. If it gets to that, it starts sending. If after 2500us it still hasn't seen 833 continuous us of silence, it does not send.
Yes, I have never put any listening code in the dumb sender: I relied on the robustness of the listening code in the reference implementation, and on the fact that the ~19.32 Hz (AUTO_INT_5) and the ~110 Hz timer (TI-Z80) are not synchronized Smile
(=> if I'm sending packets in the appropriate format, i.e. 5-byte ID, 5-byte 0, length = 01 00, payload = 01, even without listening code in the sender, packets are bound to be received by the TI-Z80, in a matter of several dozens of seconds. Or so I thought.)

I can try to put some quick listening code in.
Lionel Debroux wrote:
Yes, I have never put any listening code in the dumb sender: I relied on the robustness of the listening code in the reference implementation, and on the fact that the ~19.32 Hz (AUTO_INT_5) and the ~110 Hz timer (TI-Z80) are not synchronized Smile
(=> if I'm sending packets in the appropriate format, i.e. 5-byte ID, 5-byte 0, length = 01 00, payload = 01, even without listening code in the sender, packets are bound to be received by the TI-Z80, in a matter of several dozens of seconds. Or so I thought.)

I can try to put some quick listening code in.
You're right, that should more or less be the case. Smile That suggests that perhaps your byte-level / bit-level implementation is at fault?
KermMartian wrote:
It's clock low, data low (grounding both lines).

Thanks. The whitepaper doesn't say what the jam signal is, so I would've just pulled the clock low.

KermMartian wrote:
You almost have the starting listen write, but you missed a nuance. It listens for up to 2500us for 833 continuous microseconds of silence. If it gets to that, it starts sending. If after 2500us it still hasn't seen 833 continuous us of silence, it does not send.

That's what I was trying to say, but you said it better than me. Smile
Pulling the clock line low is definitely enough in this case, but it doesn't hurt to copy the reference implementation as closely as possible. Smile Based on your pseudocode, I'm not convinced that what I said is the same thing that you're doing. Could you post the code fragment for that bit?
Sure.

Code:
        ; set counter to 3
        ld      b,3
        ld      d,BOTH_IN_MASK
@loop
        ; wait up to 833us or until data or clock are pulled low
        ld      e,62 ;124
        call    wait_any
        jr      z,@mine         ; 833us has elapsed without activity

        ; if a line was pulled low,
        ;  decrement counter and goto @loop if counter>0
        djnz    @loop

        ; if counter == 0, return and wait for the next interrupt
        or      1
        ret

@mine

The wait_any routine waits up to 833us unless there is any activity. If there is activity it returns early with the Z flag clear. Otherwise it waits for the full 833us and returns with the Z flag set.
That's not correct. If there were three line fluctuations spaced 3us apart, then that would wait a grand total of 9us (roughly) and declare the network busy, even if it was followed by 2491us of silence.
Hm, ok. Looks like I misinterpreted the spec. I'll fix that bit now. That's probably not the real issue, though. My driver likely has bit-level timing issues which I unfortunately can't solve without a real oscilloscope. The pulse widths are almost too short to resolve at a 48KHz sample rate.
Averaging the values over hundreds of packets would, statistically, let us determine the pulse widths precisely enough to debug the program.
Here's a sample of my "oscilloscope" at 96KHz. I'm not sure if my soundcard or audio driver are up-sampling from 48KHz, or if it actually supports 96KHz natively. EDIT: Actually it looks like Audacity is up-sampling from 48K. Wink



The highlighted region is the single byte 0b01010100 (0x54, ASCII 'T').

As you can see it's hard to determine the timings exactly at this sampling rate, but I do suspect there's not enough time after the lines are released. Somebody with a real oscilloscope will have to determine the timings more precisely.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9  Next
» View previous topic :: View next topic  
Page 6 of 9
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement