@jabirulo

Just for comparision, this is from an X1000

welcome man!!!

@sailor

Great job!!!
On my SAM460ex I got these results:

Thank you, guys, for the explanation.

My first SPE-modified application stream is finished!

I need some apps for bechmarking of A1222+, and if nearly no exists, I have to it myselves .
It is on OS4 depot now. It is only one small easy piece, but this is also my first c-code after 20+ years, so I am happy...

@msteed
Thanks !

So, that what i tried then:



So yes, syntax exactly like you say, and while i am in the bridge it return 0x646011AB. But then if i type "12 config-l@" , it return same address. Same as 16, same as 20, or 50 config-l@ , return the same address.

And even if i go to any other directory, be it another /pci@C0000000 , or anything, typing those "16 config-l@" , "config-l@" and "." combo, always return at me 646011AB. Like, it does not matter where i am are in the FW, it just read by absolute address.. But what i need is to check BAR0 of the video card in the bridge..

I do check some older output from BBOOT by balaton, and this 0x646011ab address happens to be in the log like this:



So it seems to read some first (base) address of whole PCI thing, probably without depending on where we are at now in OF.. Question is how to read BAR0 of video card in bridge ..

@kas1e

I don't know anything about OpenFirmware, but I did program the Amiga in Multi-Forth for a time way back when, and still remember some things about Forth.

Quote:
"(config-addr -- data)" is a Forth stack use diagram. It means that the word 'config-l@' expects to see 'config-addr' on the top of the stack when it is executed, and it leaves behind 'data' on the top of the stack when it has finished executing.

Typing a number alone adds that number to the top of the stack. So the correct sequence would be "16 config-l@", which puts the value 16 (the "config-addr") on the stack, then executes config-l@. In Forth you would then type a single period ('.') to print the top value on the stack, which would be whatever config-l@ left there (the "data"). But maybe that's not required in OpenFirmware.

@joerg
Of course I know about AROS and maybe if it weren't for the fights between 3 independent groups in tha past 30 years but instead of duplicated efforts everybody could have agreed on contributing to one free and open source code base that would benefit everybody then it could be where Linux or at least Haiku is now. Unfortunately it did not go that way but maybe after 30 years it's not too late to try that eventually. I'm sure this was discussed before and what I say is nothing new so no need to repeat all the past debates but maybe people change and can reconsider decisions to keep AmigaOS alive in some form. If not then that's OK too, things will just go on like before.

I prefer GPL over BSD license for this because it makes sure that everyting will remain free for everybody so the most developers could contribute. Both who allow free like BSD and don't care much what it's used for and those who want it to be kept free. This worked for Linux and QEMU. The AROS license is similar to MPL which also says it should be kept free so it's not opposite and completely free like BSD but maybe less strict than GPL. Contrary to what some may believe GPL does not prevent commercial use, it just gives equal opportunity to everybody. There are/were whole companies like RedHat and Suse for example who lived from supporting open source operating systems and the base of macOS is also freely available so opening up AmigaOS would not make business impossible but those who hold the pieces maybe don't get this or think otherwise.

@flash
What needs improving on the MV64361 emulation in QEMU? I think it works well enough now. This chip has tons of features but if nothing uses them it does not worth emulating all details that will be unused. I think I already have a few unused things that weren't needed but implemented it anyway.

@Maijestro
I think somebody tested that before with real machine and ATI card with 16 bit mode (it's probably somewhere in the long QEMU pegasos2 thread, I think it was when we tested it with a Mario like game) and it did not reproduce the problem. I think somebody said back then that ATI cards support big endian 16bit mode but SM502 doesn't or something like that and it seems that some function used by graphics library does not take that into account on pegasos2. With the test from Capehill it's now also proven that it's not related to SDL code but it's something in AmigaOS. So we likely won't get more info from trying with real graphics card (unless somebody can try on real pegasos2 with a real SM501/502 card but those are probably rare so likely nobody has such card). The ATI cards were working even in 16 bit in previous tests so it should be the same result with a passed through card.

@white
Use the official QEMU sources from gitlab (see qemu.org Download menu item), I don't have a separate repo to use now.

I think you can set optimization level from configure without editing meson.build by adding -Doptimization=3 to configure. That would be better than modifying meson.build because then you can easily update from git. I don't know how much difference it makes but if you use opt 3 and see problems also check with the default optimization level just to make sure it's not some compile error. The results of opt 3 on Linux with gcc might be different than on macOS with clang.

For your QEMU command line -cpu 7457 -accel tcg are the default so you can drop these, only need to add -cpu if you want to use other than the default 7457 CPU. You can use -display gtk,zoom-to-fit=on,full-screen=on instead if separate -full-screen option that may be removed at some point and specifying it as a -display option is now preferred.

Instead of separate -drive if=none and corresponding -device ide-hd option there's a shortcut to define a drive with one option:

which does not need a separate -device ide-hd option so it's shorter and more readable. (Since QEMU 9.0 this also works with sam460ex now which previously did not support these short options.)

@smarkusg

meson.build

original:
>3 'b_staticpic=false', 'stdsplit=false', 'optimization=2', 'b_pie=true'],

do you think this is right is this what you meant ?

>3 'b_staticpic=false', 'stdsplit=false', 'optimization=3', 'b_pie=true'],


compile:

./configure --target-list=ppc-softmmu --disable-dbus-display --enable-slirp --enable-lto --enable-sdl --enable-gtk

@joerg

It was just out of curiosity, thanks anyway

@jarokuczi

They only specify what version of newlib.library is required for the individual components of your compilation.
You should not worry about this. The current stable/public version is 53.80

@jarokuczi
Quote:I added that about 20 years ago to the libc.(a|so) of newlib.
Example If newlib.library.kmod version 53.65 (or newer) is the version available to end-users there is no problem at all.
But if the publicly released version has a lower version.revision it will only work for AmigaOS 4.x developers and beta-tester but fail for end-users and you have to add a work-around.
I don't know what the current versions,revision numbers of the public and beta/developer releases of newlib are.

@salass00

Thanks. Now the code compiles and runs fine.

But the newlib.library version warning is still there, should I be worried?

@jarokuczi

Just add -athread=native option at link stage (LDFLAGS) and those errors should be gone.

@white
It's very important to use the correct VO for your (emulated) hardware.
Neither "comp(_yuv(2))" nor "sdl" are usable for emulation. It may work, but very slow.
WinUAE with Voodoo3 emulation: Use -vo amiga or -vo pip.
QEmu with SM50x emulation: Use -vo sdl_sm502

@geennaam

Quote:

I have no idea, but for me the topic has been moved and locked.
I have no problem with that. Your programme code, you have clearly stated what is important to you and licensing.
As they say ... ‘What happens in Vegas, stays in Vegas’

If you are willing and still enjoy using AmigaO4 and helping other users (even QEMU) that would be cool.

Greetings

Hello, fellow developers.

I'm trying to install the newest SDK (54.16) into Cubic IDE. I followed the instructions from the article:
https://www.amigans.net/modules/AMS/article.php?storyid=30

But I can't build the project due to strange undefined reference errors, etc.

Here goes the entire log.




Has anyone installed the newest SDK in Cubic Ide?