Do you accept bribes? ;-)
Privately, maybe (that's classified). Publicly, no.
I think that is how GEOS support was added to SD2IEC firmware... a bunch of people contributed money until the pile was big enough that somebody took up the challenge.
Money would change my priorities and make it happen sooner, but it would have to be a big wad of cash for me drop everything and concentrate on the firmware today. But then I would feel obligated and it would make the project more like work than fun.
Anyway, since you folks seem interested, I'll try to bump it up my schedule. Since it now supports, GEOS, I was thinking a nice feature would be to allow access the .CVT (I think that is the extension) for GEOS files in the native partition (outside a disk image).
This same idea could also work for real GEOS files in a disk image... just not exactly sure what to call it or how to implement it.
I was thinking something like
O-S[drive]: filename, stream_type, index, r|w|a
where O-S is an abbreviation for OPEN-STREAM, and stream_type is:
0 for the info block (index normally unused)
1 for the VLIR table (index normally unused)... or the main stream if it is Seq/non-VLIR file
2 for a VLIR entry (a record), and index value 0~127 is required
and where default open-mode is R for read unless it is opened on channel (secondary-address) 1, in which case open-mode would be forced to either W or A (default W)
Any thoughts about something like that?
Err, sorry that is feature creep! Staying on topic, one big complaint I heard about original fast-serial firmware is it would interfere with cassette when used on a real C64. I believe this is also true of 1571 and 1581, and is why 1581 has new command U0>B0 to disable fast-serial bus? My original firmware didn't support the 1581 burst command instruction set of 1581 (in particular U0>Bx command) because some of 1581 commands work in an incompatible way in comparison to 1571...
I really need to study CP/M code again and see how CBM manages to communicate, successfully, with these two devices (1571 and 1581) despite their different syntax in some burst commands...
Anyway, I think the U0>B0 command would fix the original problem with cassette on C64, however you would need to use it every time you power-on / reset the uIEC. Another 'permanent' option would be a 'user-flash-bit', similar to some existing ones for uIEC (like ability to turn JiffyDOS off 'permanently')... It is not really permanent, it is just that user choice is saved in flash memory so it will survive a reset.
Any thoughts on that issue, or other problems with fast-serial?
One problem I thought about was fast-serial transmit speed by uIEC/SD2IEC. My original firmware set transmit speed at 6us per bit. I never did bother to check what speed 1571 was actually transmitting, but the C128 uses 8us per bit. I don't know what speed 1581 uses either, but I somehow got the impression it was different. Anyway, it has been reported (don't how reliable) that 1571 set to minimum transmit time (max speed) of 3us works fine. I think/imagine choose 8us per bit for C128 to allow for 4 devices (each with long cable) to work reliably...
Now you can alter transmit speed in software of 1571/81 by poking the CIA register. But just recently there was a post on this forum about the MOS 5710 (as I recall) of DCR that uses transmit time of 3us per bit, if I understood (and remember!) correctly. I am not sure, by simply reading that post, if it is possible to alter the fast-serial bit period in that kind of drive...
Anyway, my point is I used 6us per bit because it was a bit faster than C128 but not so fast you may get bitten by 'bad-line bug'. In other words, with 6us per bit, you have 48us per byte... which is about 4us (one CIA read instruction) longer than a typical bad-line delay of 43us. In other words, my fast-serial speed of 48us per byte is just longer than 43us bad line + 4us CIA read... so you shouldn't have any problem.
But if other devices, like DCR (and maybe the 1581) already use a smaller bit time than 6us (for example 3us), then maybe new fast-serial firmware should also use faster time, along with a warning in documentation about the 'bad-line bug'. Or maybe make it programmable?
Making fast-serial transmit speed to be programmable sounds like a good idea, but there is no device-independent way to do that... I mean this requires a specific poke for a 1571, and a different poke for 1581, and different poke for FD-2000/4000, and different poke for CMD-HD...
Anyway, uIEC could look for 1571-style poke when D64 or D71 is mounted, and 1581-poke when D81 is mounted, etc, but what should it do when you are working in native file system? Allow any of those pokes? Do we need some new command, like U0>F-Bx ?
So I got all these unanswered questions which has also kept me from moving forward ... (it is not
just that I am pre-occupied with other projects)