Welcome, Guest. Please login or register.


Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - ergoGnomik

Pages: 1 ... 46 47 48 49 50 51 52 [53] 54
781
Kijelző / Re: Pixelhibás alaplapok
« on: 2014.August.18. 09:32:04 »
A Peltier-elemmel megvalósított hűtés nem véletlenül nem terjedt el. Jó ötlet az, hogy az IC-ket a külsejükön akár 0°C alá is hűthetjük, csak nagyon sok vesződséggel jár a hűtésnek a szigetelése (Lásd még: LN2 vagy LHe hűtéses processzor, RAM és VGA tuning). Sajnálatos módon a levegőben mindig van pára, ami szépen kiül a hűtőd hideg oldalára, hogy azután később folyadék formájában elhelyezkedjen a hűtött alkatrész közvetlen közelében. Az álmos-könyvek az elektromosság és víz kombinációjáról nem sok jót írnak. :cry: A másik hibája hogy mivel alacsony a hatásfoka, ezért felesleges nagy a teljesítmény igénye.

782
Assembly / Re: Assembly programozás
« on: 2013.November.16. 13:56:59 »
IstvanV és Zozo, a segítségeteket kérném! Próbáltam elméletben számolgatni a videoszegmensek elérésével kapcsolatban egy kicsit, de mivel tudásom parányi, eléggé hihetetlen érték jött ki. Egy videosor 57(*2 - órajel két fázisa) Nick buszciklusig tart. Ebből 8(*2) az LPB beolvasása, 3 memória frissítés vagyis marad 95. Ebből jön le a tényleges képernyőtartalom elérése, ami (RMARGIN-LMARGIN)*[1|2]. 40 oszlopos kép esetében ez lehet 40 vagy 80 félciklus, mely utóbbi esetében csak 15 hozzáférési lehetőség jutna a Z80-nak 256 T ciklusonként (4MHz-es processzor) , ami szerintem elképesztően kevés. Hol a hiba a számolásomban?

783
Assembly / Re: Assembly programozás
« on: 2013.November.16. 12:40:18 »
Bocsika! Jól értem, hogy a sprite adatokat a videoszegmensekben akarod tárolni? Ha igen, én ellenjavalltnak tartom, mivel akkor nem csak a memória írását, hanem a forrásadatok olvasását is lassítani fogja a Nick. Ha félreértettem, akkor dupla bocsika és nem szóltam semmit. (Nem szorosan ide tartozó megjegyzés: ezért próbálják Amigán a gyorsítókártyáknál a rajzoló algoritmusokat arra optimalizálni, hogy mire a következő Chipmem hozzáférési lehetőség bekövetkezik a következő kiírandó adat is rendelkezésre álljon, és íráson kívül ne kelljen más hozzáférést végezni.)

784
Assembly / Re: Assembly programozás
« on: 2013.November.13. 19:03:38 »
Quote
Ijesztő számomra, de kezdek hajlani eme igazságra, de azért még van bennem remény, hogy valaki másképp idomul a kérdéshez, és mégis tud valami ennél ügyesebb közelítést ismerni fel és adni, megmentve engem a dolog potyára kipróbálásától.
Bárminek a kipróbálása soha sem számít potyára dolgozásnak. Szerintem. Még akkor sem, ha valaki már kipróbálta előtted és bebizonyította hogy működik vagy nem. Mert mi van, ha te még észreveszel valamit, ami vagy jobbá vagy egyáltalán lehetővé teszi a próba tárgyát?

Egyébként gondolod, hogy IstvanV amikor írta az ep128emu-t csak úgy ült és elmélkedett magában, vagy írta az egyre trükkösebb és optimalizáltabb teszt programokat, és időnként meglepődött? Különben ő lenne a legjobb ember erre a feladatra (ahogyan látom), de nem vagyok benne biztos hogy meg akarná írni helyetted a programod legtrükkösebb részeit. :)

785
Assembly / Re: Assembly programozás
« on: 2013.November.13. 17:45:41 »
Juj!

 Megszakítási rendszer bizonytalankodása: igen van, attól függően, hogy milyen utasítás fut éppen és az hol tart, változó számú ciklust késhet a kezelő indulása.

Nick buszkésleltetés:
  • videoszegmensben fut a kódod?
  • csak írja a videószegmenst vagy olvassa is?
  • mindig csak kereten fut a kódod, vagy a képernyő aktív területén is?
mind-mind bizonytalansági tényező, ami változó mértékű késleltetést tud okozni. Mármint olyan kód esetében, ami effektíve használja a videomemóriát.

 Elvben mintha csak NOP-okat tartalmazna: egy NOP 4 ciklus, akkor kb. 253-254 NOP-od biztosan van. Még szerencse, hogy nem csinálnak semmit, így a majdani gyakorlati megvalósítás szempontjából semmit sem mondanak a problémáiddal kapcsolatban.

Nézd, én nem akarom azt állítani, hogy te hülye lennél, csak én vagyok helikopter, de még ha nem is olvastam végig és elemeztem részletesen az összes rögzített állításodat, az olvasmány élményeim és más gépen összegereblyézett ismereteim alapján próbáltam felhívni a figyelmed a tényleges gyakorlati megvalósítás során előtted álló problémákra, illetve arra hogy valós tesztekkel gyorsabban eljuthatsz a szükséges tudás megszerzéséig, mintha próbálnál elméleti konstrukciókat gyártani jelenleg nem pontosan ismert bizonytalanságok figyelmen kívül hagyásával. Már ha jól ki bírom magamat fejezni. Sajnos az sem erősségem. :(

786
Assembly / Re: Assembly programozás
« on: 2013.November.13. 16:40:14 »
Quote from: Z80System
Hát pont ez az, amit meg akarnék úszni a kérdezgetéssel ... Nyilván ha ilyen megoldás mellett döntök, akkor annak kikísérletezésétől, hogy mekkora chunk -okban tudom a csillagaimat kirajzolni, nem ment meg senki.

De ha már most eltántorít valaki attól, hogy az 1/4KHz -es időintervallum méretéhez képest egy komoly méretű lehet az ilyen bizonytalanság miatti ráhagyás vesztesége, akkor megúszok egy csomó felesleges kísérletezést.
De most komolyan! Tényleg azt várod, hogy valami nem létező kódról itt bárki megmondja neked, hogy tudja teljesíteni a kritériumaidat vagy sem?!

Egyébként tegyük fel egy pillanatra a gondolkodó sapkát! 4kHz-es megszakításnál van 1000 órajelciklusod két megszakításkérés között. Ebből ha levonod a használni tervezett leghosszabb Z80 utasítás órajelciklusainak kétszeresét, akkor nagyjából meg van az az érték, ami garantáltan rendelkezésedre fog állni. 312 soros LPT esetén nagyjából 3,9 soronként fog bekövetkezni megszakítás. Ha lenne információ arról, hogy rasztersoronként mennyi órajel szabad a videomemória írására illetve tudnád, hogy hány ciklusonként akarod írni, akkor valszeg tudnál egy becslést adni arra, hogy átlagosan mennyi késleltetést fog összeszedni a kódod a Nick buszfoglalása miatt a megjelenített képernyő sorokban.

De gondolom te nem ezt szeretted volna itt olvasni, hanem valami "Igen, 332." szerű választ. Félek, ez nem fog menni. Senkinek.

787
Assembly / Re: Assembly programozás
« on: 2013.November.13. 15:35:04 »
Quote from: Z80System
Tehát a kérdés csak valami olyasmi, hogy van -e a "megszakítás ütemezőjének" az EP harverében valami olyan pontatlansága, ami miatt nem tudom teljesen kitölteni az 1/4KHz időt, és valami "nagyobb" idő ráhagyással kell majd dolgozzak, hogy véletlen ki ne csússzak a megszak időből (nem akarok kimaradt hangot), és az X darab megszakítás ezért egy komolyabb overhead -et tesz majd a csillagmozgatásom kódjára ahhoz képest, mintha a főprogramban futna ?
Igazából nem pont a "megszakítás ütemezője" miatt, de természetesen bizonyos időzítési pontatlanságra számítanod kell mindenképp. Legalábbis szerintem. Nem tudod semmilyen módon garantálni, hogy a megszakításkezelő órajelre pontosan mikor induljon el, mivel nem fogod tudni, hogy éppen milyen utasítást hajt végre a Z80. Ezen felül mivel a videomemóriát írod, számolnod kell a Nick által lefoglalt buszciklusokkal is. Bár ez utóbbira IstvanV vagy Zozo lehet, hogy tudna rajzolni neked egy táblázatot az egyes rasztersorokban a processzor számára elérhető szabad ciklusokról. A legegyszerűbb valószínűleg az lenne, ha elméleti számítások helyett írnál egy tesztprogramot, és tesztelnéd mennyi idő áll rendelkezésre biztonságosan.

788
Assembly / Re: Assembly programozás
« on: 2013.November.04. 19:42:22 »
Nem bátorítok én senkit, csak ha ilyesmire támadna valakinek ingerenciája - fene a gusztusát - akkor legalább könnyen tervezhesse merre rohamozzon. :lol:

789
Assembly / Re: Assembly programozás
« on: 2013.November.04. 19:37:10 »
Van is egy német internetes bazár, ahol kb. 13 Euróért lehet vásárolni abból a kivitelből (SwinSID Nano) ami a DIL 28-as tok helyén elfér, 12/9V-ról egyaránt megy és választható hogy 6581-et vagy 8580-at emuláljon. Már ha esetleg valakinek gusztusa támadna hozzábarkácsolni ilyesmit az EP-hoz. Bár szerintem ez még sokkal típusidegenebb dolog, mint a plus/4-et bővíteni SID-del. A Z80-as világban inkább az YM2149/AY-3-8910 volt a jellemző, szóval ha valamit, akkor inkább azt. Szerintem.

790
SOUND: / Re: Zeneprogramozás
« on: 2013.November.04. 17:12:39 »
Mert nem része a sorozatnak. Ha jól tippelek az alapján amit a +4-es haverodról írtál, akkor ezt valami spanja hekkelhette össze az eredeti programból és másik hangmintákból. A program képernyőjén is látszik alul, hogy ez nem tartozik az eredeti programok közé.

791
SOUND: / Re: Zeneprogramozás
« on: 2013.November.04. 15:31:53 »
Volt egy sorozat, aminek Micro... volt a címe. Talán MicroVocals, MicroRithm, MicroTechno meg még valami volt belőle. Már ha jól emlékszem a címekre. De természetesen ezek C64-ről lettek konvertálva.

Természetesen rosszul emlékeztem: Micro Series.

792
Assembly / Re: Assembly programozás
« on: 2013.November.04. 15:11:22 »
Quote from: lgb
... Plus 4 eseten nem tudom pontosan hogy van ez a TED-del (ott imho nincs kulon colour SRAM) de talan pont ezert ott meg az orajellel is faragni kell, hogy beleferjen? Vagy hasonlo ...

(persze a konkret implementacio mas, C64-en orajel ciklusokat "lophat" el a VIC, +4-nel - afaik - viszont az orajel frekvencia van valtoztatva, EP-nel pedig ugye az orajellel jatszanak ismet, csak kisse maskeppen, de ezt Zozo ugyis jobban tudja)
Nos ott tényleg nincs külön színmemória, ezért a képernyőmemória mellé direktben van egy dinamikus színmemória rendelve (pl.: default képernyő kezdőcím $0C00 és az ehhez a karakterhez tartozó szín a $0800 címen van). Ennek hála a 8 bites adatbuszán kétszer annyi adatot kell karaktersoronként átrángatni, mint 64-en. Plusz bónusz a rasztersoronként 57(*2) ciklus a 63-mal szemben. Természetesen a TED ugyan úgy lopogatja a ciklusokat, mint a VIC, cak itt két badline van de legalább a sprite-ok nem zavarnak a képbe. Egyébként szerintem nincs két órajel frekvencia, csak a processzor a kereten sokkal kevesebbet van várakoztatva, mint a látható területen. De ezt IstvanV valószínűleg pontosabban tudja.

793
Assembly / Re: Assembly programozás
« on: 2013.November.04. 15:02:04 »
Gondolom geco hangmagasság helyett amplitúdóra gondolt. +4-en a négyszögjel kitöltési tényezőjét azt hiszem úgy modulálták, hogy a szokásos számú minta helyett másfélszer akkora terület volt foglalva és a kitöltési tényezőtől függően máshol (később) kezdték a kiolvasást. Így, bár több terület kell hozzá, mint a másik hullámformáknál, de mégsem annyira pazarló. Egyébként ott a lejátszási frekvencia sem volt ennyire magas, és bár hi-fi minőségről nem beszélhettünk :ds_icon_cheesygrin:, azért nagyjából rá lehetett ismerni mi is volt a 64-es eredeti.

794
Assembly / Re: Assembly programozás
« on: 2013.November.04. 12:00:04 »
Quote from: IstvanV
A különbség attól is függ, hogy Plus/4-en engedélyezett-e a képernyő. Ha nem (az egész kép keret), akkor a fenti 2.2-es "Z80 lassulást" feltételezve 3.73 MHz-es (várakozás nélküli) Z80-nak felel meg, egyébként csak 2.51 MHz-esnek.

Egyes programok gyorsulást érnek el azzal, hogy a gépet NTSC módba kapcsolják, amivel 5 / 4 arányú "overclock" lehetséges. Így azonban nincs használható video kimenet, és a szabálytalan órajelet valószínűleg nem célszerű hosszabb ideig használni.

Létezik azonban "lassú" mód is, amelyben a CPU mindig egyszeres sebességgel fut (886723.75 Hz = ~1.95 MHz-es Z80). Ennek kikapcsolt képernyőnél lehet értelme, ha konstans sebességre és pontos időzítésre van szükség (például 1541 "turbó" töltőknél).
Hát, ez az itteni úri közönséget valószínűleg meglehetősen kevéssé érdekli, én meg ismerem ezeket a lehetőségeket. Én csak annyit próbáltam volna kihozni a dologból, hogy ha valakinek van hozzá energiája, akkor szabványos konfiguráció mellett is feltehetően megoldható a "wave converter" stílusú hangkeltés EP-on.

795
SOUND: / Re: EP The Abyss vs. C64 One Man and his Droid
« on: 2013.November.04. 11:07:36 »
Alapvetően mindenből van .SID, ami elérhető a HVSC-ben. Ha nincs benne, akkor csak ki kell várni, míg előbb-utóbb bele kerül. De szerintem ez olyan régi és népszerű, hogy biztosan meg kell legyen. Mindjárt megnézem...

A http://www.hvsc.c64.org/ oldalon a jobbra levő keresőbe beírod, hogy "rob hubbard one man and his droid" (idézőjelek nélkül), egy kattintás és már jön is a letöltési link.

Pages: 1 ... 46 47 48 49 50 51 52 [53] 54