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

[Robert Gault]

Stephen H. Fischer wrote:

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

> 


Most Basic interpreters will require a trailing space only if the 
commands would be ambiguous. So, DIR#TO# and DIR # TO # would be 
equivalent. Ambiguity typically will be possible if the first character 
after a Reserved Word is a letter.


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


It is full screen. I never used this DOS as I preferred my own and 
RGBDOS so I think I erased the EPORM without saving the code. I'm not 
aware of the source being released.


> 

> 

>> CLOCK gets real time info

>> RDISK starts a ramm disk

>> MRUN LOADM+EXEC and turns off drive motors


Looks like the tabs did not get through. MRUN is the equivalent of LOADM 
plus EXEC. LOADM+EXEC is not part of the syntax.


> 

> 

> 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

> 

> 

>