KermMartian wrote:
I think string IDs would be better. I'm planning on having programs pass around both messages and addresses as strings; I think that would be the most intuitive.
The problem with strings is, as I recall, getting numeric data out of a string is harder than getting a string out of numeric data. Unless I flipped that association mentally?
elfprince13 wrote:
KermMartian wrote:
I think string IDs would be better. I'm planning on having programs pass around both messages and addresses as strings; I think that would be the most intuitive.
The problem with strings is, as I recall, getting numeric data out of a string is harder than getting a string out of numeric data. Unless I flipped that association mentally? Without libraries, yes, but with Celtic III, it's as simple as using StringRead.
I would use lists for data kermM while they are larger in size they are a lot easier to traverse in Tibasic. which I believe you should know. Ultimately we could always make it parse the input type and save it accordingly to the users wants. We should have the space for that.
Notes: I think we should use some space on SaveSscreen as a flag section for different things.
Eg.:
-Initialize cn2.2
-Return data type
-compression(if implemented)
-Make Sum(17/18 a blocking call
-etc
Only cause that would be faster than checking it in each round and it will use a lot less space code wise in the end then checking data types in my honest opinion.
Should we make this able adjust a basic variable or two (Eg. S,R) to indicate if a frame was sent/received or not? This could be easily patched into the Calcnet ISR (the expansion hook I keep nagging you about Kerm
) with out much speed loss and IMO would be fast to work with in tibasic.
KermMartian wrote:
elfprince13 wrote:
KermMartian wrote:
I think string IDs would be better. I'm planning on having programs pass around both messages and addresses as strings; I think that would be the most intuitive.
The problem with strings is, as I recall, getting numeric data out of a string is harder than getting a string out of numeric data. Unless I flipped that association mentally? Without libraries, yes, but with Celtic III, it's as simple as using StringRead.
I was going to say I'm deeply prejudiced against people who use Assembly libraries, but then I realized I'm in a thread contributing to the design of an assembly library. So I'll just keep my mouth shut.
elfprince13 wrote:
KermMartian wrote:
elfprince13 wrote:
KermMartian wrote:
I think string IDs would be better. I'm planning on having programs pass around both messages and addresses as strings; I think that would be the most intuitive.
The problem with strings is, as I recall, getting numeric data out of a string is harder than getting a string out of numeric data. Unless I flipped that association mentally? Without libraries, yes, but with Celtic III, it's as simple as using StringRead.
I was going to say I'm deeply prejudiced against people who use Assembly libraries, but then I realized I'm in a thread contributing to the design of an assembly library. So I'll just keep my mouth shut.
Including me??
(actually on a serious note my last BASIC game tried to use as less of them as possible )
DJ_O wrote:
Including me??
(actually on a serious note my last BASIC game tried to use as less of them as possible
)
I'm pretty sure that was why you stopped talking to me for a year or two back in the day.
Not that I *actually* care, I just find it much more fun working within the constraints of the language and trying to find elegant solutions that way.
I vote we leave things up for the end user to decide. We can always find more space in dcs if we have to and I would rather have this be as robust as possible.
On a more notes related thing.
Code:
dbfCn2BASICSend: ;Started
; Send out the data to sender
; Arguments:
; sum(17,arg1,arg2
; sum(17,<anything but a string>,<anything valid>
; Explicitly enable calcnet do not send anything.
; Do we really need the above see cn2.2 control idea
; sum(17,ID,Data,(Lenght?)
;
; ToDo
; [ ] Read sender id from input
; [ ] Decide on how we know which kind of input we are getting
; { } Read data from input and write to send buffer
; [ ] Decide on how we know which kind of input we are getting
; [ ] Write calcnet frame
; [ ] If blocking block else call a halt then proceed
; [ ] Clean up
jp xLIBEndNoOut
dbfCn2BASICGet: ;INCOMPLETE
; Store a pending frame in to the passed variables.
; Check to see if Cn2.2 is started. see Cn2BASICStop
; Talk to kerm about where and how these are being stored.
; Todo
; [ ] Check to see if frame is pending
; [ ] Check to see what data types we are saving to.
; [ ] save sender
; [ ] save data
; [ ] reset the we processed the frame bit
; [ ] clean up
jp xLIBEndNoOut
dbfCn2BASICStop: ;INCOMPLETE
; Not sure we actually need this. Depends on if we dont use
;a one argument command on the above commands.
; Kerm says keep it.
; Im thinking it needs to be changed into a Control command to control the
; aspects of the basic handling routines so they stay snappy
; my thoughts are
; sum(19,X
; Start or stop calcnet explicitly.
;
; sum(19,Pointer,value
; write the value to the pointer maybe i should be storing these in bits?
;Ask kerm. We have the space.
; =====================
; Cn2.2 started | 1 byte
; Enabled On key PD | 1 byte ;2
; Cn2.2 Hook pointers. | 2 or 4 bytes pending on stuff ;4/6
; ID return type | 1 byte ;5/7
; Data return type | 1 byte ;6/8
; Id send type | 1 byte maybe I should dynamically ;7/9
; Data send type | 1 byte do these two? probably not ;8/10
; Compression | 1 byte ;9/11
; Blocking Call? + 1 byte ;10/12
; = 10/12 bytes total
jp xLIBEndNoOut
My current thoughts and comment blobs on each of these routines. Thoughts?
elfprince13 wrote:
DJ_O wrote:
Including me??
(actually on a serious note my last BASIC game tried to use as less of them as possible
)
I'm pretty sure that was why you stopped talking to me for a year or two back in the day.
Not that I *actually* care, I just find it much more fun working within the constraints of the language and trying to find elegant solutions that way. Actually I think it was something else (either a misunderstanding or mis-relaying info about myself). Years before, however, I did get angry at you once on UTI for a comment about ASM libs (IIRC I thought you were singling out my games)
But yeah to be honest, trying to push BASIC to its limits was very tempting in my final days of programming. Illusiat 13 only uses 184 bytes of ASM to copy archived programs to RAM because I didn't want to force players to constantly archive/unarchive chapters/maps everytime they progress in the game, like they had to do in Illusiat 10 through 12, along with early versions of 7 and 9. But I wanted absolutely everything else to be pure BASIC. It was kinda entertaining, actually. Too bad I didn't finish the game.
Good luck displaying grayscale maps instantly in pure BASIC, though.
You make a good point for send: we should add an option to block until send is complete, or return immediately and use some arguments to Cn2Send to test whether the frame has sent yet. We could also just make Cn2Send fail with a reliable error code if the previously-sent frame hasn't sent yet. I'm not sure why arg1 is "anything but a string", while I would expect it to say "a string".
For the Cn2Stop function, perhaps that can be a Cn2Function function or something that takes a numeric argument indicating stop, start, clear buffers, etc.
What we really need to know is, once and for all, how destructive running BASIC programs actually is to an IM2 interrupt that chains TI's interrupt (for getKey and friends) and whether chaining the OS interrupt would mean it tried to catch link activity.
Chaining the os interrupt would definitely make it try to catch link activity. The question is can we stop that behavior.
That arg1 thing was an idea for explicitly enabling Cn2.2
I like that Cn2.2Function Idea. Tho I see no reason why we would need to clear the buffers if we have the Asm stubs handle it for us.
The main questoin in that block tho was the concept of the flags. Do you think that is a good idea? Or a bad one?
I find most of them to be unnecessary. Blocking, for example, I feel should be a flag to Cn2Send() rather than something pre-defined and then kept until changed. The less global state that we need to maintain, the better. What sort of compression? And finally, what do you mean by this?
Code: ; ID return type | 1 byte ;5/7
; Data return type | 1 byte ;6/8
; Id send type | 1 byte maybe I should dynamically ;7/9
; Data send type | 1 byte do these two? probably not ;8/10
Someone suggested returning the frames compressed using TiFloats to be less ram heavy.
By that I mean have the user define the input type. Like instead of parsing sum(18,str1,L4) then loading the variables and checking their types. assume they are what they are set to in the flags.
Idk if thats even needed I honestly have no idea how the parser hook passes arguments to an assembly stub. Those notes are assuming all we get is a pointer in ram.
Strings are much, much easier for us to deal with than lists, but as Elfprince pointed out, it may be less intuitive to pull bytes out of strings (even though the Celtic III libraries have everything our users would/will need).
And if we were compressing ints into TIFloats, people would have to extract them anyway, so we might as well use strings. I'm not averse to a list option, but I would recommend detecting whether to return list(s) or string(s) by the arguments passed to each individual Cn2Get call.
Sounds reasonable to me. I was just Thinking of ways to cut down on overhead. As I would rather take less Time executing and more time in the basic parser
The compression thing was just an idea. Honestly I would probably be too lazy to implement it lol.
Hmm, I could have sworn we had discussed this more recently than a week shy of two months ago. Anyway, I need you to set up the CALCnet interrupt, start running random BASIC commands, and see if and when the interrupt mode changes. Presumably we also need to be working with a CALCnet interrupt that has the OS interrupt linked in.
yeah feels like it wasn't that long ago. Dam does time fly.
Do you have any clue why jstified would be crashing on that asm stub?
geekboy1011 wrote:
yeah feels like it wasn't that long ago. Dam does time fly.
Do you have any clue why jstified would be crashing on that asm stub?
Oh, that's probably why, I might have been thinking of that discussion. Sadly, no clues, sorry.
Things that do not kill IM 2:
- Input
- disp
- if then else
- while
- output
- for
- getkey
- delvar
- ->
- Anything under Test
- Menu
- Goto
- Pause
- Line
- ClrDraw
- verticle
- horizontal
- Asm(
- Sub Programs
Things that do kill IM 2:
- Pressing On. probably because it is being handled in the Tios interrupt.
- Archive
- Unarchive (I was expecting these to act as such)
It is a start. I will be adding more as I test them.
This is great, I'm very happy to finally see these underway. I'll be especially interested if the graphscreen stuff and Pause do anything.
Edit: Whelp, this is good news.
I just did some poking around in a dissasembly of the tios. Only place I see the interrupt being changed is in flash access commands I believe ( Im 1 / di / Out (14h),a )
So I believe we are good all around. But as we test it I will keep an eye out for problem commands.
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