VT100/ANSI terminal emulation via OSWRCH

discussion of beeb/electron applications, languages, utils and educational s/w
RobC
Posts: 1821
Joined: Sat Sep 01, 2007 9:41 pm

Re: VT100/ANSI terminal emulation via OSWRCH

Postby RobC » Thu Jul 27, 2017 8:05 am

Good to see that working :D.

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

The "ATTR1" and "ATTR2" programs are just intended as examples to illustrate how the attribute modes work. As they stand, they won't work on a co-pro as they poke directly into I/O memory (a bad habit of mine!) as Steve has pointed out. I'll correct the manual and support disk so that they use legal means.
Last edited by RobC on Thu Jul 27, 2017 9:28 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 » Thu Jul 27, 2017 8:50 am

RobC wrote:Good to see that working :D.

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

The "ATTR1" and "ATTR2" programs are just intended as examples to illustrate how the attribute modes work. As they stand, they won't work on a co-pro as the poke directly into I/O memory (a bad habit of mine!) as Steve has pointed out. I'll correct the manual and support disk so that they use legal means.


Tut Tut [-X :)

@Steve. Another thought. Probably want to think how colour ansi gets switched on. Usually this would be automatic as soon as you come to an ansi colour code but because of the way Rob has to split things to get the extra colours people are going to need a very good monitor (i.e. not sure a retro cub would be up to it) to read it without getting a headache.

So perhaps a *VT102 COLOUR (which equates to ON+Colour ANSI) maybe. If vt102 on but not colour it processes the codes (so you dont get any garbages esc codes on the screen) but just passes them out as B&W. Does that sound sensible.

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby RobC » Thu Jul 27, 2017 9:27 am

Elminster wrote:Tut Tut [-X :)

I'll hopefully learn my lesson this time!

Elminster wrote:@Steve. Another thought. Probably want to think how colour ansi gets switched on. Usually this would be automatic as soon as you come to an ansi colour code but because of the way Rob has to split things to get the extra colours people are going to need a very good monitor (i.e. not sure a retro cub would be up to it) to read it without getting a headache.

I've been using the 3-bit attribute mode on a CM8833 with JGH's thin font without any issues. I'm actually starting to prefer it to the normal Beeb modes.

One of things on my TODO list is to get my 1431 Cub out of storage and use that with VideoNuLA for a bit. It'll need the analogue mod (something I haven't done for years) and I want to document the process. (It may be heresy but I never really liked the standard Cubs :shock:)

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 Jul 27, 2017 9:53 am

RobC wrote:I've been using the 3-bit attribute mode on a CM8833 with JGH's thin font without any issues. I'm actually starting to prefer it to the normal Beeb modes.

One of things on my TODO list is to get my 1431 Cub out of storage and use that with VideoNuLA for a bit. It'll need the analogue mod (something I haven't done for years) and I want to document the process. (It may be heresy but I never really liked the standard Cubs :shock:)


Be interested to know the results.

Generally my master uses an internet KVM and displays its screen on my mac via a JAVA applet it is good enough for black on white on 'fat' font. But with skiny it is hard to read, I need to try hooking it up to my 12inch LCD (nearest i have to a cub) to see what it is like.

It will certainly be clearer that the KVM (which is RGB Cable -> RGB Splitter -> RGB to HDMI convertoer -> HDMI to VGA Convertor -> to KVM Dongle -> Over Cat5 -> KVM -> Over TCP/IP -> Java applet). As you can understand it is a bit noisy.

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Fri Jul 28, 2017 9:31 am

Elminster wrote:@Steve. Another thought. Probably want to think how colour ansi gets switched on. Usually this would be automatic as soon as you come to an ansi colour code but because of the way Rob has to split things to get the extra colours people are going to need a very good monitor (i.e. not sure a retro cub would be up to it) to read it without getting a headache.

So perhaps a *VT102 COLOUR (which equates to ON+Colour ANSI) maybe. If vt102 on but not colour it processes the codes (so you dont get any garbages esc codes on the screen) but just passes them out as B&W. Does that sound sensible.


It's almost like you read my mind. What I hope to implement are four mutually exclusive new options (names subject to change) ULA/NULAATTRIBUTES/NULA4COLOUR/NULA8COLOUR. ULA will be the default and uses standard 2 colour mode just like STEM 0.02 always did. The others will set up VideoNuLA in 4, 4 and 8 colour attribute modes respectively.

NULAATTRIBUTES will use 4 colour attribute mode but set the colour based on the bold and flash attributes, so with a suitable palette you can get a nicer/more accurate display for applications which don't use colours (e.g. WordStar, Turbo Pascal). (Flash will effectively be optional as you can always set the palette to have that colour non-flashing. Or you could set the colours up according to preference, e.g. use non-flashing yellow-on-red text for 'flash', red for 'bold' and white for ordinary text.)

NULA[48]COLOURS will allow the application to set colours using the ANSI codes. The prototype I've posted is effectively NULA8COLOUR mode.

The ANSI colour codes will be silently ignored in ULA and NULAATTRIBUTES mode.

I'm reasonably confident all this will fit in the ROM so we can have a single build of STEM which supports machines with and without VideoNuLA, but we'll see how it goes. I hope to get some time to work on this over the weekend...

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 Jul 28, 2017 12:38 pm

Yep that sounds ideal. Hoping to have my piece of broken file transferness fixed this weekned as well, will make testing much easier.

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Tue Aug 01, 2017 10:27 pm

Not sure if I should ask this in the main VideoNuLA thread but it's perhaps a bit niche so I'll start here anyway, since I believe Rob is reading this thread occasionally as well...

Thanks to Kieran's b-em changes I'm doing some work to tidy up the VideoNuLA support in STEM. It seems to me that if the support ROM is *not* present, pressing BREAK or CTRL-BREAK leaves VideoNuLA's settings unaltered - so if I've run (e.g.) the ATTR2 program, then do CTRL-BREAK and MODE 0, I get a garbled screen. I assume the support ROM does ?&FE22=&40 on reset to avoid this.

It is tempting to have STEM do ?&FE22=&40 on reset as well, but on a machine without a VideoNuLA that will poke the regular ULA control register and potentially upset things - though, I think, only until the OS next updates this on vsync - but still, it has an ugly glitch-like effect (at least judging from BeebEm).

So my question is, is it possible to reset VideoNuLA in a way which is invisible/safe if the machine actually just has the regular ULA? STEM has this problem here as it supports both cases, whereas the support ROM can reasonably assume you actually have a VideoNuLA if you've installed it.

The obvious thing to do would be for STEM to record when it turns VideoNuLA on and use that to decide what to do on reset, but unfortunately my ROM workspace byte at &DF0+X is already bursting at the seams and I'm not aware of anywhere else I can reliably store this information across CTRL-BREAK. I can think of various special case hacks but I'd rather not go there if I can help it...

I hope this makes sense, I appreciate it might be quite waffly. (Another good reason to keep it out of the main VideoNuLA thread I guess. :-) )

ETA: I'm sure it's not unreasonable to assume anyone using STEM with VideoNuLA will have the support ROM installed anyway, but all the same, I'd like to handle the case where the support ROM isn't present nicely if it's possible.

ETA2: I have observed that under no-VideoNuLA-support emulators, having the support ROM loaded seems to make BREAK/CTRL-BREAK slow - I've occasionally had trouble booting discs because I don't hold SHIFT long enough. I find myself wondering if this is in some way an artefact caused by the emulator responding to this reset operation hitting the regular ULA - could that be the case? Or does this happen on a real machine? Just curious, it's obviously not sensible to load the support ROM on a machine without VideoNuLA normally so I kind of deserve all I get. :-)

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby RobC » Wed Aug 02, 2017 7:34 am

SteveF wrote:It seems to me that if the support ROM is *not* present, pressing BREAK or CTRL-BREAK leaves VideoNuLA's settings unaltered - so if I've run (e.g.) the ATTR2 program, then do CTRL-BREAK and MODE 0, I get a garbled screen. I assume the support ROM does ?&FE22=&40 on reset to avoid this.

Yes - the VideoNuLA board doesn't know BREAK has been pressed so retains its settings. With the support ROM installed, it does ?&FE22=&60, ?&FE22=&70 on reset to ensure that we don't remain in an attribute mode. Doing &FE22=&40 will also reset the extra palette, horizontal offset etc.

SteveF wrote:It is tempting to have STEM do ?&FE22=&40 on reset as well, but on a machine without a VideoNuLA that will poke the regular ULA control register and potentially upset things - though, I think, only until the OS next updates this on vsync - but still, it has an ugly glitch-like effect (at least judging from BeebEm).

Unfortunately, this is unavoidable in a machine that doesn't have VideoNuLA as the registers aren't fully decoded. (It's also why I include the ability to disable VideoNuLA from software just in case any software writes to FE22/FE23 expecting to write to FE20/FE21.)

SteveF wrote:So my question is, is it possible to reset VideoNuLA in a way which is invisible/safe if the machine actually just has the regular ULA? STEM has this problem here as it supports both cases, whereas the support ROM can reasonably assume you actually have a VideoNuLA if you've installed it.)

The obvious thing to do would be for STEM to record when it turns VideoNuLA on and use that to decide what to do on reset, but unfortunately my ROM workspace byte at &DF0+X is already bursting at the seams and I'm not aware of anywhere else I can reliably store this information across CTRL-BREAK. I can think of various special case hacks but I'd rather not go there if I can help it...

Unfortunately not in a way that's invisible but, as you've said, the OS will sort itself out on the next vsync when it changes the flash bit.

I think recording that you've turned it on is the best option if you want to avoid the glitching. I use the unused bytes in the &39F-&3A6 region - if there's no VideoNuLA support ROM, you could use one of these.

SteveF wrote:I hope this makes sense, I appreciate it might be quite waffly. (Another good reason to keep it out of the main VideoNuLA thread I guess. :-) )ETA: I'm sure it's not unreasonable to assume anyone using STEM with VideoNuLA will have the support ROM installed anyway, but all the same, I'd like to handle the case where the support ROM isn't present nicely if it's possible...

I think this is wise as the VideoNuLA board is designed to function with or without the support ROM.


SteveF wrote:ETA2: I have observed that under no-VideoNuLA-support emulators, having the support ROM loaded seems to make BREAK/CTRL-BREAK slow - I've occasionally had trouble booting discs because I don't hold SHIFT long enough. I find myself wondering if this is in some way an artefact caused by the emulator responding to this reset operation hitting the regular ULA - could that be the case? Or does this happen on a real machine? Just curious, it's obviously not sensible to load the support ROM on a machine without VideoNuLA normally so I kind of deserve all I get. :-)

I'll have a look at this - most of my testing has been on machines with VideoNuLA but I've done some testing on BeebEm and haven't noticed a problem. It's not really doing a great deal if the VDU drivers are turned off so there shouldn't be much of a delay. Which emulators are you using?

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Wed Aug 02, 2017 9:31 am

Thanks Rob - good point about not resetting using &40 to avoid altering the extended palette too. I will have a think about this and maybe come back with more thoughts later. I wanted to reply now to answer your question about emulators - I have been using b-em on Linux and BeebEm (4.14? not at home right now) for Windows running under Wine on Linux. In hindsight it *might* only have been slow with the *VNVDU drivers on, so perhaps nothing to worry about. (Is reinstating the VDU drivers on reset a lot of work?)

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby RobC » Wed Aug 02, 2017 10:00 am

SteveF wrote:Is reinstating the VDU drivers on reset a lot of work?

The redirection of the vectors is fairly trivial. The only time consuming part is restoring the font on a soft break - this is simple on a B/B+ as it just has to redirect some pointers but the font definitions need to be copied on a Master/Compact.

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Wed Aug 02, 2017 11:11 am

Ah, that makes sense, thanks. Random thought - could you use *FX20,6 to reset the font definitions on the Master? I *think* it has that effect but I haven't checked. Would that be faster? Maybe you already are anyway, and I haven't timed that call.

ETA - sorry, I guess you meant 'set the font to narrow' is what takes the time, not 'set the font back to the OS definitions'...

User avatar
Rich Talbot-Watkins
Posts: 1121
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: VT100/ANSI terminal emulation via OSWRCH

Postby Rich Talbot-Watkins » Wed Aug 02, 2017 4:03 pm

The easiest way is probably just to accept that there'll be a glitch and hide it.

So, for example:
- Select appropriate MODE if necessary
- Turn off display (?&FE00=8:?&FE01=&F0)
- Reset VideoNuLA
- Set flash rate to 1 so that the OS sets FE20 straight away (*FX 9,1 / *FX 10,1)
- Wait for vsync (*FX 19)
- Turn on display again (?&FE00=8:?&FE01=&C0)

At least like that it doesn't look ugly.

(or you could just do the reset immediately before setting the MODE, if that's an option)

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Wed Aug 02, 2017 10:11 pm

Thanks Rich, that's an interesting idea - but if I'm doing this on BREAK/CTRL-BREAK, won't the screen blank be noticeable because the OS will have already written the startup banner ("Acorn MOS" or whatever) before my ROM gets a chance to kick in, and it will flash off and back on again? I can see this would work if I was doing a mode change and needed to do a discreet reset of VideoNuLA if fitted. Sorry if I'm missing your point... My situation is that my ROM has turned on VideoNuLA attribute mode and is using it, the user presses BREAK/CTRL-BREAK at some arbitrary point and I would like to quietly turn off attribute mode in response to one of the ROM service calls issued on BREAK/CTRL-BREAK so the OS VDU drivers work correctly without the user having to type ?&FE22=&40 or similar.

I did wonder if there's any mileage in doing something like this (pseudocode):

Code: Select all

busy-wait until vsync occurs
LDA #&60:STA &FE22
LDA #&70:STA &FE22
LDA &248 \ get OS RAM copy of ULA control register
STA &FE20

The idea being to wait for VSYNC and then (on a standard ULA machine) write bad data to the ULA control register very very briefly before writing the correct value again - with the hope that by doing this right after VSYNC the glitch would not be visible.

I have no idea if this would work, or if it's actually possible to busy-wait until vsync occurs, but I thought I'd raise the possibility. I'm well outside my comfort zone here... :-)

ETA: I am aware of *FX19, but I was thinking it's maybe important to get this done ASAP after VSYNC rather than waiting for the OS to return in order to locate the brief glitch off-screen. But I am probably betraying a woeful lack of knowledge of the CRTC and how frames are generated here...

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby RobC » Thu Aug 03, 2017 7:47 am

SteveF wrote:Thanks Rich, that's an interesting idea - but if I'm doing this on BREAK/CTRL-BREAK, won't the screen blank be noticeable because the OS will have already written the startup banner ("Acorn MOS" or whatever) before my ROM gets a chance to kick in

I think this depends on which service call(s) you hook into - some fire before the banner is printed. Somewhere I've got a trace ROM image that shows the calls as they fire.

User avatar
Rich Talbot-Watkins
Posts: 1121
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: VT100/ANSI terminal emulation via OSWRCH

Postby Rich Talbot-Watkins » Thu Aug 03, 2017 9:00 am

SteveF wrote:I did wonder if there's any mileage in doing something like this (pseudocode):

Code: Select all

busy-wait until vsync occurs
LDA #&60:STA &FE22
LDA #&70:STA &FE22
LDA &248 \ get OS RAM copy of ULA control register
STA &FE20

That actually seems like the best possible way to handle it. You probably wouldn't even need to wait for VSync.

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Thu Aug 03, 2017 9:31 pm

Thanks Rich. I've implemented that for now without any wait for vsync; I can't see any glitches in normal (standard ULA) emulators, but that doesn't mean they won't occur occasionally or be more visible on real hardware, but let's stick with this for now and see how it works out. I do have an idea how I could store an "I turned attribute modes on, I need to turn them off" flag in the ROM's workspace 99.9% reliably across BREAK/CTRL-BREAK anyway, but it would be nice not to have to faff with that if I can avoid it. :-)

ETA: I might as well attach a copy of the work-in-progress code. This should make a half-decent stab at supporting "*VT102 NULAATTRIBUTES" (VideoNuLA colours used to represent VT102 bold/flash attributes) and "*VT102 NULA8COLOUR" (VideoNuLA colours exposed via the ANSI foreground codes, as all the previous VideoNuLA-supporting versions posted to this thread did), without the user needing to assist it by poking the VideoNuLA registers. I won't bother listing all the known issues with it, but I hope this is at least as good as the previous version. Feedback welcome, but don't go out of your way to test it - I hope to have a slightly more polished version available within the next few days.

I should perhaps point out here that abbreviations are supported for *VT102 options. So you can just do "*VT102 NULAA." or "*VT102 NULA8." to save typing.

This should work just fine without the VideoNuLA support ROM installed, but it should also co-operate better if it is installed - it will generate an error if you try to do *VT102 after *VNVDU ON, rather than crashing.

ETA2: I'm toying with changing the *VT102 command to *ANSI; does anyone else care? This would reflect the new ANSI colour abilities, and the VT102 manual itself does refer to the terminal's two emulation modes as "VT52" and "ANSI" not "VT52" and "VT102" so it's not really inappropriate even when viewing STEM as a VT102 emulator (which was my original goal and is one I intend to keep supporting along with the new-fangled ANSI colour stuff :-) ).
Attachments
stem-0.03x.04.zip
(83.87 KiB) Downloaded 8 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 » Thu Aug 03, 2017 9:47 pm

Great. I will have to test it. Just waiting to get my storage back up and running.

I was waiting for a new psu for my NAS, then I was waiting for a molex removal tool, then new molex atx pins, now just waiting for a molex crimp tool. Then I will be back in business (My buying a PSU for half the price of buy it from Qnap was not the money saving plan I had hoped for as it had the wrong connector on even though it was the exact same make and model psu. :) )

Edit: I dont mind what you call it (ANSI/ VT320 etc), as long as once you have decided you stick with it :twisted:

Edit2: I will probably need to work out whether it is running in vt320 mono or colour ANSI though. So that i can pass on the correct temrinal type to a Linux server etc.
Last edited by Elminster on Thu Aug 03, 2017 9:50 pm, edited 1 time in total.

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Thu Aug 03, 2017 9:49 pm

The race is on! Will I get a more polished version up before you get your hardware back 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 » Thu Aug 03, 2017 9:52 pm

Probably you will win as I have a holiday looming. I dont see my wife letting me pack a BBC Master instead of underwear.

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Thu Aug 03, 2017 9:57 pm

I thought your telnet program started off by doing some stuff which issued *VT102 commands and caught the error and reverted to "plain text" mode if it failed? If so, your telnet program controls how the colours are handled by specifying the relevant NULA8COLOUR option or whatever.

Or do you have it set up so the user can choose to type a *VT102 command before running your program, and your program auto-detects that and sets things up accordingly? If so, how does the auto-detection currently work? I know we've discussed this before but I can't remember exactly where we ended up. If there is a standard escape sequence for querying ANSI colour support I can look at implementing that, for example. (I perhaps need to have a re-read of the doc JGH posted in this thread a while back and see if there is such a code.)

Failing that I could look at implementing some kind of OSBYTE/OSWORD call to allow application code to query the current emulation settings, but I'd really rather not if it can be helped - it would mean getting an OSBYTE/OSWORD number assigned, using up a relatively scarce resource, and extra code in the ROM to support 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 » Thu Aug 03, 2017 10:58 pm

I have Jonathan local error handling hack wrapped around vt320 yes.

But I am just wondering how I am (or said I was) going to do it.

I suppose 2 calls to stem. First to stem nula, if that errors trap error, call vt320, if that errors trap error do neither.

Edit: but originally trap was if stem not installed. I assume same thing happens if stem installed but videonula not

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 Aug 10, 2017 3:29 pm

Fixed my storage issue.

*VT102 NULA8COLOUR gives

ROM &0 using extended vector error/warning currently

Edit: But I kind of lost the plot where we were. It should now work on a Master with a tube copro?

Edit2: Just to check I move ROM from 0 to 2 (no ROM 0 now), and removed the NULA ROM and get same message.

Edit3: Tube on or off makes no difference. Tried old and new screen modes. Same message

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Thu Aug 10, 2017 9:37 pm

Yes, it should work fine with or without a second processor enabled now. It should work on any machine in theory but I'm doing my testing with Kieran's b-em in Master mode so that should definitely work. As a general rule of thumb if it doesn't work probably best to try it with the tube off just in case it helps and to keep things simpler, but it *shouldn't* matter.

You say that error occurs even with the VideoNuLA support ROM removed? That's odd. Can you do *ROMS when you get that error and see what's in the slot it's complaining about (though nothing, by the sound of it)? The error means (if the code to generate it doesn't have a bug!) that something else - typically the *VNVDU ON code in the support ROM - is using extended vectors which STEM wants to use, so it generates this error instead of crashing as it used to.

Could you please also do something like:
  • Disable second processor (otherwise the *SAVE below will save uninteresting memory)
  • Press CTRL-BREAK
  • *SAVE VEC 200 E00
  • *VT102 NULA8COLOUR - hopefully this will generate the extended vector error
and attach the VEC file (or an SSD with it on, whatever's easiest)?

If it's not a big deal can you also let me see your *ROMS output?

Cheers.

Steve

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Thu Aug 10, 2017 9:45 pm

Don't worry about any of the above - I just remembered you're using MOS 3.5, and I can reproduce the error in b-em with MOS 3.5. I'll take a look...

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 Aug 10, 2017 9:47 pm

There were no ROMS there and made no difference if in TUBE ON or OFF. I always complains about &0 regardless of whether populated or not.

Ah yes. Forgot to try 3.2. Might try it later. There is a reason I use 3.5 over 3.2, just cant remember what it was currently.

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Thu Aug 10, 2017 10:07 pm

It's good in a way that you're using 3.5, it exposes various bugs. :-)

For the record, this was an embarrassing slip when checking if there was already an extended vector. I checked the low byte of the vector and if it matched the low byte of the extended vector address I gave an error, without bothering to check the high byte. (I wrote code to check the high byte, it just didn't get that far.) I got away with this on MOS 3.2 but on MOS 3.5 by coincidence the OS CNPV vector has the same low byte as the extended vector entry.

Anyway, I've attached a new version which should work on MOS 3.5 as well. This also has some other improvements I've made over the last week - the font should no longer have ugly glitches, double-width should work (never perfectly in 8 colour mode, but as good as possible) and the 4-colour and attribute modes should work better too.

Thanks for your help so far and let me know how you get on...

Cheers.

Steve
Attachments
stem-0.03x.05.zip
(84.15 KiB) Downloaded 7 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 » Thu Aug 10, 2017 11:33 pm

Hmm progress. Although I am not quote sure what mode I should be in.

Originally would run in 131 aka Mode Shadow. Initially I was expecting to run new 101/102 modes but I assume you have hacked the normal modes with attributs stuff?

So to get 8 colour ansi I stick with mode 3/131?

I have managed to get something out in colour. Next to sort the palette. If you squint you might make out the letters in red.

Edit: but wahoo, colour ansi on BBC telnet client first
Attachments
colour_telnet1.png
Last edited by Elminster on Thu Aug 10, 2017 11: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 » Thu Aug 10, 2017 11:40 pm

For Comparison on the Mac standard telnet it looks like

colour_telnet_mac.png


And on the syncterm telnet superduper bbs client it looks like

colour_telnet_syncterm.png


I think we can get as good or better than mac telner client, syncterm is huge program (2.6MB) so wont get close to that.

Have a further play tomorrow.(technically today but I am going to sleep in between)

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

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Fri Aug 11, 2017 10:11 am

Thanks, looking good-ish... :-)

You're right, just use mode 0/3/128/131 - the new mode numbers 101 etc only apply when using *VNVDU ON. How/if to use VideoNuLA is configured via the NULAxxx options to *VT102.

I have some thoughts on how to improve the colour handling, with luck I will get a chance to knock up a prototype this weekend...

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 Aug 11, 2017 12:55 pm

That is what I assumed good. Means I can just ignore Nula ROM (sorry Rob :) )

Got several hacks in the code at the moment to get the above, need to make it a bit cleaner to cope with no STEM, no NULA and STEM & NULA.


Return to “software: other”

Who is online

Users browsing this forum: ThomasHarte and 3 guests