I've replaced the code prepping and booting the boot sector(the prepareboot and following assembly as follows:

1preparereboot;
2mem[0:$7f00] := currentdisk2;
3memw[0:$7efc] := $7c00;
4memw[0:$7efe] := 0;
5asm
6mov bx,0
7mov es,bx
8mov ss,bx
9mov sp,$7efc
10mov bx,$7f00
11mov dl,[es:bx]
12retf
13end;

This should ensure that memory is cleaned up (preparereboot function), dl is loaded with the driver number (in my environment 80h, aka HDD #0, which is the first bootable device found), SS:SP is set to 0:7f00(512 bytes past the boot sector) and execution is transferred to 0000:7c00 for the boot sector. Anyone can verify this? Or is there an error in my code? When I try to run this in my x86EMU emulator, the CPU stops for some reason?

I've based my preparereboot function on the code at https://support.microsoft.com/en-us/kb/67929
Is this correct?

After I call the program with the /soft parameter, my emulator still runs, but won't respond to the debugger. This is only the case when either the debugger is running, but not showing due to an error(not likely, since it runs fine during other times)) or the CPU is in a HALT state (the debugger won't be executed, since it needs an CPU instruction to step, which it doesn't have during the HALT state. It's only called when the CPU has executed an instruction). Is there a reason the HLT instruction is called during booting?

Well, the first version of prepareboot failed most likely because you trashed DS segment and did not restore it. It needs to be pointing to Pascal's data segment for variables to work.

The second version assumes there is nothing running at 0:$7c00, but in reality DOS or some programs could be loaded there and it might be timer interrupt code, mouse interrupt code or whatever. There might be something already enabled that wants to execute something there. Blindly reloading boot sector to 0:$7c00 is really not a safe way to restart DOS, because DOS and drivers assume things are the way they are after BIOS has initialized them.

Same thing with calling int 19h. It's OK for a boot sector to call it to retry booting, but after DOS is running, it is not safe. It does not reinitialize hardware devices the way they should be (e.g. COM port interrupts disabled) and it does not reinitialize interrupt vectors (timer interrupt could point to code running under DOS).

How about

The problem is that I want the program to reboot MS-DOS only (soft reboot, so only reboot DOS, not run the entire BIOS again. Afaik using 1234h with int19h should do it, but the BIOS will fully reset anyway (the same as the normal CPU reset pin) when I try that. Is this an error in the BIOS?). Also running device drivers etc. should have been terminated by the int 21h function 0D combined with the Ctrl+Alt+Del simulation according to Microsoft's specs of their code (EMM386 terminated)?

I'm using the Generic Super PC/Turbo XT BIOS v2.5 to test.

Davros wrote:

How about http://i.imgur.com/sNObXKb.jpg […]
Show full quote

How about

Well, that does not create a standalone program, it needs debug.com from DOS and the commands instruct the debug program to go execute code from $FFFF:$0000, which is exactly same thing as JMP $FFFF:$0000 in superfury's code here:

inline($EA/$00/$00/$FF/$FF);

Another thing is it does not set the magic word at $40:$72 to perform either cold or warm reboot.

And it's better to notify memory managers and disk caches to shut down first. Otherwise you might lose data not written to disk yet, or hang the machine if there is a memory manager and for instance a 80386 CPU is in V86 mode so the BIOS ROM is also virtualized.

Just to continue Jepael's post (and I know this is not impacting Superfury, as his x86emu emulates real 8086) but I think it also won't work in Protected Mode (not only not in V86) on a 286+ as the FFFF segment might not be mapped in the GDT.

superfury wrote:

The problem is that I want the program to reboot MS-DOS only (soft reboot, so only reboot DOS, not run the entire BIOS again. Afaik using 1234h with int19h should do it, but the BIOS will fully reset anyway (the same as the normal CPU reset pin) when I try that. Is this an error in the BIOS?). Also running device drivers etc. should have been terminated by the int 21h function 0D combined with the Ctrl+Alt+Del simulation according to Microsoft's specs of their code (EMM386 terminated)?

I'm using the Generic Super PC/Turbo XT BIOS v2.5 to test.

I still think it's impossible, reloading DOS again from DOS. Most likely calling int 19h in your program just crashes the system so bad it reboots. The word at $40:$72 just selects if full cold boot sequence is run, or can it skip some initial tests and just do a warm boot, but it is read when jumping to $FFFF:$0, not when calling INT 19H.

INT 21H function 0D is a disk reset, it does not shut down peripherals, mouse drivers, other hooked interrupts or other DOS programs, like TSRs playing music (which could have hooked timer interrupts and/or sound card interrupts and using memory at $0:$7c00 for interrupt routines or DMA buffer for the soundcard). Calling INT 19H also does not stop ongoing interrupt/DMA systems. Jumping to $FFFF:$0 will, because it disables interrupts and reinitializes all motherboard peripherals and interrupt vectors to their default state before calling INT 19H to bootstrap DOS from disk.

Few links about int 19h:
http://members.tripod.com/vitaly_filatov/ng/a … asm_001.12.html
http://stanislavs.org/helppc/int_19.html

So I must replace the /soft option with calling preparereboot, setting $40:$72 to $1234, then jump to $FFFF:$0000 using the inline statement. Also preparereboot must execute push ds before and pop ds before returning? And the /hard option must execute the bottom option(catch-all) instead of calling interrupt 19h? Then all options should work? (The ds problem might explain why debugging using Turbo Pascal 6.0 failed (keyboard not fully working and couldn't step/resume execution. I just assumed DS would be loaded again during execution past the assembly, when trying to use the variables))
Would the /soft option just clear the screen and reboot dos(not executing the first screen of the Turbo XT BIOS v2.5 when implemented as described above?

superfury wrote:

So I must replace the /soft option with calling preparereboot, setting $40:$72 to $1234, then jump to $FFFF:$0000 using the inline statement. Also preparereboot must execute push ds before and pop ds before returning? And the /hard option must execute the bottom option(catch-all) instead of calling interrupt 19h? Then all options should work? (The ds problem might explain why debugging using Turbo Pascal 6.0 failed (keyboard not fully working and couldn't step/resume execution. I just assumed DS would be loaded again during execution past the assembly, when trying to use the variables))
Would the /soft option just clear the screen and reboot dos(not executing the first screen of the Turbo XT BIOS v2.5 when implemented as described above?

The prepareboot could use ES instead of DS, so you don't have to do anything (ES does not need to be preserved).

Yes, call prepareboot to notify disk caches and memory managers (as if either is in use on a 808x anyway), then decide between warm boot or cold boot by writing $1234 or $0000 to $40:$72. Never invoke INT 19H, never load anything directly to $0:$7C00 as it could overwrite the currently executing reboot program.

The effect of cold boot is same as turning on the power switch, and the effect of warm boot is same as using CTRL-ALT-DEL keyboard sequence. Some initial memory checking is skipped, so it's somewhat faster, but all motherboard peripherals are reinitialized similarly before bootstrap. I don't think you can have faster DOS reload unless you somehow take a snapshot of the emulator and save it (memory contents, CPU registers, peripheral states..), but even then it requires that if disks are detected before that, the disks must also be identical to match the saved state.

Maybe the emulator could have a fast restart button so it resets and runs at maximum speed without video/audio rendering until INT 19H is hit?

I've removed the if clause content of the /soft flag. I've also removed the interrupt 19h call.
I've moved the if clause itself to the bottom part of the script, where it will either set $40:$72 to 0(without /soft) or $1234(with /soft).

I tried running the newly compiled executable with /soft, but it results in a full reboot (The Super PC/Turbo XT BIOS still shows refreshes VGA(screen update), Shows blue bar with header, show hardware connected and starts counting memory, just like a normal hard reset (or closing and opening the emulator again). Is there an error in the BIOS I use? Does it check for the $1234 at all?
So there's no visible difference between $1234 and 0 being set with jumping to FFFF:0000? Shouldn't the whole first screen of the BIOS need to be skipped with $1234 set (and instead just start booting again with an empty screen, from the user perspective)?

When I look at the source code of the BIOS, I notice something strange:

1;--------------------------------------------------------------------------------------------------
2; Power-On Entry Point
3;--------------------------------------------------------------------------------------------------
4	entry	0FFF0h				; Hardware power reset entry
5proc	power	far				;   CPU begins here on power up
6
7	jmpf	0F000h, cold_boot
8
9endp	power

Then at cold_boot:

1;---------------------------------------------------------------------------------------------------
2; BIOS Power-On Self Test (POST)
3;---------------------------------------------------------------------------------------------------
4	entry	0E05Bh				; IBM restart entry point
5proc	post	near
6
7cold_boot:
8	mov	ax, 40h 			; Entered by POWER_ON/RESET
9	mov	ds, ax
10	mov	[word ds:72h], 0		; Show data areas not init
11
12warm_boot:

So it will never perform a warm reboot using FFFF:0000 (always reset the 1234h value). It does seem to correctly call warm_boot with CTRL-ALT-DEL with ENHANCED_KEYB defined. So the only way to reliably perform a warm reboot is either jumping to the direct address of warm_boot from my program, or simulating a CTRL+ALT+DEL through the keyboard controller(set 40:17 to 0xC, finally add key code 0x53 to the keyboard input buffer to trigger the BIOS's warm reboot. Finally, if still running display an error message.)?

Edit: I've tested above changes too: The $1234 flag is simply ignored by the BIOS. Anyone? (I'm using this BIOS: http://www.phatcode.net/downloads.php?id=101 ) I'm using v2.5's PCXTBIOS.BIN file as the BIOS.

It appears that bios jumps to warm boot label from the keyboard interrupt after detecting CTRL-ALT-DEL.

However, real IBM bios jumps to $FFFF:$0000, and later determines if this was a cold or warm boot.

So yes, the generic turbo XT bios does ignore it when jumping to $FFFF:$0000. That's bad, but good thing is there's source code and you can still patch the bios to work differently.

But unfortunately when I try to execute a CTRL-ALT-DEL key combination on my keyboard, in Direct Input mode Windows catches it instead of my emulator and when I try to execute it using the OSK in the emulator it has no effect. Apparently it's function(ENHANCHED_KEYBOARD thing according to the comments) disabled in the ROM that's distributed with the source code? Although the source code itself has it enabled? Or maybe the key has the wrong scancode mapped (it's using the scancode set #1 I believe, since it checks for the E0 prefix.)? Ctrl and Alt work fine afaik.

Yes, in Windows, user programs won't get CTRL-ALT-DEL combination.

That's why emulators have a menu to send CTRL-ALT-DEL or they remap some other key combination to be CTRL-ALT-DEL, CTRL-ALT-INS or CTRL-ALT-END seem to be popular in some virtual machines.

(I don't know why emulator OSK does not work here).

After looking at the scancode set 1 page (http://www.computer-engineering.org/ps2keyboa … scancodes1.html) I notice that E0 53 is the make code of delete. So it's indeed using scancode set 1.

Left control is 1D(make) and 9D(break).
Left alt is 38(make) and B8(break)
Right control is E0 1D(make) and E0 9D(break)
Right alt is E0 38(make) and E0 B8(break)
Delete is E0 53(make) and E0 D3(break)

Now comparing it to my emulation of scancode set 1 (Contained in a big array in hardware/keyboard_data.c)...
Left control is correct.
Left alt is correct.
Right control is correct.
Right alt is correct.
Delete is also correct.

So the input is actually correct according to the documentation.

Now looking at the actual source code of the Super PC/Turbo XT BIOS v2.5...

Edit: Currently checked Control and Alt key updating. The code seems OK(if my emulated CPU works correctly, which I think it does). So the ctrl and alt flags should be correctly updated. Now to check the del key...

It looks that when ctrl and alt are pressed and delete is pressed, below quote should be executed:

1reboot:
2	mov	[word ds:72h], 1234h		; Ctrl-Alt-Del,	set init flag
3	jmp	warm_boot			;   do a warm reboot

Next question: Since it seems that entering a Ctrl-Alt-Del through Direct Input won't work because of Windows and Ctrl-Alt-Del using seperate keys during keyboard mode (k+l for selecting the correct input block, holding left for ctrl, next also holding right for alt and finally numpad 6 to actually press the del key. So for some reason, the emulator won't receive the Ctrl-Alt-Del input because having k, l, left, right and numpad 6 pressed will be ignored for some reason (real keyboard buffer overflow because pressing 5 keys at the same time(which isn't supported by the Dell SK-8185 keyboard I'm typing with now?) (generating too many input doesn't seem to be the case, since the PC isn't producing beeps) or limitations on the amount of keys pressed in that area (don't know if the keyboard still uses those electrical wires limiting simulaneous input with that key combination?)? In any case, the emulator isn't receiving the key combination. Anyone knows anything about this?'

Also, if the ctrl-alt-del make codes aren't sent in the right order, the del won't trigger a reboot (using up instead of left+right is mapped to trigger both ctrl and alt at the same time in x86EMU during keyboard and mouse modes(indicated by the flag disappearing and a capital M in the bottom right corner of the window/screen(at fullscreen))).

I look at my input emulation and I notice two errors in both keyboard and gaming mode (gaming mode is entered by pressing down while in either mouse or keyboard mode, and exited using select(PSP) or backspace(PC). The errors are exactly the same in both cases: It checks for release of keys first, then handles keypresses, but instead of requesting release of keys it presses the keys(at the keyboard file, which handles all timing used by the CPU, but in realtime instead of direct CPU time (the CPU speed might be faster or (way) slower than it's supposed to be running (when running at 100% emulation speed). With slower PCs (less than 3-4GHz CPU), it's usually between 0% speed and 90% speed with current optimization). This shouldn't affect input given by the user, which types in realtime. So in order to fix that I've locked the keyboard input rate to real time (gotten from a high percision timer) instead of being synchronized with the CPU clock (which varies with machines running the CPU faster or slower).

I'm patching this bug right now. That should at least fix being able to use Control and Alt within those two modes, thus able to actually execute a Ctrl-Alt-Del (and any other Control and/or Alt combined with another normal key).

Edit: Now that the bug is fixed, Ctrl-Alt-Del using the emulator's OSK works. I do notice that after the XT-IDE BIOS trying to boot C, fails because of a missing OS, Ctrl-Alt-Del soft reboots. After that the soft reboot Ctrl-Alt-Del has no effect anymore?