I have happily used the Windows command prompt for years. As a matter of habit, I always change the font to Consolas 14pt and background colour to something a little less harsh than #000000. Usually a muted dark blue or green. When doing so, I’ve simply changed any one of the colour swatches to my desired colour and assign it to the “Screen Background” radio button. This seems to be how the dialog was designed, and it works fine when using standard windows command prompt. However, some recent tinkering with Node.Js made it all go horribly wrong.
As you can see, some of the text from the output of the REPL session has disappearred into the background.
The reason is that my mental model of how the Command Prompt Properties ‘Colours’ tab works, was completely wrong.
According to my mental model, I…
- Pick a colour tile, any tile from the ‘palette’ of available colours
- Modify it using the RGB values
- Assign it the “Screen Background” radio button
- Job done! My everything looks great, until I use node
Through lots of trail and error and looking at how Unix terminals treat colours, I”ve come to realise that not only is my mental model completely wrong, but this dialog box is really really badly designed.
This mental model works fine if you are only every using ‘DOS’ commands. But node was designed for Unix-y environments.
It turns out that windows command prompt has a lot more in common with Linux than I ever thought. It seems that these 16 colour chips correspond with the ANSI colours used by all terminals. They are not simply a colour palette to pick and choose from.
Therefore the correct way to use this dialog appears to be
- Select the first colour chip
- Change it to your background colour
- Make sure it is still assigned to the “Screen Background” radio button
- Ensure the next 7 colours are clearly visible on your background colour
Note that I had to deselect the colour value box before switching to another ‘swatch’ or it would transpose the colour value I was editing onto the new swatch, making things really awkward.
Here is my colour scheme after 10 minutes of playing around. They are shown in the image.
|Colour 'tile'||R,G,B Colours||Base colour|
|1||40, 40, 40||Black – This tile should always be your background colour|
|2||128, 140, 255||Blue|
|3||100, 210, 100||Green|
|4||128, 240, 240||Cyan|
|5||255, 128, 128||Red|
|6||255, 128, 255||Magenta|
|7||255, 255, 128||Yellow|
|8||220, 220, 220||White – this tile should always be your text colour|
I’ve ignored the rest, I’ve yet to see them used.
If nothing else, this post is a reminder to me how this obscure dialog works. I suspect this dialog has been around since Windows 3! It would be a good exercise in UI Design to re-fashion it to better fit how it works.
Using the Arduino IDE, we can bring up the Serial Monitor to send and receive data from the Arduino. However, if you’re using Windows, this completely ties up the COM port so that it cannot be used for anything else. If your Arduino needs to communication with other piece of software on your PC, that software gets exclusive access to that port so you can no longer use the Serial Monitor. Needless to say, it would be very nice to be able to peek at real data being sent between your PC app and the Arduino. A reliable way I’ve found to do this in Window is using com0com and hub4com. Here’s how it works.
Note on driver types (it is relevant!)
On Windows 8.1 64 bit (and true for 64 bit Vista and Win7 as far as I know) you have 3 types of driver…
- Signed driver – This is preferred. It is how you are used to installing and using windows devices, but the developer must pay for it to be signed. Not an option for com0com.
- Unsigned driver – every time you want to use the unsigned virtual COM ports, you must reboot your PC twice to get to the Allow Unsigned Driver option. It is a pain. This is true of the latest com0com 188.8.131.52. If using 64bit Windows, avoid like the plague
- Test Signed Driver – you can run a simple command line instruction to tell Windows to allow Test-Signed drivers. The setting persists between reboot, so it is convenient. For com0com, this is true for the signed version of 184.108.40.206
Use version 220.127.116.11 because it is signed. When installing, I unchecked the option to add a default pair of COM ports. I preferred a clean start Run the command: bcdedit -set TESTSIGNING ON Once com0com is installed, go and get hub4com, unzip, rename the readme file and copy the whole lot into your com0com folder.
I have an Arduino on COM3, and some PC Software which talks to it, called “PC Lap Counter” (PCLC) – it’s a race management solution for slotcar racing. PCLC sends race and lap info to the Arduino over the serial connection, but I want to be able to look in on this info as it is happening.
Step 1: Setup the Virtual COM port Pairs
Step 2: Join the COM port pairs together with hub4com’s Routes
hub4com –baud=9600 –octs=off –ox=on –route=0,2:All –no-default-fc-route=0,1:All \\.\CNCB0 \\.\CNCB1 \\.\COM3
Step 3: Snoop away
Using Putty, create a new ‘Serial’ connection. In the above example, it is connected to COM6 at 9600baud
I’ve always had an interest in making stuff which interfaces with the world, but in the days before microcontrollers, and without a solid electronics background, making stuff was hard. Much too hard. Flashing an LED with a 555 timer is reasonably straightforward- but anything more and you need a LOT of breadboard space, and a lot more time than I could spare.
Then along came the microcontroller. I can’t remember whether I discovered PIC or AVR first, but whenever a new development board was being given away for free or nearly free, I’d be on it. Writing little test programs wasn’t overly difficult. Setting up the development environment however, was. Often, between long droughts of development, my PC would have been rebuilt, and I’d lost all that setup time and effort. As far as the programming went, I have always enjoyed low level coding (starting with hand written Z80 machine code on a Sinclair ZX81). But enjoyment wasn’t the only goal – a finished project matters. And hour upon hour could be spent at too a low a level to feel like progress was being made.
I heard about Arduino, discovered it was AVR based and had a bootloader – which didn’t seems a compelling reason to go with it, since AVRISP programming worked fine. The boards were also far too big, and too expensive compared to the $1 (£1 to me) chips I was used to buying. I was perhaps also swayed by a slight preference towards PICs over AVRs. The Arduino marketing didn’t help me either. I read it as “Helping whimsical arty types create pointless trinkets with overpriced, overspecified boards so they don’t have to learn the hard way”. I liked the hard way. So I wrote Arduino off as a toy.
How wrong I was.
I recently resurrected my childhood love of slot car racing (Scalextric) by building up a reasonable collection of Scalextric Digital track and cars. I explored the PC based Race management Systems which add a whole new dimension. My ‘maker’ mentality was reawakened at the thought of interfacing with all this digital information flying round the track and doing useful things with it, like a leader board or F1 style start lights (my current project combines these into an ‘onmi gantry’ – more later). Each of the three PC based Race Management applications supported Arduino in one way or the other. So I put aside old prejudices and ordered a couple of cheap, Chinese clones of the Arduino Pro Mini and FTDI programmer. No bigger than a DIL chip, the Pro Mini appealed to my barebones mentality. After a couple of days reading around the subject, waiting for the slow boat from China to arrive, I bought an Uno. The price was more reasonable than I’d remembered – and all the tutorials referred to them, so I decided, for once, to make things as easy as humanly possible so I could concentrate on getting my project finished. The fact that the Uno can be used to burn the bootloader onto bare Atmel chip was another compelling reason to have an Uno.
I’m now a week into Arduino programming, and I can say I’ve done more in a week than I would have done in months with a bare AVR/PIC. Having the bootloader does make a big difference. When you can’t get a line of code to work… change – upload – test – repeat. Valuable seconds saved dozens of times in a programming session add up to a more pleasurable experience. The fact that I can go to a brand new PC, download the IDE, load up my files from Dropbox and carry on coding from where I left off is also useful. But the real appeal of Arduino is the libraries and other support material. The various hardware shields don’t interest me too much, but the libraries developed to support them are amazing. To think, I used to to have to read chip datasheets to write code. Now I download the library and I’m good to go. LCD screens, LED matrices, NeoPixels, Serial communication, I2C sensors – all have superb libraries which mean that getting a project finished is now a real possibility.
Finally, if anyone thinks, as I did, that cheap ARM cored boards spell the death of the 8 bit microcontroller – they are wrong. There are many projects where even an 8MHz processor is technically overkill. My next project is adding realistic looking running lights to an RC Helicopter. It seems ridiculous that such processing power is being used for such a trivial task. But doing it from discreet components would be a huge undertaking without an Electrical Engineering background. The finished project would be so big and heavy that the heli wouldn’t be able to lift off! Being able to adjust the timing of the flashing lights with a line of code is awesome compared to swapping out resistors and capacitors. An Arduino Pro Mini does the job nicely for a couple of bucks, and grams. You wouldn’t want to use the size and expense of a Raspberry Pi or BeagleBone for those kind of tasks!
So, in case you haven’t figured it out, I’m a bit pleased with the Arduino. Rather than feeling like I may have missed the boat, I believe it’s a good time to start out. The platform is mature, the community solid, the glitches ironed out and libraries already written. So if there are any hardware tinkerers out there who, like me, are stubbornly refusing to take a look at Arduino – Jump on the bandwagon, the ride is surprisingly smooth.
I always preferred VirtualBox’s simplicity over the Enterprise class complexity of Windows 8 Hyper-V.
However, in order to get a working Windows Phone 8 Emulator working, you need to use Hyper-V.
Unfortunately when trying to do this, I got an error saying that the virtual switch could not be created. I tried some fixes from StackOverflow and ServerFault, but they didn’t work. I couldn’t create nay kind of virtual switch in Hyper-V. A common theme from my searching was that VirtualBox was involved.
Uninstalling VirtualBox manually didn’t help.
Looking in the registry, I noticed hundreds of network adapters with a VirtualBox driver (just search the registry for ‘vbox’)
I couldn’t delete these keys even with Admin privileges
Apparently I needed to run Regedit as ‘System’
THe easiest way to do this was using SysInternals Psexec
C:\Windows\System32\> psexec /i /s regedit
/i means ‘interactive’, or allow the program to display a UI
/s means run the program as the ‘system’ user
Because there were so many to delete, it was easier to export the parent key, edit in Notepad, then save as a .reg file and re-import.
After doing this, removing all references to ‘vbox’ and ‘virtualbox’ from the registry, deleting other invisible network adapters from the registry, running cccleaner, rebooting, removing Hyper-V from Windows, rebooting again, Adding Hyper-V to windows… I finally got my emulator to work.
Lesson: Don’t ever install VirtualBox, stick to Hyper-V (as long as you meet Microsoft’s bizarrely restrictive processor requirements of course)
This continues from my last post, and is mostly a reminder to myself!
My .vimrc file, created for VIM on the RaspberryPi, is also usable on gVim in Windows. It’s the same 2 steps, fetch using Git, and make a symlink (yes you can do that on Windows too)
Open an elevated command prompt (run as administrator)
cd \users\greg git clone https://github.com/GregWoods/.vim.git vimfiles mklink _vimrc vimfiles\.vimrc
Older versions of Windows (such as Windows Server 2003) so not have the mklink command.
Also needed to add an environment variable $HOME
In the case of Windows Server 2003, I set up a user environment variable in System Properties -> Advanced -> Environment Variables -> User Variables
Variable: $HOME Value: %USERPROFILE%
Requires log off / login
Then create the link (it’s a hardlink rather than the softlink which mklink creates. For explanation, see overview-to-understanding-hard-links-junction-points-and-symbolic-links-in-windows )
fsutil hardlinks create _vimrc vimfiles\.vimrc