Recently I've made & uploaded a video (first since that for version 1.25) and benchmarked TRIANGULAR μOS 1.35.
Additionally I want to wrap up previous developments and write about the current state and future development of TRIANGULAR μOS.
I. Past and present.
As I've written in my lengthy post nearly a half year ago, TRIANGULAR μOS is changing from a relatively simple BASIC V2 operating system dating to Commodore PET 4 KB version 1.00 (its beginnings are in 2016 and was published in 2021) into a more powerful and flexible one.
Version 1.35 implemented BASIC 7.0 code in nearly all planned areas (graphic, sound, joy, structured programming) besides disk operations. It also includes 4 games (3 of them new and original). This alone meets goals set for this version in section 1 of plan from nearly a half year ago. Yet implementation of movable windows, some additional graphic custom assets (start menu orb, changing mouse pointer sprites etc.) and buildup of BASICALLY API went beyond that goals (and marked the start of 2 and 4 sections).
Let me present quickly the results of benchmarks of version 1.35:
Going from bottom-right corner to top diagonally (left-up) takes 4.17s.
It is 0.05s slower than the previous benchmark (version 1.31), probably due to GUI program size, but still nearly 1 seconds faster than in C64.
Loading start from scratch (type in, loading and run BIOS, loading GUI, run GUI) takes: 40s
which is whole 15 seconds faster than 55 seconds of 1.30 Beta (post C64 BASIC V2 slightly adapted to run of C128 BETA with 4 non working games) and is roughly 3 times faster than C64 version 1.25. And we are comparing less than 30KB programs with over 40KB one!
Reading system disk directory (3 files) takes: 27.2s
versus 32.4 seconds in version 1.30 BETA for C128 (~20% faster) and 21.2 seconds on version 1.25 for C64 (~28% slower).
MONITOR program, thanks to HEX$ function, displays a whole 256 bytes region of memory in just 20s
compared to 2 minutes 18s in version 1.33 (7 times slower) and 1 minute and 28s on C64 (4.5 half times slower) is an impressive speedup.
I'm actually surprised that μOS 1.35 is that fast, especially boot up time (which is 2-3 times faster than my Win11 8-core SSD - soon to replace - PC
). Seems like lots of optimizations made in the 1.3x series thus far simply paid off. And its niece achievement for over 40KB program (GUI + nearly 5KB of additional BIOS program and 5 KB of variables). But keep in mind that all those tests were performed after a fresh start and with system use (and system variables growth) it's getting slightly slower.
II. Current state and future.
A. Code consolidation.
One observable trend from the beginning of development of TRIANGULAR μOS is the growing codebase and its consolidation in one GUI program file. While early versions for Commodore PET 4KB and VIC-20 5KB had 22 and 20 program files on their SYSTEM DISKs (due to their small amount of RAM available), true consolidation started after release of version 1.10 for VIC-20 5KB where versions from 1.11 to 1.15 supported larger and larger amount of RAM through RAM expansions and thus code base was merged into bigger chunks of code, preferably into GUI file (going down to 7 files on SYSTEM DISK in 1.15). Whereas versions for Commodore 64 (1.20 and 1.25) introduced 3 files SYSTEM DISK scheme, where there is launching everything BIOS, small config file UOS.CFG and finally main GUI file, which has the whole system in one program. For VIC-20 and C64 consolidation also meant much longer loading times (when used without turbo loader) from over 1 to 2 minutes, which was corrected on C128 with a vastly faster 1581 floppy disk and various optimizations, where last version 1.35 with over 40 KB GUI program boots in just 40 seconds. The GUI program has every element of the system inside, even sprite data in DATA statements.
But consolidating everything (up to sprite data) under 'one roof' has few shortcomings.
Firstly, it makes everything slower, since big codebase (over 800 tightly packed lines of BASIC code in GUI file) along with huge variables area (over 5 KB) slows system down, which is especially visible in games that can work 3 times faster as separate, few kilobytes programs vs being part of one over 40 KB main program.
Secondly, coding in such a more complex environment necessitates longer development time and leads to many unexpected bugs due to interconnections and interdependencies with many elements of μOS. Also it requires compiling the whole GUI, adding it to SYSTEM DISK and running C128 [VICE emulator] to see results, which takes more time.
Thirdly, programs must operate with only global variables and since variable names are effectively just 2 characters long, it makes less room for new names. Not to mention adapting outside programs requires rewriting all variables so there are no collisions with those that are already present in uOS.
And lastly when developing tightly cramped code (especially multiple if...then...goto or/and else in one line - densely used in one liner added to μOS) on CBM prg Studio only 1st goto commands gets updated when renumbering lines, while the rest remain the same. That generates frustrating and hard to locate errors especially in that big code base.
I think it will be optimal to deconsolidate the future versions of TRIANGULAR μOS by detaching some programs (notably games) from the main codebase, since it will speed them up considerably (up to 3 times). Version 1.15 for VIC-20 is a good example of great balance between consolidation and healthy detachment of some apps (games). Not to mention that section 3 of my plan also provides for separating graphic data from main codebase into .bin files (loaded by BLOAD command) which will be very advantageous when used with sprite data (which will not only be outside of main code, but also binary files will be ~3 times smaller and thus speed of loading them into system will be faster than with slow for:to:read[data]:next loops).
B. GUI innerworkings transferred into modules.
Contrary to then-present code consolidation, the start of the segmenting code into editable and flexible modules commenced with introduction of BASICALLY API or rather its first glimpses in version 1.25 for C64. That later accelerated beyond planned scope by further expansion of BASICALLY API by introducing floating windows and JUMP TABLE.It will be further advanced by introducing other BASICALLY elements that allow creating more powerful apps more easily with speed gains.
III. New goals (with review of old ones).
Therefore, let me quickly review the old plan and in doing so, devise a new one.
1. EXTENDED BASIC COMMANDS
STATUS: DONE (in some limited scope ongoing)
As mentioned above, the phase of converting TRIANGULAR μOS code to BASIC 7.0 standard had already reached its goal in version 1.35. Parts of it like: 'A: Graphics commands', 'B: Sound and Joystick commands' and 'C: Structured programming' are finished completely, while in part: 'D: Other new commands' in areas such as loading and saving files and other operations' disk commands are discharged from usability standpoint, while numerous 'other' new commands were implemented. What will be added in the future is error handling and addition of other smaller commands.
Those additional changes will be implemented in future versions of TRIANGULAR μOS 1.40 and upward.
2. SYSTEM ASSETS
STATUS: ALREADY STARTED
System graphics (in form of more sprite mouse pointers, sprite start menu orb etc.) are already implemented. This will be further developed to more customizable graphic and sound assets etc. And system assets will be handled mostly by task 3 (read below), which will begin with development of the TRIANGULAR μOS 1.40.
3. SYSTEM ASSETS LOADING SYSTEM
STATUS: TODO (soon)
Since growth of system codebase leads to its bigger size, slower operation and harder development large chunks of data, especially graphics and sprites data, will be held in binary files on SYSTEM DISK. BLOAD command will serve as a great venue to load system resources from disk in a very simple and fast manner. This means separating assets from code (mostly graphic), which will reduce size and loading time and speed of operation of the system core. This will also allow having interchangeable custom assets to be available for μOS without enlarging its codebase.
This task will begin with development of the TRIANGULAR μOS 1.40.
4. BASICALLY API
STATUS: ALREADY STARTED
In TRIANGULAR μOS versions 1.25 to 1.35 BASICALLY API was gradually growing (from simple window generator to addition of JUMP TABLE). TEMPLATE program (see its source code), which is attached to SDK for μOS version 1.35 is a great presentation of a generic program that can operate under μOS using just JUMP TABLE calls of BASICALLY API. Further buildup of BASICALLY API with more GUI elements (buttons, icons etc.) will open up μOS for easier ways to write both simple and advanced BASIC programs, that don’t need to contain large chunks of redundant code in order to service μOS operations. In the (more distant) future that will be extended to service machine language programs. Not to mention that the introduction of the JUMP TABLE in BASICALLY API was meant to secure support for older apps in the newer μOSes (newer apps won't work on older μOSes, unless in newer TEMPLATE form with whole system core attached to service them).
This task has already started and will be further developed in future versions of TRIANGULAR μOS 1.40 and upward.
5. MACHINE LANGUAGE
STATUS: TODO (in distant future)
In that regard not much changed here, besides task being pushed further into future (probably after release TRIANGULAR μOS for Mega65).BASIC 7.0/10.0/11.0 codebase will be finally converted at some level to ML (Machine language). TRIANGULAR μOS should function as amalgamation of BASIC and ML code. μOS probably won’t reach 100% ML, since BASIC is very good already at some types of system operations. ML programs should be serviced by μOS BASICALLY API.
This task will start in the more distant future (TRIANGULAR μOS 2.00 and upward), where most necessary chunks of code (mostly slow graphic routines) will have top priority.
6. NEW FEATURES
STATUS: ALREADY STARTED
New features such as 3 new and original games: TREASURE CHAMBER (in place of planned LIFE RAFT), CRAB IN NEW YORK, STAR WARS: X-Wing vs TIE Fighter) have been already added to TRIANGULAR μOS. In future more games and other programs and features will be added to TRIANGULAR μOS.
This task has already started and will be further developed in future versions of TRIANGULAR μOS 1.40 and upward.
7. MULTIPLATFORM / TRIANGULAR μOS REVISITED
STATUS: DEPRECIATED / TODO (in some limited scope - soon)
I was originally thinking about trying to make TRIANGULAR μOS run on C128, C65 and MEGA65 from one SYSTEM DISK.
Nonetheless that goal will be scrapped, since C65/Mega65 versions will support 80 columns graphics mode in GUI (maybe some games will retain 40 columns mode). This alone disqualifies C128 from being serviced by C65/Mega65 versions, because its 80 column mode didn't support sprites. Not to mention more colors and other expanded functions of those computers. At this point I'm not even sure if the Mega65 version will be compatible with C65. However, if possible, I will try to make apps written with BASICALLY API calls for series 1.35 and higher to work (to some degree) with newer C65/Mega65 μOSes (same situation with Mega65 with C65 apps).
It's worth adding that in terms of multi-platforming, μOS will be more in tune with computing world standards. Already it implemented a standard file naming convention (uos.cfg vs [older] uos>cfg etc.) which allows system files to be stored in file folders on SD card [with SD2IEC].
In the near future, I will change WORDS text file extensions from .doc to .txt which will allow easier transfer of text files between TRIANGULAR μOS WORDS and other computers word processing programs like Notepad in Windows on PC etc. Moreover, I will revisit all series of TRIANGULAR μOS for: PET, VIC-20. C64, C128 and add Plus4 to adapt them to this scheme: all will have standard filename format (filename.exte[nsion]) and words file will be stored in .TXT file. Plus I will unify the naming scheme and add some essential bug fixes to match those newer versions and allow documents wrote on TRIANGULAR μOS for all series of Commodore computers to be universally accessed by not only μOSes themselves, but also by other type of computers (modern or old) as .TXT files. The .DOC files will be reintroduced as a more powerful option when text formatting will be supported in the distant future.
The main goal of this task to be scrapped, while a new smaller one will be implemented as the first task to do (before development of TRIANGULAR μOS 1.40).
8. MULTITASKING (OF BASIC PROGRAMS)
STATUS: TODO (in distant future)
One of my ultimate goals is to introduce limited and simple multitasking to μOS programs written in BASIC. I have some preliminary concepts of how it could work, but if it will be achievable time will tell.
This task will be developed in future versions of TRIANGULAR μOS.
9. SDK TOOLS
STATUS: TODO
In order to speed up creation of SYSTEM ASSETS to load into μOS I will add some tools to make and pack graphics and other types of system assets.
This task will begin with development of the TRIANGULAR μOS 1.40.
IV. Nearest future
Now let's delve into the more planned, practical side of future TRIANGULAR μOS development.
1. TRIANGULAR μOS REVISITED
First, I will be releasing revised versions of TRIANGULAR μOS (task 7). I will moderately upgrade all series of μOS (PET, VIC-20, C64, C128 and add a version for Plus4) with those objectives in mind:
- file naming convention change from older uos>cfg to standard one: uos.cfg. Also WORDS text files will be saved in .TXT file format instead of .DOC
- new version naming convention (e.g. TRIANGULAR μOS 1.08 instead of 1.05/PET etc.)
- rearranged desktop icons position, in tune with μOS 1.35
- some necessary bug fixes (but not big code modernization)
Additionally, besides above changes PET version code will be migrated to CBM prg Studio. Thus far I've developed it in VICE PET emulator and now it will have a more comprehensive SDK with source code in .BAS files like other versions. The C64 version will add a sprite menu start orb and loading logo stripes like in version 1.35. And a Plus4 version will be developed (based on version 1.25 with character mouse pointer from 1.20 and will utilize some BASIC 3.5 commands). Last will be TRIANGULAR μOS 1.36 for C128 with .TXT WORDS file extensions and some bug fixes. I won't spend time on new capabilities here, but mostly on bug fixing. This version will be more a fast and simple patch or service pack than the new version. Nonetheless, all elements of full release will be present (updated manuals, SDK with source code, updated JUMP TABLE calls).
For more features promised for the C128 version, please wait for TRIANGULAR μOS 1.40, which development will start immediately after release of 1.36.
Also I will create a website for TRIANGULAR μOS and add one after one other revisited version along with a video (I will try to add voice commentary this time). All release files will be kept on that website (those already uploaded through Mediafire will stay there safely too).
2. TRIANGULAR μOS 1.40 and later
True change will come with a new series: 1.4x, which still will be released on Commodore 128 (it will simply replace old planned series 1.36 and upward).
A. First in this series will be TRIANGULAR μOS 1.40, which will introduce a trend of detaching nonessential elements of TRIANGULAR μOS from GUI program. Where the general trend of ever-growing GUI file codebase reached its apex (for while at least) in version 1.35, in version 1.40 not only games and some programs will be spawned into separate programs, but also custom system assets (like graphics, sprites data) will be loaded from binary files. This should not only slim down size and improve speed of GUI, but also considerably speed up games and other programs like painstakingly slow WORDS word processor. Moreover development of TRIANGULAR μOS will be easier and faster.
Another important change will be implementation of mouse options with a separate MOUSE tab in the SETTINGS window. You will be able to change mouse pointer color, mouse speed (actual code is already present in mouse routine, but it is not yet implemented on GUI side). Standard shape of the mouse pointer also will be altered. There will be an option to change Mouse/Joystick port 1 or 2.
In the look and feel department a new color theme will be presented.
BASICALLY API will have considerable buildup. New API calls will be added which will allow:
- Creating icons (5x5 + label with name)
- Creating buttons
- Creating text labels
Besides that I will add sound in game mode of STAR WARS: X-Wing vs TIE Fighter and further develop WORDS, CMD and MONITOR apps. Not to mention standard improvements and bug fixes.
Documentation of SDK will be even more augmented, especially in regard to variables tables and BASICALLY API will be described more comprehensively with more explanatory review of TEMPLATE code. TEMPLATE app itself will be developed more.
B. After that TRIANGULAR μOS 1.41 will be released with custom fonts, possibly supporting multiple windows on screen. Probably TREASURE CHAMBER will be replaced by racing game that I'm planning to create.
Version 1.42 will go even further.
Version 1.50 will be fist of series 1.5x for Commodore C65 / BASIC 10.0.
Version 1.60 will be fist of series 1.6x for MEGA65 / BASIC 11.0 aka BASIC65.
TRIANGULAR μOS 2.00 and upward will have some considerable part of code migrated to ML.
3. Roadmap of TRIANGULAR μOS:
1. TRIANGULAR μOS REVISITED (for all series through μOS 1.36)
2. Series 1.4x (1.40 upward) will be a version for Commodore 128 with custom assets loaded from disk and cut into modules and further developments.
3. Series 1.5x (1.50 upward) will be a version for Commodore 65 / BASIC 10.0
4. Series 1.6x (1.60 upward) will be a version for MEGA65 / BASIC 11.0 aka BASIC65
5. Version 2.00 and upward with considerable part of code migrated to ML (Machine Language).
However, Ryan Sherwood of the Puget Sound Commodore User Group brought his C128DCR, and I hope to use his. But I don't think Ryan would want to show TRIANGULAR all through the show, so I will have to show the OS for just a little while.
