should work then. Use the method as Guillian described.
correct, it should work, but it doesnt...
files renamed:
1 -> ALESTE2.FD1
2 -> ALESTE2.FD2
3 -> ALESTE2.FD3
NEXT_DSK.dat looks like above (auto-created)
i restart the caps light blinks like it wants to load but it doesnt.
i know that the .dsk files i have are good because they boot on the same machine after i have loaded the 3 disks using FDLOAD. doing opfxsd aleste2.fd1 /D1..3 also works, but the FD1..FD3 > NEXT_DSK.dat doesnt...
maybe the extra RAM is in the way for some reasons. Have you tried disabling that? (I do not know the switch but it is described somewhere in the manual)
i did this on an emulator last evening and it worked, but when i disable the ram expansion, itll reboot and it is back on again...
I have tested it on turbo R and MFR SCC+ SD 512K and works here.
Perhaps the DSKs are fragmented in the SD card.
Probably the easiest and faster way to defragment it is to copy all the SD card to a folder in the PC, erase the card, and copy again the files to the card.
Also, be sure that NEXT_DSK.DAT file assigns the DSK in the right order. If the files are not copied in order they could be loaded like:
1 -> ALESTE2.FD3
2 -> ALESTE2.FD1
3 -> ALESTE2.FD2
Manuel, i tried it a few different ways, i deleted the card after making a back upo and then re-copied everything over. then i formatted the card and put everything back on, and then i formatted the card and ONLY put on the 3 DSK images. none of them worked.
could it be a linux thing? im not sure where else to go with this?
Could it be MFR software? kernal, etc. needs an update?
could it be a linux thing?
I copy stuff to my SD via linux and am not experiencing any of these problems.
These are the checksums of the original disks. Try checking if yours match:
SHA1(ALESTE20.DSK)= 224260bac42b56195a428fee85fad7fab5bf74b9
SHA1(ALESTE21.DSK)= 365355f6f25a40d106b0e8787451967804e36e40
SHA1(ALESTE22.DSK)= 82314e1d70087dd853eafe05d1bbac0c87b7bee4