GTK+ installer for version 2.24.31 testing

I am testing the installer I made for GTK+ 2.24.31 with excellent results so far ūüôā

Here’s the IECHost GUI Client running on Windows 10 64-bit: even¬†the firmware update option is working as expected!

IECHost GUI client under Windows 10 64-bit by Luigi Di Fraia

IECHost GUI client under Windows 10 64-bit

Posted in Technical | Tagged , , | Leave a comment

GTK+ version 2 and 3 on Windows: updates

In the afternoon today I’ve been having another look at GTK+ 3 and I have to admit that albeit the look and feel of the resulting applications is quite nice on Windows 10 (yes, haven’t downgraded to Windows 7 just yet), the interface editor, GLADE 3.x, is still as unstable as I remembered it from trying it a few years back:

IECHost client GUI created with GLADE 3 by Luigi Di Fraia

IECHost client GUI created with GLADE 3

I managed to see GLADE segfault a few times and creating a project file that would always result in subsequent segfaults. Eventually I had to manually fix the project in a text editor (it’s just XML) in order to get it back to a working state.
That’s not a good enough experience so I think I will only make marginal use of it in the future, if any.

Regarding GTK+ 2, however, I made quite some¬†progress with the MinGW SDK and runtime testing under Windows:¬†During¬†my¬†regression testing with the IECHost client compiled against GTK+ version 2.24.31 I haven’t been able to reproduce the 2 major bugs that have so far¬†frustrated me the most. This means that there are good chances I will¬†be providing a¬†runtime installer for GTK 2.24.31 that will be usable for all of my GTK+ applications: TAPClean FE, The Tast Ninja Construction Kit and Integrator 2012, the GUI clients for DC2N4-LC, C2NEmu, and IECHost, to name a few. This means I will not have to provide binary packages for my GTK+ applications that include a working, and possibly application specific, runtime.

Essentially, I’m over the moon today¬†ūüôā

Posted in Technical | Tagged , , | Leave a comment

IECHost GUI client update

This morning I managed to spend a few minutes updating the GUI client of IECHost in order to allow a simple firmware update experience for end-users.

IECHost GUI client with a new firmware update option by Luigi Di Fraia

IECHost GUI client with a new firmware update option

I¬†might have to look¬†further at the error checking side of things as¬†I guess antiviruses might break things¬†due to the fact the update process involves invoking an external application, avrdude. For now I tested it an it’s working fine with my setup ūüôā

Posted in Retrocomputing, Technical | Tagged , , , , , , , , | Leave a comment

IECHost prototype #2

With Easter behind I decided to spend some time building a second IECHost prototype so that I can get some help with the beta testing of the device and its software.

Here’s what it looks like:

I’ve also added the capability to transfer single files, including the directory listing, over the USB connection and due to the fact the client PC app is not ready yet to receive files I’ve been using RealTerm for testing purposes as its binary capture functionality is quite good ūüôā

RealTerm capturing files contents sent by IECHost by Luigi Di Fraia

RealTerm capturing files contents sent by IECHost

That’s it for now folks!

Posted in Retrocomputing, Technical | Tagged , , , , , , , | Leave a comment

IECHost warp testing: how you can help

After imaging around 70 tool disks with IECHost, I stumbled upon an original disk version of “Liverpool – The Computer Game” by Grandslam. Here’s the game’s title screen:

Liverpool - The Computer Game disk dumped with IECHost by Luigi Di Fraia

Liverpool – The Computer Game disk dumped with IECHost

I guess the disk is not copy-protected at all and albeit it was write-unprotected (suggesting some custom data might have been saved to it) I’d be interested in comparing my D64 with the D64 obtained from a different source of the original disk version.
I’ve only been able to find cracked disk versions or tape versions of the game so if you have access to a D64 of the original disk version, please¬†let me know if you’d want to share it for me to compare the two copies. Thank you!

Posted in Retrocomputing, Technical | Tagged , , , , , , , , | Leave a comment

IECHost questions answered and updates

As I am still getting questions around IECHost, particularly how it is different to ZoomFloppy, I thought to take a moment again to comment on this one point.

First of all, ZoomFloppy is a more mature project: xum1541 (firmware) and opencbm (software) at its core provide a quite complex stack with which advanced users can, for example, nibble protected disks using a parallel cable.

IECHost is one of those projects I really wanted to work at¬†in order to consolidate my knowledge about Commodore disk drives, the serial bus protocol, and the direct access approach. In fact, not only I was fascinated when I read “Inside Commodore DOS” a few years back, but I also find it quite enjoyable to play around with a Commodore disk drive such as the 1541-II: it¬†is really a tiny¬†computer with an on-board drive.
I designed the schematics for IECHost in order to¬†allow the addition of a parallel cable, but I don’t expect I will be working on¬†disk nibbling any time soon, if at all: IECHost is a low-cost¬†interface that is supposed to stay simple.

Coding IECHost from the ground up gave me the opportunity to better appreciate how things work on the IEC bus as my plan was to build a 100% compatible host emulator inspired by the C64-side of the disk access routines.

As example, take the code at¬†$ED11 within the C64’s Kernal. In IECHost’s firmware it was implemented as per below:

static void iec_send_control_code (uint8_t code, uint8_t *st)
{
	DATA_LOW();	/* Release data line */
//	if (code == CTRL_CODE_UNLISTEN) {
//		CLK_LOW();	/* Due to a coding mistake this never happens on a C64 */
//		_delay_us(8);
//	}
	ATN_HIGH();
	iec_send_byte_under_attention(code, st);
}

As you can see, I’ve gone an extra mile to avoid fitting in fixes or code that might change the behaviour of¬†IECHost when compared to a C64: As a result of that, I’ve included bugs that are present in the original code too ūüôā

Despite its somewhat early age, IECHost provides a quite comprehensive interface/API for disk access. If you’re familiar with handling the drive via the LISTEN/TALK paradigm, then it should suffice to say that IECHost implements it fully. BASIC commands, such as LOAD and SAVE, when addressing a serial device, are just friendly wrappers around the above mentioned paradigm and eventually execute LISTEN/TALK operations.
Even at an¬†intermediate disk programming level, direct access commands such as “M-W” and “M-E”, along with their payloads, are sent through the IEC bus using¬†a¬†LISTEN operation.
What I am trying to say here is that once the LISTEN/TALK paradigm is available, along with a physical layer that deals with bus signals, the sky is the limit to what one can do while interfacing a Commodore serial device.

On top of that IECHost provides its own commodity wrappers for “M-W” and “M-E”, which are particularly useful to upload custom code to the drive and execute it.

Until recently the above was the baseline available in IECHost. Then I implemented the “warp” transfer that allows users to make a D64 image of a DOS disk in about 22.5 seconds. Obviously WarpCopy64 is my reference design here and I have to credit Graham’s excellent work which has motivated me during¬†my own implementation on IECHost.

At the moment I am still testing the disk imaging process and have a few items on my TODO list for the PC client software. In particular I want it to be resilient to unexpected scenarios that might arise during usage in the field.
That said, I’ve been able to make D64 images of about 70 utility disks that I acquired a long time ago, without any major issue.

Contents of one of the disks imaged with IECHost by Luigi Di Fraia

Contents of one of the disks imaged with IECHost

There were certainly disks that puzzled me quite a bit though, such as the one that imaged as per below:

IECHost client - disk imaging with errors by Luigi Di Fraia

IECHost client – disk imaging with errors

Although I am satisfied with the code when disks can be imaged without errors, I am still heavily experimenting on what is sensible to do when there are imaging errors, and how to flag them to avoid accidental use/distribution of the relevant D64 files.

IECHost client - disk imaging with errors by Luigi Di Fraia

IECHost client – disk imaging with errors

The above pictures show sectors for which there were GCR decoding errors (in red) or data checksum errors (in yellow).

Future plans include writing D64 images back to formatted disk and ancillary features such as directory listings, file copying, etc.

I shall close this post with a few more screenshots of the GUI client running under 64-bit versions of Windows 10 and Ubuntu 16.04.

IECHost GUI Client under Windows 10 by Luigi Di Fraia

IECHost GUI Client under Windows 10

IECHost GUI Client under Windows 10 by Luigi Di Fraia

IECHost GUI Client under Windows 10

IECHost GUI Client under Ubuntu 16.04 by Luigi Di Fraia

IECHost GUI Client under Ubuntu 16.04

IECHost GUI Client under Ubuntu 16.04 by Luigi Di Fraia

IECHost GUI Client under Ubuntu 16.04

Stay tuned!

Posted in Retrocomputing, Technical | Tagged , , , , , , , , | Leave a comment

IECHost GUI client update

Not much done¬†during the Easter break, but this evening I modified the IECHost GUI client in order to display the¬†number of elapsed seconds for a disk imaging process at warp speed. Here’s¬†the value for one of my test runs:

IECHost warp disk imaging completing in about 22 seconds by Luigi Di Fraia

IECHost warp disk imaging completing in about 22 seconds

I shall try to gather some more disks to test with, especially old ones, as I’ve been testing with pretty much the same disk I had formatted and¬†on which¬†I had recorded a few utils myself in the last few years.

Posted in Retrocomputing, Technical | Tagged , , , , , , , , | Leave a comment