The Softalk Apple Project - Programming

Digging In to the Roger Wagner Archive

Timlynn Babitsky — Tue, 20 Jan 2015 21:08:02 +0000

For all of you Assembly Lines fans out there, STAP's multi-award winning Chris Torrence recently posted this excellent YouTube video showcasing the new book, Assembly Lines: The Complete Book, the first in his series of Assembly Lines videos. To date he has posted three videos. The first of his videos is reposted here. It provides an overview of the table of contents with general information about the book itself and where you can get it.

His next two videos drill down into more specific topics: Assembly Lines #1: The Merlin Assembler; and Assembly Lines #2: Merlin Assembler Editor. Since they are consecutively numbered, be looking for many more in this series as Chris takes us on his passion-driven journey into the heart of the Assembly language.

We are very proud of STAP's first Volunteer Archivist. By taking on the task of archiving the Roger Wagner and Assembly Lines content in the 48 issues of Softalk, Chris is doing an amazing job of reinvigorating interest in Assembly Language programming. We are pleased to have him on board and look forward to more amazing contributions from Chris as the Softalk Apple Project continues to evolve.

Assembly Lines: The Complete Book

Chris Torrence — Mon, 22 Dec 2014 17:45:30 +0000

I am very excited to announce that Assembly Lines: The Complete Book is now available as a hardcover from Lulu press. Roger Wagner’s Assembly Lines articles originally appeared in Softalk magazine from October 1980 to June 1983. The first fifteen articles were reprinted in 1982 in Assembly Lines: The Book. Now, for the first time, all thirty-three articles are available in one complete volume. This edition also contains all of the appendices from the original book as well as new appendices on the 65C02, zero-page memory usage, and a beginner’s guide to using the Merlin Assembler. The book is designed for students of all ages: the nostalgic programmer enjoying the retro revolution, the newcomer interested in learning low-level assembly coding, or the embedded systems developer using the latest 65C02 chips from Western Design Center.

The book will be available in a few weeks from Amazon and other online retailers. I am currently working on an eBook version, which I hope to have finished in early 2015.

You can download disk images of all of the assembly-language programs from the Asimov ftp site in the pub/apple_II/images/programming/assembler directory:

AssemblyLinesWagnerDOS1.DSK contains DOS versions for chapters 1-17
AssemblyLinesWagnerDOS2.DSK contains DOS versions for chapters 18-30
AssemblyLinesWagnerProDOS1.DSK contains ProDOS versions for chapters 1-17
AssemblyLinesWagnerProDOS2.DSK contains ProDOS versions for chapters 18-30

Note that a few of the programs (in the DOS chapter) will only work in DOS, not ProDOS.

To create your own programs, you can download a copy of the Merlin assembler from the same directory:

merlin/Merlin-8 v2.48 (DOS 3.3).dsk
merlin/Merlin-8 v2.58 (ProDOS) Disk 1-2.dsk

These disk images can be opened in any of the Apple II emulators, such as Virtual ][ for the Mac or AppleWin for Windows. You could also use ADTPro to transfer the disk images to an actual Apple II.

I would love to get your feedback on the new book. If you have any questions or comments on the new book or the original articles, please post them below.

Here's a video explaining more about how the book was created...

Assembly Lines by Roger Wagner - Part 16

Chris Torrence — Wed, 14 May 2014 00:54:01 +0000

Assembly Lines, Part 16 was first published in Softalk in January 1982. This was the first article in what was supposed to be "Volume 2" of "Assembly Lines: The Book". Unfortunately, Volume 2 remained unpublished when Softalk went bankrupt in August 1984. Part 16 is actually the first of three parts where Roger Wagner explains how to interface assembly language with Applesoft Basic.

Everyone's Machine Language Guide, Part 16

One useful application of machine language programming is in the enhancement of your existing Applesoft programs. Some people are inclined to write all their programs in machine language, but it may be more efficient on occasion to write “hybrids”—programs that are a combination of Applesoft and machine language. In this way, particular functions can be done by the operating system best suited to the particular task.

If you had to write a short program to store ten names, it would be best to do it in Applesoft:

10 FOR I = 1 TO 10
20 INPUT N$(l)
30 NEXT I

This is much simpler than the equivalent program in machine language. In cases where neither speed nor program size is a concern, Applesoft is a completely acceptable solution.

However, if you had to sort a thousand names, speed would become a concern, and it would be worth considering whether the job could best be done in machine language.

If you have ever done a call in one of your Basic programs, then you have already combined Applesoft with machine code. For example:

10 HOME
20 PRINT "THIS IS A TEST"
30 PRINT "THIS IS STILL A TEST"
40 GET A$
50 VTAB 1: HTAB 5: CALL-958

In this program, a line of text is printed on the screen. After you press a key, all text on the screen after the first word “THIS” is cleared.

Now although it might be possible to accomplish the same effect in Applesoft by printing many blank lines, it would not be as fast or as efficient in terms of code as the call -958.

In executing the above program, the Applesoft interpreter goes along carrying out your instructions until it reaches the call statement. At that point a JSR is done to the address indicated by the call. When the final RTS is encountered, control returns to the Basic program. In between, however, you can do anything you’d like!

Calling routines is hardly complicated enough to warrant an entire article on the subject. The real questions are, how do you pass data back and forth between the two programs, and how can the problem of handling that data be made easier for the machine language program?

Simple Interfacing. The easiest way to pass data to a machine language routine is simply to poke the appropriate values into unused memory locations, and then retrieve them when you get to your machine language routine. To illustrate this, let’s resurrect the tone routine from the May 1981 issue of Softalk.

To use this, assemble the code and place the final object code at $300. Then enter the accompanying Applesoft program.

1 **********************
2 * SOUND ROUTINE #3A *
3 **********************
4 *
5 *
6 OBJ $300
7 ORG $300
8 *
9 PITCH EQU $06
10 DURATION EQU $07
11 SPKR EQU $C030
12 *
13 BEGIN LDX DURATION
14 LOOP LDY PITCH
15 LDA SPKR
16 DELAY DEY
17 BNE DELAY
18 DRTN DEX
19 BNE LOOP
20 EXIT RTS

From the Monitor, this will appear as:

*300L
0300- A6 07 LDX $07
0302- A4 06 LDY $06
0304- AD 30 CO LDA $C030
0307- 88 DEY
0308- DO FD BNE $0307
030A- CA DEX
030B- DO F5 BNE $0302
030D- 60 RTS

This Applesoft program is used to call it:

10 INPUT "PITCH, DURATION? ";P,D 20 POKE 6,P: POKE 7,D 30 CALL 768 40 PRINT 50 GOTO 10

The Applesoft program works by first requesting values for the pitch and duration of the tone from the user. These values are then poked into locations 6 and 7 and the tone routine called. The tone routine uses these values to produce the desired sound, and then returns to the calling program for another round.

This technique works fine for limited applications. Having to poke all the desired parameters into various comers of memory is not flexible, and strings are nearly impossible. There must be an alternative.

The Internal Structure of Applesoft. If you’ve been following this series for long, you’ve no doubt figured out by now that I’m a great believer in using routines already present in the Apple where possible, to accomplish a particular task. Since routines already exist in Applesoft for processing variables directly, why not use them?

To answer this, we must take a brief detour to outline how Applesoft actually “runs” a program.

Consider this simple program:

10 HOME: PRINT "HELLO"
20 END

After you’ve entered this into the computer, typing list should reproduce the listing given here. An interesting question arises: “How does the computer actually store, and then later execute, this program?”

To answer that, we’ll have to go to the Monitor and examine the program data directly.

The first question to answer is, exactly where in the computer is the program stored? This can be found by entering the Monitor and typing in: 67 68 AF B0 and pressing return.

The computer should respond with:

67- 01
68- 08
AF- 18
B0- 08

The first pair of numbers is the pointer for the program beginning, bytes reversed of course. They indicate that the program starts at $801. The second pair is the program end pointer, and they show it ends at $818. Using this information let’s examine the program data by typing in:

801L

You should get:

*801L
0801- 10 08 BPL $080B
0803- 0A ASL
0804- 00 BRK
0805- 97 ???
0806- 3A ???
0807- BA TSX
0808- 22 ???
0809- 48 PHA
080A- 45 4C EOR #$4C
080C- 4C 4F 22 JMP $224F
080F- 00 BRK
0810- 16 08 ASL $08,X
0812- 14 ???
0813- 00 BRK
0814- 80 ???
0815- 00 BRK
0816- 00 BRK
0817- 00 BRK
0818- F9 A2 00 SBC $00A2,Y
08IB- 86 FE STX $FE

This is obviously not directly executable code. Now type in: 801.818

This will give:

0801- 10 08 0A 00 97 3A BA
0808- 22 48 45 4C 4C 4F 22 00
0810- 16 08 14 00 80 00 00 00
0818- 8C

To understand this, let’s break it down one section at a time. When the Apple stores a line of Basic, it encodes each keyword as a single byte token. Thus the world print is stored as a $BA. This does wonders for conserving space. In addition, there is some basic overhead associated with packaging the line, namely a byte to signify the end of the line, and a few bytes at the beginning of each line to hold information related to the length of the line, and also the line number itself.

To be more specific:

0801- 10 08 0A 00 97 3A BA
0808- 22 48 45 4C 4C 4F 22 00
0810- 16 08 14 00 80 00 00 000
818- 8C

The first two bytes of every line of an Applesoft program are an index to the address of the beginning of the next line. At $801,802 we find the address $810 (bytes reversed). This is where line 20 starts. At $810 we find the address $816. This is where the next line would start if there were one. The double 00 at $816 tells Applesoft that this is the end of the Basic listing. It is important to realize that the 00 00 end of the Applesoft program usually, but not always, corresponds to the contents of $AF,B0. It is possible to hide machine language code between the end of the line data and the actual end as indicated by $AF,B0—but more on that later.

The next information within a line is the line number itself:

0801- 10 08 0A 00 97 3A BA
0808- 22 48 45 4C 4C 4F 22 00
0810- 16 08 14 00 80 00 00 00
0818- 8C

The 0A 00 is the two-byte form of the number ten, the line number of the first line of the Applesoft program. Likewise, the 14 00 is the data for the line number twenty. The bytes are again reversed. After these four bytes, we see the actual tokens for each line.

0801- 10 08 0A 00 97 3A BA
0808- 22 48 45 4C 4C 4F 22 00
0810- 16 08 14 00 80 00 00 00
0818- 8C

All bytes with a value of $80 or greater are Applesoft keywords in token form. Bytes less than $80 represent normal ASCII data (letters of the alphabet, for example). Examining the data here we see a $97 followed by $3A. $97 is the token for home, and $3A the colon. Next, $BA is the token for print. This is followed by the quote ($22) and the text for HELLO (48 45 4C 4C 4F) and the closing quote ($22). Last of all, the 00 indicates the end of the line.

In line number twenty, the $80 is the token for end. As before, the line is terminated with a 00.

When a program is executed, the interpreter scans through the data. Each time it encounters a token, such as the print token, it looks up the value in a table to see what action should be taken. In the case of print, this would be to output the characters following the token, namely “HELLO”.

This constant translation is the reason for the use of the term interpreter for Applesoft Basic.

Machine code on the other hand is directly executable by the 6502 microprocessor and hence is much faster, since no table lookups are required.

In Applesoft, a syntax error is generated whenever a series of tokens is encountered that is not consistent with what the interpreter expects to find.

Passing Variables. So, back to the point of all this. The key to passing variables to your own machine language routines is to work with Applesoft in terms of routines already present in the machine. One of the simplest methods was described in the October 1981 issue of Softalk, wherein a given variable is the very first one defined in your program (see the input routine). This is okay, but rather restrictive. A better way is to name the variable you’re dealing with right in the call statement.

The important points here are two components of the Applesoft interpreter: TXTPTR and CHRGET (and related routines).

TXTPTR is the two-byte pointer ($B8, B9) that points to the next token to be analyzed. CHRGET ($B1) is a very short routine that actually resides on the zero page and that reads a given token into the accumulator. In addition to occasionally being called directly, many other routines used CHRGET to process a string of data in an Applesoft program line.

Here then is the revised tone routine :

1 **********************
2 * SOUND ROUTINE #3B *
3 **********************
4 *
5 *
6 OBJ $300
7 ORG $300
8 *
9 PITCH EQU $06
10 DURATION EQU $07
11 SPKR EQU $C030
12 *
13 COMBYTE EQU $E74C
14 *
15 ENTRY JSR COMBYTE
16 STX PITCH
17 JSR COMBYTE
18 STX DURATION
19 *
20 BEGIN LDX DURATION
21 LOOP LDY PITCH
22 LDA SPKR
23 DELAY DEY
24 BNE DELAY
25 DRTN DEX
26 BNE LOOP
27 EXIT RTS

This would list from the Monitor as:

*300L

0300- 20 4C E7 JSR $E74C
0303- 86 06 STX $06
0305- 20 4C E7 JSR $E74C
0308- 86 07 STX $07
030A- A6 07 LDX $07
030C- A4 06 LDY $06
030E- AD 30 CO LDA $C030
0311- 88 DEY
0312- DO FD BNE $0311
0314- CA DEX
0315- DO F5 BNE $030C
0317- 60 RTS

The Applesoft calling program would then be revised to read:

10 INPUT "PITCH DURATION? ",P,D
20 CALL 768,P,D
30 PRINT
40 GOTO 10

This is a much more elegant way of passing the values and also requires no miscellaneous memory locations as such (although for purposes of simplicity the tone routine itself still uses the same zero page locations.)

The secret to the new technique is the use of the routine COMBYTE ($E74C). This is an Applesoft routine which checks for a comma and then returns a value between $00 and $FF (0-255) in the X register.

It is normally used for evaluating pokes, hcolor=t and so forth, but does the job very nicely here. It also leaves TXTPTR pointing to the end of the line (or a colon if there was one) by using CHRGET to advance TXTPR appropriate to the number of characters following each comma. Note also that any legal expression--such as (X-5)/2--can be used to pass the data.

To verify the importance of managing TXTPTR, try putting a simple RTS ($60) at $300. Calling this you will get a SYNTAX ERROR, since upon return, Applesoft’s TXTPTR will be on the first comma, and the phrase “,P,D” is not a legal Applesoft expression.

Now what about two-byte quantities? To do this, a number of other routines are used. For example, this routine will do the equivalent of a two-byte pointer poke. Suppose for instance you wanted to store the bytes for the address $9600 at locations $1000, 1001. Normally in Applesoft you would do it like this:

50 POKE 4096,0: POKE 4097,150

Where 4096 and 4097 are the decimal equivalents of $1000 and $1001 and 0 and 150 are the low-order and high-order bytes for the address $9600 ($96 = 150, $00 = 0).

A more convenient approach might be like this:

50 CALL 768, 4096, 38400

or perhaps:

50 CALL 768, A, V

The routine for this would be:

1 **************************
2 * POINTER SET UP ROUTINE *
3 **************************
4 *
5 *
6 OBJ $300
7 ORG $300
8 *
9 CHKCOM EQU $DEBE
10 FRMNUM EQU $DD67
11 GETADR EQU $E752
12 LINNUM EQU $50 ; ($50,51)
13 *
14 PTR EQU $3C
15 *
16 ENTRY JSR CHKCOM
17 JSR FRMNUM; EVAL FORMULA
18 JSR GETADR ; PUT FAC INTO LINNUM
19 LDA LINNUM
20 STA PTR
21 LDA LINNUM+1
22 STA PTRH-1
23 *
24 JSR CHKCOM
25 JSR FRMNUM
26 JSR GETADR
27 *
28 LDY #$00
29 LDA LINNUM
30 STA (PTR),Y
31 INY
32 LDA LINNUM+1
33 STA (PTR),Y
34 *
35 DONE RTS

which will list from the Monitor as:

*300L

0300- 20 BE DE JSR $DEBE
0303- 20 67 DD JSR $DD67
0306- 20 52 E7 JSR $E752
0309- A5 50 LDA $50
030B- 85 3C STA $3C
030D- A5 51 LDA $51
030F- 85 3D STA $3D
0311- 20 BE DE JSR $DEBE
0314- 20 67 DD JSR $DD67
0317- 20 52 E7 JSR $E752
031 A- AO 00 LDY #$00
031C- A5 50 LDA $50
031E- 91 3C STA ($3C),Y
0320- C8 INY
0321- A5 51 LDA $51
0323- 91 3C STA ($3C),Y
0325- 60 RTS

The special items in this routine include CHKCOM, a syntax-checking routine that serves two purposes. First it verifies that a command follows the call address, and secondly it advances TXTPTR to point to the first byte of the expression immediately following the comma. If a comma is not found, a syntax error is generated.

FRMNUM is a routine that evaluates any expression and puts the real floating-point number result into Applesoft’s floating-point accumulator, usually called FAC. This is a six-byte pseudo register ($97-9C) used to hold the floating-point representation of a number. It includes such nifties as the exponential magnitude of the number and the equivalent of the digits of the logarithm of the number stored.

At this stage you’d have to be something of a masochist to want to deal with the number in its current form, so the next step is used to convert it into a two-byte integer.

GETADR does this by putting the two-byte result into LINNUM, LINNUM+1 ($50,51).

Even if this is not exactly an in-depth explanation of all the most precise details of the operation, the bottom line is that the three JSRs (CHKCOM, FRMNUM, and GETADR) will always end up with the low-order and high-order bytes of whatever expression follows a comma in LINNUM and LINNUM+1.

These simple subroutines should be quite adequate for many applications. Next month, however, we’ll look at string passing, some of the various other routines available, and how to pass data back to the calling Applesoft program.

Assembly Lines by Roger Wagner - Part 1

Chris Torrence — Thu, 24 Apr 2014 07:45:03 +0000

Everyone's Machine Language Guide, Part 1

NOTE: This is the first of Roger Wagner's Assembly Lines column which began its illustrious run in the October, 1980 issue. The OCR and reprint processing of this article was made possible in part by the support of STAP Project Backer, Chris Torrence. Chris is a currently working (with the support and interest of Roger) on "Roger Wagner's Assembly Lines: The Missing Volume" (or whatever it will be called). This new publication will bring together the Assembly Lines columns from Softalk magazine that did not make it to book form prior to the end of Softalk Publishing.

One often gets the impression that programming in assembly language is some very difficult and obscure technique used only by "those advanced programmers." As it happens, assembly language is merely different, and if you have successfully used Integer or Applesoft Basic to do some programming, there's no reason why you can't use assembly language to your advantage in your own programs.

Roger Wagner, president of Southwestern Data Systems, authored Apple Doc, the Programmer’s Utility Package, which was the first Applesoft renumber program; the Correspondent; and Roger’s Easel, which he refers to as “my sleeper program.” Before he discovered the Apple, Roger taught math and science at Mountain Empire High School.

This series will take a rather unorthodox approach to explaining assembly programming. Since you are presumably somewhat familiar with Basic, we will draw many parallels between various assembly language techniques and their Basic counterparts.

An important factor in learning anything new is a familiar framework into which to fit the new information. Your knowledge of Basic will provide that framework.

We will also try to describe initially only those technical details of the microprocessor operations as are needed to accomplish our immediate goals. The rest will be filled in as we move to more involved techniques.

The first of the technical details is the general structure, or architecture, of the Apple itself. The heart of the system is the 6502 microprocessor. This device operates by scanning through a given range of memory addresses. At each location it finds some particular value. Depending on what it finds, it executes a given operation. This operation could be adding some numbers, storing a number somewhere, or any of a variety of other tasks. These interpreted values are often called opcodes.

In the old days, programmers would ply their trade by loading each opcode, one at a time, into successive memory locations. After a while, someone invented an easier way, using short abbreviated words (called mnemonics) for the operations. The computer would then figure out which values to use and supervise the storing of these values in consecutive memory locations. This wonder is what is generally called an assembler. It allows us to interact with the computer in a more natural way. In fact, Basic itself can be thought of as an extreme case of the assembler. We just use words like PRINT and INPUT to describe a whole set of the operations needed to accomplish our desired action.

In some ways, assembly language is even easier than Basic. There are only fifty-five commands to learn, as opposed to more than one hundred in Basic. Also, machine code runs very fast and generally is more compact in the amount of memory needed to carry out a given operation. This opens up many possibilities for programs that would either run too slowly or take up too much room in Basic.

How the 6502 Talks to Itself. Probably the most unfamiliar part of dealing with the Apple in regard to machine level operations is the way addresses and numbers in general are treated. Unless you lead an unusually charmed life, at some point in your dealings with your Apple you have had it abruptly stop what it was doing and show you something like this:

8BF2- A=03 X=9D Y=00 P=36 S = F2

This occurs when some machine level process suddenly encounters a break in its operation, usually from an unwanted modification of memory. Believe it or not, the Apple is actually trying to tell us something here. Unfortunately, it's rather like being a tourist and having someone shout, "Alaete quet beideggen!" at you.* It doesn't mean much unless you know the lingo, so to speak...

* "Watch where you're stepping, you nerd!" (in case you're not familiar with this particular dialect.)

What has happened is that the Apple has encountered the break we mentioned, and in the process of recovering, has provided us with some information as to where the break occurred and what the status of the computer was at that crucial moment. This is rather like the last cryptic words from the recently departed.

The leftmost part of the message is of great importance. This is where the break in the operation occurred. Now, just what do we mean by the word where? Remember all that concern about whether you have a 16K, 32K, or 48K Apple? The concern was about the number of usable memory locations in your machine. This idea becomes clearer through the use of a memory map, such as the one shown in figure 1.

Inside the Apple are many electronic units that will store number values we give them. By numbering these units, we give each one a unique address. This way we can specify any particular unit or memory location, either to inquire about its contents or to alter those contents by storing a new number there.

In the Apple there are a total of 65,536 of these memory locations (incidentally called bytes). The chart gives us a way of graphically representing each possible spot in the computer.

When the computer shows us an address, it does not do it in a way similar to the numbers on the left of the memory map, but rather in the fashion of the ones on the right. You may well remark here: "I didn't know 'BFFF' was a number; it sounds more like a wet sneaker…"

To understand this notation, let's see how the 6502 counts. If we place our byte at the first available location, it's address is $0. The dollar sign is used in this case to show that we are not counting in our familiar decimal notation, but rather in hexadecimal (base sixteen) notation, usually called "hex," which is how the computer displays and accepts data at the monitor level.

After byte $0, successive locations are labeled in the usual pattern up to $9. At this point the computer uses the characters A through F for the next six locations. The location right after $F is $10. This is not to be confused with "ten." It represents the decimal number sixteen. The pattern repeats itself as in usual counting with:

$10, 11, 12, 13... 19, 1A, 1B...1E, 1F, 20

This method should be accepted just as a fact of life with the Apple for the time being. If you really can't stand not knowing the details of the reasoning behind this scheme, there are quite a number of books on number theory and number bases that you might peruse. Many books on assembly language also spend a chapter or two on this. It will be sufficient for our purposes, though, just to understand that $1F is as legitimate a number as 31.

The hex number $FF (255) is the largest value a single byte can hold. A block of 256 bytes (for instance $0 to $FF) is often called a page of memory. In figure 2, all the addresses from $0 to $FF are shown in block b. Four of these blocks together, as in c, make up 1K of memory. As you can see, there are actually 1,024 bytes in 1K. Thus a 48K machine actually has 49,050 bytes of RAM.

Block d of figure 2 shows the Apple's entire range again. If you do not have a full 48K of memory, then the missing range will just appear to hold a constant value (usually $FF), and you will not be able to store any particular value there.

The range from $C000 to $FFFF is all reserved for hardware. This means that any data stored in this range is of a permanent nature and cannot be altered by the user. Some areas are actually a physical connection to things like the speaker or game switches. Others, like $E000 to $FFFF are filled in by the chips in the machine called ROMs.

ROM stands for read only memory. These chips hold the machine language routines that make up either Applesoft or Integer, depending on whether you have an Apple Plus or the standard model. One of them is also the monitor, which is what initializes the Apple when it is first turned on so you can talk to it, and also handles your input when you're at the monitor level.

Now that break message should have at least a little meaning.

8BF2- A = 03 X = 9D Y = 00 P=36 S = F2

The 8BF2 is an address in memory. Rather like a "catch-22," it says that the break actually occurred at the address given minus two (8BF2 - 2 = 8BF0). For reasons that aren't worth going into here, the monitor always prints out a break address in this plus-two fashion.

What about the rest of the message? Consider the next three items:

A = 03 X = 9D Y = 00

The 6502, in addition to being able to address the various memory locations in the Apple, has a number of internal registers. These are units inside the 6502 itself that can store a given number value, and they are individually addressable in much the same way memory is. The difference is that instead of being given a hexadecimal address, they are called the x-register, the y-register, and the accumulator. In our error message, we are being told the status of these three registers at the break.

Figure 3 summarizes what we know so far. The 6502 is a microprocessor chip that has the ability to scan through a given range of memory, which we will generally specify by using hex notation for the addresses. Depending on the values it finds in each location as it scans through, it will perform various operations. As an additional feature to its operation, it has a number of internal registers, namely the x and y registers, and the accumulator. Memory-related operations are best done by entering the monitor level of the Apple (usually with a CALL-151 or RESET) and using the various routines available to us.

Next issue, we'll look at what an assembler actually does, and specifically how to use the Apple's mini-assembler. This assembler is present in any standard Apple with Integer Basic, or in an Apple II Plus with the Integer Basic firmware card. If you don't have either of these, I recommend getting one of the many assembler software packages available. If you're on a limited budget, there is a free one in many user group libraries called by a variety of names including Randy's Weekend Assembler, Ted II, and Assembler 3. 2. Get in touch with the librarian for your local group if you don't already have a copy. Otherwise, see your local computer store and get their advice on a good assembler. There are many opinions and I won't go into a review here.

In the meantime, you might also look at page 49 in the most recent Apple II Reference Manual. It has an excellent discussion of the monitor commands and also of the mini-assember.

Meet you here next issue!