Re: SD: Shells on the 83+
[Prev][Index][Thread]
Re: SD: Shells on the 83+
I don't need to discuss every aspect of it, I was mearly responding to peoples
replies. I have already started coding TSE, discussion here can stop until I
release a beta. Direct screen writes can be done as long as you surround them
with di and ei, it's just a little more complicated becuase you have to handle
the screen being blanked by the task switcher. I havn't seen a single Ion game
that used direct screen writes (of those that come with src, though I havn't
looked at that many.) I have had a lot of experience with the z80 (embedded
hardware, long story...), just not with TIs hardware. Well, we'll see if TSE
comes to anything... That's all I'll say for now.
--Robin Kay--
David Phillips 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?).
References: