Polling IKBD with its IRQ disabled

[charles]

Why are you stating no one is helping simonsunnyboy?

i knew he wanted a keypress with the mouse disabled,


i find it a disgrace that more individuals do not participate with these situations.
and to make this type of occurance troublesome is the fact we do not have this example in any of our libraries or routines allready.

us coders should compile a new set of routines :
example :

like object orienteed,
allowing us to pick and choose .

is it possable some combinations of this area are not previouslly explored?

i can't wait to discover what simon has cooked up next?

charles

[ijor]

I'm not sure what's exactly your problem, but seems what Hans mentioned. You have to delay and "flush" the keyboard output, otherwise you might get pending mouse packets.

[charles]

i got mine to work
but i had to use the nasty
~xbios(0,0,0,0)
to install a mouse handler which stopped the mouse
from entering this routine

'==========================
~xbios(0,0,0,0)
repeat
rkbd|=peek($fffc02)
if (rkbd|>0) and (rkbd|<115)
print at(1,3);using"#####",rkbd|
endif
until rkbd|=57 !press space bar to exit
'==========================
but the kicker is!!!!!!!!!!!!!!!!

ii had trouble reinstalling the

mouse handler ~xbios(0,2,L:a%,l:b%)

causeing the system to crash
boo hoo hoo boo hoo
gfa 3 manual says not to use it...with gem
the graphics environmental management!!!!
and the opposing
gfa manual
programmers reference v.1
states to use it so????????????????????????????????

i wonder how it coomplements lonnys lpgf-a program???
and really what i should do.
i been klacking on my keyboard now between gfa and omikron for the past month
and really devoted a whole day to look into this area.
whats up with the rest of you, any progress?

[lp]

charlie wrote:
i wonder how it coomplements lonnys lpgf-a program???

It has nothing to do with any of my programs whatsoever. If you compiled it as you should have and ran it from the desktop.

and really what i should do.

Well...

i been klacking on my keyboard now between gfa and omikron for the past month
and really devoted a whole day to look into this area.

Month? I thought you moved on to pascal. The best way to master something is to stick with it. Bouncing around from language to language is not a good idea. Especially in your case and I bet all the ones reading agree.

whats up with the rest of you, any progress?

I think Simon is very close to a solution. The rest of us are more than likely working on other things.

[Desty]

That's strange. I checked Tyler's 3D graphics book and he just does this:

Code: Select all

mse_off  pea mseoff_str
              move.w #0,-(sp)
              move.w #25,-(sp)
              trap #14
              addq.l #8,sp
              rts
...
mseoff_str dc.b $12

Does TOS do anything funny for that function that you're not doing?

[MiggyMog]

http://removers.free.fr/wikipendium/wak ... boardBible

[charles]

any body see any mistakes?

charles

[simonsunnyboy]

http://removers.free.fr/wikipendium/wak ... boardBible

Thanks but I definitly won't write a new firmware for the IKBD. Anyone else is welcome but I won't! Unless employed by Tramiel era Atari (which won't happen any time soon )

[simonsunnyboy]

** PROBLEM SOLVED **

However not with a custom IKBD routine but with the system one.
Reading the official STE developer documentation by Atari, I found that they suggested lowering the priority of the IKBD interrupt. Timer B will occur on time then and is rock stable (if you kill Timer C aswell).
The TOS IKBD handler stays intact and the GFA coder can still use INKEY$, INP(2) ets while the rasters are active.

The trick works by revectoring the IKBD IRQ through this small piece of code:

Code: Select all

new_ikbd:
  move #$2500,SR
  move.l old_ikbd,-(SP)
  rts
old_ikbd:
  DC.L 0

Simply copy the old contents of $118 to old_ikbd and hook new_ikbd into $118
With this added to my m68k raster control, everything is fine.

PS: Expect a standalone release of the raster code soon

[charles]

hey simon i am still following this topic ...but i am lost ,,,,
so how does this encorparate into the first peice of code you listed ,

so the long address of 0 is the old mouse vector?
thats what i make of it using my absent assembler knowledge,

do you have to reinstall the mouse vector to make every thing work?

charles

[simonsunnyboy]

Simply put, it removes the need for the front piece of code at all. I can simply revert back to using INP(2) and the like....as I use machine code anyway to setup my Timer B for the rasters, it is only a matter of a few more assembly instructions to add the mentioned routine.

For the mouse .... sofar it wasn't planned to make use of the mouse. It just interfered with the old version of code. maybe now you can use the mouse too...All I wanted was stability of my rasters

[charles]

simon
has the thread been concluded?
what were your results like ?
its been ten years

[thomas3]

Lol!

[charles]

I hate when I overlook the page tab on topics , makes me appear stupid ...lol
often im replying to the previous page's comment ...lol
im a dum dum ..sorry

[simonsunnyboy]

10 year necrobump, oh myyyyy - yes it was concluded back then. Nothing to add.