Sorry if this question has been asked before, I tried seaching, but kept getting stuff for the SVD or emulators.
Just wonder how possible is a disk image emulator for the GS?
I figure you need 2 megs of space for the biggest images, which is very possible with ram cards.
would the overhead be too much?
It's just it seems a lot of disk are in the 2mg format, and it seems currently you have to use emulators to convert them into something readable by the GS. So it got my wondering why someone hasn't made one before. I know I can't be the first person to think of it. so it must be some hardware limitation or something.
Anyways, thanks for listening, and if this is a stupid question, i'm ready for some stupid answers. lol
On Jul 1, 8:22 am, nyder <nyder...@gmail.com> wrote:
> Just wonder how possible is a disk image emulator for the GS?
Do you mean like the RAM disk that's built into the GS control panel?
> It's just it seems a lot of disk are in the 2mg format, and it seems > currently you have to use emulators to convert them into something > readable by the GS.
Well, the 2mg needs to be stripped of its 2mg header, but that's about it. The raw disk data can then be loaded on a physical (or RAM) disk by any of a number of file or disk transfer methods. What do you want to do, exactly?
> Sorry if this question has been asked before, I tried seaching, but > kept getting stuff for the SVD or emulators.
> Just wonder how possible is a disk image emulator for the GS?
> I figure you need 2 megs of space for the biggest images, which is > very possible with ram cards.
> would the overhead be too much?
Possibly, depending on how many of the disk image formats you want to support and how robust you want that support to be. There are quite a few disk image formats and some allow almost anything in the image. Even the 2mg format has documented support for 3 types of images and there have been less well documented attempts to add more image types. 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. I believe all of this can be done if you don't expect it to handle everything. I'm not sure it's worth the effort though.
>> Just wonder how possible is a disk image emulator for the GS? > Do you mean like the RAM disk that's built into the GS control panel? >> It's just it seems a lot of disk are in the 2mg format, and it seems >> currently you have to use emulators to convert them into something >> readable by the GS. > Well, the 2mg needs to be stripped of its 2mg header, but that's about > it. The raw disk data can then be loaded on a physical (or RAM) disk > by any of a number of file or disk transfer methods.
The 2mg format supports at least 3 types of data, including nibbles. Just stripping off the header and loading the data into a RAM disk *may* work as a quick and dirty method but I wouldn't advise doing this as a regular way to use 2mg images. Also the 2mg format allows for comments anywhere in the image. Although I've never seen an image that used this feature, it wouldn't surprise me to find one.
> 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.
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. 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.
I like that post, I worked on such a IIgs thing in January 2009 in order to mount CBM D64 images.
The objective is to double-click a disk image (DSK, PO) and thanks to the IPC thing in a PIF, load the file into memory, perform the necessary checks and add it into the list of devices.
What is interesting is that the driver is responsible for the different block reads and writes or inits and that's all, the rest of the job is performed by the FSTs.
I developed that new driver with my source code of the RAM5 (works with the RAM but is firmware related) and ensoniqRAM (not hardware related) drivers but I failed as I am still unable to simulate the disk insertion or ejection which would update the device list, even with the help of the different GS/OS books.
If one understands that notion (how to mount/unmount a device), please contact me and I will finish that one during my summer vacation,
> 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.
On Jul 1, 4:24 pm, "Charlie" <charlieD...@verEYEzon.net> wrote:
> 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.
On the face of it, this all sounds a lot like the Mac works with .dmg images - it makes them mountable and then visible to the filesystem. No problem, if reading files is our goal. But if the OP wants to _boot_ off of them, we have a whole other kettle of fish. :-)
schmidtd wrote: > On the face of it, this all sounds a lot like the Mac works with .dmg > images - it makes them mountable and then visible to the filesystem. > No problem, if reading files is our goal. But if the OP wants to > _boot_ off of them, we have a whole other kettle of fish. :-)
The quick and dirty way of doing this is to make a RAM disk the same size as the image (normally 800k for the IIgs), formatting it (to write the boot blocks), and then writing the 2mg file with DiskMaker to the RAM disk. This of course won't work with demos because they expect to run off a real 800k disk being controlled by the IWM chip.
> I like that post, I worked on such a IIgs thing in January 2009 in > order to mount CBM D64 images.
> The objective is to double-click a disk image (DSK, PO) and thanks to > the IPC thing in a PIF, load the file into memory, perform the > necessary checks and add it into the list of devices.
> What is interesting is that the driver is responsible for the > different block reads and writes or inits and that's all, the rest of > the job is performed by the FSTs.
> I developed that new driver with my source code of the RAM5 (works > with the RAM but is firmware related) and ensoniqRAM (not hardware > related) drivers but I failed as I am still unable to simulate the > disk insertion or ejection which would update the device list, even > with the help of the different GS/OS books.
> If one understands that notion (how to mount/unmount a device), please > contact me and I will finish that one during my summer vacation,
> antoine
Hi Antoine,
I'm really glad you jumped into this discussion since I feel I was getting in way over my head. It seems you are very close to what the original poster wanted.
First I have to say that I've never done any device driver programming for the Apple IIgs. Since I don't want anyone to think I would let my ignorance stop me from posting I'll ask if you have tried using the system service call SET_DISKSW which is supposed to notify GS/OS that a disk switched or is in an off-line condition. If I understand the description of the call (page 283 of the device driver reference) drivers can request a change in the disk switched status which is maintained by the device dispatcher. I believe the device dispatcher is responsible for the device list.
Anyway the description sounds a lot like what you want so I had to ask.
Charlie wrote: > Also the 2mg format allows for comments > anywhere in the image. Although I've never seen an image that used this > feature, it wouldn't surprise me to find one.
That sounds like a *terrible* idea.
A disk image is a regular structure that can be indexed into. Interpolating "comments" demands sequential reading for a negligible value.
This "feature" should be removed from the .2mg "standard".
If the comments are part of the header, they would make it a variable-length header, which is also a big downside for a small upside.
The only "minimally-distruptive" way to add comments to an image would be to suffix them--and even that makes the size of an image vary, which most would interpret as an error.
> > I like that post, I worked on such a IIgs thing in January 2009 in > > order to mount CBM D64 images.
> > The objective is to double-click a disk image (DSK, PO) and thanks to > > the IPC thing in a PIF, load the file into memory, perform the > > necessary checks and add it into the list of devices.
> > What is interesting is that the driver is responsible for the > > different block reads and writes or inits and that's all, the rest of > > the job is performed by the FSTs.
> > I developed that new driver with my source code of the RAM5 (works > > with the RAM but is firmware related) and ensoniqRAM (not hardware > > related) drivers but I failed as I am still unable to simulate the > > disk insertion or ejection which would update the device list, even > > with the help of the different GS/OS books.
> > If one understands that notion (how to mount/unmount a device), please > > contact me and I will finish that one during my summer vacation,
> > antoine
> Hi Antoine,
> I'm really glad you jumped into this discussion since I feel I was > getting in way over my head. > It seems you are very close to what the original poster wanted.
> First I have to say that I've never done any device driver programming > for the Apple IIgs. Since I don't want anyone to think I would let my > ignorance stop me from posting I'll ask if you have tried using the > system service call SET_DISKSW which is supposed to notify GS/OS that a > disk switched or is in an off-line condition. If I understand the > description of the call (page 283 of the device driver reference) > drivers can request a change in the disk switched status which is > maintained by the device dispatcher. I believe the device dispatcher is > responsible for the device list.
> Anyway the description sounds a lot like what you want so I had to ask.
> Charlie
Thanks for your help, I appreciate. SET_DISKSW requires a device number which I do not have as I need to let it be set by the device dispatcher.
Then, I have had an idea: browse the contents of your Apple II Developer CDs and the answer is to be found here: cd1 / System 6.0 sample code / System 6 pieces / SCSI.Drivers / SCSI Driver Mgmt
The way the Apple SCSI driver works is described hereafter: have a default empty Device Independent Block and set it as not HW related. That's all.
When a DStatus or DInfo is performed, control is passed to a routine (unit_state) which creates DIBs dynamically depending on the physical / logical volumes present on the device.
Consider now that we are in the FinderExtension, we have just double- clicked the disk image we want to add to the system, we need to tell our driver that a new device (then volume if recognized) must come online. That can be done of two different ways: - call a subcall to the driver and tell it to add the volume and make it online (if not already in the devices) - perform like IR from M. Deatherage does: InitialLoad2 a new driver, set the interesting values and call it
And the volume will come online because of the SET_DISKSW call that will be performed!
> > Also the 2mg format allows for comments > > anywhere in the image. Although I've never seen an image that used this > > feature, it wouldn't surprise me to find one.
> That sounds like a *terrible* idea.
> A disk image is a regular structure that can be indexed into. > Interpolating "comments" demands sequential reading for a > negligible value.
> This "feature" should be removed from the .2mg "standard".
> If the comments are part of the header, they would make it a > variable-length header, which is also a big downside for a > small upside.
> The only "minimally-distruptive" way to add comments to an > image would be to suffix them--and even that makes the size > of an image vary, which most would interpret as an error.
Quite right. It looks like the (optional) comment is found after the disk image data itself.
> > > I like that post, I worked on such a IIgs thing in January 2009 in > > > order to mount CBM D64 images.
> > > The objective is to double-click a disk image (DSK, PO) and thanks to > > > the IPC thing in a PIF, load the file into memory, perform the > > > necessary checks and add it into the list of devices.
> > > What is interesting is that the driver is responsible for the > > > different block reads and writes or inits and that's all, the rest of > > > the job is performed by the FSTs.
> > > I developed that new driver with my source code of the RAM5 (works > > > with the RAM but is firmware related) and ensoniqRAM (not hardware > > > related) drivers but I failed as I am still unable to simulate the > > > disk insertion or ejection which would update the device list, even > > > with the help of the different GS/OS books.
> > > If one understands that notion (how to mount/unmount a device), please > > > contact me and I will finish that one during my summer vacation,
> > > antoine
> > Hi Antoine,
> > I'm really glad you jumped into this discussion since I feel I was > > getting in way over my head. > > It seems you are very close to what the original poster wanted.
> > First I have to say that I've never done any device driver programming > > for the Apple IIgs. Since I don't want anyone to think I would let my > > ignorance stop me from posting I'll ask if you have tried using the > > system service call SET_DISKSW which is supposed to notify GS/OS that a > > disk switched or is in an off-line condition. If I understand the > > description of the call (page 283 of the device driver reference) > > drivers can request a change in the disk switched status which is > > maintained by the device dispatcher. I believe the device dispatcher is > > responsible for the device list.
> > Anyway the description sounds a lot like what you want so I had to ask.
> > Charlie
> Thanks for your help, I appreciate. SET_DISKSW requires a device > number which I do not have as I need to let it be set by the device > dispatcher.
> Then, I have had an idea: browse the contents of your Apple II > Developer CDs and the answer is to be found here: cd1 / System 6.0 > sample code / System 6 pieces / SCSI.Drivers / SCSI Driver Mgmt
> The way the Apple SCSI driver works is described hereafter: have a > default empty Device Independent Block and set it as not HW related. > That's all.
> When a DStatus or DInfo is performed, control is passed to a routine > (unit_state) which creates DIBs dynamically depending on the > physical / logical volumes present on the device.
> Consider now that we are in the FinderExtension, we have just double- > clicked the disk image we want to add to the system, we need to tell > our driver that a new device (then volume if recognized) must come > online. That can be done of two different ways: > - call a subcall to the driver and tell it to add the volume and make > it online (if not already in the devices) > - perform like IR from M. Deatherage does: InitialLoad2 a new driver, > set the interesting values and call it
> And the volume will come online because of the SET_DISKSW call that > will be performed!
> Oh, I think I will enjoy my summer holidays!
> antoine
Cool, we look forward to seeing the results!
As an aside, for a relative newcomer to the IIgs (I got my 1st IIgs in 2006!), are the developer CD's with source code that you mentioned still available anywhere? I'd love to get my hands on these rather than trying to reinvent the wheel all the time. :-)
>> Also the 2mg format allows for comments anywhere in the image. >> Although I've never seen an image that used this feature, it wouldn't >> surprise me to find one.
> That sounds like a *terrible* idea.
:-)
> A disk image is a regular structure that can be indexed into. > Interpolating "comments" demands sequential reading for a > negligible value.
As I mentioned it may have never been done. I should explain that there is only one comment pointer and one creator data pointer in the header (and cooresponding length longwords). So at most there would be only two breaks in the disk data if someone was perverse enough to put it anywhere other than before or after the disk data.
> This "feature" should be removed from the .2mg "standard".
Well, it actually has been but quite a while after many 2mg images were already made. There are two slightly different 2mg format specs that I have seen and the later one specifically says that the comment and creator data chunks must come after the disk data.
> If the comments are part of the header, they would make it a > variable-length header, which is also a big downside for a > small upside.
Normally the header is 64 bytes long but there is a header length word in the header leading me to believe that the original intent was for it to be extensible.
> The only "minimally-distruptive" way to add comments to an > image would be to suffix them--and even that makes the size > of an image vary, which most would interpret as an error.
My intention wasn't to make it sound worse than it is (although I admit that's what I accomplished). It was just to make people aware that just chopping off a header isn't a good thing for a program to do if it wants to be reasonably robust. The header is there for a reason and it carries important information about itself as well as the original disk it was made from (write protect, volume number and data order). Even with its ambiguities I like the 2mg format. At least it is documented.
> In article <1OydnUMe6ZzUY9HXnZ2dnUVZ_gidn...@giganews.com>, > "Michael J. Mahon" <mjma...@aol.com> wrote:
>> Charlie wrote:
>> > Also the 2mg format allows for comments >> > anywhere in the image. Although I've never seen an image that used >> > this >> > feature, it wouldn't surprise me to find one.
>> That sounds like a *terrible* idea.
>> A disk image is a regular structure that can be indexed into. >> Interpolating "comments" demands sequential reading for a >> negligible value.
>> This "feature" should be removed from the .2mg "standard".
>> If the comments are part of the header, they would make it a >> variable-length header, which is also a big downside for a >> small upside.
>> The only "minimally-distruptive" way to add comments to an >> image would be to suffix them--and even that makes the size >> of an image vary, which most would interpret as an error.
> Quite right. It looks like the (optional) comment is found after the > disk image data itself.
Yes, that is version 1 of the 2mg format (documented by Eric Shepherd in 1999 I believe). It is the better of the two I've seen since it spells out where the comments and creator data should go. Unfortunately, there is an earlier version 0 (I believe documented by Thomas Fok who wrote Revival) of the format that does not define where the comments and creator data should go (I don't have a working link to that version any more). When writing a program to use a 2mg image you could look at the version number to determine whether you need to delve further into the structure of the file. Or you could just assume that nobody has ever put a comment in a stupid place. My luck, 5 minutes after I put such a program on the internet I'd get an email from somebody complaining about how my program couldn't read their 2mg files :-)
Thanks for your help, I appreciate. SET_DISKSW requires a device number which I do not have as I need to let it be set by the device dispatcher.
Then, I have had an idea: browse the contents of your Apple II Developer CDs and the answer is to be found here: cd1 / System 6.0 sample code / System 6 pieces / SCSI.Drivers / SCSI Driver Mgmt
The way the Apple SCSI driver works is described hereafter: have a default empty Device Independent Block and set it as not HW related. That's all.
When a DStatus or DInfo is performed, control is passed to a routine (unit_state) which creates DIBs dynamically depending on the physical / logical volumes present on the device.
Consider now that we are in the FinderExtension, we have just double- clicked the disk image we want to add to the system, we need to tell our driver that a new device (then volume if recognized) must come online. That can be done of two different ways: - call a subcall to the driver and tell it to add the volume and make it online (if not already in the devices) - perform like IR from M. Deatherage does: InitialLoad2 a new driver, set the interesting values and call it
And the volume will come online because of the SET_DISKSW call that will be performed!
Oh, I think I will enjoy my summer holidays!
antoine
-------------------------<
Yes, enjoy your holidays. It sounds like you are having fun already.
"Charlie" <charlieD...@verEYEzon.net> wrote: > "John B. Matthews" <nos...@nospam.invalid> wrote in message > news:nospam-39CE32.17130802072009@news.aioe.org... > > In article <1OydnUMe6ZzUY9HXnZ2dnUVZ_gidn...@giganews.com>, > > "Michael J. Mahon" <mjma...@aol.com> wrote:
> >> Charlie wrote:
> >> > Also the 2mg format allows for comments anywhere in the image. > >> > Although I've never seen an image that used this feature, it > >> > wouldn't surprise me to find one.
> >> That sounds like a *terrible* idea.
> >> A disk image is a regular structure that can be indexed into. > >> Interpolating "comments" demands sequential reading for a > >> negligible value.
> >> This "feature" should be removed from the .2mg "standard".
> >> If the comments are part of the header, they would make it a > >> variable-length header, which is also a big downside for a > >> small upside.
> >> The only "minimally-distruptive" way to add comments to an > >> image would be to suffix them--and even that makes the size > >> of an image vary, which most would interpret as an error.
> > Quite right. It looks like the (optional) comment is found after the > > disk image data itself.
> Yes, that is version 1 of the 2mg format (documented by Eric Shepherd in > 1999 I believe). It is the better of the two I've seen since it spells > out where the comments and creator data should go. Unfortunately, there > is an earlier version 0 (I believe documented by Thomas Fok who wrote > Revival) of the format that does not define where the comments and > creator data should go (I don't have a working link to that version any > more). When writing a program to use a 2mg image you could look at the > version number to determine whether you need to delve further into the > structure of the file. Or you could just assume that nobody has ever > put a comment in a stupid place. My luck, 5 minutes after I put such a > program on the internet I'd get an email from somebody complaining about > how my program couldn't read their 2mg files :-)
Interesting. I recall a 2mg image passing by recently; it appeared to be v1 in having a suffix comment. Andy McFadden puzzled it out for CiderPress, but I've misplaced the thread.
Charlie wrote: > Yes, that is version 1 of the 2mg format (documented by Eric Shepherd in > 1999 I believe).
Its sad that I remember the 1997 Usenet exchange on comp.emulators.apple2 between Josh Thompson (author of XGS) and Henrik Gudat (co-author of Bernie) creating that format. Prior to that, XGS and Bernie used separate proprietary formats to handle images. Revival II appeared shortly after that, I actually have a copy of an early release somewhere. I also have a program called FishWings, one of the first programs that allowed manipulating of files in 2img images.
> > > > I like that post, I worked on such a IIgs thing in January 2009 in > > > > order to mount CBM D64 images.
> > > > The objective is to double-click a disk image (DSK, PO) and thanks to > > > > the IPC thing in a PIF, load the file into memory, perform the > > > > necessary checks and add it into the list of devices.
> > > > What is interesting is that the driver is responsible for the > > > > different block reads and writes or inits and that's all, the rest of > > > > the job is performed by the FSTs.
> > > > I developed that new driver with my source code of the RAM5 (works > > > > with the RAM but is firmware related) and ensoniqRAM (not hardware > > > > related) drivers but I failed as I am still unable to simulate the > > > > disk insertion or ejection which would update the device list, even > > > > with the help of the different GS/OS books.
> > > > If one understands that notion (how to mount/unmount a device), please > > > > contact me and I will finish that one during my summer vacation,
> > > > antoine
> > > Hi Antoine,
> > > I'm really glad you jumped into this discussion since I feel I was > > > getting in way over my head. > > > It seems you are very close to what the original poster wanted.
> > > First I have to say that I've never done any device driver programming > > > for the Apple IIgs. Since I don't want anyone to think I would let my > > > ignorance stop me from posting I'll ask if you have tried using the > > > system service call SET_DISKSW which is supposed to notify GS/OS that a > > > disk switched or is in an off-line condition. If I understand the > > > description of the call (page 283 of the device driver reference) > > > drivers can request a change in the disk switched status which is > > > maintained by the device dispatcher. I believe the device dispatcher is > > > responsible for the device list.
> > > Anyway the description sounds a lot like what you want so I had to ask.
> > > Charlie
> > Thanks for your help, I appreciate. SET_DISKSW requires a device > > number which I do not have as I need to let it be set by the device > > dispatcher.
> > Then, I have had an idea: browse the contents of your Apple II > > Developer CDs and the answer is to be found here: cd1 / System 6.0 > > sample code / System 6 pieces / SCSI.Drivers / SCSI Driver Mgmt
> > The way the Apple SCSI driver works is described hereafter: have a > > default empty Device Independent Block and set it as not HW related. > > That's all.
> > When a DStatus or DInfo is performed, control is passed to a routine > > (unit_state) which creates DIBs dynamically depending on the > > physical / logical volumes present on the device.
> > Consider now that we are in the FinderExtension, we have just double- > > clicked the disk image we want to add to the system, we need to tell > > our driver that a new device (then volume if recognized) must come > > online. That can be done of two different ways: > > - call a subcall to the driver and tell it to add the volume and make > > it online (if not already in the devices) > > - perform like IR from M. Deatherage does: InitialLoad2 a new driver, > > set the interesting values and call it
> > And the volume will come online because of the SET_DISKSW call that > > will be performed!
> > Oh, I think I will enjoy my summer holidays!
> > antoine
> Cool, we look forward to seeing the results!
> As an aside, for a relative newcomer to the IIgs (I got my 1st IIgs in > 2006!), are the developer CD's with source code that you mentioned > still available anywhere? I'd love to get my hands on these rather > than trying to reinvent the wheel all the time. :-)
> Cheers, > Mike
Sorry, please disregard my previous comment regarding the developer CD's!
I just remembered that I have some of these CD's too thanks to the generous efforts of Paul R. Santa-Maria, and Willi who uploaded them to the Apple II Gmail account about 18 months ago. I really should go through these CD's when I get some free time....
> In article <fHc3m.511$P5....@nwrddc02.gnilink.net>,
> "Charlie" <charlieD...@verEYEzon.net> wrote: > > "John B. Matthews" <nos...@nospam.invalid> wrote in message > >news:nospam-39CE32.17130802072009@news.aioe.org... > > > In article <1OydnUMe6ZzUY9HXnZ2dnUVZ_gidn...@giganews.com>, > > > "Michael J. Mahon" <mjma...@aol.com> wrote:
> > >> Charlie wrote:
> > >> > Also the 2mg format allows for comments anywhere in the image. > > >> > Although I've never seen an image that used this feature, it > > >> > wouldn't surprise me to find one.
> > >> That sounds like a *terrible* idea.
> > >> A disk image is a regular structure that can be indexed into. > > >> Interpolating "comments" demands sequential reading for a > > >> negligible value.
> > >> This "feature" should be removed from the .2mg "standard".
> > >> If the comments are part of the header, they would make it a > > >> variable-length header, which is also a big downside for a > > >> small upside.
> > >> The only "minimally-distruptive" way to add comments to an > > >> image would be to suffix them--and even that makes the size > > >> of an image vary, which most would interpret as an error.
> > > Quite right. It looks like the (optional) comment is found after the > > > disk image data itself.
> > Yes, that is version 1 of the 2mg format (documented by Eric Shepherd in > > 1999 I believe). It is the better of the two I've seen since it spells > > out where the comments and creator data should go. Unfortunately, there > > is an earlier version 0 (I believe documented by Thomas Fok who wrote > > Revival) of the format that does not define where the comments and > > creator data should go (I don't have a working link to that version any > > more). When writing a program to use a 2mg image you could look at the > > version number to determine whether you need to delve further into the > > structure of the file. Or you could just assume that nobody has ever > > put a comment in a stupid place. My luck, 5 minutes after I put such a > > program on the internet I'd get an email from somebody complaining about > > how my program couldn't read their 2mg files :-)
> Interesting. I recall a 2mg image passing by recently; it appeared to be > v1 in having a suffix comment. Andy McFadden puzzled it out for > CiderPress, but I've misplaced the thread.
AppleCommander handled them incorrectly at first too; I got to repair that one as well.
schmidtd <schmi...@my-deja.com> wrote: > On Jul 2, 9:52 pm, "John B. Matthews" <nos...@nospam.invalid> wrote: > > In article <fHc3m.511$P5....@nwrddc02.gnilink.net>,
> > "Charlie" <charlieD...@verEYEzon.net> wrote: > > > "John B. Matthews" <nos...@nospam.invalid> wrote in message > > >news:nospam-39CE32.17130802072009@news.aioe.org... > > > > In article <1OydnUMe6ZzUY9HXnZ2dnUVZ_gidn...@giganews.com>, > > > > "Michael J. Mahon" <mjma...@aol.com> wrote:
> > > >> Charlie wrote:
> > > >> > Also the 2mg format allows for comments anywhere in the image. > > > >> > Although I've never seen an image that used this feature, it > > > >> > wouldn't surprise me to find one.
> > > >> That sounds like a *terrible* idea.
> > > >> A disk image is a regular structure that can be indexed into. > > > >> Interpolating "comments" demands sequential reading for a > > > >> negligible value.
> > > >> This "feature" should be removed from the .2mg "standard".
> > > >> If the comments are part of the header, they would make it a > > > >> variable-length header, which is also a big downside for a > > > >> small upside.
> > > >> The only "minimally-distruptive" way to add comments to an > > > >> image would be to suffix them--and even that makes the size > > > >> of an image vary, which most would interpret as an error.
> > > > Quite right. It looks like the (optional) comment is found after the > > > > disk image data itself.
> > > Yes, that is version 1 of the 2mg format (documented by Eric Shepherd in > > > 1999 I believe). It is the better of the two I've seen since it spells > > > out where the comments and creator data should go. Unfortunately, there > > > is an earlier version 0 (I believe documented by Thomas Fok who wrote > > > Revival) of the format that does not define where the comments and > > > creator data should go (I don't have a working link to that version any > > > more). When writing a program to use a 2mg image you could look at the > > > version number to determine whether you need to delve further into the > > > structure of the file. Or you could just assume that nobody has ever > > > put a comment in a stupid place. My luck, 5 minutes after I put such a > > > program on the internet I'd get an email from somebody complaining about > > > how my program couldn't read their 2mg files :-)
> > Interesting. I recall a 2mg image passing by recently; it appeared to be > > v1 in having a suffix comment. Andy McFadden puzzled it out for > > CiderPress, but I've misplaced the thread.
> AppleCommander handled them incorrectly at first too; I got to repair > that one as well.
> Charlie wrote: >> Yes, that is version 1 of the 2mg format (documented by Eric Shepherd >> in 1999 I believe).
> Its sad that I remember the 1997 Usenet exchange on > comp.emulators.apple2 between Josh Thompson (author of XGS) and Henrik > Gudat (co-author of Bernie) creating that format. Prior to that, XGS > and Bernie used separate proprietary formats to handle images. Revival > II appeared shortly after that, I actually have a copy of an early > release somewhere. I also have a program called FishWings, one of the > first programs that allowed manipulating of files in 2img images.
Interesting thread. That was just before I discovered emulators and for that matter newsgroups. I bought my first PC in 1997. Before that it was all Apple II.
By the way, I'm *very* familiar with FishWings :-)
> Sorry if this question has been asked before, I tried seaching, but > kept getting stuff for the SVD or emulators.
> Just wonder how possible is a disk image emulator for the GS?
> I figure you need 2 megs of space for the biggest images, which is > very possible with ram cards.
> would the overhead be too much?
> It's just it seems a lot of disk are in the 2mg format, and it seems > currently you have to use emulators to convert them into something > readable by the GS. So it got my wondering why someone hasn't made > one before. I know I can't be the first person to think of it. so it > must be some hardware limitation or something.
> Anyways, thanks for listening, and if this is a stupid question, i'm > ready for some stupid answers. lol
> thanks
On Saturday, 8/AUG/2009, @ 5:54 PM (Paris time), my answer is: YES, a disk image emulator for the GS is possible. I have one ;-) Genesys, a resource editor, works like a charm from my virtual disk image driver (.com)
The code is quite clean but there are things remaining to do (do not restrict to 800KB ProDOS 2MG disk images ;-) As I do not have my Mac with me, I cannot upload things easily on our website. That will leave me some time to code the remaining stuff...
|
