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.

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 )

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:


My current thoughts and comment blobs on each of these routines. Thoughts?

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:

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?

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.