Re: LZ: Programming
[Prev][Next][Index][Thread]
Re: LZ: Programming
>>> ... and only stored the actual
>>> stuff you typed for label names, the size of source
>>> problem would diminish.
>> Someone please write it. The 86 and the ExpanderSF make this
>> practical.
>
> One problem. If it crashes there's no way to resend ZShell from the
> ExpanderSF. It's a good idea in theory, but I don't think that anyone
> will ever write a perfect program the first time. If anyone ever does,
> either they're lying or it was too simple of a program to begin with. If
> there is a way to catch progs that will crash the calc _BEFORE_ it
> does(and terminate it, prompting first:-), that's something I'd like to
> see(like a TSR to halt crashing code). This may be too big to be
> practical, but it might be worth looking into.
True. I didn't mention why I wanted it. It turns out, us HAL programmers are
planning on rewriting HAL _IN_ HAL. That means, HAL for the calc! So you're
sitting in math class and you get an urge to program. Your only option-
basic. It's too hard to program in asm on the calc. Most of us have tried.
But with HAL on the calc, you can program your heart out with the ease and
accuracy of basic and the power of asm.
Estimated memory requrements of all HAL components- 40-60k.
We haven't even started writing yet, so don't start looking for another year
or so.