TIP: Click on subject to list as thread! ANSI
echo: cis.languages
to: Greg Morse 72746,3451 (X)
from: Kevin Darling (UG Pres) 76703,4227
date: 1990-09-17 13:42:45
subject: #6741-#C Libraries

#: 6752 S3/Languages
    17-Sep-90  13:42:45
Sb: #6741-#C Libraries
Fm: Kevin Darling (UG Pres) 76703,4227
To: Greg Morse 72746,3451 (X)

Greg -

Dunno about your OS9, but the Developer's Pak for the CoCo came with an "rdump"
util... it shows the table of names/values used in linkable files. I think Carl
K is the resident expert on this stuff (well, and JJ of course). I'm a novice
at it.

Rammer: pretty sleazy piece of code, actually .  Correct approach of
course is to map in blocks legally.  But I was after speed etc, and I see
drivers as being able to legally do anything they want (as long as they don't
futz up other drivers).

Why shut off interrupts?  Two main reasons.

 1. CoCo interrupts can cause an entire map change due to the need to move to
the second 64K system map, where the gfx cursors code is.  On return, the
original system map is replaced, not the one Rammer may have rammed into the
GIME.
 2. More importantly, any interrupt requires that the system map be genuine, as
OS9 doesn't reset the DAT (at least, on DATs with more than one map available)
when it goes into system mode.  So the DAT info could be quite bad and the
system would crash and burn.

In other words, OS9 wouldn't know that someone had diddled with the system DAT
info... and it sure wouldn't know how to reset it after an interrupt. Does that
make sense?  You could insert a good block entry into the system DATImage, and
then you'd be legal, but the trouble there was that if the system map is full
up, a ramdisk like this couldn't work. - kev

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