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.

Another Noob question:
I am writing a amigaos4.1 library and want to save streamed data to a file.
Therefore I've created a child process for saving inside an amigaos4.1 library with:


There is little documentation available but from what is available I understand that each (child) process must have it's own interface to external libraries.
So how does this work? Is it as simple as just opening a second Interface and use this in child process because the library is already opened in the main process?:




Can I pass on the same lib base to the child process and in the same way what is done for the functions in the main process?


Up to now, nothing has been easy in amigaland. Little documentation so a very steep learning curve. But I am not about to give up yet .

@geennaam

I can't answer all of your questions but this is how I create a child process in one of my programs:



Right after creating the child process I send a startup message to the child's message port (get the pointer from the Project structure: &process->pr_MsgPort), the reply port being the main program's port. At the beginning of project_func() the child process waits for the startup message to arrive at its port, while the main process waits for the reply at the main port. Neither continues before all messages/replies have been duly received.

If I want to pass data between the main process and the child, I use a global data structure that has a struct Message at the very beginning. This way I can send the data as part of the startup message, ready for the child to pick up:



Hope this helps a little.

@trixie

The problem with libraries is that there is no startup code to create global variables for interfaces and variables like IDOS or DosBase. It is supposed to be good practice to store this in the library base structure. And so I did. This is why you see libBase->IExec in my code.

This structure is passed on to every "method" (my Library interface functions). But a child process is not an interface function. It cannot be called by the program which opens my library. So the library base structure with the external library interfaces like IExec is not passed on to the process.

I did a dirty trick by creating an addition global libBase called ProcLibBase and pointed it to the libBase of the main process inside the my library interface function that creates the child process. So now I have a local libBase and a global ProcLibBase. Because it is global, I can now call library funtions in the child process.

I noticed that you use the Tag NP_Child. According to this site (https://os4coding.net/forum/sharing-interfaces-your-children), this mean that both processes share the same context. And that it is reasonable safe to share the same external library interfaces like IDOS.

I only need to signal the process that it is now ok to start. The process will signal the main process when done. So I use signals instead of the message port.
So the signals are exchanged through the global ProcLibBase and this works. Don't know if i get a slap in my face by someone.
Still open for the proper implementation