[jeberle]

That is very cool. I had a similar boot disk w/ DOS 3.x and TurboPascal. It made any PC I could walk up to a complete developer box.

Just to be clear, when you say "without the need for the GUI", more accurately that's "without a GUI" (w/o Presentation Manager). So you're using OS/2 in an 80x25 console screen, what would appear to be a very good DOS box.

[kev009]

OS/2 had an evolving marketing claim of "better DOS than DOS" and "better Windows than Windows" and they both were believable for a time. The Windows one collapsed quickly with Win95 and sprawling APIs (DirectX, IE, etc).

It exists in that interesting but obsolete interstitial space alongside BeOS of very well done single user OS.

[tengwar2]

You could write your own GUI rather than using a text screen. I had to do that as I was working under OS/2 1.0, which didn't have the Presentation Manager. it did mean providing your own character set (ripped from VGA on DOS in my case) and mouse handing.

Btw, I'd love to know where this idea about no assembler programs on OS/2 came from. There was no problem at all with using MASM, with CodeView to debug on a second screen.

[rbanffy]

> Btw, I'd love to know where this idea about no assembler programs on OS/2 came from.

It’s certainly a misunderstanding - nothing prevents someone from writing assembly. Could also be a lack of official documentation on how to make the API calls from assembly. Another possible source is that you can’t access the hardware directly in OS/2, which was more closely associated with low-level programming.

[tengwar2]

But you could access the hardware directly. I don't remember the details, but I build a hardware clock running at 10ms cycle time and was able to poll it. Also my build relied fundamentally on reading from a couple of external DAC converters which presented 2 x 10-12 bits for x and y coordinates to some sort of PIO arrangement which I don't now recall. I didn't write a device driver, which I remember as being significantly more difficult (mainly because you couldn't use CodeView).

Just as a brief explanation: this was in the late 80's. I was using a device called an imaging photon detector to detect individual photo events. This was the back end of an early electronic camera running at about ISO 1G. Not a digital camera - the photo events were recorded as analogue xy coordinates, with a resolution of about 400x400 and a photon rate of about 100k/s (not an exact figure - as the rate increased, you lost an increasing number of events due to clash. I had a load of wire-wrap to rearrange the bits before they were presented to the computer (bit-bashing on the 80386/33 wasn't fast enough), then the xy coordinated were presented to some sort of PIO. In some cases I wanted to take video, hence the hardware clock, since the nearest thing available on the PC only ran at something like 13.3Hz and was used for polling the mouse. There was no GUI available at the time, so I built my own.

I don't remember a huge amount of detail, and the source is on 5¼" floppy, but as I remember it none of this was difficult for a very amateur self-taught C/asm programmer. The only significant problem was working out that the OS/2 1.0 documentation of the mouse system lied (it didn't have the display capability claimed, and attempting to use it shut down mouse polling), and third party manuals just copied the lies without testing. That was easy enough to work out, and building a couple of threads to display the mouse cursor was easy.

[rbanffy]

This sounds amazing. How did you read data from the DACs?

[tengwar2]

Unfortunately I don't remember. This was back in the late 80's, so getting on for 40 years back, and while I do have the source code, it's on 5¼" floppy. I just checked eBay, but the only USB floppy drives seem to be in the new-fangled 3½" size. I do remember that the clock that I made was on an ISA card, and presumably so were the DACs. I don't remember any difficulty in reading from them. It may be significant that I was only reading.

I think I'm going to see if I can find a service which will read the disk - it would be nice to have the code, though I remember there was a lot of stuff ♯defined out where I would have used SCCS once I had it available - hence it was a bit messy.

One little vexation was that although I had a vast 64MB hard disk, and a 1GB (bites tip of little finger) optical WORM drive, I had to reboot in to MS/DOS to use the WORM drive (no OS/2 drivers) and because one of the operating systems couldn't handle more than 32MB disk size, I had to partition the hard disk.

[ForOldHack]

CodeView? You *must" have been there.

[tengwar2]

Coming from a background of programming bank-switched Z80 code for memory-mapped displays with an 8080 assembler, 80386 code with a full-screen debugger was a dream.

[mikewarot]

Circa 1987, DOS boot disk had a "Backpack" hard disk driver on it, so I could plug it in the parallel printer port and boot up with 300 Megabytes of my stuff instantly available as D: on on any customer machine. It made service calls a lot easier to manage, no more stacks of floppy disks.

300 Megabytes!!!

I had all my source code on it, archives, utilities, compilers, the whole shebang!

[glhaynes]

Surely 30 MB in 1987, not 300, right?

[mikewarot]

Here's the PDF of the product line[1] with the price list from 1987.... 300 Megabytes was $789. I was the entire tech staff for Management Support Systems, and had written an inspection reporting system for fossil fuel generating systems in Turbo Pascal under MS-DOS that talked to Norand corporation portable computers with Symbol Technologies barcode scanners. The portables were rated for a 3 foot drop to concrete, and you could use them outdoors in winter, with gloves on... amazing stuff.

[1] http://www.bitsavers.org/pdf/microSolutions/MicroSolutions_P...

[glhaynes]

I stand corrected! Awesome, thanks for the link and the story.

[ForOldHack]

Ahem the minute I got my 286 ( free ) home, I added Mode con lines=50 to my Dos 3.3/Tp 3.02+8087 disk, everything worked perfectly until you actually tried to do some text addressing, but I was able to pass physics 1 and 2 and Pascal and the program design and styles class with As the machine served me well. Now if I had the $400 for the extra 4mb of ram, it would have run os/2 2.1 in text mode... Or not.

Oh the screen would go to snow often, and sidekick would bring it right back.

How well did OS/2 handle the text modes for VGA?

[JdeBP]

Very well, because OS/2 1.x introduced, for the first time in Microsoft's MS-DOS lineage, a fully-fledged VIO subsystem that abstracted TUI applications programming wholly away from touching the hardware. (GUI applications programming with VIO still required some low-level stuff. But TUI applications programming was entirely in terms of high-level console I/O with streams of characters and low-level console I/O with a 2-dimensional output buffer. There was no mixture of directly poking hardware and calling into the machine firmware.)

I regularly ran in 50-line VGA mode with zero problems. One could session-switch between full-screen OS/2 TUI programs (that were genuinely operating the hardware in VGA text mode, not simulating it with the hardware itself being used in graphics mode as became the norm with other operating systems much later and which OS/2 itself never got around to) and the Presentation Manager desktop.

I even had a handy LINES 50 command that wrapped the VIO mode change function, that I gave to the world as one of many utilities accompanying my 32-bit CMD, and which in 32-bit form was layered on top of a debugged clean room reimplementation of IBM's never-properly-shipped-outwith-the-Developers'-Toolkit 32-bit version of the VIO API.

You can still download it from Hobbes, today.

* https://hobbesarchive.com/?detail=/pub/os2/util/shell/32-bit...