[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CFFA3000 Video Posted
On 7/21/2011 1:39 PM, Jayson Smith wrote:
Wow, good description! Now, a few more questions. Is there any way to swap
out disk images while a program is running, in other words, without
rebooting?
Rich is developing an outboard switch mechanism with two switches that
lets you rotate through a list of disk images for each drive. So each
time you press a button, the next disk in the series gets inserted.
Exactly how that works hasn't been decided or coded yet, but the
capability is engineered into the card and the switches are being produced.
In another life, I mess with Commodore equipment. There's a device in
that world (http://www.c64-wiki.com/index.php/SD2IEC) that lets you
concoct a text file that lists disk images by specifying the path on the
memory device to each. That way, the user doesn't have to interact with
menus at all - just create the file and copy it to the device. Pushing
a button selects the next image in your file. Now, things are much
simpler in that world because there is only one memory device (the SD
card) and only one logical drive is presented to the computer. I
believe a solution like this would be suitable in the CFFA3000 scenario
too, but it remains to be seen if it can be incorporated.
Also, is there by chance a way to access the device
settings E.G. disk assignments, etc. through a program after the system is
booted?
It seems like any program that can interrogate ProDOS volumes could do
that. Such a program could display what volume names are associated
with what slots and drives. Do you have something that does that today?
I gather
you can't select the virtual disk drive and actually type in the name of the
disk image to mount there? That would be very nice for us blind folks,
rather than or in addition to a menu where you might not know how many
arrows to hit to get to the particular image.
I agree, the menu system is very visual in nature. That's why the
file-based mounting seems like a good bridge. But again, I don't know
how or if that fits into Rich's plans.
A totally off-the-wall suggestion here, but I don't assume the boot menu is
located on a 'fake' disk image with DOS 3.3 or ProDOS as its OS? If it were,
at least partial accessibility might be possible by having that image load
Textalker.
I am working on a way to at least dump out the menu hierarchy in text
form. It wouldn't be live; it would just be the map of what text is on
the screen in a default configuration. As I had mentioned in Rich's
forum, I lobbied for and got a memory dump capability, which deposits
memory from $400 to $7ff into a file. I can post-process that file and
extract the text from it. It would be entirely too clumsy to do in real
time, but at least it enables us to take snapshots of things.