[Color Computer] Re: [Coco] NT: BASIC educate {CoCo - DECB}

[Stephen H. Fischer]

Hi,

Robert Gault wrote:
> Weird, when I typed the original, the : displayed correctly but in the
> received e-mail in Mozilla the same thing happened, changed to > or |
> depending on whether the mail was in text or html mode.

Yeh, I was convinced that no DECB user would never say the statement
separator was a ">" that I had to look at the message source.

> RGBDOS included FLEXIKEY by C.J.Stearman. That made use of the right
> arrow, shifted right/left arrows, and up arrow for line editing.

I am not concerned with the editing keys as it is only reasonable that a
full screen editor be used for preparing Urbane programs.

The Flex Preprocessor only added "_" to A-Z and 0-9 for Line Labels and
Variable names.

I can allow additional characters within Line Labels and Variable names
which will never be passed onto the run version. But I think adding some may
hinder the now much more readable source listings.

So unless I see a need for more, I am going to just add one, the ASC_TILDE,
"~". I believe that I have seen it used in other languages as part of
variable names.
Adding other characters is a simple one line addition to the get
GET_VLSTRING so that more can be added later.

For myself, while I have not had a problem, I can see that some people may
have a problem telling Line Labels apart from variables. I am going to try
prefixing Line Labels with "L~" and variables with "V~".

Examples: V~IN_LINE_CH, V~QSTRING$, L~VLSTRING_ADD_UPPER_ALPHA,
L~GET_QSTRING.

And then work with the scheme to see if it is worth the change. Not a
requirement of the language, just trying to see how to write more readable
code.

> There
> certainly are additional reserved words in RGBDOS/HDBDOS and
> undoubtedly ADOS, FDOS, or any other DOS. The commands for HDBDOS can
> be found at http://www.cloud9tech.com/. I can put together a list of
> the RGBDOS commands which are essentially identical to those of
> HDBDOS. Art can supply the ADOS command set. Disto controllers came
> with CDOS.

Some of these below may cause problems with my overly simple parser. I have
the requirement that keywords be followed by a space or a special character.

In addition to easier parsing I consider the source to be more readable
with the keywords followed by a space.

I added USR0, USR1... USR9 to the keyword list as that was the only keyword
that appeared to not allow a trailing space. I will have to try "USR 0" in a
DECB program to see if a space is allowed. I hope that I do not need to
rewrite the parser as it appears to me to handle the entire DECB command
set.

There appears to be several keywords that have no space after the keyword.
Is a space allowed?

Urbane considers DIR0 to be a variable so "DIR0 TO 1' would be a problem.
"DIR 0 TO 1" would be fine.

> RGBDOS
> COPY"filename.ext:drive"TO #
> DIR# TO #
> DOS# specify the drive for the DOS command
> DRIVE ON drives 0-3 are hard drive
> DRIVE OFF [#] drives 0-3 floppy or 0-#
> DRIVE RESTORE recalibrate drive
> DRIVE # n selects scsi bus channel n=0-7
> DRIVE SET n selects Adaptec drive 0-1
> DRIVE STOP [n] parks drive, if Adaptec n=0-1
> RENAME DRIVE #,"drive_name" displays with the DIR command, stored in
>                 T17,S18
> RUNM"filename.ext:drive",offset same as LOADM + EXEC
>
> CDOS for the COCO3; the full syntax is not presented here
> COLD cold start the Coco
> COCO D disk to tape
> COCO T tape to disk
> COCO F does fast poke
> COCO S does slow poke
> COCO U remove all extra commands
> SHIFT@ start screen editor

Is this a full screen editor? If yes, is the source available? If so then it
might be possible to add context coloring which I have become addicted to by
using the "ConTEX" editor.


> CLOCK gets real time info
> RDISK starts a ramm disk
> MRUN LOADM+EXEC and turns off drive motors

I do not think that plus would be a problem. My very simple parser passes a
lot of characters straight through to the output line thus eliminating a lot
of special code. I actually have been very amazed as to its working so good.
Originally I assumed that a much more complex syntax driven parser was
required.

Stephen H. Fischer