[Coco] Howto for Altera DE1?

Aaron Wolfe aawolfe at gmail.com
Mon Jul 5 21:01:24 EDT 2010


On Mon, Jul 5, 2010 at 9:21 AM, Steven Hirsch <snhirsch at gmail.com> wrote:
> On Sun, 4 Jul 2010, Aaron Wolfe wrote:
>
>> On Sun, Jul 4, 2010 at 4:32 PM, Lothan <lothan at newsguy.com> wrote:
>>>
>>> Wouldn't it be better to use a dynamically-sized array or perhaps
>>> List<DWDiskSector> than allocating the maximum theoretical disk size for
>>> each image? If you use an array, you'll have to calculate the size of the
>>> array prior to allocation. If you use a List<DWDiskSector>, the array can
>>> be
>>> allocated on the fly as you add items to the list.
>>>
>>
>> It's been a while...  IIRC the reason I didn't use a dynamic sized
>> type is that the CoCo can request or write to any sector at any time,
>> and there didn't seem to be any elegant way to do sparse arrays...
>> maybe a hash on sector number would work.  There may be other reasons
>> that I'm not remembering, of course a List would be much nicer so I'm
>> hoping I had a good reason not to use it :)  I will revisit this
>> entire section at some point.
>
> Why not an array of references to (lazily) heap-allocated sector buffers? If
> the sector is never accessed you only waste one pointer per image sector.
>  Worst case, you'll be slightly worse off than the current architecture.
>

yes, that would be the way to do it.  in Java, things aren't quite as
simple as that.. everything is a pointer yet nothing is a pointer :)
there should be a way to do such a thing nonetheless.  feel free to
take a shot at it.


> I understand the point in your earlier note about remote images, but
> hopefully these would tend to be small and could continue to be read in
> their entirety up front.
>

remote images will always have to be cached locally, whether in memory
or a temp file, since we don't have random access.  we would have to
read the entire object each time a sector was requested otherwise :(
I knew the current scheme wasn't great, but I guess no one has tried
to mount such a large disk before, or they just didn't mention it to
me.  5MB is the biggest image I use here.

> Steve
>
>
> --
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>



More information about the Coco mailing list