Msg: 3466 *Conference*
11-29-92 12:23:34
From: RICHARD HANSON
To : JOE ZAMMARELLI
Subj: REPLY TO MSG #3457 (PROGRAM DOWNLOADS)
Very good, basic question, Joe. Well worth open discussion. Make sure you capture this message thread. All Model 100, 102, 200, and NEC8201 programs listed on this BBS are in ASCII. Thus program files are ASCII files. From a Model T point of view, they are .DO files, not .BA or .CO files. Some background: The character set used in all micro computer is made from 8 bit bytes. This yields 256 possible combinations (2^8), or codes 0 through 255. The first 128 combinations (2^7), or codes 0 to 127, present characters standardized by The American National Standards Institute (ANSI). This "common" set of characters is labeled the American Standard Code for Information Interchange (ASCII). Thus, an ASCII file is a file containing codes from 0 to 127, only! With the above in mind (i.e., ASCII as a common character presentation for the first 128 combinations out of 256 possible combinations) what characters are presented for codes 128 through 255? The answer is called 8 bit high characters. Note: Codes 128 to 255 are "not" called "upper ASCII" or "extended ASCII" since ANSI "never coded" 8 bit high characters. Again, ASCII is the name of the ANSI definations for codes 0 through 127. Period! Thus, character presentation for characters 128 to 255 are strictly controlled by the marketplace, i.e., each vendor defines their own 8 bit high characters--IBM, Tandy, Apple, DEC, etc. present different symbols for characters 128 to 255. In fact, Model 102 8 bit high sumbols are slightly different than Model 100 symbols for the same characters. Files in the Model T computers: .DO files are normally created by the TEXT program but may be created through file output or append from within programming. It is true that we [Model T users] may incode 8 bit high characters into our .DO file via the CODE, GRPH and modified CODE and GRPH using CTRL or SHIFT. But generally speaking, we usually just fill our .DO files with common alpha, numeric and special characters. The .DO file (i.e., the ASCII file) is transportable to all computers currently on the face of the earth--micro, mini, mainframe, and super computers. Most, excepting IBM mainframe, use ASCII as their character set. Thus, our .DO files are common files. BTW: IBM uses their own EBCDIC character set on their mainframes. ASCII to EBCDIC translations are accomplished via a protocol converter machine attached to the frame. Incoming ASCII terminals communicate to IBM frames via the protocol converter, or via an ASCII front-end processor, attached to the protocol converter, attached to the frame. Are you actually following this thread? Wow... good luck! .BA files are an anomaly in computing. The .BA file is also know as the "tokenized" file; referring to Microsoft BASIC tokenizing standards. A tokenized file is a file containing character strings representing program commands. You may think of a tokenized file as a partially compiled program file. The Microsoft BASIC tokenized file requires the presents of the Microsoft BASIC interpreter program to complete the compilation process, and thus the running of the BASIC program. It was Bill Gates, himself, who developed the concept and practice of tokenized BASIC program files. The objective was for BASIC program files to take up less memory (RAM) in the computer. His reasoning was in response to the small (4K and 8K) memory-addressing capabilities of the early microprocessors. Bottom line: The .BA file in our Model T's contains codes from 0 through 255 and is not considered an ASCII file. Tokenizing a .DO file to a .BA file... 1) Assuming a BASIC program file stored in ASCII (.DO) in our Model T; example GAME.DO. 2) Go into BASIC and issue the following commands: LOAD"GAME.DO" SAVE"GAME.BA" 3) Upon exiting BASIC you will see both the ASCII file GAME.DO and the tokenized file GAME.BA. The .BA file is runnable. Note: A simplified command sequence to the above example is: LOAD"GAME SAVE"GAME The built-in BASIC interpreter is very forgiving. It seeks out the first occurance of the filename GAME, thus a .DO, and copies it into its editor; tokenizing the ASCII-level commands into Microsoft tokens. When you SAVE"GAME from within the BASIC interpreter it's understood that you want to save the file as a tokenized .BA file. Creating a .DO from a .BA... 1) Assuming a BASIC program file stored as such (tokenized) in our Model T; example GAME.BA. 2) Go into BASIC and issue the following commands: LOAD"GAME.BA" SAVE"GAME.DO" Note: There is no "short cut" for creating the .DO version from within the BASIC interpreter. You must overide the automatic .BA creation by formally naming the file-extension, i.e., GAME.DO. .CO files are fully compiled 8085 machine language program files. The .CO file represents the tights code available for use. It needs no interpretation for use, thus is runs much faster then .BA program files. .CO files contain codes from 0 through 255 and thus are not ASCII files. Machine language (.CO) program use in a Model T requires attention. Due to the nature of the 8085 processor, .CO files may run from only one place in RAM. Each .CO is different in size. And, more than size, jump commands, and reference commands within the .CO file require its placement in one, and only one location in RAM so that each jump and reference goes to the "exact" memory location required. Modifying the actual location of a .CO file in RAM requires a special "relocation" program. Programs for running, relocating and translating .CO files may be found in our online library. Loading and running .CO files... 1) Assuming a .CO file in our menu, like CURSOR.CO... 2) You must first determin how much space to reserve for running this .CO program. Go into BASIC and issue the command: LOADM"CURSOR This will yield 3 numbers. You want to record the "top" number. 3) With the top number recored for all further reference, you want to prepare memory for the running of the selected .CO file. Go into BASIC and issue the following commands: CLEAR0,MAXRAM CLEAR256,topnumber MENU Note: Replace the word "topnumber" with the actual top number you recored for this .CO file. 4) You may now run the .CO file as defined. Each .CO file must be handled in this maner; carefully. Running the same .CO file over and over again should present no problem. However, running 2 or more .CO files "requires" that you clear out the old .CO file and prepare for the new before actually running the new .CO file. If you fail to follow these strict rules you may... no... I take that back... you "will" cold start your Model T computer. Again, machine language program are fast and nice to have around but do require some special care for safe operations. Now that we've explored the three filetypes found in a typical Model T computer, how do we move them to and from our Model T and a DOS (IBM or compatible) computer? In review: The question envoking this thread involved downloading files from this BBS to a DOS computer and moving them over to a Model T for use. With the understanding that all files on this BBS are in ASCII (.DO) then you will move them over to your Model T as .DO files, load them into BASIC for tokenization, then save them as .BA files. Once saved as .BA's, you may move them either back onto your DOS computer via Lapdos II, or save them to any of the Model T-oriented auxiliary storage mediums. As always, I can not stress the use of Lapdos II enough for those of you who own both Model T and DOS computers. Lapdos II is "the" way to fly for duel computer users. Note: Model T and Mac users should use 100duet. I hope this answers your questions about downloading Model T programs from our BBS via your DOS computer for use on your Model T computer. Thank you for the question. -Rick-