BETA VERSION 3 RELEASE NOTES:

Note that everything in the notes for Alpha 1, Alpha 2, Alpha 3, Beta 1, and Beta 2 still applies.

These will eventually all be merged into one document.

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

Quick note: As usual, “real life” interfered tremendously with getting as much done as either Bill or I would have liked, but there is some good stuff/improvements in this release, particularly for 6809 users this time around.

There is much more planned, and actively being worked on by both Bill and myself, so stay tuned!

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.

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.

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.

NOTE: This is now being actively worked on (as well as making VCC cross platform).

Stay tuned on the Cocolist for details and updates.

NOTE: We have nothing to do with that project.

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.

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.

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.

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.

1) 6809/6309 GRFDRV optimizations: clear screen, clear to end of line, clear to end of screen and overlay windows should be faster (most of the time) on hardware text screens on both CPU versions.

Scrolling full width windows on hardware text screens should be marginally faster as well.

2) 6809 GRFDV optimization: Clear screen for full screen width graphic windows is dramatically faster (a test program clearing a 320x200x16 color screen 100 times took about 7 seconds on the new Beta 3 version vs. about 24 seconds on Beta 2).

Clear screen for non-full screen width graphic windows is somewhat faster as well.

3) 6809 GRFDRV optimization: Horizontal lines on graphics windows, with no LSet and/or PSet logic applied, should be a little faster on wider lines.

This is much more noticeable when doing large Bar commands (filled boxes).

4) 6809 GRFDRV optimization: Filled Ellipse and Filled Circle (which share code with horizontal line) also get significant speedups, with no LSet and/or PSet logic applied.

5) Other small random optimizations in grfdrv for the 6809.

Please report any bugs that you may find.

6) Test program that I used for the Filled Ellipse/Circle demo is in /dd/sourcecode/basic09/FillCircleEllipseTest.b09.

Please note - I used this to test from various graphics modes, so I didn't program it to set up a graphics mode - you will have to create a graphics window yourself.

7) JOYDRV (for regular joysticks/mice) has been fixed to allow you to access all 199 lines on the screen, for both normal and with High Resolution Joystick Interface.

Shrunk a bit too.

8) The bouncing ball demo had a small glitch - it didn't draw the vertical lines quite far enough on the bottom of the screen the match what the lowest position of the get/put buffers for the ball.

It also didn't set both windows to the exact same size.

So it gradually “painted” in an extra row of dots on the bottom on one graphics page, but not the other, flickering away.

This is now fixed.

9) Allen Huffman's Invaders-09 (Space Invaders) game is now in the games directory, and it's full docs in / dd/DOCS (the game has some built in help, enough to play without reading any directions).

10) Change the classic Mac graphics file extension to .mcp (MacPaint), to differentiate it from the .mac sound files (If you went from one to the other in GShell, it would display the wrong icon, and try to run the wrong program).

11) Added the QBert09 game back in, after making some changes to it (thanks much to Wayne Campbell and his DECODE program, since I didn't have the original BASIC-09 source code!) so that it functions properly on the latest versions of NItrOS-9 and EOU (the line drawing routines have improved symmetry, thanks to Robert Gault, but this is one program where the slight change in line drawing actually caused Flood Fills to leak all over the screen).

The new source code (which I only commented on enough to figure out what to fix) is in /dd/sourcecode/basic09/games/qbert.b09.

I haven't extensively tested the game; please send feedback if you find any issues.

(Uses left joystick).

12) Added some GIF's to the /dd/pictures/gif directory.

Also changed the icon for forced Black & White GIF's, so that you can tell the difference.

Any GIF images you want to force to black and white (higher resolution) mode, rename to .gbw instead of .gif.

I have a few examples where I have left both (they are the same file, just a different extension), for examples.

13) Added Control Panel as a standalone app (and resizable) in the UTILITIES directory.

It will always run in a 320/16 color mode window, so that you can see all of your palette settings.

14) Added some further sound icons so that you can play some of the other sound samples in SOUND from the GUI.

Also, tweaked the hacked in sound playback speeds on some of the older samples on the 6809, so they play more at the proper speed.

(Way back when, we manually put in the time delay between samples, not caring about cpu speed increases).

They should all play pretty close to the 6309 versions now.

15) The bug in Select Window (that trapped certain apps, like VIEW, VIEWGIF and the Bouncing Ball demo, on their own windows when you tried to leave them with the CLEAR key) has been fixed.

16) A slight glitch in the /dd/defs/os9.d file has been fixed.

L. Curtis Boyle, December 21, 2018

P.S.

Work is continuing 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.

Return to NitrOS-9 Ease of Use :: Tandy Color Computer