 | |
| Microsoft MultiPlan running in M.e.S.s. emulator |
A Darn Good Spreadsheet.
This is a way of saying this is a darn good spreadsheet. Another way of saying it is to recall an article i once read (can't find the article at the moment) in which Bill Gates was asked what he considered to be mistakes he'd made early in the history of Microsoft. Notably, he said he pumped too much research and development into a spreadsheet (MultiPlan) for the eight-bit chip. MultiPlan for sixteen-bit chips (DOS) shipped September 1982, 13 months after the IBM PC shipped, and four months before Lotus 1-2-3 shipped. The copy of MultiPlan that still runs on my still running eight-bit Visual 1050 has a copyright date of 1981. This suggests that at the very time MultiPlan was shipping for eight-bit computers, it could have been shipping for the IBM PC and clones.
It's hard to say what would have happened if the better featured Lotus 1-2-3 came out four months after Multiplan, instead of the other way around. But Microsoft had to abandon the 16-bit DOS world to Lotus 1-2-3 and make up for it's mistake by focusing on the 32-bit world of Windows with Excel. In this way, Bill Gates feels he learned from his earlier mistake and made up for it.
On my still running Visual 1050, i've been playing with MultiPlan, and can definitely feel Excel vibes. I have to say, it's a darn good spreadsheet. It just works. The menu that appears at the bottom of the image above is easy to use, and seems highly intuitive for it's day and age. I don't know how it compares with it's eight-bit predecessor, VisiCalc, but at least it managed to avoid the ire of this blogger who hates pretty much all our good old killer apps. In terms of size, VisiCalc (download here) was apparently 28Kb compared to MultiPlan's 44+18+8 (70) Kb, not including 42Kb of semi-intuitive built-in help available at the click of a button. In addition, there was 78Kb of installation code in order to customize MultiPlan for each eight-bit brand of hardware. Somewhere in all those bytes was enough extra power to load and consume VisiCalc worksheets, if that tells you anything.
The Visual 1050 came with MultiPlan pre-installed for it's monitor and keyboard configurations. For example, hitting the HOME key will take the cursor to R1C1 (row 1 column 1). Hitting H (or the HELP) key will open up help, control-J will jump from one unlocked cell to another, and the semicolon (;) will switch windows. And of course, the directional keys on the numeric key pad will move the highlighted cursor from cell to cell. In today's phraseology, it just works.
This is all to say that i am actually pretty happy to have what i consider the high-water mark for eight-bit, character-oriented spreadsheets and can't imagine how it could get any better. I consider it a work of art considering the memory restrictions it dealt with. For example, even though it offers 255 rows and 63 columns, a standard 64Kb RAM page of memory will only allow about half that while it share RAM with MultiPlan(up to 255 rows x 32 columns, or, 130 rows x 65 columns) . Until i figure out how to tap the extra "banked" memory scheme offered by both CP/M Plus (3.0) and the Visual 1050, i can simply link to specific cells within supporting spreadsheets. This way, MultiPlan can pack a lot of calculating power into dependent spreadsheets without going overboard on RAM consumption. I estimate that MultiPlan could've made some really nice dashboards for the CEO's of a few respectably sized businesses.
To test MultiPlan's ability, i implemented a cool calendar based on this article from the "Wizard of Excel" using the information in this tutorial from Grey Matter Mental Gym blog. By going back and forth between MultiPlan and Excel, i found out what formulas from the article i would not be able to use. MultiPlan can't use VALUE to handle a string like "10/15/13" as a date. And it doesn't have a WEEKDAY function. So i worked around all that by some heavy reliance on lookup tables. There were a couple more workarounds that i describe in the notes included with this project, which i have provided for download below.
First, i implemented this project on my old hardware to verify it can be done in MultiPlan. I went back and forth between my old hardware and Excel to find out what would actually work in both environments. Plus i used the speed of Excel to do a lot of the design and testing. Then i sent files saved as SYLK file format (a language understood by both Excel and MultiPlan) into a virtual diskette that i ran on the Visual 1050 in the M.e.S.s. emulation. I found out that putting both the calculator and calendars on the same spreadsheet was a little heavy for the little eight-bit PC to handle (it could barely handle it). So i split the project up into two parts/spreadsheets and linked a few cells from one to the other. The calculator part is modeled on this page here. Here is a .zip file of the entire project.
ExcelToMultiPlan.zip Download
There are notes inside that show how to optimize Excel formulas to work with MultiPlan. I also show how to move files between Excel and MultiPlan and make simple modifications so they communicate perfectly.
 | |
| Day-Of-Week Calculator |
The calendar spreadsheet is externally linked to the year and month cells on the calculator spreadsheet. With links to those cells, calendars can be generated for any month, or any group of months for any year. However, even though i split the project into two worksheets (only one is loaded into memory at a time), i found more than ten calendars to be too much. I found four calendars about right, using up 28% of available memory. These can be printed to file and opened much faster with the TYPE command (read as text), or printed to paper for even quicker reference.
 | |
| Calendar-Maker Sheet |
Time
Seconds
15 - boot the CP/M operating system.
5 - display an optional front-end menu system.
10 - load Multiplan empty
8 - manually set default to B: drive (i store files separately on the B: drive)
5 - seek and select a spreadsheet
10 - load calculator spreadsheet
2 - set the recalc option to No. (otherwise will recalculate after every cell change)
10 - change the values of three cells and hit Shift-! to calculate.
12 - calculate the day-of-week
6 - save the spreadsheet
5 - seek and select another spreadsheet
30 - load and display a quarterly calendar
-----
118 seconds over all
42 seconds just to do all the calculations
But by the time i fumble around with all the keystrokes, it takes more like 200 seconds just to run the two spreadsheets. This could all be speed-ed up by booting to a command line, and invoking a .sub (CP/M version of .batch) file, this could mostly be automated. Submit (.sub) files can access applications like Multiplan, enter data, manipulate the application's menu, and close the application.
To test that theory, i wrote a .submit (like .batch) program to automate the whole sequence:
mp b:mc.mp
<on
<to^ib:
<gr1^i1
<^f$1
<^f$2
<^f$3
<ts
<ytlmcq.mp
<tsmcq.mp
<y
This script took 100 seconds to run the two spreadsheets, entering three parameters along the way. To write it, you have to walk through the sequence manually, writing down each keystroke. I was able to enter data into three different cells because of the feature talked about in the first paragraph of this article: the ability to jump from one cell to another in an otherwise locked spreadsheet. There are only three cells on the entire spreadsheet that are open for movement via Ctrl-F which is denoted as ^f in the script. I just homed the cursor and started stepping through the cells. There's also a tab in there denoted as ^i. The $1 $2 and $3 in the script are the parameters taken in by the .submit script (like %1 %2 %3 in .batch language). In this way, i was able to call the whole thing like this:
>go 2 20 2014
With just the name of the script, month, day, and year i could spend 11 keystrokes instead of 75 (and a lot of work).
 | |||
| Print to file. |
