Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!columbia!rutgers!caip!clyde!cbatt!cwruecmp!bammi From: bammi@cwruecmp.UUCP (Jwahar R. Bammi) Newsgroups: net.micro.atari16 Subject: Re: BAMMI's MAKE and ST <-> CPM Message-ID: <1591@cwruecmp.UUCP> Date: Sat, 4-Oct-86 04:07:37 EDT Article-I.D.: cwruecmp.1591 Posted: Sat Oct 4 04:07:37 1986 Date-Received: Mon, 6-Oct-86 18:34:56 EDT References: <8610031214.AA21791@ucbvax.Berkeley.EDU> Reply-To: bammi@cwruecmp.UUCP (Jwahar R. Bammi) Organization: CWRU Dept. Comp. Eng., Cleveland OH Lines: 162 Newsgroups: net.micro.atari16 Subject: Re: BAMMI's MAKE and ST <-> CPM Summary: Expires: References: <8610031214.AA21791@ucbvax.Berkeley.EDU> Sender: Reply-To: bammi@cwruecmp.UUCP (Jwahar R. Bammi) Followup-To: Distribution: Organization: CWRU Dept. Comp. Eng., Cleveland OH Keywords: In article <8610031214.AA21791@ucbvax.Berkeley.EDU> RDROYA01@ULKYVX.BITNET (Robert Royar) writes: >The following code fragments are from the bammi@case MAKE.PRG. > ...... > >struct name namehead = { > (struct name *)NULL, > (char *)NULL, > (struct line *)NULL, > (time_t)0, > (uchar)0 > }; > >I have been unable to get the program working. The program exits with >a "no memory for macro" error and the touch program "touches" all >files back to the date that TOS was born (i.e. midnight sometime in >November 1985). So question one is, "has anyone other than those at >CASE gotten this program to work?" > I know of alteast 2 dozen people who have gotten make to work outside of CASE, and with various compilers (lattice, megamax). I ran it through Mark Williams too, and it works just fine. Most people who have been having problems with 'no memory ...' type of errors, have been making the mistake of linking make with the version of gemstart.o that was distributed with the development system. That particular version only reserves 1K for stack+heap, and gives the rest back to the system. All that is needed is that you edit gemstart.s and on the line that reads add.l #$500,d0 * d0=basepage+textlen+datalen+bsslen * (plus 1K of user stack) and change the $500 to some much larger number like $4000 (16k). Better yet, use the new gemstart.s available on CompuServe, that has the various memory models. I hope that this is your problem. As far is touch goes, both the stand alone touch program, and the touch function within make, get the current time from the IKBD and not from Gem's counters. So if you only set the current time via the control panel, and have not set the IKBD's time (they are independent counters, and the control panel acc. does not set the IKBD time) the time you will get will be wrong. I am almost certain, from your description of the problem, that this is the case. The reason i chose to read the time from IKBD rather than from Gemdos is that the IKBD clock survives resets, while the Gemdos clock does not. Besides, i have long ago, thrown away the control panel accessory. To set the IKBD clock there are atleat a dozen PD programs. Many of them sit in the auto-folder. Almost all of them set both the counters. -My second question has to do with the last cast in the structure -initializer. Here's the scenario. My dev pack has been ordered and -should arrive next week, so I compiled the code with the CP/M-68K -compiler (which is identical to the early ST version right down to the -serial numbers). I had a friend compile it on the ST with his DEV -pack and he got the same errors. The early Alcyon compiler only -supports unsigned ints, so uchar is defined as char in a header file. -But the code parser (c068) balks at the coercion with the error -"invalid initializer" which means I tried to init a variable with -something other than a constant. Even the cast (char)'\0' got the -same error. Now I know the last element of that structure has to be a -character constant or the structure will not be filled properly. - -The code generated for a structure like this goes ahead and fills the -remainder of the space to allign on a word boundary, but the size of -the last element determines how that element will actually be stored -and accessed. Structure initialization and size has been a known bug -in the Alcyon compiler at least since 1983. One problem with this -structure is that all of the beginning elements are 32 bits long. -Alcyon has trouble, and always had, with structures or function -parameter lists that all have the same (long) size. All of the above comments are appreciated. I think you will find that the new version of Alcyon V2.14 handles structures quite well. Maybe i should have checked with my old compiler disks, but i did'nt since the new version had been out for more than a couple of months when this article was posted. I guess (have'nt tried) you can go ahead and declare uchar as an int, and just put a '0' for the last initializer, and it should tide you over till you get your devl system. Sounds like your friend needs to get the dev. sys. upgrade too. -Another minor beef. If you - -#define uchar char - -Sometines the preprocessor has trouble in an expansion that involves a -cast. If you - -#define void - -casts again can lead to difficult to track errors. Is there a reason -to avoid typedef in these situations? Why not use - -typedef uchar char; -typedef void int; /* after all Alcyon expects int returns by default */ - /* even when none are specified. Check the stack */ - /* popping code it produces after a jsr */ - voids are NOT int's. V2.14 supports voids just fine. I just tried a small example. It does not produce any extraneous code. Besides the stack popping code is there to pop the arguements off the stack. A value, if any, is returned in d0, so the stack popping code has nothing to do with the type of value returned by a function. I think 'typedef void int' is a bad idea, as any compiler (such as v2.14) will complain because void is now a reserved word, and can't be used as an identifier. I do throughly agree on your point about using casts. Typedefs should be used when possible (see comment below too). >Defines are hard to track down in a preprocessor output file because >they all dissapear. But a typedef follows through that output, and >you can see what a cast or value is. DRI used to > >#define FILE struct _iobuf > >That made a file definition bug a real bear to find. However, > >typedef FILE struct _iobuf; > >is more logical and closer to the intentention of using FILE >structures in the first place. > Totally agree on the above point. Since i ported neil's code i just followed the same style. I usually do use typedefs. >While I'm on the DRI soapbox. I compared the AR68 output for gemlib >to that for the old clib libraries (is AR68 available for the ST >yet?). Yes, a working version comes with the dev. sys. update. there is also a Pd version available. > ..... >effort to move to the ST. It's ridiculous that there's no equivalent >to "real" xmodem i.e 1024 packets, true CRC, batch files, 19200 baud, >scripts, etc. in the ST PD library. 19200 is great for moving files >between the ST and your other computer, whatever that may be. > I routinely use xmdm to transfers files and in terminal mode at 19.2K. One of the person's here has also implemented chuck fosberg's (sp ?) Ymodem protocol (rz/sz) and that handles 1K packets pretty well. Hopefully it will have adapting windows one day. I agree that we could use PD gems from the Cp/m world too. So as the old saying goes "Put your money where your mouth is" and post some! -- usenet: .....!decvax!cwruecmp!bammi jwahar r. bammi csnet: bammi@case arpa: bammi%case@csnet-relay compuServe: 71515,155