Inverse Printing

Other misc things
Post Reply
User avatar
RobertK
Well known member
Posts: 347
Joined: Mon Feb 26, 2018 12:58 pm

Inverse Printing

Post by RobertK »

A few cross-development-related questions about inverse printing.

On the ANSI and Generic Console, inverse printing goes like this (from the ansivt52.c sample):

Code: Select all

printf("%cpInverse On%cqInverse off\n",27,27);
1. Is there somewhere a list of those targets that support inverse printing and those that do not? Or, is there something like __INVERSE_PRINTING_AVAILABLE__ that we could check using "#if defined"?

2. If a system does not support inverse characters, shall we avoid printing the control characters \p and \q? Or should z88dk take care of this by not printing these characters? Currently, on some of these targets these unwanted characters appear and on some they don't.

3. If a target supports both the Generic and ANSI console, should the inverse printing behaviour be the same on both consoles? And if it is not (i.e. if it works only on one of them, or if control characters appear on one console but not on the other), is this a bug that we should report to the z88dk team?


Here is a list of targets that according to my tests support inverse printing:

Alphatronic PC
Bandai RX-78
Casio FP-1100 (*)
Casio PV-2000
Coleco
Laser 500
MC1000
NEC PC-6001 Mk2
Samsung SPC-1000
Sega SC-3000
Sony SMC-777
Sord M5
SVI
Tiki-100
Toshiba Pasopia 7
Z9001 (works with Generic Console, ANIS/VT100 shows control characters)
ZX81 (inverse printing using captial letters)

(*) The Casio FP-1100 ansivt52.c screenshot on the wiki page is outdated, here is a new one:

Image

And according to my tests, these targets do not seem to support inverse printing:

ABC80
Aquarius
EG2000
Epson QX-10
Exidy Sorcerer
Galaksija
Jupiter Ace
Kaypro 83
Microbee
MSX
Nascom
NCR Decision Mate V
NEC PC-8001
Osborne 1
Otrona Attache
Philips P2000
Robotron Z1013
Sharp MZ2500
Sharp MZ700
Sharp X1
Super-80
TRS-80
VG5000
VZ200
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

in ansi vt mode the escape sequence is not being printed even when the inverse text attributes are not available. please check it on some of the targets you listed as not working
User avatar
RobertK
Well known member
Posts: 347
Joined: Mon Feb 26, 2018 12:58 pm

Post by RobertK »

According to my notes (tested a few weeks ago), the following targets show escape sequence characters in ANSI console mode:

Jupiter Ace
Philips P2000
MSX
Sharp X1
User avatar
dom
Well known member
Posts: 2076
Joined: Sun Jul 15, 2007 10:01 pm

Post by dom »

Having written quite a few of these drivers I understand your pain! Unfortunately a #define isn't going to be the answer since it may vary based on screen modes.

There's several ways of doing inverse:

1. Setting the inverse bit on the attribute (for character mapped displays)
2. Inverting the bytes (for bitmap displays)
3. Swapping the paper/ink colours (for character mapped displays with flexible attributes)
4. If the character set has an inverse set available, use it (eg the characters with bit 7 set are inverted).

So for example the MC6847 machines used method 2. when in mode1/2, and method 1. in mode 0.

The TMS9918 machines use method 3 for gencon in mode 2, doesn't support it for mode 0,1. For VT100 it looks like method 2 is used, for non-32 column modes and doesn't bother for 32 column (I'm guessing this is one of the mismatches?).

Which leads us to those that don't support inverse, I think there's the following classes:

- Genuine omission, eg aquarius and super80 where we could use method 3
- Not possible, eg kaypro83 (it has flashing characters when bit 7 is set)
- Possible, but chosen not to, eg Sorcerer where there's a PCG available, but I've chosen to use it for UDGs rather than inverse
- Available, but not in the current mode, eg Galaksija where the hires mode supports inverse

I'll take a look at the genuine omissions when I've finished the new target I'm working on.

When using gencon, the [ESC]q, [ESC]p should not be printed ever - even on targets that don't support inverse they'll be parsed out.

For those machines which support both VT100 and gencon, the inverse behaviour should be the same, any mismatches are really bugs that will need fixing up.
Timmy
Well known member
Posts: 392
Joined: Sat Mar 10, 2012 4:18 pm

Post by Timmy »

Yes, I'm not understanding the request here either.

I've been discussing the possibilities of displaying inverse modes on the TMS9918 machines when I was writing a text adventure for the MSX last year, and the answer was that it's not really possible to do this on its text modes, but only on the slow and pure graphical 32x24 mode.

I can understand that people are claiming that a machine can do inverse mode in ansi because the slowest bitmapped mode can do inverse, but then again my text adventure did not suffer even if I had 0.5 frames per second. (Fortunately I didn't need ANSI support, so I dropped that immediately.) :)
User avatar
RobertK
Well known member
Posts: 347
Joined: Mon Feb 26, 2018 12:58 pm

Post by RobertK »

Ok, so in theory we don't need to care about whether a target supports inverse characters or not. We simply try to print inverse text, and the text will either appear inverse or not, depending on whether the target supports it in that particular screen mode.

The only target that I have found showing a different behaviour between GenCon and ANSI/VT100 is the Z9001: it correctly shows inverse characters using GenCon, but it shows escape characters using VT100.

Thanks for your clarification on this low-priority topic. I didn't want to distract you from working on new targets. :)
User avatar
dom
Well known member
Posts: 2076
Joined: Sun Jul 15, 2007 10:01 pm

Post by dom »

The new target isn't anything special unfortunately, just another MC6847 console that's a little under specced - I feel like we're running out of targets (apart from the rather large pool of CP/M machines) to do much with.

Anyway...this is worth fixing, I'm not sure what's going on with the Z9001 but I'll take a look.
User avatar
dom
Well known member
Posts: 2076
Joined: Sun Jul 15, 2007 10:01 pm

Post by dom »

I couldn't reproduce the z9001 issue - both ansivt52.c and ansitest.c displayed inverse text correctly under gencon and -clib=ansi respectively.

I've added inverse for the Super80 using method 3.
User avatar
RobertK
Well known member
Posts: 347
Joined: Mon Feb 26, 2018 12:58 pm

Post by RobertK »

dom wrote:I couldn't reproduce the z9001 issue - both ansivt52.c and ansitest.c displayed inverse text correctly under gencon and -clib=ansi respectively.
When I compile ansivt52.c like this...

zcc +z9001 -pragma-redirect:fputc_cons=fputc_cons_generic -o ansivt52_z9001 -create-app ansivt52.c

...it looks good. But when I compile it like this...

zcc +z9001 -clib=ansi -o ansivt52_z9001_ANSI -create-app ansivt52.c

...it looks as follows (tested with Z9001 "Farbe, Blockgrafik"):

Image


And I can't get the Super 80 to show inverse.

I compiled ansivt52.c like this...

zcc +super80 -create-app -clib=vduem -o ansivt52_super80rv ansivt52.c -D__SUPER80_VDUEM__
zcc +super80 -create-app -o ansivt52_super80em ansivt52.c

...and used the MAME super80e and super80r machines for testing, but none of them showed inverse.
User avatar
dom
Well known member
Posts: 2076
Joined: Sun Jul 15, 2007 10:01 pm

Post by dom »

RobertK wrote:And I can't get the Super 80 to show inverse.

I compiled ansivt52.c like this...

zcc +super80 -create-app -clib=vduem -o ansivt52_super80rv ansivt52.c -D__SUPER80_VDUEM__
zcc +super80 -create-app -o ansivt52_super80em ansivt52.c

...and used the MAME super80e and super80r machines for testing, but none of them showed inverse.
It's method 3 that's used, so it has to be a colour machine, so super80m and super80v
User avatar
dom
Well known member
Posts: 2076
Joined: Sun Jul 15, 2007 10:01 pm

Post by dom »

RobertK wrote:
dom wrote:I couldn't reproduce the z9001 issue - both ansivt52.c and ansitest.c displayed inverse text correctly under gencon and -clib=ansi respectively.
When I compile ansivt52.c like this...

zcc +z9001 -pragma-redirect:fputc_cons=fputc_cons_generic -o ansivt52_z9001 -create-app ansivt52.c

...it looks good. But when I compile it like this...

zcc +z9001 -clib=ansi -o ansivt52_z9001_ANSI -create-app ansivt52.c

...it looks as follows (tested with Z9001 "Farbe, Blockgrafik"):

http://666kb.com/i/e1u3singzu4qsump4.jpg
--generic-console supports VT52 codes, -clib=ansi supports VT100 codes - the inverse code sequence is different for each console - hence there's two example programs - that's why you're getting random control codes at the start of the lines - you're running the VT52 example with -clib=ansi
User avatar
RobertK
Well known member
Posts: 347
Joined: Mon Feb 26, 2018 12:58 pm

Post by RobertK »

dom wrote:the inverse code sequence is different for each console - hence there's two example programs
Thanks, until now I was thinking that the codes were the same in both ANSI and GenCon. I'm still in the middle of a learning process...
dom wrote:It's method 3 that's used, so it has to be a colour machine, so super80m and super80v
And in MAME we need to adjust the Machine Configuration to either Composite or RGB to see the inverse output.

Once again I was first wondering why I can't see any inverse output... :-)
Post Reply