Hírek | Archívum | Fórum | IRC | Amiga | AmigaOS | FAQ | RSS

 - Fórumok - Keresés - Statisztika - Szabályzat - Pegasos.hu fórum
forum.amigaspirit.hu / Fejlesztés / Általános fejlesztési kérdések
<< 1 ... 9 . 10 . 11 . 12 . 13 . 14 . 15 . 16 . 17 . 18 . 19 ... 24 . 25 . >>
Szerző Üzenet
Yellow Dog
Tag

# Elküldve: 2019. Dec. 04. 17:41


Nincs mit, én ezen adatok alapján gondoltam, hogy érdemes egy próbát tenni, noha titkon nem bíztam benne, hogy az én áramkörömmel megközelíthetőek ezen értékek, de nekem is kellemes meglepetés lett az eredmény. És még van optimalizálási lehetőség, pl. most 512 bájtonként megy a küldés mivel a DOS írás és olvasás is ekkora mérettel dolgozik, ill. a művelet alatt jelenleg nincs további adat küldés az USB-n. Ezen is lehetne változtatni, aztán nagyobb csomag méret is hozhat (pozitív) változást és még ott van a kódban a hurok optimalizálás, bár ez irányú próbák eredménye nem hozott látványos sebesség növekedést. Véleményem szerint a folyamatban a lemezre történő írás és onnan való olvasás rendszerfüggvényei emésztik fel a legtöbb időt. Látszik is, ha csak simán a memóriába írok, lényegesen nagyobb az elérhető sebesség, míg a DOS funkciók használatakor rendesen leesik az értéke.
Érdekes volna egy turbo kártya teszt, mit tud maga a hardver maximálisan.

Yellow Dog
Tag

# Elküldve: 2019. Dec. 07. 21:55


Próbálkozom, próbálkozom, de nem akar összeállni a copy funkció... Nevezetesen, a már itt feltett kérdésemre és az arra kapott válaszra (rekurzív függvény/szubrutin hívás) szeretnék kérni/kapni egy folyamatábrát amelyet le tudnék programozni.
Köszönöm

(Szerk: ez meg mindig ide tartozik, nem a szoftver problemak topicba, szoval atraktam - a moderator)

Yellow Dog
Tag

# Elküldve: 2020. Jan. 15. 17:06 - Szerkesztve: yellowdog


Szeretném kikérni a véleményeteket a képeken látható betűtípusokkal kapcsolatban. A program egy a PC-n futó TC szerű kliens (lesz...), Amiga kapcsolattal, ezért gondoltam megpróbálkozom a Topaz8 betűtípussal is... Bevallom, nekem tetszik, de érdekelne a véleményetek, a többségi vélemény.

Topaz8 betűtípus

Courier betűtípus

Dr.OG
Tag

# Elküldve: 2020. Jan. 15. 17:42


Nekem a fölső tetszik jobban.

siz
Tag

# Elküldve: 2020. Jan. 15. 19:01


Én bevallom nem szeretem az egyik platformra ráerőltetett más platformos dolgokat. (*) Ennek megfelelően (bármennyire is Amiga adatátvitelről van szó) én már nem szívesen néznék Windows-on raszteres betűtípusokat. Sőt, valszeg ebben az ablakban még monospace-t sem (megvan annak is a helye, pl. forráskód szerkesztésnél, de itt igazából nem ad hozzá semmit, cserébe viszont kevesebb karakter fér ki)

* erre "legszebb" példa a Windows-os QuickTime vagy az iTunes, de sok ilyen van még.

YADA
Tag

# Elküldve: 2020. Jan. 15. 23:15


Az also jobb.

dino
Kék troll

# Elküldve: 2020. Jan. 16. 07:11


yellowdog
ne hasznalj vindozt mer szar... :)
legyen meg a mindennapi frissitesed :) ammen

Yellow Dog
Tag

# Elküldve: 2020. Jan. 16. 10:02 - Szerkesztve: yellowdog


Köszönöm a visszajelzéseket, mondjuk a "ne hasznalj vindozt mer szar... :)
legyen meg a mindennapi frissitesed :) ammen" információt nem igazán tudom mire véljem és miként építsem be a munkámba... dino úr, ezt kifejthetnéd bővebben ;-)

Szóval mint írtam, nekem tetszik az Amiga betű típus, hiszen minden más a hagyományos Windows megjelenés, viszont a praktikum a használhatóság rovására megy egyértelműen, nagyon kevés a megjeleníthető karakter, ahogyan egyébként a Courier esetében is :-( Jó volt eljátszadozni a lehetőséggel, de valószínűleg marad az alap, esetleg Options-be mehet egy választási lehetőség, majd meglátom...

Chain-Q
Divatamigás

# Elküldve: 2020. Jan. 19. 11:23


Ne hasznalj bitmap fontot a GUI-hoz, mert aki nagy DPI-s kijelzon nezi, beszop. Ha azt akarod h. a PC oldal az Amigara emlekeztessen, basszal ki valami logot v. boingballt az egyik sarokba, ahogy a GUI-n van hely.

De amugy az ilyesmi csak idegesito. Szvsz. Nem mintha Vindozos ware barmilyen szinten eritene, szoval csak szeretetteljes feedback. :)

dh1
Mr. DTP

# Elküldve: 2020. Jan. 19. 13:44


Jah, van vektoros topaz

Yellow Dog
Tag

# Elküldve: 2020. Jan. 19. 16:39


Quoting: dh1
van vektoros topaz

Igen, kipróbáltam :-) De hajlok a windózos kinézetre a használhatóságot előtérbe helyezve, alap betűtípus alkalmazással, illetve lehet azért lesz opciósan topaz is. És valamilyen grafika valóban jó lenne mindenképpen, utalás az Amiga kapcsolatra.

Yellow Dog
Tag

# Elküldve: 2020. Jan. 24. 02:16 - Szerkesztve: yellowdog


Quoting: charlie
egyebkent a DOS belso pointerlistajan kell vegigmenni Forbid/Permit kozott... Reszletek a 2.0-tol hasznalhato dos.library/LockDosList() fuggveny manualjaban vannak, ahol van egy 1.3-mal kompatibilis rovid pelda is, ami legalabb koncepcio szintjen hasznalhato:

Próbálkozom, de a példa lévén, hogy C szinte értelmezhetetlen, illetve nagyjából a már használt DOS hívások analógiáját követve átalakítottam asm formátumba, de a LockDosList a D1-ben mindig nulla értéket ad vissza. Próbálkoztam a Forbid - Permit párossal, de ha csak egymást követően írom a programba is, azonnali fagyást eredményez. Kipróbáltam az AttemptLockDosList funkciót is, de az eredmény ugyanaz. Ha valakinek volna ötlete, megköszönném, mert 23:00 óta sz.pok ezzel a sz.rral, már bocsánat... ;-)

A programrész amelyet egy működőbe illesztettem:

MOVE.L #4,d1
CALLDOS LockDosList
MOVE.L d0,$550000

CALLDOS UnLockDosList

Chain-Q
Divatamigás

# Elküldve: 2020. Jan. 26. 04:36 - Szerkesztve: charlie


Próbálkozom, de a példa lévén, hogy C szinte értelmezhetetlen,

Mi értelmezhetetlen rajta? Mit nem értesz? Értem, hogy nem tudsz se C-ben, se angolul, de a példa _ÖT_ sor. És leginkább pszeudokód, mert nem korrekt C. :) De azért abban nincs olyan sok mágia. (Oké, a v1.3-on is működő verzió sokkal fájdalmasabb, de azért az sem felfoghatatlan.)

de a LockDosList a D1-ben mindig nulla értéket ad vissza.

A LockDosList, a D1-ben nem ad vissza semmilyen értéket, soha. A LockDosList visszatérési értéke a D0 regiszterben van. Megint alapismeretek hiányoznak - ismerni kéne ugye az AmigaOS alacsony szintű hívási konvenciókat - a D0/D1 és A0/A1 regiszterek ún. "scratch" regiszterek, ergó a meghívott függvény tetszőlegesen módosíthatja őket. Szóval semmi garancia nincs rá, hogy mi van a D1-ben a LockDosList ill. akármilyen függvény visszatérése után, de jó eséllyel nem az amit korábban beleraktál. A visszatérési érték OS függvények esetén pedig mindig a D0-ban van, sehol máshol, ha mégis valami használhatónak tűnő érték van másik regiszterben akkor véletlenszerűen van ott, és ne használd, mert más OS verzión eltörhet. Sőt, szinte biztosan eltörik. Nincs ha, meg de. Pont.

Szóval az UnlockDosList-nél szintén újra kell tölteni ugyanazokat a flageket, a D1-be, nyitásnak. (Értsd: oda is kell egy MOVE.L <flags>,D1 a CALLDOS UnLockDosList elé.)

Emellett a LockDosList/UnLockDosList-nek mindenképpen meg kell adni vagy az LDF_READ vagy LDF_WRITE flaget, hogy a rendszer tudja, éppen milyen célból kell lockolnia a listát. Az ok baromi egyszerű - multitaszkos rendszerről beszélünk, ergó az nem gond ha egyszerre több taszk is akarja olvasásra lockolni a listát, de egyszerre csak egy taszk módosíthatja, és csak akkor, ha éppen nem olvassa senki. Ennek a taszkok-közötti "forgalomirányításához" szükséges ez a Flag is - meg kell mondanod az OS-nek hogy mit akarsz a listával. Lásd lent, a példa assembly kódban.

Aztán nem akarom tudni, miért tárolod el a LockDosList által visszaadott pointert D0-ból egy fix random címre, de az sem tűnik annyira jó ötletnek...


Tessék, példának álljon itt mit fordít a Free Pascal (a másik topicban már linkelt függvényből):

# [634] List := LockDosList(LDF_DEVICES or LDF_READ);
move.l _DOSBase,a6
moveq.l #5,d1
jsr -654(a6)
move.l d0,a2

# ^^^^^^^^
# A compiler az A2 regiszterbe teszi a List valtozot, ami a LockDosList
# visszateresi erteke. Ez azert jo, mert az AmigaOS hivaskonvenciok
# alapjan, az A2 regiszter erteke mindig megorzesre kerul a
# fuggvenyhivasokban (hacsak a regiszter nem hasznalt bemeneti
# parameterkent), az OS hivasokat is beleertve.
# Egyebkent ez minden integer es address regiszterre igaz a mar
# emlitett scratch regisztereket, es a library base A6-t leszamitva.
# A fordito ismeri ezt a konvenciot, es az elso meg nem hasznalt
# "garantaltan megorzott" regisztert fogja valasztani.

#ciklus eleje
.Lj346:
# [637] List := NextDosEntry(List, LDF_DEVICES);
move.l _DOSBase,a6
moveq.l #4,d2
# itt mar nem kell a READ/WRITE flag, csak lock/unlockolashoz
move.l a2,d1 # a2 itt bemeneti parameter, azaz a List valtozo, betesszuk a d1-be
jsr -690(a6)
move.l d0,a2
# a visszateresi ertekkel felulirjuk a2-t, lasd fent az ertelmezest

# [638] if List <> nil then
tst.l a2
jeq .Lj350


# Ha a lista ezen eleme nem null, akkor kiolvassuk a
# device nevet tartalmazo BSTR-re mutató BPTR pointert, a DosList strukturabol
# Ezek a tipusok a BCPL oroksegei, amiben az AmigaDOS-t eredetileg irtak...

# [640] Temp := BSTR2STRING(List^.dol_Name);
move.l 40(a2),d0 # BSTR pointer kiolvasasa a strukturabol.
lsl.l #2,d0 # BPTR to normal pointer konverzio, beszorozzuk 4-gyel
move.l d0,a0 # cimregiszterbe tesszuk, hiszen innentol valid pointer
addq.l #1,a0 # az elso karakter tarolja a hosszt BSTR eseten, atugorjuk

# itt most a0 a device nevere mutato pointer, ahol zero-terminalt stringkent talalod,
# masold oda ahova akarod, -1(a0)-nal, 1 byteon van a hossza, ha kell.
# nyilvan ekozben ne ird felul az a2 regisztert lehetoleg, mert a ciklusnak szuksege van ra.

### innen kiszedtem egy rakas lenyegtelen trutymot, ami nem kell neked

# ciklus vege
.Lj350:
# [645] until List = nil;
tst.l a2
jne .Lj346
# ha a lista ezen eleme nem null akkor vissza a kovetkezo NextDosEntry hivasra

# [646] UnLockDosList(LDF_DEVICES or LDF_READ);
move.l _DOSBase,a6
moveq.l #5,d1
jsr -660(a6)



Az elmélet kb. FindDosEntry-vel is tökugyanez, csak a NextDosEntry helyett nyilván azt kell meghivni, es át kell neki adni a keresett nevet is a D2 regiszterben, ill. ott a Flagek a D3-ba mennek. Bár nem tudom ha ismered a nevet, akkor minek keresnél rá, hacsak nem valami más infó kell a struktúrából.

Kérdés?

Yellow Dog
Tag

# Elküldve: 2020. Jan. 26. 11:50


Na akkor először is elnézést, nem volt szándékos a D0-t véltlenül elirtam D1-re. Amint láttad a példakódomban is azt használom. A fix címre tárolás azért van csak, hogy a kód lefutását követően lássam mi jött vissza. Egyébként az http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_2._guide/node02C7.html oldalt és a hozzá kapcsolódókat tanulmányozom, abból kiindulva kezdtem neki a programrész megírásának.
Na úgy látom a moveq.l #5,d1-nél csesztem el, nálam ugye #4 érték volt megadva. Bogarászom a dosextens.i tartalmát és próbálom értelmezni, de honnan a fenéből kellett volna tudom, hogy a 0 READ és 1 WRITE az biteket jelent és nem a 0-ás bit értékét? Benéztem na, tényleg, hiszen a 4-es érték a DEVICE amit szeretnék kiolvasni az pedig a kettes bit, az evidens volt. Szerintem 50 felé (3 hónap) ennyi szenilitás már belefér, ne kövezzetek meg érte :-)

Quoting: charlie
itt mar nem kell a READ/WRITE flag

Na például ez sem derül ki a fent említett oldalon a NextDosEntry leírásából, igaz úgy látom nem is okoz problémát ha be van állítva a READ bit.

Quoting: charlie
kiolvassuk a
# device nevet tartalmazo BSTR-re mutató BPTR pointert, a DosList strukturabol
# Ezek a tipusok a BCPL oroksegei

Hát igen, itt van a rákfenéje az egésznek, a számtech angollal elvagyok a 35 éves autodidakta tanulás eredményeként, de most leírtál 3db 4 betűs szót, amiket már ugyan olvastam nem egyszer, de igyekeztem is elkerülni, amennyire lehet, szóval ezekről fingom nincs mit jelentenek... :-D
Szóval én úgy tököltem ki a dolgot, hogy miután #5 értékkel már megjöttek az értékek, Shift + F12 (WinUAE alatt próbálom) és a debuggerben megnéztem ezen területek tartalmaznak-e értelmes információt, és igen a címekhez képest +65 címen találhatóak a nevek :-) Egyedül az első bejegyzésnél nincs semmi illetve a RAM Drive nevét nem találom...

Quoting: charlie
lsl.l #2,d0 # BPTR to normal pointer konverzio, beszorozzuk 4-gyel

Tehát ezt a részt illetve szükségességét nem teljesen értem, de ebéd utáni házi feladatnak veszem ;-) Nyilván itt van a trükk, amiért nálam +65-től indul a név és nem +$40 ahogyan a példádban olvasható.

Quoting: charlie
Kérdés?

Hirtelen kettő jutott még eszembe:

STRUCTURE DosList,0
BPTR dol_Next ; bptr to next device on lis
LONG dol_Type ; see DLT below
APTR dol_Task ; ptr to handler task
BPTR dol_Lock

STRUCT dol_VolumeDate,0 ; creation date (UNION)
STRUCT dol_AssignName,0 ; name for assign path (UNION)
BSTR dol_Handler ; file name to load if seglist is null
STRUCT dol_List,0 ; List of directories assigned (UNION)
LONG dol_StackSize ; stacksize to use when starting process
LONG dol_Priority ; task priority when starting process

STRUCT dol_LockList,0 ; outstanding locks (UNION)
ULONG dol_Startup ; startup msg: FileSysStartupMsg
; for disks

STRUCT dol_DiskType,0 ; 'DOS', etc (UNION)
BPTR dol_SegList ; already loaded code for new task

BPTR dol_GlobVec ; BCPL global vector

BSTR dol_Name ; bptr to bcpl name
LABEL DosList_SIZEOF

Ha már ilyen formában megtalálható a lista a dosextens.i-ben, hogyan tudom kiszámolni a bázishoz viszonyított címet, jelen esetben pl. a dol_Name $40 értékét illetve tényleg ki kell számolni, nem lehet a struktúra elemeire a nevükön hivatkozni? Szinte kizártnak tartom, hogy nem, de nem jövök rá a használat mikéntjére ASM-One-ben, mindig szintaktikai hibával megugatja, ha megpróbálom használni.

Második kérdésem: megvannak a nevek, de ezek valójában a Volume és nem a Device (DF0, DH0, stb) ezen utóbbiakat szeretném még megtudni, ahogyan az Info parancs is kilistázza őket. Jaj, majd elfelejtettem, DH0 után meg illő megemlíteni dh1-et is ;-)

És nagyon köszönöm a részletes leírást és a magyarázatokat! Ha elkészülök, mindenképpen említésre kerül, kiknek köszönhető, vagyis kik nélkül nem jöhetett volna létre :-)

u.i.: Nem vagyok egy profi programozó, de igyekszem ;-) viszont sajnos nem minden olvasható ki a hivatalos leírásokból.

Yellow Dog
Tag

# Elküldve: 2020. Jan. 26. 13:42 - Szerkesztve: yellowdog


Quoting: charlie
FPC függvény pont ezt csinálja, kigyűjti neked a device neveket egy tömbbe, hogy könnyebb legyen elérni... Dehát, gondolom ehelyett assemblyvel szívsz, mert miért is ne...

Mivel assemblyben kezdtem, igen. Egyrész szeretem, másrész, noha többször nekifutottam és végig néztem ezt az egyébként nagyon jó és érthető C kurzust, egyszerűen nem áll rá az agyam a szintaxisára, amikor pl. egy unmount.c-ben megláttam ezt a részt:
int i;
UBYTE *p = (STRPTR)args[ARG_DRIVE];
for (i=0; i<32; i++, p++)
{
name[i] = *p;
if (*p == '\0' || *p == ':')
break;
}
name[i] = '\0';

Na aki erre ránéz és egyből átlátja...
Persze tudom, vagy öreg vagyok én már ehhez, vagy egyszerűen hülye, vagy mindkettő :-D

Quoting: charlie
az ilyen bruttó 25 sor, ebből a lényegi rész, 12 sor

Próbálom értelmezni:
function AddDisk(const Path: string): Integer;
begin
// if hit border, restart at 4
if NumDevices > 26 then
NumDevices := 4;
// set the device
DeviceList[NumDevices] := Copy(Path, 1, 20);
// return the Index increment for next run
AddDisk := NumDevices;
Inc(NumDevices);
end;

function RefreshDeviceList: Integer;
var
List: PDosList;
Temp: PChar;
Str: string;
begin
NumDevices := 0;
AddDisk(':'); // Index 0
AddDisk('DF0:'); // Index 1
AddDisk('DF1:'); // Index 2
AddDisk('SYS:'); // Index 3
// Lock the List
List := LockDosList(LDF_DEVICES or LDF_READ);
// Inspect the List
repeat
List := NextDosEntry(List, LDF_DEVICES);
if List <> nil then
begin
Temp := BSTR2STRING(List^.dol_Name);
Str := strpas(Temp) + ':';
if not IsIllegalDevice(str) then
AddDisk(Str);
end;
until List = nil;
UnLockDosList(LDF_DEVICES or LDF_READ);
RefreshDeviceList := NumDevices;
end;

Szóval pár kérdés:

function Addisk végére miért kell az Integer?

AddDisk := NumDevices;
Inc(NumDevices);
itt gondolom az Inc növeli NumDevices értékét, de miért azt követően, hogy AddDisk-nek adtad az értékét? Nem fordítva kellene? Csak kédezem, nem vedd okoskodásnak.

AddDisk(':'); // Index 0
erre miért van szükség?

Látom, használod a dol_Name pointert, ezek szerint valahol megkapta a $40-et, de hol? Én végigkerestem az összes include állományom, de sehol nincs értékadás.

A többit azt hiszem értem :-) de még annyit, ha NumDevices > 26 miért kell 4-re állítani az értékét?

Köszönöm, tudom ez már C tanfolyam ;-)

siz
Tag

# Elküldve: 2020. Jan. 26. 14:01 - Szerkesztve: siz


Quoting: yellowdog
function Addisk végére miért kell az Integer?

Mert ez Pascal és a Pascal szintaxisa szerint a függvény visszatérési típusát a szignatúra végére kell írni.

Szerk: meg úgy általában az összes deklarációban is így van, hogy név: típus.

Chain-Q
Divatamigás

# Elküldve: 2020. Jan. 26. 14:19 - Szerkesztve: charlie


@Yellow Dog:
amikor pl. egy unmount.c-ben megláttam ezt a részt:
int i;
UBYTE *p = (STRPTR)args[ARG_DRIVE];
for (i=0; i<32; i++, p++)
{
name[i] = *p;
if (*p == '\0' || *p == ':')
break;
}
name[i] = '\0';

Na aki erre ránéz és egyből átlátja...


Ránéztem, átláttam.

p egy byte-ra mutató pointer, aminek az értéke az args tömbből jön. Ezután ciklus kezdődik, i ciklusváltozóval, ami 31-ig megy (addig, amig i kisebb mint 32), és minden iterációban növeljük i és p értékét. Ezután a név tömb i-edik elemébe rakjuk a p által mutatott értéket (a csillag feloldja a hivatkozást és az általa mutatott értéket jelenti, nem a mutatót). Ezután megvizsgáljuk, hogy az éppen feldolgozott karakter null karakter-e, vagy kettőspont-e, ha igen, megszakítjuk a ciklust, ha nem, következő iteráció jön (és i és p értéke növelődik). Majd a végén null karakterrel termináljuk a name "tömbbe" eltárolt stringet.

Elnézést, de ez kezdő szintű C kód, string másolása pointer által mutatott területről tömbbe, ebben végképp semmi sincs, ami bonyolult. De azt aláírom, hogy a kód olvasása folyékonyan ugyanolyan tudomány, mint az írása, és sajnos azt látom hogy a hálószoba-programozók zseniális kódokat tudnak írni, de a már mások által megírt kódok alapszintű értelmezése is problémát okoz, és frusztrációt, mert "túl van ez bonyolítva" pedig dehogy. Csak gyakorolni kell.

Chain-Q
Divatamigás

# Elküldve: 2020. Jan. 26. 14:50 - Szerkesztve: charlie


@Yellow Dog:
AddDisk := NumDevices;
Inc(NumDevices);
itt gondolom az Inc növeli NumDevices értékét, de miért azt követően, hogy AddDisk-nek adtad az értékét? Nem fordítva kellene? Csak kédezem, nem vedd okoskodásnak.

Az AddDisk ez esetben (az AddDisk függvényen belül) csak egy változó. Egyes Pascal dialektusokban a függvénynek úgy adsz visszatérési értéket, hogy a nevével megegyező, automatikusan létrejövő, csak a függvényen belül létező változónak adsz értéket. A NumDevices értéke azért növelődik az értékadás után, hogy az AddDisk következő hívásakor már a következő "szabad Disk slot"-ra mutasson, és az AddDisk azt a slot-ot adja vissza, amelyikbe a megadott disk éppen bekerült.

AddDisk(':'); // Index 0
erre miért van szükség?

Ez egy "shortcut", amit a Pascal library ad neked és itt készíti elő. Amigán a ":" valid drive név, és az aktuális drive gyökérkönyvárát jelenti. (Ez utóbbi nem Pascal specifikus, a library csak segít benne, próbáld ki Shell-ben, hogy "cd :", működik.)

Látom, használod a dol_Name pointert, ezek szerint valahol megkapta a $40-et, de hol? Én végigkerestem az összes include állományom, de sehol nincs értékadás.

A dol_Name egy struktúra eleme, _DECIMÁLIS_ 40 offsettel a struktúra elejéhez képest. Szóval List^.dol_Name azt jelenti, hogy a List pointerhez képest (ami ugye az OS-ből jön) dol_Name-nyi eltolással olvasunk ki értéket. A fordító megnézi a DosList struktúra definícióját, majd kiszámolja, hogy a dol_Name offszetje negyven byte struktúra elejéhez képest (amire a List pointer mutat) ezért az assemblyben automatikusan beírja ezt az értéket. Ez a lényeg. Nem kell kézzel offseteket drótozgatni, mert minek. (Amúgy egész biztos vagyok benne, hogy ezt assemblyben is lehet, mert ezt az offset-számítást az assemblerek is ismerik, ha gondolod majd megírom neked később, de most nem érek rá.)

de még annyit, ha NumDevices > 26 miért kell 4-re állítani az értékét?

Ez az egész AddDisk dolog egy nem túl elegáns hack. A nevezett példakód a Free Pascal "DOS" unitjának Amiga implementációjából jön. Csak visszafele kompatibilitáshoz jön, amúgy elavultnak tekintendő,.Arra szolgál, hogy az eredetileg DOS-ra és Windowsra írt Pascal kódok lefordíthatók legyenek Amigára, és ennek megfelelően max. 26 drive nevet kezeljen - mint az MS-DOS, az angol ABC 26 betűjének megfelelően. Azért 4-re vált, ha ez "túlcsordul", mivel az első 4-et (ötöt, nullától indexelődik) sosem akarjuk felülírni, hiszen azok fixek. Ahogy írtam, ez nem egy túl elegáns kód, az FPC 1.0-ból örököltük, de a használat céljának megfelel, szóval minek turkáljak benne.

Köszönöm, tudom ez már C tanfolyam ;-)

Pascal tanfolyam. :P Az FPC library-ja és maga a fordító is, önmagában van írva, azaz Pascalban.

Chain-Q
Divatamigás

# Elküldve: 2020. Jan. 26. 15:08 - Szerkesztve: charlie


@Yellow Dog:
de honnan a fenéből kellett volna tudom, hogy a 0 READ és 1 WRITE az biteket jelent és nem a 0-ás bit értékét?

AmigaOS fejlesztői terminológia - A konstans nevéből könkrétan. Mivel az "LDF"-ben ott az "F", tudni lehet, hogy ez egy "field" vagyis mező érték, ergó magát a bitmaszkot jelenti. Van egyébként LDB_READ is, ahol a "b" bitet jelent, ergó az jelenti magát a bit sorszámát. Ebből a kettőből elég könnyen rá lehet jönni, és konkrétan 100%-ig biztos vagyok benne, hogy ezt a terminológiát valahol részletezi a manual is. (De most hirtelen nem találom és nincs rá időm megkeresni.)

de most leírtál 3db 4 betűs szót, amiket már ugyan olvastam nem egyszer, de igyekeztem is elkerülni, amennyire lehet, szóval ezekről fingom nincs mit jelentenek... :-D

BCPL - programozási nyelv, bizonyos szempontból a C elődje, a hetvenes években, nyolcvanas évek elején volt bizonyos mértékben "népszerű". Az AmigaDOS alapját adó Tripos operációs rendszert BCPL-ben írták. Ez egy külső fejlesztés volt, mert az eredeti Amiga team által írt DOS rendszer nem készült el időben. A BCPL nyelv egyik jellemzője, hogy minden mutatót 4-gyel osztható címre igazított, és ezt annyira megtette, hogy a mutatók alsó két bitjét el sem tárolta. Így a C/assembly és a BCPL kódok közötti átjáráskor a mutatókat konvertálni kell, vagy 4-gyel való szorzással, vagy 4-gyel való osztással, irányfüggően.

A BPTR egy BCPL pointert jelent. Közvetlenül nem hivatkozhatsz rá, előtte szorozni kell néggyel. A BSTR egy BCPL stringre mutató BCPL pointert jelent. A BCPL stringek annyiban speciálisak, hogy maximum 256 karakteresek lehetnek, és az első byte-on van tárolva a hosszuk. Amigán emellett az összes BCPL string zéró terminálva is van (amennyire tudom, FIXME), hogy a C és a BCPL kódok közötti átjárást megkönnyítse.

Az AmigaDOS-t a 2.0 környékén jórészt újraírták C-ben, de a bináris kompatibilitás miatt az API-ban és a struktúrákban megmaradtak a BCPL típusok, másként a korábbi programok nem működtek volna. Ha nem akarsz ezzel szarakodni, akkor a legegyszerűbb megoldás valami magas szintű nyelv megtanulása, ami ennek a többségét elrejti előled...

Nyilván itt van a trükk, amiért nálam +65-től indul a név és nem +$40 ahogyan a példádban olvasható.

Először is, nem, elég biztos vagyok benne, hogy a példámban DECIMÁLIS negyven az offset. Ezért gyűlölöm a kezdő assembly programozók hozzáállását, mert egyből a memóriamonitort nézegetik, ahelyett h. megpróbálnák megérteni, hogy mi történik. A dol_Name címen lévő BPTR meg fogja neked mondani, hogy honnan olvasd ki a nevet. Nem kell kézzel drótozni offseteket meg semmit. Valszeg merő véletlenségből van ott a név, és csak az AmigaOS dinamikus memóriafoglalásának eredménye. A rendszer először a DosList struktúra helyét allokálja a memóriában, majd a BCPL string-hez szükséges területet. Ezért ezek egymás után helyezkednek el _LEGTÖBBSZÖR_ de erre __SEMMI__ garancia nincs. Valszeg ezért nem találod a RAM Disket sem. Szóval mindenféle idióta mágikus offsetek keresése helyett olvasd ki a DosList struktúra DECIMÁLIS negyvenedik offsetjén lévő DWORD értéket, és szorozd be néggyel (shifteld kettővel), így kapsz egy pointert, ahol ott lesz a név. Az első byte-ját át kell ugrani, mert az a hossz. Kész. Ezt csinálja az FPC által generált kód is. Ott van. Copy-Paste AsmPro-ba, működik, tényleg. Komolyan, szeretnék segíteni, de olyan érzés mintha minden alkalommal direkt a rossz megoldást erőltetnéd, valami hardverprogramozós assembly berögződésből.

viszont sajnos nem minden olvasható ki a hivatalos leírásokból.

Viszont sokkal több minden kiolvasható lenne, ha a rendszer működését és terminológiáját próbálnád először megérteni, mint ráerőltetni valahogy amit akarsz. Mert a BCPL pointerek működésétől kezdve a BIT vs. FIELD terminológiáig elég sok minden benne van, amit itt leírtam neked. Én sem a kisujjamból szoptam.

Yellow Dog
Tag

# Elküldve: 2020. Jan. 26. 15:56


Quoting: charlie
Pascal tanfolyam. :P

Igen, közben siz írását olvasva leesett, talán azért is sikerült már amennyire átlátnom, jó, hogy nem C-ben írsz... :-)

Quoting: charlie
Pascal dialektusokban a függvénynek úgy adsz visszatérési értéket, hogy a nevével megegyező, automatikusan létrejövő, csak a függvényen belül létező változónak adsz értéket

Értem, közben tanulmányoztam és nekem is ez tűnt logikus magyarázatnak.
Quoting: charlie
A dol_Name egy struktúra eleme, _DECIMÁLIS_ 40 offsettel a struktúra elejéhez képest. Szóval List^.dol_Name azt jelenti, hogy a List pointerhez képest (ami ugye az OS-ből jön) dol_Name-nyi eltolással olvasunk ki értéket

Igen, ezt így gondoltam én is, arra próbáltam rákérdezni, hol, melyik include fájlban tárolódik a $40 hozzárendelés, mert nekem TC-vel átnézve a tartalmakat egyikben sem találok ilyesmit, gondolom emiatt ugatja meg fordításkor az ASM-One. Néhány átnézett forrásban megtaláltam, ott a programok elején deklarálva van (ha jól írom) de gondolom ezek is össze vannak szedve valamilyen fájlban. Egyet találtam a neten symbol.inc néven, de a szintaxisa nem megfelelő. A telepített SASC mert bizony fent van a gépemen... ;-) include fájljaiban sem találom egyébként.

Quoting: charlie
ez nem egy túl elegáns kód,

Ez tecccik :-)

Quoting: charlie
Pascal tanfolyam. :P

Igen, benéztem, amikor siz hozzászólását olvastam, már láttam, de már nem akartam átírni.


A maradék részt a 4 betűs szörnyűségeket eddig kerültem, most azok jönnek, és ígérem ma már nem zavarkolódok :-)

Quoting: charlie
olyan érzés mintha minden alkalommal direkt a rossz megoldást erőltetnéd, valami hardverprogramozós assembly berögződésből

Ezt úgy érzem, tökéletesen látod... ;-)

Chain-Q
Divatamigás

# Elküldve: 2020. Jan. 26. 16:10


@Yellow Dog:
Igen, ezt így gondoltam én is, arra próbáltam rákérdezni, hol, melyik include fájlban tárolódik a $40 hozzárendelés, mert nekem TC-vel átnézve a tartalmakat egyikben sem találok ilyesmit, gondolom emiatt ugatja meg fordításkor az ASM-One

Nem tudom fejből az assembly szintaxist, de nem szükséges, hogy lásd hogy ez "40" akárhol is. Egyszerűen a struktúradeklaráció így adja ki, magas szintű nyelveken legalábbis biztosan. A struktúráid elemei abban a sorrendben lesznek a memóriában ahogy a deklarációid vannak, minden deklarációnak megadott a mérete, így az offszetjük automatikusan kiszámítható. A jobb assemblerek ugyanígy dolgoznak. A rosszabbak valóban úgy, hogy minden elem offsetje egyesével le van deklarálva, de az elég fájdalmas... Este elindítom az AsmProt és kitalálom hogy mi kell hozzá asmban, ha addig neked nem megy.

Yellow Dog
Tag

# Elküldve: 2020. Jan. 26. 16:15


Quoting: charlie
az első byte-on van tárolva a hosszuk

Na csak még ezt, lásd, hogy próbálom értelmezni a dolgokat és látni az összefüggéseket :-) akkor megvan az ok amiért a memóriában a név nem $40-től látszik, a $40-esen van a név hossza tárolva, valóban :-)
Oké, próbálom elengedni ezt az utat, csak érdekességként említettem ;-)

Yellow Dog
Tag

# Elküldve: 2020. Jan. 26. 16:17 - Szerkesztve: yellowdog


Quoting: charlie
Egyszerűen a struktúradeklaráció így adja ki, magas szintű nyelveken legalábbis biztosan. A struktúráid elemei abban a sorrendben lesznek a memóriában ahogy a deklarációid vannak, minden deklarációnak megadott a mérete, így az offszetjük automatikusan kiszámítható. A jobb assemblerek... Este elindítom az AsmProt és kitalálom hogy mi kell hozzá asmban, ha addig neked nem megy.

Értem, logikus valóban. Köszönöm, de csak ha időd engedi, tényleg nem akarom túlfeszíteni a "húrt" :-)

szerk.:
Betettem include-ok közé a dos/dosextens.i-t, ebben található a DosList struktúra és valóban hiba nélkül lefordítja az ASM-One, köszönöm a rávezetést :-)

Mára tényleg befejeztem a firkálást, megyek programozni(?)...

Yellow Dog
Tag

# Elküldve: 2020. Jan. 26. 21:55 - Szerkesztve: yellowdog


Lefekvés előtt...

* Flags to be passed to LockDosList(), etc
BITDEF LD,DEVICES,2
BITDEF LD,VOLUMES,3
BITDEF LD,ASSIGNS,4
BITDEF LD,ENTRY,5
BITDEF LD,DELETE,6

gyakorlatilag mindegy melyiket állítom be, minden esetben ugyanazt a (volume név) listát adja, így sajnos a DFx és DHx lista még mindig nincs meg... :-(

Chain-Q
Divatamigás

# Elküldve: 2020. Jan. 27. 07:56 - Szerkesztve: charlie


Fingom sincs, de tippelhetek? A flageket véletlenül csak a LockDosList/UnlockDosList párosban módosítod, a NextDosEntry-ben nem, ott mindig az LDF_VOLUMES marad, ezért azt is kapod.

Legalábbis nekem csak így sikerül reprodukálni a problémát.

Szerk: nyilván ez egy bug, mert olyanban turkálsz, amiről a rendszernek nem szóltál, hogy hozzáférnél, szóval ebből nem az a konzekvencia, hogy "akkor nem is kell lockolni", hanem hogy "most véletlenül működik, ebből lesznek a százból egyszer fagyást okozó lenyomozhatatlan bugok". Érted.

(Szerk #2: már megérte nekem is ezzel foglalkozni, lőttem egy Free Pascal bugot a fentiekkel - az AmigaDOS unitban hibás volt a DosList struktúra egy pár platformon, emiatt a dol_Name mező rossz offsettel került kiszámításra. A hiba a fenti DOS unitot nem érinti, az egy másik headerből dolgozik. MorphOS-en eddig is jó volt, az AROS-on ugy en-bloc hiányzik ez a mező (???), OS4-en szintén bugosnak tűnik, de azt nem tudom tesztelni. Egyelőre kijavítottam a classic DosList struktúrát, ott most működik, a többi rendszerre majd visszatérek, meg szólok Marcusnak...)

Yellow Dog
Tag

# Elküldve: 2020. Jan. 27. 10:32


Quoting: charlie
már megérte nekem is ezzel foglalkozni, lőttem egy Free Pascal bugot a fentiekkel - az AmigaDOS unitban hibás volt a DosList struktúra egy pár platformo

Na ennek örülök, úgy értem, hogy hozzájárultam ha csak ilyen módon is egy hiba megszüntetéséhez :-)

Quoting: charlie
módosítod, a NextDosEntry-ben nem, ott mindig az LDF_VOLUMES marad, ezért azt is kapod.

Legalábbis nekem csak így sikerül reprodukálni a problémát.

Úgy érted, ha LDF_DEVICES-t állítottál be, a dol_Name pointer (vágom ám... ) ;-) a DH0:, DH1: stb szövegre mutat? Emlékeim szerint jól paramétereztem a NextDosEntry-t de ez nálam nem jelent semmit, délután megnézem, ja és meglett a RAM Drive is.

Nem győzöm leírni, de ezer köszönet az eddigi segítségedért :-)

Időközben találtam egy érdekes fórum bejegyzést, ahol is az alábbiakat írják:
"So I am trying to figure out how to get the device name from a volume name in 1.3 (v34) friendly fashion.
From a volume name or from a lock? From a volume name, you need to iterate through the DosList twice (struct DosInfo *)(BADDR((DOSBase->dl_Root->rn_Info)))->di_DevInfo, documented in dos/dosextens.h (or libraries/dosextens.h in 1.3), then search for the entry whose dol_Name is identical to that of the volume you are looking for and whose type is doslist->dol_Type == DLT_VOLUME. From there, get doslist->dol_Task. Then iterate through the same list again, but this time check for doslist->dol_Type == DLT_DEVICE and whose doslist->dol_Task is identical to the pointer you found during the first scan. doslist->dol_Name is then the device name you are looking for, without a trailing colon."
Tehát gyenge angollal + google fordító ;-) próbálom értelmezni, ha doslist->dol_Type == DLT_VOLUME és dol_Name-ben a keresett DEVICE volume neve van, akkor doslist->dol_Task-ra van szükségünk (struct MsgPort). Innentől viszont nem értem mit kell újra olvasni, ugyanezt, tehát a NextDosEntry-nek nem adunk új értéked a D1-be és akkor a doslist->dol_Type == DLT_DEVICE lesz illetve a dol_Name mező pedig a DFx/DHx névre fog mutatni? Mondd, hogy jól látom :-) Persze nyilván nem, illetve nem tudom akkor mi a dol_Task-ra való utalás a szövegben.

YADA
Tag

# Elküldve: 2020. Jan. 27. 14:18


Azert ketszer mert igazabol ugyanabban a listaban keresel ket bejegyzest, az egyik pl. a volume nev, a masik a device nev. Mindegyik kulon bejegyzes alatt szerepel. A kozos bennuk a task. Masodik menetben a taskra keresel, de csak a device bejegyzesekre szurve.

Regen csinaltam ilyent - meg 1.3 alatt - egy speci text editorhoz. Kellett egy sajat file requester, de kello leiras nelkul tenyleg erdekes a feladat. Cserebe volt ideje beegni az ember agyaba, halvanyan meg most is emlekszem ra.

Azt a kodot parszor ujra irtam. Volt amos, C, pascal, asm verzio is belole.

Yellow Dog
Tag

# Elküldve: 2020. Jan. 27. 16:33 - Szerkesztve: yellowdog


Quoting: charlie
módosítod, a NextDosEntry-ben nem, ott mindig az LDF_VOLUMES marad

Igen, igazad volt, megint... Most szépen listázza a DFx, DHx elnevezéseket, úgy látszik a pálinka és a programozás nem haverok :-)

Quoting: Yada
Azert ketszer mert igazabol ugyanabban a listaban keresel ket bejegyzest, az egyik pl. a volume nev, a masik a device nev. Mindegyik kulon bejegyzes alatt szerepel. A kozos bennuk a task.

A fentebb említett hibát korrigálva így már megvan a két listám, akkor már "csak" össze kell párosítanom őket. Átolvastam újra a linken az angol szöveget, és így már érthető, köszönöm az információt :-)

Chain-Q
Divatamigás

# Elküldve: 2020. Jan. 27. 17:01 - Szerkesztve: charlie


Úgy érted, ha LDF_DEVICES-t állítottál be, a dol_Name pointer (vágom ám... ) ;-) a DH0:, DH1: stb szövegre mutat?

Nálam igen. Kipróbáltam.

Szerk: bocs, most láttam hogy már válaszoltál, nem frissítettem a fórumot.

Yellow Dog
Tag

# Elküldve: 2020. Jan. 31. 14:36


Quoting: charlie
tst.l a2

Ez addig volt jó, amíg 020-ra fordított az ASM-One. Gondoltam a későbbi szopást megelőzendő, még időben átváltok 68000-ra és minddjárt meg is ugatta, dokumentáció szerint jogosan. Átírtam az alábbi módon:

move.l a2,d0
tst.l d0

Működik de megkérdezném azért jó-e így, vagy van gyorsabb/tömörebb/szebb megoldás?

<< 1 ... 9 . 10 . 11 . 12 . 13 . 14 . 15 . 16 . 17 . 18 . 19 ... 24 . 25 . >>
forum.amigaspirit.hu / Fejlesztés / Általános fejlesztési kérdések
 
 

Powered by forum software miniBB™ © 2001-2024