[SD] Re: Venus on all Z80 Ti's
[Prev][Index][Thread]
[SD] Re: Venus on all Z80 Ti's
> Van: Dines Justesen <dines@aub.dk>
>
> > (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.
What's the point? Off coarse it can be done. I wasn't sure, but I thought
it would be strange if Ti didn't use more or less the same technology on
the different calcs. What would it help, other than the primary header-part
also being the same, and needing to waste some valuable vars when it's not
really needed for assembly execution?
> > 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?
I wanted to keep my description simple, I had just found out how the hack
globaly works on the Ti82/85 so I didn't know how big the 'starter' actualy
is... Putting that (maybe 'big', let's say 10 bytes) BASIC code into one
variable could be handy I thought. But if it's small sized I don't have nay
problem with including it inside every program.
It would probably be something like "xxx->[B](x,y):getkey" (where xxx is
calculated FP-number), but well I wasn't shure.
> > 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?
As far as I know the errorhandler needs to be on top of stack (uhm, at the
Stack Pointer). When you call/push something, the error-handler won't
work...
> > 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.
Indeed. That's what I would like to avoid, since the memories are small of
the Z80 Ti calcs. Plus I don't think relocation on a Z80 platfrom is that
tremendous, more something like a 'gimmick' and only usefull when you can't
do it another way.
> > 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.
Did I say that I want the same originate on all calcs? Okay, maybe I should
have explicitly said that I didn't want to create cross-calc executables...
Just "making life a little easyer" similar to Ti83+ Ion programs that just
need to be reassembled for the Ti83(-) to also work on that calc, as far as
not too low-level things are going on.
> > - 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.
Okay, I heard people saying that before, but I've only seen 82-rom.txt and
that's about ROM 19.0...
What I've found there:
_insertmem = $2272 ; HL = number of bytes ; DE = pointer
But if you could point me at some more docs, would be handy.
> > 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.
I was thinking to keep the shell is some space like the stack, but that
might not be (directly) adressable by the hack? Could off coarse be done if
you have two vars, one with the pointers changed, and one with the content
changed. Or keeping an (adressable!) JP to the kernel.
> > 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.
Nice :-)
> > 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).
Okay, get it...
> > - 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).
Okay, so that's going to take some time, since Ti still keeps the Ti73
Flash-app-key. Ah well, never mind...
> 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?
Assembling with a bcall(xx) macro could be done:
- on the Ti83/86 it would translate to a normal "call xx"
- for the Ti83+ a "rst 28 / .dw xx"
- and on the Ti82/85 a "call vnROM_CALL / .dw xx" (or whatever).
> - How do you handle the differences in the memory maps?
different include-files...
> - How do you handle hardware differences.
Well, that's something I can't do much about, only things like creating
some programs that will make these difference less prominent if you don't
acces the hardware directly, if somebody would like that. (don't think so,
but...)
Henk Poley <><