Winbasp on Mac - test notes

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.

Relevant specifications for my Mac:

256 kB level 2 cache buffer (I think this is correct, I will have to check what is actually installed)

1 MB VRAM

16 inch Apple monitor (832x624, 16 bit colour)

System 7.5.3

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

states an amount of ram that the manufacturer suggests the program should be allocated,

allows the user to enter a minimum value of ram that the application will take and use, and

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:

12 MB be used as PC extended memory

1 Mb for conventional memory and high memory

2 MB be used as SoftWindows' "DeltaCache"

the remainder to be used by the program SoftWindows itself.

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".

Mactests:

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.

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.

In Windows, virtual memory was on (type=permanent 7,446 Kb) in all tests except the last 3 runs in which it was set to 0 Kb.

All tests were run on the same 32 M c: drive (the minimum configurable size for a PC drive under SoftWindows 3.0). My Mac hard disk was defragged shortly before running the tests.

All tests were run with SoftWindows configured to 12 M extended memory for the emulated PC.

All tests were run with SoftWindows configured to "optimum performance" with regard to window size/placement and screen bit depth (set to the same on the Mac as in SoftWindows - in this case 8 bit).

All tests were run with SoftWindows 487 emulator on (undocumented runs with the 487 emulator disabled required from 211.1 to 391.4 seconds, although the Mac screen saver came on when I was not watching and may have affected the latter). Note that the SoftWindows documentation reports that:"Due to differences in precision of the floating point unit, some programs may not function in the same way as on a PC when the 487 Co-processor is enabled. For example, rounding of decimal numbers may be incorrect or in the case of Lotus 1-2-3R4 for Dos, the Quickstart tutorial will display incorrect graphics. In such cases the 487 co-processor should be disabled. This is due to the difference in Floating point accuracy between a PC (80 bit) and a Macintosh (64 bit)"

All tests were run under the standard installation of Winbasp (.dll files in c:/windows/system).

* 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.