Re: disk image emulator on the GS - possible?

["Charlie" <charlieDOTd@verEYEzon.net>]

"schmidtd" <schmidtd@my-deja.com> wrote in message 
1a310a49-5be7-476d-a3ec-4468c38613ff@h8g2000yqm.googlegroups.com">news:1a310a49-5be7-476d-a3ec-4468c38613ff@h8g2000yqm.googlegroups.com...
> On Jul 1, 1:44 pm, "Charlie" <charlieD...@verEYEzon.net> wrote:
>> "nyder" <nyder...@gmail.com> wrote in message
>>
>> So any code written to use disk images in a GS would have to 
>> determine
>> what format the image is (it can't just look at the file extension) 
>> and
>> it would have to determine if there was enough memory available to
>> handle the image.  A 2mg, .po, or .hdv image *can* be just under
>> 32MBytes.
>
> And that's exactly the approach that emulators, CiderPress, FishWings,
> AppleCommander, ADT, and ADTPro, and the like take - they analyze the
> disk contents, make a determination about that the format is,
> translate it to a normalized form, and then use it, transmit it,
> present it, or save it to something else.

Agreed.

>
> Lacking imagination, my solution is to keep those translation tools in
> place, and have a transmitter send normalized disk image contents into
> a RAM (or physical!) disk.

That sounds like a good idea since it builds on what we already have but 
I felt the original poster wanted the GS to handle the emulation of a 
disk image.

> I now see having functionality on the GS
> end that could do its own interpretation of a raw image and "mount" it
> so the OS can see it.  But as you point out, that pre-supposes you
> have an even-larger device online that can house the image in the
> first place, as well as memory to host the interpreted image.

The more I think about it the more complicated it gets. (or maybe its 
just me making problems where none exists :-)
For instance, I envision a program running on the GS that would emulate 
the booting of the image and then turning over the actually running of 
the programs on the disk image to the GS hardware.  Reading and writing 
to the image would have to be diverted from the hardware back to the 
image emulator.  If the image was loaded completely into RAM then some 
mechanism would be needed to ensure that data written to the image 
wouldn't be lost when the program quits.

Charlie