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

Stephen H. Fischer SFischer1 at Mindspring.com
Mon Nov 21 02:45:14 EST 2005


Hi,

Robert Gault wrote:
> Stephen H. Fischer wrote:
>> Hi,

>> Robert Gault wrote:
>> 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.

I am asking the opposite question, is a space allowed.

The example in the CoCo 3 quick reference guide on page 22:

10 A=USR0(B)

I would like to require this to be written with a space between USR and the 
zero:

LINE_LABEL1 A=USR 0(B)

That just does not seem allowable to me. So that's why I added the keywords 
USR0,USR1,USR2...USR9 to the keyword table.

I am looking for any more that are of that form.

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

Does anyone have this or any other Non OS-9 screen editor for the CoCo
other than Telewriter various versions?

I used Telewriter 64, 128 or something a long time ago to edit a DECB 
program. It was not satisfactory on two counts. The DECB Language of course 
required line numbers and allowed two character variable names only and is 
one of my old attempts that failed that is driving my desire to create 
Urbane.
Telewriter being a word processor did nasty things like wrapping lines 
unless you set the options up right, which I forgot to do often making the 
process not very useful. So I do not consider it to be a good option for 
those who may wish to do their editing with the CoCo.
While my editing will be done on other platforms, there may be times that a 
simple change using a screen editor on the CoCo may be useful.

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

To simplify the effort I am imposing constraints on the usage of the
Language. Some will be removed later.

The LET keyword which I have used a lot is NOT required. I originally
planned on a syntax driven parser and felt that it might be a difficult task
to not require it.

When I switched to a very much simpler parser, it just was not
required. Strings after the possible Line Label are first checked to see if
the string is a keyword. If not then the Line Label table is checked to see
if it is one. If it is not, then it must be a Variable which is just what we
want to happen when the "LET" keyword is omitted. This much simpler parser
is slower, but easier to code. The goals currently do not include fast
processing, just get a working version that allows all DECB capabilities to
be used. My current estimate of lifetime users is 5 with my self the only
one confirmed. So I am trying to match the current goals with the number of
users but still to do a good and complete job. As the number of users
increases, the goals will be adjusted. The current interest is still in
single digits.

Keywords must be followed by a space. This in addition to making the parser
simpler makes the source code more readable which is a goal.

I am assuming a syntactically correct program is being processed and that
DECB will report any errors. If the input is really messed up, then the real
problem may sometimes be hard to find with the most useful information in
the List of Line Labels and Variables.

Cross Reference information will be written to the Debug file which will
require a post processor to sort and print.

Control characters are not allowed currently. Lines 50 and 408 have a
missing space after the line number which I cannot explain. I think that a
control character is involved but I cannot find one in the source.

Tab's are not a difficult problem as they can during pass two be changed to
a space and be handled by the excess space remover. Pass one where the
listing is written will just pass them through unchanged which may or may
not produce a glitch in the listing.

So for now the Language dictator says no Tabs!

(Subject to Impeachment, but then I do not know anyone named Monica)
---------------------------------------------------------------
Arthur Flexser wrote:
>
> Additional reserved words in ADOS are unlikely to cause problems,
> since ADOS was designed to enhance the programming environment,
> rather than create additional BASIC commands for use within programs,
> which would make those programs incompatible with standard RSDOS. The main
> ones that one might be tempted to use within a program are
> RAM (CoCo 1/2 only) for transferring ROM to RAM, and RUNM, which has
> already been mentioned.
> Art

That's good news. I had suspected that most extensions would just require
additions to the keyword table. If a keyword is used that is not in the
keyword table an variable is created with that name. I got bit by one that
did not show up until I tried running a second generation which produced
"10 AX AY = AZ", the AX appearing in many lines. I finally realized that the
"LET" keyword was missing and had to back up two generations to fix it.
---------------------------------------------------------------
Rogelio Perea wrote:

> 100 IF A=Y SET(XI,YI)
>
> -=[ Rogelio ]=-


The one that surprised me was DECB's requirement that the "REM" keyword
was required on a line with just a line number (Line Label).

Flex's "XPC" did not require this and I was sandbagged for a few
minutes by its examples.

I plan to go back and check if "'" can be used instead as well as "?"
can be substituted for "PRINT". At the same time I will be looking to
see if the trailing space after a keyword can be removed And if there
would be a benefit to merging lines with no labels. All of this might
speed up the produced RUN version but make the preprocessor slower.

None of these will be done soon as the produced RUN version is pretty
hard to read already and while I rarely look at the produced code
currently, I must look at it if there is a problem.

So far the biggest class of problems was getting the desired number of
spaces into the output.

The missing space after the line number in lines 50 and 408 still
confound ands me. I think that it must be a embedded "TAB" but I have told
"ConTEX" to not use TAB's and looking at the file I cannot find any control 
characters.

Stephen H. Fischer

(Just writing more of the FAQ's)





------------------------ Yahoo! Groups Sponsor --------------------~--> 
Get fast access to your favorite Yahoo! Groups. Make Yahoo! your home page
http://us.click.yahoo.com/dpRU5A/wUILAA/yQLSAA/CFFolB/TM
--------------------------------------------------------------------~-> 

Brought to you by the 6809, the 6803 and their cousins! 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/ColorComputer/

<*> To unsubscribe from this group, send an email to:
    ColorComputer-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 






More information about the Coco mailing list