To be honest I don’t watch much TV, I like playing games much more but sometimes there are nice movies or interesting news, but mostly I’m repelled by the amount of commercials these days.
But nevertheless I have a satellite bowl and it connected to a DVB-S2 card in my Linux server with TVHeadend as TV server which works quite nicely especially together with Kodi. But the Webpage does not work very nicely, the it’s very complicated and the in browser watching of TV program does not work most of the time. So I seldom use it (basically only to program recordings).
In the past there was a nice VLC plugin for it make it very easy to use, sadly it’s not maintained for very long time. VLC moved on and the plugin does not work again, I got it to compile somehow but still no luck still does not work.
A long introduction to what I did now, the TVHeadend have a JSON based API, therefore it was rather easy to write a little program to get all the information from the Server show it in a window and select a channel to stream. And of course as I always do when I start a new program I also make it for Amiga style systems, MorphOS is this case. (but also for Linux 😉 )
This weekend I extended (and sometimes created) the documentation for all four Amiga systems library units (amunits, arosunits, morphunits, os4units) and the util units (ami-extra).
It is available as chm file or HTML pages created with the Free Pascal fpdoc tool. The documentation is kept in separate XML file, I created a GitHub repository for that.
The build server compiles the documentation on every change and put it for download an direct use to the build server pages
There is also a new SDK (3.16) for MorphOS which also has some new function to handle TLS-memory functions (Thread Locale Storage) to handle variable switching for different threads. Charlie wants to use them for Free Pascal thread implementation for MorphOS (AThreads). To make it easier I checked the current SDK and tried to update the Free Pascal library units for MorphOS. (of course not only the TLS functions, but all updates I found). And to make it even easier also created the documentation for these functions.
My long term plan is to have for many of the library units functions an example code, I added now example code for ExamineFH, Examine/ ExNext and MatchFirst/MatchNext.
Another little project for KC85 (MicroDOS, ML-DOS or any other CP/M) a little game, the Graphic output is really slow, because done by escape sequences, so only a slow thinking game comes to mid, like the sudoku i wrote a while before. But here an other arise it uses a solver to create sudoku fields which are valid, but this is heavy recursive and did not work, but I tweaked it a bit, now it does work most of the times, but sometimes it can not find a suitable solution and just stop (due to bad radnom values for the start). To net let it run in an endless loop I tell the user that there might be a problem with too deep recursive steps and if he wants to try again, mostly it still will not find anything nice, mostly you have to end the program and restart, but most of the time it works.
Sudoku on ML-DOS KC85
I still do not get how the colors work, I found function to change front and back color but they are changing the whole screen. I also found fond a drawing colors but they seem not to do anything, strange. Thats the reason I let it be b/w instead of colors for the fixed values. As marker for the fixed Values I placed a point behind them. To select a field to edit I just use the cursor Keys or wasd 😉
It can also load and save files if you want to stop but later continue the with same field and the positions you found already.
Small improvements on the HEX2 for CP/M especially KC85 with MicroDOS/ML-DOS. Some little suggestions, like a command history and a command line option, both now included. The History option needed that I program myself the key input (instead of just using Readln) but this also means one can now edit the string if you made a mistake. You can use the Cursor keys right and left to move the cursor and type and “Del” to delete a char, but Delete works here like a Backspace.
The History function keeps the last 10 commands you send to HEX2 in a ring buffer and you can use cursor up and down to browse and edit them.
An other wish was to use the command line parameter to directly calculate and just return the result, rather easy really so I also included that as well.
I was able to revert mostly all of the memory saving tricks I tried (like overlays) because they are apparently not needed. When I compile it on MicroDOS it runs even without this tricks. And even a simple hello world compiled on ML-DOS does not work on MicroDOS, very strange, sounds like a bug in ML-DOS to me.
I got my KC85 up an running with ML-DOS a CP/M 2.2 clone, it runs rather well. The main reason I wanted this is that there is a Turbo Pascal 3.3 for CP/M 2.2 Z80 (KC85 has a U880 which is a Z80 clone). I assumed that this would be much easier to use as the native KC-PASCAL which I showed before. And I was right, this feels already much more like a modern pascal. Of course there are many limitation due of age and because of limitations of 8 bit computers.
As a starter I tried to bring my Hex2 calculator, which already exists for Windows/Amiga/Linux/Mac of course here as command line tool (as I did as a starter for Amiga as well)
But that as not so easy, I was underestimating how little 64kb RAM is. This all is new for me, comparing with that even a A500 has a huge amount of memory. Here on 8bit you have to think about to put to many texts into the code, it just inflates the RAM need. I tried to optimize it a lot by keep the texts (help/error) in extra files and only load them when I need them and even use overlays but still on MicroDos I don’t get it to run, seems the program is still too big, but not sure how to solve that any further, maybe I still do something stupid there.
Hex2 under ML-DOS on a KC85/4
Nevertheless I make a first release of it 0.1 and it nearly has the same feature set as the other version, nice to have my standard tool on all platforms.
I never came that far to compile LCL (and / or Lazarus) for AROS 64bit but of course I always cared about 64-bit compatibility on the way to implement it (as far as possible).
Now with 3.2 out and Lazarus adapted to it with some minor tweak it was possible to compile LCL stuff for AROS64, even more complicated stuff like EdiSyn.
Sadly there are still some bugs, especially in the external components I use. For example the ATTabs, as you can see the caption in the Tabs are missing and if you click on one some strange things happen. After all it is somehow working but not completely fine.
As promised I worked on the Amiga OS 4 problem in Lazarus Cross Amiga Docker. I tried to used vlink and vasm for it, but it seems vlink has some problems with the resources. But when switching back to the GNU tools (as and ld) it again works.
Cross Amiga Lazarus compiles for Amiga OS 4
I also added a little Updater Script to the archive, so if you want to use the new Amiga OS 4 download again the archive. Start the script ./CheckForUpdate.sh if there is a newer version of the docker it will automatically download.
I’m playing with docker and how to put Free Pascal for Amiga Systems and even Lazarus inside a docker container. Works quiet nicely with the latest FPC (3.2.0) and Lazarus (2.0.10), sadly there are some bugs in the published MUI interface for Lazarus, or better left overs of old Free Pascal inconsistencies between the Amiga flavors. I fixed them in FPC but did forget to remove the workarounds in the LCL. So I had to patch the official LCL. Must also check them in the official repository. Sadly the OS4 the LCL compile does not work at all, something wrong with the resource stuff, so I removed it for now. I will look into it later. So still some stuff to work on.
To actually use the Lazarus IDE I also installed a VNC server and hence also a small as possible window manager, I played around with some simple one, most old simple window managers are very annoying (e.g. twm) but icewm seems to be nice (looks like Java though).
And why docker? It’s much easier to keep the software up to date and there are automatically running scripts to create, modify and start them. But there are some drawbacks. The first compilation of a LCL program for any Amiga-style system will need a long time (as seen in the video), because it will compile the whole LCL. This will happen for every start of the docker container. This is good to have a clean compilation of LCL (especially when developing on the actual LCL) but a bit annoying when only compile simple programs. There should be some ways around it. But for now for me that’s good enough.
Raycaster compiled for all my Amiga computers available and it compiles and works nicely… mostly (turned map off for A1200, for the other does not make much difference in speed).
