Anyone ever going to add peek( and Poke( to TI-Basic through an app?

I believe that asapXCmd for the TI-86 does that ...

hmm peek() and poke(), that's a good idea. I'll consider it.

No no. not peek() and poke(), peek( and poke(...

Am I missing something?

We only need the openning parentheses with these commands.

I know, I'm being an ass.

I was telling Chickendude what he's missing, or something.

Couldn't poke( be just poke -- without the parenthesis? It seems that only commands that return a value need the parentheses, as in the example of PxTest( vs. PxOn. However, I don't know much about adding custom commands like this and whether they need parentheses and such.

Added functions must have parentheses as well as some argument. This is why the RestoreMem function has an integer argument, although it's argument doesn't matter.

*its

PxOn is actually PcOn(

At least on the TI-89/92(+) functions need parens but commands that don't return anything don't need them.

I think this is about user functions, not tios functions. As far as I know all user function in asm or basic still need the parenthesis. I don't know about flash-app extensions

whats peak and poke, i think i remember somthing like it in qbasic

"PEEK(address)" gets a value from memory at the specified address, and "POKE address,value" puts a value at the given address in memory. They're only needed in languages like BASIC and others that don't have pointer data types, like C or assembly.

cool, but those could make basic programs crash the calc

Sad but true: the wonders of low level programming.

OK, here's my 2 cents...

* z80(string) - Excecutes a string of Z80 commands, specified in hex.

* call(string,[program]) - Calls a specified label in the program (I think there was an ASAP version of this - it would be much nicer as a token)

* read(program,int) - retrieves data from a program file, at the specified address.

* write(program,int,int)

* ord(string)

* chr(int)

* indic(int) - sets the run indicator

* getarc(variable) - copies an archived variable into RAM

* runarc(program) - runs an archived program

* runapp(string) - runs an application (is this possible?)

* inputGr(x,y,[string],variable) - inputs a value in small font, on the graph buffer

That should be enough to be getting on with... :)

What would write(program,int,int) do?

prob writes data to a program file, at the specified address

i like all thoughs, but here are a few more:
pwroff() - turns calc off

delprog(string) - deletes a basic program

grphfrac(value) - display like >frac but on the graph screen

also, runarc() cannot work, even mirageOS doesnt do that, it copies to the ram, then deleats the copy. how would getarc() work? do you mean move a var to the ram because we already have unarchive, if you really mean copy, then you would have to have a new name for the unarchived var to separate it from the archived one.

runarc() could work as the TI-89/92+ runs archived programs. It makes a copy of the archived variable into RAM (but not as a new variable) and executes it. When the program returns, the temporary space can just be forgotten and/or released for other things.

<note>the rest is for everyone</note>

I'm wondering if someone (other than TI) could make an OS that is better than TI-OS and uses the archive space more like a hard drive on a computer. Then all programs will be stored in Flash ROM and copied to RAM when they run. This would be somewhat practical at least for the TI-89/92+.

I have a TI-92+ and used to own a TI-89 (until it got stolen...aaargh!), and I plan on getting another TI-89. Once I acquire one, I'd be willing to test new OS's <cough>Linux</cough> on my TI-92+ (and use the 89 for games and math, of course).

BTW, what's the current status on being able to put a new OS on a Flash calculator? Has anyone figured out how to put their own base code on them yet?

it doesent sound too hard, to do, even for the 8*, you could make a normal asm prog, except it would never return, and you could still turn the calc off by making an infinate loop of halts (with DI first) and then make an interupt to tell it turn back on when the on key is pressed

i think super mario does that

i think that omnicalc's base converter should beable to handel biger numberes... ZZZZ in base 36...

I'm talking about completely replacing the TI-OS in the Flash ROM. What we would need to do is find out how to make the current TI-OS accept the replacement OS. This is all from a TI-9x viewpoint; I don't know how the TI-83+ handles base codes (OS's).

For the TI-9x calcs, one could write a small and simple (relatively) program that will receive programs and, instead of writing them to RAM, will write them over TI-OS, thereby replacing the OS with our own!

So, has anyone written or is anyone currently writing a new OS for the calcs? There has been much talking but no doing. I personally would like to see more doing.

The 83+ OS upgrade file is simply Intel Hex format, the same as is used in application files. However, there's probably some sort of certification involved which would prevent the calculator from accepting non-TI code.

Even if we could work around the upgrade system, we are left with a greater problem: TI has never told us how to use the FlashROM. The 83+ (and the 73 for that matter) has some sort of hardware protection which must be removed when writing. The possibilities for writing a new OS would be rather limited if we had to use TI's code...

If we could get someone into TI's calculator division, we might be able to figure out how work with the Flash ROM ...

I hope you don't mind me still discussing the TI-9x calcs here. I have a TI-92+, I don't have a TI-83+, and most of what I write probably applies to both.

I believe with the TI-9x that you have to write some value(s) to RAM (or something), then the FlashROM becomes writable. I don't think there's some "secret" code that TI is holding back, other than the exact method for writing to the ROM. There are probably already non-TI programmers who know how to do it and such knowledge just hasn't spread around very much. I just need to read more about it and let everyone else know.

Could it be possible to send a base code to VTI and then open the debugger, or even reverse-assemble (gasp!) the TI-OS and trace through it to find where it writes to Flash? I think I'll try this with the TI-92+. If anyone else succeeds with the TI-83+, then post your findings! Let the truth be known!

there is a program that can do it
its dissassembler 1.7 under win/asm/
does it strait from the .rom

With TI's 83+ Flash Debugger, you can load an OS and check it out...

With TI's 83+ Flash Debugger, you can load an OS and check it out...

On the 83+ you've got to output a value to one of the ports, in order for the FlashROM to become writable. Problem is that the Flash chip only accepts this if the output instruction comes from one of (I believe) three specific ROM pages. So, at least for now, writing to Flash is impossible.
When you send a new OS to a calc, it will verify if it was approved by TI. The calc will only accept the OS if it is "signed" with a specific key (this is *not* the 0104 key). If you want to break this key, you'll need a HUGE amount of computer power. Once you succeed you'll want a lawyer to, because signing your own OS with this key is the same thing as forging a normal (pen and paper) signature.

There was a discussion on this at asm-83 in july 2001, you might want to look at that:

Enabling Flash writes: http://www.ticalc.org/archives/mail/
assembly-83/2001_July/msg00230.html

Customn OS'es:
http://www.ticalc.org/archives/mail/
assembly-83/2001_July/msg00236.html

(I know I should use the URL field, but these are just too long (the URL field cuts them off halfway), so just copy-paste them.)

If people know so much about this... how does TIOS do it? Because TIOS *does* do it. On those pages are routines which *do* write to Flash. All we have to do is work out how they work, where they're placed, and how they're called. Having done this, we merely need to, say, use code on page 1C to load our code onto 1D. Information on these routines, anyone?

No, there's nothing illegal because...

- You're not forging a signature, you're simply converting a program into its host system's native format. Since your calculator is programmable, one of your rights is to write programs for it.

- TI has no legal basis for preventing you from loading programs from your PC (which you legally own, and for the moment, are legally permitted to run programs such as TASM and TiLP on) to your calculator (which you also - presumably - legally own) and invoking said programs, so long as the programs themselves are not illegal. In other words, you own the thing, you can burn whatever you want.

- You are not infringing on TI's copyright to the OS (which people regularly infringe on anyway!)

- nor (I believe) their patents on the calculator.
This last, I suppose, is the only legitimate objection. But it's not as if you're selling an OS, nor are you performing any illegal circumvention, even under the multitudes of unconstitutional laws that have been passed in the past few years.

IM 2...
Make an a program that uses interrupt mode 2 and you could add those functions...

Here's another one: Inline If.
iif(condition, value1, value2)
returns value1 if condition nonzero, else returns value2.
Now, ideally, we would only *evaluate* the desired expression - so you could write something like iif(x=0,-1,1/x) - but you could fake it by writing this as expr(iif(x=0,"-1","1/x")).

Yet another addendum: call() and runarc() return the value that is in Ans at the end of the program. This would be useful, I expect, for many programs.

The 89 has a when( funtion that behaves like iff( as you describe. I think it evaluates only the condition and one other expression. This is like the C trinary operator condition?value1:value2. It probably wouldn't be too difficult to make.

That's just it: inline if would be incredibly easy to make in assembly, but in BASIC, it's very difficult, not to mention kludgy, slow, and difficult to read.