In the previous installment, we created a real-time shooting game using the programming language functions of MicroScript, but on this occasion we will proceed further and try creating a competitive shooting game by connecting two BTRON machines via the RS-232C interface [TN1]. By means of MicroScript's parallel execution function and BTRON's multitasking, we can write the program in a straightforward manner.
1B MicroScript [1] is a programming language that runs on the BTRON-specification 1B personal computer series. In particular, it is suited to the description of visual operations, such as the creation of screens for presentation use, and the control of external devices.
In the first installment (Vol. 22 of this magazine), I explained in detail the basic knowledge necessary in programming, and we tried creating a simple presentation system to realize a picture story show. In the second installment (Vol. 23), I took up a "television timer" that turns on a television at a specified hour by connecting an infrared remote control to the RS-232C port. Up to here is an explanation from the application side of 1B MicroScript.
In the previous installment (Vol. 25), I paid attention to the aspect as a programming language. Using the EXECUTE statement that carries out parallel execution of procedures, we created the real-time game software "Shooting Game" (Fig. 1). A ball appears from a place on which "Goal" has been written, and it falls down to the bottom while bouncing against the walls. This is a game in which we move a bar with the mouse, making the ball bounce back, and entering it into the goal.
 |
|
Let's take a look back at the program in Fig. 1. The guts of the program are the parts in which we describe the movements of the ball and the movements of the bar, and in which we detect their collisions. The programming method that easily comes to mind is making it loop through three steps
Step 1: Move the ball one step
Step 2: Move the bar in keeping with the position of the mouse
Step 3: Check whether or not the ball and the bar have collided
and repeatedly executing them. However, with this method, it is necessary to include various types of processes inside a single loop, and the overall outlook becomes bad. From the start, processing alternatively inside a loop, in spite of the fact that the ball and the bar originally ought to move completely unrelatedly, is not very neat as a method for realizing this.
Accordingly, we can nicely solve this problem when we use the EXECUTE statement that executes procedures in parallel. The program takes on the structure below.
- ACTION Move_Ball
- REPEAT
- # Do the three processes below
- # 1. Move the ball
- # 2. Processing when the ball hits the wall or the bar
- # 3. Processing when the ball has entered the goal
- ENDREPEAT
- END
- ACTION Move_Bar
- REPEAT
- # Move the bar together with the position of the mouse
- ENDREPEAT
- END
- EXECUTE Move_Ball Move_Bar
In the procedures "Move_Ball" and "Move_Bar," we respectively describe only the processing that concerns the movement of the ball and the movement of the bar. And then, we execute these two in parallel by means of the EXECUTE statement. By means of this, two procedures attain a state in which they are running simultaneously, and thus it is possible to make the ball and the bar move simultaneously. This method in which we pay attention to things called a ball and a bar, and in which we independently describe their respective actions, stands to reason and is easy to understand. A method of programming based on this type of thinking has been called "object oriented" (for a detailed explanation, refer to Vol. 25 of this magazine).
In Fig. 2, I have compared the flow of processing of the CALL statement, which carries out a so-called procedural call, and the EXECUTE statement, which carries out parallel execution.
 |
|
Above, I have briefly reviewed the "Shooting Game" program of the previous installment.
On this occasion, let's create "Competitive Shooting Game" in which we expand on "Shooting Game." This is one in which two players exchange shots with one ball while respectively moving their own bar and entering it into the goal (Fig. 3).
 |
|
|
I have moved the goal, which was at the top edge, to the center of the game board. As a ball appears from here, Player 1 moves the lower bar (Bar 1) and tries to enter the ball into the goal. The other player, Player 2, moves the upper bar (Bar 2) and tries to enter the ball.
The goal number counter shows "Goal Number ↑ :" for Player 1, and "Goal Number ↓ :" for Player 2.
With "Competitive Shooting Game," two mice become necessary. Accordingly, we have prepared one more machine, "Machine 2," for Player 2, and we have made it so that he/she can control the mouse connected there (Figs. 4 and 5). We connect Machine 1 and Machine 2 with a cross type RS-232C cable, and we send the mouse coordinate of Machine 2 into Machine 1. This is a setup in which we move Bar 2 of the shooting game in accordance with this coordinate value [2].
 |
|
|
 |
|
|
The following is the concrete method for starting up this shooting game. First, confirm that Machine 1 and Machine 2 are connected with an RS-232C cable, and then run the script "Mouse Output" on Machine 2. Next, run the script of "Competitive Shooting Game" on Machine 1. By means of this, it will become possible to play. Because Machine 1's mouse is matched to Bar 1 and Machine 2's mouse to Bar 2, two players will exchange shots with the ball.
Before I explain the program of "Competitive Shooting Game," let's take a look at the overall structure for future reference. Altogether, three programs run in parallel. I show the segments and scripts of "Competitive Shooting Game," "Mouse Input," and "Mouse Output," in Figs. 6~8, and Programs 1~3.
 |
|
|
 |
 |
|
|
|
SCRIPT "Competitive Shooting Game"/Runs on Machine 1 (Fig. 6, Program 1) Fig. 6 is almost the same as the case of the shooting game for one person in the previous installment. The big points of change are that the segment "@Bar2" and the virtual object "Mouse Input" have been added.
SCRIPT "Mouse Input"/Runs on Machine 1 (Fig. 7, Program 2) "Mouse Input" starts up in parallel through the VOPEN statement (10th line) of Program 1. Because it only receives and processes a pointer coordinate value sent in via the RS-232C, absolutely nothing is displayed inside the window. Accordingly, only the script "SCRIPT: Mouse Input" has been stored inside Fig. 7.
SCRIPT "Mouse Output"/Runs on Machine 2 (Fig. 8, Program 3) "Mouse Output" starts up on Machine 2. Because it only sends a mouse coordinate value of Machine 2 to the RS-232C terminal, as one would expect, absolutely nothing is displayed inside the window. Only the script "SCRIPT: Mouse Output" is stored inside Fig. 8.
At the outset, I will explain in detail the script of "Competitive Shooting Game" in Fig. 6. However, it goes without saying that the basic structure, as well as the method of using variables and the names of the procedures are exactly the same as the previous installment (Vol. 25 of this magazine). Accordingly, a detailed explanation will not be repeated here. I shall endeavor to explain only the points that have changed from the previous installment.
The Overall Organization
Program 1 roughly consists of the following procedures.
The Part Enclosed with PROLOGUE to END 9th to 25th Lines
After this shooting game starts up, this is the part that is executed at the very beginning only once. In the EXECUTE statement on the 24th line,
24 EXECUTE Move_Ball Move_Bar1 Move_Bar2 |
we are simultaneously calling up procedures for the movement of one ball and two bars. In the previous installment, when there was only one ball, we described as:
EXECUTE Move_Ball Move_Bar |
When you want to increase the number of balls released on the screen, all you have to do is increase the number of procedures that we make execute in parallel in the EXECUTE statement. The advantage of object oriented-based programming will be made use of.
"ACTION Move_Ball" 29th to 60th Lines
This is a procedure that describes the movements of the ball.
"ACTION" Move_Bar1" "ACTION Move_Bar2" "ACTION Move_Bar" 64th to 103rd Lines
These procedures describe the movements of the bar. On this occasion, because there are two bars, there are two procedures, "Move_Bar1" and "Move_Bar2."
"ACTION Goal_Entered" 107th to 121st Lines
This does the processing when the ball has entered the goal. It is called from the 57th line.
"ACTION Emit_Ball" 125th to 140th Lines
This determines such things as the direction in which the ball will come out of the location of the goal.
Procedure "Move_Bar" (64th to 103rd Lines)
The biggest changes in the script on this occasion are the things concerning the procedure "Move_Bar." Having said that, the basic thinking has not changed. It is just an adjustment of the interface so that we can call up in common from two bar procedures.
24 EXECUTE Move_Ball Move_Bar1 Move_Bar2 |
66 ACTION Move_Bar1 67 CALL Move_Bar BAR1 Bar1_Top_Edge Bar1_Bottom_Edge 68 END |
70 ACTION Move_Bar2 71 CALL Move_Bar BAR2 Bar2_Top_Edge Bar2_Bottom_Edge 72 END |
The range of coordinate values that the bars can move are stored in the variables "Bar1_Top_Edge," "Bar1_Bottom_Edge," "Bar2_Top_Edge," and "Bar2_Bottom_Edge." Also, "BAR1 (0)" and "BAR2 (1)" are integer values that show the bar type. In this manner, we are giving three arguments, and calling up the procedure "Move_Bar."
Inside the procedure "Move_Bar," the arguments can be accessed using the system variable $ARG (refer to Vol. 23 for details). Because it is confusing when we use the variable name $ARG, I have replaced these with easy to understand names by means of the DEFINE statement.
76 DEFINE n $ARG[0] 77 DEFINE Bar_Top_Edge $ARG[1] 78 DEFINE Bar_Bottom_Edge $ARG[2] 79 DEFINE Mousey $ARG[7] |
Furthermore, I have used the final $ARG[7] as a local variable (a variable valid only in this procedure). There is also this kind of use with the system variable $ARG.
The 82nd to 86th lines are the place where the Y coordinate (vertical direction coordinate) of the pointer are taken in. For Bar1 (the lower bar), it is fine to use the system variable $PDY. Moreover, the Y coordinate of Bar2 (the upper bar) has been entered into the system variable $GV[0].
82 IF n = BAR1 83 SET Mousey $PDY 84 ELSE 85 SET Mousey $GV[0] 86 ENDIF |
In 1B, 50 "shared variables" with the array form of $GV[0]~$GV[49] have been prepared as system variables. A "shared variable" is a variable that can be seen by all the scripts running throughout 1B, and they can freely write into them and read out from them. There is no distinction both with scripts started up by a double click operation by the user and scripts that are started up by means of the VOPEN statement (explained below). Generally speaking, that which can be accessed from all scripts that are running inside one BTRON machine is a shared variable.
On this occasion, by means of the script of Program 2: "Mouse Input," we are storing in $GV[0] the latest Y coordinate value of Machine 2 that has been sent via the RS-232C. If we access $GV[0] in exactly the same manner as the system variable $PDY, then we can process both Bar1 and Bar2 with a common script.
Well then, with the following script of the procedure "Move_Bar," we move the bars together with the movements of the mice.
94 IF n = BAR1 & Mousey != Bar1.Y 96 MOVE Bar1: Bar1.X Mousey @ 97 ELSE 98 IF n = BAR2 & Mousey != Bar2.Y 99 MOVE Bar2: Bar2.X Mousey @ 100 ENDIF 101 ENDIF |
In this manner, it is necessary to expressly make Bar1 and Bar2 separate and describe them. Properly speaking, if we could describe in the following manner, we would make things even neater.
# Inside PROLOGUE~END, substitute the segments in an array SET Bar[0] Bar1 SET Bar[1] Bar2 # Describe as follows instead of the 94th to 101st lines IF Mousey != Bar[n].Y MOVE Bar[n].Y: Bar[n].X Mousey @ ENDIF |
In the current MicroScript specification, substituting segments in an array is not a problem. However, we cannot describe them by attaching a state name such as ".Y" in that array.
Bar[n].Y |
Accordingly, we carry out the processing of Bar1 and the processing of Bar2 separately in the manner of the 94th to 101st lines.
I will now explain the script "Mouse Input" (Fig. 7, Program 2). The virtual object for this script is stored inside Fig. 6. This virtual object is not started up by a double click operation of the user, rather it is started up by means of the statement
10 VOPEN Mouse_Input |
on the 10th line of Program 1. The VOPEN statement takes the name of a real object in an argument and does the work of a double click startup of its virtual object. Because 1B is a multitask operating system, it can automatically make scripts run in parallel by just opening a virtual object into a window.
The purpose of this script is storing in the shared variable $GV[0] the Y coordinate value of Machine 2's pointer, which is sent in via the RS-232C. First, on the 7th line, we initialize the RS-232C with
7 RSINIT 0 0 19200 |
The first "0" means use Port 0. In the case of a machine where there is only one RS-232C port, we use "0." When we have multiple RS-232C ports, it will come about that we designate outside 0. With the next "0," we are setting the mode. "0" shows that we are setting
Flow Control: None/Parity Check: None/Stop Bit: 1/Data Length: 8
We can freely set values for these communication control parameters. The final "19200" specifies that we will transfer data at a speed of 19,200 bits per second (bps) [TN2].
Actually, receiving data from the RS-232C is by means of the execution of
13 RSGET 0 |
Data received from Port 0 are stored one byte each in the system variables $RS[0], $RS[1] . . . The byte number of the received data is set in the system variable $RSCNT. Accordingly, as long as it is a case of $RSCNT > 0, namely when data have been received, by means of
15 SET $GV[0] $RS[0] |
we store the one byte that has been received in the shared variable $GV[0]. Because the Y coordinate of the pointer is expressed here with one byte, the range is 0~255. The standard 1B screen is 400 dots vertical, which exceeds the range of one byte, but in the case of the shooting game on this occasion, this will suffice.
The scripts "Competitive Shooting Game" (Program 1) and "Mouse Input" (Program 2) come to run in parallel following the execution of "VOPEN Mouse_Input" on the 1st to the 10th lines of Program 1. If we look at this from Program 1, the pointer coordinate value for Move_Bar1 has entered in the variable $PDY, and the pointer coordinate value for Move_Bar2 has entered $GV[0]. There is absolutely no need to be aware of the situation that Bar2 is being operated from another machine, Machine 2. This is an advantage based on the fact that we are processing an input value from the RS-232C by means of the independent script "Mouse Input."
Well then, the contents of the system variable $RS are explicitly clear as
16 RSPUT 0 |
By means of this, it will come about that the first byte received through the latest execution of the RSGET statement will always be stored in $RS[0].
In a case where $RSCNT becomes 2 or greater, it will come about that the data will be stored in $RS[1], $RS[2], . . . , but they are ignored in this script. Because Y coordinate values of Machine 2 come in one after the other, it does not become much of a problem even if we overlook them on the order of several bytes.
Let me now explain the script "Mouse Output" (Fig. 8, Program 3). This script starts up on Machine 2 through a double click operation. It serves the role of sending the value of the Y coordinate of Machine 2's pointer to Machine 1.
By means of
7 RSINIT 0 0 19200 |
we set it to communicate at 19,200 bps, the same as Program 2. With an RS-232C, it is necessary to set the same communications speed on the side that will send the data and the side that will receive the data.
And then, with the statement
13 SET pdy $PDY & 0xff |
we take out the value of the lower 8-bit part (0~255) within the Y coordinate value of the pointer of Machine 2. The "&" is an operator that carries out an AND operation for every bit, and here we are using it in a so-called "mask."
We output the Y coordinate value expressed with 1 byte (0~255) for Port 0 by means of
15 RSPUT 0 pdy |
only in a case where the Y coordinate value is different from the previously sent value.
 |
|
|
Summary of Execution Units and Variables that Run in Parallel
Above, I finished with the general explanation of the scripts. In the scripts on this occasion, execution units that run in parallel exist on several different levels. I have collected those relationships together in Fig. 9. Concerning "local variables," "global variables," and "shared variables," I have summarized them in Table 1.
|
|
|||
|
|
|
||
| Local Variable |
|
|
|
| Global Variable |
|
|
|
| Shared Variable |
|
|
|
The lowest level execution units are the "procedures" we describe with ACTION to END. We use the EXECUTE statement to execute these in parallel [3]. Data exchange among "procedures" executed in parallel is possible using global variables.
The execution units one level higher are "scripts." In executing these in parallel, it is all right both to use the VOPEN statement inside a program or to start them up by double clicking the virtual objects of the scripts [4]. We use the shared variables $GV[0]~$GV[49] to exchange data among multiple scripts.
Feel of Use
On this occasion, we linked Machine 1 and Machine 2 via an RS-232C cable, and we transmitted the movements of Machine 2's mouse to Machine 1. As one would expect, whether or not Bar 2 will really move in real time with just this setup would probably be the point of great interest. Actually, using a 25 MHz i486SX machine for Machine 1 and a 16 MHz i386SX machine for Machine 2, we were able to move Bar 2 without much of a sense of strangeness. Operating the two machines simultaneously, you can satisfactorily enjoy the competitive shooting game.
Another RS-232C Input/Output Function
On this occasion we didn't use it, but in MicroScript, an "RSWAIT statement" has also been prepared for the purpose of input from the RS-232C. This waits until a specified data string is received at the RS-232C port.
We use the format
RSWAIT <port expression> <data to receive expression> [: <time out expression>]
For example, if we write
RSWAIT 0 0x4f 0x4b :30
we will wait up to 30 seconds at Port 0 until we receive the data string 0x4f, 0x4b. If you omit ": <time out expression>," you can wait permanently. Also, it is possible to describe separately processing for when several data strings are written and one of them has been received. The RSWAIT statement is an essential function for machine control using the RS-232C.
In this installment, I have explained the parallel execution of scripts (VOPEN) and the input/output functions of the RS-232C.
Among my readers, there are probably many individuals who assumed that "complicated programming" would probably be necessary upon just hearing of a setup in which "two machines are connected together with the RS-232C in order to make it so that the two machines can be used together." However, I believe that you now understand that if you cleverly divide between and use the two parallel execution units that 1B MicroScript possesses (Table 2), the programming can be accomplished very neatly. You may feel that parallel programming is difficult while you're not accustomed to it. However, if you can neatly design the basic mechanism in the beginning, you can simplify the programming, and maintenance and modification work also become easy.
|
|
|
|
|
|
| Procedure | EXECUTE <procedure name> |
| Script | VOPEN <real object name> |
A visually oriented programming language/environment along the lines of 1B MicroScript is also provided on other personal computers. However, 1B MicroScript has a multitasking operating system, BTRON, as a platform, and that it can do parallel programming in earnest is a great merit. On a personal computer, an environment in which parallel programming in earnest to this extent can be realized is very rare. 1B MicroScript is, of course, suited to practical use, but also as an environment in which one can easily learn and experience parallel programming.
____________________
|
|
1 #
2 # "Competitive Shooting Game" Script
3 #
4 VARIABLE x y dx dy Left_Edge Right_Edge Top_Edge Bottom_Edge
5 VARIABLE Goal_Number1 Goal_Number2
6 VARIABLE Bar1_Top_Edge Bar1_Bottom_Edge Bar2_Top_Edge Bar2_Bottom_Edge
7 #
8 #
9 PROLOGUE
10 VOPEN Mouse_Input # Starts up in parallel mouse input script
11 SCENE Base Bar1 Bar2 Goal Number1 Number2
12 SET Left_Edge Base.X
13 SET Right_Edge Base.X + Base.W - Ball.W
14 SET Top_Edge Base.Y
15 SET Bottom_Edge Base.H
16 SET Bar1_Top_Edge (Top_Edge+Bottom_Edge)/2
17 SET Bar1_Bottom_Edge Bottom_Edge - Bar1.H
18 SET Bar2_Top_Edge Top_Edge
19 SET Bar2_Bottom_Edge Bar1_Top_Edge - Bar1.H
20 SET Goal1 0; SET Goal2 0
21 TEXT Number1 "Goal Number⇓:%3d" Goal_Number1
22 TEXT Number2 "Goal Number⇒:%3d" Goal_Number2
# Downward pointing arrow appears to be Nihon Kihon 1-232D
# Rightward pointing arrow appears to be Nihon Kihon 1-232A
# Use the character search utility to find these symbols
23 CALL Emit_Ball
24 EXECUTE Move_Ball Move_Bar1 Move_Bar2
25 END
26 #
27 # Processing to make the ball move
28 #
29 ACTION Move_Ball
30 REPEAT
31 SET x x + dx;
32 SET y y + dy;
33 # Bounce processing when the ball has hit the left edge
34 IF x < Left_Edge
35 SET x Left_Edge;
36 SET dx - dx;
37 ELSE
38 # Bounce processing when the ball has hit the right edge
39 IF x > Right_Edge
40 SET x Right_Edge;
41 SET dx - dx;
42 ENDIF
43 ENDIF
44 # Bounce processing when the ball has hit the top bar
45 IF y < Bar2.Y + Bar2.H
46 SET y Bar2.Y + Bar2.H;
47 SET dy - dy;
48 ELSE
49 # Bounce processing when the ball has hit the lower bar
50 IF y > Bar1.Y - Ball.H
51 SET y Bar1.Y - Ball.H;
52 SET dy -dy;
53 ENDIF
54 ENDIF
55 MOVE Ball: x y @
56 IF y >= Goal.Y & y <= Goal.Y + Goal.H &
x >= Goal.X &
x <= Goal.X + Goal.W - Ball.W
# Join lines together; won't process with line breaks
57 CALL Goal_Entered
58 ENDIF
59 ENDREPEAT
60 END
61 #
62 # Processing to make the bar go up and down with mouse movements
63 #
64 DEFINE BAR1 0
65 DEFINE BAR2 1
66 ACTION Move_Bar1
67 CALL Move_Bar BAR1 Bar1_Top_Edge Bar1_Bottom_Edge
68 END
69 #
70 ACTION Move_Bar2
71 CALL Move_Bar BAR2 Bar2_Top_Edge Bar2_Bottom_Edge
72 END
73 #
74 # Called up from procedures "Move_Bar1" and "Move_Bar2"
75 #
76 DEFINE n $ARG[0]
77 DEFINE Bar_Top_Edge $ARG[1]
78 DEFINE Bar_Bottom_Edge $ARG[2]
79 DEFINE Mousey $ARG[7]
80 ACTION Move_Bar
81 REPEAT
82 IF n = BAR1
83 SET Mousey $PDY
84 ELSE
85 SET Mousey $GV[0]
86 ENDIF
87 IF Mousey < Bar_Top_Edge
88 SET Mousey Bar_Top_Edge;
89 ELSE
90 IF Mousey > Bar_Bottom_Edge
91 SET Mousey Bar_Bottom_Edge;
92 ENDIF
93 ENDIF
94 IF n = BAR1 & Mousey != Bar1.Y
95 # Rewrite the bar only when the bar location has been changed
96 MOVE Bar1: Bar1.X Mousey @
97 ELSE
98 IF n = BAR2 & Mousey != Bar2.Y
99 MOVE Bar2: Bar2.X Mousey @
100 ENDIF
101 ENDIF
102 ENDREPEAT
103 END
104 #
105 # Goal entered processing
106 #
107 ACTION Goal_Entered
108 DISAPPEAR Ball
109 BEEP 1000 500
110 MESG "!! Goal Congratulations !!"
111 IF dy > 0
112 SET Goal_Number2 Goal_Number2+1
113 TEXT Number2 "Goal_Number⇒:%3d" Goal_Number2
114 ELSE
115 SET Goal_Number1 Goal_Number1+1
116 TEXT Number1 "Goal_Number⇓:%3d" Goal_Number1
117 ENDIF
118 SLEEP 3000
119 CALL Emit_Ball
120 MESG # Erasure of message
121 END
122 #
123 # Initialize ball position, movement amt.: Show randomness via $RAND
124 #
125 ACTION Emit_Ball
126 SET x $RAND % 8
127 SET y $RAND % 7
128 SET dx 12 + x
129 SET dy 19 - x
130 IF x % 2
131 SET dx -dx
132 ENDIF
133 IF y % 2
134 SET dy -dy
135 ENDIF
136 SET x Goal.X
137 SET y Goal.Y
138 MOVE Ball: x y @
139 APPEAR Ball
140 END
141 #
142 # Termination processing
143 #
144 EPILOGUE
145 VCLOSE # Close the opened window
146 END
|
|
|
1 # 2 # "Mouse Input" Script/Runs on Machine 1 3 # "Competitive Shooting Game" Is Started Up from the Tenth Line 4 # 5 # 6 PROLOGUE 7 RSINIT 0 0 19200 # Initialize RS-232C; 19200 bps 8 EXECUTE Obtain_PointerLocation_fromRS 9 END 10 # 11 ACTION Obtain_PointerLocation_fromRS 12 REPEAT 13 RSGET 0 14 IF $RSCNT > 0 # There was an input from the RS-232C 15 SET $GV[0] $RS[0] # Substitute sent value into global variable 16 RSPUT 0 # Clear input buffer RS 17 ENDIF 18 ENDREPEAT 19 END |
|
|
1 #
2 # "Mouse Output" Script/Runs on Machine 2
3 #
4 VARIABLE pdy pdyOLD
5 PROLOGUE
6 SET pdyOLD 0
7 RSINIT 0 0 19200 # Initialize RS-232C; 19200 bps
8 EXECUTE Output_PointerLocation_toRS
9 END
10 #
11 ACTION Output_PointerLocation_toRS
12 REPEAT
13 SET pdy $PDY & 0xff;
# Kept within 8 bits; send a value of 0~255
14 IF pdy != pdyOLD #Send only when differs with previously sent value
15 RSPUT 0 pdy
16 SET pdyOLD pdy
17 ENDIF
18 ENDREPEAT
19 END
|
____________________
[1] The fixed price of 1B MicroScript is 60,000 yen. However, users who have enrolled in the Software Update Service (SUS) can purchase it at a special price of 20,000 yen. SUS is a system in which by having the user pay an annual fixed sum version up fee, the latest updated software regularly arrives in his/her hands.
[2] Machine 2 is used simply for the purpose of using one more mouse. The same game board as Machine 1 does not appear on top of Machine 2.
[3] Parallel execution by means of the EXECUTE statement: Parallel execution of procedures based on the EXECUTE statement is realized by means of the language processing system of MicroScript.
[4] Parallel execution by means of the VOPEN statement: Parallel execution of scripts based on the VOPEN statement is realized by using the kernel functions of the 1B operating system.
[Translator's Note 1] A lot of the latest IBM-PC/AT-compatible computers, particularly laptop models, do not have an RS-232C interface. This is because compared to the Universal Serial Bus (USB) interface, which is now the standard for connecting peripherals and other devices to personal computers, the RS-232C interface is slower, requires more power, plus a larger connector. So what is the advantage of retaining the RS-232C interface on new computer systems such as the Teacube when USB is so much better? In a word, it is "ease of programming," particularly when support for programming the RS-232C interface is built into a language such as MicroScript.
MicroScript, by the way, does not support USB programming. Here's a translation of two questions from a Japanese language FAQ on Personal Media Corp.'s Cho Kanji Web site concerning serial port programming with MicroScript.
Q1705. Can MicroScript control USB devices?
- MicroScript cannot control USB devices.
- However, concerning the serial port, because it is emulated on the VMware side [in the case of Cho Kanji V, which runs on top of Windows XP], I think communication via the serial port might be possible in a case where setting COM1, etc., on the Windows is possible. Furthermore, in utilizing the serial port with Cho Kanji V, separate settings on the VMware side become necessary.
Q1706. Among the $ERR system variables, 208~212 are RS-232C operation errors. In concrete terms, what kinds of events are assigned to 208~212? The contents of system variables $ERR208~212 are as follows:
- 208: RS232C operation error (illegal port number)
- 209: RS232C operation error (illegal initialization parameter)
- 210: RS232C operation error (busy: in use by other)
- 211: RS232C operation error (initialization error)
- 212: RS232C operation error (transmission error)
Incidentally, in case anyone runs the above Japanese language FAQ through an automatic translator, Q1703 asks whether one can call up TCP/IP functions from MicroScript. The FAQ answer is it cannot be done at the present time, but a third party offers an "auxiliary process module" that allows a MicroScript programmers to do just that. The source code is also available to improve the efficiency of the module. However, this isn't a function that beginners should concern themselves with.
[Translator's Note 2] The RS-232C interface was originally intended for transmission rates below 20,000 bps, and thus 19,200 bps is 96 percent of this capacity. However, just as the 56 Kbps modems used with dial-up Internet connections can achieve higher speeds, so too can modern implementations of the RS-232C interface, and a transmission rate of 57,600 bps, or three times the transmission rate specified in this article, has been regularly attained. The absolute maximum transmission rate for an RS-232C connection is 230,400 bps, which is very respectable for such an old technology.
According to the RSINIT statement explanation on pp. 275-276 of BTRON Maikurosukuriputo [BTRON MicroScript Reference Manual], programmers can specify a serial port communication speed of 75, 150, 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, or 115200. There is an exception for BrainPad TiPO, for which the serial port communication speed cannot be set higher than 38400. However, this hardware platform is now out of production.
The above article on MicroScript appeared on pages 70-79 in Vol. 26 of TRONWARE . It was translated and loaded onto this Web page with the permission of Personal Media Corporation.
Copyright © 1994 Personal Media Corporation
Copyright © 2008 Sakamura Laboratory, University Museum, University of Tokyo
