Omnimaga
Calculator Community => TI Calculators => ASM => Topic started by: ACagliano on March 18, 2010, 12:55:04 pm
-
Can someone please write me a subroutine in assembly that will send to another calc, without the other being in receive mode. The variable to be sent should be written into Ans at the sending calc. So for instance:
"L1
subroutine
would send the variable L1 to the other calc and store it as L1. I hope this is possible and quick to do. Thanks all.
-
Its going to be very slow if you have to send a list of floating points. Can we make the assumption that each element in the list is 1 byte (an integer between 0 and 255) because then it could be lightning fast.
And there is no such thing as sending when not in receive mode. One of the calculators must wait. Either the sender waits until the receiver confirms it got the message, or the receiver has to wait until it get a message from the sender. However, there is a way to make neither of them wait, but then you can't guarantee that the message will actually received.
-
I think Omnicalc( send/receive commands actually sends 1 byte unsigned integers, right?
But Omnicalc usage == no xLIB/Celtic possible :(
-
Yes. we can assume one byte for each term in the list. I will confine the variables to not larger that 255. And, yes. Let neither of them wait. I'll deal with making sure that there is an opponent.
-
Any luck with this so far?
-
Well, we can only send two bits at a time, and we have to kill the system interrupt, so...
Are you cool with that?
-
Well, I need it to send at most a list with <25 slots, each of which contain only integers 0-255. What exactly do you mean by "disabling interrupts" (I think I know, I just want to be clear). Then, I can tell you.
-
By "disabling interrupts," I mean stopping the OS from messing around with the link port while we are using it. Also, with 25 slots, we would have to talk to the link port 400 times to send the list.
-
I'm fine with disabling interrupts. As for 400 times, I wouldn't care if we had to talk to it 100k times (unless you had to code that many times). If its not too much, I'm ok with what you suggest. Thanks.
-
Well, I have never worked with the link port before, but I will try it later today if possible.
-
Ok. Thank you much. Once done, I'll need proper info to credit you for this subroutine.
-
At this point, the list only has 17 slots, so we can assume 20 max.
-
I'm not super stringent on getting the proper credit, but if you really care, give credit to Drew DeVault.
What exactly are you sending, out of curiosity?
This is from Will West:
;=======================
;SendByte
;Sends the contents of c
;to anothe calculator
;destroys
; a
; b
; c
;=======================
SendByte:
ld a,0
out (0),a
ld b,%10101010
sla b ;8
rla ;4
sla c ;8
rla ;4
out (0),a ;11
;xor a ;4 incase it turns out that bits 2-7 need to be 0
;39
sla b
rla
sla c
rla
out (0),a
;xor a
sla b
rla
sla c
rla
out (0),a
;xor a
sla b
rla
sla c
rla
out (0),a
;xor a
sla b
rla
sla c
rla
out (0),a
;xor a
sla b
rla
sla c
rla
out (0),a
;xor a
sla b
rla
sla c
rla
out (0),a
;xor a
sla b
rla
sla c
rla
out (0),a
;xor a
;out (c),0;both lines high
ret
GetByte:
ld c,2
m1:
in a,(0) ;11
cp c ;4
jr nc,m1 ;7/12
rra ;4
rr b ;8
;34/39
m2:
in a,(0)
cp c
jr c,m2
rra
rr b
m3:
in a,(0)
cp c
jr nc,m3
rra
rr b
m4:
in a,(0)
cp c
jr c,m4
rra
rr b
m5:
in a,(0)
cp c
jr nc,m5
rra
rr b
m6:
in a,(0)
cp c
jr c,m6
rra
rr b
m7:
in a,(0)
cp c
jr nc,m7
rra
rr b
m8:
in a,(0)
cp c
jr c,m8
rra
rr b
ret
-
http://ourl.ca/4286
The above link should give you background.
I am trying to transmit data about the enemy ships between players.
When you get a chance, can you please compile that into .8xp for me, meanwhile I'll use my on-calc compiler to see if we get the same results.
-
I wish this was implemented in Celtic III, because the Asm( command alone takes 0.25 seconds to execute. I heard it's due to having to search the VAT or something before running the program.
-Load about 80 programs in your calculator (it doesnt matter if they're archived or not, as long as there's enough space for the following):
-Then install Celtic, Omnicalc or xLIB on your calc.
-Then install CODEX.
-Make a Random 8x8 sprite and store it to pic0
-Make a program to fill the entire graph screen with that sprite using Celtic/Omnicalc/xLIB using the Sprite display command, no tilemapper command.
-Make the equivalent for CODEX.
-Now compare the speed of both sprite displayers and notice how incredibly slow the CODEX version is, and it's not CODEX fault, as the 8xp version of xLIB did that too.