The processor doesn't use DMA, it already has direct access to the memory. DMA is usually for hard disks. It's a buss master system. In other words the processor requests a chunk of data from the hard disk but since the hard disk is slow in comparison to the processor, the processor does not need to wait. It will go on about it's bussiness until the Hard disk signals the processor that data is ready. The processor will tri-state (high impedance like an open circuit) it's address and data busses and go to sleep while the DMA controller takes over all memory addressing functions and dumps the data from the hard disk straight into memory. Now you will have to initialize the DMA controller and there is a small bit of handshake during hard disk exception. You can examine the bios to find them for your particuliar machine(fairly standard code). I dont remember port numbers off hand.
As far as allocating memory in general aside from the DMA, it is all done in the GDT (LDT entries) and local descriptor tables. Set up task state segments as needed for individual tasks.
As far as allocating memory in general aside from the DMA, it is all done in the GDT (LDT entries) and local descriptor tables. Set up task state segments as needed for individual tasks.
Hey, made a thread discussing DMA, and write down the link.
thinking about the future of my project i came to the question "what about the fpu-stack when task-swithing?". i mean, neither the control word nor the stack itselfs is contained in a task state segment (tss). do i have to dump them all manually and load it manually too? any special function for it?
If you had the function I'd like to have it too.
thinking about the future of my project i came to the question "what about the fpu-stack when task-swithing?". i mean, neither the control word nor the stack itselfs is contained in a task state segment (tss). do i have to dump them all manually and load it manually too? any special function for it?
I think you must do it your self, wasn't there a thread bout win95 not supporting MMX (or was it SSE2), and running two tasks that uses MMX (or SEE2) could compromise the restult/MMx (or SEE2 ) registers. Take a look at how other OSes solves the problem, take a look on linux for instace (too bad most asm is in GAS syntax :rolleyes: luckily I've found a few converters, haven't been able to test 'em yet though, I hope they do what they're supposed to...)
hm... that's a pity...
i've created a memorymap some time ago for 256 tasks at maximum - fixed locations. expecting 128 bytes each (actually 104 bytes, but it's better with 128 bytes). if i have to store the fpu, mmx and sse2-registers too... (btw, are some of them the same? it seems to me as if the fpu-stack is the same as the mmx-registers)
i've created a memorymap some time ago for 256 tasks at maximum - fixed locations. expecting 128 bytes each (actually 104 bytes, but it's better with 128 bytes). if i have to store the fpu, mmx and sse2-registers too... (btw, are some of them the same? it seems to me as if the fpu-stack is the same as the mmx-registers)
i was a bit busy the last time so i had no time for os-programming - but soon: easter holidays!
@scientica: i found 2 functions for including the fpu in taskswitching:
saving the whole fpu-information (including controlwords and statuswords) takes either 94 or 108 bytes (i currently don't know what it depends on)
@all:
new question:
since the gfx-mode almost works i wanted to start coding the mouse. ha! not that easy as i tought. in the ports-listing i found some information using the i/o-port 0x60, but i don't know exactly how i use it.
can anybody point me to some sites where i can find further information?
and: in the listing is written, that all commands are acknowledged by 0xfa; do i have to send it or does the mouse send it?
@scientica: i found 2 functions for including the fpu in taskswitching:
fsave dest
frstor src
saving the whole fpu-information (including controlwords and statuswords) takes either 94 or 108 bytes (i currently don't know what it depends on)
@all:
new question:
since the gfx-mode almost works i wanted to start coding the mouse. ha! not that easy as i tought. in the ports-listing i found some information using the i/o-port 0x60, but i don't know exactly how i use it.
can anybody point me to some sites where i can find further information?
and: in the listing is written, that all commands are acknowledged by 0xfa; do i have to send it or does the mouse send it?
i was a bit busy the last time so i had no time for os-programming - but soon: easter holidays!
@scientica: i found 2 functions for including the fpu in taskswitching:
fsave dest
frstor src
saving the whole fpu-information (including controlwords and statuswords) takes either 94 or 108 bytes (i currently don't know what it depends on)
I have had little time to, school is hard, we've got lots of tests ahead, I hope I'll get some time for some OS-programming under the easter hollidays, thanks for the instructions, I'll take a closer look at them as soon as I get some time.
Port 0x60 used for KeyBoard, not Mouse.;)
@realvampire: you're wrong. port 0x60 ist used for both, keyboard and mouse, according to the port list.
if i am still wrong... tell me which one's correct :)
if i am still wrong... tell me which one's correct :)
To answer the first question. The regs necessary to saving machine status are automatically save during a task switch. It's embedded in the processor so you don't need to worry about it.
The mouse is usually on Comm1 or Comm2 Ports 2f8 and 3f8. It operates just like a modem but if I remember correctly it's only 7 bits no stop,no parity. You have to do some look ahead programming to get smooth operation. I attached a little driver Dat file I wrote sometime ago. You can turn it into a COM file by typing "Debug < mtest.dat". Run it in Dos real mode and it will spit out the codes that the mouse sends to the serial port.
The mouse is usually on Comm1 or Comm2 Ports 2f8 and 3f8. It operates just like a modem but if I remember correctly it's only 7 bits no stop,no parity. You have to do some look ahead programming to get smooth operation. I attached a little driver Dat file I wrote sometime ago. You can turn it into a COM file by typing "Debug < mtest.dat". Run it in Dos real mode and it will spit out the codes that the mouse sends to the serial port.
haha, nice one! but there's a catch (even three of them):
- i do os-programming, i dont have a dos-extender
- i operate in protected mode
- i have a ps/2-mouse. maybe i'll add com-drivers, but for now i'd like to have my ps/2-mouse
back to the first question:
how much space does it take to save the fpu-stack too? how do i enable saving it (any changes in cr0 or cr1?)?
- i do os-programming, i dont have a dos-extender
- i operate in protected mode
- i have a ps/2-mouse. maybe i'll add com-drivers, but for now i'd like to have my ps/2-mouse
back to the first question:
how much space does it take to save the fpu-stack too? how do i enable saving it (any changes in cr0 or cr1?)?
for saving the fpu state i think you should use fxsave and fxrstor because they save the xmm regs too. this always needs 512 bytes of space.
i sometimes thought the fpu-stack-registers and the mmx-registers are the same memory...?
512bytes is gettin too much... i've precalculated a memory-map with fixed locations i started programming after. i have now 444 task wich 128bytes TSS and a 1kb-stack each. (just the space, the tasks get, indeed, created dynamically - but not much there)
and 512bytes is mixing it up :)... but ok, that's not that bad.
but back to the ps/2-mouse: any links occoured? tips? hints? information?
512bytes is gettin too much... i've precalculated a memory-map with fixed locations i started programming after. i have now 444 task wich 128bytes TSS and a 1kb-stack each. (just the space, the tasks get, indeed, created dynamically - but not much there)
and 512bytes is mixing it up :)... but ok, that's not that bad.
but back to the ps/2-mouse: any links occoured? tips? hints? information?
Well, you could have it be optional for each task, or allocate the structure when the task uses floating point operations for the first time.
Or create your own executible format, one that has let's say flags indicating wether it uses FPU, MMX, SEE, SSE2, 3DNow, etc. And the only save/restore the FPU and so for those tasks claiming to use it, and simply not save it for the other tasks (thus the FPU can be "whatever" for the other tasks, but since they don't use it, they don't know there is "whatever" in the FPU)
i sometimes thought the fpu-stack-registers and the mmx-registers are the same memory...?
mmx registers are mapped onto the fpu stack yes, but xmm registers (sse) are seperate.
quite good tips there. i like the one with the flag since memory allocating could be difficult. but i'll continue worrying about fpu later - first i'd like to implement the mouse. so, does anyone have documents/links/tipps/ideas?
Well, to send a byte, read port 64 until bit 1 becomes clear. Then write the byte to port 60. To receive a byte, wait until bit 0 of port 64 becomes set, and read the byte from port 60. Write the command to port 64 first.
Use command D1 to set the output port. This has the following format:
When data is ready, IRQ1 will be asserted. Read port 64 and check bit 5 to determine the source of the data. A set bit indicates that the data is from the mouse.
Command D4 sends commands to the mouse. After each command, the mouse responds with FA or FE. FE indicates that an error occurred when transferring the last command and that it should be sent again.
The following commands are used to control the mouse:
E6 - Set normal scaling
E7 - Set double scaling
E8 xx - Set resolution (1, 2, 4 or 8 units per mm)
E9 - Read status, resolution and sample rate.
The status has the following format:
EA - Send data whenever the mouse is moved or a button is pressed.
EB - Read data. This returns 8 bytes.
Byte 00:
Byte 2: Movement in horizontal direction
Byte 4: Movement in vertical direction
Byte 6: Scrolling wheel movement
F0 - Do not send data automatically
F2 - Read ID (1 byte, usually 00)
F3 - Set sample rate in Hz.
F4 - Enable
F5 - Disable
F6 - Reset to default settings
FE - Send last result again
FF - Reset mouse
Use command D1 to set the output port. This has the following format:
76543210
x------- Transfer to/from keyboard
-x------ Keyboard clock
--x----- Mouse buffer full
---x---- Keyboard buffer full
----x--- Mouse clock
-----x-- Transfer to/from mouse
------x- A20 enable
-------x Clear to reset CPU
When data is ready, IRQ1 will be asserted. Read port 64 and check bit 5 to determine the source of the data. A set bit indicates that the data is from the mouse.
Command D4 sends commands to the mouse. After each command, the mouse responds with FA or FE. FE indicates that an error occurred when transferring the last command and that it should be sent again.
The following commands are used to control the mouse:
E6 - Set normal scaling
E7 - Set double scaling
E8 xx - Set resolution (1, 2, 4 or 8 units per mm)
E9 - Read status, resolution and sample rate.
The status has the following format:
76543210
-x------ Polling mode
--x----- Enable
---x---- Scaling
-----x-- Left button pressed
-------x Right button pressed
EA - Send data whenever the mouse is moved or a button is pressed.
EB - Read data. This returns 8 bytes.
Byte 00:
76543210
x------- Vertical overflow
-x------ Horizontal overflow
--x----- Up/down flag
---x---- Left/right flag
------x- Right button pressed
-------x Left button pressed
Byte 2: Movement in horizontal direction
Byte 4: Movement in vertical direction
Byte 6: Scrolling wheel movement
F0 - Do not send data automatically
F2 - Read ID (1 byte, usually 00)
F3 - Set sample rate in Hz.
F4 - Enable
F5 - Disable
F6 - Reset to default settings
FE - Send last result again
FF - Reset mouse
for basic stuff, do read the intel manuals. Combined with some playing around, the will make a lot of questions unnecessary.
for common devices like PS/2 mice and keyboards, serial COM mice, AT keyboards, vesa graphics - google. there's a lot of easy to find information, faster than posting a question here at the board.
When doing VESA, be sure to take pitch (aka stride) into account. also might want to pay attention to color mask values (some of them are weird, but you could choose not to support those crappy cards ;-)).
consider not messing with stuff like VESA and peripheral programming until you have at least mapping and tasking+threading done, and some basic kernel infrastructure - at least if you're planning on doing more than just toying around.
a couple of links:
www.osdev.org
http://www.nondot.org/sabre/os/articles
for common devices like PS/2 mice and keyboards, serial COM mice, AT keyboards, vesa graphics - google. there's a lot of easy to find information, faster than posting a question here at the board.
When doing VESA, be sure to take pitch (aka stride) into account. also might want to pay attention to color mask values (some of them are weird, but you could choose not to support those crappy cards ;-)).
consider not messing with stuff like VESA and peripheral programming until you have at least mapping and tasking+threading done, and some basic kernel infrastructure - at least if you're planning on doing more than just toying around.
a couple of links:
www.osdev.org
http://www.nondot.org/sabre/os/articles