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

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

Example high-res assembly program

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

Contents

  Example high-res assembly program D Finnigan <dog_cow@macgui.com> - 2013-10-29 15:42 +0000
    Re: Example high-res assembly program Michael J. Mahon <mjmahon@aol.com> - 2013-10-29 13:08 -0500
      Re: Example high-res assembly program D Finnigan <dog_cow@macgui.com> - 2013-10-29 18:17 +0000
        Re: Example high-res assembly program Antoine Vignau <antoine.vignau@laposte.net> - 2013-10-29 11:27 -0700
        Re: Example high-res assembly program Michael J. Mahon <mjmahon@aol.com> - 2013-10-29 19:59 -0500
      Re: Example high-res assembly program aiiadict@gmail.com - 2013-10-29 13:51 -0700
        Re: Example high-res assembly program Antoine Vignau <antoine.vignau@laposte.net> - 2013-10-29 14:47 -0700
          Re: Example high-res assembly program aiiadict@gmail.com - 2013-10-30 10:02 -0700
            Re: Example high-res assembly program David Schmidt <schmidtd@my-deja.com> - 2013-10-30 13:10 -0400
              Re: Example high-res assembly program aiiadict@gmail.com - 2013-10-30 10:35 -0700
            Re: Example high-res assembly program Antoine Vignau <antoine.vignau@laposte.net> - 2013-10-31 11:13 -0700
              Re: Example high-res assembly program aiiadict@gmail.com - 2013-11-01 09:02 -0700
        Re: Example high-res assembly program aiiadict@gmail.com - 2013-10-31 09:49 -0700
          Re: Example high-res assembly program qkumba <peter.ferrie@gmail.com> - 2013-10-31 10:55 -0700
          Re: Example high-res assembly program aiiadict@gmail.com - 2013-11-01 10:52 -0700
            Re: Example high-res assembly program Michael J. Mahon <mjmahon@aol.com> - 2013-11-01 15:00 -0500
              Re: Example high-res assembly program aiiadict@gmail.com - 2013-11-02 09:48 -0700

#925 — Example high-res assembly program

Following is a program that I wrote that uses paddles 0 and 1 to define X
and Y coordinates for the end point of a line segment that begins in the
upper left corner of the screen. It uses Monitor routines PREAD and WAIT. It
uses some high-res Applesoft entry points too.

Here are these Applesoft entry points and their arguments:

1.) HGR - $F3E2
Clears the screen just like the BASIC command

2.) HGR2 - $F3D8
Just like the BASIC command; shows page 2 with no text at bottom

3.) HCOLOR - $F6F0
Takes a hi-res color, 0-7, in the X register

4.) HPLOT - $F457
Plots a single point. Also calls HPSON in advance.
A-reg = vert. coord
X-reg = horiz. coord, low-byte
Y-reg = horiz. coord, high-byte

5.) HLINE - $F53A
Draws a line anywhere on the screen, starting from the initial cursor
position, which can be altered with HPSON.
A-reg = horiz. coord, low-byte
X-reg = horiz. coord, high-byte
Y-reg = vert. coord

6.) HPOSN - $F411
This will set the initial cursor position.
The arguments re the same as HPLOT.


Just as a reminder, the high-res screen boundaries are 280 points
horizontal, by 192 vertical (with no text), or 160 vertical (with text).


Here is the Paddle Line program:

ORG $0300
JSR $F3E2 ; HGR
LDX #$03 ; HCOLOR 3
JSR $F6F0 ; SET HCOLOR
LDA #$00 ; INITIAL COORDS
TAX ; ALL ZERO
TAY ; ALL ZERO
JSR $F411 ; SET HPSON
LDX #$00 ; GET PADDLE 0 (HORIZ)
JSR $FB1E ; PREAD RETURNS IN Y-REG
TYA ; MOVE TO ACCUM
PHA ; SAVE ON STACK
JSR $FCA8 ; DELAY NECESSARY FOR PREAD
LDX #$01 ; GET PADDLE 1 (VERT)
JSR $FB1E ; PREAD
CPY #$A1 ; IS RESULT < 161?
BCC $0324 ; YES, SO SKIP NEXT
LDY #$A0  ; NO, SO LIMIT TO 160
LDX #$00 ; HORIZ. HIGH-BYTE ALWAYS ZERO
PLA ; GET SAVED HORIZ. LOW-BYTE FROM STACK
JSR $F53A ; HLINE
LDA #$FF ; LONG DELAY
JSR $FCA8 ; WAIT
JMP $0300 ; BEGIN AGAIN

I wrote this program using a pen and paper. My reference books were the
white Apple II manual and the Stanton arcade graphics book. I typed it in
and executed it on a platinum IIe with a b&w Apple composite monitor. It
worked the first time.

I have no idea what this program looks like on a color monitor, or with an
emulator.

Further Technical notes:

I wrote this program assuming that the subroutines would NOT preserve the
CPU registers. This may or may not be true in all cases, so it may be that
the program could be optimized.

It is necessary to let some amount of time pass between consecutive reads of
the paddles. The first delay is based on the initial paddle reading. If it's
0, then the delay may not be long enough, which could adversely affect the
reading of paddle 1. In most cases, this result is probably inconsequential.

-- 
]DF$
Apple II Book: http://macgui.com/newa2guide/
Usenet: http://macgui.com/usenet/  <-- get posts by email!
Apple II Web & Blog hosting: http://a2hq.com/

[toc] | [next] | [standalone]

#928

D Finnigan <dog_cow@macgui.com> wrote:
> Following is a program that I wrote that uses paddles 0 and 1 to define X
> and Y coordinates for the end point of a line segment that begins in the
> upper left corner of the screen. It uses Monitor routines PREAD and WAIT. It
> uses some high-res Applesoft entry points too.
> 
> Here are these Applesoft entry points and their arguments:
> 
> 1.) HGR - $F3E2
> Clears the screen just like the BASIC command
> 
> 2.) HGR2 - $F3D8
> Just like the BASIC command; shows page 2 with no text at bottom
> 
> 3.) HCOLOR - $F6F0
> Takes a hi-res color, 0-7, in the X register
> 
> 4.) HPLOT - $F457
> Plots a single point. Also calls HPSON in advance.
> A-reg = vert. coord
> X-reg = horiz. coord, low-byte
> Y-reg = horiz. coord, high-byte
> 
> 5.) HLINE - $F53A
> Draws a line anywhere on the screen, starting from the initial cursor
> position, which can be altered with HPSON.
> A-reg = horiz. coord, low-byte
> X-reg = horiz. coord, high-byte
> Y-reg = vert. coord
> 
> 6.) HPOSN - $F411
> This will set the initial cursor position.
> The arguments re the same as HPLOT.
> 
> 
> Just as a reminder, the high-res screen boundaries are 280 points
> horizontal, by 192 vertical (with no text), or 160 vertical (with text).
> 
> 
> Here is the Paddle Line program:
> 
> ORG $0300
> JSR $F3E2 ; HGR
> LDX #$03 ; HCOLOR 3
> JSR $F6F0 ; SET HCOLOR
> LDA #$00 ; INITIAL COORDS
> TAX ; ALL ZERO
> TAY ; ALL ZERO
> JSR $F411 ; SET HPSON
> LDX #$00 ; GET PADDLE 0 (HORIZ)
> JSR $FB1E ; PREAD RETURNS IN Y-REG
> TYA ; MOVE TO ACCUM
> PHA ; SAVE ON STACK
> JSR $FCA8 ; DELAY NECESSARY FOR PREAD
> LDX #$01 ; GET PADDLE 1 (VERT)
> JSR $FB1E ; PREAD
> CPY #$A1 ; IS RESULT < 161?
> BCC $0324 ; YES, SO SKIP NEXT
> LDY #$A0  ; NO, SO LIMIT TO 160
> LDX #$00 ; HORIZ. HIGH-BYTE ALWAYS ZERO
> PLA ; GET SAVED HORIZ. LOW-BYTE FROM STACK
> JSR $F53A ; HLINE
> LDA #$FF ; LONG DELAY
> JSR $FCA8 ; WAIT
> JMP $0300 ; BEGIN AGAIN
> 
> I wrote this program using a pen and paper. My reference books were the
> white Apple II manual and the Stanton arcade graphics book. I typed it in
> and executed it on a platinum IIe with a b&w Apple composite monitor. It
> worked the first time.
> 
> I have no idea what this program looks like on a color monitor, or with an
> emulator.
> 
> Further Technical notes:
> 
> I wrote this program assuming that the subroutines would NOT preserve the
> CPU registers. This may or may not be true in all cases, so it may be that
> the program could be optimized.
> 
> It is necessary to let some amount of time pass between consecutive reads of
> the paddles. The first delay is based on the initial paddle reading. If it's
> 0, then the delay may not be long enough, which could adversely affect the
> reading of paddle 1. In most cases, this result is probably inconsequential.

The speedup of this loop resulting from the use of assembly language is
quite minimal relative to the same loop in Applesoft. This is because most
of the time is spent in the Applesoft paddle and plot routines. 

The real motivation for using assembly language for graphics is to create
faster routines for doing these things, by special-casing and table-driven
methods. 

The same is true for any code that spends most of its time in called
subroutines--the speed of the calling loop is dominated by the called
routines, not the loop code. Floating-point computations are another
example. 

-- 
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

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

#929

Michael J. Mahon wrote:
> 
> The speedup of this loop resulting from the use of assembly language is
> quite minimal relative to the same loop in Applesoft. This is because most
> of the time is spent in the Applesoft paddle and plot routines. 
> 
> The real motivation for using assembly language for graphics is to create
> faster routines for doing these things, by special-casing and table-driven
> methods. 

I wrote this program for ep88theman, to show him the absolute basics of how
to use the Applesoft high-res routines from assembly language. I decided on
paddle input to make the program more amusing.

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

#930

Even if Michael is right once more, David answers the initial question ;-)

Av

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

#933

D Finnigan <dog_cow@macgui.com> wrote:
> Michael J. Mahon wrote:
>> 
>> The speedup of this loop resulting from the use of assembly language is
>> quite minimal relative to the same loop in Applesoft. This is because most
>> of the time is spent in the Applesoft paddle and plot routines. 
>> 
>> The real motivation for using assembly language for graphics is to create
>> faster routines for doing these things, by special-casing and table-driven
>> methods. 
> 
> I wrote this program for ep88theman, to show him the absolute basics of how
> to use the Applesoft high-res routines from assembly language. I decided on
> paddle input to make the program more amusing.

I understand. However several other responders have also pointed the OP to
Applesoft ROM graphics routines. 

It's a way to get one's feet damp, but it could more easily be done
completely in Applesoft, which would equally serve for HGR orientation. 

If he wants to learn M/L graphics, the ROM routines aren't going to be in
his future...
-- 
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

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

#931

On Tuesday, October 29, 2013 11:08:39 AM UTC-7, mjm...@aol.com wrote:
> The real motivation for using assembly language for graphics is to create 
> faster routines for doing these things, by special-casing and table-driven
> methods. 

table driven HGR access is easy:

make the table:
http://rich12345.tripod.com/prog/lookupgen.html

make the graphics:
http://rich12345.tripod.com/bse/index.html

draw the shapes on screen:
http://rich12345.tripod.com/srccode/graphic.html 

SCRN function for HGR screen:
http://rich12345.tripod.com/prog/hirescrn.html

I will post HPLOT function in assembly language when
I find it on my drive.


Rich

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

#932

Ahem. On which page do you output data?
Av

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

#934

On Tuesday, October 29, 2013 2:47:12 PM UTC-7, Antoine Vignau wrote:
> Ahem. On which page do you output data?
> 
> Av

me?

http://rich12345.tripod.com/prog/lookupgen.html

generate lookup table for HGR  (not hgr2!)

40 yl = 8192 + y2*40+ys*128+yr * 1024

8192 = $2000, HGR (not HGR2)

to generate a table for hgr2, change line
40 to:

40 yl = 16384 + y2*40+ys*128+yr * 1024

I am going to write it all up better and
link the pages for easier access.

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

#935

On 10/30/2013 1:02 PM, aiiadict@gmail.com wrote:
> http://rich12345.tripod.com/prog/lookupgen.html
>
> I am going to write it all up better and
> link the pages for easier access.

10 fory y = 0 to 191
...
70 nexty

?NEXT WITHOUT FOR ERROR IN 70

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

#936

On Wednesday, October 30, 2013 10:10:43 AM UTC-7, schmidtd wrote:
> On 10/30/2013 1:02 PM, @gmail.com wrote:
> 
> > http://rich12345.tripod.com/prog/lookupgen.html
> > I am going to write it all up better and
> 
> > link the pages for easier access.
> 
> 10 fory y = 0 to 191 
> 70 nexty
> ?NEXT WITHOUT FOR ERROR IN 70

tHANKS, FIXED.

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

#939

On Wednesday, October 30, 2013 6:02:40 PM UTC+1, aiia...@gmail.com wrote:
> On Tuesday, October 29, 2013 2:47:12 PM UTC-7, Antoine Vignau wrote:
> 
> > Ahem. On which page do you output data?
> 
> > Av
> 
> me?
> 

Yes, you. Sorry, replying from my smartphone does not include the thread's data therefore I am sometimes difficult to follow.

I said so because I like the use of HPAG, the zero page value which contains either #$20 or #$40. The lookup table generation does not need the +8192 or +16384 information.

         LDA   THI,Y
         ora   HPAG
         STA   SHI

Antoine

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

#940

On Thursday, October 31, 2013 11:13:31 AM UTC-7, Antoine Vignau wrote:
> On Wednesday, October 30, 2013 6:02:40 PM UTC+1, aiia...@gmail.com wrote:
> 
> > On Tuesday, October 29, 2013 2:47:12 PM UTC-7, Antoine Vignau wrote:
> 
> > 
> 
> > > Ahem. On which page do you output data?
> 
> > 
> 
> > > Av
> 
> > 
> 
> > me?
> 
> > 
> 
> 
> 
> Yes, you. Sorry, replying from my smartphone does not include the thread's data therefore I am sometimes difficult to follow.
> 
> 
> 
> I said so because I like the use of HPAG, the zero page value which contains either #$20 or #$40. The lookup table generation does not need the +8192 or +16384 information.
> 
> 
> 
>          LDA   THI,Y
> 
>          ora   HPAG
> 
>          STA   SHI
> 
> 
> 
> Antoine


oh ok, thanks.  I was wondering about this while I posted my reply.

Rich

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

#937

On Tuesday, October 29, 2013 1:51:45 PM UTC-7, aiia...@gmail.com wrote:
> I will post HPLOT function in assembly language when
> 
> I find it on my drive.
> 

hplot a pixel from assembly (doesn't use applesoft ROM, so i guess I shouldn't call it hplot)

 http://rich12345.tripod.com/prog/hplotassy.html      

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

#938

you can remove both CLCs and the SEC.  The carry is controlled completely by the CMP.

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

#941

On Thursday, October 31, 2013 9:49:13 AM UTC-7, aiia...@gmail.com wrote:
> On Tuesday, October 29, 2013 1:51:45 PM UTC-7, aiia...@gmail.com wrote:
> 
> > I will post HPLOT function in assembly language when
> 
> > 
> 
> > I find it on my drive.
> 
> > 
> 
> 
> 
> hplot a pixel from assembly (doesn't use applesoft ROM, so i guess I shouldn't call it hplot)
> 
> 
> 
>  http://rich12345.tripod.com/prog/hplotassy.html

here is hplot a line from assembly:

http://rich12345.tripod.com/prog/breslines.html

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

#942

<aiiadict@gmail.com> wrote:
> On Thursday, October 31, 2013 9:49:13 AM UTC-7, aiia...@gmail.com wrote:
>> On Tuesday, October 29, 2013 1:51:45 PM UTC-7, aiia...@gmail.com wrote:
>> 
>>> I will post HPLOT function in assembly language when
>> 
>>> 
>> 
>>> I find it on my drive.
>> 
>>> 
>> 
>> 
>> 
>> hplot a pixel from assembly (doesn't use applesoft ROM, so i guess I
>> shouldn't call it hplot)
>> 
>> 
>> 
>>  http://rich12345.tripod.com/prog/hplotassy.html
> 
> here is hplot a line from assembly:
> 
> http://rich12345.tripod.com/prog/breslines.html

Since X coordinates can be larger than 255, your routines are somewhat
limited. 

Further, in computing DELTAX and DELTAY, you can't use the sign of the
result in any useful way--use the Carry bit instead (not Carry == Borrow). 

I didn't read further...
-- 
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

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

#943

On Friday, November 1, 2013 1:00:27 PM UTC-7, mjm...@aol.com wrote:
> <@gmail.com> wrote:
> 
> > On Thursday, October 31, 2013 9:49:13 AM UTC-7, aiia...@gmail.com wrote:
> 
> >> On Tuesday, October 29, 2013 1:51:45 PM UTC-7, aiia...@gmail.com wrote:
> 
> >> 
> 
> >>> I will post HPLOT function in assembly language when
> 
> >> 
> 
> >>> 
> 
> >> 
> 
> >>> I find it on my drive.
> 
> >> 
> 
> >>> 
> 
> >> 
> 
> >> 
> 
> >> 
> 
> >> hplot a pixel from assembly (doesn't use applesoft ROM, so i guess I
> 
> >> shouldn't call it hplot)
> 
> >> 
> 
> >> 
> 
> >> 
> 
> >>  http://rich12345.tripod.com/prog/hplotassy.html
> 
> > 
> 
> > here is hplot a line from assembly:
> 
> > 
> 
> > http://rich12345.tripod.com/prog/breslines.html
> 
> 
> 
> Since X coordinates can be larger than 255, your routines are somewhat
> 
> limited. 
> 

I know...  but when I wrote that I didn't have need to plot with x > 255

> 
> 
> Further, in computing DELTAX and DELTAY, you can't use the sign of the 
> result in any useful way--use the Carry bit instead (not Carry == Borrow). 
> 

I will take a look at that.

Rich

[toc] | [prev] | [standalone]

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

csiph-web