[Coco] NITROS9 internal question on serial output control

[Bill Nobel]

Niel, as far as I know it is openly available.  I never found it in the repo either.  It was part of the Level 2 development kit.  I can supply you with it if you want.  I have the manual and executables with term set file.  I think I got my copy from Gene Heskett.  I tried to disassemble it, but it ended up being a HUGE listing, as it was written in C.  The beauty about it is that it can edit a text file with unlimited size.  It paged it’s memory in blocks that were loaded and saved on the fly.  let me know if you want it.

Bill Nobel

> On Nov 4, 2015, at 6:32 AM, Neal Crook <foofoobedoo at gmail.com> wrote:
> 
> Bill,
> thanks for your comments. It sounds as though my best approach for L1 is to
> create a MINTED-derivative that uses ANSI/VT100 codes. Based on a quick
> inspection of the source code, this will be a straight-forward and
> satisfying project. You mention SCRED for L2. I note that SCRED is
> documented on the NitrOS9 WIKI and has a level2/sys/scred.hp help file, but
> it is not part of the NitrOS9 mercurial repository. Is SCRED freely
> available or closed/commercial?
> thanks
> Neal.
> 
> On 1 November 2015 at 21:08, Bill Nobel <b_nobel at hotmail.com> wrote:
> 
>> Hey Niel,  to get terminal codes to work correctly on Nitros9, the Coco3
>> Level 2 term codes will have to be ignored or dropped from the editor, they
>> are built for the windowing system in Nitros9.  I have used the Level 2
>> Scred utility that uses the Termcap file for the screen codes.  If the
>> utility you are using uses a Termcap type file then you are laughing.
>> 
>> Bill Nobel
>> 
>>> On Nov 1, 2015, at 3:01 PM, Neal Crook <foofoobedoo at gmail.com> wrote:
>>> 
>>> I have Nitros9 Level 1 ported and running on my Multicomp FPGA-based 6809
>>> system.
>>> 
>>> I am trying to understand what I need to do in order to get a
>> screen-based
>>> editor like MINTED to work on this system.
>>> 
>>> My current understanding is as follows. Corrections and other
>> elucidations
>>> welcome..
>>> 
>>> 1. minted does cursor control (ie, draws characters at arbitrary points
>> on
>>> the screen) using
>>> control codes like this:
>>> 
>>> curoff       fcb        $05,$20
>>> curon        fcb        $05,$21
>>> clrlin       fcb        $0b
>>> cls          fcb        $0c
>>> home         fcb        $01
>>> insline      fcb        $1f,$30
>>> delline      fcb        $1f,$31
>>> 
>>> 2. the complete set of these control codes is documented in "The NitrOS-9
>>> Level 2 Windowing System" chapter 5, "text commands"
>>> 
>>> 3. if I was running on a coco with a VDU, I might use term_vtg as my i/o
>>> device, and the output from minted would be interpreted by eg vtio.dr and
>>> covdg.io. Within those modules. the control codes are interpreted and
>> used
>>> to control the output to a memory-mapped screen.
>>> 
>>> 4. if I was running on a coco and communicating across a serial port, I
>>> might use t1_scbbt as my i/o device and output from minted would be
>>> interpreted by scbbt.asm. Here is where my confusion starts. By
>> inspection,
>>> I don't see  scbbt.asm do any conversion of the output codes. Therefore,
>> if
>>> I connected to that serial port using a terminal emulator, would it
>>> understand the control codes listed above (ie, are they a "known"
>> standard,
>>> if so what standard?)
>>> 
>>> 5. or, is there some conversion capability in SCF (a termcap-like
>> facility)
>>> in which case, how s it controlled and is there some documentation that
>>> I've missed?
>>> 
>>> 6. if I want to talk to a VT100 (ie, ANSI standard escape codes) do I
>> need
>>> to modify the serial driver to detect the NitrOS-9 control codes and
>>> convert them to ANSI codes?
>>> 
>>> 7. in my particular case, I am not actually using scbbt.asm on my
>> system, I
>>> am using a 6850 driver that I wrote (well, "wrote" is rather a polite
>> term;
>>> it's currently an atrocious hack of  sc6551.asm). The principle is the
>> same
>>> though: sc6551.asm does not do any output conversion of the byte stream
>> and
>>> neither does my 6850 driver
>>> 
>>> 8. if I wanted to use the same driver to talk to a dw4 server, I assume
>>> that I would want to transfer literal byte streams with no output
>>> conversions. Is there an existing flag I can use in the driver to
>>> enable/disable conversion (ie so I can have some device descriptors that
>>> use conversion and some device descriptors that do not, but all share the
>>> same device driver
>>> 
>>> thanks in advance for any explanations..
>>> 
>>> Neal.
>>> 
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> https://pairlist5.pair.net/mailman/listinfo/coco
>> 
>> 
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> https://pairlist5.pair.net/mailman/listinfo/coco
>> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco