flat assembler
Message board for the users of flat assembler.

flat assembler > OS Construction > [Solved]Many questions ...

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
Fulgurance



Joined: 27 Nov 2017
Posts: 41
Hello, i have making short program with fasm (little OS for show text).

Code:
use16

org 0x0

 mov ax, 0x7C0
 mov ds, ax

 mov ax, 0xB000
 mov es, ax

 mov byte [es:0x8000], 'H'
 mov byte [es:0x8001], 0x57
 mov byte [es:0x8002], 'E'
 mov byte [es:0x8003], 0x0A
 mov byte [es:0x8004], 'L'
 mov byte [es:0x8005], 0x4E
 mov byte [es:0x8006], 'L'
 mov byte [es:0x8007], 0x62
 mov byte [es:0x8008], 'O'
 mov byte [es:0x8009], 0x0E
 mov byte [es:0x800A], ' '
 mov byte [es:0x800B], 0x0E

 xor eax,eax
 cpuid
 mov [CPUInstructionsNumber],eax

 xor si,si

main:
 inc si
 mov al,[frames+si]
 mov byte [es:0x800A], al
 cmp si, 0x3
 je short .reset
 jmp short main
 .reset: xor si,si
 jmp short main

numberID: db ?
base: db 0x30
CPUInstructionsNumber: dd ?
frames: db '-','\','|','/'

rb 510-($-$$)
dw 0xAA55    


But i have many questions. When i do jump command, program do memory jump on disk image or in RAM ? And how is it possible, similary to linux live image to boot into usb and make code don't overwrite on taken RAM ? How is it possible to write into computer hard disk ? (without interruption)


Last edited by Fulgurance on 16 Mar 2018, 20:44; edited 1 time in total
Post 28 Feb 2018, 10:33
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15982
Location: Qo'noS
Moved to OS Construction.
Post 28 Feb 2018, 10:36
View user's profile Send private message Visit poster's website Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 371
Location: Belarus
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.
Post 28 Feb 2018, 11:07
View user's profile Send private message Visit poster's website Reply with quote
Fulgurance



Joined: 27 Nov 2017
Posts: 41
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.
Post 28 Feb 2018, 14:47
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 371
Location: Belarus
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.
Post 28 Feb 2018, 16:01
View user's profile Send private message Visit poster's website Reply with quote
Fulgurance



Joined: 27 Nov 2017
Posts: 41
Thank you for your clear explanations. Very Happy

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
Post 28 Feb 2018, 17:02
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 371
Location: Belarus
Fulgurance wrote:
Thank you for your clear explanations. Very Happy

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

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.
Post 28 Feb 2018, 18:42
View user's profile Send private message Visit poster's website Reply with quote
Fulgurance



Joined: 27 Nov 2017
Posts: 41
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)
Post 02 Mar 2018, 09:30
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15982
Location: Qo'noS
In real mode you can use any segment register to access data. DS, ES, SS, CS, GS, or FS.
Post 02 Mar 2018, 13:04
View user's profile Send private message Visit poster's website Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 371
Location: Belarus
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.
Post 02 Mar 2018, 13:22
View user's profile Send private message Visit poster's website Reply with quote
Fulgurance



Joined: 27 Nov 2017
Posts: 41
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    
)
Post 02 Mar 2018, 15:26
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 371
Location: Belarus
Fulgurance wrote:
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    
)

Why not just give it a try? Smile
Post 03 Mar 2018, 06:15
View user's profile Send private message Visit poster's website Reply with quote
Fulgurance



Joined: 27 Nov 2017
Posts: 41
Thanks, i have tested Smile

I have other question (sorry Embarassed )
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?
Post 03 Mar 2018, 23:58
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 371
Location: Belarus
Fulgurance wrote:
Thanks, i have tested Smile

I have other question (sorry Embarassed )
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?

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.
Post 04 Mar 2018, 08:07
View user's profile Send private message Visit poster's website Reply with quote
Fulgurance



Joined: 27 Nov 2017
Posts: 41
Okay, thanks. Smile
I'm boring, i know, but how is it possible to know screen pixels number without bios interrupt ? With cpuid ?
Post 05 Mar 2018, 10:49
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 371
Location: Belarus
Fulgurance wrote:
Okay, thanks. Smile
I'm boring, i know, but how is it possible to know screen pixels number without bios interrupt ? With cpuid ?

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.
Post 05 Mar 2018, 16:03
View user's profile Send private message Visit poster's website Reply with quote
Fulgurance



Joined: 27 Nov 2017
Posts: 41
Have you got an example with VBE without interrupt in assembly ? I search but i don't found anything
Post 06 Mar 2018, 21:33
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 371
Location: Belarus
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).
Post 07 Mar 2018, 10:45
View user's profile Send private message Visit poster's website Reply with quote
Fulgurance



Joined: 27 Nov 2017
Posts: 41
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....
Post 09 Mar 2018, 15:16
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 371
Location: Belarus
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).
Post 09 Mar 2018, 19:59
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2018, Tomasz Grysztar.

Powered by rwasa.