More on coprocessors

["Mike Bilow, mikebw@ids.jvnc.net" <mikebw@IDS.JVNC.NET>]

I should have mentioned something else in connection with the math chip.
A 287 or 387 coprocessor may use IRQ13.  NOS may not handle this right
unless the "isat 1" command is issued.  I wrote the am_i_an_AT() code
that Gerard has been including in ioinit() for several versions to
automatically detect the proper way to set the isat flag, but your NOS
may not do this.  -- Mike Bilow, <mikebw@ids.jvnc.net>  (Internet)

to be "far" data.

Here is what I do inside CONFIG.C:

#if (defined(__COMPACT__) || defined(__LARGE__) || defined(__HUGE__))
#define DFAR far
#else
#define DFAR
#endif

Then I change definitions such as "struct cmds Cmds[] =" to be
"struct cmds DFAR Cmds[] =".  This has also proven, within CONFIG.C
in Gerard's code, to be safe with Attab[], Tracef[], Startcmds[],
and Stopcmds[].  These objects are all rarely accessed, and never
in a time critical fashion, since they are used only for decoding
keyboard input, and this was why I chose to go after them for
relocation.

I have also found that use of "-Ff=255" in the compiler invocation
line of MAKEFILE also helps a lot, but that values smaller than this
seem to conflict with the assembly language code that is being linked,
since the compiler has no control over the assumptions that may have
been made in that.  Setting the automatic far data threshold this way
has much less useful effect than the DFAR idea above, anyway.

By dragging ever-increasing amounts of command strings out of the
default static data segment with DFAR, I have been able to stuff
much more important NOS stuff in.

(No complaints from Rob, PE1CHL.  I'm not saying he'll be wrong,
either, just that he is not likely to be happy.  The whole bit about
doing the conditional defines are for his benefit, although we all
know full well that you can't really compile NOS in small data models.)

-- Mike Bilow, <mikebw@ids.jvnc.net>  (Internet)