Re: SD: Shells on the 83+


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

Re: SD: Shells on the 83+




Actually, don't almost all programs call an update function that's built
into the shell, like ionFastCopy?  I think that a few games like Tunnel used
the ports directly, but that was when asm coding first came out on the 82
(ah, the good 'ol days).  So the shell would take care of this.  On the 86,
it would be easier, because you could just change the display memory port,
but this wouldn't work with grayscale and the few other programs that move
it.

But seriously, people, the idea of doing this on a calculator is quite
silly.  The majority of the people who use calcs don't even know how to send
programs to another calc.  And even with many cool games, they only play
ZTetris or Nibbles.

Not to insult anyone, but it appears that the majority of the people who
want to do this have little or no experience with Z80, or with calc
programming.  The people who could and have done this (Clem) do it because
they get bored one afternoon and decided to code something cool.  They don't
try to make up standards and terms and all this.  That's crazy.  It's sort
of like what John Carmack said when he went off about VRML.  Something to
the extent that it totally sucks now and is virtually unusable.  Code
something cool, he said, then come up with standards later.  Heh, Quake
could be a great 3d content engine for the internet, especially considering
it's out for every major platform.  The Quake engine as an ActiveX control,
now that would rule.

But anyway, my point is that if you are capable of coding it, then code it.
If you have to discuss every aspect of it, then you need to gain some more
skills before you think about anything this complex.

>
> OK, first of all, having to allocate data space at the end of every
program would be a hassle for most programmers,
> which means that you wouldn't get very many supporters for your shell.
Secondly, you'd also have to convince every
> programmer not to use direct screen writes and make your shell control all
of that instead. So a program would call your
> display function, and if it is the current foreground process, the shell
will update the screen from graphbuf. Your
> shell will also have to wait for the display routine to finish before
switching to another task. It is possible, but it
> would be very messy to implement. You'd also have to rewrite the handful
of programs that use direct screen writes
> (SQRXZ comes to mind, and possibly Galaxian?).




Follow-Ups: References: