home *** CD-ROM | disk | FTP | other *** search
-
- Appendix A
- Converting Programs
-
-
-
- Introduction
-
- This Appendix is intended for use by
- programmers wishing to convert various forms of
- BASIC into MaxonBASIC. It starts with general
- notes about all conversions, then is sub-
- divided into sections for particular common
- BASIC implementations. It finishes with some
- hints and tips on writing programs that can
- easily be ported to the IBM PC, Macintosh and
- Amiga
-
-
- General Conversions
-
- Most BASICs share a certain core of the
- language, no matter how different they seem to
- be. PRINT always does the same thing, so does
- INPUT and so forth. BASICs can differ by being
- machine specific, ANSI standard, or conforming
- to a certain style (Microsoft´s QuickBASIC and
- Borland´s Turbo Basic are notable examples).
- Whichever BASIC you are trying to convert a
- program from, you will need to get the source
- into ASCII. Some BASICs use ASCII for their
- programs anyway, but most interpreters use a
- tokenised form that will come out as gibberish
- if loaded into the editor. You should save your
- program from your BASIC interpreter using an
- ASCII option, if possible.
- Some things stand very little chance of being
- the same from one BASIC to another, in
- particular internal floating point
- representations and random-access file formats.
- One thing to be aware of particularly is that
- string length limitations found in other BASICs
- do not exist in MaxonBASIC. In particular the
- LEN function can return a long integer as a
- result, not just an integer as in other BASICs.
-
-
- HiSoft BASIC 1
-
- The following is a summary of some potential
- incompatibilities between HiSoft BASIC 1 and
- MaxonBASIC; don´t panic at the size of this list
- as the majority of HiSoft BASIC and its baby
- sister, Power BASIC, programs will compile
- without change. We have listed these under
- headings of facilities used.
-
-
- LIBRARY statement
-
- If you have used a path to the BMAP file
- without a colon or leading / you will need to
- change this; the best way is to remove the path
- and use the MaxonBASIC Library Path option
- (LIBPATH).
-
-
- REDIM/ERASE of arrays
-
- If you dimension an array using just a number
- or a constant (e.g. DIM A(1000) you can´t ERASE
- or REDIM it in MaxonBASIC 3 unless you add
-
-
- REM $DYNAMIC
-
-
- before the DIM statement. If the DIM expression
- is a non-constant expression e.g.
-
-
- array_size=100
- DIM A(array_size)
-
-
- then there is no need for this change. As well
- as enabling the compiler to produce faster code
- for static arrays, this change also brings
- MaxonBASIC in line with the Microsoft
- QuickBASIC usage.
-
-
- ERL function
-
- If no logical line numbers have been used, this
- function will now return the physical line
- number that caused the error. If your ONÉERROR
- routine is testing to see if ERL is 0 (perhaps
- to see if you are still in your initialisation
- code) then you´ll need to insert a line number
- at the start of your program and test for this
- value instead.
- This feature was introduced so that modern
- programs that need to use an ONÉERROR to ensure
- safe termination (freeing operating system
- resources for example) can give an indication
- of the source of the error. This facility is
- however not available in Microsoft BASIC on the
- PC.
-
-
- LOC on COM1:
-
- The LOC statement when used on files opened
- with COM1: now returns the number of characters
- waiting rather than just a 1 if there are any
- characters waiting. So use something like this:
-
-
- DO
- chars%=LOC(3)
- IF chars% THEN
- a$=INPUT$(a%,3)
- PRINT a$
- END IF
- LOOP
-
-
- rather than
-
-
- DO
- IF LOC(3) THEN
- a$=INPUT$(1,3)
- PRINT a$
- END IF
- LOOP
-
-
-
-
- New reserved words
-
- The following are now reserved words: BEGINIO,
- BYVAL, CURDIR$, FORMATD$, FORMATI$, FORMATL$,
- FORMATS$, FREEFILE, INITHOOK, IS, LTRIM$, MAX,
- MIN, PEEK$, PRESERVE, RINSTR, RTRIM$, TAGLIST
- and so can no longer be used as names for user
- variables, sub-programs and labels.
- If you are in a hurry to compile your existing
- MaxonBASIC 1 program then you can include
- HBAm1.BH at the start of your program and then
- these reserved words will be disabled.
-
-
- AmigaBASIC
-
- In the dim, distant past AmigaBASIC was
- supplied free with all the Amiga computers and
- therefore we endeavoured to make MaxonBASIC 1
- as compatible as we could with it. However
- despite all the extensions to the language,
- MaxonBASIC 3 will run many existing AmigaBASIC
- programs unchanged.
- Note that all references to AmigaBASIC refer to
- version 1.2, the final version.
-
-
- De-tokenising
-
- Before trying to compile any program from the
- interpreter, the source must be converted to
- ASCII instead of the special tokenised form
- that the interpreter uses to store its files.
- To do this , load the interpreter, then load
- your program. Select the Output window then
- type a line such as
-
- SAVE "filename.bas",a
- where "filename.bas" should be changed as
- required. The ,a at the end is important - it
- tells the interpreter to save the file as
- ASCII. We strongly recommend that source files
- follow the .bas naming convention, so you can
- tell them apart from compiled versions, for
- example. The file so created can then be used
- by MaxonBASIC and you can load it back into the
- interpreter at any time without conversion
- because MaxonBASIC only uses ASCII files and
- the interpreter can read them directly.
-
-
- Unimplemented Features
-
- The following features of AmigaBASIC are not
- implemented in MaxonBASIC:
-
- COMMON, RESUME NEXT, OBJECT.PRIORITY
- In addition, interpreter only statements such
- as LOAD, SAVE etc are not implemented as they
- make no sense in a compiler environment.
-
-
- Compatibility Issues
-
- We have tried wherever possible to be
- compatible with the interpreter in both source
- syntax and run-time emulation.
- In terms of source syntax, MaxonBASIC accepts
- practically all legal AmigaBASIC syntax, except
- that you may be using a variable which has the
- same name as one of the additional reserved
- words, such as SYSTAB. If you are in a hurry to
- compile an existing AmigaBASIC program then you
- can include AmBas.BH at the start of your
- program and then these reserved words will be
- disabled.
- When trying to compile existing programs that
- seemed to run perfectly under the interpreter,
- the compiler may find errors the interpreter
- missed, normally in a section of code that
- seldom gets executed. Note that MaxonBASIC does
- not allow a variable to be the same name as a
- program label, but this is unlikely to cause
- problems.
- Some AmigaBASIC programs use LOOP as a variable
- name: this is not possible with MaxonBASIC as
- this is a reserved word used for the general
- loop structure.
- In terms of run-time emulation, we have tried
- to emulate the exact actions of the
- interpreter, where it made sense to do so. We
- discovered several undocumented features of the
- interpreter during the development of the
- compiler (e.g. FRE(-3)) and emulated those
- found.
- However there are bound to be circumstances
- that we did not try and if you rely on an
- undocumented feature it may not work the same
- under the compiler. There are some features of
- the run-time system we decided not to emulate,
- such limiting the maximum window size to non-
- PAL sized screens and various guru-type bugs.
- Under the interpreter you can use
- DECLAREÉLIBRARY for library sub-
- programs/functions before you have used the
- LIBRARY statement; the DECLARE statements must
- be after the LIBRARY statement in MaxonBASIC.
- Multi-dimensional arrays are stored in a
- different order to that used by AmigaBASIC;
- generally this isn´t a problem except when the
- graphics GET and PUT statements are used with
- such an array.
- Note that double-precision variables are stored
- in a different order in memory between the
- compiler and the interpreter, but this will
- only effect programs doing rather nasty things
- with VARPTR. In addition, single-precision
- numbers are stored in a completely different
- format (though are still 4 bytes in size) which
- has less range than that used by the
- interpreter. When reading and writing random-
- access files (using MKD, MKS, CVD and CVS) we
- are as compatible as possible with the
- interpreter though, except for the range limit
- on single-precision numbers.
- Also note that VARPTR returns a pointer to a
- string descriptor, but the string descriptors
- themselves are very different under the
- interpreter and the compiler. Programs that use
- VARPTR to directly adjust string descriptors
- will not work without modification.
-
-
-
- Old-Style Microsoft BASICs
-
- Microsoft BASIC is the closest to a world
- standard for the BASIC language and is the one
- around which we designed MaxonBASIC.
- For this reason most versions of Microsoft
- BASIC should not present problems converting to
- MaxonBASIC. Programs written in the old-style
- BASICs, such as those found in Commodore 64s
- and under CP/M should require little or no work
- to convert, as long as machine-specific PEEKs
- and POKEs are avoided. You can also save typing
- by not entering the line numbers that aren´t
- needed.
- Most BASIC interpreters from other vendors are
- at least in part based on the same principles
- as Microsoft so should also convert reasonably
- easily.
-
-
-
- New-Style Microsoft BASICs
-
- The new style of Microsoft BASIC is defined by
- QuickBASIC, Visual BASIC and the Microsoft
- BASIC PDS and running on IBMs and compatibles.
- By new-style we mean support for structured
- programming such as sub-programs and parameter
- passing, CASE, , DO etc. MaxonBASIC supports
- almost all the features of QuickBASIC 2 and 3
- and most of the features of QuickBASIC 4.0, 4.5
- and has some additional features from the PDS
- 7.1 system.
- The main advantages of MaxonBASIC that you can
- exploit when converting programs from the IBM
- world, are the large memory and greater graphic
- support. In addition, recursive programming
- techniques can be used.
- When converting QuickBASIC programs there are a
- few things which are not supported by
- MaxonBASIC by reason of operating system or
- hardware differences.
- Missing statements under this category are:
- COM, CVSMBF,CVSMBF,DRAW, ERDEV, ERDEV$,
- FILEATTR IOCTL$, IOCTL, KEY, , LOCK,
- MKDMBF$,MKSMBF$, ON various, PAINT, PEN, PLAY,
- PMAP, SETMEM, SHELL, UEVENT, UNLOCK, VARPTR$,
- VARSEG, VIEW, and WAIT
- Obviously PEEKs and POKEs are completely
- different, as are machine-code calling
- conventions. There are also slight differences
- in the following commands:
- CIRCLE, CLEAR, CLS, COLOR, FILES, LINE, LOCATE,
- OPEN, PCOPY, POINT, SCREEN, SEEK, SOUND, STICK,
- and WINDOW.
- MaxonBASIC does not at this time support the
- following Microsoft BASIC statements:
- COMMON , DOUBLE, INTEGER, LONG, RESUME NEXT,
- SINGLE, TYPEÉEND TYPE
- In addition to this high degree of Microsoft
- compatibility, MaxonBASIC also compiles many of
- the additional features found in Borland´s
- Turbo Basic compiler and Spectra Publishing´s
- Power BASIC for the PC.
-
-
- HiSoft BASIC on the Atari
-
-
-
- The main area of incompatibility here is in
- graphics commands. MaxonBASIC does not
- support the following HiSoft BASIC Atari
- commands:
-
- BAR, CLEARW, CLOSEW, ELLIPSE, ENVIRON,
- ENVIRON$, FILL, FULLW, GB, GEMSYS, GETCOOKIE,
- LINEF, OPENW, PCIRCLE, SPOKB, SPOKEW, SPOKEL,
- SPEEKB, SPEEKW, SPEEKL, VDISYS
- The following commands are implemented on both
- machines but differ in their action:
- CIRCLE, COLOR, FRE, PALETTE, SCREEN, SOUND,
- SYSTAB, WAVE, WINDOW.
- The following are reserved words in MaxonBASIC
- 3 Amiga but may be used as variables on the
- Atari; either change the variable names or use
- the HBST2.BH include file - this will prevent
- you from accessing the following BASIC Amiga
- commands:
-
- AREA, AREAFILL, BEGINIO, BREAK. COLLISION,
- CVFFP, INITHOOK, LIBRARY, MENU, MKFFP$,
- OBJECT.various, ONÉ various, PAINT, PEEK$,
- PTAB, SAY, SCROLL, TAGLIST, TRANSLATE$
- In addition, we also supply HBST1.BH which also
- excludes the reserved words that were
- introduced in version 2 of MaxonBASIC for the
- Atari.
-
-
- Writing for compatibility
-
- We are often asked which compiler you should
- purchase to make it easy to port a program that
- you´ve written in MaxonBASIC on the Amiga if
- you want to move it to another system. At the
- time of writing we recommend the following:
- For the PC, MicroSoft´s BASIC PDS 7.1 or the
- much cheaper, but less sophisticated,
- QuickBASIC 4.5 or QBASIC that is supplied with
- MSDOS.
- For the Macintosh, Microsoft QuickBASIC.
- For the Atari ST/TT/Falcon, MaxonBASIC of
- course.
- If you want to write your program so that it is
- easy to port to other systems, here are a few
- hints:
-
- · Isolate your use of system specific
- features to a few sub-programs. If you can,
- try porting these to other machines before
- you use them extensively; you may find that
- you are relying on something that is easy
- on the Amiga, but different on another
- machine.
- · If you are porting to a non-MAXON product
- be wary of limitations on the sizes of
- strings and arrays. QuickBASIC 4.5 doesn´t
- allow more than 64K of strings total for
- example and many BASICs won´t let you have
- more than 32767 elements in an array.
- · Use the forms of statement that we
- recommend in the Command Reference section.
- For example, use EXIT DO rather than EXIT
- LOOP and REDIM PRESERVE rather than REDIM
- APPEND.
-
-
-
-