A82: Re: Fw: Proposed open operating system/gui/shell (CalcOS-82,83,85,8
[Prev][Next][Index][Thread]
A82: Re: Fw: Proposed open operating system/gui/shell (CalcOS-82,83,85,86)
>>Libraries has been tried on the TI85 and the authors of the shell found
out
>>that it was a bad idea, and therefore they removed them from the shell.
>>Libraries are nice for programmers because they make it easier for us, but
>>most users do not like them. Th reason for this is that you need a lot of
>>variables on your calc to run one program and that it is too complicated
to
>>remember which libs goes with which programs.
>Well, users have to decide. Do they want more programs (because libs make
>it easier for programmers), smaller program size (because of lib sharing,
>a.k.a. a greyscale graphics lib could be shared among 3 programs that use
>greyscale graphics instead of having 3 copies of almost identical code) or,
>do they want to have less variables on their calculator? Seems to me, the
>first two are what everyone keeps asking for (more progs, smaller size).
I know why libs seems like a good idea, and as a programmer i would like it
too. But as i wrote, it has been tried on the TI85, and the users decided
that they did not like libs even if it made the programs smaller. It is
possible to make a functions library like the one Usgard uses, this way
programming is easier for the programmer and the user does not have to deal
with libs. So what i am saying is that it has been tested and found out that
it was not a good idea.
>
>>Another thing you are suggesting is multitasking. You have to remember
that
>>this is a calc, with a small processor and a limited amount of ram. The
>>question is do we need multitasking ? are we willing to use some of the
RAM
>>for a feature like this ? My answer is no.
>I am not saying that it should be preemptive multithreaded multitasking! I
>just ment the ability to have multiple tasks (most likely, not more than 3)
>to perform different parts of a program (message handler for windows-like
>apps, or a keyboard handler for a game, things like that). I didn't mean
we
>should have Windows 95 like multitasking!
I am noy suggsting you make preempetive multithreaded multitasking, i just
think that for a Z80 based calc with 32K of ram no kind of multitasking OS
is a good idea (or at least i have seen no ideas on how this would work in a
good way). As with the libs this has been tried on the TI85 too. Instead of
being a part of the shell it is now a fak library which programmes can use
if they want. This seems to work fine and is probably the best way to do it.
>
>>You say that you want the the OS to work on all calcs, but it seems like
>you
>>have not thought about (or do not know about) the problems with all this.
>>One of the big problems is that not all functions found on one calc has
>been
>>found on the other. I am currently working on finding these functions on
>>both the ti85 and the ti82, but it takes time. These problems would have
to
>>be solved before you can make your OS work with all the calcs, and since i
>>am (as far as i know) the only one working on this it might take some
time.
>>So you would probably endup with a OS for the TI82 which could not be
>ported
>>to the other calcs with out chaning the rom calls, and then people would
>>have to make seperate version of their program for each calc anyway.
>There would be one copy of the OS for each calc (with the ROM calls for
that
>calc built-in). Then, the programs would be portable (probably would need
>to be put in different files for different calculators 82p, 83p, 85s, 86p)
>but the programmer wouldn't have to go through and change nearly every line
>in the code just to re-assemble for another calculator. It would be nearly
I have ported programs from other calcs to the TI82, and it is no problem at
all except for one thing, the graph functions. The only thing you have to
change is ram addrs in the system part of the mem which is written as
addresses. This is very simpel, just search and replace. The only real
problem is the functions dealing with the display, and i have seen no one
who have had a solution to this problem.
On the TI82 you can use GRAPH_MEM and $8228 for graphics/data. On the TI83
you have this and the stat vars. On the TI85 however you do not have the apd
buffer or the stat vars. So unless your OS uses part of the user mem on both
the TI82 and the TI85 it is not possible to use all the buffers for data.
Another problem is the size of the display, and how this is handled when
using the GRAPH_MEM. If a program wants to do graphics (full screen on a
ti85) using the GRAPH_MEM it will need a buffer which is 1K. On the TI82 and
TI83 the buffers are only 756 bytes. How will this be handled ? The only
solution as far as i can see is to place the buffer in user mem. This menas
that your OS will endup having buffers in users mem on all calcs.
Yet another problem is that on the TI83/2 the fastest way to do graphics is
to write directly to the display controller, and this is not supported by
the TI85. As far as i can see the only way to solve this is to make sure no
program uses the display controller directly.
In some programes the contrast i changed, but this is done differently on
the TI83/2 and the TI85. The onyl way i can see you can solve this is by
including a function in the shell, which will make the shell bigger.
When we are talking about graphics there is one more thing which i fell
should be discussed, and that is greyscale. The TI85 supports greyscale by
moving the display mem around in the mem ( which is not possible on the
TI82/3). The Only way to do greyscale on the TI82/TI83 is by constantly
rewriting the displayed image, this causes a lot of flikering which makes
the images look bad. Because of the way the display controller handles block
writing the images on the TI82/3 would have to be stopred differently than
on the TI85 (otherwise it would get even slower on the ti82/3). This menas
that you cannot use the same rutines for greyscale on the ti82/3 and the
ti85. So all rutines dealing with greyscale would have to be included
(including pixel on/off/test, lines, sprites ...).
>the equivilant of different ROM versions, just the ROM versions are on
>different types of calculators. I mean, that is essentially the only
The functions used on the TI83 and on the TI85 are not the same, and since
the functions used on the TI83 is not documented on the TI85 you will either
have to document them all or force TI83 to stop using most of the functions
which they are currently using. Another thing is that the functions used on
the TI83 is placed on page 4?, which means that the asm program can not
change rom page if it wants to use the rom functions. On the TI85/2 however
the rutines are placed on page 0, and a lot of programmes changes rom page
bacause they use FIND_PIXEL. So the difference between the rom on different
calcs is a lot bigger than between rom versions. And as far as i can see you
would also have to include FIND_PIXEL in the OS.
>difference between the calcs (there are only minor differences in
hardware).
Yes, the differences are small, but how would you handle them ?
>The only big problem would be in deciding how to handle the different
screen
>size of the TI-85.
I think that there are many problems with this type of shell, and this is
just one of them, but as i discribed above it is not very easy to solve.
>
>>You also write that you want your OS to be small. The OS you are writing
>>includes more functions than Usgard and alot of people think that it is
too
>>big. So what makes you think that people will like your OS which is even
>>bigger ? Again you have to remember that these calcs only have 32k of mem.
>Ahh... another reason for libs. The user (and programmer) can decide which
>libs they will need for their programs and then load only those. If a lib
>is found to be only of limited use (or none at all), no programmers would
>make programs that use them and no users would have them on their calcs
(and
>then, in the next version, we would probably remove them).
What i am talking about is that many things which are used by almost all
programmes would have to be included in the OS, and this means the libs wont
help (since everyone will need them). If you have a look at the things i
mentioned above you will see that these are commonly used functions, and
they all need to be in your OS.
>
>>As far as i can see you are missing some of the important features of a
>>shell in your OS. First of all i think tha it s very important to support
>as
>>many rom versions as possible and i know of 3 which are not yet supported
>by
>>a shell. Besides that several rom calls which could be very useful has not
>>been added in any shell yet because they lack documentation.
>As of now, there are enough known ROM routines to do the basic things
needed
>to create a program (or else there wouldn't be any!) like drawing text,
>creating pixels on the screen, etc. As more advanced functions are found,
>they can be added in libraries (i.e. a floating point library as the
>floating point functions are more documented, or a variable library for
>accessing variables, lists, etc.)
The variable functions on the TI82 and the TI85 are different in several
ways, and the possible names of variables are different too. So even if you
know the functions on all calcs, it will be hard to make a lib which can be
used on all the calcs, and it will take up more space then if only on calc
type was supported.
The FP functions is yet another problem. They are different on the TI85/2
and the TI83, so for all these functions you would need yet another lib with
even more code. Besides that there is the problem that the reals on the TI85
is bigger than on the TI82/3, and the the exponent is written differently.
Besides the problems mentioned above there is another thing which i would
like to hear how you will handle, and that is the system memory. The layout
of the system memory is not the same on the different calcs, which will
cause some problems for the programmes trying to acces the system memory.
How are you going to handle this in an OS which will work on all TI8x calcs
?
>
>Thank you for your feedback (or flame whichever the case may be :-) ),
>
This is in no way meant as a flame. After reading your ideas for a new shell
i just thought of so meny problems which you would have to deal with, and
some of the i wrote to you. The idea of this was to make people who want to
work on a project like this aware of some of the problems they will face if
they decide to go a heade with the project. I am not saying that it is
impossible to make an OS like that, but as i see it you will hve to solve
alot of big problems to make it work. And if it works the programmers will
still have a lot of trouble making the programmes work for all calcs.
I think that the best thing would not be to have an OS which could run the
same programs on all calcs, but have the same OS for all calcs. This would
mean that you would have to recompile the things wou wrote for the different
calcs, but that the same things where supported by the OS. This would make
it easier to convert programs, and it would not make it harder to program
for the OS.
Dines
Follow-Ups: