Main page
Community Hub0 subscribers
Community Hub
MBASIC
View on Wikipediafrom Wikipedia
| MBASIC | |
|---|---|
| Paradigm | imperative |
| Designed by | Microsoft |
| Developer | Microsoft |
| OS | CP/M |
| Website | www |
| Influenced by | |
| BASIC | |
MBASIC is the Microsoft BASIC implementation of BASIC for the CP/M operating system. MBASIC is a descendant of the original Altair BASIC interpreters that were among Microsoft's first products. MBASIC was one of the two versions of BASIC bundled with the Osborne 1 computer. The name "MBASIC" is derived from the disk file name MBASIC.COM of the BASIC interpreter. MBASIC, like its predecessor family of 8-bit interpreters Microsoft BASIC, were heavily inspired by Digital Equipment Corporation PDP-10's BASIC-PLUS.
Environment
[edit]
MBASIC version 5 required a CP/M system with at least 28 KB of random-access memory (RAM) and at least one diskette drive.
Unlike versions of Microsoft BASIC-80 that were customized by home computer manufacturers to use the particular hardware features of the computer, MBASIC relied only on the CP/M operating system calls for all input and output. Only the CP/M console (screen and keyboard), line printer, and disk devices were available.
MBASIC in the uncustomized form had no functions for graphics, color, joysticks, mice, serial communications, networking, sound, or even a real-time clock function. MBASIC did not fully support the features of the host CP/M operating system, for example, it did not support CP/M's user areas for organizing files on a diskette. Since CP/M systems were typically single-user and stand alone, there was no provision for file or record locking, or any form of multitasking. Apart from these limitations, MBASIC was considered at the time to be a powerful and useful implementation of BASIC.
Features
[edit]Language system
[edit]MBASIC is an interpreter. Program source text was stored in memory in tokenized form, with BASIC keywords replaced by one-byte tokens which saved memory space and speeded execution. Any line prefixed with a line number was stored as program text; BASIC statements not prefixed with a line number were executed immediately as commands. Programs could be listed on the screen for editing, or saved to disk in either a compressed binary format or as plain ASCII text. Every source line was identified with a number, which could be used as the target of a GOTO or GOSUB transfer. Only line editing commands were provided.[1] It was often beneficial to save a program as plain text and edit it with a full featured editor.
Program text, variables, disk buffers and the CP/M operating system itself all had to share the 64 kilobyte address space of the 8080 processor. Typically when first starting MBASIC there would be less than 32 kB memory available for programs and data, even on a machine equipped with a full 64 kilobytes of RAM. Comment lines, prefixed with the REM keyword or an apostrophe, could be placed in the program text but took up valuable memory space, which discouraged BASIC users from fully documenting their code. To allow larger and more complex programs to be run, later versions of MBASIC supported functions that allowed portions of program text to be read in and executed under program control (the " CHAIN " and MERGE statements). No support for "shell" command execution was provided, though this functionality could be duplicated by a determined programmer.
A particular advantage of MBASIC was the full-text error messages provided for syntax and run-time errors. MBASIC also had a "trace" function that displayed line numbers as they were executed. While this occupied the same screen space as normal program output, it was useful for detecting conditions such as endless loops.
Files and input/output
[edit]Data could be read and stored to disk as either sequential files (delimited by the CP/M convention of CR/LF at the end of each line) or else as fixed-record-length random access files, which, given a sufficiently determined programmer, could be used to perform database-type record manipulation. The Microsoft Binary Format for floating point numbers was proprietary to the implementation, which meant that data could only be interchanged with other programs using ASCII text representation or else with extensive programming to convert the binary format.
Variables and data types
[edit]MBASIC supported the following data types:
- 8-bit character data, in strings of length 0 to 255 characters;
- 16-bit integers;
- 32-bit floating point (single precision), equivalent to six decimal digits, with a two-digit exponent;
- 64-bit floating point (double precision), equivalent to sixteen decimal digits, with a two-digit exponent.
String operators included substring selection, concatenation, assignment, and testing for equality.
Arrays of the above types were allowed with up to 7 dimensions, but no functions or operators worked on arrays; for example, there was no assignment of arrays. Unlike some other BASIC implementations of the time, MBASIC did not provide support for matrix operations, complex numbers, or a decimal (BCD) data type for financial calculations. All floating point operations were carried out in software since typical CP/M systems did not have floating point hardware. The built-in mathematics functions (sine, cosine, tangent, natural log, exponential, square root) only gave single precision results. A software pseudorandom number generator was provided; this relied on the user to key in a seed number to obtain a sequence of numbers useful for games and some simulations. MBASIC permitted but did not require the LET keyword for assignment statements.
Early versions of BASIC on microcomputers were infamous for one- or two-character variable names, which made the meanings of variables difficult to recall in complex programs. MBASIC version 5 allowed identifiers up to 40 characters long, which permitted programmers to give variables readable names.
Program flow control
[edit]Program flow control in MBASIC was controlled by IF...THEN...ELSE... conditional tests, WHILE...WEND loops, and GOTO and GOSUB instructions. No CASE statement was available, although an ON...GOTO... (computed GOTO) provided multi-way branches. Subroutines had no parameters and all variables were global. MBASIC did not make structured programming mandatory for programmers and it was easy to write spaghetti code.
PEEKs, POKEs, and user functions
[edit]As with other 8-bit computers of the late 1970s and early 1980s, PEEK and POKE functions were used for directly reading and writing to memory. Since these systems typically had no memory protection, this allowed a programmer to access portions of the operating system, or functions that would not otherwise be available. This also provided opportunities for user programs to hang the system, usually by accident. For example, a CP/M programmer might use a POKE function to allow BASIC to switch the console device to the serial port, if the system BIOS supported this. For machines with real-time clocks, a set of PEEK instructions might have been used to access the time.
For more complex operations, MBASIC allowed user-defined functions that could be called from a BASIC program. These were typically placed in a reserved area of memory, or POKEd into string constants, as a series of machine codes (opcodes). MBASIC also provided hardware INP and OUT instructions that read and wrote directly to the 8080 hardware input/output ports. This could be used to control peripheral devices from a BASIC program if the system hardware permitted.
Any MBASIC programs that made use of PEEK and POKE, and of machine code user functions, were not portable between machines without modifications.
Successors to MBASIC
[edit]Besides Microsoft's BASIC-80 for CP/M, a variant of MBASIC was also available as for the ISIS-II operating system.
MSX-BASIC is also a well known successor of MBASIC, featuring several extensions specific to the MSX machines.
All the functions of CP/M MBASIC were available in the IBM PC disk-based BASICA or GWBASIC which made migration of programs from CP/M systems to PC-compatibles possible. The tokens used to represent keywords were different, so CP/M programs had to be saved in ASCII source form. Typically screen formatting escape sequences put into the CP/M version would be replaced with the cursor positioning commands found in the PC versions of BASIC, otherwise little rewriting would be needed.
BASCOM
[edit]Microsoft sold a CP/M BASIC compiler (known as BASCOM) which used a similar source language to MBASIC. A program debugged under MBASIC could be compiled with BASCOM. Since program text was no longer in memory and the run-time elements of the compiler were smaller than the interpreter, more memory was available for user data. Speed of real program execution increased about 3 fold.
Developers welcomed BASCOM as an alternative to the popular but slow and clumsy CBASIC. Unlike CBASIC, BASCOM did not need a preprocessor for MBASIC source code so could be debugged interactively.[2] While approving of its superior edit-compile-run-debug loop compared to CBASIC, and stating that binaries ran far faster, Jerry Pournelle in December 1980 denounced Microsoft's requirement of a 9% royalty for each binary copy[3] and $40 for hardware-software combinations. The company also reserved the right to audit developers' financial records. Because authors' typical royalty rates for software was 10-25%, InfoWorld in 1980 stated that BASCOM's additional 9% royalty rate "could make software development downright unprofitable", concluding that "Microsoft has the technical solution [to CBASIC's flaws], but not the economic one".[2]
Importance of MBASIC
[edit]MBASIC was an important tool during the era of 8-bit CP/M computers. Skilled users could write routines in MBASIC to automate tasks that in modern-day systems would be performed by powerful application program commands or scripting languages. Exchange of useful MBASIC programs was a common function of computer users' groups. Keying in long BASIC listings from a magazine article was one way of "bootstrapping" software into a new CP/M system. At least one compiler for a high-level language was written in MBASIC, and many small games and utility programs ranging from a few lines to a few thousand lines of code were written.
Other uses
[edit]MBASIC is also the name of a commercial BASIC compiler for the Microchip Technology PIC microcontroller family developed by Basic Micro, Inc., unrelated to the CP/M interpreter.
References
[edit]- ^ CP/M products providing full-screen editing support required their own installation routines to customize the software for the specific computer terminal used as the system console. No support was provided within CP/M to standardize terminal capabilities.
- ^ a b "Editorial". InfoWorld. 1980-08-18. p. 8.
- ^ Pournelle, Jerry (December 1980). "BASIC, Computer Languages, and Computer Adventures". BYTE. p. 222. Retrieved 18 October 2013.
- Thom Hogan and Mike Iannamico, Osborne 1 User's Reference Guide,(1982) Osborne Computer Corporation
- David A. Lien, The BASIC Handbook, 2nd Edition Encyclopedia of the BASIC Computer Language",(1981), Compusoft Publishing
- BASIC 80 Reference Manual, Microsoft Corporation, no date
MBASIC
View on Grokipediafrom Grokipedia
Development History
Origins in Altair BASIC
MBASIC traces its origins to Altair BASIC, Microsoft's inaugural product developed in 1975 by co-founders Bill Gates and Paul Allen specifically for the MITS Altair 8800, the pioneering commercial microcomputer based on the Intel 8080 processor.[7] Motivated by a January 1975 article in Popular Electronics that announced the Altair 8800, Gates and Allen contacted MITS president Ed Roberts and proposed creating a BASIC interpreter, securing a contract despite lacking access to the hardware.[8] To overcome this, Allen developed an 8080 emulator on Harvard University's PDP-10 mainframe, enabling them to write and test the code in MACRO-10 assembly; mathematician Monte Davidoff contributed the floating-point routines.[9] The team completed the interpreter in a frantic effort, delivering a demo that impressed MITS and led to the formal founding of Microsoft on April 4, 1975.[8] Altair BASIC was released in three primary variants tailored to the era's severe memory limitations, reflecting the Altair 8800's modular RAM expansions. The 4K version, the most compact, required just 4 KB of RAM and provided core functionality like basic arithmetic, loops, and simple input/output, fitting into ROM for quick loading but omitting advanced features to conserve space.[10] The 8K edition expanded capabilities slightly while still operating within 8 KB constraints, supporting longer programs and more variables.[10] The Extended BASIC variant demanded at least 12 KB of RAM and introduced enhancements such as the PRINT USING statement for formatted output and support for multi-dimensional arrays, enabling more sophisticated applications like data processing on S-100 bus systems compatible with the Altair.[10] Under the licensing agreement with MITS, Microsoft adopted a per-copy royalty model—$30 for each 4K or 8K BASIC sold and $150 for Extended—marking an early innovation in software distribution economics.[11] This structure, which included an initial $3,000 advance, incentivized MITS to bundle BASIC with Altair kits but soon revealed challenges from unauthorized copying among hobbyists.[11] In response, Gates penned the seminal "An Open Letter to Hobbyists" in February 1976, published in the Homebrew Computer Club newsletter, decrying widespread piracy of Altair BASIC tapes that undermined royalties and equated to theft, a stance that sparked debate but solidified software as a paid commodity.[8] Initial distribution of Altair BASIC occurred primarily through physical media suited to the Altair's primitive interfaces, with the 4K and 8K versions shipped on paper tape for loading via front-panel bootstraps or teletypewriters like the ASR-33. Later releases, including Extended BASIC, utilized audio cassette tapes for higher-capacity storage, read through the Altair's serial interface connected to standard cassette recorders, while output relied on teletype printers or emerging video terminals for interactive sessions.[10] This method, though cumbersome—requiring manual toggling of switches for initial bootstraps—facilitated widespread adoption among early enthusiasts before evolving into more portable formats for subsequent Microsoft BASIC implementations.[12]Adaptation for CP/M Systems
The adaptation to the Intel 8080 and Z80 processors for use with the CP/M operating system began in 1977, with Microsoft engineers porting Altair BASIC and renaming it MBASIC to denote Microsoft BASIC.[13] This adaptation retained the core syntax of its predecessor while optimizing for CP/M's environment, enabling broader compatibility with emerging microcomputers.[13] The initial key release, MBASIC-80 in 1978, required a minimum of 28 KB of RAM and introduced support for disk-based storage, marking a shift from tape-only systems to more persistent data handling.[14] Development occurred in close collaboration with Gary Kildall, CP/M's creator at Digital Research, including licensing agreements that facilitated integration; this partnership also incorporated features like the full-screen editor EDIT.COM for program modification and cassette tape support for data transfer on resource-limited setups.[13] By late 1979, MBASIC was released alongside CP/M 2.0, which enhanced file management capabilities, including random-access files up to 8 MB in size for systems specifying a 256-byte record length.[1] Later versions, such as 5.2 in the early 1980s, added refinements tailored for specific hardware, notably bundling with the Osborne 1 portable computer launched in April 1981, where it served as the primary programming environment alongside CP/M, WordStar, and SuperCalc.[13]Runtime Environment
Hardware and Software Requirements
MBASIC, the CP/M variant of Microsoft BASIC-80, was designed for 8-bit microcomputers equipped with an Intel 8080 or Zilog Z80 processor.[15] It required a minimum of 28 KB of RAM for basic operation, with the core interpreter occupying approximately 16 KB and additional memory needed for program storage and execution.[15] Systems with 32 KB or more were recommended to accommodate larger programs and data structures effectively.[15] For storage, MBASIC relied on a single floppy disk drive—typically 8-inch or 5.25-inch formats compatible with CP/M—or cassette tape for loading and saving programs.[16] Program size was constrained by available RAM, but later versions supported source code up to around 30 KB, limited by the 255-character line length and overall memory allocation.[15] On the software side, MBASIC could not operate standalone and depended on CP/M version 1.4 or later as the host operating system, with version 2.0 preferred for enhanced features like larger random-access files.[15] It interfaced directly with CP/M's Basic Disk Operating System (BDOS) for essential system calls, including file I/O and console operations.[15] A variant of MBASIC for Intel's ISIS-II operating system targeted development systems like the Intellec series, requiring an 8080 processor, at least 48 KB of RAM, and a single disk drive for full functionality.[16] This version maintained compatibility with ISIS-II's file handling but adapted to the system's higher memory demands for debugging and assembly integration.[16]Integration and Limitations
MBASIC integrates seamlessly with the CP/M operating system by leveraging the Basic Disk Operating System (BDOS) for all disk input/output operations, including file access through functions such as OPEN, CLOSE, GET, and PUT.[1] Console interactions, such as keyboard input and screen output via the CON: device, are managed through direct calls to the CP/M Basic Input/Output System (BIOS), enabling MBASIC to bypass standard BDOS behavior and prevent unintended termination from control-C interrupts during execution. This approach ensures reliable operation within CP/M's environment while adhering to its device conventions for peripherals like printers and auxiliary ports. Despite its tight integration, MBASIC exhibits several inherent limitations tied to the CP/M ecosystem. Output is strictly text-based, with no native support for graphics, sound, or color, confining applications to terminal-style displays typical of 1970s-1980s hardware.[1] The interpreter enforces single-tasking execution only, lacking features like user areas, networking capabilities, or multitasking, and it depends entirely on the host CP/M system for error handling and resource management, which can lead to abrupt halts without built-in recovery mechanisms.[1] Performance constraints further highlight MBASIC's environmental bounds, as its interpretive nature introduces execution overhead, making it slower than compiled alternatives for compute-intensive tasks. Memory management in extended sessions can result in fragmentation, necessitating garbage collection pauses that may last 1 to 1.5 minutes, potentially disrupting workflow.[1] Additionally, MBASIC's design precludes compatibility with subsequent standards like MS-DOS, rendering it obsolete for native modern use; contemporary access relies on emulators such as SIMH for accurate CP/M simulation or DOSBox-integrated tools like 22NICE for running legacy sessions.Language Features
Interpreter Mechanics and Syntax
MBASIC functions as an interpreter that executes programs line by line in memory, supporting line-numbered BASIC code stored in a tokenized binary format that compresses keywords, operators, and functions into single-byte (0x80–0xFF) or two-byte tokens for efficient storage.[17][1] This format serves as the default for saved programs, with an optional ASCII mode available via the SAVE command's "A" parameter, though the tokenized representation remains the primary in-memory structure during editing and execution.[1] The interpreter operates in two modes: direct mode for immediate command execution without line numbers, prompting with "Ok" after each statement, and indirect mode for storing and running numbered programs via the RUN command, which begins execution at the lowest line number (ranging from 0 to 65529).[1] Basic syntax revolves around commands entered at the prompt or within numbered lines, with statements separated by colons and a maximum line length of 255 characters in the disk-based MBASIC implementation.[1] Keywords such as RUN (to execute a program), LIST (to display source code), and SAVE (to write to disk) are case-insensitive, permitting mixed-case input while treating it uniformly.[1] Upon encountering invalid syntax, the interpreter halts and issues full-text error messages like "Syntax error" or "Type mismatch" in extended versions, providing clear diagnostics unlike the numeric codes in smaller variants.[1] Program editing integrates directly into the interpreter via a built-in line editor, invoked by typing the line number followed by subcommands such as "I" for insert or "D" for delete, allowing precise modifications without external tools.[1] MBASIC eschews structured modules, depending on line numbers for sequencing and flow control through commands like GOTO and GOSUB.[1] For debugging, an optional trace mode enabled by TRON prints the executing line number before each statement, with TROFF disabling it to resume normal output.[1] A distinctive syntactic feature is the automatic initialization of variables to zero (for numerics) or null strings upon first use, reducing boilerplate code for setup.[1] This, combined with the tokenized input process—where the interpreter converts textual keywords to tokens during entry—ensures streamlined program handling within the constraints of CP/M environments.[17][1]Variables and Data Types
MBASIC supports four primary data types: integers, single-precision floating-point numbers, double-precision floating-point numbers (in extended versions), and strings. Integers are 16-bit signed values ranging from -32768 to 32767, occupying 2 bytes of storage.[1] Single-precision floating-point numbers use 32 bits to represent real numbers with approximately 6 to 7 decimal digits of precision and occupy 4 bytes.[1] Double-precision floating-point, available only in the Extended and Disk BASIC versions of MBASIC, employs 64 bits for up to 16 decimal digits of precision and requires 8 bytes.[1] Strings consist of 8-bit characters with a maximum length of 255 characters, plus 3 bytes of overhead for length and descriptor information.[1] MBASIC does not support user-defined types or complex numbers, limiting numerical operations to these basic forms.[1] Variables in MBASIC are named using alphanumeric identifiers that begin with a letter, followed by letters or digits, with the first two characters being significant in the 8K version and up to 40 characters in Extended and Disk versions.[1] The data type is indicated by an optional suffix: no suffix or "!" for single-precision, "%" for integer, "#" for double-precision, and "for a [string](/page/String)).[](https://ia800609.us.archive.org/11/items/BASIC-80_MBASIC_Reference_Manual/BASIC-80_MBASIC_Reference_Manual_text.pdf) Variables are implicitly declared upon first assignment, with a default type of single-precision numeric unless specified otherwise via type suffixes or global type statements likeDEFINT, DEFSNG, DEFDBL, or DEFSTR, which set defaults for ranges of variable names (e.g., DEFINT A-Zmakes all unspecified numeric variables [integer](/page/Integer)s).[](https://ia800609.us.archive.org/11/items/BASIC-80_MBASIC_Reference_Manual/BASIC-80_MBASIC_Reference_Manual_text.pdf) Arrays are declared explicitly using theDIMstatement, specifying dimensions up to 255 with a maximum of 32767 elements per dimension (e.g.,DIM SALES(12, 4)` for a two-dimensional array), and follow the same naming and typing rules as scalar variables.[1] Variable names cannot be reserved words, though Extended and Disk versions permit embedded reserved words within longer names.[1]
Type handling in MBASIC includes automatic conversions during expressions and assignments to promote compatibility. For instance, assigning a floating-point value to an integer variable truncates the fractional part after rounding (e.g., A% = 23.7 sets A% to 24), while arithmetic operations use the type of the most precise operand, converting others as needed (e.g., integer operands in a sum with a float become floats).[1] Explicit conversion functions such as CINT, CSNG, CDBL, STR$, and VAL allow programmers to control type changes (e.g., CINT(55.88) yields 56).[1] Strings are delimited by double quotes in literals (e.g., MESSAGE$ = "Hello, World!") and support concatenation with the + operator, but numeric-string mixing requires explicit conversion to avoid errors.[1] Precision limits apply strictly: integers overflow silently by wrapping around, and floating-point operations may lose accuracy beyond the supported digits.[1]
Storage for variables is dynamically allocated from the available memory space, distinct from program code. Numeric variables and arrays use fixed sizes per element (2 bytes for integers, 4 for single-precision, 8 for double-precision), while strings are allocated from a separate string space managed by the interpreter's garbage collector, which reclaims unused space when needed and can be queried via FRE("").[1] In the 8K version, memory constraints limit variable usage more severely compared to Extended BASIC, which supports larger programs and more variables.[1] This dynamic approach allows flexible use of variables in expressions and control structures without manual memory management.[1]
10 DEFINT A-Z ' Default all numerics to integer
20 A = 42 ' A is integer (42)
30 B! = 3.14 ' B is single-precision (overrides default)
40 C$ = "Data" ' C is string
50 DIM X(5) ' Integer array X with 6 elements
60 PRINT A, B!, C$, X(1)
Control Structures
MBASIC provides unstructured control flow primarily through unconditional jumps and basic conditional statements, relying on line numbers to specify targets for branching. Programs are organized into sequentially numbered lines, typically integers from 0 to 65529, which serve as unique identifiers for execution points; all GOTO, GOSUB, and similar statements must reference these line numbers rather than symbolic labels. This design, inherited from earlier BASIC interpreters, facilitates simple navigation but can lead to "spaghetti code" without careful structuring.[1] Unconditional branching is handled by the GOTO statement, which transfers execution immediately to the specified line number without preserving the call stack. For subroutines, GOSUB branches to a line number while pushing the return address onto an internal stack, allowing up to a memory-limited depth of nesting; execution resumes after the calling line upon encountering RETURN, which pops the stack and jumps back accordingly. These mechanisms enable modular code reuse but lack modern scoping or parameter passing. For example:10 GOSUB 100
20 PRINT "Back from subroutine"
...
100 PRINT "In subroutine"
110 RETURN
10 IF X > 0 THEN 20 ELSE 30
20 PRINT "Positive": [GOTO](/page/Goto) 40
30 PRINT "Non-positive"
40 END
10 FOR I = 1 TO 10 STEP 2
20 PRINT I
30 NEXT I
10 ON ERROR GOTO 1000
20 A = 1 / 0 REM [Division by zero](/page/Division_by_zero)
...
1000 PRINT "Error at line"; ERL
1010 RESUME NEXT
Input/Output and File Handling
MBASIC provides straightforward mechanisms for input and output operations, primarily through console interactions, printer output, and disk file management, tailored to the constraints of CP/M environments. Console input is handled via the INPUT statement, which pauses program execution to accept data from the user, optionally preceded by a prompt string. For instance,INPUT "Enter name: "; A\$ displays the prompt and assigns the entered string to variable A$, with data items separated by commas for multiple variables. If no prompt is given, MBASIC prints a question mark; numeric variables expect numeric input, while strings accept any characters until Enter.[15] Output to the console uses the PRINT statement, which displays expressions, strings, or variables, with formatting options for alignment. Commas in PRINT advance to the next 14-space zone, semicolons place items immediately after the previous output without spacing, and a trailing semicolon suppresses the carriage return. Additional formatting includes TAB(n) to position the cursor at column n (where n ranges from 1 to the screen width) and SPC(n) to insert n spaces (n from 1 to 255), enabling tabular displays or spacing control; the screen serves as the default output device.[1][15]
Printer output in MBASIC is directed through dedicated statements that interface with the CP/M printer device (typically LST:). The LPRINT statement functions analogously to PRINT but sends output to the printer, supporting up to 132 characters per line and the same formatting options like commas, semicolons, TAB, and SPC. For example, LPRINT "Report Header"; TAB(20); "Data Value" produces aligned printed text. The LLIST command lists program lines to the printer, mirroring the LIST command's syntax for specifying line ranges, such as LLIST 100-200, without advanced formatting beyond basic line numbering. These operations lack built-in support for printer-specific controls like font changes or margins, relying on CP/M's device handling.[15][1]
File handling in MBASIC supports sequential and random-access operations on disk files, managed through statements that allocate file numbers (1 to 15) and interact with CP/M's file system. The OPEN statement establishes a file connection, specifying mode ("I" for input/sequential read, "O" for output/sequential write, or "R" for random access), file number, and filename, with an optional record length for random files (default 128 bytes). For example, OPEN "O", #1, "DATA.TXT" prepares a sequential output file. Sequential files are read or written line-by-line using INPUT# and PRINT# (or WRITE# for comma-quoted output), respectively; PRINT# mirrors console PRINT but appends a carriage return/line feed, while WRITE# adds delimiters for data portability. The CLOSE statement terminates access to specified files (or all if omitted), ensuring buffers are flushed for output files, and KILL deletes a file from disk, such as KILL "DATA.TXT". Random-access files use fixed-length records, with FIELD #n, length AS var$ defining substrings in a buffer (e.g., FIELD #1, 10 AS A\$, 20 AS B\$), and GET/PUT statements to read/write records by number via an implicit RECORD variable (set with RECORD #1, recnum). File status is queried using EOF(n), which returns -1 at the end of a sequential input file, and LOF(n), which provides the number of bytes (sequential) or records (random) in the file.[15][1]
MBASIC employs the Microsoft Binary Format (MBF) for efficient storage of numeric data in files, particularly in random-access mode, where integers, singles, and doubles are packed into fixed bytes (e.g., 2 for integers, 4 for singles) to conserve space on limited CP/M disks. Sequential files default to ASCII text for readability, but binary output can be forced; conversion between formats uses functions like MKI$(value) to create MBF integer strings, CVS$(string) to unpack singles, and their inverse CVI and CVD equivalents for input. Utilities such as SAVE "filename",A explicitly save programs or data in ASCII, while standard SAVE uses compressed MBF; EOF and LOF assist in navigating these formats without manual byte counting. This design balances portability and efficiency, though MBF requires compatible Microsoft BASIC interpreters for direct reading.[15][1]
Advanced Capabilities
Memory Access Operations
MBASIC provides direct memory access through the PEEK function and POKE statement, enabling programmers to read from and write to specific memory locations for low-level data manipulation. These operations are essential for tasks requiring interaction with hardware-specific memory areas, such as inspecting status flags or modifying data structures not accessible via standard BASIC variables. However, their use demands caution due to the potential for system instability if critical memory regions are altered.[1] The PEEK function retrieves a single byte from a specified memory address, returning an integer value between 0 and 255. Its syntax is PEEK(I), where I is an integer expression representing the memory address. In extended and disk versions of MBASIC, typical for CP/M systems, addresses range from 0 to 65536, allowing access across the full 64 KB address space of 16-bit systems like those based on the Intel 8080 or Zilog Z80 processors. For instance, the statementX = PEEK(16384) would read the byte at address 16384 and store it in variable X, commonly used to inspect system variables or status flags in CP/M environments. This function complements higher-level data handling by providing granular inspection without altering memory contents.[1]
In contrast, the POKE statement writes a byte to a memory address, with the syntax POKE I, J, where I is the target address and J is the byte value (0 to 255). Like PEEK, it operates within the 0 to 65536 address range in extended MBASIC implementations. An example is POKE 16384, 0, which sets the byte at address 16384 to 0, potentially used to clear flags or update data in video memory for custom display routines on CP/M terminals. Programmers often employed POKE to load small assembly routines or pass parameters to machine-code subroutines directly in memory. However, invalid addresses or writes to protected areas, such as the MBASIC interpreter itself or CP/M system regions, can cause program crashes or system hangs.[1]
These operations are inherently non-portable across different hardware configurations, as memory maps vary between systems; for example, video memory locations differ on 8080-based versus Z80-based CP/M machines, and address calculations may require adjustments due to processor-specific memory layouts or BIOS implementations. In Z80 systems, additional registers might influence indirect addressing, but PEEK and POKE themselves remain byte-oriented and compatible with 8080 code. Users are advised to consult system-specific documentation, such as CP/M BIOS details, before employing these commands to avoid hardware-dependent errors. Overall, while powerful for advanced applications like real-time data inspection in embedded-like environments, PEEK and POKE underscore the trade-offs of direct hardware access in an interpreted language.[1]