From: Rick_Michael_Cortese@cup.portal.com
Newsgroups: comp.sys.atari.8bit
Subject: Re: Cortese's 6502 sample (was Re: Quest for Refresh)
Date: Thu,  8 Oct 92 13:45:32 PDT
Organization: The Portal System (TM)

;I don't know what the original article was about,
Jeff & I were talking here & through E-Mail about two things: How to
interface Action! to M/L routines & how to develop code for something
like a 65816. I just wanted to show how to & if anyone wanted to
rewrite some of Action!'s PROCs, to work as a 65816 compiler it
wouldn't be a problem.
;I have a better solution...  (care to comment?)
start   sta string
        stx string+1
;
        lda #$4C
        sta putvec
>not bad, saves 3 or 4 bytes
        ldx editput
        ldy editput+1
        inx
        bne st2
        iny
st2     stx putvec+1
        sty putvec+2
;
loop    ldy #0
        lda (string),y
        beq end
        inc string
>mistake, unless you wanted to
>only print one character or whatever
>happens to be at [string+256, string+512, ...]
>       BNE ST3
        beq st3
        inc string+1
st3     jsr putvec
        bpl loop     ;branch if no error returned
>I suppose this is standard, but I didn't want it to terminate on a
>mistake. Really, I don't think you can ever have a mistake. The OS
>is written such that even if you don't have the screen open for text
>i.e. GR.(24), the OS will GR.(0), print the character & return no
>error. I suppose if we're counting cycles & bytes & you want to get
>cute here, you could move the loop to the lda (string),y then
>DEY BEQ loop since y reg will always come back with a #1, but then
>only people that would understand what we're doing are Atari 6502
>programmers.
>BTW: If you were planning on it being faster then my routine, the
>way it's written it only saves a couple of machine cycles/call.
>Since the 6502 does about 400,000 instructions/sec for something
>like a CLC, even for printing a 1000 chars the extra time involved
>relative to what the screen routines take is almost undetectable.
>Just for arguments sake, I ran the two routines as Action! calls
>(After correcting the BEQ of course)
>each printing 800 bytes 4 times: Took 476 tics for both routines.
>So as far as our ability to time jiffies goes, no dif detectable
>in something that takes over 7 secs.  The screen handler is the
>thing that really eats up the cycles. All the positioning, inversing
>the char under the cursor, scrolling the screen, takes so long that
>even if you wrote code that made a bunch of assumptions, it still
>wouldn't be much faster.
        rts
        .end
It was just supposed to be an example! If I was in Action! I would
never write a call to do something like that. I'd never encourage
anyone else to either. One last time trial<g>. I'd guess between
looking up the free page zero locations under MAC/65, DDT, & writting
the actual code & translating it to an Action! call with plugging &
unplugging carts, it took me about an hour, probably more, to get the
thing written. To do the same thing in Action!, it's just:

bptr=stuff
WHILE bptr^<>0
DO
 PUT(bptr^)
 bptr==+1
OD

5 lines of code to replace 25 lines of ML & if you want to push it,
the way the compiler is written, you could put everything on one
line! To be as fair to ML as possible, I only printed 800 char so the
screen scroll routines would not be added. Ended up Action! ran at
72% compared to ML.  I'd bet it took me less then a minute to type
out the Action! routine.  Anyway, that's why I'm such an Action! fan.
I usually get about 50% to 99% of the equivalent M/L routine without
having to worry if I did a BEQ or BNE & it doesn't take me a tenth of
the time to code compared to M/L.