[Coco] Just another peek...

[Dave Philipsen]

That's another idea to consider.  I can see the utility of being able to 
pull the card from your DE1 and plug it into a PC or card reader and 
swap / add / read / delete files.

I'm pretty sure most SD cards do 'wear leveling' behind the scenes so 
that the operating system (whether it be Windows, DOS, OS9, DECB) 
doesn't have to keep track of all of that stuff.  Even if you do low 
level access (which is what the operating systems are doing) the SD card 
automatically does the wear leveling to keep you from wearing it out too 
quickly.

Thanks for your input.  It's definitely an option to consider.

Dave



On 2015-10-09 19:59, S Klammer wrote:
> I would agree with you Mark.  It is my understanding that most flash 
> memory
> has a finite number of writes... wouldn't this low level 
> partioning/sector
> be detrimental and bypass and internal safeguards of the memory device?
> 
> If I was doing this, and I'm not technically able to, I'd look at using
> something which would emulate FD/HDD access to a file (DSK, VHD) on the
> memory device... aka the CocoSDC.  This would permit ease of backup,
> maintenance of those (multiple) images on a non-Coco device, without 
> the
> need for 'extra' drivers.  Darren's additions to DEB allow DEB to
> view/change which image is applied to which floppy drive being 
> emulated...
> nothing else is changed from the Coco's viewpoint.
> 
> (I'm not saying to stop what work is being done with the CocoFPGA, just
> that I might consider a different course)
> 
> Shain
> On Oct 9, 2015 8:39 PM, "Mark McDougall" <msmcdoug at iinet.net.au> wrote:
> 
>> On 10/10/2015 7:32 AM, Dave Philipsen wrote:
>> 
>> My guess is that we'll have the DE1 booting from the SD card in fairly
>>> short order but it could be some months as I have not found any other
>>> volunteers as of yet to help on the coding and my time is a little
>>> stretched right now.
>>> 
>> 
>> My $0.02 worth...
>> 
>> You're really going about this ass-backwards and creating more mess 
>> and
>> confusion along the way. We don't NEED more media support in software, 
>> it's
>> only going to muddy the already muddy waters.
>> 
>> You should be looking at making the FPGA do the heavy lifting via 
>> hardware
>> emulation. My Coco 1/2 implements the 'standard' Cloud9 IDE interface 
>> via
>> the opencores OCIDE controller core. That interfaces directly to a CF 
>> card,
>> for example. I've got read support working on the SD card - not via 
>> any
>> convoluted driver quasi hardware setup - but via a back-end interface 
>> that
>> make the SD card look/act like disk media on the back end of an IDE
>> controller. Not 1 byte of additional software/ROM required.
>> 
>> The coco is already confusing with FD-50X, Super/GlensideIDE, 
>> Drivewire
>> and CocoSDC hardware. Add DECB, (Nitr)OS9, HDBOS and Drivewire 
>> software,
>> and it's becoming unmanageable. Now you want to add SD card support in
>> software as well, across DECB and NitrOS9? That's just nuts!
>> 
>> Regards,
>> 
>> --
>> |              Mark McDougall              | "Electrical Engineers do 
>> it
>> |  <http://members.iinet.net.au/~msmcdoug> |   with less resistance!"
>> 
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> https://pairlist5.pair.net/mailman/listinfo/coco
>>