spellbinder@uwav1.u.washington.edu (06/29/90)
Here is a compiler question for those programmers out in net-land.
I'm writing a Pascal procedure which performs some mathematical computations.
The procedure gets passed handles to the data, which look like this
type ArrayRecord = record
arraySize : longint;
signal : array [ 0..1 ] of real;
end;
ArrayRecordPtr = ^ArrayRecord;
ArrayRecordHdl = ^ArrayRecordPtr;
The procedure knows how much data there is by getting the arraySize variable.
Now I'm writing this code in THINK Pascal version 2.03. It works fine when the
amount of memory dedicated to the signal array is less than 32K, but when it
gets bigger than this, then things start to mess up. So basically, for array
sizes less than 8K data points, everything's fine. My idea is that THINK Pascal
has a problem getting a value at an offset greater than 32K from the start
of the variable. I have verified my idea by changing signal to become
an array of double and an array of extended and each time the procedure
craps out when the data exceeds 32K. My feeling is that the compiler is not
generating the correct code to access values beyond 32K.
My questions are this:
1) Is there another explanation for the problem?
2) Are there any work arounds in THINK Pascal version 2.03?
3) Will THINK Pascal 3.01 avoid the problem?
Thanks in advance.
Blair Zajac Zajac@phast.phys.washington.edu
Physics Dept.
University of Washingtonhopperj@dayton.saic.com (04/18/91)
In article <9822@etsu.CMI.COM>, davet@cmi.com (David Temkin) writes: > I'm developing an animated game for for the Mac which, because of > performance requirements, doesn't use QuickDraw. It works in 1-bit (black > and white) mode, as well as 2-bit mode. In black and white everything is > pretty much fine. But in 2-bit mode things sometimes get a bit flaky, and > I've been having problems with a variety of obscure (read non-sanctioned) > Mac graphics techniques. Would some kind (and knowledgeable) souls in > netland please read on and pass on any info they might have? > I wrote also wrote a replacement for quickdraw graphics routines for a special purpose (simulation of a graphics box) which has similar limitatioins as yours I found that the best way to maintaine compatability was to draw into an offscreen bitmap and blit to mac screen. I originally wrote to the video buffer as well, but i found same thing that you did, there was no real standard way to do this that worked well. > 1. The most serious problem I have manifests itself in 2-bit mode on some > machines, but not on others. The problem seems to be that my program > writes directly into the video buffer. This only works properly on SOME > configurations. > > On the Mac IIsi and the IIci and some fx configurations, there is no > apparent problem writing directly to video memory. But on other machines, > notably the vanilla Mac II, IIx, IIcx (each with the standard video cards) > and the LC, my program produces a distorted image (multiply overlaid > copies of the image, separated horizontally) on the top two-thirds of the > screen, and nothing below it. I'm using 24-bit addressing, but even if I > use 32-bit addressing (with SwapMMUMode) the result is the same. > (Incidentally, the new calls provided with 32-bit QuickDraw -- > GetPixBaseAddr and PixMap32Bit -- do not help. The addresses in question > are unchanged and apparently do not need to be addressed in 32 bit mode). > I considered the possibility that the problem may have something to do > with 32-bit clean ROMs, but (1) I have seen it work on a IIcx with a > different video card, and (2) there are no ROM calls involved -- all of > the graphics code is mine. > I had no trouble making this work with mac II, IIx, and IIcx using original toby frame buffer card. Things got more complicated when new graphics cards came out, and as i had moved on to offscreen bitmaps by this time i did not have to wory about this problem. I can look up my code and get back to you in email if you wish. the problem you discuss about the multiple images is because you are assuming an incorrect rowbytes i belive. in 2 bit mode rowbytes no longer equals pixels/8. > 2. For some reason, I have been unable to communicate with the video > drivers as specified in Designing Cards and Drivers. I'm interested in > using > the second video page in Macs that have them (apparently Mac IIs and > SE/30s may have them as well as the originals), and to determine whether > such a beast exists, I need to query the video driver using a Status call. > But it comes up nonsense. Here's the code in question (Think C): when i first did my code to talk directly to the mac video buffer (to get multi screen buffering) i had some problems due to a bug in the video driver (this was when the mac II first cam out) but i have had no problem since. like i said before email me if you want me to look into this further (code is at home right now). > > There are a number of problems with this method. First, relaunching in > this manner does not seem to be supported in System 7 or under > Multifinder. Second, I can't figure out from inside the program whether or > not the program has already been launched. The problem here is that if I'm > running under Multifinder or whatever and I cannot get possession of the > second screen, the program continues to launch itself, over and over, > without notifying the user (or itself) that there has been a problem. I'd > like to be able to take some intelligent action if I cannot gain > possession of the second screen. Ideas? > the way i have seen other programs solve this is with an init which alocates the alternate buffer at boot time before multifinder loads. Jim Hopper Hopperj@Dayton.SAIC.Com Applelink JimH
danny@utkux1.utk.edu (Danny W. McCampbell) (05/16/91)
Subject: Think Pascal 3.02 Bus Error.... Organization: University of Tennessee Computing Center I am still having problems with my program... I get a bus error when trying to run this chunk of code.... It is not because I dispose of the Handle with the DisposHandle call...I checked that... Why is the stupid thing crashing? Why? Why? Why? procedure Menus; begin ClearMenuBar; vBPMenuBar := GetNewMBar(BPMenuBar); SetMenuBar(vBPMenuBar); DisposHandle(vBPMenuBar); vAppleMenu := GetMHandle(AppleMenu); AddResMenu(vAppleMenu, 'DRVR');----Bus Error!!! DrawMenuBar; end; I have an SE/30 with 8 megs of ram running Sys 7.0.... Danny W. McCampbell Computer Operator/Systems Analyst University of Tennessee Office: (615) 974-0138
dwright@sif.claremont.edu (05/17/91)
In article <16286@helios.TAMU.EDU>, mkh6317@zeus.tamu.edu (HOWARD, MATTHEW KENDALL) writes: > I think it is pretty clear that at some point the FDHD images from > ftp.apple.com became damaged.... I believe that ftp.apple.com > crashed for a time around 3 to 4 am early Thursday. Perhaps that is > when the damaged occurred. I got my copy after that time. Bric-a-brac crashed at about 3:30 am PDT, as I was half-way through getting "tidbits-image.hqx". The images were bad before then. Gee, maybe they went bad during one of the previous 10,000,000 crashes since Monday ;-). - Dan dwright@sif.claremont.edu Harvey Mudd College '92, Claremont, CA Mac Systems Manager Opinions posted after 1 am may not even be mine, let alone anyone elses...
danny@utkux1.utk.edu (Danny W. McCampbell) (06/04/91)
Can someone tell me where I can get the newest version of MacsBugs or is legal for one of you to send it to me e-mail? Danny W. McCampbell Computer Operator/Systems Analyst University of Tennessee Office: (615) 974-0138
ury@mosque.huji.ac.il (ury segal) (06/23/91)
In article <1991Jun19.182613.15359@ux1.cso.uiuc.edu> Chuck Hoffman writes: >>In article <1991Jun19.182613.15359@ux1.cso.uiuc.edu> >jjz34245@uxa.cso.uiuc.edu (Cub Fan - Zim man) writes: >> >> Is there a program which will turn a mac into an X station? >Mac-X does this. >> If so, is this program available via anon FTP? >Mac-X is a commercial product. Or eXudos. But they both slow. --ury