[Coco] NITROS9 internal question on serial output control

[Gene Heskett]

On Wednesday 04 November 2015 08:49:53 Bill Nobel wrote:

> 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

That sounds a lot like Dynastar. But DS has this strange requirement that 
it can only go fwd in a file, and any save operation actually cycles 
thru the whole file, re-writing it in its entirety just to fix the name 
spelling in the first line of the file.  It was quite good at that, but 
I wore out several floppy drives with it back in the day, and was quite 
bored of the whole thing by the time I got a prompt back.  Scred, like 
DS and TSedit, has a completely strange to me control key sequence, 
(although TSEdit/vi, now vim on my system, I have pretty well mastered) 
so to run sled, another different critter, I have to print a fresh copy 
of the help card & tape it over the monitor every time.  Scred I have 
not found a help file for, so its not been actively used here.

AFAIK, its still available on my web page, help yourself. I see there is 
also a scredfix.ar, which I haven't looked at in yonks.  Might be a fix 
to use /dd instead of /d0.  The fact that its an .ar might be confusing 
since there have been at 3 revisions, not always backwards compatible.  
That patches header says +AR0.0+ so thats the original ar I believe.

I just drug out my copy of the level2 devel book, and the scred 
instructions are about 1/8" thick.  They are NOT on the disks.

If interest, and I don't believe anyone else has done this, I have now 
scaned and and will post them as scanned, jpg'd images.  I've tried to 
OCR some of this before but its spelling mistakes are pretty rampant, so 
posting the images at a 300 dpi scan is probably best. At 300 dpi, they 
should scale up to full 8.5x11 paper quite well.  For those on tight 
budgets, page 30 starts the "quick reference" which should get you 
started, and the last 6 pages are the index.  Blank pages were omitted 
on purpose.

Done, now to move them to the web page & make them visible.  Give me 10 
minutes for that please.


> > 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.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>