Forth Blocks
Volume Number: | | 1
|
Issue Number: | | 10
|
Column Tag: | | Forth Forum
|
"Converting Forth Blocks to Ascii Text"
"Accuracy in Modula-2 Reviewed"
By Jörg Langowski, Chemical Engineer, Fed. Rep. of Germany, MacTutor Editorial Board
With the advent of other Forth systems than MacForth, and Forth-related packages such as NEON, a utility is needed that lets us quickly convert the MacForth 'Blocks' format into a standard ASCII text file and back. NEON, for instance, expects its input from a normal text file. Also this Journal expects its input from a MacWrite file, and after I have written an example program, cutting it out of the Forth screens and pasting it into my column is quite cumbersome.
So here is a routine that does this job automatically (it contains some ideas out of a program on one Call-A.P.P.L.E. public domain disk). At the same time we are going to learn something about the Standard File Interface package, which is undocumented (but fully usable) in MacForth 1.1.
What do we need to know to convert files from Blocks to Text format and back? The type of a Blocks file is BLKS and the creator M4TH, a Text file such as saved by 'text only' MacWrite or MDS Edit is of type TEXT and creator MACA (this probably stands for Mac Ascii). In principle, both files contain ASCII text, which, however, is organized differently.
The format of a Blocks file
MacForth blocks files consist of screens , each of which contain 16 lines of 64 characters. One line is always 64 characters long and padded with blanks after the last character. This format is a relic from early FORTH times and - in my opinion - rather obsolete. But since the MacForth editor uses it, we have to live with it. The length of a file is of course very simply related to the number of screens; each screen occupies exactly 1024 bytes.
Text files, on the other hand, contain lines of ASCII characters which are separated by carriage returns (CR).
One very simple thing that one can try out to communicate between the two types of files is to change type and creator of a Blocks file to TEXT and MACA, hoping that it is recognized by Edit, for example. When I tried this, it would show a file that had only one line (of course, since there are no CRs). So we do have to read the Blocks file, line by line, and create a new text file to which we write those lines.
Reading Forth blocks
A Forth block in a file is accessed through the word BLOCK, which accepts the block number on top of stack and returns the address of a buffer that contains the block. The block is automatically read in if it is not already there.
The position of a line in the block is at (64 * line number). The word >LINE.START in the program example returns the address of a line in a given block. We then remove trailing blanks from this line, add a CR at the end and write it to the Text file (which we have opened before). This is what the word COPY.BLOCK does, which is called from the main menu: It traverses the Blocks file line by line and writes the Text file.
ASCII to Blocks conversion
The reverse direction is a little bit more complicated. The total number of lines in a blocks file is known exactly from its size, so we know ahead of time how many screens we have to convert; also a Text file can be extended arbitrarily by just adding lines. Not so the other way around: a Blocks file must be extended by appending blocks before writing to them, and the end of a Text file is known only when an end-of-file occurs.
In the example, each text line is read into the string variable TEXT.BUF with the character count in the first byte and the actual line in the following bytes. This string is then copied into a new line in the buffer; when 11 lines have been processed in this way, the buffer is written out to disk (UPDATE FLUSH) and the Blocks file extended by one block. The last five lines of each block stay blank for easier editing. Some editing is necessary because the block boundaries will often split your definitions.
Choosing input and output files - the standard file package
So the principle of this utility routine has been set up. But we still have to open the files that we want to work on. To make file access more comfortable, let's use the standard Macintosh file package to select those files.
You've seen the dialog boxes that make up the interface to this package many times. Whenever you are supposed to select a file for input, a Mac application that conforms to the User Interface standards will show you a list of files to select from and option buttons that let you change drives, eject disks or quit the operation.
When you select a file for output (or save) you are presented with an input box with a default file name:
and when the file name that you give already exists on that disk, the standard file package will ask for reconfirmation to overwrite that file.
All these functions are built into two toolbox routines, SFGetFile and SFPutFile. MacForth provides built-in interfaces to those routines, the words (GET.FILE) and (PUT.FILE). The Forth words expect less parameters than the corresponding toolbox traps.
(GET.FILE) needs, from bottom to top of stack:
- a point (2*16 bit) where the top left of the dialog box is to be located;
- the address of a prompt string (zero for no prompt);
- the address of a list of file types to be displayed;
- the number of different file types;
- the address of a reply record.
(PUT.FILE) needs:
- the top left point;
- the address of a prompt string;
- the address of a string which may contain the default file name and later contains the actual file name;
- the address of a reply record.
Information about the user's response to the dialog box is contained in the reply record. The format is:
- 2 bytes boolean, true if OK, false if Cancel button was clicked;
- 4 bytes of file type information;
- 2 bytes integer, contain the volume reference number (important if volume was changed);
- 2 bytes integer, file version number, not used here;
- 64 bytes that contain the file name in Mac string format (count byte plus characters).
The list of file types is an array of 4 byte integers; each 4-byte cell contains one valid type designator, such as PICT, TEXT, DATA, etc. On calling (GET.FILE), only those files corresponding to one of the designators will be displayed. Invisible files will be displayed, too.
In our program, input and output files are set up using the standard file interface by the words TEXT.OPEN, BLOCK.OPEN, TEXT.CREATE and BLOCK.CREATE. After the dialog has been processed, the volume reference number (which might have been changed from the default volume) is moved into the file's FCB and the type and creator fields are set depending on whether a Text or a Blocks file is written. Thereafter, the actual file conversion takes place.
During the execution of the conversion routines the activate event is switched off. If you don't do this, the main Forth window would be activated again after the first file dialog has been processed, executing an ABORT and jumping back to the 'ok' prompt, quitting your program. Try this out and see what happens when you leave out line 6 in the CHANGE.MENU definition.
With that little routine, creating MacWrite listings from your Forth programs will be easy now.
Floating point glitches in Modula-2
Even though I am responsible for Forth, I must make one more Modula comment.
Watch out when you're using math!
I have become extremely careful in this respect. The 32-bit routines are fast, true. In order to be useful, they should also give correct results (within rounding errors). This is not so. Try the example in listing 2 (WindowIO is a module of my own that just sets up a standard window for I/O). The program just keeps adding smaller and smaller numbers to 1.0, which I did originally as an accuracy test. The output is shown there, too. Sometimes the output routine seems to fail, sometimes the addition itself. And I thought this was a system I could use for some of my calculations in the lab oh well. No more comments.
Surprisingly enough, though, a non-linear curve fitting program that I wrote in Modula seems to work well, without major problems. It may be that the bug shows up only when the numbers are close to integers (???). Any comments from readers with similar experiences are appreciated, any help even more. (Richard Ohran, are you reading this? If not, a bug report will follow.)
Listing 1: Converting text to blocks files
( Forth <-> Ascii Conversion) ( © 1985 MacTutor by J. Langowski
)
: tx-blks ;
variable ifile# -1 ifile# !
variable ofile# -1 ofile# !
: ifile ifile# @ ; : ofile ofile# @ ;
hex 4D414341 constant "maca decimal
create ="blks "blks ,
create ="textdata "text , "data ,
18 field +fcb.name 22 field +fcb.vrefnum
32 field +fcb.type 36 field +fcb.creator
( standard file reply record fields )
00 field +good : @good +good w@ ;
02 field +ftype : @ftype +ftype @ ;
06 field +vrefnum : @vrefnum +vrefnum <w@ ;
10 field +fname
create ireply 80 allot
ireply +fname constant iname
create oreply 80 allot
oreply +fname constant oname
variable screen# variable cur.line#
create text.buf 100 allot
99 constant text.read.limit
5 constant ch.menu
: moverefnum ( file#\reply -- )
@vrefnum swap >fcb +fcb.vrefnum w! ;
: get.input.name
>r >r >r
100 100 xy>point 0 r> r> r@
(get.file) page r> @good
0= if abort then ;
: get.save.name
page >r >r >r
100 100 xy>point r> r> r@
(put.file) r> @good
0= if abort then ;
: text.open
next.fcb ifile# !
page ." Text file to convert:"
="textdata 2 ireply get.input.name
iname ifile assign
ifile ireply moverefnum
ifile open ?file.error
ifile rewind ?file.error ;
: block.open
next.fcb ifile# !
page ." Blocks file to convert:"
="blks 1 ireply get.input.name
iname ifile assign
ifile ireply moverefnum
ifile open ?file.error ifile select ;
: block.create
next.fcb ofile# !
" Mac Tutor Blocks"
oname over c@ 1+ cmove
" Save as:" oname oreply get.save.name
oname ofile assign
ofile oreply moverefnum ofile delete
ofile create.blocks.file ?file.error
ofile open ?file.error ofile select
2 ofile append.blocks
1 screen# ! 0 cur.line# !
0 block b/buf bl fill update flush ;
: text.create
next.fcb ofile# !
" Mac Tutor Text" oname over c@ 1+ cmove
" Save as:" oname oreply get.save.name
oname ofile assign
ofile oreply moverefnum ofile delete
ofile create.file ?file.error
ofile open ?file.error ofile rewind
ofile get.file.info
"text ofile >fcb +fcb.type !
"maca ofile >fcb +fcb.creator !
ofile set.file.info ;
: >line.start ( block\line -- addr of line)
64 * swap block + ;
: write.line
>line.start 64 -trailing
over over + 13 swap c! ( add CR )
1+ ofile write.text ;
: write.screen
dup 16 0 do dup i ( screen\line )
over over . 2 spaces . cr ( debug )
write.line loop drop ( n ) ;
: copy.block ifile get.eof b/buf /
0 do i . cr i write.screen
do.events drop loop ;
: read.line ifile current.position
text.buf 1+ text.read.limit
ifile read.text
ifile current.position swap -
text.buf c! ;
: copy.line
read.line ?eof not
if cur.line# @ dup .
64 * screen# @ dup . cr
block + text.buf 1+ swap
text.buf c@ 1- cmove
1 cur.line# +! cur.line# @ 10 >
if 0 cur.line# ! update flush
1 screen# +! 1 ofile append.blocks
then do.events drop true
else update flush false then ;
: copy.text begin copy.line not until ;
: >text block.open text.create copy.block ;
: >block text.open block.create copy.text ;
: change.menu
0 " Change" ch.menu new.menu
" Forth->Ascii;Ascii->Forth;"
ch.menu append.items draw.menu.bar
ch.menu menu.selection:
1 activate.event scale -1 xor events !
0 hilite.menu
case 1 of >text endof
2 OF >block endof endcase
events on do.events abort ;
change.menu
Listing 2: Modula 2 FP 'accuracy test'
MODULE Accuracy;
FROM InOut IMPORT ReadCard, WriteCard,
WriteString, WriteLn, ClearScreen;
FROM RealInOut IMPORT ReadReal, GWriteReal;
FROM WindowIO IMPORT SetupWindow;
FROM EventManager IMPORT Button;
VAR a,b : REAL;
BEGIN
SetupWindow
("Accuracy test",40,40,350,450,4,9);
a := 1.0; b := 1.0;
WriteString
(" a b a+b"); WriteLn;
REPEAT
b := b/10.0;
GWriteReal(a,12); GWriteReal(b,12);
GWriteReal(a+b,12); WriteLn;
WHILE Button() DO END;
UNTIL (b = 0.0);
REPEAT UNTIL Button();
END Accuracy.
Listing 3: Output of the Accuracy program
(terminated before underflow occurred). Note that b is sometimes printed as zero, although a+b seems to be correct; and for some smaller values of b (1.0E-19 to 1.0E-25) a+b starts to behave very strange.
a b a+b
1.000000 0.1000000 1.100000
1.000000 0.01000000 1.010000
1.000000 0.00000000 1.001000
1.000000 0.00010000 1.000100
1.000000 0.00001000 1.000010
1.000000 0.00000100 1.000001
1.000000 0.00000010 1.000000
1.000000 1.0000E-08 1.000000
1.000000 1.0000E-09 1.000000
1.000000 1.0000E-10 1.000000
1.000000 1.0000E-11 1.000000
1.000000 0.0000E-13 1.000000 ?
1.000000 1.0000E-13 1.000000
1.000000 1.0000E-14 1.000000
1.000000 1.0000E-15 1.000000
1.000000 1.0000E-16 1.000000
1.000000 1.0000E-17 1.000000
1.000000 0.0000E-19 1.000000 ?
1.000000 1.0000E-19 2.844674 ???
1.000000 1.0000E-20 1.184467 ??
1.000000 1.0000E-21 1.018447 ??
1.000000 0.0000E-23 1.001845 ??
1.000000 1.0000E-23 1.000184 ?
1.000000 1.0000E-24 1.000018 ?
1.000000 1.0000E-25 1.000002 ?
1.000000 0.0000E-27 1.000000 ?
1.000000 1.0000E-27 1.000000
1.000000 1.0000E-28 1.000000
1.000000 1.0000E-29 1.000000
1.000000 1.0000E-30 1.000000
1.000000 1.0000E-31 1.000000
1.000000 1.0000E-32 1.000000
1.000000 1.0000E-33 1.000000
1.000000 1.0000E-34 1.000000
1.000000 1.0000E-35 1.000000