palmieri@porthos.rutgers.edu (Tom Palmieri) (06/21/88)
I have an annoying problem. From within a Turbo Pascal V4.0 program, I am trying to use the IBM Graphics Printer's high-resolution graphics mode. All works fine after sending the correct escape sequence for this mode (ESC "L" n1 n2, n1+n2*256 = # of graphics bytes), but whenever I try to send ASCII 26 (control-Z, also EOF) as one of the graphics bytes, it never gets to the printer; and when I send *two* or more of them, the printer leaves graphics mode in the middle and prints, as you would expect, garbage text. HELP!!! Has anyone out there had a similar problem? Can anyone fill me in as to how he/she got around the problem? To answer a question which some of you may ask, I also tried this graphics print straight from DOS using a disk file and DOS "copy" with the same results. Any ideas? -- Tom Palmieri `Amigo' =============================== Mail Addresses ================================ UUCP: {backbone}!rutgers!aramis.rutgers.edu!palmieri ARPA: palmieri@aramis.rutgers.edu ===============================================================================
ajmyrvold@violet.waterloo.edu (Alan Myrvold) (06/23/88)
In article <Jun.20.22.02.56.1988.4465@porthos.rutgers.edu> palmieri@porthos.rutgers.edu (Tom Palmieri) writes: > I have an annoying problem. From within a Turbo Pascal V4.0 program, > I am trying to use the IBM Graphics Printer's high-resolution graphics > mode. All works fine after sending the correct escape sequence for > this mode (ESC "L" n1 n2, n1+n2*256 = # of graphics bytes), but > whenever I try to send ASCII 26 (control-Z, also EOF) as one of the > graphics bytes, it never gets to the printer I had the same trouble using Turbo C. DOS tries to interpret the special characters that you intend to be just data. Actually, using C, the first problem I had was that carriage returns were being sent as CR/LF pairs ... this messed up the graphics, of course. The best solution I found was to write a routine to send a character out to the printer using the BIOS function 17H, with AH=0 and AL=the character to send. For Turbo C, this is done easiest using the BIOSPRINT function. For Turbo Pascal, you might try the INTR routine. Good luck, Alan Myrvold ajmyrvold@violet.waterloo.edu ------------------------------------------------------------------------ C : the ultimate video game ------------------------------------------------------------------------
tj@gpu.utcs.toronto.edu (Terry Jones) (06/25/88)
uh, guys, try opening the device in binary mode. If you just do an open than you get character interpretations done. Now I don't do a lot of Turbo Pascal programming but In Turbo C (both of which I own... good products Borland) you can explicitly open a file as binary and if you want to use stdout as binary you need to use fileno then setmode to change the mode of it. (See if you find THIS in the documentation... poor docs here) (They tell you to use setmode in the 1.5 upgrade supplement but NOWHERE do they mention fileno.....) tj .
boba@hpwala.HP.COM (Bob Alexander) (06/27/88)
What a coincidence! I ran into this same problem using Turbo C just this weekend. I tried openning the printer in binary mode, but that didn't help. I tried using a printer redirection program to look at what was being sent and found that Turbo C is correctly sending the CTRL-Z. I assume your Turbo Pascal is sending the right code, too. So the problem is in MeSs-DOS. I got around it by using C's biosprint call. I don't like it, but there seems to be no other way. - Bob Alexander I speak for myself, only.