In This Issue...
News from Apple
Apple sent us a mouse the other day, and we hope to build some software around it. The mouse came with a disk of graphic software (done by Bill Budge) which makes the plain old Apple II look almost as good as Lisa. I didn't know your could do all that on a 280x192 screen, and as fast as he does it. The mouse itself appears identical to the Lisa mouse. It attaches to a cute red interface card you plug into any slot. The card has a version of the 6805 microprocessor on it...the kind with internal ROM and RAM which is not visible from the outside world.
Apple also is spreading the word that future Apple //e's are going to have 32 icon characters in the alternate character set. This probably means some changes to the Cx ROM... (Erv Edge says he hopes that means they are going to fix some bugs, too!)
Another tidbit from Apple is that future //e's will have most of the chips soldered to the motherboard, rather than riding in sockets. They say that should solve most of the remaining reliability problems. In my experience, Apple doesn't have any reliability problems. And I like sockets, because I like to tinker. And if something eventually does go bad, it is certainly easier to trade chips than motherboards. Nevertheless, they have made up their minds.
For the last several months, I've been intrigued by an article in the August '83 issue of Byte Magazine, "Chisel Your Code with a Profiler", by Dennis Leas and Paul Wintz. They describe a utility program, called a profiler, which measures where an executing program is spending most of its time. The largest application for such a tool is testing programs compiled from a high-level language. Typically such a program will spend nearly all of its time executing only a small section of the code. Leas and Wintz claim that the proportion is about 90% of the time in about 10% of the code. With a profiler you can identify the bottleneck and speed up the whole program by recoding one small piece.
The profiler first divides your program into sixteen "bins". It then interrupts your program periodically and reads the stored Program Counter from the stack. If the program is in the area you want to measure, it increments one of an array of counters. The profiler then returns control to your program until the next interrupt occurs. When the testing period is finished you can display the counters and spot your problem areas.
An essential part of this tool is a source of regularly timed interrupts. The best place to get a timed interrupt signal is from a suitable clock card. All of the clock cards have some provision for generating interrupts, usually at intervals of about 1 millisecond or 1 second. Some also have available 64 Hz or 256 Hz frequencies, or other values. Check the documentation with your clock to see exactly how to use its interrupt features.
The interrupt timing you want to use will in part be a function of how long your program, or subroutine, will run. If you're profiling a sort that takes several minutes to complete, a 1000 Hz interrupt will overflow the counters long before a significant amount has been done. If the routine takes a short time, a 60 Hz clock won't catch enough hits to be meaningful. Leas and Wintz use a 6 Hz signal picked up from their disk drives to profile a compiler that runs for about 10 minutes.
If all you have available is a high-frequency signal, it's easy enough to divide it down to something usable. Just initialize a counter in the setup portion of the program to the necessary value. Then whenever an interrupt occurs, decrement the counter. Most of the time the counter will be non-zero, so then branch directly to the exit portion of the handler. When the counter reaches zero, go ahead and do the full interrupt processing and then reset the counter.
What if I don't have a clock?, you ask. That is exactly the problem I had when I started thinking about this project. Then I ran across an article in the July 83 issue of Micro in which Charles Putney (a subscriber and sometimes contributor to these pages) told how to get a 60 Hz signal to the interrupt line. Charles' article tells how to use that signal to implement a real-time clock, but it seemed to me that here was exactly the interrupt signal I had been seeking for my profiler.
All you need to do is add a wire inside your Apple, from pin 11 of the 74LS161 at coordinate D11 to pin 4 of the 6502. I used a pair of plunger clips (Radio Shack #270-370, the smallest ones) to attach the wires, and also put a pushbutton in the circuit. When attaching the clips to the IC pins, be EXTREMELY careful not to short any adjacent pins, and try to arrange things so that the wire doesn't wobble around. TURN THE POWER OFF BEFORE MESSING WITH WIRING INSIDE YOUR COMPUTER.
Here's a drawing that shows where to connect the wires:
Note that the photograph in the Micro article does NOT show the correct pins. The description in Putney's text is correct, but whoever did the photo artwork garbled it.
The signal we are borrowing is one of the video timing signals, called V5. V5 is normally high (~5 volts). It goes low every 1/60th of a second, and stays low for about 380 microseconds. That's a pretty good interrupt signal, but we're going to have to allow time for V5 to get back to its high state before we return to the main program, or we'll get more than one interrupt per cycle.
The program
When you BRUN or CALL Profiler, lines 1120-1130 hook the Initialize portion of the program into the monitor's CTRL-Y vector.
Initialize first connects the Handler routine to the IRQ vector (1190-1220). It then gets the starting and ending addresses from where the Monitor left them, takes the difference and divides by 16 to get the size of each bin (1270-1390).
Build Table then starts the table with the Start address and loops to set each table entry Step bytes larger than the previous one (1420-1650). At the same time the routine sets the count for each bin to zero and adds an extra zero byte after the count (1610-1630). This extra byte makes the table easier to read with a Monitor memory dump.
Note that the last entry is set to the End value, rather than a calculated step (1670-1700). This makes the last bin larger than the others, by somewhere between 0 and 15 bytes, to compensate for the remainder left behind when we divided to get Step.
Now we come to the Handler itself. When an IRQ interrupt occurs we first save all the registers on the stack (1740-1790). The next step is to extract the Program Counter value from inside the stack and save it (1800-1840).
The next step is checking that PC value to see if it is inside the range we want (1860-1920). If not, go on to Exit.
If we are in range, search down the table to find the right bin (1930-1980) and register the count (2000-2040). Since the counters only go up to 255, I have the profiler stop when one of them wraps around (2070-2080).
The Exit routine includes a delay loop (2120-2140) to make sure that the Handler takes at least 380 microseconds. This insures that the V5 line we're using for an interrupt source has gone back high, and won't interrupt again as soon as the RTI is done. If you're lucky enough to be getting your interrupts from a clock card you won't need this loop, but you will need to do something to tell the card that you're done with this interrupt. Check your clock manual. Profiler then ends by restoring the registers and doing an RTI.
The Compare Entry routine (2220-2270) just compares the PC value to the current table value.
The funny-looking FILLER space (line 2340) makes sure that the Table begins on a new line in the Monitor memory dump, keeping things easy to read.
Using Profiler
When I want to profile a program, I first assemble Profiler to run somewhere out of the way above or below the program I want to test. Then I enter the Monitor and type addrG to connect Profiler to CTRL-Y. Next I enter addr1.addr2^Y (that's <Start-address>.<End-address><CTRL-Y>) to initialize things.
The next step is to start the program I want to measure, and then start the interrupts coming. My system has a pushbutton between the 60 Hz source and the IRQ line, so I just hold the button down for the period I want to check on. If you're using a clock card you can probably insert instructions into your program to start and stop the interrupts at the points you want.
If one of the counters passes 255 Profiler will Break into the Monitor. Otherwise get into the monitor after your program has finished and examine the table. There's a record of exactly where your program has been.
In a large program, the bin with the highest count may be too wide to really tell where the bottleneck is. If so, just use the control Y command to profile only the bin that had the largest count. This will divide that section into 16 segments so you can see more detail.
Limitations and possible improvements
The profiler described by Leas and Wintz displays the counts as a bar graph, so the largest count really stands out. My version just leaves the addresses and counts where you can read them with the Monitor, so I'm sure you can come up with ways to improve that.
Sometimes it would be nice to be able to build the address table interactively, rather than having it forced to sixteen equal-sized sections. Maybe something like entering the starting address you want for each bin, and a zero at the end.
The DOS problem
There has always been a problem with using interrupts in the Apple II under DOS 3.3, but the solutions are now pretty well-known. Elsewhere in this issue we cover the DOS or Monitor patches necessary to use the 6502's IRQ interrupt without trouble. This program assumes that all that has been taken care of, or that you don't care.
References
1. "Chisel Your Code with a Profiler" Dennis Leas & Paul Wintz. Byte Magazine. August, 1983, pp 286-290.
2. "A Clock Interrupt for Your Apple" Charles Putney. Micro Magazine. July, 1983, pp 36-41.
1000 *SAVE S.PROFILER 1010 *-------------------------------- 1020 A2L .EQ $3E 1030 A2H .EQ $3F 1040 A3L .EQ $40 1050 A3H .EQ $41 1060 1070 STACK .EQ $100 1080 IRQ.VECTOR .EQ $3FE 1090 CONTROL.Y.VECTOR .EQ $3F9 1100 *-------------------------------- 1110 .TF PROFILER 1120 LDA /INITIALIZE 1130 STA CONTROL.Y.VECTOR+1 1140 LDA #INITIALIZE 1150 STA CONTROL.Y.VECTOR 1160 RTS 1170 *-------------------------------- 1180 INITIALIZE 1190 LDA #HANDLER install vector 1200 STA IRQ.VECTOR 1210 LDA /HANDLER 1220 STA IRQ.VECTOR+1 1230 LDA #0 initialize variables 1240 STA HITS 1250 STA HITS+1 1260 SEC 1270 LDA A2L 1280 SBC A3L calculate step size 1290 STA STEP 1300 LDA A2H 1310 SBC A3H 1320 BCC ERROR end<start 1330 STA STEP+1 1340 1350 LDX #3 divide STEP by 16 1360 .1 LSR STEP+1 (shift it right 4) 1370 ROR STEP 1380 DEX 1390 BPL .1 1400 1410 BUILD.TABLE 1420 LDA A3L first table entry 1430 STA TABLE is start address 1440 LDA A3H 1450 STA TABLE+1 1460 LDX #0 1470 STX TABLE+2 zero count 1480 STX TABLE+3 and fill byte 1490 1500 .1 INX next entry 1510 INX 1520 INX 1530 INX 1540 CLC 1550 LDA TABLE-4,X 1560 ADC STEP add step size to 1570 STA TABLE,X last entry 1580 LDA TABLE-3,X 1590 ADC STEP+1 1600 STA TABLE+1,X 1610 LDA #0 1620 STA TABLE+2,X zero count 1630 STA TABLE+3,X and fill byte 1640 CPX #$3C done? 1650 BCC .1 no 1660 1670 LDA A2L 1680 STA TABLE+4,X and make last entry 1690 LDA A2H equal end 1700 STA TABLE+5,X 1710 ERROR RTS 1720 *-------------------------------- 1730 HANDLER 1740 LDA $45 get A back from where 1750 PHA Monitor stashed it 1760 TXA 1770 PHA save registers 1780 TYA 1790 PHA 1800 TSX 1810 LDA STACK+6,X get PC from stack 1820 STA PCH 1830 LDA STACK+5,X 1840 STA PCL 1850 *---SEARCH TABLE---------------- 1860 LDX #0 compare PC to start 1870 JSR COMPARE.ENTRY of table 1880 BCC EXIT below table 1890 LDX #$40 and compare to 1900 JSR COMPARE.ENTRY end of table 1910 BCS EXIT above table 1920 1930 .1 DEX next entry 1940 DEX 1950 DEX 1960 DEX 1970 JSR COMPARE.ENTRY 1980 BCC .1 not there yet 1990 2000 INC HITS count hit in total 2010 BNE .2 2020 INC HITS+1 2030 .2 INC TABLE+2,X count hit in bracket 2040 BNE EXIT 2050 2060 * counter overflowed, so put it back to $FF and end 2070 DEC TABLE+2,X 2080 BRK 2090 * ... do whatever it takes to clean up the stack 2100 * and display the results 2110 2120 EXIT LDY #55 delay about 275 usec so 2130 .1 DEY V5 will be high on exit 2140 BNE .1 2150 PLA restore registers 2160 TAY 2170 PLA 2180 TAX 2190 PLA 2200 RTI and exit 2210 *-------------------------------- 2220 COMPARE.ENTRY 2230 LDA PCL 2240 CMP TABLE,X 2250 LDA PCH 2260 SBC TABLE+1,X 2270 RTS 2280 *-------------------------------- 2290 VARIABLES 2300 PCL .BS 1 program counter 2310 PCH .BS 1 2320 HITS .BS 2 total count 2330 STEP .BS 2 bracket size 2340 FILLER .BS */8*8+8-* align table 2350 *-------------------------------- 2360 TABLE .EQ * |
A couple of people have pointed out to me that we have advertised Don Lancaster's "Micro Cookbook, Volume II", but have never described it. This one is subtitled Machine Language Programming, and picks up where Volume I left off. He devotes about 450 pages to machine language programming, simple I/O ports, and his Micro Applications Attack method of problem-solving.
Lancaster's method of teaching machine language looks a little strange from my perspective: he says "don't even think about an assembler until you have thoroughly learned the instructions from hand assembly." He lays out a system of learning all the instructions and addressing modes by documenting them on 3X5 cards. All his examples refer to the 6502, but the system can be applied to any processor. I suppose this IS a great way to engrave into your memory exactly how a processor works. All this is handled in Don's usual entertaining and enlightening fashion.
This is a good place to mention another book of Lancaster's that has been around for a while: The Hexadecimal Chronicles. This is a huge collection of conversion tables for moving around between ASCII, decimal, hexadecimal and octal (including Apple's negative decimal way of handling addresses.) My TI Programmer calculator is a lot smaller and easier to use, but much more expensive too. If you can find a copy of this book, look it over carefully. It may be exactly what you need.
As we reported a couple of years ago (V2N4, Jan 82), there is a serious problem in using interrupts in the Apple. The Monitor's IRQ interrupt handler uses location $45 to store the contents of the A-register while it is checking to see if the interrupt was from IRQ, or from a BRK instruction. Unfortunately, DOS 3.3 uses $45 for temporary storage in several different routines. If an IRQ interrupt occurs while DOS is active, the Monitor clobbers $45 and DOS can lose a variable.
The usual solution has been to change the Monitor to use some other address to stash the Accumulator. This can be done by copying the Monitor into the RAM card and patching in the new address, or by burning a new Monitor in EPROM and modifying the Apple to accept the chip. The byte that needs changing is at $FA41 in the Autostart ROM, or $FA87 in the Old Monitor ROM.
In the January 84 issue of Washington Apple Pi, Bruce Field reports about the other approach to resolving the conflict. He passes along Wilton Helm's details of the locations in DOS that refer to $45, and how to change things around to safely use interrupts without affecting anything else. Here's Helm's report:
"Location $45 is used at the following places in DOS 3.3:$A133 $A13E $A158 $A1BE $A1D3 $A1E8 $A1F7 $A1F9 $A201 $A2CC $A767 $A77F $ADBA $AE0A $AE54 $AE58 $BED3 $BF16 $BF39 $BF55 $BF57 $BF5B $BF9D $BFA3 $BFA5.These locations should be changed to $46. Location $46 is used for only one purpose, at $BA06 and at $BDA4. These two locations should be changed to $2C. Location $2C is used only by RWTS subroutines and does not conflict with this additional use. The end result is that DOS no longer uses $45 and does not use any new locations."
Field also reports that "these modifications have been made in Universal DOS ... and similar patches have been made in Diversi-DOS."
Bob S-C put together the following Applesoft program to install the patches. The program first checks to make sure that the DOS in memory has not had the patches applied already, then puts them in place. The check beforehand will also avoid clobbering a non-standard DOS.
100 REM PREPARE DOS 3.3 FOR INTERRUPTS
110 READ A: IF A = 0 THEN 200
120 IF PEEK (A) = 69 THEN 110
130 PRINT "THIS DOS IS ALREADY PATCHED": END
140 I = I + 2: GOTO 120
200 READ A: IF A = 0 THEN 300
210 IF PEEK (A) = 70 THEN 200
220 PRINT "THIS DOS IS ALREADY PATCHED": END
300 RESTORE
310 READ A: IF A < > 0 THEN POKE A,70: GOTO 310
320 READ A: IF A < > 0 THEN POKE A,44: GOTO 320
330 END
1000 DATA 41267,41278,41304,41406,41427,41448,41463,41465,
41473,41676,42855,42879,44474,44554,44628,44632,48851,
48918,48953,48981,48983,48987,49053,49059,49061,0
1010 DATA 47622,48548,0
While we're on the subject of interrupts, I'd like to recommend a book to you: "Real Time Programming - Neglected Topics", by Caxton C. Foster. (Addison-Wesley, 1981. Paperback, $8.95 a couple of years ago.) Foster covers interrupts, ports, timing considerations, A/D conversion, filters, control loops, and communication issues. He points out that these are "enough topics to make up the better part of a full-fledged masters program in electrical engineering or computer science" and that "no book less than 10 inches thick could cover all these topics in detail." Nevertheless, in about 180 pages he does an excellent job of introducing the reader to the material, covering both hardware and software.
For two hours two nights ago I tossed, turned, wrestled, and wrote a speech on trends in our favorite industry. I think it went like this....
3-piece Suits
Woz likes blue jeans and jogging shoes. Engineers and programmers tend to put their craft ahead of their tailors. And the most productive rank skills before degrees.
But once an industry starts creating wealth, the business grads and 3-piece suiters quickly rise to the top.
Woz worked in a little cubicle at Hewlett-Packard. With their blessing he left with the seeds of the most munificent Apple tree ever. Now he is back to working in a cubicle. Are other seeds incubating? Will they stay in the same orchard?
Lawsuits
Another kind of action is drawn by the magnet of success: legal. Friends suing friends for more than they ever made. Visicorp suing Software Arts for $50 million: "You were too slow putting advanced Visicalc onto the IBM-PC." Software Arts suing Visicorp for $87 million: "You didn't promote Visicalc well enough."
United Computer Corporation (why buy when you can rent) being sued by MicroPro and others. Maybe some people only rent so they can make their own copies. In any case, UCC shouldn't remove the license agreements from the packages!
UCC has also earned some lawsuits over their advertising debts. They prepay the first month, and ask for 30-day terms to run until further notice. That was last April...we caught on in July.
Following Suit
The whole world seems to be going IBM. Last year it was all CP/M. Next year it may be all AT&T. Remember back when everyone was copying Apple?
Businessmen buy those computers having the most on-going software and hardware development. Developers, programmers, cloners, and other entrepreneurs gather around systems businessmen are buying. The boys go where the girls are, which is where the boys are, which is where the girls are.... Being popular is so popular!
All of which slows down innovation in the marketplace. Not that innovation is all good and popularity is all bad. One secret of success is to stay the same long enough. Apple II/Plus/e has presented a stable yet growing environment for developers...contrast with Commodore/OSI/Radio Shack and their strings of mutually incompatible environments.
But innovators brought us the computer. And the supercomputer. And the minicomputer. And the microcomputer. And the Apple. And the....
I talked for about 15 minutes this morning (Dec 16th) with Bill Mensch. Bill used to work at Motorola, and was involved in the design of the original 6800 family there. Chuck Peddle joined the group, and noticed opportunities others were overlooking. Chuck and Bill decided to move to Pennsylvania, and with a few friends founded MOS Technology. They designed and built the 6501 microprocessor, but someone said it looked too much like the 6800 for comfort. Then came the 6502, leading to multiple millions of video games and personal computers. Bill is now at his own design company (Western Design Systems).
Bill told me he designed all the various CMOS versions of the 6502. Now he has designed the 65802 and 65816, CMOS versions with 16-bit registers and 16-megabyte address space. And he is currently working on a 32-bit version!
You probably read about these new versions on page 64 of the December Softalk, or in recent issues of Infoworld or Electronic Design. Elsewhere in Softalk you might also have noticed a box summarizing comments by Woz about plans for a new enhanced Apple //e with 16-megabyte capability. There are probably still other manufacturers out there with boxes and sockets just waiting on the first of Bill's new chips!
I just wish I could convey on paper how excited I am about this new chip! To me, it is as revolutionary as the original microprocessors were in their day. I predict that the 65816 and its successors will prove to be more powerful than the 68008: you will be able to write more compact code that runs faster, and build boards for less money that use less electricity.
With Bill's permission I am re-printing parts of his data sheet. You can get the complete package by calling (602) 962-4545 or writing to Western Design Center, 2166 E. Brown Rd, Mesa, Arizona 85203. [ Rather than including a nearly illegible scan of the original printed page here, I will instead direct you to Bill Mensch's company web site for up-to-date material: Western Design Center. You can download a 65816 datasheet as a 62-page PDF file from the WDC site.]
I have had my QWERTY Q68 board for about 2 weeks now. In my opinion this seems to be an excellent product and also a very inexpensive way to learn about the MC68000 MPU.
As an exercise I rewrote an Integer BASIC program called "ROD'S COLOR PATTERN" found in my red Apple II Reference Manual (1978). I am sending you two versions of my program. the first version does the calculation for the LORES screen base addresses. The second version looks up the base addresses in a table, consequently running slightly faster than the first version. The second version runs (as close as I can tell) about 50 times faster than the Integer BASIC program.
[ We're printing only the first version, since the GBASCALC routine is more interesting than a table lookup. QD 14 will include both version... Bill ]
After the 68000 source code has been assembled, I BRUN a very short 6502 program which consists of the following code:
.OR $1080
JSR $30B TURN ON THE Q68 BOARD
HERE JMP HERE DON'T DO ANYTHING
This keeps the 6502 busy while the 68000 is doing all the work.
Here's a listing of ROD'S COLOR PATTERN in Integer BASIC:
10 GR
20 FOR W = 3 T0 50
30 FOR I = 1 TO 19
40 FOR J = 0 TO 19
50 K = I+J
60 COLOR = J*3 / (I+3) + I*W/12
70 PLOT I,K: PLOT K,I: PLOT 40-I,40-K: PLOT 40-K,40-I
80 PLOT K,40-I: PLOT 40-I,K: PLOT I,40-K: PLOT 40-K,I
90 NEXT J: NEXT I: NEXT W
100 GOTO 20
1000 *SAVE S.URSCHEL'S COLOR PATTERN 1010 *-------------------------------- 1020 * RODS COLOR PATTERN 1030 * RE-WRITTEN BY BOB URSCHEL 1040 * USING THE QWERTY Q68 MC68000 MPU 1045 * 1047 .OR $1000 1050 MOVE.L #$1100,A0 MOVE PROGRAM TO FAST MEMORY 1060 MOVE.L #$18600,A1 1070 MOVE #END-START,D1 1080 XFER MOVE.B (A0)+,(A1)+ 1090 DBF D1,XFER 1095 JMP $18600 1100 * 1110 *-------------------------------- 1120 * 1140 .OR $18600 1150 .TA $1100 1160 START 1170 TST.B $C050 >GR 1180 BSR CLRSCR CLEAR SCREEN 1190 *-------------------------------- 1200 START.W 1210 MOVE.B #3,W >FOR W = 3 TO 50 1220 START.I 1230 MOVEQ #1,D7 >FOR I = 1 TO 19 1240 START.J 1250 MOVEQ #0,D3 >FOR J = 0 TO 19 1260 SET.K MOVE D7,D6 >K = I + J 1270 ADD.B D3,D6 1280 *-------------------------------- 1290 MOVEQ #0,D0 >COLOR = J*3/(I+3)+I*W/12 1300 MOVE D3,D0 1310 MULU #3,D0 J*3 1320 MOVEQ #0,D1 1330 MOVE D7,D1 1340 ADDQ #3,D1 I+3 1350 DIVU D1,D0 J*3/(I+3) --> D0 1360 MOVE D7,D1 1370 MOVEQ #0,D2 1380 MOVE.B W,D2 1390 MULU D1,D2 I*W --> D2 1400 DIVU #12,D2 D2 / 12 1410 ADD D0,D2 1420 ANDI.B #$F,D2 1430 MOVE.B D2,COLOR SET COLOR 1440 * 1450 * 1460 * SUBTRACT I AND K FROM 40 1470 * 1480 MOVEQ #40,D5 1490 SUB D7,D5 D5 = 40 - I 1500 MOVEQ #40,D4 1510 SUB D6,D4 D4 = 40 - K 1520 MOVE D7,D0 >PLOT I,K 1530 MOVE D6,D1 1540 BSR.S PLOT 1550 MOVE D6,D0 >PLOT K,I 1560 MOVE D7,D1 1570 BSR.S PLOT 1580 MOVE D5,D0 >PLOT 40-I,40-K 1590 MOVE D4,D1 1600 BSR.S PLOT 1610 MOVE D4,D0 >PLOT 40-K,40-I 1620 MOVE D5,D1 1630 BSR.S PLOT 1640 MOVE D6,D0 >PLOT K,40-I 1650 MOVE D5,D1 1660 BSR.S PLOT 1670 MOVE D5,D0 >PLOT 40-I,K 1680 MOVE D6,D1 1690 BSR.S PLOT 1700 MOVE D7,D0 >PLOT I,40-K 1710 MOVE D4,D1 1720 BSR.S PLOT 1730 MOVE D4,D0 >PLOT 40-K,I 1740 MOVE D7,D1 1750 BSR.S PLOT 1760 ADDQ #1,D3 >NEXT J 1770 CMPI #20,D3 1780 BNE SET.K 1790 ADDQ #1,D7 >NEXT I 1800 CMPI #20,D7 1810 BNE START.J 1820 ADDQ.B #1,W >NEXT W 1830 CMPI.B #51,W 1840 BEQ START.W 1850 BNE START.I 1860 * 1870 *-------------------------------- 1880 * PLOT SUBROUTINE 1890 * 1900 * A0 = SCREEN ADDRESS 1910 * D0 = X-COORD 1920 * D1 = Y-COORD 1930 * D2 = WORK REGISTER 1940 * 1950 PLOT MOVE D0,A0 SAVE X-COORD 1960 LSR.B #1,D1 GET CARRY 1970 MOVE SR,D0 SAVE ODD-EVEN STATUS 1980 BSR.S GBASCALC 1990 ADD D1,A0 FINAL SCREEN ADDR 2000 MOVE.B #$F0,MASK 2010 MOVE.B COLOR,D1 2020 MOVE D0,CCR ODD OR EVEN? 2030 BCC.S PLOT1 EVEN... 2040 MOVE.B #$F,MASK 2050 LSL.B #4,D1 ROTATE COLOR 2060 PLOT1 MOVE.B (A0),D2 ORIGINAL BYTE 2070 AND.B MASK,D2 MASK OUT OLD COLOR 2080 OR.B D1,D2 AND GET NEW COLOR 2090 MOVE.B D2,(A0) PLOT TO SCREEN 2100 MOVEQ #0,D0 CLEAR OUT CCR 2110 MOVEQ #0,D1 2120 RTS 2130 * 2140 * CALCULATE BASE ADDRESS 2150 * 2160 GBASCALC 2170 MOVE D1,D2 000DEFGH 2180 AND.B #$18,D1 000DE000 2190 LSL.B #5,D2 FGH00000 2200 OR.B D2,D1 FGHDE000 2210 MOVE.B D1,D2 2220 AND.B #$18,D2 000DE000 2230 LSR.B #2,D2 00000DE0 2240 OR.B D2,D1 FGHDEDE0 2250 OR #$100,D1 1FGHDEDE0 2260 LSL #2,D1 1FGHDEDE000 2270 RTS 2280 * 2290 * CLEAR LORES SCREEN 2300 * 2310 CLRSCR CLR D0 2320 MOVE #511,D1 # OF WORDS TO MOVE MINUS 1 2330 MOVE #$800,A0 ENDING SCREEN ADDR 2340 .1 MOVE D0,-(A0) 2350 DBF D1,.1 2360 RTS 2370 *-------------------------------- 2380 * WORK AND STORAGE 2390 * 2400 MASK .BS 1 2410 COLOR .BS 1 2420 W .BS 1 2430 * 2440 *-------------------------------- 2450 END 2460 .OR $800 2470 .DA $18800 2480 .DA $1000 |
If you want the real inside scoop on the Apple II, you need "Understanding the Apple II". Following close on the heels of Gayler's "Apple II Circuit Description", this book is no second-place sequel.
"Understanding..." was written by Jim Sather, a former ITT technical representative, after many moons of trial-and-error, pick-and-shovel research into the inner sanctum of our favorite computer. Jim has a gift for clearly explaining how things work. My degree is a little rusty, or mildewed, or whatever, and hardware never was my long suit. But Jim makes it all make sense for me.
The process of "understanding" starts with a few full color diagrams and charts. In the back of the book there are two foldout full color charts of bus structure and chip layout. Surprisingly, you find color sprinkled throughout the book, along with many black & white illustrations, photos, tables, diagrams, etc.
Sather describes microcomputer fundamentals with specific applications to the Apple II. He carefully documents all the circuits on the motherboard, as well as the firmware and language cards, and Wozniak's patented disk controller.
The chapter on the disk drive and controller is especially thorough, devoting some 45 large pages, including many diagrams, to the exact workings of these devices. I have never seen a better explication of the Apple's unique disk controller.
There are especially useful discussions of address decoding, RAM/ROM addressing, and bus structure. Sather's readable style avoids much of the reference-book prose common to authoritative technical books.
Each chapter ends with some of nearly two dozen hardware & software projects, including reprogramming screen character sets, an NMI based single stepper, detecting and using television sync, modifying the firmware card so the F8 ROM can be switch-selected, and more.
"Understanding..." begins with a foreword by Steve Wozniak, and ends near an appendix describing a conversation with Woz about some of the original design decisions that made our Apples what they are today.
This would be a good text book in computer hardware fundamentals at high school level or above. Most of the courses I took in college (now over 25 years ago!) were rather abstract and difficult to relate to real applications. What better way to understand how computers work, how they can be modified and maintained, and how to design them, than to dissect a living breathing example like the Apple II!
Here's a quick look at the structure of "Understanding the Apple II":
Chapters
- Overview
- Bus Structure
- Timing Generation and the Video Scanner
- The 6502 Microprocessor
- RAM
- ROM
- Address Decoding and I/O
- Video Generation
- Disk Controller
- Maintenance and Care
Glossary of 7 pages, about 150 entries.
Appendices: references, trademarks, 6502 data sheets, program listings, logic circuits primer, number systems primer, apple ii revisional info, historical notes, conversation with Woz, how to remove the motherboard, list of figures and tables.
Schematics, Index
"Understanding the Apple II" describes the Apple II and Apple II Plus. Much of the book's information, especially the chapter on the disk controller, applies also to the Apple //e. "Understanding the Apple //e" is promised sometime in 1984.
Understanding the Apple II, Jim Sather. About 356 pages. Quality Software, $22.95 (Buy it from us for only $21 + shipping).
I received my copy of Locksmith 5.0 last week. I haven't tried any of the lock-busting capabilities, because I have no particular need for that. But there are other features which justify the price. The new manual has information on copy protection schemes which I think has never been published before. The new manual is 140 pages long! I remember the first edition came with a tiny 1/2 page summary of operation!
The other item I am in love with is the fast copy program for ordinary DOS 3.3 disks. In a 64K Apple with two disk drives on one controller, it will make a copy in only 19 seconds! And if you have a larger memory (32K beyond a 128K //e, or a II with a 128K card), it can make a complete copy in only 16 seconds. And if you want to make multiple copies of the same disk, and have large enough memory to hold an entire disk image, you can make additional copies in 8 seconds flat! These copies are without verify, but a verify pass only adds 7 more seconds.
I think this one feature is worth the $99.95 price tag, but there are many more reasons for owning a copy. If you own a previous version, they have an attractive upgrade policy. If not, we will send you a copy for $90 + shipping.
Steve Knouse sent a printout of the "on-line with Woz" session you may have heard about. Some intriguing Woz-words:
About ProDOS use of >64K memory: "Our enhanced //e family is headed toward 16M bytes in short time with a revolutionary 6502-based processor."
About software for extended RAM cards: "I promise an alternative solution soon (6 mo?) for direct addressing of 24-bit address."
About MAC: "...look at LISA. Then imagine slightly fewer resources and memory but advantage taken to make it faster and better with fewer resources (sound familiar //e world?). Mouse, no color, no slots, finest software (BASIC and Pascal are finest ever done too). MAC will use its own op-sys which was developed to handle the user interface of LISA more directly with better performance. Such good software has been written for MAC (128K bytes in ROM) that it will be transferred to LISA soon!" "Initially MAC won't displace the PC as a small business machine but is intended to be a more finished product for the bulk of the personal market -- assuming which peripherals and features they would want and supplying them at lower cost than if they have slots to make their own choices. Interesting." "I believe that MAC is the most revolutionary computer of all time -- not that what it does hasn't been done before, but that it hasn't been done at a price which will wind up with millions experiencing it." "The MAC unfortunately is so perfect that we didn't leave much room for hackers to do hardware 'for themselves' or 'their own way' -- we feel there were no alternatives. The philosophy on software is different -- open, access the hardware at various levels."
About larger ProFILEs: "...yes, plans for larger ProFILEs. Pretty the minimal hard disk for small business has grown to 10MB, soon 20."
About the Apple: "The Apple II was not built to be a product for sale. It looked like the best thing available in 1976. The first computer ever (low cost) with color, hi-res, Basic in ROM, plastic case, switching power supply, dynamic memories, paddles, speaker, cassette, etc, all STANDARD. Look at virtually every "personal" computer since. We needed $250,000 to build a thousand--where do you get that kind of money when you're a couple of kids with no business experience? We sought venture money and Mike Markkula agreed to HELP us write a business plan. He realized we were onto something that happens once a decade -- a huge market expanding out of nothing. He joined us (equal partner) and loaned $250,000. He told me I had to quit HP and go 100% Apple. HP is a good company and it's hard to leave any company for anything when you believe it's good to its employees. I said "NO" on my ultimatum day and we were not going to do Apple. Steve Jobs was (in tears) and got relatives and friends of mine to call me at work and tell me why I should start Apple. Finally I realized I could have a great time doing the one important thing in my life -- design computers for myself and start the company to make money and in my head they didn't have to be dependent. So I turned around. Markkula decided that he and Jobs had better have 52% of Apple combined -- I realize now that they were probably afaid I was a little unpredictable. A true story."
About a faster //e: "The Accelerator [Saturn, 3.58MHz 6502 with 64K RAM] is my favorite card, largely because without any fancy jumpers EVERYTHING ran with it. The only exception with the software I use is Word Juggler under ProDOS. The current Accelerator should have problems with the //e extended memory usage once software uses it. I heard that they are working on a new one to get around this. Its amazing to see everything work faster. My main direction on return to Apple was to get 3.6 MHz built in. Look for it someday. Saturn has shown it's possible."
Apple Assembly Line 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 $12 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, all rights reserved.
Unless otherwise indicated, all material herein is authored by Bob Sander-Cederlof.
(Apple is a registered trademark of Apple Computer, Inc.)