Re: writing a monitor


"Allan Adler" <spamtrap@xxxxxxxxxx> wrote in message
news:y93myss7t8o.fsf@xxxxxxxxxxxxxxxxxxxxxxx
Allan Adler <spamtrap@xxxxxxxxxx> writes:

"Rod Pemberton" <spamtrap@xxxxxxxxxx> writes:
You could look at 512DevOS. A kernel and shell in 512 bytes.
http://sourceforge.net/projects/bootsectoros

Thanks, this is extremely helpful. I've downloaded it and will start
trying
to make sense of the source code before installing it and trying it out.

I've read through the source code and, as another poster noted, it is
pretty simple. But it was still instructive to read it and, having done
so, I have a few questions:
(1) The subroutine reboot: reloads the bootsector and jumps to it by
executing int 0x19.

No. "The subroutine" reload: "reloads the bootsector and jumps to it by
executing int 0x19." The subroutine reboot: reboots the PC.

The code is:
reboot: ; reboot function
db 0EAh
dw 0000h
dw FFFFh
reload: ; reloads the boot sector and jumps to it
int 0x19

Exactly what do the 5 bytes following reboot: do and exactly how were
they selected?

jmp ffff:0000h ; jmp to segment:offset

ffff:0000h is address ffff0h, i.e., ffffh * 16 + 0000h

It's the address where the Intel 8086 cpu starts execution, CS=F000h,
IP=FFF0h. This is the address where IBM put the BIOS PC reset vector. It
usually immediately jumps to f000:e05bh like the original IBM BIOS.

Int 19h
http://www.delorie.com/djgpp/doc/rbinter/id/79/22.html

I'm somewhat aware from looking at Gilluwe's book, The
Undocumented PC, that one does not simply execute int 0x19 without
some
preparation, but I wasn't clear on what one does do.

If the low BIOS vectors have been modified, they must be restored, e.g.,
modified by DOS or some other operating system. Since 512devOS is acting as
the OS and not modifying interrupts, except 21h and 22h, there's no problem.

This code seems to
have the answer but I don't understand the answer.

Nothing to do.

(2) The interrupt vector for int 0x21 is made to point to the routine
PrtStri
while that of int 0x22 is made to point to getchari. In general, which
interrupt vectors is it safe to redefine?

Any vectors the BIOS doesn't hook and isn't used by an IRQ.

Low vectors are shared between BIOS calls, cpu exceptions and IRQ's. But,
the occurence of exceptions are low. I'd suggest 20h to 32h, maybe 33h to
3fh, maybe 51h to 5fh (BIOS reserved), 60 to 6fh (user), maybe above 78h
upto fdh. You might also get away with 0,1,3,4,6,7 (read below). Some of
this information is available in Ralf Brown's interrupt list. You could
also look at lowmem.txt:
ftp://ftp.simtel.net/pub/simtelnet/msdos/memutil/lowmem.zip

1) The BIOS in my PC doesn't use 0,1,3,4,7,20h,23h-32h. It uses 21h and 22h
but apparently this is temporary. 6 (loadall emulation) may be useable for
really old PC's. It also uses 50h, 7ah, 40-4fh, 70-77h (IRQ's 8-15).
2) Real mode IRQ's 0 to 7 are mapped to vector's to 8 to 0fh.
3) Intel cpu manuals say not to use vectors below 1fh (but this has been
done by the PC BIOS anyway...).
4) 86 will generate exceptions below 5. 186 will generate exceptions below
8. 286 will generate exceptions below 0dh. 386 will generate exceptions
below 10h. (source: Robert Collins article) 486 will generate exceptions
below 13h. 586+ reserves upto 1fh and 12h is the highest it will generate in
real-mode (source: current Intel manuals).
http://www.x86.org/articles/pmbasics/
5) DOS and DOS utils use 20h to 3fh, i.e., useable.

(3) The code for the routine savrstart has the following code:
savrstart:
mov si,scrsavrm
int 0x21
mov ah,0x01
int 0x16
jnz svreturn
jmp savrstart
svreturn:
jmp CmdPrompt

I think I understand the stuff from int 0x16 on. Basically, it flushes
the keyboard buffer to the screen and then prints the command prompt
.
I'm less clear on the call to int 0x21 which is supposed to print a
string
whose address is in SI. The null-terminated string that gets printed
in
this case is '1001101'. Why would that be the choice of a string to
print? The abbreviated name scrsavrm reads as though it was supposed
to
be an abbreviation for "Screen Saver Message". What would 1001101 have
to do with a screen saver routine?

Implemenation of a screen saver left for the future..., perhaps?


Rod Pemberton

.

Relevant Pages

  • Re: Gigabyte GA 586 Board und Festplatten > 32 GB
    ... >>> Wenn ich aber lese, was in den ganzen Texten zu meinem BIOS steht, ... ich für Deine Auffassungsgabe? ... rather than the register based calling convention of the original INT 13 ... > die EDV den Leuten, ...
    (de.comp.hardware.laufwerke.festplatten)
  • [PATCH 2.6.23.stable] ACPI: sync blacklist w/ latest
    ... Check to see if the given machine has a known bad ACPI BIOS ... * Only a couple use it to make Linux run better. ... unsigned int length, char *desc) ... extern int dmi_get_year; ...
    (Linux-Kernel)
  • [patch 72/73] ACPI: sync blacklist w/ latest
    ... Check to see if the given machine has a known bad ACPI BIOS ... * Only a couple use it to make Linux run better. ... unsigned int length, char *desc) ... extern int dmi_get_year; ...
    (Linux-Kernel)
  • Re: [PATCH] PnP Updates for 2.6.0-test2
    ... +/* The PnP BIOS entries in the GDT */ ... * after PnP BIOS oopses. ... +void pnpbios_print_status ... +static int pnp_bios_get_event ...
    (Linux-Kernel)
  • Re: Formatting a floppy using int 13h
    ... I have noticed that int 13h does not really destroy the data ... ... The free space available in the floppy is more or less the same after ... Program to FORMAT A FLOPPY DISK ... jmp WriteDir ...
    (comp.lang.asm.x86)