Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!hyc From: hyc@math.lsa.umich.edu (Howard Chu) Newsgroups: comp.sys.atari.st Subject: Re: dissassembly Message-ID: <10665@stag.math.lsa.umich.edu> Date: 16 Jan 90 17:58:03 GMT References: <1534@cs.rit.edu> Sender: news@math.lsa.umich.edu Reply-To: hyc@math.lsa.umich.edu (Howard Chu) Organization: University of Michigan Math Dept., Ann Arbor Lines: 65 UUCP-Path: {mailrus,umix}!um-math!hyc In article <1534@cs.rit.edu> ajy2208%ritcv@cs.rit.edu (Albert Yarusso) writes: >>I mean, if a program breaks because a programmer takes advantage of an >>undocumented or illegal "feature" which isn't there at the next os revision, >>isn't that the programmer's fault? > >Hmm, this reminds me of what happened when Atari brought out the XL >operating system for the 8-bit computer.. A LOT of programs broke >because programmers did not follow the rules... So, make TOS 1.4 available on a boot disk. A LOT of XL Translators were available to address the problem, and they usually sufficed, except for the rare case where actual hardware differences got in the way. (Like the XL/XE's bank switching in place of 3rd & 4th joystick ports...) Why compromise when you don't need to - get the best possible system into production, and release it. But make sure moving up to the new system isn't a one-way trip - allow for using the old system when it's needed. >I have Mark Williams C, and am curious: What is the difference between >malloc() and Malloc() ???? I am writing a slideshow/picture viewing >program, and when I used malloc() to get a 32k block of memory for a >picture, the picture always had some stray data at the top (looked >suspiciously like the other variables I was using).. However, when I >used Malloc() this disappeared. Boy, I almost pulled my hair out >trying to figure out what was wrong!!! The MWC malloc() library routine uses MWC's own memory management setup. Since GEMDOS's Malloc call is potentially dangerous, and the danger increases as you approach 20 calls per program, the idea is to call the system memory allocator as few times as possible, and to handle the memory you *do* have to allocate by yourself. So the MWC library will typically start up with a "heap" of, say, 64K, that is parceled out to you whenever you use their malloc routine. If the heap is too small to satisfy your request, the library will call Malloc to add more memory to the heap. As for the stray data at the top, perhaps you're not aligning the screen memory correctly? And just as a side note... (Since I've spent the past couple of weeks getting my favorite programs, e.g. Uniterm, working with Overscan...) If you're writing code that you eventually hope for other people to use, don't hard-code magic numbers like 32K into your screen manipulation routines. [In fact, don't even use 32K. You only need, at most, 32256, to get 32000 bytes on a 256 byte boundary, eh?] Also don't assume that when you're looking at the default screen, Physbase and Logbase will be identical. Retrieve and store them both, when you want to do page-flipping. While I'm up here on my soapbox... Here's some code to properly align your screen memory. It seems simple enough, but I've seen it done wrong too many times... [And hey, if you see that *I'm* doing it wrong, let me know, quick, 'cause this is how I've been doing it!!] In C: char *ptr, *malloc(); ptr=malloc(32256); /* for argument's sake */ (long)ptr+=255; (long)ptr&=0xffffff00; In asm I'd do something like (Malloc returns to d0...) clr.l d1 st.b d1 add.l d1,d0 sf.b d0 -- -=- PrayerMail: Send 100Mbits to holyghost@father.son[127.0.0.1] and You Too can have a Personal Electronic Relationship with God!