Running MS-DOS in terminal mode

[Ruud Baltissen]

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. 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/pe...-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!

[muta...@gmail.com]

On Thursday, April 15, 2021 at 11:17:26 PM UTC+10, Ruud Baltissen wrote:

> The Commodore CBM 8000 series cannot run CP/M because
> they have a 6502 on board. So the Softbox,
> http://mikenaberezny.com/hardware/pe...-z80-computer/ ,

That link didn't survive. I'll try:

http://mikenaberezny.com/hardware/pet-cbm/sse-softbox-z80-computer/

> I think it is "just" changing INT 10h and INT16h using a driver
> loaded by CONFIG.SYS but I could be wrong.

I spent a lot of time trying to understand exactly what you
were doing. It is a very interesting technical problem.

So you want MSDOS + IBM PC changed in such a way
that they will accept a CBM keyboard as the new keyboard,
and accept a CBM floppy as the new floppy.

And you believe you have the hardware changes in place
already to do that, so just need MSDOS to drive the new
hardware.

Does it need to be exactly MSDOS?

I have an MSDOS semi-clone in public domain C90 source code,
both an 8086 version and an 80386 version. You can get it here:

http://pdos.sourceforge.net

Quite frankly, in my opinion PDOS should be designed with
such a purpose in mind. It shouldn't be wedded to the exact
keyboard, screen and floppy that an IBM PC provides.

However, I think that this is where a BIOS comes in. Rather
than changing MSDOS with a driver, shouldn't you be trying
to replace the BIOS?

I guess if the BIOS is unchangeable then intercepting the
BIOS calls would be the next best thing. Let me know if
you think PDOS should be fundamentally redesigned to
cater for this situation.

BFN. Paul.

[muta...@gmail.com]

On Friday, April 16, 2021 at 1:38:07 AM UTC+10, muta...@gmail.com wrote:

> However, I think that this is where a BIOS comes in. Rather
> than changing MSDOS with a driver, shouldn't you be trying
> to replace the BIOS?

Actually I don't see any choice but to provide your
own BIOS. If you wish for an IBM PC to boot MSDOS
which resides on a CBM floppy, the IBM PC needs
the knowledge of how to talk to a CBM floppy.

So it needs to be running some 8086/80386 code,
either from ROM or from its own hard/floppy disk.

And it is that code that is effectively a replacement
BIOS. And with your replacement BIOS in place, you
no longer need a driver loaded in config.sys by
MSDOS. What you actually need is to ensure that
the process of loading MSDOS from CBM floppy
does not interfere with your replacement BIOS
which may be loaded in memory instead of ROM.

So you really need a variable-BIOS-aware version
of MSDOS, that knows that it doesn't control the
entire memory, and can handle being relocated.

BFN. Paul.

[Grant Taylor]

On 4/15/21 7:17 AM, Ruud Baltissen wrote:
> 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. 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.

I thought that there were some ways built into MS-DOS to control it
through the one of the COM ports.

I know that there are ways that you can run ad-hock commands through the
COM port. One of the most common I remember seeing was the method to
get INTERLNK / INTERSVR onto a computer that didn't have the necessary
software. To whit, you could use a serial connection, null or dial up
modem, and run a command on the destination computer such that it would
receive commands from the serial port. Then the source computer would
push a tiny amount of data through the serial connection to transfer the
requisite program. Once the program was transferred, you could
establish a full INTERLNK / INTERSVR connection.

But the point being the source computer was controlling the target
computer, and DOS thereon via 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/pe...-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 don't know what it would take to use an IEEE488 bus. I suppose if you
could load a driver so that DOS would see the IEEE488 bus as a COM port,
it may work.

> 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.

I don't think that doing things over the COM port will be that difficult.

If you expand past the realm of what's included with MS-DOS and look at
things like PC-Anywhere and the myriad of alternatives, there's
definitely some options.

> So any info is very welcome. Thank you in advance!

I feel like this is definitely a solved problem.

The question is will any of the solutions work for you or not.



--
Grant. . . .
unix || die

[R.Wieser]

Grant,

> I know that there are ways that you can run ad-hock commands through the
> COM port. One of the most common I remember seeing was the method to get
> INTERLNK / INTERSVR onto a computer that didn't have the necessary

...

> But the point being the source computer was controlling the target
> computer, and DOS thereon via the COM port.

Alas, It didn't/doesn't (control DOS / the 'puter).

Instead of that it just relies on redirection.of output / input (to/from
file). Remember how you can do "dir > file.txt" ? Well, you can do the
same with all kinds of in/output handles. The above method you mentioned
was simply to redirect the output of the COM port to file (with a ".com"
extension), and than execute that file.

Mind you, that (received by COM) data has been rather specifically created
to be able to be piped into a file and than executed that way. Definitily
not "just" some executable (if you want to know more about it I suggest you
ask for it in "comp.lang.asm.x86").

Bottom line : controlling the 'puter using just the COM port is *not* build
into the OS. Even if you would be able to redirect the COM port as input
to / output from the commandline there are just too many programs that use
something else than plain (int 0x21) character reads-and-writes which will
break it.

Regards,
Rudy Wieser

[Grant Taylor]

On 4/20/21 12:56 AM, R.Wieser wrote:
> Alas, It didn't/doesn't (control DOS / the 'puter).

Okay. Thank you for the clarification. I didn't know the particulars
when I last used it about 25 years ago. I definitely didn't know them now.

> Bottom line : controlling the 'puter using just the COM port is *not*
> build into the OS. Even if you would be able to redirect the COM
> port as input to / output from the commandline there are just too
> many programs that use something else than plain (int 0x21) character
> reads-and-writes which will break it.

Another option might be a feature that some BIOS offer: console
redirection. Meaning that they somehow copy text contents of the VGA
console to the COM port. It's not part of DOS, but it might allow the
OP to achieve what they want; controlling a DOS PC via serial port.

[R.Wieser]

Grant,

> Another option might be a feature that some BIOS offer: console
> redirection.

While that might look as a perfect solution, it still runs into the already
described problem : only (very) well behaved programs would keep
functioning. Any program which, for example, uses direct screen writes
would cause problems (you would not see the output).

And don't even /think/ of switching to a graphical modus - and worse, using
direct screen writes there. :-)

In short: Although its rather possible to emulate a terminal (like a VT100)
on a PC, the other way around (using the PC as the "server") will be much
harder.

Regards,
Rudy Wieser

[Grant Taylor]

On 4/20/21 11:21 AM, R.Wieser wrote:
> While that might look as a perfect solution, it still runs into the
> already described problem : only (very) well behaved programs would
> keep functioning. Any program which, for example, uses direct screen
> writes would cause problems (you would not see the output).

I never said it was perfect. I said "another option /might/ be".

> And don't even/think/ of switching to a graphical modus - and worse,

> using direct screen writes there.:-)

They are decidedly only text mode.

> In short: Although its rather possible to emulate a terminal (like a
> VT100) on a PC, the other way around (using the PC as the "server")
> will be much harder.

"much harder" sure. But decidedly not impossible.

I have done a lot of crazy things with the BIOS based console
redirection. So, I'd suggest you not knock them until you try them.

This is possible because the VGA video card and the BIOS (firmware)
doing the redirection are integrated and designed with each other in
mind. Usually they are both integrated into the same motherboard. As
such, the text console redirection feature has the capability to read
the video memory that was directly written to.

So, probably not perfect. But probably also good enough for many uses.
You / the OP / I won't know until we actually try. }:-)

[R.Wieser]

Grant,

> I never said it was perfect. I said "another option /might/ be".

...

> So, probably not perfect. But probably also good enough for many uses.

You're right. As long as the OP just wants to run commandline stuff it
will likely work.

Regards,
Rudy Wieser

[Johann 'Myrkraverk' Oskarsson]

This is very much a solved problem. Look at TINY. It does what you
want, but over the network, instead of the COM port.

http://josh.com/tiny/

The server does not seem to be open source, so I can't exactly use
it as a reference, but the client is.

It probably scans the video RAM and sends as packets, either always,
or when it detects a change. You can do this too, if you really need
to.

Good luck,

--
Johann | email: invalid -> com | www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | twitter: @myrkraverk

[Ruud Baltissen]

Thank you all for your answers!

First a clarification: the idea was that the DOS computer wouldn't have neither a video card nor a keyboard. Having no video card means that reading the video memory won't work. But having no keyboard has a consequence I didn't realize: most 8088 motherboards, the target I have in my mind won't boot because they stop, mentioning having not found a keyboard and the user has to press the F1 key.

Because of your comments I also realized that loading programs over IEEE means that at least INT13h has to be changed as well. This DOS computer won't have drives of his own so I cannot load MS-DOS and then some drivers that adjust things later on. So another solution popped up: I write my own BIOS. So far I'm only familiar with writing BIOSes for 8088 machines but that shouldn't be a problem; the idea was to use an 8088 machine anyway. I will start small: take a complete machine and first replace the INT 10h routine just to see if DOS still will start up. Then I will replace the INT 16h routine to see if DOS can be fooled/persuaded to accepts input not coming from a real keyboard. Next I will try to persuade the computer to boot from the IEEE port. And if all works, I'll remove the video card. Last step is to port the results into the BIOS.

For those who are not familiar with the IEEE bus, please have a look at: http://baltissen.org/newhtm/cbmhd.htm
Here you find a way to turn a PC into an IEEE device using a LPT port, a COM port and two ICs. And as this PC won't be a device but a master, I think just a LPT port will do. And this page will also answer the possible question how to attach mass storage devices to the whole. And my idea is more or less outdated, there exists much much smaller devices using SD cards: just google for PetDisk and PetSD. But mine looks more original :)

Thanks again for your comments!

Kind regards, Ruud Baltissen

[Grant Taylor]

On 4/28/21 12:13 AM, Ruud Baltissen wrote:
> But having no keyboard has a consequence I didn't realize: most 8088
> motherboards, the target I have in my mind won't boot because they
> stop, mentioning having not found a keyboard and the user has to
> press the F1 key.

Were the BIOS settings to not halt on no-keyboard not a thing with 8088
motherboards? All of my experience with such was Pentium or newer, so I
have no idea when that feature was added.

[R.Wieser]

Ruud,

Just a heads-up :

> Having no video card means that reading the video memory won't
> work. But having no keyboard has a consequence I didn't realize:
> most 8088 motherboards, the target I have in my mind won't boot
> because they stop, mentioning having not found a keyboard and the
> user has to press the F1 key.

IIRC without a video card installed you most likely won't even get that far,
but instead will be getting the motherboards boot-error beeps song. :-)

> For those who are not familiar with the IEEE bus, please have a look at:
> http://baltissen.org/newhtm/cbmhd.htm

[quote]
You need a PC that has (at least) one bidirectional LPT port,
[/quote]

Again IIRC, those old 8088 motherboards you are targetting did not have a
bi-directional printer port. At least, not like the current motherboards
have. Instead they just had open-collector pins with pull-up resistors
(more-or-less the same to the data pins of a(n Atmel) microcontroller). You
might want to double-check if the IEEE-488 hardware you want to attach can
handle that.

That ofcourse also means that the software on that website won't work for
those printerports and needs to be rewritten ...

Regards,
Rudy Wieser

[Ruud Baltissen]

Hallo Rudy,

> IIRC without a video card installed you most likely won't even get that far,
> but instead will be getting the motherboards boot-error beeps song. :-)

That's why I write my own BIOS: I will eliminate that part.

> Again IIRC, those old 8088 motherboards you are targetting did not have a
> bi-directional printer port.

Not on board, indeed. But any of those older LPT cards can be converted to bidirectional by cutting one line and soldering two others. In fact I prefer those cards with a LPT and a COM port on board: by piggybacking a 7406 IC on one of the others I have everything to create a full operational IEEE card. This trick won't work with some integrated ICs like the UM82C11.

Is this solution 100% electrical compatible with IEEE? No, the in and outputs of the unpowered ICs can disturb the communication of other IEEE devices. That is why I always advice to disconnect the PC from the IEEE bus if not needed. When under power, I never had problems.

Kind regards, Ruud Baltissen

[Mateusz Viste]

2021-04-28 at 11:01 -0600, Grant Taylor wrote:
> Were the BIOS settings to not halt on no-keyboard not a thing with
> 8088 motherboards? All of my experience with such was Pentium or
> newer, so I have no idea when that feature was added.

This was a common setup option on 386/486/Pentium mainboards, but not
on earlier hardware. The configuration options within a 8086 BIOS were
extremely limited (when there was a BIOS user interface at all).

Mateusz

[R.Wieser]

Ruud,

>> IIRC without a video card installed you most likely won't even get
>> that far, but instead will be getting the motherboards boot-error beeps
>> song. :-)
>
> That's why I write my own BIOS: I will eliminate that part.

In that case the "no keyboard found" problem should be moot, as you can
eliminate it the same way. :-)

> But any of those older LPT cards can be converted to bidirectional by
> cutting one line and soldering two others.

Hmmm... I always understood that the old PC printer-ports where
bi-directional (no changes needed), just not in the same way as the modern
ones are.

But, you seem to have more experience with them than I have, so I'm going to
take your word for it.

Regards,
Rudy Wieser