dont worry about that linc thats more of a note for me and him and let me know

I just installed the Axiom as of yesterday and got it integrated into Axe 1.1.2. I haven't done any message testing yet, but I did find that getKey(x) works fine, like this:

Code:

However, I also noticed that your list of equates does not contain a size pointer, because you have to store the size of the frame in the low byte of the size word. The LSB of the size word is 5 bytes ahead of the beginning of the sender ID, so I was able to figure it out.

loloops ill add that in for the next version xD

I need to dig deeper to see if i need to replace that it may or may not bug out on the rare occasion due to how axe code is formatted

also i will keep the most uptodate copy of gcnlib right here http://sc.cemetech.net/?xpi=a0dd58b02147d24567312e084848e94b
sourcecoder is wonderful somedays (also i changed some of the names around i will redocument them in the updated readme)

Thanks, geekboy.

I did a little more testing with the Axiom and library, and I was able to get Calcnet up and running between two calculators (TI 84 Plus and TI 84 Plus Silver Edition, if you'd like to know).
However, I found that the set and recieve flag commands don't work: SetS appears to set the recieve flag (or GetR appears to get the recieve flag), and a few other bugs I couldn't locate. Calcnet only started working when I modified the MSB of the size words directly.

Taking a look at your code...

Code:

...it appears like correct logic. I don't know the logistics of z80, but I think that the rotate operations actually rotates the most significant bit into the carry flag, as it does on the Apple //e's 6502. Try adding another rotate to fix the problem.

The RLCA instruction should rotate directly from bit 7 to 0, and also bit 7 into the carry. The RLA instruction, confusingly, rotates the carry into bit 0 and bit 7 into the carry. Therefore, that code should be correct, although I'd recommend:


Code:

using rlca is still faster there Kerm seeing as we don't care for any of the other flag stuff rlc does (4 cycles over i do agree with the and 1 tho and U have updated my source with that as that's a good idea for future proofing

Sorry, that was the point I was making, the and 1. Sorry if that was not entirely clear; I wasn't criticizing the rlca.

yeah thought so was just pointing out

also compy I looked at my code the set/gets are pointed to/should be returning the right data. I will upload a new copy with a updated readme and such at some point tonight

Sounds like a plan. As I mentioned on IRC, when I get home I'd be happy to look over your code as a sanity check.

awesome thanks once I get that sanity check I will update stuff. Seeing as this is why its in beta xD

Alright, so I'm looking through the white pages on the wiki, and it says, "To send data via CALCnet2.2, a calculator program must first place the receiver ID... in the associated memory areas". If I understand correctly, this memory area is 86EE, or the constant UID? How do I get the receiver ID?

86ee is your calcs id. you do not modify that as that will break stuff.

87FA or SNDID\TXID is the is the id of the calc you are sending to.

now to get that id you would follow this flow chart http://geekboy.57o9.org/CALCNet/CALCnet%20Server%20Client%20Initialization%20Flow.png

you load RCVID\TXID with 00000 then use SetS then every calc will get a frame with your id in it. they then save it and send a reply back which will contain there id.

then you copy those id's into ram. so you can copy them back into the SNDID to send data to a specific calculator

To say the same thing again, but in a different way, you load data into Cn2_Int_SendBuf, and you read data from Cn2_Int_RecBuf. You should never touch any other area of the data near 86EC. For Cn2_Int_SendBuf, you load 5 bytes of receiver ID, leave two bytes of space, load the data to send, then go back and put the size in with its high bit set. To receive, check Cn2_Int_RecBuf until the highest bit of the size gets set. When it does, read out the sender ID and data as needed, then clear the flag.

OK, I think that makes sense. I'll look more in depth to that later today.

Great, hope it helps. If you have more questions, you should of course post them. And don't forget to read through the CALCnet whitepaper; it might help:

http://www.cemetech.net/programs/index.php?mode=file&path=/text/misc/CALCnet2.2.zip

OK, so looking at geekboy's flowcharts at http://ima.tiz80.com:1235/FrameFlowControl.png, I wrote some code, do you think this would work?


Code:


Also, I noticed that nowhere on the flowchart did it say a thing about any calc's ID. Do I ever need to worry about any calc's ID, sending or receiving?

Yeah you need the other flow chart for the id stuff. That one just outlines basic frame flow.
http://geekboy.57o9.org/CALCNet/CALCnet%20Server%20Client%20Initialization%20Flow.png

also you want ResR instead of SetR. SetR will set the receive flag to 1 and calcnet will only accept new data if the receive flag is set to 0.
so when you are done with the data you have you set it to 0 so you can get the next batch

I should also point out that to clear the receive buffer, the ONLY thing you need to do is zero out the size word (you might as well just ld a word-wise zero into it, ie, ld hl, 0 \ ld (Cn2_Int_RecBuf+5),hl ). It's not necessary to clear out the address or the data received.

all i do in code is


Code:


only because in the future you may use those bits for other stuff as you have said

As far as setting, yes. But for clearing, just clear out the whole word. I believe those are the semantics I use in all of my CALCnet2.2-enabled programs.