VT100/ANSI terminal emulation via OSWRCH

discussion of beeb/electron applications, languages, utils and educational s/w
SteveF
Posts: 429
Joined: Fri Aug 28, 2015 8:34 pm

VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Wed Dec 30, 2015 12:38 pm

I finally got round to knocking up a hack I thought of about fifteen years ago. :-) I was fiddling with some random CP/M software I'd picked up on the net and trying to get it to work with the Z80 second processor. The software either didn't support patching to handle different terminal types, or I didn't have the documentation, or it did support it but the Acorn VDU terminal was too different from what it was expecting. I can't remember what software it was, but I suspect the problem was a) it wanted to send text coordinates in (Y,X) order while VDU 31 wants X,Y order and/or b) it wanted to sent text coordinates as ASCII strings rather than raw bytes.

Anyway, at the time it seemed like a good idea to have a program which intercepted WRCHV and emulated (say) a VT100, allowing the CP/M program to remain unmodified. The problem was just tricky enough and time was limited enough that I never got it off the ground back then. Inspired by all the recent Matchbox goodness, I've now revisited this idea and produced a hacky proof of concept which just does enough to handle a few minutes' play on The Hitchiker's Guide To The Galaxy. (I have never actually executed the code on real hardware, though; I've been using B-Em to test it.)

If anyone would like to have a quick play with it, I've attached a zip file which contains the source code (for beebasm) and the generated SSD image. The SSD image contains the ROM (which has to run from sideways RAM at present, as it uses SWR for workspace) and a simple BBC BASIC program to exercise the control codes. (This works fine with 6502 BBC BASIC and no second processor; that's how I've been doing a lot of my testing.) So you can do something like:

*SRLOAD TERMROM 8000 7 Q
<CTRL-BREAK>
CHAIN "TEST1"
[observe the garbled display; press a key to finish the test]
*T
RUN
[observe the gloriously formatted text; press a key and it will erase part of the screen]

You can enable this from within CP/M using the 'STAR' command: STAR T

(Why '*T'? Because I didn't want to spend any time writing a proper command parser. :-) It's case-sensitive too, so '*t' won't work either.)

This is a very hacky implementation and if you give it escape sequences it doesn't recognise it could well crash or swallow all terminal output indefinitely.

Having now satisfied myself that I can do this, I am wondering:
  • has this already been done properly?
  • is this potentially useful?
  • is there any fundamental flaw in this approach I've overlooked?
  • does anyone have an interesting CP/M program which needs half-decent terminal emulation I could use as a test case?

Cheers.

Steve

PS Maybe I've just got smarter as I've got older :-), but this seemed a lot easier to write today than it did fifteen years ago. I suspect increased quantities of obscure technical documentation on the internet combined with screens big enough to read a document and work on something simultaneously help a lot...

Edited to add: Attached an updated version, it's still pretty half baked, but I've at least got a vaguely sane bit of code to interpret escape sequences using a state machine now. It should also make a half-decent attempt at letting ordinary Acorn VDU sequences pass through unmolested. (The new scrolling region implementation is incomplete and completely broken, but the VT100 control codes which worked before still work.)

ETA2: I've continued to fiddle with this. I'm actually fairly optimistic a pretty decent VT102 emulation can be implemented in this way. I am back at work tomorrow so that might slow progress, but right now I'm trying to restructure the code so it's not quite such a dog's dinner and get the basic emulation complete, then with luck I can hook up an emulated BeebEm machine running my code as a serial terminal to my Unix box and give vttest a whirl. I'm still not sure if it's useful, but it's currently sufficiently fascinating that I almost don't care. :-) If anyone does have any interesting CP/M software I could try as a test case I'd be interested though.
Attachments
termrom2.zip
(8.39 KiB) Downloaded 37 times
termrom.zip
(4.75 KiB) Downloaded 32 times

SteveF
Posts: 429
Joined: Fri Aug 28, 2015 8:34 pm

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Wed Nov 30, 2016 8:54 pm

Hi all,

I got a bit carried away with this, but I've finally got to a point where I think it's fit to be released. Here's a demonstration video, and given how it ends it seems appropriate to post it just before 1st December! (Please excuse the jerkiness, I tried to edit out the delays due to my typing to make it slightly less painful to watch.)



If the embedded video doesn't work, here's a simple link to youtube: https://www.youtube.com/watch?v=t572FRaA0UI

I've attached a zipped SSD of the ROM and supporting tests/demonstrations. The source code is on github: https://github.com/ZornsLemma/STEM

Cheers.

Steve
Attachments
stem-0.02.zip
(83.46 KiB) Downloaded 14 times

User avatar
jgharston
Posts: 2658
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: VT100/ANSI terminal emulation via OSWRCH

Postby jgharston » Wed Nov 30, 2016 9:38 pm

SteveF wrote:[*] has this already been done properly?

I've done the reverse in PDP11: AnsiCon
and in 6502 in the terminal code for XTerm

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
guidol
Posts: 38
Joined: Sun Nov 20, 2016 10:29 am
Location: Mudanya - Turkey

Re: VT100/ANSI terminal emulation via OSWRCH

Postby guidol » Thu Dec 22, 2016 6:07 pm

SteveF wrote:I think it's fit to be released.


Thats looks very nice :)
What do you think is the best way to use STEM as/for a serial Terminal on a BBC?

Is it possible to use STEM with the integrated TERM-ROM of the BBC or will another aret of terminal-programm better?
TERM seems to use ANSI and STE; VT52/102.

I want to use a serial Nullmodem-cable from the BBC to a PC/RPi.

I did read at github:
"Unlike many
other terminal emulators, it is not intended for use with a serial connection
to a remote system
; instead, it intercepts the operating system vectors to
provide terminal emulation for programs running locally."

But how about a Terminal-Program under CP/M?
Or will STEM also support a "Dumb Terminal" like
http://www.stardot.org.uk/forums/viewto ... nal#p57308

SteveF
Posts: 429
Joined: Fri Aug 28, 2015 8:34 pm

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Fri Dec 23, 2016 1:15 pm

guidol wrote:Thats looks very nice :)

Thanks!
guidol wrote:What do you think is the best way to use STEM as/for a serial Terminal on a BBC?
But how about a Terminal-Program under CP/M?
Or will STEM also support a "Dumb Terminal" like
http://www.stardot.org.uk/forums/viewto ... nal#p57308

I haven't tried either of these, as I don't have the facilities, but yes, I think both should work (assuming Acorn CP/M supports the serial port, of course).

The dumb terminal program should automatically act like a VT52 or VT102 terminal if you issue a *VT52 or *VT102 command and make sure you're in mode 0 or 3. Or of course you could just use something like Acornsoft Termulator which has its own emulation built in.

Let me know how you get on if you do try this!


I thought this would work, but on reflection it probably won't. STEM claims the OSWRCH vector and it doesn't respect the *FX3 setting, so I suspect any attempt to write to the serial port via OSWRCH will fail. I'll have a think and see if I can fix this. Watch this space! :-)

If all you want is a serial terminal, you may be best using something like Commstar or Acornsoft Termulator anyway.

Cheers.

Steve

SteveF
Posts: 429
Joined: Fri Aug 28, 2015 8:34 pm

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Sat Dec 24, 2016 12:47 am

OK, I've attached STEM 0.02a which should hopefully respect *FX3 settings properly and should therefore allow serial output (and printer output, incidentally) without getting in the way. There's a chance this will work with a CP/M terminal program (assuming that Acorn CP/M supports the serial port in the first place) or with a dumb terminal program.

I haven't been able to test the serial output (I was unable to get BeebEm's IP-based emulation to work today, though it has worked for me in the past) but I've tested with emulated printer output and I think there's a fair chance it's correct. You should definitely a) make sure your serial connection works with STEM disabled first b) not waste ages fiddling around if enabling STEM breaks the serial connection, because STEM could be buggy.

Let me know how you get on if you try it, although as noted before you might be better off with a serial terminal emulator like Termulator or Commstar - even if you're tempted by the tinkering potential of STEM, it's probably best to start with one of those standard packages first and get everything working there before branching out. (I don't know much about the TERMINAL ROM built into the Master, but I think it's pretty basic - given you can get ROMs like Termulator or Commstar for free nowadays, it's probably not worth bothering with TERMINAL. But you might want to start another thread about that, I'm sure lots of people will be able to offer recommendations on a good serial terminal emulator and how to use it - whereas most people probably aren't very interested in STEM and won't be reading this thread.)

But even if you don't end up using it, thanks for making me think about this aspect of STEM and improve it!

One note - it looks to me as though the dumb terminal program linked in your post uses local echo, i.e. any keys pressed locally are sent to the remote system *and* echoed to the local screen. This means that if you press a key in the middle of receiving an escape sequence from the remote system, the keypress will be echoed in the middle of the escape sequence and will probably mess things up. To start with you probably don't need to worry about this (just don't type while data is being received!), but you may want to disable local echo by (I think; not tested, of course) changing line 40's OSCLI "FX3,1" to OSCLI "FX3,3".
Attachments
stem-0.02a.zip
(83.51 KiB) Downloaded 15 times

User avatar
guidol
Posts: 38
Joined: Sun Nov 20, 2016 10:29 am
Location: Mudanya - Turkey

Re: VT100/ANSI terminal emulation via OSWRCH

Postby guidol » Sun Dec 25, 2016 5:33 pm

SteveF wrote:But even if you don't end up using it, thanks for making me think about this aspect of STEM and improve it!


Many Thanks for your work! - and its always good to make something better :) Thats programming with heart and soul :)
Poor me - I have to wait for my serial cable....it will be in the post at the end of the year....hopefully I could test it in the mid of January :)

User avatar
jgharston
Posts: 2658
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: VT100/ANSI terminal emulation via OSWRCH

Postby jgharston » Sun Dec 25, 2016 10:57 pm

These are the commonest OSBYTE 3 settings:
*FX3,0 normal state, serial disabled, VDU enabled, printer enabled by VDU 2, spool output if *SPOOL file open
*FX3,1 normal output, also send to serial port
*FX3,2 disable all output except printer port and any *SPOOL file
*FX3,3 disable VDU, enable serial port and any *SPOOL file
*FX3,16 normal output without copying to *SPOOL file
*FX3,18 disable all output except printer port
*FX3,23 disable all output except serial port
*FX3,86 disable all output entirely

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: VT100/ANSI terminal emulation via OSWRCH

Postby Elminster » Sun May 21, 2017 7:28 pm

This looks interesting. I want to process ansi esc terminal code in some software but by the looks of it rather than reinvent the wheel I could just activate this first, or xterm for that matter. Will have to have a play.

One question, how can I test from a piece of software that vt102 has been activated? I haven't looked at vt102 yet, only the ansi codes, so there maybe a standard way that this is done.

User avatar
jgharston
Posts: 2658
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: VT100/ANSI terminal emulation via OSWRCH

Postby jgharston » Sun May 21, 2017 9:39 pm

Elminster wrote:One question, how can I test from a piece of software that vt102 has been activated? I haven't looked at vt102 yet, only the ansi codes, so there maybe a standard way that this is done.

I haven't checked the code, but an idea is to send VDU 27 then see if the VDU queue is empty by reading OSBYTE &DA. If VT ESC sequences are not being decoded then the VDU queue will be empty as the BBC VDU 27 sequence takes no parameters. If VT ESC sequences are being decoded then the VDU queue will be waiting for the parameters. You could then use OSBYTE &DA to clear the VDU queue or complete a VT ESC command to do something innocuous.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: VT100/ANSI terminal emulation via OSWRCH

Postby Elminster » Sun May 21, 2017 10:04 pm

Thanks. Will have a play with the software this week to see if it does what I need and see what I can see using your suggestion.

SteveF
Posts: 429
Joined: Fri Aug 28, 2015 8:34 pm

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Mon May 22, 2017 2:41 pm

I think JGH's suggestion will work but I haven't tried it. If it does it's probably the easiest and best option. If it doesn't I'll see if I can take a look this weekend to make it work

Alternatively you can test for VT102 emulation being active by outputting ESC Z (VDU 27,ASC"Z") and seeing what you get back when you read from the keyboard (probably using INKEY(0) so you don't block if emulation isn't active). I'm at work now but I think if you look at some of the BASIC programs on the STEM disc image you can see a utility function to do this (which is a bit cleverer and will discard any stray keypresses). See http://vt100.net/docs/vt102-ug/chapter5.html for more on ESC Z and the responses in VT102/ANSI and VT52 mode.

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: VT100/ANSI terminal emulation via OSWRCH

Postby Elminster » Mon May 22, 2017 3:02 pm

Thanks. No hurry. I have had a quick play with STEM just to make sure the test program work, but that is as far as I have got so far.

I wondered initially if it had a Unix like environment variable that get sets somewhere, and if there was was it gobal between the various terminal on beeb. i.e. on Unix it would be

echo $TERM
xterm (or vt100 etc etc.)

The method inthe previous post would probably tell me it was a teminal that supports ANSI codes but not what flavour of terminal. That might not actually make a huge amount of difference for what I looking at as there arent that many ansi capable terminals around on Beebs.

Prime
Posts: 2301
Joined: Sun May 31, 2009 11:52 pm

Re: VT100/ANSI terminal emulation via OSWRCH

Postby Prime » Mon May 22, 2017 3:06 pm

Humm looks like you got Wordstar working, wonder if this will allow Turbo Pascal to also work on Acorn CP/M That would be good.

Cheers.

Phill.

SteveF
Posts: 429
Joined: Fri Aug 28, 2015 8:34 pm

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Fri May 26, 2017 12:10 am

Prime wrote:Humm looks like you got Wordstar working, wonder if this will allow Turbo Pascal to also work on Acorn CP/M

Yes, it does. :-)
turbo-pascal-on-stem-1.png
turbo-pascal-on-stem-2.png
turbo-pascal-on-stem-3.png

It pretty much worked out of the box, although I tweaked the terminal definition (using the standard TINST program) to not use highlighting [1], to use all 32 lines on the Acorn screen and to make it support the real cursor keys as well as the default WordStar-like ones. The biggest struggle was getting the damn files onto an Acorn CP/M format disc in the first place. :-)

I got Turbo Pascal 3.01A from http://www.z80.eu/pas-compiler.html and that's what's on the attached disc image. The "Public Domain Turbo Pascal Terminal Installer" from that page is also on there, although I ultimately didn't use that and just used TINST.

A manual is available at http://bitsavers.trailing-edge.com/pdf/borland/turbo_pascal/TURBO_Pascal_Reference_Manual_CPM_Version_3_Dec88.pdf

I'd never used it before, the editor seems a bit slow (but it may be my version of b-em running on a virtual machine which is responsible for that; I don't *think* this is STEM's fault) but the compile time is astounding (OK, it's a trivial program, but impressive even so).

[1] Terminal emulation geekery, ignore if you're mainly interested in Turbo Pascal itself... Turbo Pascal seems to like to use highlighting (=bold) for "most" text on the screen, which looks a bit ugly under STEM as the BBC doesn't have the ability to do bold via changing the text intensity and it has to be faked by "smearing" the text to give a bold effect. I did my best to make this readable and not lose the spaces between the vertical strokes in characters like 'm' and 'w', but it's not ideal when used for large quantities of text. Here's a screenshot of how it looked before I disabled highlighting in the terminal definition:
turbo-pascal-on-stem-4.png

It still runs fine, it just doesn't look great. I found a screenshot of Turbo Pascal running on a C128 under CP/M here https://i.ytimg.com/vi/CP47fa2WLrI/maxresdefault.jpg and if you look closely you can see the ">" prompt and the following text is in bold (unlike, say, the text "ogged drive"), so this is really how Turbo Pascal chooses to use highlighting and not a case of STEM's emulation going wrong. I also *SPOOLed the output and examined it to double check and it really does explicitly turn the highlighting on in these places. I'll add something to the STEM TODO list to add an option to not fake bold text by smearing, to avoid potential problems with less flexible programs which might insist on heavily using bold and can't easily be configured not to.)
Attachments
turbo-pascal.zip
(104.48 KiB) Downloaded 8 times

Prime
Posts: 2301
Joined: Sun May 31, 2009 11:52 pm

Re: VT100/ANSI terminal emulation via OSWRCH

Postby Prime » Fri May 26, 2017 9:01 am

That's execllent work, would have been useful a couple of years back when I was trying to get some of the slogger files off an Acorn CP/M disk,
It's really useful to be able to write code to handle them on the source platform, and I'm probably more familliar with Turbo Pascal (In that I still use it's decendent Delphi) than BBC basic :)

Cheers.

Phill.

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: VT100/ANSI terminal emulation via OSWRCH

Postby Elminster » Fri May 26, 2017 9:33 am

@SeveF I am still wrestling with my BASIC program that I need to get to pass through the escape code for VT100 to pickup, currently it mangles them. Does VT100 term support ANSI colour BTW, all the examples I have seen are black and white.

@Prime I had forgotten what spegatti BBBC Basic turns into without while, elseif, case statements etc. At the same time as the basic program I am also doing Pythin and C to workout what I need basic to do and they are so much easy to read. Going to have to read to the code from the start once I have 'finsihed' now that I have nearly remembered how to program in BASIC :)

The BASIC Extension ROM by Micro Power looks interesting, although it had mixed reviews, gives all those missing BASIC statements.

SteveF
Posts: 429
Joined: Fri Aug 28, 2015 8:34 pm

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Fri May 26, 2017 10:17 am

Elminster wrote:@SeveF I am still wrestling with my BASIC program that I need to get to pass through the escape code for VT100 to pickup, currently it mangles them. Does VT100 term support ANSI colour BTW, all the examples I have seen are black and white.

No, it doesn't support colour, as a) the VT102 itself doesn't and b) I wanted a true 80 column mode and those are all monochrome on the BBC. However, there's a chance STEM will quietly ignore such unrecognised escape/control sequences (because they all follow a standard structure which allows them to be parsed even if they can't be interpreted).

It's possible to use a special 4-pixel-wide font to get 80 columns in mode 1 (320x256 resolution), which gives you the ability to display 80 column text in 4 colours - I believe there's a utility on mdfs.net to do this, although I can't find it right now. That won't work with STEM so you'd have to choose between the two for your project.

Do you have a short example program I can take a look at? If you can post that and what you think it should do and what it actually does I can see where the problem lies.

Cheers.

Steve

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: VT100/ANSI terminal emulation via OSWRCH

Postby Elminster » Fri May 26, 2017 10:59 am

Not really an example, more of a theory. The program isnt really relevant as it doesnt known anything about ANSI.

I am basically looking for what you would have in Unix. Where you set the terminal in the shell, e.g. TERM=vt100 or TERM=ansi or TERM =UNKNOWN etc, and a program will indicate to a service that it supports terminal type X, and then pass ansi codes (or what ever that terminal supports) straight through and it is the shell that picks them up and deals with them. Thereby you can write a hundred programs that may display ANSI colour without the need to write anything that actually handles ANSI.

EDIT: In other words the service understands codes, the temrinal progrma understandscode, but my progrma in the middle just passes them straight through. And that program could be anything. Although you may want the progrma to generate codes itself. e.g. ls --color [sic] on Linux.

SteveF
Posts: 429
Joined: Fri Aug 28, 2015 8:34 pm

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Fri May 26, 2017 4:32 pm

I don't think that concept of an environment variable like TERM (or PATH or HOME or whatever) really exists on the (8-bit) Acorn MOS, but I'd be interested to be proved wrong.

Normally if you're writing an Acorn program you just assume it's using the Acorn MOS terminal (VDU 23=redefine character, VDU 25=PLOT, etc), or you explicitly install your own custom VDU driver and then assume that's there.

As I understand it, the TERM environment variable on Unix is there so that programs can run with a variety of different terminals, by using TERM to look up (either directly or perhaps via a library like curses) the correct codes to emit, instead of just assuming a particular terminal type as is usual on the BBC.

I suppose we could say - if we substitute "ANSI formatting codes" (e.g. bold, underline) for "ANSI colour codes" - that STEM sort of does what you want, in that your program can simply do *VT102 to turn STEM on and then it can pass through ANSI formatting codes without having to understand them itself. But I don't think there's any way the program which is generating the data your program is passing through can be "told" to use ANSI automatically because STEM has set some kind of equivalent of the TERM environment variable you can pass through to it.

I have a feeling I'm not quite getting the point here, but maybe writing this will help make it clearer exactly what it is I'm not getting. :-)

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: VT100/ANSI terminal emulation via OSWRCH

Postby Elminster » Fri May 26, 2017 5:08 pm

SteveF wrote:I suppose we could say - if we substitute "ANSI formatting codes" (e.g. bold, underline) for "ANSI colour codes" - that STEM sort of does what you want, in that your program can simply do *VT102 to turn STEM on and then it can pass through ANSI formatting codes without having to understand them itself. But I don't think there's any way the program which is generating the data your program is passing through can be "told" to use ANSI automatically because STEM has set some kind of equivalent of the TERM environment variable you can pass through to it.

I have a feeling I'm not quite getting the point here, but maybe writing this will help make it clearer exactly what it is I'm not getting. :-)


Ignore TERM, I am not suggesting that exists on BBC, was just using it to explain the pass through method on Linux, what I am trying to say is that ANSI is an abstract for software than something else deals with.

In this case with the lack of TERM I would just check if STEM was there (somehow), if not I have the choice of sending ansi escape code direct to the screen which would look horrid, or filtering them out. Which I decide owuld be pretty much on how much space that program used.

Just wanted to know if it did colour, which it doesnt. I shall worry about that later. First I need to write a program, and then workout how to detect STEM is there.

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: VT100/ANSI terminal emulation via OSWRCH

Postby Elminster » Fri May 26, 2017 5:40 pm

The short version was. My program will present a termial of unknown, and then hopefully any service will not send ANSI, and if I can detect STEM then the term type, in lieu of environment variables on the beeb, will be set to vt100. Was my plan.

SteveF
Posts: 429
Joined: Fri Aug 28, 2015 8:34 pm

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Sat May 27, 2017 9:44 pm

Cheers, I think I'm with you now!

I've tried JGH's suggestion to use OSBYTE &DA and unfortunately given how STEM currently works that isn't a possibility. I may be able to tweak STEM to make it work, but in any case it doesn't work right now. (STEM maintains its own equivalent of the OS VDU queue whose size is read by OSBYTE &DA, so when STEM is enabled and you do VDU 27, STEM's internal flag records that we are part-way through an escape sequence, but the OS VDU queue size is still zero.)

However, there are two other options which will work. If you're willing to assume any ANSI emulation will be provided by STEM if it's fitted, you can simply execute the relevant * commands to turn the emulation on and see what fails, like this:

Code: Select all

1ON ERROR GOTO 100
2*VT102 OFF
3ON ERROR GOTO 200
4*VT102
5ON ERROR OFF
6PRINT "STEM is installed and VT102 mode has been enabled"
7REM A real program would do stuff here
8PRINT "Tidying up"
9*VT102 OFF
10END
100PRINT "STEM is not installed"
101END
200PRINT "STEM is installed but has no workspace; do *STEM then try again"
201END


I imagine your code would set a flag at line 101 and do GOTO 7 or something like that; this is just an example, of course.

Alternatively you can use the DECID escape sequence (ESC Z) and interpret the response:

Code: Select all

MODE 0
*VT102 OFF
PRINT "STEM off - FNterminal_mode returns ";FNterminal_mode
*VT102
PRINT "VT102 mode - FNterminal_mode returns ";FNterminal_mode
*VT52
PRINT "VT52 mode - FNterminal_mode returns ";FNterminal_mode
*VT102 OFF
END
:
DEF FNterminal_mode
LOCAL M%,E$
REM We use DECID as it works in both VT52 and VT102 mode
VDU 27,ASC"Z"
M%=0
REPEAT
E$=FNread_escape
REM We may have read two escape sequences (e.g. the user pressed a cursor
REM key before the program started running), so we use INSTR() here.
IF E$<>"" AND INSTR(E$,CHR$(27)+"[?6c")<>0 THEN M%=102
IF E$<>"" AND INSTR(E$,CHR$(27)+"/Z")<>0 THEN M%=52
UNTIL E$=""
IF M%=0 THEN VDU 127
=M%
:
REM Discards characters up to and including ESC, then returns everything in the
REM keyboard buffer after it; returns an empty string if no ESC is seen.
DEF FNread_escape
LOCAL C%,E$
REPEAT
C%=INKEY(0)
IF C%=27 THEN E$=CHR$(27)+FNread_string
UNTIL C%=-1 OR C%=27
=E$
:
DEF FNread_string
LOCAL C$,S$
REPEAT
C$=INKEY$(0)
S$=S$+C$
UNTIL C$=""
=S$


This has the advantage that if there's another program which does the same job as STEM, your program would automatically work with it as well. This code is perhaps a bit ornate (I extracted it from the T.IN test program on the STEM disc image) but you could probably cut it down if you wanted.

Cheers.

Steve

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: VT100/ANSI terminal emulation via OSWRCH

Postby Elminster » Sat May 27, 2017 10:07 pm

Thanks for looking. Most useful. Currently I pass a term of 'unknown' so hopefully don't get ansi back. I can try auto detect, and if that gets nowhere I can fall back to user overriding and setting term type to vt100. That should cause programs to receive ansi and then get picked up by STEM.

Completely rewrote code yesterday, oh how I miss any form of elseif, once I get it work again I will try manual override method first, then if that seems to work will look to auto detect.

Taking me longer to work out bugs in code so I can try ansi than I thought.

User avatar
jgharston
Posts: 2658
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: VT100/ANSI terminal emulation via OSWRCH

Postby jgharston » Sun May 28, 2017 2:13 pm

SteveF wrote:

Code: Select all

1ON ERROR GOTO 100
2*VT102 OFF
3ON ERROR GOTO 200
4*VT102
5ON ERROR OFF
...


A better way of doing that is something like:
vtok%=TRUE:ON ERROR vtok%=FALSE
IF vtok%:*VT102 ON
ON ERROR OFF
PRINT "VT support: ";vtok%

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: VT100/ANSI terminal emulation via OSWRCH

Postby Elminster » Thu Jun 01, 2017 8:35 am

Great thanks. I know have my code working through as an unknown term now, I.e. no ansi should be sent, and when not in unknown the ansi/esc 27 codes get passed through.

Hopefully this week will try to see what STEM does with it, and put in the 'is STEM running' code if things look good.

Another question, does STEM support extended 8 bit ASCII character set? Currently if char is 128>= I just dropped it.

SteveF
Posts: 429
Joined: Fri Aug 28, 2015 8:34 pm

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Thu Jun 01, 2017 7:40 pm

Elminster wrote:Hopefully this week will try to see what STEM does with it, and put in the 'is STEM running' code if things look good.

Cool!
Elminster wrote:Another question, does STEM support extended 8 bit ASCII character set? Currently if char is 128>= I just dropped it.

STEM emulates the VT102 with some ad-hoc extensions which seemed desirable and/or easy. As far as I'm aware, the VT102 was a 7-bit device, so I got to decide how to handle characters >=128 myself. STEM allows them and just treats them as ordinary characters, using whatever character bitmap the OS VDU driver would use. So if you've exploded the font with *FX20,6 (or you're using a second processor or Master, where this is automatically the case), you can define characters 128-255 to whatever you like using VDU 23 and STEM will display them.

(What won't work under STEM is using the 8-bit control codes, which I believe are part of the 8-bit ANSI spec, at least according to https://en.wikipedia.org/wiki/ANSI_esca ... #CSI_codes. So with STEM enabled, PRINT CHR$(155);"m"; is *not* equivalent to PRINT CHR$(27);"[m";, which it would be if STEM supported 8-bit control codes. Depending on your exact use case, you could probably write some code to perform translations from 8-bit control codes to 7-bit control codes before passing them on to STEM, if that's what you want to happen.)

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: VT100/ANSI terminal emulation via OSWRCH

Postby Elminster » Thu Jun 01, 2017 8:15 pm

Depending on your exact use case, you could probably write some code to perform translations from 8-bit control codes to 7-bit control codes before passing them on to STEM, if that's what you want to happen.)


Not sure yet, only realised code was stuck in infinite loop yesterday as I hadn't handle the extra ascii codes.

Stem is installed on Master now, although the menu program is a bit tube and gosdc unfriendly. Had to manually srload stem or it hangs with tube, disabling that seems to work but gosdc boot sequence seems to interfere. Doing manually works, although with tube enabled again menu can't work out version of stem installed.

Just playing with test profs to make sure no more compatibility issues with my setup. Train is mad fast running co pro at 16mhz :)

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: VT100/ANSI terminal emulation via OSWRCH

Postby Elminster » Thu Jun 01, 2017 8:44 pm

All th etests & Demos on the Menu page seem to work okay ( with the exceptions of theones that error that they dont work on a co pro system of course). The exception is the interactive one that gets quite far through (perhaps farther than most people would bother) and then goes wrong on the main 0 key.

Not sure if an issue but thouthg I would let you know anythign I came across.

That is the smoke test complete.
Attachments
InteractiveTest_0_Issue.png

SteveF
Posts: 429
Joined: Fri Aug 28, 2015 8:34 pm

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Fri Jun 02, 2017 10:17 am

I never expected anyone except me to use any of the tests, but of course they should work! Thanks for the bug report, I'll see if I can reproduce it over the weekend. Is this STEM 0.02a? Running on a Master with OS 3.2 and a 6502 second processor?


Return to “software: other”

Who is online

Users browsing this forum: No registered users and 4 guests