VT100/ANSI terminal emulation via OSWRCH

discussion of beeb/electron applications, languages, utils and educational s/w
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 Jun 02, 2017 12:30 pm

Very good question, downloaded a while ago, not sure if .02 or 0.2a. Will check later.

Mos 3.5 and 6502 internal copro (John K. Remake)

But I can test on 3.2 if you think that may make a difference.

Stem worked as expected in my testing, text ansi it successfully sorted, colour ansi it doesn't like, and neither of us handles extend 8 Ascii.

I think my next task is write, or borrow, some vdu 23 commands that sort all the extra characters.

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Fri Jun 02, 2017 3:46 pm

Cheers, I'll test with MOS 3.5 then. If you can post the STEM version later please do but I suspect it doesn't make any difference - 0.02 and 0.02a shouldn't (which isn't to say they don't :-) ) really differ in input handling.

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Fri Jun 02, 2017 10:27 pm

I've had a bit of a play with this - under emulation only, I'm afraid - and the input test seems to work fine for me on MOS 3.2 and 3.5.

I hate to suggest user error - but the input test *is* extremely tedious so it's easy to miss things - but did you see and follow the "Press f7 to turn keypad emulation on before continuing" instruction which (I think) would just have scrolled off the top of the screen in your screenshot? (The test can't check to make sure you've done this directly, since the corresponding flag is buried inside STEM's workspace and that can shift around depending on all sorts of things. I didn't want to provide some way - e.g. an OSBYTE - to query this status just to support a test case, but I appreciate it just adds to the unfriendliness of the test.)

What seems to be happening here is that it's on line 56 of "T.IN" - PROCe("0", "-") - where it's expecting the user to press the "0" key (the main one, as you correctly identified, not the Master keypad one) and receive "-" as input, whereas your screenshot shows it's receiving "0" and getting upset. That would happen if you hadn't pressed f7, since under normal circumstances of course the "0" key enters "0".

The keypad emulation toggled via f7 is not really necessary on the Master, of course, since there's a physical hardware numeric keypad, but it is still available as an option and hence the test case tests it.

If you don't think this is the problem I can try to produce a cut down version of the test you can try to see if it always goes wrong for you or if it's intermittent without you having to sit through the entire test - but I'm a bit concerned that if I cut the test down and it works for you it might be because I've accidentally avoided triggering a bug. So I thought I'd ask what you thought of the above first.

(I *can* reproduce the somewhat odd hang-and-it-doesn't-actually-SRLOAD-properly when booting the disc image on MOS 3.5 with a second processor. I'll see if I can do anything about that. It's only a bug in the menu code for the demonstration/test suite, it doesn't affect STEM in actual real use.)

Cheers.

Steve

PS I've tweaked the input test to show what it's expecting to see when it doesn't see it. STEM 0.02b is attached with this change, and also a bug fix to the *FX3 handling I added in STEM 0.02a (nothing to do with this problem).
Attachments
stem-0.02b.zip
(83.54 KiB) Downloaded 9 times

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 Jun 02, 2017 10:57 pm

SteveF wrote:I've had a bit of a play with this - under emulation only, I'm afraid - and the input test seems to work fine for me on MOS 3.2 and 3.5.

I hate to suggest user error -


Very unlikely.

Wasnt the keypad, had already done those.

Was the main numbers. You can see I was working my way through, 8 was okay, 9 was okay. You can see from screen short it asked for 0, it registers I pressed 0, but then gives an error. So not likely a user error. Once maybe but X times?

Edit: Hang on I might need to read your post again, just to make sure I understand the bit about f7.

Edit2: I will do the test again, I think I followed all the instructions but couldnt say for sure, so will do it again. But not tonight! :)

Edit3: I think I used 0.02. So will do the test again with 0.02b

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Fri Jun 02, 2017 11:03 pm

Thanks. I might as well waffle a bit here, since I never actually wrote any proper documentation...

Obviously a Master has a physical hardware keypad, which can be used as a decent approximation to the hardware keypad on a real VT102.

I wanted STEM to be usable on a B/B+ even if the underlying application relies on the VT102 keypad, so pressing f7 toggles a sort of "virtual numeric keypad" which uses a roughly parallelogram-shaped block of keys on the main keyboard as an imitation of the VT102 keypad (7890 UIOP JKL; M,./) (I think some laptops do/did something similar.) Keys 7/8/9 are identical in both modes, but the key to the right of '9' on the VT102 keypad is "-" (there's a picture of the keyboard here: https://alum.wpi.edu/~tfraser/Machines/vt102.jpg) so when the virtual keypad is on, the main "0" key produces "-", which is what this test is trying to test.

You can see this at the command prompt without using the test. Just do:

Code: Select all

*VT102
MODE 0
<press the '0' key - it prints '0'>
<press f7>
<press the '0' key - it prints '-'>
<press the 'U' key - it prints '4'>
<press f7>
<press the '0' key - it prints '0'>
Last edited by SteveF on Fri Jun 02, 2017 11:18 pm, edited 3 times in total.

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 Jun 02, 2017 11:05 pm

3 screen shots.

one - No vt100 emulation
two - Emulation on
three - knocked up the gfx chars in extended ascii quickly (option 0 from menu screen in above screenshot), will look to use full set in other post

Getting there
Attachments
No_vt102_test.png
vt102_test.png
extend_ascii_test.png

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Fri Jun 02, 2017 11:09 pm

Looking good!

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Fri Jun 02, 2017 11:26 pm

Incidentally (and nothing to do with the possible bug we've been discussing) I notice that in the no emulation screenshot, you can see that the BBS is sending (ESC, I assume) [6n - just after it says "Detecting terminal emulation". When STEM's enabled, it should see that escape sequence, recognise it as requesting a report on the cursor position and insert a suitable response (another escape sequence) into the keyboard buffer - if your code passes that through to the BBS I'd hope it will no longer detect as ASCII but as ANSI when emulation is on. You can see this happening in this screenshot:
Screenshot from 2017-06-03 00-24-16.png

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 Jun 02, 2017 11:42 pm

I think it means ascii capability detected, but not ansi colour. I have the source I code check.
Quite a good test case as does ansi mono, extended ascii and ansi colour. I pass anything that starts with a 27 through, with exception of some control characters every thing just gets printed..

The term type being sent is 'vt102' or might be 'vt100', forget what I set it to when the stem detection code detects it. I know that get passed as I hacked up a server to check. Unknown when stem not running, vt10x when it is.

Hopefully when I put in better bitmap for vdu 23 the title page will look better. Should read 'mystic', but I must have spent all on 10 mins on those bitmaps!

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 Jun 03, 2017 11:22 pm

Uploaded of screen shot of title screen will full 8but Ascii from Jonathan's CharRom IBM character set. Looks similar but now have all the characers rather than just 6. Bits cricled in green are odd characters I ned to workout what they are meant to be.

So all I think I am missing now is colour ANSI.

Not tested Stem 0.2b yet, but as it looks like in the other post there is a MOS 3.5 test, might be worth I wait till that fix is done?
Attachments
extend_ascii_test_charrom.png

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Sun Jun 04, 2017 4:26 pm

Elminster wrote:Not tested Stem 0.2b yet, but as it looks like in the other post there is a MOS 3.5 test, might be worth I wait till that fix is done?

I've applied the fix we were discussing in that thread but that only relates to the hang when the menu tries to automatically load STEM into sideways RAM on OS 3.5 - it shouldn't have any bearing on the input test on any OS.

However, I've attached 0.02c which contains that fix so if you can try that and let me know how you get on I'd appreciate it.

Cheers.

Steve
Attachments
stem-0.02c.zip
(83.62 KiB) Downloaded 11 times

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 Jun 04, 2017 6:25 pm

SteveF wrote:I've applied the fix we were discussing in that thread but that only relates to the hang when the menu tries to automatically load STEM into sideways RAM on OS 3.5 - it shouldn't have any bearing on the input test on any OS.

However, I've attached 0.02c which contains that fix so if you can try that and let me know how you get on I'd appreciate it.



More because i create a disk on the gosdc and that usually means removing the card and putting in Mac. Easier to do it once. Will give new version a go hopefully this evening.

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 Jun 04, 2017 7:38 pm

Test completed. Everything was 'OK'

Also the menu/srload code works fine with copro/MOS 3.5 now.

Only 2 comments I have if you are in the mood.

1. Menu still stays 'Installed version: undetermined'.
Due to the copro, not sure if it is possible for it to detect it when there is a copro (added screenshot in case not clear what I mean)

2. When you press F7 for keypad emulation mode on the Interactive test, it would be good for feedback it did something (only reason is sometimes the keys on the Master need a harder tap to make them work, getting old, and wasnt 100% sure if it had done anything, so ended up pressing about 3 times just to check!)

But looks good. And the actual code works fine.
Attachments
stem2c_menu.png

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Sun Jun 04, 2017 10:21 pm

Thanks very much for testing this, I'm glad it worked in the end!

I will have a think about the issues you raise - they're both sensible and I can probably find solutions for them if I try hard enough. :-)

I do already have a TODO comment in the code about maybe making a discreet bleep noise when f7 is pressed. What would you think about that? (I was thinking something like you might get by issuing "SOUND 1,-5,100,3".)

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 » Sun Jun 04, 2017 11:09 pm

SteveF wrote:Thanks very much for testing this, I'm glad it worked in the end!

I will have a think about the issues you raise - they're both sensible and I can probably find solutions for them if I try hard enough. :-)

I do already have a TODO comment in the code about maybe making a discreet bleep noise when f7 is pressed. What would you think about that? (I was thinking something like you might get by issuing "SOUND 1,-5,100,3".)


No Problem.

I think any sort of feedback would be fine. So if you did 'Press f7 to activate keypad, note: it will make a beep noise when activated' or words to that effect would be fine (and then it beped). I just wasnt sure if it was working (my hash key on keypad playing up today so got a bit paranoid).

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 Jun 05, 2017 10:49 pm

Question.

When I force software to send ANSI colour codes with STEM off I see them. e.g. ESC[31m for Red foreground colour. With STEM on I dont see them come through. Does STEM drop them, or does it negotitate some how and tell the sender it is mono only? Or something else?

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Tue Jun 06, 2017 1:35 pm

I'm pretty sure STEM will ignore them - it has no way to negotiate with the sender. The control/escape sequences used have a standard structure which allows them to be parsed even if they're not otherwise understood, and STEM will silently ignore things it doesn't understand. I think this is what a real VT102 would do given an unknown sequence, and it seems better than outputting junk to the screen.

(If you want to process these yourself you'd need to parse the input in your code, buffering characters between ESC and the end of the sequence, then act on the sequence yourself or write the whole sequence via VDU/PRINT/OSWRCH so STEM sees it. However, in the specific case of colour sequences I'm not sure there's much you could do with them. Unless you tried to use interrupt-driven code to redefine the colours on the fly so different lines can use different colours, which would be very cool and probably quite hard...)

Cheers.

Steve

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Tue Jun 06, 2017 2:39 pm

PS I guess in a limited sense STEM *does* have ability to negotiate with the sender - the other end can use an escape sequence to query the terminal type (as one of the BASIC programs I posted earlier does), STEM will reply (in effect) "I'm a VT102" and the other end may then say "oh, it's a plain old VT102, I won't send colour codes". So that might be happening instead. But the negotiation is at the level of terminal type, there's no "what capabilities do you support?" "capabilities X, Y, Z" type negotiation.

To tell the difference you'd need to observe the data flowing back and forth. Or *SPOOL the output to a file and see if the colour control sequences are in there - if they are, they're being sent to STEM and ignored. If they're not then the sender is somehow recognising they're unsupported and not sending them.

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 » Tue Jun 06, 2017 4:15 pm

From my program I tried forcing it to a term that supports colour ansi but still didnt come through. Colour codes were only coming through with no STEM. But as to where they are going I didnt look further.

As this is over TCP/IP I shall probably fireup wireshark. I can then also compare a unix client running mono and colour capable ansi client. And play spot the difference.

Of course even if the colour codes were coming through I am not sure what I would do with them. As mode 3 being a text mode only supports 2 colours and standard ANSI colour is 8+8 (+8 being bright and not flash). Mode 2 only give 20 columns.

Food for thought. This is a backburner one I think, as have other stuff to get on with.

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 » Wed Jun 07, 2017 8:33 am

Posted question on the Nula post and RobC thinks a 80x25 + 8 maybe 8+8 colour display maybe possible wiht his hardware.

viewtopic.php?p=172039#p172039

If it is htat would be great as that would open up the possiblity of full colour ansi displays in mode 3.

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Thu Jun 08, 2017 3:00 pm

That does look pretty cool! It would also potentially allow true bold (instead of 'smearing' the character definitions to give a bold effect) and (less usefully) flashing text.

However, STEM writes directly to the screen RAM rather than going via the OS (partly for speed, but also because it was probably easier on the whole as you're not fighting with the OS's un-VT102-like behaviour) so a special version would need to be written - it wouldn't "just work" if the hypothetical new video ULA support ROM is activated.

I'd certainly be interested in having a go at such a version if there was an emulator which had the necessary support, or I'm happy to advise anyone else who feels like having a go at modifying STEM appropriately.

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 08, 2017 3:39 pm

I guess STEM would stay STEM and ATE (Ansi Terminal Emulator) would be born. Or maybe KATE (Kolour ANSI Terminal Emulator).

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Thu Jun 08, 2017 3:49 pm

Maybe, though it might be nice to have a single version which supports modes 0 and 3 as now and the new colour modes given the right hardware, space permitting. I guess we'll see what happens once real or emulated hardware becomes available and how the community implements support in other code.

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 08, 2017 4:37 pm

Think it depends if you can get it in one ROM. Otherwise if STEM became 2, plus ROM for new hardware, and maybe application on a ROM than does colour ANSI, you have used 4 rom/sram slots. Which would be a pain.

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 Jun 09, 2017 3:55 pm

My project I am using STEM for is discribed here

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 Jul 23, 2017 8:56 am

I have my videonula now, just waiting for full ansi colour STEM [-o<

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Sun Jul 23, 2017 11:48 am

What I need to make progress here is some kind of emulator with VideoNULA support... It doesn't have to be perfect (e.g. get the aspect ratio correct or support 1-pixel horizontal scrolling) but it needs to be able to support the new attribute modes enough for me to start playing around with them. I see there's a thread in the emulator section and some interest, so fingers crossed. :-)

RobC
Posts: 1823
Joined: Sat Sep 01, 2007 9:41 pm

Re: VT100/ANSI terminal emulation via OSWRCH

Postby RobC » Sun Jul 23, 2017 12:42 pm

Hi Steve,

Do you want to borrow one of my own VideoNuLAs?

Happy to post one to you.

Cheers,

Rob

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Sun Jul 23, 2017 3:26 pm

Hi Rob,

Thanks, that's very kind of you, but unfortunately I don't have physical access to my Acorn hardware most of the time - it lives at my parents' place for want of space in my flat - so I do most of my development on emulators.

It has occurred to me that it *might* be semi-feasible to do this development without proper emulator support by:
  • installing the VideoNULA support ROM in the emulator even though there's no video NULA - since AIUI the hardware is write-only, this would work, but the display would be corrupt
  • saving the screen memory of the emulator to a file
  • using a program on the emulator host OS to translate the screen memory dump into a full-colour PNG image

It would be much more fun with a proper emulator though, so my inclination is to wait a few weeks and see if anyone takes up the emulation challenge. Or maybe I'll try to kludge something together myself.

Cheers.

Steve

PS Do you intend to make the support disc image available for download to the general public? Perhaps you already have and I've missed it. I appreciate you might want to restrict distribution, at least for an intial "beta test" phase, of course. I see you answered this in the other thread, thanks!

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 Jul 23, 2017 8:49 pm

Obviously I can do the testing of STEM with my real VideoNULA, which seems to be working great, but as you say emulator support would make it much easier to develop.


Return to “software: other”

Who is online

Users browsing this forum: cmorley and 5 guests