I am glad to share the fact that the PCBs whose design I had sent to manufacturing arrived today.
New PCBs for: DC2N4-LC, IECHost (2 versions), and Tiny C2N Monitor
The PCBs in the above image are (top left, then clockwise): Tiny C2N Monitor, IECHost, IECHost “white knight” version, and DC2N4-LC.
I am having a few long days with the commute, so I will not be doing much with these PCBs this week, but expect an announcement soon 🙂
Stay tuned!
A while back I provided the guys at History64 with a dozen IECHost DIY kits, at production cost. They’ve now assembled them all and are going to make them available to users!
History64: a dozen fully built IECHost devices available to ship
If you would like an IECHost for a short period of time, to help preserve your stuff and then pass it on to somebody else, so that the cycle can repeat, then visit their website and ask to be put in their waiting list!
I had previously commented on the fact that using the sector dumping mechanism for a series of sectors was significantly slower under Windows, compared to Linux.
Well, this evening I have been experimenting a bit with communication timeouts and I was able to e.g. substantially reduce the dumping time for all allocated sectors in the test disk I used previously, from 13 seconds to less than 6:
IECHost GUI client: reduced BAM-based dumping time under Windows
It’s too early to share this version as I have to do some regression testing in order to fully appreciate the implications of reduced communication timeouts on the stability of the application.
Fingers crossed, things are going to pan out nicely for Windows users on this one too 🙂
Stay tuned!
Version 3.0 of the IECHost GUI client is now available within my Software page.
IECHost GUI client: version 3.0 released
Be reminded that this version too requires a firmware update in order to deal with the changes to a few commands.
Again, a video that illustrates how to do a firmware update is available on YouTube:
Enjoy!
Although I haven’t looked at the communication overhead for Windows when compared to Linux, as per my previous post on this subject, I have been working a lot on even more new features and doing research for the IECHost GUI client version 3.0.
The full list of changes in this version is available here.
Worth noting:
I myself had the luck of having access to one disk with inaccessible tracks, kindly donated by Andy, so I was able to shed some light on what appeared to be a track 1 seeking bug, reported by a few users, which it certainly wasn’t.
Here’s what my testing disk produces when dumped with the IECHost GUI client:
IECHost GUI client: disk with an inaccessible track 1
It certainly appears that track contents are off by 1, to the left, doesn’t it? Here’s the logging:
IECHost GUI client: disk with an inaccessible track 1
While dumping this sort of disks, users can clearly hear some rattling as the read head bumps a few times against the bumper, in an attempt to move all the way to track 1. The logging also shows a number of sector retries being exhausted at the inner boundaries of each speed area: these are a clear indication of inaccessible tracks at the outer edge of the physical disk. In my case, the first outermost accessible track on the floppy drive I use is track 2.
Here’s how the IECHost GUI client version 3.0 reports on and attempts to recover from this scenario:
IECHost GUI client: disk with an inaccessible track 1
When outermost tracks are inaccessible, it might still be the case that they were unused, so users can safely archive the resulting disk image and move on to the next disk. However, more often than not, these outermost tracks were used to store data with a misaligned drive. Therefore it takes a misaligned drive, or a drive without head bumper, to access them, and recover the data therein, for archival/preservation purposes.
Furthermore, in presence of a lot of disks with inaccessible outer tracks formatted by the same misaligned drive, the IECHost GUI client provides an option to set the outermost accessible track value, which informs the drive code to expect track 2, or higher, as first accessible track after bumping, so that there is no sector retry exhaustion occurring while dumping.
Here’s the outcome of dumping my test disk with the outermost track value option set to 2:
ECHost GUI client: disk with an inaccessible track 1
As you can see from the above screenshot, both the IECHost GUI client and drive code are aware of the issue with inaccessible tracks, and that, in turn, is captured within the block error info part of the resulting disk image:
D64 Editor: block error info for a disk with an inaccessible track 1
Therefore both the drive code and client software proceed comfortably through the dumping process, which is also quicker by about 2 seconds (because the drive code does not attempt to wait for non-existing sectors), as shown by the logging:
IECHost GUI client: disk with an inaccessible track 1
In both cases, whether the software shifts track data or the user expects some tracks are unreachable, the resulting D64 image contents are, of course, the very same, including the block error info part. Again, letting IECHost know about the outermost accessible track on the drive in use is an effective way to deal with a series of disks written by the same misaligned drive: the process is faster and each speed area is treated with the appropriate density setting.
I will conclude with saying that most of the changes in version 3.0 were proposed and discussed with Mads, from The Transfer Team, to whom go my thanks also for the time he spent helping with testing. Valuable feedback on misaligned drives was also provided by Tommi during our IRC exchange: a big “thank you” to Tommi is also due!
Hopefully, the amount of insight that resulted from such testing with IECHost will be valuable for preserving Commodore disk contents moving forward too, including during X’2018 🙂
Stay tuned for the official release. If no problems arise, it should be generally available this weekend.
I’ve added support for “Lexpeed Fastsave System” in TAPClean, including for those tape images with multiple titles in them.
“Lexpeed” takes its name from Lex Boere and is (C) 1985 by Radarsoft. It seems to be a more flexible version of the “Radarspeed” loader, which was written by the same author.
I am currently looking into “Radarspeed” titles and I’ve already identified two variants, in terms of loading plan:
In principle, both scenarios are quite simple to support in TAPClean. I will try to work at both as soon as I get a couple of afternoons free.
Stay tuned!
I’ve recently added support in TAPClean for a Microload variant often found on Blue Ribbon titles. The code is nicely optimized when compared to the original Microload one, so I have put it down in a document on my own Wiki.
I shall add a list of titles that use the loader too as some point.
Feel free to share your impressions on the code, the documentation format, etc.
For the full list of upcoming changes in TAPClean v0.38, have a look at this page.
