Page 3 of 4

Re: Loading meh kernel above 0x10000

Posted: Fri Sep 12, 2008 2:09 pm
by ChazZeromus
I already knew that the segments are loaded at those designated values. I just thought that the initial values stated by the manual we're too cliche and I knew that that most BIOS would change it, but then again, it starts in real mode... And wow, page 9-11, hm maybe god is on to me..

@Richard

Please don't patronize me, I've had enough on other forums, and I'd like to stop talking about this. I just said one thing, and people complained, I didn't want to sound weak so I fought back. That's all. So just stop, it's irritating me, and it's irritating you, so just stop it from it from here.

Re: Loading meh kernel above 0x10000

Posted: Fri Sep 12, 2008 2:58 pm
by brickhead20
In strength there is only softness, and in softness one gains strength (a Japanese proverb, sort of paraphrased).

Typically it takes more strength to admit you are wrong, and act accordingly to correct yourself than to try to defend something that is wrong.

Patronize? It is not a question of seeming "weak", what you said is genuinely sick, any decent person would apologise. To be honest, if you are like this all the time, I'm not surprised people on other forums flame you.

Well if you believe in god, then perhaps you believe in persistence of spirits too... :lol:

I'm happy to leave it there. Please be careful about what you say in jest in future though.

It would make sense that they be loaded at the same position, just like the BIOS checking the MBR for a boot signature etc. It makes is easier for assertive software etc.

Re: Loading meh kernel above 0x10000

Posted: Fri Sep 12, 2008 4:18 pm
by ChazZeromus
Well, I just don't like losing, and yes I could have said sorry, but I just didn't. We'll, you can say that I said it now, because I'm glad this has stop, and so, i am afraid to say, sorry I even brought it up.

Re: Loading meh kernel above 0x10000

Posted: Fri Sep 12, 2008 4:48 pm
by DT170x
This topic need to stay on topic. ChazZeromus put that topic on General Rambling not here.

Re: Loading meh kernel above 0x10000

Posted: Tue Sep 16, 2008 10:18 am
by Love4Boobies
Easy dude :) I'm only 18 myself. Yor probably got me wrong... You can check where BIOS places its interrupts by inspecting the IVT itself. Somewhere in the fist MB of RAM anyway.

Re: Loading meh kernel above 0x10000

Posted: Tue Sep 16, 2008 3:34 pm
by ChazZeromus
Alright Alright I GOT IT! Geez, is there anyway to lock this topic? Cause I already have everything I need, I just didn't about the A20 line as much.

Re: Loading meh kernel above 0x10000

Posted: Tue Sep 16, 2008 3:42 pm
by Love4Boobies
There are plenty of ways to enable/disable the A20 gate. Unfortunately, you can't make sure your code works properly. However, most AT-compatible BIOSes provide a function for coping with this. This is what IBM's PCS (Personal Computer Standard) said (note that this is a rare document, lol):
(AH)=24h---A20 Gate Support
Classification: Optional

(AL) = 00h - Disable A20 gate
Return Value: (AH) - Return code
= 00h - Operation successfully completed
= 01h - Keyboard controller is in secure mode
= 86h - Function not supported
CF = 0 - Operation successfully completed
= 1 - Operation failed

(AL) = 01h - Enable A20 gate
Return Value: (AH) - Return code
= 00h - Operation successfully completed
= 01h - Keyboard controller is in secure mode
= 86h - Function not supported
CF = 0 - Operation successfully completed
= 1 - Operation failed

(AL) = 02h - Query status of A20 gate
Return Value: (AL) - Status of A20 gate
= 00h - Disabled
= 01h - Enabled
(AH) - Return code
= 00h - Operation successfully completed
= 01h - Keyboard controller is in secure mode
= 86h - Function not supported
CF = 0 - Operation successfully completed
= 1 - Operation failed

(AL) = 03h - Query A20 gate support
Return Value: (BX) - Status of A20 gate support
Bit 15 = 0 - No additional data available
= 1 - All bits in register are used; additional
data is available (location of additional
data is to be determined)
Bits 14 to 2 - Reserved
Bit 1 = 0 - Not supported with bit 1 of port hex 92
= 1 - Supported with bit 1 of port hex 92
Bit 0 = 0 - Not supported on keyboard controller
= 1 - Supported on keyboard controller
(AH) - Return code
= 00h - Operation successfully completed
= 01h - Keyboard controller is in secure mode
= 86h - Function not supported
CF = 0 - Operation successfully completed
= 1 - Operation failed

Re: Loading meh kernel above 0x10000

Posted: Tue Sep 16, 2008 3:47 pm
by ChazZeromus
Mine is better:
8042 - Keyboard Controller (AT,PS/2)
8042 Status Register (port 64h read)

|7|6|5|4|3|2|1|0| 8042 Status Register
| | | | | | | `---- output register (60h) has data for system
| | | | | | `----- input register (60h/64h) has data for 8042
| | | | | `------ system flag (set to 0 after power on reset)
| | | | `------- data in input register is command (1) or data (0)
| | | `-------- 1=keyboard enabled, 0=keyboard disabled (via switch)
| | `--------- 1=transmit timeout (data transmit not complete)
| `---------- 1=receive timeout (data transmit not complete)
`----------- 1=even parity rec'd, 0=odd parity rec'd (should be odd)

Port Mode Description

64h read 8042 status register. Can be read at any time. See
table above for more information.
64h write 8042 command register. Writing this port sets Bit 3
of the status register to 1 and the byte is treated
as a controller command. Devices attached to the
8042 should be disabled before issuing commands that
return data since data in the output register will
be overwritten.
60h read 8042 output register (should only be read if Bit 0 of
status port is set to 1)
60h write 8042 data register. Data should only be written if
Bit 1 of the status register is zero (register is empty).
When this port is written Bit 3 of the status register
is set to zero and the byte is treated as a data. The
8042 uses this byte if it's expecting data for a previous
command, otherwise the data is written directly to the
keyboard. See KEYBOARD COMMANDS for information on
programming the actual keyboard hardware.



8042 Commands Related to PC Systems (Port 64h)
Command Description

20 Read 8042 Command Byte: current 8042 command byte is placed
in port 60h.
60 Write 8042 Command Byte: next data byte written to port 60h is
placed in 8042 command register. Format:

|7|6|5|4|3|2|1|0| 8042 Command Byte
| | | | | | | `---- 1=enable output register full interrupt
| | | | | | `----- should be 0
| | | | | `------ 1=set status register system, 0=clear
| | | | `------- 1=override keyboard inhibit, 0=allow inhibit
| | | `-------- disable keyboard I/O by driving clock line low
| | `--------- disable auxiliary device, drives clock line low
| `---------- IBM scancode translation 0=AT, 1=PC/XT
`----------- reserved, should be 0

A4 Password Installed Test: returned data can be read
from port 60h; FA=password installed, F1=no password
A5 Load Security: bytes written to port 60h will be read
until a null (0) is found.
A6 Enable Security: works only if a password is already loaded
A7 Disable Auxiliary Interface: sets Bit 5 of command register
stopping auxiliary I/O by driving the clock line low
A8 Enable Auxiliary Interface: clears Bit 5 of command register
A9 Auxiliary Interface Test: clock and data lines are tested;
results placed at port 60h are listed below:

00 no error
01 keyboard clock line is stuck low
02 keyboard clock line is stuck high
03 keyboard data line is stuck low
04 keyboard data line is stuck high

AA Self Test: diagnostic result placed at port 60h, 55h=OK
AB Keyboard Interface Test: clock and data lines are tested;
results placed at port 60h are listed above with command A9
AC Diagnostic Dump: sends 16 bytes of 8042's RAM, current input
port state, current output port state and 8042 program status
word to port 60h in scan-code format.
AD Disable Keyboard Interface: sets Bit 4 of command register
stopping keyboard I/O by driving the clock line low
AE Enable Keyboard Interface: clears Bit 4 of command register
enabling keyboard interface.
C0 Read Input Port: data is read from its input port (which is
inaccessible to the data bus) and written to output register
at port 60h; output register should be empty before call.

|7|6|5|4|3-0| 8042 Input Port
| | | | `---- undefined
| | | `----- 1=enable 2nd 256K of motherboard RAM, 0=disable
| | `------ 1=manufacturing jumper not installed, 0=installed
| `------- 1=primary display is MDA, 0=primary display is CGA
`-------- 1=keyboard not inhibited, 0=keyboard inhibited

C1 Poll Input Port Low Bits: Bits 0-3 of port 1 placed in
status Bits 4-7
C2 Poll Input Port High Bits: Bits 4-7 of port 1 placed in
status Bits 4-7
D0 Read Output Port: data is read from 8042 output port (which is
inaccessible to the data bus) and placed in output register;
the output register should be empty. (see command D1 below)
D1 Write Output Port: next byte written to port 60h is placed in
the 8042 output port (which is inaccessible to the data bus)

|7|6|5|4|3|2|1|0| 8042 Output Port
| | | | | | | `---- system reset line
| | | | | | `----- gate A20
| | | | `-------- undefined
| | | `--------- output buffer full
| | `---------- input buffer empty
| `----------- keyboard clock (output)
`------------ keyboard data (output)

D2 Write Keyboard Output Register: on PS/2 systems the next data
byte written to port 60h input register is written to port 60h
output register as if initiated by a device; invokes interrupt
if enabled
D3 Write Auxiliary Output Register: on PS/2 systems the next data
byte written to port 60h input register is written to port 60h
output register as if initiated by a device; invokes interrupt
if enabled
D4 Write Auxiliary Device: on PS/2 systems the next data byte
written to input register a port at 60h is sent to the
auxiliary device
E0 Read Test Inputs: 8042 reads its T0 and T1 inputs; data is
placed in output register; Bit 0 is T0, Bit 1 is T1:

|1|0| Test Input Port Bits
| `---- keyboard clock
`----- keyboard data

Fx Pulse Output Port: Bits 0-3 of the 8042 output port can be
pulsed low for 6 æs; Bits 0-3 of command indicate which
Bits should be pulsed; 0=pulse, 1=don't pulse; pulsing
Bit 0 results in CPU reset since it is connected to system
reset line.

- PC systems previous to the AT use the 8255 PPI as a keyboard
controller and use the keyboard's internal 8048.
- the keyboard's internal controller buffers up to 16 bytes of
make/break code information. This is common among all PC systems
and shouldn't be confused with the (32 byte) keyboard buffer
maintained by the BIOS.
- see KEYBOARD COMMANDS for information on programming the
keyboards internal microprocessor


Re: Loading meh kernel above 0x10000

Posted: Tue Sep 16, 2008 3:58 pm
by Love4Boobies
The only problem is that not all systems use the extra pin on the 8042 keyboard controller for the A20 gate. There are also other ways... That's why BIOS will always work (if the function is present). Perhaps it would be better to try BIOS first and if that fails, try other methods as well (such as the 8042).

Re: Loading meh kernel above 0x10000

Posted: Tue Sep 16, 2008 4:01 pm
by ChazZeromus
Yeah, my reference doesn't have an return stuff. So it's hard to tell you did something right.
By the way, can you link me to where you got the interrupt that enables it?

Re: Loading meh kernel above 0x10000

Posted: Tue Sep 16, 2008 4:10 pm
by Love4Boobies
Unfortunately, I can't - IBM had it online years ago and I was able to fetch the pages from somewhere and put them in an archive. I am sending you the archive so check your private messages.

Re: Loading meh kernel above 0x10000

Posted: Tue Sep 16, 2008 4:17 pm
by ChazZeromus
Thanks! Man, some don't support it...make you wonder how linux does it...wait I forgot, Grub handles that. Then how does Grub do it? Gotta download that too...
So new computer don't have it anymore? Then how are suppose to load onto a high address then!?!?!? #-o

Re: Loading meh kernel above 0x10000

Posted: Tue Sep 16, 2008 4:37 pm
by Love4Boobies
My pleasure :)

What actually happens is that new CPUs have A20 gate already enabled when they start up but for compatibiliy reasons, BIOSes that support these new CPUs deactivate it (so that old operating systems that expect A20 line to be disabled would still work). I use a custom boot loader for my OS, but you made me curious so I looked over GRUB's source code. It does just what we said earlier - it first tries the BIOS and if that doesn't work, it tries a bunch of other stuff.

Take a look at this http://www.win.tue.nl/~aeb/linux/kbd/A20.html for more info on what else you could try. Don't forget that even if you tried everything, you still can't know for sure that it worked so just assume :!:

Re: Loading meh kernel above 0x10000

Posted: Tue Sep 16, 2008 9:46 pm
by ChazZeromus
I've read that too, lol. Hm, that's interesting. How exactly does the CPU have the A20 gate already enabled? Unreal or PM, it's addressing modes are very static and I don't think the processor can mechanically enable A20 on startup. Maybe the address line that is equivalent, maybe that's whats you meant, sorry got me a bit puzzled. lol.

Re: Loading meh kernel above 0x10000

Posted: Tue Sep 16, 2008 9:59 pm
by Love4Boobies
The A20M# signal (called this way because of the A20M# pin that the CPU has, and which is provided for compatibility) can be used in real mode to mask the A20 line so you can have the 20-bit wrap-around that the 8086 CPU had. The A20 line is not masked by default but it can be done (and as I've said, BIOSes do it). It's not as much a mechanism for enabling/disabling transfers on the bus or anything, it's just masking... mimicking. Hope that clears it up...