I'm not sure if this is just my own inexperience with the Apple II as a platform or if I'm genuinely doing something wrong here.
I use a Floppy EMU and a physical drive on my Apple IIe, and I've noticed that frequently, after swapping disks on the FEMU, it will get stuck on track 34 (and often rapidly flips between track 34 and track 0) after a warm boot and it never recovers until I power it off and on again. It most frequently happens when switching between DOS 3.3 and ProDOS disks in the FEMU, but it doesn't have to. As a result, if this happens, the FEMU simply behaves like it's stuck; the system seems to simply spin the drive endlessly and no actual data is read from the drive. If this issue occurs while a BASIC prompt is onscreen, I'll get an I/O error whenever I try to do any disk access.
Is this a common issue? Is there something I can do from a BASIC prompt to make things behave properly again without having to power-cycle the machine?
What version of the FloppyEmu and firmware do you have? What disk controller do you have, a "genuine" Disk ][ Controller Card or a clone?
I also have this happen with my FloppyEMU in disk II mode - it happened with my Disk II card and it still happens with my Yellowstone card in disk II mode. If I switch disks I often need to turn it off - wait - then power the Apple IIe back on for it to read the new disk - otherwise it bounces between track 34 and 0 doing nothing.
If you can come up with exact steps to reproduce this reliably, I'm sure Steve will look into it if you reach out to him. Could be some kind of memory leak or something.
...or the SD card is corrupted.
I have run into similar (albeit not identical) situations before. The fix was to copy all the content off of the SD card onto my laptop, low-level re-format the SD card and then copy all the content back onto the card. That solved it for me.
I have reformatted my micro sd and use multiple cards and I still run into this issue. I thought maybe I wasn't using the FloppyEMU incorrectly as well. It didn't seem right to have to turn off and on the Apple IIe so much / just to load a different game, but it doesn't happen all if the time / sometimes I can successfully boot something else without turning the computer off/on.
Well, if you want to avoid power cycling the machine, then use the three fingered salute - OpenApple-Control-Reset to force a cold boot.
You can reboot the Floppy Emu itself without power cycling by pressing the power /reset button on it.
That's the thing -- even Ctrl-OA-Reset doesn't fix it; the system still does the same thing.
The system firmware is running version 221128A; this is the most recent version on the BMOW front page.
As to the disk controllers involved, I've tried it on four separate machines, each with a different type of controller, and they all do the same thing: one is a IIc using the BMOW internal drive switcher to make the FEMU act as drive 1, one is a Platinum IIe with an Apple 5.25" Controller Card, one is an Enhanced IIe with a standard Disk ][ controller card, and the last is a IIgs through the onboard floppy port.
All of these have the same reaction, and it happens across multiple FEMUs (I have two).
I seem to remember having tried using the reset button on the FEMU before, but it's been awhile, and I don't recall if that addressed the issue or if it caused other problems. I'll have to try it again here.
I haven't found a solution either - I basically just live with it.
I tried a reset on the FEMU last night -- sometimes, disks would change tracks to something other than track 34, but they still wouldn't read.
A PR#6 at a prompt just hangs if I Ctrl-Reset out of it. As I mentioned before, Ctrl-OA-Reset also makes no difference.
A slight clarification, though: While it initially looks like it toggles from track 0 to track 34, it actually seems to be sweeping the entire range extremely quickly -- it's like it's crawling through all 34 tracks on the disk, getting hung up on track 34, and then it tries again from 0. Maybe this is a disk-handling routine that's not getting handled properly on one end or the other?
Strange - have you tried using alternate disk image formats like .woz or .po / .do vs .dsk?
I have a mix of all of those disk formats on my micro SD but I haven't experimented to see if it's only certain formats this happens with.
So Baldrick you dont experience this with your FloppyEMU? You can endlessly switch disks - ctrl alt del and they boot right up?
(If you have an "alt" key on your Apple II and you press "ctrl-alt-del", then something is seriously wrong! ;-))) )
I can swap disks and reset the machine all day - always works. I'm also using the latest FEMU "C", however with firmware "221122A". Indeed Steve released another update a few days later (221128A), but I haven't upgraded again. Are you both (with the issue) using this same firmware (221128A)? Is anyone else using this and not seeing this issue?
In any case, I would contact Steve (BMOW) and ask about it. Especially if there was two of you with the same issue. He'll probably have an idea. Even if this was a hardware issue with the machine itself - he's probably aware of almost all the possible failure modes.
I've already sent a support email, but haven't heard back yet (it's been less than 24 hours since I sent the email).
I just find it tremendously strange that I'm experiencing the exact same failure mode regardless of the disk controller or machine.
Hah! Oops ctrl open apple reset - I am using the latest firmware but it happened on the old firmware as well. I do have the latest FloppyEMU C as well. I will have to email Steve and see what he thinks is going on.
So with some very good direction from Steve at BMOW I think it does in fact have something to do with my micro sd card. Baldrick you may be right on the money. I tried disk switching with the preloaded BMOW sd card that I bought when I purchased my FloppyEMU and found that I can switch disks and ctrl-oa-reset to load them one after another endlessly with no problem. On the other hand, the micro sd card that I made full of downloaded games etc from Asimov site doesn't work like this - sometimes when I switch to another disk it will load with ctrl-oa-reset but most times nothing happens and I have to power off the Apple IIe..wait and power on to get the newly selected disk to boot. It's weird, I previously reformatted that card and reloaded it so I am not sure what the issue is.
Does the SD card that has issues have a lot of files in the directory where the disk images reside? By a lot I mean more than let's say 50.
Yes in fact quite a lot more - I have several folders on the sd organized by game type aka rpg, arcade, Infocom etc and there are well over 50 in each folder. You think this is the issue?
Let's just say for example counting games in 1 folder at 50 I had only gotten to the letter c.
I have a hunch that this is the issue. Try with a folder that has less than 50 and if the problem goes away I'll explain why it's happening.
Ok I will do that - thank you CVT
I think you are probably right CVT. The FloppyEmu has limited memory and processing power. It's probably getting bogged down or running out of space/power with too many files in a sigle directory on the SD.
It may be possible to get around this by re-structurng the files on the SD, and dividing them up into smaller chunks in more directories. That may make it take longer to select images, but in some ways it may be possible to make it easier to find things by being better organized.
That's going to be my project this weekend - thank you SJ.
Another thing to keep in mind with devices like this, is that certain images work only or work best when stored contiguously on the SD card. Depending on the OS you are using to format and copy files, and also just depending on luck of the gods with SD manufacturer, you can/will run into werid stuff.
Yes, the FloppyEmu requires file data to be stored contiguously on the drive, otherwise the particular disk image won't work. It's described in the manual. But that is properly checked by FloppyEmu, and it will show an error that the image is unusable. Simple fix for those cases is to simply move the file to a separate folder (trash), so the file with non-contiguous blocks remains allocated but isn't used. And then you simply copy the file again to the disk. If it happens too often (usually happens becomes a problem when the disk is almost full), then it's best to reformat and rewrite the card (and using a larger SD card, so it's not immediately full again).
If it's really a large number of files which causes the described issue, then this still sounds like a software bug in the FEMU firmware. Yes, its resources are limited - but if large directories (e.g. covering multiple blocks) aren't supported, then FloppyEmu should easily detect this and report an error - in the same way as it complains about non-contiguous files.
That was indeed the problem- I reformatted the micro sd card and put directories with fewer files in each and I am able to switch programs endlessly without issue on the FloppyEMU. Thank you CVT for that brilliant insight and thank you to all of you for your fantastic input. Impressive group of computer enthusiasts in this forum.
I ran into this issue myself and it appears to be a bug in one of the common open source libraries for C++ used to access the SD card. For some reason trying to open and close a file in a directory that has a large number of files takes a long time (sometimes seconds) depending on the number of files before it in the directory. It starts to slow down after the first hundred and then it gets slower and slower the more files there are before it. By the time it gets to 1000 it takes seconds per file. This happens even if you try to open a single file that is way down without opening the files before it: the more files there are before it in the directory, the longer it takes to open.
I made a video demonstrating this with the Apple II card I am currently developing and a directory that has more than 540 files. I simply list all the files in the directory, but in order to determine the file’s size and date the open source library needs to open and close it. I had to limit the listing to 512 until I find a better solution, since it gets really slow soon after that. Notice that the second time I run the listing the files at the top are still very fast. Also listing the files doesn't sort them in any way. The reason mine appear sorted is because I copied them from Windows as they were sorted alphabetically. Also this is running on a 240 MHz microprocessor. Slower micros will take longer.
Video: https://www.youtube.com/watch?v=Y6UFv5SVlG4