TIP: Click on subject to list as thread! ANSI
echo: cis.os9.6809.coco
to: PaulSeniura 76476,464 (X)
from: Kevin Darling 76703,4227
date: 1991-07-02 17:04:19
subject: #11162-still need help!

#: 11279 S10/OS9/6809 (CoCo)
    02-Jul-91  17:04:19
Sb: #11162-still need help!
Fm: Kevin Darling 76703,4227
To: PaulSeniura 76476,464 (X)

No, despite what some editorials and people say, I don't think we've "lost that
many to the wolves" :-)   Times are just tight, and people are very busy, at
the moment.  All you have to do is to read other computer forums to find out
that this is universally true.

I was going to reply to your grfdrv article months back, but lost both it and
my answer when my ramdisk got clobbered during a thunderstorm glitch.  I'll try
again.

Grfdrv uses a max window size table (which you gave patches for), and figures
the max gfx coords on the fly.  So no, it doesn't use IT.ROW directly. The
scaling math is hardcoded to 191 tho.

Your suggestions for either extending grfdrv into the extra block in the
graphics system map, or using it to map in longer screens, are valid. What I
used it for in the end, was as a place to map in a lookup mask drawing to
covered/overlapped windows.

You've given me another idea tho.  The OSK window system has totally separate
driver internals for each gfx mode.  The CoCo window system had it all together
within the 8K grfdrv module.  Perhaps if we split up grfdrv into specialized
modules, we could add more functionality and speed without using up more
graphics map space for a larger grfdrv.

That wasn't possible back when we had to worry about 128K systems, but how many
people have those now?  :-)  best - kev

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™.