| Szerző |
Üzenet |
PeachMan
Tag
|
# Elküldve: 2020. Dec. 28. 06:53 - Szerkesztve: peachman
Van egy kis probléma az A1200+B1260 gépemmel.
Ezt a demo-t szeretném futtatni: link
Úgy indítom a gépet, ahogy a leírásban van.
Csak setpatch, aztán a demo. Viszont minden alkalommal az inicializálásnál kifekszik és error ablakot dob. Egész pontosan a -csg résznél (bármi is legyen ez)
noc_dgr.exe
Program failed (error 80000008)
Wait for disk activity to finish.
Suspend - Reboot
Mi lehet a gond? Tönkre ment a b1260 kártya? Eddig nem tünt fel a géppel probléma. Winuae alatt indul a demo.
Esetleg valaki lepróbálná, akinek ilyen kártyája van?
060 libek telepítve vannak. Ram-test (chip+fast) eddig nem talált hibát.
|
Chain-Q
Divatamigás
|
# Elküldve: 2020. Dec. 28. 14:16 - Szerkesztve: charlie
Nekem nyilvan megy a cucc, mert en vettem fel Revision partyn a compora, mert en vagyok arrafele az orga altalaban es a compogep egy A1200+B1260...
A 80000008 guru sokminden lehet, de gyanus h. valami olyan utasitast akar vegrehajtani a cucc, amit a proci nem akar tudni. Ami pl. CPU libek fele mutat. Milyen ROM? Milyen '060 libek vannak fent? Biztos rendesen betolti azt a SetPatch? En a phase5-feleket hasznalom, a legfrissebbet a http://phase5.a1k.org/ -rol.
|
PeachMan
Tag
|
# Elküldve: 2020. Dec. 28. 17:23 - Szerkesztve: peachman
A phase5 oldalról a friss libek vannak fent.
(68040old.library, 68040new.library, 68040.library, 68060.library)
Normál 40.068 rom van a gépben, annyi hogy a maprom alapban megy a kártyán, jumpert nem variálok vele.
A gépen amúgy OS3.9 van, de a "demos" könyvtárban van a megfelelő setpatch, azt használom hozzá. (OS3.1 gépen sem volt jobb eredmény)
Úgy indítom a gépet, hogy:
- early-startup és no startup
- átlépek a "demos" könyvtárba
- futtatom a setpatch-ot
- indítom a demo-t
kép
Valamit nem jól csinálok? Más demo-k mentek így. Például: Rift
Lehet esetleg az a probléma, hogy rev2 kártya és rev1 cpu? (50MHz-en használom)
|
siz
Tag
|
# Elküldve: 2020. Dec. 28. 17:48 - Szerkesztve: siz
Nekem simán megy, most töltöttem le. (B1260, 060 Rev6/66MHz, 128M RAM). OS egy általam tákolt Commodore 3.1, szintén gyári 3.1 40.068 ROM MapROM-olva és hozzá való legújabb SetPatch (talán Cloanto-tól, 43.6). Semmi úri huncutság (=ami nem eredeti 3.1-hez való cucc, tehát 3.5, 3.9 és társai) nincsenek a gépen.
szerk: nyilván Phase5 68040.lib 46.5-ös és van, ezen kívül FBlit, FText és BlazeWCP meg nyilván BlizKick-elve egy csomó library)
szerk2: nekem akkor voltak ilyen random hibák eleinte, amikor hibásan voltak átmásolva/kitömörítve cuccok. látszólag lement a kitömörítés jó, elindult a cucc és ugyanígy elszállt.
|
PeachMan
Tag
|
# Elküldve: 2020. Dec. 28. 17:59 - Szerkesztve: peachman
Quoting: siz Nekem simán megy, most töltöttem le.
Akkor valami nagyon nem kerek a gépemmel... :(
Én ezeket próbáltam, ezekkel nem volt gond:
tbl - starstruck
tbl - ocean machine
tbl - silkcut
tbl - rift
Nem értem mi lehet a géppel akkor.
update:
Quoting: siz látszólag lement a kitömörítés jó, elindult a cucc és ugyanígy elszállt
Többször is nekifutottam, de ugyanaz lett az eredmény.
Kizártnak tartottam, hogy ez legyen a gond, de a próba kedvéért gyári a500 táppal (4.3A) és pc táppal is próbáltam, de ugyanez lett.
|
Chain-Q
Divatamigás
|
# Elküldve: 2020. Dec. 28. 18:18
Ize, hulye kerdes, foleg ha a TBL demok mennek, de biztos jo a filesystem setup? Pl. ilyen MaxTransfer 0x1fe00 be van allitva jol minden particiora? Mert az szokott ilyet csinalni, hogy kitomorited es utana nem megy.
|
PeachMan
Tag
|
# Elküldve: 2020. Dec. 28. 18:27
Persze, ilyen gond nincs.
Most átraktam másik gépbe (OS3.1) és ugyanúgy indítottam, mint ahogy írtam és abban is ugyanezt csinálja.
|
thomas^sd
Tag
|
# Elküldve: 2020. Dec. 28. 19:22 - Szerkesztve: thomassd
Quoting: peachman noc_dgr.exe Program failed (error 80000008) Wait for disk activity to finish. Suspend - Reboot
Ugyanez van nalam is.
Ugyanaz a hw es sw.
|
PeachMan
Tag
|
# Elküldve: 2020. Dec. 28. 19:38
kép - ilyen is van, amikor os3.9 alol inditom.
Eddig 1x jott csak elo, amugy 80000008 hiba van csak.
|
PeachMan
Tag
|
# Elküldve: 2020. Dec. 28. 21:53
Az említett demo valószínüleg bug-os még.
A latest phase5 libekkel nem akar indulni, de ezzel a kutyult 68060.library-val elindul és rendben lefut nálam is.
Nem tudom miben más ez a lib és nem is fogom használni általában (max tesztelgetem), de annyit tudok, hogy ezzel működik.
|
siz
Tag
|
# Elküldve: 2020. Dec. 28. 23:23
Megnéztem még egyszer a Phase5-os listát és az ott levő 46.7-es és 46.15-ös 68060.library-vel is megy nálam. Szóval passz.
|
thomas^sd
Tag
|
# Elküldve: 2020. Dec. 28. 23:31
Rev 1d4 lap.
A masik 060 libbel megy nekem is!
Koszi!
|
PeachMan
Tag
|
# Elküldve: 2020. Dec. 29. 05:28
Quoting: siz 46.7-es és 46.15-ös 68060.library-vel is megy nálam
Köszi, hogy megnézted. Kipróbáltam, nálam egyikkel sem megy, mindegyikkel ugyanaz a hiba. Kizárólag a linkelt "fura" 68060.library-vel működik.
|
repa
Tag
|
# Elküldve: 2021. Feb. 28. 20:13
Blizzard 1230/IV 64mb rammal tette szépen a dolgát az elmúlt években. Pár napja használat közben black screen, gép gyorsan kikapcs. Újraindítás után vagy semmi, vagy fagyás. Alapos tesztelés eredménye, hogy az A1200 rendben működik, a 1230 kártya memória nélkül megy, de amint teszek bele bármilyen memória modult, random fagyás vagy nem is indul a gép. Átalakított minőségi pc tápról megy, amper van bőven. 50 Mzh cpu + 68882. Az elem lemerült, 2V mérek rajta. Találkozott valaki már hasonló problémával, lehet vele valamit kezdeni?
|
dh1
Mr. DTP
|
# Elküldve: 2021. Feb. 28. 21:29
foglalat tisztitas?
radir?
vagy kontaktspray (ez csak ideiglenesen)
de en leginkabb foglalatot cserelnek
|
Chain-Q
Divatamigás
|
# Elküldve: 2021. Már. 01. 00:22
En nyitasnak letiltanam a MAPROM-ot, erre van jumper a kartyan, es kiprobalnam ugy. Ha ugy megy, akkor sajnos lattam mar Blizzard 1230-at doglott MAPROM funkcioval. Amugy meg siman lehet h. meghalt valami a RAM vezerlesben. Hat ezek is hany eves hardverek mar, 25 fele lassan, raadasul eleg forron is jarnak...
|
Sax
Tag
|
# Elküldve: 2021. Már. 05. 18:00
Quoting: ratman Két lehetőség van: - ha már mediator, akkor 256 megás PCI-os R9200 vissza tud adni akár 128 megát is a rendszernek, nem gyors és nem stabil. - a másik - ezt sem próbáltam soha - a zz9000 z3-as firmware-el is vissza tud elvben adni valamennyit a rendszernek: - nem autoconfigos, és hát mivel z3 ez sem lesz valami gyors. - fastlane z3 amiről fogalmam sincs, hogy múködik-e mediator mellett.
Fastlane memóriabővítőként működik Mediatorral!
|
Sax
Tag
|
# Elküldve: 2021. Már. 05. 18:03 - Szerkesztve: Sax
Memória:
Sysinfoval is meg lehet nézni a RAM prioritását.
Sajnos azt kell hogy mondjam, a Mediator RAM-ok nagyon lassúak.
Számolásban nem látsz különbséget, pl. a Sysinfo, Sysspeed ugyanannyi MIPS-et mér. Viszont ha elindítasz egy demot, játékot, lehet, hogy felére is visszaesik a sebesség. Pl. egy MP3-at nem bír lejátszani full minőségben egy 060/50 MHz-en! (ha jól emlégszem egy Bl1240 A1200-esen éppen le tudta játszani)
Mióta saját RAM-os CPU kártyám van, simán lejátsza az MP3-at 60-70% CPU terhetség mellett. (Megjegyzem A3660-al is 60-70% terhelést írt)
|
ratman
Kék troll
|
# Elküldve: 2021. Már. 06. 19:48 - Szerkesztve: ratman
Quoting: Sax Sajnos azt kell hogy mondjam, a Mediator RAM-ok nagyon lassúak.
Ez nem véletlen, mivel a mediatoron lévő ram (amit gondolom a videókártya memóriájábol osztasz viszza a rendszernek), ugyanazon a 2-4-8 megás memória ablakon keresztül érhető el, mint minden más a mediátoron lévő eszköz. Az meg nem lesz olyan nagyon gyors. :D
Szóval ebben nincsen semmi meglepő, nincsen semmi látnivaló emberek, kérem mindenki haladjon tovább. :D
|
thomas^sd
Tag
|
# Elküldve: 2021. Már. 07. 18:59
Quoting: Sax ha jól emlégszem egy Bl1240 A1200-esen éppen le tudta játszani)
A1200 blizz1240/40
Mpega.lib nofpu
Delitracker
22050hz stereo medium
Kb ez a vege. High talan meg elmegy. Ha emlekeim nem csalnak.
A 44khz sztereoban felejtos 040 en.
Fugg meg a layer3 bitrate tol is.
|
Sax
Tag
|
# Elküldve: 2021. Már. 10. 08:30
Hmmm... Lehet, hogy rosszak az emlékeim... Úgy rémlik, hogy Blizzard1230/IV 50 MHz-en éppen lejátszotta felezve monoban az mp3-at low minőségben, és az mp2-őt sztereóban high 22050 Hz-en. (Shellből indítva mpega-val.) Persze függ a bitrate-ől is, 128 kbps-ban volt a legtöbb zeném akkoriban, mp2-ben meg 192-ben. A Blizzar 1240/25 elvileg 2x gyorsabb. 040/40 pedig 3x. Monoban 44,1kHz-en bármilyen mp3-at le kellene nyomnia! Próbáld ki, de ne mindenféle zenelejátszóval!
|
dh1
Mr. DTP
|
# Elküldve: 2021. Már. 10. 08:38
A1200 blizz1240/40
Mpega.lib nofpu
ezt nem is ertem :)
040-en no FPU? :D
|
siz
Tag
|
# Elküldve: 2021. Már. 10. 08:55
Quoting: dh1 040-en no FPU? :D
Biztos LC vagy EC. :D
|
Chain-Q
Divatamigás
|
# Elküldve: 2021. Már. 10. 11:33 - Szerkesztve: charlie
Megint megy a dünnyögés gondolkodás helyett...
A no-FPU verzió gyorsabb mint az FPU-s, ezért realtime lejátszáshoz az ajánlott, viszont a floating point verzió meg "pontosabb".
This library can decode MPEG 1,2 layers I, II & III to
audio pcm samples. This package contains '020 & '040
integer decoder versions and '020 & '040 floating
point decoder versions (slower, but more accurate).
valamint:
*** IMPORTANT ***
Please, note that FPU versions are more acurrate
that integer ones, but they consume more CPU !!!
So, don't e-mail me that mpega.library is slower
than mpega before you check this !!!
*** IMPORTANT ***
Idézetek innen: http://aminet.net/package/util/libs/mpega_library
|
Chain-Q
Divatamigás
|
# Elküldve: 2021. Már. 10. 11:36 - Szerkesztve: charlie
@Sax:
Monoban 44,1kHz-en bármilyen mp3-at le kellene nyomnia!
Thomas direkt leírta h. sztereóról beszélt. Nyilván a 22Khz sztereó vagy a 44Khz monó kb. ugyanannyi kakaót igényel... És a 44Khz sztereó valóban nem fér bele egy negyvenesen. Amúgy is Amigán vagyunk, miaz h. monó, hagyjál már. :)
|
Sax
Tag
|
# Elküldve: 2021. Már. 10. 17:56
Na jó... Szükség törvényt bont, néha elmegy az monoban is (pl. ha nosztalgiából CRT TV-re kötöm)
Azért most ezen felbuzdúlva egy fastRAM-os ezerkettest megkínáltam egy 128 Kbps MP3-al. :) Negyedelve lowQ-ban, monoban majdnem lejátsza! 28 MHz-en biztosan menne. Ha lesz egy kis időm, megnézem mp2-vel is. :)
|
dino
Kék troll
|
# Elküldve: 2021. Már. 10. 19:47
Quoting: Sax megnézem mp2-vel is. :)
Empekettonek nem kell annyi energija...
|
Sax
Tag
|
# Elküldve: 2021. Már. 10. 21:02
Szurkoljatok neki! :-)
|
dh1
Mr. DTP
|
# Elküldve: 2021. Már. 10. 23:15
Quoting: charlie Megint megy
hat ezt nem vagtam, van a gepemen egy lassito koprocesszor :D
sorry :)
de pusztuljak el ha Amigan .mod helyett mp3-at hallgatok! ;)
|
Chain-Q
Divatamigás
|
# Elküldve: 2021. Már. 11. 01:03 - Szerkesztve: charlie
@dh1
van a gepemen egy lassito koprocesszor :D
Oh, a jó öreg vita, hogy mire is jó egy FPU. :) Ilyenkor mindig ilyen Vampire-team utánérzésem van... Ők terjesztettek sok okosat az FPU-ról, ami azóta is ott kering összezagyválva az userek fejében. Akkor hát leírom részletesen, hátha még jó lesz ez a post is valamikor egyszer a jövőben linkelésre.
Az FPU nem arra való, hogy általánosságban gyorsítson... Ha nem használsz olyan szoftvert ami használja, akkor leginkább semmi különbséget nem jelent. Esetleg enyhén - jó eséllyel nem érzékelhetően, de - lassít, mert a multitask OS-nek minden taszkváltás között az FPU állapotát is el kell menteni és visszaálltani.
Arra jó, hogy ha 32 v. 64 bites (esetleg egyes platformokon, ideértve a 68k-t is 80 bites) lebegőpontos számításokat végzel, azokat sokkal gyorsabban tudja elvégezni mint a központi processzor, amely erre csak erős szoftveres támogatással képes, mivel nem ismeri a szabvány lebegőpontos adatformátumokat. Ha ugyanazt az algoritmust FPU-n vs. CPU-n egy szoftveres lebegőpontos library-val futtatod, a hardveres megoldás néhány nagyságrenddel gyorsabb. Ez mindig is így volt és így is lesz.
Ellenben, ugyanazt az algoritmust sokszor meg lehet írni fixpontos számokkal is, ekkor a CPU simán gyorsabb lehet, mint az FPU. Ez nem csak 68k-n van így, hanem szinte minden architektúrán. Pl. a Javascript egyik legnagyobb teljesítménykorlátja, hogy minden számot lebegőpontosan ábrázol. Szinte az összes JS, vagy általánosságban a böngészőben futó szoftverek gyorsítására tett kísérlet (asm.js, wasm) arra szorítkozik, hogy ilyen-olyan módon bevezeti az egész számokat a rendszerbe, hiszen akkor azokat a CPU-val is ki lehet számolni és nem kell hozzá a lebegőpontos egység. (Én meg csak röhögök, hogy negyven év elteltével még mindíg azon szívunk, mint a C64 ill. általában a 8 bites gépek BASIC-jével: onnan meg ROM helyhiány miatt hagyták ki az egész számok támogatását, így az is mindent lebegőpontosan számol, azért olyan kurbli. Aztán a JS visszavezette ezt a brilliáns ötletet, mert hogy most már van FPU, minden jó gyors lesz lebegőpontban is. Hátööö. Nem.)
Ha ennyire rossz a lebegőpont, miért nem írnak mindent fixpontosra? A fixpont hátránya a korlátozott pontosság, ergó komolyabb algoritmusoknál egész egyszerűen nem használható. Ekkor jönnek be a lebegőpontos számok és az FPU. Például egy kockát forgatni a képernyő közepén 3D-ben arra simán elég a fixpont. Még egy Doom-szerű, 2,5D-s grafikához is. De egy fullos 3D világ teljes ábrázolására képes motort, mint pl. a Quake, eléggé elképzelhetetlen jól megírni lebegőpontos számok nélkül, túl sok kompromisszummal járna. Az MP3 határeset, a fixpontos számokkal még pont élvezhető eredményt kapsz, főleg a Paulán, amelyiknek elég limitált a "hangfelbontása". De ha pl. WAV-ba akarod kirenderelni ugyanazt, vagy valami komolyabb hangkártyád van, akkor erősen ajánlott a lebegőpontos és ezzel együtt az FPU-s változatot használni. (Megjegyzem, az h. van fixpontos és ennyire gyors MP3 dekóder library, egyáltalán nem jellemző, szóval örüljünk h. Amigán ilyen is van, és így egy harmincason is lehet valamennyire MP3-at hallgatni, nem kell hozzá egy hatvanas.)
Egyébként, kb. úgy kell elképzelni a fixpont és a lebegőpont közti különbséget, mint mondjuk az ECS 4096 színe és az AGA, vagy a modern grafkártyák és gépek 16 millió színe közötti különbséget. Rengeteg grafikához és játékhoz bőven elég az ECS, és kellő hozzáértéssel gyönyörű és remek progikat lehet rá írni, de azért ha fényképet retusálsz, annak nem állnál neki egy olyan chipseten, ami azzal kezdi h. 4 bit per színkomponensre kvantál mindent... Érted. Ellenben egy ECS progi nem fog gyorsabban futni csak azért mert van AGA, viszont az AGA-s vagy általában egy truecolor cucc meg több helyet foglal, mert egyszerűen a magasabb színmélységű bitmapok nagyobb méretűek, és lassabban is kezelhetők mint a 12 bites képek. Még azt támogató HW-n is. Minden jár valamiféle kompromisszummal.
Fogalommagyarázat:
A fixpontos számok gyakorlatilag egész számok, amelyek a nevüket arról kapták, hogy a törtrész kezdete, a tizedesvessző helye mindig "fix". Tehát pl. ha van egy 32 bites egész számom, azt tudom úgy kezelni, hogy 16 bit egész, 16 bit törtrész. Ebben az esetben 65536 különbözö egész szám, 65536 különböző törtértékét tudom tárolni. Jól látszik, hogy a pontossága erősen limitált, hiszen hiába akár nulla az egészrész, azokat a biteket nem tudom használni, továbbra is csak 16bit áll rendelkezésre a törtrész ábrázolására.
És a lebegőpontos számok? Gyakorlatilag normálalakú számok, de tizes számendszer helyet kettes számrendszerben (binárisban) ábrázolva. A számban fix mennyiségű bit van fenntartva az alap és a kitevő ábrázolásához. Pl. 32 bites lebegőpontos számok esetén általában 8 bit kitevő és 23 bit alap, plusz előjel bit. Ez azt jelenti, hogy egy lebegőpontos számban az adat mennyisége azt határozza megy, hogy a számod hány számjegyből állhat összesen, azt hogy a tizedespont hol van benne, mellékes. Ez lehetővé teszi, hogy ugyanaz azzal a 32, 64, vagy 80 bittel rettentő kicsi, szinte csak törtész tartalmazó, valamint hatalmas de kevésbé pontos számokat is ábrázoljunk. Mint ahogy papíron is leírhatod, hogy 3.14567890123 * 10^-2, vagy 3.14567890123 * 10^8. Ez a két szám mindkét esetben ugyanannyi adatból (számjegyből) áll, de mégis, a két szám tíz nagyságrenddel különbözik.
A lebegőpontos számok részletes magyarázatáról egy jó videó pl. itt: https://www.youtube.com/watch?v=PZRI1IfStY0 (angolul)
|
