ecf_emeb@jhunix (Mark E. Bouver) (02/09/89)
Hello,
I am looking for an AT&T 620 or 630 emulator for the Atari ST.
Specifically, I want it to emulate an XT windowing terminal for use
with the layers pacakge. The Atari's GEM interface should lend itself
well to this task, I would think.
I would also appreciate any information on the actual protocol that
layers expects from the terminal, as I would be more than willing to
write my own emulator if one doesn't already exist.
Thanks, and Happy Computing!
Mark
******************************************************************************
** BITNET: INS_BMEB@JHUVMS, INS_BMEB@JHUNIX, P99I0620@JHUVM **
** ARPANET: ins_bmeb%jhunix@hopkins.ARPA, INS_BMEB%JHUVMS@HOPKINS.ARPA **
** UUCP: { allegra!hopkins, inhp4!whuxcc } !jhunix!ins_bmeb **
** **
** "The meek shall inherit the earth. The rest of us will go to the stars." **
******************************************************************************rich@jolnet.ORPK.IL.US (Rich Andrews) (02/11/89)
In article <689@jhunix.HCF.JHU.EDU> ecf_emeb@jhunix (Mark E. Bouver) writes: >Hello, > >I am looking for an AT&T 620 or 630 emulator for the Atari ST. Forget it....The atari is not multitasking, i.e., screen output to 3 or more windows at once, so the limitations are too great. To do a true 630/620/615 emulation, you would have to re-write GEM. The protocol is a bit complex and requires special drivers to work. It would be easier to write a unix for the ST. -- Any opinions expressed are my own. Now, for a limited time, they can be yours too, for the incredible price of only $19.95. Simply send $19.95 (in Alterian dollars) to ...killer!jolnet!rich or rich@jolnet.orpk.il.us.
fst@mcgp1.UUCP (Skip Tavakkolian) (02/12/89)
In article <689@jhunix.HCF.JHU.EDU>, ecf_emeb@jhunix (Mark E. Bouver) writes: > Hello, > I am looking for an AT&T 620 or 630 emulator for the Atari ST. > Specifically, I want it to emulate an XT windowing terminal for use > with the layers pacakge. The Atari's GEM interface should lend itself > well to this task, I would think. > I would also appreciate any information on the actual protocol that > layers expects from the terminal, as I would be more than willing to > write my own emulator if one doesn't already exist. > Thanks, and Happy Computing! > Mark > ****************************************************************************** > ** BITNET: INS_BMEB@JHUVMS, INS_BMEB@JHUNIX, P99I0620@JHUVM ** > ** ARPANET: ins_bmeb%jhunix@hopkins.ARPA, INS_BMEB%JHUVMS@HOPKINS.ARPA ** > ** UUCP: { allegra!hopkins, inhp4!whuxcc } !jhunix!ins_bmeb ** > ** ** > ** "The meek shall inherit the earth. The rest of us will go to the stars." ** > ****************************************************************************** I've heard that one of the universities had done a port of the Blit software to the ST. This was a while back; and I do not know if they can distribute it (due to AT&T copyrights). Since the 620 does not have the program down loading capability, it may be just as well to modify the unix end of the UW (Un*x Windows) to use SXT drivers, and the ``poll'' call to provide the same service. I do not know if UW provides error checking on the link, but that should not be too difficult to add. If you have to have the capabilities of the 630, you may have to reverse engineer the ST end to provide the same interface (things like wait(), sleep(), etc). The 630 programmer's guide has a lot of detailed information on the 630's executive, which should be enough to get one started. I would be happy to help with this. Sincerely -- Fariborz ``Skip'' Tavakkolian UUCP ...!uw-beaver!tikal!mcgp1!bruno!fst UNIX is a registered trademark of AT&T
rich@jolnet.ORPK.IL.US (Rich Andrews) (02/13/89)
I have received a few letters to the effect that the Atari ST could do a 630 emulation simply because it can be made to do multitasking. I should have quantified my statement that that atari cannot do a full true emulation of the 630 due to simple hardware constraints. To do a real 630 emulation you need the following capabilities. 1) a 3 button mouse 2) 14 active windows on the screen at once, all concurrent (7 windows per host). 3) all 14 have to have the ability to display 146 columns by 48 rows and be able to change to 80 by 32 or any other size at any time. 4) Capable of connection to 2 hosts at once with on screen editing. There are other constraints to be considered, but I do not feel like getting involved with it right now. Now if someone wanted to do a Atari-st layering terminal within the limits of the Atari ST, then that is a different matter. rich@jolnet.orpk.il.us -- Any opinions expressed are my own. Now, for a limited time, they can be yours too, for the incredible price of only $19.95. Simply send $19.95 (in Alterian dollars) to ...killer!jolnet!rich or rich@jolnet.orpk.il.us.
mvadh@cbnews.ATT.COM (andrew.d.hay) (02/13/89)
In article <149@jolnet.ORPK.IL.US> rich@jolnet.ORPK.IL.US (Rich Andrews) writes: "In article <689@jhunix.HCF.JHU.EDU> ecf_emeb@jhunix (Mark E. Bouver) writes: ">Hello, "> ">I am looking for an AT&T 620 or 630 emulator for the Atari ST. " " "Forget it.... [] " It would be easier to write a unix for the "ST. there is an atari minix -- i don't know if it's officially out yet, but the (original) ibm version costs ~$80 from prentice-hall and gives you *full* source code! -- Andrew Hay +------------------------------------------------------+ Apprentice Polymath | Yes, the wages of sin ARE death, but after they take | AT&T-BL Ward Hill MA | taxes out, it's kind of a tired feeling really | mvuxq.att.com!adh +------------------------------------------------------+
twolf@homxb.ATT.COM (T.WOLF) (02/14/89)
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)
katzung@laidbak.UUCP (Brian Katzung) (02/18/89)
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
cks@ziebmef.uucp (Chris Siebenmann) (02/21/89)
In article <1758@mcgp1.UUCP> fst@mcgp1.UUCP (Skip Tavakkolian) writes: ... >I've heard that one of the universities had done a port of the Blit software >to the ST. This was a while back; and I do not know if they can distribute >it (due to AT&T copyrights). Some people at the University of Toronto did this two or three years ago. With the widespread availability of Suns there, I believe it's been more or less abandonded. It can probably be distributed to people with a Blit source licence and nobody else. If you want to try getting in touch with someone about it, try drb@csri.toronto.edu (he was one of the people who did the port). -- "At LAST. Really, what must one DO to get ATTENTION 'round here?" - Kid Miracleman Chris Siebenmann uunet!{utgpu!moore,attcan!telly}!ziebmef!cks cks@ziebmef.UUCP or .....!utgpu!{,ontmoh!,ncrcan!brambo!}cks