Rear Admiral

[Hershey]

I Just installed the ra this weekend. It is working great. very fast. little ticked with the manuals for the fact it mentioned that you could boot into 128 mode but did not state how it was done. So after many time going over manuals and online search I gave up and went to the configure software. Very power software. After playing around in there (carefull not to change anything that I could not remember what it was before) found lots of features and the c128 mode boot. now I moved dragonfire bbs software to it (went well except rel file, had to use a rel file copier)

Now to run the bbs software - did not load with dragonfire bbs  had to use load"dragonfire bbs",8  and was loaded before I could remove my hand from keyboard.

typed run then this happend

load"1:dragonfire ?.?",8?

run

run
monitor
#
when I exited ml monitor the ra display bar came up under the load dragonfire prompt.
removed the ? at the end of the load command and the bbs loaded and ran fine.

this well cause a problem because this software loads in stand alone modules moving back in forth I would have to be there to run the mods and main bbs prg. if the bbs loads a prg that I wrote  it will not load it but will return back to the bbs after I load it (I use load"dragonfire ?.?",dv:run).

my question is  is the ra bar interfering with the direct mode input of commands if so how do I turn off display bar with out turing of ra

Hershey

[BigDumbDinosaur]

I Just installed the ra this weekend...my question is  is the ra bar interfering with the direct mode input of commands if so how do I turn off display bar with out turing of ra

Welcome to the curse of software written by undisciplined amateurs.  Dragonfire malfunctions with the RA/Lt. Kernal because the software was not written according to coding standards as set forth by Commodore long ago.  To quote from an authoritative source on the Lt. Kernal/RA:

The Lt. Kernal DOS interaction with the Commodore kernal demanded the use of a much more disciplined approach to software development than was often found in the eight bit Commodore world.  Complaints of incompatibility were most often traced to amateurish programming techniques, as well as a lack of understanding about the way the Lt. Kernal behaved.  Incompatibility was often encountered in attempting to get some sloppily-designed BBS packages to run on the system (two in particular, C-Net and Image, a C-Net derivative, were particularly egregious examplesâ€"arguably the worst cases of spaghetti code ever written by anyone). Other compatibility issues developed because amateur assembly language programmers would bypass the kernal jump table (contrary to both Commodore's and Fiscal's instructions) and directly call kernal ROM subroutines.  When the system crashed after a call to a now-relocated or modified ROM function, it was always blamed on the Lt. Kernal, not the programmer's ignorance.

Succinctly stated, you are the victim of poorly designed software.  Dragonfire gets away with sloppy coding when using CBM floppy drives for storage (or a CMD drive running in CBM emulation mode).  The RA is not as forgiving, nor does it need to be.  It's up the programmer to stick with coding standards, and not go off half-cocked with illegal ROM jumps, etc.  Your RA system is working fine.

Incidentally, that thing you keep referring to as a "display bar" is the RA DOS prompt.  It is telling you the RA's CBM device number, the currently active logical unit and user, and the hardware port number (the latter relevant if you run a multiplexed system).  You can't "turn it off" without issuing the LKOFF command.

[Hershey]

Thanks for the quick rely BigDumbDinosaur

I do understand about not following proper programing and I was hoping it was not that. Will move bbs back to cmd hard drive. Could it also be why when I just use the file name, the bbs never finish loading just sits there with the ra drive light on and I have to reset the system and use load"dragondire bbs",8 to load up the bbs boot file

Hershey

[BigDumbDinosaur]

Could it also be why when I just use the file name, the bbs never finish loading just sits there with the ra drive light on and I have to reset the system and use load"dragondire bbs",8 to load up the bbs boot file

Rename the file to dragonfirebbs (one word).  The blank between dragonfire and bbs is causing the RA DOS to think that the filename you want to run is dragonfire and that bbs is a command line argument to dragonfire.  Shame on you for not figuring this out, as the behavior of the RA command line is clearly explained in the documentation. 

[Hershey]

Thanks again BigDumbDinosaur

I printed the manual on sunday. Now to take the time to read it.

I Think it is now time to think outside of the commodore dos box. Everything I know about cbm dos is about to change lol

Hershrey

[Hershey]

Could it also be why when I just use the file name, the bbs never finish loading just sits there with the ra drive light on and I have to reset the system and use load"dragondire bbs",8 to load up the bbs boot file

Rename the file to dragonfirebbs (one word).  The blank between dragonfire and bbs is causing the RA DOS to think that the filename you want to run is dragonfire and that bbs is a command line argument to dragonfire.  Shame on you for not figuring this out, as the behavior of the RA command line is clearly explained in the documentation. 

Ok i read the manual over and over and the only thing I can find is
invoke (feature)
Syntax: [lu:][user:]filename
Any legal filename typed beginning in the first column of the screen will cause the system to attempt to load and execute that file. The INVOKE feature works for both BASIC and machine language programs. Simply type the program's name, followed by a carriage return.

am I missing somthing  - a full manual maybe.

[BigDumbDinosaur]

Ok i read the manual over and over and the only thing I can find is
invoke (feature)
Syntax: [lu:][user:]filename
Any legal filename typed beginning in the first column of the screen will cause the system to attempt to load and execute that file. The INVOKE feature works for both BASIC and machine language programs. Simply type the program's name, followed by a carriage return.

am I missing somthing  - a full manual maybe.

You need a full manual (which is unlikely to exist at this point in time) or access to the Lt. Kernal "Power Station" articles that were written by Lloyd Sponenburgh and others.

Regarding command invocation, here's an excerpt from the LK documentation that explains it in detail:

One of the unique aspects of the Lt. Kernal DOS is its 'direct invocation'
facility.  A processor can be loaded and executed simply by typing its name.
 
Most Lt. Kernal DIRECT-MODE commands are DOS PROCESSORS.  When the command's
name is typed, beginning in the the left-most column of the screen, and WITHOUT
an LU/USER specification preceding the name, the command is searched for in the
following manner:
 
1)  The command name is extracted by taking up to sixteen characters
    from column 1 to the first space in the command line.
 
2)  LU 10, USER 0 is searched for a type 2 or type 3 file matching
    the command name. If found, the processor is loaded and executed.
    A pointer indicating the column position of the first character
    on the line beyond the command name is passed to the processor so
    that 'command-tails' may be acted upon.
 
3)  If the command name as extracted above cannot be found, then the
    first sixteen characters of the line including any embedded
    spaces (but dropping trailing spaces) is treated as a possible
    command name, and LU 10, USER 0 is searched for a PROCESSOR of
    any type (2,3,11, or 12) matching that name.
 
4)  If that command is not found:
 
     a)  If ALTERNATE COMMANDS are active (DOS 7.1 -5/01/89 only)
         then the alternate keys are searched for the command.
 
     b)  If ALTERNATE COMMANDS are not active or the command is not
         found among the alternate keys, then step 5 of the search is
         performed.
 
5)  The first 16 characters of the command line without trailing
    spaces is treated as a possible command name, and the CURRENTLY
    LOGGED LU and USER is searched for the command-name.
 
If a command is typed WITH an LU/USER specification preceding it, then only
the LU and USER specified is searched for a processor matching the name.  The
name is extracted by taking the first sixteen characters AFTER the LU/USER
specification, without trailing spaces.

The principle of parsing command line input for separating spaces is not unique to the Lt. Kernal DOS.  All operating systems that are controlled via a command line interface (e.g., BASH in Linux) have a similar behavior.  In BASH, for example, it is necessary to quote filenames with embedded spaces in order for the command parser to recognize the name as one word rather than two or more.  For this reason (as well as other more esoteric ones), it's wise to not use filenames with embedded spaces or strange characters.