A83: Re: Re: _insertmem (2) [83]


[Prev][Next][Index][Thread]

A83: Re: Re: _insertmem (2) [83]




> > Now I know how to invoke _insertmem (and _deletemem)...
> >
> > But what does it 'exactly' do? What I think it does:
> >
> > If there is a variable already at the pointer, it starts shuffeling the
> > variables till there is enough room there, then the VAT and a sort of
> table
> > where the free/used memory is noted are updated.
> > Can somebody prove my right or wrong?

> More or less you're right.  There are just a couple of clarifications
> that could be made.
> "If there is a variable already at the pointer, it starts shuffeling the
> variables till there is enough room there"
> ...I wouldn't call it "shuffling" around.  The RAM space is not like the
> 83 Plus archive space.

Don't know anything about the 83+ Flash archive but go on...

> All variables are stored sequentially in memory
> starting at $9D95 (or $9327 on the 83); there are no holes.  When you
insert
> memory, it doesn't have to rearrange the order of variables or anything,
it
> just lddr's all the RAM data after the insertion point (and before the
> floating point stack) forward a certain amount.  Also note that it
doesn't
> do any initialization of the data it moves, it literally just runs a
single
> lddr.

Okay, but what happens if you _insertmem a couple of bytes in the middle of
some free memory, does it allocate all space from the ending of the
variable-data to the place where you "insermem'ed"??? Or does it
crash/error, what ever.
BTW: I've read that on other calcs you can 'install' your own
error-handler, from the Ti docs in the internet I can read that it should
be possible Ti-83 too (they don't say it in a direct way, but something
like "We may talk later about errorhandling"). Is this true what I think,
and how should you do that???

> One other note about organization of variables in memory.  They're all
> located starting at $9D95/$9327 *only* when no edit buffers are open, and
no
> assembly programs are loaded.  On the homescreen (or when editing a BASIC
> program) all available memory is allocated (InsertMem'ed) into the
beginning
> of RAM ($9D95/$9327).  In these cases, variable data will start after
this.
> When assembly programs are running, it's the same idea (except only some
of
> the available memory is allocated, not all of it).

So all variables are stored at the end of your program when it is
running??? At least when you run your program from the TIOS, or Zasmload
(is almost the same), or Ion.

> Moral of the story: Don't try to InsertMem while an edit buffer is open.

This is only so if you make an interrupt prog (I think). Otherwise no
edit-buffers are opened off coarse...

> "then the VAT and a sort of table where the free/used memory is noted are
> updated."
> ...The VAT is updated with new data locations for variables that were
> shifted forwards.  What you should be aware of, however, is that
InsertMem
> does not update the size bytes of the variable you are inserting into. 
You
> must do this manually.

I know, AsmGuru told me, but you can't trust everyting that is noted there.
Most file-system-ROMcalls are incorrectly discribed, it almost always says
that you must use OP1, but most of the time you have to give a data-pointer
and symbol-table-pointer of the file you want to do something with...