I think it's getting a bit silly now. The last update fundamentally broke some really important parts of the SDK for anyone wanting to do any drivers (which are pivotal for the OS), and we still don't have an update.
For four months now I've been wanting to work on getting more done on my TV card and I've not been able to because of the lack of an SDK.
I know SDKs don't grow on trees, but this is getting daft. Can't we at least have a diff to the parts of the docs/includes that are broken?
Sorry to sound impatient but how on earth are people expected to code for an OS when the only SDK that exists publically is out of date and useless when it comes to things like driver writing? It's getting incredibly frustrating.
(For those not in the know: the last update changed the function AllocMem() and a parameter was removed which was essential for allocating a contiguous DMA'able chunk of memory. You now need to use AllocVecTags() I think but that function doesn't exist in the latest 51.22 SDK. Hence it's impossible to DMA anything with the current SDK!)
Developers might be interested in this: We're also working on a new SDK right now. The final on the CD will include support for loading UNIX-liked shared objects, and the SDK will be able to produce them (like a libpython.so) (I finished libpython.so today BTW ) Python is a scripting language that can be incorporated into your own program. For example, Blender uses it for scripting. The shared objects will be 100% like under Linux, meaning that most of the time you can create them without editing a makefile.
But of course it should be possible for devs to ask Hyperion directly for an earlier up-to-date version of the SDK
Personally i really like to see your TV card driver come to life, especially because i don't want to kill my Plasma with the channel logos burned in...please keep on
... but I wish they'd prioritise a bit more developer-friendly. I'm not sure they realise that the lack of a complete SDK means that until it comes out no developer can write a driver - all because of one or two files.
I understand why they want to make the SDK encompass all the new stuff, but in doing so they're holding up development on other projects which have nothing to do with it. Kind of annoying....
great to hear you're still 'working' on it (even if you arent able to get anything done ) I'm hungry for this - I havent used been able to use my TV card for about a year now (since Upd 4 IIRC). even tried tinkering with the code you sent me, to no avail.
I've even considered moving it to the girl's Peecee (spit!) in the dining roomjust so it gets used.
Work is still going on on the SDK. As you might have read in my recent Q&A, the latest AmigaOS will contain the possibility for shared object files like UNIX, and that requires a new toolchain (actually changed spec file for the compiler and slightly modified binutils). So the SDK will be bumped in importance RSN.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Rogue wrote: ...the latest AmigaOS will contain the possibility for shared object files like UNIX, and that requires a new toolchain (actually changed spec file for the compiler and slightly modified binutils). So the SDK will be bumped in importance RSN.
I noticed the IBM SDK for the PPC family also is using a shared library feature. In my programming ignorance it seemed to be an important addition. Especially as IBM was claiming that its SDK made it considerably easier to code for all the range of PPC based CPUs.
Thanks for the reply. You'll have to excuse my impatience as I know there's a lot of work to do in an SDK and you're all very busy... but it's so frustrating seeing all these people deprived of software when there's people like myself who can't do any coding just because of one or two files which are being held up by stuff that I don't need (yet!).
I share your pain, although not on quite as large a scale. I have projects that have a pressing need for recognising DST and being able to manipulate 32-bit icons.
(I also want to see the DOS pattern-matching fixed so that # works as it should, but that's another story)
At least it sounds as if the new SDK is getting closer. I appreciate that there are other things to be done, but the SDK should have been a little bit higher priority given that nobody will buy OS4 unless there are apps for it.
I've already posted this over on utilitybase.com (see here), but you're more likely to know the answer to this:
Now that Unix style shared-objects are usable on the Amiga, I'm wondering what the differences are between the Amiga OS4 ABI and the ABI used for PowerPC Linux (the Sys V ABI?). More specifically, could Linux compiled shared objects be used under Amiga OS4, assuming that they don't rely on kernel code that we don't have?
Hans wrote: @Rogue Now that Unix style shared-objects are usable on the Amiga, I'm wondering what the differences are between the Amiga OS4 ABI and the ABI used for PowerPC Linux (the Sys V ABI?). More specifically, could Linux compiled shared objects be used under Amiga OS4, assuming that they don't rely on kernel code that we don't have?
Hans
I don't think it would work. It may work in some cases, since both AmigaOS 4.0 and Linux use the SysV ABI, but for example Linux binaries have their relocs removed, because Linux binaries are supposed to work on fixed addresses, and that won't work on AmigaOS.
In general, you would probably be better off to recompile them; if you cannot because of missing symbols or something like that, chances are the binaries wouldn't work either.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Hans wrote: @Rogue Now that Unix style shared-objects are usable on the Amiga, I'm wondering what the differences are between the Amiga OS4 ABI and the ABI used for PowerPC Linux (the Sys V ABI?). More specifically, could Linux compiled shared objects be used under Amiga OS4, assuming that they don't rely on kernel code that we don't have?
Hans
I don't think it would work. It may work in some cases, since both AmigaOS 4.0 and Linux use the SysV ABI, but for example Linux binaries have their relocs removed, because Linux binaries are supposed to work on fixed addresses, and that won't work on AmigaOS.
In general, you would probably be better off to recompile them; if you cannot because of missing symbols or something like that, chances are the binaries wouldn't work either.
Thanks for your reply. I thought that there might be a catch somewhere. I was thinking in terms of using shared objects that are available in binary only format. Obviously not feasible.