• Please review our updated Terms and Rules here

Running MS-DOS in terminal mode, second try

Ruud

Veteran Member
Joined
Nov 30, 2009
Messages
1,369
Location
Heerlen, NL
I asked this first in the software part but thinking about it again, it will be fitting here much better.

CP/M can be run on a stand alone computer with its own video screen and keyboard or can be run on a computer which is accessed with a terminal. Like the Zeta from Sergey. So far I have seen running MS-DOS only on PCs and I was wondering what would have to be done to run it on a, for example IBM PC/XT, and accessing it over its COM port using a terminal. But I want to go a bit further and not using the COM port.

The Commodore CBM 8000 series cannot run CP/M because they have a 6502 on board. So the Softbox, http://mikenaberezny.com/hardware/pet-cbm/sse-softbox-z80-computer/ , was developed so the CBM could run CP/M in an indirect way. My idea is to use a Commodore PC, a XT or AT compatible, to enable the CBM to "run" MS-DOS. But, like the Softbox, over the IEEE488 bus. I have my own made IEEE488 interface so the hardware isn't the problem.

I think it is "just" changing INT 10h and INT16h using a driver loaded by CONFIG.SYS but I could be wrong. I have done some googling to avoid inventing the wheel twice but I think I used the wrong keywords: I got a lot of feedback but not what I wanted. What I'm looking for is the exact info of what needs to be changed/added or what ever. The source of a program that does this over the COM port would be welcome: I only have to change the part that handles the hardware.

So any info is very welcome. Thank you in advance!
 
I've had thoughts about this too, although it was from the stand point of a serial port only. There is the dos command ctty which redirects input and output to a com port and I've used it before, but to really be able to do this at least for text applications, you would need to have TSR/driver that scans the screen looking for differences in the last time it sent it and then sends it so it can be reconstructed on the other system. Something like a pcanywhere or carbon copy type of thing.
 
As has already been mentioned in both threads DOS comes with a command called CTTY which redirects the INT10h BIOS calls so programs that rely exclusively on them can work over a serial port. If your IEEE488 interface can fake being a serial port-like device then you can use that. But as has already been stated, this will probably only work for a minority of commercial DOS software, since much of it skips the BIOS interfaces and tickles the hardware directly, which is why people are mentioning programs like PC Anywhere.

Here is the code for a BIOS plugin that Google wrote years ago that redirects BIOS I/O to a serial port by hooking in via the same INT10h path that a VGA card does. If you're looking to try to write your own driver to load in CONFIG.SYS instead of running CTTY this will probably cover most of what you need, but, again, realistically you're probably going to run into a lot of problems with commercial software. Try hooking a terminal up to a PC and doing the CTTY thing to get an idea of what will work and what won't. I know that, say, really old versions of Wordstar are able to be configured to use the BIOS path so I won't say *nothing* will work, but you will hit substantial roadblocks if you don't also include in your driver something to, at the very least, snoop video RAM and look for updates. (As the aforementioned PC Anywhere does.)
 
When (long ago) we did an 8-bit ISA card to direct video output to a terminal, we essentially made a clone of an MDA card, sans video circuitry with a Z80A onboard that snooped the video buffer and sent updates over RS232. This was probably overkill--one could install a timer interrupt routine to do the snooping just as easily. Keeping the payload size down is important to getting any sort of speed.

You need this because of the large numbers of applications that write to the video buffer directly.

As mentioned, Carbon Copy and PCAnywhere pretty much do the same thing.
 
DOS 2's SKELIO.ASM has code the comments claim to be able to direct IO from an Altos to a H-19 serial terminal. Might be a starting point if the system in question differs too much from the IBM PC to accept the other solutions.
 
A big hello and thank you to all who responded!

About programs that skip the BIOS: I don't mind, There will be enough left that will work. Problem solved :)

About PCanywhere and CarbonCopy: this is indeed the idea but over IEEE488 (also known as GPIB).

The pointers to the sources codes are more than welcome! It gives me at least a start.

Thank you again!
 
I can test redirecting the video and the keyboard using the COM port. But I forgot one thing: the Softbox boots from the floppy disk drive that is attached to the IEEE488 bus. So if the redirection works out fine, I have to port it to IEEE. The next step then will be telling INT 13h to use the IEEE bus instead of the internal drives(s). Quite a challenge, I think :)
 
I have an AMPRO little board 186. It's a MS-DOS computer that is nothing like a PC.
They wrote a BIOS that provides the usual INT services but the console is serial and the disk is SCSI and WD1770
And the CPU is i80186, so nothing like a PC at all!
I disassembled the ROM some time ago. It's on Bitsavers.

joe
 
In fact, several early PCs used serial I/O--I recall a kit featured in Byte that did just that--used the ISA bus and 8088, but no direct video. My unobtanium Retro that I had a hand in development, the Durango Poppy, used an 80186 and 80286 (option) ran MSDOS and Xenix and used serial I/O for console work. I believe the SCP system had no direct video as standard equipment. Same for several Compupro systems.
 
Just throwing this out there - The Columbia Data Product 1600 (The first IBM PC hardware clone) can be set via dip switch to output all BIOS text I/O to a serial port so it can be run entirely headless. Works with even vanilla MS-DOS.

However, the use of something like Carbon Copy would allow applications that write text directly to the video (which many do), to run via serial.
 
A gross cheat would be to use a 386 or higher and either run a Unixoid OS that can run a DOSEMU-type vm86 virtual environment or one of the specific multi-user DOS OSes (PC-MOS?) that can do the work for you of handling the screen I/O. Back in the Linux Stone Age I played with running DOS programs on a VT-100-compatible serial terminal via DOSEMU and, well, it did mostly work. Keyboard handling was “fun” and of course there’s issues with mismatched character sets and terminal handling, but that’s certainly going to be an issue with a PET as the console anyway.
 
Hello Joe,

I have an AMPRO little board 186. It's a MS-DOS computer that is nothing like a PC.
They wrote a BIOS that provides the usual INT services but the console is serial and the disk is SCSI and WD1770
And the CPU is i80186, so nothing like a PC at all!
I disassembled the ROM some time ago. It's on Bitsavers.
Found it and thank you!
 
The Columbia Data Product 1600 (The first IBM PC hardware clone) can be set via dip switch to output all BIOS text I/O to a serial port so it can be run entirely headless. Works with even vanilla MS-DOS.
Do you own this machine and could you provide me with a ROM dump, please?
 
Absent ROM dumps, it would seem pretty straightforward to write a DOS TSR that hooks the INT 10h calls and translates them to INT 14h ones. You'll need to set the serial port to the desired data rate and word length, anyway. Said resident would be either a loadable driver or something called at autoexec.bat time. Should be only a few hundred bytes at most.
 
When (long ago) we did an 8-bit ISA card to direct video output to a terminal, we essentially made a clone of an MDA card, sans video circuitry with a Z80A onboard that snooped the video buffer and sent updates over RS232. This was probably overkill--one could install a timer interrupt routine to do the snooping just as easily. Keeping the payload size down is important to getting any sort of speed.

Out of curiosity, was that the PC Weasel 2000 or an earlier device? We had a couple of the PC Weasels kicking around the office at my dot-com startup back in the day.

(Of course these days many high-end servers have lights-off management processors that include the ability to virtualize the entire SVGA console, graphics and all, and let you connect to it across the network via VNC or whatever. You can often even do a full OS install by mapping a virtual CD-ROM drive to either a file or a physical drive on your client computer...)
 
Out of curiosity, was that the PC Weasel 2000 or an earlier device? We had a couple of the PC Weasels kicking around the office at my dot-com startup back in the day.

(Of course these days many high-end servers have lights-off management processors that include the ability to virtualize the entire SVGA console, graphics and all, and let you connect to it across the network via VNC or whatever. You can often even do a full OS install by mapping a virtual CD-ROM drive to either a file or a physical drive on your client computer...)

No--it was the Tripas Trilink board--this was about 1984-85, so predates the dot-com stuff by about a decade. Still have one of the boards and may (I'm not sure) have the firmware source. All the junk I hang onto for no good reason...
 
No--it was the Tripas Trilink board--this was about 1984-85, so predates the dot-com stuff by about a decade. Still have one of the boards and may (I'm not sure) have the firmware source. All the junk I hang onto for no good reason...

I was guessing it probably wasn’t after looking up a picture of the Weasel and seeing no Z80 and a Spartan FPGA on it... which is probably a masterpiece of overkill all things considered, but maybe they were thinking ahead to the PCI/VGA-emulating model that I don’t think ever materialized. (The weasel had the misfortune of showing up right around the time ISA slots were going the way of the dodo, as was MDA support.)
 
Absent ROM dumps, it would seem pretty straightforward to write a DOS TSR that hooks the INT 10h calls and translates them to INT 14h ones....
I always have been interested in BIOSes in the first place. The advantage of a BIOS doing the trick for you is that it also can work for other operating systems. The disadvantage is that it will work only for one type of a machine. The idea is to stick to an 8088 machine anyway just to stay a bit in the same time line as my Commodore CBMs.
 
Back
Top