gfa keyboard vector table /midi vector how to swap?

GFA BASIC-related articles in here please

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
charles
10 GOTO 10
10 GOTO 10
Posts: 2407
Joined: Tue Aug 17, 2004 12:11 am
Location: ont. Canada
Contact:

gfa keyboard vector table /midi vector how to swap?

Postby charles » Sat Jan 13, 2007 1:43 am

i am desprite researching how to swap then restore keyboard /midi vectors within gfa ...any ideals..

callaghan
The radioactive half-life : )
Atari is a lifestyle,not a hobby.
HOLD ON ! ! ! Im printing unreadable characters ...!

User avatar
lp
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2368
Joined: Wed Nov 12, 2003 11:09 pm
Location: GFA Headquarters
Contact:

Postby lp » Mon Jan 15, 2007 4:10 am

Requires assembler.

User avatar
charles
10 GOTO 10
10 GOTO 10
Posts: 2407
Joined: Tue Aug 17, 2004 12:11 am
Location: ont. Canada
Contact:

aseembler?

Postby charles » Mon Jan 15, 2007 4:56 am

why did not mention this in gfa manual?
it does not say anything about using assembler in the manual to place a vector in any other location..this is only a minor set back...i shall succed..

its xbios(34) and xbios(14,2) that i desire to alter and "mesh" about with.

so really no way to alter ???i am disappointed , talk about disapointed..
-----------------------------------------------------------------------------
i have found an other gfa mis direct as well .
its to do with the resource file tedinfo ob_spec information for the g_box,g_ibox_and g_boxchar
ascii code for draw,frame and object color...
i bet simon sunny cr is interested in this find..
the manual has no # or text written in for g_box,
i feel it should be written in on top of g_text ..g_box is 20.
which by the way is OB_TYPE=20
and has no diagram like the following examples of the flags and the states....so for the ob_spec if a bit reprensentation of a binary number is nessesary its made up of all listed numbers and some that weren't even indicated within book!!!!
wow still only couple years into programming but getting to grips with it..
i would encourage any body whoms interested in finding ouot exactlly
whats in a resource file to construct what i did ...a resource ripper program.. all locations of memory used by ~rsrc_load are examined and the specs are printed to the screen.for each object and tree within the resource file..whew thats a long post i did!!
but its good reducing the areas of large unknown gfa stuff.

done!

callaghan

i don't like assembler.i like gfa.
The radioactive half-life : )
Atari is a lifestyle,not a hobby.
HOLD ON ! ! ! Im printing unreadable characters ...!

User avatar
daeghnao
Captain Atari
Captain Atari
Posts: 479
Joined: Wed Oct 27, 2004 12:41 pm
Location: York, UK
Contact:

Re: aseembler?

Postby daeghnao » Mon Jan 15, 2007 11:01 am

callaghan wrote:why did not mention this in gfa manual?
it does not say anything about using assembler in the manual to place a vector in any other location..this is only a minor set back...i shall succed..

its xbios(34) and xbios(14,2) that i desire to alter and "mesh" about with.

so really no way to alter ???i am disappointed , talk about disapointed..


GFA can quite happily alter the vectors in memory to point to any bit of code you want. However, if you want to point the vector to run your own code, then that code needs to be assembled or compiled. With XBIOS call 34, you get the address of the table where the OS keeps its keyboard vectors, so a really simple example is this:

Code: Select all

code$="Nu"
kbdvbase%=XBIOS(34)
temp%=LONG{kbdvbase%+16}
LONG{kbdvbase%+16}=V:code$
~GEMDOS(1)
LONG{kbdvbase%+16}=temp%


All this does is effectively turn off mouse processing until you hit a key by redirecting the mouse processor to an "RTS" instruction. (I couldn't remember the GFA for 'wait for a key' off the top of my head, so went straight to the OS for that).

To get your own code in, you'll have to use an INLINE or a BLOAD or something. I doubt there's any wisdom in trying to point an OS vector at a piece of interpreted code, as the interpreter will do all sorts of crazy things while it runs.

callaghan wrote:-----------------------------------------------------------------------------
i have found an other gfa mis direct as well .
its to do with the resource file tedinfo ob_spec information for the g_box,g_ibox_and g_boxchar
ascii code for draw,frame and object color...
i bet simon sunny cr is interested in this find..
the manual has no # or text written in for g_box,
i feel it should be written in on top of g_text ..g_box is 20.
which by the way is OB_TYPE=20
and has no diagram like the following examples of the flags and the states....so for the ob_spec if a bit reprensentation of a binary number is nessesary its made up of all listed numbers and some that weren't even indicated within book!!!!


That's unfortunate if so, but of course one would be sensible not to rely on a single source of information. As I think you've surmised, the ob_spec for a g_box is the same as for a g_ibox.

wow still only couple years into programming but getting to grips with it..
i would encourage any body whoms interested in finding ouot exactlly
whats in a resource file to construct what i did ...a resource ripper program.. all locations of memory used by ~rsrc_load are examined and the specs are printed to the screen.for each object and tree within the resource file..whew thats a long post i did!!
but its good reducing the areas of large unknown gfa stuff.

done!

callaghan

i don't like assembler.i like gfa.


A "resource ripper" is a good way of really understanding how GEM works, it's a fun little project. Of course, a sensible resource construction set would also be able to show you the same information, but not the underlying layout and encoding.

User avatar
daeghnao
Captain Atari
Captain Atari
Posts: 479
Joined: Wed Oct 27, 2004 12:41 pm
Location: York, UK
Contact:

Re: aseembler?

Postby daeghnao » Mon Jan 15, 2007 11:06 am

callaghan wrote:why did not mention this in gfa manual?
it does not say anything about using assembler in the manual to place a vector in any other location..this is only a minor set back...i shall succed..

its xbios(34) and xbios(14,2) that i desire to alter and "mesh" about with.

so really no way to alter ???i am disappointed , talk about disapointed..


Forgot to ask: What exactly is it you're trying to achieve? There may be a way more suited to GFA than messing around with vector tables and iorecs and that.

User avatar
charles
10 GOTO 10
10 GOTO 10
Posts: 2407
Joined: Tue Aug 17, 2004 12:11 am
Location: ont. Canada
Contact:

achieve

Postby charles » Mon Jan 15, 2007 11:30 am

i am to understand how the midi vector and keyboard vectors swap to transmit midi data.

it will assist myself at obtaining an additional method of the st's midi ports.

a good resource set is a must , but i found some what difficult to obtain
values and create dialog, buttons and objects without knowing the're full
attributes.

my goal is too eliminate unnessesary resources, like ones we don't use alot from programs to the rsc file , but the select ones which are often used will be embeded into the program , rather than rsc files..also saves on disk space this way..

callaghan
thanks again -d
The radioactive half-life : )
Atari is a lifestyle,not a hobby.
HOLD ON ! ! ! Im printing unreadable characters ...!

User avatar
daeghnao
Captain Atari
Captain Atari
Posts: 479
Joined: Wed Oct 27, 2004 12:41 pm
Location: York, UK
Contact:

Re: achieve

Postby daeghnao » Mon Jan 15, 2007 1:52 pm

callaghan wrote:i am to understand how the midi vector and keyboard vectors swap to transmit midi data.

it will assist myself at obtaining an additional method of the st's midi ports.


Is there something wrong with using an existing call, like the XBIOS call Midiws to transmit MIDI data? The vectors you get from kbdvbase are all for MIDI and keyboard input, so messing with them won't affect how things are output.

callaghan wrote:a good resource set is a must , but i found some what difficult to obtain
values and create dialog, buttons and objects without knowing the're full
attributes.

my goal is too eliminate unnessesary resources, like ones we don't use alot from programs to the rsc file , but the select ones which are often used will be embeded into the program , rather than rsc files..also saves on disk space this way..

callaghan
thanks again -d


Is this for your own code, or are you proposing to embed the RSC files from existing programs into the main executable?

User avatar
charles
10 GOTO 10
10 GOTO 10
Posts: 2407
Joined: Tue Aug 17, 2004 12:11 am
Location: ont. Canada
Contact:

daeghnao

Postby charles » Mon Jan 15, 2007 11:13 pm

d,d,d,----what i should really have done is right and right out asked if you can spare me some time , a little bit of time and translate from c to gfa
approx 20 lines of example code...infact i feel like posting it any how to demonstrate what the author is trying to convey in this atari explorer article.

this would not only establish that you are terrifically gifted with computer language (like we know you are already!!!!) but that you also have enough understanding to put what you currentlly working on down and come to help me .. great!..

CHAR---Cccallaghan

good ideal?
The radioactive half-life : )
Atari is a lifestyle,not a hobby.
HOLD ON ! ! ! Im printing unreadable characters ...!


Social Media

     

Return to “GFA BASIC”

Who is online

Users browsing this forum: No registered users and 2 guests