| Szerző |
Üzenet |
dh1
Mr. DTP
|
# Elküldve: 2018. Aug. 21. 02:52
En 25 masik linket tudok adni error kodokkal es annak magyarazataval! Nem ez volt a keres / kerdes! ;)
De latom neked sikerult! Elmondanad nekem is!? :)
|
PeachMan
Tag
|
# Elküldve: 2018. Aug. 21. 06:49 - Szerkesztve: peachman
Quoting: dh1 Elmondanad nekem is
Szerintem ez egy sima RuntimeException lehet, semmi hardveres dolog valószínűleg.
00000003 - címhiba
BBBBBBBB - ez pedig a cím ami nem tetszik neki
Mondjuk nekem is elég furcsa ez a címtartomány :)
Mintha 32bites lenne.
Ez alapján lehet még a címről kutakodni kicsit. Reserved címtartományban van.
|
Chain-Q
Divatamigás
|
# Elküldve: 2018. Aug. 21. 07:04 - Szerkesztve: charlie
A fő baj - amellett hogy egy faszság az a cím - az, hogy páratlan (hexa "B" = decimális 11). És ezért kapod a címhibát, mert a sima 68k nem tud közvetlenül 16bites vagy nagyobb értéket páratlan címről betölteni. De ez valszeg a futó szoftver sara, és nem HW bug, ha ennyire reprodukálható.
|
dh1
Mr. DTP
|
# Elküldve: 2018. Aug. 21. 16:46 - Szerkesztve: dh1
A hibauzi valid... van foto is ha kell :)
Termeszetesen, hiszen a gep jol muxik minden massal, csak ez hal meg alatta, mely egy masik A500-on meg siman fut ...
egy gyanusitottam van, a fel megas ram bovito nem tetszik neki ...
amugy erdekes, de ezt az en A500am is csinalta (fentebb nem az en gepem van) es tobb sensi 96-97 probalgatasa utan lett jol futo verzio ...
vaaaaaaaagy lehet virus is??? nem a tores szar?
de egyebkent en Guruban csak olyan hibauzit kaptam meg amire kb. mindenki szettarta a kezet :) meg ment a "szerintem" ... talan akkor nem en vagyok annyira hule hozza (de :D )
|
Yellow Dog
Tag
|
# Elküldve: 2018. Aug. 31. 18:09
Még mindig keresnék OS3.1 alá egy elfogadható sebességű (nagyon gyors) lemez(re)író rutint. Jó lenne asm, de ha minden kötél szakad jöhet C formátumban is, köszönöm.
|
Chain-Q
Divatamigás
|
# Elküldve: 2018. Aug. 31. 18:16
Meg mindig hasznald a trackdisk.device-t. Az az egyetlen cucc, ami garantaltan mukodik minden drive-val amit valaha gepekbe acsoltak. Amigara nem lehet C64-szeruen fastloadert irni, szoval nem tudom mit is akarsz tulkepp.
|
ratman
Kék troll
|
# Elküldve: 2018. Aug. 31. 18:26
@Chain-Q: Ott a pont. :)
|
Yellow Dog
Tag
|
# Elküldve: 2018. Aug. 31. 19:17
Quoting: charlie nem tudom mit is akarsz tulkepp
Nem, nem azt kérem, hogy írjatok nekem egy fastloadert, OS barát megoldást szeretnék természetesen illetve csak linkre gondoltam, hátha tudtok valahol a neten egy elfekvő példát, amelyet hossza bambulást követően valahogyan tudnék értelmezni ;-)
Én a dos.library-t nézegettem mivel A1200-ason OS alatt szeretném megoldani a dolgot és nem csak floppy hanem vinyó is játszik, tehát DH0: DH1: stb...
Az FWrite látszik jónak, mint bufferelt írás, viszont nem teljesen jó mégsem, mivel nekem nem egy memória területen áll rendelkezésre a kiírandó adat, mondjuk 256 bájt, vagy a többszöröse, hanem mindig ugyanarról az egy memória címről kellene kiolvasni és azt kiírni. Szóval a lényeg, elérhető esetleg ennek a függvénynek is a forrása valahol, mert lehet az is segítene.
A jelenleg Basic-ben írott és lefordított rutin az alábbi gépi kódot generálja:
--------------------------------------------------------
name "WriteByte", "(Byte)"
flags LongResult ;-- should return 1 or 0
amigalibs _DosBase, a6
WriteByte_TEST:
MOVEM.l d2-d4,-(a7)
MOVE.l (a5), d1
LEA.l _NumBuffer(a5), a0
MOVE.b d0,(a0)
MOVE.l a0, d2
MOVEQ #1, d3
MOVEQ #1, d4
JSR _FWrite(a6) ; (File, Buffer, BlockLength, NbBlock) d1/d2/d3/d4
MOVEM.l (a7)+,d2-d4
RTS
--------------------------------------------------------
Vagyis minden egyes bájt írása után visszatér, majd újra meghívódik ami láthatóan sok felesleges utasítás végrehajtást kíván, minek eredménye, hogy kb. 5 kbyte/s az írási sebesség :-(
|
siz
Tag
|
# Elküldve: 2018. Aug. 31. 22:24
Quoting: yellowdog Az FWrite látszik jónak, mint bufferelt írás, viszont nem teljesen jó mégsem, mivel nekem nem egy memória területen áll rendelkezésre a kiírandó adat, mondjuk 256 bájt, vagy a többszöröse, hanem mindig ugyanarról az egy memória címről kellene kiolvasni és azt kiírni.
Hát, bájtonkénti írás/olvasás márpedig gyors nem lesz.
Ilyenkor azt szokták, hogy arról az egy memóriacímről beolvasnak egy 256 bájtos memóriaterületre 1-1 bájtokat, majd utána az egészet egyben kiírják. (Mondjuk a 256 bájt is elég picike puffer, ennél jóval nagyobbakat szokás használni)
|
Yellow Dog
Tag
|
# Elküldve: 2018. Sze. 01. 08:39
Köszönöm az ötletet, csak példa volt a 256 természetesen, értem az elgondolást, de ugye az a beolvasás is időbe telik, minden utasítás lassítja a végeredményt.
Azért is kérdeztem, hogy elérhető-e magának az FWrite függvénynek a forrása, mert akkor az alapján lehetne írni egy rutint amely annyiban térne el, hogy nem növelné a forráscím pointerét, ha jól gondolom.
|
Chain-Q
Divatamigás
|
# Elküldve: 2018. Sze. 01. 11:50 - Szerkesztve: charlie
Az FWrite fuggveny sem fekete magia, csak annyit csinal (saccra, de kb. minden buffered I/O igy mukodik) amit siz is leirt, hogy megcsinalja a bufferelest neked, vagyis csak egy koztes (nagyobb) bufferbe masolja a parameterben megadott adatot, vegul a tenyleges kiirashoz meghivja a buffereletlen Write() fuggvenyt ha betelt a buffer, vagy valaki meghivta a filehandlera a Flush()-t.
(Es meg van egy rakas corner case, hogy mivan ha valaki az elerheto buffernel nagyobb adatot adott at, akkor azt kozvetlenul kiirjuk, persze elotte flusholva a buffert stb.)
Ha ennel gyorsabbat akarsz akkor kb. azt csinalod amit siz mondott, es te rakod sorba egy bufferbe a bajtjaid, aztan hivsz ra egy unbuffered Write()-t. Bar en akkor is FWrite()-ot hasznalnek, mert majd az OS megcsinalja nekem a legoptimalisabban aztan kesz.
Mellesleg ha nem akarsz egy byte-okat irni a filehandlera FWrite()-tal, van FPutC(), amit pont erre talaltak ki.
Mas megoldas nincs. Ha ennel gyorsabbat akarsz, akkor valahogy a beolvaso oldalon kell megoldanod, hogy ne ugyanarra a cimre erkezzenek a forrasbajtok. Ha ez valami hardveres basz, akkor amit akarsz azt DMA-nak hivjak, ergo szoftverbol akarod a DMA viselkedeset szimulalni, amit csak a hardver oldalon lehet megoldani. Egyebkent pont ezert van a legtobb pl. halozati kartyanak beepitett kis sajat memoriaja, hogy oda erkezzenek a packetek es a CPU egy nagyobb blokkot tudjon majd kiolvasni egy interrupt utan. De ez mar feltetelez rendes, reteges kommunikacios stacket es definialt frame-tipust, ami alapjan a hardver el tudja donteni, hogy "aha megjott egy adag adat", most kell szolni a procinak, interrupt.
Szoval szerintem a kerdesed rossz, mert hibas alapfeltevesekre epul (mint rendesen, megemlexem a hasznaljuk az ESP TCP/IP stackjet c. agymenesre, eros deja-vum van, de biztos csak en vagyok helikopter megint).
Ez olyan mint az egyszeri assembly programozo, aki azt hitte, hogy egy szar algoritmus is lehet olyan gyors mint egy jo algoritmus, csak assemblyben kell megirni. Nos, nem.
|
siz
Tag
|
# Elküldve: 2018. Sze. 01. 17:36
Egyébként valóban, amit Charlie is írt: feltételezem, hogy ez egy saját hardware-ed. Ott, ha normális teljesítményt akarsz, akkor nem a Z80/Intel féle I/O buszt kell szimulálni, ami egy bájtos kapun zavar át mindent, hanem memory-mapped-I/O-t kell csinálni (ha lehet), azaz magán a vason kell megoldani, hogy mondjuk 256 bájtos memóriaablakot mutasson és ebbe kell sorba tenned az adatokat. Majd amikor megtelt, akkor interrupt a procinak, aki egy FWrite()-tal kiírja, nyugtázza a megszakítást és utána lehet újra írni a pufferbe. (mármint a vas addig vár). Vagy ugye ennél még kényelmesebb (amit szintén említett Charlie), hogy DMA kontrollernek kell megmondani, hogy töltse a RAM-ba a puffernyi adatot.
|
Yellow Dog
Tag
|
# Elküldve: 2018. Sze. 01. 19:58
Sajnos nem én hozom a szabályokat, a clock port 8 bites és mindössze 4 címvezeték található rajta :-( Nem DMA-t szeretnék szoftveresen emulálni, mindössze azt kérdeztem, hogy hol találhatok egy lehetőleg minél gyorsabb rutint amelyet a fenti korlátok mellett fel tudnék használni, hogy elfogadható sebességet érhessek el.
Igen, gondoltam én is a memóriába mappelésre, de ahhoz új nyák-ot is kellene terveznem amelyre egyelőre a sok egyéb lakás körüli teendő miatt nincs időm és lehetőségem. Természetesen ekkor akár 32 bites is lehetne a hozzáférés, amely gondolom még inkább lökne egyet a sebességen.
Köszönöm a tanácsokat.
Quoting: charlie a kerdesed rossz, mert hibas alapfeltevesekre epul (mint rendesen, megemlexem a hasznaljuk az ESP TCP/IP stackjet c. agymenesre, eros deja-vum van
Igen, eltaláltad, még mindig, vagyis hosszú kihagyást követően ismét az ESP-ről van szó. Nekem ez (az elektronika) hobbi és azt gondolom tanultam és tudok pár dolgot 40 évvel a hátam mögött, ami gondot okoz az a szoftver, pontosabban az Amiga lelkivilága, ezért fordultam ide tanácsért illetve információért. Hogy erről mi a véleményed, nem tartozik különösebben a kérdésemhez, ami nekem hobbi, neked agymenés, ami neked hobbi, lehet nekem, vagy másoknak agymenés... ;-)
|
AliveMOon
Tag
|
# Elküldve: 2018. Sze. 02. 09:43 - Szerkesztve: alivemoon
A 68k procikban van egy
MOVEP: Move peripheral data utasítás.
The MOVEP operation moves data between a data register and a
byte-oriented memory mapped peripheral.
|
siz
Tag
|
# Elküldve: 2018. Sze. 02. 16:54
Quoting: yellowdog Sajnos nem én hozom a szabályokat, a clock port 8 bites és mindössze 4 címvezeték található rajta
Akkor viszont továbbra is az a célszerű, ha te mozgatod egy memóriapufferbe az adatokat és onnan írod ki blokkokban. Az AliveMOon által írt MOVEP erre akár jó is lehet, bár igazából, amikor egyébként is handshake-elni kell, hogy mikor áll rendelkezésre egy bájt, gyakorlatilag mindegy, hogy te magad másolod vagy egy utasítás automatikusan növel neked egy index regisztert.
Egyébként, mivel a háttértárak blokk szervezésűek, úgyis blokkok fognak a háttérben íródni, csak annyi a különbség, hogy ha te egyesével hívod az I/O műveleteket, akkor nagyobb overhead-je lesz azzal, hogy egyrészt mindig valamilyen OS műveletet hívsz, másrészt meg neki kell ellenőrizni, hogy a puffer betelt-e és kiírni lemezre. (Rosszabb esetben, nyilván implementációtól függően mindig megír egy bájtot, kiírja lemezre, majd utána a következőnél beolvassa, hozzáír egy bájtot és újra kiírja).
A blokkolt I/O minden implementációnál egy nagyságrenddel gyorsabb.
|
Yellow Dog
Tag
|
# Elküldve: 2018. Sze. 05. 21:14 - Szerkesztve: yellowdog
Quoting: siz ha te egyesével hívod az I/O műveleteket, akkor nagyobb overhead-je lesz azzal, hogy egyrészt mindig valamilyen OS műveletet hívsz, másrészt meg neki kell ellenőrizni, hogy a puffer betelt-e
Köszönöm a megfogalmazást, ezt írtam körül csak más szavakkal :-)
Egyébként a lemezpuffer hány bájtos, mennyivel dolgozik pl. a FFS esetében az OS?
|
ratman
Kék troll
|
# Elküldve: 2018. Sze. 05. 21:50
az fajlsystem fuggo, hogy mennyi a default.
Te is le tudod kerdezni, addbuffers df0:
kiirja... de ha jol emlexem az ertek 5, egy buffer meg 1,5 kilobyte. :D
tehat, az kb. 7,5 kilobyte.
|
Chain-Q
Divatamigás
|
# Elküldve: 2018. Sze. 06. 14:39
Kerjuk ne keverjuk mar a filesystem bufferet mint fogalmat a filehandle-hez tartozo, buffered I/O eseten hasznalt buffermerettel...
Mert hogy amit az FWrite() hasznal az filehandle specifikus, es a merete es a buffereles viselkedese a SetVBuf() fuggvennyel allithato (Kick 2.0 vagy ujabb):
http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_2._guide/node02FF.html
A filesystem addbufferrel allithato buffere egy teljesen mas teszta.
|
Yellow Dog
Tag
|
# Elküldve: 2018. Sze. 06. 21:15
Quoting: charlie amit az FWrite() hasznal az filehandle specifikus
Ha jól értem az már egy alacsonyabb szint, köszönöm, megnézem.
|
dh1
Mr. DTP
|
# Elküldve: 2018. Okt. 05. 22:30
kerdesek:
(AOS3.9 szenne pacskerezve :) tudom szar de megis ...)
- ha kepernyomodot valtoztatok, az tesztig jo, katt, megmutatja visszaszamol, visszalep a Screenmode prefsre. DE ha le OK-ezom vagy SAVE-zom akkor szepen becsuk mindent, kepernyovaltas, de a visszakapott screen szurke, ikonok es a wb nem jon vissza, resetre teremeszetesen mar az uj SAVE-ezott felbontasban jon fel... esetleg valakinek otlete?
- volt regen egy jo kis pacsker ami ha barmi Assignt vagy Mountot keresett a rendszer, akkor egy feljovo ablakban lehetett mountolni, assignolni stb. mi lehetett ez (MCP remlik de az kihagynam)
- volt olyan requesterem ahol jobb gombra az elerheto meghajtokat, mountokat, assignokat stb. kaptam... melyik pacsker vagy requester lehetett ez?
thx
|
dh1
Mr. DTP
|
# Elküldve: 2018. Okt. 06. 06:16
jobb egergomb es assign problema megoldva ... maradt a screenvaltas bug :)
|
Yellow Dog
Tag
|
# Elküldve: 2018. Okt. 06. 11:46
Quoting: dh1 jobb egergomb es assign problema megoldva
Mint a cégnél a műszak átadás... Megoldva, de, hogy hogyan, mert az lenne a lényeg... ;-)
|
dh1
Mr. DTP
|
# Elküldve: 2018. Okt. 06. 17:20
mivel mindenki - szokas szerint, tisztelet a C64eseknek :D - tesz ra, gondoltam csak nalam avagy nekem problema
1. jobb gomb mizeria...
alapvetoen osszetett problema
en szerettem regen ha jobb gombra a kotetekhez jutok, es ha Amiga elott ulok rendszeresen nyomogatom a jobb gombot egy-egy requesterben ... de!
a magicmenu alam tesz, mert o meg minden legordulo menut megvarazsol, tehat jobb gombra nem a kotetekhez jutok, hanem legordul a requester menuje... es ez engem idegesitett, persze menubol is kivalaszthatnam de az macera ... sajna a magicmenuben nem lehet megadni mit varazsoljon at, sot meg az sem, hogy csak a desktop felett lebego menu legyen, mikozben az OS tobbi menujehez ne nyuljon ... ez pedig nekem azert nem jo, mert igazandibol hasznalnam a magicmenut de csak egy featurejat, megpedig a jobb gombra FENT legordulo menut ami ragad, tehat a jobb gomb elengedesere a fenti menu nem tunik el, var arra, hogy valasszak ... ez nekem a tegeseg miatt a jobb kezem szarsaga miatt jo ... a magicmenu lebego menuje igazandibol nem izgat, felolem akar ne is legyen, de a kettot nem lehet kulon kezelni vele. kutakodtam es talaltam egy specko homebrew progit egy forumon ami a jobb egergomb kitartasat megoldja, de azzal meg az volt a baj, hogy a kitartas ugyan ugy minden menure igaz es requester eseten - magicmenu nelkul is -, a jobb gombra minden legordul es var... tehat ez sem segitett, akar hogy konfigoltam... aztan jott a pofara eses, az egerem kozepso, gorgeto gombja erdekes modon visszalep a kotetekhez egy gomnyomasra ... arghhhh ha ezt tudom (pecen sem szoktam hasznalni a gorgo alatti gombot). az, hogy ezt az A-Eonos egerdriver vagy a FreeWheel2.2 csinalja, meg nem nyomoztam ki, orultem es a jobb kezem is a mukodesnek :)
2. assign ... emlekeztem anno az MCP-re amiben volt ilyen funkcio de ujkori vasaimban mar nem hasznalom es mivel igy is annyi pacsker van a rendszerben, hogy csak osszekavarodnek meg egy MCP fele pacskerhalmaztol igy elvetettem. De szerencsere meglett az AssignWedge nevu ware ami kicsi gyors, es azt csinalja ami nekem kell... assign, mount stb. nem kell kulon shell ablakbol mountozgatni, hanem RAD:-ra feljon az AW es megkerdezim it szeretnel kisgazdam! :)
3. screenmodvaltas szurkesege ... erre meg nem tudom a valaszt ... kutatom, melyik pacskercsinalja ki es miert...
|
Yellow Dog
Tag
|
# Elküldve: 2018. Okt. 07. 19:56
Köszönöm az információkat :-)
|
PeachMan
Tag
|
# Elküldve: 2018. Nov. 17. 17:36
Mi lehet az oka, hogy a WhichAmiga bármelyik verziója lefagyasztja a gépet Blizzard 1230-IV használatakor? Próbáltam két gépen és két ilyen kártyával is. Betöltött OS vagy no startup megoldással is. KS3.0 és 3.1 esetén is. B1260-al nincs ilyen gond. Illetve a kártyák/gépek amúgy jól működnek. Nincs erre valami megoldás?
|
dh1
Mr. DTP
|
# Elküldve: 2018. Nov. 17. 19:07
A gepem (Blizzard 1230-IV) epp Sensible bajnoksagon teljesit, de holnap megnezem nalam mit csinal a Which...
|
dino
Kék troll
|
# Elküldve: 2018. Nov. 17. 21:15 - Szerkesztve: dino
Quoting: peachman WhichAmiga bármelyik verziója lefagyasztja a gépet Blizzard 1230-IV
Itt is fagy, ugyanezen a konfigon...
060 ra van optimalizalva, azzal nekem is mukodik.
|
siz
Tag
|
# Elküldve: 2018. Nov. 17. 23:04
Lehet, hogy tényleg a 030-at nem szereti, mert ACA-1231-el is szétfagy. (alapgépen és nem 1200-on nem emlékszem, hogy próbáltam-e)
|
dh1
Mr. DTP
|
# Elküldve: 2018. Nov. 17. 23:28
Barataim, ti melyik WhichAmigat hasznaljatok?
van 1.3.3 ACA verzio is
http://dh1.amigaspirit.hu/whichamiga_1_33_aca.lha
030 cpu tamogatott, ott vmi mas humbug van/lehet
sajna nem kaptam vissza a gepem, csak holnap tudok referalni
|
dino
Kék troll
|
# Elküldve: 2018. Nov. 18. 08:02
Quoting: dh1 van 1.3.3 ACA verzio is
Proba cseresznye alapon megprobaltam ezt a verziot B1230 alatt, ugyanugy szarra fagy.
Blizzard 1230 ra nincs?
|
