#: 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.
|