A83: Re: query and shell issue?


[Prev][Next][Index][Thread]

A83: Re: query and shell issue?




as for external levels being detected as assembly programs by a shell, the
best way to get around this (that I can see) is to have a detect string (for
your program to detect the level) at the beginnning of your level, and make
sure that the detect string is not going to be detected by the shell as an
assembly program.

-Dan


> >I should've made this more clear. You don't need dynamic memory
allocation
> >if you don't use multitasking because you can simply allocate all that is
> >free
> >at the start of the program... pretty simple.
>
> Yes?
> In total agreement here: use '_findfreemem' and create a program of that
> size, keeping in mind to delete it when you leave.
>
> However, 'if you don't use multitasking'....
>
> How *do* you use mulitasking. Do you mean: use write back on exit such
that
> your program continues from where you left of the next time its run? Or
have
> i completly missed the plot here...
>
> Also: Mild shell issue...
>
> This is wild, so bear with me:
>
> There is a bug in my current level editors (sorry, its pretty miner
though)
> but it got me thinking about the idea of levels.
>
> When i save a level it is a program which holds a set of bytes
(effectively
> storing a two dimensional array). Fine: nice easy idea.
>
> Now, how does a level set stored in a program differ from an executable
> program?
>
> Well, either it dossent have a loader program called RUNME or whatever,
> or it dosent have the necessary SoS, Ashell detection.
>
> How do we know it dosent *accidently* have Shell detection....
> In fact, Basic programs might *accidently* have Shell detection...
>
> As far as i can see: all you need is a single byte 'instruction' at the
> start. And some 'jump' instruction or somthing. (maybe joe could
> define this better ;)
>
> I messed about with this (using some very dogey methods) to produce
> *delibertly* an attached Basic program. This is detected in SoS...quite
> correctly!
>
> But as an assembly program. Not Basic....
>
> Most definitly BACK UP YOUR CALC before using this basic program
> with SoS - i have no idea of what it achually *does*...
>
> Do you get it? This example is silly, of course, but it does suggest that
> while we make programs *for* one format - we should also ensure all
> non-programs (game sets, graphics add ons..) do not get detected...
>
> Told you it was wild!
>
> Bill J Ellis
> ----------------------
> Bill James Ellis
>
> B.J.Ellis@hw.ac.uk
> http://www.cee.hw.ac.uk/~ceebje/
>
>
>
>
>
>
>
>
>



References: