bk19#@andrew.cmu.edu (Bradley D. Keister) (05/15/87)
To: outnews#ext.nn.comp.lang.pascal@andrew.cmu.edu I'm having trouble getting a Turbo inline procedure to find the parameters passed to it. The procedure is an attempt to produce a hardcopy of a Hercules graphics display without resetting the printer at the end (as the Hercules Co version does) and is not as slow as what comes with the Graphix ToolBox, and will allow for printing part of the screen. I've dimensioned an array for a single print line (8 bits high) in a calling procedure (NOT in the main program) which then calls the inline code to map the bits into this array. The Turbo Reference Manual states that local variables are placed in the stack with an offset relative to the BP register. That's fine, but the contents of BP changes when one procedure calls another. I've tried using variable parameter passing and other approaches short of transferring the entire array to the inline code (which tends to defeat the purpose of it), but the array never is where I think it is. I'm not very experienced with PC Assembler, but the inline code comes from an assembly version which I got to run correctly. It simply sets BP to the bottom of the stack segment and is never changed. My questions are: 1. How do I locate (a) local variables; (b) variable parameters; (c) value parameters which are passed from a procedure which itself is not the main program? If the calling program passes a segment address and an offset, to what does the offset refer? It would be nice to be able to locate the parameters without having to draw a memory map of all of the variables involved... 2. Is there a difference between scalars and (the first byte of) arrays in any of the above? A simple program which illustrates the correct procedures would be most helpful. On a related matter, I'm also working on the inline code for printing the graphics directly, rather than using the Turbo write procedure. I've noticed that both the Graphix HardCopy is considerably slowed down by writing to LST (which requires that each byte be converted to char type, because LST is apparently automatically a text file). Also, the Turbo version of UUDECODE is considerably slower than the compiled C version, and it also relies of writing to a text file one byte at a time. Is there a way within Turbo to force buffered I/O and override the conversion of type between "byte" and "char"?