IECHost clients updated

Version 2.9 of the IECHost GUI client and version 1.6 of the IECHost CLI Utilities were published within my Software page.

Details of what’s changed in this version are provided within each package, through the changelog.txt file. Additionally, I am managing an issue tracker for the GUI application on Hosted Redmine.

Again, please be advised that a number of features in the recently introduced Tools menu require a firmware update, which can be performed through either client software once the device and bootloader ports are both discovered correctly, as per IECHost manual.

IECHost: new features added to the GUI client

Enjoy!

A good reason to be careful when giving a GTK+ widget focus

While running my IECHost client under Linux I noticed that something was bugging me: If the application was launched and a key pressed or released before the directory listing drawing area had been shown, an assertion failure would be reported on the console:

Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

It turns out that in GLADE, the GUI editor I use, I was asking for the drawing area to initially have focus. As the drawing area widget is in an initially hidden page of the notebook widget, it is not realized yet when the application is launched. This means that as a result of pressing a key, there was an attempt to call the event handler for key presses of a widget that was not initially realized.

Why does GTK+ 2 allow giving focus to a widget that is not yet realized is arguable, but I’d rather not get into that sort of argument. In fact, it turns out that I didn’t need to initially give focus to the drawing area at all, as it only makes sense to do so when:

• the disk directory is retrieved
• the user clicks on the drawing area itself

When a widget has focus it receives events associated to key presses, scrolling, etc. In my case these events are necessary to navigate the directory listing, and a user might want to wait for one to be available before navigating it 🙂

I am writing this post in the hope that it might help somebody else to address this runtime issue.

Happy days!

IECHost GUI client: issue tracker

In order to coordinate development efforts on the IECHost GUI client, following Tomse’s suggestion, I’ve set up a project on Hosted Redmine. My choice fell on the hosted version, as opposite to running my own instance, due to a number of things, but in particular I don’t want to have to think about spammers and co.

Although things might change in future, I reckon this is one way to get started. Feel free to pop over, create an account, and request collaboration.
Security tip: please make sure you are using HTTPS and do not register using a password that you’re already using elsewhere.

Update ahead of the Easter break

The feedback on the IECHost GUI client for mass-dumping purposes has been patchy: I got bits and pieces in terms of feature requests but haven’t managed, among other things, to get hold of Graham (the author of WarpCopy64).
Therefore, I decided to merge-in a different development branch of my code and publish an updated version of the IECHost GUI client ahead of Easter, for generic usage.

Users will need to update their firmware, using the Firmware menu, in order to be able to benefit from a few of the new features as per screenshot below:

IECHost: new features added to the GUI client

In release 2.8 the whole Tools menu has been added, which is a sort of feature bucket where I am currently putting all features that would otherwise crowd the GUI itself. I am also providing easy shortcuts (Ctrl+Key combination), for quicker access.

Binaries for Windows, Linux, and RPi are available at the following links:

• • IECHost multi-threaded GUI client 2.8 for Linux 64-bit (Ubuntu/Debian)
  • IECHost multi-threaded GUI client 2.8 for Raspberry Pi 3 Model B (Raspbian)
  • GTK+ 2.24.31 runtime installer for Windows (all versions)
  • IECHost multi-threaded GUI client 2.8 for Windows XP (Windows XP – requires the above GTK+ runtime)
  • IECHost multi-threaded GUI client 2.8 for Windows 7 or later (Windows 7 or later – requires the above GTK+ runtime)

For the time being I shall not update release links on my main website as this release requires a firmware update that might be tricky for those who don’t RTFM 🙂
I will officially publish the update on my main website once I manage to also build the “iechost-utils” package. The latter can also use the new features and is distributed along with an updated firmware, the same as per release 2.8 of the GUI client.

Stay tuned and Happy Easter all!

IECHost: upcoming features

Having expanded the IECHost firmware to return the status message from a drive, in a format suitable for client applications, and having added the option to iechost-utils to use such feature, today I also added the querying functionality in IECHost’s GUI client.

For the time being the status can be queried via a tiny button in the bottom right of the GUI, but I plan to re-organize a few controls and I guess I might move it then.

In the below screenshot I tried to query the status message from my 1541-II at boot time, getting the usual “73,CBM DOS V2.6 1541,00,00” string, as shown in the windows’s status bar:

IECHost: querying the status message from a disk drive

I’ve also updated the IECHost firmware to allow users to select a number of parameters when fast-formatting a disk:

• disk name and id
• number of tracks (e.g. 40 rather than 35)

I will have to think of whether I want to allow users set additional parameters, as allowed by Format II‘s drive code (namely the tailgap). Once I am settled with that, I shall also add a dialog to build disk name and id, similarly to what I did for D64 Browser a while ago:

D64 Browser: Filename input dialog

Stay tuned!

IECHost errors and WinVICE 3.1

It appears that WinVICE 3.1 has good support for DOS errors on disks. In fact, it can write the error information to a D64, while true drive emulation is enabled, even at the time an error is actually created: this is quite remarkable if you ask me! Therefore I shall be using WinVICE 3.1 for testing the process of dumping to D64 while including the error information with a disk image.

For testing purposes I had created DOS error 23 on tracks 1 and 3 in VICE:

D64 Editor: showing the error information added to a D64 by VICE

The thing I was able to confirm is that the error information consists of FDC codes and not IP codes!

Here’s the mapping according to D64 Editor:

D64 Editor: mapping of FDC codes to IP codes

As the above screenshot shows, errors can only be detected by performing a R/W/SEEK operation. What this means for me is that to produce a D64 with error information I would have to go for a slow disk dumping process, querying each sector in turn and consulting the error channel after each read attempt.
Upon detecting certain errors when invoking the standard block read command, U1, a head bump would occur as well, which not only slows the process down dramatically, but also puts some stress on the drive’s mechanics!

I’d have to write some custom drive code to make the process faster and less stressful.
If you know of an existing implementation that meets such requirements, just let me know!

IECHost: two commands exposed in iechost-utils

Version 1.6 of my iechost-utils package exposes two additional commands:

• one for resetting the disk drive, and
• another for querying the status string through the command channel.

Running them back to back I get:

>iechost-utils.exe -r COM9
IECHost utilities, rel 1.6 - (C) 2018 Luigi Di Fraia
Communicate with an IECHost device to perform common tasks

Resetting... succeeded in 0.01 seconds.

>iechost-utils.exe -s COM9
IECHost utilities, rel 1.6 - (C) 2018 Luigi Di Fraia
Communicate with an IECHost device to perform common tasks

Fetching drive status... succeeded in 0.08 seconds.

73,CBM DOS V2.6 1541,00,00

Stay tuned for updated packages!