Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.msdos.programmer > #3948 > unrolled thread

Running MS-DOS in terminal mode

Back to article view | Back to comp.os.msdos.programmer

Contents

  Running MS-DOS in terminal mode Ruud Baltissen <rbaltissen@gmail.com> - 2021-04-15 06:17 -0700
    Re: Running MS-DOS in terminal mode "muta...@gmail.com" <mutazilah@gmail.com> - 2021-04-15 08:38 -0700
      Re: Running MS-DOS in terminal mode "muta...@gmail.com" <mutazilah@gmail.com> - 2021-04-15 09:11 -0700
    Re: Running MS-DOS in terminal mode Grant Taylor <gtaylor@tnetconsulting.net> - 2021-04-19 19:29 -0600
      Re: Running MS-DOS in terminal mode "R.Wieser" <address@not.available> - 2021-04-20 08:56 +0200
        Re: Running MS-DOS in terminal mode Grant Taylor <gtaylor@tnetconsulting.net> - 2021-04-20 09:33 -0600
          Re: Running MS-DOS in terminal mode "R.Wieser" <address@not.available> - 2021-04-20 19:21 +0200
            Re: Running MS-DOS in terminal mode Grant Taylor <gtaylor@tnetconsulting.net> - 2021-04-20 13:43 -0600
              Re: Running MS-DOS in terminal mode "R.Wieser" <address@not.available> - 2021-04-20 22:48 +0200
    Re: Running MS-DOS in terminal mode Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2021-04-20 22:58 +0000
      Re: Running MS-DOS in terminal mode Ruud Baltissen <rbaltissen@gmail.com> - 2021-04-27 23:13 -0700
        Re: Running MS-DOS in terminal mode Grant Taylor <gtaylor@tnetconsulting.net> - 2021-04-28 11:01 -0600
          Re: Running MS-DOS in terminal mode Mateusz Viste <mateusz@xyz.invalid> - 2021-04-29 08:11 +0200
        Re: Running MS-DOS in terminal mode "R.Wieser" <address@not.available> - 2021-04-28 20:37 +0200
          Re: Running MS-DOS in terminal mode Ruud Baltissen <rbaltissen@gmail.com> - 2021-04-28 22:47 -0700
            Re: Running MS-DOS in terminal mode "R.Wieser" <address@not.available> - 2021-04-29 09:11 +0200

#3948 — Running MS-DOS in terminal mode

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!

[toc] | [next] | [standalone]

#3949

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.

[toc] | [prev] | [next] | [standalone]

#3950

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.

[toc] | [prev] | [next] | [standalone]

#3951

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

[toc] | [prev] | [next] | [standalone]

#3952

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

[toc] | [prev] | [next] | [standalone]

#3953

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.



-- 
Grant. . . .
unix || die

[toc] | [prev] | [next] | [standalone]

#3954

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

[toc] | [prev] | [next] | [standalone]

#3955

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.  }:-)



-- 
Grant. . . .
unix || die

[toc] | [prev] | [next] | [standalone]

#3956

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

[toc] | [prev] | [next] | [standalone]

#3957

On 15/04/2021 1:17 pm, 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.
> 
> 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!
> 

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

[toc] | [prev] | [next] | [standalone]

#3978

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

[toc] | [prev] | [next] | [standalone]

#3981

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.



-- 
Grant. . . .
unix || die

[toc] | [prev] | [next] | [standalone]

#3984

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

[toc] | [prev] | [next] | [standalone]

#3982

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

[toc] | [prev] | [next] | [standalone]

#3983

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

[toc] | [prev] | [next] | [standalone]

#3985

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.msdos.programmer

csiph-web