mil@mendel.acc.Virginia.EDU (Maria I. Lasaga) (08/28/90)
Many thanks to those of you who helped me figure out what I was doing wrong
in the code I posted previously. Basically, I was using @ to set a pointer
to the global variable ScrnBase rather than Pointer(). I was also using $727
as the base address for the alternate memory buffer, and so I was writing over
other important system info; I should have been using $72700.
Now, I have set a pointer to the memory location ($824) correctly. To do
so, I have used a handle, because the memory location $824 contains an
address itself, which is what I want to change.
So, I set my handle as a pointer to the location ($824). I know this works,
because when I check with Lightsbug (Think Pascal debugger) it tells me that
the value of MyHandle^ is the same as screenbits.baseaddr. So I know that I
have set up a handle that points to the location $824 which did, indeed,
contain the memory location of the main screen buffer.
Here's where I now run into a STRANGE problem. When I then try to set
MyHandle^ as a pointer to memory location $727000 (the base for the alternate
screen buffer) instead of what $824 had originally pointed to, it doesn't
work, but in an odd way: When I check with Lightsbug, it tells me that
MyHandle^ is still the _same_ as screenbits.baseaddr. But when I use the
Instant window and ask it to write the value of MyHandle^, it correctly
tells me that it is $727000. What's going on? Can anyone give me a clue?
(I list the short code I am using below.)
Any help would be greatly appreciated. I am very frustrated with this
problem. I don't get why Apple doesn't put out a tech note on how to
use the alternate video buffer on the "lower" macs. Granted, the Mac II's
don't have an alternate buffer, but not everyone is into software development
for use on all machines. Besides, there is a lot of software available
that doesn't run on the earlier macs. Why not allow us to develop some
software that doesn't run on the Mac II? I myself purchased an SE because it
had an alternate slot to which I could attach an external monitor, and
because it had an alternate video buffer. I need to use these two options
for research purposes. Yet I can't find documentation anywhere that tells
me how to take advantage of either of these two options!! I may as well
have purchased a Mac Plus. (I wish I could have afforded a Mac II.)
Allright, enough venting. ANY help on figuring out how to access
the alternate screen buffer of an SE, or on what is wrong with the following
code, would be welcomed:
TYPE
ahandle = ^ptr;
VAR
MyHandle: ahandle;
BEGIN
MyHandle := pointer($824); { the location of the global variable, }
{ ScrnBase, that holds the address of }
{ the main screen buffer. }
MyHandle^ := pointer($72700); { Attempt to set ScrnBase to the address }
{ of the alternate screen buffer.}
END.
--------------------------------------------------------------------------
Maria Lasaga
Dept. of Psychology
Gilmer Hall
University of Virginia
Charlottesville, Virginia 22903 mil@virginia.bitnet
--------------------------------------------------------------------------chewy@apple.com (Paul Snively) (08/29/90)
In article <1990Aug27.170838.199@murdoch.acc.Virginia.EDU> mil@mendel.acc.Virginia.EDU (Maria I. Lasaga) writes: [Code intended to help in using the alternate screen buffer deleted] > Any help would be greatly appreciated. I am very frustrated with this > problem. I don't get why Apple doesn't put out a tech note on how to > use the alternate video buffer on the "lower" macs. That's easy. The Tech Notes are basically concerned with correcting errors in Inside Macintosh, with documenting new features as they come out (rather than waiting for a new Inside Macintosh), and for addressing misunderstandings, especially when they lead to software incompatibilities across the various machines/system software combinations. Since the primary application of the alternate screen buffer is for games, it just hasn't gotten that high a priority for us, even though it is definitely a source of confusion and compatibility problems (for example, you can't just point the screen to the alternate screen buffer; you also have to set a bit on the VIA). However, the alternate screen buffer, along with code to utilize it, is presented very well in one of MacTutor Magazine's anthologies of back issues. The article is by Mike Morton, and I highly recommend it. > Granted, the Mac II's > don't have an alternate buffer, but not everyone is into software development > for use on all machines. Very true, but our job is basically to support Apple Partners who, for the most part, _do_ do development for use on all Macintoshes. Of course, the academic environment (among others) is different, and we're trying to find ways to effectively address that. (There are only about 35 or so of us and about 7,000-8,000 partners.) > Besides, there is a lot of software available > that doesn't run on the earlier macs. How much is "a lot?" And how much of this is just taking advantage of (necessary) new features, i.e. natural evolution? We're essentially opposed to the development of software that doesn't work across machines for gratuitious reasons (note that this is a statement of personal opinion; your milage may vary). > Why not allow us to develop some > software that doesn't run on the Mac II? No one is stopping you; rather, by pointing you to a source of the information, I am trying to help you. However, I must admit that I find your railing about _us_ not being the source of the information vexing. > I myself purchased an SE because it > had an alternate slot to which I could attach an external monitor, and > because it had an alternate video buffer. I need to use these two options > for research purposes. Yet I can't find documentation anywhere that tells > me how to take advantage of either of these two options!! It's true that the sum total of information about Macintosh programming is scattered all over. We're working on ways to consolidate it. The Developer CD is a good example--IM I-V, the Tech Notes, sample code, etc. all in one place. It's worth the price of the CD-ROM drive, in my opinion. > ------------------------------------------------------------------------- - > Maria Lasaga > Dept. of Psychology > Gilmer Hall > University of Virginia > Charlottesville, Virginia 22903 mil@virginia.bitnet > ------------------------------------------------------------------------- - __________________________________________________________________________ Paul Snively Macintosh Developer Technical Support Apple Computer, Inc. chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that I believe what they believe, or vice-versa. __________________________________________________________________________
mil@mendel.acc.Virginia.EDU (Maria I. Lasaga) (08/29/90)
In article <9954@goofy.Apple.COM> chewy@apple.com (Paul Snively) writes: > > In article <1990Aug27.170838.199@murdoch.acc.Virginia.EDU> > mil@mendel.acc.Virginia.EDU (Maria I. Lasaga) writes: > >> Any help would be greatly appreciated. I am very frustrated with this >> problem. I don't get why Apple doesn't put out a tech note on how to >> use the alternate video buffer on the "lower" macs. > > That's easy. The Tech Notes are basically concerned with correcting > errors in Inside Macintosh, with documenting new features as they come out > (rather than waiting for a new Inside Macintosh), and for addressing > misunderstandings, especially when they lead to software incompatibilities > across the various machines/system software combinations. > There are tech notes that amplify information that is available in Inside Macintosh, such as how to optimize copybits. I don't think that information that amplifies how to use the alternate screen buffer would be inappropriate. There is only one reference as to how to do so in IMIII-20. Please don't get the wrong idea. I think the IM volumes are great. This happens to be one problem I have had for which I have found very little documentation anywhere. > Since the primary application of the alternate screen buffer is for games, > it just hasn't gotten that high a priority for us, even though it is > definitely a source of confusion and compatibility problems (for example, > you can't just point the screen to the alternate screen buffer; you also > have to set a bit on the VIA). > I disagree that the primary application of the alternate screen buffer is for games. There are many scientific applications that require rapid displays of images. In fact, there are several articles available in academic journals that describe ways to optimize how quickly a bit-mapped image is displayed on a Mac screen. Unfortunately, we are dealing with complex images and need to use an alternate screen buffer. This is a very common operation used by many of my colleagues nationwide who use IBM PC's in their research. I happen to prefer the Macintosh system. I know of at least some other colleagues who use Macs who could use some illumination on how to switch between a main and an alternate screen buffer of a Mac. I don't think I am alone in academia. > However, the alternate screen buffer, along with code to utilize it, is > presented very well in one of MacTutor Magazine's anthologies of back > issues. The article is by Mike Morton, and I highly recommend it. > Great. Can I bother you for the date of the article? I don't subscribe to MacTutor, and will need to borrow a copy. >> Granted, the Mac II's >> don't have an alternate buffer, but not everyone is into software > development >> for use on all machines. > > Very true, but our job is basically to support Apple Partners who, for the > most part, _do_ do development for use on all Macintoshes. Of course, the > academic environment (among others) is different, and we're trying to find > ways to effectively address that. (There are only about 35 or so of us > and about 7,000-8,000 partners.) > That would be great if a little more emphasis would be placed on assisting software development in the academic environment. I think there might be more individuals who would switch from IBM PC's to macs in the academic world if more support were provided. I could be wrong. >> Why not allow us to develop some >> software that doesn't run on the Mac II? > > No one is stopping you; rather, by pointing you to a source of the > information, I am trying to help you. However, I must admit that I find > your railing about _us_ not being the source of the information vexing. > My frustration comes from trying to request help several times on the network, from buying numerous books that supposedly might help, etc., but not really getting anywhere. I am not a computer scientist or engineer by training, so that is probably a large part of the problem. It just seems to me that the ability to use an alternate screen buffer is a good capability that should be better documented. However, it seems from your message that few individuals other than myself or those that develop games for the mac have any use for the alternate screen buffer. So perhaps I shouldn't be complaining about the lack of documentation. >> I myself purchased an SE because it >> had an alternate slot to which I could attach an external monitor, and >> because it had an alternate video buffer. I need to use these two options >> for research purposes. Yet I can't find documentation anywhere that tells >> me how to take advantage of either of these two options!! > > It's true that the sum total of information about Macintosh programming is > scattered all over. We're working on ways to consolidate it. The > Developer CD is a good example--IM I-V, the Tech Notes, sample code, etc. > all in one place. It's worth the price of the CD-ROM drive, in my opinion. > Again, please don't get me wrong. I think that Apple does a very good job of providing support for software developers, and this in spite of the many changes in Macintosh hardware over the years. I happen to think that there is an important though maybe small void in the documentation that merits filling: how to use the alternate screen buffer of earlier macs. > > __________________________________________________________________________ > Paul Snively > Macintosh Developer Technical Support > Apple Computer, Inc. > > chewy@apple.com > > Just because I work for Apple Computer, Inc. doesn't mean that I believe > what they believe, or vice-versa. > __________________________________________________________________________ > > ------------------------------------------------------------------------- Maria I. Lasaga Dept. of Psychology Gilmer Hall University of Virginia Charlottesville, Virginia 22903 mil@virginia.bitnet -------------------------------------------------------------------------
lemke@radius.com (Steve Lemke) (08/29/90)
chewy@apple.com (Paul Snively) writes: >It's true that the sum total of information about Macintosh programming is >scattered all over. We're working on ways to consolidate it. The >Developer CD is a good example--IM I-V, the Tech Notes, sample code, etc. >all in one place. It's worth the price of the CD-ROM drive, in my opinion. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sure is, especially when that CD-ROM drive can sit on an AppleShare server, with the latest Developer CD in it, available to an entire engineering department (or entire company, depending on how the server is set up, though in our case the server is for engineering only). There have been many times when I have been looking for some tidbit of information or some file, and I just KNOW that it's on the CD-ROM. I'd like to publicly thank Apple for putting together such a great resource for the developer community - keep it up! One minor complaint (you KNEW there was a catch, right?): In the past, OnLocation files were included on the CD (and on the latest one, the old OnLocation files are STILL there), but there is no file for the PRESENT disc. Yes, it says I can build it myself, but I don't want to! Since the CD _IS_ on a file server, even though it's on Ethernet, it would take forever to build the stupid index. How long would it REALLY have taken (on a IIfx, with a hard disk-based pre-release of the CD-ROM) to build the index? OK, that was basically it. I still like the CD, it's just that there's SO much information on it, it's sometimes hard to find stuff... --Steve -- ----- Steve Lemke, Engineering Quality Assurance, Radius Inc., San Jose ----- ----- Reply to: lemke@radius.com (Note: NEW domain-style address!!) -----
jackiw@cs.swarthmore.edu (Nick Jackiw) (08/29/90)
Enough bickering!
From "Pascal Procedures: Alternate Video Screen Animation," by Mike
Morton (then at Lotus), pp. 242-247, The Complete MacTutor Vol 2:
(a) Make sure you don't have the RAM Cache on. The Cache overlaps the
alternate vid screen on a plus.
(b) You must be prepared to relaunch yourself if launched without the
second-screen capacity. In that Finder doesn't launch you with second-
screen capacity, this step seems crucial.
(c) Do a HideCursor before switching.
(d) Switch to the mainscreen before quitting.
Condition (b) may be difficult to overcome when running under Lightspeed,
because Lightspeed--not your program--is the application. Solution:
Build Application and run it from the finder, instead of "testing" in
Lightspeed.
From the source code he gives in assembly, I gather that the
command to show either the default page or the alternate page is a bit-
toggle on the VIA. You want Pascal.
const ViaBase=$1D4; {Contains the base address of via}
type PtrPtr=^ptr;
var theViaByte:ptr;
begin
theViaByte:=PtrPtr(ViaBase)^;
theViaByte:=ptr(ord(theViaByte)+$1E00); {Offset to the magic control}
{To show the alternate screen, when default screen is showing}
theViaByte^:=theViaByte^-64; {BCLR #6,$1E00(VIA)}
{To show the default screen, when the alternate is showing}
theViaByte^:=theViaByte^+64; {BSET #6,$1E00(VIA)}
end;
------
Presumably the reason you can't set the alternate screen up is that
Lightspeed wasn't launched with the request to allocate space for it.
Whether Lightspeed will continue to work if you *do* launch it with
that request is a question perhaps Rich can answer. If not, your
only recourse seems to be, as I mentioned above, running your program
*outside* of the THINK environment.
Disclaimer: This code was composed in vi. I've never touched the
alternate video screen. Flamefests, however, grow boring quickly
for nonparticipants.
--
------------------------
Nick Jackiw jackiw@cs.swarthmore.edu "We are what we think,
Visual Geometry Project jackiw@swarthmr.bitnet having become what wehawley@adobe.COM (Steve Hawley) (08/30/90)
I posted an article about a week ago that contained C source for how to use the alternate screen buffer, and how to make it work correctly within QuickDraw(). Did this not reach you? Steve Hawley hawley@adobe.com -- "I can always telephone, but I can't tell it much." -Roy Blount
chewy@apple.com (Paul Snively) (08/31/90)
In article <1990Aug29.022048.674@murdoch.acc.Virginia.EDU> mil@mendel.acc.Virginia.EDU (Maria I. Lasaga) writes: > There are tech notes that amplify information that is available in > Inside Macintosh, such as how to optimize copybits. I don't think > that information that amplifies how to use the alternate screen > buffer would be inappropriate. Neither do I--especially if it were to be in conjunction with information about how to do page-flipping on Macintosh II family video cards that are capable of it. Again, a priority (for us) is to provide information that's useful across the line. > I disagree that the primary application of the alternate screen buffer > is for games. In academia, I'm sure that you're correct. I should have been clearer and said that among the folks whose questions we see the most, the primary application seems to be... > This is a very common operation used by many of my colleagues > nationwide who use IBM PC's in their research. I happen to prefer > the Macintosh system. I know of at least some other colleagues who use Macs > who could use some illumination on how to switch between a main and an > alternate screen buffer of a Mac. I don't think I am alone in academia. I'm certain that you aren't, and I agree that the information is quite useful. Hopefully you found some of the other followups helpful. > > However, the alternate screen buffer, along with code to utilize it, is > > presented very well in one of MacTutor Magazine's anthologies of back > > issues. The article is by Mike Morton, and I highly recommend it. > > > > Great. Can I bother you for the date of the article? I don't subscribe > to MacTutor, and will need to borrow a copy. One of our fellow netters posted the info. > That would be great if a little more emphasis would be placed > on assisting software development in the academic environment. I think > there might be more individuals who would switch from IBM PC's to > macs in the academic world if more support were provided. I could be > wrong. Actually, from the consortium onward, I'd always felt that our approach to higher education was pretty good--although we certainly are exploring ways to make it better. We have several Apple Partners who are academics, and hopefully they find being Partners worthwhile. (For example, most of the Macintosh Allegro Common Lisp questions that I see are from either academic or government sites.) > However, it seems from your message that few individuals other than > myself or those that develop games for the mac have any use for the > alternate screen buffer. So perhaps I shouldn't be complaining > about the lack of documentation. Well, it can certainly be tough to find what you want/need to know among the tons of stuff about the Mac that exists, whether it's got an Apple label on it or not. Certainly my opinion is that MacTutor is an extremely valuable non-Apple-affiliated resource for Mac programmers. I hope that the other followups have helped you! __________________________________________________________________________ Paul Snively Macintosh Developer Technical Support Apple Computer, Inc. chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that I believe what they believe, or vice-versa. __________________________________________________________________________
chewy@apple.com (Paul Snively) (08/31/90)
In article <1311@radius.com> lemke@radius.com (Steve Lemke) writes: > In the past, > OnLocation files were included on the CD (and on the latest one, the old > OnLocation files are STILL there), but there is no file for the PRESENT > disc. Yes, it says I can build it myself, but I don't want to! Since > the CD _IS_ on a file server, even though it's on Ethernet, it would take > forever to build the stupid index. How long would it REALLY have taken > (on a IIfx, with a hard disk-based pre-release of the CD-ROM) to build > the index? The issue is certainly one of time, just not of the time it takes to build the index. A while back, the Electronic Media Group of Developer Press indexed the CD (I believe it was the release "Phil and Dave's"). They had been led to believe that building the index and then changing a file or two would have no ill effect on the index, so the CD went final AFTER the index had been built and AFTER a change of a few words had been made to a text file. Guess what? Sure enough--the index was totally useless. Can you say "once bitten, twice shy?" The great folks in the EMG have enough blood, sweat, and tears shed getting the CD out the door without going through that experience again, and since things really do get down to matters of hours when they go final, they just can't index the beast with any assurance that something won't have to change after that. So you're on your own for indexing the current CD. To be fair about it, so's everyone else! What I do when I get the new CD is start indexing on my IIx before I go home some evening; that way the index is waiting for me the next day. It's not too painful. (In your case, you should index on a local machine, of course, rather than over the network.) __________________________________________________________________________ Paul Snively Macintosh Developer Technical Support Apple Computer, Inc. chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that I believe what they believe, or vice-versa. __________________________________________________________________________