No, that's not possible. There's no DOS in NT4, so you can't have any DOS TSRs loaded. DOS is only provided as a VM inside NT. It's like asking how to do the same with Linux. You simply can't. You would need the code as a native NT driver.

It wouldn't be a DOS TSR, but rather a boot shim.
May work, difficult to do. You'd basically have to inject the code into the NT bootloader.
Would only work if it's not actually a TSR. Because you can't keep resident code under NT.

Is it actually a driver or does it just modify a flag in the BIOS data area or something like that? Adding small pieces of code to a boot sector doesn't take much work. You have to swap out an instruction or two somewhere with a CALL or JMP that goes to your new code (which must include the instructions that you removed to make room for the jump). Easiest way to make room for new code is to overwrite part of the error message string. Since the boot sector contains parameters specific to the disk/partition, you need an exact copy of it to modify (can't use the sector from another disk/partition). And rather than modifying it on the disk, and risk making it unbootable, it's nice to copy it to a file and then add an entry in the NT boot menu to use that file.

Does NT4 have a boot menu? I can't remember. I used the Win2000 NTLDR to boot NT4.

feipoa wrote:

IRio444 made a TSR program which adds PS/2 mouse support.

Is it even a 32-bit program, I suspect not, use Menu->File->Show Image to check.

I expect that IRio444 would need to write an NT4 kernel mode device driver, but without knowing what the TSR does I can't even guess how much work this would be.

After pondering I think https://docs.microsoft.com/en-gb/sysinternals … ve-applications may do what you need, but you still need to write a program that calls a boot start driver.

Yes, NT4 has a boot menu. I used to have an NT4/Win98SE dual-boot system, with NT4 providing the boot menu,
Perhaps you could create a boot sector that first enables the PS/2 mouse (as bakemono says, it only works if you just have to toggle something on, not if some code has to remain resident as a driver), and then re-loads the HDD bootsector and performs a 'warm boot' from there.
Then you'd create an entry for that boot sector in the NT4 menu... You'd manually boot to that bootsector, then the bootsector will re-trigger the boot menu, and then it can boot through with the default option, being NT4.

Alternatively you could do the same trick with the bootsector on a floppy, and you won't require the NT4 boot menu.

Rio444 wrote:

The driver needs the same hardware modification what was made by you or Anonymous Coward. It include installation of the inverte […]
Show full quote

The driver needs the same hardware modification what was made by you or Anonymous Coward.
It include installation of the inverter circuit and connection Irg12.
The driver adds support PS/2 mouse without need to modify the BIOS.
It contains TSR module and the installation module.
TSR module include int 15h handler (services C2h and C1h) and int 74h handler.
The installation module does the following:
- check, whether there is already support for the mouse,
- adds mouse to the equipment list, at 40:10h address,
- unmasks Irq12 PIC,
- changes interrupt vectors 15h and 74h to its own.

I have tested with Award BIOS 4.50 (also it was tested with modified BIOS) and Ami BIOS 2.11 (1993).
386DX-40 motherboard is M326 V5.2 model. I did the same modification KBC, as you with your DTK PKM-0033S.

I have no NT4 driver. I suppose it is not needed.
You just need to enable the Irq12 at PIC and add mouse to the equipment list.
Everything else is already included in OS.

Added 26/01/18.
Last version of the driver, rev.1.0.2c, is here: https://yadi.sk/d/5ge32bgv3RoUHs

BIOS option ROM that modifies the equipment list and confs the PIC shouldn't be difficult to do. It could even hold the interrupt handlers.

User Anonymous Coward mentioned using GRUB for DOS. Then load GRUB from the DOS prompt to load NT4. This way I can run ps2suppc.com and cyrix.exe

http://xpt.sourceforge.net/techdocs/nix/disk/ … fo/ar01s03.html

12.3 Starting GRUB for DOS from DOS 
2You can use load GRUB for DOS in config.sys using one of the following lines:
3
4DEVICE=GRUB.EXE
5INSTALL=GRUB.EXE
6SHELL=GRUB.EXE
7grub.exe can also be launched from DOS prompt or batch file such as AUTOEXEC.BAT.

I am attaching a response from RIO444, which I hope he does not mind. It provides a lot of additional information and answers some of your questions about it being or not being a TSR.

Rio444 wrote:

I did not mean editing BIOS. It's hard for me too. I thought just add at the end of the BIOS code that would be executed before […]
Show full quote

feipoa wrote:

Unless an old version of AMIBCP turns up, I don't think editing the BIOS will work out. Someone more familiar with BIOS editing could do it, but that's not me.

I did not mean editing BIOS. It's hard for me too. I thought just add at the end of the BIOS code that would be executed before loading the operating system.

feipoa wrote:

I've seen a ROM card for Super Disk which gives native support for booting LS-120 super disks, but designing something like this is beyond my current skill set and I haven't the time learn.

Most network cards have a BIOS ROM. There are also special cards for similar purposes that only have ROM. It seems this is one of them https://twitter.com/foone/status/1058956966595256326 For code simplicity, this is the best option.

feipoa wrote:

Best options sounds like modifying the MBR. But will the code fit in the MBR? Have you done this before? Do you know of a tutorial to walk me through this process?

I did this almost two years ago. Now it’s hard for me to remember.
You can see my posts on the Russian forum https://www.phantom.sannata.org/viewtopic.php … 26981&start=147
The bottom line is as follows. You need to modify the MBR so that the code is executed before the operating system starts. This code should do the same thing that ps2supp.com does. It must make the necessary settings and place interrupt handlers in memory.
The MBR has free space where you can insert several commands that lounch the main program. After the MBR, there are always several free sectors where this program can be placed.
There is a lot of information about MBR and the structure of hard disk data on the Internet. But now I can’t remember something specific. You can start with Wikipedia or the books of Peter Norton.

feipoa wrote:

Also, did you test PS2SUPPC.com with Win95? And which driver did you use?

Yes, of course, I tested.
Driver it the standard mouse driver in Windows.
Ps2supp.com was launched from autoexec.bat before booting Windows.

feipoa wrote:

Is PS2SUPPC.COM a TSR? A comment on my post says this would only work if it wasn't a TSR. Any way to run a DOS TSR program before loading Windows NT 4.0?

Of course, in the DOS it is TSR.
But for Win NT, it's just a DOS interrupt handler that you can place anywhere. Probably the best option for to avoid damage code with the Windows, place it in the EBDA area.
It is needed only during the loading of Windows at the initialization stage of the mouse. After loading, Windows will use only its own interrupt handlers.

However, it has occurred to me that my SXL2 system needs more than the PS/2 mouse driver loaded. I also need to run a dos program to setup the cache and clock double, e.g. cyrix.exe -f -r -cd -i1 . I am going to attempt a fresh install of Win95c on the CF-SCSI card first. If I can get W95c running fine, then I might feel motivated to spend a some time on all your great suggestions.

This is the result of trying GRUB4DOS, GRUB4DOS help needed to boot NT4 from DOS - SOLVED

Anyone familiar with GRUB4DOS who can assist in that post? Much appreciated.

Even if you "loaded" it NT would wipe it from memory and probably clear interrupt vectors as well...I.e. it would not survive very long.

Why do you think the CPU register bits would return to default once NT loads?

Not of their own volition, I imagine any protected mode OS would clear any existing interrupts and page tables etc so it can have complete control. I could be wrong of course 😁

kolderman wrote:

Not of their own volition, I imagine any protected mode OS would clear any existing interrupts and page tables etc so it can have complete control. I could be wrong of course 😁

Indeed. The fact that it is called an Operating System implies that this takes over complete control of the system.
The OS has to take over completely, because there's no way to guarantee that the OS works correctly if it starts from an unknown state.
Windows NT will only use fallbacks to legacy BIOS routines when no specific drivers are available, and this is done only for certain known devices (int 13h for disk access for example). So I wouldn't expect some kind of custom mouse hack to survive.

Well, what about the L1 cache remaining enabled then? Or the CPU left in clock doubled mode? I can get around the mouse by using a ps/2-to-serial port emulator card (discussed elsewhere).

feipoa wrote:

Well, what about the L1 cache remaining enabled then? Or the CPU left in clock doubled mode?

What does that have to do with TSRs?
We are talking about 16-bit interrupt handlers installed by the TSR, which would likely get overwritten as the OS kernel initializes.
You are talking about chipset/CPU states.

It's possible to boot DOS, run some DOS utility to initialize some hardware, and then boot eg. Linux via Loadlin, or some other OS via some other loader.
But it's impossible for that DOS utility to provide its resident services under other OS.

In other words...

Scali wrote:

Would only work if it's not actually a TSR.

EOT?

the interrupt vectors are only needed for the ps/2 supplement program to work with DOS mouse drivers

even if NT clears them when it loads (it will) the important part of adding the mouse to the equipment list and programming the PIC will already be done, and NT will know to look for a ps/2 mouse

Scali wrote:

What does that have to do with TSRs? We are talking about 16-bit interrupt handlers installed by the TSR, which would likely get […]
Show full quote

feipoa wrote:

Well, what about the L1 cache remaining enabled then? Or the CPU left in clock doubled mode?

What does that have to do with TSRs?
We are talking about 16-bit interrupt handlers installed by the TSR, which would likely get overwritten as the OS kernel initializes.
You are talking about chipset/CPU states.

Yes I am. I should have been more clear in the original post (since updated). My interests are two-fold: 1) I want to ensure that my CPU's register bits stay as I have set them using cyrix.exe, and b) the the the PS/2 mouse still works once PS2suppc.com has been loaded. Perhaps you could also include your thoughts concerning the CPU register status clearing or not?