NitrOS-9 is a community-based distribution of the Microware OS-9 operating system for the Motorola 6809 that was introduced in the late 1970s and sold into the 1980s.
The Hitachi 6309, which contains additional registers and enhanced instructions, is also supported.
Here are the current ports of NitrOS-9:
| Computer | Port | Processor |
|---|---|---|
| TRS-80 Color Computer | NitrOS-9 Level 1 | 6809 & 6309 |
| Radio Shack Color Computer 2 | NitrOS-9 Level 1 | 6809 & 6309 |
| Tandy Color Computer 3 | NitrOS-9 Level 2 | 6809 & 6309 |
| CoCo3FPGA | NitrOS-9 Level 2 | 6809 |
| Dragon 64 & Tano Dragon | NitrOS-9 Level 1 | 6809 |
| Dragon Alpha | NitrOS-9 Level 1 | 6809 |
| Atari w/ Liber809 | NitrOS-9 Level 1 | 6809 |
| Corsham 6809 SS-50 | NitrOS-9 Level 1 | 6809 |
| Foenix F256 with FNX6809 | NitrOS-9 Level 1 & 2 | 6809 |
To build NitrOS-9, you need the following:
- lwtools. This package contains the required 6809 assembler and linker.
- ToolShed. ToolShed provides file system tools for creating disk images, copying files to and from those disk images, and more.
Once downloaded and installed, you can build the entire project:
export NITROS9DIR=$HOME/nitros9
make
Then to build all of the disk images:
make dsk
The result is a number of disk images (ending in .dsk) that can be used on real floppy drives, emulators, and DriveWire.
If you wish to contribute, please fork the repository and submit pull requests.
Also, assembly source code is formatted to the following specifications:
- Spaces only (no tabs)
- One space between opcode and operand, and operand and comments
This ensures a consistent experience and efficient representation in the repository.
Put this file in your .git/hooks folder to ensure that any source code you submit is automatically formatted.
When you commit your changes, please use standard Git message style. The first line of your message should be short but descriptive, telling viewers of the source code what you have changed in 50 characters or less. This is like a "Subject:" line in an email, and git format-patch actually uses it as one.
If the change is not 100% self-explanatory, the first line should be followed by a blank line and a message (word wrapped at 72 or fewer characters) telling everyone why you made your changes. Be descriptive, someone (perhaps even you) will someday need to understand what you had in mind when you wrote something, and the easier that is for them the better.
Everything in each commit should be related to a single change, described in the message. For example, if you are documenting a source file and also optimizing it, those actions are separate even if they touch the same file. Document it first, then optimize; so that if you accidentally make a mistake in one change, we can use Git tools to revert just that change without having to detangle two of them.
That doesn't mean you need to do everything separately, though. It's possible for one change to touch many files and still be a single change. One example would be renaming an assembly language symbol-- something like that should definitely be done in every file that uses it, so that there's no window during which the build process is broken.
Here are some general coding guidelines for the project.
Having a comment on each line of assembly may seem excessive, but doing so keeps the meaning behind flow of the code intact and gives the reader a clear understanding of what is happening.
Take time to write clearly about what a line of code is doing. Avoid repeating the obvious.
Instead of this:
clra clear A
do this:
clra set the path to standard input
Comments may or may not be complete sentences; as such, dispense with the formalism of capitalization and punctuation.
Instead of this:
ldb #E$PNNF Prepare the "pathname not found" error.
do this:
ldb #E$PNNF prepare the "pathname not found" error
Avoid abbreviations. Spelling out words increases the readability of the comments.
Instead of this:
pshs d,x,y,u push regs
leax ,u load path desc ptr in X
do this:
pshs d,x,y,u save the registers on the stack
leax ,u load the path descriptor pointer in X
Adding an empty line to the end of a source file ensures that some programs that parse the input do not abandon any important information on the last line.
Instead of this:
rts
do this:
rts
