In the evening today I implemented the PRG import feature in IECHost: I can now copy data from a PC to a real disk.
However, the work on this is not yet finished as I’ve been copying a chunk of memory initialised to a sample program, instead of a user-picked PRG file, for simplicity.
In order to further troubleshoot new features that write back to disk, I felt compelled to step back a bit and add some useful features before finishing the PRG import one.
In particular I added a quite flexible interface to IECHost that enables users to send commands to serial devices through the command channel. On my first attempt I roughly implemented the equivalent of:
In case you have not tried the above before in direct mode, it might surprise you that control is returned to the BASIC interpreter immediately while the disk is busy executing <command>, which might take a while if e.g. the command is about formatting a disk.
However, if you issue a CLOSE command while the disk is busy, you might appreciate the fact that control is not returned to the BASIC interpreter until the disk command completes:
This is due to the fact that a serial device on the IEC bus (e.g. a printer or floppy drive) might be busy performing a long job. In that case it will take a while to signal it’s ready to receive when the IEC host signals it’s ready to send by releasing the clock line. There’s no time limit when it comes to waiting for a device to become ready: that’s why CLOSE will not return to the BASIC interpreter until that happens.
Over the weekend I worked at a maintenance release of my IECHost GUI client, addressing an issue I was having with data exchange upon creating the USB communication thread under Windows 10.
Before I go on and start adding a file import feature to save PRG files back to physical disks connected to IECHost, I thought to provide an update of where I am at the moment.
Here’s a video that hopefully covers just that!
I finished an important part of the maintenance I was planning for the IECHost GUI client: all communication code is now running in a separate thread, including the initial setup. The implications on the stability and responsiveness of the client are significant at this point indeed.
I also decided to extend my work on the directory listing feature and add the PRG exporting one, which is conceptually identical. Here a few images of my tests exporting a PRG:
IECHost: PRG export feature in use
IECHost: PRG export completed
Obviously looking at the time it takes to export a large file one might wonder: why not warp image the whole disk in just about 22 seconds instead?
The answer is simple: exporting a file with standard (hence slow) routines ensures maximum compatibility. The choice is therefore left to users on how to transfer data across, based on their disk drive compatibility.
Stay tuned as the fun is only just about starting!
As I mentioned before, I worked at some code maintenance following the integration of a number of modules in my IECHost client application. That specific post-integration maintenance is now pretty much complete.
I am also sharing a video of a longer directory listing:
Perhaps I do need a scrollbar after all 😉
I finally had some time this afternoon to finish the directory listing command in my IECHost client.
Here’s what it looks like:
This is a quite important milestone because I now have a working method to transfer single files (including the directory listing, which is coming across just like any other file, using “$” as file name) out of the 1541 drive using an extremely compatible approach.
I will now have to go through a maintenance cycle of the client in order to better integrate all bits involved in the directory listing handling and move a few bits into the communication thread in order to allow an even more robust solution 🙂
I was having a play with converting the directory listing received from my 1541-II (which is essentially a BASIC program) and noticed that I went a little too far with emulating the behaviour of the output routine of the Commodore 64.
In order to illustrate what I mean, have a look at the picture below, particularly at the way the first filename is displayed on a C64 compared to what D64 Browser shows:
Forging unexpected names on a D64
I had forged a special name in D64 Browser, putting a 0xa0 character after “TESTFILENAM” – which creates a shorthand version of the filename, then I also added 2 control codes. Obviously, as these control codes are outside a quoted name in the directory listing, the output routine used by the LIST command on the C64 interpreted them as control codes and enacted on them, instead of showing their quoted version.
One can very easily upset the directory listing output on a C64 if e.g. a 0x13 character (Home) is inserted after 0xa0 in a filename…
Forging names with a 0x13 char in them after 0xa0
I will have to simplify/rewrite the implementation of the output routine as it appears I might have over-thought it slightly 🙂
I’ve had some time today to progress the directory listing feature of the IECHost client.
IECHost client: directory listing preview
At the moment I am shooting the listing as text to the display for testing purposes but in the next couple of days I might write the parser that gives some structure to the listing so that each item can be acted upon.