Omnimaga
Calculator Community => TI Calculators => ASM => Topic started by: Xeda112358 on July 27, 2015, 12:03:43 pm
-
I am trying to write some link port routines and I am having some issues. Every so often, data won't be correctly transmitted and I have deduced that this only occurs when the sent byte has bit 1,3, or 5 set, it sometimes causes the next bit up to be set (so if bit 3 is supposed to be set, it also sets bit 4). This is a chaotic occurence.
What I do know is when the odd bits are read, bit 0 of port 0 (so the tip) reads 1. As well, the sending calc had a low battery, so I am not sure if it is an issue of bringing the lines up. I am pretty sure this is not the problem, though, as I switched out batteries.
I also tried adding code that guaranteed that the lines were reading correctly, otherwise it would rewrite the value to port 0 until it did. This still didn't work.
I tried adding huge delays, it still was just as unreliable.
Interrupts and link assist are disabled.
Below is my code if you want to muddle through it. It is supposed to send a value in Ans to the other calc and the receiving calc receives in Ans (modulo 100).
#define bcall(x) rst 28h \ .dw x
.db $BB,$6D
.org $9D95
bcall(4AD7h)
bcall(4AEFh)
sendb:
di
ld c,a
xor a
out (8),a
ld e,55h
sendloop:
rrc c
rla
sla e
ccf
rla
out (0),a
ld b,6 ;this is a delay, and not claculated to be precise. We probably do not even need a delay
djnz $
jr nz,sendloop
ld b,10 ;delay
djnz $
xor a
out (0),a
ret
#define bcall(x) rst 28h \ .dw x
.db $BB,$6D
.org $9D95
call getb
bcall(478Ch)
bcall(4ABFh)
ret
getb:
di
xor a
out (8),a
ld bc,$08AA
readloop:
in a,(0)
xor c
rra
jr c,readloop
rra ;bits cycled in are masked with 0x55 as a sideeffect. Need to invert anyways, so mask at the end with 0xAA
rr c
djnz readloop
ld a,c
and 1
rrca
xor c
xor $AA
ret
-
I believe that the sending code has a subtle timing error. I am going to do the rest of my post in code blocks because of ascii art.
When you send a bit, the lines look like this (or something similar but with things flipped):
____ ____ __
C: | | | | |
__| |____| |____|
__ ____ __
D: | | | |
|____| |_________|
? ? ? L ?
The letters under the changes in the clock are the state of the data line at that time. (L=low, H=high, ?=changing)
When the clock line changes at the same time as the data line, the receiving calc may see them at very slightly different times because the time scale here is tiny, and small errors in timing can happen.
What would be preferable is a slightly offset clock, so that the data line is certainly high or certainly low before the receiving calc sees the clock line. The slightly offset graph would look like this:
____ ____ _
C: | | | | |
____| |____| |____|
__ ____ ___
D: | | | |
|____| |_________|
L H L L H
-
Thank you a bunch! I just looked at the Tachyon link routines and noticed that the receiving end does in a,(0) \ rra \ jr c,$-3 \ in a,(0) \ rra \ rra
I tried doing that and it worked, but now I understand why. Thank you!