I used to have many more debug pixels that I could turn on, but I think I don't have enough space left to turn those back on for a TI-83+/84+ build.
Hopefully we can track down issues with this soon.
Edit: Ooooh, you actually can see each bit in the transmission with your 96kbps "oscilloscope"! Not bad.
I added a partial waiting loop at the beginning of send_frame, to check for both lines remaining high for long enough before trying to send a packet (but for now, it will give up after the first collision - it doesn't retry up to 2.5ms)
Code: | Direct link I/O wire access
lea 0x60000E,%a1
| A dumb listening check, will not send anything unless the line has been free for long enough (>= 833 us)
| TODO: a better check !
| 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.
move.w #500,%d2
loop_listen:
move.b (%a1),%d3
dbne %d2,loop_listen
addq.w #1,%d2
bne.s end
| Compute checksum
[snip]
| TODO: ACK/NAK the checksum if it's a directed frame
| lea ack(%pc),%a0
| bsr.s send_byte
end: | added label before the return;
move.w (%sp)+,%d3
rts
This addition reduces the number of collisions to very low levels, I've seen a couple in 3 minutes.
Groups 2 and 3 now move rather slowly, like they do between the 83+ and the 84+.
The code is therefore in a state a lot saner than it used to be
But still no detection, which means I probably still have the bit/byte timings wrong enough. Unless a couple random pokes at the waiting loop counts fix the problem, I'll declare it done for tonight.
[EDIT: increasing the loop counts by ~10% and decreasing the loop counts by ~10% don't fix the problem. Enough poking for tonight ]
Very nice on the better sending and receiving speeds; what is your planned approach for tracking down your timing issues? Too bad Christoph doesn't have a TI-83+/TI-84+ to grab a timing view of the reference implementation. Perhaps I can see if my sound card can pull it off.
Since I won't be able to try the oscilloscope outside work hours this week, at home, I guess I'll solder a male stereo 3.5mm jack to the female stereo 2.5mm jack, and use the soundcard as well.
Lionel: just for reference if you do use your soundcard as an oscilloscope, the left side is tip (clock) and right side is ring (data).
Also, the Line-in on my PowerMac can't do better than 48KHz either. I tried 192KHz with arecord, but I just get lovely (near) sine waves where the data signal should have sharp edges.
Either ALSA or arecord is upsampling it for me. This soundcard also seems to invert the waveform too, so that a low signal is high in the wave. That's something to watch out for.
Ah yes, I noticed that in your Audacity screenshot. I'd still prefer to have some isolation circuitry between my expensive computer and my calculator, but I suppose it's safe enough.
christop wrote:
Lionel: just for reference if you do use your soundcard as an oscilloscope, the left side is tip (clock) and right side is ring (data).
Also, the Line-in on my PowerMac can't do better than 48KHz either
I wouldn't expect to be able to get better than 48KHz from line in. I think your optical audio might do better, but obviously the link cable isn't going to be outputting that.
Somehow he pulled off 96KHz, it looked like, unless I'm mistaken...?
KermMartian wrote:
Somehow he pulled off 96KHz, it looked like, unless I'm mistaken...?
Both he and Christop had issues with upsampling.
elfprince13 wrote:
KermMartian wrote:
Somehow he pulled off 96KHz, it looked like, unless I'm mistaken...?
Both he and Christop had issues with upsampling. Oh right, good point. Ah well, it was worth a try. I'll see if I can't get to run traces from my calculators either tomorrow or Friday for you guys and post them up.
elfprince13 wrote:
KermMartian wrote:
Somehow he pulled off 96KHz, it looked like, unless I'm mistaken...?
Both he and Christop had issues with upsampling.
Yup, I recorded at a higher rate than the hardware supported, so the software upsampled it for me. That didn't give me any more detail than at 48KHz, regardless of the sample rate of the WAV file. (There is no software in which I can say "Enhance!" to get better detail or resolution, despite what CSI et al try to claim ).
And I don't even have optical in, so I couldn't go that route anyway.
Awww, but you totally could figure out the protocol from a scratchy tape recorder tape of the transmission recorded underwater while loud music was played using such enhancement software.
KermMartian wrote:
Awww, but you totally could figure out the protocol from a scratchy tape recorder tape of the transmission recorded underwater while loud music was played using such enhancement software.
Actually, a good tape recorder would probably give you better quality if it wasn't for the music and scratching.
[edit]
Actually a bad one, since 96KHz is non-standards-compliant for DAT.
Ah, that's unfortunate. Anyway, let's try to steer this topic back to the subject of forward- and reverse-engineering the CALCnet protocol.
My father, mostly, and I have now made the female stereo 2.5 mm jack <-> female stereo 3.5mm jack adapter. I can now visualize CALCnet frames... and notice my blunders
* the first thing I saw, was my utter failure at reading the spec: the receiver ID comes, er,
before the sender ID... sigh
* then I saw that the 84+ does not mask out the MSB ("frame ready" indicator) of the length when sending the frame;
* then I saw (again, actually - I remember Kerm telling me that receivers don't read a checksum for broadcast frames) that there's no checksum for the broadcast frame.
But even after that, the 84+SE does not detect the 89T. I'll continue in the next few days.
Lionel Debroux wrote:
My father, mostly, and I have now made the female stereo 2.5 mm jack <-> female stereo 3.5mm jack adapter. I can now visualize CALCnet frames... and notice my blunders
* the first thing I saw, was my utter failure at reading the spec: the receiver ID comes, er,
before the sender ID... sigh
* then I saw that the 84+ does not mask out the MSB ("frame ready" indicator) of the length when sending the frame;
* then I saw (again, actually - I remember Kerm telling me that receivers don't read a checksum for broadcast frames) that there's no checksum for the broadcast frame.
But even after that, the 84+SE does not detect the 89T. I'll continue in the next few days.
The 2nd and 3rd points are interesting. First the 3rd point. Here's what the whitepaper says about broadcast frames:
Quote:
Note that broadcast frames do not follow the checksum/checksum/ACK-NAK convention.
After the transmitter sends its checksum, the frame is complete, and receivers are solely respon-
sible for checking the checksum and validating or invalidating the received data.
It sounds to me like the transmitter does send the checksum, and that the receiver should read and verify it.
Now the 2nd point. Does that mean that all receivers must mask out the high bit of the payload length field? Neither part of that is specified in the whitepaper (either sending with the high bit set or masking out the high bit in the receiver). My driver just strips the high bit of the payload length before sending the frame. Perhaps the DCS CALCnet driver assumes that the high bit is set so that it doesn't have to set it after the whole frame has been received (to tell the application that it received a frame), so my transmitted frames are, in effect, invisible to DCS applications.
Quote:
* then I saw that the 84+ does not mask out the MSB ("frame ready" indicator) of the length when sending the frame;
Code: ld hl,Cn2_Int_SendBuf+5
ld c,(hl)
inc hl
ld a,(hl)
and %01111111
ld b,a
dec hl
inc bc
inc bc
Cn2_Int_SendFrameAddr3:
push hl
ld a,(hl)
push bc
call Cn2_Int_SendByte
pop bc
pop hl
inc hl
dec bc
ld a,b
or c
jr nz,Cn2_Int_SendFrameAddr3
Notice that it masks it off on the sender end (and also on the receiver end). The +2 for the size is to account for the two checksum bytes.
Quote:
*then I saw (again, actually - I remember Kerm telling me that receivers don't read a checksum for broadcast frames) that there's no checksum for the broadcast frame.
Wrong again, sorry. The only thing that doesn't happen is that receivers don't ACK or NACK broadcast frames.
KermMartian wrote:
Quote:
* then I saw that the 84+ does not mask out the MSB ("frame ready" indicator) of the length when sending the frame;
Code: ld hl,Cn2_Int_SendBuf+5
ld c,(hl)
inc hl
ld a,(hl)
and %01111111
ld b,a
dec hl
inc bc
inc bc
Cn2_Int_SendFrameAddr3:
push hl
ld a,(hl)
push bc
call Cn2_Int_SendByte
pop bc
pop hl
inc hl
dec bc
ld a,b
or c
jr nz,Cn2_Int_SendFrameAddr3
Notice that it masks it off on the sender end (and also on the receiver end). The +2 for the size is to account for the two checksum bytes.
Kerm: I don't see any code that clears the MSb in the data that is actually sent on the wire. It only clears the MSb in BC.
Ooooh, good point, I didn't read carefully enough. Sorry, it's been a weird day. You're exactly right about that. It definitely gets cleared on the receiver end, though, so it doesn't matter if it gets sent as set or not.
KermMartian wrote:
Ooooh, good point, I didn't read carefully enough. Sorry, it's been a weird day. You're exactly right about that. It definitely gets cleared on the receiver end, though, so it doesn't matter if it gets sent as set or not.
My next question now is: does the receiver set the MSb of the payload length in memory once it has successfully received the entire frame?
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
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