Ok so I'm thinking of starting on a project with calcnet and I need some info on the CALCnet routines.
Personally I would prefer if one could get the source to the routines so that they can be modified to support my end goal but i doubt that will be possible (future compatibility blah blah blah)
So what I would like accomplish-able some how.
I need to have my drawing routines in a interrupt for grey scale quality among other things.
This game will be ran at 15mhz so we have some slack in the interrupt for other code and I need a way to add this and have control over what code is executing on each interrupt call.
Probably have more in a bit still processing ideas and all that fun stuff ^_^
Grayscale with CALCnet? I've thought about supporting both in my own OS, then I realized that they may not be completely compatible. CALCnet requires somewhat precise timing to work properly, so it cannot be interrupted while it's working. This means that if you managed to make them run in the same interrupt, the grayscale will stutter every time CALCnet sends our receives data. It could even pause the grayscale for about a second when transferring the largest possible CALCnet frame (255 bytes).
If you decide to do this anyway, I can think of two ways to do it:
- After setting up CALCnet, change the interrupt handler to your grayscale routine, and then jump into the CALCnet interrupt code
- Write your own CALCnet driver
The first would be the easiest option. I think you can get the address of the interrupt handler from the interrupt vector table, assuming it's using IM 2 (disclaimer: I haven't done interrupt code for Z80 for some time now, and not at all for the 83+ series). Then you can jump to that address instead of returning from your greyscale interrupt handler.
I believe what is being planned is to do the first option on that chart.
As for making the greyscale stutter it might it depends on if we can get calcnet to run every other interrupt or so instead of once per. At 15mhz. I think this should be possible with minimum issue but I am not sure >.<
Few other things worth asking
Is there a way we can take control of the on key when calcnet is running (I believe if we chain calcnet with our own routines first this will not be a issue but I may be wrong)
And just for knowledge's sake what is the CC counts on Cn2_ClearSenc/RecBuf?
christop wrote:
After setting up CALCnet, change the interrupt handler to your grayscale routine, and then jump into the CALCnet interrupt code
That's my recommendation as well.
geekboy wrote:
As for making the greyscale stutter it might it depends on if we can get calcnet to run every other interrupt or so instead of once per. At 15mhz. I think this should be possible with minimum issue but I am not sure >.<
If you do what Christop described, then yes, you can easily run once per several interrupts, but if you make it too far apart, you risk bottlenecking Cn2.2.
geekboy wrote:
Is there a way we can take control of the on key when calcnet is running (I believe if we chain calcnet with our own routines first this will not be a issue but I may be wrong)
Sooooort of. Not very reliably. Why?
geekboy on HCWP wrote:
Does Cn2_Setup clear out the send/rec bufs with zeroes?
Yes
geekboy wrote:
And just for knowledge's sake what is the CC counts on Cn2_ClearSenc/RecBuf?
ClearRecBuf: 79+(21*263)+1 = 5603 CC = 933.8us (0.93ms) at 6MHz or 0.37ms at 15MHz
ClearSendBuf: 5603-12 = 5591 CC, almost the same time.
I was wondering because we have a habbit of using on to quit our games. next question.
Does calcnet expect the shadow registers to remain intact? That is the only real issue with chaining it is we don't have the shadow registers to use in our own code unless they can be garbage when calling calcnet. And does calcnet expect the stack to remain sane for proper execution.
ok nother questoin coming from iambian this time. for a 255byte frame how many cc's does it take?
Shadow registers: CALCnet will "trash" them. CALCnet doesn't keep anything there in between interrupt invocations. If you care about your shadow registers, though, di/ei around the code that uses them.
Stack: Doesn't care where the stack is, just make sure it has a half-dozen to a dozen spaces to use. IF you need to use sp specifically for something like that clever buffer-clearing routine, di/ei around that.
CCs for a 255-byte frame: no way to tell. Depends on the receiver if it's a directed frame, depends how long it needs to wait to get control over the clock line for directed and broadcast frames. It may take several interrupt invocations for the data to actually go out depending on the state of the network.
KermMartian wrote:
Shadow registers: CALCnet will "trash" them. CALCnet doesn't keep anything there in between interrupt invocations. If you care about your shadow registers, though, di/ei around the code that uses them.
well we would be using them in our own interrupts where calcnet wont be called till the end of them anyway
KermMartian wrote:
Stack: Doesn't care where the stack is, just make sure it has a half-dozen to a dozen spaces to use. IF you need to use sp specifically for something like that clever buffer-clearing routine, di/ei around that.
Thank You very much for this info
KermMartian wrote:
CCs for a 255-byte frame: no way to tell. Depends on the receiver if it's a directed frame, depends how long it needs to wait to get control over the clock line for directed and broadcast frames. It may take several interrupt invocations for the data to actually go out depending on the state of the network.
mmkmay hopefully it wont go over 120000cc's or what ever that number is in 6mhz (i think thats the 15mhz value iambian gave me) thanks tho ^^
Iambian was wondering how he would find Dcs and its version number from an external flash app?
kinda realized this is important to even use calcnet from a flash app....
we are also wondering what the consequences of possibly moving the whole portion of calcnet that resides in ram(the routeins at $9999) would be if we so needed to for our purposes
also does calcnet/dcs use the asm_flags
Well, I can give you the BCall that you can use to find Doors CS, but there's no easily-found exposed version number. Moving the routine would not be advised, as it uses quite a number of absolute calls and jumps, as I recall. DCS uses a single asm_flag byte for running and indexing programs. CALCnet does not touch them.
*bump* Did you have any further questions here, Geekboy or Iambian? I've been off Cemetech for the past week or so, and I wanted to check if I missed any questions from you guys. I will also try to be on HCWP later.