Re: SD: Shells on the 83+
[Prev][Next][Index][Thread]
Re: SD: Shells on the 83+
There is a new shell coming out for the 83+, and it
will rock the 83+ community. That's all I can say...
--- David Phillips <david@acz.org> wrote:
>
> 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?).
>
>
>
>
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com