ressler@galileo.ifa.hawaii.edu (Mike "IR" Ressler) (03/11/91)
Greetings. I hope this post isn't too far out of line with this newsgroup. Before I put an axe through my new 386, I thought I'd ask y'all a few questions. What I want to do: write software (in C) to reduce and display astronomical images on my 386. These images will be floating point up to 512x512 (1 Mbyte each). The code (and executable) does not have to be at all portable since it will never go beyond my machine and I would like to maximize the number crunching speed, thus I would like to compile in 386 protected mode, if possible. Also, being able to display with a 256 level grayscale or false color palette is mandatory. What I've got to do it with: 33 MHz 386 running DOS 4.01, FP coprocessor, 1024x768x256 color monitor and graphics card (Diamond SpeedSTAR VGA v. 3.10 with 1 Mbyte RAM), 4 Mbyte RAM (with room for plenty more), 135 Mbyte hard disk, etc. Specific questions: Do any compilers out there compile real, honest-to-God, 386 instructions as opposed to only 286 and lower? What things do I need so I can do a malloc for 1 Mbyte? Any compilers know how to talk to the SpeedSTAR card so I can get 1024x768x256 as opposed to 640x480x16? Any advice on how to put the software together for not too many dollar$ would be greatly appreciated - I'm a starving grad student, etc. I've played with Microsoft C 6.0 and Turbo C++ and neither were close to satisfactory (the user interfaces are fine; they just won't talk to my video board or produce 386 optimized instructions). QEMM seemed to make PCWrite barf (what does "packed file is corrupt" mean?) while Microsoft didn't tell me much of anything about the extended memory stuff they included with DOS 4.01. So I'm very confused, frustrated, and seriously wondering if I spent a lot of money on a machine that won't do what I want it to do anyway. Again, any useful advice will be very greatly appreciated. Please e-mail (preferred for bandwidth considerations) or post. Thanks. P.S. Could someone please explain to me the following Microsoft device drivers included with DOS 4.01? Why should or shouldn't I use them? Yes, I RTFM, but half of them weren't even mentioned in the manual. (I do understand smartdrive and ramdrive, but any extra hints will be greatly appreciated.) emm386.sys, himem.sys, xma2ems.sys, smartdrive.sys, ramdrive.sys -- Mike Ressler - Infrared Photon Jockey ressler@galileo.ifa.hawaii.edu If at first you don't succeed, get a bigger sledgehammer.
bobmon@iuvax.cs.indiana.edu (RAMontante) (03/12/91)
ressler@galileo.ifa.hawaii.edu (Mike "IR" Ressler) <11886@uhccux.uhcc.Hawaii.Edu> : | video board or produce 386 optimized instructions). QEMM seemed to make | PCWrite barf (what does "packed file is corrupt" mean?) while Microsoft I got this same message with one of Anarkey's support programs (to load macros; it's non-resident), only when the resident portion was loaded into high memory. Strange... however, the message refers to the program being "packed" by Microsoft's PACK.EXE or whatever it's called. I unpacked the executable, and the result runs fine whether Anarkey is loaded in high memory or the 640K stuff. The UPACKEXE.EXE unpacker that I used came with the LZEXE executable-compressing program (great program, and I get to practice my French too :-) --- so I tried running the problem program through LZEXE and the result *also* works fine in either high mem. or 640K. And the result is far far smaller than the PACKed original. You might try unpacking PCWrite; you might also try LZEXE compressing it to see how you like that. | emm386.sys, himem.sys, xma2ems.sys, smartdrive.sys, ramdrive.sys My vague understanding is that the first three manage extended memory on a 386, allow access to the RAM between 640K and 1M, and [do something pretty much neato keeno]. QEMM takes the place of all three of them.
joe@proto.com (Joe Huffman) (03/13/91)
ressler@galileo.ifa.hawaii.edu (Mike "IR" Ressler) writes: >Specific questions: Do any compilers out there compile real, honest-to-God, >386 instructions as opposed to only 286 and lower? What things do I need so >I can do a malloc for 1 Mbyte? Any compilers know how to talk to the >SpeedSTAR card so I can get 1024x768x256 as opposed to 640x480x16? Zortech C/C++ can give you 386 code with the PharLap DOS extender. The graphics library (which I wrote) currently does not support a 512 x 512 x 256 simultaneous color mode. But if your graphics board supports VESA then the high resolution (greater than 320 x 200) 256 color modes will be supported soon. If it doesn't support VESA then either you can easily make the driver yourself (example C code for 320 x 200 x 256 colors is supplied) or send me the technical information and I might be persuaded to support the desired mode myself... To malloc 1 Mbyte with Zortech C/C++ with the PharLap DOS extender: #include <stdio.h> #include <stdlib.h> #define BUF_SIZE 1000000 int main() { char *p = malloc(BUF_SIZE); if(p) { printf("malloc(%d) succeeded.\n", BUF_SIZE); free(p); } else fputs("malloc() failed.\n", stdout); return 0; } >Any advice on how to put the software together for not too many dollar$ >would be greatly appreciated - I'm a starving grad student, etc. I've Zortech gives educational discounts to people that have .EDU in their email address. Call 800-848-8408 and ask for Renee to order (or to get information). --- Zortech mailing list: send email to 'ztc-list-request@uunet.uu.net' with: Add: your-user-name@your-machine-name In the body of the message. --- Send Zortech bug reports to 'zortech-bugs@zortech.com' Send requests for educational discounts to 'zortech-ed@zortech.com' --- Zortech is my major source of income. Statements about them or their competitors cannot be totally without bias. -- joe@proto.com
osmoviita@cc.helsinki.fi (03/18/91)
In article <1991Mar12.174602.25258@proto.com>, joe@proto.com (Joe Huffman) writes: > > Zortech C/C++ can give you 386 code with the PharLap DOS extender. The > graphics library (which I wrote) currently does not support a 512 x 512 x > 256 simultaneous color mode. But if your graphics board supports VESA > then the high resolution (greater than 320 x 200) 256 color modes will be > supported soon. If it doesn't support VESA then either you can easily make > the driver yourself (example C code for 320 x 200 x 256 colors is supplied) > or send me the technical information and I might be persuaded to support > the desired mode myself... > When will that be available (V. 2.2 ?)? I hope it supports all VESA modes. And double buffering functions for cards with enough memory e.g. 1 MB card in 800x600x256 or 640x480x256 mode. 512x512x256 color mode support would be nice for me too (with use of 1024x1024x256 image memory and 512x512 window). VESA support is really important, but in addition to that there could be drivers for most common SuperVGAs which doesn't support VESA. GNU C/C++ 386 compiler supports cards based on Tseng 3000 and 4000 chips. It sounds too hard to start writing a driver if one wants to buy a compiler to make graphics programs without any knowledge of the graphics hardware or being novice in C/C++. > Zortech gives educational discounts to people that have .EDU in their email > address. Call 800-848-8408 and ask for Renee to order (or to get Only in U.S.A. :-( ? Kari Osmoviita
joe@proto.com (Joe Huffman) (03/20/91)
osmoviita@cc.helsinki.fi writes: >In article <1991Mar12.174602.25258@proto.com>, joe@proto.com (Joe Huffman) >writes: >> >> Zortech C/C++ can give you 386 code with the PharLap DOS extender. The >> graphics library (which I wrote) currently does not support a 512 x 512 x >> 256 simultaneous color mode. But if your graphics board supports VESA >> then the high resolution (greater than 320 x 200) 256 color modes will be >> supported soon. If it doesn't support VESA then either you can easily make >When will that be available (V. 2.2 ?)? I hope it supports all VESA modes. It won't support all of them (I'm not sure that any board supports all of them). But it will support some of the high resolution (>= 800 x 600) 256 color modes. >And double buffering functions for cards with enough memory e.g. 1 MB card >in 800x600x256 or 640x480x256 mode. 512x512x256 color mode support would be >nice for me too (with use of 1024x1024x256 image memory and 512x512 >window). VESA support is really important, but in addition to that there >could be drivers for most common SuperVGAs which doesn't support VESA. Double buffering functions in not planned at this time. Several Super VGA boards are currently supported including: Orchid Pro Designer With multi-freq monitor, 800x600x16 colors (mode 0x29). Paradise VGA Plus With multi-freq monitor, 800x600x16 colors (mode 0x58). Trident 8900 With multi-freq monitor, 800x600x16 colors (mode 0x5B). Video 7 VEGA VGA With multi-freq monitor, 800x600x16 colors (mode 0x62). Diamond Flower Inst With multi-freq monitor, 800x600x16 colors (mode 0x64). VESA (multi vendor) With multi-freq monitor, 800x600x16 colors (mode 0x6A). Everex EVGA With multi-freq monitor, 800x600x16 colors (mode 0x70). >It sounds too hard to start writing a driver if one wants to buy a compiler >to make graphics programs without any knowledge of the graphics hardware or >being novice in C/C++. There are about 4 functions that you have to write in order to make a crude (slow) driver with FG. fg_init_YOUR_BOARD(), fg_term_YOUR_BOARD(), fg_YOUR_BOARD_drawdot(), and fg_YOUR_BOARD_readdot(). If in addition you write a fast fg_YOUR_BOARD_drawline() for the case of horizontal lines then you will make a significant speed up for the library as a whole. >> Zortech gives educational discounts to people that have .EDU in their email >> address. Call 800-848-8408 and ask for Renee to order (or to get >Only in U.S.A. :-( ? I'm not sure of the details. Send email to zortech-ed@zortech.com. I think it is available elsewhere. --- Zortech mailing list: send email to 'ztc-list-request@uunet.uu.net' with: Add: your-user-name@your-machine-name In the body of the message. --- Send Zortech bug reports to 'zortech-bugs@zortech.com' Send requests for educational discounts to 'zortech-ed@zortech.com' --- Zortech is my major source of income. Statements about them or their competitors cannot be totally without bias. -- joe@proto.com