David mentioned Burst mode on Facebook. It doesn't require new ROMs in CBM drives, and since we're talking about a custom SD2IEC anyway (I'm partial to using a Pi Pico, right now), then it's probably easier to add a burst mode setting to SD2IEC than to re-create JiffyDOS. Not only does this prevent any JD Copyright issues, but burst mode could be back-ported to the official SD2IEC source and benefit Commodore 128 users down the road.
I meant "ala" to imply "in the manner of / for example".
I'm pretty sure burst mode would require ROM changes, though. I don't think a stock 64 supported burst mode on capable drives. Related but different is fast serial mode which definitely requires different ROM routines.
I meant "ala" to imply "in the manner of / for example".
I'm pretty sure burst mode would require ROM changes, though. I don't think a stock 64 supported burst mode on capable drives. Related but different is fast serial mode which definitely requires different ROM routines.
Yes. Support for one fastloader format already supported by SD2IEC would allow existing devices to be used, while support for the most efficient available alternative for the CX16 would allow units with CX-compatible firmware to communicate as fast as possible. Whether the C128 burst mode is supported in hardware by the available pins on the W65C22 ... I don't know, but it wouldn't be surprising if Burst mode on an SD2IEC device connected to a 4MHz, 6.25MHz or 8MHz CX16 would allow faster throughput than Burst Mode to a C128.
I meant "ala" to imply "in the manner of / for example".
I'm pretty sure burst mode would require ROM changes, though. I don't think a stock 64 supported burst mode on capable drives. Related but different is fast serial mode which definitely requires different ROM routines.
I'm pretty sure burst mode would require ROM changes, though. I don't think a stock 64 supported burst mode on capable drives. Related but different is fast serial mode which definitely requires different ROM routines.
there are actually is a C64 burst ROM KERNAL already out there. And there's obviously the Commodore 128 KERNAL. Since that code already exists, that should be less of an issue than trying to re-create the JiffyDOS protocol from scratch in a manner that doesn't infringe on Mark Fellows's Copyright.
Right, I thought you were saying the kernal could use those features without modification. My understanding was that C64 was the base kernal, and I don't know what the license actually allows from other kernals. It may be a distinction without a difference.
The continued discussion after David's comment would be helpful, but no FB here, wish David would give a proper YouTube update where more people would see it.
It seems Michael is willing to fix the sd card issues and I would hate to lose that feature. Maybe this Facebook post will kickstart the project again
Quote
About FAT32 and the SD card: First, this is a very complex yet mature piece of the software stack. And it is way better than an external sd2iec, e.g. it's 50x faster, but also way less limited, more generic, and still very much in the style of Commodore hardware (no D64 images, but direct access to up to 2 TB of storage, with subdirs etc). Sure there are bugs, as in any software. I could dedicate some time to fix them, but again, with the project overall making little progress, I'd rather dedicate it once I know there will actually be a project at the end.
The continued discussion after David's comment would be helpful, but no FB here, wish David would give a proper YouTube update where more people would see it.
This gives me a bad feeling about the future.
I don't think the lack of a YouTube update at this point is cause for concern, or at least no more concern than before the most recent FB update. David puts a lot of time into production on his videos, trying to create evergreen content. This would not qualify (at least not from my perspective).
why not creating a SD device that goes on the floppy drive connection and make it work as if it was one? that could move this out of the computer insides and be more easier to update it, no? and you can make so that you can have 4 like the floppy drive and help copy files on each of them?
I can already see the tiny SD reader with a floppy-drive style design near the computer, could be fun.
