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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 :)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 :))

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)