BETA VERSION 5 (April 30, 2020) NOTES:

Note that everything in the notes for Alpha's 1 to 3, and Beta's 1-4, still apply. These will eventually all be merged into one document. If you have installed previous betas, you can skip ahead to the "CHANGES FROM BETA 4, RELEASE 2:" section.

NOTE: IF YOU ARE A USER BRAND NEW TO NITROS-9/EOU, PLEASE READ THE "NitrOS9 Ease of Use - Beginners documentation.rtf", WHICH HAS THE BASIC INSTRUCTIONS FOR GETTING EOU (Ease of Use) RUNNING, AND SOME TIPS ON USING IT.

Please report any problems, bugs found, questions, etc. in the Discord NitrOS9EOU group, or via email to me @ curtisboyle@sasktel.net.

ALSO - PLEASE SCAN THROUGH THE BEGINNERS DOCUMENTATION FILE, AS IT CONTAINS SOME UPDATED INFORMATION PERTAINING TO BETA 5.

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 GSHELL:
For programs that do not require full screen windows: For apps ran from the main GUI window, their icons are set up to run on a specific window type (ex. 320x200x4, 320x200x16, 640x200x4), that you can then resize to the minimum that application will allow. For the ones running from the Tandy menu, they also have minimum sizes, but they will always be created with the window type you are running GShell in, AT THE TIME OF LAUNCHING THEM. This means that you can change types while running, and then launch such apps, so that you can run them beside other, regular GUI apps, of the same type. This can help you if you want to run, say, Rogue next to a shell on the same screen. Rogue defaults to 640x200x4; launch it, and make it's size small enough to leave enough room for another app. Then, if you set your GShell resolution (in the pull down VIEW menu) to the same resolution/color, any of resizable Tandy apps (shell, control panel, calculator, clock) that can fit it's minimum size on the screen, will let you place it beside it.

QUICK NOTE ABOUT VCC/OVCC:
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. UPDATE: OVCC (a cross platform version), and VCC 2.0.1e now have full 6309 support, and should work fine. But you must have VCC 2.0.1e or higher for that support. It should be noted, however, that neither version of VCC currently supports a 2nd hard drive.

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 older versions of 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 doing public Betas now, 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. 
NEW TO BETA 5: WE ARE INCLUDING A BLANK HARD DRIVE IMAGE, CALLED EOU_USER.VHD, THAT IS MEANT FOR YOU TO PUT YOUR OWN PROJECTS ON. THIS WILL WORK ON BOTH THE COCOSDC (IF MOUNTED AS DRIVE 1), OR IN MAME. CURRENTLY, VCC & OVCC DO NOT SUPPORT A 2ND HARD DRIVE MOUNTED.
If you still need to keep things on the main image:
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 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.

Quick note on Snakebyte game: I had some oddities where some get/put buffers (or fonts) appear corrupt, or it returns "buffer size too small" errors, when you run another program after running Snakebyte and quitting that game.  From what I am able to determine, it is because Snakebyte doesn't clean up it's own get/put buffers after itself, and if the next program doesn't kill it's own buffer group before sizing/reloading them, it may experience these errors. Most programs do perform get/put buffer cleanup on exit. For programmers, probably the safest way to deal with situations like this, is to have your program send a KilBuf for your get/put buffer group, for the whole group (usually, you are using your own process # for the group #, so that you know it is unique, so you would send a 1b 2a <process#> 0), and then size, load/get the buffers needed for your game. This way, you clean up after any misbehaving program that didn't do this yourself, and you can make sure your get/put buffers are the size you actually want.

In the meantime, if you quit the 2nd game (which will then usually clean that group up itself), and then relaunch it, it will be fine.

FIRST, A BIG THANK YOU TO THE FOLLOWING PEOPLE FOR CONTRIBUTING TO BETA 5 RELEASE, FROM BOTH BILL NOBEL AND L. CURTIS BOYLE:

Nick Marentes for new icons for various programs
Rob Inman for new icons for various programs, and giving me a pre-set up RSB to install.
Todd Wallace for his new IBM CGA font (with all CHR$(32-255) supported).

Also thanks to our testers: 
Aaron Doughty, Michael Furman, Rob Inman, Ron Klein, David Ladd, Grant Leighty, Nick Marentes, Nick Marotta, Mark Overholser, Terry Steege, and Todd Wallace.

CHANGES FROM BETA 4, RELEASE 2:

1) Shrunk/optimized a few bits in Grfdrv/6809, and fixed a couple of bugs:
 - a bug in the Matchbox version when clearing a graphics screen with a new window that didn't properly clear the whole screen behind the new window.
 - The scale factor calculation routine was erroneously using 16x16 unsigned multiplication (and requires signed for certain circumstances; drawing Arc's for instance). This bug has been around since at least 2006.
 - slight speed increase to copy screen parameters from caller to Grfdrv
 - DefColr in CoWin is faster & shrunk on 6809.
 - printing text characters CHR$(32-127) should be slightly faster

2) Grfdrv/6309 - shrunk by 2 bytes, fixed bug of what byte to clear the remainder of a graphics screen if one is creating a window that doesn't take the whole screen. Printing text characters CHR$(32-127) should be slightly faster.

3) CoWin/6809 - shrunk/slight speed increases to DefPal, Arc, Circle, Ellipse, FFill, FCircle,FEllipse, Get/Put/Point.

4) Shawn Driscoll's BASIC09 version of Shanghai (which also uses his GUIB library) is installed in /dd/GAMES/SHANGHAIB09. It includes the game and the editor for it. Documentation is in /dd/docs, and the sourcecode is in /dd/sourcecode/basic09/games/ShanghaiB09.

5) Shawn Driscoll's KNIGHTS game (also written in BASIC09) is also installed in /dd/games. Documentation is in in /dd/docs, and the sourcecode is in /dd/sourcecode/basic09/games/Knights

6) Ken Bergman's MASMIND (a version of the board game Mastermind), another game written in BASIC09, is in /dd/games. Sourcecode is in /dd/sourcecode/basic09/games/MASMIND, and has some minor modifications by me, which slightly shrinks/speeds up the game. Documentation is built into the game itself.

7) SuperIke Icon editor version 1.1 (specially modified for the EOU) is in APPS. You can use this to make your own icons for Gshell. NOTE: The normal icons can be found in '/dd/cmds/icons'. Changes from the original Superike:
-fixes mouse cursor scaling on the fat bits grid
-Uses GSHPAL palettes from the /dd/sys/env.file (the ones GShell uses), so that you are editing in the same colors as you will see in GShell.
- Uses the mouse port and mouse resolution settings from /dd/sys/env.file (same as GShell uses).
- Fatbits display is almost twice as fast as the previous version
- Loading Icons screen (the one with the icons drawn, not the text only ZipLoad) now uses the narrower font so that you can see up to 8 characters of the icon filename, vs. only 6 before.
- General optimizations, and some time delays now use Sleep calls so they don't hog the CPU like they originally did.
- The 3 ML subroutines, bizarrely, had self-modifying code, so they broke their own CRC's. Fixed.
- No longer bumps up it's priority to maximum of 255 (didn't make much difference, speedwise, anyways. Just slowed down all other programs).
- Changed SHIFT, CLEAR and CREATE to use add any new pixels based on your current color selection (originally, it always did color 0)
- Fixed a cosmetic bug in ZipLoad
- Fixed a bug in Undo that occasionally occurred under certain circumstances.
- Changes overlay window palettes so that the border shows up properly, and better contrast of colors for readability.

Please report any bugs. The original version is still there (/dd/cmds/superike_org) for comparison, although it has some bugs of it's own.

8) Sokoban (a text version). I know at one point there was a special graphical font for it, but I have lost it over the years. If anybody reading this has it, please send it to me, and I can include it on the next update. Source code (in C) is also in the SOURCECODE/C folder. Hit '?' for help. Please note that there are some command line options that you can use if you run it one your own. It will run on any type of 80 column window.

9) DISASM edition #6. This fixes a bug where it would disassemble PULU or PSHU with 'u' as the register to push/pull, rather than 's'.

10) Magic Stones, and board style game for 1-6 players, written by Floyd Resler, has had a bug fixed and is now in the GAMES folder. And the fixed sourcecode is included as well.

11) Boot_Win has been fixed so that it runs properly now.

12) IOMAN has the I$Attach call optimized a little for the 6809. Also allocating a path descriptor is a little faster.

13) KRN has been optimized for system calls that go between system and user states to be a little faster, for the 6809.

14) KERNEL_UTILITY has been added for advanced users to swap new REL, Boot and KRN modules into a boot track, that can be moved to a floppy track 34 using KUTIL.

15) Moved F$CpyMem system call in 6809 version to Krn from KrnP2. This allows optimization and a dramatic (several times)  speed up, and also saves some memory in your system RAM (and now matches the way that 6309/EOU does it). Most noticeable on utilities like PROC and MDIR, as well as some others. Also optimized F$Chain (about 750 cycles faster), F$AllPrc (370 cycles faster) on 6809. F$Debug smaller/faster on both 6809 and 6309.

16) Fixed the corrupted icon for the MultiVue "demo" app in DEMOS folder.

17) Keyboard mouse has been changed from global (you toggled it on/off for the entire system) to local (each window gets it's own setting, and any new windows you make inherit from the setting from the parent). This means that you can launch mouse based apps from GShell, and those apps will also use the keyboard mouse, but your normal hardware text windows that were already set up stay the way they were, so that line editing, command history, etc. all work without you have to turn it on/off again.

18) A new system call has been added in IOMAN:
Programmers information for the new call:
* I$ModDsc (SWI2 $91). Modify *any* bytes in a Device Descriptor module ONLY, after the module header. Unlike F$Linking it, it lets you modify it without having to link the entire file block it is in (like the OSBoot file, which can be 32 or 40K) into your processes' workspace.
* Entry Conditions:
*   X=Ptr to name of module to modify (Can be hi bit or CR terminated)
*   B=# of bytes to change (max 127)
*   U=Ptr to (B) # of 2 byte blocks:
*     byte 0 is the offset into the descriptor to change ($12 (IT.DVC) to size of module)
*     byte 1 is the byte to write to that offset
* Exit Parameters:
*   CC clear if no errors, and header parity/CRC on descriptor updated
*   CC set if error, B has error code. Some possible results:
*     B=216 Path name not found (module not found)
*     B=187 Illegal argument (tried to modify bytes either before IT.DTP/IT.DVC or beyond length of descriptor)
*       A=offset that was out of range (which byte pair had the error, not offset itself)
* It is up to the calling process to make sure they know the file size and right offsets.
* Offsets below IT.DVC ($12) will be deemed illegal, as well as any past the end of the
* descriptor (they can specify CRC bytes; they will get overwritten anyways).

19) Rescue on Fractalus has been optimized, and runs about 10% faster than the original Tandy version on a 6809, and about 20-30% faster on a 6309. It has also been fixed to not to chain to a SHELL when you quit (which would cause two shells running on the same window).

20) GShell has two new features added:
  A) You can now directly launch a VDG based application from GShell. To do this, your AIF.*** file MUST have the screen type set to 0, and the X/Y size should be set to 32x16. This uses the new system call I$ModDsc in IOMAN (see above), so that GShell won't run out of RAM when processing larger directories. The screen type is line 5 in the AIF file, and the X & Y sizes are lines 6 and 7. PLEASE NOTE: Currently, to enforce backwards compatibility, foreground/background colors in the AIF file for VDG based programs is ignored.
NOTE: SOME LEVEL 1 GAMES REQUIRE LETTER KEY RESPONSES TO BE CAPITAL LETTERS. NITROS-9 DEFAULTS TO LOWERCASE, SO FOR THOSE GAMES, ONCE THEY ARE LAUNCHED, HIT <CTRL>-<0> (zero) TO ENABLE CAPSLOCK. BIOSPHERE IS AN EXAMPLE.
NOTE 2: LEVEL 1 GRAPHICS GAMES TAKE 6K OUT OF YOUR SYSTEM MAP, SO ONE SHOULD ONLY ATTEMPT TO PLAY 1 AT A TIME (AND NOT HAVE TOO MANY OTHER REGULAR WINDOWS OPEN AT THE SAME).

(This has to be the most requested feature, ever, for EOU. :-) )

  B) You can now have an optional application name to print on GShell's screen under the applications icon, rather than just the name of the application itself. To do this, edit the first line in an AIF (which is the application name (executable program found in the CMDS directory), and add a pipe '|' symbol (CTRL-! on a real Coco 3 keyboard), followed by the "alternate" name to display. The name before the pipe has to still match the name of the program in the CMDS directory, but the 2nd name can be whatever you want. Please note that one can only fit 11 characters on screen for the 80 column/640 pixel mode in GShell, and only 10 characters for 40 column/320 pixel mode). Anything past that will be ignored, and I recommend only using up to 11 characters (spaces are ok) to shrink the file sizes (and GShell's internal tables) as small as possible.

21) Thanks to GShell's ability to launch VDG based apps, the following games will now launch from GShell: Rescue on Fractalus, Microscopic Mission, Where in the World is Carmen San Diego, Kyum-Gai: To Be Ninja, Biosphere, Zero Gravity, Flight Simulator II. Shanghai now has 3 tile sets that have separate icons to click on. 

22) The GAMES folder has been reorganized into a tree structure, to accomplish two things: 1) separated by Level 1 (Coco 1/2) and Level 2 (Coco 3), and again by genre so that load times for icons is reduced, and 2) games that require their own data files will have them in their own directory.
PLEASE NOTE: ALL LEVEL 1 GAMES THAT USE GRAPHICS SCREENS SHOULD ONLY BE RAN ONE AT A TIME, AS THEY TAKE A LOT OF SYSTEM MEMORY!

23) Joel Hegberg's Checkbook+ is installed in the APPS directory. Unfortunately, the docs I have are for the DECB version, but ALT-Letter keys and the arrow keys let you navigate menus.

24) COCOPRO!'s Klondike Solitaire (called Klondike 2) game by Kevin M. Foley has been added, as well as the source code for it (/dd/sourcecode/asm/klondik2). It has also been patched to leave your mouse settings alone, unless you force it by using command line options. Also, since the game has two variations (Regular and Klondike), I created 2 icons so that you can launch it easily in either mode.

25) Color Computer Artist is installed in GFX_APPS.

26) EXPERIMENTAL - TRY AT OWN RISK! - The CP/M emulator by Luis Antoniosi ("Coco Demus") is in EMULATORS. I have one experimental AIF and program to try - Hitchhikers Guide to the Galaxy text adventure (originally by Infocom). Since this literally emulating both CP/M and a Z80, give it time. If it seems to run ok, I will add some more CP/M programs to try on the next release or update.

27) Burke & Burke's Coco 3 enhanced version of the original Cyrus Chess is in the LEVEL2/BOARD_GAMES folder.

28) The main hard drive images (6xSDC.VHD) for the SDC are now "Schizo" images, thanks to David Ladd. This puts a very small Disk Basic partition onto it, where it has AUTO.BAS preinstalled. If you are one who spends the vast majority of your time in NitrOS-9, if you 1) Rename this file to AUTOEXEC.BAS, and 2) Point your default drive in the SD card's config file to your 6xSDC.VHD, your Coco will autoboot NitrOS-9 on power up.

29) Koronis Rift has been patched to cleanly exit back to GShell when you quit the game (with CTRL-C), and also has some minor optimizations for both the 6809 and 6309 versions.

30) Many thanks to Alan Dekok for allowing is DECB program launching utility RUSTY. I have created a folder called DECB, and put Alan's DECB program CC3DEMO.BIN there for testing, as well as multiple programs (mostly Coco 1/2, but a few Coco 3) to try. You can 'CD /dd/DECB', and then type 'RUSTY CC3DEMO.BIN' (or whichever program you want to test) to try it out. I don't have it set up for MultiVue/GShell yet; there are multiple options that we have to decide on defaults for first. (Type 'RUSTY -?' to see a list). NOTE: ON A COCOSDC, IF YOU HAVE SDC EXPLORER SET TO AUTOMATICALLY COME UP ON BOOT, YOU MUST  HOLD DOWN THE SHIFT KEY WHEN YOU HIT 'Y' <ENTER> UNTIL THE PROGRAM BOOTS. Also, the full docs for Rusty are now in /dd/docs, and two utilities that came with it, RSDISK & BUILDDIR are installed as well.

31) Also thanks to Alan Dekok for BOUNCE96 in the DEMOS folder. This a demo program using some routines that he has released to allow a game programmer to almost completely take over the Coco (including IRQ and FIRQ), while launching from OS-9. It even lets you CLEAR back to OS9 afterwards without rebooting. Documented source is in /dd/sourcecode/asm/bounce96.

32) RAYBOUNCE is another demo program found in the DEMOS folder. This page flips 9 raytraced images (it takes awhile to load), and you may need a 1 or 2 MB RAM upgrade for it to run. Hold down the <ENTER> key to exit the demo. This was released as freeware on Delphi way back, and was written by Robert Marsa. Source for this demo is in /dd/sourcecode/c/raybounce.

33) A new text font has been added (buffer number $42) that you can use in your own programs, or from any graphics window. This duplicates all 224 characters from ASCII 32 to 255 from the IBM PC CGA character set, including special drawing characters.
  To try it out: 
  DISPLAY 1B 24 1B 20 6 0 0 28 19 0 2 2 1B 3A C8 42 1B 21
    to see on a 40 column screen
  DISPLAY 1B 24 1B 20 5 0 0 50 19 0 1 1 1B 3A C8 42 1B 21
     to see on a 80 column screen
Many thanks to Todd Wallace for creating this font in April!

34) The filenames for the DSK and VHD images are now all forced uppercase, and will remain that way from now on. This is to both have consistency, and help users using the SDC who are manually mounting drive images with the DRIVE command, to not have to worry about switching between upper and lowercase.

35) The 6309 version of Flight Sim II has been optimized with a TFM, and the 6809 version has had it's main stack blast routine optimized (>900 CPU cycles per frame refresh). It is still frame locked, so you won't see a speed up, but it will smooth multi-tasking on both CPU's. We are working on actual speedups that should make it into Beta 6.

36) Drive /D2 has been removed from the default GShell drive list, as very few people have on, and they use the room for something else.

37) Sub Battle Simulator has been patched to exit cleanly, and return to GShell (you quit with CTRL-Q).

38) We thought that we had a bug in Where in the World is Carmen Sandiego, when you try to exit either the Hall of Fame screen, or list of detectives... but it turns out that the instructions on the screen are wrong (it says to hit any key). You actually have to hit <CTRL>-<BREAK>. Far in the future, I will actually fix this, but will leave it for now. Just be aware of it.

39) In honour of the original author of the simulator Game of Life, John Horton Conway, passing away in April 2020, the OS-9 version of the life simulator is installed in games/level2/simulators. It can be ran on it's own too, with command line parameters to change the settings. You can hit the <D> key to edit more dots in while it is running (<Q> to quit back to the simulation), or <Q> to quit the program. It's full documentation is in /dd/docs.

40)  3 Smartwatch utilities (GETCLK, SWREAD and SWSET) have been installed. If you have a Smartwatch installed in your Coco, you should be able to replace the SETIME line in the STARTUP file with GETCLK. This should initialize the OS9 software clock to your Smartwatches time, meaning you shouldn't have to type in the time at all any more. (We still need to get the native drivers fixed, but this stopgap should help those of you with a Smartwatch).

41) A little vanity text file from me in /dd/docs (called 6309index_modes.txt), which is the original post I put on Compuserve and the Fidonet Coco related "echo" boards back in October 1992. As far as I know, this was the first report in North America about the extra indexing modes that use the E,F and W registers. It was not part of the original translations from OhFM! magazine in Japan. If anyone who can translate/has seen the full translation of those original articles from 1988 in Japan can let me know if they were known before this, I would love to know. I was quite proud figuring this out back then! (Curtis).

42) Some sample original MacPaint pictures are included in /dd/pictures/mcp. Since their screen was very tall, it will by default shrink it to fit one screen, proportionally resized. If you want to see them in full, you can go to that directory and use VIEW -huge <filename>. It will break it into multiple screens, that you switch between with the up and down arrows.

43) 4 more WAV files have been added to /dd/sound. All 4 involve speech, but are sampled low (around 4-5 KHz), and are small enough that you could make each of them a standalone program (like the MEEP command we already had). They are: action, no_rules, missed4, and twenty).

44) More source code samples have been included, in /dd/sourcecode/asm. I have not tested all of these extensively; they are meant as more educational. This includes Allen Huffman's SNDDRV driver, sourcecode for the REBOOT utility, and Alan Dekok's GLIB library routines for doing sprites in NitrOS9. It includes docs, and there is a demo using it as well (see below). It was also used in the game Smash, which you have seen before.

45) The full docs for PCDOS and CC3Disk (with 512 byte sector read/write support) has been added to /dd/docs.

46) A demo program called BounceIt has been added to /dd/demos. This is a demo that Alan Dekok wrote to demo his GLIB sprite library. CTRL-E to exit, or it times out after a minute or two. You may have to hold the keys down for a second.

47) The game Sea Battle has been added into /dd/games/level2/board_games. It is a full graphical version of Battleship, mouse driven. Place your pieces on the right grid, and shoot at your enemy on the left.

48) A graphic twist on the Minesweep genre called Minefield, also by Zack Sessions, has been added to /dd/games/level2/strategy. Also mouse driven, the grid & numbers it gives you (how many mines are touching the space you are in) is the same as Mine sweeper - but, you are actually navigating from the upper left corned of the grid to the lower right, without blowing yourself up. So you have to move your happy face one square at a time.

49) Dynacalc has been added in the APPS folder. It's a complicated program; please download the manual from the Color Computer Archive for details.

50) RSB (to run DECB programs in NitrOS9) (with both VDG based launching and Windows based launching icons) is experimental in the EMULATORS folder. While not perfect, it will run simple programs easily, and could be a great aid for porting programs to BASIC09 - you can compare the output in the RSB window to another window with your BASIC09 conversion.

51) The system module VTIO has had it's SS.GIP (Set Global Input Parameters) enhanced:
The original version had a nice feature - if register Y was $FFFF on entry, it left your keyboard settings alone, allowing you to set the global mouse settings without forcing an update to the keyboard settings as well. So, I expanded on that and made it so that all 4 individual settings (Mouse resolution, Mouse port, Keyboard repeat start delay, and Keyboard repeat speed delay) will leave the current setting alone if you send that parameter with a value of $FF:

SS.GIP (function code $94)
Entry conditions:
  A=path number
  B=$94
  X = mouse resolution; in the most significant byte
      0 = low resolution mouse
      1 = optional high resolution mouse adapter
      $FF= leave current system setting alone
      = mouse port location; in the least significant byte
      1 = right port
      2 = left port
      $FF= leave current system setting alone
  Y = key repeat start constant; in the most significant byte
      0     = no key repeat
      1-$FE = clock ticks (1/60th of a second) before key repeat starts
      $FF   = leave current system setting alone
     = key repeat delay; in the least significant byte
      0-$FE = clock ticks (1/60th of a second) before key repeats
      $FF   = leave current system setting alone

52) A bunch of the Sierra games have been added (including some fan made ones). NOTE: These currently contain self-modifying code, so you should only try to run one Sierra game at once. If you want to switch games, ALT-Z will exit any of them, and then you can switch folders and try a different one. Currently, it works with 512K Coco 3's, and Coco 3's with the Triad+ and Boomerang E2 (2nd revision) 2 MB boards. Robert Gault had made patches for older 1 and 2MB RAM boards (Disto, older Boomerang are examples), but those apparently crash on a 512K machine. I am currently looking into what is needed to fix these up so that the same versions of the program modules will run cleanly on ALL 512K+ machines. All of the Sierra games have their own folders, found in /dd/games/level2/adventure/graphical.
NOTE: I noticed when checking against the archive that I still have more of these to add (mostly fan made ones). These will come in the next release.

53) As mentioned in the "QUICK NOTE ON FUTURE UPDATES" section above, we are now including a second, blank hard drive image (also 128MB), that you can mount as drive 1 in MAME (using the File Manager menu), or on the Coco SDC (Unfortunately, VCC and OVCC both only currently support 1 hard drive mounted at a time). This will give you a spot to put your own files, projects, and backups of anything you change from the main boot drive, so that we don't wipe them out when the next hard drive image is released. (Eventually, when most 3rd party software is fully installed on the main hard drive image, and we clean up a lot of our test and "in development" files to free up some room, we will start releasing floppy image "installer disks" to do updates, that won't wipe things out on you. But that's multiple versions away from happening, yet). Please note, you do not need to have this installed in order to run EOU.

In MAME:
  Select 'File Manager' from the menu (or assign -hard2 from the command line) and then select the EOU_USER.VHD for the second hard drive. This will be under /h1 in NitrOS-9, and will bring your total storage up to 256 MB.

On the CoCo SDC:
  If doing it from BASIC, mount the drives with DRIVE 0,"6xSDC.VHD" (replace 'x' with 8 or 3, depending on your CPU) and DRIVE 1,"EOU_USER.VHD". Then, type DRIVE0 and then DOS to boot.

  If doing it from the CoCo SDC Explorer, select the data drive first, and hit SHIFT-1 to mount it as drive 1. Then select the main boot drive (6xSDC.VHD) and hit enter on that to boot NitrOS-9.

A 3rd option, if you use NitrOS-9 almost exclusively, is to edit the STARTUP.CFG file to set up drive 0 and 1 with the main boot image VHD and data drive, respectively. You can boot straight into it on powerup (and even make that automatic by renaming the AUTO.BAS file to AUTOEXEC.BAS, as mentioned previously).

Another advantage to having this second hard drive is that you can share it between 6809 and 6309 machines, if you have both, or after you upgrade. 

SOME KNOWN BUGS/GOTCHAS:
1) GLife has been fixed to keep the system mouse settings, but be forwarned that it really does require high res mice in order to draw single dots in specific places. If you do not have a high resolution mouse interface, I would strongly suggest using the keyboard mouse temporarily in this situation, with the SHIFT arrows allowing single pixel movement (See the Beginners Guide documentation for more detail in using the keyboard mouse).

2) The Sierra games will currently only work on a 512k Coco 3, or one of the newer 2 MB RAM boards (Triad+ or Boomerang E2 version 2 or higher) that allows reading back MMU block registers. There was a patch done years ago that fixed that, but apparently it also crashes on 512k machines (which is why Guillaume Major reverted back to the stock version on the Archive) . Since the newer 2 MB RAM boards are much more plentiful in the wild, I am currently supporting the stock version until I can fix it to be universal (so, Beta 6).

There are also some programs that are partially installed, but known not to work (and will crash). If you go into a games folder, but there is no actual game icon to click on, it's probably one of those. Please don't try to run them until the next release. I have left them on the VHD's for us to work on.

I am sure others will be found. Please email me the details (what program, what specifically it is doing wrong, whether you are running on real hardware or an emulator (which emulator, and which version of the emulator, if the latter). Also mention if on the 6809 or 6309 version, and what RAM you have installed (and brand). Email bug reports to curtisboyle@sasktel.net, or post them in the #nitros9eou channel (under 'OPERATING SYSTEMS' on the CocoTalk! Discord, and we will try and find/fix them.