Re: 0.25k Programming Contest!

[iigs@wam.umd.edu (Geoff Weiss - The Doctor)]

heldon Simms <sheldon@netcom.com> wrote:
>I can see limiting code + static data to 256 bytes but are you
>saying that the program shouldn't be able to use any memory
>outside it's alloted 256 bytes? I think that is a bad rule. For
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Actually, that wasn't what I was inferring, but I do change my
mind agree on what you say here:  

>example I think that a program ought to be able to generate
>code at runtime that exceeds the 256 byte boundary. Also a program
>ought to be able to use as much space as it wants for data as long
>as it is generated at runtime and not part of the memory image.
>In other words, I mean that I think the best rule is that the
>static memory image that is loaded for execution must be less
>than or equal to 256 bytes, including code and data, what the
>program does at runtime is up to it.

I said previously:
>> Should we make any assumptions about the mode
>>the Apple is in when the program starts (i.e. 40 column mode,
>>80 column mode, HGR already set, etc...)?
>
>I don't think there should be any assumptions.

I disagree on this.  Say you are making a hi-res game and you tweaked it
so it was 259 bytes.  You could remove a JSR $f3e2 (the BASIC HGR routine)
and the program would be 256 bytes.  But to play it, you would have to
type HGR and then BRUN the program.  This would be unfair when compared
to another hi-res game which does set the hi-res screen within its
256 bytes.

>If IIgs programs are allowed, I can see this. For 8 bit machines,
>just don't make it a system program.

Geoff
-- 
email: iigs@wam.umd.edu    <a href="http://www.wam.umd.edu/~iigs/";>Home Page</a>