| Szerző |
Üzenet |
Yellow Dog
Tag
|
# Elküldve: 2020. Ápr. 13. 10:22
Köszönöm, bevallom félve tettem fel a kérdést, mert pl. az MC68000 könyv sem jelzi, hogy külön létezne SP, ott is az A7 (duplán létező) regisztert nevezi meg mutatónak, de ennek ellenére "Az Amiga programozása C és Asm nyelven" könyvben meg SP szerepel, és még több forrásban is. Egy szubrutinnál jött elő az igény, hogy lementsem a regisztereket majd vissza, ahogyan az korrekt megoldásnál elvárható, de nekem fagyást okozott az SP használata, ezért néztem utána, és találkoztam kétféle jelöléssel. Csak halkan jegyzem meg, sikerült megoldanom "vermelés" nélkül, de kényelmetlenebb, mert figyelnem kell visszafelé is, nem használom-e előrébb és nyilván a rutin után is adott regisztert. Nem vagyok rá büszke, na, de egyelőre nem futottam bele emiatt fellépő bug-ba, egyelőre... ;-)
|
Yellow Dog
Tag
|
# Elküldve: 2020. Ápr. 13. 11:31
Van arra lehetőség, hogy ha programból akarom listázni egy könyvtár, pontosabban egy maghajtó tartalmát, de nincs bent lemez, tehát DFx esetében, akkor a Lock() hatására ne ugorjon fel a "No disk present in device DFx" requester a Workbench-en, hanem csak a program felé jelezze valami/valahogyan, hogy nem tudja olvasni, mert ugye nincs mit?
|
YADA
Tag
|
# Elküldve: 2020. Ápr. 13. 11:53
Elvileg van, de az csunya OS hack.
Valahol a processz strukturak kornyeken meg lehet hackolni a rendszert, hogy ezek helyett a requesterek helyett a sajat rutinod hivja meg a rendszer. De rendkivul gusztustalan megoldas, es nem atombiztos. Minden mas uzenet is ugyanazon a requesteren megy keresztul, nincsenek szeparalva. (parameterekre mar nem emlekszem, talan az alapjan lehet szelektalni futasidoben)
A protracker es az Amos is ezt hasznalja, hogy sajat custom ablakban jelenjenek meg a rendszer uzenetei. Nem lenyelik a kerest, csak ujra implementaljak a requester megjelenitest.
Rendszerbaratabb megoldasrol nemtudok. Persze a rendszer privat infoi valahol tuti jelzik hogy nincs bent lemez, mert a requester is valami alapjan megjelenik.
|
Yellow Dog
Tag
|
# Elküldve: 2020. Ápr. 13. 12:42
Quoting: Yada rendszer privat infoi valahol tuti jelzik hogy nincs bent lemez, mert a requester is valami alapjan megjelenik
Igazad van, ezen az úton lehet érdemes elindulni, köszönöm.
Egyébként Amiga esetében létezik hasonló mint a C16 és C64 esetében (könyvben is) elérhető ROM lista, úgy értem itt Kickstart természetesen? Esetleg OS barát változó terület? Vagy ezek már nagyon eretnek gondolatok? ;-)
|
Chain-Q
Divatamigás
|
# Elküldve: 2020. Ápr. 13. 14:29 - Szerkesztve: charlie
@Yellow Dog:
Egyébként Amiga esetében létezik hasonló mint a C16 és C64 esetében (könyvben is) elérhető ROM lista, úgy értem itt Kickstart természetesen?
Igen, Kickstart 1.x-hez letezett, bar nem tudom h. publikus volt-e vagy csak "kivalasztott" fejlesztok kaptak meg. De nem akarod hasznalni, minek? Igy keletkezett a tonnanyi ware, ami nem megy 2.0-n, vagy csak adott OS verzion megy, mert a ROM listat olvasgatva az okos assembly koderek elkezdtek implementacios reszletekre epiteni - pl. a flageket tesztelni a fuggveny visszateresekor a megadott dokumentalt regiszter TARTALMA helyett, meg ilyen agyhalott dolgok, mert KS1.x-en veletlenul a flag is mukodott, de OS2.x-ben mar mas volt a fuggveny implementacioja, a flag hirtelen mar nem volt ugy beallitva mint korabban -> blamm. Gratulalok.
Esetleg OS barát változó terület?
Mivan? Mirol beszelsz? Nullaslapot akarsz, vagy mit? A., miert nem jo az AllocMem-mel foglalt memoria? B., miert nem jo az exedbe epitett .bss es .data terulet, amit megmondhatsz az assemblernek h. miket akarsz, es majd az OS foglalja neked az exe-t betoltesekor? Errol meg azt is meg lehet mondani Amigan hogy a chip v. fastmembe foglalja neked automatan...
Szoval kepzelj ide egy ujabb virtualis szeretetteljes pofanvagast a hardvermagus-assemblygurukent valo gondolkodasert, pedig az AmigaOS-rol magas szinten, es API-kban kell gondolkodni. Es ez meg KS1.x-re is igaz.
|
Chain-Q
Divatamigás
|
# Elküldve: 2020. Ápr. 13. 14:45 - Szerkesztve: charlie
@Yellow Dog:
Van arra lehetőség, hogy ha programból akarom listázni egy könyvtár, pontosabban egy maghajtó tartalmát, de nincs bent lemez, tehát DFx esetében, akkor a Lock() hatására ne ugorjon fel a "No disk present in device DFx" requester a Workbench-en, hanem csak a program felé jelezze valami/valahogyan, hogy nem tudja olvasni, mert ugye nincs mit?
Van. A Processzed pr_WindowPtr-jet kell -1-re állítani.
Pszeudokod:
; lekered a processzed.
move.l #0,a1
jsr FindTask(ExecBase)
move.l d0, a0
; itt most a0-ban van a processzed pointere
; eltarolod a korabbi WindowPtr-t
move.l pr_WindowPtr(a0), oldWindowPtr
; atallitod -1 -re
move.l #-1, pr_WindowPtr(a0)
; < itt turkalod amit akarsz a DOS-ban, nem kapsz requestert hanem error kodokat amiket az IoErr() fuggvennyel lehet lekerdezni >
; vegul visszaallitod a korabbi WindowPtr-t
move.l oldWindowPtr, pr_WindowPtr(a0)
(Szerk, 2021.10.01: a pszeudokodban javitva a konstans -1-rol #-1-re, mert kicsit tul kozel volt az igazi assemblyhez, es ez remek bugokat okozott, ha valaki innen copypastelt. Lefordult, csak mast csinalt.)
|
Yellow Dog
Tag
|
# Elküldve: 2020. Ápr. 13. 14:51
Quoting: charlie kepzelj ide egy ujabb virtualis szeretetteljes pofanvagast a hardvermagus-assemblygurukent valo gondolkodasert
Látod, éreztem, hogy ma eljutunk eddig :-) Igen, a "nullás lap" vagyis annak valami megfelelője jutott eszembe, de jó lesz API is természetesen, hiszen próbálok nem letérni az OS ösvényről, bár néhol eléggé szűkös, és nem tiszta merre is visz tovább ;-)
Szóval, lehet erre megoldás? Végignéztem a dos.library-t de nem jött szembe a lemez jelenlétét megadó függvény. Kezdem azt gondolni, hogy ehhez a trackdisk.device lesz/lehet a befutó. Mindegy, egyelőre félreteszem...
|
Yellow Dog
Tag
|
# Elküldve: 2020. Ápr. 13. 14:52
Upsz, most látom, közben Te is írtál, akkor GOTO -1, akarom mondani JMP... mindjárt átolvasom :-)
|
mc68k
Tag
|
# Elküldve: 2020. Ápr. 13. 16:18
Hallgassatok Charlie-ra: ne akarjatok olyan szar programot írni, mint a demosok Amigán 1990 környékén: fordítsunk fix címre multitask OS-en(!), nézzük az OS source kódot és onnan olvassunk stb.
1. egy asm-ben írt program elkészítési ideje sokszorosa az ekvivalens C verzióéval
2. asm-ben írt programban fellelhető bug-ok száma sokszorosa a C verzióhoz képest
Demot írunk asm-ben és specifikus rutinokat, amiket a C fordító nem tud elég jól előállítani. Mindenre van könyv (PDF és downloadable). Tessék olvasni.
|
YADA
Tag
|
# Elküldve: 2020. Ápr. 13. 17:05
Szokas szerint Charlie friss rutinja tobbet er mint a regi emlek. (pedig valahol emlekeztem meg erre a -1 trukkre, csak tul melyre van eltemetve)
De arra meg emlekszem, hogy ennek a -1 ptr atirasnak is vannak "karos" mellekhatasai.
Pl. az igy vedett kod szakasz alatt az egyeb requester uzenetek sem fognak megjelenni, amikre esetleg szamitasz, hogy megjelennek majd.
Szoval alaposan at kell gondolni, mit es miert csinal az ember.
|
Yellow Dog
Tag
|
# Elküldve: 2020. Ápr. 13. 19:04
Quoting: mc68k Demot írunk asm-ben és specifikus rutinokat, amiket a C fordító nem tud elég jól előállítani
Ti lehet, én viszont nem értek a C-hez, próbáltam többször is, de nem megy, nem az én világom, szóval feladtam :-( Az asm valóban lassan megy, de legalább megy, lassan de biztosan ;-) "Fáról fára" haladok előre, és nem mellesleg az ember megtanul, vagy legalább is találkozik dolgokkal, ez sem utolsó szempont.
Quoting: Yada az igy vedett kod szakasz alatt az egyeb requester uzenetek sem fognak megjelenni
Csak addig kell ez az állapot amíg lekérdezem a létező device-okat amelyek megjelenhetnek a TC oldalon mint elérhetőek és a tartalmuk listázható, tehát ha nincs lemez nem lesz megjelenítve sem.
|
Yellow Dog
Tag
|
# Elküldve: 2020. Máj. 01. 16:26
Ha már szóba került verzió a "Szoftver problémák, megoldások, tanácsok"-ban, KS mérete és kezdőcíme 1.3-ig 262144byte / $FC0000, 2.0-tól 524288byte / $F80000 ha jól tudom. Van kivétel, vagy ökölszabályként elfogadható fenti állítás? Illetve kiolvasható az aktuális valahonnan? Nyilván igen...
|
Chain-Q
Divatamigás
|
# Elküldve: 2020. Máj. 01. 17:51 - Szerkesztve: charlie
Mit hekkelsz megint? :) Amúgy ha a ROM chip tartalmára gondolsz, akkor szerintem az mindig ott van. De az nem biztos h. megegyezik azzal a Kickstarttal ami éppen fut (lásd MapROM, etc.).
Ill. bizonyos kártyákon, főleg low-endebb gépekbe való bővítéseken lehet h. az a címterület nem a fizikai ROM chipre mutat, hanem ugyanoda mappolja be a mindenféle custom Kickstartot ami a kártyán lehet.
|
Yellow Dog
Tag
|
# Elküldve: 2020. Máj. 01. 18:02
Nem hekkelek ;-) Lesz (van) egy olyan funkció, hogy Kiskstart letöltése, a gépben található ROM-ról készít másolatot a PC-re, fájlba. Tudom, nem sok értelme van, de adja magát :-) Ha a MapROM a helyére teszi az aktuálisan kiválasztottat, akkor arról készül természetesen, az éppen működőről.
Még, hogy nincs "nullás lap" ;-)
move.l 4.w,a6
move.l LIB_VERSION(a6),d0
cmp.w #39,d0
|
Chain-Q
Divatamigás
|
# Elküldve: 2020. Máj. 01. 18:45 - Szerkesztve: charlie
Az exec.library libbase legkevésbé sem nullás lap. Mitöbb, minden library megnyitáskor egy Library-struktúrára mutató pointert kapsz, a verziót a lib_version mező, az alverziót a lib_revision mező tartalmazza. Ettől a címtől felfele ugye vannak ezek a mezők, lefelé meg a jumptable, ezért van az h. minden JSR -offset(A6) hívásnál az offset negatív... Szóval ugyanezt eljátszhatod az OpenLibrary() által megnyitott többi libre is, azoknak a libbase-jában is ott lesz a verzió.
Ezek a mezők vannak sorban:
struct Node lib_Node;
UBYTE lib_Flags;
UBYTE lib_pad;
UWORD lib_NegSize; /* number of bytes before library */
UWORD lib_PosSize; /* number of bytes after library */
UWORD lib_Version; /* major */
UWORD lib_Revision; /* minor */
APTR lib_IdString; /* ASCII identification */
ULONG lib_Sum; /* the checksum itself */
UWORD lib_OpenCnt; /* number of current opens */
Az meg kb. közismert, és minden tutorial kb. a másfeledik fejezetben a library-k megnyitásánál tárgyalja, hogy az AmigaOS programozásban egyetlen fix cím van, az pedig az exec.library kezdőcíme, ami $4-ről olvasható ki, és egyben ez az egyetlen library amit megnyitni sem kell, de attól még a cím amit kapsz ugyanolyan Library struktúrára mutat. Azért ezt nulláslapnak hívni elég bátor... (És akkor még olyan apróságokat mint a '010-től felfelé létező VBR, vagy a mindenféle MMU trükkök, vagy pl. a Mac emukhoz való hackok mint a FusionReserve, ami lefoglalja az első 8K RAM-ot nekik, nem is említettük.)
|
Yellow Dog
Tag
|
# Elküldve: 2020. Máj. 01. 19:28
Quoting: charlie AmigaOS programozásban egyetlen fix cím van, az pedig az exec.library kezdőcíme, ami $4-ről olvasható ki
Igen, ezt már megtanultam :-)
Quoting: charlie Azért ezt nulláslapnak hívni elég bátor...
Idézőjelek közé is tettem ;-)
|
Yellow Dog
Tag
|
# Elküldve: 2020. Máj. 01. 19:30 - Szerkesztve: yellowdog
Szeretnék segítséget kérni Windows, vagyis x86 (és 64) C forrás módosításában...
Nem kell tegnapra, de jó volna minél előbb, ha valaki bevállalná, köszönöm.
x86 verzió
|
Chain-Q
Divatamigás
|
# Elküldve: 2020. Máj. 01. 22:23
Csak tipp, de mondjuk legalább címszavakban ha leírnád milyen módosításokat akarsz bele, akkor talán még esélye is lenne h. ha valaki belenéz a kódba akkor megsaccolja h. mekkora szopás megcsinálni.
|
Yellow Dog
Tag
|
# Elküldve: 2020. Máj. 02. 13:30
Quoting: charlie legalább címszavakban ha leírnád milyen módosításokat akarsz bele
Ó igen, a lényegről elfeledkeztem ;-) Igazából első körben csak érdeklődni volt bátorságom, volna-e valaki aki időt áldozna a dologra, ezt követően akartam a részletekkel előhozakodni...
Szóval mint fentebb említettem, az eredeti verzió mindkét irányban 1024 bájtos egységekre darabolva küldi át a fájlt. Egy frame felépítése:
2 byte = 'FT'
1 byte = 0 (minden frame küldés után 1-el növekszik, $ff után ismét 0, stb)
1 byte = 'b'
2 byte = keret mérete = adat + 10
2 byte = crc
1024 byte = adat
2 byte = 0, 0
Tehát a méret összesen adat + 10byte, ezen érték kerül a keret mérete word-be. Ha kisebb a fájl mint 1024 bájt akkor természetesen egy frame kerül elküldésre és a méretnek megfelelően kisebb lesz a frame is, adat + 10byte.
Amiga oldalon meg tudtam növelni az átvinni kívánt bájtok számát, 16kbyte-ig próbáltam, a frameben a keret mérete az eredeti $040a (1024+10) helyett $400a (16384+10) lett. Ezt szeretném PC oldalon is megoldani, tehát ne 1kbájtonként hanem 16kbájtos csomagokban küldje az adatot.
De nekem az is jó, ha kaphatok támpontot, hol történik a darabolás 1kbájtokra, mert néztem a forrást, de nem igazán találtam meg. Igaz C++ programom sincs... na mindegy, köszönöm előre is :-)
|
Yellow Dog
Tag
|
# Elküldve: 2020. Máj. 03. 11:09
Felraktam VirtualXP-re a Visual Studio 6-ot (C++) a dsp fájlra kattintva be is töltődik és a build szépen elkészíti a setransplg.wfx plugin fájlt, viszont míg az eredeti mérete kb. 80kB addig az újonnan generált kb. 240kB lett. Nem mondom, hogy hatalmas probléma, mert egy PC-n elfér, de gondolom optimalizálással lejjebb lehetne tornászni a méretet. VC-ben erre hol találok beállítási lehetőségeket? Köszönöm
|
anchor
Tag
|
# Elküldve: 2020. Máj. 03. 11:21
lehet hogy debug targetet fordítottál. próbáld meg átállítani release-re.
|
Yellow Dog
Tag
|
# Elküldve: 2020. Máj. 03. 11:49
Igen, ez volt a probléma, és még kisebb is lett mint az eredeti, mindössze 57kB, köszönöm :-)
|
YADA
Tag
|
# Elküldve: 2020. Máj. 03. 12:56 - Szerkesztve: Yada
kerdes: milyen device neven akarsz kommunikalni pc oldalrol (milyen nevu eszkozon keresztul)?
USB*? vagy COM*?
|
Yellow Dog
Tag
|
# Elküldve: 2020. Máj. 03. 13:34
COM portként jelenik meg Windowsban, gyakorlatilag mint a szokásos soros USB átalakítók, annyi a különbség, hogy a másik végén nem Rx és Tx vezeték van hanem (bufferelt) parallel port.
|
YADA
Tag
|
# Elküldve: 2020. Máj. 03. 14:13 - Szerkesztve: Yada
Ertem, source alapjan COM kezdetu portokat kisebb bufferrel kezeli (jav. USB nagyobb buffert hasznal).
De akkor saccra a megoldas, itt van definialva a hasznalt buffer merete:
lowlvlio.h:
#define maxblocksizeserial 1*1024 // XModem-1k block size
Kb ennyi, ranerzesre minden egyebet tud a kod.
Amugy kb a WIN95 serial servert kellene amigasitani es kesz. (nem vallalom, asszem)
|
Yellow Dog
Tag
|
# Elküldve: 2020. Máj. 03. 14:48
Quoting: Yada #define maxblocksizeserial 1*1024 // XModem-1k block size
Ez az, köszönöm!
Quoting: Yada WIN95 serial servert kellene amigasitani
Igen, ezt készítem ;-)
|
Yellow Dog
Tag
|
# Elküldve: 2020. Máj. 04. 15:19
Quoting: Yada Kb ennyi, ranerzesre minden egyebet tud a kod.
Van benne még pár buffer méret definiálás, konkrétan 1kB és hasonlók, ezeket nem kell hozzáigazítani a megnövekedett blokkmérethez? Működik a módosítás, de nem szeretném, hogy ez csak a véletlen műve legyen és esetleg olyan helyekre írjon, ahová nem kellene és csak idő kérdése amíg valami nem kavar be, vagy valaminek nem kavar be a plugin.
|
Chain-Q
Divatamigás
|
# Elküldve: 2020. Máj. 05. 09:32 - Szerkesztve: charlie
Engem leginkább az érdekelne, hogy ez az egész minek. Mit vársz a megnövekedett buffermérettől?
Amit gyanítok, hogy már megint elmaradt a házi feladat elkészítése, és a kommunikációs blokkméreted közvetlenül meghatározza a disk I/O blokkméretet is, így a 16K-s bufferméret esetén az Amiga oldalon nem 1K-s blokkokat hanem 16K-s blokkokat írsz-olvasol a lemezre/lemezről, és az gyorsabb. De nyilván ha a kommunikációs protokollod blokkmérete határozza meg h. milyen blokkmérettel kezeled a lemezt, és ezt a protokollod patkolásával próbálod megoldani, akkor szvsz valamit rosszul csinálsz. (Protip: kérjük hasonlítsuk össze a felmerült blokkméreteket pl. egy Ethernet packet méretével, ami LAN-on tipikusan 1500 byte. És azzal száz megabitig simán ki lehet szolgálni bármit. Szóval ja.)
A másik lehetőség, hogy spórolni akarsz az átküldött fejlécek számán, de figyelembe véve, hogy 10 byte vs. 1024 byte-ról beszélünk, ezt maximum 1% sebességnövekedést tesz lehetővé, szóval ezt kétlem.
De fixme, és nyilván mit értek én hozzá.
|
YADA
Tag
|
# Elküldve: 2020. Máj. 05. 10:27
Ez egyben valasz arra is, hogy miert van tobbfele buffer a PC oldali kodban (kliens/szerver egyarant). Azon tul, hogy az egy multiprotokol kod. Elsosorban Palm sorosport, masodsorban Palm USB es PC soros kommunikacio. Ez a harom pedig egy kozos kodbazison alapul #ifdef blokkokban alternalva igeny szerint.
Amugy abban a PC oldali kodban is van par csunya megoldas (mondhatnam hogy fos), de vegulis valahogy mukodik a legtobb esetben.
|
Yellow Dog
Tag
|
# Elküldve: 2020. Máj. 05. 18:23
Quoting: Yada PC oldali kodban is van par csunya megoldas (mondhatnam hogy fos), de vegulis valahogy mukodik a legtobb esetben.
Erre mondhatjuk, amit nem tudunk az nem fáj ;-) Egyébként Ghisler műve aki a TC-t is fejleszti, szóval valamit már letett az asztalra, ha mást nem egy szinte hibátlanul működő fájlkezelő programot, és ugyanez elmondható egyébként a pluginről is, még nem fagyott le, nem hibázott, sem PC sem az Amiga kommunikációt illetően ;-)
De én biztos vagyok abban, hogy a szoftverek 99%-a az "oké, megy, mehet a piacra" kategória, főleg ha pénzről szól a dolog tehát határidős. Én ipari automatizálással foglalkozom nap mint nap, hiba keresés PLC szoftver elemzéssel real time, tudnék mesélni, neves gyártók micsoda módszereket, kókány megoldásokat alkalmaznak, de ami számít (sajnos) az kizárólag a végeredmény, a gépek működnek, termelik a darabokat, tehát a pénzt... Ezért mondom és vallom, a programozásnak az igazi programozásnak hobbi szinten kellett volna maradnia... :-)
|
