TI83+ ASM Transfer Protocol
» > >
»
» View previous topic :: View next topic  
  • TI83+ ASM Transfer Protocol
  • 28 Nov 2010 09:28:52 pm
  • Last edited by Anakclusmos on 01 Dec 2010 01:10:52 pm; edited 1 time in total
From what I'e heard, this is my best attempt at writing a routine to recieve a byte from the link port.Please tell me if there are any mistakes.I barely understand any of the ring pull stuff.This is my best try.

Code:
RecieveAByte:
  ld b,8      ;we need to recieve 8 bits
  ld c,0
rab_loop:
  xor a
  out (0),a      ;set the lines low to init transfer
  in a,(0)
  bit 0,a      ;check if we recieved a 0
  jr nz,rab_not0   ;if not, check the second line
  xor a
  rra
  rl c      ;roll a 0 into C
  djnz rab_loop
  ld a,c
  ret
rab_not0:
  bit 1,a      ;check if we recieved a 1
  ret nz      ;return if both lines are high
  ld a,1
  rra
  rl c      ;roll a 1 into C
  djnz rab_loop
  ld a,c
  ret
Just gettin back in da groove
Well, it entirely depends on what the receiving routine looks like; you generally need to match the sending and receiving routines. Also, in the first few lines I see 'a' being used without being initialized:


Code:
  ld b,8      ;we need to recieve 8 bits
  ld c,0
rab_loop:
  out (0),a      ;set the lines low to init transfer
Surprised oh, I missed that..there was supposed to be an XOR A before that.But aside from that, do I have the right idea?If not, can you point out what I did wrong?

This routine needs to match up with the TIOS one.
Just gettin back in da groove
Anakclusmos wrote:
Surprised oh, I missed that..there was supposed to be an XOR A before that.But aside from that, do I have the right idea?If not, can you point out what I did wrong?

This routine needs to match up with the TIOS one.
It definitely doesn't match up with the TI-OS one, because it doesn't check that the receiver acknowledged the bit as far as I can tell.
Confused I thought that was done by pulling both lines low?
Just gettin back in da groove
Anakclusmos wrote:
Confused I thought that was done by pulling both lines low?
That's only to initiate the transfer in the beginning, not to initiate each bit. Razz
oh, my bad. how do you do that then? do you XOR the tip and ring or pull both lines high?
Just gettin back in da groove
Anakclusmos wrote:
oh, my bad. how do you do that then? do you XOR the tip and ring or pull both lines high?
Well, it's fairly complex, but basically when the sending calculator pulls a line high or low, the receiving calculator needs to pull the other line high or low as a form of acknowledgement.
I read it and I understand bit more.I even managed to improve their routine ^_^

Code:
RecieveAByte:
  ld b,0
  ld d,1
  in a,(0)
  bit 2,a
  ld c,0
  jr z,rab_loop
  ld c,1
rab_loop:
  in a,(0)
  bit 2,a
  ld a,c
  jr z,rab_lowclock
  or a
  jr z,rab_chclock
  jr rab_loop
rab_lowclock:
  or a
  jr z,rab_loop
rab_chclock:
  in a,(0)
  bit 2,a
  ld c,0
  jr z,rab_cont
  ld c,1
rab_count:
  bit 3,a
  call nz,rab_update
  rlc d
  ld a,d
  cp 1
  jr nz,rab_loop
  ld a,b
  ret
rab_update:
  ld a,b
  or d
  ld b,a
  ret
Just gettin back in da groove
Better, but I think still imperfect, not to mention that the sending routine doesn't check that the receiver actually acknowledged the byte. Also, the word is "receive", not "recieve". Smile
Neutral But it should still work, right? here's my sending routine...

Code:
SendAByte:
  ld b,a
  ld d,1
  ld c,$D1
sab_loop:
  ld a,b
  and d
  or a
  set 1,c
  jr z,sab_cont
  res 1,c
sab_cont:
  rlc d
  ld a,c
  out (0),a
  xor 1
  ld c,a
  ld b,6
sab_delay:
  djnz sab_delay
  ld a,d
  cp 1
  jr nz,sab_loop
  ret
Just gettin back in da groove
It won't work well, because it could continue to charge forward in sending bits before the receiver has acknowledged the previous bit, leading to de-synchronization and data corruption.
Here's the original routine, would it have the same problem?It seems to be pretty well timed...

Code:
Read:
   ld b,0         ; reset variables (b = byte,
   ld d,1         ; d = bitmask, e = clockstate)
   in a,(0)      ; Get byte and check tip
   bit 2,a
   call z,State_zero
   call nz,State_one
Read_go:
   in a,(0)      ; Is clockstate changed?
   bit 2,a
   ld a,e
   jr z,Clock_is_low
   or a
   jr z,Clockchanged   ; Yes (High)
   jr Read_go      ; No
Clock_is_low:
   or a
   jr z,Read_go      ; No  (Low)
Clockchanged:         ; Yes
   in a,(0)      ; Get value from port
   bit 2,a
   call z,State_zero   ; Store new clockstate
   call nz,State_one
   bit 3,a
   call nz,Or_byte   ; Or them, depending on state of ring
   rlc d
   ld a,d
   cp 1
   jr z,Stop_read      ; Yes: quit
   jr Read_go      ; No, next bit
Or_byte:
   ld a,b
   or d
   ld b,a
   ret
State_zero:
   ld e,0
   ret
State_one:
   ld e,1
   ret
Stop_read:
   ld a,b
   ret
Just gettin back in da groove
Yeah, I'm not complaining about your Receive routine; that looks fine. Your Send routine is the one not checking that the receiver acknowledged the bit, if I'm reading your code at a glance properly.
I am sooo getting mad...I tried testing the original routine posted above in my OS and it froze. I know that the problem has to do something with the above routine.Here was my code...

Code:
keyloop:
  in a,(0)     ;check the link port
  bit 0,a      ;if the tip is high
  jr nz,continue   ;no one is sending anything
  ld a,$D0   ;set both lines low
  out (0),a
  call receiveabyte  ;receive a byte
  ld de,0
  ld (pencol),de
  call _vDispAHEX    ; display the received byte in hex
continue:
  ld a,GEnter
  call CheckKey
  jr nz,keyloop
  jr mainloop

linktxt:  .db "Receiving...",0
Just gettin back in da groove
Sometimes, when I have freezing issues, I set up an IM 2 ISR that checks for the ON key, and optionally chains to the TIOS ISR. When you press ON, the ISR displays the last value on the stack---which is the location of the next instruction that would have been executed---and the current register values. It makes for a sort of crude on-calc debugger.
DrDnar wrote:
Sometimes, when I have freezing issues, I set up an IM 2 ISR that checks for the ON key, and optionally chains to the TIOS ISR. When you press ON, the ISR displays the last value on the stack---which is the location of the next instruction that would have been executed---and the current register values. It makes for a sort of crude on-calc debugger.
Ooooh, that sounds great! Unfortunately, the one major issue where that would have helped me, the problem was in an interrupt that was getting disabled, which is one of the few places that that wouldn't help. Sad
  
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
TI83+ ASM Transfer Protocol
»
» View previous topic :: View next topic  
Page 1 of 1
» 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