[blitz] CreateNewProc_() - syntax question

[peceha]

Hi,
I'd like to execute CreateNewProc_().
One of the arguments (for the tags) is NP_Entry
As per manual:

NP_Entry takes a function pointer for the routine to call

Is function a standard blitz statement/function?
If so, how to pass a pointer to it?

when I do:

tags(0)\ti_Tag=#NP_Entry ,&myfunction{}

I get an error: garbage at the end of the line

When I ommit "{}":

tags(0)\ti_Tag=#NP_Entry ,&myfunction

my amiga crashes

myfunction inthe above cases is:

Statement myfunction{}
...
End Statement

Thanks

[Daedalus]

I'm not sure you can use it in that way, but if you do, you would get the address of the function by adding a label before it, something like this:

.myLabel
Statement myFunction{}
...

But, given that the OS refers to a function pointer, I would suspect that it would be a function in terms of a library function and not a Blitz function.

[peceha]

That is not good
I'm working on my own GUI for Prisma (using MHI) an all is fine and dandy but one thing - serious one.
Playing of the song must be started as separate process.
At the moment, if I open top menu or ASL requester or do something with the program's window (eg long dragging around the screen) - the song stops playing and resumes when there is no action from my side.

[Daedalus]

Yeah, this is a problem alright. Have you tried using

tags(0)\ti_Tag=#NP_Entry ,&myLabel

instead? I don't really know how it might work (and you might need to also create a dummy call to that function that never gets called to make sure the compiler doesn't eliminate it as dead code), but it's worth a try.

Instead of doing it that way, when I made my MP3 jukebox software, I simply wrote a separate stand-alone executable and used Intuition messages between them for control. It worked well and meant I could substitute in separate "engines", for example a wrapper to control AmigaAmp instead of decoding the audio myself, so maybe that's an option?

[peceha]

Been away from amiga since my last post - I will try your idea today, if it 's not going to work then will follow the advice and make separate exe.

I will report soon.

[peceha]

Looks like it is a "no go".
I did a statement with the label like you explained. I passed that label like: &label and still the same - crash (no red guru only request "suspend" "reboot")

Next thing I did I removed "statement /end statement" and moved the code from inside to the very end of my program (so these were the last lines, not enclosed in statement anymore). I made a label like before and still no luck.

At the moment I'm using amigalibsii.res and there are no constants for #NP_Entry, #NP_Name ... but I used direct numbers like : $80000000+3 (for NP_Entry), +12 (for NP_Priority)...

Later I will check with amigalibs.res (there are above constants in there) - need to change some code firts (amigalibs and amigalibsii have different names for some newtypes)

[idrougge]

What if you instead of a pointer to a Blitz procedure supply a pointer to a small piece of assembly? e.g.
myFunction:
Even
MOVE $0f00, $dff180
RTS

[E-Penguin]

Blitz uses address registers A5 and up for internal purposes - if the function call is trashing those registers and not restoring them before exiting then you'll get crashes. I don't know what CreateNewProc_() does with registers.

[peceha]

What if you instead of a pointer to a Blitz procedure supply a pointer to a small piece of assembly? e.g.
myFunction:
Even
MOVE $0f00, $dff180
RTS

standard window pops up:
+----------------------------
|****COMPILING****
| STOP!
+----------------------------
and later it just disappears with faint screen flash and that is all - there is no Guru but program doesn't start

But if Runtime Error Debugger is ON then its window (debugger's window) shows up on the WB screen and cannot be closed without restarting amiga.

I tried & and ? in front of myFunction when passing as an argument
tags(0)\ti_Tag=$80000000+3 ,&myFunction
tags(0)\ti_Tag=$80000000+3 ,?myFunction

[thomas]

If the Basic runtime expects certain registers to contain specific values, you cannot use a Basic program in CreateNewProc without compiler support. In C you would declare the function with __saveds or __geta4 to tell the compiler that the context registers need to be filled at the beginning of the function. If Blitz Basic lacks such a directive, then it is impossible to use internal subroutines with CreateNewProc.

A similar problem is with call-back hooks. How would you initialise a struct Hook for example to make a window backfill routine?

[peceha]

Thanks,
so the only way to avoid "hiccups" (shown on the video)
[ Show youtube player ]
is to make separate exe for handling music and communicate with it (as Daedalus said)?
I'm talking about Blitz since I know nothing about other languages.

[idrougge]

Originally Posted by peceha

standard window pops up:
+----------------------------
|****COMPILING****
| STOP!
+----------------------------
and later it just disappears with faint screen flash and that is all - there is no Guru but program doesn't start

The flash should indicate that the function was executed.

[peceha]

Originally Posted by Daedalus

... I simply wrote a separate stand-alone executable and used Intuition messages between them for control. It worked well ...

I'm currently doing the same and have to ask you one question (but most likely you don't remember anymore or you used AB3 and that doesn't count).

Did you create separate port for answers to you messages (mn_ReplyPort) or you used the same port for both ways?

I'm asking because amiga always hangs when using the same port.
When I introduce separate one all is fine.

I could leave it like this since it works with 2 ports scenario but I feel a little bit troubled about it (hope it is just BB2 bug)

Thanks

[thomas]

You cannot use the same port for both directions. A port always belongs to the task which allocated it. Only that task can wait for incoming messages. The mn_ReplyPort must be different from the port you use in PutMsg.

[peceha]

I meant, my first program created its port for msg eg. GUI. Second program also has its own port for msg Mhi

Both these ports are on the list (via AddPort()). Nów when I send the msg from GUI to Mhi i pass GUI as replyport. And when from Mhi to GUI then Mhi is a reply port. So these are not the same as in putMsg().
So that scenario fails
To make it work I need to add 1 more port to each program and declare it as replyport - then everything is fine

[thomas]

Actually it should work with two ports as llong as you don't confuse the messages.

Normally you have a client and server relation. The server creates a port for receiving requests and the client creates a port to receive replies.

You make a quite strange protocol with sending messages and replies in both directions. So you have to make sure that you properly distinct requests from replies. When you receive a reply you have to extract the result from the message and throw it away. When you receive a request you have to start processing and keep the message so that you can reply when the request has been processed.

If your program hangs you got it messed up. You wait for the wrong port or expect a reply when you sent a request or vice versa or something similar.

And of course you must not reuse a message which has not yet been replied to. Messages are not copied, only the pointer to the memory of the message is attached to the receiving port.

[Daedalus]

My player just used a single direction protocol - the player listened for commands and responded with details when asked, but didn't send any messages of its own accord back to the GUI. So only the player part opened a port (the GUI also opened an ARexx port, but that's a different story). It was done in AB3, but didn't use any AB3-specific stuff so should be identical to a BB2 implementation.

[peceha]

Thanks, I will look into it.

I have 2-way communication:
GUI is sending commands (play, pause...)
MHI, more or less every second is sending information about empty buffer - and that's the only way I can find out the current playback position

[Daedalus]

You could also implement that in a similar fashion from the GUI - I polled the engine at regular intervals and it reported its status. The overhead shouldn't be any different, and when the GUI is unable to send messages (e.g. file requester open), the engine will play along by itself without multiple unanswered messages building up.

[peceha]

Why didn't I think about it ??
MHI part is countig its signals but is not informing the GUI
It's the GUI who asks about the status
So simple....
Thanks, hehe