@Hans

I'm not good at C. The vo_comp_yuv2.c I have is similar to the one on github: https://github.com/khval/mplayer-amiga ... /src/libvo/vo_comp_yuv2.c

It looks like the test you're talking about is already there. If I hard code "have_readeonhd" to TRUE (typo corrected in my source) as I've done in the test binary above, or was to remove that check altogether, it should still get to "if (have_compositing == FALSE)" and stop on machines that don't support it, however on my Sam Flex machine with a Radeon 9250SE, it passes that bitmap test, so have_bitmap_format and have_compositing are TRUE and I end up with a white window. Is the test being done wrongly?

I've not tested this (nor am I able to). I just disabled the check for RadeonHD.chip in comp_yuv2. non-altivec build.

https://www.sendspace.com/file/byyesp

Does LiveForIt-MPlayer 6.5.7 work?

http://os4depot.net/share/video/play/liveforit-mplayerng.lha

When using 6.4, check the shell output and see if it's really using comp_yuv2 or just comp_yuv (or just comp).

Altivec or non-Altivec? Does it crash, freeze, or something else? DSI/ISI? Empty window? And do test LiveForIt-MPlayer 6.5.7. It's closest to mickjt-mplayer.

@mufa

You didn't mention which version of mplayer you were trying to run, and whether it's for altivec or not. Paste all the lines that say something like "VO: [somethinghere] text here".

Version 6.4 doesn't have the same checks that later versions do.

In later versions there is a check to see if RadeonHD.chip is being used, and I suspect that check is failing with RadeonRX.

You'd then see something in the shell like:

VO: [comp_yuv2] You need RadeonHD to use this video output.

@Raziel

FYI, it's not limited to ReadLn. It's the way REXX works (not just AREXX). Here is another example:



Think about what you'd expect if you used:

ADDRESS COMMAND ReadLn(File)

Assuming no AREXX port had been manually set yet, that will temporarily switch to the COMMAND port, run the result, and switch back to the REXX port. In the script example above, COMMAND was already set as the AREXX port ahead of time.

When you use ReadLn() without anything proceeding it, by default it sends the result to the REXX port. That's what was happening in your script.

I remember when writing something for Regina REXX, I couldn't use "Call Function()" when I didn't need to store the result, so I just used "Null=Function()" instead, because Function() on its own would cause havoc.

Wrap your head around this one!



The Word variable is set to 'hello' (single quotes included)

Temp is set to "SAY 'hello'" (both types of quotes included)

Then the contents of Temp is sent to the REXX port. Those contents direct it to say the word hello.

Edit: Removed stuff that may have caused confusion.

There is a difference between

ReadLn(Something)

and

Call ReadLn(Something)

The former will try to run the result as a command to whatever port AREXX is currently addressing.

The latter will just read a line, store it nowhere and not try to run it as a command or send it off as a command to an arexx port.

I don't know why it's working on the first run and not subsequent ones, but I suspect it can be solved by adding "Call" before ReadLn's that don't get stored into any variable.

For example, you can create a file, say RAM:test, with the word "time" in it. Then you can create a script:

/**/

ADDRESS COMMAND

Call Open(File,"RAM:test","R")
ReadLn(File)
Call Close(File)
Exit

and that will open the time preferences program. If you modify RAM:test to say "hello:hello2" instead of "time", it will ask you to insert hello:, and for some reason it'll still do that even if you remove "ADDRESS COMMAND" from the script.

Edit: Just realised this probably can't work from the IBrowse search bar.

If you disable javascript in Firefox it sends a POST request to https://duckduckgo.com/html

When searching for "test" (quotes not included) it sends:

q=test

You should be able to make a local .html file with a simple form in it so IBrowse can generate the required POST request and send it to the right URL.

@daveyw

Here's my quick and dirty fix (Example only. It doesn't cut the last 4 characters):



6.RAM Disk:> rx test "1 2" 2
1 2
2
6.RAM Disk:> rx test "1 2" "2 3"
1 2
2 3
6.RAM Disk:> rx test 1 2 3
1
2 3
6.RAM Disk:> rx test 1 "2 3"
1
2 3

@acefnq

That's here: http://os4depot.net/index.php?functio ... brary/graphics/libpng.lha

Although I recommend AmigaBlitter statically link the binary instead, because I could update those libs at any time and the version numbers might change.

The ShowNetStatus source code is available in the Roadshow SDK if it's of any help.

It doesn't seem to be specific to AmigaOS. They've removed native Windows code for the GUI too. It looks like they're mainly sticking to SDL2 and GTK3 for future versions. There still exists Amiga specific code for SDL2.

Ok. I just went through the steps myself. I'm naming the CROSS_PREFIX directory as adtools-ppc-uwin64-20180416-480 (I used make print-dist-version to find the date/revision). After doing all the gild stuff, I went into native-build and ran:

make gcc-cross CROSS_PREFIX=/usr/local/amiga/adtools-ppc-uwin64-20180416-480

When I got to the error, I simply did:

ln -s /usr/local/amiga/adtools-ppc-uwin64-20180416-480 root-cross

So that makes a root-cross symlink inside of native-build that points to /usr/local/amiga/adtools-ppc-uwin64-20180416-480

Then I ran the "make" line again, and it continued on fine. Sorry to say salass00, your method is the hard way, even if it is more "proper" :) I'm sure Sebastian Bauer will fix CROSS_PREFIX to work properly again soon anyway (basically the same as what you did).

Edit: It was fixed on May 4th.

I missed that CLIB2_CROSS_DONE_DEPENDENCY line.

So, the makefile still builds it but doesn't always take into account modified variables.

It looks like the instructions in post #1 jump straight into building gcc before building binutils. AmigaBlitter's screenshots he sent to me show it failed when looking for ppc-amigaos-ar in native-build/root-cross/bin/. I had a look at the Makefile in native-build and the gcc-cross target, and I don't see where binutils is made for that target.

So I suggest going into native-build, and running "make binutils-install". Then building gcc should work afterwards. Not tested, but this is my best guess.

Edit: The Makefile from when this thread was first made, used to build binutils for the gcc-cross target, but no longer does. 18 days ago a change was made (893c02b) that meant binutils would no longer be built automatically if using the gcc-cross target. Previously, gcc-cross would call clib2-cross which would call xgcc-done which called binutils-cross.

Edit 2: That wasn't right either. See salass00's post below.

Boost, unless it only needs a very old version, is something we don't have unfortunately. The one on OS4Depot is built against clib2.

@Raziel

Just good timing I guess!

There's pdcurses on OS4Depot

http://os4depot.net/index.php?functio ... ary/graphics/pdcurses.lha

@broadblues

He means using the "autoplay" parameter that makes YT.rexx itself run MPlayer. No HTML pages need to be generated.

For AWeb you'd need something like:

Play in MPlayer

SYSTEM RX Work:YT/YT.rexx %u silent autoplay

But %u is current webpage. You will need to left-click and load the page for the YouTube vid you want to watch first, and then right-click and choose the menu option.

There doesn't appear to be a way to right-click on a link and send that link as a parameter. NetSurf has same limitation. I've only had a brief look at the AWeb docs though.

Is this useful for you?

http://os4depot.net/index.php?functio ... /database/blu_manager.lha

@white

NetSurf doesn't have that ability, yet.

I know that "data:" is a URI scheme that might cause issues, and changing it to Data: with a capital D might help. Also if YT.rexx is in a path with spaces, that can cause problems.

I'll send you an e-mail.