BETA 6.0.1 UPDATE NOTES
Beta 6.0.1 (January 23, 2021 updates): The bug fixes (and some updates) that have been done since Beta 6.0.0 are listed below:
1) Much thanks to Ed Jaquay, who solved a long standing bug in the EMUDSK driver that caused problems when copying from /h1 to /dd.
This is now fixed (and it is slightly optimized).
It also should boot properly from hard drive 0 if you reboot after last using hard drive 1.
2) Grfdrv has had an obscure bug fixed in it's PUTBLK routine (for get/put buffers) - if you were PUTing a graphics buffer on the screen where the last line of the get/put buffer coincided with the last line of the window you were drawing it on, it would draw an extra line of garbage.
This has been fixed.
Also, LSET's using XOR or AND logic on wide areas of at least 2 bytes are a little faster on the 6809.
3) Thanks to Bill Pierce, various new documentation files are now added to /dd/docs.
4) Thanks to JoAnn Donaldson, a missing carriage return in /dd/defs/stdlib.h has been fixed.
5) Thanks to Rob Inman, a GSHPAL setting bug in SuperIke has been fixed, and it will now display your chosen 4 GShell colors properly when showing icons.
6) A new version of the DWIO driver is installed on both the 6809 and 6309 Drivewire boots.
This now preserves the DriveWire server version #, making it available for future use.
7) A new version of SysGo is installed on all images, which adds in DriveWire detection.
This has several levels: “Not Detected” - this means the Coco has booted up without the DWIO module loaded.
“Installed” - this means that the Coco has at least the DWIO low level DriveWire driver module loaded.
“Active” - this means that both the Coco has DriveWire drives loaded, and that the DriveWire server responded.
It will also reveal the type or version of Drivewire that it found.
“(Inactive) - Checking” - this should only show up briefly if it finds the DriveWire server, but no device has been connected yet (it will try to open a path to any one of /X0, /X1 and /X2; if it can't it will ask you to check your DriveWire server).
8) Thanks to Jeff Teunissen, his new DCC C compiler has had two modules updated: dcpp - should be much harder to crash dcc68 - should also be harder to crash.
Both modules should allow larger, more complicated projects to properly compile, by allowing dynamic allocation of memory between the symbol table and the stack, instead of more fixed sizes to each.
9) GShell - The Disk → Set Devices pop-up menu now warns of its 5 (storage) device limit.
EOU recommends specifying less than 5 default devices in the SYS/env.file (RBFDEV=/dd, h1, etc).
Since default devices cannot be changed within GShell, the above guidance ensures that that lesser-used /devicenames (i.e.
/d2 /x2, /r0) can be continuously swapped in or out.
It has also had some minor patches to work with the new CONTROL program (see below).
10) FORMAT is now up to edition #26 (thanks, David Ladd!), which now can format both regular floppies (18 sectors per track) and the special 20 sector/track format that gives you more storage space on regular floppy drives.
It works as per normal, except it now has an extra option 'e' (upper or lowercase is fine), which lets it use the 'e'hanced track format that gives you 2 extra sectors per track.
This works on all physical floppy drives, irregardless of # of tracks or sides.
11) Owing to the newly discovered feature in GShell above, we have reduced the default drives for all configurations to leave at least one slot free for swapping.
Of course, if you need a specific set of 5 drive devices all the time, you can change this by editing the SYS/env.file's.
12) Due to popular demand, the SDC only and EMU images now have the printer driver installed for the bitbanger.
In the case of the emulators, you must make sure that they are set up for the bitbanger printer, and how they react to that (saving the printer output to a file, etc.).
13) Added CALL program by Scott Griepentrog, thanks to William Carlin, include docs in /dd/docs, and sourcecode in /dd/sourcecode/c/call.
This allows performing a command on multiple files with a single command line.
14) SDC2 has been updated with some bug fixes when used with a multi-pak, and makes sure that it only runs on drives that are SDC related.
Please let us know if you still find some issues with the new version.
15) SwapBoot has been updated to version 1.01.
This version moves all 3 files of a set (OS9Boot, startup, env.file) into /dd/BOOTS, to help clean up the root directory, and make it easier for one to organize.
16) There is an additional DriveWire boot set that supports DriveWire through the RS-232 pak instead of the bit banger.
17) Guillaume Major's update to the MNLN module that is used by all of the Coco 3 Sierra games in now included.
This allows playing music, but you can abort the music by pressing the BREAK KEY.
This will work on 512K Coco 3's/emulators, and later 2 MB RAM machines/emulators that allow reading all 8 bits of the MMU (the latest Boomerang E2, Cloud 9 and Zippsterzone 2 MB RAM upgrades).
The previous version is still available (in case problems are discovered).
In /dd/cmds, 'MnLn' defaults to this new version.
'MnLn.org' is the previous version, and 'MnLn.new' is the new version.
To change the version, simply do 'CP -o MnLn.* MnLn', where * is either 'org' (for the older version), or 'new' for the new version.
18) Many thanks to Fred Provoncha for his great work in re-writing the CONTROL program from scratch, so that it has a better presentation, has a new presets feature (which includes not only the 4 alternate color sets we showed in 6.0.0 release documentation, but many other color sets as well!), and will no longer corrupt the SYS/env.file if it is too large.
NOTE: Any changes you make with CONTROL are saved to the ACTIVE SYS/env.file.
If you want to make those changes permanent between SWAPBOOT's, you will need to do: CD /dd/sys CP -ov env.file env.file.<setname> where <setname> is the current bootset you are running.
This way, when you SWAPBOOT to something else, and the SWAPBOOT back to this set, your changes will stay.
It should also be noted that GShell will keep the last colors you edited in control, so make sure you have the GSHELL button (under the Palette: column) pushed down on exit, otherwise it will use the “main” first 4 colors when you exit.
BETA VERSION 6.0.0 (December 24, 2020) NOTES:
Note that everything in the notes for Alpha's 1 to 3, and Beta's 1-5, 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 5:” 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 at sasktel dot net.
ALSO - PLEASE SCAN THROUGH THE BEGINNERS DOCUMENTATION FILE, AS IT CONTAINS SOME UPDATED INFORMATION PERTAINING TO BETA 6.
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.
There is also some work being done on getting OVCC to support a second hard drive.
The original VCC still currently only supports a single hard drive, although that is also getting an update very soon.
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 6 RELEASE, FROM BOTH BILL NOBEL AND L.
CURTIS BOYLE:
Todd Wallace - new DOSDIR command, which formats the DIR like MSDOS, and reports both file sizes and free space left on the current drive (floppy or hard drive) in decimal instead of hex.
Also for his IBMCGA font, which includes 224 characters from the ANSI character set (CHR$(32)-CHR$(255)), which is in Group $C8, Font $42.
Jay Searle - for helping get the major project of redoing/updating the entire OS-9 Level II manual off the ground.
Thanks to him, we now have both the Windowing and Technical Reference reference sections complete, available at: http://www.lcurtisboyle.com/nitros9/nitros9_docs.html Work on the next parts of the manual have started as well.
Jeff Teunissen - For giving us permission to included his new, more modernized C compiler 'DCC' (and related parts) to be included as of EOU Beta 6.
He also supplied the new HELP command system that you can try out.
Ed Jacquay, who fixed a long standing bug in the EMUDSK driver for the emulators, that caused some fatal problems when copying files from /h1 to /dd.
All of the original authors of various programs that we now have set up to run from GShell, of whom there are too many to mention.
Also thanks to our testers: Aaron Doughty, Michael Furman, Rob Inman, Ron Klein, David Ladd, Grant Leighty, Nick Marentes, Nick Marotta, Mark Overholser, Floyd Resler, John Shawler, Terry Steege, Steve Strowbridge, Tim Lindner, Ed Snider, David Lightman, Bill Pierce, and Todd Wallace.
NOTES ON RTC (REAL TIME CLOCK) SUPPORT
EOU Beta 6 now has some support “officially” for real time clocks.
On the real Coco hardware side, support for reading the real time clock from your DriveWire (or pyDriveWire) server is supported, if you select the correct boot (and have the server running).
This seems stable from multiple people testing.
If you have an actual real time clock hardware chip in your Coco, you will have to modify the OS9Boot file and replace the Clock2 driver with the appropriate one from the NitrOS-9 repository.
Let us which ones from there work, and which don't.
If you have a Smartwatch installed, then replacing the 'SETIME <»>/1' line in the /dd/startup file with 'GETCLK' (or just typing it at a Shell prompt) should update your time.
In the emulators, it seems to be a mixed bag, with no real predicability.
This is where we need your feedback; please try the following suggestions, and let us now what the results are on your emulated system.
Please include the following information: 1) What emulator you are running, at it's version number (ex.
VCC 2.1.0b, MAME 64 bit 0.224, etc.):
2) What settings you used for the real time clock in the emulator (for example, MAME has options for Disto, and Cloud9):
3) Whether you are running the 6809 or 6309 version of NitrOS-9 Beta 6:
4) What host OS are you running your emulator under, and it's version information (like Windows 7 32 bit, Windows 10 64 bit, OSX Catalina, etc.)
This way we hope to narrow down why it seems to be inconsistent.
From what we have seen, one of the following is most likely to happen: 1) It works fine.
2) It will work on the initial boot (your SHELL will report the proper date/time when NitrOS-9 boots), but it will return the incorrect time/date (either all 0's or “random” date/time) after about 1 minute.
3) It will always return 0/0/0 00:00:00.
In general, here are some things that seem to work more often than not:
1) VCC - Set slot 3 to be Hard drive + Cloud 9 RTC.
Try the latest version (2.1.0b at the time of this writing).
2) MAME - Bring up the MAME “GUI”, select Machine Configuration → Real Time Clock.
Try DISTO first.
If that does not work, switch it to CLOUD9.
If that doesn't work, use SWAPBOOT to switch to the Emulator software clock instead.
CHANGES FROM BETA 5:
DEFAULT SETTINGS: EOU Beta 6 now has some different defaults, depending on whether you are running from real Coco 3 hardware, or a GIME-X test system, or an emulator.
These are based on the minimum capabilities of each, but you can change them (what and how to change is found in the separate “env_file_documentation.rtf” file).: A) Real Coco 3 (6809 or 6309) - defaults to Composite video mode, and 40 column /TERM window and 40 column GShell.
This makes it readable on all systems, but if you have RGB or VGA output (or good eyes!), you can change this (See separate documentation file “env_file_documentation.rtf” for details).
B) Real Coco 3 with GIME-X (6809 or 6309) - defaults to RGB video mode, and 80 column /TERM and GShell.
C) MAME, VCC or OVCC Emulators (6809 or 6309) - defaults to RGB video mode, 80 column /TERM and GShell, and software clock.
You can switch to a hardware clock, if you are lucky (see page 4 above for notes and details).
For A) (real Coco 3, regular GIME), you can also boot with DriveWire, rather than just the SDC.
See SWAPBOOT instructions in the separate documentation file “EOU_Beta6_Drivewire_updates.pdf” for details.
PLEASE BE AWARE: IF YOU SWITCH BETWEEN A REAL COCO AND AN EMULATOR, THE STARTUP AND ENV.FILE FILES WILL BE LEFT IN THE LAST SWAPBOOT STATE.
This means that you should run SWAPBOOT after you switch, and select the appropriate boot set, to make sure that it's settings take over (if you change them to match, of course, then you don't need to unless you are changing between hardware configurations within either the real hardware or the emulator; the OS9Boot files for each are on separate drives (/d0 for the emulators, and /dd for the real Coco 3/SDC).
1) Small bugfix in VTIO that will cause it not to work with CoGrf instead of CoWin (doesn't apply to EOU at all, since it requires CoWin, but would cause an issue with the Repository version of NitrOS9).
Also slightly optimized keyboard read routine.
Also the SetStat SS.ComSt (when using with VTIO/CoVDG combination devices) is fixed.
2) Fixed the attributes on the VEd..Defs file (in /dd/CMDS) so that you can save your own system wide settings.
3) Fixed some sound files (with embedded Coco defined speed settings) on the 6809 image.
These were correct in Beta 4, but when the new directory structure was made for Beta 5, I inadvertently copied the 6309 versions to the 6809 image (so they played at the wrong speed).
4) Fixed the AIF file for Color Computer Artist to default to 320x192x16 color mode (instead of just 4 color mode).
5) Fixed Cyrus Chess to not switch system wide mouse settings on exit.
6) KwikGen now defaults to a 48K buffer (rather than 32K), which should handle all EOU boot files, so you won't need to remember to add the '#48k' every time.
7) DISPLAY had an unreported (until July 4th) bug when processing decimal values - it would produce incorrect results for any '0' digits in the decimal number.
This is now fixed.
Thanks to John Federico for finding this and reporting it on Discord.
8) Todd Wallace's new DOSDIR (MS-DOS style DIR command - looks really good with Todd's IBM CGA font!) has been added, including sourcecode in /dd/sourcecode/asm.
9) KeyDrv (the keyboard driver) has been merged back into VTIO.
This will be (very slightly) faster, but it also makes the combined module more than 50 bytes smaller, and releases some VTIO system RAM as well, which I plan on using shortly.
10) The beginnings of the new SS.GIP2 SetStat call is installed.
More features will be added in the future, so any undefined bits in X, and registers Y and U, should be set to 0 on entering this call so as not to cause unexpected results when the call is gradually updated with more features.
SS.GIP2 (Global Input Parameters 2) Entry: A=current path
B=$99 Y=$0000 (reserved for future use) U=$0000 (reserved for
future use) For the following, each flag is handled by 2 bits:
X=MSB: 0xxxxxxx = Leave 2nd mouse button function unchanged
10xxxxxx = Disable 2nd mouse button as CLEAR key 11xxxxxx =
Enable 2nd mouse button as CLEAR key xx0xxxxx = Leave current
key click setting alone xx10xxxx = Disable key click on
current window xx11xxxx = Enable key click on current window
Key click is a local window setting (based on current path), and works on both CoWin and CoVDG windows.
2nd mouse button function is system wide, affecting all CoVDG and CoWin windows.
It should be noted how the 2nd mouse button as window select works: 1) Click and release 2nd button by itself - go to next window (same as CLEAR key) 2) Click and release 2nd mouse button while 1st button is held down - It will go to the previous window when you release the 2nd button (same as SHIFT-CLEAR keys).
If you keep holding button 1 down, you can keep click/releasing the 2nd button to keep going backwards through your windows.
One other note on the 2nd mouse button functionality - previous versions of NitrOS-9 3.xx.xx had this hard coded to the right joystick port only.
It now uses the system setting that you specify, so you can make it left or right, as you prefer.
A note on Key click - if you create another window, the key click status is carried over from the parent window.
(ie if you have Key click enabled in /TERM, and you do a SHELL i=/w4& from /term, then /w4 will also have keyclick on).
• 11) MVCanvas is installed, in the GFX_APPS folder.
The manual is available on the Color
• Computer archive.
This is a full featured graphics screen editor, like Colormax 3 or CocoMax III,
• and even allows editing at 4 different screen/color resolutions.
•
12) Pierre Serrazin's Color8 game (level 1 graphical card game based on Crazy 8's) in GAMES/LEVEL1/CARD_GAMES.
As with most level 1 graphics games, it takes a lot of system RAM, so don't run it with a lot of other windows, and make sure to close it when you are done playing.
13) Screen scrolling (especially on full width text and graphics screens with no borders) is about 14-15% faster on the 6809 (ex.
listing a text file 287,298 bytes long went from 237 seconds to 204 seconds on an 80×25 hardware text screen, and went from 1535 seconds to 1251 seconds on a 640x200x4 graphics screen).
GPLoad's should be a little faster too, as well as large width Get/Put buffers.
14) DIR has been updated to edition 9.
This shrinks the code slightly (and should be marginally faster) and fixes a longstanding bug when filenames >15 characters are present while running in a window with <48 character width.
15) Much thanks to Paul Shoemaker, we now how have his nicely draw 16 color card sets (55 get/put buffers in all).
They are in reserved get/put buffer group #207 ($CF), but they are NOT loaded by default, as they are fairly large.
The buffers themselves are in /dd/sys/carddeck; sample BASIC09 code is in /dd/sourcecode/basic09/cardbase.b09.
It has 3 subroutines you can use (please read the comments), and a small test program.
The graphics speed, even on the 6809, is quite decent, so it would be quite possible to make a card game in BASIC09 where one could drag and move the entire card around.
16) An updated version of GPMAP is included that is both faster, and now knows about two more special get/put buffer groups: Stdwnd (group $CE; Gshell/MultiVue extended graphics) and StdCd16 (group $CF, the new playing card 16 color graphics mentioned above).
Source code is in /dd/sourcecode/basic09/gpmap.b09
17) 6 pixel wide and proportional fonts are sped up a few percent on both 6809 and 6309.
18) Ultimuse III's latest release (G) is now installed, and should work properly.
19) Bill has added a early alpha version of a new SDC2 utility which is an easier to use/remember commands version of Barry Nelson's earlier SDC utilities (which are also still present in case you have scripts set up).
NOTE: AS OF DECEMBER 2020, THIS STILL HAS SOME BUGS BEING WORKED ON.
20) ASM is now up to Edition #11, Revision 1.
This contains two bug fixes: A) Modules that contain bytes that should be generated before the MOD statement (like REL uses, for example), were erroneously including those bytes in the CRC calculation for the module.
That has been fixed.
Thanks to Bill Nobel for finding this one.
B) For the “G” option (generate all bytes on program listings when the “L” listing option is selected), ASM was erroneously throwing part of the original source line (and shifted to a weird position) on the last line of any block that was >4 bytes, and that did not end up being an even 4 bytes.
That should be fixed.
Thanks to David C.
Wiens for reporting this error.
21) 6809 versions now have the slightly smaller/faster edition #3 of KrnP3 (previously had edition #2)
22) REL will now show whether you are running the 6809 or 6309 versions of the kernel on boot.
23) REL will also now show if you are running a GIME-X at 2.86 MHz or not on boot.
This is the first of our GIME-X support, which is to run the entire OS at 2.86 MHz (except when accessing the SDC; it has to drop back to 1.78 Mhz for that).
Thanks to Bill Nobel for getting the 2.86 Mhz working across multiple modules!
Please note: You have to use the specific 68GIMEX.VHD or 63GIMEX.VHD in order to get the increased speed, and you must have a static RAM based memory upgrade (Triad, Triad+, Boomerang/Boomerang E2 (latter needs latest updated version), and Zippster's 2MB RAM upgrade).
24) The RAM disk driver RAMMER is slightly faster on reads on the 6809 now.
The 6309 version is a tad smaller.
25) The “use the 2nd mouse button to switch windows” has been fixed now to use what ever mouse port you have active (previously, it was hardcoded for the right port only).
26) A BASIC09 test program (/dd/sourcecode/basic09/test-ssgip2.b09) allows you to test the SS.GIP2 system call, and allows you to turn key click on/off in the window you run it from, and whether to enable the 2nd mouse button for changing the active window or not.
It is currently defaulted to OFF on boot (it actually made some programs that required a 2 button mouse not work properly), but you can turn it on again with this utility.
It is also already packed, so you can it from the shell with TEST_SSGIP2.
27) A BASIC09 test program (/dd/sourcecode/basic09/testjoymouse.b09) is also included (and packed already), that allows you to test the Joystick and Mouse GetStat calls in conjunction with changing the SS.GIP2 2nd mouse button function.
This will monitor the 2 buttons (depending on your SS.GIP2 setting) and the position of joystick (0-63 x 0-63) or mouse (scaled to 0-639 x 0-198).
28) I have tried patching the FFill (flood fill) with patterns enabled (in Grfdrv) as best as I can, to prevent it occasionally getting stuck in an infinite loop with certain patterns and with certain backgrounds it is painting over.
However, this may cause it to exit with a stack overflow error on occasion (even the original from Tandy/Microware did - hugely complex paint areas can cause this error).
So, when filling (painting), try to make sure that you are doing smaller, enclosed areas to prevent such an error from happening.
29) Fixed a bug in the Memory dump option in the DEBUG utility (Thanks to Paul Barton for pointing out this bug!)
30) Floyd Resler's Gem Quest game is now installed.
It has been patched a bit to slow it down to a playable speed, by adding some extra sound tickets for walking and climbing ladders.
Some other minor patches to the original is to return the memory for it's Get/Put buffers back to the system on exit, and fixing a bug where the pods would occasionally disappear before being destroyed.
The manual is viewable in /dd/docs/gemquest.txt.
You can view that on an 80 column hardware text screen with 'VU /DD/DOCS/GEMQUEST.TXT', or through GShell by single clicking the .txt file, and then selecting File→List from the GShell menu.
31) MODBUSTER (a utility to split a file of merged memory modules into each separate file within) has been updated to report errors a bit better, and also to display the name of each module being split out, as they are created.
32) GFX has been updated to include the FILL function (no parameters) which will paint the current foreground color at the current graphics cursor location.
This is for medium resolution screens (Coco 1/2 style graphics screens).
There is a small test program demonstrating it in /dd/sourcecode/asm/basic09/test_programs/gfxtest.bas.
This must be run from a 32 column VDG window.
It also includes sample code for the GLOC function, which is mentioned but not fully explained in the BASIC09 manual (it will be in the new version of the manual).
This allows you to get the address of the graphics screen, where you can POKE and PEEK around to your hearts content.
33) PIPEMAN as been very slightly optimized.
34) DISASM has had a minor bug fixed (PSHU/PULU used U for the register to push onto itself).
Fixed so that is S.
It has also been updated to properly disassemble the new I$ModDsc system call.
35) 6 new programs have been installed in the EMULATORS/CPM folder, for those who want to run some old 8080 based CP/M programs.
Added is Supercalc, Turbo Pascal, Wordstar, and Zork I/Zork II/Zork III.
They do run slow (but we are emulating another CPU running another OS, after all), but they do run.
They run better on the upcoming GIME-X at 2.86 MHz, of course.
36) MShell (by Bill Pierce) has been reinstalled with version 1.03.
I have not “initialized” it, so if you type MSHELL from a text screen, and then hit ENTER after the screen clears and a cursor comes up, you can set the defaults for it to your own tastes.
There is some documentation for it in /dd/docs as well, but full documentation in PDF format can be gotten from Bill Pierce's website.
37) The new DCC (newer C compiler suite) by Jeff Teunissen has been installed (in such a way that the older version is still there, just in case).
See the separate documentation that comes with EOU Beta 6 for details on what has been updated and improved.
Currently it does 6809 code only.
38) 7 more Sierra AGI engine based games have been added: Mixed-Up Mother Goose (Sierra game) and 6 Homebrews: AGI Quest I, Caitlyn's Destiny, Enclosure, Time Quest, V and Voodoo Girl.
These can all be found in /dd/games/level2/adventure/graphical.
39) An *adult* Strip Poker game has been added in the games/level2/Card_Games folder.
If this is offensive to you, feel free to delete the directory, or rename the AIF file to something else so that it doesn't shows up as double clickable in GShell.
The game is exclusively keyboard, and is based on an original for the IBM PC from way back, using the left/right arrow keys and space bar.
This was another that I had de-compile, and I think it is fully working, but if you find a bug, let me what you did to get it.
The sourcecode is in /dd/sourcecode/basic09/games/spoker.
40) We have made new special merged versions of BASIC09, with some common BASIC09/RUNB subroutine modules merged, and with slightly different names.
Currently, this is only the Tandy ones (although updated): SYSCALL, INKEY and GFX are merged and name BYSCALL,BNKEY and BFX, respectively.
GFX2 now has a matching standalone version called BFX2.
These are functionally identical to the regularly named versions, and are meant for use in debugging programs in BASIC09's pre-packed and debugging modes.
Using the originals meant that they need to get mapped into BASIC09's 64K process space along with BASIC09 itself (which takes 3 MMU blocks itself, and 1 more for it's internal variables and the start of your programs).
There were two ways this happened; loading each one separately as they were called (which means they take 8K *EACH*), or the pre-merged versions in RUNB (which meant that all of them combined take 16K, since RUNB itself tags along).
Using this new method, if your program uses the calls Inkey, Syscall or Gfx, it takes NO extra RAM at all.
Adding GFX2 to the mix is only 8K RAM extra.
This way, you can test your larger BASIC09 programs by simply doing a wildcard replace of those RUN modulename's with changing the first letter to a 'b'.
Once you have finished debugging your program and are ready to PACK it, simply use the wildcard name replace to rename them back to normal (so that they will work with RUNB).
You can do these renames in several of the included text editors (VED still being
RTS
Return to Top or NitrOS9EOU