Retro GUI IDE and WeeGUI – Objects #3

In the last post the label and numberbox (spinner) control was added for how many numbers the user wanted to play.  We start this post with the addition of two more number boxes, one for number of games to play (1-999) and one that we will use in this session to select which numbers the user wants to play. Here’s what the updated screen looks like :


The default number of games to play is 10, and the starting point for selecting a number is 40, the middle of the keno board.  In review here is what the number box code looks like for the two new ones, labels in the first picture and the set up code for the numbboxes:



From the highlighted code block above then number of games numberbox value will be in variable VI, and we can see it set to the default value of 10 in line 60107.  Similarly VK =40 in line 60110 will be used for the selction of a number to play. Also the callback routine line numbers are 1800,1900  and 20000, 21000 for the games to play and selected numbers.  The code at 18000 is show below with min of 1 being tested in line 18000 and max of 999 tested in line 19000, for the number of games to play.


Moving on to selecting number to play, this will require a bit of user code to be written in the scratch pad.  First a button will be added to be used to select the number from the previously added number box.  To add the button let’s take a look at the RGI interface. A button object is added ast 22, 20 with width 5 and the caption “Add”.


The updated progam screen :


This is view number 12 for this program (and the 13th total since the count starts at 0).  So there are only 3 left for use.  The purpose of this button is to a. store off the number selected buy the user for checking later for a “hit” when the game is played, and also to mark on the board with ** the numbers the player has selected.  This will be accomplished it the callback subroutine for the Add button.  Looking the the automatically generated code we see the callback line number is 22000. We also know that RGI puts in a rem statement at 22000 and a return at 22999.


In the next post the callback funtion code store and mark the board will be added.


Retro GUI IDE and WeeGUI Objects #2


In Windows applications they are called spinner controls, in Retro GUI IDE I call them number boxes, why ? well I guess from text box to number box.  This is not a WeeGUI object (view) but it is composed of two buttons and a &print statement.  There are three of these in the KENO simulator, one for how many number the player will play, one for the number of games to simulate and the third is used to help pick the numbers on the board to play.  In this post the number of games option will be explored.

In this version of KENO the player can select to play between 5 and 10 numbers inclusive.  A label is added to identify the number box “How many #’s to play :”, at position 2, 14.  The number box then is added at 26,14, with a width of 3.  This will result in the characters for the number, one space and two button next to each other.  One button will lower the number by 1 and the other will raise it.  Here’s what it looks like in the IDE and when run.


The Min and Max cotrols in the IDE will be the limits that the number box can take values.  The value field is the starting value for the number box, the number of games in the running program is 10.  There is some minor complexity to the code that is automatically genetated.  There is code that is needed to create the control in WeeGUI then some in the call back function for each button to increase or decrease the value, which is stored in a variable also created by the code building engine.

The code segment below is what is needed to create the increase “>” and decrease “<” buttons and to display the initial value.  Line 60102 is the increase button, the following line is the decrease button.  Line 60104 creates the variable VG to hold the value for the number box, sets it to 10 and then creates a string so it can be displayed VG$.  It’s important to note the variable names VA-VP should be avoided as then will be used for values for views 0-15, where VA is for view 0, VB for view 1 etc.  In addition line number 10000-25999 should be used for call back functions where line 10000 is the starting line number for view 0, 11000 for view 1 upto to 25000 for view 15.  For this number box the bottons are views number 6 and 7, so the blocks of code 16000 and 17000 are the callback area as can been seen in the &BUTTN statements below.


When a button is clicked a gosub is executed within WeeGUI to the callback line number.  For a number box the call back funtion is automatically written, but one could also add additional code if some other actions were needed in the program.  The auto generated code is pictured below:


Lines 16000, 16005 and 16010 are used to process a click of the decrease “<” button.
16000 checks if the value is already at the minum then jump the return
16005 decreases the value of VG and redisplays
16010 returns

Lines 17000-17010 per a similar approach for the increase button excpet increase the value of VG by one. As I write this I am thinking there may be occasion to want to change the min and max values based on some other actions in the program, I’ll be adding that to my future enhancements list.



The next post will cover the combination of the a number box and button with associated code to allower the player to select the numbers to play.



Retro GUI IDE and WeeGUI – Objects #1


In the last post a menu was added to the Keno simulation program and the BASIC coded to end the program was added into the callback function for the exit button.  Next the screen for the program will be built using labels, rectangles, buttons, progress bar, check box and number boxes.  These screen objects (or view in Wee GUI vernacular). There are two kinds of objects, those that are just displayed and others that have some action associated. In this post the static or display objects will be discussed and the action oriented ones in the next post.

Labels are objects that can be used to place text on the screen in the application. They are added to the project by using the Objects Definition group of controls in the bottom left corner of the Retro GUI IDE window. The different objects required different data based on which is selected, and this changes the rest of the controls in this group. To define a Label object the X,Y position relative to the window and the text to display is required.

To add the KENO title to the left side of the game screen above the numbers that will comprise the board the X value is set to 13, Y to 3 and the text KENO is typed into the Caption text box.  Once the  Add button is clicked the label is stored in the objects list box, as seen below the first entry of “LABEL : KENO”.



When the project is run and the code pasted into the emulator (see earlier post) we see that the label has been added to the screen.


Reviewing from the previous post a block of BASIC code is set up at 60300 and this is where the code for the static ojbects is added.  This will allow the programmer to call to this block if in his/her program they need to redraw the static objects.  Line 60302 has been inserted  to this block as a result of the additon of the KENO label.  It should be noted that a “Label” is Retro GUI IDE object type, which is created by two WeeGUI commands &CURSR and &PRINT.  The &CURSR(14,3) places the local cursor to the position of column 14 and row 13 relative to our main window view. The local cursor is relative to the upper left corner of the view which is 0,0 and where the Clear #’s button is located.


To build out the rest of the KENO play screen, which is 8 lines of ten numbers (1-80) these are entered as eight labels starting on row 5.  The pictures below show what this looks like in the IDE, the BASIC code that is automatically generated and the the screen when the program is run.


Next a rectangle (box) will be added to frame the main play screen.  When the rectangle object is selected there is some additional needed, width and height.  To frame the labels already added it will be placed at 2,4 with a wdith of 34 characters and height of 10.  Here is a short video to show how this works. The rectange is a WeeGUI object and the single command &DRAW(2,4,34,10) in line 60311 creates the box on the screen.

As the program builds it wil be easy to redraw the static parts of the screen with gosub 60300.

The next post will begin to cover the action focuses objects.



Retro GUI IDE & WeeGUI – Menu

Next the menu is added to the program. WeeGUI doesn’t have a menu view or control, so it is built into the code building engine of Retro GUI IDE. The menu bar consists of a set of buttons placed in series across the top of the screen. More could fit in theory, but remember WeeGUI only allows for 16 views.

To add the menu check box must be clicked, which will make visible the menu setup group. There are three buttons to add, rename and remove menu items. The picture below shows what the IDE would look like after Clear #’s item was added and Play is currently being added.


Adding the rest of the menu options, Demo, Help and Quit looks results in the IDE state below


Then pressing play to load and run the program (with a SHIFT-INSERT to paste into the emulator) provides this output, which one can scroll through the buttons with <TAB> and <Escape>. Selecting a buttton will toggle the button graphic to inverse, but of course will not do anything yet.


Now let’s look at the code that Retro GUI IDE created to make this menu. The first picture below shows a block of code called out in the orange box.  The lines 60020 to 60024 create the buttons.  Each button call has six parameters that are passed, the view id, followed byt the x, y coordinates with the current view, the width of the button, the callback subroutine line number and finally the text inside the button.  The callback subroutine line number is the line line number that is called when the button is pressed.  The callback line number is alway the same in every program based on the view ID.  The line number is 10000 + 1000*ID.  So button with the ID 5, the “exit” button has a callback line number of 15000.


There five sets of REM and RETURN statements, one each at 11000, 12000, 13000, 14000, and 15000 each one is for the buttons to set up blank callback subroutines.  We will see how to use the Scratch Pad to write code to go inside these callback templates.  (Note below that some code has been added for the Exit button, let’s look and see how that is done)


In the Callback Scratch Pad one types in their own code.  In this case for the Quit button lines 15010-15040 are added.  The &EXIT command shuts down WeeGUI and leaves puts the computer in a stable state and the HOME and END clear the screen and end the program.  When the Play button in the IDE is pressed the code in the scratch pad is appended to the code generated from the IDE.  When the project is saved the IDE information is saved in a file with a .RCI extension, and the code in the scratchpad is saved in a file with .SCP extension.  Both have the project name as the file name.  Both are loaded when the project is loaded into the Retro GUI IDE.


The next post will cover adding additional objects (or views in WeeGUI terminology) to the application.

Retro C IDE now does WeeGUI/BASIC too

Retro C IDE will soon be renamed to Retro GUI IDE with the addition of Quinn Dunki’s  WeeGUI  library & BASIC code builder integration for Apple II.  Details coming soon, but here’s a couple of pictures to get things started:




OK so how do a a few mouse click and a few lines of Applesoft BASIC result in this KENO simulation?  Well that might be a bit of an exageration, however still much easier than coding it all from scratch.

When one starts up Retro C IDE (Retro GUI IDE name change comming) you are asked to select either an existing project create a new one.  Once selected the main IDE is displayed.  For a AppleSoft/WeeGUI project Apple II/e should be selected as the target system, and then WeeGUI in the Window defintion group should be checked.

The size of the main window (or view in WeeGUI terminology) is set with the four spinner controls X1, Y1, X2, Y2.  This is enough to create a program, not a very exciting one.

Upon clicking the play button (code, save, compile run) the codebuilder engine creates the BASIC code in the code window, the one in the lower right part of the IDE screen.  It is automatically copied to the clipboard and then the AppleWin emulator is started.  Then Shift -Insert will past the code into the emulator, and a RUN is appended to the bottom of the code so the program starts, yes automatically.

One point of interest is the code in the conde textbox is not in numerical order, but that doesn’t matter, think about typing a BASIC program, you don’t type in all the lines in order do you?  See the images below, the first from the IDE the second listed at the ProDOS prompt.



So all this from a couple of settings in the IDE, but what does it do?  First it should be noted that the target disk in the drive is a ProDOS disk with the WeeGUI program already installed, with BASIC.SYSTEM as well.

Line 10 starts up the WeeGUI program which sits in the background, (to see Quinn’s documentation see the link at the top of this post).  Line 15 calls two subroutines,  one that sets up all the views (think controls like windows, buttons, progress bar etc) at 60000 and one that draws static objects like labels and rectangales (boxes). The reason for this approach lies within the beauty of WeeGUI’s “lightweightness” and that there is no capturing of screen memory for redrawing.  So if part of a screen gets covered being able to access these subroutines later on will be valuable.  We will see this later when the help system is added.

At this point the only view set up at 60000 is the main window in line 60005.   The &WINDW() has several parameters the first is the view ID, one can have upto 16 views, this one is 0.  The second one is the style of the window in this case “1” is a simple box. The next two are the top left corner of the box (1,1) and the final four are the width and height of the box and text area (which can also be larger or smaller than the window).

The &sel(0) at 60101 and 6301 will be important once more views, static objects are added, but this command tells WeeGUI which view (in this case window) to apply other commands.  It’s important to note these line numbers as they will be the same (60000, 60300) for all programs built with Retro GUI IDE.

Lines 100-199 form the control loop that allows for user input to WeeGUI to execute actions.  Line 160 checks for the escape key and if found transfer focuse to the previous view (control) in the list, and line 170 detects a tab and advances focus to the next view.  Line 180 checks for the enter key and then lets WeeGUI take the appropriate action based on the view.  For example if the view is a button then the code tied to the button (a callback subroutine) is called.

I like to set the emulated procressor speed to maximum when pastng in the code, to speed things up, and then slow it down while the program is running.  When this program is run not alot exciting is seen for the user.  The main window is displayed and the program is looping for key presses.  It should be noted the WeeGUI has it’s own &GET(A%) routine which is non-blocking, meaning that processing is occuring while checking for keys, this allows the GUI’ness.  Since no other views or key checks have been added CTRL-C is our only way out at this point.


To save the work so far selecting file / Save or clicking the save (blue disk) button will create a *.rci file which holds the project data and can be loaded next time the Retro GUI IDE is run.

In the next post the menu system will be added.


Post 13 – Retro C IDE – Retrochallenge Recap

As the January 2016 Retrochallenge comes to an end it’s time to take a look at the progress made towards my initial goals.  To recap here they are:

The IDE & Code Builder will have single click ability for each of the following:
(1)  generate C code for the client application from the VB program
(2)  to compile C source to platform specific executable
at least Commodore 64 and Atari 800, with stretch goals for
C0mmodore Plus/4 and Commodore 128
(3)  Run compiled program in Vice (Commodores) and Altirra (Atari)

While I would love to be able to complete a full program point in click there is the ability to call user written functions from Buttons and Menus so the IDE will allow for writing of C code as well.

To point (1) the IDE and embedded code builder generates C code for the client application for the base window, the menu system and several objects (labels, textbox, number box, buttons).  Additionally user written header file and support files can be included via point and click as well.  So point one is a check, with two opportunities for the addition of list boxes and check boxes from the TUI C Library.


For point (2) the application supports Commodore 64, Commodore 128, Commodore Plus/4, Apple IIe, Atari 400/800 and of all systems the Oric Atmos which was added on a whim with specific updates to the TUI C Library for Oric. (see TUI C Library web site).  So the point is a “check plus” the additions beyond the initial target of C64 and Atari 400/800.



Point 3 is also well supported and exceeded with the integration of three 4 Vice emulators,(C64, c128 40 & 80 column modes, Plus/4), Altirra (Atari 400/800), Applewin for Apple IIe and Oricutron for Oric Atmos.  The Vice and Altirra work exactly as I would like by being able to generate source code, save source code, compile, and run in emulator with a single mouse click.  Applewin and Oricutron do operate a little differently.

Applewin wants the program as a binary file in a disk image.  After some research I landed on using the CiderPress program to take the compiled program and insert it onto a disk image.  This does require a few extra points and clicks but works great in the emulator and I’ll discuss the side project that allowed me to also try on a Vintage AppleIIgs in AppleIIe mode.

The documentation from the CC65 compiler web site provides the guidance to compile the Atmos code to a tape file, which with the proper compiler switches and parameters will automatically load the tape file in the emulator, leaving the user to simply type RUN at the BASIC prompt to run the program.  The Oric definitely provided some challenges with the TUI C Library because of the way it handles screen memory and colors, but that could be a paper all on its own.

In order to make the single button push and all the point and click I needed some amount of setup parameters, which I didn’t really anticipate initially, but turned out to be a good bit of the secret sauce to make this work.  The photo below and previous posts give a good deal of detail for those interested.  Settings for the compiler, emulators and support programs did the trick.


As for opportunities for enhancement I would like to add access to FileZilla to be able to move compiles programs, disk and tape images for use with a Raspberry Pi.  Also to set up separate directories on my laptop to handle source code and project save files in a different directory for each system/emulator type.

To the final point, there are two ways to add user code, one is directly type in for each menu item (that can also be called from buttons) and the inclusion of an additional header file and C source or compiled object files.  Also I test a work around to adding additional header files by including them at the top of the first menu user written call back function, but for me there is an opportunity to add the ability to add more header and .C and .O files. That said this is a mission accomplished as well.


The help menu and links is an additional feature that I really like, it gives easy access to the websites for each of the emulators, the CC65 site and to my TUI C Library reference on google sites.

In my first Retrochallenge last July I had a guiding principle of not having any other project distractions from a vintage computing perspective, this round I did not adhere to that approach.  Specifically, I lucked into three Apple IIgs systems for $130 and couldn’t pass them up.  So in parallel to building the Retro C IDE I cleaned and tested the three new Apple IIgs systems, three disk drives and added a FloppyEmu to I could and did test the programs I built with the IDE.

So in conclusion I have had another grand time with the Retrochallenge and feel that I have created a useful IDE and have learned much about Visual BASIC, the CC65 compiler, numerous emulators, and retro-computers and even built a game program for 4 systems in a day.  I am looking forward to the next challenge, which may be in April or October with pending changes to the schedule.


Post 12 – Retro C IDE – Keno for All

Rome wasn’t built in a day, but this Keno game for Commodore 64, Apple IIe and Atari was.  With the Retrochallenge winding down and Retro C well advanced I wanted to challenge myself to see if I could build a game in a day, for three retro computer systems.  I did the work over two sessions, I had a layover in the Detroit Airport Thursday night and I was able to build the main play field of the 80 numbers, all as labels in the IDE.  It only took about 20 minutes.  Today I finished the rest, adding number boxes for how many numbers and games to play.  I added call back function to two menu options to access these objects.  Then a simple loop and using the input_box function from the TUI C Library I was able to pick the numbers to play.  It would be nice if I had parameters of where the input box displays as it overlaps the play field, that’ll need to go on the enhancement list.  Finally three addition labels for Number of hits each game, number of coins, (loose one every game, gain coins based on number of hits), and number of games remaining if multiple games are selected.  Finally game play code is a call back function for the Play menu item.  The beauty and the reason for the speedy development is that 75% of the code was built from the IDE and Code Builder, the program logic was all that was left.  Here a few pictures showing the Retro C IDE set up and some code, and three screen shots of Keno for Commodore 64, Apple IIE and Atari at startup.

The next post will be my wrap up post for the Retrochallenge Winter Warm up 2016.



Picture above shows number selection.


Running on my Commodore 128 and AppleIIGS!