toddpw@tybalt.caltech.edu (Todd P. Whitesel) (04/14/90)
wogg0743@uxa.cso.uiuc.edu writes: >As for Cary Farrier, he sounds pretty vindictive. If he wants to write a >DA loading NDA, let him see how easy it is. As for the integrity of >Apple's code--ha! If you all are so bright, how come I've got multitasking >(works perfectly on most pre-5.0 programs, still flakey with newer ones) >and they don't. Do it yourself first and then blame it on my programming. I assume you mean Leapfrog... When I ran that (ROM 1, 1.25 meg) it crashed right away. Any idea why? A working version of leapfrog would be great -- definitely worth $$$ to me -- especially if Soundsmith works with it. BTW, when is somebody going to write a Soundsmith background music CDA? Todd Whitesel toddpw @ tybalt.caltech.edu
dcw@lcs.mit.edu (David C. Whitney) (04/14/90)
In article <1990Apr13.193141.24356@laguna.ccsf.caltech.edu> toddpw@tybalt.caltech.edu (Todd P. Whitesel) writes: >wogg0743@uxa.cso.uiuc.edu writes: > >I assume you mean Leapfrog... When I ran that (ROM 1, 1.25 meg) it crashed >right away. Any idea why? A working version of leapfrog would be great -- >definitely worth $$$ to me -- especially if Soundsmith works with it. > >Todd Whitesel >toddpw @ tybalt.caltech.edu I got leapfrog to work just fine on my 3meg ROM 01. Actually, it worked only with programs that behaved themselves. There were only 2: Shrinkit and DIcEd. Wierdly, when I quit one program, they both quit - THEN Leapfrog crashed. If/when leapfrog works, I'll pay for it...definitely! -- Dave Whitney dcw@sun-bear.lcs.mit.edu ...!mit-eddie!sun-bear!dcw dcw@athena.mit.edu My employer pays me well. This, however, does not mean he agrees with me. I wrote Z-Link & BinSCII. Send me bug reports. I use a //GS. Send me Tech Info.
toddpw@tybalt.caltech.edu (Todd P. Whitesel) (04/15/90)
dcw@lcs.mit.edu (David C. Whitney) writes: >I got leapfrog to work just fine on my 3meg ROM 01. Actually, it >worked only with programs that behaved themselves. There were only 2: >Shrinkit and DIcEd. Wierdly, when I quit one program, they both quit - >THEN Leapfrog crashed. If/when leapfrog works, I'll pay for >it...definitely! If you mean P8 shrinkit, it's the culprit. ANY P8 program has to allocate all of bank 0 and that nukes any other applications' direct page and stack. According to mail I just received, leapfrog loads EVERY tool set into memory when it starts up, and if anything is not on the boot disk it bombs. Looks like I'll have to install Appletalk. There ought to be a way for leapfrog to figure out which tools are unavailable and then not ask for them, but the tool locator wasn't designed with that sort of bizarre situation in mind. oh well Todd Whitesel toddpw @ tybalt.caltech.edu
khorster@pro-graphics.cts.com (Karl Horster) (01/01/91)
As I believe with the multitasking on the GS, it can't be fully done, because when Apple made the GS compatible with the //e the disk controller ports and things like that had to be the same. And since they had to the same the Apple can only do one output and one input at the same time. So let's say you were running a BBS and you were playing a game. You couldn't have two disk inputs/outputs at the same time. Then there is the speed compromise, unless you were running a Transwarp or those experimental Rocket chips. And Prodos would most likely be completely rewritten to handle the inputs/outputs if something was workable. OR you could just plug in another coprocessor in slot 3 or something and work it through there....but that would lead to a lot of troubles...
gwyn@smoke.brl.mil (Doug Gwyn) (01/11/91)
In article <6639@crash.cts.com> khorster@pro-graphics.cts.com (Karl Horster) writes: > As I believe with the multitasking on the GS, it can't be fully done, >because when Apple made the GS compatible with the //e the disk controller >ports and things like that had to be the same. And since they had to the same >the Apple can only do one output and one input at the same time. That's a non-issue, since certainly there would be mutually exclusive access to system resources such as peripherals. All multitasking operating systems have to address this issue. MicroSoft Windows 3.0 is built around MS-DOS, which has similar characteristics as ProDOS, and it works wonderfully well.
johns@pro-library.cts.com (System Administrator) (01/12/91)
In-Reply-To: message from gwyn@smoke.brl.mil > That's a non-issue, since certainly there would be mutually exclusive > access to system resources such as peripherals. All multitasking > operating systems have to address this issue. MicroSoft Windows 3.0 > is built around MS-DOS, which has similar characteristics as ProDOS, > and it works wonderfully well. With all the talk of multitasking going on, is it going to become a reality on the GS? Please, please, say it is so. John
bazyar@ernie (Jawaid Bazyar) (01/12/91)
In article <1991Jan12.050921.1002@clark.edu> johns@pro-library.cts.com (System Administrator) writes: > >With all the talk of multitasking going on, is it going to become a reality >on the GS? Please, please, say it is so. It very well could be. The foundations have been laid for us by Apple. A brilliant operating system (GS/OS isn't perfect, but it's damn good). Bill Gulstad has been working on getting the tool sets to cooperate with each other in a multitasking environment, and he's got it 95% licked. All that stands in the way of a GOOD system is the MMU- and that's in the early design stages, right here on the Internet. It seems that everyone involved knows their beans when it comes to making a machine appear to run multiple programs at once. We're all pretty well educated, and since any problems we might face are strictly engineering tasks, we have a good shot at getting this thing going. Yeah, I'd say it's so. And a side note- in case you're all wondering, YES I've moved to my very own Sun 3/260 (well, it belongs to the dept....) I've forwarded my mail to the address listed in the Reply-To field. Please ignore the bazyar@chip address above. Just use the Reply feature of your newsreader to contact me. If you want to send mail directly, use the address in my .sig. -- Jawaid Bazyar | Being is Mathematics Senior/Computer Engineering | Love is Chemistry bazyar@cs.uiuc.edu | Sex is Physics Apple II Forever! | Babies are engineering
gwyn@smoke.brl.mil (Doug Gwyn) (01/13/91)
In article <1991Jan12.050921.1002@clark.edu> johns@pro-library.cts.com (System Administrator) writes: >With all the talk of multitasking going on, is it going to become a reality >on the GS? Please, please, say it is so. I haven't heard even a rumor of Apple working on it. If outside parties were to produce a good multitasking environment for the IIGS, which I think is technically feasible (a few hobbyists have been working on it), for it to attain any degree of commercial acceptance it would have to permit most IIGS applications that follow current Apple programming guidelines to work adequately under the multitasking system. (Of course, many existing applications access the "bare metal" in ways that are likely to interfere with any multitasking coordinator. Even many NDAs, which are supposed to take this into account, interfere with some "main" applications; anybody remember SytleWare's DeskPak? Will it ever be overhauled to work right with current GS/OS?) There was one such multitasking implementation posted to some computer information services, in a preliminary ("alpha test") form. I tried it and was amazed to find that it actually worked, sort of, although it wasn't sufficiently robust at that point to use for more than a demo. Note also that there have been a few Apple II emulations posted for use on (non-Apple) UNIX-based systems. Except for the slowdown caused by emulation, clearly in theory any sort of operating system could be implemented as an emulation of the desired behavior. However, for this to be practical on the IIGS, native code execution would have to be used for the bulk of an application, or in other words the multitasking OS would kick in only at the points where applications make toolbox or GS/OS system service requests. (That's how the demo I mentioned works.) There are several ways in which the tools and GS/OS could have been designed differently to facilitate such an approach, but we don't have the luxury of changing their interfaces now. My own IIGS system support projects for the near term are limited to making the ORCA/APW and GS/OS environments more nearly UNIX-like, so far as applications are concerned, to facilitate porting applications that were developed for UNIX systems. After that I would probably concentrate on cooperative multitasking systems, for example a NewSqueak interpreter. Such a system would support effective concurrency and intercommunication among the concurrent processes, but only if they were written and "compiled" specifically for such a target environment; existing IIGS applications would not be able to participate.