Back to the Homepage

Winbasp on Mac - test notes

by David Simpson

Below I include my notes from tests run using Winbasp on a Mac under Softwindows. For those unfamiliar with Mac computers I also provide some information about my computer as well as a brief orientation regarding memory allocation in Mac and SoftWindows.

I got Winbasp downloaded and installed..., and took a few minutes for some unstructured exploration. The installation procedure went smoothly, no problems at all.
I also put the Displa feature of Winbasp through its paces in order to determine the amount of memory required to display a given map in .bmp format.
My own interest in this venture has been to test my version of SoftWindows as well as learn something about Winbasp. For me it has been a success. I hope it is of some help to others as well.

(Softwindows is a product of Insignia Solutions. See the company's announcement and the review in the MacUser-Magazine for further information.)

Relevant specifications for my Mac:

Note that this is likely the last Mac to be produced with the old 601 processor. I have read that the 603e processor of the current generation is twice as fast as the 603, that is, with both running at the same clock frequency. I imagine that the improvement of these over my old 601 would be vast.

Mac memory allocation:

Before running an application in Mac, you have the option of adjusting the amount of memory allocated to it. One just hilights the application's icon with a mouse click and from the menu or a keyboard shortcut request Get Info. The resulting dialogue box displays the program's name, version, creation date, last modification date etc. It also
  1. states an amount of ram that the manufacturer suggests the program should be allocated,
  2. allows the user to enter a minimum value of ram that the application will take and use, and
  3. a preferred value that it will take if that much ram is available (older versions of the operating system do not provide the preferred option).
One could thus enter a minimum required value that is less than the manufacturers suggested ram allocation on a ram poor system, or if pushing a specific application to its limits (loading large documents) one might find that the minimum ram allocation will have to be boosted much beyond the manufacturers suggested value.

In addition, on Macs with PowerPC processors, certain programs also state in the Get Info dialogue box that memory requirements for the application will decrease by 1 MB if Mac virtual memory is turned on, or that requirements will increase by 1 MB if Mac virtual memory is turned off. Turning on or off virtual memory will automatically adjust the minimum allocated value for these programs in the Get Info dialogue box. This is the case with for SoftWindows. Thus, if I turn on virtual memory, allocating the minimim configurable 1 MB of hard disk space, then SoftWindows and various other programs with this feature I may have running simultaneously will require 1 MB of ram less EACH. Very strange if you ask me, but thats how it seems to work.

SoftWindows and memory allocation

The Mac sees SoftWindows as any other Mac application - give it its ram and hard disk space and let it do its thing. When it comes to hard disk space, SoftWindows creates a "hard disk file", the size of which corresponds to the size of the emulated PC hard disk. As I understand, the maximum hard disk size you can create is 256 MB, but in addition to creating a "bootable c: drive", one can also create an additional "non-bootable d: drive" (@ 256 MB each). Not only that, but you can create as many sets of c: and d: drive files as you have Mac hard disk space for (or the fine print somewhere in the manual may state a maximum here) though only one c: and d: drive may be used at any given time. However, from within SoftWindows the user can define a "shared" directory, that is a Mac folder (directory) that will become an e: drive to the emulated PC. The capacity of that shared directory is thus limited only by the amount of free space on the Mac hard disk! (A quick side track, the emulated PC created by SoftWindows not only accesses my diskette station, but also accesses my internal CDrom station and Iomega Zip drive. Installation of drivers etc. took place automatically under the installation of the PC hard disk file. All I had to do was run SoftWindows and insert the Zip disk and a CD. One thing I have to look into here is that it appears that I can have either a shared directory or use the Zip drive, but not both at the same time.)

With regard to ram, during installation SoftWindows looks at the Mac system and makes recommendations regarding how much ram should be allocated to itself and how the user might best allocate that ram within SoftWindows. For example, upon first installation (if I remember correctly), Soft Windows suggested I devote 21 MB ram to SoftWindows, of which:

The amount of ram allocated to SoftWindows itself is of course configurable after installation (see discussion of Mac memory allocation above), as is the amount of ram to be allocated to PC extended memory and SoftWindows' "DeltaCache".


I used the stock configuration that resulted from the SoftWindows installation with the exception that I ran memmaker to free up more conventional ram, added a Norwegian keyboard driver, and modified the mode and path commands in the autoexec.bat file.

Listings of the config.sys and autoexec.bat follow:


    DEVICE=C:\DOS\himem.sys /TESTMEM:OFF
    REM device=c:\insignia\cdrom.sys
    REM - ISL2_END


    @echo off
    LH /L:0;1,43920 /S C:\WINDOWS\SMARTDRV.EXE C 1024,128
    path C:\windows;c:\insignia;c:\dos;c:\insignia\softnode\netbatch;
    set TEMP=C:\DOS
    c:\insignia\fsadrive e: g: h:
    LH /L:1,1136 c:\insignia\
    mode com1:19200,n,8,1
    prompt $p$g
    LH /L:1,55168 COMMAND /E:256 /Cc:\insignia\usecd.bat
    REM - ISL2_END
    keyb no,, c:\insignia\keyboard.sys
    echo Type WIN and press RETURN to start Windows.
Regarding loading DOS high, the SoftWindows documentation reports that this will degrade peformance. I have not tested the impact of this in the following tests.

Test runs:

    Run     Ram     Mac     Mac     Allocation      Delta           .bmp    test
    #       Doubler virtual ram     to Soft         Cache           crash   time
                    memory*         Windows                         **      (sec)
    1       on      off     64 M    31,123 Kb       11,190 Kb       no      58.8
    2       off     1 M     33 M    21,123 Kb       2,524 Kb        yes     37.1
    3       off     32 M    64 M    21,123 Kb       2,524 Kb        yes     36.8
    4       off     32 M    64 M    31,123 Kb       1,2524 Kb       no      39.8
    5       off     off     32 M    22,279 Kb       2,523 Kb        yes     35.0
    6       off     off     32 M    25,000 Kb       5,224 Kb        yes     37.0
    Establishing limits for .bmp crash:
    7       on      off     64 M                    6,524 Kb        yes
    8       on      off     64 M                    7,524 Kb        no
    9       on      off     64 M                    11,190 Kb       no
    Effect of Windows virtual memory (and general stability):
    (8,177 Kb Windows virtual memory)
    10      off     1 M     33 M    25,123 Kb       6,524 Kb                35.4
    11      off     1 M     33 M    25,123 Kb       6,524 Kb                36.1
    12      off     1 M     33 M    25,123 Kb       6,524 Kb                36.4
    (0 Kb Windows virtual memory)
    13      off     1 M     33 M    25,123 Kb       6,524 Kb                35.1
    14      off     1 M     33 M    25,123 Kb       6,524 Kb                34.9
    15      off     1 M     33 M    25,123 Kb       6,524 Kb                35.0
*  Note that larger amounts of Mac virtual memory (32 M) resulted in SoftWindows (and Windows once in the emulator) to take a very long time to load.
** Reflects success (or otherwise) of attempts to load a 708,670 byte .bmp map of Scandinavia in Winbasp's Displa feature.
On this topic, Irwin Scollar remarks:
"...the bmp file crash seems very memory dependent indeed. The physical disk size of the file probably does not reflect what Windows or its emulation may need when constructing it on the screen. I suspect that when it is expanded by the Windows API call, the machine may use 1 byte for every bit in the original which is a simple two-level map, but I am not sure. That would account for the need to have so much memory to display it."

I hope this is of some help, and if there are any problems with the formatting of the table please let me know and I will send it to those interested from another email program or as a Word, WP or Excel etc document as an attachment.
     David Simpson            |     e-mail:
     Arkeologisk Institutt    |     tel:    +47-55-582933 (office)
     Universitetet i Bergen   |             +47-55-328967 (home)
     Haakon Sheteligs pl 3    |     fax:    +47-55-589178
     5007 Bergen, Norway      |             +47-55-589656 (alternative)

Back to the Homepage
Last update: March 8, 1997