Make NTSC-demos instead with raster code impossible on PAL..

Maybe this will finally lead to exploiting C128 features by the scene ;)

I wouldn't count on it.

You also have a BURST load, and you can probably say 1571 required, to which you get another 2mhz CPU which you can burst transfer data. For faster loading and streaming.

said 32 clocks don't take any 128 CPU or Drive CPU

so on the drive you can GCR decode(given the Drive has 64 clocks to play with you could probably even deflate on the drive) and get the next byte ready while the hardware transfers the byte. So you can send a byte in 32 clocks, and then send one instantly again.

To which the 128 has a 32 clock window to grab it in(sadly a 1Mhz NMI handler would take longer than this, but on 2Mhz you could use the NMI - I think not actually worked out all clock variants).

Also you can Burst transfer and bit bang at the same time.

but the time it doesn't have to spend loading and installing the loader

Quote:

said 32 clocks don't take any 128 CPU or Drive CPU

Not quite, at least writing the next byte into the latch and reading a byte on the other side plus storing it require a few cycles as well.

Quote:

so on the drive you can GCR decode(given the Drive has 64 clocks to play with you could probably even deflate on the drive) and get the next byte ready while the hardware transfers the byte. So you can send a byte in 32 clocks, and then send one instantly again.

Sending data during fetch+decode might be possible, especially by using the optimised GCR read+decode+checksumming approach which i haven't ported from 1541 to 1571 yet. It could do that already, thanks to 2 MHz mode and some suitable tables in ROM, but alas, without spare cycles to speak of. Sending data while reading from disk would not work with an IRQ loader, but at least the screen could remain enabled while loading.

Decompression on the drive side would likely have more drawbacks than gain. There's no RAM to store a dictionary or previously-depacked data, and the serial transfer will remain the bottleneck even with BURST.

Quote:

To which the 128 has a 32 clock window to grab it in(sadly a 1Mhz NMI handler would take longer than this, but on 2Mhz you could use the NMI - I think not actually worked out all clock variants).

NMI is probably prohibitive either way. But polling would work and leave spare cycles for some interleaved code doing other stuff.

Quote:

Also you can Burst transfer and bit bang at the same time.

That's an interesting idea! :)

Quote:

but the time it doesn't have to spend loading and installing the loader

Hmm, i've mostly regarded the install prodedure as a fire&forget action, so never really benchmarked that. I've had some plans to let the drive fetch its custom loader code directly from disk, rather than the roundabout way of loading a file into computer memory and then uploading the custom drive code to the drive. But i scrapped those plans for the sake of easier usage.