I guess it would have been nice in early 80s, when a common setup was CGA with a composite monitor - or even a TV set! - where 80-column text wasn't legible enough.
May also be useful for 40-column palmtops, like Atari Portfolio.

Can it work under DOS 1.x, perhaps?

Thanks for the comment! Yeah this is about as simple as an IDE with a full screen text editor can get. It was originally written for battery-operated/embedded systems using the Intel 80C196 microcontroller and a 40 column LCD display where remote instruments are programmed "in the field."

Dos 1.x compatible? I don't think so. I'm calling interrupts 16h / AH = 0 and AH = 1, int 10h /AH = 1, 2 and 3, int 29h, int 14h / AH = 0, 1, 3 and E3h, int 21h / AH = 3Ch, 3Dh, 3Eh, 3Fh, 40h, 41h and 56h. Most of these calls only work in 2.0+. I should've mentioned that.

Grzyb wrote on 2026-08-04, 02:23:

... Can it work under DOS 1.x, perhaps?

If you want to try it, have a look at DOSBOOT.ZIP (in downloads on my site)

It has .IMGs for about 25 different versions of DOS going back to 0.90 pre-release, 1.00 and up

You can boot them in most emulators (I use PcEM, VMware and DosBox)
stuff can be tricky to run in 1.x - 2.x up runs a lot of stuff!

Grzyb wrote on 2026-08-04, 02:23:

I guess it would have been nice in early 80s, when a common setup was CGA with a composite monitor - or even a TV set! - where 80-column text wasn't legible enough.
May also be useful for 40-column palmtops, like Atari Portfolio.

Can it work under DOS 1.x, perhaps?

Hi there! 😃👋

On a small green monitor ("data display"), for example, CGA over composite was crystal clear; even in 80 column mode.
I've used that setup most of time here. It's basically RGB level, just in mono.

Also, I think, many European PCs in PAL land didn't have the NTSC colour-burst circuit installed.
So their AV out for on-board CGA was monochrome all the time.

If the colour monitor was good (modern SCART TV or Commodore 1084),
then the 80 column mode worked as good as on a real monochrome monitor.

IBM PCs with IBM CGAs or higher-end CGA clone cards excluded, of course.
They were sold internationally and had NTSC outburst circuit left intact.

Edit: Never mind, missed the point. Sorry, I was a bit too chatty again! 😅

Awesome!

Thank you

rather than thinking "do i have a use case" i just like that its been done 😀 Love that it packs everything into a .com !

gerry wrote on 2026-08-05, 11:38:

rather than thinking "do i have a use case" i just like that its been done 😀 Love that it packs everything into a .com !

Appreciate it. It really is a very boring bare bones programming environment. It's portable, though, and easy to use. Moving it to a 68K CPU or the CoCo would take a few day's work each, more so for 8-bit CPUs. If we integrated a compact audio and 3D graphics engine under the assumption that it is still possible to produce ground-breaking games for these older systems, then we might just have something here.

Very interesting little demonstration, I like when things are made up nice and small (unlike modern development environments 😀 )

Not sure exactly how "small" this one actually is, as NINE.COM is obviously compressed, you can't see any amount of printable text in it (not even things it shows when it runs), and looking within NINE.ZIP, NINE.COM is reduced by less than 0.5% - typical for compressed executable as the decompressor has to be clear text.

Language looks a lot 'C' ish, but with (IMHO) fairly significant limitations. It looks to be a lot like my CFLEA simplified - a compiler to a byte code and not a native executable. This means programs can only run in the IDE, and since no external files are generated, you can't see how much code it's actually producing (but I'm assuming the virtual machine is fairly optimal for the compiled code) - It might be nice to include a stand alone executable only (no editor/compiler etc.) perhaps set up so you could simply appending the bytecode to it (easy to do with a .COM), making a directly executable version of the program!

I can't say I like the "forced" 40 columns, and the use of .TXT files which have to be "converted" to a fixed filename is just weird. (Perhaps "convert" is the byte code "compiler" and "NINE" is just an interpreter - it's not clear where/how-much actual compilation is taking place).

Choice of .COM is interesting given some of the limits which appear to be mostly memory based (Almost all the DOS stuff I've distributed over the years has been TINY model(.COM) because 64k is a huge amount of space for a typical DOS program. In a few cases I've gone to SMALL model to have more data space (for example MCP.EXE - Micro-C preprocessor which allows for a very large number of complex, parameterized etc. #definitions, and MCC.EXE - Micro-C compiler which allows for a large number of symbolic definitions)

Btw, just to be clear - I'm not trying to "rag" on you, It's a very cool little demonstration to show what can be done! I just have a bit of an exceptional interest in small compilers - much of my career was dedicated to producing and supporting a C compiler which was used on many different very small embedded processor architectures (and a pretty decent (IMHO) DOS edition - which I've written almost all of my DOS "stuff" with).

interesting and awesome, what kind of compiler does it work with?
guess the best ide that can run on an xt is probably the borland c++ 2.0, maybe even better with an ems expansion card.

DaveDDS wrote on Yesterday, 03:45:

Very interesting little demonstration, I like when things are made up nice and small (unlike modern development environments :-) […]
Show full quote

Very interesting little demonstration, I like when things are made up nice and small (unlike modern development environments 😀 )

Not sure exactly how "small" this one actually is, as NINE.COM is obviously compressed, you can't see any amount of printable text in it (not even things it shows when it runs), and looking within NINE.ZIP, NINE.COM is reduced by less than 0.5% - typical for compressed executable as the decompressor has to be clear text.

Language looks a lot 'C' ish, but with (IMHO) fairly significant limitations. It looks to be a lot like my CFLEA simplified - a compiler to a byte code and not a native executable. This means programs can only run in the IDE, and since no external files are generated, you can't see how much code it's actually producing (but I'm assuming the virtual machine is fairly optimal for the compiled code) - It might be nice to include a stand alone executable only (no editor/compiler etc.) perhaps set up so you could simply appending the bytecode to it (easy to do with a .COM), making a directly executable version of the program!

I can't say I like the "forced" 40 columns, and the use of .TXT files which have to be "converted" to a fixed filename is just weird. (Perhaps "convert" is the byte code "compiler" and "NINE" is just an interpreter - it's not clear where/how-much actual compilation is taking place).

Choice of .COM is interesting given some of the limits which appear to be mostly memory based (Almost all the DOS stuff I've distributed over the years has been TINY model(.COM) because 64k is a huge amount of space for a typical DOS program. In a few cases I've gone to SMALL model to have more data space (for example MCP.EXE - Micro-C preprocessor which allows for a very large number of complex, parameterized etc. #definitions, and MCC.EXE - Micro-C compiler which allows for a large number of symbolic definitions)

Btw, just to be clear - I'm not trying to "rag" on you, It's a very cool little demonstration to show what can be done! I just have a bit of an exceptional interest in small compilers - much of my career was dedicated to producing and supporting a C compiler which was used on many different very small embedded processor architectures (and a pretty decent (IMHO) DOS edition - which I've written almost all of my DOS "stuff" with).

Hi Dave.

Thank you for your reply! I never thought you were ragging on me. After I took a dive into your website I had a feeling you might be interested in something like this. Like to check out your CFLEA bytecode interpreter after I get done typing.

BTW you can compile source without running it. ^K T (test) will report sizes of code, data and free bytes (stack). As for the language, yes it's limiting and typeless. The language was designed for the average schmo with little experience in programming languages. Given how we both enjoy cramming as much code as possible into a single 64KB segment, I thought this would be a nifty exercise in keeping things simple while having the satisfaction in knowing that it serves as a rudimentary operating system running on battery-operated embedded systems. It's got everything ya need and nuthin' you don't.

There are a few tricks up its sleeve, like nested functions with anonymous functions and arrays, multidimensional jagged arrays. Its de-referencing scheme uses brackets only, with byte-alligned pointer bases plus indexes multiplied by two: byte_address + index * 2, so arr != i[arr]... a little weird but flexible given the 16-bit types.

The reason programs are converted is because the built-in text editor compresses / decompresses internally. The compression ratio becomes more obvious the larger a program gets. The editor is divided into 100-line "sections" where the compression occurs behind the scenes. I'm able to squeeze out ~30% more space doing it this way. Moving between sections is fluid but a little chunky on slower CPUs (fixed in 1.02).

40-column text mode, for me, seems to fit the mood of the whole project. I too was forced into this given all the existing constraints. Things just worked in an almost mathematically-perfect way, like an edit-buffer size that matched the compression-buffer, no array waste, byte code memory fitting temporary stuff exactly. Everything worked out. I love having 80 columns. Doing so would've ballooned me into the small memory model where feature creep would set in. I had to put my foot down.

Programs are compiled directly from memory, not from a file. Separating the compiler/editor from a runnable binary is another step top take. Definitely thought of doing that. Like you said the VM instructions cater to the language's style which is always nice and portable. It runs strait from the editor, or a user's editor via batch file calling "convert" and Nine's -r command line option (the only command line option).

I guess things just fell into place with this project that gave me a nice warm C64 vibe. The program was designed to operate on lo-res LCD's. I might as well keep with that tradition. The editor also has an upload/download feature which helps it break out into the world in a way.

Nine's true size is ~18,000 bytes give or take. That file is also compressed, obviously. A quick scan with DEBUG would reveal no error messages or any other readable text.

Thank you very much for the thoughtful review!

-Todd

noshutdown wrote on Yesterday, 07:11:

interesting and awesome, what kind of compiler does it work with?
guess the best ide that can run on an xt is probably the borland c++ 2.0, maybe even better with an ems expansion card.

Thank you! It's a text-editor and compiler in one program, and runs ok on an XT. The programming language is not very C-like, though.

Dave, your website looks similar to my code library. This is just great. You've got all the good stuff! Integer bignum with division, check. BASIC interpreter with string and dimension support? Yup. Monitor and OS for the 6809, my favorite CPU (because Robotron), is here too! Virtual machines and C compilers everywhere. You got a nice Yaesu 897 for sale (KJ6ZVT, expired). Your source code is clean and easy to read throughout. Very interesting stuff. The motorcycle story was a sad one with a happy ending. Thank you for sharing. Best wishes.