Adding an RGB SCART connector to a Commodore 1901 monitor

So, this post is going to be a departure from most of the previous content on this blog. This may or may not be indicative of future posts.

A couple of months ago, I bought a cheap, used Commodore 1901 monitor[1] from Tradera. The Commodore 1901 has digital RGBi input using D-SUB 9 connector, as well as separate Luminance and Chrominance inputs via RCA jacks (which is the same signal as S-Video, just different connectors). I thought this would be a good monitor for my old Bondwell Model 8 computer, which only has CGA output (and probably deserves a post of its own). It would probably also work with my Commodore 64. The Commodore 1901 also has a built-in speaker, that connects with yet another RCA plug, so I wouldn’t even need a separate speaker.

When I connected my Bondwell to the monitor, it was indeed glorious, as evident in the image below. What is harder to see is that the colours where a bit off, there was a bit of a yellow tint that kind of came and went.

I managed to find the service manual for the Commodore 1901 monitor, and found that there were a couple of potentiometers that could be adjusted if the colour was off. So I opened the monitor and adjusted the potentiometers which at least made the colour a little bit better. Unfortunately, I also noticed that the PCB had a small crack, which caused some bad connections, and was probably the cause of the colour problem. More about this later.

But what I also found, to my great surprise, was a number of solder points that looked like they could fit a SCART connector, and a matching hole in the metal backplate. What on earth could this be for? Maybe this monitor came in a different version[2], with a SCART connector? But if so, what kind of signals was used[3]? And did this version actually use those signals? Would it be possible to get analog RGB input by adding a SCART connector?

A bit of research indicated that yes, this might indeed be possible. I found a thread on amibay.com and blog post by a Danish guy (unfortunately missing all images[4]) that discussed this. The problem seemed to be that the solder points for the SCART connector on the PCD are oriented backwards, so that a standard 90-degree connector won’t fit. So the usual solution seemed to have been to solder wires between the PCB and the SCART plug. However, I managed to find an angled SCART connector on eBay that seemed to be oriented the other way around. It sure looked like it would fit!

So, the first thing to do was to remove the solder blocking the holes. Time to heat up my solder sucker!

After this, it was simply a matter of fitting the SCART connector and soldering it in place. Or rather, it would have if the darn plug would have fitted through the hole in the metal frame!! When I had fitted the legs through the holes in the PCB, it was completely impossible to get the plug through the hole. In the end, I hade to bring out a knife and go to town on the poor plug.

Finally, I was able to fit the SCART connector through the hole, and solder it in place.

And now, the moment of truth. Would this work? I have an Amiga 600 with a SCART cable that carries not only analog RGB video, but also sound. So maybe I would get sound through the built-in speaker as well? Time to connect a cable. Would it even fit the mangled SCART connector?

The answer to the last question is yes, it fits. And the answer to rest of the questions are yes, everythings works perfectly! I get a crystal clear image from the amiga, and I get the sound through the speaker! The only thing left to do was to make a hole in the plastic cover as well, which was easy since there was already an indication in the cover where to cut. Here is a picture of the Amiga workbench on the Commodore 1901 monitor:

So hooray, everything is great! Except for the crack in the PCB, remember? Since I had the monitor open, and the soldering iron out, I decided to see if I could fix that as well. But I believe this post is long enough already, so that will have to wait until part 2.


  1. 1.The Commodore 1901 monitor was a PAL-only monitor produced between 1986 and 1988, and was meant to be used together with the Commodore 128. It is not as famous as the 1084 monitor but, as we will see, with the SCART modification it is just as useful!
  2. 2.The monitor was actually manufactured by Thompson. And Thompson did release their own version of it with a SCART connector, the Thompson 450G. Why the Commodore version came without it, I do not know.
  3. 3.The SCART connector actually carries a lot of different signals. It can carry composite video, s-video and RGB, and event YPbPr, as well as stereo sound. Wikipedia has a good article.
  4. 4.While writing this post I checked the blog post again, and now it seems all images are back! This would have made it easier for me when I actually was working on the monitor!

The blog is now even more static than before!

This blog has been rather static lately. In fact, I haven’t written a new post since 2014. I’m sure that has nothing to do with the fact that I became a father for the second time in 2014. Obviously a coincidence.

But now it’s time for the blog to become static in a whole new way! For more than 8 years, this blog has beenrunning on my own blog engine, but now the time has come to leave that behind, and move to the wonderful world of static site generators. I know, I’m a couple of years late to party, but better late than never!

After looking at a lot of alternatives, and sinking way to many hours into making a combination of gulp and metalsmith work the way I wanted it to, I finally decided on using Hexo to generate the site. That worked pretty much out to box, although I still feel I have enough flexibiliy to make it work that way I want. Hexo generates a completely static site, and I just need a lightly configured Nginx server in front of it, mainly to keep some old links alive.

So now the source code for both the posts and the scaffolding for the blog lives on Github, and publishing a new post is a simple matter of writing it in markdown and pushing to Github.

Or, well, it will be once I finish the script that auto publishes the blog. So, any day now.

I also gave the blog a new coat of paint, which was sorely needed. Hopefully this will lower the bar for me to write new posts, which might mean that I will be able to produce more than one every five years. Fingers crossed.

Deploying to remote IIS with MsDeploy

We’ve been using MsDeploy to automate our web site deploys for some time. Our build server (running TeamCity) creates the deploy packages, and a PowerShell script on the production server downloads the packages and deploys them to IIS. Recently, we added a fallback-server in another physical location in case there is a problem with the normal server. Naturally, we want to make sure that all the web sites are up to date on the fallback server as well. And that means we want to make the scripts that deploy the site on the production server also deploy to the fallback server.

Now, MsDeploy has support for deploying to other servers, but as it turns out, it can be a little tricky to get it working. One option is to use a windows user with administrator privileges on the target server, but we didn’t really want to do that. The other option is to use an IIS Manager User. This options require a couple of steps to get the authentication working.

1. Create a new IIS Manager User

The first thing you need to do is to create an IIS Management User. This is done by opening the IIS Manager, clicking on the server node, and then Management - IIS Manager Users. Add a new user, let’s call it “deploy” with the password “password”.

2. Allow the IIS Manager User on the site

The next step is to give the user permissions to deploy on all the sites that are to be deployed this way. Click on the site node and then on IIS Manager Permissions. Under Actions, click on Allow User.

Select IIS Manager, and then click Select to find your user. Unfortunately, you have to repeat this process for each site.

3. Give IIS Management Service permissions on site

A not so obvious step is that you need to make sure that the IIS Management Service has permissions to actually perform the deploy on each site. The easiest way to do this is to right-click on the site in IIS Manager, and select Edit Permissions. Under the Security tab, give Local Service “Full control”.

By default, this IIS Management Service runs as Local Service, but if you have changed that, you’ll have to use that account instead. It might work with only modify permissions, but it didn’t for me.

4. Run msdeploy with the correct parameters

Finally, the trickiest part is getting the parameters to msdeploy right! This is what we ended up using.

> msdeploy.exe -verb=sync -source:package="PACKAGE.zip" -dest:auto,computerName=https://FALLBACKSERVER:8172/msdeploy.axd?site=SITENAME,userName=deploy,password=PASSWORD,authType=basic -setParam:"IIS Web Application Name"="SITENAME" -allowUntrusted=true -skip:Directory="App_Data"

There are some things worth mentioning here. First, you need to use the full url to the server (including msdeploy.axd) with the sitename as a querystring parameter in order to be able to use a IIS Manager User, since they only have permissions on individual sites. Otherwise the authentication will fail. Also, you need to set authType=basic, otherwise it will try to use a Windows user instead.

Applying MSBuild Config Transformations to any config file without using any Visual Studio extensions

As I have mentioned in previous posts, I frequently use a setup where our TeamCity servers creates deploy packages that are semi-automatically deployed to the web servers. A great help in achieving that is Visual Studios Web.config transformations. However, frequently we have the need to transform other config-files as well, either because we’re not in a web project, or because we simple have multiple config files.

I’ve had some success using a Visual Studio plug-in called SlowCheetah. Unfortunately it does not really play well with TeamCity. Sometimes it works, sometimes not. More the latter than the former. So recently I made an effort to solve this without using SlowCheetah, or any other extension. As it turns out, you can. And it’s not even particularly difficult.

First of all, you need to have the Visual Studio Web Application build targets installed on your build server. This can be achieved either by installing an express version of Visual Studio or the Visual Studio Shell Redistributable Package.

Then, create an App.config file in your project. I placed in in a folder called “Config”, to avoid any automatic behaviour from Visual Studio. Then, create your transform files, App.Debug.config, App.Release.config and whatever you need (I usually don’t use those, but rather Test, Prod, Acceptance etc). Now, these will all be placed beside App.config, and not be linked to it as with Web.config transforms. Not to worry, we’ll fix that shortly!

Next, unload your project, and edit the .csproj file. First we’ll fix the linking of the files. This is done simply by adding a DependentUpon element inside each Item. Let’s say you have this:

1
2
<None Include="Config\App.config" />
<None Include="Config\App.Debug.config" />

Simply change it to this:

1
2
3
4
<None Include="Config\App.config" />
<None Include="Config\App.Debug.config">
<DependentUpon>App.config</DependentUpon>
</None>

Now, let’s move on the real trick. In order to make msbuild transform your config file, we need to att a build event. At the end of the file, add

1
2
3
4
5
6
7
<UsingTask TaskName="TransformXml"
AssemblyFile="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.Tasks.dll" />
<Target Name="AfterBuild">
<TransformXml Source="Config\App.config"
Transform="Config\App.$(Configuration).config"
Destination="$(OutputPath)\$(AssemblyName).$(OutputType).config" />
</Target>

You need to make sure that the path in the second import matches the version of your Visual Studio build targets.

In this example, I have a console application, so I want the result of my transformation to end up in the output directory, and be named as AssemblyName.exe.config, e.g. bin\Debug\MyConsoleApplication.exe.config. In a web application where I have other config files, I would use something like

1
2
3
<TransformXml Source="Config\NLog.config"
Transform="Config\NLog.$(Configuration).config"
Destination="NLog.config" />

And if you have more than one config file that you would like transformed, you can of course add several TransformXml-lines. After you’re done, just reload the project, and hopefully everything works. At least it works on my machine!

Finally, I should add that I found another Visual Studio extension that seems to work better than SlowCheetah (at least sometimes) called Configuration Transform and make this entire post unnessecary. On the other hand, this way there is less magic and more control, which I personally like. And if your extension suddenly breaks after an update, it might come handy!

UPDATE 2014-03-20 – I realised that unless your destination file is included in the project, or rather has a suitable Build Action, it will not be included in the deploy package, or deployed at all. Usually the build action should be “Content”. You don’t have to worry about the content of the destination file, though, as it will be replaced on every build. I prefer not to have it checked in to source control, though, since it would be pretty pointless to check in every change to an auto-generated file.

Visual Studio feature - Preview web.config transforms

On my way to continuous delivery, I often use Visual Studios built-in support for Web.config transformations, at least for relatively simple situations. This allows you to automatically create variations of you web.config file for different deployment environments. And with the help of the excellent Visual Studio plug-in SlowCheetah, you can apply this to other config files as well.

This is all great, but I found it a little tricky to verify that my config transformations yielded the expected result, I basically had to create the deploy packages and check inside them. But then I noticed this little gem in Visual Studio:

Yes, there is a preview transform option in the context menu for transform.config-files!

If you right-click on a config transformation file, you get the “Preview transform” option. This was, I think, introduced in Visual Studio 2012. I was just a little slow to notice it. But it’s great! If you select it, you get to see the original config file and the transformed file side by side, with all the changes highlighted.

Click me if you can't read! :-)

All the differences between the files are highlighted on the right, and also in the code window itself. This really makes it very easy to verify that the transforms are correct.

Manipulating history with the HTML5 History API and AngularJS

As I’ve mentioned earlier, I’ve been working quite a lot with AngularJS lately, most recently on a search function on a website. Naturally, since this is an ajax application, the search result page never reloads when I perform a search. Never the less, I would like to

  1. Be able to go back and forth between my searches with the standard browser functions
  2. See my new query in the location bar
  3. Reload the page and have the latest query - not the initial one - execute again
  4. Make this invisible to the user, that means no hashbangs - only a nice ?query=likethis.

Fortunately, HTML5 is there for me, with the history api! This is supported in recent versions of Chrome, Firefox and Safari, as well as in Internet Explorer 10. Unfortunately, no support in IE9 or earlier. Anyway, in AngularJS, we don’t want to access the history object directly, but rather use the $location abstraction.

The first thing we need to to is set AngularJS to use HTML5 mode for $location. This changes the way $location works, from the default hash mode to querystring mode.

1
2
3
4
angular.module('Foobar', [])
.config(['$locationProvider', function($locationProvider) {
$locationProvider.html5Mode(true);
}]);

Note: Setting html5Mode to true seems to cause problems in browsers that doesn’t support it, even though it’s supposed to just ignore it and use the default mode. So it might be a good idea to check for support before turning it on, for example by checking Modernizr.history.

Now, all I have to do to whenever I perform a search is to update the location to reflect the new query.

1
2
3
4
5
6
$scope.search = function() {
//Do magic search stuff

var path = $location.path(); //Path without parameters, e.g. /search (without ?q=test)
$location.url(path + '?q=' + $scope.query);
};

This makes the querystring change when I perform a search, and it also takes care of the reloading of the page. It does not, however make the back and forward button work. Sure, the location changes when you click back, but the query isn’t actually performed again. In order to make this work, you need to do some work when the location changes.

In plain javascript, you would add a listener to the popstate event. But, you know, AngularJS and all that, we wan’t to use the $location abstraction. So instead, we create a [$watch](http://docs.angularjs.org/api/ng.$rootScope.Scope#$watch) that checks for changes in $location.url().

1
2
3
4
5
6
$scope.$watch(function () { return $location.url(); }, function (url) {
if (url) {
$scope.query = $location.search().q
$scope.search();
}
});

And that’s pretty much it! Now you can step back and forth in history with the browser buttons, and have AngularJS perform the search correctly every time!

Using an AngularJS directive to hide the on screen keyboard on submit

Recently, I’ve been working on a responsive web site running AngularJS. In this, we have a search form. As search forms usually works, you enter a query in a text field, and then you click the button to search. Or, more likely, you hit enter. Now, since this is a responsive site, this needs to work on a phone too. This is were it gets a bit more tricky.

A search form

When you click the text field, your on screen keyboard pops up. You enter your query, and click Enter, or Next, or Go or whatever the button is called on your keyboard. This submits the form, but unfortunately, the soft keyboard still lingers. If you had clicked the button instead, your keyboard would have disappeared. Why? Because when you click enter on your on screen keyboard, your text field still has focus!

So in order to rectify this, we need to make sure that the text field loses focus when the enter/go/next-button is clicked. It’s easy to make an object lose focus, you just call blur() on it. The problem is when to call it. What happens when you press the enter key on your on screen keyboard? Well, that depends.

Take this form for example:

1
2
3
4
<form>
<input type="text" name="query" />
<button>OK</button>
</form>

Now, in this case, when I press enter in the text field, two events will fire: the submit event on the form, and the click event on the button. The exact same thing happens when you click the button Why? Because the default behaviour of a button in HTML5 is to submit the form. In order to prevent this, you need to use <button type="button">OK</button> instead.

If you do this, pressing enter in the text field will still submit the form, but not click the button. And vice versa, clicking the button will fire the click event on the button, but not the submit event on the form!

Since this is an AngularJS application, the easiest way is to specify a submit action for the form, and then make sure the form submits whether you click the button or press enter. Like this:

1
2
3
4
<form ng-submit="foo()">
<input type="text" ng-model="query" name="query" />
<button type="submit">OK</button>
</form>

A nice and pretty form, but this still leaves me with the original problem, who do I make sure that the text field loses focus whenever I click enter/ok/go on my soft keyboard, or to put it in more technical terms, how do I run blur() on the text field whenever the submit event fires? This is still an AngularJS app, so the answer is of course – a directive! I came up with this:

1
2
3
4
5
6
7
8
9
10
11
angular.module('Foobar', [])
.directive('handlePhoneSubmit', function () {
return function (scope, element, attr) {
var textFields = $(element).children('input[type=text]');

$(element).submit(function() {
console.log('form was submitted');
textFields.blur();
});
};
});

Then, you just apply this to the form: <form handle-phone-submit>, and like magic, your soft keyboard disappears whether you press enter/ok/go or the button. There’s a jsfiddle with a working example.

I allowed myself to use jQuery within the directive, but naturally you could do this with just the jQuery lite implementation that always exist in Angular. In that case, the directive function could look something like this:

1
2
3
4
5
6
7
8
return function (scope, element, attr) {
var textFields = element.find('input');

element.bind('submit', function() {
console.log('form was submitted');
textFields[0].blur();
});
};

There are some limitations there, but it seems to work ok.

Creating an SSH tunnel on a Mac

A while ago I wrote a post about how to set up an SSH tunnel to access remote desktop. Since then I’ve started using a Macbook Air, and naturally I want to do the same.

As it turns out, however, I’m terrible at remembering the syntax. So here it is, for my own future reference:

I want to access Remote Desktop on RDPSERVER, port 3389, and map it to port 3391 on my local machine. To to this I will connect to SSHSERVER and tunnel through that.

> ssh -l username -L localhost:3391:RDPSERVER:3389 SSHSERVER

Easy, peasy. Now I will never forget it again!

Updated Anti-XSRF Validation for ASP.NET MVC 4 RC

In our project, we’ve been using Phil Haack’s method for preventing cross-site request forgeries for JSON posts by inserting the request verification token as a header in the request, and then using a custom ValidateJsonAntiForgeryToken attribute to validate it. And it’s been working just fine.

However, with the recent release of ASP.NET 4 MVC RC, it didn’t work anymore. To my initial dismay, it didn’t even compile anymore. Turns out that the method, AntiForgery.Validate(HttpContextBase httpContext, string salt) , that hade been used to validate the tokens is now obsolete.

However, this turned out to be a good thing, as the MVC developers have made it easier to configure the anti-XSRF validation. You can now provide the tokens directly to the Validate method, and thus there is no need to create a wrapper for the HttpContext and the HttpRequest anymore.

Instead, you can just call the validate method with the proper tokens directly from your attribute:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[AttributeUsage(AttributeTargets.Method | AttributeTargets.Class,
AllowMultiple = false, Inherited = true)]
public sealed class ValidateJsonAntiForgeryTokenAttribute
: FilterAttribute, IAuthorizationFilter
{
public void OnAuthorization(AuthorizationContext filterContext)
{
if (filterContext == null)
{
throw new ArgumentNullException("filterContext");
}

var httpContext = filterContext.HttpContext;
var cookie = httpContext.Request.Cookies[AntiForgeryConfig.CookieName];
AntiForgery.Validate(cookie != null ? cookie.Value : null,
httpContext.Request.Headers["__RequestVerificationToken"]);
}
}

And, just to make this post complete, in case the original post is removed, this is the javascript required to add the header to the request:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
postJsonWithVerificationToken: function (options) {
var token = $('input[name=""__RequestVerificationToken""]').val();
var headers = {};
headers['__RequestVerificationToken'] = token;

$.ajax({
cache: false,
dataType: 'json',
type: 'POST',
headers: headers,
data: options.jsonData,
contentType: 'application/json; charset=utf-8',
url: options.url,
success: options.onSuccess,
error: options.onError
});
}

Finally, you just use it as you would the standard ValidateAntiForgeryToken attribute, by decorating your action method like this:

1
2
3
4
[HttpPost, ValidateJsonAntiForgeryToken]
public ActionResult DoSomething(Foo foo) {
//Do something
}

And in your form, you just call Html.AntiForgeryToken(), just as you would for a normal form post.

A lot cleaner than the previous haack (although it was very clever)!

Setting up an SSH tunnel to access Remote Desktop using Putty and SSHD on Linux

In Approach, we have servers (ya, rly!). From time to time I need to access them. Usually, I do this by connecting to our VPN. At times, however, that is not possible, like for instance when some overzealous firewall administrator has blocked outgoing PPTP. Then you might have the need for an alternate approach, like using an SSH tunnel (provided that the administrator didn’t block outgoing SSH as well…)

And yes, I am aware that there are plenty of guides how to setup an SSH tunnel with Putty, but I found that they are either 1) overly verbose, 2) not exactly describing my problem or 3) wrong.

The situation

  • I want to access a Windows Server using Remote Desktop
  • There is a Linux server running in the same network section. Mine is running Ubuntu, so all examples will be in Ubuntuish.
  • I have a Windows 7 client machine, with the Putty ssh client

On the Linux server

  1. Make sure that SSH is installed (it probably is, otherwise, how do you access the server?). If not, $ sudo apt-get install ssh.
  2. Edit /etc/ssh/sshd_config.
    Check that it says AllowTcpForwarding yes somewhere. If not, add it.
  3. Reload sshd.

$ sudo /etc/init.d/sshd reload or
$ sudo service ssh reload depending on your Ubuntu version.

On the Windows client

  1. If you don’t have Putty yet, get it.
  2. Configure putty to connect to your Linux server using SSH 2.
  3. Under Connection – SSH – Tunnels, map a local port to remote desktop on your Windows server. Usually, the remote port is 3389. The local port can be anything, except 3389 or 3390, which won’t work*.
    Configuration of SSH Tunnels in putty
  4. Save the session and connect to your linux server. You need to log on, and keep the connection open.
  5. Open a remote desktop session to the source port on localhost.
    Opening a new Remote Desktop connection
  6. Profit.

* Because 3389 is probably already running a RDP server, and 3390 is blocked in Windows 7 for some reason.