Aww, I dont think I will be able to. Maybe I can ask someone to help me

Good luck on this Kerm, I await a beta

That's fine, I'm sure someone like a parent would be willing to help you. So far you only have two calculators, right? No need to worry about it yet until you have more calculators anyway. I finished helping Sonlen with his program for now, and posted code and a screenie, so right now I'm staring at CALCnet2.2 code again. It seems to succeed in transmitting pretty frequently now...

how much longer do you think until there is something for me to test ;P

I'll try to get a simple two-calculator test done by the end of the day today, but no promises.

O_O

Keep staring at the code. like this ^



I will be waiting for it Kerm

Some progress! The following things occurred to me during testing:

:: Looks like successes are replicable. If so, I'll post screenies and a photo of real calculators.
:: For jamming the network prior to transmitting: right now I spend 1/60th sec per interrupt jamming. That means the regular program never gets to run. Two possible solutions:

(1) Jam for 50% or 75% of 1/60th of a second, then relinquish control until the next interrupt. Possibility: another rogue calc could steal network control.

(2) Only attempt transmission every OTHER frame. Detriment: would limit to 30*256 = 7.68KB/sec maximum, probably much less.

Might I ask for some features of calcnet?

Sure, here's what I remember and have re-learned from my code:

:: Connection of an arbitrary number of calculators on a single network
:: Electrically-simple networking, requiring only simple line boosters in large networks.
:: Versatile network protocol, offering flexibility to applications for network usage
:: Integrated support for global CALCnet (gCn) via a special network address (AA:AA:AA:AA:AA), allowing bridging to the outside world. A gCn bridge may also provide transparent support for linking multiple CALCnet networks by acting like all the calculators in the remote network(s)
:: Non-blocking, interrupt-based buffered network routines require minimal changes to the host program.

Probably more; I'll flesh this out as I go.

*bump* I've been working some more on this (sporadically, of course), and I'm making progress. I worked out some kinks with timing and synchronization, commented out some byte-transmission count aggregation code that looked to be non-functional, and added a flag to avoid attempting transmission of the same packet in two successive interrupt frames to avoid leaving no time for normal computations. Currently messages more or less always send on the first try, but they seem to be partial. See below:



The left-hand calc is receiving, the right-hand one is sending. The pixel bars are to help me debug network activity and interrupt segments. To do list!

1) Fix partial bug
2) Test on real calcs, post pictures
3) Implement send-to-many, namely (3a) implement comparison to $00*5 as receiver ID and continue receiving if so, (3b) adjust sender delay to account therefore, and (3c) do not do sender/receiver checksum confirmation for such a packet
4) Write PONG demo
5) Screenshots and videos!

It works!!!!!!

Well, it's missing half the message, which I'm working on debugging at the moment. I think I'm close to tracking down the problem.

what will be CALCnet's icon on DCS?

Currently it's just the DocDE7 icon, due to laziness. Do you have any ideas? I just quick sketched these random brainstorms up.

I like the second one the best

I just don't feel with the first one....

Yeah, I agree about that, definitely the second over the first, but I'm still not 100% on that. It seems to me that I had some old, spiffy Cn2 icons somewhere; I'll have to search for them.

Some debug notes:
:: When I start the receiver, then the sender, nothing happens (ie, the sender tries to send indefinitely, and the receiver spins indefinitely)
:: If I then quit and restart the receiver, the message succeeds immediately.
:: If I start the sender, then the receiver, the message succeeds immediately

In all cases the full messages is now succeeding. I suspect that making the sending routine work only every other interrupt resolved the partial-message issues.