at the moment I'm working on the crt unit for freepascal, (ms-dos style console functions in freepascal)
for checking the current size of console and current position of caret (and other stuff) I use the ConUnit. It works nicely on AROS and AmigaOS3, cu_XMax and cu_YMax returns for example 80 and 13 for my default shell which is reasonable. But on MorphOS (3.12) the same exe gives 0, negative or very large values (like 0 and 4114). Also when compiled directly on MorphOS it does not work.

I also found a C source doing the same, and it shows the same behavior when compiled for 68k or MorphOS (68k exe works AmigaOS3.x, 68k/powerpc exe return wrong Value on MorphOS)

Link to C source and 68k Exe to try: http://home.alb42.de/files/conunit.lha

someone has an idea what wrong here? is there an alternative?

ConUnit is not supported by MorphOS MUICON-Handler. 'con_unit' in your example code will always be NULL.

Technically this can happen with original console-handler, sometimes, too:
Quote:
Using WINDOW STATUS REQUEST custom ANSI code sequence should work however. See http://www.theflatnet.de/pub/cbm/amiga/AmigaDevDocs/dev_4.html#4-4-2-1 and http://www.theflatnet.de/pub/cbm/amiga/AmigaDevDocs/dev_4.html#4-5-3 for details.


[ Edited by Piru 31.12.2019 - 04:15 ]

how bad!

is there any example source how to do that?
(reading the size from current size/caret position, like in this example source)

Is there also a solution for console front/back pen?

Quote:
https://sintonen.fi/src/misc/conwinsize.c

[ Edited by Piru 31.12.2019 - 12:59 ]

Quote:

Not really, there is virtually nothing viable using those APIs and they’re basically some implementation brainfart of Commodore.

Quote:

I suggest you familiarize yourself with documents at https://vt100.net/

jacadcaps: maybe but thats a more Amiga-ish way (in contrast to the unix-way to get it from the console) and more importantly on Amiga68k it's much faster to use ConUnit, especially for reading Caret position, which I need a lot. I tried that on my Amiga and it's noticeable slower using the ANSI code sequences.

Quote:

Must have been a really slow Amiga then. Did you enable the raw mode first?

A1200/030/50Mhz on a 64 color WB. Raw mode, sure, without it does not work at all.

but i found something which is ONLY possible via ConUnit, or maybe you have a pointer for me how to do that without ConUnit.

I need special colors (red, green, blue, cyan, magenta, yellow, brown, light blue, light green, ...) over all 16 colors. but setting colors via ansi only supports to use of the first 8 colors in the palette, so I cant use ObtainBestPen (because they are usually > 7) and I can't use ObtainPen because the colors 0..7 are fixed (by OS I guess).

But in ConUnit I can set the cu_FGPen/cu_BGPen to any Pen 0..255 as I like and it works.
Any idea how to set the text/background in MorphOS to any self-defined color?

[ Edited by ALB42 02.01.2020 - 11:40 ]

PowerTerm supports the XTerm 256 colour palette:
https://en.wikipedia.org/wiki/ANSI_escape_code#8-bit


[ Edited by jacadcaps 02.01.2020 - 17:57 ]

Thanks, works well

https://blog.alb42.de/2020/01/03/crt-with-correct-colors/

VincEd also supports the xterm colours, if you're looking to reproduce this on vanilla 68k AmigaOS as well. KingCon AFAIK does not. (One of the reasons I preferred VincEd to KingCon, but it seems I was in a minority.)

VincEd may work on OS4 as well, if its console doesn't support xterm colours (which it might, I have no idea). VincEd works on MorphOS, though it hangs if you try to use the GUI preferences. You must edit prefs by hand. Possibly the same will be true on OS4.