Hello Frank,
Am 24.08.2022 um 02:47 schrieb Frank Kolmann <frank.kolmann@xxxxxxxxx>:
1 byte can control 256 colours, why is it limited to 14?
I think this is based on the limited hardware capabilities of (early) terminal chipsets by IBM. It even ain't 14, but 7: Each of the RGB colors by itself, and in combination switched just on, or off. R, G, B, R+G=YLW, R+B=PNK, G+B=TRQ, R+G+B=WHT. No in-between values, just switch colors on or off. Easy to implement. In addition, 14 is a theoretical value, because the colors itself don't change, but the addition of DSPATR(RV) adds seven additional "visual effects".
As you probably are aware, the color support isn't true "color", but more a less a recycling of existing attributes, mapped to colors. Maybe this also plays a role.
I never understood why the Attribute Byte is written to the screen, surely it can be kept in the Device buffer.
This also might have been easier to implement. I don't know much about 3270, but isn't it the same, there, too? AFAIK heavy "recycling" of available technology within IBM happened, regarding the Future Systems project.
Who uses 'Selector Pens'?
Dunno. My 3486 has a PS/2 mouse port, is this the same?
I've connected one to see that it works, but otherwise couldn't find out how to copy a marked area and paste at the current cursor position. A function I expect to be available, and one of the most missed for a pure terminal vs. an emulator running in a GUI OS.
So more work for developers to support Monochrome devices and Colour devices, backwards compatibility is broken but have a workaround.
Yes, and you gave the perfect reason why this won't happen: Backwards compatibility, IBMs holy cow. Also, apparently the majority of people around (and within) IBM i (devs, as well as users) seem to disregard terminal screens. Why would you expect IBM to put any effort into it?
I can only state for myself: 5250 will not change, so I can just accept the challenge and find creative use of what's available. Remember the inclusion of "ASCII art" by Booth Martin in his screen examples, and his dedication to use the pseudo-graphical display capabilities of iACS and predecessors? And, sometimes I'll have to accept that something isn't working. Eventhough we've been shown that the limits can be pushed — see the recent discussion about forcing a device read. Very interesting!
Or has this already been done, I never worked on AS400 Office word processing software, I don't know.
OV/400 has three "support modes". A plain one, another one with some special functions regarding 3477 terminals, and a "full" one where part of the editor might run locally on the PC. Not too sure about it, just scratched the surface of the topic, yet.
If you're curious, have a look at
https://ibmdocs.pocnet.net/SC41-9617-02.pdf (SAA OfficeVision/400: Learning about OfficeVision/400 Word Processing), and
https://ibmdocs.pocnet.net/SC41-9618-02.pdf (SAA OfficeVision/400: Using OfficeVision/400 Word Processing). Differences between those modes are explained there.
They're on my reading list for ages, out of sheer curiosity, but then I have not yet found a compelling use case for really trying the word processor. Part of it is my limited understanding about IBM i printing functions, fonts, etc. I want to find a way to use the available proportional font descriptions within OS/400 and make them work with my eBox IPDS adapter. Unfortunately, at least V4 assumes an extremely limited range of fonts being available when using TRANSFORM(*YES) which affects generation of PDFs for preview. (I'm using V4R5 almost exclusively on my main machine, a model 150.)
:wq! PoC
midrange.com
