flat assembler
Message board for the users of flat assembler.
Index
> OS Construction > [Solved]Many questions ... Goto page 1, 2 Next |
Author |
|
revolution 28 Feb 2018, 10:36
Moved to OS Construction.
|
|||
28 Feb 2018, 10:36 |
|
DimonSoft 28 Feb 2018, 11:07
Fulgurance wrote: When i do jump command, program do memory jump on disk image or in RAM ? Jumps just make CPU fetch the next instruction from the address you specify instead of just “address after the current instruction”. Addresses are only applicable to RAM, and CPU can only fetch instructions and read data from RAM. Fulgurance wrote: And how is it possible, similary to linux live image to boot into usb and make code don't overwrite on taken RAM ? Please, explain what exactly do you want to achieve. Fulgurance wrote: How is it possible to write into computer hard disk ? (without interruption) Don’t know what you mean by interruption. In real mode disk access can be performed by means on INT 13h service. If that is what you can “interruption” then… uhm, OK. If your OS is UEFI-oriented you can use the services it provides which are called as procedures, not ISRs, although there’s not much difference between the two. Note though that you’re not supposed to use UEFI services for anything except OS boot since these services are quite limited and cannot provide a lot outside the capabilities that are required by the UEFI standard. If you’re going to write your OS as it should be, you’re going to write drivers for different buses and other hardware, and then use these drivers as intermediates between the applications/OS and hardware. But since you’re still worried about more basic questions like the basics of the work of CPU you’re not going to reach these problems soon. |
|||
28 Feb 2018, 11:07 |
|
Fulgurance 28 Feb 2018, 14:47
Okay. If i understand good, when CPU execute code on device, he execute all on RAM ?Code is it duplicate on RAM ?
For explain my question about live image: in past i have installed linux on computer. After, i have boot bios with usb with this code, and, when i have rebooted on Linux, my computer don't do anything. I have supposed my assembly code have erased data on RAM. But i'm not very sure, because if i remember, RAM is cleaned after shutdown... No ? I would like to understand... Still, if I'm not mistaken, my assembly code does not erase anything in memory, right? When i said interruption, i talk about do that without bios interrupt. |
|||
28 Feb 2018, 14:47 |
|
DimonSoft 28 Feb 2018, 16:01
Fulgurance wrote: Okay. If i understand good, when CPU execute code on device, he execute all on RAM ?Code is it duplicate on RAM ? Someone has to load the code into RAM. BiOS/UEFI is the one responsible for loading an OS bootloader. Since that point it’s all up to the OS to make code available in RAM at the right addresses. Fulgurance wrote: For explain my question about live image: in past i have installed linux on computer. After, i have boot bios with usb with this code, and, when i have rebooted on Linux, my computer don't do anything. I have supposed my assembly code have erased data on RAM. But i'm not very sure, because if i remember, RAM is cleaned after shutdown... No ? I would like to understand... Still, if I'm not mistaken, my assembly code does not erase anything in memory, right? You code seems to be incomplete but you definitely couldn’t break the Linux installation without accessing the hard drive. So, either you’ve missed something in your story or there was something in the part of your code you don’t show us. |
|||
28 Feb 2018, 16:01 |
|
Fulgurance 28 Feb 2018, 17:02
Thank you for your clear explanations.
I have other question: what is the use of CS,DS register. Is it just for addressing (for segmentation)? Or more ? I don't understand very well |
|||
28 Feb 2018, 17:02 |
|
DimonSoft 28 Feb 2018, 18:42
Fulgurance wrote: Thank you for your clear explanations. Segmentation, yes. The instructions are fetched from offset speicifed in (E)IP and it is relative to CS. The offsets specified in memory operands are by default treated as relative to DS (except EBP-based where SS is implied). The default choice of a segment register for memory operands can be overriden. |
|||
28 Feb 2018, 18:42 |
|
Fulgurance 02 Mar 2018, 09:30
Is it possible to addressing data with other register, or is it obligatory to use DS ?
Other question: i fi would like to access byte by byte to ebx for example, is it possible directly ? (for example to exploit and show cpuid output with 0 value on eax) |
|||
02 Mar 2018, 09:30 |
|
revolution 02 Mar 2018, 13:04
In real mode you can use any segment register to access data. DS, ES, SS, CS, GS, or FS.
|
|||
02 Mar 2018, 13:04 |
|
DimonSoft 02 Mar 2018, 13:22
Fulgurance wrote: Is it possible to addressing data with other register, or is it obligatory to use DS ? Like I said, DS is used by default (except for the (E)BP-based addressing case). You can override the behaviour. In FASM this is done by prefixing the memory operand with the name of the segment register you want to use: Code: mov eax, [fs:ebx] Fulgurance wrote: Other question: i fi would like to access byte by byte to ebx for example, is it possible directly ? (for example to exploit and show cpuid output with 0 value on eax) EBX is a four-byte register. Some parts of it have custom names that can be used to access them. Lower two bytes of EBX are called BX. In turn, the least-significant byte of BX is called BL, the most-significant byte of BX (byte 1 of EBX) is called BH. More on that can be found in Intel SDA, Volume 1, Chapter 3, section 3.4. As for CPUID with EAX = 0, you don’t really need byte-by-byte access to registers there as in most cases you’re going to put the register contents somewhere into memory to form a string anyway. |
|||
02 Mar 2018, 13:22 |
|
Fulgurance 02 Mar 2018, 15:26
Okay thanks.
And if i would like to access to specific adress calculating with incremental variable, is it possible ? (for example: Code: mov byte [es:0x800B+si], 0x0E |
|||
02 Mar 2018, 15:26 |
|
DimonSoft 03 Mar 2018, 06:15
Fulgurance wrote: Okay thanks. Why not just give it a try? |
|||
03 Mar 2018, 06:15 |
|
Fulgurance 03 Mar 2018, 23:58
Thanks, i have tested
I have other question (sorry ) If i use text mode at boot (start at 0xB8000), how i know limit of memory to use text mode ? And how i know the memories area that I do not have to change? |
|||
03 Mar 2018, 23:58 |
|
DimonSoft 04 Mar 2018, 08:07
Fulgurance wrote: Thanks, i have tested You shouldn’t use anything you don’t know about. And “know” means “can find in docs/specs”. In case of video memory you can find the limit by looking at the docs for int 10h/00h function where legacy video modes are listed (TechHelp might help). Knowing the amount of bytes per item (pixel or character) and the size in pixels/characters you can calculate the valid amount of memory to be used. Later you can read more about video pages if you wish. |
|||
04 Mar 2018, 08:07 |
|
Fulgurance 05 Mar 2018, 10:49
Okay, thanks.
I'm boring, i know, but how is it possible to know screen pixels number without bios interrupt ? With cpuid ? |
|||
05 Mar 2018, 10:49 |
|
DimonSoft 05 Mar 2018, 16:03
Fulgurance wrote: Okay, thanks. CPUID has nothing to do with any hardware except CPU. For legacy modes the screen mode characteristics are “just known” by convention. Later there used to be a VBE standard that had some mean to get the display mode description but AFAIK its support has certain problems, in some emulators at least. And then again VBE in real mode was accessible via int 10h. You can also talk to video hardware directly but the specs for particular video cards are quite complex and/or difficult to find so implementing it this way is better achieved with the concept of a driver. |
|||
05 Mar 2018, 16:03 |
|
Fulgurance 06 Mar 2018, 21:33
Have you got an example with VBE without interrupt in assembly ? I search but i don't found anything
|
|||
06 Mar 2018, 21:33 |
|
DimonSoft 07 Mar 2018, 10:45
Fulgurance wrote: Have you got an example with VBE without interrupt in assembly ? I search but i don't found anything For real mode you won’t find it since real-mode VBE services are provided via int 10h. For protected mode the situation is different, but if I remember it right you will not avoid int 10h anyway using the officially recommended way to do that (I may be wrong). |
|||
07 Mar 2018, 10:45 |
|
Fulgurance 09 Mar 2018, 15:16
Sorry if i don't understand very well. But i search how to use VBE in protected mode. But it's impossible to use bios interrupt with protected mode. Do you know or have you got documentation about do that with protected mode? And for other drivers fo other devices on protected mode. I search standard method to use devices, hard disk , graphic card with assembler, but i don't found example with ASM only....
|
|||
09 Mar 2018, 15:16 |
|
DimonSoft 09 Mar 2018, 19:59
Fulgurance wrote: Sorry if i don't understand very well. But i search how to use VBE in protected mode. But it's impossible to use bios interrupt with protected mode. Do you know or have you got documentation about do that with protected mode? Like I said, it’s not really worth it. But if you wish, you can find more info here. Since VBE/Core 3.0 you can also use a separate protected-mode entry point. Fulgurance wrote: And for other drivers fo other devices on protected mode. I search standard method to use devices, hard disk , graphic card with assembler, but i don't found example with ASM only.... The implementation depends on the hardware. Graphics cards are especially poorly-documented and every model might have its own custom quirks. Abstracting them is what drivers are all about. So no need to look for standard methods: standard method is either int XXh, or interacting with hardware directly. For the latter (to make things a bit simpler) you’ll have to implement a whole bunch of routines to support something like PCI bus (or maybe even ISA one for legacy hardware). |
|||
09 Mar 2018, 19:59 |
|
Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.