Great achievement Lft, can you tell an estimation, how much faster can a loader be using this technique?

Cruzer: Was that sort of a challenge of who'd build the fastest IRQ loader now? :)

You cannot transfer $fe bytes during the time a sector flies by, this is just barely possible with those $e0 bytes per sector schemes

@Oswald:

My thoughts exactly, which is why I didnt bother with checksumming in my loader.
I mean, its a trackmo, even if there is a loading error, there's usually no time to reload, so why bother? :)

lft did it with less memory needed :P :)

So will YOU need that speed? I have the vague feeling you're more the screen-off-non-IRQ-loading kind of guy, and for that... I do have two ideas on paper waiting to be tried out, both D64 compatible, giving 50x and 32x speed.

Can't a quick CRC be done at the beginning of each linked part (once all data is loaded and decompressed?) Sure, this would not be a solid way of doing things - in particular if the crc checker at the beginning has load errors., but should be a mimimum issue

Just make it load fast from SD and 1541u !!!1111

The bottleneck in most cases seem to be certain types of decompressors

I see more profit in finding a way to read from disk and transfer to c64 at the same time. Should really have a go at that once.. :) prolly i'll quickly see why that isnt possible though..

If I get the time I would like to do a similar test for loading + decrunching combined

E.g. I doubt that it makes sense to pack code, unless it's mixed up with data or full of "align to next page" statements.

My experience with packing code has shown that it can indeed be sensible to pack code by separating op-code stream and operand stream.

For even better compression, make sure to actually add redundancy to the code (e.g., lda #$00:ldx #$00 is likely to pack better than lda #$00:tax in the end).

Seems like he deleted his account, and before that never officially released the packer. Weird :

It will be hard because Wegi is like Derbyshire Ram

HCL: I might be wrong, but the drive being slightly faster actually gives you more than 18 cycles here and there on the drive side, according to my understanding.

As for the 18-cycle limit with plain 2bit+ATN, which i confirm: My explanation is that waiting for ATN flip in a loop is 6 cycles minimum, then 7 cycles for a miss which does happen, then 4 cycles to set next bitpair, then another cycle due to slightly different clocks, wire delay, missed sampling windows and whatnot. Makes 6+7+4+1=18 cycles.

So, in case the drive is a fragment slower, you need to go below 18 cycles here and there. The drive is after all waiting for the computer when needed.

i would say the computer side is the bottle neck, at least i have NOPs in my transfer loop on the computer side.

I think I've managed 16 cycles actually (66.5 per byte in practice with 2x unrolling.)

The trick is to reduce the delay between reading the bits and flipping ATN by combining both in a single RMW instruction (e.g. SLO/SRE.)

Hmm, how does that speed up the drive side, which is the bottleneck here, as it has to wait for the C-64 and respond to ATN flips asap?

Yes, I also had this idea. But I couldn't figure out a way to do it without restricting the user to vicbank 0 (and maybe also 3). Did you find a way that works regardless of vicbank?

Quoting doynax

I think I've managed 16 cycles actually (66.5 per byte in practice with 2x unrolling.)

The trick is to reduce the delay between reading the bits and flipping ATN by combining both in a single RMW instruction (e.g. SLO/SRE.)

Yes, I also had this idea. But I couldn't figure out a way to do it without restricting the user to vicbank 0 (and maybe also 3). Did you find a way that works regardless of vicbank?

Couldn't the $dd00 bank bits just be kept 00? Then switching can be done via $dd02.

Yes, this explains everything. :)

Couldn't the $dd00 bank bits just be kept 00? Then switching can be done via $dd02.

Couldn't the $dd00 bank bits just be kept 00? Then switching can be done via $dd02.

I wonder if it would be possible to get the bits through in the right order without sacrificing performance..

So setting $dd02 from user code is forbidden, while in your idea, setting $dd00 is.

I wonder if it would be possible to get the bits through in the right order without sacrificing performance..

Good point. Then RMW doesn't work unless the bit is forced low by the instruction,

Interesting transfer loop, do you really get out what you want there? :P. Gotta check it once again :).

I guess it should be easy for you to simply shuffle the bits around on the disk so that it arrives in computer memory in the correct order. And in that case, no problem, is there? I mean, you sacrificed other general-use requirements (VIC bank) before, so.. :)

Has been a feature since day 1.

..also have it in my loader

apparently the delay caused by the cable connection is slightly (really, less than a cycle) different than expected.... someone did a bunch of measurements (because chameleon has had a similar problem)

... yes its possible to make it work, by detecting and specifically handling C128D that is. (and then everything will break again with more than 1 drive on the bus ... =P)

- How fast may the head be stepped? Can it be improved with acceleration?

- What is the range of rotation speeds which should be supported?

- How hard are the GCR constraints? May clock recovery be reliable with more than two zero bits in a row?

Graham claims 280-320 rpm. TNT has only seen 295-305 rpm.
The drives I've encountered have all been very close to 300 rpm, even over time (i.e since '85 or so).

That said, it should be possible to allow three 0's in a row as long as the data rate (+ jitter) coming from the disk is strictly faster than the bit clock in the drive in all situations.
This requires you to write at a higher bit rate than you read.

- Which illegal opcodes, if any, may safely be relied upon?

As an aside how am I supposed to handle multiple IEC devices on the bus in a two-bit IRQ loader? My best idea so far is to manually detect and handle as many of them as possible by installing code to put them into tight ATN-acknowledgement loops to avoid blocking the DATA line, but presumably that will fail miserably on many devices.

My loader uses acceleration, too, originally suggested by Graham.
.
.
.
Acceleration is above figure, added once every timer lo-byte underflow. See source for details ;)

Same as for the 6510, minus SAX. SAX is reportedly not working on HCL's 1541 clone (using a Synertec 6502 clone), plus i suspect it to be generally a bad idea when used on the bus port bits. Data and clock might be updated at different times within a cycle. (But this might not be an issue after all.)

This is what i will add to my loader, too. First tests worked just fine with loading from any drive in a 4-units daisy chain using standard CBM cables.

The actual problem though is that the other drives have to be somewhat protocol-savvy to correctly decide when to reset, as i do use a watchdog approach so you can safely reset the host computer at any time without locking up your drives, or you can cart-freeze and implicitly uninstall by using standard KERNAL drive access. (Not all C-64s issue a reset signal via serial.)

I realize that it isn't much of an issue in demos but in my current project I'm forced to do an awful lot of random-access.

As you've probably guessed my transfer loop relies on SAX to mask out the ATN acknowledgment.

Have you encountered any IEC devices where this scheme won't work? Personally I have no experience with printers or modems or anything besides floppy drives really.

Thanks for the heads up! The reset signal not being reliable is precisely the kind of thing to catch the inexperienced drive coder by surprise.

Unfortunately I rather trash all of RAM, including using the full stack and zero-page as buffers, so routing a hardware timer interrupt through the ROM vectors may take a bit of juggling.

Quoting doynax

- Which illegal opcodes, if any, may safely be relied upon?

Same as for the 6510, minus SAX. SAX is reportedly not working on HCL's 1541 clone (using a Synertec 6502 clone), plus i suspect it to be generally a bad idea when used on the bus port bits. Data and clock might be updated at different times within a cycle. (But this might not be an issue after all.)

Do you have anything to back that timing suspicion up?
I can't see how the bit timing could be different all the way out to the port pins. Surely there must be at least one pipe line step through the VIA so even if there is a difference in timing on the bus out from the 6502 it will be reclocked.

didn't examine it in detail but the asl $dd00 will shift CLKin into DATAout (=DATA out from the c64 will be the inverse of the state of the CLK line).

Maybe that is what bites you?

Unfortunately I think you've got the shift direction mixed up. The CLK input is bit 6 with DATA out in bit 5 just below it, so an ASL should not pick up the two significant input bits.