call and assembler how to use in gfa

[Mug UK]

Erm .. assemble the code and then look at it in a hex-editor if you're going to go down that masochistic route.

Research into what PC relative coding is - as mentioned above you *need* it to work with GFA's INLINE commands - plus it teaches you a neater coding style so that's a bonus.

Try coding a few bootsectors as they all need to be PC relative - from memory there is a command you can place inside your Devpac source code (pc+?) that tells Devpac to check that your code is PC relative. You then have to alter the lines of code that fail this check at assembly time.

But, as previously displayed in this thread and many others, the answers have been given as well as pointers for you to research but you seem to ignore what everyone has written so far, so I daresay this will also happen with my reply.

[Nyh]

nyh i did it my self !

now anyway you look at it its all "cut and paste "
unless you write your own
compilier ,editor and fabricate your very own list of commands.


that is what i'm trying nyh ,

form_alert #1,#text

thats all

No Charles, you did nothing yourself!!!

There is no 68000 instruction form_alert.

You just copied an example and you have absolutely no clue how it works.

And you are not able to write the program which uses a subroutine to multiply with 9 and displays the results for the number 0-10 in a loop.

Hans Wessels

[lp]

It's this simple, since there is no parameters:

1) write an *.s file in pc-relative format (required)
2) compile it to a binary
3) load the binary into the inline, not in hex format
4) open the manual and read the description of inline for the love of god
5) hit Run

If it fails, the *.s file is not written correctly or the calling method is in incorrect. You do realize that certain registers must remain unchanged (or restored) or GFA will crash. This is stated in the manual as well. Converting it to hex/data lines is the hard way and defeats the purpose of inline.

Nyh is right, you didn't write any of it yourself. You copied a macro from somewhere. Is the macro written for pc-relative operation? Is the macro destroying the registers GFA relies on?!

[charles]

ok lonny please expand ,i need more insruction from what you last wrote:
compile into a binary..
what is this?

compile into
.prg
.tos
or
app?

charles

if any body has abacus machine language book.
the data lines gfa uses is exactlly as what the abucus book
details as the hex dump of the instruction or the table..

so? i am not going to use a exec , i want to use a call or rcall, monitor,,etc

i am ressearching each night everybody ...i will check the vdi lib the aes lib and geminc and gem macro
which devpac relies on , to see if they are pc reletive

pc realitive means all lines sent are 32 bit even though they only use 24 bit right?

charles

[lp]

It's just a subroutine, not a full program, the file extension does not matter. What matters is if you wrote the subroutine correctly and it follows all the rules of being called from within GFA. That's basically all it comes down to, and if you can't sort that out, well... ______________________ (fill in the blank).

[daeghnao]

Just to weigh in on this rather heavy topic - I've taken up the challenge from earlier in this thread and created a "multiply by 9" routine and called it from a GFA Basic program. All from memory. Took about 20 minutes to get right. It's really not hard once you've taken the effort to understand the basic, fundamental concepts. I can post a step-by-step guide if you really want to see it, but it's far better to find the documentation, read it, understand it and apply it. For this particular task, you need to know:

• how to assemble code, using an assembler, into a program file. If you can't do this, you don't get to play assembler.
• how to call a piece of code from GFA Basic once you've calculated its start address. I personally only ever remember how C: () works, go look up C: () and RCALL in your source of GFA Basic information.
• how to write your assembly-language program so that it reads the parameters passed to it. C:() and RCALL use different conventions for this, precisely because there's no one way to do it.
• how to write your assembly-language program so that it returns the result back to GFA Basic. Again, there's more than one way to do it.
• how to write a GFA Basic program with an INLINE statement in it correctly. If you can't do this, you don't get to play GFA Basic.
• how to load the program file into the GFA Basic program, in the GFA Basic editor. Instructions should be given alongside the INLINE command in your favourite GFA Basic manual.
• how to find the start address of the text segment of the INLINEd program file. This could be a little tricky if you didn't know that it's 28 bytes in as standard.

Once you know all these things, then it should be easy to combine assembler and GFA Basic. I did it from memory, having learned all these things from documentation a long time ago.

Now, the question has to be, why would you want to do this? Unless you're doing something with precise timing - playing samples or splitting the palette - I can't see any benefit to using assembler for part of the program. I'd either do it all in GFA Basic or all in assembler. Or all in C. Whichever is the most suitable language for the task at hand.

[lp]

I think the bit with the 28 byte header can be ignored. I don't have the manual in front of me, but I think I recall the magic value in the header, first word is the equivalent to a branch always with an offset of 28. Thus the header is skipped. So just having the address of the inline itself is enough.

Some other asm user can confirm this I'm sure.

[Nyh]

I think the bit with the 28 byte header can be ignored. I don't have the manual in front of me, but I think I recall the magic value in the header, first word is the equivalent to a branch always with an offset of 28. Thus the header is skipped. So just having the address of the inline itself is enough.

Some other asm user can confirm this I'm sure.

That is correct. My initial thought was that a .prg file was a bad idea because of the program header. But the first word is a branch to the start of the code so all will be all right for PC-relative code. Using the compiled assembly without the program header will make the file slightly smaller.

Hans Wessels

[charles]

daeghnao lets do a walk though if time permits(step by step) .
here is what i include and have got so far .

recyrs_v.gfa -a file that insures my inline or open loads the files
char.s - a simple what for keypress in asm source file
1.gfa -the whole target project, doesn't work bombs
gfa_3_6.prg - the gfa editor..


ok try it out , from how i conceive the instructions this is what i madde of it , i did many attempts ,
i just do not know what lonny meant by compile a binary ..that seems to indicate make into executable ????????

charles

[Nyh]

daeghnao lets do a walk though if time permits(step by step) .
here is what i include and have got so far .

recyrs_v.gfa -a file that insures my inline or open loads the files
char.s - a simple what for keypress in asm source file
1.gfa -the whole target project, doesn't work bombs
gfa_3_6.prg - the gfa editor..


ok try it out , from how i conceive the instructions this is what i madde of it , i did many attempts ,

ROTFL!!!!!!!!!

Did you read the Gfa basic manual about the inline command?

Even if you did read it, you completely and totally failed to understand it.

Even without the manual and never used the Gfa inline command I had solved the problem in less than 5 minutes. Somehow I managed to press the Page-up key in STeem at the right moment and I was enlightened.

Hans Wessels

[charles]

multiply by nine ?

divide by three


i do not care ?

nyh i do not think your inline routine works .

did you get same results as myself?

ok happy canadaian thanks giving its monday and sunday..

/|\ charles

[lp]

As I had thought, loaded the *.s file into the INLINE. If you dump the inline back to disk, it's the *.s file.

From the comments in the 2nd file:

Code: Select all

' inline kinda sucks ,no allocation ,just magic numbers,variable declaration?
'
INLINE rm%,102
'
' another magic number, : file size...pooof !!! with no way re-adjust


ROTFL! (also)

These two listings on the disk are the funniest/worst I have ever seen to date.

[Mug UK]

Charles´ knowledge (or rather, the lack of it) has made my day at this event in Germany - but no-one else here to share it the laughs with! Well done Charles - if you did this as a joke, it was very good and you are the #1 joke-meister on this forum

[charles]

nope no joke ,
there must be a method to convert my
" .s" file
into a file of
binary
or
hexcidecimal .

so convert from (asc text/ .s file )
to a (neumeric form ,that is pc relevante)
because devpac does not format different file types,it just saves as asc

charles

[Desty]

nope no joke ,
there must be a method to convert my
" .s" file
into a file of
binary
or
hexcidecimal .

There is - it's called an assembler.

[PaulB]

Stick your .s assembly code into Genst. Y'know the 68000 assembly program.
Compile it to disk as a program.
The *.prg file it makes is the one you need to load into the GFA inline.
Personally I used to cut off the first 28 bytes (the program header) as it wasn't needed to run with GFA.
But... as lp says, it works for him leaving the header there, so try that.

Everything you want to run or call from an inline/array or whatever in GFA must be compiled first. Of course if you just wanna stick a 32000 byte pic in an inline, you can do that too. Then you can show the pic directly but obviously your compiled GFA program size will go up by 32000 bytes as well.

[charles]

gee finally ,
i will try right now and see what results

thats what was making no sence to me ,
that when i opened up with text editor and looked into the example files,
they were comprised of only a series of what appeared to be a series of values ,
not a compilied program ,,, and then to top it all off , the gfa manual only listed hexadecimal values or the data area of the vector to address for my rcall /call/c:
command.

to be honest i saw a rcall or call example in some 'c' bindings that were not compilied and this is what makes programming from text/resource so damn hard....

ok b back later
charles

[charles]

yep this works as intended ,
i am thrilled?

so what you doing tonight paul?
i should maybe stay close to u and be best buddies paul .b ?

here is a .st image of what i quickily explored and learnt .

similar to first disk image but this one functions,,i used a simplified .s file

charles
thanks again and please comment about stuff..

[lp]

gee finally ,
i will try right now and see what results

thats what was making no sence to me ,
that when i opened up with text editor and looked into the example files,
they were comprised of only a series of what appeared to be a series of values ,
not a compilied program ,,, and then to top it all off , the gfa manual only listed hexadecimal values or the data area of the vector to address for my rcall /call/c:
command.

to be honest i saw a rcall or call example in some 'c' bindings that were not compilied and this is what makes programming from text/resource so damn hard....

ok b back later
charles

The inline command is nothing more than a buffer. Anything can be put into the buffer, an image, a sound, midi file, ascii, asm code, so long as it fits. The problem is this, or rather your problem. You don't seem to actually comprehend what you read. If you fully read it at all.

The example in the book is an asm example and yes it's in hex and copied to the inline then executed. This is because the book is static, it's cannot really show an example where you hit help and load a binary. It should be obvious after reading it, it was to me all them years ago. The variable returns the address and the number is the size of the buffer, no mystery at all. Just someone unable to connect the dots per usual.

Had the example displayed some image or something, you'd probably be ranting how inline sucks because it only handles images. Why, because you interpret things wrong and make bad assumptions.

[charles]

lonny..is that u lonny?

ok i thought so.

i probally do get things mixed up ,
the terms are a dime a dozen ,
still got years to go to fully understand and remeber all this stuff.

charles

thanks .
trying at the moment now get the xdef xref stuff working
so i can pass parameter values into and out of this command....
clip clip button push button push
frowning
cause i do not have a 68000 manual of any kind.

back to the gfa manual
but how difficult is it to branch to another sub routine
from within this "RCALL"
or
now the ideal i have is to use installed addresses to other procedures
for the kbdvbase
????????????????????? learn more asm ????????????????
!!!!!!!!!!!!!!!!!!!!! learn more asm !!!!!!!!!!!!!!!!
charles

[lp]

Well if 8 years got you to the point of loading ASCII into an buffer and trying to execute it with a JSR, then yeah I'd say many more years.

One tip, xdef and xref are not needed. Whatever listing you are hacking atm, throw it out.

Since there are many good books on the subject of assembler, I would suggest "Introducing Atari ST machine code", has a section on doing so with GFA. Or better yet "The GFA BASIC & Assembler User Book" which was from the GFA themselves.

I won't go into explaining the details of parameter passing, someone else can spend the time.

[charles]

ok , the small task is easy , this should make its way to daeghnoe too i hope
a long time ago she helped me about vector swapping and the xbios 34 kbdvbase for midi

and i had tough time making a 'c' code into a gfa file
so i went on to one of the other things i had on the go.
but now just the other day i found this on the internet and it relates back to the kbdvbase.

this
"midithru.s"
is for her and

here are some of my references (pictures),
which got pushed on me all at the same time..i got a crate or two of mags and books for the atari , and this was a more than welcome gift ..but some areas i was expposed to went well past my extended coprehendable b limitiations.

stos manaul even has some asm code to utilize in its rear , appears alot of basics liked to interface with other languages by means of call or c: or rcall etc.

its usally about a dozen times a year i get a "block" with programming and i don't know what it is but somehow i manage to go on.

charles

Code: Select all

Hi People,

A while back, Ted Lyngmo asked that I post a snippet of code that I sent
him which echoes MIDI in to MIDI thru.  Here it is:


---- cut here ----
*
*       through.s  --  MIDI input handler routine to simulate MIDI thru
*


        csect   text,code
        xdef    _install_thru,_uninstall_thru   ; export entry points
        xref    _thru_channel                   ; reference external value


midisend        equ     $fffffc06       ; MIDI output register
midiread        equ     $fffffc06       ; MIDI input register
midictrl        equ     $fffffc04       ; ACIA control register
midistat        equ     $fffffc04       ; ACIA status register
mfpiis          equ     $fffffa11       ; MFP
bit6            equ     $40             ; ..MIDI ACIA bit
notbit6         equ     $bf


_install_thru:
        move.w  #$0022,-(a7)            ; push Kbdvbase function code
        trap    #14                     ; Xbios
        addq.l  #2,a7                   ; tidy stack after Xbios
        movea.l d0,a0                   ; copy address of Kbdvbase table
        move.l  (a0),oldvec             ; save first entry (midivec)
        move.l  #interrupt,(a0)         ; install our routine
        rts                             ; return


_uninstall_thru:
        move.w  #$0022,-(a7)            ; Kbdvbase
        trap    #14                     ; Xbios
        addq.l  #2,a7                   ; tidy
        movea.l d0,a0                   ; copy table pointer
        move.l  oldvec,(a0)             ; restore old value
        rts                             ; return


interrupt:
        btst    #3,midistat             ; check MIDI output status
        bne.b   notready
        cmp.b   #$ef,d0                 ; system byte?
        bhi     notready                ; don't forward system messages
        tst.b   d0                      ; status byte?
        bpl     send                    ; don't touch data byte
        andi.b  #$f0,d0                 ; zero channel
        or.b    _thru_channel,d0        ; set to global "thru_channel"
send:
        move.b  d0,midisend             ; echo MIDI IN to MIDI OUT
notready:
        andi.b  #notbit6,mfpiis         ; disable interrupt-in-service bit
        rts                             ; return


        csect   storage,bss
oldvec:
        ds.l    1                       ; old midivec place saver


        end


*** through.s ***
---- cut here ----


To use, assemble this code, then link it into your C application.  Set the
global variable "thru_channel" to be the MIDI channel for the resulting output
stream (this bit of code can be hacked to make the thru stream verbatim, rather
than channel-shifted).  Now you can call "install_thru" and "uninstall_thru".


I hope someone finds it useful.  BTW, I originally got this from someone
else: alas, I don't remember who.  If anyone recognises their code, please
feel suitably pleased with yourself.  :-)


Cheers,


[M][a][r][c]


**  ---------------------------  **  ---------------------------  **
**  Marc CR Bouron               **  Digital Capital Markets.     **
**  +44 (0)895 208260            **  Harefield Place, The Drive,  **
**  Marc.Bou...@ime.mts.dec.com  **  Uxbridge, Middlesex,         **
**  bour...@trout.ime.dec.com    **  UB10 8AQ.               UK.  **
**  ---------------------------  **  ---------------------------  **


And for my next trick, I shall disappear in a puff of smo




[charles]

ok just back tracking , i am sifting through st format coverdisks and found this to add to the old gfa/asm thread ..wish i was indexing all this stuff over the past years...gee
i haven't tried , only to ponder it good for adding , i got my gfa asm to work together using rcall......should i ask????

whats the differences ,,,how does c: differ?

heres the files anyway

fun fun fun ,,right?

charles

[lp]

The differences are stated in the GFA manual.

[charles]

how do we know what people are doing with this code?


does any body have some good uses for these c: rcall etc etc?


i plan to use to zero the timer i use ,

or

set timer to different readings
like if timer went from 400 - 1000 then have intervals inbetween which are allotted in an array , i could then reconstruct the replay of events,
after setting back to 400
and recreate the elements from array..(over and over again)

i suppose math is fast in the rcall or c and so would midi out ..

thats what i'm doing .
charles