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!

This entry was posted in Retrocomputing, Technical and tagged , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s