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