elf do you think you could convert a code for me from basic to asm?
Mexi1010 wrote:
elf do you think you could convert a code for me from basic to asm?
do you mean a program?
and Im gonna pass on that, I have my own projects and a shiteload of schoolwork, plus my eagle project, plus fundraising for various trips. sorry.
http://dragonfire.unitedti.org/asmin28/
ok i understand (im only a freshman and im going to have a censored of homework over the summer) (im going to princeton for a summer school program)
Mexi1010 wrote:
ok i understand (im only a freshman and im going to have a censored of homework over the summer) (im going to princeton for a summer school program)
I was a freshman when I started programming my calc....ah the memories. and I considered the princeton summer programs, but Im probably gonna be working at a camp in maine instead getting payed to take little kids camping
I started programming Christmas last year, I was in 7th grade. 
I still can't believe I lost my calc though.... And Spring Break is this week, so I probably will not find it =\
I still can't believe I lost my calc though.... And Spring Break is this week, so I probably will not find it =\
Any fool can use a computer. Many do.
Oh, god! 
I thought the project was given up because there was no update in the CVS and that you were not on efnet...
I'll start up again.
I thought the project was given up because there was no update in the CVS and that you were not on efnet...
I'll start up again.
elfprince13 wrote:
will LIFOS be able to utilize the extra pages on SEs? (both RAM and archive)
Quoted for emphasis.
@ Kllrnohj 
KermMartian wrote:
elfprince13 wrote:
will LIFOS be able to utilize the extra pages on SEs? (both RAM and archive)
Quoted for emphasis.
@ Kllrnohjstupid quoted for emphasis bullshit
<insert 'find rant -author kllrnohj -topic quoted'>
Kllrnohj wrote:
KermMartian wrote:
elfprince13 wrote:
will LIFOS be able to utilize the extra pages on SEs? (both RAM and archive)
Quoted for emphasis.
@ Kllrnohjstupid quoted for emphasis bullshit
<insert 'find rant -author kllrnohj -topic quoted'>
Archive pages, sure, RAM pages, probably.
I could probably pretty easily implement something like Omnicalc's RAM recovery, and maybe use the additional RAM for a 'debug mode', etc. It could also just be used as volatile archive, too, but that might not be a great idea.
I could probably pretty easily implement something like Omnicalc's RAM recovery, and maybe use the additional RAM for a 'debug mode', etc. It could also just be used as volatile archive, too, but that might not be a great idea.
Such things would need to be implemented with apps, not in the main OS.
If you need a little clarification, I'm basically stealing the idea of Vera, making some changes, and actually writing the thing. To quote jim e,
The base of our system should be the drivers, code that communicates with the hardware. LCD, Link, key, interrupt, Flash, status, and file management. It should have the most basic support, Not optimised for speed but rather security. (We can leave the speed optiness for game coders : ) ). How the memory is used shoud be set in stone.
Above that should be internal functions. Programs that are absolutely needed for function of the command line. Most of these should be utilities seen in other cli os's. Such as creating a file, deleting, altering, handleing input, praseing and passing arguments, a prompt(text input), and other things I maybe forgetting.
Plugins should consider more advance than traditional hooks or apps. They should be INSTALLED, meaning the intention is to have them remain for a long while. They are OS extensions, not happy fun time programs, they should become a part of the os. As for calls to their functions, an external program would merely declare that plugin as being a dependant, and it could then access those functions(say by bcall). So in other words, just because 2 plugins may have similar purposes doesn't mean one would be mistaken for another.
Hooks should be within plugins, they should occur at certain points in most internal functions. That way if they are meant to replace an internal function they can by going before and then return tell that function to stop, or if they are meant only to augment, they can and tell the function to continue. Internal functions that should not have hooks are the flash routines as that poses a serious threat. Installing a hook on another plugin's functions can be handle somewhat by the os but not enitrely. It would be up to the plugin coder to decide the limit of it's extendablity.
The final layer in our architicture should have the least athority, apps and programs(if those would exist). Stand alone programs meant to execute, do it's jobs, then terminate.
Basically the same idea as LIFOS, except the only 'app' that the system recognizes as special is the ' HOME' app, which is executed at boot time. Libraries and such act pretty much as written, but don't get registered with the OS as such, and are specified by name and the dep() macro.
If you need a little clarification, I'm basically stealing the idea of Vera, making some changes, and actually writing the thing. To quote jim e,
jim e, about Vera wrote:
The base of our system should be the drivers, code that communicates with the hardware. LCD, Link, key, interrupt, Flash, status, and file management. It should have the most basic support, Not optimised for speed but rather security. (We can leave the speed optiness for game coders : ) ). How the memory is used shoud be set in stone.
Above that should be internal functions. Programs that are absolutely needed for function of the command line. Most of these should be utilities seen in other cli os's. Such as creating a file, deleting, altering, handleing input, praseing and passing arguments, a prompt(text input), and other things I maybe forgetting.
Plugins should consider more advance than traditional hooks or apps. They should be INSTALLED, meaning the intention is to have them remain for a long while. They are OS extensions, not happy fun time programs, they should become a part of the os. As for calls to their functions, an external program would merely declare that plugin as being a dependant, and it could then access those functions(say by bcall). So in other words, just because 2 plugins may have similar purposes doesn't mean one would be mistaken for another.
Hooks should be within plugins, they should occur at certain points in most internal functions. That way if they are meant to replace an internal function they can by going before and then return tell that function to stop, or if they are meant only to augment, they can and tell the function to continue. Internal functions that should not have hooks are the flash routines as that poses a serious threat. Installing a hook on another plugin's functions can be handle somewhat by the os but not enitrely. It would be up to the plugin coder to decide the limit of it's extendablity.
The final layer in our architicture should have the least athority, apps and programs(if those would exist). Stand alone programs meant to execute, do it's jobs, then terminate.
Basically the same idea as LIFOS, except the only 'app' that the system recognizes as special is the ' HOME' app, which is executed at boot time. Libraries and such act pretty much as written, but don't get registered with the OS as such, and are specified by name and the dep() macro.
Sure I could, but that's mostly a matter of building little programs to test my routines. A full-blown app wouldn't allow the most important testing of variable storage and memory usage schemes, and the important but little stuff like display routines don't require much debugging.
What I meant was when the basics of the os were complete you could us it like a shell so you could still us the TI-OS for stuff like homework
@Tari aren't you still grounded from the computer i was going to suggest this to you in class tomorrow
btw yes i will help with lifos any why i can even though i don't know asm
@Tari aren't you still grounded from the computer i was going to suggest this to you in class tomorrow
btw yes i will help with lifos any why i can even though i don't know asm
Register to Join the Conversation
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
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