Copyright: Copyright (C) 2009 by faddenSoft, LLC


Welcome to CiderPress

CiderPress is the culmination of a journey that began in May 1989 with the first release of "NuView".  That program, which quickly evolved into NuLib and eventually became NuLib2, was the first to access ShrinkIt archives on computers other than Apple IIs.  CiderPress continues the tradition by becoming the first Windows GUI application to support ShrinkIt archives.

CiderPress is not "toy" software.  It is a fully-functional Windows file archiver, with all of the gizmos and gadgets you'll find in applications for "mainstream" formats.  The only difference is an emphasis on preservation and conversion of Apple II file formats.

Some pages that will get you started:

Quick overview of CiderPress features.

How to use CiderPress.

Getting help.

Credits.

If you prefer a tutorial to a reference manual, check out the tutorial on the faddenSoft web site.


The contents of the block or sector are displayed here.  If you are following a file and reach a sparse block, "SPARSE" will be displayed instead.


Tool - Disk Editor
Disk Viewer

The Disk Viewer provides an interface similar to "disk zap" utilities on the Apple II.  You can view the contents of a disk as a collection of 256-byte tracks and sectors, as a series of 512-byte blocks, or (for nibble images) raw track data.  The current version of CiderPress does not allow sector or nibble editing, so the "write" button is always disabled.

Start the viewer by selecting it from the menu or by clicking on the toolbar icon that looks like a 5.25" floppy.  Select whether you want to open a disk image file or a Windows volume.  (The 3rd choice opens the disk image you currently have open in the file viewer.  If nothing is open, or you've opened a file archive, the 3rd button will be greyed out.)  Choose a disk image or volume to open.  In most cases, the viewer opens immediately.

If CiderPress can't identify the filesystem, or if you have "Confirm disk image format" selected in Disk Image Preferences, you will be allowed to review and change the disk image characteristics  before the image is opened.  If the disk doesn't have a filesystem that CiderPress recognizes, you can use one of the "generic" entries to specify how the sector ordering should be handled.  (If it's a 140K disk, you probably want "Generic DOS"; if it's an 800K disk, you probably want "Generic ProDOS" and "View data as blocks".)  CiderPress may have been able to guess at the image sector ordering from the filename or file format, so if it's not set to "unknown" it's probably best to leave it alone.

CiderPress will automatically choose between displaying 512-byte blocks or 256-byte sectors based on the filesystem of the image you're opening (sectors for DOS disks, blocks for everything else).  If CiderPress can't identify any sectors on a nibble image, only the track nibble viewer will be available.  You can override the setting from the "Confirm disk image format" dialog described above.

The viewer opens on track 0/sector 0 or block 0.  Data is read into the buffer and displayed as a hex dump.  The ASCII on the right half of the window represents the data after a "High ASCII" conversion (technically: the high bits have been stripped off).

You can move to another location on the disk by adjusting the track/sector/block numbers and clicking on the "Read" button.  You can also use the "Read Next" and "Read Prev" buttons to move forward or backward.  If you prefer your numbers in hex, just hit the "Hex" checkbox to change how they are displayed and interpreted.

The disk viewer will allow you to see every block on the disk, including those that are part of sub-volumes.  If you want to open a sub-volume as a disk, click on the "Sub Volume" button and choose the volume from the list.  (If a disk has no sub-volumes, the button will be disabled.)  Learn more about DOS sub-volumes.

You can also choose to open and follow a file.  Click on the "Open File" button to bring up the file selection box.  Type the full pathname of the file as it appears when you open the disk with the CiderPress "Open..." menu item.  For a ProDOS disk, this means typing the full path with subdirectory names separated by colons (':').  If you want to try to open a resource fork, click the "Open resource fork" checkbox.  (NOTE: this feature does not currently work for HFS disks.)

Move through the file with the "Read Next" and "Read Prev" buttons.  The track/sector or block number will update automatically as you move.

You can't open files stored in embedded sub-volumes this way.  Instead, you need to open the sub-volume, and then open the file.

Bear in mind that what you are seeing is the actual sector or block data from the disk, not just part of a file.  In some cases you will see junk after the end of the file.  Also, attempting to view files on a DOS 3.3 disk while in 512-byte block edit mode will produce strange results, because two adjacent 256-byte sections of a file might be in completely different parts of the disk.  You will be shown the block that holds the first half of the 512-byte section of the file.  (If this doesn't make sense, don't worry about it -- just leave the default settings alone and view DOS disks as 256-byte sectors.)

DOS and ProDOS disks can hold "sparse" files, where some blocks filled with zeroes aren't actually stored on the disk.  If you move into a "sparse" block, the sector display will be replaced with a status message and the block number will be set to zero.  You will see one of these for every sparse block in the file.  On CP/M disks, empty files are stored without any block allocation, so if you try to follow an empty CP/M file you will see an appropriate message.

RDOS uses a sequential sector format, similar in structure to Pascal, but it's unusual in that it does not know how to "give up" storage.  In some cases you may find a few sectors allocated past the actual end of file, notably in some BASIC programs that apparently had some debugging statements deleted before the disks were shipped.  For "RDOS 3" disks, only the first 13 of 16 sectors on each track are used.

Nibble images are simply raw track data.  Identifying sectors on a disk requires interpreting that data.  CiderPress takes its best guess at the format of the disk, but if it can't find a reasonable number of readable sectors it gives up and only shows nibble data.  For cases where valid sectors were found, you will be able to choose between several sector formats in the sector or block display from a drop list in the lower right corner.  The "Patched" versions of DOS 3.2 and DOS 3.3 are like "standard" but they ignore epilog bytes and address field checksums, so using these should allow you to read disks with mild forms of copy protection.

Not all sectors on a nibble image will be readable.  Those that aren't will show an error message.  In some cases, changing the sector parameters with the drop-down list at the bottom right of the dialog will let you see more.  (One interesting example: floppy disks that were bootable under both DOS 3.2 and DOS 3.3 have two different copies of track 0 sector 0.  Switch from "DOS 3.3" to "DOS 3.2" and back again to see what's there.)

Click on the "Done" button to close the editor.

Some interesting places to visit:

DOS: catalog usually starts at track 17, sector 15, and goes down to track 17, sector 1.

ProDOS: volume directory in blocks 2 through 5.

Pascal: volume directory in blocks 2 through 5.

CP/M: volume directory in blocks 24 through 27.

RDOS: catalog starts on track 1 sector 0.

RDOS actually includes all of tracks 0 and 1 in a file called "RDOS 2.1 COPYRIGHT ...".  On nibble images of 13-sector disks, this file may be partially unreadable.


Closes the window.


Display and enter track/sector or block numbers in hexadecimal instead of decimal.


Read the block or sector specified.


Click here to write the current block or sector.  This is disabled for disks open in read-only mode.


Enter a track/sector or block number.


When following a file, move to the next block or sector.


When following a file, move to the previous block or sector.


Open a file.  This option is only available when the disk's filesystem is recognized.


Click for help on this screen.


Open a sub-volume.  This option is not available if the disk image doesn't have any sub-volumes.


Credits

Design & Implementation

The bulk of CiderPress was written by Andy McFadden (www.fadden.com) through FaddenSoft, LLC.  Andy has been writing ShrinkIt-related utilities since 1989, including "NuLib" and "NuLib2", and was the author of Westcode Software's HardPressed(tm) compression software for the Apple IIgs.

This software was written entirely in C++, using Microsoft Visual C++ 6.0 and the MFC user interface library, and requires over 100,000 lines of commented source code.  The major components are:

CiderPress application - 43K lines of code

MDC application - 1.5K lines

File converter library (used by CiderPress app only) - 15.5K lines

DiskImg DLL (used by CiderPress and MDC) - 42K lines

Common functions (used by CiderPress and MDC) - 7K lines

External DLLs (NufxLib, zlib, libhfs, wnaspi32, plus Windows msvcrt, mfc42, etc.)

ShrinkIt and the NuFX archive format were developed by Andy Nicholas.  The Binary II format was developed by Gary Little.

My understanding of Integer BASIC and the S-C Assembler file format was dramatically improved by comments in Paul Schlyter's "A2FID.C".

Many thanks to Apple Computer and especially Apple's DTS group for creating or encouraging the creation of Apple II File Type Notes.  These saved me many hours of reverse-engineering.

Many aspects of the CiderPress UI were inspired by WinZip (www.winzip.com).

Apple /// Business Basic support by David Schmidt.

Testing

v1.0 beta test volunteers:

Bryan "I found a bug" Carter <bryan@gamezero.com>

Tom "I have a suggestion" Phelps

Eric "Sheppy" Shepherd (www.syndicomm.com)

v2.0 beta test volunteers:

Rich Dreher

Bill Garber

Glenn Jones

Andrew Molloy

Allan Sutton

My thanks also go to Dave Touvell and Jeff Fink for helping track down some bugs in v2.4.

Other Included Software

Access to NuFX (ShrinkIt) archives is provided by the NufxLib library ("nufxlib2.dll").  NufxLib is an open-source project, available for download from www.nulib.com.

Access to .gz files, and support for the "deflate" algorithm in NuFX archives, is provided by the Zlib library ("zlib.dll").  Zlib is free; visit the web site at www.zlib.org.

Access to HFS volumes is provided by "libhfs", part of the "hfsutils" package written by Robert Leslie.  hfsutils is available from http://www.mars.org/home/rob/proj/hfs/.

The install/uninstall program was created with DeployMaster (www.deploymaster.com).

NList.Data is part of the Nifty List desk accessory, written by Dave Lyons.  The file was included with the permission of the author.

Legal Notices

----- for software based on CiderPress code -----

Copyright (c) 2007, FaddenSoft, LLC

All rights reserved.

Redistribution and use in source and binary forms, with or without

modification, are permitted provided that the following conditions are met:

    * Redistributions of source code must retain the above copyright

      notice, this list of conditions and the following disclaimer.

    * Redistributions in binary form must reproduce the above copyright

      notice, this list of conditions and the following disclaimer in the

      documentation and/or other materials provided with the distribution.

    * Neither the name of FaddenSoft, LLC nor the

      names of its contributors may be used to endorse or promote products

      derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY FaddenSoft, LLC ``AS IS'' AND ANY

EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED

WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE

DISCLAIMED. IN NO EVENT SHALL FaddenSoft, LLC BE LIABLE FOR ANY

DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES

(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;

LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND

ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT

(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS

SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

----- for binary distributions of NufxLib2 -----

Copyright (C) 2007, Andy McFadden.

All rights reserved.

Redistribution and use in source and binary forms, with or without

modification, are permitted provided that the following conditions are met:

  * Redistributions of source code must retain the above copyright

    notice, this list of conditions and the following disclaimer.

  * Redistributions in binary form must reproduce the above copyright

    notice, this list of conditions and the following disclaimer in the

    documentation and/or other materials provided with the distribution.

  * Neither the name of the copyright holder nor the names of project

    contributors may be used to endorse or promote products derived from

    this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"

AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE

IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE

ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS

BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,

OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF

SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS

INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN

CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)

ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF

THE POSSIBILITY OF SUCH DAMAGE.


Using the File Viewer

With the file viewer you can examine files stored in an archive or disk image without having to extract them first.  Files may be converted from several different Apple II formats.

When the file viewer opens you will be shown the first file you selected from the file list.  If you selected multiple files, the "Prev" and "Next" buttons can be used to move between them.

The "data", "resource", and "comment" buttons on the left can be used to choose which part of the file you want to view.  If the file doesn't have the part in question, the button will be dimmed.  Disk images in NuFX archives are treated as data forks.

You can choose how you want the file to be formatted by choosing a formatter from the drop-down list.  You will always have the option of viewing data in raw form or as a hex dump.  If not disabled, a generic text converter that changes end-of-line characters and strips "high ASCII" will also be available.  Certain types of files will have additional options that can be chosen from the list.  The buttons labeled "best", "hex", and "raw" change the selection to the best formatter, the hex dump formatter, and the raw dump, respectively.

The "best" option, which is always the first in the list, is determined by examining the file.  Certain file viewer preferences, such as disabling reformatters or setting a preference for black & white hi-res images, will affect the conversion.  The other modes are still available and may be chosen from the list, but the viewer will default to your preference.

For text documents, the font can be changed with the "Font" button.  A monospace font like Courier or Courier New is recommended for Apple II files since most of them were created with a fixed-width font in mind.  The default is 10-point Courier New.  If you're viewing a IIgs word processing file, such as a Teach document, the file may be in multiple fonts and multiple sizes.  Using the "font" button will force the text to use a single font and size.

You can use the "Find" button to search for text.  The search starts at the currently selected text or, if none is selected, at the blinking cursor.

You can print text or graphics with the "Print" button.  The document will be sent to the printer using the fonts you see on screen.

If a format converter fails, perhaps because the file being converted has become corrupted, the "raw" output will be displayed instead.  If an error occurs, such as trying to view a file larger than the configured maximum limit, a message will be displayed on a yellow background.

All hex dumps, text, and pictures can be cut and pasted directly from the file viewer.  Printing "raw" output is generally not a good idea, because the output may contain "page feed" characters that leave all or part of a page blank.

You can also copy documents to other programs.  To select the entire document, click on the document to set the input focus, then hit Ctrl-A to select all and Ctrl-C to copy it to the clipboard.  Switch to another application (Windows WordPad and Microsoft Word are the most appropriate) and hit Ctrl-V to paste.

Bear in mind that not all applications support all formats.  Pasting text into Windows notepad, which doesn't support Rich Text Format, will cause highlighed BASIC listings and formatted AppleWorks documents to be converted to plain text.  Pasting graphics into Notepad doesn't work at all.

Click "Done" to close the window.

Tip: hit the Tab key to highlight the format selector, then use the up and down arrows to move between different conversion modes.


Click this to accept values and continue.


Click this to go back without doing anything.


Appendix - About Disk Images
About Disk Images

Disk images are copies of entire Apple II floppy disks stored in a single file.  There are several different ways to generate and store them, some designed for uploading to web pages, others for use with Apple II emulators.  There are also a number of different ways of storing files on an Apple II disk, the most prominent being the DOS 3.3 and ProDOS filesystems, so opening an image file and getting at the files inside can be tricky.

CiderPress takes most of the pain out of opening disk images by automatically determining the storage format and filesystem for many common formats.  You can view the format for an open disk image with the Archive Info feature, and you can attempt to override the automatic settings by enabling "Confirm disk image format" in Disk Image Preferences.

There are five attributes that must be determined before a disk image can be opened: outer format, image file format, physical format, sector ordering, and file system format.

Outer Format

Sometimes disk images are compressed with gzip or another program to reduce their size.  If CiderPress sees a ".gz" or ".zip" extension, it will automatically uncompress the file when it is opened, and re-compress it if any changes are made.

CiderPress supports Zip/gzip compression in conjunction with all formats except ShrinkIt archives, so ".sdk.gz" and ".sdk.zip" won't open.  Generally speaking, archives compressed with ShrinkIt don't compress much, so this is uncommon.

Image File Format

This is the format of the file that you have on your PC.  The format is often indicated by the filename extension, e.g. ".sdk" for a disk packed with ShrinkIt.  The disk image file formats that CiderPress handles, with their most common extensions, are:

Universal Disk Image	.2MG, .2IMG
DiskCopy 4.2	.DSK, .DC, .DC6
Sim //e HDV	.HDV
Dalton's Disk Disintegrator (DDD)	.DDD
Formatted Disk Image (FDI)	.FDI
Unadorned sectors	.DSK, .DO, .PO, .D13, .HDV, .IMG, .RAW, .ISO
Unadorned nibbles	.NIB, .NB2
NuFX (ShrinkIt)	.SHK, .SDK
TrackStar	.APP

The "unadorned" format refers to files that are nothing but disk data.  The other formats have headers that must be removed before the data can be accessed.  For some formats, such as NuFX and DDD, that data may need to be uncompressed before it can be used.

The Image File Format is reliably detected by CiderPress, and can't be overridden.  If you think CiderPress has got it wrong, you can usually override its choice by changing the file extension.

Identifying DDD archives is tricky, because there is little information in the file format to distinguish it from an ordinary file.  The only way to tell is to try to unpack the file and see if you run out of compressed data at roughly the same time as you output 140K of uncompressed data.  Further complicating matters is that DOS DDD archives are stored as binary files but with a length of zero, so CiderPress has to guess that it's a DDD archive and then modify the length.  CiderPress will adjust a DOS 'B' file if it has an address and length of zero, is at least 8 sectors long, and has angle brackets (<>) in the filename.

Please do not use DDD v2.0 under DOS; it has a bug that can cause the last sector on the disk to be corrupted.  Because the DDD file format lacks any sort of checksum, the corruption can go undetected.  Use DDD v2.1 or later under DOS.  Better yet, use ShrinkIt to create your disk images.

TrackStar images are created and used by the TrackStar Apple II emulator hardware.  This board was developed many years ago, and is rare today.  The images are stored in nibble format, but have a variable length with a maximum of 6525 bytes per track.  Standard ".nib" images use 6656 bytes per track, which means that converting from ".app" to ".nib" requires adding extra bytes in inter-sector gaps, and converting the other way requires finding and removing unnecessary bytes.  Neither of these is 100% reliable, especially on copy-protected disks, so converting to and from ".app" only works well for unprotected disks.

The TrackStar's image maker creates 40-track and 80-track images.  On a typical 40-track image, the last 5 tracks are empty, but some forms of copy protection used an additional track at the end of the disk.  You can view the contents, if any, with the Disk Viewer.  When converting to or from standard 35-track disk images, the last 5 tracks are dropped or zero-filled.  80-track images are like 40-track images but with "half tracks" stored as well.  No other disk image format supports half-tracking, so CiderPress just skips every other track.

FDI images, created by "Disk2fdi", are similar to TrackStar in that they can have more than 35 tracks and use a variable-length track format.  The "raw" images contain an image of the magnetic pulses captured from a PC floppy drive while reading an Apple II disk.  FDI images may also contain nibble images of 3.5" disks, something no other format handles.  The images are converted internally to variable-length nibble format, which means they can be converted to TrackStar format without losing data, but not to .NIB.

A ".ISO" image of a CD-ROM is essentially equivalent to ".PO".  ".ISO" images of Macintosh-partitioned or HFS CD-ROMs can be accessed directly.

Physical Format

Once the headers are stripped and the data is uncompressed, you're left with one of two things: a stream of raw "nibble" data, stored exactly as it appeared when read from a 5.25" Apple II disk drive, or a stream of 256-byte sectors.  This value indicates which of the two formats is used.

The most common nibble image format (.nib) has 6656 bytes per track, but occasionally you will find a ".nb2" image with 6384, or a ".app" TrackStar image with variable-length tracks.  CiderPress supports all formats.

Sector Ordering

Apple II floppies typically have 16 sectors.  The various Apple II operating systems used different "sector interleave" values for performance reasons, resulting in some confusion about where exactly a given track and sector resides in a sector-based disk image.  Nibble images include the sector addresses, so there is no ambiguity.

There are four common ways to order the sectors, defined in terms of the operating system used to create the disk image:

Physical order: no interleave is used.  Nibbles images always use this, and the Copy ][+ ".IMG" format is an "unadorned" file with this ordering.

DOS order: "-2" interleave is used.  Programs commonly used for transferring 5.25" disk images will read the disk as DOS sectors, resulting in a DOS-ordered ".DO" image.

ProDOS order: "+2" interleave is used.  ShrinkIt reads disks as a series of ProDOS blocks, and once extracted the disk is a ProDOS-ordered ".PO" image.

CP/M order: "+3" interleave is used.  This would only be generated by a disk image creator running under CP/M, so you're unlikely to find an image in this order.

The sector order reflects the sequence in which the sectors were written into the image file.  It allows us to convert between "physical" order and the stored order, which is important for proper handling of the "filesystem" attribute (described next).

It is possible to override the sector ordering value.  If you do, CiderPress takes it as a recommendation, and will try that order first.  If it is unable to process the image using the order you requested, it will go ahead and try Physical, DOS, and ProDOS.

13-sector ".d13" images are always stored in ascending sector order.

Filesystem Format

This is the key.  It tells CiderPress how it should go about looking for files inside the disk image.  The attribute defines not only how the files are arranged, but also how sectors should be pulled out of the image.

The supported filesystems are as follows:

Filesystem	Sector Order
ProDOS	ProDOS
HFS	ProDOS
UCSD Pascal	ProDOS
DOS 3.2/3.3	DOS
CP/M	CP/M
RDOS 3.2	Physical
RDOS 3.3	ProDOS
UNIDOS/AmDOS	DOS
OzDOS	DOS

CiderPress also supports CFFA-style fixed partitions and Macintosh-style partition maps.

If the sector order for the filesystem format matches the Sector Ordering attribute, then reading the correct sector from the disk image is easy, because the image was written in exactly the same way that the filesystem needs to be read.  If they don't match, then some amount of "sector swapping" is required to read the right sector from the right place.

If a disk doesn't actually have a filesystem -- perhaps it's an Apple II game that has its own disk format -- you will not be able to open it with CiderPress and view it as a collection of files.  You can, however, open it with the Disk Sector Viewer.  To provide the proper translation of sector numbers, you can use one of the "generic" filesystem formats.  These don't define a file structure, but do let you describe the ordering of the disk.  For example, if you use the "Generic DOS" entries, you will be able to read the disk exactly as you would with a "disk zap" utility.  If you select the "Generic ProDOS" entry, you will get results equivalent to a ProDOS "block zap" utility.

The "generic" entries are only available when opening disk images with the Disk Editor.

Some disks have embedded DOS "sub-volumes", e.g. DOS 3.3 embedded in a ProDOS disk.  See the embedded DOS volume section for more information.  CFFA cards, partitioned hard drives, and CD-ROMs are handled similarly.


Preferences - General
General Preferences

You can access General Preferences by selecting "Preferences..." from the "Edit" menu.

This screen is divided into a number of different sections.  Click on the tabs near the top to change to a different set of preferences.  Click on "OK" to accept the changes and close the dialog, "Apply" to accept the changes without closing the dialog, and "Cancel" to throw away any changes you have made since the last "Apply".

Columns

Place check marks next to the columns you want to see on the screen, and remove them from those you don't.  ("Disabled" columns are actually just zero pixels wide, and can be hidden or restored by clicking on the dividers in the column headers and dragging.)

Clicking on the "Defaults" button restores the displayed columns to the default set, and resizes all columns appropriately for the current screen dimensions and font choices.

NuFX (ShrinkIt) archives

Options that only affect ShrinkIt archives.  If you select "Mimic ShrinkIt quirks", ShrinkIt compatibility mode will be enabled in NufxLib.  This has the following effects:

•	The first file added to an archive will have an empty 200-byte comment attached.

•	All files compressed with Dynamic LZW/1 or /2 will be one byte longer.

•	Files smaller than 512 bytes are never compressed.

•	Archives with SEA wrappers have an extra byte added to the end.

There's really no value in enabling any of these, but the archives that are created very closely resemble those created by GS/ShrinkIt.  In theory, a poorly-written application might depend on these quirks, and have compatibility problems with CiderPress if they weren't enabled.  In practice, everything tested so far works just fine without needing to have these enabled.

If you select "Reduce error checking", CiderPress will ignore bad CRCs and some forms of damage to compressed data.  Enabling this is generally a bad idea, because it means you will not be notified when corrupted data is found.  In some rare circumstances, however, it can allow you to recover some data from damaged or poorly-formed archives.

See the NufxLib API documentation on www.nulib.com for more details.

Filename munging

Enabling "Lower-case DOS 3.3 filenames" causes the names of files pulled from DOS 3.3 disks to be converted to a mix of upper and lower case, as if they were book titles.  The mixed-case names will be used when the files are extracted, so this is best used when preserving the original names is not important.  The flag does not, however, affect the names of files added to DOS disks (which are always upper-case-only).

"Show spaces as underscores" does exactly what it says: all spaces in all files are converted to underscores.  This is similar to the way MP3 files are often distributed, and is useful for files that will be placed directly on a web server.

File type associations

Clicking this button brings up the Edit File Associations dialog.

Miscellaneous

The "Strip pathnames when pasting files" flag determines how the paths of ProDOS files are handled when pasting files from the clipboard.  If set, the leading path is removed before the files are pasted.  You should set this flag if you just want to copy files around, but clear it if you're moving entire subdirectories and want to retain the hierarchy.  The flag affects pasting, not copying, so you don't need to re-copy files after changing this flag.

If "beep when operations complete successfully" is checked, CiderPress plays a sound when various operations (e.g. adding or extracting files) complete successfully.


Disk Image Characteristics

This comes up when you are opening a disk image and have either checked the "Confirm disk image format" box in Disk Image Preferences or are opening a disk that CiderPress does not fully recognize.

If CiderPress doesn't recognize the disk, you will probably need to choose a filesystem format, and may need to select the sector ordering.  For more information about these fields, see the detailed disk image discussion.

When opening an image with the disk sector viewer, you can select one of the "generic" formats if you don't know what format the disk is in.  The format you choose is combined with the sector ordering value to determine how blocks or sectors are read from the disk.  If you're trying to open the image in the file list, the "generic" formats will not be available.


Appendix - Embedded DOS Volumes
Embedded DOS Volumes

The DOS 3.3 file format is wonderful for 140K 5.25" floppies, but requires some modifications before it will work on other kinds of media.  A number of authors came up with ways of putting one or more DOS 3.3 volumes onto an 800K floppy.  CiderPress recognizes most of them automatically.

Apple shipped two 3.5" drives, the AppleDisk 3.5 and the UniDisk 3.5.  The latter, combined with an interface card, would work on an Apple //e, and is responsible for the suffix used in some of the product names.

ProSel Uni-DOS (Glen Bredon)

ProSel-8 and -16 shipped with Uni-DOS, a way to format an 800K disk with 600K of space for ProDOS and 200K of space for DOS 3.3.  The embedded volume had 50 16-sector tracks.

DOS Master (Glen Bredon)

Essentially an enhanced version of Uni-DOS, DOS Master allowed placement of multiple DOS volumes on a single disk.  You could, for example, put five 140K DOS 3.3 disks on one 800K disk, and switch between them with the ",v" (volume) parameter.  The volumes could also be placed on a hard drive.

AmDOS 3.5 (Gary Little)

The "Amateur Disk Operating System version 3.5" software allowed storing two 400K DOS volumes on one 800K floppy.  Each DOS volume used 50 tracks of 32 sectors, which is the largest you can get without making significant alterations to DOS.  The change from 16 to 32 sectors broke compatibility with some programs (such as the "FID" file copying utility), but was manageable with a few well-placed patches.

UNIDOS (Unknown)

The disk format is identical to AmDOS.  It's unclear what the heritage of this is.

OzDOS (Richard Bennett)

This is another two-400K-disks-on-one-800K scheme, but the author decided to do something a little different.  Instead of putting the volumes one after the other, he stretched them out across the entire disk, using odd sectors for one volume and even sectors for the other.  For a device that reads 512-byte blocks, this makes a certain kind of sense.


Appendix - File Format Converters
File Format Converters

CiderPress can convert a variety of Apple II files into formats more easily accessible on a PC.  BASIC programs can be converted into text program listings, AppleWorks word-processing documents become RTF (Rich Text Format) documents, and graphics become Windows BMPs.

The end-of-line (EOL) marker on text files changes from system to system.  Macintosh and the Apple II use carriage returns (CR), UNIX systems use linefeeds (LF), and MS-DOS uses one of each (CRLF).  Windows programs vary in their ability to handle text files with different EOL formats, but they all handle CRLF.  CiderPress can convert all text files to Windows format if you desire.

DOS High ASCII (TXT)

Apple DOS stores text files with the high bit of every 8-bit byte set.  This causes most other operating systems to display characters from an "extended" character set (accents, tildes, etc.) instead of the intended characters.  This is usually undesirable, so all files from DOS disks with file type 'T' should be run through this converter to strip the high bit off.  This will also convert the end-of-line character to CRLF.

CP/M Text (NON)

CP/M text files use CRLF line terminators, but also follow a convention that has fallen out of use under Windows: a Ctrl-Z marks the end of the file.  This converter identifies text files on CP/M disks, and drops everything after the first Ctrl-Z.  Files with unusual control characters embedded in them may not be identified as text.

UCSD Pascal Text (PTX)

UCSD Pascal disks have text files with an unusual format (done so for the benefit of the editor).  These can be converted to text in a format that mimics the on-screen and printed output of the original.

UCSD Pascal Code (PCD)

The executable code files can be broken into segments, each of which is named and has a data type.  The converter breaks the file into segments, and displays the segment header along with a hex dump of the contents.

Applesoft BASIC (BAS)

Applesoft programs are stored in a "tokenized" format, meaning that BASIC keywords like "FOR" and "NEXT" are stored as a single byte rather than a text string.  This reduces program size and improves execution speed, but makes them hard to read on a PC.  The Applesoft converter produces output identical to what you would see if you loaded the program and typed "LIST".  If the appropriate preference is enabled, BASIC keywords, comments, and quoted text will be highlighted in color by default.

Integer BASIC (INT)

This is similar to the Applesoft converter, but for the older Integer BASIC format.  Again, the output is identical to the "LIST" command.

It was not uncommon to stash machine-language code snippets at the start or end of an Integer BASIC program, resulting in a collection of junk.  Usually some "LOMEM:" and "HIMEM:" commands were used to rearrange things so that the code gets hidden and only the BASIC program remains ("APPLEVISION", from the DOS 3.3 system master disk, is a classic example).  The converted output of the machine-language parts may not match what "LIST" does, which is a good thing -- in some cases LIST would loop forever.

Asm source (TXT, INT, and $F4)

The S-C Assembler used the DOS 'I' file type, but doesn't use the Integer BASIC file format (it's a line-oriented compressed text file).  Fortunately it's easy to tell the difference between S-C files and Integer programs.  This converts the file to plain text.

The DOS versions of LISA (Lazerware's Interactive Symbolic Assembler), v2.5 and earlier, used a mildly tokenized format stored in DOS 'B' files.  (This is the alternate type 'B', not the standard binary format; it shows up as type $F4 in CiderPress.)  The ProDOS and GS/OS versions used the ProDOS INT type reserved for Integer BASIC, with the source written in a compressed format.  The output is plain text, and matches the converted output of the original when written to a text file with the "write" command.

The file formats for LISA versions 2, 3, and 4 are different.  All three are handled.  Version 5 is equivalent to version 4, and the format for version 1 is unknown.

Merlin and Merlin-16 used a text format that crunched out excess spaces.  The Merlin converter puts the spaces back in, so the output resembles what you'd see in the Merlin-16 full-screen editor.  Merlin source files usually have filenames ending in ".S".

Disassembly (various)

Two modes of disassembly are currently supported:

•	Apple //e monitor listing.  This produces output identical to the monitor 'L' command on an Apple ][+ or //e, with two changes: 65C02 operands are supported, and NiftyList-style annotations are added.

•	Apple IIgs monitor listing.  Output is identical to the monitor 'L' command on an Apple IIgs, with the addition of NiftyList-style annotations.  You may choose "short" (8-bit) or "long" (16-bit) registers.

See the Disassembly Notes section for more information.

8-bit Word Processor (various)

Currently supports Magic Window / Magic Window II "formatted" documents.  These have file type BIN and end in ".MW".

AppleWorks Word Processor (AWP)

CiderPress does a fairly good job of converting AWP documents to Rich Text Format (RTF) files that can be edited with WordPad or Microsoft Word (the former is a Windows "accessory", and should be available on all systems).  Most text styles are supported (bold, italic, underline, subscript, superscript), as well as paragraph formatting (left/right justified, centering) and some page layout features (left/right margins, page breaks).

AppleWorks Database (ADB)

Database files in AppleWorks are two-dimensional, with a fixed set of columns and one row for each entry.  This converts easily to CSV (Comma-Separated Value) format, which can be imported into Microsoft Excel or other applications.  The file viewer will show the data in CSV form, which isn't ideal but is much easier to read than the raw unconverted format.  The first row of data holds the column titles.

AppleWorks Spreadsheet (ASP)

Spreadsheets tend to be tied to a specific application, and AppleWorks ASP files are no exception.  Microsoft Excel does a pretty good job of converting formulas over, but you can expect to do some amount of hand-tweaking after conversion.  Most formulas will transfer, but some (like @AVG) don't, and multi-cell labels will be chopped up.  As with database files, these are converted to CSV format, which should be accepted by just about any modern spreadsheet application.

Apple IIgs Word Processor (GWP)

There are actually three formats here.  All of them convert common symbols and accented characters from the IIgs fonts to Windows fonts.  Not all of the symbols have equivalents, but many of them do.  Text written in languages other than English should convert correctly.

The supported formats are:

•	Teach document (GWP $5445).  The "Teach" application on the Apple IIgs created these, which have text in the data fork and formatting information in the resource fork.  Font size and style changes are supported, accented characters are converted, and an attempt is made to convert the typeface to something similar to the original.  The results are ususally pretty good.

•	AppleWorks GS Word Processor (GWP $8010).  Same basic features as "Teach", plus some basic formatting features like centered and justified paragraphs.  The "header" and "footer" sections are displayed at the top of the converted document.

•	Generic (GWP, any aux type except the two above).  Does a IIgs text conversion without any other reformatting.  If you have a text file that uses symbols or accented characters from the IIgs font values, you can change its file type to GWP to enable this converter.

ProDOS Folders (DIR)

If you select a folder from a ProDOS disk for viewing, this converter will display it in a format similar to the 80-column output produced by the ProDOS "catalog" command.  The active set of files are shown, followed by any deleted files that can be identified.

Enabling or disabling this converter has no effect on file extraction, because CiderPress doesn't explicitly extract folders.  (It simply creates them when needed.)

Resources (resource fork of any file)

Resource forks have a well-defined structure.  Each fork is a series of resources whose formats are defined by the user or by the system.  This converter separates the fork into individual resources and displays their contents as hex dumps.  Any recognized system-defined resources will have a type description displayed next to the resource type.

Hi-Res Graphics (FOT or 8K BIN, 280x192, six colors)

The classic Apple II graphics mode is "hi-res", featuring a resolution of 280x192.  In some respects it's 140x192 (because two pixels are combined to form one color), in others it's 560x192 (because the Apple II display hardware used a half-pixel shift to get colors on a television).

The Hi-Res converter produces a 16-color, 560x384 bitmap file (BMP) that takes into account half-pixel shifting and other oddities.  The results are usually identical to what you would see on an Apple IIgs RGB monitor.  (If you set just the right pixels you can get yellow and brown on the hi-res screen of a real Apple II; in practice, this never really came up, so it isn't emulated here.)

If you select the black & white output mode, you will get a 16-color 560x384 image using only black and white.  The image matches the Apple IIgs RGB monitor output except that the half-pixel shifting is left enabled.  This was done to match the display of the IIgs composite output and other members of the Apple II line, which don't disable half-pixel shifting in monochrome mode by default.

Double Hi-Res Graphics (FOT or 16K BIN, 560x192, sixteen colors)

This graphics mode, first introduced on the enhanced Apple //e, can also be treated as 140x192, because four pixels are combined to form each color.  In monochrome mode, the output is fully 560x192.

The Double Hi-Res converter produces a 16-color, 560x384 bitmap file (BMP) that attempts to recreate the output from an Apple IIgs RGB or composite output.  Because of various weirdnesses in the Apple II display hardware, this is harder than you might think.  As a result, there are actually four different ways to process the file.  You can choose between them in the file viewer, or pick a default from the "Double Hi-Res mode" setting in the File Viewer tab of Preferences.

Black & White: output is in black and white only, full 560 pixels across.  Output matches Apple IIgs RGB monitor display exactly.

Simple 140: produces 560x384 output as if the input were 140x384.  The simplest and most "obvious" approach, it produces inferior results because the Apple II video hardware doesn't work this way.

Sliding window: converts the picture the way Apple IIe Tech Note #3 describes, using a 4-bit sliding window.  The result closely matches the composite output on an NTSC device (monitor or television), but is much more blurry than the output of an RGB monitor because most transitions have a lot of color "fringes".

Latched color: a variation on "sliding window", this tries to reduce the fringes around transitions to and from black and white.  The result renders the colors fairly well while sharpening up text.

Super Hi-Res Graphics (PIC/PNT or 32K BIN, 320/640x200)

First introduced on the Apple IIgs, Super-Res was the first mode largely devoid of video idiosyncracies.  When you set pixels to certain colors, the output on an RGB monitor was exactly what you expected.  The resolution, which could be changed on every line, was 200 lines of either 320 pixels across with 4 bits of color per pixel, or 640 pixels across with 2 bits of color per pixel.  The way colors in the file were translated to colors on screen involves some minor color palette gymnastics.  The output of the converter is a 256-color 640x400 BMP.

Super-Res images were also the first to be regularly compressed, which isn't surprising since they're 4x as large as standard hi-res.  CiderPress can convert images in the following formats:

Unpacked ("PIC" $c1/0000)

Activision Paintworks ("PNT" $c0/0000)

Packed with PackBytes ("PNT" $c0/0001)

Packed Apple Preferred Format ("PNT" $c0/0002)

The Apple Preferred Format allows for images of arbitrary dimensions.  CiderPress supports up to 1280x1024.  Paintworks images are 320x396, and convert to a 640x792 BMP.

3200-Color Super Hi-Res Graphics

A clever fellow named John Brooks figured out that, if you changed palettes at just the right time, you could get more colors on the screen than would be otherwise possible.  The results were sufficiently compelling to cause a number of GIF and JPEG converters to spring up, as well as one full-fledged 3200-color paint program.  The files are always 320x200, and the output from the file converter is a 24-bit 640x400 BMP.

Most 3200-color pictures were stored in BIN files and given names like ".3200".  Later on, official filetypes were specified, and some additional formats were developed.  CiderPress can convert the following:

Unpacked ($c1/0002 or BIN ".3200")

Packed with PackBytes (BIN ".3201")

Packed Apple Preferred Format ($c0/0002 with "MULTIPAL" block)

For Apple Preferred Format, only 320x200 images are handled.

Print Shop Clip Art

Clip art from Print Shop "classic" usually comes on DOS 3.3 disks as a 576-byte 'B' file with a load address (aux type) of $4800, $5800, $6800, or $7800.  The images unpack to 88x52 black & white BMP files.

Clip art files for Print Shop GS are 1716 bytes long, and use ProDOS file type $F8 with aux type $C323.  The images unpack to 4-bit 88x52 BMP files.

The Print Shop GS editor doubles the width and triples the height, displaying a nearly-square 176x156 image.  CiderPress does not magnify the image because that would make it awkward to manipulate the original pixels in an image editor.

MacPaint Graphics (*.mac)

The original Macintosh Paint program created monochrome 576x720 images.  These represented a full printed page on a 72dpi ImageWriter printer.  While not really an Apple II format, these were commonly found on BBS systems in the years when Apple IIs were popular.

CiderPress will attempt to identify MacPaint files that don't end in ".mac" by looking for a 128-byte MacBinary header with a 'PNTG' file type.  MacPaint files transferred to other systems usually had this header.


Preferences - File Viewer
File Viewer Preferences

You can access the File Viewer Preferences by selecting "Preferences..." from the "Edit" menu, and then clicking on the "File Viewer" tab.

The options on this screen control the operation of the file viewer.  In most cases they also alter the way files are extracted when "Convert to non-Apple II formats" is enabled.

Converters

Use these checkboxes to enable or disable conversion of specific formats.  The converters are described in more detail under File Format Converters.

If you select "Relax type-checking on graphics", CiderPress will be a little more aggressive when deciding if a file is a graphic image or not.  For example, not all hi-res and double-hi-res graphics have reliable file types, so any binary file that looks to be about the right size is displayed as a graphic.

Conversion Options

Most of these are described on the File Format Converters page.

If "Scroll horizontally instead of wrapping words" is set, the file viewer will add a horizontal scroll bar, and lines of text will not wrap when they reach the right edge of the viewer.

"Highlight hex dump columns" puts alternating 4-byte columns in bold for easier reading.  This is only done for small files, because loading the hex dump with Rich Text Format notations is considerably slower.

"Disassemble BRK/COP as a single-byte instructions" affects IIgs monitor disassembly output.

File Viewer Size Limit

This is the size of the largest file that the file viewer will open.  Large files may place a strain on Windows systems with limited memory, and in many cases there's little value in examining truly huge files with the file viewer.  The upper limit can be set in 1K increments from 1K to 32MB (32768K).


Press this to reset the columns to default sizes.


Sorry, there is no help message for this item.


Click this for help on this screen.


Click this to apply changes without closing the dialog box.


Preferences - Files
File Preferences

Temp Folder

The folder for temporary files is set by default to the system temporary folder.  You may set this anywhere you wish.

The folder is used when you double-click on a ShrinkIt archive, Binary II archive, or archived disk image in the file list.  The file in question is copied into the temp folder and passed as an argument to a new instance of CiderPress.

External File Viewer Extensions

In some cases you may want to launch an external viewer to handle certain types of files stored in ShrinkIt archives or disk images.  For example, CiderPress does not have a built-in GIF or JPEG viewer.  If you put "gif; jpg; jpeg" in this field, then any files that end with those extensions will be opened using the default viewer (the program that gets run if you double-click on the file in Windows).

The file extensions are separated by semicolons, and should not include a leading dot ('.').  You will need to configure the default "open" handler in Windows for the specified file extensions yourself.  This can usually be done by opening a folder from My Computer, selecting "Folder Options" from the "Tools" menu, clicking on the "File Types" tab, and then editing the entry for the file type in question.

When you double-click a file with a matching extension, it is extracted to a temporary file and handed to the external viewer.  When you exit CiderPress, all of the temporary files created in this manner are deleted.  If an external viewer still has the file open, it may not be possible for CiderPress to remove it.  The file will eventually be removed by the Windows disk cleanup feature.


Preferences - Compression
Compression Preferences

You can access the Compression Preferences by selecting "Preferences..." from the "Edit" menu, and then clicking on the "Compression" tab.

This screen lets you choose the default compression method.  This will be used for all files added to an archive, and will be the default choice when you ask CiderPress to re-compress files.  It's also used by the disk image conversion tools.

The compression algorithms are described in detail here.


ShrinkIt's "Dynamic LZW/2" compression, first introduced in GS/ShrinkIt.  A combination of RLE and 12-bit LZW.  Slightly more efficient than LZW/1, this algorithm is well-supported on the Apple II.


ShrinkIt's "Dynamic LZW/1" compression, part of the original ShrinkIt.  A combination of RLE and 12-bit LZW.


Do not compress files.


The "SQueeze" format was popularized under CP/M by the "sq" and "usq" commands, which created ".QQ" files.  Commonly used as part of the Binary II application "BLU" to create .BQY files.  Generally inferior to LZW, it was rarely used once ShrinkIt was released.  Supported in NuFX archives by all versions of ShrinkIt, but due to program bugs only GS/ShrinkIt can actually unpack it.


This creates the same output as UNIX "compress", one of the early LZW compressors, restricted to 12-bit codes.  First introduced in the original NuLib utility, this format is supported by NuLib, NuLib2, and GS/ShrinkIt.


Like LZC-12, but with 16-bit codes.  Performs better than 12-bit LZW, but the improvement is only noticeable on larger files.


The "deflate" algorithm from zlib is used in ZIP archives, gzip ".gz" files, PNG graphics, and is defined by an Internet RFC.  It is currently one of the most common ways to compress data.  Its compression performance is considerably better than LZW, but support on the Apple II is limited.  Its use was first defined as a NuFX extension in NuLib2 v1.1.


The "bzip2" program uses the Burrows-Wheeler Transform (BWT) compression method.  It's slower and more memory-intensive than "deflate", but it does exceptionally well on large sets of text files or source code.  Support on the Apple II is nonexistent.  Its use was first defined as a NuFX extension in NuLib2 v1.1.


Choose Folder

This allows you to choose a folder on a local disk or across a network.  Click on the folder you want in the "tree" display, then click "Select".  Click on '+' signs to expand branches of the tree, '-' signs to collapse branches.

The full name of the folder that is currently selected is shown in the grey box underneath the tree.  Some folders, such as "My Computer", are special and do not have a pathname.  When these are selected in the tree, the "Select" button will be dimmed.

If you know the full pathname of the folder you want, you can type it in where it says "type the folder name" and then click on "Expand Tree".  The folder you entered will be selected in the tree.

If you click on the button next to the grey box (looks like a folder with a star in the upper right corner), CiderPress brings up the "New Folder" dialog.  This allows you to create a new folder inside the currently-selected folder.


Extracting Files

If you only want to extract a few files, select them from the file list before clicking on "Extract...".  Selected subdirectories are ignored; only plain files are examined.

The extraction options dialog presents a large set of choices.  If you find the range of options bewildering, you may want to walk through the tutorial on the faddenSoft web site.  The Quick Configuration buttons, described later, can simplify common tasks.

Files to Extract

You may choose to extract the files selected in the file list, or all of the files in the archive or disk image.  If no files have been selected, "all files" will be the only option available.

Parts to Extract

You can further refine your selection by choosing to extract only certain kinds of entries.  You will almost always want to leave "data forks" and "disk images" enabled, unless you have an archive that is a mixture of the two.  "Disk images" refers to ShrinkIt-archived disk images (the file type is listed as "Disk"), not disk images stored as files.

If you just want to view the contents of the files under Windows, there's usually not much value in extracting the resource forks.

Attempting to extract a ProDOS subdirectory file (type "DIR") will not work.  You can examine them as raw data in the file viewer, but extracting them as raw data doesn't make much sense.  Instead, folders are automatically created as they are needed.

Format Conversion

Two options are available.  If you select "Convert to non-Apple II formats", then files will be converted in the same way they would when viewed with the file viewer.  For example, BASIC programs will be converted to TXT or RTF files, and graphic files are extracted as Windows bitmaps (BMP).  The individual converters can be turned on and off from the file viewer preferences page.  Files without specific conversions are treated as text or binary data according to the rules specified in the "text conversion" options (described below).

The "Extract disks as .2MG" selects whether disk images in NuFX archives are extracted to ProDOS-order ".PO" files or Universal Disk Format 2IMG files.  The latter is generally preferred for use with Apple II emulators because the format contains some useful information about the disk image.

Filenames

There are a couple of ways to tweak the filenames.  Selecting "Add file attribute preservation" will extend the filename with an attribute preservation sequence, and will replace any characters not legal in Windows with "%xx" codes.  This can be used to restore the file type, aux type, original filename, and whether the file holds a data fork, resource fork, or disk image.  More detail can be found here.  This setting is useful when you plan to add the files back into an archive.

The "Add type extension" option adds a three-letter extension to files that lack one.  For example, any file of type TXT will be given a ".TXT" extension so that you can open the file with Notepad by double-clicking on it.

The filename alterations that affect the list view, such as converting filenames to lower case or replacing spaces with underscores, are also taken into account here.  These are configured in the General Preferences screen.

Text Conversion

Text files on the Apple II have carriage returns (CR, ASCII code 13) at the end of each line.  UNIX and its derivatives use linefeeds (LF, ASCII code 10), and Windows prefers a carriage return followed by a linefeed (CRLF).  CiderPress can convert these "end-of-line markers" to CRLF so that Windows applications can read the files.

Not all files of type TXT are text files, and not all text files have type TXT, so CiderPress can try to sort things out for you.  There are four settings for end-of-line conversion: off, by file type, automatic scan, and on.  When it's set to "off", nothing is converted; when it's "on", everything is converted.  If you select "Convert text files by file type", only files of type "TXT" or "SRC" are converted.  In the "Auto-detect & convert files with text" mode, CiderPress will scan each file and convert the ones that look like text files, regardless of file type.

Apple DOS 3.3 complicates matters somewhat with "high ASCII" text files.  These look garbled unless the high bit of every byte is stripped.  However, stripping every text file would cause Apple IIgs documents with "smart quotes" and accented characters to appear damaged.  CiderPress only strips the high bits if the end-of-line converter is also enabled, and does so only on DOS 3.3 text files or on text files that are entirely composed of characters with the high bit set.  (The "strip high ASCII text files" option is dimmed when "don't convert text files" is selected.)

Archived disk images (e.g. "Disk" entries in a ShrinkIt Archive) never undergo text conversion, even when "Convert ALL files" is selected.  Neither do resource forks.

Miscellaneous

Two options that you may find useful.  These are not affected by the Quick Configuration buttons.

"Strip folder names" reduces the pathnames shown in the list to just their filenames.  Everything you extract will end up in the same folder.

If you select "Overwrite existing files", you will not be asked to confirm overwriting of files with the same name as files being extracted.

Quick Configuration Buttons

There are two large buttons at the bottom of the dialog that allow you to choose from the two most common configurations.  Pressing the buttons just changes the state of the controls in the dialog.  There are no hidden options or side-effects.

"Configure to preserve Apple II formats" is useful when you want to extract files from one archive and add them to another.  Resource forks are extracted, file attribute preservation is enabled, and format converters (including text conversion) are disabled.  These files will most likely not be readily usable under Windows, so file extensions are not added.

Click on "Configure for easy access in Windows" when you want to extract files for viewing under Windows.  File viewer and text converters are enabled, and file extensions are added where appropriate.  Disks are extracted in 2MG format.

Other Notes

Extracting a file that already exists brings up a small dialog that lets you choose whether or not to overwrite the file.  You can choose to overwrite it, skip it, overwrite it and all other conflicting files, skip it and all other conflicting files, rename the file being extracted, or cancel the whole thing.

"Damaged" files will not be extracted.


Enter the name of the file to open exactly as it appears in the CiderPress file listing.  This means including all path names, separated by ':', and converting ':' to '_' when it's used in a filename.

If the file is in a DOS 3.3 sub-volume (e.g. it starts with "_DOS001:"), you will need to open the sub-volume first and then open the file from there.


Add Files Dialog
Add Files

Use this feature to add files to a disk image or ShrinkIt archive.  This dialog is similar in many ways to the standard Windows "open file(s)" dialog, but it has been customized to allow you to select folders as well as files.

Select the files and folders you want to add, then click on "Accept".  You can click on a file and then shift-click on another to select a range of files.  Use control-click to select or unselect a single file in a group.  Double-clicking a file immediately selects that file and starts the "add files" process, while double-clicking a folder simply opens the folder.

(The differences from the standard Windows "open files" behavior may occasionally cause confusion.  For the most part you shouldn't notice anything unusual.  Just remember that clicking on "Accept" will add everything selected, including folders.)

CiderPress tries to ensure that all files you select are added without conflicting with each other.  For example, if you add "ReallyLongFilenameA" and "ReallyLongFilenameB" to a ProDOS disk, it will add them as "ReallyLongFilen" and "ReallyLongFile1".  CiderPress will try to preserve filename extensions, so "ReallyLongFileName.c" becomes "ReallyLongFil.c".

The dialog has a few options you can change, described below.

File attribute preservation

Use this to decide whether CiderPress will accept or ignore file attribute preservation sequences in filenames.  If a file was extracted with tags (strings that look like "#062000"), they will be used to determine the file type and fork of the file being added.  Also, any characters that were invalid in Windows filenames and had to be changed to "%xx" sequences will be converted back.

If the option is set to "Ignore file attribute preservation tags", CiderPress will act as if it has never heard of the things.  Files will be added as type NON, and the "#062000" and "%xx" stuff will be added exactly as it appears on disk.  You should only use this when adding files that have '#' or '%' characters that are confusing CiderPress.

If the option is set to "Use file attribute preservation tags", CiderPress will use them whenever it finds them.  If it doesn't find them, the file will be added with type NON.  This is the default setting.

The "Use tags and guess type from extension" goes a little farther, and tries to set the ProDOS file type based on the Windows extension.  For example, ".txt" files will be added with type TXT, and ".shk" files will become $e0 with auxtype $8002.  This is very useful when adding files to DOS 3.3 disks, because it ensures that ".txt" files get file type 'T'.  Without this, ".txt" files will be added as 'B'.  Use this option if you are adding files that weren't generated on an Apple II, like Windows text files or graphics.

Text conversion

This option allows you to convert text files from Windows text conventions (carriage return followed by linefeed at the end of each line) to Apple II conventions (carriage return at the end of each line).  Due to limitations in the NufxLib library -- as well as philosophical concerns about altering archived files -- the feature is disabled when adding files to ShrinkIt archives.  It's enabled for disk images only.

You have four choices.  The most basic are "Don't convert text files", which adds every file exactly as it is, and "Convert ALL files", which converts all EOL markers found in every file.  The "convert all" option is generally not recommended, because it will try to convert non-text files, potentially rendering them unusable.

The "Convert text files by file type" option will convert anything added as "TXT or "SRC", and leave everything else alone.  The file type is determined based on the file attribute preservation setting (discussed above).  If CiderPress is configured to ignore attribute preservation tags, files will be added with type "NON", which does not undergo a text conversion with this setting.

When "Auto-detect & convert files with text" is selected, CiderPress scans the file to see if it appears to be text.  The file type is ignored.  This can be helpful, because it'll convert Windows files with names like "README" or old documents called "file.doc".  (It was common practice to name text files ".doc" until Microsoft Word claimed that extension.)

If CiderPress gets the auto-detection wrong, delete the files, and re-add the files that didn't work, setting the conversion to be always off or always on.  (Tip: if you delete the bad ones, you can re-add the entire set, and when asked if you want to overwrite an existing file, say "no to all".  That way you don't have to hand-select just the files to re-add.)

There is a small performance boost when text conversion is turned off.  If you're adding files that previously came out of an Apple II disk image, and no text conversion was performed during the extraction, turn text conversion off when adding files.  Conversely, if you're adding text files or source code that you've been editing under Windows, set it to "by type" or "auto".

Resource forks are never converted, regardless of their contents and the current settings.  Any file added to a DOS disk that is identified as text will also be converted to "high ASCII".

Miscellaneous

If "Include subfolders" is checked, then CiderPress will descend into any folders you have selected, adding files found in them and descending into their sub-folders.  If it's not checked, only files in the current directory will be added.  You will usually want to have this checked.

If you decide you don't want folder names, check the "Strip folder names" box.  This removes the folder names, effectively putting all files into the same folder in the archive.  This option is enabled automatically when adding files to DOS 3.3 and Pascal disks, which don't have folders.

The "Overwrite existing files" setting will cause any entries with the same name (case-insensitive) as a file being added to be overwritten by the newly-added file.  If this box is not checked, you will be presented with the option of overwriting the existing file, skipping the add of the new file, or renaming the new file.  (The option to rename the file being added is not available for ShrinkIt archives, because NufxLib doesn't support it.)

Storage prefix

This option is only available when adding to a ShrinkIt archive.  Anything you put here will be prepended to the filename stored in the archive.  The reasons for doing this may not be immediately obvious.

Suppose you want to add a file called "foo" to an archive.  If you move to the folder with "foo" in it, select it, and click on "Accept", it will be added to the archive as "foo".  This is fine, unless you want it to appear in the same sub-folder in the archive as other files.  Perhaps you have a file called "bar" stored as "dir1:subdir2:bar", and you want "foo" and "bar" to be extracted to the same place.

You could create a folder called "dir1" under Windows, and then create another folder called "subdir2" in that, and then put "foo" in that folder, and finally have CiderPress do an Add Files on "dir1".  If you put "dir1:subdir2" into the Storage Prefix box, and then just add "foo", you will get exactly the same result -- files added as "dir1:subdir2:foo" -- with significantly less effort.

(You could, in this case, just add "foo" and then use the Rename Entry feature to change the pathname, but that becomes tedious when a large set of files is involved.)


Rename Entry

This feature is disabled when an archive or disk image is opened in read-only mode.

Select one or more files to rename, then activate the "Rename..." command.  A dialog opens for the first file.

The grey edit field on the top is the current name of the file.  The edit field on the bottom is the name to change the file to; it defaults to the current name of the file.  The box labeled "Path separator character" shows the character used to separate pathname components from each other in this specific file.  This requires a little explanation.

If you have a folder "subdir", in which is a file called "foo", you would access it as "subdir\foo" under Windows.  Under UNIX or ProDOS 8 you would use "subdir/foo", and under GS/OS you would write "subdir:foo".  CiderPress follows the GS/OS convention, so pathnames from disk images and in files archived by CiderPress always use ':'.

Suppose you tried to extract a file called "subdir/foo:bar".  On a UNIX system this would be a folder called "subdir" with a file called "foo:bar" in it, but on an HFS filesystem that would be a folder called "subdir/foo" with a file called "bar" in it.  ShrinkIt archives were intended to be multi-platform, so the format requires the application adding the file to specify the value for the separator.  Most archives use '/' or ':', but a few use '\'.

This is important to understand because, when renaming files in a ShrinkIt archive, you're not just changing the filename, you're changing the entire pathname.  You can effectively move a file into a different subdirectory by renaming "subdir1:foo" to "subdir2:foo".  You need to be aware that the path separator character isn't always the same for every file.

You can change the path separator character for files in NuFX archives.  The NufxLib library used by CiderPress currently does not allow a null value for the separator, so if you try to delete the character altogether, CiderPress will substitute ASCII value 0xff, which looks like a 'y' with an umlaut under Windows.  This value can also appear for files copied & pasted from DOS disk images.  This behavior may be corrected in a future release of NufxLib.

If you're renaming a file on a disk image, you will be shown the full path but can only change the file name.  (There is currently no way to "move" a file to a different subdirectory, but you can copy and paste the file to a new folder if the disk has sufficient space.)

After choosing the new name, press "OK" to accept it.  The dialog will update to show the name of the next file in the list.  If you decide you don't want to rename this file, you can either click on "Skip" to move on to the next entry or "Cancel" to drop out of the process.

ShrinkIt stores disk images with the disk volume name, not a pathname.  For this reason, the filename separator character cannot be part of a disk image name.

If you have one of the filename alterations enabled, such as conversion to lower case or replacing spaces with underscores, you will be shown the name with the modifications already made.  If you press "OK", the alterations will become a permanent part of the archive, and will not go away when you turn the alterations off.  You may want to switch these off before renaming entries.

The aux type of AppleWorks files is not updated in ShrinkIt archives when the filename changes.  (The aux type is used as lower-case flags.)  This may result in strange-looking filenames when the contents are extracted to a disk image.  The lower case flags are set appropriately when AppleWorks files are renamed on a disk image, even if the ProDOS "allow lower case" preference is turned off.

You cannot rename the volume directory of a ProDOS or HFS volume.  Attempts to do so will be silently ignored.  Use the Rename Volume command instead.

Some HFS files may have strange characters in the filenames.  These are "Macintosh Roman" characters that don't translate directly to Windows equivalents.  The names in the file list are "sanitized", with characters like '¥' converted to simple letters and numbers, but when renaming a file the name is presented unmodified.


Edit Comment

This feature only works for NuFX archives, because that is the only Apple II format CiderPress supports that allows file comments.  It will be disabled for archives opened read-only.

To add, edit, or delete a comment, select the entry you want to modify.  You may only select one entry at a time.  Activate the "Edit comment..." command.  If the entry does not already have a comment attached, you will be asked if you want to add one.

The dialog that appears allows you to edit the text of the comment or delete it entirely.  If you hit "Cancel", your changes will be discarded.

Comments in NuFX archives use a "pre-sized" buffer.  For example, when GS/ShrinkIt adds files or disks to an archive, the first entry has space set aside for a 200-character comment.  The idea was to allow comments to be updated without having to shift lots of data around to make room.  This space is allocated by GS/ShrinkIt whether you choose to write a comment or not.  Any comments you add with CiderPress will also be "over-sized".

If you enable the "Mimic ShrinkIt" feature on the General Preferences screen, CiderPress will behave like GS/ShrinkIt and add an empty comment to the first entry whenever you add files or disks to an archive.


Edit File Associations

CiderPress can be "associated" with file types, meaning that when a file with an associated extension is opened (usually by double-clicking on it from Windows Explorer), CiderPress is launched to handle it.  The recognized extensions, and the default behavior when opening them, are listed here.

When CiderPress is first installed, all recognized extensions that do not already have an association are linked to it.  You can use this dialog to associate or disassociate any of the file types by clicking in the checkbox next to the extension.

This dialog changes the settings but does not make them permanent.  Hit "OK" or "Apply" in the preferences pages to actually make the update, or "Cancel" to undo the changes.


Appendix - File Extensions
File Extensions

CiderPress handles a variety of Apple II file and disk image formats.  If you associate these files with CiderPress, opening the documents (perhaps by double-clicking on them from Windows Explorer) will launch CiderPress automatically.

Some files can be interpreted in more than one way.  For example, ".BXY" files are ShrinkIt archives wrapped in a Binary II header.  The file selector you choose in the "Open File" dialog determines how the file is opened.  When double-clicking on a file, however, you don't have an opportunity to make a choice, so CiderPress tries to guess which way you wanted.  The same applies when opening a file with the selector set to "All Files (*.*)".

The following table summarizes the types handled and the method of handling them.

Ext	Description	Default Action
.2MG	2IMG disk image	Open as disk image
.APP	Disk image in TrackStar nibble format	Open as disk image
.BNY	Binary II	Open as Binary II
.BQY	Compressed Binary II	Open as Binary II
.BSE	GSHK Self-Extracting Archive, wrapped in Binary II	Open as NuFX
.BXY	NuFX wrapped in Binary II	Open as NuFX
.DDD	DDD-compressed disk	Open as disk image
.DO	DOS-order disk image	Open as disk image
.DC6	DiskCopy 6.x image	Open as disk image
.DSK	Disk image (often DiskCopy 4.2)	Open as disk image
.GZ	Disk image compressed with gzip	Open as disk image
.HDV	Raw disk image	Open as disk image
.IMG	Disk image (usually Copy ][+)	Open as disk image
.PO	ProDOS-order disk image	Open as disk image
.RAW	Raw disk image	Open as disk image
.SDK	NuFX disk archive	Open as disk image
.SEA	GSHK Self-Extracting Archive	Open as NuFX
.SHK	NuFX file or disk archive	Open as NuFX
.ZIP	Disk image compressed with ZIP	Open as disk image
(none)	File with no extension	Open as disk image

If the default handler fails, the file will not be opened.

DiskCopy 6 can create images in a "raw" format or with fancy headers.  CiderPress only handles the "raw" form.

CiderPress does not create file associations for .RAW because there are many other PC file formats that use the same extension.  A similar exclusion is made for .GZ and .ZIP, because the extension only indicates that "gzip" or "zip" was used to compress the file.  It doesn't say anything about the contents.


How (and Why) to Register

Registration is no longer required.


Features

CiderPress is a fully-functional "ShrinkIt for Windows" that can operate on disk images and file archives.  Files can be viewed or extracted in their native form, or converted to formats better suited for browsing in Windows.

When working with NuFX (ShrinkIt) archives and DOS 3.2/3.3, ProDOS, HFS, and UCSD Pascal disk images, you can:

•	View files without having to extract them first.  Special converters are provided for several popular file formats.

•	Extract files and directories, optionally converting them.  File type information can be preserved, using the method developed for use in NuLib2.

•	Add individual files or entire directories full of files.

•	Copy & paste files through the Windows clipboard.

•	Rename files.

•	Delete files or entire subdirectories.

•	Edit file type, auxtype, and access permissions of ProDOS files.

•	Print a listing of the files in the archive.

On NuFX archives, you can also:

•	Convert a ShrinkIt file archive directly to a ProDOS disk image.

•	Re-compress entries with a different algorithm.  All compression methods defined in the NuFX specification are supported, as well as gzip "deflate".

•	Add, update, and delete comments.

•	Test entries or whole archives.

On disk images, you can also:

•	Create subdirectories.

•	Change volume names and numbers.

Read-only access (viewing and extracting files, but not adding or deleting) is supported for Binary II archives, AppleLink Compression Utility archives, and CP/M and RDOS disk images.

The file viewer can convert several formats for easier viewing on a PC:

•	ProDOS text with carriage returns to Windows "CRLF" format.

•	DOS 3.3 "high ASCII" text to plain text.

•	CP/M text to plain text.

•	UCSD Pascal text to plain text.

•	UCSD Pascal code to partially analyzed hex dump.

•	Applesoft BASIC to text (matches output of "LIST" command), with or without color syntax highlighting.

•	Integer BASIC to text (matches output of "LIST" command), with or without color syntax highlighting.

•	Apple /// Business BASIC to text (matches output of "LIST" command), with or without color syntax highlighting.

•	S-C Assembler to text.

•	LISA tokenized assembly source to text.

•	Merlin assembly source to properly-tabbed text.

•	65C02/65816 code disassembly, to //e or IIgs "monitor" output.

•	Magic Window / Magic Window II "formatted" files to text.

•	AppleWorks Word Processor to Rich Text Format (supports left/right margins, bold, italic, etc).

•	AppleWorks Database to CSV (suitable for import into Excel or other applications).

•	AppleWorks Spreadsheet to CSV.

•	Teach (GWP $5445) document to Rich Text Format.

•	AppleWorks GS Word Processor (GWP $8010) to Rich Text Format.

•	Hi-Res graphics to 560x384 16-color .BMP (B&W or color with half-pixel shifting).

•	Double Hi-Res graphics to 560x384 16-color .BMP (B&W or color).

•	Super Hi-Res graphics to 640x400 256-color .BMP.  Supported formats include unpacked ($c1/0000), Paintworks ($c0/0000), packed ($c0/0001), DreamGrafix ($c0/8005), and Apple Preferred Format ($c0/0002) up to 1024x1024.

•	3200-color Super Hi-Res graphics to 640x400 24-bit .BMP.  Supported formats include unpacked ($c1/0002 or ".3200"), packed (".3201"), DreamGrafix ($c0/8005), and Apple Preferred Format ($c0/0002 with "MULTIPAL").

•	Print Shop and Print Shop GS graphics to 88x52 .BMP (B&W and color, respectively).

•	Macintosh Paint images to 576x720 2-color .BMP.

•	Apple IIgs resource forks are split into individual resources and displayed as hex dumps.

In addition, any fork of any file can be viewed in its "raw" state or as a hex dump.

CiderPress has the ability to identify most common disk image formats, and view or extract files directly from them.  Supported file formats include:

•	Universal Disk Images (.2mg), all formats

•	DiskCopy 4.2 (.dsk)

•	Copy II Plus (.img)

•	Sim //e HDV images (.hdv)

•	TrackStar images (.app)

•	Dalton's Disk Disintegrator (DDD 2.1+, DDD Pro 1.1+) (.ddd)

•	FDI "raw" images of 5.25" and 3.5" disks (.fdi)

•	Unadorned sector-format files (.po, .do, .d13, .raw, .hdv, .iso)

•	Unadorned nibble-format files (.nib, .nb2)

•	Any of the above compressed with gzip (.gz)

•	Any of the above compressed with zip (.zip)

•	ShrinkIt (NuFX) compressed disk images (.shk, .sdk)

The file format, filesystem, and sector ordering are determined automatically for most disks.  The settings can be overridden if necessary.  The recognized disk formats are:

•	DOS 3.2/3.3 (13, 16, or 32 sectors, up to 50 tracks)

•	ProDOS

•	HFS

•	UCSD Pascal

•	CP/M

•	SSI's RDOS (13-sector, 16-sector, and 13 converted to 16)

•	UNIDOS / AmDOS / OzDOS (two DOS volumes on an 800k disk)

•	ProSel Uni-DOS / DOS Master (DOS volumes embedded in an 800K ProDOS disk)

•	CFFA fixed-size partitions (4-part and 8-part formats)

•	Macintosh-style partitoning (for CD-ROMs and SCSI hard drives)

•	///SHH Systeme MicroDrive partitioning

•	FocusDrive partitioning

Images larger than floppies, such as ProDOS hard drive partition images, are fully supported.  Physical media, including floppy disks, CD-ROMs, CFFA-formatted CompactFlash cards, and SCSI hard drives can be accessed directly (assuming you have appropriate hardware).

CiderPress includes a collection of tools:

•	Disk viewer - view disk images as blocks, sectors, or nibblized tracks.

•	Disk image converter - convert disk images from one format to another.  Can operate on individual images or perform a bulk conversion on a large set.

•	Disk image creator - create bootable DOS 3.3, ProDOS, or Pascal disk images from scratch.

•	Volume copier - copy all or part of a disk image from one place to another.

•	SST image merge - combine images generated by SST into a single .nib image file.

•	2MG properties editor - edit comments, lock/unlock images.

•	EOL scanner - check for ASCII transfer damage.

•	Import from WAV - extract programs from Apple II cassette tapes.


Available Commands

If you've used other file archive software, such as WinZip or WinRAR, then you already know most of what you need to know to use CiderPress.  There are some differences, mainly because CiderPress is optimized for use with Apple II files.

Things you can do:

Selecting the command you want.

Opening, closing, and creating archives and disk images.

Opening raw disk volumes.

Getting information about an archive.

Working with the file list.

Printing the file list.

Viewing the contents of files in an archive or disk image.

Adding files and disk images to an archive.

Creating new subdirectories.

Extracting files and disk images.

Copying and pasting files.

Testing entries in an archive.

Renaming entries.

Renaming disk volumes.

Deleting entries.

Editing archive comments.

Editing attributes of archived files.

Convert disk image to file archive.

Convert file archive to disk image.

Import files from Apple II cassette tapes.

Import BASIC programs from text files.

CiderPress has some additional tools that you may find useful:

Disk sector viewer.

Disk image converter.

Bulk disk image converter.

SST image merge.

Volume copier.

2MG properties editor.

End-Of-Line scanner.

There are several screens of preferences:

General preferences.

Disk Image preferences.

Default compression selection.

File viewer settings.

File and folder locations.


Entering Registration Data

After you register CiderPress you will receive an e-mail message with your registration code.  Copy the information from the message exactly as it appears.  Upper-case vs. lower case is important, as is all punctuation.  Don't forget to put the hyphens ('-') in when typing the registration key.

The easiest way to fill the fields out is to cut and paste directly from the registration message.  Copy the text from the message, click in the appropriate field in the CiderPress dialog, and hit Ctrl-V to paste it.

As you paste or type the text in, you will see the four-character "checksum" value change.  Make sure the checksum shown in your confirmation letter matches what you see on screen.  If they don't match, something has been mis-typed.  (If you're cutting & pasting, make sure you don't accidentally paste the checksum values into the box.)

When you hit "OK", CiderPress will verify your key.  If all fields have been entered correctly, you will return to the "About" box with your name and company shown, and the "Enter registration code" button will be disabled.


Working With the File List

After an archive or disk image is successfully opened you will be presented with a list of files found inside.  The list is divided into several columns:

Pathname

File type

Aux type

Modification date

Format

Size

Ratio

Packed size

Access

Columns can be hidden or returned to default sizes with buttons in the preferences screens.  You can resize them by clicking and dragging on the space between items in the column header.  Hide columns by shrinking them down until they disappear.

Any column can be sorted.  Click on the column header once to sort on that column.  Click on it a second time to change the direction of the sort.  You can also use the "Sort" feature in the "Edit" menu to choose a column to sort on, or choose to return to the original order of the files.

Column widths and sort order are retained across invocations.  If you change the screen font sizes with the Windows "appearances" settings, use the "Defaults" button in the preferences screen to adjust the widths for the new font size.

Select entries in the list by clicking on them.  To select multiple entries, click on the first item and then shift-click on the last item.  You can control-click to add or remove items from the selection list.  To select all items, type Ctrl-A, or use the "Select all" function from the "Edit" menu.  The "Invert selection" feature selects everything that isn't selected, and un-selects everything that is.

Double-clicking on most items will immediately bring up the file viewer.  Double-clicking on ShrinkIt archives, Binary II archives, or archived disk images will cause the file to be copied into the temp folder and opened in a new instance of CiderPress.  (The opened copy will be marked read-only because the file in the temp folder is thrown out as soon as CiderPress exits.)

If you double-click on multiple files (click, hold the shift key down, then double-click), the file viewer is opened for all of them regardless of what they contain.

Right-clicking brings up an abbreviated "actions" menu.

You can search for entries in large archives or disk images with the "Find" feature.  Hit Ctrl-F, or select "Find" from the "Edit" menu.  You can make the search case-sensitive if you like, and if you select "whole words" it will only match complete filenames or filename components.  The search begins from the currently selected item, and wraps around when it reaches the end of the list.


Opening, Closing, and Creating Files

Open an archive or disk image by selecting "Open..." from the "File" menu.  Select the file to open, and click the "Open" button.  All of the standard Windows "open file dialog" features work here.  For example, if you want to change the current folder to "C:\apple2\disks", you could navigate there by selecting "C:" from the drop-down menu and then double-clicking on the "apple2" folder and then the "disks" folder.  A perhaps faster approach is to click in the "File name:" box, type "C:\apple2\disks", and hit return.

The class of files you select in the "Files of type:" box does more than just choose which files you get to see.  In some cases, it determines how the file is opened.  For example, a .BXY file is a ShrinkIt archive with a Binary II header.  If you select "ShrinkIt Archives" or "All Files", the file will be opened as a ShrinkIt archive.  If you select "Binary II Archives", the file will be opened as a Binary II archive (with a single ShrinkIt archive inside).  The same applies to ShrinkIt archives with a single disk image in them.  They can be opened either as ShrinkIt archives or as disk images.

You may want to examine the default behavior defined for each file extension when double-clicked from Windows Explorer or opened with "All Files (*.*)".

If you select "Open as read-only", the file will be open in read-only mode.  This means that operations that modify the file, such as adding, deleting, or renaming files, will be deactivated.  The file will automatically be opened in read-only mode if the file itself is marked "read only" in Windows.  (You can change this setting before opening the file by right-clicking on the filename, selecting "properties", and un-checking the "Read-only" box.)  Disk images that appear to be damaged will also be opened in read-only mode to prevent modifications from exacerbating problems.  You can check for damage with the Archive Info feature.

CiderPress can open disk images stored in gzip (.gz) or Zip (.zip) archives, so long as the archive contains only one file, and the file is 32MB or less when expanded.  Because the disk image is uncompressed to memory, CiderPress does not handle compressed images larger than 32MB.  Also, ShrinkIt archives inside Zip or gzip archives cannot be opened.  You can extract them with a program like WinZip or by enabling "compressed folder" support in Windows XP.

You can create a new, empty ShrinkIt archive by selecting "New -> ShrinkIt archive..." from the File menu.  The archive is created immediately.  If you close the archive while it is still empty, the file will be removed.  You can create disk images with the "New -> Disk image..." function.

In most cases, any changes you make to a file archive or disk image happen immediately.  If you're working with a compressed disk image, stored in a ShrinkIt, ZIP, or gzip file, the image isn't recompressed until you close it.  You can flush the changed data sooner by using the "Save changes" menu item.  This will automatically be invoked for you if you use one of the tools that can modify disk images (e.g. the volume copier).

Close the current archive or disk image with "Close" from the File menu.  You won't often need to use this, since the files are closed automatically when a new file is opened or the program exits.

Changes made to an archive or disk image by another program, such as an Apple II emulator, will not be detected automatically.  For example, if you add or delete files from a disk image with Copy ][+ in an emulator, you will need to close and re-open the file.  The easiest way to do this is with the "Reopen" command in the File menu.


Selecting Commands

There are three distinct ways to perform actions:

1. Select a command from the menu at the top of the screen.

2. Select a command from the toolbar below the menu.

3. When a file is open, right-click and select a command from the menu that pops up.

All three approaches produce the same results.

There is a fourth way to initiate action: double-click on an item in the file listing.  The exact behavior depends on what it is you clicked on.  See Working With the File List for details.

Most features will be disabled unless an archive or disk image is open.  Some will be disabled until you select one or more entries from the list.  Some are only active for ShrinkIt archives, or will be dimmed if the file is opened read-only.


Printing

The output sent to the printer looks very much like the file list when all columns are enabled.  The sort order matches the current file list.

Select "Print..." from the "File" menu to bring up a standard Windows print dialog.  Choose your printer and, optionally, a range of pages to print.


Viewing Files

To use the "View..." command, first select the files you want to view.  Select the "View..." menu item or click on the toolbar button.  The File Viewer opens.

Double-clicking on most kinds of files will open the file viewer.  However, if you double-click on a ShrinkIt archive or disk image, a new instance of CiderPress will be launched with the file displayed in it.  (You can get the same behavior with disk images by selecting the image and then using "Open as disk image" from the Actions menu.)


Adding Files and Disks

Add files and folders to an archive by selecting "Add files..." from the "Actions" menu.

In most cases you will immediately be asked to choose the files you want to add.  See the explanation of the "Add Files" dialog for details on what to do next.

If you're adding files to a ProDOS disk that has subdirectories, or to an image with sub-volumes (e.g. CFFA or Macintosh partition image), you will need to select which disk and which subdirectory you want to add files to.  There are two ways to do this.

•	The first way is to click on the name of an existing subdirectory, or the ProDOS volume directory.  If CiderPress sees that you have a single subdirectory selected, or if there's only one place the files could possibly go, the files will be added there.

•	If you don't have a subdirectory selected, and there's more than one place where files could be added, you will be given the opportunity to choose the location from a tree of possible locations.

In either case, the subdirectory chosen will show up in the "storage prefix" box in the next screen.

Files added to a ProDOS disk get file type "NON" and auxtype $0000 unless one of the file attribute preservation options is enabled.  DOS 3.3 disks get file types in a similar way, but files that aren't 'A', 'I', or 'T' will be set to type 'B'.  Any non-text file over 64K will get file type 'S'.

All files added to a Pascal disk get the "PDA" type (Pascal Data file), unless they have a ProDOS type that matches one of the Pascal values.  (Text files added to a Pascal disk become PDA, not PTX.  This may change in a future release.)  Some parts of the UCSD Pascal system rely on the filename suffix rather than the file type, e.g. "file.text" vs. "file.code", so changing the file's type may not have an effect on some applications.

Disk images added to a ShrinkIt archive are added one at a time.  If the disk image format can't be determined, you will be asked to specify the details on a "disk image characteristics" dialog.

If an entry already exists, you will be given the opportunity to decide if you want to overwrite it.

When adding "forked" files, you need to add the data and resource forks at the same time.  If you try to add them in two steps, CiderPress will assume that they are parts from different files that happen to have the same name, and will offer to replace the existing file with the new one instead of combining the two together.

Tip: if disk images were extracted with file attribute preservation enabled, they can be added en masse using the "Add files..." mechanism.  Just tell CiderPress to make use of the preservation sequences, and the disk images will be detected automatically.


Testing Archives

This feature does not work on disk images, because they don't have any sort of checksum or CRC on the files.  Every file on a disk archive is scanned when the disk is opened, and any obviously damaged files are labeled as such in the file list.

Files in ShrinkIt, Binary II, and AppleLink Compression Utility archives can be tested, but not all of those have CRCs either.  In those cases CiderPress will read the data to verify that the archive hasn't been truncated.  Errors in compressed data can sometimes be detected without a CRC.  The overall structure of the archive, including any CRCs on header fields, is verified when the archive is opened.

For files that do have checksums or CRCs, CiderPress will use the appropriate error detection algorithm, uncompressing the data when necessary.  Testing an archive essentially does a full extraction, doing everything except write the data to disk.


Delete Entries

Use this feature to delete some or all files in an archive or disk image.  Select the files you want to delete in the file list, then activate the "Delete..." function.  When you confirm by pressing "OK", all entries are immediately deleted.

There is no "undo" or "undelete" feature.  The entries you delete are gone forever as soon as you press "OK".  Use this feature with caution.

If you delete all entries from a ShrinkIt archive, and close the archive without adding any new ones, the archive file will be removed.

If you select a folder on a ProDOS disk image, all files in the folder will automatically be selected for you when you click "delete".  You cannot delete the volume directory.


Re-Compress Entries

This feature is only enabled for ShrinkIt archives, because disk images don't have compressed entries and Binary II archives are always opened read-only in CiderPress.

Use this function to change the way files and archived disk images are compressed.  ShrinkIt archives created with ProDOS 8 ShrinkIt or the original NuLib are compressed with "dynamic LZW/1", while archives created with GS/ShrinkIt or NuLib2 are compressed with the slightly enhanced "dynamic LZW/2".  You may want to use the gzip "deflate" algorithm to reduce the size of the files even further.

Be aware that not all compression formats can be unpacked with all software.  The best overall choice is "dynamic LZW/2".  If the files will only ever be opened with CiderPress or NuLib2, you may want to use "deflate".  See the Compression Algorithms page for more information about the algorithms and application compatibility.

Each fork of each file is expanded and re-compressed individually.  The files are read in batches, compressed, and written back out.  If you cancel the process, entries that have previously been written out will remain in their re-compressed state.

At the end of the process a dialog appears showing the size before and after of the files in the archive.


List - Pathname

The full pathname of the file.  In disk archives that don't support folders (DOS 3.2/3.3, Pascal, CP/M, RDOS), this is just the filename.  For ProDOS disks and ShrinkIt archives, the pathname includes all folders out to the "root" of the collection.

The names are usually presented exactly as they appear in the original, but there are a few exceptions:

•	ProDOS names are converted to lower case based on the case flags.  These were added in ProDOS 8 v1.8 to allow the GS/OS FST to put lower case and spaces in names.

•	AppleWorks filenames stored on a ProDOS disk are converted to lower case based on the aux type.  This value overrides the ProDOS flags.  (AppleWorks files stored in ShrinkIt archives are simply presented as they were stored.)

•	The names of files on DOS 3.3 volumes are "sanitized", so that inverse and flashing characters are converted to normal text.

•	If the appropriate preference is enabled, filenames stored on DOS 3.3 volumes are converted to mixed case based on common rules for English titles.  Filenames with lower case in them already -- uncommon but not unheard-of -- are left alone.

•	If the appropriate preference is enabled, all filenames have spaces converted to underscores.  This could be useful for files destined to be served directly from a web site.

The ProDOS volume name is not shown as part of the pathname, except in the entry for the volume directory itself (identifiable as a pathname starting with ':').

There may be one of four icons to the left of the filename.  A document icon that is "empty" (has a white interior) indicates a ShrinkIt archive entry with an empty comment.  Most archives created by GS/ShrinkIt have an empty comment added to the first entry, so this is fairly common.  If the document icon is solid yellow, that means there is a comment with information in it.  This can be viewed with the file viewer or by using the "edit comment" feature.  A red 'X' icon indicates a damaged entry, usually on a disk image.  CiderPress was unable to fully process the file, so it has been marked as unavailable.  A blue '?' icon indicates a suspicious entry; it's not unreadable, but it doesn't look healthy.

Files in a sub-volume, such as a DOS 3.3 disk embedded in a ProDOS disk, are shown as being in a folder (something like "_DOS001").  This is done so that the files will be extracted into a separate folder from the outer-volume content, and also to keep the files grouped together when the file list is sorted by name.


List - File Type

This field displays the ProDOS file type.  Types that don't have three-letter abbreviations assigned are shown in hexadecimal notation.  Archived disk images are listed simply as "Disk".

Forked files are noted with a plus sign ('+') following the file type.  Folders appear with a trailing slash ('/'), and will usually appear as "DIR/".  However, it is possible (but not recommended!) for a folder to have a different file type.

Macintosh files stored in a ShrinkIt archive may be displayed with a 32-bit Mac file type instead.

File types from non-ProDOS disks are converted to the most appropriate type.  The following conversions are used:

DOS 'T'	TXT
DOS 'I'	INT
DOS 'A'	BAS
DOS 'B'	BIN
DOS 'S'	$F2
DOS 'R'	REL
DOS 'A' #2	$F3
DOS 'B' #2	$F4
Pascal Untyped	NON
Pascal Xdsk (bad blocks)	BAD
Pascal Code	PCD
Pascal Text	PTX
Pascal Info	$F3
Pascal Data	PDA
Pascal Graf	$F4
Pascal Foto	FOT
Pascal SecurDir	$F5
Files given "$Fn" types have formats that are not well defined.


List - Aux Type

The auxiliary type of the file.  The exact meaning of this varies depending on the archive or disk image.

ShrinkIt archives: the ProDOS "aux type", or the size of an archived disk image.

Binary II, ProDOS: the value of the 16-bit "aux type" field.  For BIN files this is usually the load address.  For Applesoft BAS files it's the start address of the program.

DOS 3.2/3.3: for 'B' (BIN) the load address is pulled out of the first sector of the file.  For 'A' (BAS) the field is always set to $0801, and for 'I' (INT) and 'T' (TXT) it's always set to $0000.

Pascal, CP/M: set to $0000 for all files.

RDOS: the load address of the file.

ShrinkIt is capable of storing Macintosh files from HFS volumes, in which case the "aux type" field will hold a 32-bit creator type.


List - Mod Date

The modification date of the entry.

ShrinkIt archives use the IIgs "DateTime" format, which includes year/month/day and hours/minutes/seconds.

ProDOS disks and Binary II archives use the ProDOS date format, which has year/month/day and hours/minutes but not seconds.

Pascal disks use the Pascal date format, which has year/month/day but no time.

DOS 3.3, CP/M, and RDOS do not store dates.

When no date is available, "[no date]" is shown.  This is expected on disk images and archives created on systems without clocks.  If the stored date is invalid (e.g. February 31st), it will be shown as "<invalid>".


List - Format

For ShrinkIt archives, this describes the compression format used.  Possible values are described here.

For Binary II archives, this holds a guess at whether the file is stored uncompressed or "squeezed".  There is no 100% reliable way to determine if a file stored in Binary II was squeezed, so a quick examination of the file contents is used to determine the status.

For disk archives, the name of the file system is shown.  This is done to emphasize that files with the same file type may be structurally different on different file systems.  For example, DOS text files use ASCII characters with the high bit set, while ProDOS text files leave the high bit unset.

It's also useful on mixed-filesystem disks, such as ProSel "Uni-DOS" 800K disks that have a 200K DOS 3.3 filesystem embedded in an 800K ProDOS volume.


List - Size

This is the full length of the file when uncompressed and "sparse" blocks filled are in.

The size does not reflect format conversions (e.g. converting a graphic to a BMP) or text conversions (changing end-of-line markers), either of which can result in significantly different extracted sizes.  The size will be accurate only when all conversions are off ("preservation mode").


List - Ratio

This is simply the ratio of  the "Size" field to the "Packed" field.  An uncompressed, non-sparse file is displayed as "100%".


List - Packed

This represents the compressed size of data in a ShrinkIt archive.  The size does not include archive overhead (e.g. storage of the filename, CRCs, and file attributes).

On a disk archive, this indicates the size needed to store the file.  Some files take less space than you might expect because they are "sparse".  On filesystems that support sparse files (ProDOS, and to some extent DOS 3.3), a block filled entirely with zeros isn't actually stored on the disk.  Instead, the file system structure is updated to indicate that there is a gap, and when the file is read the missing data is filled in with zero bytes.


List - Access

This column shows the ProDOS access permissions for each entry.  The letters are:

d - file may be deleted

n - file may be renamed

b - backup needed

i - file is invisible

w - file may be modified

r - file may be read

DOS 3.3 and CP/M only understand "locked" and "unlocked", which correspond to "r" and "dnwr", respectively.  For Pascal and RDOS disks, all files are effectively "unlocked".


Appendix - File Attribute Preservation
File Attribute Preservation

The definitive guide to the file attribute preservation mechanism employed by CiderPress can be found in the "library" section of the www.nulib.com web site.  This is a brief introduction to the topic.

There are four attributes that must be restored when adding Apple II files: file type, aux type, pathname, and file part (i.e. data fork, resource fork, disk image, or comment).

File Type and Aux Type

ProDOS files use an 8-bit file type and a 16-bit aux type.  These can be encoded in a six-character hexadecimal string that looks like "#062000".  The '#' is used to indicate the start of an attribute preservation string.

HFS files with 32-bit file and creator types require more digits, resulting in a 16-character hexadecimal string.

Extracted folders do not have preservation strings added.

Pathname

Some characters, such as '/', are legal in Apple II filesystems (DOS 3.3, HFS) but illegal under Windows.  These are converted to "%nn" sequences, e.g. "foo/bar" becomes "foo%2fbar".

Some words, such as "AUX" and "PRN", cannot be used as filenames under Windows.  These are prefixed with "%00", so "Aux" would become "%00Aux".  (If file attribute preservation is turned off, these will be prefixed with underscores, e.g. "_Aux".)  The "%00" is removed when the file is added.

The complete list of illegal names: CON, PRN, NUL, AUX, LPT1, LPT2, LPT3, LPT4, COM1, COM2, COM3, COM4.  This also affects files that start with the name and a dot, e.g. "AUX.FOO" is also illegal and will be altered.

File Part

HFS and ProDOS support the notion of "forked" files.  This horrible idea has caused problems for users and developers alike since the Macintosh was first released in 1984.  The basic idea is that a file is actually two files with the same name, one of which (the "data fork") has unstructured data such as ASCII text, while the other one (the "resource fork") holds highly-structured data.  Some ProDOS literature refers to these as "extended" files.

Because Windows doesn't handle "forked" files, each fork must be stored in a separate file.  Resource forks are indicated by adding the letter 'r' to the end of the preservation sequences, and disk images have the letter 'i'.  These files are automatically converted back to the correct file part when added to an archive.  If two files have the same name, but the preservation sequences indicate one is a data fork and the other a resource fork, then the two forks will be combined into a single file in the archive.

Other Considerations

The modification date of the original file, if any, can be stored in the local filesystem.  Access permissions aren't completely restored, but they usually don't need to be -- most Apple II files are either "locked" or "unlocked", and that can be encoded in Windows access permissions.

The scheme falls apart somewhat if the generated filenames are longer than Windows can support.  Windows "vfat", "fat32", and "ntfs" filesystems can handle names far longer than any Apple II filesystem, so this should not be a problem.


Appendix - Compression Algorithms
Compression Algorithms

CiderPress supports every compression algorithm listed in the NuFX and Binary II specifications, as well as those listed in the "NuFX addendum" on www.nulib.com.  The actual compression code lives in the NufxLib library, however, and the library can be built with some or all of the compression code disabled.  You can see which algorithms are enabled by going to the Compression Preferences screen.

No compression

Exactly what it says: the contents are not compressed in any way.

Squeeze (sometimes "SQueeze")

This format became popular under CP/M with the "sq" and "usq" commands, which created ".QQ" or ".QQQ" files.  These appeared on the Apple II as Donald Elton's "sq3" and "usq2" utilities, and un-squeezing became part of Floyd Zink's "BLU" utility.  The algorithm, a combination of RLE (Run-Length Encoding) and Huffman encoding, is generally inferior to LZ-based techniques, and Squeeze fell out of common use after ShrinkIt was released.  It was, however, an official part of the NuFX format specification.

Most NuFX utilities can handle Squeezed files, but ProDOS 8 ShrinkIt has a bug that prevents it from unpacking the files correctly.  GS/ShrinkIt handles them correctly.  No Apple II utility actually creates Squeezed NuFX archives.

Dynamic LZW/1

Originally designed to compress tracks on 5.25" disks, the original ShrinkIt compression algorithm grabs a 4K chunk of data, compresses it with RLE, and then compresses the result with LZW (Lempel-Ziv-Welch).  A 16-bit CRC is computed on each compressed chunk.

All NuFX utilities can handle this algorithm.

Dynamic LZW/2

This is a slightly improved version of the original, first introduced in GS/ShrinkIt.  All NuFX utilities can handle this algorithm, making this the best choice for compressing Apple II files.

LZC-12

Before ShrinkIt was born, UNIX systems had the "compress" command.  A fairly pure implementation of the LZW algorithm, "compress" was widely used until the Unisys GIF/LZW controversy sped adoption of the superior "gzip".  LZC-12 produces output equivalent to "compress -b12", i.e. LZW with a maximum code length of 12 bits.

The algorithm was first supported in NuLib, and can be unpacked by NuLib, NuLib2, and GS/ShrinkIt.

LZC-16

Just like LZC-12, but the maximum code length is increased to 16 bits.  Usually offers improved compression over LZC-12, though it's only noticeable on larger files.

Same compatibility as LZC-12.

Deflate

This algorithm uses LZH (Lempel-Ziv + Huffman), which is in a different LZ family from LZW.  The algorithm became popular in archive utilities like LHArc, and eventually became the standard PKZIP archive format.  Some of the authors of the free "Info-Zip" utility decided to write a replacement for UNIX "compress" called GNU Zip ("gzip" for short), using the same algorithm.  It quickly became popular, and "deflate" is now defined as an Internet standard (RFC 1951), and is used for everything from file distribution to PNG graphics.  It was first implemented for NuFX archives in NuLib2 v1.1, and is the best general-purpose compression that CiderPress has to offer.

Unfortunately, few NuFX utilities can unpack this format.  It is unlikely you will ever be able to access "deflated" files on an Apple II.  Only use this for archives that will only be accessed from CiderPress or NuLib2.

Bzip2

This is a relatively new format that relies on the BWT (Burrows-Wheeler Transform) algorithm.  It is slower and more memory-intensive than "deflate", but does exceptionally well on large collections of text files or source code.  It is becoming the standard way to compress source code distributed on the Internet.  It is generally inferior to "deflate" on Apple II files, so unless you have an 800K disk image full of text files there's not much point in using it.

It was first implemented for NuFX archives in NuLib2 v1.1, and it is unlikely to be supported by anything else, so it's usually disabled in NufxLib.


The pathname column may not be hidden.


Un-check to hide the "type" column.


Un-check to hide the "aux type" column.


Un-check to hide the "mod date" column.


Un-check to hide the "format" column.


Un-check to hide the "size" column.


Un-check to hide the "ratio" column.


Un-check to hide the "packed" column.


Un-check to hide the "access" column.


When enabled, certain GS/ShrinkIt quirks are emulated.


When enabled, the Disk Image Characteristics dialog is displayed whenever a disk image is opened.


If enabled, DOS 3.3 filenames will be converted to a mix of upper and lower case for improved readability.


If enabled, all spaces in filenames will be converted to underscores ('_').  Useful for extracting files that will be distributed by a web server.


Click this to open the Edit File Associations dialog.


Click the tabs to move to a different set of options.


Enables the Applesoft BASIC converter.


Enables the AppleWorks Word Processor document converter.


If enabled, Applesoft and Integer BASIC programs will be converted to Rich Text Format with colored highlights.


If enabled, some columns in the hex dump display will be highlighted for easier viewing.


Enables the double-hi-res graphics converter.


Selects the preferred conversion algorithm for double-hi-res graphics.


If enabled, end-of-line characters in text files will be converted when viewing in "raw" mode.


Enables the hi-res graphics converter.


If enabled, hi-res graphics are converted to black & white images by default.


Enables the text converter, which strips "high ASCII" text and converts end-of-line characters.


Enables the Integer BASIC converter.


This determines whether lines of text wrap when they reach the right edge of the file viewer, or run off the edge and are viewed with a scroll bar.


Enables the Pascal text (PTX) converter.


Relaxes strict type-checking requirements for graphics files.  Useful for hi-res and double-hi-res images, which often are stored with the generic "BIN" type.


Enables the super-hi-res graphics converter.


Set the size of the largest file that the file viewer will open, in 1K increments.


Set the size of the largest file that the file viewer will open, in 1K increments.


The contents of the current file.


Change the font used when displaying text.


Go to the next selected file.  This button is disabled when there are no more files.


Go to the previous selected file.  This button is disabled when there are no earlier files.


The number of entries you have selected.


If enabled, comments attached to selected files will be displayed.


If enabled, data forks of selected files will be displayed.


Appendix - Disassembly Notes
Disassembly Notes

A great deal of Apple II source code is written in 6502 or 65816 assembly language.  The simplest way to disassemble raw data into something understandable on a real Apple II is to load the program, enter the monitor with "CALL -151", and list the data with the 'L' command ("2000L").  The output seen depends on which model of Apple II you have.

The CiderPress file viewer allows you to create monitor-style code disassemblies that closely match the original.  The disassembler is selected automatically for appropriate files.

All files are ranked in a priority scheme by file type.  "High" priority means that disassembly is the preferred method for viewing the file.  "Medium" means use it if nothing better comes along (e.g. an 8192-byte BIN file will be decoded as a hi-res image rather than disassembled, but both options will be available in the file viewer).  "Low" means the option to disassemble will be available, but will be prioritized below converted text or "raw" display.

The "extract files" feature when used in "easy access in Windows" mode will write the converted data to a text file.  This is an easy way to dump a monitor listing of a file to disk.

Apple ][, ][+, //e monitor

The classic Apple IIs come with the monitor built into the F8 ROM.  It's able to display all 6502 operations as three-letter mnemonic operations and hexadecimal values.

CiderPress emulates this output as closely as possible, but adds two features for convenience.  First, the new operations introduced with the 65C02 CPU are properly displayed.  Second, annotations have been added to the following:

•	ProDOS 8 MLI calls (the "inline" calls are broken out onto separate lines)

•	Softswitches and F8 ROM routines

Files of type SYS, CMD, 8OB, and P8C are categorized "high priority".

Files of type BIN are categorized "medium priority".

Files of type NON and $F1 through $F8 are categorized "low priority".

Apple IIgs monitor

The Apple IIgs monitor introduced a number of new features.  The 65816 CPU added several new instructions as well as 24-bit addresses and variable-width registers.

The output of the disassembler closely matches the IIgs output.  Annotations have been added to the following:

•	ProDOS 8 MLI calls (the "inline" calls are broken out onto separate lines)

•	ProDOS 16 and GS/OS calls (again, "inline" calls are broken out)

•	IIgs toolbox calls

•	E1/xxxx vectors

•	E0/xxxx vectors

•	01/xxxx vectors

•	Softswitches and F8 ROM routines

Disassembly of 65816 code is tricky because the width of the registers can change, which affects the size of instructions with "immediate" mode addressing.  CiderPress gives you the option of listing a file with "long" (16-bit) or "short" (8-bit) registers, but does not try to track the mode.  Obtaining a complete disassembly of a chunk of code may require listing it twice and merging pieces together.

There is also a preference to control whether BRK and COP commands are displayed as two-byte operations ("BRK 00") or single-byte ("BRK").  The former matches the behavior of the IIgs monitor, but the latter can make the disassembly easier to read in some circumstances, e.g. instructions following an odd number of zeroes.

The IIgs monitor listing mode includes limited OMF (Object Module Format) support.  OMF files are broken into segments, and the disassembly restarts at the top of each segment.

Files of type OBJ, LIB, S16, RTL, EXE, PIF, TIF, NDA, CDA, TOL, DVR, LDF, FST and OS are categorized "high priority".

Files of type BIN, SYS, CMD, 8OB, P8C, and NON are categorized "low priority".

Notes

If you want to see a disassembly of a file with the wrong type, e.g. you want to view assembly language code embedded in a BAS or INT file, change the file type to "BIN".

If a disassembly is starting at the wrong address, or you want to change the start address because the code relocates itself early on (fairly common for SYS files), change the file type to BIN and set the aux type to the desired start address.

The annotations on memory locations and OS calls come from a file called NList.Data, which can be found in the CiderPress installation directory.  The data file was developed by Dave Lyons as part of the Nifty List desk accessory, and is included with permission of the author.  If you want to add additional locations (perhaps Applesoft entry points) or expanded commentary, the file format is pretty self-explanatory.

The format of the Nifty List annotations may not be immediately obvious.  The following is an excerpt from the Nifty List v3.4 manual.

------------------------------------

Interpreting the parameter summaries

------------------------------------

Some tools take no parameters and return no information.  These

appear with an empty pair of parentheses after the tool name:

   GrafOff()

   SystemTask()

Tools that take one or more parameters and return no information are

listed like this:

   SetPort(@Port)

   WriteBParam(Data,Parm#)

An "@" in front of a parameter means it is a pointer and takes 4

bytes (2 words).  All parameters not specially marked take 2 bytes

(1 word).

Tools that take no parameters but return one are listed like this:

   GetPort():@Port

   FreeMem():FreeBytes/4

A "/" and a digit after a parmeter means it takes the specified number

of bytes.  (When making a tool call, you must push space on the stack

for any result values *before* pushing the input values.)

A few tools return more than one value.  In these cases, the

results are listed in the order they have been pushed onto the

stack (so that the first value PULLED is the last one listed):

   GetMouseClamp():Xmn,Xmx,Ymn,Ymx

Each of these values takes 2 bytes (1 word), since there is no

indication of a different size.

Tools that take and return values are listed like this, where a

trailing "H" indicates a Handle (4 bytes):

   EqualRgn(Rgn1H,Rgn2H):Flag

-----

Review of parameter sizes:

   Leading  "@"     4-byte pointer

   Trailing "H"     Handle (4 bytes)

   Trailing "/n"    n bytes

   All other values are 2 bytes long

-----

For ProDOS calls, the parameters are shown in parentheses even

though they actually belong in a parameter block.  For ProDOS 8,

the first item in the list is the parameter count, which should

be in the first byte of the parameter block.

   P8:RENAME(2:pn1,pn2)

ProDOS 16 calls (also called class-0 GS/OS calls) do not have a

parameter count.

   P16:CHANGE_PATH(@Path1,@Path2)

Class-1 GS/OS calls have parameter blocks beginning with a parameter

count word.  Some calls allow a range of values for the parameter

count (like Create, which can take from 1 to 7 parameters), and some

(like Destroy) have a single acceptable value:

   GS/OS:Create(1-7:@P,Acc,Typ,Aux/4,Stg,EOF/4,rEOF/4)

   GS/OS:Destroy(1:@P)


Enable conversion of Print Shop and Print Shop GS clip art.


Import From Cassette

Back in the early days of the Apple II, the most popular way to distribute commercial software was on audio cassettes.  Cassette tapes are slow, transferring data at an average of 1350 bits per second (better than a 1200 baud modem, but about a thousand times slower than a 1x CD-ROM).  If stored properly, however, they can last a long time.

Technical Background

The basic layout of Apple II data on a cassette looks like this:

(1) Ten seconds of 770Hz tone.

(2) Short pulse indicating start of data.

(3) Data (one cycle at 1000Hz for a '1', one cycle at 2000Hz for a '0').

The last byte of data is a checksum that can be used to verify that the previous data read correctly.  The data length is not stored, and there is no explicit "end" marker, so it's necessary to either know the length ahead of time or guess the position of the end based on the absence of data.  Because of the way the code works, you're limited to 64K of data, though in practice you'd be limited to less than 48K on a real Apple II unless you were using custom read routines.

Applesoft and Integer BASIC programs write two consecutive blocks of data.  The first block contains the length of the second block.  CiderPress doesn't really need the first block, because the end of the recording is usually pretty obvious, but the existence of the first block makes it easier to guess what the second block contains.

Most cassettes include more than one copy of a program.  In some cases (such as Adventure International's "Asteroid") they are slightly different implementations, while in others it's the same program repeated.  Sometimes the program is repeated on the back side of the tape.  Magnetic tapes wear out if you play them too much, so redundancy was common.

Getting the Audio Data

You will need to capture the audio from the cassette tape on your computer.  This requires connecting a tape player to your PC while running audio capture software.  Using a sound editor is recommended.  Some examples:

•	Adobe Audition (www.adobe.com; expensive)

•	GoldWave (www.goldwave.com; shareware)

•	Audacity (audacity.sourceforge.net; freeware)

It isn't necessary to record each section of data from the cassette into its own WAV file.  CiderPress will try to find every chunk of data in a WAV file.

If you have a "line out" on your tape player and a "line in" on your PC sound card, use those.  If not, you can use the "microphone" input and the "headphone" out, though you will have to set the volume levels correctly.  In the "speaker" or "multimedia" control panel, set the microphone input gain to 50%.  Start up your sound editor.  If you have an input level meter (e.g. hit F10 in Adobe Audition), turn that on.  Play the cassette tape out loud until you hear a tone, then plug it into the computer and watch the input level.  You want to set the volume so that the input is as high as you can get it without exceeding the limit (this causes "clipping", which is a lot like a square wave but probably isn't going to help us here).  In Adobe Audition, make sure it stays above -3dB.

Once you have the volume level figured out, back the tape up to the start of the tone.  Hit "record" in your software and "play" on your tape player.  Record at 22.05KHz with 8-bit samples.  (Recording at CD quality -- 44.1KHz with 16-bit samples -- doesn't help and requires 4x the space.)  If your software shows an input meter while recording, continue to record until the volume level drops and stays low for at least 10 seconds.  If you can't monitor the input, you will either need to time the cassette, or just record for a long time and perhaps trim the excess off in the sound editor.  Make sure you get all of the data from the tape.  When you think you're done, pull the audio plug out of the tape player and keep listening for a little bit.

Tip: CiderPress only needs to see about a second of the lead-in, so it's okay to fiddle with the volume while the initial tone is playing.

Tip: in some cases, setting the volume a little too high can be beneficial.  It's better to clip some samples than have too little signal.  If at first you don't succeed, crank up the volume a notch and try again.

Save the WAV file, launch CiderPress, and open a ShrinkIt archive or disk image.  Files extracted from WAV files are added to the currently open archive.  Select the "import file from WAV" option in the Actions menu, and open the WAV file you created.

Decoding the Data

The display shows the name of an algorithm, and a box with six columns:

Index: relative position of the program on the tape.

Format: best guess at the nature of the data (Applesoft, Integer BASIC, etc).

Length: decoded length, in bytes, not including the checksum.

Checksum: the checksum, with "Good" if the checksum matched, "BAD" if it didn't.

Start sample: sample number (not byte offset) where the data began.  Useful when examining the data in a sound editor.

End sample: last good sample in the data.  If the data is bad, this is probably where things went wrong.

The text in the "format" column is a guess at the contents, based on the length of the current and previous segment.  For BASIC headers, the contents (e.g. length of program that follows) are shown in hexadecimal.  Applesoft also has an "auto-run" flag, set to either $55 or $D5.

The output of the Apple II is a blocky "square wave" rather than a smooth "sine wave".  Because of limitations in how quickly voltage levels can change, the output isn't perfectly square.  Because of the physical properties of and variations in magnetic media, the not-quite-square wave is rather rounded and wiggly.  After being stored in less-than-perfect conditions for 25-30 years, what you read back from an Apple II tape is pretty crazy.  Deciphering it can be tricky.

CiderPress provides different algorithms that you can apply:

"Zero Crossing" works very much like the Apple II does, and measures the distance between points where the signal changes from positive to negative.  This is usually a good place to start.

"Peak to Peak Width (Sharp)" measure the distance between peaks, which works a little better when the input has been affected by a DC bias (i.e. the entire signal has been shifted up or down, in some cases so far that it no longer crosses zero).

"Peak to Peak Width (Round)" is the same as "Sharp" but with different parameters.

"Peak to Peak Width (Shallow)" is another peak-width variant with different parameters.

Usually one will work better than the others.  In some cases, different algorithms may pull out different copies of a program from the same tape.  You can use the "start offset" column in the display to see which copy has been found.  (Note the start offset may vary by a couple of samples for different algorithms.)

Most cassettes can be recovered, even those that will no longer play on an Apple II.  If you find one that can't, you may want to keep the WAV recording anyway, on the off chance that in the future an improved algorithm can be developed that will decode it.

When CiderPress encounters data that it can't interpret, it stops trying to read from that section of the WAV file.  For this reason, damaged entries will usually be shorter than undamaged ones.  If a file appears to have the correct length but the checksum still doesn't match, it means the signal was sufficiently distorted to make a '0' bit look like a '1' bit, which is actually pretty hard to do.  In most cases the decoder will either make an accurate determination or will conclude that the signal is too distorted to process.  So far only one case has been found where the checksum was deliberately altered, as part of a copy protection scheme (Sargon II).

If the tape has more than one program on it, you can usually tell if it's multiple copies of the same thing by comparing lengths and checksums.  If the checkums say "good" but have different values, you probably have two different programs, or two slightly different versions of the same program.

Saving the Data

The best way to save cassette programs is to a DOS 3.3 disk image, because it's difficult to run Integer BASIC programs under ProDOS.  If you're only extracting Applesoft or binary programs, the choice of disk format doesn't really matter.

Click on the file to save and then click "import".  This brings up the import options screen.  You can change the file name, file type, and for binary files you can alter the start address.  The file name you enter will be altered as needed for compatibility with the currently open archive or disk image.  If it's the same as an existing file, numbers will be appended to the end of the name.

For binary files, a range of addresses should be shown on the cassette tape or on instructions included with it.  It should say something like "800.1A6FR", which is the Apple II system monitor command to read data from the tape and store it in memory (for this example, in locations $0800 through $1A6F, inclusive).  CiderPress is able to determine the length accurately, so when you supply the start address CiderPress fills out the end address for you.

You can import files with bad checksums.  They will almost certainly be damaged or, more likely, incomplete.

Once the file has been imported, you will be able to view it as you would any other file.  Because loading machine language subroutines from disk wasn't an option, many BASIC programs included embedded routines.  It's not uncommon for Integer BASIC programs to appear to have only one or two lines of POKEs and HIMEM: statements until they're run for the first time.  In some cases, the entire program was written in assembly language and then wrapped in BASIC so that the tape could be loaded with "LOAD" instead of from the monitor.  Such programs may not be all that interesting to look at when listed with the BASIC file viewer.

There are three cases where CiderPress currently guesses the file type incorrectly:

•	Applesoft BASIC arrays stored on tape.  These have a 3-byte header section like Applesoft programs, but just contain data.  The "RECALL" statement is used to load these.

•	Shape tables stored on tape.  These have a 2-byte header section like Integer BASIC programs, but contain shape table data.  The "SHLOAD" statement is used to load these.

•	Custom data load routines.  For example, the Integer BASIC program "Starfleet Orion" calls the F8 ROM tape read routines directly, so no BASIC header is present.

A quick examination of the file with the CiderPress file viewer should reveal whether or not it is not a BASIC program.  Anything that isn't should be saved as a binary file.  Actually making use of them is left as an exercise for the reader -- start with the Applesoft BASIC reference manual, or find an Apple II emulator that emulates the cassette I/O port.

Other Notes

You may be tempted to store copies of the WAV file in MP3 format.  This is not recommended.  CiderPress cannot decode MP3s, and the decoded MP3 file is less likely to work than the original.  However, experiments with converting the sound files in and out of MP3 format suggest that "healthy" files are unharmed at reasonable compression ratios.

You don't need fancy equipment.  Connecting the headphone jack of a 15-year-old "boom box" to the microphone jack of a low-cost PC with on-motherboard audio works just fine.


Import BASIC Program

This feature allows you to import an Applesoft BASIC program from a text file.  The text file must contain an Applesoft program listing, with one program line per line of text file.

CiderPress makes no attempt to verify the correctness of the program.  It's possible to import code that can't possibly work.  (The same holds true for loading a program from a text file with the "exec" command on an Apple II.)

Converting BASIC to Text

Going the other direction -- converting a BASIC program to a text file -- is easy.  Just extract the BAS program to windows, selecting "Configure for easy access in Windows".  The conversion is automatic.  Note that you must uncheck "Prefer syntax highlighting on BASIC programs" in the file viewer preferences, or it will be saved as a .RTF file to preserve the colored text.

You can also just open the BASIC program in the file viewer, select the text with Ctrl-A, copy it with Ctrl-C, and then paste it into a text editor such as Windows Notepad.

If you want to convert a program to a text file from within an Apple II emulator, add the following lines to the start of the file:

1 GOTO 4

2 D$=CHR$(4) : PRINT D$"OPEN LISTING" : PRINT D$"WRITE LISTING"

3 POKE 33,33 : LIST : PRINT D$"CLOSE" : TEXT : END

4 REM CONTINUE

To generate a listing, delete line 1 and run the program.  The "POKE 33,33" prevents Applesoft from splitting each program line into multiple output lines.  This will work under both DOS and ProDOS.

It is possible for carriage returns embedded in string constants or REM statements to be lost.  Fortunately these are rare.


Create an unadorned 13-sector disk image.  Only available for 5.25" disk images with 13 sectors per track.


The image file format.  This setting may not be altered.


The filesystem used on the disk image, i.e. how the disk was formatted on the Apple II.


Click this for help on this screen.


The physical format of the image, usually sectors or nibbles.  This setting may not be changed.


The order in which the sectors were written into the image file, defined in terms of the operating system used to write them.


The disk image file being opened.


This determines whether the disk is accessed as 256-byte sectors or 512-byte blocks.


Choose the sub-volume you want to open from the list.


If checked, the resource fork of the file will be opened instead of the data fork.


Enter the name of the folder to use for temporary files.


Click here to choose the temporary folder from a list.


Click this to expand the tree to show the folder name typed in the box on the left.


Click this to open the "New Folder" dialog.  Folders will be created in the folder currently selected in the tree.


The full pathname of the folder currently selected in the tree.


To jump directly to a folder, type the full pathname here and then click "Expand Tree".


This is the "folder tree".  Click on '+' to expand folders to see their contents, '-' to collapse them.


The currently selected folder.  The new folder will be created inside this folder.


Enter the filename of the folder you want to create.


If enabled, a three-letter extension will be added to extracted files.  This can make them easier to use in Windows.


If enabled, file attribute preservation sequences are inserted into filenames, and illegal characters are converted to "%xx".


Click this to extract all files in the archive or disk image.


Click this to choose the folder to extract to from a list.


Click this to modify the options on this screen so that extracted files are most readily usable under Windows.


Click this to modify the options on this screen so that extracted files retain their original structure and attributes.


Select to treat all files as text files.  (Archived disk images are NOT included.)


Select this to disable conversion of text files.


Select this to automatically determine which files are text files, and convert them.


If enabled, "high ASCII" text files will be converted.  This is only done to files identified as text.


If enabled, data forks of selected files will be extracted.


If enabled, resource forks of selected files will be extracted.


If enabled, archived disk images will be extracted.


If enabled, disks will be extracted as .2MG files.  If not enabled, disks will be extracted into .PO files.


If enabled, existing files will be overwritten without confirmation.


The full pathname of the folder to extract to.


If enabled, extracted files will be translated using the file format converters.


Click this to extract only the files selected in the file list.


If enabled, folder names will be removed before the files are extracted, effectively dumping all files into the extraction folder.


The modification date of the existing file.


The name of the existing file.


The modification date of the new file.


The name of the new file.


Click this if you want to keep the existing file.


Click this if you want to leave all existing files alone.


Click to rename the new file.  The existing file will be left untouched.


Click to overwrite the existing file with the new one.


Click to overwrite all existing files with the new ones.


Type the full pathname of the file to extract to.


The name of the file as it appears in the archive.


The full pathname of the file as CiderPress tried to extract it.


Click this to accept the currently selected files and folders.


If enabled, files in sub-folders will be added.  If not, only the files in the current directory will be included.


Select this to ignore file attribute preservation sequences in filenames.


If enabled, existing files will be overwritten without asking for confirmation.


Enter a path prefix here.  This will be prepended to all files added to the archive.


Select this to look for and make use of file attribute sequences.


Select this to make use of file attribute preservation sequences, and to "guess" ProDOS file types from file extensions for files that don't have preservation data.


If enabled, folder names will be stripped from all files being added.  This effectively piles them into the "root" of the archive.


Apply to all entries.


Apply only to selected entries.


Enter the new name for the entry.  The names of disk images stored in ShrinkIt archives must be simple filenames.


The current name of the file, possibly modified from its original form.


The pathname separator character, usually ':' or '/'.  This separates the folder names in a pathname.


Click this to leave the name alone and move on to the next selected entry.


Click here to delete the comment.  This option will be disabled if you just now added the comment.


Enter the text of the comment here.


Select the compression method that the files will be re-compressed with.  Algorithms not supported by the currently-installed copy of NufxLib will not be shown.


Place a checkmark next to the file extensions that you want to associate with CiderPress.


Enter the company name shown on the registration letter.


The checksum of the text entered in the Company field.


Enter the registration key shown on the registration letter.


Enter the user name shown on the registration letter.


The checksum of the text entered in the Registration Key field.


The checksum of the text entered in the Name field.


Tool - Disk Image Converter
Disk Image Converter

This handy tool converts disk images from one format to another.  In this case the word "format" refers to the image file format (2MG, SDK, etc.) rather than the disk filesystem format (DOS, ProDOS).  With this utility you can add and remove 2MG headers, change DOS-order disks to ProDOS-order, convert 5.25" floppies to nibblized formats, and so on.  Read more about disk images here.

Start by selecting the image to open.  If the sector ordering cannot be determined, or if you have "Confirm disk image format" enabled in Disk Image preferences, you will be prompted to specify it.  (You will also be able to set the filesystem format, but that actually has no effect on the conversion process.  If it couldn't be determined, the dialog will show "Generic ProDOS blocks".)

After the image has been opened and examined, you will be asked to select the format of the new image.  One or more of the choices may be unavailable depending on the source image format.  For example, only 5.25" floppy images can be converted to nibble format, and only 3.5" 800K floppies can be converted to DiskCopy 4.2.

You can also choose to compress the file with gzip.  This makes the file smaller and adds a ".gz" extension to the filename.  ShrinkIt archives are already compressed, so the gzip flag is ignored.  A few emulators and utilities can handle DOS-order images with gzip (.do.gz), but generally speaking you should only add gzip compression if you're planning to store the images rather than use them.  The "gzip" checkbox is disabled for images larger than 32MB, because CiderPress doesn't open compressed images larger than that.

Once you have selected the format, click "OK".  You will be prompted for the name of the new archive.  If you don't specify an extension, the correct one will be added for you.  Click "Save" to write the image.

Most disk images are copied as a series of blocks, either ProDOS blocks or pairs of sectors on a 16-sector floppy.  If you are copying from a nibble format to a sector format, any unreadable blocks will be skipped.  A warning dialog will let you know how many had to be skipped over.  If you copy from a nibble format to a new image with the same nibble format (e.g. you're just adding or removing a 2MG header), the data is copied as nibble tracks, and any errors or copy protection are left undisturbed.  If the format changes, e.g. you're copying from ".nib" to ".nb2" or ".app", it may not be possible to copy the data directly because the formats are incompatible.  In such cases the image will be copied as formatted blocks, converting in and out of nibbles as appropriate.

You will be offered the opportunity to open the image in CiderPress to test it.  As with all disk images, this only works if the image has a recognizable filesystem.

The recommended image formats are:

•	5.25" disks: DOS-order .DO, or (if necessary) .NIB

•	3.5" disks: ProDOS-order .PO or .2MG

•	anything else: ProDOS-order .PO or .2MG

These will work with the broadest set of emulators and utilities.  Disk images that are 2GB or larger must be stored in .PO format.

Nibble and 2MG formats can store a volume number that DOS uses.  CiderPress takes care to preserve this value when converting between formats.

Comments in 2MG files are currently lost when images are converted.  This may be fixed in a future version of CiderPress.


Create a plain DOS-ordered image (.DO).  This is the most common format for 5.25" disk images.  It is not available for large volumes or 13-sector disks.


Create a DOS-ordered image with a 2MG header.  Not available for large volumes or 13-sector disks.


Create a plain ProDOS-ordered image (.PO).  Not available for 13-sector disks.


Create a ProDOS-ordered image with a 2MG header.  Not available for 13-sector disks.


Create a plain nibble image.  Only available for 5.25" disk images.  Tracks have 6656 bytes.


Create a nibble image with a 2MG header.  Only available for 5.25" disk images.  Tracks have 6656 bytes.


Create a DiskCopy 4.2 image file.  Only available for 3.5" disk images.


Create a ShrinkIt disk image.  The configured default compression will be used.  Not available for 13-sector disks.


Create a Sim //e "virtual hard drive" image.  Not available for 13-sector disks.  Some applications may have difficulty with the image if it does not contain a ProDOS filesystem.


Compress the file with "gzip" compression, and add ".gz" to the filename extension.  This setting is ignored when creating ShrinkIt disk images.


View the disk as a series of 512-byte blocks.  Recommended for ProDOS, Pascal, and CP/M.  Not available on 13-sector nibble images.


View the disk as a collection of tracks and 256-byte sectors.  Recommended for DOS 3.2 and 3.3.  Not available on odd-sized volumes, e.g. some ProDOS images.


View the disk as nibblized track data.  Only available for nibble images.


Tool - SST Image Merge
SST Image Merge

This tool is used to combine two disk images created by the "SST" utility into a single ".nib" disk image.

SST is "Saltine's Super Transcopy", a nibble copier modified to read raw nibble data from disks and write it to two floppy disks.  The usual approach to creating .nib files is to run SST on a real Apple II, create images of the two disks, copy them to a PC, and then run SST in an emulator to copy the two sides onto a "blank.nib" file.  The advantage of this approach over creating ShrinkIt or ".do" files is that in many cases the copy protection can be left more or less intact.

CiderPress can't make the first half of the process easier, but it can simplify the second.  Instead of running an emulated SST to combine the images, just use the "SST Image Merge" function from the Tools menu.  You will be asked to locate the first side, then the second side, then asked for the name of the output file.  The pieces are merged immediately.  You are given the option of opening the newly-created disk in CiderPress, but as with all disk images this will only work if the disk has a recognizable filesystem.  The NIB format is generally used for disks without filesystems, so you may have to test the image by booting it in an Apple II emulator.

If CiderPress notices anything unusual about the images, you will be notified.  A warning will be shown if they don't appear to be images of SST-created disks, or if they were specified in the wrong order.

You can transfer the SST disk images from your Apple II in any format that CiderPress supports.  The most popular are unadorned DOS-order files (.DO) or ShrinkIt (.SHK/.SDK).  Since the disks don't have a recognizable filesystem, CiderPress' automatic sector order determination algorithms may not work, so it is important to use the appropriate filename extension on unadorned formats.  If CiderPress can't figure it out, or if you have "Confirm disk image format" enabled, you will be prompted to enter it.  (The "filesystem format" will usually show "Generic DOS sectors"; this is normal, and can be left alone.)

SST has some fancy features (nibble counting, track synchronization) that CiderPress does not try to emulate.  If you need special parameters in SST, you will need to use the original method.


When viewing a nibble disk image as blocks or sectors, this lets you choose the sector parameters.  The "Patched" versions will allow you to read sectors from mildly copy-protected disks.


Edit File Attributes

To edit an entry's attributes, select the entry from the list., and activate the "Edit attributes..." command.  You may only select one entry at a time.

The pathname and modification date will be displayed but may not be changed.  (To change the pathname, use the rename feature.)  The file type will be shown in the drop-down box, and may be changed by selecting a new entry.  Tip: if you click in the drop box and type a letter, you will move to the next entry that begins with that letter.  This can make it easier to find a file type by its three-letter abbreviation.

The auxilliary type (usually called "aux type") is shown as a 4-digit hexadecimal number, and may be edited freely.

The type description is based on both the file type and the aux type.  For example, type "LBR $E0" with aux type "8002" is listed as a "ShrinkIt (NuFX) document" in the Apple File Type Notes.

The access flags may be enabled or disabled individually with the checkboxes.  Most files have "Read" enabled and possibly the "Backup needed" flag.  Checking the bottom three boxes results in a "locked" file, while unchecking them indicates an "unlocked" file.

Not all formats support all possible values.  For example, on DOS 3.3 disks, checking the "write enabled" flag unlocks the file, while un-checking it locks the file.  DOS 3.3 only supports a few file types, and only BIN has a meaningful aux type.  HFS directories don't have file types at all.

Changing the file type on a DOS 3.2/3.3 disk should be done with caution.  BASIC programs and binary files have the file length embedded in the first sector of the file, and binary files have a start address as well.  CiderPress does not add or remove these values when changing the file type.  If, for example, you change a file of type TXT to type BIN, you will find that the first four bytes of the text file have mysteriously vanished, and the start address and length are strange.  If you change the aux type, and then change it back to TXT, you will find that the first two characters in the text file are different.

WARNING: if you change a DOS file to BAS, INT, or BIN, there's a good chance that the length value pulled out of the first sector will be larger than the file.  This may not be immediately apparent because CiderPress truncates the length for safety.  The next time CiderPress opens the disk, it will mark the file as "suspicious", and mark the disk read-only.  The only way to change the file type back will be to use a sector editor in an emulator.  If you want a file from another source (Windows text file, ProDOS disk, etc) to have a specific file type, add it to a ShrinkIt archive or ProDOS disk image, change the file type, and then copy it to a DOS volume.

This behavior is by design.  You can take advantage of it when copying certain types of files around.  Cracked games with short DOS loaders can be copied by first changing the file type to 'S' ($F2), copying the file, pasting it into the new disk, and then changing the type back to BIN.  This works because 'S' has no embedded length, and CiderPress does not alter the embedded aux type unless you explicitly change it.

When changing the file type to BIN, you will have the opportunity to change the aux type.  If you leave it alone, the aux type will be pulled out of the first sector of the file.  If you change the value in the edit box, the new value will replace the old.

DOS 3.2/3.3 disks only support eight file types.  The most common are 'B' (BIN), 'A' (BAS), 'I' (INT), and 'T' (TXT).  Less common are 'R' (REL) and 'S' ($F2), and you will rarely see the alternate 'A' ($F3) and 'B' ($F4).  The hex-valued types, like $F2, are used because there is no direct mapping between the DOS type and a ProDOS type.

Pascal disks are similar.  Three types are commonly used: PDA (generic data), PTX (Pascal text editor format), and PCD (Pascal code format).  The others are "untyped" (NON), "bad blocks" (BAD), "info" ($F3), "graffile" ($F4), "foto" (FOT), and "securdir" ($F5).

HFS uses 4-character values for the file type and "creator type".  Apple defined special handling for files with a creator type of "pdos".  CiderPress automatically recognizes those values, and presents them as standard ProDOS file types.  You can choose between ProDOS and HFS types on HFS disks and ShrinkIt archives.


The pathname of the entry being edited.


The file type, displayed as its hexadecimal code and the common three-letter mnemonic.  Not all types have a mnemonic.

Tip: clicking in the file type box and then typing a letter takes you to the next entry whose mnemonic begins with that letter.  This can make it easier to find an entry by "name".


The file's auxilliary type.  Sometimes used to indicate information about the file (such as a 'BIN' load address), sometimes used to distinguish between files with the same file type (such as the various application-specific 'CFG' config file formats).

Enter a four-digit hexadecimal number.


Enable or disable the ability to read the file.


Enable or disable the ability to write the file.  On a DOS 3.2/3.3 file, this locks or unlocks the file.


Enable or disable the ability to rename the file.


Enable or disable the ability to delete the file.


If set, the file won't be displayed by the IIgs Finder and some other utilities.


Set or clear the "backup needed" flag.


Date when the file was modified.


A brief description of the file's type.  This is based on both the file type and the aux type.


Convert Disk Image to File Archive

This feature extracts every file it can find in a disk image and stores it in a ShrinkIt archive.  This is similar to extracting all files with "preservation mode" enabled and re-adding them, but is faster and easier.  It can be used in conjunction with "convert file archive to disk image" to resize a ProDOS volume.

Open a disk image and highlight the files you want to convert.  Items will be converted in the order that they appear, so if you want to leave the order undisturbed make sure you have them sorted in the original order (more information on this).  Select "Convert to file archive..." from the Actions menu.

The "Preserve empty folders" feature is useful when you plan to convert the file archive back to a disk archive, perhaps after modifying some files or just choosing a different disk size.  The ShrinkIt archive format describes a way to store empty folders, but it has never been used by any ShrinkIt utility and could cause some software to break.  Instead, CiderPress creates standard zero-length file entries with the name ".$$EmptyFolder".  These are automatically dropped when converting to a disk archive, but will appear as normal entries in the archive.  This option should therefore be enabled only when you plan to convert back to a disk image.

The selected default compression will be used when creating the ShrinkIt archive.

Text files on DOS 3.2/3.3 and RDOS disks (file type 'T') will be converted to ProDOS format.  This involves stripping "high ASCII" text from the file.

For performance reasons this feature holds most of the files in memory during the operation, making this somewhat memory-intensive.  If you are working with 32MB hard drive partitions, performance on systems with insufficient RAM may suffer.

Files in embedded volumes, such as a DOS volume inside an 800K ProDOS disk, can be converted.  However, they become just like any other file, and if the file archive is converted back to a disk image they will no longer be stored in an embedded volume.


Convert File Archive to Disk Image

With this feature, you can copy part or all of a ShrinkIt file archive to a new ProDOS volume in a single step.  When combined with the "convert disk image to file archive" feature, it's possible to resize ProDOS disks, converting 140K floppies to 800K floppies or even 32MB hard drive images.

The images created are always unadorned ProDOS-order (.PO) files.  If you need to have it in a different format, you can use the Disk Image Converter to change it.

Open a file archive and highlight the files you want to convert.  Items will be converted in the order that they appear, so if you want to leave the order undisturbed make sure you have them sorted in the original order (more information on this).  Select "Convert to disk archive..." from the Actions menu.

Choose the size of the disk to create from the set shown.  Standard removable media and hard drive sizes are available.  If you're not sure how much space the files require, click the "Compute" button.  The size requirements will be determined by creating a temporary 32MB volume with the selected files and adjusting for system overhead.  Any size options that won't work will be dimmed.

Filenames on ProDOS disks must start with a letter, be composed entirely of letters, numbers, and dots ('.'), and can be at most 15 characters long.  Any invalid characters will be stripped, and long filenames will be truncated.  CiderPress will try to preserve filename extensions (e.g. ".jpg"), and will make filenames that reduce to the same thing unique.  For example, "my&&file" and "my__file" both convert to "myfile", so the first is stored as "myfile" and the second as "myfile1".

ProDOS stores filenames using upper case letters only.  A modification added for the benefit of the GS/OS ProDOS FST allows mixed-case names with spaces in them, but the method used to store the case information can confuse older versions of ProDOS 8.  The "Allow lower-case ProDOS names" option in Disk Image Preferences lets you tell CiderPress whether to create lower-case names on ProDOS disks.  If you're planning to use the disk with a pre-v1.8 version of ProDOS 8, you should not enable the feature, or your files may be inaccessible.

The volume directory on a ProDOS disk holds at most 51 files.  If you need to put more than 51 files onto a ProDOS disk, make sure some or all of them are in folders, which do not have a limit.

If you are converting a ShrinkIt archive that contains a disk image, the disk image will be converted as a ProDOS-order (.PO) file.

For performance reasons this feature holds most of the files in memory during the operation, making this somewhat memory-intensive.  If you are working with 32MB hard drive partitions, performance on systems with insufficient RAM may suffer.


Select this to convert DOS text files to ProDOS format.  This involves converting the "high ASCII" text to standard ASCII.  Conversion is recommended, because if you don't do this the files may be difficult to read.


Select this to convert Pascal "PTX" text files to standard ASCII.  It isn't necessary to do this because the files will retain the "PTX" file type, and will still be viewable with CiderPress.


Select this to preserve empty folders on ProDOS volumes.  ShrinkIt archives don't provide a good way to store empty folders, so CiderPress will create an empty ".$$EmptyFolder" file in the archive.  This will be removed automatically if the archive is converted to a ProDOS disk image.  This option should only be enabled if you plan to convert the archive back to a disk image.


Display ProDOS folders in a format similar to the ProDOS 8 BASIC.System 80-column "catalog" command.  (Folders are never extracted, so this only affects the way folders are viewed.)


View and extract resource forks by breaking them down into individual resources, which are displayed as hex dumps.


Create a 140K image, equivalent to a 5.25" floppy disk.


Create an 800K image, equivalent to a 3.5" floppy disk.


Create a 5MB image.


Create a 16MB image.


Create a 20MB image, equivalent to a 20MB floptical disk.


Create a 32MB image, the largest possible ProDOS volume.  (Technically, it's one 512-byte block short of 32MB.)


Click this to compute the size required with the currently-specified options.  The computation is performed by creating a 32MB image and examining the number of blocks used.


The space required by the selected set of files with the current options.  Click the "Compute" button to calculate this.


If selected, ProDOS files are allowed to have lower case letters and spaces in them.  This can confuse older versions of ProDOS 8 (pre-v1.8), so only select this if you're using a recent version of ProDOS.


If selected, empty blocks won't actually be stored.  Instead, the ProDOS "sparse" mechanism is used to indicate the existence of the empty space.  You should generally leave this enabled, as it can save considerable space.


Enter the desired ProDOS volume name here.  It must start with a letter, and contain nothing but letters, numbers, and dots ('.').


Tool - Bulk Disk Image Converter
Bulk Disk Image Converter

The bulk converter works much like the single-image converter, but it can process a large number of disk images with a few clicks.  It's probably best to become familiar with the single-image converter before using this feature.

After you select this feature from the "Tools" menu, you will be asked to select the disk images to convert.  All images must reside in the same folder.  Select multiple files with the mouse, using shift-clicks to select a range of files or ctrl-clicks to add or remove individual files.  You can select all files in the current folder by clicking on one and then hitting Ctrl-A.

Next, you will be asked to choose the output format.  All images will be converted to the same format.  Not all images can convert to all formats -- for example, you can't create 800K nibble images or 140K DiskCopy images -- so make sure you choose an appropriate format.  CiderPress will not prompt you to specify sector ordering, so it's important for the images to have descriptive filename extensions (e.g. ".po" instead of the generic ".dsk").

Finally, select a folder for the output.  Creating a new, empty folder is recommended.  The converted files will have the old names but with the extension replaced, but in some cases the old extension might match the new.  For example, converting a DOS-ordered 2MG file to a ProDOS-ordered 2MG file does not change the ".2MG" extension.  CiderPress will not overwrite an existing file.

If CiderPress encounters a file it cannot convert, you will be shown an error message with the name of the file and given the opportunity to skip the file and continue or halt processing.  Some messages, such as warnings about unreadable blocks on nibble images, are suppressed during bulk conversions.

If you are converting to ShrinkIt .SDK archives, the files will be compressed with the current default compression method.  This provides an easy way to convert a large set of disk images to "deflate" format for reduced storage requirements, or back to LZW/2 for Apple II compatibility.


Create a DDD compressed disk image, compatible with DDD Pro.  Only available for 5.25" disk images.


Enables the AppleWorks Database document converter.


Enables conversion of assembly source files (S-C Assembler, LISA, Merlin) to text.


Enables the AppleWorks Spreadsheet document converter.


Enables conversion of MacPaint 'PNTG' graphics files.  These are monochrome 576x720 images from the original MacPaint program.  The newer 'PICT' format is not supported.


List file extensions that should be opened in an external viewer when double-clicked from the file list.  For example, if you want to view GIF or JPEG images stored in a ShrinkIt archive or disk image, you should put "gif; jpg; jpeg" here.


Create a 40-track TrackStar image.  Tracks are variable length and stored in nibble format.  Only available for 5.25" disk images.


Opening a Volume

In some circumstances it is useful to open a raw disk volume.  Two common examples are ProDOS-formatted 1.4MB floppy disks and CFFA flash cards.  CiderPress allows you to access ProDOS and HFS filesystems directly.

WARNING: it's possible to destroy all data on your hard drive.  Make sure you're opening the right volume!  When in doubt, open the disk in "read only" mode by checking the "read only" checkbox.  As a safety measure, "read only" is set by default, and CiderPress will not allow you to open "C:\" or physical drive 0 if read-only mode is disabled.  Always close the volume (with File->Close) before ejecting removable media.

Not all devices will work under all operating systems.  Please check the hardware compatibility list on the faddenSoft web site.

Disks can be opened as "logical" or "physical" volumes in Windows.  Understanding the distinction is important.  The basic difference is that a "logical" volume has a drive letter associated with it (e.g. "A:\" for your first floppy drive), while a "physical" volume is numbered (e.g. physical device 0 is your primary hard drive).  From the operating system's perspective, a "physical" disk has a partition table in block 0 that describes one or more "logical" volumes.  Floppy disks are an exception; for them, "logical" and "physical" are equivalent.  A CF card reader may present itself to the system as a physical disk, in which case Windows will try to find a partition table in block 0.

ProDOS and HFS volumes don't have a partition table in block 0, which can cause some confusion.  In some cases you will see a "physical" volume for the CF card but no "logical" volume.  In others the "logical" volume will appear and will be as large as the "physical" disk.  If Windows thinks it has a valid partition table, the "logical" volume may be a small subset of the "physical" disk.

The bottom line is that it's best to use "physical" disks whenever possible.  However, it's not always possible.  You can't treat a floppy drive as a "physical" disk in Windows 2000, and access to "physical" hard drives in Win9x/ME is tricky.  You have to access floppies as "logical" volumes under Win2K, but if you do that under Win98 you will have terrible performance in some circumstances.  It would be nice if CiderPress could automatically do the right thing in all cases, but every CF card reader is different, so CiderPress tries not to limit your options.

CD-ROM drives have their own access method.  No version of Windows makes it easy to read blocks from a CD-ROM with an unrecognized filesystem format.  Under Win2K/XP, CiderPress relies on a technology called SPTI (SCSI Pass-Through Interface) to access the disc.  Select the drive you want from the "logical" list, by letter (e.g. "D:\").  Under Win98/ME, it's necessary to use an ASPI driver (Advanced SCSI Programming Interface), just like CD recording applications do.  CiderPress will look for "wnaspi32.dll", and use it if found (Win98 includes it -- look in the About box to see if it was loaded successfully).  CD-ROM drives show up in the "physical" list, described by manufacturer and model number.  Some external CD-ROM drives may not show up in the list.

Generally speaking, SPTI and ASPI have equivalent performance.  The only notable difference is that SPTI requires exclusive access to a device, so you can't have a CD-ROM open in the file list and then open it in the volume copier.  Some ASPI layers will pick up devices other than CD-ROM drives, such as SCSI hard drives, Zip drives, and even CF card readers.

Hard drives partitioned for an Apple II or Macintosh can be accessed if attached to an IDE or SCSI connector.  Under Win9x/ME you can only access drives that the ASPI layer can find, which usually means you can only get to SCSI hard drives.

Here's what you should do:

In Windows 2000/XP:

•	Use "A:\" to access your floppy drive.

•	Use "D:\" (or something similar) to access your CD-ROM drive.

•	Use "physical disk N" to access hard drives.

•	Use "physical disk N" to access your CF card if that's an option.  If not, use the logical drive (e.g. "M:\"), but be aware that the card may appear to have a different size when formatted for CFFA vs. Windows.  With some card readers, the size shown for the card may be wildly inaccurate, especially on Win2K or earlier.

In Windows 9x/ME:

•	Use "floppy drive N" to access floppies.  CiderPress will actually hide "A:\" if the disk doesn't have a Windows filesystem, because "logical" access to such disks is very slow.  (It will otherwise show it, so you can identify your Windows disks.)  After overwriting a disk, Windows will continue to show the old volume label until you eject the disk.

•	Select your CD-ROM drive by vendor name and model number.

•	Select SCSI hard drives by vendor name and model number.

•	Use the logical drive (e.g. "M:\") to access CF cards.  If the logical drive shows up in the list when you insert a Windows-formatted card but not with a ProDOS-formatted card, you have a brain-damaged CF card reader driver, and it's not going to work.

Access to physical devices other than floppy disks in Win2K/XP requires "administrator" privileges.

If you un-check the "read only" box, Win2K/XP will not allow you to open the volume a second time, e.g. you can't have a disk open in read-write mode and then open it again in the volume copier.

The "filename" for physical disks will show up as two digits, e.g. "81:\" for the second physical disk.  This is an artifact of the way the PC BIOS works.  CD-ROMs and hard drives under Win9x/ME will look like "ASPI:0:1:0\".

You cannot create or access files larger than 2GB under Win9x/ME.  This is an operating system limit, and cannot be circumvented.

CiderPress has a self-imposed 8GB volume limit (as a "reasonableness" test to keep it from running amok).  This should be large enough to handle CF cards and hard drives partitioned for use on an Apple II.

CiderPress does not detect media ejections or swapping.  Do not eject disks or CF cards while CiderPress has them open.

In some cases you may need to be patient!  Scanning the contents of a CD-ROM with 10,000 files spread across several 32MB ProDOS volumes can take a few minutes.


Create a 1440K image, equivalent to a 3.5" floppy disk on a PC.


Specify the size in 512-byte blocks.  The largest possible ProDOS volume has 65535 blocks (though 65536 is allowed for compatibility).  The smallest CiderPress allows is 16 blocks.


Appendix - About Removable Media (CF, floppy, CD-ROM)
About Removable Media (CF, floppy, CD-ROM, external HD)

The ability to move data between a PC and an Apple II on removable media can be very handy.  With a CFFA card installed in an Apple II, and a CF card reader on a PC, you can move entire hard drive volumes around easily.  Floppy disks are easier to insert and eject on the Apple II, but hold less.  In both cases you need suitable hardware on both the Apple II side and the PC side.

CiderPress does not detect media ejections or swapping.  Do not eject disks or CF cards while CiderPress has them open.

Floppy Disks

Formatting a 3.5" disk with ProDOS can be very useful if you have a way to read the disk on an Apple II or Macintosh.  Newer Macs, and Apple IIs equipped with appropriate hardware, can read and write PC-formatted 3.5" floppies.  An Apple II requires a SuperDrive (with controller card), PC Transporter, or Tulin "floptical" drive.  Without one of these, it's not possible to read PC disks.

Inserting a ProDOS disk into a Windows machine can cause some consternation for the OS.  For example, the capacity of a PC floppy disk cannot easily be determined.  There are BIOS calls to retrieve the type of drive, but not the type of media currently inserted.  Common practice is to examine sector counts stored in the floppy boot sector.  Since ProDOS and HFS floppies do not follow PC boot sector conventions, the size of a floppy disk must be determined by other means.  Specifically, accessing blocks to see which calls succeed and which fail.  A disk with bad blocks could be interpreted as smaller than it actually is.  Windows may actually refuse to do a "quick format" on a ProDOS formatted disk, because it's unable to tell how large it should be.

CiderPress has been tested with 720KB and 1.4MB 3.5" floppy disks.  It will not work with 800K or 1.6MB 3.5" floppies from an Apple II or Macintosh, because the drive in a PC is not capable of reading them.  For similar reasons, it cannot read 140KB 5.25" floppies created on an Apple II.  CiderPress has not been tested with 360KB or 1.2MB 5.25" floppy disks, because they're no longer used in the PC world, and they can't be read on an Apple II or Macintosh.

CiderPress does not "format" floppy disks or other volumes directly.  Instead, open the disk you want to format with the Volume Copier, and copy a ProDOS volume onto it.  If you don't have a ProDOS disk image of the appropriate size, create one with the Disk Image Creator first.

Compact Flash Cards

Richard Dreher's CFFA card for the Apple II created the ability to access inexpensive high-capacity compact flash card media as a hard drive.  Because the cards are relatively easy to install, and CF card readers are common on PCs (especially laptops), they make an ideal way to transport large quantities of information.

As with floppies, CF cards formatted for ProDOS or HFS are not handled well by Windows.  Disks can be accessed as "physical" or "logical" volumes.  "Physical" disks correspond to physically connected devices.  Block 0 holds a partition table for the rest of the disk.  ProDOS and HFS don't have a Windows-style partition table, so Windows can become very confused when a non-Windows CF card is plugged in.  "Logical" volumes, such as "C:", are created by the device driver.  For a disk device they are generated from the partition table, so a CF card may have one or more logical volumes that correspond to part or all of the physical storage.

Long story short: whether or not your CF card is viewable in Windows depends on what hardware and drivers you're using to access the card.  You may be able to access it as a physical disk, logical disk, both, or neither.  Sometimes under Win98 the ASPI driver will find it.  See "Opening a Volume" for additional information.

Assuming it's possible to access the CF card, figuring out what's on it can be tricky.  A CF card can be formatted with 4 partitions or 8 depending on the firmware setting on the CFFA card in the Apple II.  With a GS/OS driver, the 4-partition mode can actually hold 6 partitions.  If you are using a card larger than 128MB, CiderPress will have to make some educated guesses as to where your partitions are and what's in them.  For cards 1GB and smaller, it usually guesses right.  However, you can override its choice by enabling "Confirm disk image format" and selecting an alternate partitioning scheme when opening the volume.

One caution: if you format a disk for ProDOS, and then format it with your camera, you may find that it still appears to have some ProDOS files on it.  (CiderPress should identify it as an MS-DOS "FAT" filesystem, but if the camera uses a non-standard boot block it may not be detected correctly.)  Some files may appear to be damaged.  This is because the camera's format routine didn't zero out all of the blocks, so some of the ProDOS directory structure is still present.  Attempting to read or write files to the volume as if it were a ProDOS disk is not recommended.  The safe way to switch between Apple II and Windows formatting is to use the image-copy tool to overwrite the entire CF card.  Be aware that formatting with a camera can reduce the number of blocks available on the drive, which will make copying images onto it impossible: the image copier only works if the destination volume is at least as large as the source volume.

The speed at which CF cards are read or written depends primarly on your card reader.  USB2.0 readers will be faster than USB1.x, and Firewire, PCMCIA, or IDE interfaces will usually be faster than USB2.0.  Also, some cards have a higher speed rating than others.  Speeds of 200-400KB/sec are typical when copying from a USB1.x device, while writing to it may reach 700KB/sec.  Writing tends to be faster than reading because of block caching.

CiderPress assumes that the first partition on a CFFA card will be ProDOS or HFS.  If it's not, the image will not be detected as CFFA.

CD-ROM

CD-ROMs for Apple IIs and Macintoshes were created with a partition table identical to those found on Macintosh hard drives.  This allows a CD-ROM to have several ProDOS and HFS partitions.  Happily, the format is well defined, and there is no ambiguity in the size or location of each partition.  Occasionally the partition information is wrong, and an "Apple_Extra" partition refers to parts of the disc outside the recorded area.  In such cases CiderPress will trim its internal copy of the map to fit what's actually on the disc.

Access to files on CD-ROMs can be slow, especially on ProDOS volumes.  Unlike ISO-9660 discs, the file layout on Apple II CD-ROMs is not optimized for sequential accesses, and the drive head has to seek to a new position often.  If the speed becomes a problem, extract the CD-ROM into a ".ISO" image file and use that instead.

CiderPress does not have the ability to write to CD-Rs.

Hard Drives

Apple II or Macintosh hard drives can be connected, assuming you have the necessary hardware (e.g. SCSI interface).  Non-SCSI drives, such as the Applied Ingenuity InnerDrive or Vulcan drives, may not be formatted with the Macintosh partioning scheme and hence may be inaccessible.

Figuring out the size of a hard drive is a bit tricky under Windows, which uses different interfaces in different versions of the OS.  Some interfaces return different answers depending on what version you're running.  CiderPress currently scans the drive to determine its size.


Tool - Windows Volume Copier
Windows Volume Copier

This tool lets you copy all or part of a Windows volume to or from a file.  This can be used to make images of 3.5" floppy disks, copy disk images onto 3.5" disks, back up a CFFA card, or swap partitions in and out of a hard drive.  This can also operate on normal disk image files and block images extracted from devices.

WARNING: it's possible to destroy all data on your hard drive.  Make sure you're opening the right volume!  When in doubt, open the disk in "read only" mode.

There are two versions of the tool.  If you select "Volume copier (open volume)", you will be given a list of volumes to choose from.  Select the volume you want to work with.  If you check "read only", copying data into the volume will be disallowed.  If it's not checked, the volume will be opened with write access enabled.  In either case, under Windows 2000 or XP you will need to have administrator privileges to access volumes other than the floppy drive.

If you select "Volume copier (open file)", you can open any disk image of your choosing.  This can be a handy way to extract from or modify a multi-partition image file.

CiderPress will try to figure out what format the volume is in, automatically detecting any sub-volumes, such as CFFA partitions and hard drive partitions.  If the volume has a single filesystem on it, CiderPress will display the volume name, format, and volume size in blocks and megabytes.  If the volume has sub-volumes, you will see one entry for the entire volume (shown with a large green dot) and below it one entry for each sub-volume (with a smaller blue dot).

Click on the volume or sub-volume you want to manipulate.  To copy the volume to a file, click on "copy to file".  This will create a ProDOS ordered ("xxx.po") disk image that some Apple II emulators will be able to use directly.  To copy a file onto the volume, click on "copy from file".  This pulls blocks out of the disk image file and writes them to the volume or sub-volume.  You can open any disk image format that CiderPress supports.

When copying from a file to a volume, the file must be smaller than the volume.  You cannot, for example, copy a 32MB ProDOS volume onto a 1.4MB floppy.  If you copy a 1.4MB floppy image onto a 32MB CFFA partition, you will have a 1.4MB ProDOS partition and 30.6MB of wasted space.  If you copy a 140K DOS 3.3 image onto a 32MB CFFA partition, you will end up with a useless partition, because nothing will look for a DOS volume there.  For safety, CiderPress will not allow you to copy data onto a volume 8GB or larger.

When copying large volumes to disk, CiderPress starts by creating an empty disk image file.  For large (512MB+) volumes, this may take several seconds as Windows creates an empty file.

If you are overwriting the first volume of a CFFA image, make sure you're copying ProDOS or HFS in.  If CiderPress can't recognize the first partition, it may not be able to detect that the volume is a CFFA card, and will not display the CFFA sub-volumes.

The sizes used are for the entire partition.  If you formatted a 32MB ProDOS volume in a 1GB partition on a CFFA card, CiderPress will treat it as a 1GB volume, even though ProDOS is only on the first part of it.  Extracting that ProDOS volume may be awkward.

Hard drives with Macintosh-style partioning have explicit filesystem identification for each partition.  That is, each partition will be labeled as ProDOS, HFS, a device driver, or whatever is appropriate.  CiderPress does not currently have the ability to change these labels.  Copying the wrong thing onto a partition, such as putting a ProDOS volume into a partition meant for HFS, could have unexpected results.

Bear in mind that old hard drives are pretty slow by today's standards.  A 2GB drive purchased in the mid-1990s will deliver 4-5MB/sec on bulk reads, which means it'll take about 8 minutes to back up the entire drive.  These drives tended to have small caches and slow seeks though, so it can take 30 seconds to a minute for the contents of the disk to be loaded, because scanning the list of files requires lots of single-block reads.

If CiderPress encounters errors while reading, it will start doing single-block reads instead of bulk reads.  This can be *significantly* slower, on the order of 5-10x for some types of drives.  Errors encountered while writing halt copying immediately.


Specify the size in 512-byte blocks.  The largest possible ProDOS volume has 65535 blocks (though 65536 is allowed for compatibility).  The smallest CiderPress allows is 16 blocks.


Disk Image Creator
Create Disk Image

This allows you to create blank, formatted disk images in a variety of formats.  The images created can be used with CiderPress or an Apple II emulator.

Start by selecting the filesystem.  CiderPress currently supports creation of images in DOS 3.2, DOS 3.3, ProDOS, and UCSD Pascal formats.  You can also choose to create a completely blank file with the specified size, though this is only useful in a few circumstances.

The choice of filesystem determines which size options are available to you.  DOS 3.2/3.3 formatting is only allowed on 140K floppies, Pascal can be written to 140K or 800K floppies, and ProDOS can be written to images from 16 blocks up to 32MB.  Blank images can be as small as 1 block or as large as 8GB.  Your filesystem selection also enables some filesystem-specific options:

DOS 3.2/3.3: choose the disk volume number (default 254) and whether or not a DOS image should be written.  If "Allocate DOS tracks" is checked, tracks 1 and 2 are marked "in use", and a bootable DOS image is written to the disk.  If it's not checked, tracks 1 and 2 are marked as free space, and the disk will not be bootable.

ProDOS: choose the volume name.  ProDOS volume names must start with a letter, contain only letters, numbers, and '.', and can be at most 15 characters long.  To make the disk bootable, you will need to copy the "PRODOS" file from another ProDOS 8 disk.

Pascal: choose the volume name.  Pascal volume names can only be 7 characters long, but may contain letters, numbers, and symbols other than "$=?,[#:".  To make the disk bootable, you will need "SYSTEM.APPLE" and "SYSTEM.PASCAL" from a Pascal system disk.

After you hit "OK", you will be prompted for the name of the file to save to.  For 140K floppy images you can select DOS order (".do", the default) or ProDOS order (".po").  For DOS 3.2, ".d13" must be used.  For other images only ProDOS ordering is available.  If you want the image to be in a different format, such as .SDK or .2MG, use the Disk Image Converter tool.

If you want to create a blank filesystem image on physical media (e.g. format a 1.4MB floppy disk for ProDOS), create an image of the appropriate size, open the floppy disk with the Volume Copier, then copy the image onto the disk with the "load from file" button.

Tip: if you want to create several images of the same kind, create one and then use Windows Explorer commands to make multiple copies of the file.


Format the disk for DOS 3.3.


Format the disk for ProDOS.


Format the image with the UCSD Pascal filesystem.


Create an image file but leave it completely blank.


If checked, the first three tracks of the disk are marked "in-use" for a DOS image.  If unchecked, two tracks are freed up but the image can't be booted.


Enter the desired ProDOS volume name here.  It must start with a letter, and contain nothing but letters, numbers, and dots ('.').


Enter the desired Pascal volume name here.  You may use upper-case letters, numbers, and symbols other than "$=?,[#:".


DOS volume number (usually 254).


If set, CiderPress will play a sound when operations complete successfully.


Select Location

Select the disk or subdirectory where the files will be added.  If the current disk has sub-volumes (e.g. embedded DOS 3.3 volumes or CFFA partitions), they will be shown under the encapsulating disk volume.

Disks in formats that cannot be written are shown with a red 'X' through the disk icon.  This commonly appears in the root volume of a partitioned image.  For example, you can add files to CFFA partitions, but you can't add files to the CFFA entry because it only contains other partitions.  It can also appear for partitions that appear to be damaged or hold damaged files.

You can skip this step on ProDOS disks by selecting a directory before using "add files".  The files will be placed in the selected directory.

If you want to add or extract partitions, use the volume copier tool instead.


Archive Info

The Archive Info command in the "File" menu provides a way to view information about the currently open disk image or file archive.  The set of information shown depends on the kind of file currently open.

NuFX (ShrinkIt) Archive

•	Filename: the name of the file that is currently open.

•	Format: archives can be plain ShrinkIt archives (NuFX), wrapped in a Binary II wrapper (usually named .BXY), GS/ShrinkIt self-extracting (.SEA), or GS/ShrinkIt self-extracting in a Binary II wrapper (.BSE).

•	Records: the number of records in the archive.  Each file, whether forked or not, occupies one record.

•	Master Version: the master version number of the NuFX archive.  This can be useful when trying to determine if an archive is from a really old version of ShrinkIt.  The most current version is 2.

•	Created: the date and time when the archive was created, if available.

•	Modified: the date and time when the archive was last modified.

•	Junk Skipped: the number of bytes skipped over when scanning for the start of the archive.  NufxLib skips over MacBinary headers and the leftover HTTP junk that seems to show up in files on some FTP sites.  Most other NuFX applications, e.g. ShrinkIt, do not, so this can explain why an archive won't open on an Apple II.

Disk Image

•	Filename: the name of the file that is currently open.

•	Outer Format: the name of an external "wrapper", if any; usually gzip (.gz) or zip (.zip).

•	File Format: the overall format of the disk image file.  Common formats are 2IMG (.2MG) and unadorned (.PO, .DO, .DSK).

•	Physical Format: internal layout of the file.  Most files are "cooked" sectors, but some are in a nibble format.

The Sub-Volume box shows the name of the volume that the rest of the information applies to.  Most disks don't have sub-volumes, and the box will be greyed out.  UNIDOS 800K disks, Macintosh-style partitions, CFFA cards, and ProDOS disks with embedded DOS images will have entries here.  Selecting a different entry will change the information below.

•	Sector Ordering: sector layout within the image.  Most disks use DOS (.DO) or ProDOS (.PO) order.

•	Filesystem Format: the type of filesystem on the disk, e.g. DOS 3.3, ProDOS, Pascal.  For "hybrid" disks, such as DOS3.3/ProDOS mixed on a 5.25" disk, only the dominant filesystem will be shown.

•	Files+Directories: the number of files and directories on the disk.  For ProDOS the count includes the volume directory.

•	Storage Capacity: how many blocks or sectors the disk can hold.  In some cases, such as an 800K disk image copied to a 32MB CFFA partition, a second number will be shown indicating the maximum size of the disk image area.

•	Free Space: how much free space is on the disk.  For formats like CFFA, which just hold other disk images, this is meaningless.

•	Writable Format: says whether or not CiderPress is capable of adding and deleting files on disks with this format.  Currently this is "yes" for DOS 3.3, ProDOS, and UCSD Pascal.

•	Damaged: this indicates whether or not CiderPress believes the disk is damaged.  If it does, the disk will be marked read-only, and attempts to add or delete files will be blocked.

•	Notes: if CiderPress detects damage or other anomalies when scanning the disk, they wll be noted here.

More information about the different disk formats can be found here.

Binary II Archive

•	Filename: the name of the file that is currently open.

•	Records: the number of entries in the Binary II archive.

AppleLink Compression Utility Archive

•	Filename: the name of the file that is currently open.

•	Records: the number of entries in the ACU archive.


Preferences - Disk Image
Disk Image Preferences

You can access the Disk Image Preferences by selecting "Preferences..." from the "Edit" menu, and then clicking on the "Disk Images" tab.

General

If "confirm disk image format" is enabled, you will be shown the Disk Image Characteristics dialog whenever a disk image is opened.  This gives you an opportunity to see what format CiderPress believes the disk is in, and to override it.

The "default to read-only when opening volumes" setting determines whether the "read-only" box is checked in the Open Volume dialog.  This should normally be set as a safety feature, but if you find yourself writing to physical disks frequently, you can save yourself a click by disabling this option.

"Allow write access to physical disk 0" disabled a safety feature.  On most systems, physical disk 0 is your boot disk (i.e. C:\).  If you have multiple drives, this may not be the case.  By default, CiderPress prevents you from opening physical disk 0 for writing; if you set this checkbox, write access will be allowed.  It's best to leave this disabled unless you get a message that says, "Unable to open '80:\': for safety, write access to this volume is forbidden" while trying to open a disk that you are sure contains Apple II data.

ProDOS

When Apple released GS/OS, they added the ability to have lower-case letters and spaces in file and volume names.  This made file listings nicer to look at, but broke compatibility with versions of ProDOS 8 older than v1.8.  If "allow lower-case letters and spaces in filenames" is enabled, files added to ProDOS disks will use mixed-case filenames.  If disabled, all filenames are stored in upper case.  Uncheck this item for best compatibility.

The "use 'sparse' allocation for empty blocks" option enables a handy space-saving feature.  Disk blocks filled entirely with zeroes aren't actually written to disk.  Every version of ProDOS supports this feature, so there's no real reason to disable it, but it's there if you want to experiment.


If enabled, files added to ProDOS disk images will have lower case letters in their names when viewed with GS/OS.  ProDOS 8 older than v1.8 can't handle lower case names, so disable this option if you're using an old version of ProDOS.


If enabled, files with empty blocks (all zeroes) will be stored more efficiently (recommended.)


Appendix - Administrator Privileges
Administrator Privileges

Windows 2000, Windows XP, and presumably any subsequent version of Windows requires "administrator" privileges to access logical and physical devices directly.  This is required because the direct block access bypasses normal file access control mechanisms.  You either need to log in as an administrator to use the device-access features of CiderPress, or upgrade the privilege level of your non-administrator account.

Most Win2K/XP users are set up with administrator access, but some may not be.  CiderPress will tell you if devices are failing to open because of access permissions.  To gain administrator access, you have to start by having administrator access to the machine.  Yes, this is a bit of a chicken and egg problem, but there's no way around it.  If you don't know how to log in as administrator, ask the person who set up your computer.

Windows 2000:

•	From the "Start" menu, select "Settings" and then "Control Panels".

•	Open the "Users and Passwords" control panel.  If you're not allowed to do this, you're not an administrator, and cannot proceed further.

•	You should see a list of users on the machine.  Find the username you log in as, and make sure that "Administrator" shows up in the list of groups.

•	If you're not in the "administrator" group, click on the "Advanced" tab, and click the "Advanced" button to bring up the "Local Users and Groups" dialog.

•	Click on the "Users" folder on the left side, then click on your user name on the right side.  From the "Action" menu select "Properties".

•	Click the "Member Of" tab.  Click the "Add" button to open the "Select Groups" dialog.

•	Click on "Administrators".  Click "Add".  Click "OK" in this dialog and the previous one.

•	Close the dialog boxes.  You should be all set.

Windows XP:

•	From the "Start" menu, select "Control Panel".

•	Click on "User Accounts".  If you only see the current account, and it says "limited user", you're not an administator and cannot proceed further.

•	Click on the account you want to change.

•	Click on "Change my account type".

•	Click the "Computer Administrator" radio button.  Click "change account type".

•	Close the dialog boxes.  You should be all set.

Win9x/ME does not have the concept of user privilege levels, so none of the above is necessary.


Creating Subdirectories

To create a new subdirectory on a ProDOS disk, select the subdirectory in which it will reside, then use the File->Create Subdirectory command.

This feature is disabled for ShrinkIt archives, because they don't store subdirectories explicitly.  You can, however, rename files to make them appear as if they were in a subdirectory.


This is the name of the directory in which the new subdirectory will be created.


Enter the name of the directory to create here.


Select the volume to rename.  (In most cases you will only have one to choose from.)


Enter the new volume name here.  For DOS disks, enter the new volume number.


Renaming a Volume

You can change the volume name of a ProDOS or Pascal disk image, or the volume number of a DOS 3.3 disk image, by selecting "Rename volume" from the Actions menu.

You will be presented with a tree of volumes to rename.  In most cases there will only be one possible, but if you're working with a disk image that has embedded DOS sub-volumes, or a partitioned image like a CFFA card, you will see multiple entries.  Click on the one you want to rename.

In the box at the bottom, enter the new volume name or number.  When you click "OK", CiderPress will update the volume name.

Volume names for ProDOS and Pascal are very similar to file names.  ProDOS volume names aren't allowed to have a space in them, even if "allow lower case" is enabled, but are otherwise identical.  Pascal volume names use the same set of characters as filenames, but are limited to 7 characters.

The volume "name" for a DOS 3.3 disk is its volume number, which can range from 1 to 254.  (Initializing a disk under DOS 3.3 with volume number 0 yields volume number 254.  Attempting to use volume number 255 results in a "range error".)

The DOS volume number is actually stored in up to three places:

1. If the file has a 2MG header, the volume number may be specified there.

2. If the file is a nibble image, a copy of the volume number is stored in the address header of every sector on the disk.

3. A copy is stored in the disk Volume Table of Contents (VTOC).

The "rename volume" function only updates #3.  The DOS "CATALOG" command uses #2, which means that changing the volume number with CiderPress may not have an impact on what you see in an emulator.  For non-nibble images, most emulators just generate the default volume number (254) into each sector.  CiderPress itself prefers #2 over #3, so changing the volume number on a nibble image may not have any noticeable impact within CiderPress itself.

Some emulators will obey the 2MG volume number (#1), so you may want to change it in both places.  You can set the value in the 2MG header with the 2MG Properties Editor.  All things considered, it's probably best to just leave it set to 254.


Select this to disable conversion of text files.


Select this to automatically determine which files are text files, and convert them.


Select to treat all files as text files.


Tool - EOL Scanner
EOL Scanner

EOL is an acronym for "end of line".  Each line of a text file ends with an end-of-line marker.  The Apple II and Macintosh use a carriage return, UNIX systems use a linefeed, and Windows uses a carriage return followed by a linefeed.  These are usually abbreviated "CR", "LF", and "CRLF".

When text files are moved from one system to another, the end-of-line markers on text files need to be converted.  Unfortunately, overzealous converters will sometimes convert a non-text file, resulting in corrupted data.  The only way to tell if a file has been corrupted is to count up the occurrences of CR, LF, and CRLF, and see if they make sense.

The EOL Scanner tool does exactly that.  The number of times CR, LF, and CRLF appear are counted and displayed.  This information, combined with some knowledge of the format of the file, will tell you if a file has been corrupted by an EOL conversion.  The tool also counts up "high-ASCII" characters to test for conversions to and from DOS text files.

Take for example a healthy 140K disk image.  The scanner reports the following:

143360 characters

43582 high-ASCII characters

381 carriage returns

863 line feeds

3 CRLFs

A typical disk image will have a smattering of CR (hex value 0x0d) and LF (hex value 0x0a).  Occasionally they will appear near each other and form a CRLF.  A disk image with lots of text files will have many more CRs than LFs, while a disk with programs on it could have any amount of either.  (To be accurate, a DOS 3.3 disk with text files won't show a large number of CRs, because DOS 3.3 uses "high ASCII" 0x8d instead of 0x0d.)  Note that an occurrence of "CRLF" only updates the CRLF counter, not the CR and LF counters.

Now lets look at a disk image that doesn't seem to work.  The scanner comes back with:

143360 characters

56085 high-ASCII characters

530 carriage returns

0 line feeds

0 CRLFs

The disk image has absolutely no line feeds whatsoever.  A blank formatted ProDOS disk will have 3 or 4 carriage returns and line feeds, a blank unbootable DOS disk 1 of each.  A non-empty disk should never have zero CRs or LFs.  This disk was corrupted by a converter that changed all of the linefeeds to carriage returns.

Similar results hold for compressed data archives.  Data that is well compressed will show a fairly even distribution of all possible characters, so a total absence of CR or LF is a big red flag.  Of course, if the archive is only a few hundred bytes long, it's quite possible that no CRs or LFs will be found.

Disk images in nibble format (.nib) have no CRs or LFs in them.  This is normal.  The entire file should be "high ASCII" characters.

Besides its use as a diagnostic tool, the EOL Scanner can also tell you what format a text file is in, and also how many lines it has.


Copy and Paste

CiderPress can use the Windows clipboard to copy Apple II files around.  You can copy files from any disk image or file archive that CiderPress can open, and paste them into NuFX (ShrinkIt) archives and writeable disk images (currently DOS, ProDOS, and Pascal are supported).

To copy files, open the archive, select the files you want from the file list, and use "Edit->Copy".  (Or, right click and choose "Copy".  Or hit Ctrl-C.)  The files will be extracted from the archive or disk image and placed on the Windows clipboard.

Next, open the archive where you want the files to go.  If it's a ProDOS disk image, select the directory where you want the files to appear.  Select "Edit->Paste".  (Or right click and choose "Paste".  Or hit Ctrl-V.)  The files will be added.  You can also have two copies of CiderPress open, and copy from one and paste to the other.

If you're pasting to a disk image with sub-volumes, or pasting to a ProDOS disk with subdirectories and didn't select a subdirectory, you will be asked to choose where the files will go.  This is similar to the way "add files" works -- if the destination isn't obvious, CiderPress will ask.

Copying and and pasting is meant to be simple, but there's a lot of complexity underneath it.  Here are some things you should be aware of:

•	Files copied from ProDOS volumes are extracted with their full paths, e.g. "subdir1:subdir2:foo.txt".  You may choose to strip the subdirectories off with a global preference.  This determines whether pasting "subdir1:subdir2:foo.txt" into "subdir3" yields "subdir3:foo.txt" or "subdir3:subdir1:subdir2:foo.txt".  Files pasted to DOS or Pascal disks have their paths stripped automatically.

•	Unlike the "add files" approach, which prompts you when new filenames clash with existing files, "paste" automatically handles conflicting files for you.  If you paste a file called "FOO" to the same disk image twice, the second one will be called "FOO1".  If you paste files with the same name multiple times to a NuFX archive, you will simply have multiple entries called "FOO", because NuFX allows duplicate filenames.

•	Files converted between different operating systems will have their file types converted.  The mapping of DOS and Pascal types to ProDOS types is shown here.  Files pasted to DOS disks that don't have a direct file type conversion will become 'B' if they are less than 64K, or 'S' if they are more.  ProDOS "SRC" files become 'T'.  Most files converted to Pascal disks become "PDA" (generic data).  CiderPress does not currently convert in and out of Pascal Text (PTX) format.

•	DOS text files use "high ASCII" format.  Text files pasted to and from DOS volumes will be converted appropriately.  (Text files copied from one DOS volume to another are left alone, not converted twice.)  Because all Apple II formats use carriage returns to indicate the ends of lines, no end-of-line conversion is done when pasting files.

•	The comments stored in NuFX archives are not copied with the files.  (This may be fixed in a future release.)

•	Copying and pasting files from Windows Explorer is not currently supported.  You can, however, paste into an application such as Notepad to get a tab-delimited copy of the file list (pathname, file type, aux type, etc).  If you paste this into a spreadsheet, such as Microsoft Excel, each field gets its own row and column.

•	Selecting a directory on a ProDOS disk copies the directory, not the directory and all of its contents.  Pasting the directory into a ProDOS disk image creates an empty directory.  If a directory with that name already exists, nothing happens.  NuFX archives do not store directories, so pasting a directory into a NuFX archive has no effect.  You cannot copy the volume directory of a ProDOS disk, though there is no harm in trying.

•	Resource forks are not pasted to DOS or Pascal disks.  If you paste a forked file, only the data fork is added.  (All forked files on ProDOS disks have a data fork, even if it's just an empty one, but forked files in NuFX archives may have just the resource fork.  Pasting a forked file to a DOS disk may or may not actually create a file.)

•	Some DOS games were stored in 'B' files with a short "loader" segment.  The "loader" would start immediately and load the rest of the game itself.  CiderPress obeys the shorter length value, and as a result will not copy the entire file (as evidenced by the pasted file being significantly smaller than the original).

•	Files are copied and pasted in the order in which they appear in the file list.  You can alphabetize your disks by sorting the list by pathname and copying & pasting the files to a new disk.

•	Damaged files are not copied to the clipboard.

•	In Win98, copying 16MB or more to the clipboard causes the system to lock up.  CiderPress therefore limits you to copying less than 16MB of data under Win98/ME.  Because of overhead added to the clipboard data, it's not possible to copy 16MB files (the largest possible under ProDOS) to the clipboard.


If enabled, pathnames will be stripped off of files before they are pasted into an archive.  If disabled, the original directory hierarchy will be preserved.


Select this to treat all files of type TXT or SRC as text files.


Select this to treat all files of type TXT or SRC as text files.


Tool - 2MG Properties Editor
2MG Properties Editor

This tool allows you to see and update some of the attributes embedded in a 2MG disk image file.  Select the disk image you want to open (it will usually have a ".2mg" or ".2img" suffix), and click "Open".

Some fields from the file header are shown at the top.  "Creator" is a 4-letter code for the software that created the file (CiderPress uses 'CdrP').  "Version" is the 2MG file version number, usually 0 or 1.  "Image format" tells you whether the image uses DOS-ordered sectors, ProDOS-ordered sectors, or raw nibbles.  "Blocks" is the number of 512-byte blocks in the file.

"Locked" is a software flag used to indicate whether or not the virtual disk has been write-protected.  Some emulators obey the flag, some don't.

"Specify disk volume number" indicates whether or not a volume number has been explicitly defined.  This is potentially of use for 140K 5.25" disk images.  5.25." floppies have a volume number embedded in the address field of every sector on the disk, but this value is lost when disks are converted to sector images (you have to use nibble images to retain it).  Some emulators will use the volume number from the 2MG header to determine the sector-address-field volume number.  This is only useful for a handful of mildly copy-protected disks that actually care about the volume number.

The "Volume number" field is enabled if the previous checkbox is set.  You may enter a number from 1 to 254.

The "Comment" box holds the comment for this file.  It can be any length you want.

If CiderPress is unable to open the file for writing, perhaps because it's marked read-only in Windows (a common occurrence for files copied off of a CD-ROM), the file will be opened read-only.  You will be able to see the contents of the fields but not edit them.


Indicates whether the "locked" flag is set.  Some emulators will use this flag to decide whether or not to treat the disk as write protected.


If checked, a volume number is specified in the header.  If not checked, no number is specified, and the volume number edit field will be greyed out.


Volume number (1-254).  Some emulators use this field to emulate the sector-address-header volume number field.  Rarely useful.


The comment field is stored in the 2MG file, and can contain anything you want.


Enables conversion of UCSD Pascal code files to a partially analyzed hex dump format.


If enabled, the "read only" box will be checked by default on all Open Volume requests.


CiderPress Help

If you're reading this much, you know how to access the "help" system.  In case you got here by accident: select "Contents..." from the "Help" menu, or hit F1 while the menus are active.  Many of the interactive dialogs also have "Help" buttons that will take you directly to a relevant page.

Most dialog windows have a little question mark ('?') in the upper right-hand corner.  If you click on that, then click on a button or checkbox in the same window, you will get a short description of what that button does.

A Frequently Asked Questions list and a CiderPress tutorial are available from the faddenSoft web site at http://www.faddensoft.com/.

The "About..." item on the Help menu brings up the CiderPress "About Box".  This shows the version you're using, what versions of DLLs were loaded, and to whom your copy is registered.  If the product has not been registered, it shows how many days are left in the 30-day evaluation period.

"DLL" is an acronym for Dynamic Loadable Library.  That's a fancy way of saying that it's a part of the program that is stored in a separate file, which means it can be shared among multiple copies of the same program or multiple different programs.  The DLLs used by CiderPress are:

•	DiskImg.  All of the code for accessing disk images is here.  This is an integral part of CiderPress, and is shared by the CiderPress application and MDC (Multi-Disk Catalog).

•	NufxLib.  All of the code for accessing NuFX (ShrinkIt) archives is here.  This is an open-source library developed by the author of CiderPress.  It's also used by the NuLib2 command-line utility.

•	zlib.  Free software from the authors of gzip.  This provides "deflate" compression, and is used by hundreds of different applications.

•	wnaspi32, a/k/a "the ASPI layer".  Unlike the previous DLLs, this one is only loaded when necessary.  For CiderPress, it's only necessary under Win98/ME, so Win2K/XP users won't ever see this loaded.

The first three DLLs are distributed with CiderPress, and are updated whenever you download a new version of CiderPress.  The ASPI DLL is part of the operating system, and may be replaced when you install CD recording software.  (If you want to use a specific version of wnaspi32.dll, copy it into the CiderPress installation directory, usually C:\Program Files\faddenSoft\CiderPress\.)

Click on "Credits" to bring up some information about the development of CiderPress.  If your copy has not been registered, click on "Enter registration code" to enter the code you received from faddenSoft after buying the product.


The IIgs monitor disassembles BRK and COP instructions as two bytes, which can make some disassemblies harder to read.  When this option is enabled, BRK and COP are shown as single-byte operations.


Enables the CP/M text converter.  Only applies to files that appear to contain text and reside on CP/M disks.


Enables IIgs word processor file conversion, including AWGS and Teach.


Enables code disassembly, including //e and IIgs monitor output.


Format the disk for DOS 3.2.


If enabled, you will be allowed to open physical disk 0 for writing.  This is usually your Windows boot disk, so setting this is not recommended.


Convert 8-bit word processor documents, such as Magic Window.


If set, this attempts to recognize "bad Mac" archives, which have bad pathname separators ('?' instead of ':') and some bad data in the LZW area.


Disable some error checking on ShrinkIt archives.  Specifically, this ignores bad LZW/2 lengths (usually found in "bad Mac" archives) and bad data CRCs.  Leaving this enabled is a bad idea, because you may not discover corrupted data right away.