indeed, I want fastload, preferably screen on and only SD2IEC, in that I would strip out all the other drive versions.

Claus_2015: thanks for the hint, eload is .. interesting :) Practically you setup loading first with the stock routines, then upload the short "drivecode" and resume with a fast protocol.

It's a 2bit timed protocol, so you can't have sprites and IRQs will be delayed while it waits for badline clearance, but screen can be on, so would be OK for typical games.

and I could load with burst.. but lots of work very little gain.

Please remember that the Sam's Journey fastloader is only supported by sd2iec v1.0.0. Some SD2IECs have an other firmware and can't be upgraded. Example SDRIVE1564 that has sd2iec v0.10.3 and cannot be upgraded.

Quoting oziphantom

and I could load with burst.. but lots of work very little gain.

When it comes to burst, indeed. I've recently added it to my loader, and it's not faster at all than a well-optimised bit-banging protocol.

But where do you get all the content to fill 5-6 disk sides? How much space do you reckon would everything take when well-compressed?

One note after a shot at implementing eload: doing the setup for file load using IEC protocol will be murder for your interrupts, if you use Kernal (and it takes several frames.) However, as the device is known at this point, you could take a happycase approach, and implement your own simplified IEC send byte routine that can coexist with your interrupts. Also has the advantage that you can clobber whatever memory you like.

I think Burst while not faster than 2bit in a tight coupled loop,if I'm pulling in a byte around other things, such as irqs, sprites, game logic, having 8 bits being transferred without a CPU having to be involved will make it a lot easier. As I can't miss the byte, and it will wait for me without needing to be sent again.
However does your code use Burst + 2Bit bang, because that would get you faster again right, as the Burst byte won't occupy CPU time while you transfer the 2bits and hence be almost for "free"?

the 512K cart will already be compressed. It will have some code uncompressed to do the initial boot etc, but all the data will be compressed.

... when you factor in partial blocks + the loader code + side detection code + what disk is that file on data, it would push you to 4 sides. So you could probably squeeze it onto 4, but usually in such cases its better to keep a stash of common data on each side to limit the amount of flipping you need to do, and hence you start to spill into 5/6 sides.

I did some research into that for Thundax's yet-to-be-released game which premiered at X 2018. He required an IRQ loader as well as an IRQ saver, both not resident in the drive, so also uploading the code using KERNAL had to be IRQ-friendly. I don't have the code here at the moment, and it needs some clean-up, but i'll post the gist of it soonish.

Hmm.. ended up making an NMI state machine to get the IEC stock protocol sends (before eload init, or for saving) reliable. The good part is that now that I got it running, can try to make it tidier.

[..] To which I take that sd2iec are somewhat ubiquitous these days particularly with the more casual user, 1541uII is for the hardcore user. But I feel that 1541IIu+ hundreds (probably has reach over a 1000 though) sd2iec thousands [...]

gideon should make a cost reduced 1541u

[...] I assumed [...]

You can test IDE64 in VICE. It works almost like "true drive emu" off, ie. CHRIN is fast, and IRQs get delayed only about a line, if at all.l

not sure if this helps, but this is an example of what i did

Working eload-based game fastloader here: https://github.com/cadaver/c64gameframework

Working eload-based game fastloader here: https://github.com/cadaver/c64gameframework

It's tangled quite deep with the rest of the framework (in loader.s), so may not be very usable outside of it.

> Its hard to say until the game is done. Or even started, I'm just at the
> planing and early test stage. I guess an IDE64 with CF is going to be "as" fast
> but as just KERNAL and not fastloader, will it be fast enough?

Depends. Some benchmarks:
https://singularcrew.hu/idedos/perf.php

Up to date information is in the user's guide. Section 13 describes KERNAL
calls and memory use:

https://singularcrew.hu/idedos/beta/IDE64_users_guide_beta.pdf

The operating system was written so that it only "trashes" memory locations
which would be trashed the same way on a stock machine as well when accessing a
serial device. The addresses are listed so there's no need to guess what to
back up.

Okay, didn't get around cleaning it up yet and not sure if this helps, but this is an example of what i did:

         ; scratch "TEMP"
         lda #FLOPPYMW - scratch
         ldx #<scratch
         ldy #>scratch
         jsr $ffbd; SETNAM
         lda #$6f; secondary address: command/error channel
         sta $b9
         lda #$20; LISTEN
         jsr sendslow
         jsr $f3e6; send secondary address and filename
         lda #$3f; UNLISTEN
         jsr sendslow
         jsr $ee03; clear ATN

         [...]

sendslow ora $ba
         sta $95
         lda $dd00
         and #%11001111
         ora #%00001000
         sta $dd00
-        bit $dd00
         bpl -
         sei
         jmp $ed5a; send byte