🚀 go-pugleaf

In article <2968@homxb.ATT.COM> twolf@homxb.ATT.COM (T.WOLF) writes:
>In article <149@jolnet.ORPK.IL.US>, rich@jolnet.ORPK.IL.US (Rich Andrews) writes:
><text chopped away>
>> Forget it....The atari is not multitasking, i.e., screen output to 3 or more 
><text chopped away>
>It seems to me that as long as none of the "uploadable" programs are used,
>multi-tasking isn't really an issue....but then, I guess it wouldn't be true
>620/630 emulation (it would be something akin to 'uw' for BSD systems.)
>
>-- 
>Tom Wolf
>Bell Labs, Holmdel, NJ			E-mail:  twolf@homxb.att.com
>
>(My employer doesn't know about these and other incriminating remarks)

Indeed, download emulation is a bigger deal than the multitasking
issue for a 630 emulator.  The 630 scheduler is non-premptive (from
a high-level view, the wait routine should be able to just locate the
next ready-to-run process, switch to its stack, and return).  An
"emulator" with local load instead of download might be a reasonable
way to go (thus avoiding the cross-development environment).

You could fudge on the download issue by returning "application
already resident" for applications available locally (dmdld won't
even look for a host binary) and "download protocol failed" for
applications that aren't.  You do lose command line arguments in
this scenario, but cached applications on a real 630 have to work
around this anyway since the stack is built at the first download.

Application loading would have to "stop the world" while GEM loaded
images, but this shouldn't be too bad considering that local disk
transfer will be much faster than RS232 download for all but the
shortest applications.

Let me know when you're ready to beta test your emulator!  :-)

  -- Brian Katzung  ...!laidbak!katzung