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 . >>
Szerző Üzenet
Chain-Q
Divatamigás

# Elküldve: 2019. Nov. 10. 12:45 - Szerkesztve: charlie


Én fenntartom, hogy egy szabadon válaszott szám (amit mellesleg az OS egyes komponensei is használnak, és csinálhatsz rá egy define-ot lásd diskfont) jobb mint ezt a fekete mágiás random struktura random mezőjéből leszármaztatott értéket beszorozzuk egy hasracsapó véletlenszámgenerátorral készült konstanssal, majd fekete kakast áldozunk felette kecskevérrel rajzolt pentagramm felett teliholdkor, és akkor az majd jó lesz. Hát pls no.

Szerk: amúgy valszeg egyikünknek sincs igaza, mert - kis túrás után - valszeg nincs a könyvtárak egymásbaágyazhatóságára limit Amigán (vicces módon - pont mint Linuxon). Legalább is a fájlrendszerek szintjén. Ergó a path elméletileg akármekkora is lehet. Más kérdés h. milyen rendszer és 3rd party komponens mennyire kezd el bugzani egy idő (ill. bizonyos méretú PATH hossz) után.

Szerk 2: Azt sikerült megerősítenem, hogy - legalábbis a MorphOS-féle dos.library-ben - nincs elvi path limit. Szóval akármekkora is lehet. Ha az eredeti amigás library-ban van valamiféle limit, akkor az nem by design van, hanem implementáció specifikus.

Szerk 3: Azt mondják a nálam hozzább értők, hogy az eredeti dos.library-ban 255 karakteres limitek vannak, mivel belül BSTR típusú stringeket (BCPL string) küldözget a dospacket API-ban, ami maximum 255 karakter lehet, mert hasonlóan a klasszikus Pascal stringekhez, az első byte-on van a hossz. És MorphOS-ben (ill. valszeg a többi next-gen rendszerben?) erre van egy backward compatibility hack/workaround/megoldás, hogy hosszabb utak is menjenek.

Szerk 4: Ill. valami rémlik, hogy az OS4 inkább kidobta a dospackets API-t valami Final Edition akárhányban, és helyette ott valami más van. De mivel most amiga-szerű rendszerekről van szó, ezért az OS4-et inkább hagyjuk figyelmen kívül... :P

Szóval ja. Sok hűhó semmiért után visszajutottunk oda, hogy classicon jó lesz az a 256-os bufferméret. Mivel BCPL.

AliveMOon
Tag

# Elküldve: 2019. Nov. 10. 13:36 - Szerkesztve: alivemoon


Ja ilyen 255-ös limitációt utoljára a Prezi dokisában találtam ott fogták a OS-ekre, hogy ők tudnának de hát a rendszerek sajnos nem sorry :) 256 = 8x32.
Akkor szerintem a linux/POSIX 4kbyte 128mélység x 32byte, sokkal jobb, nem egy horror méret.
Elég arra figyelni, hogy két '/' között ne legyen 30byte-nál több.

Yellow Dog
Tag

# Elküldve: 2019. Nov. 10. 14:20 - Szerkesztve: yellowdog


Köszönöm a tanácsokat!
Úgy néz ki a fájlnév valóban 108 lehet max. érdekes módon pl. a DOpus csak 30 karaktereset enged létrehozni illetve átnevezni sem tudja a hosszabb fájlneveket... A könyvtárak egymásba ágyazása, vagyis a path is megáll olyan 220 körül, 22db 10 karakterest engedett egymásban létrehozni, de ha mondjuk két karakteres a mappa neve akkor 33-ig próbáltam és engedte, szóval valószínűleg a darabszám nem, csak az úthossz korlátozódik egy bájtban leírható méretűre. (FFS rendszer)

szerk. ÉS ne öljétek egymást ;-)

siz
Tag

# Elküldve: 2019. Nov. 10. 15:08 - Szerkesztve: siz


Quoting: yellowdog
a DOpus csak 30 karaktereset enged létrehozni

Ebbe én is belefutottam régebben, csak már nem emlékszem, hogy mit kellett csinálni. Egyrészt DOpus valamelyik verziójánál volt fícsör, hogy támogatja a hosszabb neveket, másrészt meg mintha filesystem szinten kellett volna valamit állítani, de már nem emlékszem pontosan.
(Közben megtaláltam, itt egy thread róla)
Szerk: természetesen ez PFS3 esetén működik csak, FFS-nél passz (mintha azt írtad volna, hogy FFS-t használsz)

Yellow Dog
Tag

# Elküldve: 2019. Nov. 10. 15:27


Én a jó öreg DOpus 4-et használom és igen, FFS nálam a fájlrendszer. Lehet az 5-ös verzió már támogatja, de nekem az régen sem tetszett, csak egy próbát ért meg nálam, ma meg már a feeling miatt nem szeretném úgymond fejleszteni a rendszerem ezen részéit ;-)

Chain-Q
Divatamigás

# Elküldve: 2019. Nov. 10. 15:32 - Szerkesztve: charlie


@siz
másrészt meg mintha filesystem szinten kellett volna valamit állítani, de már nem emlékszem pontosan.

Az eredeti FFS nem tud hosszú fájlneveket. (Ahogy pl. a gyári RAM: handler sem, ha kipróbálod.) Az Olaf Barthel-féle FFS2 elvileg tud, de DOS/6-ot kell DOSType-nek beállítani h. menjen.

@Yellow Dog:
Az Aminetrol jelenleg leszedhető 4.16-os DOpus4 tudja a 30 karakternél hosszabb neveket (nem tudom te melyiket használod), viszont az általad használt FFS jó eséllyel nem.

Yellow Dog
Tag

# Elküldve: 2019. Nov. 10. 16:53


Az enyém az About alapján 4-es verzió, az aminet viszont nem megy...

BSzili
Tag

# Elküldve: 2019. Nov. 11. 21:25


Kicsit off itt, de ha már szóba került az aminettel tudja valaki mi van? Le akartam kapni onnan egy program forrását, de napok óta nem jön be az oldal.

Balage
Tag

# Elküldve: 2019. Nov. 11. 21:43


BSzili: En ilyenkor odamegyek, hogy de.aminet.net, csak ott meg nincs kereses. De ha tudod, hogy mi kell es hol van... ;)

BSzili
Tag

# Elküldve: 2019. Nov. 11. 22:11


Kösz, itt megtaláltam a link alapján.

Yellow Dog
Tag

# Elküldve: 2019. Nov. 26. 17:40 - Szerkesztve: yellowdog


Szeretném megkérdezni milyen elfogadott és a rendszert (OS3) lehetőleg minimálisan terhelő, egy bit állapotát figyelő várakoztatási metódust ajánlanátok ?
Én arra gondoltam, a program indításakor leveszem a prioritást mondjuk -5-re és így figyelem a bit állapotát, majd amikor az változik, a prioritást beállítja magának 5-re, hogy a tényleges funkció végrehajtása a lehető legnagyobb prioritással fusson le, majd visszaál -5-re, mintegy alvó állapotba(?) kerül és várakozik tovább
Gondolom nem ez a "legszebb" megoldás...

BSzili
Tag

# Elküldve: 2019. Nov. 26. 19:08


Nem a legszebb, de ha nincs szignál amire várhatnál, akkor csak a polling marad. Itt szerintem legfeljebb annyit lehet variálni, hogy milyen gyakran nézed a bitet.

Yellow Dog
Tag

# Elküldve: 2019. Nov. 26. 20:54


Köszönöm a tanácsot, sajnos OS szintű szignál nincs, egy memória cím egyetlen bitje változik illetve ezt a változást szeretném figyelni, minél kisebb erőforrás felhasználásával. Mivel a reagálás nem időkritikus, azért gondoltam, hogy "belassítanám" a programot a prioritása csökkentésével.
Jó ez a megoldás, vagy te milyen módon oldanád meg, hogy mondjuk csak a példa kedvéért 100ms-onként nézzen rá és addig ne fusson esetleg egyáltalán?

anchor
Tag

# Elküldve: 2019. Nov. 27. 00:54


interrupt-al probaltad? ha asm pelda kell, szerintem nezz ra egy protracker replay forrasra.

mc68k
Tag

# Elküldve: 2019. Nov. 27. 04:22


Ha sokáig kell figyelni a bitet, hardware interrupt kell neki.

Yellow Dog
Tag

# Elküldve: 2019. Nov. 27. 07:26 - Szerkesztve: yellowdog


.

Yellow Dog
Tag

# Elküldve: 2019. Nov. 27. 07:27 - Szerkesztve: yellowdog


És interrupt el tud indítani egy önálló programszálat?

mc68k
Tag

# Elküldve: 2019. Nov. 27. 12:58


Van interrupt server support az OS-ben. Olvasd a RKM-t, abban van példa.

Yellow Dog
Tag

# Elküldve: 2019. Nov. 27. 20:54 - Szerkesztve: yellowdog


Megnéztem, köszönöm. Nekem az a gondom ezzel, hogy ha innen indítom a programot ha detektálom a bitváltozást, akkor biztosan GURU lesz az eredmény, hiszen a futása akár percekben is mérhető mire visszaadná a vezérlést.
Azért kérdeztem, hogy interrupt rutin, pár soros amely figyeli a bitváltozást, ha igaz a feltétel el tudná-e indítani a tényleges programot?
Kb. nagyon erőltetett hasonlattal élve, CLI-bő RUN parancs külön taszkot indít a vezérlés pedig rögtön visszaadódik.

anchor
Tag

# Elküldve: 2019. Nov. 28. 17:37


1. interrupt: az interrupt handler figyeli a bitet, és ha az set, küld egy signal-t egy másik alvó tasknak, aki arra signal-ra várakozik.

2. polling: egy task fut, a bit figyelések között várakozik, pl a timer.device segítségével. de lehet hogy van az exec-ben is olyan fv mint windowson a Sleep(), vagy linuxon a usleep(). esetleg meg lehet nézni egy 68k SDL forrást hogy van implementálva az SDL_Delay(). vagy használni az SDL-t :)

Yellow Dog
Tag

# Elküldve: 2019. Nov. 28. 19:06


Quoting: anchor
1. interrupt: az interrupt handler figyeli a bitet, és ha az set, küld egy signal-t egy másik alvó tasknak, aki arra signal-ra várakozik.

Ez a megoldás jónak tűnik, de a második lehet egyszerűbb (számomra) ha létezik az említett Sleep() szerű lehetőség, utánanézek.
SDL tuti nem, kizárólag natív OS friendly assembly kód a max. sebességért ;-)

Köszönöm mindenkinek a tanácsokat.

Yellow Dog
Tag

# Elküldve: 2019. Nov. 28. 19:35


Úgy néz ki van egy dos.library/Delay. Tehát ha ezt meghívom a programban akkor a következő utasításra csak a D1-ben beállított érték/50 másodperc elteltével kerül vezérlés, a köztes időt pedig az OS egyéb dolgaira tudja felhasználni a programom ténylegesen áll addig és nem használ erőforrást?

anchor
Tag

# Elküldve: 2019. Nov. 28. 23:15


igen, szerintem ez az amit keresel. egyebkent ugy latom ez a fv is a timer.device-t hasznalja. a varakozasi ido alatt a task alszik.

mc68k
Tag

# Elküldve: 2019. Nov. 29. 00:00 - Szerkesztve: mc68k


Már az általános iskolában is tanítják, hogy a polling az lame, az interrupt a helyes megoldás. De okos voltam megint. :D Polling akkor muszáj, ha nincs INT vonal. Viszont ha te tervezed a hardvert, akkor tervezhetsz hozzá INT vonalat is, INT enable regiszterrel és INT flaggel, ami törölhető.

Yellow Dog
Tag

# Elküldve: 2019. Nov. 29. 14:49 - Szerkesztve: yellowdog


Első körben (lustaságból) a parallel portra építettem meg a kütyüt, ott sajnos nincs INT :-( Tervben van a ClockPort verzió is, de majd csak ha itt megy rendesen akkor állok neki NYÁK-ozni, meg CPLD-zni.

YADA
Tag

# Elküldve: 2019. Nov. 29. 23:38


Az amigas parallel port mukodesenek jobban utana olvasnek a helyedben. Halvany emlekeim szerint van rajta valami interrupt keres lehetoseg, amit a CIA tud kezelni.

Yellow Dog
Tag

# Elküldve: 2019. Dec. 03. 06:15


Köszönöm! Valóban, a Flag bemenetre (ACK pin) érkező lefutó él képes INT2 megszakítást generálni, ha engedélyezve van.

mc68k
Tag

# Elküldve: 2019. Dec. 03. 08:01


Okoskodni szabad? Parallel port 1 IRQ per Byte, CPU load a plafonon, speed 20-40 kB/sec max, 101% CPU load mellett. Kerülni messziről.

Yellow Dog
Tag

# Elküldve: 2019. Dec. 03. 16:30


Quoting: mc68k
Okoskodni szabad?

Aki profi és ért hozzá, miért ne tehetné? Nem is értem a kérdésed :-) :-D

Sajnos nincs más épkézláb külső csatlakozófelület a gépen/gépeken, a parallel port tűnik a leggyorsabbnak. A belső busz nyilván más tészta (lehet) de most ehhez van készen egy egyszerű áramkör és ez amolyan "csak fogom, bedugom és működik" verziónak készül.
Egyébként ahhoz képest nem rosszak az eddig mért értékek, már már a vállalható kategória, ezért sem akarom félredobni:

PC -> Amiga RAM: kb. 80kByte/s
PC -> Amiga DH1: kb. 35kByte/s (Kingston 2GB CF kártya)
Illetve közvetlen memóriába (Fast RAM) írás esetén kb. 104kByte/s

Amiga (RAM:) -> PC kb. 116kB/s
Amiga (DH1:) -> PC kb. 95kByte/s (Kingston 2GB CF kártya)

Mindez egy alap A1200, semmi turbókártya 030 és hasonló. Oké, némi (4MB) Fast RAM... Az IRQ annyihoz kellene, hogy alvó állapotban figyelje érkezik-e adat a portra az USB vagyis a PC felől. Attól kezdve (saját protokoll) tudja mennyi az annyi bájt, tehát nincs várakozás és onnantól IRQ sem kell, egyedül a vételi puffer kiürülése van közben figyelve, ha megérkezett minden, akkor megy ismét várakozó/figyelő állapotba.

mc68k
Tag

# Elküldve: 2019. Dec. 04. 03:47


Köszi a mérési eredményeket, kevesebbre számítottam.

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

Powered by bulletin board software miniBB™ © 2001-2020