Category Archives: Coding and Software

Turn a BASIC Program into a Cartridge for the C64

Posted on by
1

The other day, I was researching the Jason-Ranheim Capture cartridges and browsing the DDI Projects on that topic. The capture cartridge is a freezer module for the C64 that allows the internal state of the machine to be saved or to be burned directly into an EPROM. These ROMs can then be installed in a cartridge that will run the frozen state. An interesting concept that I’ll probably explore closer at a later date.

In one of the archives I downloaded I came across a PDF document containing scans of a text, also by Jason-Ranheim Company, that caught my eye. The document is titled “Auto-Start BASIC Programs” and describes a simple process to convert a Commodore BASIC program into an auto-starting cartridge for the C64 or the VIC20. I got curious and decided to try this — but first I wanted to explore how it works in detail.

Continue reading →

Converting .mysql_history Files to New Format

Posted on by
Reply

When I upgraded one of my servers from Fedora 20 to 21 recently, I noticed that – among a few other issues – the command line history of my mysql client was missing. Too me, this is valuable information and documentation, even. So I investigated and found, that the file format for the .mysql_history seemed to have changed and the client had just discarded my old data. The new file now contains various characters (including ‘space’) in octal notation and it starts with a special marker line:

_HiStOrY_V2_

I assume that this change might have been caused by either MariaDB or Fedora itself having switched from readline to using libedit.

#!/usr/bin/env php
<?php
$oldData = file($argv[1]);
foreach ($oldData as $line) {
    readline_add_history($line);
}
readline_write_history($argv[2]);

The PHP package that comes with Fedora 21 seems to be using the same library. So, after restoring my old .mysql_history from backup it was easily converted to the new format using but a few lines of PHP code:

./convert_history.php ~/.mysql_history.bkp ~/.mysql_history

 

 

Android Development on Windows using an Intellibook Tablet

Posted on by
3

Earlier this year I acquired a 7 inch Intellibook Android tablet by ordering a trial subscription for a magazine on Java programming. When I tried to use it for Android development on Windows today, I couldn’t find a suitable USB driver. It took me a while to find out that the driver released by Google for their own devices would actually work.

Intellibook Tablet

Here is how to install it for the Intellibook tablet:

  1. Download the Google USB driver package for Windows.
  2. When finished, the driver is located in <android-sdk>\extras\google\usb_driver\, and you need to modify the file android_winusb.inf contained within. Add the following lines twice, once in each section [Google.NTx86] and [Google.NTamd64]: 
    ;Intellibook
%SingleAdbInterface%        = USB_Install, USB\VID_2207&PID_0010
%CompositeAdbInterface%     = USB_Install, USB\VID_2207&PID_0010&MI_01
  3. Connect the tablet to the PC and install the modified driver.device_manager
  4. Create the file %USERPROFILE%\.android\adb_usb.ini containing the vendor code 0x2207 or add it if the file exists: 
    echo 0x2207 >> "%USERPROFILE%\.android\adb_usb.ini"
  5. Remember to enable developer options and USB debugging on the device.

This worked for me, but of course there is no guarantee since Google does not support this device. On the other hand, it might also work for other “no-name” devices lacking suitable drivers. To find the hardware id string needed to modify the driver’s *.inf file connect the device to the PC, locate it in the Device Manager, and right-click to open properties -> details -> hardware-id. Try at your own risk…

OpenWRT and Scripting Languages, Part 1

Posted on by
1

The RGB wall light project is currently on hold due to a massive lack of time. Still, I’m taking little steps of preparation for the second phase of the project, the software intended to control the RGB matrix. I could use the gcc cross compiler for the job, but using a scripting language to develop directly on the device promises to be far more comfortable. I’d like to narrow this down to languages readily available as packages for OpenWRT which leaves me with Erlang, Lua, Ruby, Perl, and Python. Since I feel like trying something new I’m going to rule out Perl for now.

Make Room

The installation of the bleeding edge OpenWRT version called “Attitude Adjustment” on the TL-MR3220 leaves about 1MB of space for additional packages to be installed – which isn’t even close to being enough for this purpose. So, the first step is to extend that space and the currently recommended way to do this is to move the overlay mount to an external USB device: Continue reading →

Fixed Weave Sync Again

Posted on by
Reply

After I upgraded my Weave server to API version 1.0, syncing my bookmarks between browsers no longer worked alright. At first, I didn’t really notice because Weave Sync still seemed to work but just not — well, just not always. Fuzzy symptoms that kept me from investigating for some time.

Then, almost by accident, I noticed Jason Frisvold’s post on the mozilla-labs-weave group. He describes exactly the same problems I was having and points to the solution: when I upgraded the user API database table I missed the necessary changes to the WBO table. Most notably, the column containing the modification time of an object has been changed from

`modified` decimal(12,2) DEFAULT NULL

to

`modified` bigint(20) DEFAULT NULL

This resulted in all my bookmark records having a modification time of 9999999999.99 which explains why the syncing would no longer work as expected.

Mozilla Weave Server Upgrade to API Version 1.0

Posted on by
1

For about half a year I have been using the Mozilla Weave Sync plug-in to synchronize the Firefox data from various systems with my own Weave server. Updating the plug-in during this time has been no problem at all, except getting used to the repeated complete UI overhauls.

Keeping the server component updated, or even knowing when such an updated was required by a new version of the plug-in was not quite as easy.  After my recent upgrade to the first beta release 1.0b1 of the plug-in, the sync process failed again, indicating that an upgrade of the server might be needed.

On the server side, the directory and URL layout has been changed, making it somewhat clearer now.  I gathered the necessary changes from the Mozilla Labs wiki, from the pages describing the setup of the sync and user service.

The sync would still not work at this point, but now I could see why in the server’s error log:  for the MySQL table users, the column username no longer was the primary key. Instead, the developers added a synthetic primary key id to the table. Simply dropping the old key and creating the new one helped to get my weave server up and running again:

ALTER TABLE users DROP PRIMARY KEY;
ALTER TABLE users ADD COLUMN id int(11) NOT NULL PRIMARY KEY auto_increment;