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.
Posted on 2003-03-11 10:16:05 by mrgone
Hey, made a thread discussing DMA, and write down the link.
Posted on 2003-03-11 18:35:52 by realvampire
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?
Posted on 2003-03-12 13:20:53 by hartyl
If you had the function I'd like to have it too.
Posted on 2003-03-12 19:58:37 by realvampire

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...)
Posted on 2003-03-12 23:43:32 by scientica
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)
Posted on 2003-03-15 05:11:22 by hartyl
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)

@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?
Posted on 2003-04-05 03:20:49 by hartyl

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.
Posted on 2003-04-05 03:52:21 by scientica
Port 0x60 used for KeyBoard, not Mouse.;)
Posted on 2003-04-05 05:55:38 by realvampire
@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 :)
Posted on 2003-04-05 08:12:46 by hartyl
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.
Posted on 2003-04-05 16:13:06 by mrgone
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?)?
Posted on 2003-04-06 03:49:02 by hartyl
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.
Posted on 2003-04-06 07:20:57 by stormix
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?
Posted on 2003-04-06 14:10:00 by hartyl
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.
Posted on 2003-04-06 14:50:59 by Sephiroth3
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)
Posted on 2003-04-06 23:48:07 by scientica

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.
Posted on 2003-04-07 09:08:26 by stormix
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?
Posted on 2003-04-07 13:57:04 by hartyl
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:
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
Posted on 2003-04-07 15:28:10 by Sephiroth3
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
Posted on 2003-04-07 16:08:21 by f0dder