My guess is that JiffyDOS accelerated ACPTR does some handshaking every time it is called (for every byte), while GEOS turbo is probably optimized to transfer the whole block... On a real 1541/1571 DolphinDOS might have a chance vs GEOS turbo, as it has additional RAM for storing whole track and uses parallel port for transfer - but it is limited to 1541/1571 only.
But with JiffyDOS or DolphinDOS such a drive would just fly, maybe even IDE64 could work this way (imagine that speed...).
But I agree, new desktop is badly needed... I hope the English version will also be available some day, testing German one is not easy for me
adtbm - what about your plans for conditional compilation? I see two use cases:
1. For the purpose of development I replaced the fancy Mega65 banner with a simple generic one (it displays faster and does not interfere with my old C64 debugging habits, by doing things like sta $0400 or stx $0402 in the interesting places), but I imagine it might upset some users. I would like to be able to build BASIC images with different banners (generic one, for Mega 65, for Ultimate 64, etc.)
2. It appears my Ultimate 64 provides an easy to use method to load data from internal IEC generic 'drive' really quickly - it would be nice to incorporate it in the Kernal, but... it would be better to do it in U64-specific Kernal build. Same for device #2, on U64 it is probably possible to write Kernal routines accessing it's built-in modem emulation instead of User Port. But for all these we would need U64-specific builds.
I have tried to put some platform-specific code in subdirectories (and using Ophis macros to inject hooks into core Kernal/BASIC), but I couldn't get it to work due to preprocess tool unable to handle more than one assembler files directory.
Google search revealed, that this is probably at least partially done - see here, First look on GEOS running on MEGA65 in C64 mode. In order to make this work, I had to strip any turbo code from the 1581 driver that normally would run off the 1581 drive, Unfortunately, code does not seem to be public.
petSD+ replied with 00,OK,00,00; but I found the information, that the only turboloader it supports is JiffyDOS - it's CPU is clocked twice as fast as SD2IEC (needed for IEEE-488 support), so the code supporting each protocol has to be adapted; so it's probably normal that GEOS does not work.
Yes, disk IDs were the same - as I simply moved the SD card from one device to another, I also set the same drive number (old unit was disconnected).
How does the MP3 recognizes SD2IEC? Till now I was using a 'cableless' SD2IEC device (initial status message: 73, SD2IEC V1.0.0ATENTDEAD0-24,00,00) as a boot device - I boot it from DNP image. I moved the SD card to another unit (petSD+ unit, 73,NODISKEMU V1.0.0ALPHA-20181028-12B2387,00,00), assigned it the same drive number, but GEOS MP3 no longer boots, it stops at the white-gray grid without any error message, desktop background is never displayed. After switching back to 'cableless' SD2IEC unit GEOS boots again.
It's just not compatible enough. You wouldn't believe how incomplete this code currently is - some problems with the LOAD are there because there is no turnaround-to-talker implemented yet. And there is gazillion of such missing pieces there; the only reason a lot of games already work is that they take over the whole C64 and don't care about it's ROMs.
You can safely use original chargen, though
In the mean time LOAD started working... sort of
- only from drive 8 (hardcoded in BASIC)
- probably just once in the lifecycle - cleaning-up the drive status after loading does not work yet
For all curious, you can download precompiled binaries here - just don't mix these ROMs with Commodore Kernal/BASIC, or bad things will happen.
Continuing the thread from the old Mega65 forum: with my today commit the emulated 1541 finally started moving head and blinking the red LED on LOAD"$",8 Loading does not work yet, though - not yet known why.
Something is probably wrong with jsr iec_wait100us / jsr iec_wait60us - I needed to insert several of them (too many I think) to make the EOI recognized...
One option for a more powerful sound would be ARM2SID with its FM emulation...
IMHO as soon as someone tries to run some utility cartridges or BASIC extenders, this fancy logo will start causing compatibility problems - like the ones you can observe with JiffyDOS Dolphin mod (try to use this Kernal with IDE64...). Why not to go with something simple?
Whichever code tries to mess with such startup message will most likely produce at least something sane.
 Various modifications are possible, for example '64K RAM SYSTEM' -> 'MEGA65 MACHINE', or ' ULTIMATE 64 ', or 'REV 30.02.2019'; some branding could be configurable during compile time
Indeed, the background bug is fixed now, thank you.
I have noticed, that a lot of functionality is accessible using right mouse button only - this might be a problem for joystick owners. Would it be possible to simulate RMB with, for example, Control+Fire? Maybe the SuperStick drivers themselves could provide such emulation too (so that other apps could benefit)?
Another suggestion - how about supporting mouse wheel for scrolling within the desktop windows? The great Micromys interface allows to use the scroll wheel on C64, see here.
Current snapshot displays a garbage background if no background image is used ('Screen' settings in GEOS.Editor).
With the C64 community being very active these days, we may be able to establish a standard for extended Kernal ROMs.
Having a kernal with banking would be really neat.
Have you tried to contact Gideon from Ultimate 64 project? If both Turbo Chameleon 64 and Ultimate 64 support such standard, and there is at least one Kernal utilizing the banking to perform anything useful, I'm sure the rest will follow.