Jump to content
  • entries
  • comments
  • views

The ABCs of Compiled Diamond BASIC Programs



A couple of months ago I found my ABC BASIC compiler disk and wondered if a BASIC program written for Diamond could be compiled. Then I said, “I'm going to try that as soon as I get disk drive 2 up and running.”


Disk drive 2 is up and running and I can say that an Atari BASIC program, demoing the Icon commands, compiled and ran on a 130XE with Diamond 3.0 . It took me longer to format an Atari DOS 2.0 disk then it did to compile the program.




ABC was produced by Monarch Data Systems, copyright 1982, 1983. Quoting from the manual:


“ABC is a software development tool designed to improve the performance of your Atari BASIC programs. It lets you enjoy the high speed and memory efficiency of compiled languages like FORTH and C, without leaving the familiar environment of your BASIC cartridge.”


“A compiler is a program that accepts source code (your BASIC program) and translates it to another form, in this case a compact pseudo-code or P-code. Once compiled, this P-code can be executed by another program called a run-time interpreter.”


The benefits of using ABC include faster execution speed, greater memory efficiency, and a non-BASIC cartridge environment.


The ABC software does have its limitations. When writing BASIC programs to be complied, it is best to know these limitations and avoid them when designing the program. One thing to consider is that numeric variables are considered integer. ABC does not support Floating Point Math( FPM). Then there is a hole list of commands that are not supported.


So far most of the diamond programs I have written have not required floating point math. Communications between BASIC and DIAMOND is done through a USR call to page six. Moving byte and memory location data between the programs is done without FPM.



An Atari BASIC demo program was to be used for the first attempt. HORSE.BAS was written to demo the icon function calls. INSTALLICON(4), MOVEICON(5), REMOVE ICON(6), SHAPEICON(7), and OVERLAPICON(46). All but the last are used within the program to animate an icon. The SHAPEICON function is used to redraw the icon with different bit mapped images.


There is a series of bit mapped images of a running horse in Computer Animation Primer by David Fox and Mitchell Waite. The book is archived at atariarchive.org. Page 182 and page 183 holds the bit map for each of five frames of animation.


The program starts with the public domain basic shell program to setup the transfer of data from BASIC to the Diamond cartridge . The Diamond desktop is then initialized and ready for the icons to be placed on the screen. Each icon is displayed on the screen after the bitmap data is placed into a string of memory. Once all the five icons have been placed on the screen they are then removed. One icon is placed in the center, then SHAPEICON is used to cycle through the different frames.


BASIC runs the program at a reasonable frame rate to view the animation.



I wasn't thinking there was much of a chance that this was going to work so if the procedure was anymore then what it turned out to be I was going to give up quick.


Step 1 – Put the ABC disk in drive one. Put a single density disk with HORSE.BAS in drive 2.


Step 2 – Boot the computer without Diamond or BASIC.


Step 3 – Enter the source file name D2:HORSE.BAS


Step 4 – Enter the destination file name D2:HORSE.APP


Step 5 – Let ABC do its thing.


Was I surprised that it worked the first time I tried running HORSE.APP from the desktop and it worked? YES I was.


There was one small glitch. When I first compiled the program I named it HORSE.OBJ. When I tried to run it from the desktop the mouse pointer showed up and then letters started to flash all over the screen. It was 1970 all over again.


Then I remembered that exiting diamond for an APP is different then an OBJ. Diamond remains active in the system when an APP is run. I renamed the HORSE.OBJ to HORSE.APP and it worked without recompiling the program.


Speed check.


I timed the programs from when the Diamond GOS was exited to when the animation started.


BASLOADR.APP was used to create an auto run file (HORSE.SYS) for the HORSE.BAS. Double click on the HORSE.SYS file. Then select QUIT from the drop down menu. I started the timer when the OK button was clicked. It took 57 seconds until the horse was running.


To time HORSE.APP , the clock was started after double clicking on the file name. It took 20 seconds for the running horse to show up. The frame rate of the running horse was improved over BASIC but it would not be require to program a delay loop to keep it from moving to fast.




I'm going to call this experiment a success (on a stock 130XE with Diamond GOS 3.0). And as always, past success is not always an indication of future failure.


Attached are two Movie Files of the load and run. You can see for yourself the speed advantage of a compiled program. Sorry, couldn't get my frame grabber to work so I used a camera.


Recommended Comments

There are no comments to display.

Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...