Current Progress?

[Adm.Wiggin]

or, we could do these keystrokes at the start of the program :
1. Rcl
2. [PI]
3. +
4. Rcl
5. [e]
6. ->
7. N

ok, so it might be a little work, and be long and evil to try and code the checker... i vote we just do something like that 124->N thing suggested...

[62 52 53 53]

but that interupts vars! how about 124->LNIM(1):DELVAR LNIM

[NETWizz]

How about we make it simple like this

:! hidden

:: mirage

::"COMMENT mirage

[Adm.Wiggin]

ok, but it may take a while to get to the ! for some people... maybe something like :* or something... maybe :@ then only people with the TI-Keyboard could make a hidden one

[NETWizz]

nah,

you can do it without the ti keyboard.

Make a new asm program with nothing except the hex value of the @ character.

I.E.

AsmPrgm
41

Then compile it.

AsmComp(prgmNEW,prgmZNEW

Now unlock it with a shell, or whatever and you will have a character in there.

In this example 41 is hex and represents an A, so all you have to do is look up the hex code for @ in ascii.

[anduril66]

Hey, are you still adding features to NimbusOS? I would add the Str1 asm encryption program by David L as a feature of the app. It's small and very good, but I don't really like things lying around on the program menu.

[Toksyuryel]

[GuillaumeH]

Hi everybody !

I hope I'm not asking this too late : please consider the easyness of programming at the same time for ti82/83(+) when developping NimbusOS.

In fact, I'm just asking one thing : please make in sort that NimbusOS doesn't restrict anything more than MirageOS, like saferams, or particular features of the TI-OS. MirageOS already requires to disable the interrupts to use StatRam.

It would be a real mess in programs developpements if there were one more restriction to take in account...

The best thing would be that (contrary to ION and MirageOS) NimbusOS doesn't use text_mem2 (also called cmdShadow) when it launches NimbusOS-only programs. If there is this feature, I will probably recommend to use NimbusOS in my FAQ (see my sig) on TI-83+ both for programmers and for users.

Good luck.

[Adm.Wiggin]

uh, you cant have apps on a TI-82... NimbusOS is an app... Programming for both at the same time wouldnt work here... but i know what the other part you are asking is... it is a good idea, Jbirk, SO FAR, how many/what saferam locations does Nimbus need unchanged?

[David]

NimbusOS currently uses the CmdShadow area for internal storage. Guillaume, why do you consider that as undesirable? Both ION and MirageOS uses it for the same purpose, so I think it's clever for NimbusOS to follow the flock unless you have another good rarely used saferam location that I haven't heard of...

Nimbus needs to save the program name and the current position in the program list, that is only 10 bytes. Later on, not in App 1, there will be an increased need of internal storage space, especially if we choose to have an interrupt tasker, but we will try to keep things minimal.

[GuillaumeH]

[David]

Why is statVars to prefer over CmdShadow?

[GuillaumeH]

Currently, if one wants to use TEXT_MEM2 on TI82 and CmdShadow on TI83, (s)he also wants to have 128 bytes of saferam on TI83+, but (s)he won't be able to do it with cmdShadow because of the libraries vectors. So (s)he will have to use Statvars, but is is a waste because (s)he will only use 128 bytes on 531 bytes.

So if, for its own programs, NimbusOS uses StatRam for its own vectors and other temporary stuff, it will have more space than with cmdShadow, while the programer will still have 128 free bytes to use in cmdShadow.

[David]

Ok, so it is for the lazyness of those who port TI-82/83 files to NimbusOS we should use StatVars?

"So (s)he will have to use Statvars, but is is a waste because (s)he will only use 128 bytes on 531 bytes."

Then I consider it a waste to use StatVars for internal storage as well!

[AlienCC]

One mans laziness is another mans genious, One mans waste is another mans treasure.

Any one who may be interested in porting a program I wrote for the Ti-82(asm) to the Ti-83/83p(asm) please contact me.

Oh, and good luck with Nimbus, its very impressive so far.

--AlienCC

[David]

Lol :)

Since NimbusOS APP1 doesn't have an own program format, we'll wait with the decision on what RAM areas NimbusOS should use. APP 1 however uses the CmdShadow and copies it to Appbackupscreen during TI-BASIC parsing since these progs usually destroy the CmdShadow.

Aliencc, what program do you wish to have ported?

Oh, and thanks for wishing us good luck. My strategy is
First complete the website, then NimbusOS.
Oh man, it has been delayed for one year soon!

[AlienCC]

Thanks, but someone has already shown interest in porting it...I'd like to wait a while and see how that goes before announcing which program to prevent the duplication of effort.

--AlienCC

[NETWizz]

I would really like to write the NimbusOS Task Handler in App 1.

I know quite a bit (no pun intended) about IM2, and I am assuming that killing a program would be easy.

Essentially, The task handler would do the following:

1. Check what page assembly is being executed from
2. If code is being executed from somewhere other than ram, we can assume the calculator is busy with a bcall, and display a popup informing the user that the program is currently in the process of a system call.

The user will be given three options:
1. Wait (each time the interrrupt runs it will check the page until in ram then finish the kill).
2. Force kill regardless of page (IE, nimbus changes the page back to ram and we hope the call has nothing to do with writing to the archive)
3. Cancel


Assuming the program is in ram, killing a program should be relativly easy.

Steps:
1. Reset system flags to state before the program was executed
2. Reset the stack to the correct point
3. Ret (Assuming the correct exit address is on top of the stack this should end it)

If the program is writen in basic:

1. Set a specific flag that tell Nimbus's error handler not to report any errors.

2. set an on interrupt to be intentionally caught by the NimbusOS error handler

3. Next the error handler will return to Nimbus without displaying the error.

As for saving pictures of programs, we could ask the user what picture to put it in, or ask the user to provide an appvar name for us to compress a picture too.

(We could use David's RLE routine he has previously written)

As for the other stuff, I do not see a problem with turning off the calculator from the task handler, but I really do not think we need an option to exit to TI-OS. If the user wants to do that, they can exit then press one key to exit NimbusOS. That can be done very fast.

Lastly in adition to the force kill I talked about above, we should have an option to "Kill Nice"

Kill Nice would work like MirageOS's kill in that it would jump to a label in the program provided by the program's header. Essentially, this would let the program do some clean up; however, this option would be cooperative because all we essentially do is tell the program to exit NOW.

Either way, if Kill Nice doesn't work, the user should still have the option to be agressive by resetting the stack and forcing a jump.


Laslty,

Instead of holding ON and pressing a key, I think it would be better to tap ON once and have a menu pop up. The user could use the menus and then if they wish to continue, tap on again to resume the program.

When pressed, the interrupt could go into a loop where its menu is displayed. In this loop, it will test for ON, and if that is pressed, it will exit and resume normal operations.


What do you think?

[Adm.Wiggin]

well, the only problem with the ON thing is that some asm programs use on as a function key... other than that, it is great!

[NextPerception]

is nimbusos still on schedule for app 1 being released at christmas time?