> 00 1A 00 CD 67 0B CD 6 CLS CLEAR SCREEN/HOME CURSOR STRING
> 06 1B 54 00 C1 77 D8 6 CLEOL CLEAR TO END OF LINE STRING
> 0C 1B 3D 00 C5 E5 5 CPOS CURSOR POS LEAD-IN STRING
> 11 00 5C 1D 3A 4 CPOS CURSOR POS BETWEEN ROW/COL STRING
> 15 00 02 D6 0D 4 CPOS CURSOR POS AFTER STRING
> 19 00 BYTE HORIZONTAL OFFSET
> 1A 00 BYTE 0 = ROW FIRST 1 = COL FIRST
> 1B 01 BYTE (1)
> 1C 01 BYTE 1 = USE CLS/CLEOL 0 = SIMULATE
>
> 4D 20 00 WORD OFFSET ADDED TO ROW/COL
>
> (1) Appears to be unused in Orbquest.
>
> - Strings are terminated with 00H byte
> - Data from 1D to EB is used by ORBQUEST
> - Data from EC to FF is overwritten by the overlay

Hello, Is anyone familiar with VT100 escape codes able to have a go at making the necessary TERM.CTL modifications make it display correctly to a VT-100 terminal? I am trying to get Orbquest working on a homebrew Z80 being accessed over serial from a linux desktop, but not succeeding very much in working out the HEX edits needed.

On Wednesday, April 19, 2023 at 4:32:31 AM UTC-4, Ben wrote:
> > 00 1A 00 CD 67 0B CD 6 CLS CLEAR SCREEN/HOME CURSOR STRING
> > 06 1B 54 00 C1 77 D8 6 CLEOL CLEAR TO END OF LINE STRING
> > 0C 1B 3D 00 C5 E5 5 CPOS CURSOR POS LEAD-IN STRING
> > 11 00 5C 1D 3A 4 CPOS CURSOR POS BETWEEN ROW/COL STRING
> > 15 00 02 D6 0D 4 CPOS CURSOR POS AFTER STRING
> > 19 00 BYTE HORIZONTAL OFFSET
> > 1A 00 BYTE 0 = ROW FIRST 1 = COL FIRST
> > 1B 01 BYTE (1)
> > 1C 01 BYTE 1 = USE CLS/CLEOL 0 = SIMULATE
> >
> > 4D 20 00 WORD OFFSET ADDED TO ROW/COL
> >
> > (1) Appears to be unused in Orbquest.
> >
> > - Strings are terminated with 00H byte
> > - Data from 1D to EB is used by ORBQUEST
> > - Data from EC to FF is overwritten by the overlay
> Hello, Is anyone familiar with VT100 escape codes able to have a go at making the necessary TERM.CTL modifications make it display correctly to a VT-100 terminal? I am trying to get Orbquest working on a homebrew Z80 being accessed over serial from a linux desktop, but not succeeding very much in working out the HEX edits needed.
Is your VT100 a VT100, or is it an "ANSI" terminal.Reason is that VT100 has a command that shifts to VT52 mode. ANSI needs to send ascii number for row/column. VT52 just needs a character.

> Is your VT100 a VT100, or is it an "ANSI" terminal.Reason is that VT100 has a command that shifts to VT52 mode. ANSI needs to send ascii number for row/column. VT52 just needs a character.
I do not have a physical VT100. Ideally I would like to use minicom running from a standard Ubuntu terminal which communicates with the computer running Orbquest over serial, as that is what I'm already using for other applications. My understanding is that most supposedly "VT100 compatible" terminal emulators (including minicom) may not handle the command that shifts to VT52 mode. So I think ideally we would NOT shift to VT52 mode, OR have multiple versions to try.

Instead of minicom under the standard Ubuntu terminal it may be possible for me to use xterm instead which I believe can handle the VT52 shift, or run it in pure VT52 mode. I also have a hardware terminal emulator which supposedly can handle the shift to VT52 mode that I can fall back on if software termainal emulators aren't doing the trick (https://github.com/dhansel/VersaTerm).

So in the best case there would be 3 versions to try perhaps; a pure VT100, pure TV52, and VT100 that shifts to VT52 when expedient. It might be very educational to see those three side-by-side but beggers can't be choosers :) If just one then I think purely VT100/ANSI will be most likely to work if it's possible to implement in the limited space provided in the TERM.CTL file.

On 20/04/2023 10:27 am, Ben wrote:
>
> If just one then I think purely VT100/ANSI will be most likely to work if it's possible to implement in the limited space provided in the TERM.CTL file.

It would be a rare 1982 application that didn't support VT100. Likely TERM.CTL
already does. It's a matter of locating the terminal driver in Orbquest to find
out how.

On Thursday, April 20, 2023 at 12:08:55 PM UTC+10, dxforth wrote:
> On 20/04/2023 10:27 am, Ben wrote:
> >
> > If just one then I think purely VT100/ANSI will be most likely to work if it's possible to implement in the limited space provided in the TERM.CTL file.
> It would be a rare 1982 application that didn't support VT100. Likely TERM.CTL
> already does. It's a matter of locating the terminal driver in Orbquest to find
> out how.
Hi dxforth. My understanding was that you had worked out the details necessary to configure TERM.CTL (in your message above from Jan 6 2020) but that those are the hex values from the recovered TERM.CTL which are configured for Osbourne1 not VT100. The original SETTERM from Orbquest that has not been recovered would have supported generation of a TERM.CTL for VT100 but attempting to edit manually is where I have found myself stuck and asking for someone with experience to have a look at it. To make Orbquest display properly under VT100 would it not "simply" be a matter of changing those hex values in your post above to VT100 control codes?

On 20/04/2023 12:25 pm, Ben wrote:
>
> To make Orbquest display properly under VT100 would it not "simply" be a matter of changing those hex values in your post above to VT100 control codes?

No because ANSI sends xy coords as ASCII strings - not byte values. Likely
there's a switch in TERM.CTL that informs Orbquest but I couldn't determine
what that was.

On Thursday, April 20, 2023 at 12:38:03 PM UTC+10, dxforth wrote:
> On 20/04/2023 12:25 pm, Ben wrote:
> >
> > To make Orbquest display properly under VT100 would it not "simply" be a matter of changing those hex values in your post above to VT100 control codes?
> No because ANSI sends xy coords as ASCII strings - not byte values. Likely
> there's a switch in TERM.CTL that informs Orbquest but I couldn't determine
> what that was.
Thanks for the explanation. Then is it possible by editing the TERM.CTL to achieve something VT100 compatible switching to VT52 mode? This should at least work on VT100 terminals that support VT52 mode, such as my hardware emulator mentioned above and perhaps xterm in linux which I believe supports switching to VT52 mode.

On Thursday, April 20, 2023 at 12:38:03 PM UTC+10, dxforth wrote:
> On 20/04/2023 12:25 pm, Ben wrote:
> >
> > To make Orbquest display properly under VT100 would it not "simply" be a matter of changing those hex values in your post above to VT100 control codes?
> No because ANSI sends xy coords as ASCII strings - not byte values. Likely
> there's a switch in TERM.CTL that informs Orbquest but I couldn't determine
> what that was.
Thanks for the explanation. Then is it possible by editing the TERM.CTL parts you have determined to achieve something VT100 compatible that uses switching to VT52 mode? It should at least then work on VT100 terminals that support VT52 mode, such as my hardware emulator mentioned above and perhaps xterm in linux which I believe supports switching to VT52 mode.

On 20/04/2023 1:25 pm, Ben wrote:
> On Thursday, April 20, 2023 at 12:38:03 PM UTC+10, dxforth wrote:
>> On 20/04/2023 12:25 pm, Ben wrote:
>>>
>>> To make Orbquest display properly under VT100 would it not "simply" be a matter of changing those hex values in your post above to VT100 control codes?
>> No because ANSI sends xy coords as ASCII strings - not byte values. Likely
>> there's a switch in TERM.CTL that informs Orbquest but I couldn't determine
>> what that was.
> Thanks for the explanation. Then is it possible by editing the TERM.CTL parts you have determined to achieve something VT100 compatible that uses switching to VT52 mode? It should at least then work on VT100 terminals that support VT52 mode, such as my hardware emulator mentioned above and perhaps xterm in linux which I believe supports switching to VT52 mode.

VT52 mode should work but may need to be switched manually.

On Wed, 19 Apr 2023 01:32:29 -0700 (PDT)
Ben <hello@electronicsluckydip.com> wrote:

> > 00 1A 00 CD 67 0B CD 6 CLS CLEAR SCREEN/HOME CURSOR STRING
> > 06 1B 54 00 C1 77 D8 6 CLEOL CLEAR TO END OF LINE STRING
> > 0C 1B 3D 00 C5 E5 5 CPOS CURSOR POS LEAD-IN STRING
> > 11 00 5C 1D 3A 4 CPOS CURSOR POS BETWEEN ROW/COL STRING
> > 15 00 02 D6 0D 4 CPOS CURSOR POS AFTER STRING
> > 19 00 BYTE HORIZONTAL OFFSET
> > 1A 00 BYTE 0 = ROW FIRST 1 = COL FIRST
> > 1B 01 BYTE (1)
> > 1C 01 BYTE 1 = USE CLS/CLEOL 0 = SIMULATE
> >
> > 4D 20 00 WORD OFFSET ADDED TO ROW/COL
> >
> > (1) Appears to be unused in Orbquest.
> >
> > - Strings are terminated with 00H byte
> > - Data from 1D to EB is used by ORBQUEST
> > - Data from EC to FF is overwritten by the overlay
>
> Hello, Is anyone familiar with VT100 escape codes able to have a go
> at making the necessary TERM.CTL modifications make it display
> correctly to a VT-100 terminal? I am trying to get Orbquest working
> on a homebrew Z80 being accessed over serial from a linux desktop,
> but not succeeding very much in working out the HEX edits needed.

Aha; the values in the odd bytes from 1D to 4B are the characters sent
out for the row values in the cursor positioning string (there are 24 of
them). The values in the odd bytes from 4D to EB are the characters
sent out for the column values in the cursor positioning string (there
are 9- of them). Despite being zero separated, they aren't strings; the
program won't accept two character strings so you can't just replace the
characters with two digit strings for the rows and columns beyond 9 (I
tried). The program expects a single character followed by a zero for
each row & column position.

> The values in the odd bytes from 4D to EB are the characters
> sent out for the column values in the cursor positioning string (there
> are 9- of them).

That should have been "there are 80 of them", of course!

Ben schrieb am Donnerstag, 20. April 2023 um 02:27:11 UTC+2:
> So in the best case there would be 3 versions to try perhaps; a pure VT100, pure TV52, and VT100 that shifts to VT52 when expedient. It might be very educational to see those three side-by-side but beggers can't be choosers :) If just one then I think purely VT100/ANSI will be most likely to work if it's possible to implement in the limited space provided in the TERM.CTL file.

In such cases where a program cannot be patched to ANSI/VT-100 I patch it for VT-52 and this
is my VT-52 terminal then:

cat ~/bin/vt52
#!/bin/sh

LC_ALL=C exec xterm -ti vt52 -tn vt52 -T "DEC VT-52" &

Also I like an old style green terminal which you get with:

cat ~/.Xdefaults
XTerm*Background: black
XTerm*Foreground: green
XTerm*font: 7x13

Got it. They weren't zero terminated 1 character strings. They were "up
to 2 characters, possibly terminated earlier by a zero" strings. I have
a TERM.CTL that works with an ANSI terminal and it's HEX version
is included below. Save the lines beginning with : below to TERM.HEX,
use LOAD to create TERM.COM and rename it to TERM.CTL. Fingers crossed
that the Intel hex makes it through.

:100100001B5B481B5B4A1B5B4B0000001B5B00003A
:10011000003B0000004800000000000101303130C9
:1001200032303330343035303630373038303931A2
:10013000303131313231333134313531363137319B
:100140003831393230323132323233323430313088
:100150003230333034303530363037303830393172
:10016000303131313231333134313531363137316B
:100170003831393230323132323233323432353250
:100180003632373238323933303331333233333336
:10019000343335333633373338333934303431341C
:1001A0003234333434343534363437343834393502
:1001B00030353135323533353435353536353735FB
:1001C00038353936303631363236333634363536E0
:1001D00036363736383639373037313732373337C6
:1001E000343735373637373738373938300C00172A
:1001F00000CDE116032AA101E5CDBF263E0132C3A1
:0000000000

On 20/04/2023 4:07 pm, Wayne Hortensius wrote:
> Got it. They weren't zero terminated 1 character strings. They were "up
> to 2 characters, possibly terminated earlier by a zero" strings. I have
> a TERM.CTL that works with an ANSI terminal and it's HEX version
> is included below. Save the lines beginning with : below to TERM.HEX,
> use LOAD to create TERM.COM and rename it to TERM.CTL. Fingers crossed
> that the Intel hex makes it through.

So SETTERM builds the row/col data for Orbquest to use rather than
generating it at run-time. Nice work spotting it!

On Thursday, April 20, 2023 at 4:07:24 PM UTC+10, Wayne Hortensius wrote:
> Got it. They weren't zero terminated 1 character strings. They were "up
> to 2 characters, possibly terminated earlier by a zero" strings. I have
> a TERM.CTL that works with an ANSI terminal and it's HEX version
> is included below. Save the lines beginning with : below to TERM.HEX,
> use LOAD to create TERM.COM and rename it to TERM.CTL. Fingers crossed
> that the Intel hex makes it through.
>
> :100100001B5B481B5B4A1B5B4B0000001B5B00003A
> :10011000003B0000004800000000000101303130C9
> :1001200032303330343035303630373038303931A2
> :10013000303131313231333134313531363137319B
> :100140003831393230323132323233323430313088
> :100150003230333034303530363037303830393172
> :10016000303131313231333134313531363137316B
> :100170003831393230323132323233323432353250
> :100180003632373238323933303331333233333336
> :10019000343335333633373338333934303431341C
> :1001A0003234333434343534363437343834393502
> :1001B00030353135323533353435353536353735FB
> :1001C00038353936303631363236333634363536E0
> :1001D00036363736383639373037313732373337C6
> :1001E000343735373637373738373938300C00172A
> :1001F00000CDE116032AA101E5CDBF263E0132C3A1
> :0000000000
Thanks Wayne, this appears to be working brilliantly, completely playable (as far as this game can be considered so) in my case through minicom and on the Versaterm VT100 hardware emulator. You have restored my faith in the internet, or least in an internet where CP/M is the prevailing OS :)

On 20/04/2023 4:07 pm, Wayne Hortensius wrote:
> Got it. They weren't zero terminated 1 character strings. They were "up
> to 2 characters, possibly terminated earlier by a zero" strings. I have
> a TERM.CTL that works with an ANSI terminal and it's HEX version
> is included below. Save the lines beginning with : below to TERM.HEX,
> use LOAD to create TERM.COM and rename it to TERM.CTL. Fingers crossed
> that the Intel hex makes it through.
> ...

I've put together an installer based on the latest info. It's named
TERMSET to not confuse with the original SETTERM.COM should the latter
ever be located. Usage is:

TERMSET [TERM[.CTL]]

Included are the TERM.CTL and Wayne's ANSI version.

There are two values/flags in TERM.CTL whose purpose is as yet unknown
(assuming they're used at all). The installer identifies them as 0x19
and 0x1B.

Current version is: TRMSET10.ZIP

https://drive.google.com/drive/folders/1kh2WcPUc3hQpLcz7TQ-YQiowrozvxfGw

Any updates will be posted there.

On Sunday, April 23, 2023 at 7:03:46 AM UTC+3, dxforth wrote:
> On 20/04/2023 4:07 pm, Wayne Hortensius wrote:
> > Got it. They weren't zero terminated 1 character strings. They were "up
> > to 2 characters, possibly terminated earlier by a zero" strings. I have
> > a TERM.CTL that works with an ANSI terminal and it's HEX version
> > is included below. Save the lines beginning with : below to TERM.HEX,
> > use LOAD to create TERM.COM and rename it to TERM.CTL. Fingers crossed
> > that the Intel hex makes it through.
> > ...
>
> I've put together an installer based on the latest info. It's named
> TERMSET to not confuse with the original SETTERM.COM should the latter
> ever be located. Usage is:
>
> TERMSET [TERM[.CTL]]
>
> Included are the TERM.CTL and Wayne's ANSI version.
>
> There are two values/flags in TERM.CTL whose purpose is as yet unknown
> (assuming they're used at all). The installer identifies them as 0x19
> and 0x1B.
>
> Current version is: TRMSET10.ZIP
>
> https://drive.google.com/drive/folders/1kh2WcPUc3hQpLcz7TQ-YQiowrozvxfGw
>
> Any updates will be posted there.

Hello everyone!
Well done dxf, Wayne et al. You solved the major part of the quest ;)
Btw, could you share TERM.CTL configured just for VT-52? Coz I got no clue :))

On 5/05/2023 5:15 am, Alex Trusty wrote:
> ...
> Btw, could you share TERM.CTL configured just for VT-52? Coz I got no clue :))

I've checked it on something that claims to be VT-52 emulation. Seems to work.

CLEAR SCREEN: <ESC> H <ESC> J
CLEAR TO EOL: <ESC> K
CURSOR LEAD-IN: <ESC> Y
BETWEEN row/col: <none>
AFTER row/col: <none>
Column first: N
Binary: Y
ROW offset: 32
COL offset: 32
Use CLS/CLREOL: Y
Value at 0x19 (0): 0
Value at 0x1B (1): 1

:100100001B481B4A00001B4B000000001B5900004D
:10011000000000000000000000000001012000219C
:1001200000220023002400250026002700280029A3
:10013000002A002B002C002D002E002F0030003153
:100140000032003300340035003600370020002133
:100150000022002300240025002600270028002973
:10016000002A002B002C002D002E002F0030003123
:1001700000320033003400350036003700380039D3
:10018000003A003B003C003D003E003F0040004183
:100190000042004300440045004600470048004933
:1001A000004A004B004C004D004E004F00500051E3
:1001B0000052005300540055005600570058005993
:1001C000005A005B005C005D005E005F0060006143
:1001D00000620063006400650066006700680069F3
:1001E000006A006B006C006D006E006F000ABE09B3
:1001F000290F110FCF088902E898DF3724E836DE8F
:00000001FF

On Friday, May 5, 2023 at 6:45:57 AM UTC+3, dxforth wrote:
> On 5/05/2023 5:15 am, Alex Trusty wrote:
> > ...
> > Btw, could you share TERM.CTL configured just for VT-52? Coz I got no clue :))
> I've checked it on something that claims to be VT-52 emulation. Seems to work.
>
> CLEAR SCREEN: <ESC> H <ESC> J
> CLEAR TO EOL: <ESC> K
> CURSOR LEAD-IN: <ESC> Y
> BETWEEN row/col: <none>
> AFTER row/col: <none>
> Column first: N
> Binary: Y
> ROW offset: 32
> COL offset: 32
> Use CLS/CLREOL: Y
> Value at 0x19 (0): 0
> Value at 0x1B (1): 1
>
> :100100001B481B4A00001B4B000000001B5900004D
> :10011000000000000000000000000001012000219C
> :1001200000220023002400250026002700280029A3
> :10013000002A002B002C002D002E002F0030003153
> :100140000032003300340035003600370020002133
> :100150000022002300240025002600270028002973
> :10016000002A002B002C002D002E002F0030003123
> :1001700000320033003400350036003700380039D3
> :10018000003A003B003C003D003E003F0040004183
> :100190000042004300440045004600470048004933
> :1001A000004A004B004C004D004E004F00500051E3
> :1001B0000052005300540055005600570058005993
> :1001C000005A005B005C005D005E005F0060006143
> :1001D00000620063006400650066006700680069F3
> :1001E000006A006B006C006D006E006F000ABE09B3
> :1001F000290F110FCF088902E898DF3724E836DE8F
> :00000001FF

Works just fine. Thank you so much, dxf!