I use my bicycle regularly, drive every day to work and nearly every day a little round as training just for fun. Having and iPhone and Apple Watch, it’s very easy to record the tracks with that (I use an app called “Trailes”) of course would be even nicer to have some statistics about it, sadly the App does not really have that.
Therefore I coded my own little tool to show some statistics about my last rounds, as always for the last programs I did I coded it with Free Pascal for Amiga and it worked quiet nicely and easy, most of the stuff is already there in MUIMapparium (reading GPX files and calculating track properties)
So here it is:
2 hours of work and it loads the GPX data and shows them in a nice little table with settings to choose the columns and sort them by it. Free Pascal power at its best.
Working a little bit on the Workbench 1.x compatibility of Free Pascal compilation. A lot of important calls are missing for 1.x which makes it a bit difficult to compile the same program for OS3.x and 1.x especially all the TagList calls are missing. I implemented some of them by hand (like OpenScreenTags, OpenWindowTags) to make it a bit easier. As a test I chose the Free Pascal IDE, I do not really expect it to be usable, because of the huge DOS mode chars und FreeVision emulation, which is needed. But after some days of coding, finally it somehow works (without any changes inside of the IDE source code). In the DOS Mode emulation I changed it to be always on a own 16 color screen and always use the smaller font, everything is unchanged. so very nice.
A little video:
Sadly I still can’t upload the changes because Free Pascal is still on the move to GitLab and it’s not finished.
It’s very common on 68k Amiga to turn off the operating system and directly write to hardware registers to get maximum speed. Many games and demos does it this way. Usually they are written in assembler, but of course this is also possible with Free Pascal for Amiga.
I got that idea because Charlie did a little test how small a program in Free Pascal on Amiga can be. (I guess it can be even smaller than that, when replacing the DosWrite(Output()) by PutStr() and compile for 68020).
So I took his source and tried to make a little bit more useful example out of it and remembered my time doing Amiga 68k Assembler (in ASM-One, I was never good with that, but hey I can learn a bit now)
So I did a little copper list example and it’s 700 bytes long, not bad, as second I tried some bit-plane manipulation. The program became around 3kbyte (most of that is because of the huge sinus table included).
And it runs very nicely on my A1200.
The Source with compiled executable is available on Gitub.
New Release of Free Pascal is done. It’s a bug fix release for 3.2.0 it has also some bug fixes for the Amiga systems, especially structures and functions are checked against official SDKs (especially for MorphOS with its latest SDK Version). For changes that break compatibility you can check official changes document.
Someone asked me to try a CDXL converter (agaconv) but I did not get to work until i compiled it for myself on Linux. CDXL if you don’t know, was an very early movie format invented by Comodore to use for the Amiga CDTV, so it aimed at a 68000 with 7 MHz with a Single speed CD Rom (150 kb/s).
I tried to create some little movies with it and it works quite nicely, especially the agablaster is very good and fast for viewing on a native Amiga (if you have AGA I guess from the Name? I do not own an OCS or ECS Amiga so I can not try). To really get the movie to the small size (to meet the 150kb/s target) you really have to tweak the options. You need to lower den resolution to 160×100 (or lower) and the colors to 5bit (32 colors) or 6bit (HAM6) reduce the number of frames per second to 12 and recalculate the audio to mono 11025 kbit/s.
For me it was interesting to see how the movie would look like with such low quality, as example I took the OpenSource Big Bug Bunny Movie, which is nicely short and free to use without any legal problems.
For a faster Amiga (like a A1200) with a normal HD (around 1 MB/s) you can make the movie in something like 320×200 in 256 colors or even HAM8 and looks rather decent texts still readable sound is ok (just the 8 bit sound conversation is a bit weak, I increased the loudness a bit) and you get a nice movie result, just a bit big (around 500 MB for 8,5 minutes movie). Not all CDXL player can show this format (agablaster does it very nicely)
If you go to the original CDXL format description (as above), it becomes hard, it’s really tiny and greasy you can easily see the dithering and color reduction, texts (except Main Title) not readable at all, back in the days maybe nice (in 1991 or so, when CDTV came out) to at least see a movie but its much worse than CD-i (1990) or VCD (1993).
Because the agaconv is not directly running, need FFMPEG and java (if you want convert to HAM and it it needs a X Server) I created a docker container where all is installed inside working. I created two little scripts (one for Linux and one for Windows) to start the agaconv using the docker, all you need is installed docker and this script and of course the movie.
for example to create the standard movie format as decribed before you need to start it with (linux example):
And a little Bugfix for Ask Your Amiga, especially on AROS, the images would not load properly, fixed that very quickly. Download as always at the AYA Page
I added assumptions to Ask Your Amiga. Assumptions are the way the different meaning of one word are separated from each other in Wolfram alpha. For example if you ask for “Berlin” it will show you information about the capital of germany, but also shows you a list of other cities (mostly in USA) named Berlin and also other meanings like Berlin as a name or a music band (never heard that before) and so on.
Like on the web page I put these assumptions to at the top of the results to select from a cycle widget.
AYA 0.5 with Assumptions
Download latest AYA at hte AYA Page or use the build-in Update Version
Some might wondering what happened to the Free Pascal test result on the Amiga. There are some reasons I did not write about the results. 1. it took much longer than though, especially later tests need much longer to compile and run (more like 30s per test) and 2. some tests crash what leaded to idling computer half of the night until I can let it continue, overall it stopped 8 time, of which it was 3 times a “Guru” and 4 times the enforcer (of Draco) killed the program before it could crash the computer because the program accessed some memory it’s not supposed to and once the Hard disk went full and it stopped with a Disk full requester (I did not notice that the logs and programs need such big amount of HD).
Overall 326 tests are failing either do not compile or the compiled program does not work correctly + for mentioned 7 that crash, which is much more than the m68k-linux test for this compiler version which should be around 40 or. I guess that must be some implementations are missing for the Amiga. I saw scrolling by some Link LibC or other c library errors, which will not work because we did not implement that. The rest I have to check slowly the next days.
It’s not bad after all, 333 tests give problems means around 5600 tests ran well without problems and my Draco did run 3 days without interruption without any problem, also nice to know. After checking the errors, maybe I can fix some of them and make a test list without the 7 crashing tests that I can run on one go. I should repeat that test with the latest Free Pascal and compiled for FPU, especially some tests which are not working with the qemu setup I’m using atm. (if they really show an FPU compiler error or just an qemu problem)
Again got a crazy idea… after my attempts to run the Free Pascal test suite on a real m68k linux (I’m not sure whats the problem it it just stopped at some point but did not start the actual tests) I looked a bit closer how these test run is designed (with a bit Makefile, which does not work on Amiga even with unix kind shell installed, I tried already) I wrote a little program make the list of tests and I got around 5800 test, not the same amount as the original (which is nearly 9000) but ok for first list creation, later maybe find out where are the other tests hidden.
the “dotest” util making the actual test (checking if on the right CPU/OS/Version and so on) does not run because it’s only implemented for windows/dos and unix… and full of {ifdef windows}doDOSstuff{$else}doUNIXstuff{$endif} or vice versa… I made some very nasty changes and implemented a little routine for Amiga to make it at least work to run the tests gather the output and check return code and it works.
Next transfer everything to my Amiga (Draco 68060 in this case) and start and press all thumbs it works somehow.
And? Yeah it works, needs around 10s per test hmmm that makes around 16h for the full 5900 tests :-O ok the Draco is very stable, I just hope none of the test let it crash 😉 lets see tomorrow the result, which tests fail and why 😉 (running currently with 3.2)
If that works well I should also make a run with FPU (thats SoftFPU atm.)
Besides the documentation work I also updated the docker container. I created 4 scripts to compile directly from the docker (without using VNC/lazarus) so you can directly compile in your linux installation, that there is a docker container behind it you barely notice. But it only can compile standard Free Pascal things, no LCL applications (missing pathes to the lcl units, also not easy possible, but without Lazarus make not much sense, I think)
The AROS compilation had a big problem, when you compile without -g option it tries to strip but the strip tool was not installed, so I added some more tools to make it possible to compile without -g (makes the executable much smaller)
On this I updated the lazarus version to the latest version 2.0.12 as well.
If you want to use the newest Version of the docker (with the AROS bugfix) start the “CheckForUpdate.sh” script if you also want to have the direct compile command download the CrossAmigaLazarus Package.
