MTU C13R Specifikace stáhnout pdf (Strana 15)

"The decimal point shift bug does not exist in microBASIC, since numbers 0.1E+10

or larger (and 0.1E-4 o smaller) are automatically converted to scientific not

ation. Example 12 on the tutorial disk illustrates this. Someone else will have

to answer if the bug exists in APL or COBOL, but I don't believe it can."

Later, Bob told us that the 'factor of 10* problem affects only the screen dis

play. Since internal calculations are right, correct the display only.

< X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X > < > C > < X X X X X X X X X X X X X X X X X X X X X X >

PLOTTER PROBLEMS H.O. Pritchard, Professor of Chemistry at York University

In SuperPET at Downsview, Ontario M^J 1P3, reports problems in mFORTRAN

while using an HP7470A plotter with SuperPET. The plotter

is addressed as ieee5. When, after mFORTRAN has been running for a long time, he

requests digitized input from the plotter with the

open (unit=10,file="ieee5") sequence shown at left, he receives an EOF error,

read (10,*) x,y,ipen The problem is cured either by reset of SuperPET,

[Returns EOF error] or by revising the program to read as shown in the

second version at left. Dr. Pritchard states that

open (unit=10,file="disk5" the problem afflicts a number of SuperPET models,

read (10,*) x,y,ipen from the earliest to the latest, and suspects ROMs

[Works] carrying IEEE system routines are in error, since

the problem does not occur when he uses BASIC 4.0 with the 6502. He reports that

the same problem crops up in microBASIC and in Assembly language. Waterloo has

been queried and we'll report on their response. Note: this is an input bug; it

may afflict other input devices on the IEEE bus. Dr. Pritchard also also reports

the same problem noted by Bob Davis elsewhere in this issue: the loss of a fact

or of ten in screen displays of large numeric values in mFORTRAN.

C K X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X > < X X X X X X X X X X X X >

MORE ON RELATIVE FILES In this article, I'll cover some less basic aspects of

by Loch Rose relative files, beginning with ways to handle files if

102 Fresh Pond Parkway some records contain more data items than others. Pro-

Cambridge, MA 02138 gram 1, below, creates such a file:

Program 1

400 randomize : string$ = "abcdefghijklmnopqrstuvwxyz" : c$ = ","

410 terminator$ = chr$(255) ! terminator$ could be any character(s)

420 open #2, "(f:60)examples,rel", output

430 for recnum = 0 to 20 ! write 21 records

440 num_items = int(rnd*5) ! each record randomly contains 0-4 items

450 print #2, rec=recnum, ! positions you at start of rec. //recnum

460 for j = 1 to num_items ! if num_items=0 this loop is skipped

470 print #2, str$(string$,rnd*21+1,4); c$; ! print a 4-char, string

480 next j

490 print //2, terminator$ ! last char, (since no end of record)

500 next recnum

510 close //2 : stop ! SAVE this program

As usual, data items are separated by commas; note that now the last data item

is always a chr$(255). The remark on line 490 refers to the fact that a PRINT//

statement that does not end with a semicolon causes the end of the current rec

ord and the start of a new one, though in this case line 450 would cause you to

move to the next record on the next iteration anyway. Program 2, below, shows

how you can INPUT the file created above:

Program 2

200 open //2, "(f:60)examples,rel", input

210 for recnum = 3 to 18 ! for fun, only look at records 3-18

SuperpPET Gazette, Vol.I No.11 -170-

December 1983/January 1984

1 2 ... 10 11 12 13 14 15 16 17 18 19 20 ... 24 25

Komentáře k této Příručce

Žádné komentáře

MTU C13R Specifikace Strana 15

Komentáře k této Příručce

Související produkty a manuály pro Motor MTU C13R