Apple Assembly Line
Volume 7 -- Issue 6 March 1987

In This Issue...

Sorry we haven't written sooner...

This really is the March issue you're receiving sometime in the middle of April, and there's no blaming the Post Office. We've had a surplus of other work lately and a shortage of AAL inspiration. (That's a hint: you can send in articles and programs and help us and all AAL readers. We are especially interested in good short items about exploring the IIgs.) We were almost back on track by last December, but slipped again. We expect to catch up across the next several months....

About those Disk Subscriptions

When you subscribe to the Apple Assembly Line Monthly Disks you not only receive all the source code from an issue, you now also get the text of all that month's articles (in DOS 3.3 Text files.) We know of six blind subscribers who really appreciate this format, and there may be more of you who are interested. Our thanks to Larry Skutchan, of the American Printing House for the Blind, for prompting us to add this service.

Some Bugs in Apple's ProDOS Version 1.3 Bob Sander-Cederlof

Apple recently released version 1.3 of ProDOS, and sent copies to all licensees. We started sending it out with the ProDOS version of the S-C Macro Assembler. But last week (around March 16th) we received a letter from Apple "recalling" version 1.3. It has two serious problems.

First, there is a "BRA" (BRanch Always) opcode in it. This means version 1.3 will not operate in an older Apple with only a 6502 microprocessor. If you have a 65C02 or 65802 or 65816, no problem here. You are safe in a IIgs, //c, or enhanced //e. You are also safe if you have upgraded the cpu chip yourself in an older machine. That offending instruction could just as well be changed to a BEQ opcode, because that would always branch in this case. With that change the 6502 machines work fine.

Second, when the Apple experts tried to implement the patch developed in Australia and reported first by Tom Weishaar in "Open Apple" to fix an elusive disk-trashing problem, they didn't do it right. This is the same fix I reported in the November AAL, page 13. (Turns out I didn't report it right either, because I overlooked one part of the patch. More on this below.) The way Apple did it causes severe problems with two-drive systems. When you are accessing drive two, version 1.3 keeps switching back to drive 1. If you try to use FILER to copy a volume from drive 1 to a blank disk in drive 2, and if you remember to write-protect the disk in drive 1, FILER will hang up with an I/O ERROR after initializing the drive 2 disk. FILER evidently applies the drive 1 write-protect status to drive 2, and gives up. I don't even want to experiment without having drive 1 write-protected! On the other hand, if you copy from drive 2 to drive 1 it works, but it takes a lot longer than it should to read each segment from the source disk in drive 2.

Both bugs can be fixed by rather simple patches. Boot up PRODOS, into either BAISC.SYSTEM or the S-C Macro Assembler. Then load the PRODOS file, with "BLOAD PRODOS,TSYS,A$2000". Then get into the monitor with "MNTR" from S-C Macro Assembler or "CALL-151" from BASIC.SYSTEM. Type the following patches:

       4CCD:F0         (was 80, changing BRA to BEQ)
       5204:BD 8E C0   (was EA EA EA)
       58C3:BD 80 C0 BD 82 C0 BD 84 C0 BD 86 C0

Then get back into the system by typing "3D0G", and save the new version with "BSAVE PRODOS,TSYS,A$2000".

The third patching line above replaces Apple's flawed loop which walked on too many soft-switches. Apple's loop does a LDA from C080, C082, C084, and C086; this is correct. It also does it from C088, C08A, C08C, and C08E. This is not correct. It turns off the motor and selects drive 1. The only correct one among this group of four was C08E, intended to be sure the selected drive is in read mode.

 Old Code        Apple's Loop      My Patch
-----------    ---------------    -----------
STA $C080,X       LDY #8          LDA $C080,X
STA $C082,X    .1 LDA $C080,X     LDA $C082,X
STA $C084,X       INX             LDA $C084,X
STA $C086,X       INX             LDA $C086,X
                  BNE .1

My patch puts the C08E load where Tom's Australian-connection originally put it, over some NOPs which immediately followed the JSR to the code shown above.

Now about my incomplete patch to version 1.1.1 from last November. I omitted the "LDA $C08E,X", which gets patched at location $5004 in this version. I also mis-typed the address for the other patches as going at $56D3 when they actually belong at $56C3. So, in version 1.1.1, following the same load-patch-save sequence above, the patches are:

       5004:BD 8E C0   (was EA EA EA)
       56C3:BD 80 C0 BD 82 C0 BD 84 C0 BD
               (changing 9D's to BD's)

Version 1.4 is due out soon, and we trust Apple will have it all right this time. Still, I am getting skittish.

Meanwhile, unless you are using a IIgs, you may wish to stick with version 1.1.1. The only real advantage the newer versions have is automatic recognition of the IIgs clock-calendar chip. You don't need this feature if you are not running in a IIgs.

Notes on the IIgs Monitor Sandy Mossberg

Bob's article "New Features in Apple //gs Monitor" in the January 1987 issue of AAL was interesting and useful, but I have several corrections. I also have two nice examples for the U-command, which allows you to call tools from the monitor.

First, I noticed Bob said that the Change Cursor Command is Control-6 followed by the new cursor character. While that works on his keyboard, the actual character is Control-Shift-6. Apparently Bob's IIgs, which is a //e box and keyboard with a IIgs motherboard, accepts Control-6 and Control-Shift-6 to generate the same code ($9E). In "true" ASCII, this key is really known as Control-Shift-N. If you remember the old Apple II or II+ keyboards, which were modeled after teletypes, the carat character (ASCII $DE) was generated by a Shift-N; likewise, a Control-Shift-N generated the ASCII code $9E. On the //e, //c, and IIgs the carat has been moved to the Shift-6 position. Several other characters were moved at the same time, allowing the all of the alphabet keys could use the Shift Key to control lower- and upper-case input.

Second, Bob apparently misunderstood the meaning of the Flip ASCII capability. When you are entering data into RAM with the "addr:" command, or specifying patterns for the "\pattern\<addr.addrP" search command, you can enter ASCII strings or flip ASCII strings.

Normal strings are entered by typing any number of characters between quotation marks. The status of the ASCII FILTER MASK determines whether the string is low-ASCII or high-ASCII. You control the filter mask using the monitor "=" command: type "7F=F" before entering strings you want in low-ASCII, or "FF=F" before strings in high-ASCII.

Flipped strings can be from one to four characters. The characters are typed between apostrophes, and will be stored in RAM or used as a pattern in REVERSE ORDER. Again, the characters will be in either low- or high-ASCII depending on the state of the filter mask. For example:

00/0300:C1 C2 C3 C4 C5 C6 C7 C8-ABCDEFGH

00/0300:41 42 43 44 45 46 47 48-ABCDEFGH

*300:'ABCD' 'EFGH'     (note filter still 7F)
00/0300:44 43 42 41 48 47 46 45-DCBAHGFE

*FF=F 300:'ABC' 'MNO' 'ST'
00/0300:C3 C2 C1 CF CE CD D4 D3:CBAONMTS

The monitor "U" command gives you the ability to call tools in the various tool sets. In particulary, I have worked out the method for calling the two time routines in the Miscellaneous Tool Set.

Call ReadTimeHex (tool set $03, function $0D)

     *\08 08 00 00 00 00 00 00 00 00 0D 03\U

     Tool Error-> 0000
     06 1F 17 57 1B 02 00 07

Interpretation of Input:

     08 = 8 bytes on stack
     08 = 8 bytes off stack
     00...00 = 8 zero bytes constitute parms
     0D = function number in toolset
     03 = toolset number

Interpretation of Output:

     Error 0000 means NO ERROR
     06 = 6 seconds
     1F = 31 minutes
     16 = 22 hours
     57 = year 1987
     17 = 24th day (0=first day)
     02 = 3rd month (0=first month)
     00 = null
     03 = 3rd day of week (1=Sunday, first day)

Call ReadASCIITime (tool set $03, function $0F):

     *\04 00 00 00 03 00 0F 03\U 300.317

     Tool Error-> 0000
     00/0300:A0 B4 AF A0 B1 AF B8 B7: 4/ 1/87
     00/0308:A0 A0 B9 BA B1 B3 BA B0:  9:13:0
     00/0310:B3 A0 C1 CD FF 00 00 FF:3 AM....

Interpretation of Input:

     04 = 4 bytes on stack
     00 = 0 bytes off stack
     00 00 03 00 = buffer address at 00/0300
     0F = function number in toolset
     03 = toolset number

Interpretation of Output:

     Error 0000 means NO ERROR
     300.313 has string " 4/ 1/87  9:13:03 AM"

Beagle Compiler Review Bill Morgan

Ever since ProDOS first appeared in 1983 people have been asking us about an Applesoft compiler that would run under that system, but we've had to tell them that there was no such thing. Well the good folks at Beagle Bros have remedied that situation by bringing us The Beagle Compiler, by Alan Bird.

This isn't a true native code compiler, it's more of a very high-speed interpreter. As a result, the compiled program is usually smaller than the original source Applesoft program. On the other hand you lose some memory because of the extra space taken by the compiler's runtime system. The compiler and runtime system together take about 11K, but you can cut that figure in half if you only need the runtime portion. If your program will not fit the first time you try, you can probably take advantage of the compiler's ability to use //e or //c auxiliary memory for storage of arrays and strings.

Beagle claims a 2 to 15 times speedup of a program, depending on what operations are most common. They say that string and variable manipulations show the most improvement, while heavy floating point calculations aren't affected at all. The compiled code automatically uses integer arithmetic whenever possible, thereby avoiding a lot of floating point arithmetic in most programs.

There are several programs in the package: COMPILER.SYSTEM is the normal runtime interpreter, replacing and extending BASIC.SYSTEM. COMPILER processes an Applesoft program file into its high-speed version. AUX.SLOT.SYSTEM & APPLEMEM.SYSTEM (included with version 2.0 and beyond) are versions of COMPILER.SYSTEM that take advantage of memory expansion cards for array and string storage. You have to have one of the SYSTEM files to execute a compiled program, but you can distribute these files with your product "after paying a very reasonable licensing fee."

The Beagle Compiler is made to be very simple to use. After booting into the SYSTEM your STARTUP program can execute COMPILER. Then you just need to type RUN <filename> to load your file, compile it, and start execution. Once you have a finished program you can type COMPILE <source file>,<object file> to produce a disk file of the compiled code. To execute that file you no longer need COMPILER, just one of the SYSTEM files.

As supplied, the compiler uses the standard Applesoft INPUT, but they also include an "INPUT anything" routine that allows commas and semicolons. There is also a FAST.HPLOT routine available that noticeably speeds up HPLOT, but at the cost of an extra 1K of memory for the runtime code. A special SLOW.PDL patch can slow down game paddle reading so you always get the correct reading.

This compiler, unlike other Applesoft compilers we've seen, allows full use of &-routines, including parameter passing. An &-call without parameters will work just fine as it's written; one with parameters will need to be rewritten to match the compiler's syntax and evaluation needs, but the new procedures are easy to use and very well documented. It's not immediately clear how well an "&-interpreter" will work with this approach.

Beagle does an excellent job of documenting how a machine language program can get along with a compiled program. They list all the keyword entry points as well as the entries to many useful utility routines, including string and numeric output, error handling, string allocation and handling, variable assigment and evaluation, and many others.

They also provide complete details of the unique method the compiler uses to store and access its variables. All variables are referred to by a one byte index, so there can be up to 256 different variables or arrays. By the way, this really is an upper limit on the number of variables. For some reason there is no clear statement in the manual saying so, but if you have more than 256 different variable names it cannot be compiled. The single-byte variable index is used through six different pointers to access the values. The six pointers are:

     $78  Variable Type (array, string, numeric, FN, integer)

     $7A  Val1 -- array: LSB of header address
                  string: LSB of string address
                  FP: non-zero flags FP, 1st byte of value
                  integer: a zero here flags integer

     $7C  Val2 -- array: MSB of header address
                  string: MSB of string address
                  FP: 2nd byte of value
                  integer: LSB of value

     $7E  Val3 -- array: LSB of array address
                  FP: 3rd byte of value
                  integer: MSB of value

     $80  val4 -- array: MSB of array address
                  FP: 4th byte of value

     $82  Val5 -- array: number of dimensions, 0 if
                  FP: 5th byte of value

This approach to dealing with variables is one of the main keys to the Beagle Compiler's speed. Another great factor in the speed is that GOTO and GOSUB can point to absolute addresses in RAM, rather than to a line number that must be searched for during execution.

Here's an example of a short Applesoft program along with a hex dump of its compiled result. (When COMPILER.SYSTEM finishes executing a program it trashes its pointers, so that's why I ended my little program with a CALL-151 to get us into the Monitor with everything intact.)

     10 D$ = CHR$(4):BUFFER = 4096:REM $1000
     20 ARGUMENT = 20
     30 RESULT = BUFFER / 2 + ARGUMENT * 3.3
     50 CALL -151

     0078-43 08 48 08 4D 08 52 08 57 08 5C 08

     0800-00 00 00 11 56 8D 05 40 00 42 00 00 00 00 00 00
     0810-00 34 00 B6 94 04 14 01 96 00 10 14 02 94 20 14
     0820-03 A8 AE 9C 01 94 02 AC 9C 02 98 82 53 33 33 33
     0830-34 04 9A 08 41 41 52 44 56 41 52 4B 6E 96 69 FF
     0840-12 FF 12 40 00 00 00 40 FE 00 00 8C 33 65 00 20
     0850-06 08 00 10 00 99 00 00 00 00 99 00 00 00 00 9A

The compiled code for the program apparently begins at $0810, and continues to $0842. In comparison, the original Applesoft program (not counting 35 bytes used to store the variables) ran from $0800 through $0875. There are five variables, so the six tables which begin at $0843 are each five bytes long. Using the table which comes in the Compiler manual I was able to "decompile" the compiled code as follows:

     00    Initialize and run program

     34    Assign value to simple string variable
     00    1st Variable (D$)
     B6    CHR$
     94 04 One-byte integer (04)

     14    Assign value to simple numeric variable
     01    2nd Variable (BUFFER)
     96 00 10  Two-byte integer ($1000=4096)

     14    Assign value to simple numeric variable
     02    3rd variable (ARGUMENT)
     94 20 One-byte integer ($20=32)

           RESULT = BUFFER/2 + ARGUMENT*3.3
     14    Assign value to simple numeric variable
     03    4th variable (RESULT)
     A8    addition    [Notice the Polish form here]
     AE       division
     9C 01       get value of 2nd variable (BUFFER)
     94 02       One-byte integer (2)
     AC       Multiplication
     9C 02       get value of 3rd variable (ARGUMENT)
     98          Five-byte floating point constant follows
     82 53 33 33 33   Floating point constant (3.3)

     34 04  Assign value to 4th variable (MYSTRING$)
     9A    A string constant follows...
     08 41 41 52 44 56 41 52 4B   String, 8 bytes, "AARDVARK"

           CALL -151
     6E     Call
     96 69 FF   Two-byte integer ($FF69 = -151)

     12     End of program

Notice how all variables are referenced by the one-byte index, and how the constants are compiled in-line in their final form (integer, floating-point, or string). Looking at the six variable slices, and lining them up for easier viewing, I see:

     00 -- 40 FE 65 00 00 00  D$ = CHR$(4)
     01 -- 00 00 00 10 00 00  BUFFER = 4096
     02 -- 00 00 20 00 00 00  ARGUMENT = 32
     03 -- 00 8C 06 99 99 9A  RESULT = 2153.6
     04 -- 40 33 08 00 00 00  MYSTRING$ = "AARDVARK"

Maybe all this detail is overkill, but I wanted to show that the Beagle Compiler is real, well-constructed, valuable, and interesting. It is an excellent value at their price of $74.95. If you remember, the various DOS-based compilers cost more and (many would agree) delivered less. We like this one enough to help you get a copy: you can buy them through us for $65.

Commented Listing of ProDOS, $DEF3-DFE4 Bob Sander-Cederlof

As I promised last December, here is another piece of ProDOS. This time I am unveiling the code which processes IRQ interrupts, and the handlers for the related MLI calls. All of the following applies to version 1.1.1 of ProDOS. Later versions may differ in this area.

The two MLI calls related to interrupts are $40 (Allocate Interrupt) and $41 (De-Allocate Interrupt). There is room inside ProDOS for connecting up to four user-coded routines for processing IRQ interrupts. The Allocate Interrupt call stores the address of your routine at the next available entry in the IRQ Path Table. This table exists in the MLI Global Page ($BF00-BFFF), and is shown in lines 1140-1170 in the listing below. When you boot ProDOS these four entries all contain $0000, indicating no interrupts are allocated. An MLI call of the form:

       JSR $BF00
       .DA #$40,IRQ.IOB

with an IOB like this:

       IRQ.IOB .DA #2
       IRQ.NUM .BS 1
               .DA MY.IRQ.PROCESSOR

will cause the address of MY.IRQ.PROCESSOR to be stored in the IRQ Path table. The index into the table pointing to the entry used will be converted to an integer from 1 to 4, and stored at IRQ.NUM in the IOB. The purpose of this number is to allow you to later de-allocate the interrupt if you wish. A call and an IOB like this will de-allocate an interrupt:

          JSR $BF00
          .DA $41,IRQ.IOB
       IRQ.IOB .DA #1 
       IRQ.NUM .BS 1   (filled in by program)

Note that the first byte if the IOB is different this time, because there is only one parameter rather than two. It is important to de-allocate, because otherwise a sneaky interrupt could occur which would cause ProDOS to branch after your program is gone.

Another way to de-allocate is to store zeroes directly into the IRQ Path table, but Apple warns against this practice. It is quicker and easier, though.

There may be more than one source of IRQ interrupts in a given system. For example, you may be using both a clock card and a modem, both with interrupts. ProDOS allows you to have separate interrupt handlers for each of them installed. When an IRQ occurs the first handler installed will be called first. If that handler determines the IRQ is its own, it should process the IRQ and return with carry status clear. If not, the handler should return with carry status set. ProDOS will try giving the interrupt to each handler in turn, until one of them returns with carry clear. If none of them claim the IRQ, or if there are no processors allocated, "System Death" will occur: you will get error code $01, and a message to insert system disk and restart. It seems a nicer approach to unclaimed interrupts would be to count it, and continue processing. When the count exceeds some magic number, say 255, that would be the time to go through the agony of "System Death". I would also like to know the cause of "Death", if possible.

Lines 1400-1640 in the listing below show the code for allocating an interrupt. The code searches the IRQ Path table for an available entry (equal to 0000), and inserts the user's processor address in the first one found. If none are found you get error $25, INTERRUPT TABLE FULL. Actually only the high byte of each entry is checked, which means you cannot put an interrupt processing routine anywhere in page zero. The MLI call will allow you to do so, and it will even work, but if you later try to allocate another interrupt it will use the same table entry and clobber the first one. I suppose this is a bug in ProDOS, but not too likely to cause any problem because you are not likely to stick your code down in that page. Still, it COULD happen.

Lines 1660-1770 de-allocate an interrupt routine. If the interrupt index number is not in the range form 1 to 4, you will get error $53, BAD PARAMETER. Otherwise, the indicated entry will be zeroed.

When an IRQ interrupt occurs, if the status is such that interrupts are enabled, the processor status and the current PC-address will be pushed onto the stack; then processing will branch to the address currently at $FFFE and FFFF. What address is there will depend on which kind of Apple you are in, and whether ROMs or RAM are currently switched into the $D000-FFFF area. The original Apple II monitor and also the Apple II+ monitor vector IRQs into the $F8 monitor ROM area. A short routine there saves some registers and separates BRKs from IRQs (because they both share the same vector at $FFFE). IRQs then branch through another vector at $3FE and 3FF. The various Apple //e monitors vector IRQs and BRKs to an address at $C3FA, while the //c monitors send them to $C803.

When you boot ProDOS the installer/relocator code checks which kind of monitor you have. If your IRQ vector points anywhere below $D000, it assumes you have a "new style" monitor; if it points to anywhere between $D000 and $FFFF it assumes you have an "old style" monitor. The Apple II and II+ are old style, all others are new style. The installer/relocator stores a flag at $DFD8 so that the IRQ handler can tell what kind of machine it is in when an IRQ occurs later. This flag is shown at lines 2650-2710. In new style machines the vector found in ROM at $FFFE is copied into both Main and Auxiliary RAM banks at the same address, in case an interrupt occurs when RAM is switched on. In old style machines the address $FF9B is left in the RAM vector, pointing to a special IRQ handler shown in lines 3060-3400 below.

The vector at $3FE,3FF is set up to point to IRQ.ENTRY, a short routine inside the MLI Global Page. This is shown in lines 3000-3040. Since no matter what kind of monitor is resident the IRQ eventually vectors here, I will start the explanation here. Lines 3020-3030 turn on RAM at $D000-FFFF, so that ProDOS is accessible. It also write enables the RAM, because the IRQ processing will be storing a value at $DFCE, which identifies the current owner of the $C800 space (lines 1970-1980).

Lines 1800-1870 save the registers in the MLI Global Page. If you are in an old style machine lines 1880-1950 will save the processor status and return address in the Global Page as well.

ProDOS wants to make it easier to write IRQ processors, so it also makes sure you can use the stack and some page zero. If there are not at least 128 bytes left on the stack it will pop off 16 bytes and save them in a special buffer; if there are at least 128 bytes left this step is skipped. Then lines 2070-2120 save zero page locations $FA through $FF in a special buffer. Your IRQ processor can use these six bytes without worrying about saving and restoring them. (If you need more, you will have to save-restore them yourself.) This is all nice, but it does add to the general overhead for processing interrupts, which is already burdensome.

Lines 2130-2320 sequence through the installed interrupt processors until one of them claims the IRQ. Lines 2330-2350 signal DEATH if none of the processors claim the IRQ.

If the IRQ is properly claimed, lines 2360-2410 restore the six zero page bytes; lines 2420-2500 restore the 16 bytes of stack space if they were previously saved. Lines 2520-2630 restore some registers and the $C800 space if you are in an old style machine, and in any case branch to the IRQ.EXIT routine in the MLI Global Page.

IRQ.EXIT, shown in lines 2800-2960, restores the correct kind of memory (RAM or ROM) and then executes an RTI instruction. In an old style machine if the IRQ happened during a time when the RAM was switched on, this will send control to IRQ.EXIT.OLD, shown in lines 3690-3740. In a new style machine, or in any machine if the ROMs were on when the IRQ happened, the RTI will go back to the control of the monitor; exactly where that is depends on which monitor. Normally BANK.ID.BYTE contains the value $01. If an IRQ occurs in an old style machine when RAM is switched on, it will be changed to $00 or $FF depending on which $D000 bank is selected. Lines 2930-2940 change it back to $01 after one either $00 or $FF is processed.

One advantage to having both IRQ.ENTRY and IRQ.EXIT in the MLI Global Page is that you could substitute your own code if you wish. If you want to reduce overhead, and you know that you will always be running in a specific monitor configuration, you can patch in here. You could also patch in through the vector at $3FE, and avoid even more overhead. However, you would no longer be "standard".

I published a listing of lines 3070-3640 way back in December 1983, but I decided to include it here for completeness. This code is only used in an old style machine, and only when the IRQ occurs while RAM is switched on. The vector at $FFFE starts up the code at line 3140. The nonsense in lines 3140-3180 regarding location $45 makes sure we do not clobber the saved A-register. The old style monitor ROMs save the A-register at $45 rather than on the stack. This conflicts with use of the same location within both DOS 3.3 and ProDOS. QUESTION: Wouldn't it have been both easier and better to avoid using locaton $45 inside ProDOS? Kludge on top of kludge, if you ask me.

Lines 3290-3340 set up fake data on the stack for later use by an RTI instruction. Lines 3350-3380 do the same for an RTS instruction. Note that RTS requires an address with is one less than the actual address, while RTI requires the address un-modified. RTS pops the address, adds one, and branches; RTI pops the address and status, and branches without adding one. Line 3400 switches back to ROM. This means the next instruction will be executed from $FFCB in ROM, which is ALWAYS an RTS. Anyway it had BETTER be! If you ever make your own monitor ROM, be sure to leave an RTS here. (You will also need an RTS at $FF58, because a lot of I/O firmware expects that one is there.)

Lines 3420-3470 are executed in the old style machines if RAM is switched on when you hit RESET. That is, if you have the particular type of RAM card which leaves the F8 area switched on when you hit RESET. Many of them switch back to ROM when RESET occurs. Just in case, the code is here.

That about wraps it up. But it still leaves a lot of mystery in that part of IRQ processing which occurs inside the monitor ROMs. Each monitor version has its own unique code. The Apple II was simple, the II+ about the same. The three versions of //e and three versions of //c monitors of which I am aware are all mutually different. The IIgs is even more so. Perhaps in a future article we can rationalize them all.

  1000 *SAVE MLI.IRQ
  1010 *--------------------------------
  1020 PARM.PNTR        .EQ $40,41
  1030 COMMAND          .EQ $42
  1040 SAVE.A           .EQ $45
  1050 *--------------------------------
  1060 CURRENT.ROM.SLOT .EQ $07F8   $C0 + Slot which owns $C800.
  1070 *--------------------------------
  1080 CALL.SYSERR      .EQ $BF09
  1090 CALL.DEATH       .EQ $BF0C
  1100 *--------------------------------
  1110 SAVE.LOC45       .EQ $BF56   Used if in Apple II or II+
  1120 SAVE.D000        .EQ $BF57       ditto
  1130 *--------------------------------
  1140 IRQ.PATH.1       .EQ $BF80   These are 0000 if not allocated,
  1150 IRQ.PATH.2       .EQ $BF82   address of user IRQ handler
  1160 IRQ.PATH.3       .EQ $BF84   if allocated.
  1170 IRQ.PATH.4       .EQ $BF86
  1180 *--------------------------------
  1190 IRQ.A            .EQ $BF88
  1200 IRQ.X            .EQ $BF89
  1210 IRQ.Y            .EQ $BF8A
  1220 IRQ.S            .EQ $BF8B
  1230 IRQ.P            .EQ $BF8C
  1240 BANK.ID.BYTE     .EQ $BF8D
  1250 IRQ.RETURN       .EQ $BF8E,BF8F
  1260 *--------------------------------
  1270 IO.RESET.ROMS    .EQ $CFFF   De-select $C800 space.
  1280 *--------------------------------
  1290 IRQ.SV .EQ $FEDF thru $FEEE  (16 bytes saved from STACK)
  1300 *--------------------------------
  1310        .PH $DEF3
  1320 *--------------------------------
  1330 *   Handle $40 and $41 MLI calls
  1340 *--------------------------------
  1350 * (DEF3) DE57
  1370        STA COMMAND  Save in case anyone cares later.
  1380        LSR          $40 or $41, lsb into CARRY
  1390        BCS .5       ...$41 is DEALLOCATE
  1400 *---$40 is ALLOCATE--------------
  1410        LDX #3       FOR X = 3 TO 9 STEP 2
  1420 .1     LDA IRQ.PATH.1-2,X
  1430        BNE .2       ...ALREADY ALLOCATED
  1440        LDY #3       FOUND HOLE, INSTALL IRQ
  1450        LDA (PARM.PNTR),Y
  1460        BEQ .3       BAD PARAMETER
  1470        STA IRQ.PATH.1-2,X
  1480        DEY
  1490        LDA (PARM.PNTR),Y
  1500        STA IRQ.PATH.1-3,X
  1510        TXA          GIVE IRQ# TO CALLER
  1520        LSR          MAKE 3,5,7,9 INTO 1,2,3,4
  1530        DEY
  1540        STA (PARM.PNTR),Y
  1550        CLC          Signal NO ERROR
  1560        RTS
  1570 .2     INX          Next X
  1580        INX
  1590        CPX #11
  1600        BNE .1
  1610        LDA #$25     "INTERRUPT TABLE FULL"
  1620        BNE .4       ...ALWAYS
  1630 .3     LDA #$53     "BAD PARAMETER"
  1650 *---$41 is DEALLOCATE------------
  1660 .5     LDY #1
  1670        LDA (PARM.PNTR),Y
  1680        BEQ .3       ...0 is illegal value
  1690        CMP #5       Must be 1,2,3,4
  1700        BCS .3       ...too large
  1710        ASL          DOUBLE FOR INDEX
  1720        TAX
  1730        LDA #0       CLEAR THE ENTRY
  1740        STA IRQ.PATH.1-2,X
  1750        STA IRQ.PATH.1-1,X
  1760        CLC          Signal NO ERROR
  1770        RTS
  1780 *--------------------------------
  1790 *   If an IRQ occurs, we eventually get HERE.
  1800 *--------------------------------
  1820        LDA SAVE.A
  1830        STA IRQ.A
  1840        STX IRQ.X
  1850        STY IRQ.Y
  1860        TSX
  1870        STX IRQ.S
  1880        LDA ENHANCE.FLAG
  1890        BNE .1       ...In a "new style" monitor
  1900        PLA          ...In an Apple II or II+ monitor
  1910        STA IRQ.P    Save P-reg and RETURN address
  1920        PLA
  1930        STA IRQ.RETURN
  1940        PLA
  1950        STA IRQ.RETURN+1
  1960 .1     TXS          Keep P-reg and RETURN on stack
  1970        LDA CURRENT.ROM.SLOT   Save $C800 Slot 
  1980        STA ROM.PAGE.BYTE
  1990 *---Save some stack, maybe-------
  2000        TSX          If in bottom half of stack,
  2010        BMI .3            then save 16 bytes of it.
  2020        LDY #15      SAVE 16 BYTES FROM STACK
  2030 .2     PLA
  2040        STA IRQ.SV,Y
  2050        DEY
  2060        BPL .2
  2070 *---Save some page zero----------
  2080 .3     LDX #$FA     SAVE 6 BYTES FROM PAGE ZERO
  2090 .4     LDA 0,X      $FA...FF
  2100        STA IRQ.SV-$FA+16,X
  2110        INX
  2120        BNE .4
  2130 *---Call to first IRQ vector-----
  2140        LDA IRQ.PATH.1+1
  2150        BEQ .5       IRQ#1 EMPTY
  2160        JSR IRQ.1    Try this IRQ level
  2170        BCC .9       ...IRQ Claimed, Now Exit
  2180 *
  2190 .5     LDA IRQ.PATH.2+1
  2200        BEQ .6       IRQ#2 EMPTY
  2210        JSR IRQ.2    Try this IRQ level
  2220        BCC .9       ...IRQ Claimed, Now Exit
  2230 *
  2240 .6     LDA IRQ.PATH.3+1
  2250        BEQ .7       IRQ#3 EMPTY
  2260        JSR IRQ.3    Try this IRQ level
  2270        BCC .9       ...IRQ Claimed, Now Exit
  2280 *
  2290 .7     LDA IRQ.PATH.4+1
  2300        BEQ .8       IRQ#4 EMPTY
  2310        JSR IRQ.4    Try this IRQ level
  2320        BCC .9       ...IRQ Claimed, Now Exit
  2330 *---No IRQ vectors alive!--------
  2340 .8     LDA #$01     Un-claimed Interrupt Error
  2370 .9     LDX #$FA     RESTORE $FA...FF
  2380 .10    LDA IRQ.SV-$FA+16,X
  2390        STA 0,X
  2400        INX
  2410        BNE .10
  2420 *---If saved, restore stack------
  2430        LDX IRQ.S
  2440        BMI .12      16 BYTES FROM STACK NOT SAVED
  2450        LDY #0       RESTORE 16 BYTES TO STACK
  2460 .11    LDA IRQ.SV,Y
  2470        PHA
  2480        INY
  2490        CPY #16
  2500        BNE .11
  2510 *---Choose EXIT routine----------
  2520 .12    LDA ENHANCE.FLAG
  2530        BNE IRQXIT   ..."New style" monitor ROMs
  2540        LDY IRQ.Y    ...Apple II or II+ monitor.
  2550        LDX IRQ.X
  2560        LDA IO.RESET.ROMS    Turn off $C800 bank
  2570        LDA $CF00            Select Interrupted $C800 bank
  2580 * (DFCE) DF5E DFCF          (Hi-byte filled in)
  2590 ROM.PAGE.BYTE .EQ *-1       (Self-modifying code!)
  2600        LDA ROM.PAGE.BYTE
  2610        STA CURRENT.ROM.SLOT
  2620 * (DFD5) DFC1
  2640 *--------------------------------
  2650 * (DFD8) DF49 DFBE
  2660 ENHANCE.FLAG .HS 00 (Set to 01 by relocator if new
  2670 *                    type ROM is found)
  2680 *   ((If IRQ vector in ROM at $FFFE,F points below
  2690 *      $D000, it is "new type".  The "old type",
  2700 *      which is the original $F8 ROM in the Apple II
  2710 *      or that of the Apple II+, points to $Fxxx.))
  2720 *--------------------------------
  2730 * (DFD9-E2) DF7C DF86 DF90 DF9A
  2740 IRQ.1 JMP (IRQ.PATH.1)
  2750 IRQ.2 JMP (IRQ.PATH.2)
  2760 IRQ.3 JMP (IRQ.PATH.3)
  2770 IRQ.4 JMP (IRQ.PATH.4)
  2780 *--------------------------------
  2790        .PH $BFD0
  2800 *--------------------------------
  2820 *--------------------------------
  2830 IRQ.EXIT
  2840        LDA BANK.ID.BYTE
  2850 IRQ.EXIT.1
  2860        BEQ .2
  2870        BMI .1
  2880        LSR
  2890        BCC .3
  2900        LDA $C081    Switch on ROMs at D000-FFFF
  2910        BCS .3       ...ALWAYS
  2920 .1     LDA $C083    Switch on RAMs at D000-FFFF
  2930 .2     LDA #1
  2940        STA BANK.ID.BYTE
  2950 .3     LDA IRQ.A
  2960        RTI
  2970 *--------------------------------
  2980 *   An IRQ interrupt comes here when it occurs
  2990 *      because of the vector at $3FE,3FF.
  3000 *--------------------------------
  3010 IRQ.ENTRY
  3020        BIT $C08B    Switch on and write-enable
  3030        BIT $C08B         RAM at D000-FFFF
  3040        JMP IRQ.HANDLER
  3050 *--------------------------------
  3060        .PH $FF9B
  3070 *--------------------------------
  3090 *      This code is used when IRQ happens while
  3100 *      the RAM at D000-FFFF is switched on (inside
  3110 *      an MLI call, for example) if we have the
  3120 *      "new style" monitor ROMs.
  3130 *--------------------------------
  3140 IRQ    PHA          SAVE A-REG
  3150        LDA SAVE.A      ALSO SAVE SAVE.A
  3160        STA SAVE.LOC45
  3170        PLA          NOW PUT A-REG INTO SAVE.A
  3180        STA SAVE.A
  3190        PLA          PEEK AT STATUS
  3200        PHA
  3210        AND #$10     WAS IT "BRK"?
  3220        BNE .2       ...YES, LET MONITOR HANDLE IT
  3230        LDA $D000    CHECK WHETHER D000 BANK 1 OR 2
  3240        EOR #$D8     "CLD" OPCODE
  3250        BEQ .1       ...IN D000 BANK 1
  3260        LDA #$FF     ...IN D000 BANK 2
  3270 .1     STA BANK.ID.BYTE
  3280        STA SAVE.D000
  3300        PHA
  3310        LDA #IRQ.EXIT.OLD
  3320        PHA
  3330        LDA #$04
  3340        PHA
  3350 .2     LDA /$FA41   PUSH FAKE "RTS" VECTOR INTO
  3360        PHA               MONITOR ROM
  3370        LDA #$FA41
  3380        PHA
  3400        STA $C082    SWITCH TO MOTHERBOARD ROMS,
  3410 *                   WHERE THERE IS AN "RTS" OPCODE
  3420 *--------------------------------
  3440        PHA          PUSH FAKE "RTS" INTO MONITOR
  3450        LDA RESET.VECTOR
  3460        PHA
  3470        JMP CALL.MONITOR
  3480 *--------------------------------
  3500 *--------------------------------
  3520        STA IRQ.A
  3530        LDA SAVE.LOC45
  3540        STA SAVE.A
  3560        LDA SAVE.D000
  3570        JMP IRQ.EXIT.1
  3580 *--------------------------------
  3590        .BS $FFFA-*  <<<EMPTY SPACE>>>
  3600 *--------------------------------
  3610 V.NMI      .DA $03FB
  3620 V.RESET    .DA RESET
  3630 V.IRQ      .DA IRQ  (Replaced by relocator with
  3640 *                   the value from ROM vector if
  3650 *                   the machine has "new style" monitor.
  3660 *--------------------------------
  3670        .PH $BF50
  3680 *--------------------------------
  3710 *--------------------------------
  3730        LDA $C08B    SWITCH RAM ON, D000 BANK 1
  3740        JMP IRQ.SPLICE
  3750 *--------------------------------
  3760        .LIST OFF

$48 and "G" Strike Again! Bob Sander-Cederlof

This is still a problem. When you use the monitor "G" command, it loads up the registers from $45 through $49 and then goes to the address you specified. Location $48 supplies the status, the P-register. Unfortunately, both DOS and ProDOS walk on location $48. Therefore it might have a meaningless value.

Worse than meaningless, it might be dangerous. It was for me a few days ago. I was debugging a program under ProDOS, and found that if I started it up with "800G" immediately after a SAVE command, it went completely crazy. The screen output was totally trashed. Scrolling turned into shuffling, the cursor jumped around the screen when typing in characters, and so on.

Why? Because $48 had a garbage value with bit 3 turned on, which turned on the decimal mode. Apparently SAVE stores something into $48, and the actual value depends on mysterious factors. Anyway, I woke up the next morning with the explanation of what was going on. I even remembered that I wrote an article about the problem in the June 1984 issue of AAL (pages 13 and 14).

One solution is to put a "CLD" instruction at the beginning of my program, just in case. Other, less secure fixes are to type "48:4 N 800G" instead of just "800G", or avoid using the G-command altogether by putting the code on a BRUNnable file.

A Bug in FID with 400K Volumes Bob Sander-Cederlof

Tom Weishaar sent me copies of some correspondence regarding the RamFactor boards and and Apple's FID program. If the name FID means nothing to you, it is the DOS 3.3 equivalent to the ProDOS FILER program, and comes on the Apple DOS 3.3 System Master Disk. It seems that if you use FID to transfer files to a 400K DOS 3.3 partition on the card that FID quits with the DISK FULL error long before the volume is really full.

I tried to reproduce the problem on my system. When I used FID, it failed just as stated above. The exact point at which FID gave up seemed to vary with the size of the files being copied. When I used plain DOS, using BSAVE or SAVE, I had no problem really filling the disk. I also tried it with my word processor, with no problems. Apparently the problem is in FID.

When I got the DISK FULL message from FID, I went to the monitor and took a look at the VTOC sector of the RamFactor drive. The VTOC buffer is located at $B3BB thru $B4BA after leaving FID. Sure enough, there were plenty of free sectors left, but they were almost all in sectors 0 thru 15 (the third and fourth bytes of each track's bit map) of each track. I went back into FID and experimented with trying to copy various size files. FID had no trouble copying files of fewer than 17 sectors, but on larger files it said DISK FULL again. It seems FID has a bug in the subroutine which looks for free sectors to COPY into.

I investigated a little more, with the help of a partial disassembly of FID which Bill Morgan did back in 1982. Sure enough, the subroutine to find the next free sector ignores the third and fourth bytes of each track's bitmap in the VTOC. Since FID allows the DOS File Manager to do part of the allocation, some of those sectors do get used. However, when the GET.FREE.SECTOR subroutine is called it will not use sectors 0-15 of a 32 sector per track disk.

Lines 1000-1210 in the listing which follows are the offending code from FID. As you can see, only two bytes of the VTOC are moved (lines 1090-1120). Lines 1130-1150 check if those two bytes are both zero, and if so move on to the next track.

My first attempt to fix the bug is shown in lines 1220-1430. I re-arranged the code somewhat, to free up the X-register so that I could write a loop which would move four bytes from the VTOC to the bitmap work area. The loop is in lines 1330-1390. This did not leave room for code to check whether all four bytes were zero or not, so I just left out that feature; it was not necessary anyway, but it did shave a few microseconds off the worst cases.

In my second attempt I found room for testing whether or not there are any free sectors in a track and avoiding the extra time it takes to look at the bitmap one bit a time. Lines 1440-1680 show the result.

To install the patch, first assemble it as shown. This will leave a copy of the original code starting at $21E0, of PATCH1 at $31E0, and PATCH2 at $41E0. Then BLOAD your copy of FID, and check the starting address and length by looking at AA60.AA61 for the length and AA72.AA73 for the starting address. In my copy, the starting address was $803 and the length was $124F. Using the monitor, verify that the original code at $11E0 is the same. If you have a different version of FID, this is the time to find out!

       :   (type in the source code as shown)

       :BLOAD FID
       :$AA60.AA61 AA72.AA73
       AA60:4F 12
       AA72:03 08       (this is what Apple displays)

If no discrepancies are reported, you can copy either PATCH1 or PATCH2 into place and BSAVE the result.

       :$11E0<31E0.3207M   (for PATCH1)
       :$11E0<41E0.4207M   (for PATCH2)

       :BSAVE FID.PATCHED,A$803,L$124F

A patched version of FID is included on the monthly and quarterly disks for this issue.

  1010 *--------------------------------
  1020        .OR $11E0
  1030        .TA $21E0
  1040 *--------------------------------
  1050        TXA
  1060        ASL
  1070        ASL
  1080        TAY
  1090        LDA $198A,Y
  1110        LDA $198B,Y
  1120        STA $1932
  1130        BNE $11F7
  1150        BEQ $11DA
  1160        STX $1393
  1170        STX FREE.TRK
  1180        LDX $1987    # OF SECTORS PER TRACK
  1190        STX FREE.SEC
  1200        STY $1392
  1210        BNE $11A4
  1220 *--------------------------------
  1230        .OR $11E0
  1240        .TA $31E0
  1250 *--------------------------------
  1260 PATCH1 STX $1393
  1270        STX FREE.TRK
  1280        TXA
  1290        ASL          MULTIPLY BY FOUR
  1300        ASL
  1310        TAY
  1320        STY $1392
  1330        LDX #0       COPY 4 BYTES TO WORK AREA
  1340 .1     LDA $198A,Y
  1360        INY
  1370        INX
  1380        CPX #4
  1390        BCC .1
  1400        LDX $1987    # OF SECTORS PER TRACK
  1410        STX FREE.SEC
  1420        BNE $11A4
  1430        .BS 5,$EA    FILLER IS "NOP"
  1440 *--------------------------------
  1450        .OR $11E0
  1460        .TA $41E0
  1470 *--------------------------------
  1480 PATCH2 STX $1393
  1490        STX FREE.TRK
  1500        TXA
  1510        ASL          MULTIPLY BY FOUR
  1520        ASL          ALSO CLEARS CARRY
  1530        TAY
  1540        STY $1392
  1550        LDX #$FC     256-4
  1560 .1     LDA $198A,Y
  1570        BEQ .2       THIS ONE HAS NO FREE SECTORS
  1600        INY
  1610        INX
  1620        BNE .1       ...UNTIL 4 BYTES MOVED
  1630        BCC $11D7
  1640        LDX $1987    # OF SECTORS PER TRACK
  1650        STX FREE.SEC
  1660        BNE $11A4
  1670        NOP          FILLER IS "NOP"
  1680        NOP
  1690 *--------------------------------
  1700 FREE.SEC   .EQ $192F
  1710 FREE.TRK   .EQ $1930
  1720 BITMAP.OF.CURRENT.TRACK .EQ $1931 ... 1934
  1730 *--------------------------------

Apple Assembly Line (ISSN 0889-4302) is published monthly by S-C SOFTWARE CORPORATION, P.O. Box 280300, Dallas, Texas 75228. Phone (214) 324-2050. Subscription rate is $18 per year in the USA, sent Bulk Mail; add $3 for First Class postage in USA, Canada, and Mexico; add $14 postage for other countries. Back issues are available for $1.80 each (other countries add $1 per back issue for postage).

All material herein is copyrighted by S-C SOFTWARE CORPORATION, all rights reserved. (Apple is a registered trademark of Apple Computer, Inc.)