dreher.net

CFFA3000 Customers,

If you have ideas for new features for the CFFA3000 firmware please add them to this thread.
I will start the list with a couple features that are already planned:

1) Subdirectory support.
2) Greater then 256 image file limit per device.


Thanks,
-Rich

Firmware upgrades from USB (or auto-copy them from USB to CF) would be nice.

Copying disk images (or folders, recursively) between CF and USB would really help us avoid opening our machines unnecessarily.

Supporting disk swapping on the smart port would help for those unusual IIgs programs that look for disks by device and not by label.

Saving and reloading of configuration would be nice to quickly swap between software.

Rich,

Alter the order of images mounted, without deleting it, in smartport option.

Regards,

Leandro

Am absolutely loving my CFFA3K, but had a suggestion for the screen for importing from disk to USB/CF.

I've had some disks that are having trouble at different parts, and I see some of them report that a certain track couldn't be read - perhaps instead of a row of "all-the-same" asterisks, there could be something to indicate which tracks had trouble (because the report of the problem can scroll off the screen).

Also, maybe some ticks or indicator of the track numbers.

So the end result (with tracks 7 and 17 failing to be read) would look like:

Code: Select all

   |******-*********-*****************|   
   0    '    1    '    2    '    3
   0         0         0         0

or to save a line of output:

Code: Select all

   |******-*********-*****************|   
   |    '    |    '    |    '    |    '

The more I look at it, the more I prefer the latter.

Not sure if it'd be possible to also save a log for disks that didn't work (tracks/sectors which didn't work, number of attempts, etc.) - I'd suggest diskname.log, but it is possible to write a different disk image to a previously abandoned name - maybe concatenated if the .log file already exists. I'm sure cleverer people than me could figure out a mechanism for that. Only just thought of the log file (whereas I've been thinking of the above indicators all day), not sure how useful it might be.

Might have more suggestions later :)

Sean

I'd lump my requests under "file management"...

You've covered part of it by adding sub-directories, and increasing the file limit.

I'd also chime in that having an ability to copy between USB and CF would be awesome, and time saving.

I'd also vote for the ability to at delete files from the USB and CF devices. Example - while experimenting, I'd create a largish ProDOS volume on the CF card, but have to remove the card and move it back to the Mac in order to delete the file afterwards.

Finally - if there was the ability to add/delete folders, and even perhaps move files around, I don't think you'd ever need to pull your CF card at all...

Hi Rich, I was looking to see what opportunities there might be to extend the CFFA3000 via firmware or hardware.

For example

1) Is it possible to access CF/IO cards via the CF port?
2) How much room is left in the AT90USB1287 for additional code for supplementary function?
3) Can other USB devices be accessed via the USB port directly or via a HUB. I understand this relates to item number 2 above as well.

Glenn

>1) Is it possible to access CF/IO cards via the CF port?

I'm not sure what sort of cards you're referring to. Are there some specific ones? The hardware should be able to talk to anything that uses ATA parallel I/O, at least. For something more out of the ordinary, I'd have to look into it.

>2) How much room is left in the AT90USB1287 for additional code for supplementary function?

Currently (v3.0.1) there is about 13.5K free, out of 120K available for the main code (8K is for the bootloader that allows firmware updates). But there are various ways to free up some of the space when needed: Reducing the amount of Debug code and Debug logging; compressing UI text; rewriting portions in assembly in some cases; and just generally trying hard to optimize the C code for size.

>3) Can other USB devices be accessed via the USB port directly or via a HUB. I understand this relates to item number 2 above as well.

The CFFA software doesn't currently support any devices other than a Mass Storage class device, and the LUFA USB stack we're using does not currently offer support for hubs. But the hardware should be fine -- it's "a small matter of programming," plus managing complexity of the UI.

Cheers,

--Dave

Also, the source is closed at this time. I would like it to be open at some point.
But that time still hasn't arrived yet. Not sure when that will be.

-Rich

Hi Dave, thanks for the reply.

[quote="dlyons"] >1) Is it possible to access CF/IO cards via the CF port?

I'm not sure what sort of cards you're referring to. Are there some specific ones? [/quote]

Yes I was thinking specifically wifi CF/IO cards. They are getting kind of hard to find these days and there are better alternatives for embedding in a project but I was just curious. Then on second thought it's probably not workable anyway as the Antenna is to big and the cover would not close.

[quote="dlyons"] The hardware should be able to talk to anything that uses ATA parallel I/O, at least. For something more out of the ordinary, I'd have to look into it.

>2) How much room is left in the AT90USB1287 for additional code for supplementary function?

Currently (v3.0.1) there is about 13.5K free, out of 120K available for the main code (8K is for the bootloader that allows firmware updates). But there are various ways to free up some of the space when needed: Reducing the amount of Debug code and Debug logging; compressing UI text; rewriting portions in assembly in some cases; and just generally trying hard to optimize the C code for size. [/quote]

Okay good to know

[quote="dlyons"] >3) Can other USB devices be accessed via the USB port directly or via a HUB. I understand this relates to item number 2 above as well.

The CFFA software doesn't currently support any devices other than a Mass Storage class device, and the LUFA USB stack we're using does not currently offer support for hubs. But the hardware should be fine -- it's "a small matter of programming," plus managing complexity of the UI.

Cheers,

--Dave[/quote]

Okay thanks for the info

Glenn

[quote="rich"]Also, the source is closed at this time. I would like it to be open at some point.
But that time still hasn't arrived yet. Not sure when that will be.

-Rich[/quote]

Hi Rich, I hope you don't mind me asking every once in a while. :)

Glenn

I'll echo all the file management requests - sub-directories, copy (and copy between USB to and from CF), move, delete - and to add a new one - rename.

I have a USB extender cable so that if I need to add files, I can plug a USB flash drive into that rather that popping the top off or using serial transfers, but it would be nice to be able to copy from USB to the CF.

I have just figured out a kludge to copy disk images to/from CF & USB.

For USB to CF
Mount the desired images on the virtual Disk II from the USB drive.
Import the disk image to the compact flash.

It's slower than a 'select all these and copy', but it's making backing up my files from the CF and importing new ones to it much easier - and I no longer have to open the box.

rich wrote:CFFA3000 Customers,

If you have ideas for new features for the CFFA3000 firmware please add them to this thread.
I will start the list with a couple features that are already planned:

1) Subdirectory support.
2) Greater then 256 image file limit per device.


Thanks,
-Rich

Would IWM emulation be on the cards for full support of the 3.5" drive on the IIGS? Or is that something best left to the CFFA4000? :-)

- Alex

alelee wrote:Would IWM emulation be on the cards for full support of the 3.5" drive on the IIGS? Or is that something best left to the CFFA4000? :-)

My personal opinion is that it would be very low ROI - there was so little software written targeting that hardware. And I haven't seen anything beyond those few demos that has done so before or since.

Would there be a possibility to add the floppy drive emulation to take over the native apple /// controller. This would be a really nice feature to have. The CFFA card does this for the A2 emulation, but not for the normal A3 disk operations.

/Rob

Hello! I just acquired a //gs, and it needs storage! Already asked to be included in the list for batch #3.

My feature suggestion is: space for more RAM. So the CFFA could also expand the //gs to 1M / 2M / 4M. Would that be at all possible?

Juan

JCCyC wrote:Hello! I just acquired a //gs, and it needs storage! Already asked to be included in the list for batch #3.

My feature suggestion is: space for more RAM. So the CFFA could also expand the //gs to 1M / 2M / 4M. Would that be at all possible?

Juan

Probably not, and even if it were possible the card would need to be redesigned.

For the memory to be recognized in the IIgs, the card would need to be installed in the memory expansion slot, which is different from the other 7 slots. Older memory cards that worked in the IIe could go into one of the other 7 slots, but their memory would not be seen as "IIgs" memory and therefore would not be available to GS/OS programs.

You can still buy new memory cards for the IIgs.

http://www.brielcomputers.com/wordpress/?cat=22

http://16sector.com/shop/a2ram/sirius-ram-iigs-w8mb/

I have worked in professional software development and engineering for many years, and would be interested in reasonable means by which I can use CFFA to test FPGA code development (not necessarily very interested in viewing your own sources ;-/)...

David

I'm not sure what you're looking for here...is the CPLD on the CFFA3000 similar enough to some FPGA you want to target that the CFFA3000 would make a good testbed?

--Dave