Retrochallenge 2019/10 Final Update

As sometimes happens Retrochallenge efforts take turns and twists.   The progress made on the GUI version on the Superstar Baseball game was sufficient proof of concept for me to know that Visual MUMPS was capable.  While working on the game I kept having ideas to improve Visual MUMPS.  So this final post for the challenge will document those improvements. These improvements include providing GUI versions of existing system routines, and the beginning of Visual BASIC type IDE for creating Visual MUMPS applications.

A number of options were added to the MUMPS menu, that provide GUI versions of MUMPS system routines. Specifically (^%io – IO status, ^%gd – Global Directory, ^%g – global display, and ^%vd (or w  ) for variable display. Also Clear Console (w #) was added.


IO status used to provide a text listing on the console of the status of each IO unit number (used to read and write files) now it shows them in a listbox, which later enhancement may allow closing units from listbox.


Next the Global Directory shows all the global (arrays stored to disk) that are in the database, in a listbox.  Then the global can be displayed by selecting the list item and clicking the display button.


The global can also be displayed by selected Global Display, which provides a dialog asking the user to type in the global name.


Whether the user selections the global ^icecream from the global directory screen and clicks the display button, or uses the Display Global option above the output is a text listing of the global.



The IDE is still undergoing development  but let’s review progress to date.  The IDE is invoked from the IDE menu, or open apple I.  When selected a dialog for specifying the parameters for a window is presented. The parameter are set with a combination of line edit, popup menus and checkbox.  These parameters match those needed in the $zwindow() function call.

Clicking the “Try” button displays the window according to the parameters set :

Result of clicking Try Button

Clicking the “Close” button or the Close box on the Trial window closes the window.  Save will eventually produce the Visual MUMPS code associated with this window, (including controls which are created by clicking the “Ctrl” button)

Adding Controls to the window with the “Ctl” Button is done through a two window activity.  The first window allows the selection of the control type, adding a new control or the selection of an existing control and editing it. A “Try” button will also be provided.

Well that wraps up this Retrochallenge, I forged on with my projects despite there not being much from organizers of this round of the Retrochallenge, with that the spirit of the Retrochallenge is to do retro-computing, and a few of us carried on in light of minimal or no formality of the Retrochallenge.



Retrochallenge Update #5 – Listbox – Change to Load Window

When Anidar Visual MUPMS was first released it had a good number of GS/OS controls available in the interpreter, but there were still a number missing including the List Manager tools.  Well the Listbox control has been added along with three function calls, $zwaddlitem() with adds items to one of two embedded lists, $zwlist() which places the list box control on a window, and $zwgetlsel() which returns the number of the selected item in a list.

With these new tools at my disposal I rewrote the load data window for the baseball game.  While the radio buttons worked, I think the listboxes provide a much cleaner user interface.

The implementation of the list manager functionality in Visual MUMPS allow for two lists at any time, both can have up to 50 items up to 80 characters in length. The lists are simply numbered 1 and 2.  The lists are defaulted to only allow single selection this will likely be expanded to allow multiple selections.  Each item in the list can be set as selected or not selected and dimmed (not available) or available.

Show below are the calls which can also be found at along with all the other Visual MUMPS function calls.


Retrochallenge 2019/10 Update #1 – Splash Screen – Main Menu

As noted in my project intent I am going to use Visual MUMPS for the Apple IIGS that I developed in the previous Retrochallenge to do an update to the Superstar Baseball game that I wrote for the Timex Sinclair 2068.

So starting out I made the decision to use 320 graphics mode, while it is a lesser resolution it’ll give more robust color options and I’ve not done much programming in this mode so I wanted to give it a try.

So looking back to the original game the program starts with a splash screen and then a menu to set up the team lineups for the game. The game is a computerized version of an old board game, where each player has it’s own data card, more on that in the next post.

Here is the splash screen and menu from the original :


So let’s take a look at how this can be done with Visual MUMPS

The code for the program will be called bb320.mps ( the mps is what I use to denote MUMPS source code, and the file should be text or source file type).  The splash screen will be done with an alert box (message box), but first the graphics mode will be switched to 320 mode and the MUMPS console window will hidden.  Then the message for the alert box set and alert created. 

Source code : 

bb3B0 ; superstar baseball in 320 graphics mode for Apple IIGS

; set to 320 mode and hide console
w $zgmode(320),$zwhide(0)

; splash screen for game start
set b8=” ”
s smsg=b8_”Superstar Baseball”_$c(13)_b8_” For Apple IIGS”_$c(13)
s smsg=smsg_b8_” Version 2.0″
s %z=$zwalert(smsg,3,3,0,-1,-1)
k b8 ; delete the variable b8 (blanks) as it’s no longer needed

What it looks like:

Starting the ^bb320.mps program and splash screen


Next I there were a couple of choices for implementing the menu.  My first inclination was to build a window with buttons for each menu option, and also radio buttons for the choice of home team, this allows for some colors splash and make it pretty clear what options are next : 


but then I remembered that I had added a User menu, that supports up to 9 application definable menus that can be used and that might look something like: 


What is not addressed in this approach is the selection of the home team.  So a menu item and window that would allow the selection as show above  or two menu items to for AL home and one of NL home could also be used as shown below.  It would have been good to implement the check marks on the menu, but that has not been done yet in Visual MUMPS.


I think I’m leaning towards my initial idea of the bottom box, with radio buttons, because as I think ahead there may be additional opportunity to use the menus.

Regardless of choice the Visual MUMPS programming language makes it easy to prototype the various options. 

More to come…

RetroChallenge 2019/03 – Final Wrap Up

Listed below is my initial goals in italics and what I was able to complete in bold for the testing and release of Andiar MUMPS, Character based and GSOS Windows based versions.

A. Release of a new Programming Language for the Apple IIgs – MUMPS – character based interpreter including tutorial documentation and YouTube training videos.

Completed the AndiarSoftware wordpress site with all the updates for the new GSOS extension function calls, several video shorts on Youtube on the Andiar Software Channel

B. Launching the retro software company I always wanted as a kid – Andiar Software – WordPress site, Gmail, Twitter to support A. And C.

Completed with Twitter account AndairSoftware, gmail, and wordpress site as mentioned above

C. New programming to use the character MUMPS interpreter and take it GUI in GSOS, in a way that greatly simplifies and removes barriers to entry in GSOS GUI development,

  1. including interpreted GUI – this was the key accomplishment and one that took the most work. Extensions to the programming language to create windows, controls, access to graphics for lines, and shapes were created tested and throughly documented on the site.
  2. conversion of resource (.rez) files to mumps code, which will allow use of Design.Master GUI / resource editor use for interpreted “Visual Mumps” and one proof of concept application possibly – the rez2m.mps utility was written and tested to convert Rez resource code to Visual Mumps code, a sample menu creation program was used to test.
  3. simple RPN calculator or simple database front end. – Instead of a RPN calculator a Battleship game with player vs computer mode was an excellent test of a significant application being written in Visual MUMPS. It made use of multiple windows, controls, lines and shapes along with some complex logic and multiple source files to improve application speed.

The following are stretch accomplishments that were beyond the planned ones:

Stretch achievements :

  1. Added user menus to the Visual MUMPS environment allowing function calls to add menu items, with callback code to one of nine positions in the User Menu.
  2. Several small sample programs written to test specific functionality of Windows, buttons, checkboxes, radio buttons, static text, text, lines, boxes, ovals and thermometer control.
  3. Ported the character version of Andiar MUMPS to macOS 6.0.8 using Think C, and mocOS Mojave using clang. The Mojave version seems to be working well. There are some issues with the 6.0.8 version that need to be investigate (memory/system errors) But it is quite a interesting that with minimal tweaks that the ORCA/C code runs in all these environments.

So that wraps up this round of the RetroChallenge. Nice work by all and special thanks to John Linville for carrying on the Retrochallenge tradition.

RetroChallenge 2019/03 – Andiar Mumps on MacOS 6.0.8 and Mojave

Just a quick note before my RetroChallenge 2019/03 final wrap up. As an experiment I have ported Andiar MUMPS character version to both Macintosh 6.0.8 using the Mini VMac emulator and the Think C 5.0 compiler, and to my modern day Macbook Pro running macOS Majove, compile with clang.

While I’ve gotten each to compile and run the character version of the MUMPS interpreter, the Macintosh 6.0.8 version gives a system error, Out of Memory after trying to run more than a couple of MUMPS programs. Admittedly I basically just ported and compiled, fixed a couple of parameter passing issue but have really not looked into it deeper yet. It most likely is a memory leak or the way I segmented the code, but could be an emulator issue as well. I need to try on my MacSE and see what the real hardware provides. The version on my modern Macbook Pro seems to be just fine, but perhaps there is so much ram that any issues my be masked. That said it’s quit amazing the Orca/C was so portable!!!

RetroChallenge 2019/03 – Update Mar 29 – Resource to Mumps Utility

Design Master is a GUI resource utility provided in the Byte Works suite of development tools. It provides the capability to create Window with controls via point and click.

The resulting window can be saved in a number of formats, (not Visual Mumps since I just wrote it 😉 ). However I have written a utility in Visual Mumps to convert windows and controls created in Design Master and saved in REZ source format to Visual Mumps.

Window with controls being saved in Rez Source format

The menu driven Design Master allows the user to easily create windows and controls, here is a sample application interface I put together that will be used to create a program that will add menu items to the User Menu in Visual Mumps.

Selecting a control to add to the window
Interface for entering menu item title and callback, and radio button to select menu slot to store in Visual Mumps User Menu.

The window contains two Static Text controls (Title, Callback Code) two edit line boxes, nine radio controls and two buttons. Once saved in Rez source format the “REZ2M.MPS” program can use it as input. The utility is started with the command d ^rez2m.mps

Starting the resource to MUMPS conversion program.
The input filename setmenu.rez has been entered and the program is ready to run.

One simply enters the name of the resource source file and clicks the Run button. The thermometer control in the window will provide real time conversion progress information.

The resource source code for this window is over 300 lines long, here is the resulting Visual Mumps code immediately following the conversion.

Visual Mumps code for setmenu.rez – 300 lines of code reduce to about 20

A few notes about the resulting Mumps program. First it will run as is and display the window and controls, but of course no logic for button clicks, or text entry is in the program as Design Master only builds the interface pieces. Also REZ2M.MPS “makes up” generic variable names for each control, all named zvarX, where X is an integer counter. zvar3 is the variable name which hold the index to the line edit control for the menu item title. Also with variable for the window is always “win”. Finally the current version of Design Master to Visual Mumps utility supports Windows with Static Text, Buttons, Radio Buttons, Checkboxes, Line Edit controls. Design Master did not support Rectangles or thermometer controls, and Design Master has some additional controls not yet in Visual Mumps.

Running setmenu.mps after creating the MUMPS code using REZ2M.MPS

After adding in logic for each of the controls in the callback parameter, typically the last one in the control function call), and two subroutines “save” and “exit” the program is complete provides an easy way to add items to the menu.

Running setmenu.mps – adding a new menu item to position three
Result of running setemenu.mps – Lines program added to menu in position 3

Retrochallenge 2019/03 Update – 3/24 – Battleship

Over the past three weeks I have been documenting the Visual Mumps programing language and environment on the site, with some very simple code examples. This post presents a full version of the game Battleship written in Visual Mumps. One of my goals for this Retrochallenge is to provide a full program written in my new programming language. Here is a quick review of the Battleship game followed by the Visual Mumps source code. B

From Wikipedia : “Battleship (also Battleships or Sea Battle[1]) is a guessing game for two players. It is played on ruled grids (paper or board) on which each players fleet of ships (including battleships) are marked. The locations of the fleets are concealed from the other player. Players alternate turns calling “shots” at the other player’s ships, and the objective of the game is to destroy the opposing player’s fleet.”

This version run with the d ^bship.mps command at the Visual Mumps command prompt. The game starts with the naming of your naval fleet and selection of the Play Mode level. Easy mode is the traditional alternating turns, medium allows the computer two shots for everyone the player takes, hard 3 shots for the computer per turn and random, allows the computer 1 to 3 shots per turn, randomly. There is no AI built into the computer’s turn, just random selection of letter/number grid position for each turn, so easy is really easy.

Screen shot of player position his/her fleet

Upon clicking the OK button on Fleet Identification window, the player is presented the fleet grid and fleet positioning window. Each player has five ships in their fleet, of varying length: Aircraft Carrier “A” 5 spaces, Battleship “B”, 4 spaces, Cruiser “C”, 3 spaces, Submarine “S”, 3 spaces and Destroyer “D”, 2 spaces. Each ship can be oriented Horizontally or Vertically on the board and placed using the letter/number radio buttons.

Once the player completes placement of his/her fleet the computer positions its fleet, of course those ships are not displayed. The computer’s grid is on the right side of the screen, and “Bridge Deck” is seen in the middle.

Screen shot of Battleship ready to begin play.

Within the Bridge Deck window the player selects the grid position he/she wishes to take a shot. If there is a computer ship in that grid position, a purple oval is displayed, otherwise a white one is shown. Then the computer takes a turn, taking its one to three shots based on the play mode. Statistics are displayed for each player, the total number of shots taken, hits and misses are shown, and letter and number of shot(s) taken during the last turn. Also as a ship is sunk, its letter A,B,C,S,D is turned from green to purple. The image below is a sample of a game in progress.

Battleship game in progress, Play Mode Medium, computer gets two shots per turn

The game continues in this manner until either the player sinks all of the computer’s ships or the computer sinks all of the player’s ships.

Computer wins the game

Shown below is the Visual Mumps source code in files named (bship.mps, bship0.mps, bship1.mps, bship2.mps, bship3.mps, bship4.mps, bship5.mps). All these files are relatively small. All the source code could have been in one file, however splitting them up speeds up program execution. Like in BASIC GOSUB calls, the “DO” command in mumps scans file for the line label being called so placing subroutines in other files reduces the number of lines that need to be read.