[asembler] pliki COM

0

czesc. podobno w plikach com kod programu przesuniety jest w stosunku do poczatku segmentu o 100h bajtow. I teraz takie pytanie : czy windows nadal uzywa segmentacji pamieci ? chyba nie... a pliki com nadal istnieja... wiec jak to jest ? poza tym mam pytanie co do ladowania programow do pamieci z segmentacja, czy kazdy program ma byc ladowany do odzielnego segmentu ?

pzdr, opx

0

Windows pracuje w trybie wirtualnym v86 => http://pl.wikipedia.org/wiki/Tryb_wirtualny tak więc wszystko działa jak należy :)
A jeżeli chodzi o drugie pytanie, to każdy program działa w innym segmencie ? inaczej by się nadpisywały. Segmenty można ustalać co 16 bajtów więc nie jest to żadna przeszkoda.

0

Ad2. Nie, kazdy program jest w segmencie 100h, z tym, ze kazdy program ma swoja przestrzen adresowa i tak na prawde moze byc (a wlasciwie na 100% jest) gdzie indziej, mimo to widzi jakby byl w 100h.

0

hmm a przypadkiem 100h to nie jest częśc offsetowa :P natomiast segment jest dowolny? wystarczy uruchomić dowolny debuger... np. windowsowy debug.exe ? :>

0

No tak, 100h to jest offset, ale co za problem zamist 0:100h zrobic 10h:0 czy jakie tam ma przesuniecie segment :)

0

czyli mam rozumiec ze windows wkorzystuje segmentowanie i stronicowanie ? czy stronicowanie moze byc wykorzysywane jednoczesnie z segmentowaniem ? czy nie sa to raczej dwa oddzielne sposoby podzialu pamieci ? pozaty mam pytanie co to znaczy ze poczatek segmentu moze byc ustalany co 16 bajtow ( czyli na wstepie pamieci nie jest podzielona (zsegmentowana) dopiero to jak podzieli ja OS ) ? mam rozumiec ze jesli tak jest to system operacyjny mimowszystko ustala kolejne uzyteczne segmenty liniowo bo jesli by tak nie bylo to byloby to strasznie marnotrawienie pamieci, bo np jedna przestrzen adresowa segmentu nie moglaby sie zmiescic w jakiejs przestrzeni adresowej bo np. tam gdzie konczyl bys sie owy segment zaczynalby sie nastepny... chyba ze jest tak ze tak naprawde jest to zrobione jakos wirtualnie ze wcale nie musza te segmenty byc upakowane liniowo a i tak pamiec jest wykorzystywana cala. Dalej mam pytanie w zwiazku z adresowaniem 16 bitowym w trybie rzeczywistym lub wirtualnym... skoro adresowanie jest 16 bitowe to program ma dostep tylko do 1MB pamieci i teraz dwa pytania czy tylko do pamieci swojego kodu czy tez do pamieci ktory jest poza kodem i drugie pytanie co jesli program jest dluzszy niz 1MB ?

0

Ale namotales :)

czyli mam rozumiec ze windows wkorzystuje segmentowanie i stronicowanie ?

Segmentacja dziala zawsze, z tym, ze w rmode jest ustawiona na sztywno (tam segmenty maja rozmiar 64b i ich poczatek jest co 16b [jak pomylilem wartosci to krzyczec] przez co one na siebie "nachodza") a w pmode programista osa sam moze sobie zrobic segmenty jakie i gdzie chce. Stronicowanie Windows tez wykorzystuje po to aby stworzyc oddzielne przestrzenie. W v86 natomiast MMU (stronicowanie) wciaz dziala, lecz adresuje sie tak jak w rmode, wyglada to mniej wiecej tak:

[jakas operacja na wskazniku] -> segmentowanie w stylu 80186 -> LDT (jesli jest, ale w windows bodaj jest) -> GDT (stronicowanie pmode) -> MMU (stronicowanie).

czy nie sa to raczej dwa oddzielne sposoby podzialu pamieci ?

Sa, ale moga dzialac rownolegle, pierw segmentacja, potem stronicowanie (jak w przykladzie).

pozaty mam pytanie co to znaczy ze poczatek segmentu moze byc ustalany co 16 bajtow ( czyli na wstepie pamieci nie jest podzielona (zsegmentowana) dopiero to jak podzieli ja OS ) ?

W pmode dzieli to OS, w rmode jest na sztywno ustawione, w v86 jest mix :)

Dalej mam pytanie w zwiazku z adresowaniem 16 bitowym w trybie rzeczywistym lub wirtualnym... skoro adresowanie jest 16 bitowe to program ma dostep tylko do 1MB pamieci i teraz dwa pytania czy tylko do pamieci swojego kodu czy tez do pamieci ktory jest poza kodem i drugie pytanie co jesli program jest dluzszy niz 1MB ?

Prawdopodobnie Windows go utnie :)

Z tym marnotrawieniem nie chce mi sie dochodzic o to chodzi ale to jest tak, ze dzieki stronicowaniu wirtualnie pamiec jest liniowa, a fizycznie dziurawa jak pofragmentowany dysk, po to jest MM w systemie zeby tym zarzadzac :)

0

Przepraszam za taka niechlujnosc.

  1. Skoro segmenty na siebie nachodza to dlaczego programy na siebie nie nachodza ?

Stronicowanie Windows tez wykorzystuje po to aby stworzyc oddzielne przestrzenie.

Co dla ciebie znaczy stworzyc oddzielne przestrzenie ?

  1. Co tak w ogole daje nam stronicowanie ( wydaje mi sie ze to ze dane moga byc rozproszone po calej pamieci a stronicowanie robi cos takiego ze sklada je do kupy jakos i daje nam w postaci stron ) ? niby czytalem na wikipedii ale niestety niedokonca to rozumiem...

  2. co to jest LDT , GDT , MMU ?

  3. I w koncu nie wiem jak to jest z tym adresowaniem 16 bitowym... czy 1MB mozna wykorzystac tylko odwolujac sie do wlasnego kodu programu ? no i co jesli program jest dluzszy ?

  4. W programie napisanym w jezyku ASM mozna dzieki takim dyrektywa jak segment w pewnym nazwanym segmencie stworzyc kod albo dane ... jak wtedy takie segmenty sa upakowane w pamieci czy faktycznie dane sa oddzielnych segmentach jesli tak to czy te segmenty leza jeden obok drugiego ?
    Co jesli chcemy sie odwolac do danych z jakiegos segmentu a segment lezy poza ta dana nam przestrzenia adresowa 1MB jak sie do niego odwolac ?

Dziekuje za wszystkie odpowiedzi...

0
  1. Skoro segmenty na siebie nachodza to dlaczego programy na siebie nie nachodza ?

Bo kazdy program ma swoja przestrzen adresowa, czyli w programie A pod adresem np 1000h jest co innego niz w programie B pod tym samym adresem.

  1. Co tak w ogole daje nam stronicowanie ( wydaje mi sie ze to ze dane moga byc rozproszone po calej pamieci a stronicowanie robi cos takiego ze sklada je do kupy jakos i daje nam w postaci stron ) ?

Dzieki stronicowaniu mozemy zmapowac pamiec np tak, ze adres 1000h wskazuje tak na prawde na adres 0 (przyklad).

  1. co to jest LDT , GDT , MMU ?

Powiedzmy, ze LDT i GDT sluza do segmentacji w pmode a MMU odpowiada za stronicowanie.

  1. I w koncu nie wiem jak to jest z tym adresowaniem 16 bitowym... czy 1MB mozna wykorzystac tylko odwolujac sie do wlasnego kodu programu ?

Jesli program jest 16 bitowy to tak.

Co jesli chcemy sie odwolac do danych z jakiegos segmentu a segment lezy poza ta dana nam przestrzenia adresowa 1MB jak sie do niego odwolac ?

Po to jest system operacyjny zeby tego uniknac.

0

W dawnych czasach było tak:
Miałeś 16 bitowe rejestry, a pamięci miałeś max 1 MB i już.
16 bitami możesz zaadresować tylko 64kB. 20 bitowy adres fizyczny [u]procesor[/u] obliczał następująco: SEGMENT*16 + OFFSET.
SEGMENT i OFFSET to 16 bitowe rejestr np. DS i AX.
I stąd segmenty mogą zaczynać się co 16 bajtów, segment ma 64k (adresowane offsetem).
Stronicowanie dotyczy pamięci wirtualnej i z założenia jest dla ciebie niewidoczne.

0

dobrze ale jak jest teraz ? i co to znaczy ze stronicowanie jest dla mnie nie widoczne ? na poziomie programisty ( jak sobie pisze jakis program w asm np.) ? i jesli tak to mam rozumiec ze ogolnie mnie jako programisty w asm nie obchodzi cale pojecie stronicowania bo ogolnie nie moge na nie wplynac ?

Dalej...

czy jesli tworze program wraz z danymi w asm to czy te dane i kod sa tak naprawde ladowane do jednego segmentu ? albo czy powiedzmy ( powtorze sie teraz bo juz o tym pisalem ) dyrektywa "segment" tworze pewien obszar to czy ten dane(kod) z tego obszaru sa narpawde w innym segmencie ?

bede wdzieczny za odpowiedzi... bardzo mnie ten temat interesuje chcialbym go poznac jak najglebiej ale niestety wszystkie publikacje jakie do tej pory znalazlem na ten temat do mnie nie trafiaja , sa pisane strasznie nie zrozumiale.</email>

0

"Dawniej", znaczy w rmode. Z tym, ze nie jest to taki przezytek bo v86, chcoiaz rzadko uzywany, emuluje rmode, a poza tym procesor budzi sie wlasnie w rmode, OS musi zadbac o to jesli chce byc pro :)

i jesli tak to mam rozumiec ze ogolnie mnie jako programisty w asm nie obchodzi cale pojecie stronicowania bo ogolnie nie moge na nie wplynac ?

Dokladnie, chyba, ze piszesz OSa czy cos w tym rodzaju. Dzieki stronicowaniu po prostu kazdy program ma dla siebie pamiec od 0 do 2GB (domyslnie w windows) i nie musi sie przejmowac innymi programami (bo ich nawet nie widzi).

czy jesli tworze program wraz z danymi w asm to czy te dane i kod sa tak naprawde ladowane do jednego segmentu ? albo czy powiedzmy ( powtorze sie teraz bo juz o tym pisalem ) dyrektywa "segment" tworze pewien obszar to czy ten dane(kod) z tego obszaru sa narpawde w innym segmencie ?

To juz zalezy jak program jest zlinkowany, w windows (PE) sa to wlasciwie sekcje, chociaz nie powiem ci jak to dalej w pamieci jest pakowane, moge sie jedynie domyslac, ze kazda sekcja ma swoj wpis w LDT (czyli swoj segment) ale jak to w MS zrobili na prawde - nie wiem.

bede wdzieczny za odpowiedzi... bardzo mnie ten temat interesuje chcialbym go poznac jak najglebiej ale niestety wszystkie publikacje jakie do tej pory znalazlem na ten temat do mnie nie trafiaja , sa pisane strasznie nie zrozumiale.

Proponuje wszystko co jest zwiazane z OSDev, czyli przede wszystkim manuale intela, strony (http://osdev.devtown.net , http://osnau.freehostia.com/ , http://www.osdever.net/)

0

na tej stronie : http://www.grush.one.pl/article.php?id=virtmem&page=3 koles pisze ze mozna uzywac obecnie stronicowania i segmentacji jednoczesnie... ale jest to niepraktyczne i uzywa sie tylko stronicowania... skoro tak jest ze uzywa sie tylko stronicowania to dlaczego programy pisane w asm uzywaja niby skladni np (segment) takiej jakby segmentacja byla caly czas uzywana... co wiecej jest cos takiego jak ""segmentation fault" ktore uwidacznia moim zdaniem to ze segmentacja caly czas dziala.
Mam jeszcze takie pytanie: skoro segmentacja daje nam dostep tylko do pamieci w obrebie segmentu to dlaczego jak pamietam moglem napisac program ktory wlazil do tablicy wektorow przerwan i zmienial sobie rozne rzeczy ( jesli dobrze pamietam oczywiscie ) , albo np moglem pisac pod adres A000 i zmieniac wyglad ekranu... to chyba nie jest juz adres w obrebie tego samego segmentu ( tak mi sie wydaje ) . Wiec jak to jest ? Dzieki za linki Wolverine :)

0

I jeszcze oprocz tych pytan ktore teraz zadalem to mam nastepujace :

weszlem na pierwsza strone ktora mi podales http://colony.devtown.net/site/Kurs_pisania_OS_-_tryb_rzeczywisty.html i tutaj dostrzeglem problem ktory mnie nurtowal od bardzo dawna, otoz spojrz na podpunkt 06h i tam masz napisane przed tym ze BIOS czyta pierwsze 512 bajtow i laduje je pod adres 07C0:0000. No wlasnie i teraz w kodzie tam w 06h masz napisanego tego bootloadera ktorego pierwsza intrukcja jest dyrektywa ORG 7C00h , wiem ze 7C00h fizycznie jest rownowazne adresowi logicznemu 07C0:0000, ale nurtuje mnie pytanie po co ta dyrektywa jest wstawiona bo skoro BIOS zaladuje te 512 bajtow pod ten adres 7C00h to po co jeszcze przesuwac ( dzieki dyrektywi ORG - mowie to na podstawie strony //binboy.sphere.pl/index.phpshow=serwis&d=asm&s=arej.htm na samym koncu jest o tym ) o 7C00h wzgledem poczatku segmentu pod ktory zostanie zaladowany ten kod ? Zupelnie to jest dla mnie niezrozumiale.

0

Czekaj, bo to sie robi bez sensu, artykul ktory podales dotyczy programowania systemu operacyjnego, nie "normalnego" programu. Jak piszesz program pod windows/windows-v86 stronicowanie cie praktycznie nie obchodzi bo i tak nie masz na nie wplywu. Segmentacja jest obecna zawsze, nawet piszac jmp 1000h skaczesz do cs:1000h.

I teraz piszac pod win32 masz elegancki plaski model pamieci, kazda sekcja (.text, .data, .bss itp) ma swoj segment i musisz tylko pilnowac zeby przypisywac do rejestrow segmentowych wartosci tych "etykiet".

Pod DOSem/win-v86 (EXE) jw i procz tego musisz pamietac o tym, ze w rmode masz co 16b segmenty ktorych dlugosc wynosi 64k.

Pod DOSem/win-v86 (COM) bo o tym chyba jest ten temat musisz pamietac tylko o adresowaniu w rmode (czyli jw) bo w COM program moze zajmowac max jeden segment.

ale nurtuje mnie pytanie po co ta dyrektywa jest wstawiona bo skoro BIOS zaladuje te 512 bajtow pod ten adres 7C00h to po co jeszcze przesuwac ( dzieki dyrektywi ORG

No po to zeby kompilator wiedzial, ze program bedzie pod adresem 7C00h (czyli zerowy bajt nie jest pod adresem 0 tylko 7C00h, pierwszy pod 7C01h itp).

0
Wolverine napisał(a)

Czekaj, bo to sie robi bez sensu, artykul ktory podales dotyczy programowania systemu operacyjnego, nie "normalnego" programu.

no systemu operacyjnego... chodzi o to ze podobno ta segmentacja jest prawie nie uzywana w systemach operacyjnych ( tak rozumiem to co koles napisal ) a ty mi dalej piszesz ze segmentacja jest zawsze uzywana... nie bardzo rozumiem

No po to zeby kompilator wiedzial, ze program bedzie pod adresem 7C00h (czyli zerowy bajt nie jest pod adresem 0 tylko 7C00h, pierwszy pod 7C01h itp).

A nie powie mu tego procesor w momencie ladowania programu do pamieci ? poza tym jak powiedzialem a raczej chcialem to wskazac tez na stronie dyrektywa ORG dziala jako przesuniecie wzgledem poczatku segmentu... a nie ze ogolnie mowi ci jakis jest fizyczny adres instrukcji programu. Pytanie tylko gdzie tutaj jest poczatek segmentu ? To mi nie pasuje... wiesz o co mi chodzi ?

0

No więc oczywiście, że segmentacja jest użuwana w systemach operacyjnych takich jak Windows, dlatego, że są one w pewnym stopniu kompatybilne z poprzednimi wersjami. Podczas normalnej pracy systemu najprawdopodobiej segmentacja jest nie użuwana, ale jak uruchamiasz program *.com lub program dla trybu chronionego ("dosowy") to system operacyjny tworzy taką otoczkę w której zostaje on uruchomiony. Ten program widzi cały komputer tak jak by on działał pod starym DOSem i z segmentacją systemu.

Musisz sobie uświadomić, że istnieją różne tryby adresowania gdy masz pamięć segment:offset lub selektor:offset. I to trzeba o nich rozmawiać z osobna bo inaczej tego nie zrozumiesz.

Proponował bym ci na razie zadawać pytania tylko odnośnie trybu rzeczywistego i adresowania segment:offset jak już wyjaśnisz sobie wszystkie wątpliwości wtedy zrozumienie działania systemu będzie łatwiejsze.

;------------------------------
A jeżeli chodzi o ORG 7C00h to to jest dyrektywa dla kompilatora. Musi on wiedzieć jaki offset jest początku programu. Dlatego, że wszystkie adresy wewnątrz programu są liczone względem jego początku. Pisząc ORG 7C00h dodaje on do tych adresów dodatkowo tą liczbę informującą, że początek też ma swoje przesunięcie względem początku segmentu.

PS

Pod DOSem/win-v86 (COM) bo o tym chyba jest ten temat musisz pamietac tylko o adresowaniu w rmode (czyli jw) bo w COM program moze zajmowac max jeden segment.

No właśnie nie musi. Widziałem programy które mają 90KB. Tylko nie mam pojęcia jak one są wgrywane do pamięci. To jest jak na razie dla mnie dziwna sprawa.

0
Nevar napisał(a)

A jeżeli chodzi o ORG 7C00h to to jest dyrektywa dla kompilatora. Musi on wiedzieć jaki offset jest początku programu. Dlatego, że wszystkie adresy wewnątrz programu są liczone względem jego początku. Pisząc ORG 7C00h dodaje on do tych adresów dodatkowo tą liczbę informującą, że początek też ma swoje przesunięcie względem początku segmentu.

Ale chyba troche nie rozumiecie o co pytam. Wyjasnie to moze blizej. Rozumiem ze ORG jest dyrektywa i ze nadaje przesuniecie dla wszystkich komend programu, lecz zobaczcie w ten link ( http://colony.devtown.net/site/Kurs_pisania_OS_-_tryb_rzeczywisty.html i podpunkt 06h) ktory podalem gdy pierwszy raz pytam sie o to. Autor tego artykulu pisze ze program ktory jest tworzony bedzie ladowany pod adres 07C0:0000 inacze mozna to zapisac jako 0000:7C00 . No wlasnie skoro program jest ladowany pod ten adres to skad wiecie ze jego przesuniecie wzgledem segmentu bedzie wlasnie 7C00... przeciez adres poczatku do ktorego bedzie ladowany program moze wyniesc np. 7C0 i wtedy gdy dacie dyrektywe ORG 7C00 to tak naprawde piersza linia programu zacznie sie pod adresem: 07C0:7C00.

0

aby byc dokladnym tam mialo byc poczatku segmentu w lini :
ten adres to skad wiecie ze jego przesuniecie wzgledem segmentu bedzie wlasnie 7C00... przeciez adres poczatku [segmentu] do ktorego bedzie

0

Ano teraz widzę, że masz rację. Boot Loadder jest ładowany pod adres fizyczny 7C00h. Ale już po załadowaniu skacze pod adres 07C0:0000. Czyli część segmentowa 7C0 offsetowa 0. No i żeczywiście jak by dać tak jak tam jest org 7C00 to na pewno to nie bedzie dobrze działać. Powinno być org 0 co najwyżej.

0

wlasnie o tol mi chodzilo co zauwazyl Naver... Wolverine jak sie do tego ustosunkujesz ?

0

Kurde, o czym wy piszecie? BIOS laduje to pod 07C0:0000 / 0000:7C00. CS zakladamy, ze wynosi 0 to przesuniecie musimy ustawic na 7C00 :P

Ale już po załadowaniu skacze pod adres 07C0:0000.

ee? Co, kiedy? :)

No właśnie nie musi. Widziałem programy które mają 90KB.

Pewnie sie jakos "doladowuja" do MMSa, XMSa czy czegos tam jeszcze, nie znam sie tym ale to hacki po prostu.

0

Tak, tak teraz musze przyznać rację Wolverine'nowi. To co powiedziałem to nie jest prawda. Po załadowaniu Boot Loaddera BIOS skacze pod adres 0000:7C00 tak więc nie miałem racji. Ale ... ;]
zauważyłem pewną rzecz. Tak naprawdę o tym czy to będzie org 7C00h czy org 0h czy cokolwiek innego decyduje to jak będziemy odczytywać dane.

Jezeli będziemy to robić w stylu:
mov ax, [cs:costam]
albo
mov ax,cs
mov ds,ax
mov ax,[costam]
itp

to na pewno należy ustawić org 7C00h

Zdaje mi się tylko, że i tak to niczego nie zmienia w tym przykładzie bo równie dobrze może on mieć dowolną wartość przy org lub nie mieć tego wcale.
http://colony.devtown.net/site/Kurs_pisania_OS_-_tryb_rzeczywisty.html

0

ja wysiadam :)... Wolverine dlaczego zakladasz ze CS = 0 ? Bo to jest wlasciwie najistotniejsze bo jezeli faktycznie tak jest a nie tylko sobie tak zakladasz to zmienia cala postac rzeczy pytanie tylko dlaczego ?

0

No bo taka wartosc zostawia BIOS przekazujac kontrole bootloaderowi.

0
Wolverine napisał(a)

I teraz piszac pod win32 masz elegancki plaski model pamieci, kazda sekcja (.text, .data, .bss itp) ma swoj segment i musisz tylko pilnowac zeby przypisywac do rejestrow segmentowych wartosci tych "etykiet".

poprawka Wolverine - pod win32 faktycznie masz płaski model pamięci ze stronnicowaniem, ale selektory segmentów nie dotyczą sekcji. W sumie to w zwykłych programach występują chyba tylko 3 selektory - CS, DS=ES=SS, FS... GS = 0 /po wartości zapraszam do dowolnego debuggera albo ntddk - piszę z kafei :/ /. Co do danych sekcji to w nagłówku każdej w pliku PE podane są jej atrybuty - rozmiar w pliku, rozmiar w pamięci, offset w pliku i w pamięci oraz atrybuty w rodzaju wykonywalny, odczytowalny itd. które odnoszą się do atrybutów stron pamięci zajmowanych przez konkretną sekcję.
Ew. potem jeszcze coś wyjaśnię - teraz czas mnie goni :/

0

Jeszcze sprostuje co do bootloadera ... możesz dać nawet org 0 ale wtedy musisz ustawić wszystkie rejestry ( za wyjątkiem cs ) na adres 0x7C0 :] i też będzie działac ;p w końcu 0x7C0 : 0000 a 0x0000 : 0x7C00 to przecież to samo ;p

0

[Aduch] dlaczego tak ? i dlaczego nie mozna ustawic CS ? mam rozumiec ze myslisz iz CS zostanie ustawiony w momencie ladowania progsa do pamieci ? ( nie bardzo rozumiem )

</cpp>
0

i jeszcze takie male pytanko ktore w sumie nie powinno sie pojawic w tym watku ale juz napisze... :
dlaczego NASM wypluwa mi taki blad :

plik.txt error: attempt to define a local label before any non-local labels
plik.txt error: parser: instruction expected

gdy kod wyglada tak:

.model small

start:

mov ah,4ch
int 21h

wychodzi na to ze nasm nie trawi dyrektywy .model ale skoro tak to jak napisac w jakim modelu pamieci pracujemy ?

0

Dodam że mówiąc rejestry miałem na myśli segmentowe ( es, ds itd :P ).
Musisz wiedzieć że adres liniowy tworzysz w taki sposób : segment * 16 + offset, wiec ( 16 to w hex 0x10 )
0x07C0 : 0x0000 = 0x07C0 * 0x10 + 0x0000 = 0x07C00 liniowo
0x0000 : 0x7C00 = 0x07C00 liniowo jak widać dokładnie to samo :P
teraz np :

[ORG 0x0000]
start: 
 mov ax, 0x7C0
 mov ds, ax
 mov si, offset zmienna
zmianne db 0 

offset zmienna zwraca zawsze adres względny ( od początku programu ! ) czyli tak naprawde w si będzie stałą wartość równa ROZMIAROWI programu od początku aż do tej zmiennej ( czyli ile bajtów trzeba przeskoczyć ) następnie dodawane do tego jest to co masz w org czyli zero ) ale w bootloaderze liniowo będzie to 0x7C00 + adres_względny_zmiennej ( tak zapisze to w programie kompilator). dlaczego tak? ponieważ początek programu znajduje się w punkcie 0x7C00. teraz ten efekt otrzymujemy na dwa sposoby. albo zmieniamy org na 0x7C00 i już będzie kompilator wiedział ile dodawać ( wtedy musimy wyzerować rejestry segmentowe - prosta matematyka która byłą powyżej ) drugi sposób to również wykorzystanie tego co było powyżej i po prsotu ustawienie segmentu na 0x07C0. mam nadzieje że rozumiesz :P

1 użytkowników online, w tym zalogowanych: 0, gości: 1