Commodore disk dumping revisited

The idea of making a whole track dump of a standard DOS disk for the Commodore 64 in just two revolutions, at least on lower density tracks, using IECHost, has never really left me. Although it is pretty much pointless to achieve the above nowadays that we have better disk dumping hardware, it’s one of those challenges that I did not manage to tinker with enough to either admit it’s impossible or succeed. The truth is that I like (and love) the amount of seemingly-reusable-elsewhere knowledge that I gather in the process. So here I am, trying again.

As a long time has passed since I was working on this challenge, in the last few days I decided to start from the very basics and only use my previous work for reference later on.
So far I managed to set up a test rig that I run on emulators: CCS64 and VICE’s x64. It’s still far from its final state, but I managed to put together a sector dumping solution where the C64 is requesting track+sectors and the 1541 is replying with data from them. Nothing more, nothing less.
Well, this very primitive setup takes 25 seconds for a whole disk dumping: yes, it’s slightly more than WarpCopy 64 and it’s not dumping lower density tracks in just two revolutions (I only counted revolutions on track 1 to be honest, which is where I would expect a better chance to lower them to just 2).
However, this is just a stepping stone for me as I was wanting to refresh my memory about the drive code idea that’s at the core of my jolly (and final) attempt to beat the 22 second baseline of WarpCopy 64.

What I need to change now in order to make a difference is:

  • the drive needs to take initiative instead of being requested tracks/sectors (albeit the current API has little overhead if one asks for all sectors in a track): this change alone would save a tiny fraction of time in between tracks, which is when I request another track, so it might not be worth the effort unless the next change is providing the time saving I expect;
  • the transfer protocol over the IEC bus needs to be changed to the very optimised one I was using before (and beyond): I expect this change to reduce intra-track (or inter-sector if you wish) “dead” time, that is the time spent to send a sector to the host computer.

The “beyond” reference above is due to the fact I don’t expect this to work on a Commodore 64, but IECHost might just have that tiny extra edge that makes dumping in under 22 seconds possible.

As a matter of fact, I will be cycle counting instructions again (as I had to do a lot for my crack intro, “Border Mania”) and putting together some proper timing diagrams for all bus signals involved in the transfer protocol.

In the meanwhile I decided to provide myself with a cheat-sheet to avoid having to look up the basics over and over again during my fragmented development effort. I am happy to share it in the hope it might be useful to other people too should they want to appreciate the design of the IEC bus and its wiring on the host computer and peripherals 🙂

IEC cheat sheet by Luigi Di Fraia

IEC cheat sheet by Luigi Di Fraia

I’ve essentially avoided references to components that are not quite meaningful for describing the workings of the bus and noted down how asymmetric the wiring is (hence the memory-mapped I/O register bit configurations are too) on the master and slave side.

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: Logo

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s