Wednesday, November 27, 2019

Coroutine68k - Stackful coroutines for Bare Metal 68k Applications in C++

Recently I've read through the enhancements the C++ fans get with C++20.
I was especially interested in the concept of coroutines as it is an approach for asynchronous programming and an alternative to state machines. The latter always have the problem that they are unstructured and it sometimes is difficult to "see" the flow of the states. On the other hand a synchronous algorithm as a structured program might be easier to understand.

The GCC is still not ready for C++20 so stackless coroutines are currently only possible using the mechanism used by Protothreads. But stackful coroutines on the other hand just need some context switching which can be implemented inside a library.

As I'm currently on a 68k trip I wondered how easy it would be to create a similar thing for that processor. Last weekend I've made a small case study and published it as a small open project on github. Enjoy.

Friday, September 20, 2019

Connecting an Amiga Monitor to a modern Nvidia GTX 960

Disclaimer:
The methods described in this article can generate malicous video signals that are able to damage your CRT.
Please apply anything written here with care and thought. I can't be held responsible for damages on your hardware.
That said, if your monitor is showing strange rolling screens or makes noises that it has never made before, SHUT IT DOWN immeditatly.

Well, let's start....

How to use an RGB Monitor with ~15 kHz horizontal frequency on a modern graphics card?
I don't know if this topic was already addressed at various sites and forums on the internet. Some MAME enthusiasts seem to try to get this running. But with some random scripts from the internet I had no luck. So here is how I did it.

First of all? Why?
Simple! Native Amiga video modes on a PC for proper visuals with emulators!

Of course this means that an unusual horizontal frequency is needed. While standard VGA modes rely onto ~31kHz, a lower frequency is not reachable with standard methods as such a modeline will most likely be not accepted by Xorg.

Also of course you need of connecting your PC to your Amiga monitor.
There do exist passive cables with VGA on one side and SCART on the other.
As my GTX 960 doesn't offer a VGA port I've also used a DVI-I to VGA adapter without issues.

How to enable flexible clock rates

I assume that currently no xorg.conf file is used on your system.
This is quite common in in the current Linux world as the modes are now auto configured.

Open nvidia-settings.
Click on "XServer Display Configuration"
Click on "Save to X Configuration File" and save a folder you are allowed to.

Edit the file and search for this line:

    HorizSync       30.0 - 83.0

Replace 30.0 by 13.0 and save that file to /etc/X11/xorg.conf

Restart Xorg and pray that it's still running.

You are now able to set horizontal frequencies below any VGA standard.

Add some modes

As I live in a PAL country I'm used to PAL video modes on my Amiga system.
There are 3 common video modes which were used.

320 x 256 progressive, nearly square pixels, mostly used for games
640 x 256 progressive, pixels with half width, mostly used on workbench
640 x 512 interlaced, the perfect way to damage your eyes

At least for games 320 x 256 is probably a nice resolution to work with.
640 x 256 is supported by Xorg but I haven't found any program which is in harmony with that mode. It seems non square pixels are not common any more.

Now onto some modelines you can add with xrandr:

These modes have a similar timing to the Amiga ones on a 1084 monitor.
You don't need to readjust the monitor to switch between your Linux system and your Amiga:

xrandr --newmode 320x256_50.08    7.09379   320 363 388 454   256 273 278 312  -hsync -vsync
xrandr --newmode 640x512_25.00i  14.18758   640 720 770 908   512 542 547 625  -hsync -vsync interlace

If you like to have some overscan this can be used:

xrandr --newmode 768x576@25i     14.75      768 789 858 944   576 581 586 625  -hsync -vsync interlace


For NTSC these can be used. I haven't tested them with an Amiga emulator though. Please keep in mind that these resolutions are not exactly the ones you find on an US Amiga model. Use them as a starting point.

xrandr --newmode 320x210_60.12    7.15909   320 363 388 458   210 225 230 260  -HSync -VSync
xrandr --newmode 640x210_60.12   14.31818   640 726 776 916   210 225 230 260  -HSync -VSync
xrandr --newmode 640x435_30.07i  14.31818   640 720 760 907   435 456 460 525  -hsync -vsync interlace


Again some overscan:

xrandr --newmode 720x480@30i     13.5       720 736 799 858   480 486 492 525  -hsync -vsync interlace


Now as the modes are created we need to add them:
In my case I have do to this:

xrandr --addmode DVI-I-0 320x256_50.08

And to switch to that mode:

xrandr --output DVI-I-0 --mode 320x256_50.08

Your monitor should now show the upper left of your desktop.
Use something like this to create an extended desktop to have a different view on your CRT.

xrandr --output DVI-I-0 --left-of HDMI-0 

I've tested this configuration with fs-uae in full screen mode and the results seems to look like it was executed on a real Amiga which is some really cool shit.

To avoid tearing in fs-uae you need to add video_sync = 1 to your .fs-uae config file. Without it, a tear line is very slowly traveling down the screen. :-(



Monday, September 16, 2019

Custom git diff tool for Tiled

As I'm currently developing Tiny Little Slug and I use tiled for the levels I had the frequent issue that I wanted to compare .tmx files over the history of the game. As .tmx files are rather difficult to parse with the human brain I thought it must be possible to get an automated image export from tiled. And I was lucky. Here is my approach:

Create a text file with this content. I name it tileddiff.

#!/bin/bash

tmxrasterizer "$1" /tmp/local.png || exit 1
tmxrasterizer "$2" /tmp/remote.png || exit 1
compare /tmp/local.png /tmp/remote.png /tmp/view.png
eog /tmp/view.png


Save it at a preferred place and make it executable.
Edit your ~/.gitconfig and add these lines at the end:

[difftool "tiled"]
    cmd = /home/derp/bin/tileddiff "$LOCAL" "$REMOTE"

Then use this call to let's say compare the current state to the last one.

git difftool -t tiled HEAD~1

You should see a nice visualization where all changed tiles are highlighted in red.

Possible Problems:
Please keep in mind that this only compares .tmx files. If you have external dependencies like .png or .tsx files this approach will probably not work.
Differences between .tsx files are easy to observe though.
And comparing .png files is a different story. But the approach presented here will work for .png files as well ;-)

Friday, June 21, 2019

How to fix WLAN issues with Debian Linux and the Acer Aspire 5

I've recently bought the Acer Aspire 5 A515-52G-53PU and experienced issues with the Wifi. This blog entry is for anyone with the same issues.

After some days I've experienced that my system ignored touch input with a frequency of 1 second. sudo dmesg -c exposed this:

[  374.733298] iwlwifi 0000:00:14.3: Microcode SW error detected. Restarting 0x0.
[  374.733372] iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
[  374.733374] iwlwifi 0000:00:14.3: Status: 0x00000100, count: 6
[  374.733375] iwlwifi 0000:00:14.3: Loaded firmware version: 38.755cfdd8.0
[  374.733377] iwlwifi 0000:00:14.3: 0x00000071 | ADVANCED_SYSASSERT         
[  374.733378] iwlwifi 0000:00:14.3: 0x0080A210 | trm_hw_status0
[  374.733380] iwlwifi 0000:00:14.3: 0x00000000 | trm_hw_status1
[  374.733381] iwlwifi 0000:00:14.3: 0x00454EAA | branchlink2
[  374.733382] iwlwifi 0000:00:14.3: 0x0045E8C2 | interruptlink1
[  374.733383] iwlwifi 0000:00:14.3: 0x0045E8C2 | interruptlink2
[  374.733384] iwlwifi 0000:00:14.3: 0x00000000 | data1
[  374.733385] iwlwifi 0000:00:14.3: 0x00001000 | data2
[  374.733386] iwlwifi 0000:00:14.3: 0xF0000008 | data3
[  374.733387] iwlwifi 0000:00:14.3: 0xFFF4F839 | beacon time
[  374.733388] iwlwifi 0000:00:14.3: 0x104CA603 | tsf low
[  374.733389] iwlwifi 0000:00:14.3: 0x000001E9 | tsf hi
[  374.733390] iwlwifi 0000:00:14.3: 0x00000000 | time gp1
[  374.733391] iwlwifi 0000:00:14.3: 0x003CEEE8 | time gp2
[  374.733393] iwlwifi 0000:00:14.3: 0x00000001 | uCode revision type
[  374.733394] iwlwifi 0000:00:14.3: 0x00000026 | uCode version major
[  374.733395] iwlwifi 0000:00:14.3: 0x755CFDD8 | uCode version minor
[  374.733396] iwlwifi 0000:00:14.3: 0x00000312 | hw version
[  374.733397] iwlwifi 0000:00:14.3: 0x18C89008 | board version
[  374.733398] iwlwifi 0000:00:14.3: 0x0061019C | hcmd
[  374.733399] iwlwifi 0000:00:14.3: 0x24022000 | isr0
[  374.733400] iwlwifi 0000:00:14.3: 0x01800000 | isr1
[  374.733401] iwlwifi 0000:00:14.3: 0x08001802 | isr2
[  374.733402] iwlwifi 0000:00:14.3: 0x00417CC0 | isr3
[  374.733403] iwlwifi 0000:00:14.3: 0x00000000 | isr4
[  374.733404] iwlwifi 0000:00:14.3: 0x0061019C | last cmd Id
[  374.733405] iwlwifi 0000:00:14.3: 0x00000000 | wait_event
[  374.733406] iwlwifi 0000:00:14.3: 0x00000080 | l2p_control
[  374.733407] iwlwifi 0000:00:14.3: 0x00010034 | l2p_duration
[  374.733408] iwlwifi 0000:00:14.3: 0x0000003F | l2p_mhvalid
[  374.733410] iwlwifi 0000:00:14.3: 0x000000CE | l2p_addr_match
[  374.733411] iwlwifi 0000:00:14.3: 0x0000000D | lmpm_pmg_sel
[  374.733412] iwlwifi 0000:00:14.3: 0x08081115 | timestamp
[  374.733413] iwlwifi 0000:00:14.3: 0x0034D800 | flow_handler
[  374.733447] iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
[  374.733448] iwlwifi 0000:00:14.3: Status: 0x00000100, count: 7
[  374.733449] iwlwifi 0000:00:14.3: 0x00101208 | ADVANCED_SYSASSERT
[  374.733450] iwlwifi 0000:00:14.3: 0x00000000 | umac branchlink1
[  374.733452] iwlwifi 0000:00:14.3: 0xC0087C88 | umac branchlink2
[  374.733453] iwlwifi 0000:00:14.3: 0xC008462C | umac interruptlink1
[  374.733454] iwlwifi 0000:00:14.3: 0x00000000 | umac interruptlink2
[  374.733455] iwlwifi 0000:00:14.3: 0x00000001 | umac data1
[  374.733456] iwlwifi 0000:00:14.3: 0x000003FF | umac data2
[  374.733457] iwlwifi 0000:00:14.3: 0xDEADBEEF | umac data3
[  374.733458] iwlwifi 0000:00:14.3: 0x00000026 | umac major
[  374.733459] iwlwifi 0000:00:14.3: 0x755CFDD8 | umac minor
[  374.733460] iwlwifi 0000:00:14.3: 0xC08875AC | frame pointer
[  374.733461] iwlwifi 0000:00:14.3: 0xC08875AC | stack pointer
[  374.733462] iwlwifi 0000:00:14.3: 0x0061019C | last host cmd
[  374.733463] iwlwifi 0000:00:14.3: 0x00000000 | isr status reg
[  374.733466] ieee80211 phy2: Hardware restart was requested
[  375.183415] iwlwifi 0000:00:14.3: BIOS contains WGDS but no WRDS


First I tried updating the firmware driver for iwlwifi from the sid repository as I thought this would help. But sadly it didn't...

According to this post I should try out some module options and this is what helped me:

$ cat /etc/modprobe.d/iwlwifi.conf
options iwlwifi 11n_disable=1

According to inxi my card is this:

Network:   Device-1: Intel Cannon Point-LP CNVi [Wireless-AC] driver: iwlwifi v: kernel port: 5000 bus ID: 00:14.3
           chip ID: 8086:9df0
           IF: wlp0s20f3 state: up mac: <filter>

Maybe this also means that 802.11n does not work anymore but this is ok for me as I don't use WLAN for bulk data transfer.


Saturday, February 23, 2019

Fritz!Box Interne Anrufe mit Pulswahlverfahren

Durch Zufall habe ich herausgefunden, dass es mit der Fritz!Box und einem Wählscheibentelefon doch möglich interne Anrufe ohne das Abschaltung der "spontanten Amtsholung" zu deaktivieren.
Nimmt man den Hörer ab und hört den Ton des Amts und drückt dann kurz(!) auf den Auflegemechanismus sollte man danach nicht mehr das Amt hören, sondern stattdessen 3 Piep-Töne gefolgt von einer Pause.
Dies ist das Signal der Fritz!Box, dass interne Anrufe ohne ** nun möglich sind.
Möchte man wieder das Amt anrufen hält man den Auflegemechanismus einfach länger gedrückt.


Also Hut ab für die Ingenieure bei AVM. Nicht nur, dass das Pulswahlverfahren noch unterstützt wird. Nein, selbst an so etwas wurde gedacht.
Wahrscheinlich sitzt da auch noch ein Liebhaber von alten Telefonen. Anders kann ich mir das nicht vorstellen :-)

Fritz!Box Internal Call with Pulse Dial

After some experimenting I've found out that it seems that the Fritz!Box has a non standard way of doing internal calls using pulse dial.
After picking up the phone and hearing the signal that your phone is ready for dialing you just have to do a manual click on the switch-hook a very short time.
Now the result should be 3 beeps, then a pause and then 3 beeps again.
The Fritz!Box uses this to give the indication that internal dialing is ready.
Now the dial without **.

Fritz!Box 6490 Cable Pulse Dialing / Pulswahlverfahren

I wasn't able to find lots of information about the support of pulse dialing on the Fritz!Box 6490 Cable and just have experimented a little.
I currently use FRITZ!OS: 07.01 and I can confirm that an old telephone with rotary dial is working just fine.

Now on german....

Ich wollte mir gerne ein altes Post-Telefon mit Wählscheibe zulegen. In der Anleitung der Fritz!Box verliert AVM leider kein Wort darüber, ob das Pulswahlverfahren unterstützt wird. Ich konnte jedoch gerade experimentell ermitteln, dass es tatsächlich noch funktioniert.
Interne Anrufe sind allerdings problematisch, da diese normalerweise mit ** beginnen.
Man kann jedoch in der Fritz!Box die "Spontane Amtsholung" deaktivieren. Nach abheben des Hörers ist man im internen Modus und kann interne Nummern ohne ** wählen, während für externe Nummern stets eine 0 vorgewählt werden muss.
Ist die Frage was man möchte.... Mir ist leider keine Methode bekannt, wie man Stern und Raute-Taste per Pulswahl überträgt.