BTRON MicroScript Reference Manual

Here, we will explain the method for developing applications on top of BrainPad TiPO (hereafter TiPO) using MicroScript. Because TiPO is a handheld terminal without a keyboard and the screen also is confined, it is, sorry to say, not suited to full-blown programming. Therefore, we make it a habit to carry out the development, debugging, and testing of applications on 1B/V3 (hereafter 1B), and then run those on top of TiPO. If we do things in a manner in which, after making it so that applications run completely on 1B, we bring them to TiPO, and then carry out fine adjustments in accordance with need, development becomes very efficient.

Here, we will first explain the method in which we do development by combining 1B and TiPO, and then we will introduce 1B techniques that will become necessary in development. Concerning the individual operating techniques of 1B, please refer to the 1B manual.

In doing development by combining 1B and TiPO, it is necessary to share between 1B and TiPO data and scripts that are in the process of being created. A PC Card (ATA card) is simple and convenient for this. By storing all the scripts in the process of being created and the related data on a PC Card, it becomes possible to edit and execute just by inserting the PC Card in either 1B or TiPO. Moreover, backup can easily be realized by doing real object copying of the contents of the PC Card onto the hard disk on 1B.

There is a PC Card slot in many of the notebook-type machines, and thus you can connect the just mentioned PC Card. With a desktop machine, it is necessary to make it so that you can connect the PC card by adding a PC card adaptor.

For TiPO, there is nothing in particular to add. In accordance with need, you can also use a serial cable, an AC adaptor, and a keyboard adaptor.

For the PC Card, we use the so-called ATA card. Because an SRAM card cannot be used on 1B and a hard disk cannot be used on TiPO, please be careful. A capacity of 4〜8 MB is sufficient. Because the empty capacity of the TiPO Flash disk is only on the order of 3 MB, it is necessary to hold down to this capacity to store scripts on the TiPO main unit in the end.

PC Card formatting is necessary to use a PC Card that's in a state of having just been bought. When we turn on the power supply after having inserted the PC Card in TiPO, a panel asking "Will you format?" is displayed. Input a disk title, and then format the PC Card (for the detailed operation method, please refer to the TiPO manual). By storing scripts in the process of being created on this PC Card, we come to edit and execute them.

Script development based on cooperation between 1B and TiPO becomes like the flow below.

• Design on top of TiPO (if necessary)
• Develop and debug on top of 1B
• Execute on top of TiPO, make fine adjustments to design, etc.
• Confirm operation on top of TiPO

What's important here is the point that with MicroScript the exact same things operate on top of 1B and on top of TiPO. Accordingly, carrying out testing and debugging as much as possible on the 1B side, and finishing up with just confirmation of operation on the TiPO side is ideal (for the window size and parts locations, and the speed of animation, it is necessary to confirm with TiPO). Furthermore, if necessary, you can also maintain a temporarily completed script with just TiPO (it is possible to freely make revisions using TiPO's figure editor and text editor).

First, we create on the PC Card all the real objects we will use in the scripts. Then, we copy to the hard disk on the 1B side only the virtual objects (these virtual objects are on top of the hard disk, but they point to real objects on the PC Card). Because contents revised on the 1B side have been entered into the PC Card, you can execute by just taking out the PC card and inserting it in TiPO.

Among the real objects we will use in scripts, there are the following items.

• Figure real objects in which we will store segments (1)
• Text real objects in which we will store scripts (1〜8)
• Real objects that will start up with the VOPEN statement (0〜)
• Real objects that will be used in the input and output of data (0〜)
• Others (such as real objects we will use with the PROCESS statement)

Because the "figure real object in which we will store scripts" is started up from both the Basic Figure Editor and MicroScript, it is convenient to prepare and put in place two virtual objects: a virtual object for starting up the Basic Figure Editor, and a virtual object for starting up MicroScript (it will come about that two virtual objects will exist for one real object on the PC Card). For the "text real objects in which we will store scripts" also, we prepare and put in place virtual objects. As for virtual objects outside of these, it should be fine if you prepare them in accordance with need. Incidentally, taking out virtual objects is easy when we use "Real-object--Virtual-object Network" for the "figure real object in which we will store scripts."

Because the "text real objects in which we will store scripts" are the real objects in which we will work most frequently, we leave them in a opened state in the window (you can take out the PC Card even in a state in which things are opened in the window). On the other hand, since the "figure real object in which we will store segments" will not change much once it has been created, we will open the window when necessary. Since these real objects will not be changed much, no problems will occur even if they are opened as is in the window (however, when editing real objects on the TiPO side, please close the windows on the 1B side).

Because it is necessary to test all sorts of data with real objects that scripts read in, it is more convenient leaving them opened when testing. On the other hand, caution is necessary in a case where you will execute scripts of the type that directly edit real objects. When you open a real object that is written into in a window, and then when you do not open once more after having exited that window once, you cannot see the written-in results. Also, when you select "Update and Exit" with the window opened as is, the contents that are written in by means of the script end up being written over.

As an example in which we use several virtual objects, we will introduce the appearance of editing and debugging of a script we have used to make and output the reference section of this book (there are approximately 1,600 lines). This script only operates on top of 1B, but under the assumption that we are creating an application on TiPO, we have created a real object on top of a PC Card.

Figure 1

Translator's Note: The bottom window is the "1B" desktop window; on top of it is the "Data Exchange Use" window, which has been clicked open from the virtual object of the same name in the 1B desktop window; and on top of that is the "Reference Section" cabinet, which has been clicked open from the virtual object of the same name. The user has clicked on the "ref creation (Script)" virtual object in the Reference Section window, and has selected "Virtual-object Network" from the submenu, which is under "Real-object in the main menu.

Fig. 1 is a script real object that has been stored on a PC Card. When we take a look in the virtual object network, it is made up as in Fig. 2. "SCRIPT:" is the text real object of the script main body. The script reads in from the "Input" text real object, and it outputs to the "Output" text real object. Also, the illustrations that serve as subject matter are stored below "Illustrations."

Figure 2

Translator's Note: The title of the top window is: "Virtual-Object Network: ref creation." This was opened as a result of the actions by the user in the previous figure. The four virtual objects in the middle of the window, from top to bottom, are: SCRIPT, Input, Output, and Illustrations.

We create a cabinet for work use on the hard disk, and then first we copy the virtual objects of the figure real objects into the window of the hard disk. We copy one more time, preparing two virtual objects that point to the same figure real object. We make one side for MicroScript startup use, and the other side for figure editor startup use (by selecting from the execution menu, the selected application will be will be remembered in the virtual object). We also copy to the hard disk the virtual objects of the script text real objects. Things become as in Fig. 3. Through this, it has come about that the editing and execution of scripts can be carried out freely.

Figure 3

Translator's Note: The three windows opened on the screen are, bottom to top, "1B" desktop, "Virtual-Object Network: ref creation," and "Reference Section," the last being the active window. The three virtual objects in the top window, from top to bottom, are: ref creation (Figure), ref creation (Script), and SCRIPT: (Text).

In a case where there is a real object related to work, its virtual object also is copied and put into place on the hard disk. As for a test of this script, we carrying it out by rewriting in various ways the Input real object and executing the script, and then confirming whether or not things have been written in normally in the Output real object. Accordingly, because the Input, Output, and Illustration real objects are operated frequently, we put virtual objects that correspond to these on the hard disk (Fig. 4).

Figure 4

Translator's Note: In the "Reference Section" window at the top, there are now six virtual objects. They are: ref creation (Figure) Input (Text) ref creation (Script) Output (Text) SCRIPT: (Text) Illustrations (List)

Figure 5

Translator's Note: The bottom window in this figure is "Input," on top of that is the window "SCRIPT:,"underneath the pointer is a panel that reads "ref creation, Processing: Local." In the lower left is the same "Reference Section" window as in Figure 4.

During testing, we work in the manner of Fig. 5. Script and input virtual objects are left open, and they are made up so that they can be revised at any time. The execution of a script is carried out by double clicking the virtual object set in MicroScript. The results are implemented by applying Basic Print to the output virtual object (Fig. 6). If there is some problem, we revise the script, execute it again, and then confirm the results.

Figure 6

Translator's Note: The right side of the print panel in the center of this figure reads: "1," "Page," "1," "464," "Std" [Standard], and "Exit." The windows below it as the same as in Figure 5.

Finally, we would like to introduce two points that easily lead to problems in MicroScript.

After revising, even if you operate MicroScript's "Reread Script," segments in which contents and attributes have been modified do not return to the source. It is necessary to start up once again, after terminating MicroScript once.

What you must be careful with in TiPO is electrical power consumption, and when there is a problem in the way a script is written, the battery life becomes shortened, because the machine ends up operating continuously. Please avoid script writing methods of the type that come to leave the machine operating. At the present time, there doesn't seem to be anything other than directly measuring the electrical current to check the electrical power consumption of TiPO.