`NVGetVar' just fetches the settings from NVRAM.

In order to change the settings you would have to boot into CFE and actually change and then save (do not forget to save) the settings.

I do not believe you can do this from within AmigaOS4 - but would be happy to be told otherwise!

@Capehill

I see that in https://github.com/AmigaPorts/SDL-2.0 you have now modified things so that a build will generate SDL3 names. Are you sure this is the best approach and will not cause confusion? Why not create https://github.com/AmigaPorts/SDL-3.0 ?

Many things to comes wrt. porting will still use SDL2, it means that people will have to clone your branch and checkout a previous commit ID to get the latest and greatest SDL2 libraries.

I just thought I would raise this now.

Thanks for all your work and all those involved in making SDL possible for Amiga in the first place!

===

EDIT

===

Actually, I notice that the change to SDL3 names happened in:


This means that you (@capehill) did nothing more than merge in their changes. I am surprised they are not creating a separate branch though. I guess there is a reason!

===

EDIT

===

Woah, I am really confusing myself.

I think SDL2 is specifically on your branch: "SDL2". "main" is just SDL3 since December last year.

Understood, thanks.

Afxgroup created his own CLIB2 repository that anyone can add to their apt.sources.

I wonder if a general apt repository is a good way to have an actual package management system for AmigaOS4. Consider a repository named "os4depot", where the latest things can be downloaded.

But, questions would have to be answered such as who would maintain it. Is it even a good idea!? Even if we have an apt repository, would it really make any difference? What about other package management systems / Windows users.

Perhaps the best thing is still just what we have now. Get a released version from GitHub or build the source code yourself. For the latter - not everyone is interested or experienced in that.

Who is maintaining SDL2 libraries such as libsdl2_net?

I see an entry on OS4Depot.net from 2016.

===

EDIT: I guess no one since net is nothing more than a thin wrapper that calls of into the C library. So, updating it is presumably simple.

Yeah, UK.

These r9, 7900 cards are so large and bulky. The RX series is nice, quiet and light.

Not sure if there is a lightweight SI card to get.

I'll have a search. Thanks for the hint wrt. Ebuyer.

My X1000 came with the Radeon 4XXX series card. After a while, I upgraded to a 7950 (SI). That card was massive in size and fairly loud, but it worked for a while. I also bought the SI software from the AmiStore: I cannot even remember what that was for now. I think it was about 30£ and it enabled SI to use W3DNova..?

Anyway, the 7950 died one day. I put back a Radeon 5XXX card (which came with my X5000 that I upgraded to a 560RX because the 550RX was DoA. Actually, that 560RX has been solid and there are no problems there).

Then, I bought a 280 for my X1000 and that worked for a short while but found artifacts on the screen after a short time! I also tested it in a PC and the same artifacts were there.

So, all the cards I have bought so far have been from eBay. I got lucky with the important one: the 560 in the X5000.

I am wondering to risk Yet Another SI card from eBay or get an RX card, preferably avoiding eBay!

1. Is there a safe source of these cards?
2. Is it as simple as plugging in the RX card into the X1000? (Other than installing drivers)

Thanks.

This happens to me when using Odyssey and YouTube.

Once I get that error, I need to restart the machine and video playback works again until I try to play another video through yt.

It is known. I created a thread named with YouTube in the title but I cannot be bothered to find it on my phone right now.

lhasa _does not work_ for later version of the SDK. It will not report an error either, it will just not correctly extract.

You should notice that the ReadMe.md has updated since last night too.

Fine. I think Coreutils is a red-herring anyway. Your initial error is complaining during the build of clib2 due to the use of a subpar version of LHA.

In summary,

- Use a known working version of LHA and use adtools repo
- or, use adtools_testing with ./adt -b
- and know that coreutils 8 should not be used for now

You probably did not specify the "gcc-cross" target when invoking make. In that case, adtools assumes you want to build a cross compiler *and* a native compiler. The native compiler attempts to package everything up ready for an SDK release and so also uses coreutils.

@Hans

The easiest thing is probably do use Docker, as suggested above. Otherwise, you can clone https://github.com/3246251196/adtools_testing and, tldr:

There are a number of options which may be of interest, but that - alone - will create for you the Xcompiler that you originally wanted.

The script will also tell you, before building, if you will have any unmet dependency packages - including - the lack of an LHA extractor that actually works.

In a nutshell, half of adtools_testing is a wrapper around adtools and the other half is a way to build tests / add tests ready for deployment on an AmigaOne.

Options to consider are things like using the alternative clib2 by afxgroup (e.g. ./adt -b -e beta10)

You also do not need to checkout coreutils unless you are actually interested in building them, or, you are trying to create a native version of the compiler package to transfer to an AmigaOne machine. Further, coreutils 8 needs to be fixed in ADTOOLS since it will not successfully build right now.

Right, you are missing


Presumably you want to boot into AmgiaOS4 by default, hence why I chose 1.

You should set that variable and remember to save it.

===

If that does not work for you I will actually consult my X1000 documentation and find out what exactly you need.

It may be the MENU_TIMEOUT setting that needs changing. Cannot remember right now.

Can you output the contents of your `nvgetvar'?

`nvgetvar'

Thanks.

Once more I have forgotten how to display the CFE variables in shell. There is a simple command that shows them when inside a shell/booted up AmigaOS4 session.

Is it also the same command to see UBOOT variables?

@nbache told me what command this was, but I can no longer remember!

Excellent, Aris.

Thank you.

nochmals vielen dank!

It never worked to begin with.

It is a massive flaw.

We have been waiting for a necessary upgrade to the ELF.LIBRARY for too long now.

Though, I think it is coming very soon.

Behind the scenes, things are moving, though; slowly.

That's right. I hope to get a baserel test ASAP.