Deadwood announced a ALSA AHI driver for AROS Hosted which I tried today, the first version crashed AROS completely. But now the second really works very nice. I take out my mp3player again and it is working very nicely, debugging this way is much better ;-).
When I wrote the mp3 player I wanted to make a video with sound, but sadly I noticed the sound recording of RecordMyDesktop seems not to work, its all quiet the whole time. I tried some trick I found online, (direct alsa, pulseaudio and so on) but nothing helped its all quiet. Then I tried some other programs and finally I found one working kazam has not so many options but enough for my needs. So here is my first youtube video with sound 😉
The sound is a free one from youtube Hero Theme by MK2.
As I said before much better would be to link directly to the C LinkLibs instead of writing this wrapper libraries, in the past I always failed because of the autoinit stuff. But now when creating the libraries I learned a little bit more about how it work and finally I was able to make a statically linked connection directly from freepascal unit to AROS C LinkLib. And it works 🙂
Freepascal program links to C Linklib
I played a while ago a funny tiny game on my phone called 2048, really easy concept but makes fun to play. So I wrote an own game for AROS which is inspired by it really easy and nice to program.
Its called BinShifter Bin because of Binary numbers which results from it and shifter because you have to shift the blocks around. With the arrow buttons or cursor keys you shift all blocks to one
direction. If two blocks with the same number are stacked in this direction they are added together and you earn points. The maximum number for one block is 4096 (like the numbers of colors
of the original Amiga ;-)). The game ends when no movement is possible.
BinShifter 1.0 i386-aros
Bin Shifter 1.0
Good news, the Libraries I created are also compilable at AROS x64, so this learns us two things. First it also works on 64Bit (also with 64Bit freepascal) and Second it also works on ABIv1 (64bit AROS is ABIv1 only). The testlib worked just without any additional actions. sqlite3.library needed some work, seems some C Linklibs are changed so the Makefile libs had to change a lot. The compilation worked well then, but the example program crashed. Seems it always crash when it tries to convert a float to a string, if I read the double by Hand and use the pascal routine to convert it to string it works without problems. Hmm strange problem, especially because the rest is working without any problems. Because of the previous problems with AROS64… it’s maybe a just a AROS64 bug. so I changed my example source 😛 and now it works perfectly.
Freepascal SQLite3 on AROS64
Worked a little bit more on the sqlite3.library for AROS to use in freepascal. Its more or less only diligent working, and take care not to mix up anything. I didn’t include all the functions only the most important until now (at least what I think is most important) until now its already 106 functions inside the library.
Now I tried some test codes… the one from fpc directly are rather boring, even less impressive than my own examplecode.
But I found a german Tutorial how to use databases in Lazarus, with some tiny changes in in Lazarus component it compiles really nicely and works as expected.
SQLite3 freepascal example program
Left side Linux, Right side AROS.
I published the first part of the Libraries creation at github. For now only the basic test library with some description how to use. The next will be the sqlite3 start I did.
AROS-Libraries at Github
Currently we are only able to use the shared AROS .libraries, so every C link lib is not available in freepascal for AROS. For example sqlite3, SDL, GLUT, SSL and and and much things only available as c linklibs.
I tried once long time before to use the c link libs directly but failed because of the „auto library init“ needed by them.
But of course the other way round, maybe would be possible to specially create a library in C which can be used in freepascal later. I’m not very good in C neither in Makefile magic but hey worth a try. First the official documentation is just crap, not existing (many 404 there, seems someone deleted/moved the documentation) or very old (already written in there that it will change in 2006 and the docu gets not updated) and what I found is just a documentation about how to create a library inside the AROS core build process. I don’t want to compile the complete AROS just to get my Library compiled. Shit, luckily I found an other library which had the same problem and which also come with the source (which is rather seldom on Amiga-style systems, but on AROS more common, but there not so many 3rd party libraries available, one I found)
With this it was rather easy to create a own custom build library with a simple function inside.
The next step was to include sqlite3 to the library. I decided for sqlite3 because its the easiest to check for success and even with some functions its already useful. The task sounded easy but exactly there the problems started, as always.
Again the „compiler magic“ autoinit killed me many times. Finally I found out that I can invoke this autoinit from my initialization by hand. And finally it worked.
This is now a single instance library, a pertask library would make more sense but I didn’t find out how to change that behavior (just to change a flag in the libinit structure was maybe too easy for the designer of this system). But for sqlite3 its not a big problem, it mostly work on a db which have to be opened and closed before using and then always must be supplied to the library. There are some calls which are not threadsafe like sqlite3_config or so but they could be protected via a mutex later. So for now not a big problem, maybe later I find a way to switch to pertask behavior.
The library includes now: sqlite3_open(), sqlite3_close(), sqlite3_free(), sqlite3_exec(). Which is enough to create a database, create a table, add some data and make some selections + output which I tested with a tiny pascal program.
The make process is not complete done and understood by me, there I have some more work to do and then one could begin to include all the sqlite3 functions to the library and make some more tests and of course write a pascal wrapper unit 😉
The long term idea would be also again to check how one could use the link libs directly in freepascal, when creating the c library I got much more knowledge how this autoinit things are working, maybe one could copy this to freepascal.
Played around a little bit with graphics and game mechanics. Result is (until now) a Pipe-like game just for fun.
Playing around with the LCL for MorphOS, seems to work nicely, but (as described last time already) it crashes on Exit. I tried to find the reason for it. It seems that that the MUI Objects are kind of destroyed already, even still visible on the screen. Due to the special way to work in LCL I do not like the automatic destroy function of MUI. If you build up a mui application with application, window, items in there you usually only need to destroy the application and every thing else will just be automatically destroyed. Of course thats not what we want to use for LCL (or it would be impossible to destroy single button/Windows and so on). Long time before at AROS I played around with it and the best solution is to just unlink the item from its parent and destroy it by hand (MUI_DisposeObject) because then it is always in my full control when an object gets destroyed or alive.
Seems thats exactly my problem now. When I begin to destroy my objects at some point it seems that the MUI Objects are already destroyed, so it crashes, but this object (window) is still visible on the screen. I removed all MUI_DisposeObject from my code and still the Window gets destroyed somehow :-O and the mui objects are invalid. Here happens something I do not understand. Really strange thing, maybe its some special „new MUI Version“-thing? I don’t know and not really an idea how to continue here. Maybe I need to write a simple non-LCL program where I do the same and try to find out this strange behaviour.
A long time ago I played around with x64 AROS already. Of course I would like to freepascal on it as well. Even on the first implementations of freepascal fr AROS i386 I already enabled and included basics for x64 AROS but I never got it to work, because my freepascal branch didn’t compile for x64 because it was at some broken state. Now at the trunk of course it will work again. In April 2015 I tried again and reached very fast the point to write the assembler startupcode. The same problem as before (with i386) no idea how it should look like. I looked a little bit around (also into the other startupcodes of other x64 fpc platforms, linux mostly) and took a shot. Sadly it didn’t work it always told me „bad load hunk“. So from time to time I looked into when I have only little time (not enough time to do anything useful at LCL) but I didn’t get any idea. Yesterday evening (already in bed just before sleep) I got an idea, and today evening I tried it very shortly and it gives not an error message but crash. YEAH! Never so happy about a crash. But why it crashs? ABIv1 problems? The Stacktrace tells me it crashes inside dos.library/Error with an _aros_not_implemented_ error :-O. This call gets the Error Output filehandle, seems still does not exists on x64 AROS. Easy solution comment out and use the Output stream as Error stream like Amiga and MorphOS do.
And finally it is working 😉
Of course its only a very bad hacked version currently and no ABIv1 things are done, so the compiler self does not really work (crashes on linker calling). But it shows that it will be possible to make an fpc for x64 AROS. Of course I have to talk to Charlie to check how to make a syscall for x64 (is even easier than i386) and how to make such ABI difference. but it is not really in hurry.
