Kllrnohj wrote:
elfprince13 wrote:
as in....2.5mm serial cable on one end, cat-5 on the other, with a chip in the middle to turn CN2 packets into TCP packets.


Except the problem is the CHIP IN THE MIDDLE. *THAT* was where things got stuck, not on protocol. So TCP still won't help at all with the actual problem.
But if there's already an embedded chip with a straightforward C or ASM programming language that already has a TCP solution implemented, it's not the end of the world to implement Cn2 on the device as well to build a bridge.
So, until the problems are solved, are you planning on stripping GCN for extra space? I'm still hopeful this'll get released one day...
yoman82 wrote:
So, until the problems are solved, are you planning on stripping GCN for extra space? I'm still hopeful this'll get released one day...
AFAIR, removing the Cn2 only saved about 440 bytes anyway. Sad
KermMartian wrote:
But if there's already an embedded chip with a straightforward C or ASM programming language that already has a TCP solution implemented, it's not the end of the world to implement Cn2 on the device as well to build a bridge.


But now we are getting into rather expensive solutions. I don't think many people are willing to spend $50+ for a calculator <-> ethernet bridge. The focus should be on the cheapest solution possible.

Besides, if people are going to do online calculator games you are also going to want UDP Wink
Kllrnohj wrote:
KermMartian wrote:
But if there's already an embedded chip with a straightforward C or ASM programming language that already has a TCP solution implemented, it's not the end of the world to implement Cn2 on the device as well to build a bridge.


But now we are getting into rather expensive solutions. I don't think many people are willing to spend $50+ for a calculator <-> ethernet bridge. The focus should be on the cheapest solution possible.

Besides, if people are going to do online calculator games you are also going to want UDP Wink
Eh, with the speed of the calculator, I think I'm willing to sacrifice the low latency associated with UDP for the "guaranteed" delivery and in-order arrival of TCP packets.
440 bytes is better than nothing, no? And removing the menu options could save a bit more, too, as could removing the associated pictures. Should be enough space to add group selections, right?
yoman82 wrote:
440 bytes is better than nothing, no? And removing the menu options could save a bit more, too, as could removing the associated pictures. Should be enough space to add group selections, right?
Yeah, I should think so. If I had multiple selections adding like a "combine to group" option wouldn't be terribly much harder, either...
KermMartian wrote:
yoman82 wrote:
440 bytes is better than nothing, no? And removing the menu options could save a bit more, too, as could removing the associated pictures. Should be enough space to add group selections, right?
Yeah, I should think so. If I had multiple selections adding like a "combine to group" option wouldn't be terribly much harder, either...
You should have a group viewer much like the zip file viewer on the PC. ;D Just let groups act like folders and let you extract, copy files, or even run straight from the group with no writeback. Very Happy
Shock My brain hurts just thinking about all the kludges I'd need to put together to make that work.
KermMartian wrote:
Shock My brain hurts just thinking about all the kludges I'd need to put together to make that work.

Um BrandonW's Grouptool is Open source iirc so that would give you a good start.
I think that you shouldn't delete anything: 3 flash pages would be an acceptable size for the features that it'll provide...
And I think that you should concentrate on first removing the existing bugs before adding nex functions. For example, DCS crashes when it tries to launch a no-stub asm program.
*The group selection tool sound great though, as well as the group "unzipper"*
Certainly, that is a good plan; part of the problem is I need to de-kludge the whole program management system first, which is a bit of a headache considering I built it up over time to do a bunch of new and exciting things rather than designing it from the beginning to do everything it does now.
KermMartian wrote:
Certainly, that is a good plan; part of the problem is I need to de-kludge the whole program management system first, which is a bit of a headache considering I built it up over time to do a bunch of new and exciting things rather than designing it from the beginning to do everything it does now.
I agree, redoing file management and removing unused features (gCn) is a good place to start. Finishing runprog would be a help as then things like calcutil, noshell and msd8x could run DCS games. I think it would be a good idea to start with only the library calls and then slowly add in the features you want until you run out of room. you've already said they don't all fit on one page so whatever room you have left on the second page is for the ui and other features.
That group feature is a great idea. Now if only someone would finish up iPaint... *wink*
Are you currently working on this, or just brainstorming, Kerm?
TheStorm wrote:
runprog would be a help


I am too lazy to actually make my own post so instead I quote people and then don't say anything new
How difficult would program compression be to implement? Not exactly necessary, but a neat feature nonetheless.
yoman82 wrote:
How difficult would program compression be to implement? Not exactly necessary, but a neat feature nonetheless.


I don't think program compression would really help anything. It would slow down the loading of programs with minimal (if any) saving of space unless there is some super awesome way to compress ASM commands....
yoman82 wrote:
That group feature is a great idea. Now if only someone would finish up iPaint... *wink*
Are you currently working on this, or just brainstorming, Kerm?
Just brainstorming; as the first two weeks of the semester come to a close I suddenly find myself with way more than my original 18 credits of schoolwork, including lots of research stuff and my personal social commitments.
Kllrnohj wrote:
yoman82 wrote:
How difficult would program compression be to implement? Not exactly necessary, but a neat feature nonetheless.


I don't think program compression would really help anything. It would slow down the loading of programs with minimal (if any) saving of space unless there is some super awesome way to compress ASM commands....


actually....there are a few CrunchyOS programs that aren't available in other form for the 83+, and it would be nice to be able to run those. By those, I'm referring specifically to Joltima.
Doesn't CrunchyOS and OmniCalc both feature compression?
And: I can run Joltima, it's working fine. *using it now*
  
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
» Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9, 10  Next
» View previous topic :: View next topic  
Page 7 of 10
» 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

 

Advertisement