Beta Tester Feedback

[rich]

For the Kfest attendees that purchased a CFFA3000, please leave feedback about problems, thoughts and suggestions for
future CFFA updates.

Thanks,
-Rich

[f8dy]

Well I wasn't at KFest but someone who was FedExed me one of the beta cards. I'm having a problem with mounting images read/write. Is writing supported in the current firmware? (I have b3.) Any attempt to copy files or SAVE or BSAVE new files results in an I/O error. This happens with several different disk images, including the official Beagle Bros Pronto-DOS disk and a hard drive image running ProDOS 2.0.3.

[petern]

Thank you for bringing the CFFA3000 to KansasFest and for selling "beta" cards. So far, I've tried the card in an enhanced IIe and accelerated IIgs with both SmartPort and Disk ][ emulation, and the card works flawlessly. I'll test more and leave my feedback here.

Are you interested in comments on the user interface yet? I have two minor ideas but don't want to comment if you're planning UI changes already.

-Peter

[rich]

Yes, I am interested in all comments, including the UI. Feel free to start new threads in this forum.
Nothing is off limits for discussion.

-Rich

[rich]

Well I wasn't at KFest but someone who was FedExed me one of the beta cards. I'm having a problem with mounting images read/write. Is writing supported in the current firmware? (I have b3.) Any attempt to copy files or SAVE or BSAVE new files results in an I/O error. This happens with several different disk images, including the official Beagle Bros Pronto-DOS disk and a hard drive image running ProDOS 2.0.3.

Writing is supported on all images types including .nib.
The only way to disable writing is to set the write protect attribute on the image file or to set the write protect bit inside a 2mg file. If neither of those are set, then the file is write enabled by default. A manual write protect feature is coming but no done yet.

If you want to send me an image file for me to test, send it to rich@dreher.net, and I will take a look.
In general start with a simple image file like a DOS system master and see if that works. You can also get into the
debug section of the card by pressing <CTRL> D in the menu. Once there, go to the log and look for something abnormal.
You should be able to save the log to CF or USB and send it to me. To increase the verbosity of the log, flip dip-switch three
down. Also do you have the preliminary docs I send out?

-Rich

[f8dy]

OK, I bought a new USB flash drive and transferred my disk images onto it, and the CFFA3000 is performing as expected. Yay! I'm willing to chalk it up to bad media, although it is strange that I was able to write to both of my other flash drives on modern operating systems. Perhaps I shouldn't trust them!

For the record, here are the symptoms I experienced with all the media I have tried so far:

1 GB flash drive, formatted as FAT-16/MBR: frequently was not recognized on cold boot. I had to unplug and plug it back into the CFFA3000 to get it to be recognized at all. Disk images of all flavors would load but would be read-only; any attempt to SAVE or BSAVE would result in an "I/O Error".

32 GB flash drive, formatted as FAT-32/MBR: sometimes was not recognized on cold boot. Again, I would have to unplug it and plug it back in. Disk images with longer than 8.3 filenames would show up with MSDOS-under-Windows-style filenames, for example, OLDTIM~1.po. CFFA3000 appears to have created a mystery 0-byte file called USBC3 (no idea why), which would show up in the list of disk images but be unreadable. I frequently could not select disk images to add to the SmartPort list. When I did, I could boot from them but they would be read-only. Any attempt to SAVE or BSAVE would result in an "I/O Error". CFFA3000 frequently "lost" the media; rebooting into configuration mode, it would claim that the media was unformatted (untrue). A cold reboot would get the CFFA3000 to recognize the media again, albeit temporarily.

4 GB flash drive, formatted as FAT-32/MBR: CFFA3000 recognized the drive reliably, even on cold boot, but would boot to a BASIC command prompt instead of auto-booting the first drive listed in the SmartPort list. Typing "PR#7" would boot the first drive image to the "ProDOS" loading screen, then hang. At that point, the computer was completely hosed; breaking into the monitor and trying to enter the CFFA configuration mode with "C730G" would simply hang.

Same 4 GB flash drive, formatted as FAT-16/MBR: everything appears to be working normally. I have two hard drive images loaded in the SmartPort list. The first autoboots, even on cold boot, and writing work properly from BASIC, Merlin, and Copy ][+ 9.1.

I have replicated these results on 3 different enhanced Apple //e computers -- one with a ZipChip 8000, one with a ZipChip 4000, and one unaccelerated. (Yes, I have too much hardware.) I have tried with and without other cards, including stripping one computer down to nothing but an 80-column card. The things that appear to affect CFFA3000 are (a) choice of media, (b) choice of FAT16/FAT32 disk formatting of the USB media, and (c) naming of disk images on the USB media.

Hope this helps.

[dlyons]

CFFA3000 seems to have trouble writing to certain USB drives, and I'm hoping that when I update to the latest "LUFA" USB-stack release those will be solved.

But if the same drive works as FAT16 but not FAT32, that would be a different issue. If convenient, try to determine whether the problem also occurs with Compact Flash. But note that any problem with FAT16 vs FAT32 could very well be influenced by the exact pattern of file writes, resulting in differing fragmentation of the disk image files.

In the CFFA3000 menus, there is a cryptic indication of how many contiguous chunks a chosen disk-image file occupies on the FAT disk. It's in (Ctrl-D) Debug > FAT Status, when it says "[ext: n]" that's the number of "extents" occupied by the file. If it says 0, the CFFA hasn't tried to access that disk image yet, so it hasn't cached the extents.

I don't know of any bugs with CFFA's handling of fragmented files, but if there are any lurking we need to uncover them.

--Dave, The Firmware Guy

[a2fan]

Can the firmware upgrades be read off the USB flash drive instead of the CF card? Just asking, because the flash drive is the device more likely to be extended outside the machine.

[bhtooefr]

Very minor, low priority feature request: Real timestamps on the FAT filesystem. In 2011, you'd really only have to support the No-Slot Clock and the IIGS clock.

[dlyons]

Two-part answer for upgrading from USB:
(1) Firmware updates have to come from the CF card for technical reasons (the bootloader is limited to 8K of code).
(2) If a CF card is present (FAT formatted, not raw partitions), we could watch for an upgrade to be available on USB, and automatically copy it to CF and then upgrade from there.

FAT timestamps: Noted. The case where it will break down is if you boot from another slot and only access the CFFA3000 as a Disk II -- then no 6502 code runs from the CFFA3000, so it won't have a chance to get the time from the Apple II. The other cases seem do-able.

--Dave

[bhtooefr]

Another low priority request, and you guys might already have this planned, although if you don't, it might need a CPLD update...

Have it so pushing both buttons on the remote drops into the CFFA menu, from whatever you're doing. This actually is possible, see the Wildcard, although doing it elegantly and safely (saving the screen mode, etc., etc.) would require a lot more, I do believe.