D3, being the leading-edge product that it is, apparently has the capability
to control color. Yes, that's right, according to page 236 of my BASIC
documentation, I find that in addition to supporting graphics characters A-Z
(both upper AND lower case!) as well as punctuation, it can also control
EIGHT different foreground and background colors. Wow!

To get to the point, has anyone actually gotten this to work on any modern
terminal emulator? I've played with various "at minus" codes for foreground
and background colors, using several different terminal emulator programs
and emulation modes, none to any effect.

I am sure the apparent lack of functionality will turn out to be caused by
something either patently obvious or completely undocumented. But I did
make this stuff work on an Ultimate years ago with a color ADDS terminal, so
I do not think I am completely hopeless. Either way, I'd certainly
appreciate whatever insight any of you may offer.

thanks

Brian Bond wrote:

I thought this only worked on the main console (port 0).

Maybe it would work with emulation software in IBM/PC mode and the
current port's emulation mode set the same?

--
Kevin Powick

Kevin Powick wrote:
for a while but was returned with ABS patch 35. If you want color and
to work with an emulator look at Accuterm and the SUI extension. I
believe you'll need the latest and greatest version 5.2b.

HTH, Patrick <;=)

P.S. You can also get *just* color by playing with the dim, reverse, etc
in Accuterm in conjunction with the @ functions if the accuterm
configuration colors are set up in conjunction with these. You do lose
the mouse stuff though.

Or just look here.

http://www.asent.com/topsecret/modernizing1.html

Patrick, <;=)

This depends entirely on which term "type" you use. For VT100-style, try
ANSI.C.

TERM ANSI.C


@(-33) - @(-48)
white, yellow, magenta, red, cyan, green, blue, black

If you look at the DEVICES item for ansi.c, you'll see how the @(-nn) values
are setup and you can make your own.

Basically, you can use the @(-nn) codes to generate any string of characters
you want.


Mark Brown


"Brian Bond" <brian (AT) XYZXYZXYZXYZbonanzapress (DOT) com> wrote

Patrick wrote:
I was going to suggest this too, but off-topic from the OP I don't
understand the reference to losing mouse functionality when you're
also using screen attributes. I know you can enable a green screen to
use a mouse but I'm not aware that use of attributes is in conflict
with that. Can you elaborate?

Thanks!
T

Hi Brian.

Colour (or color) is not a simple matter on D3.

Yes, D3 console can support colour but on an IBM graphics console. The
current PC for example. If you wish to create a colour application then
the results are rewarding but a little challenging.

Colour terminals display colour according to the 'Escape' sequence you
send to them. For example when you CRT @(-12) then D3 will ouput the
sequence of characters defined for that operation for the terminal
device it thinks you are using for your currnet logon session. Check the
'devices' file for these definitions. Note that D3 stores these
character sequences as a mixture of literal characters and hexadecimal
pseudo codes all separated by commas.

If designing a major application or run-time environment then you might
consider creating your own device definition file in which you can store
your colour codes.

The matter is further complicated as some colour terminals accept can
accept colour commands which determine a colour for foreground and then
a colour for background. Other terminal devices demand that you specify
a foreground/background colour pair together a single code. Turning a
colour 'off' is also a consideration.

A workable approach is to define your own logical abstractions for
terminal colours which in turn uses the colour definitions maintained in
your own device file. For example you can define your basic screen
(white on blue) with help legend bar (green on black). When painting
your ledgend bar you output the colour held for that effect then turn it
off by returning to the basic screen colour. In this way your
application never needs to concern itself with the terminal colour codes
- it just outputs the code for the defined colour pair according to the
effect you wish to produce. It also has the benefit of allowing users to
customise their colous and produce screens which are magnificently hideous.

Colour definitions for most terminals are easily found on the Internet:

http://www.bluesock.org/~willg/dev/ansi.html

ASCI C is a fairly easy definition to begin playing with. It is a simple
matter to create a simple program which outputs text in colours. Note
that in many cases you will find sixteen foreground colours (eight basic
colours in bold and normal) and eight background colours. It sounds a
lot but getting some visually pleasing combinations from this palette
can be a challenge. Try to work with the rule that 'less is more'.

Good luck.


John Bend.



Brian Bond wrote:

Thanks, that did it.

A quick test shows that ANSI.C works with the cheapo-discount Windows telnet
client, Hyperterm, VanDyke CRT (my personal fave), and the "real" terminals
I have scattered around the building.



"Mark Brown" <mbrown (AT) drexelmgt (DOT) com> wrote

Tony Gravagno wrote:

You are correct Tony. I should have said you lose some of the mouse
functionality (I was thinking scroll) If you bypass the SUI route.
The ability to use the mouse to execute processes based on screen
text patterns is still available. I think SUI has the ability to
create buttons you can click on as well without the requirement
of a local mouse file.

Heck you can even kick off shell apps (Notepad, Calculator, etc)
with the mouse patterns without using the SUI. It is just not as
full of screen functionality IMHO.

Patrick, <;=)

Just a quick note - AccuTerm supports the 16 color palette John
mentioned, but additionally, you can customize the exact color for each
of those 16 colors in the palette, using current system colors, or the
standard Windows color selection dialog.

Pete