Disk images sites (other than Asimov)
Gérard Imbert
I'm looking for some games I cannot find over there, and all my searches for
alternate sites have ended in pages with not very much disks (at least
compared the Asimov ftp). Someone knows where another good ftp site can be
located ?
Rubywand
When it comes to old commercial 8-bit titles in disk image form Asimov
offers by far the best collection. You can't quite say "If it isn't on Asimov,
it isn't"; but, if you did, you would almost always be right.
One part of Asimov which sometimes gets overlooked is the File Based area
at ftp://ftp.apple.asimov.net/pub/apple_II/images/games/file_based/ .
The file_based/ folder features disk images which have several games each.
Many games are here which are not available on separate single-game disk images.
If you are viewing the page under Netscape, you can click "Edit" and do a "Find
in page" search for all or part of the game title you're looking for.
For other sites which might have what you want, see the listings in the
Csa2GAMES.txt folder at one of the following:
Ground offers pure Text for downloading or Viewing via
an FTP program ...
ftp://ground.ecn.uiowa.edu/apple2/Faqs/
Text on the ACN Florida, ACN Tarnover, and USA2WUG sites is
line-length formatted for on-line perusing via Netscape, etc. ...
ftp://24.96.48.134:6502/Cabi_Archives/FAQs.and.INFO/A2.Csa2.FAQs/
ftp://tarnover.dyndns.org/cabi/FAQs.and.INFO/A2.Csa2.FAQs/
http://www.grin.net/~cturley/A2.FAQs.and.INFO/CSA2.FAQs/
Or, for an html listing see ...
http://home.swbell.net/rubywand/A2FAQs7GAMESITES.html
Rubywand
Gérard Imbert
>offers by far the best collection. You can't quite say "If it isn't on
Asimov,
>it isn't"; but, if you did, you would almost always be right.
I suppose that's why I had trouble finding archives ;-)
> One part of Asimov which sometimes gets overlooked is the File Based
area
>at ftp://ftp.apple.asimov.net/pub/apple_II/images/games/file_based/ .
> The file_based/ folder features disk images which have several games
each.
>Many games are here which are not available on separate single-game disk
images.
>If you are viewing the page under Netscape, you can click "Edit" and do a
"Find
>in page" search for all or part of the game title you're looking for.
Thanks :-) I'm mainly looking for "complete-disk" programes (King's Quest 4,
Millionware, etc) there sure are things in the "file_based" section that I
would have overlooked Iif you hadn't pointed it existence :-)
> For other sites which might have what you want, see the listings in
the
>Csa2GAMES.txt folder at one of the following:
>Ground offers pure Text for downloading or Viewing via
> an FTP program ...
> ftp://ground.ecn.uiowa.edu/apple2/Faqs/
What are the "shrinkit" (Shk) images ? Is there a way I can use those with
an emulator ? (My Apple II hard drives are broken, however if someon can
help me repairing them...).
Maybe there is a way to interface an Apple IIe with a PC, in a way that the
PC acts as a hard drive ... just wondering :)
Rubywand
>
....
> Thanks :-) I'm mainly looking for "complete-disk" programes
> (King's Quest 4, Millionware, etc)
....
>
> What are the "shrinkit" (Shk) images ? Is there a way I can use those with
> an emulator ?
ShrinkIt files on the Apple II series are like Zip files on the PC.
ShrinkIt files are compressed archives of files or, sometimes, whole disks.
Usually file archives are tagged ".shk" and whole-disk archive files end with
".sdk".
As far as I know, there is no way to deal with whole-disk (.sdk) files
on an emulator because the .sdk file is not recognized as a disk image.
Possibly, you could handle .shk files which come on a disk image; but,
having .shk files on a disk image is a pretty unusual situation.
> (My Apple II hard drives are broken, however if someon can
> help me repairing them...).
>
You could post questions about your hard disk problems. Someone may be
able to help.
> Maybe there is a way to interface an Apple IIe with a PC, in a way that
> the PC acts as a hard drive ... just wondering :)
....
A BBS program on the PC might let you access the hard disk as though it
were on a BBS. The usual way to get stuff from PC is to transfer it using a
NULL modem connection. There's some information about this at ...
http://home.swbell.net/rubywand/Csa2T1TCOM.html .
Rubywand
phoenyx
> ShrinkIt files on the Apple II series are like Zip files on the PC.
> ShrinkIt files are compressed archives of files or, sometimes, whole disks.
> Usually file archives are tagged ".shk" and whole-disk archive files end with
> ".sdk".
>
> As far as I know, there is no way to deal with whole-disk (.sdk) files
> on an emulator because the .sdk file is not recognized as a disk image.
>
> Possibly, you could handle .shk files which come on a disk image; but,
> having .shk files on a disk image is a pretty unusual situation.
Actually most emulators work with .sdk files as long as they are 140k. If
the .sdk files are 800k then you can use nulib to extract the disk format
and the emulator can use it like a hard disk image. Apple PC does this as
well as Apple Oasis and Kegs for Linux. I can't say for sure about the
Mac emulators.
To use shk files you need a way to place them on a disk or hdv image. Again,
Apple Oasis for the PC can do this and Kegs has a utility to accomplish this.
Phoenyx
Rubywand
>
....
>
> Actually most emulators work with .sdk files as long as they are 140k. If
> the .sdk files are 800k then you can use nulib to extract the disk format
> and the emulator can use it like a hard disk image. Apple PC does this as
> well as Apple Oasis and Kegs for Linux. I can't say for sure about the
> Mac emulators.
>
> To use shk files you need a way to place them on a disk or hdv image.
> Again, Apple Oasis for the PC can do this and Kegs has a utility to
> accomplish this.
Suppose a compressed (less than 140k) .sdk whole-disk ShrinkIt file is
moved onto a blank ProDOS disk image. You run ShrinkIt v3.4 on your emu and
insert the disk image into Drive 1. Will AppleWin and/or other emus extract
the file to a formatted 140k disk image in Drive 2?
Rubywand
Cturley2
"Actually most emulators work with .sdk files as long as they are 140k. If the
.sdk files are 800k then you can use nulib to extract the disk format and the
emulator can use it like a hard disk image. Apple PC does this as well as Apple
Oasis and Kegs for Linux. I can't say for sure about the Mac emulators."
And, I reply: The Mac IIgs emulator - Gus - has the very nice option and
ability to do a 'drag and drop' (over it's program icon on the Mac desktop) of
a ShrinkIt disk (SDK) archive and will launch it - if it has GS/OS, ProDOS 16
or ProDOS 8 on the SDK archive for full launch ability. You can also drag and
drop a ShrinkIt disk (SDK) archive directly into the Gus IIgs emulators desktop
window and Gus will instantly mount and present it as on its dessktop as a disk
icon for access and use. This is one of the unique options I like th most
about Gus v1.0d4.
I've tried this with Bernie ][ the Rescue v2.01 and it DOES NOT have either of
these options. I won't even comment on the XGS PPC or 68k Mac IIgs emulators,
as they are just totally way to slow to deal with.
Cheers,
Tom
Supertimer
> Suppose a compressed (less than 140k) .sdk whole-disk ShrinkIt file is
>moved onto a blank ProDOS disk image. You run ShrinkIt v3.4 on your emu and
>insert the disk image into Drive 1. Will AppleWin and/or other emus extract
>the file to a formatted 140k disk image in Drive 2?
Actually, what Phoenix is talking about is a feature of nulib. For .shk
files, nulib does its best to extract them, but loses the file type and
resource fork (not good for Apple II stuff).
However, for .sdk files, it is actually useful. You make an .sdk file of
an 800k or 140k disk and extract it in nulib. Nulib will spit out a .dsk
file. ;-) That's what Phoenix is talking about.
You need not first move the .sdk file to a ProDOS disk image at all.
Rubywand
Okay; thanks for the explanation. My question is about dealing with
compressed ShrinkIt whole-disk (.sdk) files of 140k diskettes.
Most .sdk files are automatically compressed at the time of creation
because this saves space. Something around 80k is a fairly common size. Nearly
any compressed .sdk file of a 140k disk will fit on a 140k disk image.
Suppose you are running AppleWin (or some other emu) and have a disk image
which contains an .sdk file in 'Drive 1'. Can it be unshrinked to a target disk
image in 'Drive 2'?
On a real Apple II, of course, there would be no problem. ShrinkIt 3.4
would unshrink the .sdk file to the target diskette. Will this work on any
current emu? If it will and there are ways to get the .sdk files onto dsk's,
then there would be a way for emu users to access nearly everything in 5.25"
.sdk files.
Rubywand
Supertimer
Well, it does work, at least under XGS. I once .sdk compressed an 800k
IIGS disk containing a 5.25" .sdk on that disk. I used NuLib to create an
800k disk image from that 800k .sdk. Then I mounted the disk image in
XGS. It showed up in the emulated IIGS Finder (very slowly, I might add).
Running 8-bit ShrinkIt from Finder under XGS, one could then extract the
5.25" .sdk file inside the 800k disk image onto a blank 5.25" disk image.
But why would you do this? I mean, I only did it because the smaller
.sdk happened to be on the 3.5" disk I was imaging. Normally, why not
use NuLib to change the 5.25" .sdk file into a .dsk and be done with it?
Emu users should just use NuLib to convert .sdk archives into .dsk. It
saves the step of moving the .sdk file into a disk image!
Rubywand
> > Most .sdk files are automatically compressed at the time of creation
> >because this saves space. Something around 80k is a fairly common size.
> >Nearly any compressed .sdk file of a 140k disk will fit on a 140k disk
> >image.
> >
> > Suppose you are running AppleWin (or some other emu) and have a disk
> >image which contains an .sdk file in 'Drive 1'. Can it be unshrinked to a
> >target disk image in 'Drive 2'?
> >
> > On a real Apple II, of course, there would be no problem. ShrinkIt
> >3.4 would unshrink the .sdk file to the target diskette. Will this work
> >on any current emu? If it will and there are ways to get the .sdk files
> >onto dsk's, then there would be a way for emu users to access nearly
> >everything in 5.25" .sdk files.
>
> Well, it does work, at least under XGS. I once .sdk compressed an 800k
> IIGS disk containing a 5.25" .sdk on that disk. I used NuLib to create an
> 800k disk image from that 800k .sdk. Then I mounted the disk image in
> XGS. It showed up in the emulated IIGS Finder (very slowly, I might add).
> Running 8-bit ShrinkIt from Finder under XGS, one could then extract the
> 5.25" .sdk file inside the 800k disk image onto a blank 5.25" disk image.
>
> But why would you do this? I mean, I only did it because the smaller
> .sdk happened to be on the 3.5" disk I was imaging. Normally, why not
> use NuLib to change the 5.25" .sdk file into a .dsk and be done with it?
>
> Emu users should just use NuLib to convert .sdk archives into .dsk. It
> saves the step of moving the .sdk file into a disk image!
Except, NuLib will not (as far as I know) work with ShrinkIt .sdk files
which include compression-- which is pretty nearly all .sdk files.
Just tried something like your experiment. Instead of 800k stuff, only
140k 5.25" dsk's were involved. The emu used was AppleWin.
ShrinkIt 3.4 had no difficulty shrinking a 140k dsk and placing the
resulting whole-disk .sdk file on a dsk in Drive 2.
And, ShrinkIt had no problem unshrinking the new .sdk file to a target dsk
in Drive 2. (The target dsk can be ProDOS or DOS 3.3 and does not need to be
blank because ShrinkIt formats the target dsk.)
So, if there is a way to put .sdk files on dsk, it looks like emu users
can access nearly all .sdk files by just using ShrinkIt to unshrink them to dsk
form.
Rubywand
Rubywand
>
> On Wed, 07 Jul 1999 13:47:11 -0500, Rubywand <ruby...@swbell.net>
> wrote:
>
> > Except, NuLib will not (as far as I know) work with ShrinkIt .sdk files
> >which include compression-- which is pretty nearly all .sdk files.
>
> any problems that I know of.
....
Well, DUH! Like it does seem to. (At least Nulib v3.24 does.) Thanks for
the info!
Tried an experiment with DOS 3.3 and ProDOS ShrinkIt whole-disk 5.25" .sdk
files (both include compression).
Example: Go to the MS-DOS prompt (from Win95) and, in the DOS window, get to
the Nulib folder (where the .sdk files have been copied to simplify things).
enter this--> nulib X copy2p55.sdk
and the result is a disk image file.
Both the DOS 3.3 and ProDOS .sdk files came out as perfectly good
143,360-byte disk images. Changed the file names to end with ".dsk" and they
booted fine under AppleWin.
> I just tried it and it works fine with ProDOS 5.25" .SDK files but I
> had problems doing it with DOS 3.3 5.25" .SDK files and I'm not sure
> why.
....
Me neither. Maybe there are some 5.25" whole-disk ShrinkIt files that
don't work-- seems like I may have run into one and decided Nulib couldn't
handle compressed .sdk's. Possibly, there is a problem with .sdk files created
by GS-ShrinkIt (usually, I use 8-bit ShrinkIt to create 5.25" .sdk files).
In any case, a ProDOS .sdk file and two DOS 3.3 .sdk files tried all
turned out okay as disk images. Thanks, again, for clearing things up!
Rubywand
Jeff Blakeney
wrote:
> Except, NuLib will not (as far as I know) work with ShrinkIt .sdk files
>which include compression-- which is pretty nearly all .sdk files.
I'm not sure what you mean but NuLib uncompresses .SDK files without
any problems that I know of. That is the way I originally move some
of my disks over to my PC to try out XGS. I created .SDK files of
some 800k disks, transferred them to the PC, used NuLib to create .RAW
dumps of the disk images then used a utility to convert them into disk
images useable by the emulator.
I just tried it and it works fine with ProDOS 5.25" .SDK files but I
had problems doing it with DOS 3.3 5.25" .SDK files and I'm not sure
why.
+------------------------------------------------------------------------+
| Jeff Blakeney - Dean of the Apple II University in A2Pro on Delphi |
| Delphi Apple II Forums Web Pages |
| A2: http://www.delphi.com/apple2 A2Pro: http://www.delphi.com/a2pro |
+------------------------------------------------------------------------+
HyperCard IIgs course now in session in the A2Pro forum on Delphi
Learn to Program in GSoft BASIC course now in session
Ron Kneusel
Rubywand wrote:
> Both the DOS 3.3 and ProDOS .sdk files came out as perfectly good
> 143,360-byte disk images. Changed the file names to end with ".dsk" and they
> booted fine under AppleWin.
Just a word of caution. Traditionally, files ending with a .dsk
extension were
DOS 3.3 order image files. The output from nulib in this case is a
ProDOS order
disk image file and should have a .po extension. Obviously AppleWin is
able to
tell the difference but some older emulators might rely upon the file extension.
Ron Kneusel
rkne...@mcw.edu
Rubywand
>
> Rubywand wrote:
> > Both the DOS 3.3 and ProDOS .sdk files came out as perfectly good
> > 143,360-byte disk images. Changed the file names to end with ".dsk" and they
> > booted fine under AppleWin.
>
> Just a word of caution. Traditionally, files ending with a .dsk
> extension were DOS 3.3 order image files.
It is unfortunate that the original choice of the suffix for A2 emu disk image
does not promote recognition of disk order. The ending ".dsk" conveys the idea of
"disk image", not "DOS 3.3 disk image". The ending ".po" looks like a subset of
".dsk" rather than an equal-level category.
> The output from nulib in this case is a
> ProDOS order disk image file and should have a .po extension.
Nice to know!
> Obviously AppleWin is able to tell the difference but some older emulators might
> rely upon the file extension.
....
That would be pretty important. Disk order is definitely a concern for ADT
users, too.
When employed to transfer a diskette from Apple II to PC, ADT always creates a
DOS 3.3-order disk image-- even if the diskette is a ProDOS disk. When used to
transfer a disk image from PC to diskette on Apple II, the disk image must be DOS 3.3
order. ADT will not correctly transfer ProDOS-order disk images.
It looks like we are stuck with needing to keep track of a disk image's DOS 3.3
or ProDOS sector ordering. Is there an emu utility which can identify ordering and
which allows setting DOS 3.3 or ProDOS ordering and saving the Dsk?
Rubywand
Ron Kneusel
Rubywand wrote:
> It looks like we are stuck with needing to keep track of a disk image's DOS 3.3
> or ProDOS sector ordering. Is there an emu utility which can identify ordering and
> which allows setting DOS 3.3 or ProDOS ordering and saving the Dsk?
One could be written, certainly. My Image2File program for the Mac
(extracts files from
Apple II disk images) will automatically determine the image order (I
think - haven't looked
at it in a long time)
It could be a fun exercise. Anyone want to do it if it hasn't already
been done?
Ron Kneusel
rkne...@mcw.edu
Bill North
>Subject: Re: Disk images-- ShrinkIt .sdk on dsk's
>From: Ron Kneusel, rkne...@mcw.edu
>Date: Fri, 09 Jul 1999 09:15:13 -0500
A2Catalog auto-detects normal 144k disks.
April 11, 1999
A2Catalog v1.1
Announcing the release of a new version of a free Apple ][
Disk Image Utility to support Apple ][ emulators
A2Catalog is a utility program to manipulate files containing
Apple ][ 5.25" 16 sector disk images for use with Apple ][
emulators. Specifically, A2Catalog allows you to:
1. Read in .DO (.DSK), .PO (.RAW), .NIB, and .2MG (2IMG) files,
even if .gz (GZIP) compressed;
2. View the file's contents as an Apple ][ disk dump;
3. View and save the catalog (directory) of disks in DOS 3.3,
ProDOS, RDOS 2.1, RDOS 3.3, and Apple Pascal formats;
4. Extract certain file types on an OS/Filetype basis;
5. Save the disk image file as .DO, .PO, .NIB, or .2MG; and
6. Create new disk images formatted as DOS 3.3 and ProDOS.
Further information about A2Catalog along with the download
can be found at:
http://purl.org/net/cklipsch/a2catalog/
Please direct all A2Catalog inquiries to the news group:
comp.emulators.apple2
Note:
A2Catalog is written in Java as an application, not an
applet, so you can't run it from a Java enabled web
browser. You must have the Java runtime version 1.1+
installed. A2Catalog should run on any platform supporting
Java 1.1+.
Changes from 1.0 to 1.1:
1.1 April 11, 1999
Corrected data checksums in NIB output.
Replaced deprecated methods.
Suppressed some multi-characters in Macintosh high-ascii dump.
Added ability to extract files as text.
Added ability to extract selected file types interpreted.
Modified Catalog saved to disk to show originating disk image file name.
Modified Dump to show byte addresses.
>Ron Kneusel
>rkne...@mcw.edu
Mr.I'mAnOutOfControlLisaSimpsonFannnn
disk image
> does not promote recognition of disk order. The ending ".dsk" conveys
the idea of
> "disk image", not "DOS 3.3 disk image". The ending ".po" looks like a
subset of
> ".dsk" rather than an equal-level category.
There was a .do ending, as well as .po and .dsk.
.dsk might have meant either ProDOS order or DOS order, while .do and .po
were more specific.
--
jonr...@napanet.net jrelay.cjb.net
An Apple II fanatic since 1998!
Syntax Error: an error on a criminal's tax record.
Bad Subscript: a criminal reading a book on a subway.
Unimplemented Trap: when a bear trap isn't set up properly and thus does not work.
Rubywand
>
> > It is unfortunate that the original choice of the suffix for A2 emu
> > disk image does not promote recognition of disk order. The ending
> > ".dsk" conveys the idea of "disk image", not "DOS 3.3 disk image".
> > The ending ".po" looks like a subset of ".dsk" rather than an
> > equal-level category.
>
> There was a .do ending, as well as .po and .dsk.
Yes; but, it is virtually never used-- probably just as well.
> .dsk might have meant either ProDOS order or DOS order, while .do and .po
> were more specific.
AppleWin works like that. If a disk image file name ends with ".dsk",
AppleWin will figure out the sector ordering (i.e. it will identify DOS 3.3
or ProDOS ordering).
If the name ends with ".po", then AppleWin assumes ProDOS sector
ordering (which means the disk will bomb if it is not really ProDOS sector
ordered). The same principle applies to names ending with ".do".
The problem with this approach is that sector ordering is important
information. Many users like to transfer disk image files using ADT and ADT
does not correctly transfer ProDOS ordered images. There is no place in an
archive for a "whatever order" name designation.
So, although ".dsk" _can_ indicate either DOS 3.3 or ProDOS sector
ordering (at least to an emulator), the standard is to use ".dsk" for just
DOS ordered images.
Since a 5.25" ProDOS formatted disk with ProDOS content can be a DOS 3.3
ordered disk image, it turns out that there is nearly zero need for 5.25"
ProDOS disk image ordering. In general, when a 5.25" disk image is created
using DSK2FILE or Asimov, the disk ordering should be set to "DOS 3.3" and
the file name should end with ".dsk".
About the only exception to the above seems to be when a disk image is
produced from a ShrinkIt 5.25" disk archive (.sdk) file, usually via Nulib on
a PC. These disk images end up with ProDOS sector ordering and need a file
name ending with ".po".
Rubywand
Supertimer
to mess with tiny dsk images. Jeff Blakeney posted a
good way to transfer IIGS info.
Use ShrinkIt GS to compress an ENTIRE hard disk
drive partition, then transfer it across to the PC (he used
null modem 56k to transfer 11MB of compressed
volume across). On the PC, use Nulib to extract the
hard disk partition as an image file, which boots in XGS
or Sweet16. Of course a Zip drive would even be better.
Works with ProDOS volumes. Not sure about HFS
ones. Well, Sweet16 is said to support them. I wonder
how XGS will react. ;-)
Jeff Blakeney
>If you are serious about emulating a IIGS, it is best not
>to mess with tiny dsk images. Jeff Blakeney posted a
>good way to transfer IIGS info.
The real benefit here is that I got my emulated IIgs running the exact
same GS/OS set up with all the extras installed without having to do
it all from scratch. I won't be setting up an exact copy of my IIgs
setup in my emulators because I don't really have the hard drive space
for 1.2 GB of disk images. :)
I'll probably just transfer over four or five of my nine ProDOS
partitions.
>Use ShrinkIt GS to compress an ENTIRE hard disk
>drive partition, then transfer it across to the PC (he used
>null modem 56k to transfer 11MB of compressed
>volume across). On the PC, use Nulib to extract the
>hard disk partition as an image file, which boots in XGS
>or Sweet16. Of course a Zip drive would even be better.
Keep in mind that when you create a disk image of a 32 MB ProDOS
volume, the disk image has to be saved to an HFS volume. ProDOS has a
16 MB maximum file size limit. When you use GSHK to compress it, you
might be able to get away with saving the archive to a ProDOS volume.
In my case it would have worked because my ProDOS volumes weren't near
being full so they compressed down to the 6-11 MB range.
>Works with ProDOS volumes. Not sure about HFS
>ones. Well, Sweet16 is said to support them. I wonder
>how XGS will react. ;-)
Good question I should try that out one of these days. :)
Andy McFadden
Jeff Blakeney <CUTbl...@home.com> wrote:
>On 07 Aug 1999 08:31:42 GMT, super...@aol.com (Supertimer) wrote:
>
>>If you are serious about emulating a IIGS, it is best not
>>to mess with tiny dsk images. Jeff Blakeney posted a
>>good way to transfer IIGS info.
>
>The real benefit here is that I got my emulated IIgs running the exact
>same GS/OS set up with all the extras installed without having to do
>it all from scratch. I won't be setting up an exact copy of my IIgs
>setup in my emulators because I don't really have the hard drive space
>for 1.2 GB of disk images. :)
Dang... I didn't realize you could do that! :-)
I did a file-by-file compression on four 20MB ProDOS partitions right
after I nearly lost them due to stiction. Hadn't even occurred to me
to archive the entire volume as a single disk. Sounds like a fine
inaugural application for the new localtalk setup.
(I ended up replacing the sticky 100MB hard drive with a 2GB hard drive,
which was the smallest I could find. Couldn't get it working on a RamFAST,
but the Apple HS SCSI worked fine. Sort of amusing to have five 20MB ProDOS
partitions -- the fifth one is a floptical xfer slot -- and a 1.9GB HFS
partition with nothing on it.
The PC I just put together has 128MB of RAM and boots off an 18GB Quantum
Atlas IV Ultra2-LVD hard drive that scored 20MB/sec in a sequential read
benchmark. In theory, I could read the entire contents of my original IIgs
hard drive into physical memory in about five seconds. My, how times have
changed. It's cool to think that not only are both machines still
running, they can talk to each other and share files over a network.)
--
Send mail to fad...@netcom.com (Andy McFadden)
CD-Recordable FAQ - http://www.fadden.com/cdrfaq/ (a/k/a www.spies.com/~fadden)
Fight Internet Spam - http://spam.abuse.net/spam/ & news.admin.net-abuse.email
Andy McFadden
Andy McFadden <fad...@netcom.com> wrote:
>>>If you are serious about emulating a IIGS, it is best not
>>>to mess with tiny dsk images. Jeff Blakeney posted a
>>>good way to transfer IIGS info.
>Dang... I didn't realize you could do that! :-)
Wait a minute... you can't do that.
How'd you do that? GSHK shows everything greyed out.
I looked through recent postings but couldn't find anything relevant.
Jeff Blakeney
>In article <7oicum$s...@dfw-ixnews11.ix.netcom.com>,
>Andy McFadden <fad...@netcom.com> wrote:
>>>>If you are serious about emulating a IIGS, it is best not
>>>>to mess with tiny dsk images. Jeff Blakeney posted a
>>>>good way to transfer IIGS info.
>
>>Dang... I didn't realize you could do that! :-)
>
>Wait a minute... you can't do that.
>
>How'd you do that? GSHK shows everything greyed out.
>
>I looked through recent postings but couldn't find anything relevant.
Sorry about that. I guess I should have mentioned that I used
Sheppy's ImageMaker program to create disk images in 2MG format
directly from my ProDOS partitions. You can get it at Sheppy's web
site at:
It is a $5 US shareware program and Sheppy has set up an account with
Kaji to accept credit card payments if you don't want to bother
sending cash, cheque or money order. This URL is also availabe from
Sheppy's web page:
http://order.kagi.com/cgi-bin/r1.cgi?QGC&
Once I created the 2MG files I compressed them with GSHK. I then
transferred the SHK files to my PC and used Nulib to extract the 2MG
files and copied them to my emulator directories (XGS and Sweet16).
By the way, if you don't have a big enough HFS partition (needs to be
around 40 MB minimum for one 32 MB disk image) but have an AppleTalk
network available, you can save the disk images that ImageMaker
creates onto any AppleShare volumes you have mounted.