KimJorgensen
D64 with loading in game not working
When I load a game in which there are other loads, such as the title screen and then the following levels, it does not work. In-game loading does not work. Another exemple : I load koala painter and when I want to load picture there is an error message : device not present.
This is a limitation listed in the README. Disk drive emulation will only work if the program or game uses kernal vectors (slow load) and a lot doesn't. The best you can do is try an alternative version of the game or find an EasyFlash release.
With the current hardware it is not possible to support fast loaders or software that uses direct hardware access. For that you will need a physical connection to the serial port.
Is it possible to respond to the mw and me commands the same as an sd2iec ? For example in fload https://csdb.dk/release/?id=114912 if the response is the same as sd2iec then the fast load is disabled and kernel routines are used instead
Hi, I think this could be reconsidered.
I've done some analysis on the delta between the set of working SD2IEC images and the working KungFuFlash D64/ D81 images.
Surprisingly only few of the SD2IEC D64/D81 images seem to use a fastloader. Most of them use a regular kernal fallback.
I estimate on top of the current working KungFuFlash set, around 400-800 existing SD2IEC D64/D81 images could work out of the box if the CBM-DOS command set is extended to a more complete set. I checked using Vice's +virtualdevice mode. In that mode, a virtual drive is connected where most CBM-DOS commands work but all the memory-read, memory-write and memory/block execute commands generate a "Syntax Error". Supporting (most) of the virtualdevice CBM-DOS commands seems to be enough to make the fastloaders in the SD2IEC set disable themselves, and supporting the track/sector loading/saving (U1/U2) as well as opening files with CBM-DOS extended naming like "0:A4,S,R" seems to be sufficient, use character-by-character mode for both read and write.
Supporting these D64 images, does require some refactoring of the current D64 support code on both C64 and ARM, then after that refactoring some implementation of the basic CBM-DOS command set.
- One more Kernal call (CHROUT) needs to be trampolined. This might be done if the filename buffer at $df00 currently is removed and replaced with character-by-character calls.
- Parsing commands on channel 15, and extended filename support on other channels.
- The Open and Close could be done using only Talk/Untalk Listen/Unlisten like the actual device does
- Supporting the 15 buffers fully
- REL file support (although I don't expect that to be used much in the SD2IEC set)
Most of this is quite doable, but I do wonder if the added ARM code would still fit in the available space. I expect the ARM code would take > 8 kB of space at least.
Dear contributors,
I just started using this cartridge recently and I mostly use D64 files, but with mutliple disk games.
It is an issue even for PC/Android etc emulators that when I select an other disk it interrupts the current running code or resets and executes/types in the LOAD command etc.
All I want is just to be able to mount a different D64 image without interrupting the current game when it asked me to change the disk in the drive.
I think with the current implementation here, I have to push menu button which makes a RESET and runs code from FW and I can mount other disk, but the running game already wiped out...
There could be an easy solution for it I assume:
- selecting a D64 would set the file path/name in a variable of the MCU, so just some local variable not in the C64 loader program like "idoregesz_disk1.d64"
- when pushing the "special button" the MCU could increase a counter like "idoregesz_disk2.d64" in the file name and mount the disk with the incremented name and call the routine on drive as tray open and closed/ejected disk and inserted (if possible)
- game would not be interrupted as everything happens in the MCU level...
I know it won't be a perfect implementation as need to put images in a sequence but could be a workaround for change the disk ingame issue.
What do you think?
If possible I can also help in the implementation and fork and try to implement is, just might need some advices where to start as I have limited time developing hobby stuff :( I worked in STM32 based projects, mostly on drone firmware modifications previously.
Is it possible to respond to the mw and me commands the same as an sd2iec ? For example in fload https://csdb.dk/release/?id=114912 if the response is the same as sd2iec then the fast load is disabled and kernel routines are used instead
I think KIM did not see this message, maybe he missed it, you could publish it as a new topic. I think your proposal is very good!!! that would improve compatibility a lot!!! and many D64 images that don't work today could eventually work.
