/me wishes I was better at assembly....
the problem is at this point I know a ton of the theory, but I haven't really messed around much....
anyway here's my outline of how it should work:
Code:
"123FE9":Asm(prgmDcslib
:Ans->A "The address of the the sprite to use as a register value for Ion sprite routines
:{vectortableaddress,registervalues}:Asm(prgmDcslib
I'm starting to like this idea a lot... I believe you're really onto something here. Now, we need to figure out which of the routines the BASIC programs should be allowed to access.
KermMartian wrote:
I'm starting to like this idea a lot...
me too, I think you need to implement it *hint hint* *nudge nudge*
I expanded on my post since you answered.
KermMartian wrote:
I'm starting to like this idea a lot... I believe you're really onto something here. Now, we need to figure out which of the routines the BASIC programs should be allowed to access.
all of them? and would there be way to access SE's?
SEs would be way more complicated. The best I could do for things like usb and cn2 would be to give the programs a 256-byte receive and 256-byte send buffer pair to write to.
KermMartian wrote:
SEs would be way more complicated. The best I could do for things like usb and cn2 would be to give the programs a 256-byte receive and 256-byte send buffer pair to write to.
I still like it....maybe SE's should have the basic lib built in, so that if they are called using Asm() instead of from the shell itself, the ones they can handle it themself....I dunno....
Which type of SEs?
calc84maniac wrote:
Which type of SEs?
elfprince13 wrote:
KermMartian wrote:
SEs would be way more complicated. The best I could do for things like usb and cn2 would be to give the programs a 256-byte receive and 256-byte send buffer pair to write to.
I still like it....maybe SE's should have the basic lib built in, so that if they are called using Asm() instead of from the shell itself, the ones they can handle it themself....I dunno....
Sorry, I couldn't resist.
KermMartian wrote:
elfprince13 wrote:
KermMartian wrote:
SEs would be way more complicated. The best I could do for things like usb and cn2 would be to give the programs a 256-byte receive and 256-byte send buffer pair to write to.
I still like it....maybe SE's should have the basic lib built in, so that if they are called using Asm() instead of from the shell itself, the ones they can handle it themself....I dunno....
I dont really know how the SE system works though, so perhaps now would be a good time to explain it to me...
Three types: called at load, called during mouse, called at unload. Each section can be up to 768 bytes (stored in saferam during execution). Limited absolute jumping allowed. No VAT changing or RAM deletion/insertion allowed. The mouse one can trigger mouse events such as movement and clicking (useful for Ps/2 stuff).
I just searched your ticalc.org programs, Kerm, but I didn't see any shell expansions to test. Am I just looking over them or are they somewhere else?
If I recall, they may all be 83, not 83+/84+. I don't believe I ever ported them to 83+...
KermMartian wrote:
Three types: called at load, called during mouse, called at unload. Each section can be up to 768 bytes (stored in saferam during execution). Limited absolute jumping allowed. No VAT changing or RAM deletion/insertion allowed. The mouse one can trigger mouse events such as movement and clicking (useful for Ps/2 stuff).
ahh, but how are they called? in other words how does an assembly program call a loaded SE?
also, how do ALEs work again?
*tifreak8x thinks that the wiki pages should have this tid-bit of info on them, for easier reference.
tifreak8x wrote:
*tifreak8x thinks that the wiki pages should have this tid-bit of info on them, for easier reference.
*elfprince13 concurs
*Harq thinks we should skip all of this and go right to creating our own language and ruling the world
But really, it would be awesome to have access to some of your routines, we can go rule the world later.
elfprince13 wrote:
anyway here's my outline of how it should work:
Code:
"123FE9":Asm(prgmDcslib
:Ans->A "The address of the the sprite to use as a register value for Ion sprite routines
:{vectortableaddress,registervalues}:Asm(prgmDcslib
Why bother with all the Asm() calls? Kerm, can't you just have DCS set up a hook for some function like Omnicalc does?
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
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
