VT100/ANSI terminal emulation via OSWRCH

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Mon Jul 24, 2017 8:14 pm

It's a massive hack, but I "proudly" present the catchily-named STEM 0.03xS.204813, which supports the VideoNuLA 8 colour modes (modes 101 and 102) only.

As far as I can tell from looking at the screen bitmaps in BeebEm it works but I haven't been able to test it properly. If someone could give it a go and provide feedback/a screenshot that would be great.

You'll need the VideoNuLA support ROM installed as well as this version of STEM. Then just CHAIN "T.VNULA" - this test/demonstration is not integrated with the menu.

Big list of known faults:
  • There's some kind of incompatibility with the VideoNuLA support ROM VDU extensions, probably around claiming vectors. (I'm not saying this is the support ROM's fault, just that this incompatibility exists - I need to investigate, and may come back with questions later.) This is worked around in T.VNULA by enabling the extensions just long enough to select mode 101 then turning them off before enabling STEM - I am assuming the support ROM doesn't un-set the mode when the VDU extensions are turned off.
  • It just assumes it's in one of the VideoNuLA 3bpp-bit attribute modes without checking. The output is wrong (but interestingly so) in mode 0 or 3, and the 2bpp-bit attribute modes will look even weirder.
  • Double-width text almost certainly won't look right. The fact that there's a mandatory background pixel column at the right of each character means this is never going to look good in 3bpp-bit modes anyway, but right now it will just be terrible. (Reverse video, underlining and graphics characters will all inevitably suffer from this too.)
  • I'm using Rich's "(M%ANDM%*2)*2" trick to modify the OS font bitmap to get a 5-pixel-wide font, so some characters (notably 'w') look terrible.
  • It's dog slow - it's a debug build, and I've disabled the "fast path" which normally plots "simple" characters in an optimised way.
  • Lots of other stuff I've probably forgotten.

That said, please share and enjoy! :-)
Attachments
stem-0.03x.zip
(84.35 KiB) Downloaded 8 times
Last edited by SteveF on Mon Jul 24, 2017 8:46 pm, edited 1 time 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 » Mon Jul 24, 2017 8:28 pm

Hopefully I will get chance to have a play tomorrow. My usual method of copy stuff is busted so need to do it the hardway.

Need to get new version of VideoNula ROM and STEM copied over, plus I need to dig out my 'best' working copy of my program as I was hacking about with it.

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 Jul 25, 2017 7:21 am

Okay got the latest STEM and NULA ROMs loaded. Were you expecting things like the animated ansi train stuff to get corrupted.?

EDIT: No retested but realised later I had forgotten to do *VNVDU ON (or not, still tryingto get my head aroundmodes, and vdus)


stem_nula_help.png


stem_train.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 » Tue Jul 25, 2017 9:21 am

Hmm dont think the nula demo program works quite as expected.
Attachments
VNULA_Stem_demo.png

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Tue Jul 25, 2017 9:48 am

Shame. :(

Thanks for testing this. Yes, I expected the corruption on the "proper" tests and demonstrations - this is an effect of this version of STEM assuming it is always in one of the VideoNuLA 3-bit attribute modes, because all those run in mode 0 or 3 and so that assumption is wrong.

It looks like VideoNuLA is not getting 'activated' in T.VNULA. Possibly doing the *VNVDU OFF is also disabling the attribute mode or possibly I have made some other mistake.

You could try (in non-shadow mode with tube off) doing *SAVE x 3000 8000 after running T.VNULA, then do ctrl-break, *VNVDU ON, MODE 101, *LOAD x 3000. In other words, save the screen RAM created by that test then reload it with STEM not active and the VDU extensions active. That would confirm STEM is putting the right stuff in the video RAM and it's just a question of getting the new attribute mode active at the same time.

Cheers.

Steve

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Tue Jul 25, 2017 10:02 am

PS The other thing you could try is deleting all the * commands and MODE commands at the top of T.VNULA and replacing them with something like:

*VNVDU OFF
*VT102
MODE 0
?&something=something:REM get the poke command from VNULA manual to enable attribute mode
?&somethingelse=somethingelse:REM get the poke command from VNULA manual to enable 3-bit attribute mode

I'm on phone so can't check manual myself now. But the idea is to not use the support ROM at all but program the VideoNuLA directly as a workaround.

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 Jul 25, 2017 10:15 am

I did have a bit of a play with my program and with vdvdu on/off, various old and new mode and vt102 on and off. etc.

*VT102 will hang if you dont do a vnvdu off.

Okay. Will have a further play later hopefully. Bit of a pain as my usal copy method is busted so have to physcailly move media between mac and master at the moment. Only a foot away but still a pain.

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Tue Jul 25, 2017 10:29 am

Thanks. Yes, the hang is the incompatibility I noted - probably down to claiming vectors, as both STEM and the support ROM probably claim the same vectors and something goes wrong. I haven't investigated that properly yet but in the meantime it needs to be worked around using some technique like the ones in my posts above.

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby RobC » Tue Jul 25, 2017 3:40 pm

SteveF wrote:?&something=something:REM get the poke command from VNULA manual to enable attribute mode?&somethingelse=somethingelse:REM get the poke command from VNULA manual to enable 3-bit attribute modeI'm on phone so can't check manual myself now. But the idea is to not use the support ROM at all but program the VideoNuLA directly as a workaround.

The relevant pokes for 3-bit attribute modes are:
?&FE22=&61
?&FE22=&71

If you've already got support for your own 5-wide font in STEM, it's probably easiest to drive VideoNuLA at the hardware level and leave my VDU extensions turned off.

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Tue Jul 25, 2017 4:18 pm

Thanks Rob. I am thinking you might be right - I will leave user palette setting to your support ROM but do the attribute mode setting myself. I already have some code to optionally fiddle with the CRTC settings on mode changes (to make mode 3 gapless) so it's probably easy for me to do the attribute mode setting at that point.

I will still investigate what's causing the hang (probably some kind of vector chaining problem) and try to give an error rather than hanging if the user tries to use STEM and the VideoNuLA VDU drivers simultaneously.

Elminster - can you please try those commands Rob just gave in place of the 'something'/'somethingelse' lines in my PS above? I'd hope that will get 0.03x working for the T.VNULA demo/your telnet program.

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 Jul 25, 2017 4:36 pm

Okay, so

*VNVDU OFF
*VT102
MODE 0
?&FE22=&61
?&FE22=&71
<rest of demo 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 » Tue Jul 25, 2017 4:44 pm

Ran it without the V.Nula ROM loaded at all with slightly moded code, in screen shot. But results were the same.
Attachments
No_nula.png

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby RobC » Tue Jul 25, 2017 5:04 pm

Forgot to say that you'll need to program the standard palette as per mode 2 (not mode 0) when in attribute mode :oops:

There's a program on p.44 of the VideoNuLA manual that does this (or it's the program "ATTR2" on the support disk).

(If there's a problem with my ROM, I'm happy to fix it. Extended vectors were new to me and so it's quite possible that I've messed up!)

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 Jul 25, 2017 5:23 pm

That will be an after dinner, maybe tonight test then.

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 Jul 25, 2017 8:09 pm

But of course STEM doesnt interpret esc chars in mode 2. So that is not corrupted but prints a lot of esc charaters.
Attachments
mode2_stem.png

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Tue Jul 25, 2017 9:14 pm

I think what Rob meant was to use mode 0 but use the code from appendix D of the VideoNuLA manual as the initialisation in the test, and this has the technical effect of setting up the *palette* like mode 2 but not changing the actual mode.

At the risk of being patronising, but it may save you some typing if you didn't know it, you can merge that code together with T.VNULA by doing something like:

Code: Select all

LOAD "ATTR1" (from the VideoNuLA support disc)
PRINT ~TOP-2
*LOAD T.VNULA the-four-digit-value-printed-by-the-previous-line
OLD
RENUMBER


You can then just delete the *VNVDU stuff and the MODE statement left over from T.VNULA.

I'll put together an SSD with what I think is the correct code on now anyway. Thanks for your patience with this, we'll get there in the end!

ETA: I've attached the SSD. STEM is the same (it will have a different few digits at the end of the version number, but that's all), it's just the T.VNULA program which is different.

ETA2: And here's T.VNULA in case you'd rather use this post as a reference to do the edits manually without having to use the SSD:

Code: Select all

*VT102
MODE 0
?&FE22=&40:REM Reset VideoNuLA
FOR I%=0 TO 15 STEP 4
REM Set logical colour I% to physical colour 0
REM Value sent to FE21 is physical colour EOR 7
?&FE21=(I%*16) EOR 7
REM Set logical colour I%+1
?&FE21=((I%+1)*16)+(((I% DIV 4)+1) EOR 7)
NEXT I%
REM Set attribute mode
?&FE22=&61
REM Display some colour
?&3000=2
FOR I%=0 TO 7
PRINT CHR$(27);"[";STR$(30+I%);"mColour ";I%;" ";CHR$(27);"[4mwith underlining";CHR$(27);"[0m and without"
NEXT
PRINT
S$="The quick brown fox jumps over the lazy dog."
FOR J%=1 TO 10
FOR I%=1 TO LEN(S$)
PRINT CHR$(27);"[";STR$(29+RND(8));"m";MID$(S$,I%,1);
NEXT
NEXT
PRINT


ETA3: I've tweaked the code which creates the 5-pixel-wide font from the OS bitmaps; it's still not perfect (and may never be) but it's much nicer. I've attached a new SSD with a new version of the STEM ROM (0.03x.02) with this change - feel free to test this one or the previous one, it's the changes in T.VNULA which are really critical to getting the thing basically working/figuring out why it isn't, and both of the attached SSDs have the above changes to T.VNULA in. 0.03x.02 is also a release build so will be a bit faster.

ETA4: I should just have kept posting new entries to the thread... Anyway, to be clearer, 0.03x.02 is the newest of the two attachments and should be preferred, but either is valid to test "getting things basically working and showing some colour". And you can just manually edit T.VNULA to look like the code above and use the STEM ROM I posted yesterday if that's easier for you. And the support ROM VDU drivers should *not* be enabled - perhaps do *VNVDU OFF first just to be super paranoid.
Attachments
stem-0.03x.02.zip
(84.17 KiB) Downloaded 8 times
stem-0.03x-new.zip
(84.52 KiB) Downloaded 11 times
Last edited by SteveF on Tue Jul 25, 2017 10:36 pm, edited 4 times in total.

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Tue Jul 25, 2017 9:47 pm

RobC wrote:(If there's a problem with my ROM, I'm happy to fix it. Extended vectors were new to me and so it's quite possible that I've messed up!)

Thanks Rob. I've had a look at this but please take it with a pinch of salt as I haven't yet tried to make the corresponding changes.

If you do "*VNVDU ON" then "*VT102", the machine locks up because the (VideoNuLA) support ROM has claimed REMV via the extended vector mechanism, then STEM (incorrectly) does the same, saving the previous REMV claimant from &22C so it can chain on to it. This chaining doesn't work with extended vectors - when STEM tries to chain on to the parent, it chains on to the extended vector handler at &FF42 and the OS will end up transferring control back into STEM's code via the extended vector table - so we have an infinite loop...

I am not sure if it's possible to chain extended vector handlers (it doesn't seem easy, at least - I think you'd need to patch up the extended vector entry to point to the parent, call the parent, then when the parent returns put your own extended vector entry back so the next call goes to you), and in this case I'm not sure it's worth the effort anyway. I will modify STEM so that it refuses to try to claim vectors if they are already claimed via the extended vector mechanism, then that will stop this crash.

I think the support ROM might exhibit the same bug as STEM, however. If you do "*VT102" then "*VNVDU ON" (i.e. the claims occur in the opposite order), an endless stream of '%'s is output (for me, anyway; I guess it might not fail consistently). I suspect this is caused by the support ROM trying to chain on to the parent and again ending up chaining on to itself. If so the easy fix would be the same one I'm planning to make to STEM - before claiming (e.g.) REMV, check to see if it already points to the extended vector entry at &FF42 and refuse to proceed if it does.

ETA: I hope this explanation makes sense, it's the sort of thing that calls for diagrams. I think you'll probably get it in spite of my explanation :-) but let me know if you want me to try to sketch it out via ASCII art...
Last edited by SteveF on Tue Jul 25, 2017 10:37 pm, edited 2 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 » Tue Jul 25, 2017 10:08 pm

SteveF wrote:I think the support ROM might exhibit the same bug as STEM, however. If you do "*VT102" then "*VNVDU ON" (i.e. the claims occur in the opposite order), an endless stream of '%'s is output (for me, anyway; I guess it might not fail consistently). I suspect this is caused by the support ROM trying to chain on to the parent and again ending up chaining on to itself. If so the easy fix would be the same one I'm planning to make to STEM - before claming (e.g.) REMV, check to see if it already points to the extended vector entry at &FF42 and refuse to proceed if it does.


I remember getting pages of %'s at very points of testing

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 Jul 25, 2017 10:10 pm

SteveF wrote:I think what Rob meant was to use mode 0 but use the code from appendix D of the VideoNuLA manual as the initialisation in the test, and this has the technical effect of setting up the *palette* like mode 2 but not changing the actual mode.


Misunderstood that completely then.

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby RobC » Wed Jul 26, 2017 7:06 am

SteveF wrote:ETA: I hope this explanation makes sense, it's the sort of thing that calls for diagrams. I think you'll probably get it in spite of my explanation :-) but let me know if you want me to try to sketch it out via ASCII art...

Makes perfect sense Steve. The thought

I'll put a check in the next version to see if the vectors have already been claimed and then report something like "vector already claimed by ROM n".

If you need any info on how I do colours etc., just let me know.

SteveF wrote:I think what Rob meant was to use mode 0 but use the code from appendix D of the VideoNuLA manual as the initialisation in the test, and this has the technical effect of setting up the *palette* like mode 2 but not changing the actual mode.

That's exactly what I meant. All the attribute modes expect the standard palette to be setup like mode 2 even though they are based on modes 0,1, 3, 4 and 6.

SteveF wrote:At the risk of being patronising, but it may save you some typing if you didn't know it, you can merge that code together with T.VNULA by doing something like:

Code: Select all

LOAD "ATTR1" (from the VideoNuLA support disc)
PRINT ~TOP-2
*LOAD T.VNULA the-four-digit-value-printed-by-the-previous-line
OLD
RENUMBER


The "ATTR1" program sets up a 2-bit attribute mode. "ATTR2" sets up the 3-bit attribute mode.

(Sorry for not responding sooner but my broadband has been down.)

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 Jul 26, 2017 8:33 am

Ah okay. So one of those case where when you know what some one is talking about it is obvous and when you dont it sounds like F£$T£$ wFW£ £$G£$£$F mode 2 FDSFSE 342@£ FWEWf.

Will try to find some time this evening to have a play, although thinking about it I think I am out till late this evening.

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby jgharston » Wed Jul 26, 2017 9:08 am

http://mdfs.net/Docs/Comp/Comms/ANSICodes

Don't know if I've posted this before:. Sorry for the crap formatting, why on earth do these things not have cursor keys and a menu button?

Code: Select all

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

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Wed Jul 26, 2017 9:39 am

Thanks guys.

Rob - good idea to show the ROM number in the error message, I'll see if I can do the same.

Elminster - since I used the ATTR1 program from the manual as the basis for the updated T.VNULA test the screen will not look right, but you should still see some colours. If you tweak T.VNULA to be based on ATTR2 instead that should work perfectly, but you can just do the basic test first without needing to worry about it. I'll post an updated SSD tonight.

JGH - very useful, ta - I'll look into supporting some of those codes later.

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 Jul 26, 2017 4:06 pm

Okay I retested using the original ROm with ATTR1 and ATTR2 and made no difference. But I have not downloaded the _02 (or new for that matter) yet. As didnt noticed they were added till later.

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Wed Jul 26, 2017 5:46 pm

Thanks for testing. I'm starting to think there's something massively wrong with my code then. You could try the attached but the STEM code is the same, all I've done is update T.VNULA with ATTR2's setup code instead of ATTR1.

If this doesn't work, can you please try the *SAVE/*LOAD test I sketched out the other day to see if we can narrow this down any further.

Cheers.

Steve

PS The version number of the STEM ROM has changed but that's just to try to reduce confusion; the code is the same as that in 0.03x.02 posted yesterday - it's just T.VNULA which is really different.
Attachments
stem-0.03x.03.zip
(84.17 KiB) Downloaded 6 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 » Wed Jul 26, 2017 11:00 pm

Hmmm. Not I was hoping for

splash_0303.png


foxy.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 » Wed Jul 26, 2017 11:02 pm

Perhaps this maybe

Colour_stem.png


Difference? I switched off Tube copro.

Edit: Recreatable. Steps

    - switch on machine
    - *configure notube
    - ctrl break
    - shift break (to load stem)
    - load 't.vnula"
    - 1 (deletes *vnnula off as ROM not loaded)
    - run

Edit2: Left tube off, switch machine off and on again

    - shift break (to load stem)
    - *srload vnula 8000 5 (load videonula rom)
    - ctrl break
    - chain 't.vnula"

Also works.

Edit3: Rob has already fixed one Tube but in Videonula, is this another? Or is this a STEM tube issue (STEM was working fine with tube when not trying to do pretty things)

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Wed Jul 26, 2017 11:28 pm

Woohoo! =D>

That's great! It's only a bug in the temporary hacks in T.VNULA to poke directly at the VideoNuLA hardware to set up the attribute mode. When I do this properly, STEM will do these pokes itself and (as it's running on the host at all times) it will be able to poke these registers even when using a second processor.

Thanks very much for your help with this so far.

Now that's working, I will go off in the background and start trying to tidy up the VideoNuLA support in STEM. In the meantime I'm sure you'll want to give your telnet program a go - please do post some screenshots if you get this working - and I'll leave you with an open question: what, if anything, would you like changing in the ANSI colour handling compared to this prototype?

At this moment, it completely ignores the background colour setting codes and just honours the foreground codes, as used in T.VNULA. That may well be optimal, given we don't have the flexibility to set an arbitrary combination of foreground and background colours, but I'm open to suggestions on how best to handle this. No rush, just have a think and we can discuss any thoughts you (or anyone else reading this, of course) have.

I assume you can redefine the palette using the support ROM, *possibly* before running T.VNULA (but maybe the palette setup T.VNULA does will overwrite that) or (almost certainly) by loading a saved palette after all the VideoNuLA pokes. Just don't do *VNVDU ON and there shouldn't be any clashes between STEM and the support ROM. I haven't got my head round the exact capabilities of VideoNuLA yet, but it may be that you can redefine the palette so some of the colours have a different coloured background, which may or may not be helpful and may or may not influence how you'd like STEM to interpret the ANSI colour foreground and background codes.

Cheers.

Steve

ETA: I guess you'll need the tube enabled for your telnet program to run. If you convert the poke operations in T.VNULA to use OSWORD 6 it should work. There's some documentation about it at http://beebwiki.mdfs.net/OSWORD_%2606

I haven't tested this, but probably what you need is to change:

Code: Select all

?&FExx=yy

to

Code: Select all

PROCmem_poke(&FExx, yy)

and add this:

Code: Select all

DIM block% 5:REM just once, near the top of your program

DEFPROCmem_poke(io%,val%)
A%=6
X%=block%:Y%=block% DIV 256
!X%=io%:X%?4=val%:CALL&FFF1
ENDPROC
Last edited by SteveF on Wed Jul 26, 2017 11:49 pm, edited 1 time 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 » Wed Jul 26, 2017 11:48 pm

Yep need tube for telnet as it is big slow BASIC program. Will have a play, although like many people here I have several mini projects on the boil. So you might 'completed' STEM before I get telnet sorted.

But first colour ANSI on Beeb is good to see. Keep up the good work. Home straight.
Last edited by Elminster on Thu Jul 27, 2017 12:03 am, edited 1 time 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 » Wed Jul 26, 2017 11:57 pm

As to what to implement for Colour that is more interesting. Quick think would be to go through all the ansi stuff see what is easy to do and what is impossible. Then work out themust haves, nice to haves and never use.

I think there is an official ANSI palette colour code, so that bit might be easy ( but I could be misremembering that).

It might be that just have to visit BBs, MUDs and run Linux ansi program via telnet, comparing output to same on Mac. See what looks good and bad.

Edit: colours code for ansi on Wikipedia good a start as any (3/4 way down)

Edit2: I guess colour code for terminal.app would make most sense as that is what I would be using for comparison. I guess no reason could ten have a putty or xterm palette for windows, Linux users to use the colours they are used to maybe.


Return to “software: other”

Who is online

Users browsing this forum: No registered users and 2 guests