Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!husc6!think!ames!ucbcad!ucbvax!FINGATE.BITNET!MAILER-DAEMON From: MAILER-DAEMON@FINGATE.BITNET (Mail Delivery Subsystem) Newsgroups: comp.sys.atari.st Subject: Returned mail: Deferred: Connection timed out during user open with op Message-ID: <8707150242.AA15423@ucbvax.Berkeley.EDU> Date: Tue, 14-Jul-87 22:43:44 EDT Article-I.D.: ucbvax.8707150242.AA15423 Posted: Tue Jul 14 22:43:44 1987 Date-Received: Fri, 17-Jul-87 01:49:22 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 430 ----- Transcript of session follows ----- 554 qfAA09495: line 6:... Unknown fudec host name ----- Unsent message follows ----- Received: by santra.UUCP (5.51/6.4.TeKoLa) id AA09495; Thu, 9 Jul 87 15:45:25 +0300 From: Message-Id: <8707091245.AA09495@santra.UUCP> Received: by fingate Thu Jul 9 15:45:19 from MAILER@FINHUTC.BITNET via rscs BSMTP. Received: by FINHUTC (Mailer X1.24) id 5091; Thu, 09 Jul 87 14:54:51 FIN Date: Wed 8 Jul 87 14:51:34 PDT Reply-To: Info-Atari16@Score.Stanford.edu Sender: "Atari ST users forum (INFO-ATARI16)" Original-From: Info-Atari16 Digest Subject: Info-Atari16 Digest V87 #263 To: , Original-To: , Info-Atari16 Digest Wednesday, July 8, 1987 Volume 87 : Issue 263 This weeks Editor: Bill Westfield Today's Topics: MFP problems STadel Degas File Formats Re: Unix Windows (source required) BIOS re-entrancy Curses HDSCAN, bummer man... Re: How can you send a BREAK? Re: BIOS re-entrancy Re: How can you send a BREAK? Re: MFP problems more DCFORMAT problems Re: Mega-ST release date? Where can I get the latest version of UNITERM? Re: MWC problem with 'long int' ---------------------------------------------------------------------- Date: Mon, 22 Jun 87 12:56:36 CET To: info-atari16@score.stanford.edu From: HAHN_K%DMRHRZ11.BITNET@wiscvm.wisc.edu Subject: MFP problems I'm still trying to install my own timer, and stumbled over the 'fact', that the system's timer ('C') is said to generate a 200hz- interrupt... As far as I can see it's installing procedure uses a division factor of 64 (decimal, I suppose), and a counter that's set to 192 (C0 hex). IF I believe my documentation which says that the MFP 68901 uses a 4Mhz - clock cycle, then what? All the divisions mentioned above wouldn't at all generate a 200hz-interrupt. Am I wrong? What I need are the data and control values for getting a one-millisecond resolution. Any suggestions? Yours in advance, Klaus. -- Klaus Hahn -- ------------------------------ Date: 23 Jun 87 07:41:18 GMT From: tektronix!reed!percival!edrury@ucbvax.Berkeley.EDU (Ed Drury) Subject: STadel To: info-atari16@score.stanford.edu What is the current status of Citadel 3.1 for the ST? I have not seen any news for some time. Also, is anyone interested in creating a snail mail STadel update type thing. I am currently running v. 3.0c but am DYING for a uucp capable STadel as a high percentage of my users are *nix account users, my self included.... **************************************************************************** * ..!{ucbvax,ihnp4,seismo}!tektronix!reed!percival!edrury * * * * "You should never wear your best trousers when you go out to fight for * * freedom and liberty." * * -- Henrick Ibson * ------------------------------ Date: 23 Jun 87 07:36:17 GMT From: tektronix!reed!percival!edrury@ucbvax.Berkeley.EDU (Ed Drury) Subject: Degas File Formats To: info-atari16@score.stanford.edu degas uses the following file format: The first 2048 bytes fof the font file are divided into 128 groups of 16 bytes. Each set of which are a char. The 16 bytes are stored from the top to bottom. The last two bytes are a WORD indciating whether or not the font is scaled too half it's normal height. A DEGAS picture file uses the first two bytes to determine resolution. The next 32 to give color palette information and 32000 to give picture data. I hope this is of some help. **************************************************************************** * ..!{ucbvax,ihnp4,seismo}!tektronix!reed!percival!edrury * * * * "You should never wear your best trousers when you go out to fight for * * freedom and liberty." * * -- Henrick Ibson * ------------------------------ Date: 23 Jun 87 00:43:14 GMT From: ihnp4!upba!eecae!msudoc!las@ucbvax.Berkeley.EDU (Larry A. Sheilds {runs Lunapark}) Subject: Re: Unix Windows (source required) To: info-atari16@score.stanford.edu I too would like UW source. thanks, ==larry -- --------------------------- LARRY SHIELDS USENET: ...!ihnp4!msudoc!lunapark!larry P.O. Box 6159 BIX: lshields E. Lansing, MI 48823 Compuserve: 70277,3677 ------------------------------ Date: 23 Jun 87 18:16:36 GMT From: iarocci@eneevax.umd.edu (John Iarocci) Subject: BIOS re-entrancy To: info-atari16@score.stanford.edu Anyone out there have any experience with making BIOS, XBIOS, and/or GEMDOS calls recursively? I'm writing a multi-tasking kernel, and trying to find a safe way to allow multiple processes access to operating system functions. My understanding is that upon entry to the BIOS trap routines, registers are saved in savptr ($4a2). However, the default save area contains enough room for only three levels of re-entrancy. Can this situation be resolved simply by allocating a larger area of memory and setting savptr to point to it? Also, does anyone know if any conflics may arise if a process were preempted in the middle of the BIOS, only to have another process make a BIOS call, possibly the same one that was interrupted? The same question goes for the XBIOS and GEMDOS. Thanks in advance for any help you can offer. ------------------------------------------------------------------------------- | Bill Dorsey 'Imagination is more important than knowledge.' | | - Albert Einstein | | 'He who has imagination without learning has wings and no feet.' | | - Joubert | | ARPA : iarocci@eneevax.umd.edu | | UUCP : [seismo,allegra,rlgvax]!umcp-cs!eneevax!iarocci | ------------------------------ Date: Tue, 23 Jun 87 12:52 EST From: Matt Kimmel To: Info-Atari16@SCORE.STANFORD.EDU Subject: Curses X-VMS-To: CSNET%"Info-Atari16@Score.Stanford.edu" Is there a version of Curses available for the ST? If so, could someone mail it to me? Please write me in advance so that I don't end up with 20 copies of Curses in my mailbox. Thanks! -Matt Kimmel Bitnet: KIMMEL@UMAECS CSNet: KIMMEL@ECS.UMASS.EDU Internet: KIMMEL%ECS.UMASS.EDU@RELAY.CS.NET UUCP: ...!seismo!UMAECS.BITNET!kimmel ------------------------------ Date: 17 Jun 87 01:08:25 GMT From: ptsfa!hoptoad!academ!uhnix1!uhnix2!uace0@ames.arpa (Univ ATARI Comp Enthusiasts) Subject: HDSCAN, bummer man... To: info-atari16@score.stanford.edu I still couldn't get the new posting to work correctly. It exits arc saying that there is a CRC error. Perhaps the poster can send me a direct copy, or perhaps not arc the file before uuencoding, or uuencode on the ST (preferred) then send it on the net. The file I have this time is the same size as the old one, and spits out the same error. I am of course referring to HDSCAN 1.3 - Mike -- >>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<< UACE + A Smith & Wesson beats a four of a kind! + uhnix2!uace0 ------------------------------ Date: Wed, 24 Jun 87 11:14:08 EDT From: Michael Fischer Subject: Re: How can you send a BREAK? To: info-atari16@score.stanford.edu In-Reply-To: , 24 Jun 87 03:20:17 GMT johng@iscuva.UUCP (John Gardner) writes: > The Atari developer's kit includes a function called Rsconf ... This is an XBIOS routine built into TOS and not a part of the developer's kit. It can be called from any language that provides access to the system primitives. --Mike Fischer ------------------------------ Date: Wed, 24 Jun 87 10:59:37 EDT From: Michael Fischer Subject: Re: BIOS re-entrancy To: info-atari16@score.stanford.edu In-Reply-To: , 23 Jun 87 18:16:36 GMT Anyone out there have any experience with making BIOS, XBIOS, and/or GEMDOS calls recursively? I've called a BIOS routine successfully from inside an RWABS handler, but I've never been able to call a GEMDOS routine from there, presumably because GEMDOS ==> RWABS ==> GEMDOS results in a recursive call on GEMDOS. I'd like to know how. I'm writing a multi-tasking kernel, and trying to find a safe way to allow multiple processes access to operating system functions My understanding is that upon entry to the BIOS trap routines, registers are saved in savptr ($4a2). However, the default save area contains enough room for only three levels of re-entrancy. Can this situation be resolved simply by allocating a larger area of memory and setting savptr to point to it? Yes, I think so, but I'm not convinced that that is the only problem. I tried expanding the save area once and the recursive call still crashed. Of course, maybe I didn't do it correctly... Also, does anyone know if any conflics may arise if a process were preempte in the middle of the BIOS, only to have another process make a BIOS call, possibly the same one that was interrupted? The same question goes for the XBIOS and GEMDOS. Thanks in advance for any help you can offer. Interrupting a BIOS routine at an arbitrary point seems very unlikely to work, The BIOS manipulates hardware control registers, then waits for the actions to complete. Interrupting in the middle would be disasterous. For example, if you interrputed a disk read between the seek and the actual I/O operation and then did another read, when you came back to the first one the head would be in the wrong place. To write a good multi-taksing kernel, you should rewrite the BIOS to put the current task in an I/O wait state when I/O has been initiated and then go back to the process scheduler to see if another task can be run. Completion of the I/O would then be detected by an interrput rather than by busy-wait loops as in the current BIOS. The BIOS itself would then have to worry about how much concurrency to permit and how to schedule multiple requests. Short of a complete rewrite, your best bet is probably to set a lock when the BIOS is entered and to make sure not to switch tasks while the lock is set. The same thing will probably also be needed for calls to GEMDOS, XBIOS, and perhaps also VDI and AES or at least the line A graphics routines. Then there is the memory fragmentation problem. While you can write your own memory manager, TOS will continue to use its own Malloc, unless of course you *replace* the GEMDOS version with your own and TOS is clean enough to always go through the trap vector when calling GEMDOS functions. Doing a multi-tasking kernel right is a big job. Modifying a system like TOS to make it multitasking is perhaps even harder than starting from scratch, especially without access to the sources. Good luck! --Mike Fischer ------------------------------ Date: 24 Jun 87 03:20:17 GMT From: uunet!iscuva!johng@seismo.css.gov (John Gardner) Subject: Re: How can you send a BREAK? To: info-atari16@score.stanford.edu In article <8706230308.AA26681@ucbvax.Berkeley.EDU> SYSTEM@UVPHYS.BITNET (NAME NIK ZAPANTIS) writes: > I would like to be able to send a BREAK to my RS-232 port from my program, >just like UNITERM does with the ALT L or ALT B key. > >Thank you in advance, > >Nik Zapantis To send the break signal, you need to program the 68901's tsr register. If you put in a hex 0x89 the RS232 port will now send the break signal. Write tsr with a hex 0x81 to turn it off. The Atari developer's kit includes a function called Rsconf and basically if you do something like Rsconf(-1, -1, -1, -1, 0x89, -1); you turn on break. The -1's tell this function not to change the parameter at that location. The parameters appear like this, Rsconf(speed, flowctl, ucr, rsr, tsr, scr); Later, JAG ------------------------------ Date: Wed, 24 Jun 87 10:59:52 EDT From: Michael Fischer Subject: Re: MFP problems To: info-atari16@score.stanford.edu In-Reply-To: , 24 Jun 87 02:04:25 GMT I'm still trying to install my own timer, and stumbled over the 'fact', that the system's timer ('C') is said to generate a 200hz- interrupt... As far as I can see it's installing procedure uses a division factor of 64 (decimal, I suppose), and a counter that's set to 192 (C0 hex). IF I believe my documentation which says that the MFP 68901 uses a 4Mhz - clock cycle, then what? All the divisions mentioned above wouldn't at all generate a 200hz-interrupt. Am I wrong? What I need are the data and control values for getting a one-millisecond resolution. Any suggestions? Yours in advance, Klaus. A 200hz interrupt has a 5 millisecond period. The numbers you give are not far off, if the '64' is interpreted as a hex number (= 100 decimal), for then the timer would interrupt every 100*192 clock cycles, or every 19.2/4 = 4.8 milliseconds. --Mike Fischer Arpanet: Bitnet: ------------------------------ Date: 23 Jun 87 13:53:00 GMT From: cca!mirror!datacube!ftw@husc6.harvard.edu Subject: more DCFORMAT problems To: info-atari16@score.stanford.edu The patch to dcformat.uue that was posted on June 18 by pmt@sbcs.uucp does not seem to fix the problem I have with the archive. I don't appear to have any truncated lines; my copy of ARC claims that both dcformat.prg and dcformat.rsc have bad checksums. Anyone else have this problem with the dcformat archive? (Moshe, is this the trouble you had?) Farrell ------------------------------ Date: 24 Jun 87 04:04:36 GMT From: necntc!adelie!mirror!xanth!src@husc6.harvard.edu (Scott R. Chilcote) Subject: Re: Mega-ST release date? To: info-atari16@score.stanford.edu In article <762@atari.UUCP> neil@atari.UUCP (Neil Harris) writes: > > I don't know how these stories get out. > >--->Neil Harris, Director of Marketing Communications, Atari Corporation Perhaps it has something to do with the fact that only one of every forty or so messages directed at Atari induces a response, and in this this case you ignored the principal question in order to sling mud at an admittedly misinformed reply. My information came directly from an Atari distributor who merchandises a local retail store where I work. If and when you choose to provide your distributors with correct information, then as an Atari salesperson I will accurately relay it to the public. Your tolerance for lesser mortals is humbly appreciated. ------------------------------------------------------------------------------- Disclaimer: I said it, so I'll take the rap! ------------------------------------------------------------------------------- src@xanth.UUCP Scott Chilcote ------------------------------ Date: 17 Jun 87 12:25:27 GMT From: ptsfa!hoptoad!academ!killer!blaise@ames.arpa (Walter Wilinsky) Subject: Where can I get the latest version of UNITERM? To: info-atari16@score.stanford.edu Could some kind soul please post or E-mail me the latest version of UNITERM, I think it is version 1.7b. I need kermit which is not in the version of UNITERM that I have (1.6). Thanks in Advance Wally Wilinsky {ihnp4,pollux,dj3b1}!killer!blaise ni ------------------------------ Date: 21 Jun 87 11:06:16 GMT From: mcvax!unido!laura!@@seismo.css.gov (Andreas Toenne) Subject: Re: MWC problem with 'long int' To: info-atari16@score.stanford.edu Hi, has anyone collected all known bugs in MWC 2.0 ?? I am quite happy with the old version (and I know all its bugs :-) but 2.0 is probably better. Andreas Toenne U of Dortmund, IRB West Germany at@unido.uucp at@unido.bitnet D ------------------------------ End of Info-Atari16 Digest ************************** -------