The Apple II does not need a hard disk.

I've never used applewin, but I do think it supports hard drives. Are you trying to use a specific hard disk image? What format is it?

Yes Applewin supports up to 2 hard drive images. You select them in the Configuration page (click the icon on the right with the joystick and speaker icons). Supports .2mg and .po formats.

Here's an excellent video tutorial on YouTube that can help you.

AppleWin - Creating A HDV (Virtual Harddisk) File & Running Programs LongPlay

https://www.youtube.com/watch?v=l8XdSaxq7vA

Good luck!

Not knowing the newbie's background - we may be assuming a bit too much here...

So, just to mention the very basic, since not everyone grew up in (or before) the 80s and knows what computers were like back then: yes, it was normal for an Apple II to *not* have a hard drive. Hard drives were even really uncommon, at least for home users. And you didn't need to "install" software on an Apple II. In order to run an application, you would just pick the disk for the specific application, insert it into the disk drive, switch the machine on - and it would run. Just like that! :-)

So, yes, AppleWin is able to emulate a hard drive - but it's not the common approach for running software on an Apple II (hence, this option is rather hidden in AppleWin's menu).

There are very few things that you could do with a HDD image on a //e emulator. You could run MouseDesk, or GEOS, but unless you are doing productivity with ProDOS, that isn't very useful.

More practical, if you want to use USCD-PASCAL, is a HDD image for the PASCAL OS. 

Other than that, if you have a lot of games that are not copy protected, that you can convert to the ProDOS filesystem, you can toss them all on one image.

The maximum ProDOS HDD size is 32MB, and the largest DOS 3.3 size is, iirc, 400K. I think that USCD-PASCAL caps at 10MB, but that may be wrong. At the least, the largest USCD-P drive that I ever ran was 10MB. 

You can also use a HDD for CP/M, but as you are already running emulators, you are better off emulating a native CP/M system if you want to run CP/M software and HDDs easily.

Keep in mind, this isn't like PC-DOS. You can't copy (commercial) game disks to a HDD and run them from directories. You can however, create a lot of space for unprotected games/binary software that loads with BRUN, or BASIC programmes; or to write your own software. As was the case with Lotus 1-2-3 and Corel on DOS, the main reason most Apple ][ owners (prior to the //gs) owned a HDD was for use with AppleWorks. 

This is likewise, true of using a HDD on the Apple ///, as its library was almost exclusively business/enterprise software. For everything that I do, as complex as some of it is, I am usually quite content with a 2MB SuperDrive for mass storage on a //e. You haven't stated any specific goals, so I hope that this was useful to you. 

Timelord wrote:

I think that USCD-PASCAL caps at 10MB, but that may be wrong. At the least, the largest USCD-P drive that I ever ran was 10MB.

I'm a bit confused with that, and I did not really check this before. The block size is 512bytes. A directory entry has a pointer to first block used by this file, and a pointer to the next free block after the last used block. The pointer is an integer value (not unsigned integer), means maxint is 32767. So the maximum file system size is 16MB - 1 block.

This is based on the file system of Apple Pascal (UCSD II.1). But normally nobody is interested in this detail because the maximum number of directory entries is 77 which is the practical limit.

RalfK wrote:

Timelord wrote:

I think that USCD-PASCAL caps at 10MB, but that may be wrong. At the least, the largest USCD-P drive that I ever ran was 10MB.

I'm a bit confused with that, and I did not really check this before. The block size is 512bytes. A directory entry has a pointer to first block used by this file, and a pointer to the next

This makes sense. Drive sizes went 5MB->10MB->20MB, and thus 20Mb was not supported, but 10MB was supported. We used a 10MB ProFIle for it. The USCD-P F/S is also notorious for wasting space by being unable to use non-contiguous data blocks.