JEMCCABE@mtus5.BITNET (01/05/87)
Date: 4 January 87 22:36-EST
From: JEMCCABE@MTUS5
To: INFO-ATARI16@SCORE.STANFORD.EDU
Subject: BITNET mail follows
I was wondering if there is a way to determine the state of the RS-232 D
from OSS Personal Pascal. I'm writing a BBS and need to have some way o
knowing when the user hangs up. I think it may have something to do wit
MFP level 1 interrupt, but I have no experience whatsoever with the MFP
interrupts.
Help!
Jim McCabe
JEMCCABE@MTUS5.BITNETJEMCCABE@mtus5.BITNET (01/09/87)
Date: 9 January 87 13:25-EST
From: JEMCCABE@MTUS5
To: INFO-ATARI16@SCORE.STANFORD.EDU
Subject: BITNET mail follows
I was wondering what the GDOS is. I've seen one or two programs
boot up with GDOS in the AUTO folder, but I haven't seen it anywhere
in my books. Is it some type of extension to the graphics routines
or the GEMDOS? I'm sure somebody out there knows what it is... :-)
Also, how can I set up the screen to leave certain lines stable while
the others scroll "under" it? (Like Flash's bottom status line, or
Forem ST's status lines at the top of the screen...) Do I have to
keep track of where the cursor is at all times and manually write my
own routines to fake this, or can you just tell TOS that the screen
has a different size? Help!
*************************************************
* Jim McCabe *
* G34 E. Coed Hall *
* Michigan Technological University *
* Houghton, MI 49931 *
* (906)487-1065 JEMCCABE@MTUS5.BITNET *
*************************************************JEMCCABE@mtus5.BITNET (01/13/87)
Date: 13 January 87 00:30-EST
From: JEMCCABE@MTUS5
To: INFO-ATARI16@SCORE.STANFORD.EDU
Subject: BITNET mail follows
Subject: OSS Personal Pascal PEEKing
Is there a way to PEEK a memory address in Personal Pascal? I asked
a question a while back about detecting the DCD on the RS232, and
someone was kind enough to strenthen my own guesses about how to do
it into solid assurance. It consists of manipulating a byte
read from $FFFA01 to check the bits. However, there is one
problem with this. To read this address, the 68000 must be
in Supervisor mode, not the normal User mode. To put the ST in
Supervisor mode, one can simply call GEMDOS function super().
(GEMDOS 32) However, I unfortunately have yet another problem.
Personal Pascal doesn't have any PEEK function or MEM array like
Turbo Pascal does. I have no way to find out how to peek it!
This really peeves me, because I know how to get the complex
stuff out of the way (entering and exiting Supervisor Mode), but
I can't perform even a simple PEEK! This is a really important
operation, so I'm pretty sure someone out there must know how
I can PEEK($FFFA01)... I think there may be a way to fool
Pascal into peeking with variable records and pointers, but I'm
still unknowledgable when it comes to pointers at this point.
Does anyone know how to do this? I don't have an assembler, so
I can't write any EXTERNAL routines to INCLUDE in compilation,
and I don't know 68000 machine language anyway... Please, if
you know how to do this, post the answer as soon as possible!
I need to know the answer very quickly... Thanks!
(And thanks to Simon Poole for reassuring my guess...)
Jim McCabe
JEMCCABE@MTUS5.BITNETJEMCCABE@mtus5.BITNET (01/14/87)
Date: 13 January 87 22:03-EST
From: JEMCCABE@MTUS5
To: INFO-ATARI16@SCORE.STANFORD.EDU
Subject: BITNET mail follows
Subject: OSS PEEKs, and user support...
A few days ago I sent out a question about the ability to PEEK and
POKE using Optimized Systems Software's Personal Pascal. Last night
I called up OSS's own BBS, and lo and behold, I found a wealth of
information on Pascal. Not only did I find PEEK and POKE routines
for Byte, Integer, and Long_Integer, but I also found STR and VAL
routines as well as a patch to fix some small bugs in my version
of Personal Pascal and I even downloaded a function that returns
the address of a procedure (useful in interrupts, I guess.) I
would like to congratulate OSS for its great user support, and
for maintaining their BBS, which has so much valuable data online.
I plan on calling the BBS every month or so now just to keep up
on the new developments. Very impressive guys, keep it up!
*************************************************
* Jim McCabe *
* G34 E. Coed Hall *
* Michigan Technological University *
* Houghton, MI 49931 *
* (906)487-1065 JEMCCABE@MTUS5.BITNET *
*************************************************JEMCCABE@mtus5.BITNET (01/23/87)
Date: 22 January 87 17:59-EST
From: JEMCCABE@MTUS5
To: INFO-ATARI16@SCORE.STANFORD.EDU
Subject: BITNET mail follows
The REAL Subject (not "Bitnet mail follows..."): Telecom stuff...
I have a question about the ongibit() and offgibit() calls. (XBIOS
calls 30 and 29, respectively.) According to Abacus' Atari ST
Internals, a ongibit(4) clears the DTR line on the RS-232 port.
When I try this, however, the busy light on the disk drive comes
on, but it never reads from the disk (even works when the disk
isn't in the drive) and it never stops. I've heard that the
Internals book is faulty, but I've never seen anyone say WHERE
it is faulty. Maybe I found a place, eh?
Also, does anyone know where I can get my hands on the source code
of a program(s) that has all the XMODEM transfers in it, and maybe
YMODEM, KERMIT, and others? I can get a PD program, for the IBM,
called Pibterm, that is in Turbo Pascal (I would like it in Pascal,
if possible...) and it has XMODEM, XMODEM CRC, YMODEM, TELINK,
KERMIT, MODEM7, and a bunch of other protocols.... This would be
heaven to me if I could only read the files of the disk! (It's
a PC club, and they have this program in their disk library.) Maybe
if I am lucky, they will have it in 3.5 inch disks, which are
rumored to be readable by ST's.
I also have a suggestion for the person wondering how to autoboot
a GEM program. Looking through the Internals book, it seems that
GEM can maybe load a file for ya... Here's what it says about memory
location $482.
$482 two bytes _comload default 0
If this variable is set to a value other than zero by the boot pro-
gram, an attempt will be made to load a program called "COMMAND.PRG"
after the operating system is loaded.
I've never tried this myself, but maybe it'll work. To test it,
make a TOS program to poke this location with a 1 or something, and
stick that file in the AUTO folder. Then, rename your .PRG file
to COMMAND.PRG, and see if everything works when you reboot. Re-
member, I've NEVER done this before and this could all be another
error in the Abacus book, but it's worth a try.
* Jim McCabe *
* G34 E. Coed Hall *
* Michigan Technological University *
* Houghton, MI 49931 *
* (906)487-1065 JEMCCABE@MTUS5.BITNET *bruce@ektools.UUCP (Bruce D. Nelson ) (01/25/87)
In article <8701222316.AA21388@ucbvax.Berkeley.EDU> JEMCCABE%MTUS5.BITNET@forsythe.stanford.edu writes: >I have a question about the ongibit() and offgibit() calls. (XBIOS >calls 30 and 29, respectively.) According to Abacus' Atari ST >Internals, a ongibit(4) clears the DTR line on the RS-232 port. >When I try this, however, the busy light on the disk drive comes >on, but it never reads from the disk (even works when the disk >isn't in the drive) and it never stops. I've heard that the >Internals book is faulty, but I've never seen anyone say WHERE >it is faulty. Maybe I found a place, eh? Yes, the ABACUS book is wrong (but that's nothing new!). You have to supply the bit PATTERNS of the bits you want to turn on and off. The following examples show how it's done. BTW, my previous posting on this subject was a bit overkill by going into supervisor mode and tweaking the bits in assembler. I guess I hacked before I looked. :-) ----------------------------- cut here -------------------------------- /* This program turns ON DTR by setting bit 4 of the sound chip OFF. Notice the argument to Ongibit is the complement of the BIT PATTERN of the bits to be reset on the sound chip. The ABACUS book was wrong in saying it was the BIT NUMBER. */ #include <osbind.h> main() { Offgibit(~0x10); } ----------------------------cut here -------------------------------- /* This program turns OFF DTR by setting bit 4 of the sound chip ON. Notice the argument to Ongibit is the BIT PATTERN of the bits to be set on the sound chip. The ABACUS book was wrong in saying it was the BIT NUMBER. */ #include <osbind.h> main() { Ongibit(0x10); } Bruce D. Nelson, Sr. Appl. Analyst: Software Maintenance, Product Line Systems EASTMAN KODAK COMPANY, 901 Elmgrove Rd., Rochester, NY 14650, 716 726-7890 UUCP: {allegra, seismo}!rochester!kodak!ektools!bruce ARPA: kodak!ektools!bruce@rochester.ARPA
JEMCCABE@mtus5.BITNET.UUCP (01/30/87)
Date: 30 January 87 02:22-EST
From: JEMCCABE@MTUS5
To: INFO-ATARI16@SCORE.STANFORD.EDU
Subject: BITNET mail follows
Real subject: UUENCODE and decoding...
Can anyone please send me the program that does all the UUENCODE
and UUDECODE stuff? Not only do I want it, but the computing
center here at Michigan Tech is looking for it. We need to
decode a PD Kermit program for distribution. (They collect
Kermit for all the computers they can find...)
If it is available for download on the Atari BBS, just say so
and I can get it from there if it is too much trouble to get
it another way.
Thanks (hopefully),
Jim
*************************************************
* Jim McCabe *
* G34 E. Coed Hall *
* Michigan Technological University *
* Houghton, MI 49931 *
* (906)487-1065 JEMCCABE@MTUS5.BITNET *
*************************************************JEMCCABE@mtus5.BITNET.UUCP (02/07/87)
Date: 7 February 87 03:20-EST
From: JEMCCABE@MTUS5
To: INFO-ATARI16@SCORE.STANFORD.EDU
Subject: BITNET mail follows
========================================================================
Date: Sat, 07 Feb 87 03:13:06 EST
From: Jim McCabe <JEMCCABE@MTUS5>
Subject: RS-232 Handshaking
To: info-atari16@score.stanford.edu
I have come across a little problem with the RS-232 transmissions on the
ST. I assume that it is my fault and I am just ignoring something. Any-
way, when I send a big string of text to the modem and then hang up
right after I send it, the ST will quickly fill up its buffer and then
return to my program as if the buffer was actually sent, even when it
wasn't. At 300 baud, this happens a lot, with callers getting about two
lines or so of text (out of five or ten) and having the system hangup
(DTR toggle, so I don't have to send commands to the modem directly) before
it is all transmitted. Tonight I changed my program to use RTS/CTS
handshaking, but I haven't had a chance to test it. I'd like to know if
I'm supposed to use XON/XOFF handshaking or RTS/CTS (or none?) to fix
this problem of mine.
Thanks!
Jim
..............................
"Your friends will know you better in the first minute you meet than
your aquaintances will know you in a thousand years."
--Richard Bach, "Illusions"
..............................
****** ****** *********** ***** ***** +--------------------------+
******* ******* *********** ***** ***** | Jim McCabe |
*** *** *** ** *** ** *** *** | G34 E. Coed Hall |
*** * *** *** *** *** | Michigan Tech University |
*** *** *** *** *** | Houghton, MI 49931 |
***** ***** ***** ********** | JEMCCABE@MTUS5.BITNET |
***** ***** ***** ******** +--------------------------+
The views and opinions expressed above do not reflect those of Michigan
Technological University, but rather, they belong to me and that's all
there is to it. So there. Nyah.JEMCCABE@mtus5.BITNET.UUCP (02/09/87)
Date: 9 February 87 00:16-EST
From: JEMCCABE@MTUS5
To: INFO-ATARI16@SCORE.STANFORD.EDU
Subject: BITNET mail follows
Real Subject: OSS Personal Pascal problems...
You may remember my posting a while back about having problems finding
a PEEK routine for Pascal. Well, I found it but now, no matter what I
try with Personal Pascal, it won't let me access certain memory
locations. The program stops when I try to access $FFFA01, even though
I am in supervisor mode. I even have the pointer checking set off.
This problem is really beginning to bug me... All I wanted to do was
monitor the DCD line...
I'm considering making an interrupt to set a flag when the DCD is there,
but I'd also need another interrupt that is executed BEFORE that one
that sets the flag to false, just in case that the DCD is low...
That would insure that the flag is always right. The flag is set to
false by default, and then if the DCD is high the interrupt would
set the flag to true again. I know how to set up my interrupt (MFP
interrupt 1) but I need another one that is always executed before
that one.
(But then again, if there is an easier way than an interrupt or
PEEKing $FFFA01, someone please tell me!)
A depressed thanks...
Jim McCabe
JEMCCABE@MTUS5.BITNETJEMCCABE@mtus5.BITNET (03/09/87)
Date: 8 March 87 17:25-EST
From: JEMCCABE@MTUS5
To: INFO-ATARI16@SCORE.STANFORD.EDU
Subject: BITNET mail follows
Here's a little suggestion for the new 68020 machines... Would it be
too unreasonable to have the OS stored on a cartridge? This way, updates
to the OS would be extremely simple and quick, but we would still have the
advantage of a ROM OS so that it wouldn't have to load off the disk.
Any ideas?
Jim
JEMCCABE@MTUS5.BITNETJEMCCABE@MTUS5.BITNET.UUCP (04/13/87)
Date: 13 April 87 13:18-EST
From: JEMCCABE@MTUS5
To: INFO-ATARI16@SCORE.STANFORD.EDU
Subject: BITNET mail follows
Date: 13 April 1987, 13:17:15 EST
From: Jim McCabe 487-1065 JEMCCABE at MTUS5
To: INFO-ATARI16 at SCORE.STANFORD.EDU
Is there a public domain Kermit program available for the ST? If
so, where can I get it? I have Flash's Kermit accessory but my school
is looking for a PD Kermit program... Thanks!
JimJEMCCABE@MTUS5.BITNET (04/24/87)
Date: 23 April 87 20:15-EST
From: JEMCCABE@MTUS5
To: INFO-ATARI16@SCORE.STANFORD.EDU
Subject: BITNET mail follows
Date: 23 April 1987, 20:15:13 EST
From: Jim McCabe JEMCCABE at MTUS5
To: INFO-ATARI16 at SCORE.STANFORD.EDU
I've seen a few programs that use a special 50 line screen on my monochrome
monitor... (UniTerm, Flash, the Atari 800 emulator, etc...) How is this
achieved? And after you've done it, can the standard VT52 cursor positioning
calls still be used to access the lower half of the screen?
Thanks!
Jim
(BTW, I'm using Personal Pascal...)JEMCCABE@MTUS5.BITNET (04/25/87)
Date: 25 April 87 12:57-EST
From: JEMCCABE@MTUS5
To: INFO-ATARI16@SCORE.STANFORD.EDU
Subject: BITNET mail follows
Date: 25 April 1987, 12:54:56 EST
From: Jim McCabe JEMCCABE at MTUS5
To: INFO-ATARI16 at SCORE.STANFORD.EDU
(Actually, this is directed to Sam Streeper... I couldn't reach you
directly, so I'm using this... )
I'd love it if you could send me the source code to that 50 line screen
hack!
JimU00177@HASARA5.BITNET (08/26/87)
Reply to: Help! Fdatime() under Lattice C blows up. (22 aug 1987)
Why bombs with Fdatime() under Lattice C.
First of all, Metacomco's Lattice C latest version is 3.04.01. And
a good working Make program is supplied with this version.
Ask for a update.
M's manual is doesn't say anything about Fdatime(). But Mark
Williams C development kit (version 2.0.1) does. M-W also contains a
Make, a pretty good shell (like the Bourne and Berkeley C shell) and
a reset proof, bootable RAM-disk that can save and restore it self
to and from floppy disk. Sources included!
But as to Fdatim(), try this:
void Fdatime(info, handle, getset);
int info[2], handle, getset;
handle: the file's handle, set when the file was first
opened with Fopen (gemdos 61 or 0x3D;
Fopen(name, mode)).
Do not use fopen() from stdio!!
getset: 0 = get time, 1 = set time.
info : pointer to a buffer that holds two integers. It
contains or receives the time/date stamp,
depending on getset:
info[0] 0-4 no. of two second increments (0-29)
5-10 no. of minutes (0-59)
11-15 no. of the our (0-23)
info[1] 0-4 day of the month (1-31).
5-8 no. of the month (1-12).
9-15 no. of the year (0-119, 1980=0).
Perhaps this will work.
And a note on TOS-ROMS -- BLITTER version (from Herbert Goertzel, 20
aug 1987):
I saw the same message on the official ATARI-BENELUX (Netherland,
Belgium) bulletin board. Probably we must beleave it.
Wim Schaasberg (U00177@HASARA5.HEARN).JEMCCABE@MTUS5.BITNET (10/07/87)
Date: 6 October 1987, 18:21:11 EST
From: Jim McCabe JEMCCABE at MTUS5
To: INFO-ATARI16 at SCORE.STANFORD.EDU
[ blah blah blah ]
I'm looking for a good, durable, and cheap plug-in (no soldering please!)
memory upgrade for a standard 512K 520ST. I'm considering getting an
upgrade from a company called Tech Specialties Co. (they have ads in
Computer Shopper magazine a lot.)
They sell two kinds of boards:
a) one board with room for upgrades of 1Mb, 2.5Mb, and 4Mb,
costing $179, $495, and $995 respectively. (You are supposedly
able to just plug in different chips to get more memory.
b) a standard 1Mb upgrade, with the RAM chips soldered on to a
1Mb-only sized board. Cost is $129.
Does anyone out there have any experience with this company and/or with
these products?
Jim McCabe
JEMCCABE @ MTUS5.BITNET
(By the way, they also sell SCSI 20Mb hard drives that connect through
the DMA port for $595...)
(Disclaimer: I don't know anyone in that company, have no experience
at all with them, am not advertising their products with the intent to
bring them any business other than my own, etc...) :)JEMCCABE@MTUS5.BITNET (10/20/87)
Date: 20 October 1987, 09:11:00 EST
From: Jim McCabe JEMCCABE at MTUS5
G31 East Coed Hall
Michigan Technological University
Houghton, MI
49931
To: INFO-ATARI16 at SCORE.STANFORD.EDU
[ Does Bitnet have line-eater problems too? ]
I've got a question for someone who knows a little about the
GEMDOS directory management.
I'm writing a program where it is necessary for the user to
take out the disk that the program was loaded from and insert
a data disk. From this program, when I try to access a file
after swapping disks, it can find files just fine if they are
in the root directory, but subdirectories cause error -33 (at least
I think that's what error it was... haven't looked at it in
a month or so...) which means that the pathname isn't found
or whatever. Just to test this out, I wrote a small program
to do the exact same file I/O, but it works as it should with
the test program! Somehow things aren't working in my real
program, and I am fairly certain that it isn't the fault of
the program.
If I could just force GEMDOS into loading the new directory tree...
With my test program, GEMDOS recognizes the fact that the disk
has been changed and loads the directory info off the new disk.
However, with my real program, it doesn't work. (It doesn't
even access the disk! I guess GEMDOS is just saying "I don't
have that subdirectory in my directory tree, and the disk
hasn't been changed since you accessed the root directory, nyah!")
I tried to set the "dirty" flags in the directory buffers (as
described breifly in the Abacus ST Internals book) and then
reaccess the disk, but nothing different happens. How does
the GEM Item Selector box automatically get the new directory
when we tell it to? How does the desktop do this when we hit
the <ESCAPE> key? If I could only do this, I bet my problem
would go away...
Confused,
Jim0ALEVI@POMONA.BITNET (10/27/87)
Date: 26 October 1987, 14:50:23 PDT From: 0ALEVI at POMONA To: INFO-ATARI16 at SCORE.STANFORD.EDU ========================================================================= I am planning on putting together a memory map for the 1040/520 ST. I would appreciate any input... If you know of ANY addresses which the ST uses, tell me please! (even if they seem insignificant) Since I have very little information about the inside workings of the ST, I will be relying on the input I get from you. If anybody would like a copy of this memory-map-to-be, just let me know and I'll send you one. Thanx in advance for any help you can give. I also have one more thing to say... Has anyone successfully converted an RGB signal to a composite signal using the public domain circuit diagram and instructions? If so, did you have to make any modifications to the circuit? Does this circuit make sure that the ST thinks that you have a color monitor hooked up?(I've had crashes using programs which work in color only with my monochrome monitor) Thanx in advance. By the way, my adress is : 0ALEVI@POMONA.BITNET
0ALEVI@POMONA.BITNET (04/18/88)
OPTIONS: NOACK LOG SHORT NOTEBOOK ALL Date: 15 April 1988, 10:20:31 PST From: 0ALEVI at POMONA To: INFO-ATARI16 at SCORE.STANFORD.EDU >i believe rsrc_load() does some Malloc'ing of its own. if you never do an >Mshrink to free up the space at startup, this might be your problem (alan >pratt's NEW gemstart.s does this and the "old" gemstart did it as well, as >i recall. you are obviously not using the dev kit so your compiler may differ) > >0 DOES indicate an error (as it does in rsrc_gaddr), at least according to >"official" atari/(ibm)dri docs :~). also if you did a Dsetpath before the >load, this might cause the file to not be found. > >other than that, you might make sure "filn" really contains what you think >it should prior to load. don't be insulted, i've done far stupider things >myself before :~). > >-bill Bill, first of all: I'm certainly not insulted, just a bit frustrated. Second of all, what's an Mshrink? I looked in the osbind.h file on my m Lattice C disk and found it. Aparently, it's a gemdos call. Well m? that's fine and dandy, but I don't have any documentation about it. What book has this documentation? An Abacus book perhaps? ow. Third of all, thanx for the help. ************* To: Rainer Klute Thank you for the adress. ************* (****** I think I need some documentation *********) -Alan M. Levi
0ALEVI@POMONA.BITNET (04/20/88)
Date: 19 April 1988, 19:50:32 PST From: 0ALEVI at POMONA To: INFO-ATARI16 at SCORE.STANFORD.EDU Bill writes:(Bill Rosenkranz) >Mshrink is a gemdos call that returns memory to the operating system. a far >as i know, when you double-click (or otherwise start a program) it take >ALL available memory for itself. since rsrc_load needs to allocat space >(using a Malloc call, probably the gemdos version NOT the gemlib malloc, >there is none available and it would probably bomb. this is why the alcon >startup file GEMSTART.S does the Mshrink almost as soon as the program tarts. >the gemstart module is the first thing that executes when your program tarts >and eventually calls your "main" function. i don't know how lattice >works but it probably does something similar. check your docs to see if >they mention something about linking and a certain object that has to b >first. you should probably solicit a response from lattice hackers. ************************************************************************ Bill, What you said makes perfect sense. I even think it will help! But,... what are the two parameters to the Mshrink(a,b) call? Do you know? Are these universal to all compilers? Does the function return a value (such as an error code)? I know I have been asking quite a few questions, but maybe I'll be answering questions someday. Thanks for everything! Sincerely, Alan Levi ******ANY COMMENTS FROM THE PEANUT GALLERY ARE WELCOME!!!************
0ALEVI@POMONA.BITNET (04/20/88)
Date: 19 April 1988, 19:52:13 PST
From: 0ALEVI at POMONA
To: INFO-ATARI16 at SCORE.STANFORD.EDU
Subject : UUxxCODE and ARC
My results from attempting and failing to successfully down-load and decode
binary files from UH-INFO at ... :
1) I need a modem for my ST!
2) I need Uniterm to use with a modem
3) Transfering files through a PC with an IRMA board
and through a PC with a modem
doesn't work for programs!
(except for decoded and unarced text files)
4) I was given an arc utility by a fellow info-atarian which works on
a VMS system! It works! But what can I do with a binary file that
gets screwed up during transfer to a floppy? NOTHING!
So, I can get text files. wow. It's something, at least.
*********************************
******************* Wherever you go, there you are. ******************
*********************************
-Alan M. Levi (0alevi at pomona.bitnet)mcli@ur-tut (Maurice Ling) (04/20/88)
In article <8804200341.AA29070@ucbvax.Berkeley.EDU> 0ALEVI@POMONA.BITNET writes: >Date: 19 April 1988, 19:52:13 PST >From: 0ALEVI at POMONA >To: INFO-ATARI16 at SCORE.STANFORD.EDU >Subject : UUxxCODE and ARC > >My results from attempting and failing to successfully down-load and decode >binary files from UH-INFO at ... : .......... (stuff deleted) > 4) I was given an arc utility by a fellow info-atarian which works on > a VMS system! It works! But what can I do with a binary file that > gets screwed up during transfer to a floppy? NOTHING! >So, I can get text files. wow. It's something, at least. > > ********************************* >******************* Wherever you go, there you are. ****************** > ********************************* >-Alan M. Levi (0alevi at pomona.bitnet) You can use Kermit in binary mode to send files from your XXXX machine to your ST. It works really well. In fact, when I got the latest version of Uniterm (V20c 009, I think), It took almost no time to uudecode it and unarc it on the VAX 8650. The thing that took the longest time was downloading it to my ST at 19600 baud (It's connected directly to the dataswitch). later, Maurice ******************************************* * * * Optics... The wave of the future * * * * BITNET : MCLI_SS@UORDBV, MCLISS@UORVM * * UUCP : ...rochester!ur-tut!mcli * * Internet: mcli@tut.cc.rochester.edu * * * *******************************************
wes@obie.UUCP (Barnacle Wes) (04/24/88)
In article <8804200802.AA03159@ucbvax.Berkeley.EDU>, 0ALEVI@POMONA.BITNET writes: [...] > what are the two parameters to the Mshrink(a,b) call? Do you know? Are these > universal to all compilers? Does the function return a value (such as an > error code)? From the MWC docs: Mshrink - gemdos function 74. Shrink amount of allocated memory. #include <osbind.h> long Mshrink(begin, length) long begin, length; *Mshrink* shrinks the amount of memory allocated by a program, and returns dynamic memory to the free memory pool. _begin_ points to the beginning of the space to be returned, and _length_ indicates the amount of memory to be returned. *Mshrink* returns zero if memory could be de-allocated, and non-zero if it could not. NOTES The *gemdos* call has a third parameter that is always zero; the Mshink macro inserts this parameter automatically. ----------------------------------------------------------------------- I think the <osbind.h> file came from Atari, so most compilers should support the two parameters mentioned, and automagically insert the 0 parameter. -- /\ - "Against Stupidity, - {backbones}! /\/\ . /\ - The Gods Themselves - utah-cs!uplherc! / \/ \/\/ \ - Contend in Vain." - sp7040!obie! / U i n T e c h \ - Schiller - wes
leo@philmds.UUCP (Leo de Wit) (04/28/88)
In article <8804200802.AA03159@ucbvax.Berkeley.EDU> 0ALEVI@POMONA.BITNET writes: >Bill writes:(Bill Rosenkranz) >>Mshrink is a gemdos call that returns memory to the operating system. a far >>[...middle of article deleted...] >>first. you should probably solicit a response from lattice hackers. >Bill, > What you said makes perfect sense. I even think it will help! But,... >what are the two parameters to the Mshrink(a,b) call? Do you know? Are these >universal to all compilers? Does the function return a value (such as an >error code)? >[...middle of article deleted...] >Alan Levi Here is an answer from a Lattice hacker: In Lattice the linking process starts with a INPUT startup.bin. This module does indeed a Mshrink. As far as I remember without having the documentation with me, this is equivalent with a gemdos 0x4a call: setblock. It takes two parameters, the first the block's start adress, the second the block's size. I don't know, but I think Mshrink returns a -1 on fail and 0 on success (the standard gemdos return values). All decent C compilers for the ST should offer the Mshrink function in some way; Lattice does it by a macro definition that uses a function gemdos(). Typically the start address is the address of the base page, the length is the sum of the text, data, bss, spare and stack segments. You should obtain a copy of Data Becker's Atari St Intern, the gemdos calls are, if not very superfluous, explained there. Startup.bin takes standard all memory but 4K (that four K is for stuff like .RSC files!). You can however overrule this by assigning to the external variable _mneed, e.g.: int _mneed = 10240; main() { .... } As far as I understand it, the size of the spare room (above the bss, under the stack space) is now set to 10240. This spare room is typically used for mallocs etc. (the C mallocs, not the gemdos call!). For the stack something similar applies: the standard stack size is 2K, this is adequate if you don't do too weird things. You can overrule this by, analoguous to the _mneed variable, assigning to the variable _stack. Note that there are no checks against the stack overrunning the data space, so you should indeed use this variable when you need lots of stack space (sbrk will only allocate till the bottom of the stack segment). All this talk about _mneed and _stack you should be able to find in your Lattice manual. It also says that you always must link with startup.bin; this is not quite true; I have managed to link without it; it saves you K's! If you are interested, I'll describe how (C source). Hope you find these hints useful. Leo.
0ALEVI@POMONA.BITNET (05/11/89)
Date: 10 May 1989, 10:38:25 PDT From: 0ALEVI at POMONA To: INFO-ATARI16 at SCORE.STANFORD.EDU UNSUBSCRIBE INFO-ATARI16 UNSUBSCRIBE INFO-A16