| Szerző |
Üzenet |
TCH
Tag
|
# Elküldve: 2011. Feb. 25. 17:25 - Szerkesztve: TCH
Amigók, itt egy 128 bites szorzórutin (020+), ez így működne? Elméleti kérdés, nincs egzakt oka. :Pmul4_2 ; a0 = var0, a1 = var1
movea.l _tmp128, a2
moveq #4, d0
moveq #0, d1
- move.b d1, (a2)+
dbeq d0 -
movea.l _tmp128, a2
moveq #4, d0
- move.l (a1)+, d1
mulu.l (a0)+, d1:d2
add.l d1, (a2)+
add.l d2, (a2)
dbeq d0 -
rts
Ha igen, akkor mi az amin optimolni lehetne rajta? Pl: loop unroll:mul4_2 ; a0 = var0, a1 = var1
movea.l _tmp128, a2
move.l (a1)+, d1
mulu.l (a0)+, d1:d2
move.l d1, (a2)+
move.l d2, (a2)
move.l (a1)+, d1
mulu.l (a0)+, d1:d2
add.l d1, (a2)+
move.l d2, (a2)
move.l (a1)+, d1
mulu.l (a0)+, d1:d2
add.l d1, (a2)+
move.l d2, (a2)
move.l (a1)+, d1
mulu.l (a0)+, d1:d2
add.l d1, (a2)+
move.l d2, (a2)
rts
Egyébként már tudom is mi van benne elbaszva, összeadásnál nincs lekezelve az átvitel. :P Egyebet valaki? :)
Csárli, nincs valami olyan bbcode tag ebben a minibb-ben, ami "pre" tagek közé tenné a cuccot? Kódhoz nagyon jó lenne...
|
AliveMOon
Tag
|
# Elküldve: 2011. Feb. 25. 19:34 - Szerkesztve: alivemoon
Várjunk tehát 2 64bit-es pozitív számot szoroz 128bitesé.
Én elösször is megnézném tényleg kell e 128bit tehát ha a magasabb vagy alacsonyabb értékek 0-lák akkor azokat kihagyom, lehet, hogy így wordoket szorozva ösze adogatva több mindent ki lehet hagyni.
|
AliveMOon
Tag
|
# Elküldve: 2011. Feb. 25. 19:54 - Szerkesztve: alivemoon
mulu az több ciklus alatt fut 020-ason, 060 már mindegy ha jól tudom, pipelin miatt? Tehát lehet, hogy megérné pár ellenörzéssel kihagyni olyan szorzást ami nem kell.
|
TCH
Tag
|
# Elküldve: 2011. Feb. 25. 21:03
Quoting: alivemoon Várjunk tehát 2 64bit-es pozitív számot szoroz 128bitesé. Quoting: alivemoon ha a magasabb vagy alacsonyabb értékek 0-lák akkor azokat kihagyom Quoting: alivemoon Tehát lehet, hogy megérné pár ellenörzéssel kihagyni olyan szorzást ami nem kell.
De egyébként is elbaxtam, mert a felsőbb helyiértékek összeszorzásánál nem egyszerűen a végeredményt adom hozzá, hanem el is kell shiftelni, 4000*4000 az nem 16000 hanem 16000000. :P
Ez van, ha melóban sutyi68k-zom. :P
|
AliveMOon
Tag
|
# Elküldve: 2011. Feb. 26. 07:01 - Szerkesztve: alivemoon
Ok! Én is mostanában PC-n programozok, kezdetben fel sem tünt, de alapvetö hiba.
Igazán 68k szelemében 128 bitet litle-endian-ban kéne tárolni, tehát a magas helyi értékűekkel kezded és a 4. long a legalacsonyabb.
Dekrementálásra kéne cserélned a léptetéseket.
De én úgy probálnám optimalizálni, hogy incrementáltan végig mennék rajta és meghatároznám, valolyában hány byteosak, utánna megfordulok és decrementáltan lépkedve elvégezném a kellő mennyiségű szorzást.
Több különböző optimalizált szorzással. A szorzó rutinok számát lehet szűkíteni, azzal, hogy mindig a kevesebb byteos számot szorzod a nagyobbal.
|
TCH
Tag
|
# Elküldve: 2011. Feb. 26. 13:10
Quoting: alivemoon Igazán 68k szelemében 128 bitet litle-endian-ban kéne tárolni, tehát a magas helyi értékűekkel kezded és a 4. long a legalacsonyabb. Quoting: alivemoon meghatároznám, valolyában hány byteosak A szorzó rutinok számát lehet szűkíteni, azzal, hogy mindig a kevesebb byteos számot szorzod a nagyobbal.
Köszi a tippeket! Ha van még, ne habozz megosztani. :)
|
AliveMOon
Tag
|
# Elküldve: 2011. Feb. 26. 13:34
Ezel a bigendien litle endiennel bajba vagyok, memoria, hagyományok szerint, mint az europai írás bal->jobb->lefelé Motorolanál nagyon helyesen a kicsi van a végén.
Motorola a természetes, Intelnél az embernél való komunikációnál folyton meg kell fordítani a számokat, ami igazán szerintem azért alakult ki, mert nem elörre tervezett volt, hanem 8 bitesből tuningolták nagyobra és rosszul.
A következő amin mindig PC-n lehet tudni, hogy egy fatális hiba, ez a fajta tárolás, mikor shiftelsz, << balra shiftelsz >> jobbra shiftelsz, balra növeled , jobbra csökkented, de a memóriában már ami balra lép ki a byte-ból az jobbra lép be a következő byteban, pontosabban a bitek balra nönek, de a byteok már jobbra :)
|
TCH
Tag
|
# Elküldve: 2011. Feb. 26. 16:53 - Szerkesztve: TCH
Valóban a big-endian a természetes az emberi gondolkodás számára, viszont a little endiant nem az intel találta ki és nem is csak ő alkalmazta, ld. pl. 6502.
A kétféle endian csak egy más bitbetöltési/tárolási stratégia volt annakidején, amikor a biteket még sorban töltötte be a processzor a regiszterekbe, vagy épp írta ki; mert spórolni kellett a tranzisztorokkal. Aztán amelyik mérnök ahogy gondolta éppen, úgy lett felhasználva.
Azonkívül a little endian egy másik fajta gondolkodás és ha végiggondolod nem teljesen hülyeség, noha az esetek többségében a big-endian logikusabb:
- A bitsorrend ugye big endiannál konszisztens azaz pl. FEDCBA98 76543210, ez így tiszta és logikus míg a little endiannál megkavarodik byteonként 76543210 FEDCBA98. Ez eddig 1:0 a big-endian javára.
- Továbbá, ha az irányokat nézzük, ahogy le is írtad bitenként épp a másik irányba shiftelsz, mint amerre byteonként. 2:0.
- Viszont, amikor nagyobb értékeket fűzöl össze és emberi szempontból kell gondolkodni, akkor jön be, hogy a memória sorrendje helyiérték szempontjából épp fordítva van, mint az emberi gondolkodás, a helyiértékezés hátrafele nő, minnél nagyobb a cím, annál hátrább vagy benne, vagy hogy megfordítsam a legkisebb cím van legelől!
Na itt van létjogosultsága a little endiannak, hiszen ha azt mondom, hogy x-nél kezdődik egy szám, akkor ha mondjuk a harmadik helyiérték kell, akkor x+3 és ez így teljesen logikus, nem úgy mint a big-endiannál, ahol x-3 lesz. Vagyis összesen 2:1 a big-endian javára.
Konzekvencia a big-endian az esetek többségében közelebb áll az emberi gondolkodáshoz - mindaddig, amíg az olvasott/írt érték belefért egy olvasatba, így pl. 68k alatt 32 bitbe, mert akkor neked nem kell a sorrenddel törődni, viszont olvasni és végiggondolni sokkal könnyebb.
Amikor viszont a regiszterek kapacitásánál nagyobb értékekkel dolgozunk, akkor a little-endian jobb. Lásd pl. 6502, amikor 16 vagy nagyobb értékeket csinálsz, akkor is felfele gondolkodsz, de az én kódomon is látszott, hogy az összefűzött számoknál az ember little-endianban gondolkodik.
Szóval attól, hogy a szarházi intel is ezt választotta, attól még lehet valamire jó. :)
|
AliveMOon
Tag
|
# Elküldve: 2011. Feb. 26. 17:52 - Szerkesztve: alivemoon
Kicsit arra emlékeztet ez a dolog, miként a koordináta rendszerek természetesen y+ az felfele van viszont a képernyőn memoria szervezés, a tv-k miatt megfordult. Viszont a a modern GPU-k nál megint vissza fordult , a képernyő bal felső sarka a -1, +1, jobb alsó sarok a +1,-1.
Tehát 68k-n ha olyan feladat lenne, hogy bővíthető méretre lenne szükségem, egyszerüen megcserélném a szervezését, az igényelt memoria végére pakolnám a cuccokat és semi nem kadályozza meg, hogy dekrementáltan lépkegyem az elemeken.
68k sokkal rugalmasabb és nem igazán hátrány.
|
TCH
Tag
|
# Elküldve: 2011. Feb. 26. 19:49
Nem azt mondtam, hogy a 68k-nak nem mindegy, hanem azt, hogy az embernek nem mindegy a fordított helyiértékek esetében.
A 68k nyilván mindkét irányban lazán összefűzi, neki aztán mindegy. :)
|
TCH
Tag
|
# Elküldve: 2011. Júl. 13. 20:41 - Szerkesztve: TCH
Function StrToInt(_S: String; err: Pointer): LongInt; XAssembler;
ASM
movea.l 8(sp), a0
moveq #0, d0
moveq #0, d1
move.b (a0)+, d1
moveq #0, d2
moveq #0, d3
moveq #0, d4
moveq #0, d5
moveq #0, d6
cmp.b #45, (a0)
bne @cty
moveq #1, d2
addq #1, a0
subq #1, d1
@cty: cmp.b #36, (a0)
bne @zscp
moveq #1, d3
addq #1, a0
subq #1, d1
@zscp: cmp.b #1, d1
beq @tys
@zsc: cmp.b #48, (a0)
bne @tys
addq #1, a0
subq #1, d1
cmp.b #1, d1
beq @tys
bra @zsc
@tys: or.b d3, d3
beq @dect
@hext: move.b (a0)+, d4
move.b d4, d5
cmp.b #48, d4
bmi @ice
sub.b #48, d5
cmp.b #58, d4
bmi @sbh
cmp.b #65, d4
bmi @ice
sub.b #7, d5
cmp.b #71, d4
bmi @sbh
cmp.b #97, d4
bmi @ice
sub.b #32, d5
cmp.b #103, d4
bmi @sbh
bra @ice
@sbh: asl.l #4, d0
bcs @ioe
or.l d5, d0
subq #1, d1
bne @hext
bra @ss
@dect: move.b (a0)+, d4
cmp.b #48, d4
bmi @ice
cmp.b #58, d4
bpl @ice
sub.b #48, d4
move.l d0, d5
asl.l #3, d0
bcs @ioe
asl.l #1, d5
add.l d4, d5
add.l d5, d0
bcs @ioe
subq #1, d1
bne @dect
bra @ss
@ice: moveq #1, d6
bra @ret
@ioe: moveq #2, d6
bra @ret
@ss: or.l d0, d0
beq @ret
or.b d2, d2
beq @ret
cmpi.l #$80000000, d0
beq @ret
bpl @ioe
not.l d0
addq #1, d0
@ret: movea.l 4(sp), a1
move.l d6, (a1)
move.l d0, 12(sp)
END; Ehun egy 32 bites StrToInt függvény, -2G-től +4G-ig konvertálja a stringet át egy 32 bites integerbe.
A visszatérési érték típusa itt előjeles, de át lehet írni egy mozdulattal előjel nélkülire, ha az kell, de tök mindegy, mert a bitek ugyanazok maradnak, ha annyira a másik típus kell, akkor átteszem egy olyan változóba az eredményt.
A függvény megeszi a hexa kódot is, csak akkor kell egy $ a szám elejére ($FA52).
Hexa is lehet mínuszos (-$F05).
TODO: Túlcsorulásnál (>4G || -2G>) és karakterhibánál egyelőre -1-et és -2-őt ad vissza, mert ahol kellett, ott nem voltak negatív számok, de ez így akkor sem jó, valahogy meg kéne hívni a HiSoft pascal megfelelő error rutinjait.
Lehet leszarni. :)
Sz*rk: CSÁÁÁÁÁÁRLÍÍÍÍ!!! PLÍÍÍÍZ VALAMI PRE BBCODE TAGOT GÁNYOJJÁMÁN A FÓRUMBA!
|
AliveMOon
Tag
|
# Elküldve: 2011. Júl. 13. 22:36 - Szerkesztve: alivemoon
Én hiba esetén is 0-lával térnék vissza, 0 helyett akkor elég tokeneket( vesszöket, pontokat ... ) használni. C-ben is csak addig mennek az str ciklusok mig van értelme, tehát ha 0-lával tér visza és egy byteot sem tudott értelmezni akkor van hiba.
char* p_str = p_begin;
izé = str_izé( p_str, &p_str );
if( *p_str == 0 )
{
vége a sztringnek;
}
else if( izé == 0 && p_begin == p_str )
{
hiba;
}
|
TCH
Tag
|
# Elküldve: 2011. Júl. 13. 23:37 - Szerkesztve: TCH
Pascalban nem létezik a string terminátor fogalma. Helyette a string 0. eleme a string hossza.
Itt is így van, hogy beolvassa a 0. elemet és az a hossza. Ha az 1. elem mínusz jel, akkor negatív flag beáll, továbbá egyel kevesebb elemet kell értelmezni. Ha az 1. vagy negatív szám esetén a 2. elem dollárjel, akkor hexa konverzió fog történni és megint egyel kevesebb elemet kell értelmezni. Utána a ciklus addig dobálja el a nullákat a string elejéről, amíg összefut egy nem nullával vagy a maradék string hossza egy (gy.k. '0').
Na utána a típusnak megfelelő (dec/hex) konverzió lefut, majd amennyiben negatív a szám akkor !szám+1 kivéve 0x80000000 esetén.
Ennyit csinál ez a függvény.
Sz*rk: Ettől persze még visszaadhatna 0-át hiba esetén, de hogy döntöm el, hogy hiba történt-e vagy sem?
Na ezt kéne valahogy kihámoznom a HSPascal unitokból, hogy hogy dob hibaüzenetet és állítja meg a futást.
Persze beírhatnám a két kérdéses helyre, hogy "illegal" és akkor ott runtime erroral elszáll a program, de ez milyen láma már. :P
|
Chain-Q
Divatamigás
|
# Elküldve: 2011. Júl. 14. 10:06 - Szerkesztve: charlie
@TCH:
Ehelyett: Function StrToInt(_S: String): LongInt; XAssembler;
Ez: Function StrToInt(_S: String; Res: PLongInt): LongInt; XAssembler;
Vagyis a vegeredmenyt nem visszaadja, hanem cim szerint atadott parameterbe tarolja el. Ekkor a visszateresi ertek siman hasznalhato ugy, hogy pl. pozitiv szam es nulla eseten megmondja, hogy a stringbol hany karaktert sikerult szamkent ertelmezni, negativ visszateresi ertek eseten pedig hibat jelezhet, vagy mittomen. :)
Egyebkent ez az egesz fuggveny egy elegge halalcsillagnak tunik nekem, szinte biztos vagyok benne, hogy meg lehet irni egyszerubben. Es abban sem vagyok biztos, hogy okos otlet hexa szamoknal a negativ elojelet hasznalni, leven pl. egy LongInt (elojeles) eseten az hogy $FFFFFFFF az mar onmagaban negativ, hiszen a legfelso bit 1, es ez nagy kavarodasokat okozhat.
|
TCH
Tag
|
# Elküldve: 2011. Júl. 14. 11:16 - Szerkesztve: TCH
Tényleg, ez jó ötlet. Bár valszeg fordítva lesz, hogy a hiba pointere lesz átadható és a visszatérési érték meg a szám, imho így logikusabb.
Köszi az ötletet. :)
---
Egyáltalán nem halálcsillag a függvény. Egyszerűbben? Ja, kiszedem a hexa részt és máris fele ekkora lesz, lévén a hexa résznél nem csak 48-57, hanem 48-57|65-70|97-102| karakterek érvényesek.
Lehet hogy egy-két dolgot valami trükkel ki lehetne egyszerűsíteni, de a funkciókat aligha (előjel, hex/dec típus, lead zero remove, karakterellenőrzés), mert ezekre szükség van.
De ha van valami ötleted akkor ne tartsd magadban, vevő vagyok mindenre. :)
A visszatérési típus meg opcionális; átírható, de akár előjel nélküli változóba is áttölthető; a bitek békénmaradnak, semmi nem veszik el: a felhasználás a programozóra van bízva, a végeredményt értelmezheti előjelesen is, meg nem is.
A hexa számoknál a negatív előjel nem hülyeség, a függvény -2G-től +4G-ig megeszik mindent és előjelhelyesen adja vissza, (le lett tesztelve) azaz oké, hogy ha a konvertálandó számban áll a legfelső bit és az alapból negatív, de egyrészt mint mondtam a visszatérési érték típusa képlékeny, másrészt ha negatív a szám, akkor mindenképpen negálni (!x+1) fogja, kivéve ugye -$80000000 esetén.
Ha meg arra gondolsz, hogy mi van dupla előjel ütközés esetén, akkor meg olyan nincs (kivéve a -$80000000 értéket, de az le van kezelve).
Ugyanis a függvény nem fogadja el azt, hogy -$FFFFFFFF, hanem overflowként kezeli. A tartomány amit megeszik: -$80000000 -> $FFFFFFFF, tehát ha te beírod neki, hogy -$80000001 akkor hiba van.
|
TCH
Tag
|
# Elküldve: 2011. Júl. 14. 17:53
Nnna, Csárli, implementáltam az ötletedet, Function StrToInt(_S: String; err: Pointer): LongInt; faxán müxik, thx. :)
|
TCH
Tag
|
# Elküldve: 2011. Okt. 31. 15:52 - Szerkesztve: TCH
68k véletlenszámgenerátor.srnd2:
move.l d0, d1
eor.l #$aaaaaaaa, d1
move.b d1, d4
asr.l #11, d1
rol.l d4, d1
move.l d1, d4
asr.l #21, d4
eor.l d4, d1
move.l d0, d2
eor.l #$55555555, d2
move.b d2, d4
asl.l #6, d2
ror.l d4, d2
move.l d2, d4
asr.l #22, d4
eor.l d4, d2
move.l d1, d3
asr.l #16, d3
move.l d2, d4
asl.l #16, d4
or.l d4, d3
movel. d0, __seed0
movel. d1, __seed1
movel. d2, __seed2
movel. d3, __seed3
rts
rnd2:
move.l __seed0, d0
move.l __seed1, d1
move.l __seed2, d2
move.l __seed3, d3
rol.l #5, d1
ror.l #9, d2
rol.l #11, d0
eor.l d1, d0
move.l d1, d4
rol.l #8, d4
asl.l #11, d4
eor.l d4, d0
move.l d2, d4
ror.l #8, d4
andi.l #63, d4
eor.l d4, d0
move.l d3, d4
rol.l #8, d4
asr.l #5, d4
eor.l d4, d0
ror.l #14, d0
eor.l d3, d0
eor.l d3, d1
eor.l d3, d2
ror.l d0, d3
movel. d0, __seed0
movel. d1, __seed1
movel. d2, __seed2
movel. d3, __seed3
rts
__seed0:
dc.l 0
__seed1:
dc.l 0
__seed2:
dc.l 0
__seed3:
dc.l 0
|
ratman
Kék troll
|
# Elküldve: 2011. Nov. 01. 16:18
"Bárki, aki aritmetikai módszerekkel akar előállítani egy véletlenszámot, a bűn állapotában leledzik." - Neumann János
|
TCH
Tag
|
# Elküldve: 2011. Nov. 01. 18:19
Ezt már Csárli is mondta. De ez nem igazi véletlen, hanem pszeudorandom, nem az a cél, hogy valóban véletlen számokat generáljon, hanem hogy ugyanabból az indító számból mindig ugyanazt a számsort generálja.
Mittudomén mondjuk térképgenerátorhoz vagy bármihez, ahol a "véletlenszámokat" reprodukálni kell, oda való.
|
TCH
Tag
|
# Elküldve: 2011. Nov. 01. 23:22
MOVE #$0002,28(A1)
MOVE.L #$00005400,36(A1)
MOVE.L #$00020000,40(A1)
MOVE.L #$00000400,44(A1)
JSR -456(A6)
JMP $20000
Ez egy bootblockban volt, valaki segítene megfejteni, hogy mi a nyavalyát csinál?
(Igen, ennyi volt benne, nem több, nem tudjuk mi van az A1 és A6-ban.)
|
Chain-Q
Divatamigás
|
# Elküldve: 2011. Nov. 01. 23:56 - Szerkesztve: charlie
@TCH:
Ez egy exec.library/DoIO hivas. Amigan minden floppylemez bootblock a kovetkezo regisztertartalommal kerul meghivasra:
A1 = a trackdisk.device IORequestjere mutato pointer
A6 = exec.library libbase
A -456-os offset az execben a DoIO() hivas. Elotte pedig feltolti az IORequestet, ami trackdisk.device eseten egy kiterjesztett IOStdReq struct (lasd: exec/io.h es devices/trackdisk.h).
A 28(A1) az io_Command mezo, ami esetunkben 2, ami nem mas, mint a CMD_READ, vagyis ez egy olvasas parancs, 36(A1) az io_Length mezo, amivel megadjuk a device-nek, hogy mennyit olvasson fel, 40(A1) az io_Data mezo, amivel megadjuk, hogy hova toltse az adatot, a 44(A1) pedig az io_Offset, ami megadja, hogy honnet olvasson. A hossz, es az offset mezo mertekegysege eszkozspecifikus, floppyn nem tudom mekkora.
Ezutan a JMP $20000 pedig egy fix cimre ugrik, ami ha megfigyeljuk, pont az a cim, ahova a trackdisk.device-szal betoltettuk a cuccot. Mas szoval ez annyit csinal, hogy betolt a floppy egy meghatarozott helyerol kodot, es aztan odaugrik.
Ha szabad megjegyeznem, nem tunik tul szofisztikalt kodnak, mivel hibat azt nem ellenoriz, es fix cimre is tolt ill. ugrik, ahelyett hogy memoriat foglalna, szoval ez valami durvan nem OS friendly cucc bootblokkja.
Kerdes? :)
|
TCH
Tag
|
# Elküldve: 2011. Nov. 02. 16:36
Hú kösz Csárli, isten vagy! :)
Azt én is gondoltam, hogy ez valami hóttprimitív betöltőrutin akart lenni, dehát a részletekről gőzöm nem volt (a JMP $20000 nekem is feltűnt, de a többit nem vágtam), szóval köszi. :)
Nem ez valóban nem egy OS friendly cucc, hanem egy trackloades game bootblockja. A lemez maga DOS-os, van is rajta egy 576kbyte reklám, de a program nem fáljrendszer szinten van jelen, hanem a blokkokba van behányva és most már azt is tudom, hogy hol. :)
Thx again.
|
TCH
Tag
|
# Elküldve: 2011. Nov. 02. 18:42
Kérdés:
A program elején a további adatblokkok betöltögetése mellett, találtam egy ilyet: MOVE #$0009,28(A1)
MOVE.L #$00000000,36(A1) Ez oké, hogy 0 hosszúsággal végrehajt egy CMD_NONSTD parancsot, de az micsoda? Mert a gugliban csak forrkódokat találtam, ahol használják ezt a parancsot, de leírást nem, hogy mire.
|
TCH
Tag
|
# Elküldve: 2011. Nov. 02. 22:52
Csárli, meg tudod nekem mondani, hogy asm-ben hogy csukjuk be a WB screent?
Gondolom intuition kinyit és closescreen meghív, de mit és hogy adunk át?
|
Chain-Q
Divatamigás
|
# Elküldve: 2011. Nov. 03. 08:31 - Szerkesztve: charlie
Bakker, mindenhez en ertsek? :)
1., CMD_NONSTD: ez csak egy offszet, vagyis innen felfele kezdodnek minden device sajat parancsai. Mint mondtam, devices/trackdisk.h:
#define TD_MOTOR (CMD_NONSTD+0) /* control the disk's motor */
Vagyis jo esellyel az a parancs kikapcsolja (vagy valami mast muvel vele) a lemezmeghajto motorjat.
2., Workbench becsukasa: intuition.library/CloseWorkBench() hivas. Van parja is: OpenWorkBench(), amivel a program kilepesekor illik visszanyitni a cuccot. Mivel a CloseWorkBench() eleg sok esetben elfail-elhet, es hibaval, valamint nyitva maradt WB screennel terhet vissza, ezert olvasd el a manualjat. Es ne probald korbehekkelni az altalad leirt modon, mert semmilyen program (igy a WB sem) szokott tul halas lenni, ha szo nelkul kirantjak alola a kepernyojet... :)
|
YADA
Tag
|
# Elküldve: 2011. Nov. 03. 14:27
Igen! Erts! :)
De a trackdisk is byte alapon szamolja az adatokat/offsetet. Csupan annyi a megkotes hogy szektor meretre es hatarra kerekitett blokkokat kezel (ertelemszeruen).
En mar csak az emlekeimbol elek, de a bootblock kapasbol ismeros volt (kb a pinball bootblockja is azonos az emlekeim szerint, meg kb minden regebbi jatek)
Kellene a mai ifjusagnak egy jo amigas programozoi tutorial. (nekem sem artana az teny, fejbol nehez kodolni, ez nem olyan rendszer) Kicsit oop szeru a dolog, de assembly szinten megvalositva. Nem veletlen hogy aki az amigahoz ert, az minden mast rohogve (esetleg horogve) kezel.
|
TCH
Tag
|
# Elküldve: 2011. Nov. 03. 15:01
Köszi Csárli, már egész jól haladok.
Egy kérdés van még, hogy lehet-e egy programnak megmondani azt, hogy hova töltődjön? (Hunk header vagy ilyesmi.) Akár pontos pozíció, akár csak annyi, hogy chip/slow/fast ram?
|
YADA
Tag
|
# Elküldve: 2011. Nov. 03. 16:49
Persze hogy lehet, erre a celra (is) szolgalnak a Hunk-ok.
Vagy siman dinamikus memoria keressel lefoglalod a szukseges memoriat es utana bemasolod a megfelelo adatot (kod eseten a cpu cache kezelese keresztbe tehet)
A google kellemes talalatokat ad az "amiga hunk types" szavakra keresve.
|
TCH
Tag
|
# Elküldve: 2011. Nov. 03. 17:30
Én is nézegettem már ezeket, de sajnos nem találtam meg, hogy hogy lehet a betöltési címet beállítani valahova.
|
YADA
Tag
|
# Elküldve: 2011. Nov. 03. 19:18
Alapvetoen a fix toltesi cim hasznalata a hibas programozasi gyakorlat egyik ismertetojele. Ha fix cim kell, kerd el szepen a rendszertol, ha nem kapod meg, akkor az a cim mar foglalt, igy kar is probalkozni vele.
|
