TIP: Click on subject to list as thread! ANSI
echo: cis.os9.6809.coco
to: Brother Jeremy, CSJW 76477,142 (X)
from: Lee Veal 74726,1752
date: 1992-01-05 17:05:06
subject: #13834-#Vefio_Help

#: 13846 S10/OS9/6809 (CoCo)
    05-Jan-92  17:05:06
Sb: #13834-#Vefio_Help
Fm: Lee Veal 74726,1752
To: Brother Jeremy, CSJW 76477,142 (X)

Bro,
   Even though the VEFPRT docs say that it can print OS9 Lvl 2 screen types 5,
6, 7 and 8.  That doesn't seem to be the case.   I was able to successfully
print 5, 6 and 8 only.  VEFPRT always kicked out Bad Screen Type: 1, on a
640x192x4 screen.  In VEF jargon a Type 1 screen is a 640x192x4 screen, which
is supposed to correspond with the Type 7 screen as defined in the OS9
Reference manual.
   Looking at the VEFPRT source code seems to show that when a Type 1 VEF
screen is being deciphered the "case" for Type 1 screens is not followed by a
"break".  Instead of completing the processing for a Type 1 screen VEFPRT drops
down to a default routine that puts out the "Bad Screen Type: 1" message.
   The second byte of the file produced by VEFIO (vefio -term >file) indicates
the screen type.  Patching a $00 in that byte will make VEFPRT think that the
screen being printed is a 320x192x16 screen.  That may work as a stopgap until
we can get some one to run VEFPRT.C through a new compile process.
   The source code that I think needs to be corrected is:

 .
 .
 .
    /* initialize */
    switch(type)
        {
        case 4:
            width = 80;
            nbits = 8;
            break;
        case 0:
            width = 160;
            nbits = 2;
            break;
        case 3:
            width = 80;
            nbits = 4;
            break;
        case 1:
            width = 160;
            nbits = 4;
            break;                   <-- This "break" was missing,
                                     <-- thus, allowing the program
                                     <-- to fall through to the fol-
                                     <-- lowing "fprint" routine.
        default:
            fprintf(stderr, "Bad screen type: %d\n", type);
            exit(0);
        }
 .
 .
 .

Anyway, that's what I think the problem is, but I'm not a C programmer, just an
'old' mainframe assembly programmer.

Lee

There is 1 Reply.

SOURCE: compuserve via textfiles.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.