Category Archives: NitrOS9

Spaces in path names still break stuff in 2025?

17 Replies

Updates:

  • 2025-02-27 – Corrected use of “hard links” to be “symbolic,” per William A. in the comments. Thanks!

NOTE: I am posting this as a plea for help. If you understand this problem, and know of solution, please leave a comment. I would really appreciate some input and clarification on my “understanding” of this issue.

TL:DNR: Symbolic links are a workaround.

The year is 2025, and open source projects can still be broken by having a space in a path name.

According to a robot, “Windows has allowed spaces in filenames and directory names since Windows NT 3.1, which was released in 1993.”

I have not fact checked this. My first PC was a Toshiba laptop I purchased at the end of 1995. (Not counting my DOS-based Tandy 1400LT I had years earlier.) At that point, it was Windows 3.1 that followed the 8.3 filename format that CP/M used.

FILENAME.TXT

It was the late Steve Bjork that convinced me to upgrade to the new Windows 95 when it came out. This upgrade allowed filenames up to 255 characters, if my quick web search is correct. I recall having a DOS C compiler (“Power C” – wow, they still sell this???) and it did not support the long filenames. Windows did provide some level of backwards compatibility by having any long filename still represented by a short name, which would have the first part of the filename then a “~1”, so something like “really long filename.txt” might also exist as “REALLY~1.TXT”.

Side note: There was a quirk with this implementation. Even filenames that could have fit in the 8 characters seemed to get this “~1” added to them. BUT, you could rename those to the normal 8 characters and is till worked. i.e. “filename.txt” would create “FILENA~1.TXT” but you could then “RENAME FILENA~1.TXT FILENAME.TXT” and it would show up as FILENAME.TXT. I actually wrote a C program that would go through the directory and rename any files like this. Fun times. And yikes, that was 30 years ago!?!?!

So basically, for three decades we could have spaces in filenames and directories on Windows.

Unix, back when it started, had short filenames and did not allow spaces initially. But, as long as I have been using it (my first exposure was 1995 on SunOS) I believe it did.

In the late 1980s I began using Microware’s OS-9 for the 6809 (on a Radio Shack Color Computer 3). While it had longer filenames than DOS (28 characters?), it did not allow spaces in filenames or directory names. I am unsure if the modern OS-9000 (renamed to just “OS-9 for x86” or whatever architecture, waybackwhen) has ever updated to allow spaces.

But I digress.

I still run across open source projects that fail if they are built from a path that has a space anywhere in it. For example, if you have this:

/usr/allenh/github downloads/

…and you “git” your project there, the build might break because of that space. Scripts may just see it as “/usr/allenh/github” and fail. This seems to be the case for the NitrOS9 Project, a fantastic effort to recreate OS-9/6809 with tons of enhancements.

From my experience, I think these problems can be solved by simply adding quotes around paths in the build scripts. For example, if you have this:

DISCLAIMER: Just examples. I know about escaping spaces as “\ ” in *nix filesystems, and maybe something like that exists for Windows (let me know in the comment).

SOURCE_PATH=C:\Users\Allen Huffman\Development\Source Code

somecommand -xyz $(SOURCE_PATH$)

…that will fail because it ends up looking like three parameters after the options:

somecommand -xyz [C:\Users\Allen] [Huffman\Development\Source] [Code]

But if the build script “quotes” the file path, like this:

somecommand -xyz "$(SOURCE_PATH$)"

…then that gets passed to the command the same way:

somecommand -xyz "C:\Users\Allen Huffman\Development\Source Code"

And that seems to work.

But, again, this is 2025. I run into projects that fail with spaces in the path multiple times a year.

Just don’t put spaces, duh.

“Hey doctor, it hurts when I do this.”

“Then don’t do that.”

Why not just remove the spaces? In olden days, you were in control of directories because you made them. I came from a “no spaces allowed” OS background so I never used spaces. “SOURCECODE” or, if underscore was allowed, maybe “SOURCE_CODE” to be more readable (but I hate typing two extra keypresses to generate that underscore).

But, Windows may not agree. Once I did a fresh Windows install, and let it do all the defaults (Microsoft account to login, enable OneDrive, etc.) and the path it created had a space in it. Anything that I put in “my” home folder (Documents, etc.) had a space somewhere earlier in the path.

Likewise, on macOS, if you use iCloud, some default directories get links that make them look “normal”:

allenh@Mac Documents % pwd
/Users/allenh/Documents

…but if you decide to make your own directory on your “iCloud Drive”, you see the true long path — which has a space in it!

allenh@Mac Development % pwd
/Users/allenh/Library/Mobile Documents/com~apple~CloudDocs/Others/Development

That “Mobile Documents” path is the cause of so many problems.

My workaround was to simply move these folders outside of my self-created directory and put them into one of the defaults, like “~/Documents/Development”.

Symbolic links, anyone?

On macOS (a Unix-type operating system), and Linux (if such a problem exists there?), you can create symbolic-links to folders. You create a new name and then tell it where it points to.

ln -s /Users/allenh/Library/Mobile\ Documents/com\~apple\~CloudDocs/Others/Development ~/Development-iCloud

Now in my home folder, I have a directory called “Development-iCloud” that has no space in it, but points to the real spot with a space:

allenh@Mac ~ % cd Development-iCloud 
allenh@Mac Development-iCloud % pwd
/Users/allenh/Development-iCloud

Now I can change into that folder and build scripts that were failing will work. Nice.

But what about Windows?

I have not tried it myself, mostly because I didn’t have A.I. to ask for a solution the last time I ran into this on Windows, but there is a “mklink.exe” command that appears similar, and may solve the problem there:

mklink /D "C:\path\to\link" "D:\path\to\actual"

It feels like this workaround should work there.

But is this what developers do? Most smart computer folks I know run away from anything cloud (and for good reason). I have been drinking the Kool-Aid for awhile and love having access to non-private files on all my devices, via syncing on Dropbox (mostly) or iCloud or OneDrive or Google Drive. I use all of them, for different purposes.

This is my workaround, but is there a better way?

Let me know in the comments.

Until then, stay off my lawn.

Recreating the Pac-Man maze in 1993

2 Replies

Many years ago, I played with drawing a 3-D maze under OS-9 on my Radio Shack CoCo 3. That demo is on the NitrOS-9 “Ease of Use” release under the name “semaze“. It lets you wander around a simple line maze:

There is even a map you can bring up with “?”:

As I mentioned years ago on this site, I had played with turning that into an OS-9 version of the classic Phantom Slayer 3-D game on the CoCo 1. I got as far as having my maze with a “phantom” in it that would wander around:

An unfinished CoCo 3 OS-9 3-D maze game inspired by the old “Phantom Slayer” by MED SYSTEMS.

But the oddest version was probably me putting the Pac-Man maze into my 3-D “engine” and then deciding to put dots around it, and make it refresh every half second or so, making it a “real time” game. With a prototype ghost (which appeared just as a large circle) wandering around!

And bringing up the map showed the Pac-Man maze:

In the days before the Internet, the only way I would have been able to recreate this map is if I had access to an accurate home port (I did not), or a picture in a magazine (maybe). I am guessing I based it on some CoCo Pac-Man clone with a fairly accurate maze.

How well did I do? Here is my CoCo version, then the actual arcade game, and the Arduino TV-Out version I was working on a decade ago (very accurate, down to the tiles).

Pac-Man arcade screen
Pac-Man
Arduino Pac-Man!

I can see a few errors, like the bottom walls under the power pellets going into the maze an extra tile. And the dots are off. Today, I understand how the Pac-Man maze is laid out with tiles so it would be much easier to recreate my 3-D “DotMaze” game with an accurate map.

Maybe I will.

Sub-Etha graphical adventures?

Leave a reply

Around 93-94, I created a text adventure that featured black and white digitized pictures from the 1992 Atlanta CoCoFest. It was more of a “simulation” than a game — and even called itself a simulation on the splash screen. But, while browsing through the source code, I found there were quite a number of things you could “do” in the game, while the score let you know how much of it you completed.

I also found one from a Chicago CoCoFest, which seems to be complete other than missing the images. Rooms were numbers with the vendor name and description. It was kind of like “playing” one of my old CoCoFest reports. Trippy.

And a weird 3-D first-person Pac-Man game I was working on…

Now that I have Xroar running the current Ease of Use NitrOS-9 build, and have my CoCoSDC “real CoCo” hard drive image mounted as the second drive, I may finally be able to dig through all this stuff and see what else I have.

Like finding I made a Towel V1.05” — after I moved to Iowa! I have no recollection of that. Lots of stuff to get archived and posted online.

Should be fun.

My old Space Invaders game running on an arcade cabinet!

2 Replies

A few years back, Color Computer community member Rietveld Rietveld took an Arcade1Up Rampage cabinet and converted it so I could run other software — such as emulators. Images have been shown of it running the Color Computer emulator and software.

Now, with the official 1.0 release of the NitrOS9 “Ease of Use”, that has been installed on this arcade machine and, by request, my OS-9 game Invaders09 has been ran on it.

I never imagined that my “arcade” game would eventually be running on a (sorta) arcade machine. Thanks, Rietveld!

I found hidden stuff in my own game.

2 Replies

On August 21, 1994 I began writing a space invaders game for the Radio Shack TRS-80 Color Computer. The game was written in 6809 assembly language, and ran under the Microware OS-9 operating sytem as opposed to the ROM-based Disk Extended Color BASIC.

It did not initially start out as an OS-9 game. It started out as a NitrOS9 game. NitrOS9 was (and still is) a greatly optimized and enhanced version of the stock OS-9 for the Color Computer. It was initially a set of patches that took advantage of the hidden features of the Hitatchi 6309 chip. Many of us did CPU swaps in our CoCo 3s specifically to be able to run this faster version of OS-9. Years later, NitrOS-9 was backported to run on a stock 6809 and the project continues today with the Ease of Use edition where it comes ready to run and bundled with all kinds of utilities, applications, and games. (I think my game is even on there.)

http://www.lcurtisboyle.com/nitros9/nitros9.html

But I digress.

The reason I chose to write a game was after learning about a new system call that NitrOS9 added. It allowed mapping in graphics screen memory so a program could directly access it — just like from BASIC. With that in mind, I wrote a simple demo that had a peace-sign space ship that could move left and right and fire (multishots!), as well as a scrolling star background.

I believe my game demo source might have been published in The International OS-9 Underground magazine at some point.

As soon as I figure out how to make WordPress allow uploading a .asm source file, I’ll share it here.

But I digress. Again.

Invaders09 Secrets

Version 1.00 was completed on September 24, 1994. It was first sold at the 1994 Atlanta CoCoFest. I don’t remember how many copies the game sold over its lifetime, but I do know it was not enough to retire on. :)

On December 26, 1994, version 1.01 was released. This contained code by Robert Gault that allowed the game to work on machines with more than 512K memory. (Robert was also responsible for code that allowed the game to work on stock OS-9, as well.)

A big update happened on January 29, 1995, when the game was upgraded from a 4-color screen to glorious 16 colors.

1.03 was completed on February 4, 1995 and included bug fixes.

Almost twenty years later, to the day, I did a 1.04 update. The title screen text removed my old P.O. Box from Texas, and replaced it with an e-mail address. I also added the “secret” command line option to the help screen, so it would no longer be secret. There had also been a bug that caused the fonts to sometimes fail to load, which I found and fixed. There were also some bad bits in the graphics I had never noticed (but could see clearly on a modern monitor) which were corrected.

Something old. Something new?

I pulled up this source code today and was looking at it to see what all I’d have to do to convert it to run under Disk Extended Color BASIC. I’d have to learn about keyboard and joystick reading in assembly, as well as how to map in graphics screens. I’d also have to take care of the blips and boops, and create my own graphical text engine for displaying game and title screen messages.

I don’t know how to do any of that, yet.

But I did discover something I have no recollection of… The game contains its own font data, which it loads when the game first runs. (Note to self: Better check and make sure the game cleans that font up and deallocates it when the game exits.)

The font data is a series of fcb byte entries like these:

* 91 [
 fcb 126, 64, 64, 96, 96, 96, 126, 0
* 92 \
 fcb 64,64,32,24,12,6,6,0
* 93 ]
 fcb 126, 2, 2, 6, 6, 6, 126, 0
* 94 up arrow
 fcb 24,52,98,0,0,0,0,0
* 95 _
 fcb 0, 0, 0, 0, 0, 0, 0, 255
* 96 `
 fcb 96, 48, 0, 0, 0, 0, 0, 0
* 97 a
 fcb 0, 0, 62, 2, 126, 98, 126, 0

The fonts are 8×8 pixels in size, so each entry has 8 bytes to represent the character.

At the top of the font data was a comment that caught my attention:

* hidden stuff in the font! :)

Hidden stuff? What did I hide? It appears there was repeating data in the first 32 font characters before the SPACE at 32:

font
 fcb $05,$00,$08,$00,$08,$04,$00 <- GPBufLoad Stuff
 fcb 0,87,81,119,20,23,0,0  * hidden stuff in the font! :)
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
 fcb 0,87,81,119,20,23,0,0
* 32 (space)
 fcb 0, 0, 0, 0, 0, 0, 0, 0

I was curious what that was, so I searched to see if I could find an only bitmap font editor. Sure enough, someone has one for doing Commodore fonts:

https://petscii.krissz.hu/

I went there, and was able to recreate this “hidden stuff” in the font:

https://petscii.krissz.hu/

I had hidden a teeny tiny “42” in the font character set… Something no one would ever see, and that I had forgotten about.

Sub-Etha Software had other hidden 42s in other programs we distributed. I bet I’ve forgotten about some of them, as well…

But wait, there’s more … BASIC!

I took the code I wrote to display VIC-20 font data on a CoCo and updated it a bit, with this font data.

Invaders09 font data displayed on PMODE 0 under Extended Color BASIC.

You can adjust the WD variable in line 10 based on what PMODE you want to see it in. Change that to 32 and PMODE 4 and you get it in the size it would be on a CoCo 32-column screen. Use 16 and that will work with PMODE 0 or PMODE 2. (PMODE 1 and 3 are color modes and just look weird since they take the 8 bits and turn them in to four 2-bit color pixels).

Enjoy…

0 REM INVADERS09 CHARSET
10 WD=16 '16=PMODE 0/2, 32=4
20 PMODE 0,1:PCLS:SCREEN 1,1
30 L=1536+2048:C=0
40 FOR R=0 TO 7:READ D:IF D=-1 THEN 999
50 POKE L+(WD*R),D:NEXT
60 L=L+1:C=C+1:IF C>=WD THEN C=0:L=L+(WD*8)
70 GOTO 40
999 GOTO 999
1000 ' hidden stuff in the font! :)
1010 DATA 0,87,81,119,20,23,0,0
1020 DATA 0,87,81,119,20,23,0,0
1030 DATA 0,87,81,119,20,23,0,0
1040 DATA 0,87,81,119,20,23,0,0
1050 DATA 0,87,81,119,20,23,0,0
1060 DATA 0,87,81,119,20,23,0,0
1070 DATA 0,87,81,119,20,23,0,0
1080 DATA 0,87,81,119,20,23,0,0
1090 DATA 0,87,81,119,20,23,0,0
1100 DATA 0,87,81,119,20,23,0,0
1110 DATA 0,87,81,119,20,23,0,0
1120 DATA 0,87,81,119,20,23,0,0
1130 DATA 0,87,81,119,20,23,0,0
1140 DATA 0,87,81,119,20,23,0,0
1150 DATA 0,87,81,119,20,23,0,0
1160 DATA 0,87,81,119,20,23,0,0
1170 DATA 0,87,81,119,20,23,0,0
1180 DATA 0,87,81,119,20,23,0,0
1190 DATA 0,87,81,119,20,23,0,0
1200 DATA 0,87,81,119,20,23,0,0
1210 DATA 0,87,81,119,20,23,0,0
1220 DATA 0,87,81,119,20,23,0,0
1230 DATA 0,87,81,119,20,23,0,0
1240 DATA 0,87,81,119,20,23,0,0
1250 DATA 0,87,81,119,20,23,0,0
1260 DATA 0,87,81,119,20,23,0,0
1270 DATA 0,87,81,119,20,23,0,0
1280 DATA 0,87,81,119,20,23,0,0
1290 DATA 0,87,81,119,20,23,0,0
1300 DATA 0,87,81,119,20,23,0,0
1310 DATA 0,87,81,119,20,23,0,0
1320 DATA 0,87,81,119,20,23,0,0
1330 ' 32 (space)
1340 DATA 0, 0, 0, 0, 0, 0, 0, 0
1350 DATA 16, 16, 24, 24, 24, 0, 24, 0
1360 DATA 102, 102, 204, 0, 0, 0, 0, 0
1370 DATA 68, 68, 255, 68, 255, 102, 102, 0
1380 DATA 24, 126, 64, 126, 6, 126, 24, 0
1390 DATA 98, 68, 8, 16, 49, 99, 0, 0
1400 DATA 62, 32, 34, 127, 98, 98, 126, 0
1410 DATA 56, 56, 24, 48, 0, 0, 0, 0
1420 DATA 12, 24, 48, 48, 56, 28, 12, 0
1430 DATA 48, 56, 28, 12, 12, 24, 48, 0
1440 DATA 0, 24, 36, 90, 36, 24, 0, 0
1450 DATA 0, 24, 24, 124, 16, 16, 0, 0
1460 DATA 0, 0, 0, 0, 0, 48, 48, 96
1470 DATA 0, 0, 0, 126, 0, 0, 0, 0
1480 DATA 0, 0, 0, 0, 0, 48, 48, 0
1490 ' 47 /
1500 DATA 2, 2, 4, 24, 48, 96, 96, 0
1510 DATA 126, 66, 66, 70, 70, 70, 126, 0
1520 DATA 8, 8, 8, 24, 24, 24, 24, 0
1530 DATA 126, 66, 2, 126, 96, 98, 126, 0
1540 DATA 124, 68, 4, 62, 6, 70, 126, 0
1550 DATA 124, 68, 68, 68, 126, 12, 12, 0
1560 DATA 126, 64, 64, 126, 6, 70, 126, 0
1570 DATA 126, 66, 64, 126, 70, 70, 126, 0
1580 DATA 62, 2, 2, 6, 6, 6, 6, 0
1590 DATA 60, 36, 36, 126, 70, 70, 126, 0
1600 DATA 126, 66, 66, 126, 6, 6, 6, 0
1610 DATA 0, 24, 24, 0, 24, 24, 0, 0
1620 DATA 0, 24, 24, 0, 24, 24, 48, 0
1630 DATA 6, 12, 24, 48, 28, 14, 7, 0
1640 DATA 0, 0, 126, 0, 126, 0, 0, 0
1650 DATA 112, 56, 28, 6, 12, 24, 48, 0
1660 DATA 126, 6, 6, 126, 96, 0, 96, 0
1670 ' 64
1680 DATA 60, 66, 74, 78, 76, 64, 62, 0
1690 DATA 60, 36, 36, 126, 98, 98, 98, 0
1700 DATA 124, 68, 68, 126, 98, 98, 126, 0
1710 DATA 126, 66, 64, 96, 96, 98, 126, 0
1720 DATA 124, 66, 66, 98, 98, 98, 124, 0
1730 DATA 126, 64, 64, 124, 96, 96, 126, 0
1740 DATA 126, 64, 64, 124, 96, 96, 96, 0
1750 DATA 126, 66, 64, 102, 98, 98, 126, 0
1760 DATA 66, 66, 66, 126, 98, 98, 98, 0
1770 DATA 16, 16, 16, 24, 24, 24, 24, 0
1780 DATA 4, 4, 4, 6, 6, 70, 126, 0
1790 DATA 68, 68, 68, 126, 98, 98, 98, 0
1800 DATA 64, 64, 64, 96, 96, 96, 124, 0
1810 DATA 127, 73, 73, 109, 109, 109, 109, 0
1820 DATA 126, 66, 66, 98, 98, 98, 98, 0
1830 DATA 126, 66, 66, 98, 98, 98, 126, 0
1840 DATA 126, 66, 66, 126, 96, 96, 96, 0
1850 DATA 126, 66, 66, 66, 66, 78, 126, 0
1860 DATA 124, 68, 68, 126, 98, 98, 98, 0
1870 DATA 126, 66, 64, 126, 6, 70, 126, 0
1880 DATA 126, 16, 16, 24, 24, 24, 24, 0
1890 DATA 66, 66, 66, 98, 98, 98, 126, 0
1900 DATA 98, 98, 98, 102, 36, 36, 60, 0
1910 DATA 74, 74, 74, 106, 106, 106, 126, 0
1920 DATA 66, 66, 66, 60, 98, 98, 98, 0
1930 DATA 66, 66, 66, 126, 24, 24, 24, 0
1940 DATA 126, 66, 6, 24, 96, 98, 126, 0
1950 ' 91 [
1960 DATA 126, 64, 64, 96, 96, 96, 126, 0
1970 ' 92 \
1980 DATA 64,64,32,24,12,6,6,0
1990 ' 93 ]
2000 DATA 126, 2, 2, 6, 6, 6, 126, 0
2010 ' 94 up arrow
2020 DATA 24,52,98,0,0,0,0,0
2030 ' 95 _
2040 DATA 0, 0, 0, 0, 0, 0, 0, 255
2050 ' 96 `
2060 DATA 96, 48, 0, 0, 0, 0, 0, 0
2070 ' 97 a
2080 DATA 0, 0, 62, 2, 126, 98, 126, 0
2090 DATA 64, 64, 126, 70, 70, 70, 126, 0
2100 DATA 0, 0, 126, 66, 96, 98, 126, 0
2110 DATA 2, 2, 126, 66, 70, 70, 126, 0
2120 DATA 0, 0, 124, 68, 124, 98, 126, 0
2130 DATA 62, 34, 32, 120, 48, 48, 48, 0
2140 DATA 0, 0, 126, 66, 98, 126, 2, 62
2150 DATA 64, 64, 126, 66, 98, 98, 98, 0
2160 DATA 16, 0, 16, 16, 24, 24, 24, 0
2170 DATA 0, 2, 0, 2, 2, 2, 98, 126
2180 DATA 96, 96, 100, 68, 126, 70, 70, 0
2190 DATA 16, 16, 16, 16, 24, 24, 24, 0
2200 DATA 0, 0, 98, 126, 74, 106, 106, 0
2210 DATA 0, 0, 126, 66, 98, 98, 98, 0
2220 DATA 0, 0, 126, 66, 98, 98, 126, 0
2230 DATA 0, 0, 126, 66, 66, 126, 96, 96
2240 DATA 0, 0, 126, 66, 78, 126, 2, 2
2250 DATA 0, 0, 124, 96, 96, 96, 96, 0
2260 DATA 0, 0, 126, 64, 126, 6, 126, 0
2270 DATA 16, 16, 126, 16, 24, 24, 24, 0
2280 DATA 0, 0, 66, 66, 98, 98, 126, 0
2290 DATA 0, 0, 98, 98, 98, 36, 24, 0
2300 DATA 0, 0, 66, 74, 106, 126, 36, 0
2310 DATA 0, 0, 98, 126, 24, 126, 98, 0
2320 DATA 0, 0, 98, 98, 98, 36, 24, 112
2330 DATA 0, 0, 126, 108, 24, 50, 126, 0
2340 DATA 14, 24, 24, 112, 24, 24, 14, 0
2350 DATA 24, 24, 24, 0, 24, 24, 24, 0
2360 DATA 112, 24, 24, 14, 24, 24, 112, 0
2370 DATA 50, 126, 76, 0, 0, 0, 0, 0
2380 DATA 102, 51, 153, 204, 102, 51, 153, 204
2390 DATA 102, 51, 153, 204, 102, 51, 153, 204
2400 DATA -1

Until next time…

Building KenTon/LR-Tech SCSI drivers for NitrOS-9

Leave a reply

While the NitrOS-9 project does contain drivers for the KenTon and LR-Tech hard drive interfaces, they are not built or included by default. I wanted to document the steps I took to build and use the KenTon interface under the current NitrOS-9.

Basically, you will be modifying a few makefiles to enable the building of the low level booter, device drivers and device descriptors. If I recall, the changes are the same for each of these makefiles, but you only need to make them for the one you are using. If you are only using the KenTon drivers under NitrOS-9 Level 2 on a CoCo 3, just do that makefile.

  • nitros9/level1/coco1/modules/makefile
  • nitros9/level2/coco3/modules/makefile
  • nitros9/level3/coco3/modules/makefile

Step 1 – Add “KTLRFLAGS”.

These generate the define used inside the generic SCSI source code so it knows which code to build.

TC3FLAGS = $(AFLAGS) -DTC3=1 $(FLAGS)
KTLRFLAGS = $(AFLAGS) -DKTLR=1 $(FLAGS)
IDEFLAGS = $(AFLAGS) -DIDE=1 $(FLAGS)

Step 2 – Add “boot_ktlr” to the BOOTER list.

This makes it a dependency so make will look for it and try to build it. I added it in the middle of the list so when you get updates, it will be easier for the “diff” tool to see what has changed.

BOOTERS = boot_1773_6ms boot_1773_30ms \
 boot_burke boot_rampak boot_wd1002 boot_dw \
 boot_tc3 boot_ide boot_rom boot_dw_becker \
 boot_ktlr \
 boot_dw_arduino boot_dw_38400 boot_sdc

Step 3 – Add the modules to the RBF list.

RBF = rbf.mn \
 rbdw.dr dwio.sb dwio_38400.sb dwio_becker.sb dwio_arduino.sb \
 rb1773.dr rb1773_scii_ff74.dr rb1773_scii_ff58.dr \
 ddd0_35s.dd d0_35s.dd d1_35s.dd d2_35s.dd d3_35s.dd \
 ddd0_40d.dd d0_40d.dd d1_40d.dd d2_40d.dd \
 ddd0_80d.dd d0_80d.dd d1_80d.dd d2_80d.dd \
 ddx0.dd x0.dd x1.dd x2.dd x3.dd \
 rbsuper.dr lltc3.dr llide.dr llcocosdc.dr \
 llktlr.dr \
 dds0_ktlr.dd s0_ktlr.dd s1_ktlr.dd s2_ktlr.dd s3_ktlr.dd s4_ktlr.dd \
     s5_ktlr.dd s6_ktlr.dd sh_ktlr.dd \
 ddi0_ide.dd i0_ide.dd i1_ide.dd ih_ide.dd \
 dds0_tc3.dd s0_tc3.dd s1_tc3.dd s2_tc3.dd s3_tc3.dd s4_tc3.dd \
     s5_tc3.dd s6_tc3.dd sh_tc3.dd \
 ddsd0_cocosdc.dd sd0_cocosdc.dd sd1_cocosdc.dd

Step 4 – Add the dependency to build the driver:

# TC^3 SCSI Booter
boot_tc3: boot_scsi.asm
 $(AS) $(ASOUT)$@ $< $(TC3FLAGS)

# KenTon/LR-Tech SCSI Booter
boot_ktlr: boot_scsi.asm
 $(AS) $(ASOUT)$@ $< $(KTLRFLAGS)
 
# SuperIDE/Glenside IDE Booter
boot_ide: boot_ide.asm
 $(AS) $(ASOUT)$@ $< $(IDEFLAGS)

Step 5 – Add the dependencies for building each descriptor. I put mine after the existing TC3 SCSI driver stuff:

sh_tc3.dd: superdesc.asm
 $(AS) $(ASOUT)$@ $< $(TC3FLAGS) $(HDBDOS)

# KenTon/LR-Tech SCSI Descriptors
dds0_ktlr.dd: superdesc.asm
 $(AS) $(ASOUT)$@ $< $(KTLRFLAGS) $(ID0) -DDD=1

s0_ktlr.dd: superdesc.asm
 $(AS) $(ASOUT)$@ $< $(KTLRFLAGS) $(ID0) $(SCSI_HD)

s1_ktlr.dd: superdesc.asm
 $(AS) $(ASOUT)$@ $< $(KTLRFLAGS) $(ID1) $(SCSI_HD)

s2_ktlr.dd: superdesc.asm
 $(AS) $(ASOUT)$@ $< $(KTLRFLAGS) $(ID2) $(SCSI_HD)

s3_ktlr.dd: superdesc.asm
 $(AS) $(ASOUT)$@ $< $(KTLRFLAGS) $(ID3) $(SCSI_HD)

s4_ktlr.dd: superdesc.asm
 $(AS) $(ASOUT)$@ $< $(KTLRFLAGS) $(ID4) $(SCSI_HD)

s5_ktlr.dd: superdesc.asm
 $(AS) $(ASOUT)$@ $< $(KTLRFLAGS) $(ID5) $(SCSI_HD)

s6_ktlr.dd: superdesc.asm
 $(AS) $(ASOUT)$@ $< $(KTLRFLAGS) $(ID6) $(SCSI_HD)

sh_ktlr.dd: superdesc.asm
 $(AS) $(ASOUT)$@ $< $(KTLRFLAGS) $(HDBDOS)

# IDE Descriptors
ddi0_ide.dd: superdesc.asm
 $(AS) $(ASOUT)$@ $< $(IDEFLAGS) $(MASTER) -DDD=1

Now those modules should be built and made available for including in your bootfile. You could do this by editing the bootlist you are using:

  • nitros9/level1/coco1/bootlists/standard.bl
  • nitros9/level2/coco3/bootlists/standard.bl
  • nitros9/level3/coco3/bootlists/standardL3.bl

Or you could use a bootfile editor like ezgen to add them to your current bootfile. Or, if you were just doing something temporary (like I was, to pull data from hard drives), you could just merge the needed modules together and dynamically load them when you need to use the SCSI drive.

Hopefully this will be helpful to someone else.

Creating a RaspberryPi DriveWire server

4 Replies
  • 2016/05/12 – This is a work-in-progress article I originally wrote on February 8, 2015, but never completed. The other night I was trying to look up my notes to help Curtis B. with a NitrOS-9 boot disk and I realized I never completed this. I will try to finish it when I have a moment.

Summary

To get DriveWire 4 server running on a Raspberry Pi, you will do the following:

  1. Download the DriveWire server to the Pi and unzip it:
    wget http://sites.google.com/site/drivewire4/download/DriveWire4_4.3.3.zip
    unzip DriveWire4_4.3.3.zip
    cd DriveWire4_4.3.3.zip
  2. Edit the config.xml file to default to your serial port on your Pi in <deviceType> and <serialDevice>. (i.e., “serial” and “/dev/ttyUSB0“)
  3. Run the server with no user interface:
    java -jar DW4UI.jar -noui
  4. On the CoCo, load the needed DriveWire modules from NITROS9/6x08L2/MODULES/RBF:
    dwio.sb, rbdw.dr, x0.dd up to x3.dd
  5. Use the “dw” command to test things by creating a blank disk image:
    dw disk create 0 /home/pi/test.dsk
    format /x0
    dir /x0
  6. Customize your boot disk to include the modules you want and read the documentation to learn how to use all the cool virtual terminals, MIDI and other neat features.

And now, the long version…

Materials Needed

  1. Raspberry Pi B (or B+, or probably the Pi 2 B). I did all these steps on a B.
  2. USB keyboard (a mouse makes things easier, but I do not have one so all of these tips will just use a Pi, keyboard and HDMI TV/monitor).
  3. Compatible* 8GB SD card (or larger).
  4. Ethernet cable to hook the Pi to the Internet. (Required if you plan to do the network install of NOOBS LITE).
  5. WiFi (with a supported USB dongle) or Ethernet is needed later for downloading the DriveWire software and updates, but there are ways to do all of this without any Internet access if you start with the full NOOBs installer.
  6. Compatible* USB serial adapter (or TTL->RS232 converter for use with the built in UART pins of the Pi).
  7. …

Preparation on Windows/Mac/Linux

  1. Download the “NOOBS” installation for Raspberry Pi (currently 1.3.12). You can get the full NOOBS (780MB, just unzip and copy to the SD card and boot), or the NOOBS LITE (22.8MB) version.
    • NOOBS LITE can also be used. It is a much smaller download, but requires the Pi to be hooked up to the internet via Ethernet to download the rest of the OS files which is about 2355MB.
      http://www.raspberrypi.org/downloads/
  2. Unzip the files, then copy them over to a freshly formatted SD card.

Preparation on the Raspberry Pi

  1. Boot the Pi using this card. You will see a menu of operating systems you can install. Choose “Raspbian [RECOMMENDED]” at the top by using the arrow keys and SPACE to select. You may also wish to hit “l” for Language and set it to “English (US)” or your preference, and “9” for Keyboard and select yours. Once Raspbian is selected, press “I” for install. It will ask if you are sure you wish to overwrite the SD card. Select “Y” for yes.
    • NOOBS LITE: The Pi will then download the Raspbian image (2.3GB), then install.
    • NOOBS: The Pi will then install.
  2. The Pi will (eventually) reboot and after a bit, you get a DOS-like screen for the raspi-config utility. Arrow over to Finish and press ENTER. You will not be at the Pi shell prompt.
    pi@raspberrypi ~ $
  3. At this point, I like to do a full reboot to make sure everything is working properly:
    sudo reboot
  4. On a reboot, you won’t go directly to a shell prompt. You will get a login prompt. The default account is:
    username: pi
    password: rasbperry.
    Log in and you will get back to the shell prompt. You will be in the home directory for user “pi”.
  5. Now we need to download the DriveWire 4 software. Note the filename will change when DriveWire is updated, so check the official site if this does not work.
    wget http://sites.google.com/site/drivewire4/download/DriveWire4_4.3.3.zip
  6. After the zip file is download, you can extract it by typing:
    unzip DriveWire4_4.3.3.zip
  7. DriveWire 4 is set up to run with a nice GUI with mouse control. This requires a keyboard and mouse, and the Pi to be set up with X-Windows running. Since I do not have a mouse, and plan to run the Pi headless with nothing hooked up to it but power and the CoCo, this is not an option for me. Instead, I need to manually edit the configuration file to tell it what Linux serial port I will be using.
    cd DriveWire4_4.3.3
    copy config.xml config.xml.org (always keep a backup!)
    pico config.xml
    The editor will open, and you want to look for a few entries:<instance category=”instance” desc=”Autocreated 2013-03-24 23:57:53.831″ name=”TCP connection via TCP“>
    …
    <DeviceType category=”device” list=”serial,tcp-server,tcp-client,dummy” type=”list”>tcp-server</DeviceType>
    …
    <SerialDevice category=”device” type=”serialdev”>COM14</SerialDevice>The first entry is just the name of the connection. You could change that to “Serial Connection” or whatever. The second “tcp-“server” should be changed to “serial”, and the “COM14” entry should be changed to your serial port device. On my Pi, when I plug in a single USB RS232 adapter, it shows up as /dev/ttyUSB0 so that is what I use.
  8. Save your changes back to the file (Ctrl-X, Y) and now you are ready to run the server without a user interface. (Getting the user interface to run requires installed two more additional packages, and I will make a tutorial for that soon, if anyone wants me to.)
    java -jar DW4UI.jar -noui
  9. After a bit, Java will load and the DriveWire 4 server will start. Java is big, and the Pi is small, so it can be quite sluggish. Now, with the USB cable connected between the Pi and the CoCo, you can start testing.

Preparation on NitrOS-9

This tutorial is being written for someone who already has an active NitrOS-9 system and wants to add DriveWire support to it. If you have no customized

If you are using one of the default NitrOS-9 disk images for you system, it should have a NITROS9 directory, and inside of it will be various device drivers and descriptors, including the ones used by DriveWire. Ultimately, you would want to make a custom boot disk that includes these modules, but here is a simple way to merge them together and just load them when you want to use them. From OS-9:

  1. If you are running a stock CoCo 3 with the standard 6809 processor, go here:
    cd /dd/NITROS9/6809L2/MODULES
    …and if you have upgraded your CPU with a Hitachi 6309, go here:
    cd /dd/NITROS9/6309L2/MODULES
  2. The modules you want depend on what you plan to do. Here is the list:
    • drio.sb – this module handles all communication with the DriveWire server.
    • rbdw.dr – RBF device driver that uses DriveWire for disk access instead of disk hardware
      • ddx0.dd, x0.dd, x1.dd, x2.dd, x3.dd – device descriptors for the DriveWire disk drives (/x0 to /x3, with ddx0.dd being a /dd descriptor for DriveWire).
    • scdwp.dr – printer driver
      • p_scdwp.dd – device descriptor /p for scdwp.dr
    • scdwv.dr – virtual serial port driver
      • n_scdwv.dd, n1_scdwv.dd to n13_scdwv.dd – serial port descriptors. /n is the “next available” descriptor, similar to /w for windows. /n devices may also be used for MIDI.
      • midi_scdwv.dd – this is n14 but named /midi for MIDI programs that are hard coded to look for that name.
      • term_z_scdwv.dt, z1_scdwv.dd to z7_scdwv.dd – (??? not in the doc wiki)
  3. For my example, I am only concerned about the disk drives, so I would merge the following modules together:
    chd RBF
    merge dwio.sb rbdw.dr x0.dd x1.dd x2.dd x3.dd >/dd/dw
    This gives me a single file called “dw” I can load to get DW support instantly. First, I need to set the attributes to allow that:
    attr /dd/dw e
    …then I can just load it when I want to use DriveWire:
    load /dd/dw
  4. If this worked, you should now be able to use the DriveWire command, “dw”, to communicate with the server. Type “dw” and it should report back a list of commands:
    config  disk  log  midi  net  port  server
    …and you can then type “dw config” or “dw disk” to see what all it can do.

Using DriveWire

Here is an example of creating an empty disk image and formatting it:

dw create 0 /home/pi/test.dsk
format /x0
dir /x0

If you look on the Pi, you will see a new file “test.dsk” there. You can now use this disk like any other OS-9 disk. In my test, I copied my NITROS9 directory over to it just for fun:

chd /dd/NITROS9
dsave /x0 ! shell

DriveWire’s performance is not as good as you’d get from a No Halt floppy controller like the Disto Super Controller 2 or a hard drive interface like the Cloud-9 SuperIDE or KenTon SCSI. As disk activity is going on, interrupts are masked while data is blasted out of the bitbanger port. Still, it did a remarkable job keeping up with my typing. Quite impressive for a cheap cable and a $35 computer with a serial port.

TO DO

  1. Make the DriveWire 4 server auto-start.
  2. Update the DriveWire 4 software from the command line (is this even possible?).
  3. Update the Raspberry Pi software.

Problems

One issue I immediately ran in to was a bunch of ERROR #207 (Memory Full) errors. mfree still showed 352K free, and it wasn’t the #237 (RAM Full) that happens when there isn’t enough room left in the main 64K memory map.

Building NitrOS-9 on Mac OS X

1 Reply

Updates:

  • 6-22-2022 – I wrote up the steps on building LWTOOLS under Windows using Cygwin. I found it very simple. But, I was not able to get Toolshed building under Cygwin.
  • 12-7-2022 – A few updates about ‘hg’ on Mac.
  • 2-20-2025 – Updated location of NitrOS9 project, and changing instructions to use “git” instead of Mercurial for that step.

Since I have to relearn all the steps, I thought I would post them as I go through them. The NitrOS-9 website has a tutorial on building it, but here are my steps with some specifically for Mac OS X:

Install the Command Line Tools for Mac OS X.

We need the command line versions of the Mac OS X compiler so we can build the tools that are then used to build NitrOS-9. If you have XCODE installed, you may already have them. An easy way to do this is from a Terminal prompt: 

xcode-select --install

That will launch the Apple Mac App Store installer and get the tools for you. Cool.

Installing the Mac OS X command line tools.
Installing the Mac OS X command line tools.
Screenshot 2016-05-01 17.26.21

Download Mercurial.

The NitrOS-9 repository now uses git as version control. You will need to download a git client, or use the GitHub Desktop app. I just learned about this change today (Feb 2025) so I need to update these steps.

Toolshed and LWTools use Mercurial, so you will need to download that as well. On macOS, you should be able to install it using “brew install mercurial”:

brew install mercurial

Download LWTools.

These are the cross-compiler tools used to build 6809 source code from Mac/Windows/Linux systems. From a Terminal prompt, find a directory you want to download the lwtools to. I chose a poor location — “CoCo” inside my Downloads folder:

pwd
/Users/allenh/Downloads/CoCo

From this directory, use the “hg” command to obtain and build the tools. It will build the directory you specify from the command line (“lwtools”):

hg clone http://lwtools.projects.l-w.ca/hg/ lwtools
cd lwtools
make
sudo make install
cd ..

Build Toolshed.

Next we want to build Toolshed. This is a series of command-line utilities that operate on CoCo/OS-9 disk images (like those used with emulators and the CoCoSDC interface). Once again, I do these steps from my “Downloads/CoCo” directory:

hg clone http://hg.code.sf.net/p/toolshed/code toolshed
cd toolshed
sudo make -C build/unix install
cd ..

(Note: I had to use “sudo make…” here to get it to build on my system.) The different build/make process shows the different styles of the various developers that made these tools. (Note: Mine seems to fail looking for a command “markdown” at the very end. Not sure what this is, but it seems to be building HTML documentation or something.)

Build NitrOS-9.

Now we are ready to download and build NitrOS-9. Once again, I start in my “Downloads/CoCo” directory, and issue the following git commands to download all the NitrOS-9 stuff: 

git clone https://github.com/nitros9project/nitros9.git
cd nitros9
make dsk

This will build absolutely everything, including tons of ports and disk images you likely do not want. After this, you will have all the sources, and have built all (or some) of the sample disk images for various types of hardware (CoCo 1/2, CoCo 3, 6809 or 6309, CoCoSDC controller versus floppy or IDE hard drive, etc.).

If you are only interested in a CoCo 3 6809 setup, why build all the CoCo 1/2 and Dragon versions, or any of the 6309 stuff? I always build everything, but you can also specify to build just a specific port. For my CoCo 3/6309 build, I could do this instead:

make dsk PORTS=coco3_6309

For stock 6809 CoCo 3:

make dsk PORTS=coco3

Updating NitrOS-9 and the Tools.

Later, if you want to update your sources, you can use this command from the “nitros9” directory:

git pull
make ask

For updating LWTools and Toolshed, use this:

hg pull
hg update

…then the build steps, shown earlier.

NOTE: David Ladd has pointed out that you may want to clean out old files before rebuilding. For Toolshed, I needed to do this first:

hg pull
hg update
make -C build/unix clean
make -C build/unix

I do this occasionally to get the “latest and greatest.” You can do this for the other tools, too, by changing in to their directory then issuing the “pull” and “update”, then the appropriate make command.

TODO: This next section was from when NitrOS9 was at SourceForge and used Mercurial. I have not had a merge conflict using git yet, so I don’t know what those look like. I will try to update this document later.

If you get a merge conflict because you changed something locally, you might see this:

hg update
abort: outstanding merge conflicts

You can use this command to see what files have been changed on your local repository that conflict with the master files. This happens if, for instance, you tweak a makefile or build list or source code:

hg resolve -l
U 3rdparty/utils/tlindner/sdir.asm

This reminded me that I already Tim’s “sdir” source code (for CoCoSDC) so enable built in help and such. I have to revert those changes if I want to update, or learn how to use the merge too… I forgot!

These steps should get you everything you need to begin playing with NitrOS-9 on a real CoCo with the CoCoSDC interface, or an emulator. If you plan to use real floppies, you can use toolshed utilities to format and then copy disk image .DSK files over to the physical floppy, but I don’t have any way to hook a 360K Floppy drive to my Mac so I have never done this. CoCoSDC is the way to go there.

More to come…