[SD] Re: Venus on all Z80 Ti's
[Next][Index][Thread]
[SD] Re: Venus on all Z80 Ti's
> > (more-or-less) the same shell header on all Z80 Ti platforms. The
> > differences are merely because of the (in)ability to start assembly
> > programs in the same way from the TIOS-prompt. The rest of the
> > header has a standard format.
> I have not seen a Z80 TI calc where you could not use the technique used on
> the TI82 to start an assembly program. On some calcs in does not makes snese
> to do it, but it should be possible.
> > On the Ti83+ and Ti86 "asm(prgm0" could be used. And on the Ti82/85 this
> > would be just "prgm0", where prgm0 is a BASIC program that enables the
> > 'hack', by overwriting the right TIOS pointers so the Venus-kernel gets
> > executed.
> Why not just include the BASIC code to start the kernel?
It might probably safe some space. On the other hand, having no prgm0 might be a bit more user friendly: no "freaking" programs on your calc.
> > finished. When
> > you crash back to the TIOS (via an "ERR:xxx" for example) the OS doesn't
> > know what to do with that strange 'gap' there, so sooner or later it will
> > become unstable and crash.
> If the problem is that an error can cause the calc to crash, then why not
> just install a custom error handler which moves the program back before the
> real error handler is started?
Venus moves all program data, including the size bytes, to the start of usermem. It updates all bytes in the VAT too. Actually Venus changes the order in which variables are stored in usermem, moving the executed program to the start. A consequence of this is that when a system error occures, no dirty ram is left behind. Installing an error handler to clean up ram is not necessary, because there is nothing to clean up.
It also allows for easy program write back, easy accessing TIOS variables, easy memory management,...
> > With the 'relocation-factor'-solution you normaly shouldn't have these
> > problems. I'm not shure if on the Ti85 (the only calc where they have
> > shells that behave that way) it doesn't crash because of the inability of
> > the OS to run assembly by itself and thus cleanup some things (maybe these
> > things [cleanup, etc.] are done by the Ti85 shells, and such create an
> > unstable environment when that's not done after quiting). BTW: I
> > don't have
> > a Ti85...
> If you do not move the program around you will not have the problems which
> some types of relocation can give you. It does however mean that all
> programs will be bigger and take longer time to start.
> > What would be great if we move the entier variable (including
> > sizebytes) to
> > the exec_ram, so when the program crashes back to the TIOS there won't be
> > problems because of the wierd 'gap' in memory.
> THe problem wiht moving the program to a specific location is that the
> memory layout is not the same on all calcs. So if you want to use the same
> location on call calcs, and want to be able run large programs, user mem is
> the only place available.
> > - Ti82 and Ti85 are still basicaly unknown terain for most ROMcalls (like
> > the needed _insertmem and _deletemem). Experiments with shells like this
> insertmem and deletemem are well known on the TI82, and using them on the
> TI82 or Ti85 is not a problem.
> > have only resulted in failure (I've heard). This might be because of the
> > TIOS expects the 'starter' (the BASIC prog that enables the 'hack') to be
> > in the same place as it was before the kernel/shell is run. Maybe
> For the hack to work the program started when you run the BASIC code needs
> to ne in a fixed location, but that is not a problem as all TI85/2 shells
> are made this way.
> > a similar
> > approach as with Venus-83 would be handy, 'manualy' changing the pointers
> > so the TIOS thinks it has reached the end of the BASIC prog and quits
> > (returns to the previous).
> Just doing a ret form the assembly program which was started by the BASIC
> code will cause the TIOS to return ot the home screen, as long as no strange
> things has happend to the mem.
Normally, when an assembly program returns, it returns to the BASIC program that executed it. Venus programs have one line of BASIC code (to execute the kernel). When a program returns, the TIOS would attempt to execute the "rubbish" after that line. To prevent this, Venus changes some pointers.
> > For the Ti82/85 different kernels for the different ROM version should be
> > made I think...
> The problem with that is that this would make it hard for people to get a
> copy of the shell (Not everyone has a link cable, and copying from one calc
> to another is done quite often).
> > - Another *problem* for the Ti82/85 would be that the Venus-program you
> > need to run is not the 'caller' (since the prgm0 is running when entering
> > the kernel), so you need to find out where the TIOS stores information
> > about the previous running BASIC-program.
> Why not use the same method as on the other calcs and have the BASIC program
> call the kernel directly?
> > - People are still being vague about assembly shells for the Ti73...
> The ROM is pretty much like the other calcs, and so is the memory layout.
> The only problem is to send the hack to the calc, since it does not support
> backups. This could be done by writing a flash application for it (if anyone
> knows how to do that, it should no be hard to make a shell).
>
> While this would make programing for several different calcs some what
> easier, it does not solve the problems of handling the differences between
> them.
>
> - How do you handle the differences between the ROMs?
> - How do you handle the differences in the memory maps?
> - How do you handle hardware differences.
>
> Dines
>
>
>
-----------------------------------------------------
Mail.be, Free WebMail and Virtual Office
http://www.mail.be
Follow-Ups: