NIGHTMARE MISSION
MAC's the one for the job
The assignment?
Produce a high-quality game simulating the behavior of a new aircraft from major aerospace manufacturer. The game is to be used at trade shows.
The destination equipment?
The end-user had a number of ATARI 400's with 16K RAM.
The time allowed?
Unlike the usual three to six months allowed for game development, we had four weeks.
Four weeks! To develop over 250 pages of assembly code (some 25K of object)? Yes, four weeks.
Most sane programmers would have declined the task. This is just not enough time to develop all the terrain and bitmaps, type in all the code, and get the whole works debugged. And did I mention that we had to put it all into a cartridge for the end-user!
However, other considerations made us tackle this assignment. First was our professional pride. Second was our belief in our equipment. Third, and most important, were our upcoming bills; a second baby was due to arrive any day.
So, we accepted the challenge, and delivered the game on schedule. To be sure, we cut things a little close - we delivered the game the day the trade show opened - but we made it.
How did we do it? That's the subject of this and several upcoming columns. Briefly, we used some very advanced equipment and techniques to drastically shorten the development time for the game. The individual methods will be covered in these columns, for your use.
The emphasis here is not just on getting the job done. Rather, we are speaking of getting a large programming task done very quickly. Anyone who has paid for programming services knows how expensive a programmer's time is; herein are some valuable tips to cut down the amount of time required to develop products for the ATARI. Software developers take note! The techniques used here can save you weeks of development time and large amounts of money.
The first topic we'll cover is assemblers. The program had to be written in assembly language in order to be put on cartridge. To be sure, a variety of other languages can possibly be put on cartridge, but we didn't have time to experiment with unknowns. In order to write an assembly language program, we need an assembler - and in this case, the best one available, for there would be many assemblies and thousands of lines of code. The amount of time that would be wasted by a slow assembler was unacceptable for a project that had to be done in four weeks.
We have used a variety of assemblers for the ATARI. For this project, we selected the best of the group -- MAC/65. MAC/65 is from Optimized Systems Software in Sunnyvale, California.
I must admit that this was a difficult choice. We had not used MAC/65 before embarking on this project, so if it had not lived up to its advertising, we would have been in trouble. Fortunately, it did, and the MAC/65 turned out to be a key factor in our making this tight deadline; it is a fast, debugged assembler and editor rolled into one. How fast would you believe 320K of source code assembled in under three minutes? That's about 4000 lines of code per minute, including disk-access time.
Why did we decide to go with MAC/65, a relative unknown? Let's look briefly at the other assemblers we have used:
Assembler/Editor Cartridge (from Atari). This cartridge is the reason we felt queasy about buying MAC/65 from OSS; OSS in its early days designed this cartridge and sold a slightly upgraded version of it as "EASMD'. This is not a professional or even particularly useful assembler; it assembles about one line of code per second. At that rate, our project would have assembled in about 3 1/2 hours instead of three minutes. This cartridge also has some weird bugs and "locks up" during assemblies for unknown reasons. If you are developing Atari software, do not buy this cartridge for assembling, although (as we shall see) its debuggers can be useful. As an assembler, however, it will just waste your valuable time.
Atari Macro Assembler/Editor. This was the best thing on the market for some time. It takes input from a text editor (usually MEDIT is used) and assembles from the raw source code. Naturally, this is a rather slow process, because much analysis must be performed on the source code to make sure the syntax is valid. We used AMAC for our last large project, and while it was an improvement over the ASM/ED cartridge, it wasn't enough. (Keep in mind that hand assembling code is very nearly an improvement over the ASM/ED cartridge. ) However, while AMAC is good, its overall use in the development process doesn't work out so well.
The problem? All the disk accesses to load AMAC, MEDIT, DOS Menu, and so forth, take time. Anything having to do with disk drives on the ATARI is very slow. It is a real shame there is no "direct" way to go from MEDIT to AMAC, and have both in memory at the same time.
At Atari, this problem has been partially solved by using RAMDISK -- a product which emulates an Atari disk drive with RAM. Thus, going from DOS to AMAC, for instance, is very fast. However, there are two problems with RAMDISKs: 1) they are expensive and 2) if the system crashes, the contents of RAMDISK are lost.
Atari's Macro Assembler has some other really strange things about it. Sometimes the files on the destination disk get chewed up for no particular reason; I have never found the exact cause of this problem, but it always happens when AMAC is present. In addition, double density is not supported and only works sometimes. AMAC is resident in fairly low memory, so too many double-density file buffers will overwrite it.
Remember, Atari doesn't support double density. If the disk to which AMAC is writing the print or object file fills up, the system crashes - just dies. No error message or anything. Furthermore, your disk's directory will be messed up following such a crash.
AMAC will assemble illegal opcodes. Try a STA #$04, for instance (an immediate STA is an impossible concept). Sure enough, AMAC will create an opcode for it, because it gets past the syntax checker.
Supposedly there is a new version of AMAC that fixes these and other bugs, but in the meantime, the slow editing/assembly development process and other problems disqualified AMAC for us.
Synassembler (from Synapse Software). This assembler is used in-house at Synpase, with great success. I used Synassembler to develop the software for a memory board disk emulator. It has both good and bad points.
On the bright side, this is a very fast assembler. It achieves this speed by "tokenizing'' or crunching down, source code as it is entered. MAC/65 also uses this process. Assembling this crunched code is a fast process, because the code already has the opcodes and operands labelled. Synassembler does not have to scan for them, as does AMAC. Hence, even long programs (a few thousand lines) assemble in a few seconds. The speed is comparable to MAC/65.
The Synassembler also includes a monitor, which I found powerful, but difficult to remember how to use. It kept me close to the user's manual, constantly looking up how to disassemble memory change locations, and so on. I wish that there could be a standard for monitors and monitor commands so that I would not have to constantly learn new "improved" commands; I'm happy with the usual old ones. When I could figure out how to do what I wanted to do, the monitor worked well.
However, I shied away from the Synassembler for this project for a number of reasons. First, it has a different syntax for 6502 opcodes. I am used to the usual syntax from the ASM/ED cartridge and other places, and didn't want to keep looking up new instructions. Example: "ROL A" in Synassembler is "ROL"; "ROL A" makes for an assembly error. How frustrating!
Some other things about Synassembler bother me. The BLOAD feature for loading binary files loads only the first segment of the file. If you use multiple segmented files, as I do, you are out of luck. In a big project, you are practically forced to use segmented files, as charsets, P/M bitmaps, and such must start on page boundaries. The syntax checker has problems. It gives incorrect errors on:
10 LABEL ;This semicolon is illegal.
or
10 TXA; This comment is laso flagged as bad.
or
10 LDA #10 ;whups! two spaces between A and #.
or
10 LDA #1+1; no space between parts of expression.
And so on and so on. (Naturally, none of this is mentioned in the manual, with the exception of stating that the syntax is "free format" i.e, extra spaces are ignored. The manual is wrong.)
When the author gets time to go clean up these trivialities, which should be any time now, the Synassembler will be a nice tool; in the meantime, I just don't have the mentality to remember all of its idiosyncracies. I am starting from behind using the Synassembler because I am used to other syntaxes. If you are just starting out in assembly, the Synassembler might be much easier to use.
Another assembler we could have used is MAE. However, I have never used MAE, and did not have time to learn a new syntax and new debugger. On the other hand, a "leading programmer" tells me that MAE is not bad at all, but that his version is extensively modified from the original MAE. So please do not feel that I am saying anything bad about MAE.
There are some other assemblers for the ATARI, but I have not had experience with them. Which brings us to MAC/65.
MAC/65 was written by Steven Lawrow, from New Jersey, and marketed through OSS. It is extremely fast, powerful and thoroughly debugged. It is a pleasure to use. MAC/65 consists of two parts, the editor, and the assembler. The editor is the default mode; the assembler is invoked with the "ASM" command, and returns to the editor when done. MAC/ 65 can be invoked in the assembler mode from OS/A + , if you use OS/A +.
The editor is line-number oriented, so those of you who have used the Synassembler or ASM/ED will be in familiar territory. A number of powerful editing functions are included. MAC/65 uses an internal crunched form, and converts all source code into this tokenized format. This allows MAC/65 to assemble at very high speed; if you have a thousand lines of code in memory, and type ASM, by the time you look up at the screen after pressing [RETURN], your assembly will be done.
The editor is very powerfu at some of the functions:
BLOAD/BSAVE: Load and save binary files. (Yes, it loads multiple segmented files too).
C,D: Change or Display memory immediately. This allows you to change margins, color, and so forth while in the editor.
DEL: block delete a range of line numbers.
ENTER: A most powerful command. Allows entry of untokenized source code. The ,M option will merge the source code into the current file; this is how to add a block of line-numbered code to a current file. The ,A option allows you to enter source code without line numbers (translation, from AMAC files). What a thoughtful addition! It saved me a lot of work, as a lot of my code came from former AMAC files. ENTER will automatically add line numbers to the code.
FIND: Finds a given string, optionally within a range of line numbers. This is a quick and easy way to search for anything; it saves you having to LIST through a file to find (for example) a given label. Just FIND /LABEL/ instead. The optional ,A finds all occurrences of a given label. This provides an excellent way to list out, for editing, everything relating to one label that needs changing.
LIST, LOAD,NEW: List to printer/ disk, Load a tokenized file, and Clear memory.
NUM: start auto line numbering.
PRINT: Like LIST, EXCEPT that line numbers are not printed to a disk file. Hence, you can go BACK to AMAC using PRINT. (Again, very thoughtful).
REN: Renumber. Very fast and comprehensive.
REP: Replace. Replaces any one string with another, optionally for all occurrences, optionally within a range of line numbers in the file. This is a very useful and powerful command; for instance, if you have incorrectly used a label throughout a file, you can zap all occurrences of it with REP.
SAVE: Saves internal format files to disk.
SIZE: Prints current memory allocations, and how much memory of the MAC/65 buffer is in use. There's a large amount of internal memory free (from roughly $2000 to $8000), and SIZE lets you keep track if you are running low on internal space. Should your source code be too large, it can be broken up into several files and chained together with ".INCLUDE". Of course, this slows down the assembly process to disk speed.
And finally, "?". "?" does hex to decimal or decimal to hex conversions, right there, immediately. This is just in the right place, at code entry time; it saves a lot of paper and pencil work. Sometimes when I need a fast conversion I will boot up MAC/65 just for this feature.
In summary, the editor will do most everything you will ever want and more.
The assembler uses nice, standard opcodes, from the ASM/ED "standard". In fact, ASM/ED files will load in (via ENTER) and assemble directly with no hassles, which is great for upgrading. The assembler also has a powerful macro facility, which I did not have the time to learn how to use. However, the manual gives a clear example of one macro, which I will pass on as an example of how powerful the macros are:
10 PRINT "THIS IS AN OUTPUT LINE OF TEXT"
-WILL- assemble, and actually print that line of text to the screen, with proper macro definitions. Talk about easing the transition from BASIC to assembler! Anyway, for those of you into macros, MAC/65 has more than enough to keep you happy.
In the final stages of our project, we had two double density disks completely filled with code and a third drive with DOS and MAC/65 on it (because the other disks were so full). MAC/65 would bring in the data fram both drives and produce a 180 sector (dden) object file in three minutes. That is impressive indeed. (Mind you, this was using a fast drive that cut down on disk access time. But if you use a RAMDISK or Corvus drive, you will also run at this sort of speed. I would recommend it for longer programs).
What is more impressive is the lack of "surprises" in using this assembler; I did not find any bugs whatsoever. It is a pleasure to find an assembler (or any other product) where the designer did not invent a new series of commands or syntax for the users to have to learn. MAC/ 65 does the "good old stuff" very quickly.
In summary, MAC/65 proved to be an extremely fast, versatile assembler which greatly helped us complete our project in time. We recommend it to anyone wishing to speed up their program development.
"Next: How, we debugged the program: a revolutionary technique."
Dave and Sandy Small are proffesional programmers working with ATARI computers and ATARI-compatible peripherals and software to run on ATARIs. They begin here to share some discoveries, insights, experiencs and secrets of interest to others at or near their level of practice. Each article is intended to stand alone, but articles are sequential and full value may depend on reading the whole series. Questions or suggestions can be addressed to them care of ANTIC. Responsive answers are not guaranteed, but may be made individually by mail (if self-addressed stamped envelope is provided) or publicly in this department.