Re: A89: More stron89 help (new questions)
[Prev][Next][Index][Thread]
Re: A89: More stron89 help (new questions)
S43R80@aol.com wrote:
> CODE-------------------------------------------------
> First of all if anyone is wondering how the clearscreen routine works I will
> try to explain:
> ClearLines:
> move.l #00,(a0)+
> move.l #00,(a0)+
> move.l #00,(a0)+
> move.l #00,(a0)+
> move.l #00,(a0)+
> add.l #10,a0
> sub.w #1,d0
> tst.w d0
> bne ClearLines
> rts
>
> ; ** Clear out screen buffer at a0.l
> ; INPUT: a0.l=screen offset
> ClearScreen:
> move.l d0,-(a7) ; save d0
> move.w #100,d0
> bsr ClearLines
> move.l (a7)+,d0 ; restore d0
> rts
>
> Prior to this #LCD_MEM (the screen offset) was moved into a0...Now 100 is
> moved into d0 because that is how many pixels there are on the screen (in the
> y direction)...Now you jump to the label ClearLines...Now you push the
> longword 0(that would be 32 0's(4 bytes)) onto the screen...You do this 5
> times because 5*32=160(the x direction pixels). The next line then updates
> a0(so it doesn't crash when you leave the routine i think)...d0 contained
> 100(y direction) so you need to do the same thing 100 times (1 time for every
> line going down)...after you did the first line you subtracted 1 from this so
> you can keep track of how manytimes you need to do it...now after the 100th
> time d0 will be 0...it is tested to see what flags are set...now if the zflag
> is set it means d0 is 0 and the routine has been done 100 times, hence the
> screen is cleared! then you return back...
>
> I doubt that paragraph helped anyone, but it helped me a little just by
> writing it down...If i said something wrong...please tell me...
>
> 1 question though: Shouldn't there be a rom call that does this for you???
You are right exept for one thing. "add.l #10,a0" is not to prevent the
routine to crash when it exits.. its because of the format on the screen of the
89..
the screenram is identical to the screenram on the 92. but the screen is
smaller.. so on every line, there is 10 bytes that is not visible.. (the 92 har
a 240 pixel wide screen)
that add is skipping thoose bytes that is not shown anyway.. speeding up the
routine a bit..
>
> Ok...my real problem lies with this routine:
> ; ** Program Initialization
> DoProgramInit:
> move.w #$700,d0 ; Disable interrupts, saving old in mask
> in d0
> trap #1
> bclr.b #2,($600001) ; disable memory protection
> move.l ($64),Old_Int1 ; save old int1 address
> move.l #New_Int1,($64) ; set int1 to New_Int1
> bset.b #2,($600001) ; reenable memory protection
> trap #1 ; restore old interrupt
> mask (from d0)
> ***FOUND LATER ON:***
> New_Int1: ; empty INT 1
> rte
> Old_Int1 dc.l 0
>
> ???'s
> 1. So clearing the 2nd bit in ($600001) will disable memory protection?
> 2. What is memory protection?
> 3. ($64) is the location of int1?
> 3.b What is int1 for? What does it do?
> 4. Does dc.l 0 just reserve space?
> 5. Now the author makes the new int1 be this instead...why?
> New_Int1: ;
> rte
> This seems to be doing nothing???
> 6. I imagine rte to be a return command...but i couldn't find it
> anywhere...what is the difference between rte and rts?
> 7. Now if he restores the old interrupt...what was the use of him changing
> it???
1. the protected ram is the ram below $120. it is protected because it holds
vital systeminformation, like all interrupt vectors, and trap vectors and stuff
like that
2. if you try to write to memory below $120 int 7 will be called instead..
3. Yes
3.b read the docs that come with FargoII (I think it is in the DoorsOS docs to)
I'm not sure exactly what it does, but it is called approx. 350 times per
second. whatever it does it will speed up some if you disable it.
4. "dc.l 0" is defineing a long with the value of 0
5. He is replaceing int 1 with another routine, that does nothing.. this is to
disable int 1..
6. rte is what I can see used to return from interrupts, rts to return from
subroutines..
7. I assume he doesnt restore it until the end of the program?
> Thanks for your help on my last questions, Mr. Hedman. I hope you can be as
> enligtening as you were in your last post; I think I am at least progressing
> somewhat...
>
> -Steve-
np. knowledge is meant to be shared..
//Olle
References: