@Kalan: Everything I have so far is interrupt-less. The next layer that I'm working on now will use the lower levels in an interrupt routine to make things easier for real time games. But that has nothing to do with the Basic interface. To explain, here are the different levels:
low level - Easily control the hardware (not possible in Basic interface)
mid level - Sending over bytes using the low level (is in the Basic interface)
high level - Sending over blocks of data using the mid level (could be put in Basic interface)
network level - Setting up and using a network using the mid level (not in Basic interface, and will probably not get there)
net handler level - Holds the network level in an interrupt to make things easier (not in Basic interface)
@Liazon: Yes, the networking interrupt will make it impossible to use greyscale, but:
- you don't
have to use the interrupt for networking
- you can try merging the two interrupts, shouldn't be difficult, but I expect very ugly flickers when data is received
- the networking part will slow the game down enough; using greyscale too will probably make it too slow to be fun
And if I understand correctely how the interrupt timers work, they will not be reset when you enable interrupts. Only when you put the calc in low power mode (soft powerdown). So your idea of synchronizing the interrupts is pretty cool, but I don't think it'll work
Anyway, I don't use the interrupt to synchronize the network. I use it to enable calculators to be running a program/game and listen for transfers on the link port at the same time.
Ordinary two player link games usually swap a byte once every loop of the main routine, and that's it. You can't really do this in a scalable network though, because it will slow everything down way too much when the network gets larger. The other option you have is to check if a transfer is about to be sent once every loop of the main routine, and jump to a receive routine when you do. This can be dangerous though, if you happen to be doing something time intensive outside the main loop (like copying sprites to the screen and calling ionFastCopy) and you return too late to detect the transfer in time. I will add that option to the library though, because it can be useful if people want to try making a greyscale multiplayer game.
Anyway, the third option you have is to set up an interrupt with the sole task of doing that transfer check. It's there in the background, just waiting for a transfer to begin, while your game is running in front. When a transfer is detected, it calls a receive routine, checks if the transfer is meant for you, and if so it calls a user defined handler. So if you'd want to make a multiplayer game where you can walk around the screen for some reason, you'd just make your own transfer handler accept coordinates and draw your opponent on the screen. Whenever you move your character, your own coordinates are sent out to the other calculators, who then get triggered to draw your sprite.
Anyway, I'll make a few demo programs to do the talking for me when I finish the library routines