I am trying to build the AHI source from aminet. "unfortunately" it is multiplatform so the source needs to be configured for amigaos4.
So I run the configure script to create the makefiles for the device and drivers but it fails on a missing component called SFDC.

Found SFDC master on aminet. It claims to "convert SFD files into something useful". It is created by the same programmer as the one who created AHI so this must be the component that I am looking for.

After config and make install it creates the following three files:
/SDK/local/C/sfdc
/SDK/POSIX/usr/local/bin/sfdc
/SDK/POSIX/usr/local/share/man/man1/sfdc.1

So I run the the configuration script of AHI again and SFDC is found. Configuration was successfull and the makefiles are now succesfully created.

But when I try to make AHI I get the following error:

SFDC --target=powerpc-unknown-amigaos --mode=gatestubs ../Include/SFD/ahi_lib.sfd --output gatestubs.c \
--gateprefix=gw --libprefix=_ --libarg=last --addvectors=device
T:gmake.sh.1843.WFIUPW[2]: SFDC: No such file or directory
gmake[1]: *** [gatestubs.c] Error 1


Apparently SFDC is not found. So nothing "useful" is created as promised. Upon inspection of the sfdc created in the SDK, sfdc is not a binary but some kind of perl script.
Anybody knows what I am doing wrong here?

if SFDC is a perl script it won't just run, at least it will need to be +es protection bit and the first line will need to be running perl

@geennaam

I haven't used that program, but if the makefile has one or few places with it, place "perl" and the full path in front. Maybe also the full path to perl if needed.

@NinjaCyborg

Thanks. The first line had some unix path to perl in place. Replaced it with #!/SDK/Local/C/perl and now it runs.

Next issue is that perl throws me a script failure. But I will try this next week on AmigaOSFE with the latest SDK. See if this helps.

The Envy24HT driver seems to missing library_card.c and h.
It is supposed to be located in /Drivers/Common and is only needed for the amigaos4 driver.

Going to create dummies and see what happens.

@Thematic

Solved with correcting the path in the script self. Apparantly it wasn't fully configured for Amigaos4 or maybe it was expected to run with some cross compiler.

@geennaam

Lyle Hazelwood has done some recent work on the OS4 AHI drivers. He might give you useful tips. Drop him a line: lylehaze at gmail.

@trixie

Thanks, I will need it.
Both Morphos and Aros use the available library.c and h. Why Amigaos4 ifdefs to the missing library_card instead is a mystery to me.

All I need is a AHI driver source for a "modern" chipset that can actually produce a working driver with the latest SDK to act as a template for my own driver. Because AHI driver development is not/poorly documented.

I read everywhere that the Envy24ht is the most stable driver. Hence this effort.

Found this thread with google:
https://os4coding.net/comment/2378
A guy called Hypex tried to compile the Emu10kx driver with help from the original coder but eventually gave up. Best quote in the thread: "I had to agree with Davy (Wentzler) in the end, that compiling an AHI driver is a bitch! "

@geennaam

Have you tried changing the reference library_card.c/.h references to library.c/.h? It's possible that the library_card files have been removed because they were no longer needed and the driver code just hasn't been updated.

@geennaam
Quote:

Don't expect that things will compile out of the box for aros/morphos/amigaos4/amigaos3 ever. Even if there can be some source code which pretends to, it still will not (many reasons: changed SDKs over time, different include hackish on the developer and public SDKs, native or cross-compiler usage, using of hardcoded paths in build scripts, usage of different make tools (anycygnix one, native one, POSIX one from the "sh" only and so on).


Quote:

Compiling everything on amigaos4 can be a bitch, the matter only your motivation and wish to have a final result. One may give up after few tries and stop at the beginning, another one will solve things one by one, day by day, week by week, and have something in end :)

And btw, it better to not use makefiles done by others, at beginning at least, as you can in end burn out to deal with them. Better to see what files it compiles, and then (for first) manually compile object by object, to solve real issues, and not makefile ones.

@kas1e

The unix path in the sfdc script raised the suspicion that AHI was build with a cross compiler anyways. So I am now creating the cross compiler environment using your blog post

@salass00

Good idea. That is worth a try

@kas1e

Problem is that the AHI makefiles create Os4 specific files with SFDC. So I have to run it at least once.

@kas1e

What really really needs to happen, ahead of pretty much any new development of Amiga OS, is for common, stable universal toolchain to be established that means developers can share and collaborate and not have to worry about differing includes, libs, tools, and all that crap. It's by far the biggest barrier to entry for anyone wanting to come and have a go at doing Amiga stuff.

As a professional software development manager out in the real world, you cannot expect developers to be productive if they spend most of them time faffing with the tooling. Microsoft and Apple figured this out over 20 years go, which is why there's no longer a Borland or Metrowerks or anyone else providing the tooling for Windows and Mac/iOS.

The OS4 SDK was a huge step in the right direction, but it's not been maintained and now it's massively out of date again. I hope it's being updated properly, at the same time as the new OS3.2 SDK is being put together.

@NinjaCyborg
Quote:

The biggest barrier its all those ideas on how to save an amigaos4 and what is need it :)

The OS4 SDK in the current form is more than enough for any native amigaos4 development if you do things from scratch. For real. Nothing else needs it.

All those play-games with new compilers, new versions of GCC and co, that all only for making some modern and fresh stuff to port. Yes, mostly _to port_. For plain, standard, native amigaos4 app there is really no big need for updating SDK.

Updating SDK will happen one day, but not expect it will give you anything which you didn't have now. It will just have updated SYSTEM includes, and GCC, and maybe some other tools (or maybe not). But it will not give you anything which will make you think that everything is as you want it to be.

You still need to download manually stuff, you still need to understand how it all structured, you still need to spend time on all sorts of stuff. And, by the way, the same happens everywhere, I know it, and in windows and in the Linux world.

It's just once you start complaining, you can't stop and will try to find anything which you may think is bad, while in reality if you want to do something, you do it.

New SDK anyway planned, but as I say didn't expect it to be radically different from what is now, just updated system includes, libs and GCC. And if you want updated GCC right now, you just fiddling with adtools, or just not, and use old SDK with no problems too.

@NinjaCyborg

Quote:
Agreed. An updated SDK integrating a recent and well-tested build of GCC, plus all the related tools and documentation, would be a step in the right direction. Not everyone is fond of fishing things out of the adtools repository and other places.

@kas1e

it's that 'just fiddling with adtools' that is not as small as issue as you make out. As bare minimum, OS4 SDK needs newer GCC, ideally 9 or 10, latest clib2/newlib updates included, and setup scripts not just for amiga native toolchain but linux cross compiler too.

Linux might have similar issues, but Windows and Mac certainly do not - as I said, Microsoft and Apple learned that lesson a long long time ago.

@kas1e

Quote:

I spend a day creating a cross compiler environment. First tried several times with msys2. But that didn't work out. Got it working with ADTOOLS on cygwin following your step by step guide here: https://www.amigans.net/modules/xforum/viewtopic.php?post_id=116486

As expected, the SFDC script runs fine in this environment. Unfortunately it produced unusable files that gave a lot of compiler errors.

So I followed your advice and tried to compile the Envy24HT source files one by one.

But it almost feels like the sources are sabotaged.
Envy24HT.c includes pci_wrapper.h and proto/expansions.h
proto/expansions.h includes expansion/pci.h.
In pci.h, we can for example find:

enum enPCIConfigSpace{
PCI_VENDOR_ID = 0x00,
PCI_DEVICE_ID = 0x02,
.. and so on
};

But pci_wrapper.h continues with an #undef PCI_DEVICE_ID
and #define PCI_DEVICE_ID 2

Not only is this useless considering the enum in pci.h. The compiler also punishes me with a "error: expected identifier before numeric constant".

So I have a lot of cleanup to do. Not only fix all compiler errors, but also remove the Morphos and Aros code until I get a clean AmigaOS4 AHI driver framework. (hint: Coffee prices will go up in the coming weeks )

It feels like it will only compile out of the box on the target which was last in line to port the driver to.