I was searching for an mp3 decoder in pascal… seems it does not exists… (or at least not for free to download).
Of course there are many C examples, so I took a very simple C source, I ported it to Pascal, not a very fast source, but hopefully easier to understand.
The port work (even at AROS 😉 ) but is really VERY slow.
After a long time again a little bugfix release of fpc, and first release of clipboard support for aros (there is an example script in the src directory of fp)
The news:
Download like always on the fpc aros page
Today I cared about the Clipboard in aros, how to get a text from there and how to put a text here.
I should say it was not that difficult, but only because I had a example source code in C functions toClip and fromCli. But first I had to create an iffparse unit because the informations are saved as IFF in the clipboard. Has the advantage that you can everything what you can transport via IFF format, so pictures, sounds and of course Text.
The first function GetTextFromClip was really simple and worked directly, PutTextToClip in principle the same easy task but it didn’t work always end with error -6 on PushChunks. I compared all calls and variables but all seems to be correct. Then I tried to make copy paste in editor but there it also didn’t work. So Something was wrong with AROS self. After a restart of AROS both routines worked very nice, strange like always.
I will put both routines into Clipboard unit for easy access from fpc programs. Perhaps later also make a version for images.
As first test I added it to the FP IDE, there is already something prepared for windows to get the Clipboard from Windows.
Today I bring all together and release. A not complete lists of changes/bugfixes for this realease:
* some basic units moved from arosunits to rtl, also helpful if later joined with amiga and morphos
– amigados, agraphics, exec, inputevent, intuition, layers,
– longarray, pastoc, tagsarray, timer, utility
– IMPORTANT: DELETE UNITS BEFORE INSTALL NEW VERSION TO GET RID OF UNITS IN OLD DIRECTORY
* changed all library calls to cdecl
* Startup and finishing code improved
* FileGetDate/FileSetDate implemented
* GetEnvironmentVariableCount/GetEnvironmentString implemented (example code by magorium)
* Video unit with fullscreen support (color tag = False)
* Keyboard unit rewritten, better identification of keys for fp ide, mousewheel as pgup/pgdwn
* free vision GetDosTicks implemented (needed for double click)
* layers aros unit (thanks to anon and magorium)
* FPGUI:
– MOUSEENTER/MOUSELEAVE implemented
– MOUSEMOVE with mouse grabbing
– KEYRELEASE implemented
– Input focus implemented
– Modal windows, blocking of other windows
– save closing of window (removing of messages from message port)
– combobox closing when a entry is selected repaired (hopefully)
check out https://blog.alb42.de/fpc-aros/ for the last Version
With new Icons from my old OS3.9 Installation (my real A1200 in the cellar)
Not very easy to get the icons to AROS, the original Icons are just black, converter are rare and if existing only work with MagicWB colors, but this Icons have a much more colorful set.
Lucky OS3.9 can export both pictures via info dialog.
Cclick to picture -> menu save as, the current state is save as IFF file
Can be converted with nconvert to png and used as icon in AROS.
Screenshot of my old Amiga installation (still without Graphicscard, so it must be 1999, short before I bought my CyberVision 3D) its running nicely in UAE, but still slower as in real amiga, especially the rainbow background makes it very slow.
Sometimes when a Button or so is destroyed in runtime the software crashed because in the messageport still some messages for this particular object and I have no chance to see if it is still alive.
First Idea was to poll all messages before destroy this windowthis was implemented when writing the Message for 07.01.2013 in this blog the first error report. But now I noticed sometimes a stack overflow appear when large windows are closed.
When searching for CloseWindowSafely Amiga you find a lot of source snips which all do the same, remove all messages for this window from the messageport.
for example this
So the StripIntuiMessage is exactly what I need, conversation to Pascal is simple, the problem was it didn’t change the problem. I changed the routine that it counts how many messages are there and how many are removed. So at least it does something. Then I let the routine run twice one after the other so the second should not find a message and the overall should be smaller (because removed messages). I was surprised that the messages are not be removed.. so both runs are identical, I’m not sure whats wrong with my routine it does exactly the same as this C routine. So in the end I wrote a complete new routine, which gets all messages with GetMsg and then put them back with PutMsg when they not belong the removed window. Task done, now its working.
Another task I set for myself was the keybinding for fp-editor, and this is really crap, finally I think it would be easier to make a very big table for all cases, so all keys combinations with shift, alt, ctrl, sounds crazy but this keycodes have no real systematics. The most keys are working already… so menu keys, copy paste and so on, are working also mark text with keys is working, but still need some testing.
When I started to bring FreePascal to AROS I had no idea how this should be especially the startup code was something like magic. The startup codes are mostly in Assembler, I used much i386 and x64 Assembler, even machine code already (created an compiler to machine code). But for this you have to know about the inner system of aros and freepascal and additionally this assembler uses a rather strange syntax AT&T, ok when look right to it the intel syntax is strange… but I’m more used to it.
So I just looked into the different i386 implementations for linux, ppc for amiga and tried to guess how it should look like, in principle it was just a lucky shot. And I was rather surprise that the startup worked, just the finish was nearly impossible, for me this was more or less obvious because I do not know what AROS expect on the stack after the program.
The simple approach was DosExit, a call in dos.library which ends the process directly, but because its such a hard end it leaves some memory leaks open, especially the dos.library stays open (of course it must be open to call this DosExit). The conseqeuence was when calling very often after a while you get some strange effects like „out of memory“ even there are some hundred megabytes free.
Finally I got disturbed by it and try to find a different solution.
First I tried what happen when I just leave the program directly again, seems everything works nicely.. so it seems Aros expect the same stack as started, so more or less its just a CDECL call of „start“ with CommandLine, CommandLineLength and Execbase as arguments. As in the copied startup code of linux I saved the stack pointer called my program restored the stack pointer. Sadly this did not work, on „ret“ it looked like it jumped back into my fpc program and not back to aros system., so for me it looked like the stack is not at right position. I compared the stack entry by entry, its exactly the saem before and after my routine, so this was not my problem. Of course I didn’t noticed this directly, this would be too easy. First I tried 3 days to debug this situation why my stack could be wrong or destroyed or whatever and thats all without a real debugger and without output (writeln does not work at this position of course). In germany we say „I was barking at the wrong tree.“
Ok back to problem, I noticed that the stack is completely the same, so what else could it be, of course the other registers. So I added pushad/popad (in AT&T syntax its pushal/popal) and its working I was really surprised about this. It seems that the starting of a program in AROS is really just like call a subroutine… which was not obvious for me because I guessed you get a new process so also get a clean set of registers.
I’m not really sure if I saved now enough… how about SSE registers? FPU registers? until now fpu seems always be empty, sse register difficult to say. Much more interresting will be for x64 if one day I will also bring fpc to there (its my wish) there is no pushal/popal and much registers.
Nevertheless its working now, included in the next release.
As long I wrote down so much bugs I should also begin to fix them. I will collect some more before I make a release.
The first one:
– sometimes a dialog window freezes complete AROS, when closed via OK button -> workaround: use X of window to close
is a very hard one… there are some problems come together, first a little bit about the problem:
I have very much windows (because every button, memo, edit usw. all are windows) so I decided to have one Global message port where all my messages arrive together. The messages have a IDCMPWindow field where I can read which Window recieved the message. Now when someone press the button to close the window it can be that there are some more messages for this Window. So the Window is destroyed but some more messages for them appear. Solution sounds rather simple but was not because of structure of fpgui: When I destroy a window, then I check if there are some more messages for this window and remove them.
– displacements of menus and comboboxes
party solved, so at least the mouse position is right when selecting entries… but its still a little bit too high.. and for comboboxes its too low
– wrong key binding
magorium from Aros-Exec forum reminded me that AROS send press and release message… But my implementation does not… I got one message only. I noticed that the message is not sent if IDCMP_VANILLAKEY is set… which is practical becasue you get directly the pressed char… IDCMP_RAWKEY gives only the keycode. But there is a very nice function in kemap.library to map the keycode to the char: MapRawkey. So I wrote a unit for keymap.library. The result is that I now have the exact key down and key up messages as I need them. I noticed that some crashes disappear (in UIDesigner when delete an item).
– change of focus with Tab does not change focus
This was rather easy to solve, I just looked into Windows implementation. So before send the key message to the item get the focussed item with FindKeyboardFocus.
– Missing concept of modal windows
Modal windows work now, its already well prepared in the fpgui interface, there is a field TopModalForm where one can get if a modal window is open at the moment. So I also implemented a function that the modal window is (re-)activated if an other window is clicked.
– Mouse over, MouseEnter MouseLeave still no way to implement
not really a implementation for it but I have an idea just as reminder want write down here. There is a function WhichLayer in layers.library seems exactly what I need.
all together should be something like this:
LockLayerInfo(@(Screen^.LayerInfo));
Layer := WhichLayer(@(Screen^.LayerInfo), Screen^.MouseX, Screen^.MouseY);
UnlockLayerInfo(@(Screen^.LayerInfo));
if Assigned(Layer) thenResult := Layer^.Window;
With this should be possible, just need to write the layers unit and check how this leave and enter messages work.
As people begin to ask for fpc release with fpgui and the fp-editor.
I checked the installation and ordered some things, wrote a manual, added uidesigner (of fpgui) and and the fp editor.
serk118uk in aros-exec Forum reminded me of the „good old days“ where „it was just little bluescreen with ide and (F5) to compile..“ turbopascal, freepascal has a very similar surface with a turbo vision like surface. I remember that the ide for morphos is already prepared and working, so it should be not so difficult to bring it to aros. So here it is…. I’m feeling younger than ever.
besides this I worked on the key press problem it seems now its completely working (except § and some special chars but i dont‘ know why I also need an other keyboard for my computer… this one has no right amiga key so I can’t test it (and no copy paste).
The menu shift problem is partly solved but still needs some testing.
I’m also aware that finally it will be important to write a sort of installation manual and readme for fpc@aro. Also the release archive must be reorganized before it can be a real release of fpc with fpgui. I hope soon I have time for it.