Fine by me for the purposes of what I need. Thanks for the help tho.
» Forum
> Your Projects
Ok, here is the plan on how I will use calcnet. This i feel is the most streamlined. I use a temporary appvar to hold the on-calc database of all players.
(a calculator joining the network will broadcast a one-byte message, containing $01)
In the data sector of the CalcNet receive buffer, the first byte is the transmission type byte.
$01 indicates a new player. This calls up a routine that Adds 11 bytes to the appvar and inserts it's five byte sender ID. This leaves 6 bytes blank. They are later filled in. BROADCAST
$02 indicates an attack. This calls up a routine that deals damage. The next byte (RecBuf+1) indicates attack type (phaser/photon/torpedo/ect). PTP
$03 indicates a position update. This places the data in the appvar, filling in the 6-bytes after that player's sender ID. The only two blocks with this are (1) Finding the correct place to insert the position in the appvar in a timely fashion, and (2) Avoiding instances in which multiple transmissions interfere. However, since each calc updates its position on a broadcast, not PTP, within a few cycles, the transmission should hit. BROADCAST
$04 indicates a kill. This means that either a player has been destroyed and is auto-ejected from the network or that a player has left the network. This causes a receiver to scan the appvar for that player's data and delete all data pertinent to that player, and decrease the appvar size by 11. BROADCAST
Any comments/suggestions?
(a calculator joining the network will broadcast a one-byte message, containing $01)
In the data sector of the CalcNet receive buffer, the first byte is the transmission type byte.
$01 indicates a new player. This calls up a routine that Adds 11 bytes to the appvar and inserts it's five byte sender ID. This leaves 6 bytes blank. They are later filled in. BROADCAST
$02 indicates an attack. This calls up a routine that deals damage. The next byte (RecBuf+1) indicates attack type (phaser/photon/torpedo/ect). PTP
$03 indicates a position update. This places the data in the appvar, filling in the 6-bytes after that player's sender ID. The only two blocks with this are (1) Finding the correct place to insert the position in the appvar in a timely fashion, and (2) Avoiding instances in which multiple transmissions interfere. However, since each calc updates its position on a broadcast, not PTP, within a few cycles, the transmission should hit. BROADCAST
$04 indicates a kill. This means that either a player has been destroyed and is auto-ejected from the network or that a player has left the network. This causes a receiver to scan the appvar for that player's data and delete all data pertinent to that player, and decrease the appvar size by 11. BROADCAST
Any comments/suggestions?
oh crap. I did not mean to do that. lol. Can someone delte the second?
Edit: Code updated. Can someone tell me if 'call iFastCopy' has the right data passed to it.
http://pastebin.com/R3KwMYPQ
Edit: Code updated. Can someone tell me if 'call iFastCopy' has the right data passed to it.
http://pastebin.com/R3KwMYPQ
That won't work, you should use FastCopyb instead of iFastCopy.
souvik1997 wrote:
That won't work, you should use FastCopyb instead of iFastCopy.
Exactly this; I believe I mentioned that on IRC. You should test your code so you can see how and if it fails! - ACagliano
- Guru-in-Training (Posts: 2001)
- 12 May 2011 09:43:54 am
- Last edited by ACagliano on 12 May 2011 11:35:43 am; edited 1 time in total
First successful compile of the program. However, I didn't get to test all of it. First off, I need a better splash screen. Second, this is keeping caught in an infinite loop.
Code:
Code:
splash:
ld hl,Splash1
ld de,$9340
ld bc,Splash2-Splash1
ldir
ld hl,Splash2
ld de,$86EC
ld bc,Description-Splash2
ldir
ld a,8
ld (winBtm),a
greyscaleloop:
ld hl,$9340
call FastCopyb
b_call(_ClrLCDFull)
ld hl,$86EC
call FastCopyb
b_call(_ClrLCDFull)
nop
b_call(_getCSC)
jr z,greyscaleloop
b_call(_ClrLCDFull)
The Doors CS SDK works fine on Macs; the SDK PDF explains how to use it on Mac OS X, if I recall correctly. Problems with your code:
1) Use [code] tags! I'm getting tired of editing people's posts to include them.
2) In between getcsc and jr z, you don't check the value of the accumulator, for example with cp 0 (which you should always write with its more optimized form, "or a").
1) Use [code] tags! I'm getting tired of editing people's posts to include them.
2) In between getcsc and jr z, you don't check the value of the accumulator, for example with cp 0 (which you should always write with its more optimized form, "or a").
KermMartian wrote:
The Doors CS SDK works fine on Macs; the SDK PDF explains how to use it on Mac OS X, if I recall correctly. Problems with your code:
1) Use [code ] tags! I'm getting tired of editing people's posts to include them.
2) In between getcsc and jr z, you don't check the value of the accumulator, for example with cp 0 (which you should always write with its more optimized form, "or a").
1) Use [code ] tags! I'm getting tired of editing people's posts to include them.
2) In between getcsc and jr z, you don't check the value of the accumulator, for example with cp 0 (which you should always write with its more optimized form, "or a").
1. Sorry about the code tags. Could've sworn they were there. They're there now
2. Oh. I thought the b_call(_getCSC) set the flags on its own. Point taken. I followed advice above and instead used Direct Input on that loop.
Now that I've gotten to the rest, all other parts that are coded seem to work...except for this, which freezes:
Why aren't the tags working?
Code:
quit:
b_call(_ClrLCDFull)
ld hl,AppVar ;AppVar is defined.
b_call(_Mov9toOp1)
b_call(_ChkFindSym)
jr nc,overwrite
createappvar:
ld hl,AppVar
b_call(_Mov9toOp1)
ld hl,14
b_call(_CreateAppVar)
overwrite:
ld a,b
or a
jp nz,unarc2
ld hl,ShieldPoints
ld bc,8
ldir
ld hl,photons
ld bc,6
ldir
ld hl,AppVar
b_call(_Mov9toOp1)
call arcf
ret
aeTIos wrote:
You should look @ it in the not-working code post. I'm pretty sure it's checked.
That's what I'm saying. The only thing in that post that is checked is **attach signature.
merthsoft wrote:
It was because you had an open code tag in Kerm's quote, so it was confused. I fixed it for you.
Oh. So, it was all Kerm's fault. lol. jk. Thanks merth.
Sorry to ask for more code snipets, but can someone help me out with:
1. A TEXT INPUT routine that uses direct input (or getCSC, but di is preferred). My intent in this is to hit the [graph] key, which opens a window with a list of player names. You select a player name, and then get a typing window. Press [ENTER] and the text is transmitted PTP. This can use the DCS GUI commands. If someone can help with the GUI and the DI, I'll handle the transmission (I'd rather have someone else code direct input, at least until I get used to how it works).
2. Help with a routine, using the DCS GUI routines, that prompts for a user name and password.
You can use the DCS GUI functions for text input. http://dcs.cemetech.net/index.php?title=Developers%27_SDK
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
» Go to Registration page
» Go to Registration page
» Goto page Previous 1, 2, 3, 4 Next
» View previous topic :: View next topic
» View previous topic :: View next topic
Page 2 of 4
» All times are UTC - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Advertisement