BIF Documentation By Joel Matthew Rees 19 January 1992, 8 April 2019 BIF documentation Copyright 1992, 2000, 2019 Joel Matthew Rees BIF source and object Copyright 1992, 2000, 2019 Joel Matthew Rees https://ja.osdn.net/projects/bif-6809/ In the spirit of fig-FORTH, the author grants permission as follows: ========= Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the accompanying copyright notices and this permission notice appear in all copies. THE SOFTWARE IS PROVIDED “AS IS” AND ISC DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ========= (This is essentially the ISC license.) If the copyright notices in this file and the README.TXT file are retained, including that file and this with your distribution will fulfill the copyright notice obligation. But you really should include both anyway, just to be kind to the people who receive it. Note that: BIF is architecturally derived from fig-FORTH. fig-FORTH comes courtesy of the FORTH INTEREST GROUP, PO Box 1105, San Carlos, CA 94070. This is not a commercial product; it was a student project, use it at your own risk. No warranty whatsoever is made concerning it. (If, by chance, anyone is interested in using BIF in a commercial product, I would appreciate knowing about it in advance.) The author's intent is only to make it available for experimentation, and it should be treated as strictly experimental software. DO NOT ATTEMPT TO ACCESS ORDINARY DISKS FORMATTED FOR USE BY OTHER OPERATING SYSTEMS WHILE BIF IS RUNNING! Contact as of January 2000: http://reiisi.blogspot.com joel.rees+knock@gmail.com https://defining-computers.blogspot.com/ https://ja.osdn.net/users/reiisi/ https://sourceforge.net/u/reiisi/profile/ ******************************************************************************* General Information BIF (BInary tree, fig-FORTH) is a dialect of FORTH for the Tandy Color Computer. It is a direct-threaded version of the pre-FORTH-79 fORTH interest group publication of FORTH (fig-FORTH), using a non-standard binary tree dictionary structure. The direct-threading mechanism uses the direct-page addressing mode of the 6809, and thus may not be easily adaptable to FORTH-83. It also uses absolute addressing, and thus does not comform to the requirements of OS-9. (I am working on an indirect-threaded version of BIF for OS-9 in my spare time.) BIF.BIN is the executable object; after LOADMing it, EXEC the address &H1300 (see below). BIFSOURC.ARC contains the archived (TC31) source files; the assembler used is Disk EDTASM+. I used TSEdit to generate the source files in EDTASM+ format: line-number SPACE [label] TAB mnemonic etc. LF Using a text editor to replace the macros with their expansions should make it compatible with most other assemblers. An object which will run under the EDTASM+ "stand-alone" debugger may be generated by changing ORG $1200 in BIF.ASM to ORG $3F00. BIFSCREE.ARC contains the BIF/FORTH source for several utilities, the assembler, and double integer definitions (TOOLS.G00) and a definition pairing example (PAIRS.G28) useful for making paired lists. Using TOOLS.G00 and PAIRS.G28 directly will require moving the two files to their original granules, 0 and 28, on an ECB disk. Once they are moved, protecting the BIF screens with ECB directory entries may be a good idea. But resist the temptation to use a text editor on them. Messing with the whitespace will move the source code out of alignment with the physical FORTH/BIF screens, and thus cause the source code not to load. If you want to look at these two files with an editor, I suggest copying them to a different disk and looking at the copies. Even my favorite IBM PC editor, QEDIT, will insert a CR/LF at the end of every 512 bytes on saving, which is not good. (I wonder how many letters from OS-9 users it would take to convince the folks at SEMWARE/Applied Systems Technologies to make an OS-9 version of their editor?) For $5.00, to cover postage, time, and the cost of floppies, I will send a copy of the BIF screens disk on a standard 5 1/4" (ECB formatted) floppy. If you request the EDTASM+ compatible source code, I will send that as well, on the same format disks. For $5.00 more, I will include a photo-copy of the documentation (useful if you don't have a way to print it). The documentation which follows is written in the standard FORTH documentation style. It is not intended as a primer or study guide. Brodie's Starting FORTH, Winfield's THE COMPLETE FORTH, or some other text is suggested to those unfamiliar with FORTH. Much of the code and examples should work as shown in the textbooks I recommend Leo Brodie's work, because he points out most of the places the user will have to refer to this documentation. Some of the descriptions are incomplete, particularly where definitions are intended to be used inside other definitions. The object contains a simple one-sector editor (for 32-column screens) in the EDITOR vocabulary. It does not provide search and replace, but it is sufficient, for the patient, to write code. My apologies for it. I did not have a Color Computer 3 when I wrote the original code, and haven't had the time to update it. Those with access to the fig-FORTH Installation Manual should have no problem installing the editor shown there. The assembler in the BIF screens is a full postfix assembler. The double integer screens show a quick example of its use. ******************************************************************************* Getting BIF Running Before you start, remember that BIF has the same post-fix grammar as FORTH. Think Reverse Polish, as in HP calculators. Computer: Comments: In Disk ECB, type: LOADM "BIF.BIN" from whichever drive it is on, then remove all disks and EXEC &H1300 BIF should tell you it is running with 6809 BIF V1.0 OK At this point, see if BIF is really running by typing VLIST and hitting ENTER. You should see a listing of your main vocabulary (symbol table) which should run on for about 200 entries, and then the computer responds with OK If this doesn't happen, you have a bad object file, get a new copy. Otherwise, you have BIF! If you have my BIF screens disk, put it in drive 0. Then type 6 LOAD to load the utilities starting at screen 6. After the utilities are loaded, you can load the assembler by typing DECIMAL 16 LOAD If you don't have the BIF screens disk with the error messages, type 0 WARNING ! and BIF responds with OK but now tells you error numbers instead of messages. Okay, a few examples: 42 EMIT puts the ascii character 42 (asterisk if the current BASE is DECIMAL) on the output device. 5 6 * . prints the product of 5 and 6 (30, base ten) on the output device. DECIMAL : CHARS 32 DO I . I EMIT CR LOOP ; HEX 45 CHARS will set up a BIF "word" called CHARS, which, being invoked on the second line, will print the characters and hexadecimal ascii codes from SPACE up to, but not including, DASH. The BIF screens disk should always be in drive 0 if you want real error messages. If you want to look at the message text, the messages are at the front of TOOLS.G00, after the directory screen and title screen. Each message takes exactly 32 characters, including spaces and non-printing characters. Numbering starts with 0. If you have some other disk in drive 0 you will get funny and not exactly intelligent error messages. I know it's weird, but I was following the fig-FORTH model, which is designed for very limited memory. If you haven't been able to put the BIF screens disk together, you don't really need it to play around with BIF, but do clear the WARNING variable so BIF will know error messages are not available. Aside from the error messages in drive 0, there is nothing special about screens disks, except they do not have directory tracks. You should generally not put them in your drives when running under BASIC (DECB), OS-9 or some other system. By tradition, programmers use the first several screens as a hand-typed directory. You can format fresh BIF disks with either Disk Extended Color BASIC's DSKINI or OS-9's format. BIF ignores the directory information both systems write, so you also generally should not put a real DECB or OS-9 disk in while BIF is running. If you do format with OS-9, format single-sided (I used DECB's disk interface routines so BIF can't do double sided) with as many tracks as you want. To use the extra tracks, or a third or fourth drive, you will need to modify the DRIVE-OFFSET array. Pick a standard disk configuration and stick with it. An important word of warning. BIF, like FORTH, uses buffered I/O. Your screens are not actually saved to disk until you cause the system to need enough new buffers to write your editing back to the disk. To force the system to save the buffers, give BIF the SAVE-BUFFERS command. ******************************************************************************* BIF's QUICK Editor EDITOR gets you into the EDITOR vocabulary. 0 QLIST lets you look at the first sector of the directory. 4 B/SCR * QLIST lets you look at the first eight error messages. DECIMAL makes sure your conversion base is base ten. 64 B/SCR * QUICK lets you edit the first sector of the pairing example. Use the cursor keys to move around; use the BREAK key to get out. If you modified something you don't want to change, type EMPTY-BUFFERS and ENTER. If you want to make sure your changes are written to the disk, type SAVE-BUFFERS and ENTER. The QUICK editor is in the EDITOR vocabulary. It is available at boot up. You'll need to get into the EDITOR vocabulary, to access it. Pass it a sector number, not a screen number. Multiplying by B/SCR (which happens to be 4) will convert a screen number to a sector number. Add 1, 2, or 3 to the base sector number of a screen to get the sector numbers for the second, third, and fourth sectors of that screen. The editor has no find/replace or block functions. Again I apologize for the editor, but I found it surprisingly workable. Note that the utility screens contain routines to move/copy sectors, so all is not entirely mud. One more glitch. Lower case letters will show as VDG codes until you run the cursor over them. What can I say? During editing, all arrow keys are cursor controls. Use SHIFT-LEFTARROW for destructive backspace, SHIFT-DOWNARROW for `[' left bracket, SHIFT-RIGHTARROW for `]' right bracket, SHIFT-UPARROW for `_' underscore (back-arrow on CoCo2). SHIFT-CLEAR escapes the UP-ARROW to provide the `^' caret. SHIFT-CLEAR also escapes itself to provide the backslash. Perhaps this is as good a place as any to mention a few points of terminology. A block is a sector. Sectors are numbered sequentially from 0. Sector numbering continues sequentially from drive n to drive n+1, see DRIVE-OFFSET, but also see OFFSET. A SCREEN is a kilobyte worth of blocks, in this case, four 256-byte sectors. SCREEN numbering also begins with 0. (SCREENs are called SCREENs because a SCREEN can be displayed on 16 lines of a 64-column CRT screen.) You will notice that a CoCo 2 can't properly display and edit a whole SCREEN. Finally, forward blocks are control constructs, not disk sectors. ******************************************************************************* The BIF Virtual Machine { bifc_vm.h --- fig 6809 UP [DP] pointer to the per-USER variable table (USER Pointer) IP Y pointer to the next definition (Instruction Pointer) RP S return/control stack pointer SP U parameter/data stack pointer W [S] pointer to executing definition's parameter field } The BIF Virtual Machine fig 6809 { bifc_vm.c bif.m bifdp.a NEXT ( --- ) jmp [,y++] (macro in bif.m) Causes the next definition to execute. DOCOL ( *** IP ) jsr