xbtimer data and count

[charles]

xbtimer ,
when i change these inputs , the data and the control
of timer c
i can make the timer act faster or slower.....

where in the memory of the atari do these values go?

i can't find them when i peek or poke ,,,

$fffa1d does not change ,its always 81
thats one of the 25 addresses at odd offset
for the hardware handoff vectors
and within the lpeek(lpeek($114)) i can get someinfo on data but as a 16 bit data struicture points to now where and values don't change .

any clues on the horizon ?

charles

[GroovyBee]

Charles you really should read some documentation, well any would help!

$fffa1d is not even a valid 68901 address . Its mapped in from $FFFA06 to $FFFA2E and accessed at even addresses in that range.

The address stored at $114 points to executable code. Doing the double lpeek on it is meaningless.

[Nyh]

xbtimer ,
when i change these inputs , the data and the control
of timer c
i can make the timer act faster or slower.....

First of all:
Do not change the frequency of timer C. TOS is using timer C for some of its functions. If you change timer C some things will fail or go wrong. Which things go wrong depends on the TOS version. The newer the TOS more things will go wrong.

Use timer A for your own purposes.

where in the memory of the atari do these values go?

They go into the Mfp registers.

$fffa1d does not change ,its always 81
thats one of the 25 addresses at odd offset
for the hardware handoff vectors
and within the lpeek(lpeek($114)) i can get someinfo on data but as a 16 bit data struicture points to now where and values don't change .

Well. You are doing something wrong. I wrote and tested this Omikron Basic program:

Code: Select all

PRINT PEEK($FFFA1D)
PRINT PEEK($FFFA23)
XBIOS (Tmp%L,31,2,113,255,L LPEEK($114))
PRINT PEEK($FFFA1D)
PRINT PEEK($FFFA23)
XBIOS (Tmp%L,31,2,81,192,L LPEEK($114))
PRINT PEEK($FFFA1D)
PRINT PEEK($FFFA23)

And its output is:
81
107
113
191
81
76
So Xbtimer works as it should work. If it doesn't for you then you are doing something wrong.

I do not understand why you do an lpeek(lpeek($114)) as this would give you the first 4 bytes of the interrupt handler. Nothing interesting to see there.

Hans Wessels

[Nyh]

Charles you really should read some documentation, well any would help!

$fffa1d is not even a valid 68901 address . Its mapped in from $FFFA06 to $FFFA2E and accessed at even addresses in that range

I don't know what kind of Atari you have but in the Atari ST series the Mfp is mapped at odd addresses from $FFFA01 to $FFFA2F.

$FFFA1D is a valid Mfp address and points to Timer C+D Control register

Hans Wessels

[charles]

the double lpeek at $114 will return the address of the timer ,
like how timer c is read at location $4ba
thats 1210 decimal ,
so i figure if you install a handler to user timer a
, this would apply to that timer to,

Well. You are doing something wrong. I wrote and tested this Omikron Basic program:

Code: Select all
PRINT PEEK($FFFA1D)
PRINT PEEK($FFFA23)
XBIOS (Tmp%L,31,2,113,255,L LPEEK($114))
PRINT PEEK($FFFA1D)
PRINT PEEK($FFFA23)
XBIOS (Tmp%L,31,2,81,192,L LPEEK($114))
PRINT PEEK($FFFA1D)
PRINT PEEK($FFFA23)

And its output is:
81
107
113
191
81
76

So Xbtimer works as it should work. If it doesn't for you then you are doing something wrong.

i don't know about that , using gfa in my experiment at the address $fffa23 would return differnt results , this number always changes as the program runs ,never stays the same.


groovey bee seems to be trying to lmisleed me , hes a bit of a chip off the old block as you say.


nyh i will try again , i have my results written down and i will double check , so from here how do we start timer a ? just stuff all these values in it using xbtimer at location $134 ?

charles

[Nyh]

the double lpeek at $114 will return the address of the timer ,
like how timer c is read at location $4ba
thats 1210 decimal

Well under Steem:
?hex$(lpeek($114))
$9d17e
?hex$(lpeek(lpeek($114))
$48e70002
?hex$(lpeek(lpeek($114)+4)
$4dfada6e

Which translates into:
$48e70002 -> movem.l A6,-(SP)
$4dfada6e -> lea $C79FA(PC),A6
Which is the start of the interrupt routine.

so i figure if you install a handler to user timer a
, this would apply to that timer to,

You figure completely wrong. The handler you install is the code that gets executed every time the MFP timer produces an timer A interrupt.

The problem is you don't know what an interrupt handler is. You still think timer C updates the value at $4ba by some kind of magic. Although no magic is involved writing interrupt routines is something for wizard level programmers with deep understanding on how the ST works.

i don't know about that , using gfa in my experiment at the address $fffa23 would return differnt results , this number always changes as the program runs ,never stays the same.

Of course it does. When $FFFA23 reaches 0 an interrupt is generated and the value starts again at 192. Counting down to zero at a frequency of 2457600/64 = 38400 Hz. 200*192*64 = 2457600 which is the base frequency of the Mfp timers.

nyh i will try again , i have my results written down and i will double check , so from here how do we start timer a ? just stuff all these values in it using xbtimer at location $134 ?

No, I can tell you how to program timer a as soon as you can tell me how interrupts work on the ST.

Hans Wessels

[charles]

well if you don't change the interrupt handler to c
then we can change the data and contrl values,,
but if we use a new"vector" with our own routine
we can replace this old vector and call it our own
,,,with a label.... but since
i don't know where to put the final value of the installed harware handler , i do not know where its value from

....c is lpeek($4ba)
but where is value from "a" timer returned?,

i can allready do this is a sort of mixed up way.
you just told me how interrupt works
i tryed and does not really change to much if i replace lpeek($114) with ...pointer(@mycode) in pascal

program install handler;

var
x:longint;

function mycode:longint;
begin
inc (x);
mycode:=x;
end;
end;

begin;
xbtimer(2,112,96,pointer(@mycode))
end.



somtimes pointer(pointer(mycode));
charles

[daeghnao]

well if you don't change the interrupt handler to c
then we can change the data and contrl values,,
but if we use a new"vector" with our own routine
we can replace this old vector and call it our own
,,,with a label.... but since
i don't know where to put the final value of the installed harware handler , i do not know where its value from

....c is lpeek($4ba)
but where is value from "a" timer returned?,

No, the value at location $4BA is _hz_200, which is incremented by the system's default interrupt handler for timer C. That is, when timer C interrupts, the processor calls the code at the address stored at $114, and some of the instructions in that routine happen to increment the value stored at $4BA. If you want to achieve this type of behaviour in your own routine, you will need to figure out a way to have the routine update a variable that's in scope for the parts of your code that want to read it.

i can allready do this is a sort of mixed up way.
you just told me how interrupt works
i tryed and does not really change to much if i replace lpeek($114) with ...pointer(@mycode) in pascal

program install handler;

var
x:longint;

function mycode:longint;
begin
inc (x);
mycode:=x;
end;
end;

begin;
xbtimer(2,112,96,pointer(@mycode))
end.

I'm no Pascal expert, so my interpretation of this may be a little rusty, but it looks like this sets up the timer to increment some value x and then exits? Given that the location x is only known to this program, and that the OS is now free to overwrite the memory that contains the interrupt handler at its leisure, this seems like an incredibly stupid idea.

somtimes pointer(pointer(mycode));
charles

What?

[GroovyBee]

$FFFA1D is a valid Mfp address and points to Timer C+D Control register

My mistake! Thats what it says in the Atari Compendium that I have here. I got the start address wrong too. Crawls back into bed...

[thothy]

i don't know about that , using gfa in my experiment at the address $fffa23 would return differnt results , this number always changes as the program runs ,never stays the same.

Maybe you should switch to another Basic ?

[charles]

this time you were funny thothy , an other basic , like omikron ? i like omikron v4
gfa 3. god too.

If you want to achieve this type of behaviour in your own routine, you will need to figure out a way to have the routine update a variable that's in scope for the parts of your code that want to read it.

d
thats the exact reason why i posted here , i want to use timer a as a timer.

so whats happening with what data , variable,control frequency, handler address do i do this with
to kill some time i did this , this illustrates the routine address and the data handoff vector now do i need to set a up in same fashion , and where does the value of the a timer get read from?

Code: Select all

'
old%=GEMDOS(32,L:0)
t%=LPEEK(&H114)
PRINT "lpeek: ";LPEEK(t%)   !this must be address of routine
PRINT "dpeek: ";DPEEK(t%+4) !this one is the address of contents(timer in this case)
PRINT "dpeek: ";DPEEK(t%+6) !clueless
PRINT "dpeek: ";DPEEK(t%+8) !clueless
PRINT "dpeek: ";DPEEK(t%+10)!clueless
PRINT "dpeek: ";DPEEK(t%+12)!clueless
PRINT "dpeek: ";DPEEK(t%+14)!clueless
PRINT
'
~XBIOS(2,7,121361,L:LPEEK(&H114))
'
LPOKE &H4BA,1
REPEAT
  a%=TIMER
  PRINT AT(30,1);a%
UNTIL a%>321
'
~XBIOS(2,128,64,L:LPEEK(&H114))
old%=GEMDOS(32,L:old%)
'




and after the timer reaches its maximum value the machine thinks its negative and begins counting backwards ,,,well gfa at least!!!!

[simonsunnyboy]

Whatever you are trying to do, it cannot work at all.
XBIOS call number 2 does not take any parameters ,it just returns one. A long, the current screen address.

[charles]

ahhhh !#$%@^

pascal is
xbtimer(2,x,x,addr)

and gfais
xbios(31,2,x,x,adr)


see my trouble...no its not skipping languages

but still i might need some help ..
thats why timer speed did not execute faster

simon i want you to live forever!!! ok?

charles

[charles]

OK THIS IS GOOD BUT NOW SINCE EVERY BODY SAYS THE SYSTEM IS DEPENDANT ON TIMER C, LETS SEPARATE THE SYSTEM FROM THE USER TIMER

CAN I DO SOMETHING LIKE THIS , USING TIMER A?
A TIMER A ?

Code: Select all


'
old%=GEMDOS(32,L:0)
t%=LPEEK(&H114)
PRINT "lpeek: ";LPEEK(t%)   !this must be address of routine
PRINT "dpeek: ";DPEEK(t%+4) !this one is the address of contents(timer in this case)
PRINT "dpeek: ";DPEEK(t%+6) !clueless
PRINT "dpeek: ";DPEEK(t%+8) !clueless
PRINT "dpeek: ";DPEEK(t%+10)!clueless
PRINT "dpeek: ";DPEEK(t%+12)!clueless
PRINT "dpeek: ";DPEEK(t%+14)!clueless
PRINT
'
nuts&=90
'
GOSUB xbtime
'
LPOKE &H4BA,1
'
REPEAT
  '
  ON MOUSEK GOSUB x,x,x
  '
  a%=TIMER
  PRINT AT(30,1);a%
  '
UNTIL INKEY$=" "
'
~XBIOS(31,2,112,64,L:LPEEK(&H114))
'
old%=GEMDOS(32,L:old%)
'
PROCEDURE x
  IF MOUSEK=1 AND nuts&>1
    DEC nuts&
    xbtime
  ELSE IF nuts&<65535 AND MOUSEK=2
    INC nuts&
    xbtime
  ENDIF
  PRINT AT(30,2);nuts&
RETURN
'
PROCEDURE xbtime
  ~XBIOS(31,2,nuts&,23,L:LPEEK(&H114))
RETURN





[Nyh]

so whats happening with what data , variable,control frequency, handler address do i do this with
to kill some time i did this , this illustrates the routine address and the data handoff vector now do i need to set a up in same fashion , and where does the value of the a timer get read from?

The value of timer A is no where!

Look at the code with a debugger.
Start bugaboo
type: dump $114
Then bugaboo shows a hexdump from address $114 and on.
The first 4 bytes are the address of the timer C interrupt routine, on my computer they are 00,0A,87,04
Disassemble this routine with:
dis $a8704

interrupt_rout.png

As you can see the first instruction is addq.l #1,$4bA.w, that is where the 200 Hz value is updated. The value is changed by the interrupt routine.

A very simple timer A counter interrupt routine would look like this:

Code: Select all

timer_A_handler:
     addq.l #1,timer_A_counter
     rte
timer_A_counter:
     dc.l 0

Hans Wessels