Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #5061 > unrolled thread

Assembly 80 column text

Back to article view | Back to comp.sys.apple2.programmer

Contents

  Assembly 80 column text Du Hast <duhast6377@gmail.com> - 2019-04-08 18:23 -0700
    Assembly 80 column text gids.rs@sasktel.net - 2019-04-08 18:57 -0700
      Assembly 80 column text gids.rs@sasktel.net - 2019-04-08 18:59 -0700
        Assembly 80 column text gids.rs@sasktel.net - 2019-04-08 19:06 -0700
          Assembly 80 column text Antoine Vignau <antoine.vignau@laposte.net> - 2019-04-09 06:19 -0700
            Re: Assembly 80 column text Du Hast <duhast6377@gmail.com> - 2019-04-09 18:23 -0700
              Re: Assembly 80 column text gids.rs@sasktel.net - 2019-04-09 19:51 -0700
                Re: Assembly 80 column text Du Hast <duhast6377@gmail.com> - 2019-04-10 17:25 -0700
                  Re: Assembly 80 column text D Finnigan <dog_cow@macgui.com> - 2019-04-11 00:50 +0000
                    Re: Assembly 80 column text Michael J. Mahon <mjmahon@aol.com> - 2019-04-10 20:40 -0500
                    Re: Assembly 80 column text Du Hast <duhast6377@gmail.com> - 2019-04-11 19:18 -0700
                      Re: Assembly 80 column text Antoine Vignau <antoine.vignau@laposte.net> - 2019-04-11 21:26 -0700
                      Re: Assembly 80 column text Michael J. Mahon <mjmahon@aol.com> - 2019-04-12 00:43 -0500
                        Re: Assembly 80 column text Antoine Vignau <antoine.vignau@laposte.net> - 2019-04-12 09:59 -0700
                        Re: Assembly 80 column text Michael Pohoreski <michael.pohoreski@gmail.com> - 2019-04-12 13:17 -0700
                          Re: Assembly 80 column text Antoine Vignau <antoine.vignau@laposte.net> - 2019-04-12 14:20 -0700
                            Re: Assembly 80 column text Michael Pohoreski <michael.pohoreski@gmail.com> - 2019-04-12 15:21 -0700
                          Re: Assembly 80 column text Michael J. Mahon <mjmahon@aol.com> - 2019-04-12 17:18 -0500
                        Re: Assembly 80 column text Du Hast <duhast6377@gmail.com> - 2019-04-12 15:15 -0700
                          Re: Assembly 80 column text Michael J. Mahon <mjmahon@aol.com> - 2019-04-12 17:25 -0500
                          Re: Assembly 80 column text gids.rs@sasktel.net - 2019-04-12 19:08 -0700
                  Re: Assembly 80 column text gids.rs@sasktel.net - 2019-04-10 21:52 -0700
                  Re: Assembly 80 column text James Davis <JPD.Enterprises@outlook.com> - 2019-04-11 19:19 -0700

Page 1 of 2  [1] 2  Next page →

#5061 — Assembly 80 column text

Forgive my crappy code as I'm just really diving into assembly.  Just using regular old Merlin in Applewin.  I'm trying to fill a line with a character pressed from the keyboard and I'm running into issues.  First it won't go to the line I want on the first go round.  I remember hearing that cursor position won't be updated until printed, and I did that with a space, but no love on that.  Also when it prints the line, the last character hangs out in one space and then moves backward through the line.  It's hard to explain, but I'm posting up the code and the hex for some guidance....



         ORG   $300

CHAR     EQU   $08
KYBD     EQU   $C000
STROBE   EQU   $C010
COUT     EQU   $FDED
CH       EQU   $24
CV       EQU   $25
HOME     EQU   $FC58

         JSR   HOME       ; CLEAR SCREEN
ENTRY    LDA   #$00       ; HORIZ TO 0
         STA   CH
         LDA   #$09       ; VERT TO 9
         STA   CV
         LDA   $A0        ; SPACE
         JSR   COUT       ; PRINT IT

READ     LDA   KYBD
         CMP   #$80       ; KEYPRESS?
         BCC   READ       ; NO, TRY AGAIN
         STA   STROBE     ; CLEAR KYBD STROBE
         CMP   #$9B       ; ESC?
         BEQ   RETURN     ; YES, QUIT
         STA   CHAR       ; SAVE CHAR
CLEAR    LDY   #$4F       ; 80 CHARS
         LDA   CHAR       ; GET CHAR
LOOP     JSR   COUT       ; PRINT IT
         DEY              ; COUNT-1
         BNE   LOOP       ; NOT ZERO
         JMP   ENTRY

RETURN   RTS

0300-   20 58 FC    JSR   $FC58    F8ROM:HOME
0303-   A9 00       LDA   #$00
0305-   85 24       STA   $24
0307-   A9 09       LDA   #$09
0309-   85 25       STA   $25
030B-   A5 A0       LDA   $A0
030D-   20 ED FD    JSR   $FDED    F8ROM:COUT
0310-   AD 00 C0    LDA   $C000    r:KBD  w:CLR80COL
0313-   C9 80       CMP   #$80
0315-   90 F9       BCC   $0310
0317-   8D 10 C0    STA   $C010    r:KBDSTRB
031A-   C9 9B       CMP   #$9B
031C-   F0 0F       BEQ   $032D
031E-   85 08       STA   $08
0320-   A0 4F       LDY   #$4F
0322-   A5 08       LDA   $08
0324-   20 ED FD    JSR   $FDED    F8ROM:COUT
0327-   88          DEY
0328-   D0 FA       BNE   $0324
032A-   4C 03 03    JMP   $0303
032D-   60          RTS

[toc] | [next] | [standalone]

#5063

The space by itself is caused by printing the 80th character which will cause a carriage RETURN of the screen which scrolls rhe screen up before the last character is printed.

Instead of 

LDA #9
STA CV
LDA #$A0
JSR $FDED

try this

LDA #9
JSR $FB5B

[toc] | [prev] | [next] | [standalone]

#5064

I meant a carriage RETURN on the screen but the screen will mot scroll

[toc] | [prev] | [next] | [standalone]

#5065

Another note

You are in 80-col mode and need to store the horizontal position in $57B, which is the 80-col horizontal position

[toc] | [prev] | [next] | [standalone]

#5066

The three above messages are great.
Note that you wrote $A0 (zero page addressing) instead of #$A0 (direct space char value) in the ENTRY routine

av

[toc] | [prev] | [next] | [standalone]

#5067

On Tuesday, April 9, 2019 at 9:19:51 AM UTC-4, Antoine Vignau wrote:
> The three above messages are great.
> Note that you wrote $A0 (zero page addressing) instead of #$A0 (direct space char value) in the ENTRY routine
> 
> av

They were great, and it's helped me out a lot in that things are working better now.  

So much of my confusion is interpreting the documentation.  TABV is never mentioned anywhere I could find.  Some docs were practically saying that CH and OURCH were interchangeable, which is doesn't seem like they are.  And I'm confused on some of the monitor routines.

Like clear line, CLEOLZ.  There's F.CLEOLZ, B.CLEOLZ, X.GSEOLZ.  What's Where just says they all clear the line, but obviously there must be a difference?

[toc] | [prev] | [next] | [standalone]

#5068

On Tuesday, April 9, 2019 at 7:23:08 PM UTC-6, Du Hast wrote:
> On Tuesday, April 9, 2019 at 9:19:51 AM UTC-4, Antoine Vignau wrote:
> > The three above messages are great.
> > Note that you wrote $A0 (zero page addressing) instead of #$A0 (direct space char value) in the ENTRY routine
> > 
> > av
> 
> They were great, and it's helped me out a lot in that things are working better now.  
> 
> So much of my confusion is interpreting the documentation.  TABV is never mentioned anywhere I could find.  Some docs were practically saying that CH and OURCH were interchangeable, which is doesn't seem like they are.  And I'm confused on some of the monitor routines.
> 
> Like clear line, CLEOLZ.  There's F.CLEOLZ, B.CLEOLZ, X.GSEOLZ.  What's Where just says they all clear the line, but obviously there must be a difference?


Sometimes the labels define the same address point depending on who labeled the source code.  But more often than not, multiple variations of the same label usually mean an alternate entry point for machine language programmers.

Take $F948, $F94A and $F94C, for instance.  All print a row of characters to the screen and basically call the same code, but with different entry points.

So, your code above can be reduced from:

         STA   CHAR       ; SAVE CHAR
CLEAR    LDY   #$4F       ; 80 CHARS
         LDA   CHAR       ; GET CHAR
LOOP     JSR   COUT       ; PRINT IT
         DEY              ; COUNT-1
         BNE   LOOP       ; NOT ZERO

to:

         LDX #$4F
         JSR $F94C

[toc] | [prev] | [next] | [standalone]

#5069

On Tuesday, April 9, 2019 at 10:51:41 PM UTC-4, gid...@sasktel.net wrote:
> On Tuesday, April 9, 2019 at 7:23:08 PM UTC-6, Du Hast wrote:
> > On Tuesday, April 9, 2019 at 9:19:51 AM UTC-4, Antoine Vignau wrote:
> > > The three above messages are great.
> > > Note that you wrote $A0 (zero page addressing) instead of #$A0 (direct space char value) in the ENTRY routine
> > > 
> > > av
> > 
> > They were great, and it's helped me out a lot in that things are working better now.  
> > 
> > So much of my confusion is interpreting the documentation.  TABV is never mentioned anywhere I could find.  Some docs were practically saying that CH and OURCH were interchangeable, which is doesn't seem like they are.  And I'm confused on some of the monitor routines.
> > 
> > Like clear line, CLEOLZ.  There's F.CLEOLZ, B.CLEOLZ, X.GSEOLZ.  What's Where just says they all clear the line, but obviously there must be a difference?
> 
> 
> Sometimes the labels define the same address point depending on who labeled the source code.  But more often than not, multiple variations of the same label usually mean an alternate entry point for machine language programmers.
> 
> Take $F948, $F94A and $F94C, for instance.  All print a row of characters to the screen and basically call the same code, but with different entry points.
> 
> So, your code above can be reduced from:
> 
>          STA   CHAR       ; SAVE CHAR
> CLEAR    LDY   #$4F       ; 80 CHARS
>          LDA   CHAR       ; GET CHAR
> LOOP     JSR   COUT       ; PRINT IT
>          DEY              ; COUNT-1
>          BNE   LOOP       ; NOT ZERO
> 
> to:
> 
>          LDX #$4F
>          JSR $F94C

Ok, but actually according to What's Where that routine just prints blanks.  Is there any really detailed breakdown of the entry points or is basically you have to go through the source code and figure it out?

[toc] | [prev] | [next] | [standalone]

#5070

Du Hast wrote:
> 
> Ok, but actually according to What's Where that routine just prints
> blanks.
> Is there any really detailed breakdown of the entry points or is basically
> you have to go through the source code and figure it out?
>

You can make your own entry points where ever you want. But for ROM
compatibility, you're only supposed to use Apple's published entry points.
They really bent over backwards to ensure that these entry points stayed the
same throughout ROM revisions.

Apple published the Monitor ROM entry points in its Apple II Reference
manuals for Apple II, II Plus, IIe, IIc, and so on.

-- 
]DF$
The New Apple II User's Guide:
https://macgui.com/newa2guide/

[toc] | [prev] | [next] | [standalone]

#5071

D Finnigan <dog_cow@macgui.com> wrote:
> Du Hast wrote:
>> 
>> Ok, but actually according to What's Where that routine just prints
>> blanks.
>> Is there any really detailed breakdown of the entry points or is basically
>> you have to go through the source code and figure it out?
>> 
> 
> You can make your own entry points where ever you want. But for ROM
> compatibility, you're only supposed to use Apple's published entry points.
> They really bent over backwards to ensure that these entry points stayed the
> same throughout ROM revisions.
> 
> Apple published the Monitor ROM entry points in its Apple II Reference
> manuals for Apple II, II Plus, IIe, IIc, and so on.
> 

But it’s worth noting that they chose to preserve many more entry points
than they documented. 

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#5073

On Wednesday, April 10, 2019 at 8:50:57 PM UTC-4, D Finnigan wrote:
> Du Hast wrote:
> > 
> > Ok, but actually according to What's Where that routine just prints
> > blanks.
> > Is there any really detailed breakdown of the entry points or is basically
> > you have to go through the source code and figure it out?
> >
> 
> You can make your own entry points where ever you want. But for ROM
> compatibility, you're only supposed to use Apple's published entry points.
> They really bent over backwards to ensure that these entry points stayed the
> same throughout ROM revisions.
> 
> Apple published the Monitor ROM entry points in its Apple II Reference
> manuals for Apple II, II Plus, IIe, IIc, and so on.
> 
> -- 
> ]DF$
> The New Apple II User's Guide:
> https://macgui.com/newa2guide/

I've been reading the manuals and what I'm not finding is what is the difference between the entry points.  The clear line example:

CLEOLZ $FC9E
F.CLEOLZ $C19C
B.CLEOLZ $C1D9
X.GSEOLZ $CD4E

Apple references state the first address.  What's Where describes all the others as "entry points for the clear line subroutine".  Just go with Apple?  How do you know what the others do besides trial and error or studying all the code?  The C series are in the 80 column card?

[toc] | [prev] | [next] | [standalone]

#5075

Go with Apple entry points. Those in the $F800..$FFFF area,

av

[toc] | [prev] | [next] | [standalone]

#5076

Du Hast <duhast6377@gmail.com> wrote:
> On Wednesday, April 10, 2019 at 8:50:57 PM UTC-4, D Finnigan wrote:
>> Du Hast wrote:
>>> 
>>> Ok, but actually according to What's Where that routine just prints
>>> blanks.
>>> Is there any really detailed breakdown of the entry points or is basically
>>> you have to go through the source code and figure it out?
>>> 
>> 
>> You can make your own entry points where ever you want. But for ROM
>> compatibility, you're only supposed to use Apple's published entry points.
>> They really bent over backwards to ensure that these entry points stayed the
>> same throughout ROM revisions.
>> 
>> Apple published the Monitor ROM entry points in its Apple II Reference
>> manuals for Apple II, II Plus, IIe, IIc, and so on.
>> 
>> -- 
>> ]DF$
>> The New Apple II User's Guide:
>> https://macgui.com/newa2guide/
> 
> I've been reading the manuals and what I'm not finding is what is the
> difference between the entry points.  The clear line example:
> 
> CLEOLZ $FC9E
> F.CLEOLZ $C19C
> B.CLEOLZ $C1D9
> X.GSEOLZ $CD4E
> 
> Apple references state the first address.  What's Where describes all the
> others as "entry points for the clear line subroutine".  Just go with
> Apple?  How do you know what the others do besides trial and error or
> studying all the code?  The C series are in the 80 column card?
> 

In the case of the above labels (but without looking at the monitor listing
:-), it looks to me like the only actual entry point is CLEOLZ. The other
labels look like labels that the main entry point transfers to in order to
perform its function. For example, I’d guess that X.GSEOLZ is the routine
added to the monitor to support the IIgs, and that the main entry point
goes here after determining that it’s running on a IIgs.  The other two
labels seem likely to be used in the stubs and vectors needed to transfer
to code in a different ROM bank. 

Listings like “What’s Where...” are most useful for reverse engineering
code, by providing hints about the purpose of a CALL or JSR. I don’t find
them particularly useful when writing code. 

Certainly these lists are no substitute for reading and understanding the
code, especially since the WW listings seldom describe registers preserved
or any “side effects” of the entry point. 

While reading code may seem like non-productive work, practice in reading
and understanding code is one of the very best ways to master assembly
language—especially when the code you’re reading is masterful code. ;-)

The monitor, particularly the original (the ][ and ][+), is very pretty
code, written mostly by Woz and his friend Allen Baum. Every time I read a
few pages I learn a new technique!  

Later monitors also contain fine code, but adding functions while
preserving the original entry points and visible memory footprint requires
a lot of dancing around that interferes with the original esthetic—or maybe
it’s just differently pretty:  in its achievement of backward
compatibility.  :-)
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#5078

I cannot agree more, Michael.

That is why I do not like reading the firmware code of the IIgs. It is, with the 65c02 Apple IIs, the slowest one among all the firmware available (comparison at 1MHz).

It is full of JMP, new softswitches to activate other ROM banks, etc.

The original firmware is cute and efficient but has less features.

Antoine

[toc] | [prev] | [next] | [standalone]

#5079

> Listings like “What’s Where...” are most useful for reverse engineering 
> code, by providing hints about the purpose of a CALL or JSR. I don’t find 
> them particularly useful when writing code. 

I guess it depends on the use case. The book "Apple Monitors Peeled" was
my mini-bible until I got a hold of the ROM listings.

I find having (or knowing) a set of "common" entry points is extremely
handy since I can leverage existing ROM snippets.

I think the takeaway is that "Context matters." i.e. Knowing what memory
locations are touched upon (Zero Page? Screen Holes? etc.) and what
registers are preserved across the various entries points is just as
important as knowing which ones are available for use. :-)


> The monitor, particularly the original (the ][ and ][+), is very pretty 
> code, written mostly by Woz and his friend Allen Baum. Every time I read a 
> few pages I learn a new technique!   

Agreed! The original Apple ][ ][+ $F800 ROM listing is a pure joy to read.
Still can't believe Woz managed to squeeze a mini disassembler in there!

Speaking of which, has anyone every "properly" documented the MNEML and MNEMR
tables ?  The original listing is a huge disappointment of hard-coded table
entries. :-/  About my only real complaint.

[toc] | [prev] | [next] | [standalone]

#5080

On Friday, April 12, 2019 at 10:17:22 PM UTC+2, Michael Pohoreski wrote:
(cut)
> Speaking of which, has anyone every "properly" documented the MNEML and MNEMR
> tables ?  The original listing is a huge disappointment of hard-coded table
> entries. :-/  About my only real complaint.

Download the source files at http://www.brutaldeluxe.fr/public/source/
Search for INSDS2, MNEML, OPTBL, etc. and I'm sure you'll understand (and be able to document) the tables ;-)

Antoine

[toc] | [prev] | [next] | [standalone]

#5083

Thanks Antoine!

The listing for the //c provides a nice opportunity to diff the original 6502 mnemonics support and where they added support for the 65C02 instructions.

Looks like this is the place to start:

* http://www.brutaldeluxe.fr/public/source/AUTOST1.TXT
* http://www.brutaldeluxe.fr/public/source/AUTOST2.TXT

Thanks again for the idea & files!

[toc] | [prev] | [next] | [standalone]

#5082

Michael Pohoreski <michael.pohoreski@gmail.com> wrote:
>> Listings like “What’s Where...” are most useful for reverse engineering 
>> code, by providing hints about the purpose of a CALL or JSR. I don’t find 
>> them particularly useful when writing code. 
> 
> I guess it depends on the use case. The book "Apple Monitors Peeled" was
> my mini-bible until I got a hold of the ROM listings.
> 
> I find having (or knowing) a set of "common" entry points is extremely
> handy since I can leverage existing ROM snippets.
> 
> I think the takeaway is that "Context matters." i.e. Knowing what memory
> locations are touched upon (Zero Page? Screen Holes? etc.) and what
> registers are preserved across the various entries points is just as
> important as knowing which ones are available for use. :-)
> 
> 
>> The monitor, particularly the original (the ][ and ][+), is very pretty 
>> code, written mostly by Woz and his friend Allen Baum. Every time I read a 
>> few pages I learn a new technique!   
> 
> Agreed! The original Apple ][ ][+ $F800 ROM listing is a pure joy to read.
> Still can't believe Woz managed to squeeze a mini disassembler in there!

And not only a mini-disassembler, but a mini-assembler that works by
incrementing the opcode and disassembling until the disassembly matches the
input line!  An implicit assembler—beautiful!

> Speaking of which, has anyone every "properly" documented the MNEML and MNEMR
> tables ?  The original listing is a huge disappointment of hard-coded table
> entries. :-/  About my only real complaint.

Everything is made clear by reading the code!  And after reverse
engineering, you will appreciate the encoding of the table(s). ;-)

Some problems should always be left to the reader.  Or as a comment in a
particularly tricky piece of code once pointed out, “If you don’t
understand this code, don’t try to change it!”

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#5081

On Friday, April 12, 2019 at 1:43:17 AM UTC-4, mjm...@aol.com wrote:
> Du Hast <duhast6377!gmail.com> wrote:
> > On Wednesday, April 10, 2019 at 8:50:57 PM UTC-4, D Finnigan wrote:
> >> Du Hast wrote:
> >>> 
> >>> Ok, but actually according to What's Where that routine just prints
> >>> blanks.
> >>> Is there any really detailed breakdown of the entry points or is basically
> >>> you have to go through the source code and figure it out?
> >>> 
> >> 
> >> You can make your own entry points where ever you want. But for ROM
> >> compatibility, you're only supposed to use Apple's published entry points.
> >> They really bent over backwards to ensure that these entry points stayed the
> >> same throughout ROM revisions.
> >> 
> >> Apple published the Monitor ROM entry points in its Apple II Reference
> >> manuals for Apple II, II Plus, IIe, IIc, and so on.
> >> 
> >> -- 
> >> ]DF$
> >> The New Apple II User's Guide:
> >> https://macgui.com/newa2guide/
> > 
> > I've been reading the manuals and what I'm not finding is what is the
> > difference between the entry points.  The clear line example:
> > 
> > CLEOLZ $FC9E
> > F.CLEOLZ $C19C
> > B.CLEOLZ $C1D9
> > X.GSEOLZ $CD4E
> > 
> > Apple references state the first address.  What's Where describes all the
> > others as "entry points for the clear line subroutine".  Just go with
> > Apple?  How do you know what the others do besides trial and error or
> > studying all the code?  The C series are in the 80 column card?
> > 
> 
> In the case of the above labels (but without looking at the monitor listing
> :-), it looks to me like the only actual entry point is CLEOLZ. The other
> labels look like labels that the main entry point transfers to in order to
> perform its function. For example, I’d guess that X.GSEOLZ is the routine
> added to the monitor to support the IIgs, and that the main entry point
> goes here after determining that it’s running on a IIgs.  The other two
> labels seem likely to be used in the stubs and vectors needed to transfer
> to code in a different ROM bank. 
> 
> Listings like “What’s Where...” are most useful for reverse engineering
> code, by providing hints about the purpose of a CALL or JSR. I don’t find
> them particularly useful when writing code. 
> 
> Certainly these lists are no substitute for reading and understanding the
> code, especially since the WW listings seldom describe registers preserved
> or any “side effects” of the entry point. 
> 
> While reading code may seem like non-productive work, practice in reading
> and understanding code is one of the very best ways to master assembly
> language—especially when the code you’re reading is masterful code. ;-)
> 
> The monitor, particularly the original (the ][ and ][+), is very pretty
> code, written mostly by Woz and his friend Allen Baum. Every time I read a
> few pages I learn a new technique!  
> 
> Later monitors also contain fine code, but adding functions while
> preserving the original entry points and visible memory footprint requires
> a lot of dancing around that interferes with the original esthetic—or maybe
> it’s just differently pretty:  in its achievement of backward
> compatibility.  :-)
> -- 
> -michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

Well I bought What's Where because it's the "canonical" listing and I was hoping that after 40 years there would be a nice easy reference to the monitor, but I guess not....

[toc] | [prev] | [next] | [standalone]

#5084

Du Hast <duhast6377@gmail.com> wrote:
> On Friday, April 12, 2019 at 1:43:17 AM UTC-4, mjm...@aol.com wrote:
>> Du Hast <duhast6377!gmail.com> wrote:
>>> On Wednesday, April 10, 2019 at 8:50:57 PM UTC-4, D Finnigan wrote:
>>>> Du Hast wrote:
>>>>> 
>>>>> Ok, but actually according to What's Where that routine just prints
>>>>> blanks.
>>>>> Is there any really detailed breakdown of the entry points or is basically
>>>>> you have to go through the source code and figure it out?
>>>>> 
>>>> 
>>>> You can make your own entry points where ever you want. But for ROM
>>>> compatibility, you're only supposed to use Apple's published entry points.
>>>> They really bent over backwards to ensure that these entry points stayed the
>>>> same throughout ROM revisions.
>>>> 
>>>> Apple published the Monitor ROM entry points in its Apple II Reference
>>>> manuals for Apple II, II Plus, IIe, IIc, and so on.
>>>> 
>>>> -- 
>>>> ]DF$
>>>> The New Apple II User's Guide:
>>>> https://macgui.com/newa2guide/
>>> 
>>> I've been reading the manuals and what I'm not finding is what is the
>>> difference between the entry points.  The clear line example:
>>> 
>>> CLEOLZ $FC9E
>>> F.CLEOLZ $C19C
>>> B.CLEOLZ $C1D9
>>> X.GSEOLZ $CD4E
>>> 
>>> Apple references state the first address.  What's Where describes all the
>>> others as "entry points for the clear line subroutine".  Just go with
>>> Apple?  How do you know what the others do besides trial and error or
>>> studying all the code?  The C series are in the 80 column card?
>>> 
>> 
>> In the case of the above labels (but without looking at the monitor listing
>> :-), it looks to me like the only actual entry point is CLEOLZ. The other
>> labels look like labels that the main entry point transfers to in order to
>> perform its function. For example, I’d guess that X.GSEOLZ is the routine
>> added to the monitor to support the IIgs, and that the main entry point
>> goes here after determining that it’s running on a IIgs.  The other two
>> labels seem likely to be used in the stubs and vectors needed to transfer
>> to code in a different ROM bank. 
>> 
>> Listings like “What’s Where...” are most useful for reverse engineering
>> code, by providing hints about the purpose of a CALL or JSR. I don’t find
>> them particularly useful when writing code. 
>> 
>> Certainly these lists are no substitute for reading and understanding the
>> code, especially since the WW listings seldom describe registers preserved
>> or any “side effects” of the entry point. 
>> 
>> While reading code may seem like non-productive work, practice in reading
>> and understanding code is one of the very best ways to master assembly
>> language—especially when the code you’re reading is masterful code. ;-)
>> 
>> The monitor, particularly the original (the ][ and ][+), is very pretty
>> code, written mostly by Woz and his friend Allen Baum. Every time I read a
>> few pages I learn a new technique!  
>> 
>> Later monitors also contain fine code, but adding functions while
>> preserving the original entry points and visible memory footprint requires
>> a lot of dancing around that interferes with the original esthetic—or maybe
>> it’s just differently pretty:  in its achievement of backward
>> compatibility.  :-)
>> -- 
>> -michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com
> 
> Well I bought What's Where because it's the "canonical" listing and I was
> hoping that after 40 years there would be a nice easy reference to the
> monitor, but I guess not....
> 

You’re probably looking for something more like “The Apple Monitor Peeled”,
but it’s a bit harder to find in hard copy. And, frankly, no documentation
is as good as reading and understanding the code itself. The original
monitor is only 2KB, and well worth understanding. 

For Applesoft, I recommend “All About Applesoft”, a collection of
explanatory articles that is an excellent introduction to the Applesoft ROM
and its uses. 

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.sys.apple2.programmer

csiph-web