BETA VERSION 1 RELEASE NOTES:

Note that everything in the notes for Alpha's 1 to 3 still applies. When the actual releases start (possibly in upcoming wider betas as well), these will be merged into one document again. I was going to do this for beta 1, but I have been too busy with work to do it, so it will have to wait until Beta 2.

Also... Due to overtime with work, this Beta is being rushed out without being as thoroughly tested as I would normally like, and also doesn't have everything in it that was originally planned. Work is finally dying down for me (Curtis) now, and I hope to have a Beta 2 with some NitrOS-9 bug fixes, etc. by sometime in October. Please report any problems, bugs found, questions, etc. in the Discord NitrOS9eou group, or via email to me @ curtisboyle@sasktel.net.

QUICK NOTE ON STARTUP FILE:
The current startup file loads all system fonts, and a couple of batches of small, commonly used utilities (which makes the system seem faster once it is booted). However, if you would rather start with the bare minimum (just the one 40 column window, no utilities/fonts, etc. pre-loaded) you can simply hold down a SHIFT key while it is booting, and it will bring you to the shell much more quickly.

QUICK NOTE ABOUT VCC:
Since RUNB and BASIC09 are starting to get fully 6309 optimized, and VCC has incomplete support for the 6309, you may start hitting glitches (the hardware divided instructions in particular). This does not affect the 6809 versions. The 6309 versions will run fine on real hardware, or on MAME. 
On the 6309 image, I have made pre-merged special RUNB (/dd/cmds/runb_alpha3) that contains the older version from Alpha 3 that shouldn't use those instructions, but it does include the new GFX2 (See below), for those of you using VCC. If you are going to go that route, do a LOAD /dd/cmds/runb_alpha3 after booting, to make sure that you have the older, more VCC compatible version loaded, and you hopefully won't hit any issues.

QUICK NOTE ON FUTURE UPDATES:
Since we are going to public Betas as of this release (to get more people involved in testing, etc.), one thing we need to worry about is people making changes/additions/customizations to the images themselves. Since we are sending out hard drive images "pre-built", this would wipe out any said changes you may have done. So, this is a warning to back these up before getting the new image(s), and copy them back over afterwards. It might be easier if you create your own directory and keep all of your new stuff in it (easier to back it up). You can then either back these up to a new floppy or floppy image, or copy them to a Windows/Mac/Linux box using the varying utilities that are around for that purpose (like Toolshed, etc.). On a real Coco or MAME, you could even have a 2nd hard drive image for all of your local stuff (VCC, at this time, only supports 1 hard drive image mounted at a time).
If you go the floppy/floppy image route, and you have made your own directory of your additions, you should be able to do a CD <your directory name>, and then do MSCOPY -alm * <your backup floppy name, like /d1) #56k. This will copy all files and sub-directories (like DSAVE, but *much* faster) as long as you have enough disk space.
If you find your stuff is too big, you can try compressing them first with one of two archive compression programs (please note that both add their own extension automatically - .ar or .lzh):
AR (AR -u <archive filename> <filenames to compress>). This is faster than the other method but doesn't compress quite as well. It also only does subdirectories if you manually specify them, and can only handle a certain number of files at a time (you can do it several chunks; the -u means "update archive", which means you can create an archive with some files, and then run AR -u again with different files and it will combine them into the same archive. Extracting preserves attributes, and will create directories as needed automatically, and doesn't have a limit to the number of files you are extracting, unlike when it is compressing.
The other option is LHA. It compresses better (but slower), and has a ton more options, but is slower (and can be more complicated to use). I don't believe it has a (reasonable) limit to the number of files to compress. Recommended usage for our situation here is:
LHA a -xpr <archive filename> *
Again, run from your new directory, and this will automatically do all sub-directories as well. The options used are: 'a' (add to archive - will create a new one if your archive filename doesn't exist, or add any new files to an existing one). The '-xpr' is actually 3 options: x means allow extended filenames, p means to keep full paths, and r means recurse through sub-directories.
To restore, CD to the directory you want to restore into, and then LHA x -l <archive filename>. This will extract the entire archive, with paths, and show the paths on screen while it is extracting.

CHANGES FROM ALPHA 3:

1) First optimized versions of RUNB 6809/6309, in some integer math functions. Also crunched the size down by removing the BASIC09 splash screen (which you can never see from RUNB anyways), and some other bits "leftover" from BASIC09. Also first attempt at 'speeding up' (an overzealous description) for string copying literals to variables by 1 cycle/byte in both BASIC09 and RUNB.

2) Planet Engine installed in APPS folder.

3) Some revisions (first of many planned!) to GSHELL:
  i)  Added new DUMP command to FILES menu. This will allow NitrOS-9 beginners to dump files, directories, etc. at our request to help debug things in the field, without having to go through explaining how to do it from the command line. 
  ii) Changed both the existing STAT and the new DUMP commands to use the 8x8 font (instead of the 6x8 font that everything used before). Both of these commands fit (with room to spare) using the wider font, which prints much faster, so both of these commands will display faster. LIST and others can fill the full width, so I have left those at 6x8.
  iii) GSHELL initialization on 6809 should be faster (may not be noticeable...lol)
  iv) When forking new SHELLS to new screens from GSHELL, command line editing is now fully enabled by default.
  v) GSHELL now auto-recognizes the amount of RAM in your system (up to 2 MB), so you can remove the RAM=### from the SYS/env.file completely. You can also leave it in for testing (it will override the real RAM with whatever you specify).
  vi) GSHELL now takes 3 less GET/PUT buffers for icons than before, saving a little memory (about 1/3 of a K)
  vii) GSHELL can now launch a packed BASIC09 program directly (without an AIF file set up) in an overlay window. Please note that some BASIC09 programs weren't programmed to know about running in a non-full window, so some will not display correctly, but a fair number will run now (the below mentioned GPMAP is one of them). I think some BASIC09 programs that need large data areas may still not launch properly, however (I have added some patches for that, which seems to be alleviating the problem, but not sure if it solves all of them yet).
  viii) STDWND vertical scroll bar graphic fixed - was set too wide, and would leave a "trail" of white pixels in the vertical scroll bar area when updating.
  ix) If a program launched from an AIF requires a full width screen, and the Y size required is either 24 or 25, it will create the window as a full screen of 24 or 25 lines (previously, if the program required 24 lines high, it would allow a resizable window - which is silly since you could only move it up and down 1 line on a 25 line screen).

4) PAC-OS9 documentation installed in DOCS directory, and RMA source code for it in /dd/sourcecode/asm/pacos9. Many thanks to Bill Nobel for making the MAKEFILE for it - you can remake it from the source by simply type MAKE in that directory.

5) GPMAP previously had SYSCALL merged with it, which could cause issues (and it's already merged with RUNB). Fixed.

6) Bombs Away! game (artillery style) added in GAMES folder.

7) ChessMV (I had to patch it for MultiVue, so I renamed it) added in the GAMES folder.

8) Tetris added in the GAMES folder.

9) Shellplus 2.1 docs added to DOCS folder (explains all of the enhancements in Shellplus. The docs for 2.2a explain the additions for command line history, and a couple of additional bug fixes).

10) Moved Battleship (1998 version with digitized sound effects) BASIC-09 source code to /dd/sourcecode/basic09 (had it in the wrong directory), as well as the 1998 update documentation to /dd/docs.

11) New GFX2 edition #4. The current "official" NitrOS-9 distribution is using the stock Tandy one, not even the upgraded one released by Kevin Darling and Kent Meyers in 1990, which added support for Multi-Vue style windows, etc. This has been upgraded to match that, as well as adding support for two new commands. More full documentation is in the DOCS directory (see gfx2_edition4.TXT), but a brief list of new and updated commands follows:
Updated commands:
---------------------------
"DRAW" - supports optional startx,starty coordinates before you specify the draw string. Method in manual still works too. So, syntax with new options:
RUN GFX2([path],"Draw"[,startx,starty],Drawstring)

New GFX2 commands (see docs for full details and parameters):
--------------------------------------------------------------------------------------
"TITLE" : Set up main Multi-Vue window descriptor and name
"MENU": Set up menu bar menu basics
"ITEM" : Set up items in a menu
"WNSET" : Set up type of Multi-Vue window (double box, framed, framed with scroll bars, etc.)
"WINFO" : Return window information (type, size, etc.)
"GETSEL": Get menu # and menu item # selected by user
"UMBAR" : Update menubar (activate/deactivate menu items, etc.)
"SBAR" : Update horizontal & vertical scrollbar positions
"SETMOUSE" : Set some mouse parameters, including auto-follow and sampling rate
"ONMOUSE" : Lets you put your program to sleep and let the system update the mouse until user selects a menu option that you have set up.
"ID": Get process ID # (useful as a group # for graphics buffers (Get/Put, etc.), so that you know it is unique to your program and won't stomp over someone elses running at the same time).
"TONE": Play a tone of specified pitch, length & volume.
"FCIRCLE" : Draw filled circle, same parameters as CIRCLE.
"FELLIPSE": Draw filled ellipse, same parameters as ELLIPSE.

This should help BASIC09/RUNB programmers do fancier applications/games, with less work.
There is a test program called 'testgfx2' that you can run from the command line, and the source code for it is called 'testfx2.bas' and can be found in /dd/sourcecode/asm/basic09, if you want to see sample code of how most of the new commands work.
The new GFX2 is pre-merged with RUNB, SYSCALL, INKEY and GFX, on both 6809 and 6309 versions.

12) MEEP command added. This was a fun little audio digitized sample, baked into a standalone program. 

13) /dd/SOUND directory made, with some 30 odd sound samples of various formats (Mac, Amiga, WAV, SUN, etc.) that you can play with the PLAY command. I got two types set up for GShell - '.mac' and 'wav'. I will be adding other icons later so you can run the other types (Amiga, Sun/AU, etc.) from GShell; just ran out of time. I should note: If you have an Orchestra-90 card (or compatible), you can get full 8 bit sound on most of these samples with PLAY -o <filename> (it should even do stereo, if any of these samples are stereo). Add a '-i' parameter to see the specifications of the sound file being played. For fun, add a '-s##' parameter (where ## is any number from 1 to 99) to change the speed of the playback; lower number are faster/higher pitch. Also note: The Mac samples were partially converted over to a 'native' Coco format back in the late 1980's/early 1990's to have the speed of playback embedded; because the 6809 and native mode 6309 operate at different speeds, they won't sound the same between the two, if they have the same speed option embedded. As it currently stands in Beta 1, the 6309 version runs the most at the "proper" speed; the 6809 versions play most back at a slower/lower pitch (.WAV is not affected; it has the actual sampling rate in the header, which PLAY adjusts for). You can override the speed with PLAY -s## (which can fix it), but at some point in the future I will change those sound samples on the 6809 version to play more at "proper" speed.

14) James Jones found a bug with BASIC09/6309 where the ABS function (with REAL numbers) was returning incorrect results within a certain range. Even better, he figured out what was wrong in the code, and that fix has been done here (and in RUNB, too - Alpha 3 didn't have the RUNB with the ABS REAL optimized for 6309; but our internal Beta 1 build did, so it is fixed there as well).

There are multiple other known bugs that we haven't gotten to yet, including some programs in the CMDS directory on the 6809 version have 6309 code in them, the mouse doesn't let you use the bottom 8 lines of a x200 screen, programs that try page flipping graphics "steal" the CLEAR key so that you can't go to another window until you abort, Grfdrv>8k in size causes unnecessary OS9boot file size restrictions because of how it is loaded, etc. All of these are actively being worked (some may actually be done already, but have not been tested, so they will wait until Beta 2).

L. Curtis Boyle, September 1, 2018

P.S. Work has begun on new manuals (BASIC09 first) that will incorporate the updates that have been done in NitrOS-9/EOU over the years compared to the original Tandy/Microware manuals, so eventually we hope to have a modern, up to date version to go along with the hard drive images for everyone to work from. But this is a BIG project, so it will be awhile (we will likely release it in chunks, based on the sections in the original OS-9 Level II manual). This will include updates to existing system calls (corrections and/or additional features), as well as newly added/previously undocumented ones.

P.P.S. Late add-on Sep. 1 - hid an "Easter egg" .WAV file in /dd/sound. If you have 2MB RAM upgrade, you will get to hear the full file (or almost all of it, depending on what all else you have running), but it will still as much of it as you have free memory for on a 512k or 1024k machine.