Enterprise Forever
:HUN => Hardver => Topic started by: balagesz on 2014.December.21. 23:39:53
-
Üdvözlöm a tisztelt társaságot!
Egy ideje már olvasgatom a fórumot (illetve a kapcsolódó oldalakat), de úgy érzem, elvesztem az információkban, és kénytelen vagyok kérdezni! :)
Eddig még nem foglalkoztam Enterprise-szal, de már nagyon régen sikerült beszerezni egyet. Viszont vagy 10 évig ki sem sikerült próbálni, mivel nem volt hozzá még egy videokábelem sem. A közelmúltban viszont előkerült a szekrényből, és nekiálltam keresgélni a neten információkat róla. Így jött szembe ez a fórum is. :)
Odáig jutottam, hogy a gép működik, ISSUE6-os alaplap, "új" NICK-es verzió szerencsére. Beleépült a CVBS kimenet, illetve a táprészt átalakítottam, mivel az eredeti tápegysége "nem tetszett". (Csatlakozó kontakthibás, melegszik, stb...)
Szóval a gép "megy", de van még rajta mit faragni. (Például rossz a billentyűzetfólia (minő meglepetés...), egy külső billentyűzet illesztése már folyamatban van, csak a végére kellene már érnem.) No de a kérdés: hogyan tovább? :) Ugyanis semmi (értsd: SEMMI) perifériám nincs hozzá. Ezen majd még ügyködni akarok, de ennyire nem szaladnék előre. Elsőre két dolgot csinálnék meg:
- Az alaplapi ROM helyére a javított BASIC + EXOS-t - ahogy látom - célszerű lesz berakni
- A ROMBAY kártyájából a kijövő BASIC helyére be lehet rakni egyéb "okosságokat"
Kérdések: Mi a jelenlegi "leghibajavítottabb" BASIC + EXOS verzió? Gondolom annyira ezek már nem titkosak. :) Az eddigi "nagy kedvenc" gép számomra a Commodore plus/4, abban van az ismerkedéshez egy kiváló (khm... :) ) MONITOR program. Ehhez hasonló program - ahogy láttam - létezik Enterprise-ra is, no de melyiket lenne érdemes megnéznem? Ráadásul olyan verzió kellene, amelyiket "okosságként" a BASIC helyére be lehetne rakni. (Egyrészt ez mindig jól jön, másrészt - egyelőre - nem tudok töltögetni. :) )
-
Hello! Hat szerintem vegyel SD kartya illesztot. Akkor lesz vmi ertelmes periferiad, helyed is eleg, modern is, gyors is, stb :) Plusz: basic cartridge helyere megy, sajat flash-et EP-rol lehet ujrairni, igy belepakolhatsz akar sajat dolgokat is adott esetben, ha vmi kell. Ha az alaplapi ROM-ot "modernizaltad", es igy IS-BASIC ott van, az SD illeszto flash-eben az arra szant hely is hasznalhato masra.
-
A legegyszerűbb megoldás tényleg az SD illesztő lenne, egyszer csak eljutok oda is. :) De egyelőre még nem tartok ott, meg amit csak lehet, azt inkább "összefaragom" magam. (Legalábbis ez a terv. Remélem idő lesz rá, meg a lelkesedés is kitart.)
-
Üdv :)
Az EXOS-hoz itt találhatsz részletes infót, beszereléssel együtt EXOS (http://ep128.hu/Ep_Util/Exos.htm), úgy látom, hogy a 2.1-es Basic javított verziója tölthető le szinte mindenhonnan, az oldalon ott van a módosítatlan is. Itt megtalálhatod az EXOS 2.4 (http://enterpriseforever.com/programozas/exos-2-3-tovabb-fejlesztese/msg33427/#msg33427)-et, Zozo tudna nyilatkozni arról, hogy melyiket lenne érdemes használnod, vagy esetleg várni egy keveset, mire a 2.4 mögött nem lesz ott a beta :D
Amíg nincs "semmid" a géphez, addig vagy az emulátor, vagy a Tapir, vagy az EPTE használatával beciripelheted a programokat :)
Úgy tudom, hogy a legtöbben a HEASS-ra szavaznak, mert gyors, és nagyméretű forrást is kezel, én az ASMON, és TASMON-t használtam, ugyan nem sokat, és FENASS ami kiemelkedik még a mezőnyből, de ha programozni szeretnél, akkor inkább a Notepad++, vagy Context és SJASM kombót ajánlom Winfos alatt, debugolásra meg az EP128emu-t, szerintem ez a leghatékonyabb :)
-
Itt megtalálhatod az EXOS 2.4 (http://enterpriseforever.com/programozas/exos-2-3-tovabb-fejlesztese/msg33427/#msg33427)-et, Zozo tudna nyilatkozni arról, hogy melyiket lenne érdemes használnod, vagy esetleg várni egy keveset, mire a 2.4 mögött nem lesz ott a beta :D
Az ott látható beta5 az utolsó. Felelőtlen ígéreteket nem tennék, hogy mikor lesz kész, Lacika is akar mindenféle EDITOR javításokat :-)
Ha jól értem nincs ellenedre némi hardver barkácsolás :-) Ha veszel egy darab próbapanelt élcsatlakozóval, kell még 512K SRAM, 512K Flash ROM, 1 db 74HCT138 meg egy marék drót :-) ebből összehozol 512K RAM és 512K ROM bővítést, ennyi ROM-ban az összes fontos ROM program elfér. De esetleg az alaplapra is rá lehet építeni.
-
Az ott látható beta5 az utolsó. Felelőtlen ígéreteket nem tennék, hogy mikor lesz kész, Lacika is akar mindenféle EDITOR javításokat :-)
Az a fránya időhiány ;) lehetne mondjuk 48 órás egy nap :D, amiből csak 8-at, vagy se kell dolgozni ;)
-
Az a fránya időhiány ;) lehetne mondjuk 48 órás egy nap :D, amiből csak 8-at, vagy se kell dolgozni ;)
Esetleg EP-vel foglalkozo munkahely, ez egy csomo problemat megoldana :)
-
Az EXOS-hoz itt találhatsz részletes infót, beszereléssel együtt EXOS (http://ep128.hu/Ep_Util/Exos.htm), úgy látom, hogy a 2.1-es Basic javított verziója tölthető le szinte mindenhonnan, az oldalon ott van a módosítatlan is. Itt megtalálhatod az EXOS 2.4 (http://enterpriseforever.com/programozas/exos-2-3-tovabb-fejlesztese/msg33427/#msg33427)-et, Zozo tudna nyilatkozni arról, hogy melyiket lenne érdemes használnod, vagy esetleg várni egy keveset, mire a 2.4 mögött nem lesz ott a beta :D
Ezt az oldalt mintha már láttam volna. :) Nem vagyok a beta verzió ellen, szerintem ha odáig jutok, úgyis valami FLASH lesz beépítve az eredeti EXOS helyére, azt meg nem kaland újraprogramozni.
Amíg nincs "semmid" a géphez, addig vagy az emulátor, vagy a Tapir, vagy az EPTE használatával beciripelheted a programokat :)
Na ez az, amit szívem szerint kihagynék. (Annak idején magnóztam én eleget, öreg vagyok már ehhez. :) )
Úgy tudom, hogy a legtöbben a HEASS-ra szavaznak, mert gyors, és nagyméretű forrást is kezel, én az ASMON, és TASMON-t használtam, ugyan nem sokat, és FENASS ami kiemelkedik még a mezőnyből, de ha programozni szeretnél, akkor inkább a Notepad++, vagy Context és SJASM kombót ajánlom Winfos alatt, debugolásra meg az EP128emu-t, szerintem ez a leghatékonyabb :)
Ezek - ahogy nézem - inkább komplett fejlesztői környezetek. (Ami természetesen nem baj, sőt...) Első körben egy egyszerűen használható, ROM-ba rakható MONITOR (-t is tudó) cucc kellene. Ezekből melyik ajánlható ilyen célra? :) Később mindenképpen szeretnék majd programozni is, de azt manapság már kényelmesebb cross-platform csinálni a kedvenc editor + assembler kombóval, természetesen.
Ha jól értem nincs ellenedre némi hardver barkácsolás :-) Ha veszel egy darab próbapanelt élcsatlakozóval, kell még 512K SRAM, 512K Flash ROM, 1 db 74HCT138 meg egy marék drót :-) ebből összehozol 512K RAM és 512K ROM bővítést, ennyi ROM-ban az összes fontos ROM program elfér. De esetleg az alaplapra is rá lehet építeni.
Hardvert szeretek barkácsolni, sőt... (Amúgy is inkább vagyok hardveres mint szoftveres.) A felsoroltakból venni semmit sem kell, mind van. Meg még kedv is van, csak idő legyen! :)
-
Ezek - ahogy nézem - inkább komplett fejlesztői környezetek. (Ami természetesen nem baj, sőt...) Első körben egy egyszerűen használható, ROM-ba rakható MONITOR (-t is tudó) cucc kellene. Ezekből melyik ajánlható ilyen célra?
Az EPDOS-ban van egy egész jó kis monitor. Tud disassemblálni, van hexadump, lehet memóriába írni, tud portot írni, és számrendszerek között átváltani (hirtelen ennyi jut eszembe). És mindez elérhető bárhonnét, ahol EXOS-parancsot tudsz kiadni.
Itt van jó kis leírás róla:
http://ep128.hu/Ep_Util/EPDOS.htm
-
Na ez az, amit szívem szerint kihagynék. (Annak idején magnóztam én eleget, öreg vagyok már ehhez. :) )
Esetleg gyorsabb sebességet, vagy akár turbó betöltőt is lehet használni, így kétszer olyan gyorsan tölthet be.
Igaz, még ez is 25 évvel ezelőtti technológia, de még mindig gyorsabb, mint turbó nélkül.
A "ciripelést" fel lehet venni mp3 lejátszóra is valami jó magas bitrátával, és arról tölteni, mintha magnóról töltenénk.
-
Igaz, még ez is 25 évvel ezelőtti technológia, de még mindig gyorsabb, mint turbó nélkül.
A "ciripelést" fel lehet venni mp3 lejátszóra is valami jó magas bitrátával, és arról tölteni, mintha magnóról töltenénk.
Persze, ez nyilvánvaló. De 25 (inkább 30) évvel ezelőtt is volt már ennél modernebb technika, ami szintén nem "típusidegen". Nem a magnó, mint periféria az, amit kihagynék, hanem maga az elv. :) (Ha egyszer nagyon mazochista akarok lenni, azért nem kizárt hogy kipróbálom.)
Az EPDOS-ban van egy egész jó kis monitor. Tud disassemblálni, van hexadump, lehet memóriába írni, tud portot írni, és számrendszerek között átváltani (hirtelen ennyi jut eszembe). És mindez elérhető bárhonnét, ahol EXOS-parancsot tudsz kiadni.
Itt van jó kis leírás róla:
http://ep128.hu/Ep_Util/EPDOS.htm
Na, ez is érdekes lehet. A távlati tervben szerepel valami EXDOS klón kreálás, egy ilyen kiegészítés pont jól jöhet hozzá.
-
Esetleg EP-vel foglalkozo munkahely, ez egy csomo problemat megoldana :)
Az biztos is, erről már lecsúsztunk :D, mint kiderült a maga idejében se onnan mentünk volna nyugdíjba :D
-
Ezek - ahogy nézem - inkább komplett fejlesztői környezetek. (Ami természetesen nem baj, sőt...) Első körben egy egyszerűen használható, ROM-ba rakható MONITOR (-t is tudó) cucc kellene. Ezekből melyik ajánlható ilyen célra? :) Később mindenképpen szeretnék majd programozni is, de azt manapság már kényelmesebb cross-platform csinálni a kedvenc editor + assembler kombóval, természetesen.
Elméletileg mind a háromnak van ROM verziója.
-
He-he...
Nézzetek el balagesz blogjára a hup.hu-n (lustáknak balagesz blogja (http://hup.hu/blog/18982)).
Érdekes lehet még BSZ's Site (http://bsz.amigaspirit.hu/), illetve Evo Lution (http://plus4world.powweb.com/software/Evo_Lution).
-
Az Evo Lution marha jól néz ki, mintha egy kevésbé jól beállított tv-t néznék :D , fasza az ötlet, és a kivitelezés is, nekem csak egy bajom van ezekkel a megoldásokkal, hogy itt már szinte semmit se csinál az eredeti hardware, egyedül a felbontás, és a színek, amik az eredeti hardware korlátozott le. Tényleg jó. :)
-
A távlati tervben szerepel valami EXDOS klón kreálás
Ahogy elnézem azt a Plus 4-es cuccodat, nem fog gondot okozni összerakni egy EXDOS kártyát :-)
Az eredeti kapcsolási rajzot átalakítva fix címzésűre egy csomó alkatrész megspórolható.
-
Elméletileg mind a háromnak van ROM verziója.
Ezek szerint ízlés kérdése, hogy melyik a jobb? :) Mondjuk kipróbálhatom az összeset is akár, aztán majd kiderül.
Ahogy elnézem azt a Plus 4-es cuccodat, nem fog gondot okozni összerakni egy EXDOS kártyát :-) Az eredeti kapcsolási rajzot átalakítva fix címzésűre egy csomó alkatrész megspórolható.
Igen, nem érzem ezt olyan nagy kihívásnak. :) Igazából egy problémám van: a használt FDC. Nincs valakinek eladó WD1772-je? :) (A szmájli ellenére a kérdés komoly. Akár kettő is jöhetne belőle. A környezetemben nem találtam ilyen csipet. Még az is eszembe jutott, hogy bedrótozok egy PC/XT I/O kártyából kiműtött floppy-vezérlőt, de az EXDOS módosítása hozzá most még túl nagy falat lenne.) Egyébként ezt egy ilyen kombinált cuccnak tudom elképzelni, hogy lesz mellette IDE vezérlő is. Erről is majd lesz kérdésem, de odáig el kell jutnom, ennyire nem akartam előreszaladni. :) Remélem hogy az ünnepek között (Boldog Karácsonyt!) lesz idő meg kedv a ROM-os részhez, utána majd meglátom.
-
Nincs valakinek eladó WD1772-je? :) (A szmájli ellenére a kérdés komoly. Akár kettő is jöhetne belőle.
Van, 1500 ft/db.
Egy kisebb adag :-) (http://gafz.enterpriseforever.com/Galery/Bovitmenyek/Picture/12_wd1772x17k_1.jpg), összesen 40 lett pár éve felvásárolva belőle.
-
Van, 1500 ft/db.
Egy kisebb adag :-) (http://gafz.enterpriseforever.com/Galery/Bovitmenyek/Picture/12_wd1772x17k_1.jpg), összesen 40 lett pár éve felvásárolva belőle.
Kettőt kérnék! :-D (A részleteket magánban, nemsorára jelentkezek! :) )
-
Ezek szerint ízlés kérdése, hogy melyik a jobb? :) Mondjuk kipróbálhatom az összeset is akár, aztán majd kiderül.
Igen, meg szokás :D , de gondolom a Heass a legjobb, azt pregerálják a legtöbben, én meg még sose használtam :)
Ja, bocsi, most esett le, hogy a Plus4-es kártyát te készítetted, vagy legalábbis nagyban benne voltál, jó cucc :) Csak az ilyen demókat nem szeretem annyira (tetszenek), mert nem az eredeti hardver határait feszegetik.
-
Igen, meg szokás :D , de gondolom a Heass a legjobb, azt pregerálják a legtöbben, én meg még sose használtam :)
Na majd akkor azzal kezdek! :)
Csak az ilyen demókat nem szeretem annyira (tetszenek), mert nem az eredeti hardver határait feszegetik.
Nyilván, ezzel mindenki tisztában is van, nem véletlenül külön kategória.
-
Fejlemények:
Most sikerült a dologgal egy kicsit foglalkoznom. Az alaplap módosítása az EXOS+BASIC cseréhez megtörtént:
(http://bsz.amigaspirit.hu/Enterprise/pics/s/pic20150104_001s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/pic20150104_001.jpg)
Amit "vadásztam" FLASH-t, azt a programozóm nem ismeri, :( így egy rendes EPROM került a helyére. A 2.4ß5 szépen el is indult:
(http://bsz.amigaspirit.hu/Enterprise/pics/s/pic20150104_002s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/pic20150104_002.jpg)
Eddig minden rendben. "Monitor" témában is próbálkoztam kicsit, ott viszont egyelőre nincs sikerélmény. Egyrészt a Turbo AsMon 1.5 (http://ep128.hu/Ep_Util/Prg/Turbo_AsMon15.rar)-öt, másrészt a FENOMASS (http://ep128.hu/Ep_Util/Prg/Fenas12.rar)-t próbáltam, mindkettőből a .ROM kiterjesztésű fájlt sütöttem be. Most a BASIC kártyájába került egy (másik fajta) FLASH, ehhez természetesen a kártyát "egy kicsit" át kellett faragni. Ez a két program egyáltalán működőképes ott? Ha jól rémlik, az alaplapi 64K van a $00..$03-as "lapokon", a ROMBAY meg a $04..$07-en. A FLASH-t úgy programoztam, hogy a 32K-s .ROM fájlok elvileg a $04..$05 területekre esnek. Mit kellene látnom, ha valamelyik működne? A :HELP parancsra előjövő listában nincs semmi különleges, egy BASIC v2.1, egy WP v2.6 (SUPERWP) illetve egy WP v2.1 sort látok csak.
Kihagytam valamit? :-D
-
Mit kellene látnom, ha valamelyik működne? A :HELP parancsra előjövő listában nincs semmi különleges, egy BASIC v2.1, egy WP v2.6 (SUPERWP) illetve egy WP v2.1 sort látok csak.
Kéne ASMON, vagy FENAS sornak lennie.
EXOS 2.3+ esetén bárhol lehetne az adott ROM.
Nézd meg BASIC-ből, hogy mi látszik:
10 FOR I=0 to 15
20 PRINT SPEEK(4,I)
30 NEXT
Ez kiírja a 4-es szegmens első 16 bájtját, ami optimális esetben az adott ROM fájl első 16 bájtja :-)
-
Egy ilyen számsort írt ki:
84, 69, 83, 84, 95, 82, 79, 77, 195, 192, 63, 195, 205, 219, 205, 255.
Ezt visszaellenőrizve, ez a "TEST_ROM" szöveg, illetve az első 16 BYTE-ja annak, amit beégettem. (Ez a TASMON15.ROM fájl eleje.) A jó hír: jónak tűnik amit csináltam. A rossz: miért nem jó? :) Van a ROM-okban valamilyen ellenőrző összeg? Ha van, esetleg a számításhoz egy ilyen BASIC program?
(Előzőleg visszaraktam az eredeti EXOS ROM-ot az alaplapra, a BASIC ROM-ot meg a módosított kártyába. Úgy volt BASIC, emiatt talán a kártyát nem toltam túlzottan elfele. :) )
-
És az 5-ös szegmensen mit látsz?
Milyen cartridge (foglalatok száma) lett átalakítva? 64K-hoz a plusz címvezetéket is bekötötted?
ROM CRC csak az EXOS saját magára van, a bővítésekre nincs.
-
Miután sikerült a táp-problémát megoldani (http://enterpriseforever.com/hardver/belso-12v-taparamkor/msg44328/#msg44328), eszembe jutott egy kérdés. Ide is beszúrom ezt a képet:
(http://bsz.amigaspirit.hu/Enterprise/pics/s/pic20150114_001s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/pic20150114_001.jpg)
Az a szép vezeték, ami a stab.IC meg a tekercs között jön a ROMBAY csatlakozójára, az mi akar lenni? (Azt leszámítva, hogy talán az A13.) Van-e erről valami "legenda"? Elég sok érdekesség kiderült már a géppel kapcsolatban.
Amúgy megjött a WD1772 is, (Köszönet Zozo-nak!) lassan neki fogok tudni állni a forrasztgatásnak, csak legyen rá idő. A MONITOR-os történethez kapcsolódik, hogy megpróbáltam az EPDOS-t (az 1.9-et (http://ep128.hu/Ep_Util/EPDOS19.htm)) is beindítani. Ez a :HELP listában szépen megjelenik, de az :EPDOS parancsra elindul a WP. :-D Ez így "normális", vagy még mindig van valami gáz a BASIC kártya átalakításom körül? EXDOS kártyám természetesen még nincs.
-
Az a szép vezeték, ami a stab.IC meg a tekercs között jön a ROMBAY csatlakozójára, az mi akar lenni? (Azt leszámítva, hogy talán az A13.) Van-e erről valami "legenda"? Elég sok érdekesség kiderült már a géppel kapcsolatban.
Erre én is nagyon kíváncsi lennék! Hátha előkerül majd egyszer egy hardveres is a cégből, akkor majd kifaggatjuk :-)
Nézd meg a lap alját, ott a vezeték csak el van vágva a Z80-nál és a cartridgenél is. ISSUE 3-4-es alaplapokon még utólag, 5-6-osokon már eleve úgy készült a NYÁK.
Csak tippelni tudok, hogy kezdetben 2x8K EPROM-ban volt a BASIC, és ekkor ugye az A13 vezérelte a címkiválasztás a cartridge-ben. Lehet, hogy ha valami brutál lassú EPROM-okat sikerült beszerezni kiárusításon, akkor esetleg pont a rövidebb, vastagabb drót kellett ahhoz, hogy jól működjön :-)
Én amúgy több gépben is összekötöttem a NYÁK-on az eredeti vezetéket, és nem volt gond. Ez főleg akkor érdekes, ha foglalatba kerül a Z80, akkor egyszerűbb kidobni ezt a plusz drótot.
Ez a :HELP listában szépen megjelenik, de az :EPDOS parancsra elindul a WP. :-D Ez így "normális", vagy még mindig van valami gáz a BASIC kártya átalakításom körül? EXDOS kártyám természetesen még nincs.
Igen, mert nem lát EXDOS-t. De EPDOS-ra maga a fájkezelő indulna el. Az általad keresett monitor parancsok közvetlenül adhatóak, pl:
:SM 255,0
Az kidumpolja a rendszerszegmens elejét.
Itt (http://www.ep128.hu/Ep_Util/EPDOS.htm) menj le az "Egyéb parancsokig", ott kezdődik a téged érdeklő rész.
-
Nézd meg a lap alját, ott a vezeték csak el van vágva a Z80-nál és a cartridgenél is. ISSUE 3-4-es alaplapokon még utólag, 5-6-osokon már eleve úgy készült a NYÁK.
Pontosan ez tűnt nekem is fel. Egyrészt az összes ISSUE-s fényképen ott látni a vezetéket, másrészt a saját lapomat (ISSUE6) vizsgálva pont úgy néz ki, hogy az a fólia ott nagyon nem véletlenül van megszakítva két helyen is. És úgy néz ki, mintha valaki a nyákgyártó filmet "patch-elte meg" ehhez.
Csak tippelni tudok, hogy kezdetben 2x8K EPROM-ban volt a BASIC, és ekkor ugye az A13 vezérelte a címkiválasztás a cartridge-ben. Lehet, hogy ha valami brutál lassú EPROM-okat sikerült beszerezni kiárusításon, akkor esetleg pont a rövidebb, vastagabb drót kellett ahhoz, hogy jól működjön :-)
Nem tudom, hány (tized) nS késleltetést okoz a hosszabb jelút, de ha ennyi számít (1984/85!), akkor ott valami nagyon nem jó. :-D (Mondjuk én ilyen "áthallás" jellegű hibát tippeltem volna, de nem néztem meg, hogy milyen jelek mennek a "kivágott" fólia mellett.) Azért is érdekes ez a kérdés, mert az utólagos drótozgatás egy meglehetősen nagy szívás a gyártás oldaláról. (Itt ugye 80000 körüli darabszámról beszélünk. Speciel az én gépemben levő még egész kulturáltan van kivitelezve, a fellelhető fotókon nem mind látszik "szépnek".) Szerintem valaki nagyon csuklott, amikor ezt a részt kézzel kötögették.
Igen, mert nem lát EXDOS-t. De EPDOS-ra maga a fájkezelő indulna el. Az általad keresett monitor parancsok közvetlenül adhatóak, pl:
:SM 255,0
Az kidumpolja a rendszerszegmens elejét.
Itt (http://www.ep128.hu/Ep_Util/EPDOS.htm) menj le az "Egyéb parancsokig", ott kezdődik a téged érdeklő rész.
OK, akkor talán nem állok annyira rosszul drótozás ügyben, majd tesztelek tovább!
-
EXDOS kártya ügyben egyelőre még nem jutottam előre, de a rendszerbuszra való csatlakozást azért sikerült megoldani / összerakni. (Az EP tervezőinek ugyan nem sikerült többségében "szabvány" csatlakozókat tervezni a gépre, de legalább raszteres érintkezőtávolságú élcsatlakozót raktak a nyákra, ezúton is köszönet érte! :) )
Közben vizsgálgattam az eredeti lemezvezérlő kártya kapcsolási rajzát (http://enterprise.iko.hu/schematics/EXDOS~1.jpg). Első körben két fontos kérdés van: egyrészt az EXDOS ROM milyen címen látható, másrészt a kártyán levő I/O portok hova kerülnek. A címdekódoló logika egy kissé túl van bonyolítva a tervezett "buszkiterjesztő" (http://enterprise.iko.hu/schematics/EXPANSIONMOTHERBOARD.jpg) miatt, ezt én nagyvonalúan el is hagyhatom majd. :) Mindenesetre a több kártyahely mint ötlet jópofa, nagyjából - azt hiszem - értem is, hogy mit csinálna. A kártyahelyekhez tartozik egy 3 bites azonosító, ezek az SA2, SA1, SA0 vonalak. (Talán Slot Address?) Az eredeti terv alapján 6 kártyahely lett volna, mindegyik kártyahelyhez tartozik egy I/O címtér, illetve egy memória-tartomány. Csináltam egy táblázatot róla:
| Slot száma | SA210 | I/O cím | Memória bank száma | Direkt memóriacím |
| 1 | 001 | 0x10..0x1F | 0x20..0x3F | 0x080000..0x0FFFFF |
| 2 | 010 | 0x20..0x2F | 0x40..0x5F | 0x100000..0x17FFFF |
| 3 | 011 | 0x30..0x3F | 0x60..0x7F | 0x180000..0x1FFFFF |
| 4 | 100 | 0x40..0x4F | 0x80..0x9F | 0x200000..0x27FFFF |
| 5 | 101 | 0x50..0x5F | 0xA0..0xBF | 0x280000..0x2FFFFF |
| 6 | 110 | 0x60..0x6F | 0xC0..0xDF | 0x300000..0x37FFFF |
Ebből az egészből az eredeti SBB (http://enterprise.iko.hu/schematics/BRIDGE~2.jpg) az 1-es Slot-ot valósítja meg, mindenféle meghajtás nélkül. A 0-ás meg a 7-es "elvi" Slot I/O címterével nem lenne gond, de a hozzájuk tartozó memóriatartomány "belelóg" az alapgépben kiépített ROM/RAM részbe, szóval a "000" illetve az "111" SA kombináció erősen ellenjavallt. :)
Valamerre itt a fórumon már láttam erről listát, de most nem találom. :) Jól "számoltam"? A ROM-hoz a "Direkt memóriacím" fog majd kelleni, de ha jól sejtem programozás alatt ezekkel az ember nemigen találkozik. (A hardver viszont ezzel dolgozik...) A memóriatartomány 512K-s részekre van osztva, de az EXDOS kártya "csak" 256K-t dekódol a ROM címének.
Tehát ami fontos lesz:
- A WD + kiegészítő port 0x10..0x1F I/O tartományba kell hogy essen
- Az EXDOS DOM 0x080000..0x0FFFFF tartományon belül az elejére kerüljön (0x20, 0x21-es bank)
Jól sakkozok? :-D
(Amúgy "kellemes" ez a buszbővítős lehetőség. Régen, plus/4 (meg egyéb CBM gépek) esetén mennyire örültünk volna valami hasonlónak, ha gondoltak volna ilyenre. Hát nem... :) Az mondjuk igaz, hogy ez az automata konfiguráló megoldás eléggé fapados Plug&Play, de mondjuk nem kötelező használni.)
-
Tehát ami fontos lesz:
- A WD + kiegészítő port 0x10..0x1F I/O tartományba kell hogy essen
- Az EXDOS DOM 0x080000..0x0FFFFF tartományon belül az elejére kerüljön (0x20, 0x21-es bank)
Igen. És ami még fontos, hogy a WD 4 regisztere két példányban is látszik, kell mind a kettő, mert használja.
ROM-ra meg dobj egy 512K Flash ROM-ot (29F040 ajánlott) 20-3Fh szegmensekre. A dekódolás egy 74HCT138-al megvan :-) és még lógathatsz rá pár 512K SRAM-ot is :-)
-
(Az EXDOS DOM természetesen EXDOS ROM akart lenni. :) )
Igen. És ami még fontos, hogy a WD 4 regisztere két példányban is látszik, kell mind a kettő, mert használja.
Erre majd figyelni fogok. (Valamerre olvastam már ezt egy hozzászólásodban. :) )
ROM-ra meg dobj egy 512K Flash ROM-ot (29F040 ajánlott) 20-3Fh szegmensekre. A dekódolás egy 74HCT138-al megvan :-) és még lógathatsz rá pár 512K SRAM-ot is :-)
Ahogy magam ismerem, a dolgot egy kicsit úgy is el fogom bonyolítani a rugalmasság kedvéért. :) RAM-om egyelőre csak egy darab van, flash-em meg egy sem (amit programozni is tudnék), de valamit majd jól kitalálok. :)
-
flash-em meg egy sem (amit programozni is tudnék)
29F040 (vagy 010,020)-t lehet EP-n programozni. (Mást is ha megírod hozzá a programot :-) )
-
29F040 (vagy 010,020)-t lehet EP-n programozni. (Mást is ha megírod hozzá a programot :-) )
Hehe... Valahogy látszik, hogy ez a téma nekem újdonság. Elfelejtem mindig, hogy EP-n nincs "kitüntetett" ROM meg RAM terület külön, így semmi extra megoldani a FLASH írását, jóformán csak be kell normálisan kötni a _WE-t is. :)
FLASH-ből jelenleg egy Winbond-féle W29C040 van kéznél, amit ugyanúgy kell programozni, mint az Atmel-féle AT29C040A-t, ha minden igaz. (256 BYTE-os (!) lapok... Természetesen más a sima 29F0x0 algoritmusa, még ha nem is nagyon.) Az utóbbit tudja a programozóm írni, de az algoritmus azzal kezdődik, hogy leellenőrzi a típus/gyártó azonosítókat. Erről meg eddig nem sikerült lebeszélnem. Ha ezek nem jók, a folytatás is abbamarad. :( De ez itt mellékes, majd megoldom! ;)
-
Csak eljutottam odáig, hogy az EPDOS "MONITOR" részét is megnézzem. Működik:
(http://bsz.amigaspirit.hu/Enterprise/pics/s/pic20150123_001s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/pic20150123_001.jpg)
(A monitor-fotózási tehetségem nem túl nagy... :) ) Működni látszik a dolog! De azzal csak most "szembesültem", hogy mennyire lassú a megjelenítés. Ez az "editor" annyit tud, hogy indokolt? :) Azt hiszem jól fog jönni valami turbó is majd később. :-D
-
Nos, csak sikerült haladnom... Egy kissé elbonyolítottam a megoldást (mivel ilyen "mindent bele" típusú cucc készülne), meg vannak még bőven kihívások, de azért alakul. Első körben az 512KB-nyi SRAM-ot kötöttem be, előtte egy rakás buszmeghajtóval. :) (A tervezett buszbővítő (http://enterprise.iko.hu/schematics/EXPANSIONMOTHERBOARD.jpg) mintájára a használt vonalakat jól megpuffereltem, ki tudja mit akarok én még idekötni? :) ) Azért a RAM, mert akkoz szinte az összes vonal szükséges, így ha a memória jó, akkor nagy hiba már nem lehet a felépítésben. Első indításra azért lett is 512K "BAD" memóriám, amit egy címvezeték zárlat (ez is megér majd egy mesét) megszüntetésével sikerült helyrerakni:
(http://bsz.amigaspirit.hu/Enterprise/pics/s/pic20150203_001s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/pic20150203_001.jpg)
640KB, mert az mindenre elég. :) A jelenlegi (2.4ß) EXOS memória gyorstesztje, meg az "Advanced" teszt szerint is rendben van, viszont a gyári RAM-teszt szerint nem:
(http://bsz.amigaspirit.hu/Enterprise/pics/s/pic20150203_002s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/pic20150203_002.jpg)
Hogyan működik az eredeti RAM-teszt? Mit csinál? Amúgy igaza van, tényleg vannak furcsaságok. Pár dolgot megváltoztatva jelenleg - úgy tűnik - sikerült úrrá lenni a problémán, de mindenesetre nem megnyugtató, lesz még mit mókolni. (Illetve valahogy jó lenne megoldani, hogy a gyári RAM-teszt rutint futtassam mondjuk végtelen ciklusban, tesztelés gyanánt. A módosított tesztek nem hozták ki egyszer sem a problémát.)
-
A módosított tesztek nem hozták ki egyszer sem a problémát.
Ez fölöttébb izgalmas :oops:
Ha C+N-nel csinálsz Normal Test-et, akkor is jön a hiba? (Elvileg az ugyanaz mint a gyári teszt, csak a képernyő új.)
-
Ez fölöttébb izgalmas :oops:
Ha C+N-nel csinálsz Normal Test-et, akkor is jön a hiba? (Elvileg az ugyanaz mint a gyári teszt, csak a képernyő új.)
Igen, ott is jelzi. Az tuti hogy van valami hardveres hiba, de érdekes módon általában ugyanarra az egy szegmensre mondja a problémát. Eddig talán egyszer volt olyan, amikor két szegmenst is kidobott. (Erre nincs valami frappáns BASIC megoldás, hogy a szegmensek listáját (mit minek "talált ki") ki lehessen íratni?)
-
Erre nincs valami frappáns BASIC megoldás, hogy a szegmensek listáját (mit minek "talált ki") ki lehessen íratni?
Ha van EPDOS, akkor :LRAM
-
Ha van EPDOS, akkor :LRAM
Jaj-jaj... :) Úgy van EPDOS-om, hogy a BASIC kártyába azt rakom. Ha az a kártya be van dugva a gépbe, akkor nem mondja hibásnak a RAM-ot. Ha kiveszem, hibás (valószínűleg a "legmagasabb" szegmens, jelenleg $9F..$80 szegmensszámokra van bekapuzva). :) Jöhet a gomb meg a varrás. :)
Szerk: miután ezt leírtam, mégis sikerült egy hibás szegmenst találni. (Jelenleg a $85-ös, bár azt hiszem nincs ennek semmi jelentősége, nem így van gubanc a történetben.)
-
Itt írja mit csinál a EXOS RAM teszt. (http://ep128.hu/Ep_Konyv/Gepi_kod.htm#18)
Szerintem biztos ami biztos ezt a rutint is bele teszem az Advanced Test rutinjai közé.
A RAM-od egyébként milyen IC?
Lehet, hogy érdekes: a spanyol srác SRAM-osított Microteam kártyája esetén nagyon hasonló jelenség jött elő, és ott az lett a megfejtés, hogy van amelyik régi Z80 nem szereti a modern SRAM-ot.
-
Itt írja mit csinál a EXOS RAM teszt. (http://ep128.hu/Ep_Konyv/Gepi_kod.htm#18)
Szerintem biztos ami biztos ezt a rutint is bele teszem az Advanced Test rutinjai közé.
Valószínűleg jó lesz az ott, már csak ebből az esetből is kiindulva. A leírásba beleolvasva az derül ki, hogy a RAM-teszt a 16K-s blokkokat különálló egységenként ellenőrzi, így ha az A14 vagy afölötti címvonalakkal van valami gubanc, az nem biztos hogy kiderül. Azt hiszem érdemes lesz a FLASH-t is feléleszteni, abba tudok majd valami teszt-adathalmazt programozni, amit vissza lehet ellenőrizni. Bár BASIC-ből meglehetősen lassú lesz... :)
A RAM-od egyébként milyen IC?
Lehet, hogy érdekes: a spanyol srác SRAM-osított Microteam kártyája esetén nagyon hasonló jelenség jött elő, és ott az lett a megfejtés, hogy van amelyik régi Z80 nem szereti a modern SRAM-ot.
Hát, az én RAM-om is "modern": BS62LV4006 (http://www.jm.pl/karty/BS62LV4006.pdf). Viszont a "modernságából" semmit sem láthat a Z80, mivel buszmeghajtók mögött ücsörög. Nekem is gyanús egyébként, de más típusból csak kisebbek vannak kéznél, ettől függetlenül egy próbát meg fog érni úgy is. Viszont ha már "modernság": a buszmeghajtók jelenleg 74HC245-ök. Se HCT-s, se LS-es verzióm nincs kéznél, pedig szívem szerint ezek cseréjét próbálnám ki először. Ezzel kapcsolatban valami tapasztalat nincs-e véletlenül?
-
A leírásba beleolvasva az derül ki, hogy a RAM-teszt a 16K-s blokkokat különálló egységenként ellenőrzi, így ha az A14 vagy afölötti címvonalakkal van valami gubanc, az nem biztos hogy kiderül.
Így van, ez az eredeti teszt hibája. Viszont az EXOS 2.4 az függetlenül attól, hogy éppen milyen rutinnal tesztelte az adott szegmenst (mármint ha nem az eredeti EXOS teszt fut, hanem a módosított), tesztel erre:
Amikor jó egy szegmens az elejére odaírja a szegmensszámot, ill. az invertáltját. Ekkor nő a TESTED szám, a végén visszaellenőrzi, és ami jó az kerül az OK-ba. Ha esetleg címvezeték hiba miatt két szegmens valójában egy, akkor ez kiszűri, csak egy példányban kerül az OK-ba.
Ezenfelül az Advanced Test-ben, a Random Fill pszeudó véletlenszám generátora az aktuális szegmensszámmal van inicializálva, így minden szegmensre külön véletlen mintázat kerül, itt is kijönne a végén az ellenőrzésnél ha címvezeték hiba lenne.
Ezzel kapcsolatban valami tapasztalat nincs-e véletlenül?
Buszbővítőben szerintem még nem próbáltam HC-t. Máshol elment :-)
-
Viszont az EXOS 2.4 az függetlenül attól, hogy éppen milyen rutinnal tesztelte az adott szegmenst (mármint ha nem az eredeti EXOS teszt fut, hanem a módosított), tesztel erre:
Amikor jó egy szegmens az elejére odaírja a szegmensszámot, ill. az invertáltját. Ekkor nő a TESTED szám, a végén visszaellenőrzi, és ami jó az kerül az OK-ba. Ha esetleg címvezeték hiba miatt két szegmens valójában egy, akkor ez kiszűri, csak egy példányban kerül az OK-ba.
Ez abból a szempontból jó hír, hogy biztosan nem ilyen hibám lesz akkor, mert azt a módosított teszted mutatta volna ki, nem a gyári. :)
Ezenfelül az Advanced Test-ben, a Random Fill pszeudó véletlenszám generátora az aktuális szegmensszámmal van inicializálva, így minden szegmensre külön véletlen mintázat kerül, itt is kijönne a végén az ellenőrzésnél ha címvezeték hiba lenne.
Érdekes történet ez. Kicseréltem a RAM-ot egy UT621024-re, azzal még nem sikerült hibát produkálnom, pedig párszor újraindítottam. (De lassan "félek" kísérletezni... :) ) Csak hát ez így +128K a +512K helyett. :( Na mindegy, azt hiszem egyelőre maradnom kell ennél. Az "Advanced test" esetén a "TESTING REFRESH" alatt mi történik? (Tipp: vár egy gombnyomásra. Utána visszaellenőrzi a Random Fill adatait, hogy történt-e felejtés az esetleges hibás frissítés miatt.) Ez számomra nem lényeges, gondolom nem vagyok előrébb vele, ha várok itt fél órát... :)
Buszbővítőben szerintem még nem próbáltam HC-t. Máshol elment :-)
Ha sikerül találnom valamerre HCT és/vagy LS verziót, tuti kipróbálom. A bővítő porton a Z80 lábai lógnak "direktben", elvileg az meg valamilyen MOS alkatrész, szóval nem biztos hogy gondot okozhat a HC. Az egyetlen kérdés a Dave, annak vajon milyenek a kimenetei? (A14..A21)
-
Az "Advanced test" esetén a "TESTING REFRESH" alatt mi történik? (Tipp: vár egy gombnyomásra. Utána visszaellenőrzi a Random Fill adatait, hogy történt-e felejtés az esetleges hibás frissítés miatt.) Ez számomra nem lényeges, gondolom nem vagyok előrébb vele, ha várok itt fél órát... :)
Teljesen helyes a tipp :-)
-
Teljesen helyes a tipp :-)
Hacsak a kozmikus sugarak nem modositottak az SRAM nehany bitjenek allapotat :) Bar amugy egyszer (nem EP temaban ...) lattam mar olyat, hogy egy SRAM-nal a busz idozites nem volt tokeletes (vmi olyasmi volt, hogy SRAM elobb kapta meg a write engedelyezest, hogy stabil lett volna a cim/adatbusz, vagy tul kesob vette le, nem tudom, hasonlo ...) es igy mast is atirt amit kellett volna, igen nehezen kideritheto, es nem teljesen kovetkezetes hibat vitt a rendszerbe :(
-
Hacsak a kozmikus sugarak nem modositottak az SRAM nehany bitjenek allapotat :)
Ne ijesztgess! :-D Valami régi legendában meséltek ilyenről, csak ott EPROM-ok tömege volt az áldozat, amikben néha 1-1 bit hibás lett. Aztán egy idő után kiderült, hogy a kerámia tokok összeragasztásához felhasznált anyag volt sugárszennyezett, a kozmikus változatnak nem volt köze hozzá. :) Hogy a történet igaz-e, az jó kérdés.
Bar amugy egyszer (nem EP temaban ...) lattam mar olyat, hogy egy SRAM-nal a busz idozites nem volt tokeletes (vmi olyasmi volt, hogy SRAM elobb kapta meg a write engedelyezest, hogy stabil lett volna a cim/adatbusz, vagy tul kesob vette le, nem tudom, hasonlo ...) es igy mast is atirt amit kellett volna, igen nehezen kideritheto, es nem teljesen kovetkezetes hibat vitt a rendszerbe :(
Ismerős, nem kell messze menni: meséltem is róla (http://hup.hu/node/117280). :) A "minimál koncepciós" plus/4-em is ezért hibázott alapesetben. A Z80 vezérlőbusza viszont (elnézve a dokumentációt) meglehetősen kulturált, itt nem ezzel lesz a bajom. Ha ilyen eset lenne, akkor a RAM típusától függetlenül mindig hibáznia kellene, de - úgy tűnik - csak azzal a darabbal teszi. Szerintem nem is a memóriaírással lesz a baj, hanem a kiolvasással. Egyszer csak meg fogom tudni ezt vizsgálni egy oszcilloszkóppal, lehet hogy látok majd csuda dolgokat. :) De a RAM téma egyelőre jegelve, elég lesz a +128K elsőnek. Most jön a WD177x, meg a körítése.
-
Na igen, en olyan hibakat lattam amugy, hogy hiaba a korrekt busz idozites, ha mondjuk a kozebiktatott logika mas-mas kesleltest vissz egyes helyekre, igy totalisan felbirotja az eredetit. Mondjuk inkabb elmeletben ismerem a problemat, mint gyakorlatban, hogy oszinte legyek :) Esetleg CMOS/TTL jelszintek kozotti elteres, foleg ha amugy "zajos" kicsit a dolog tud "segiteni" meg ilyen problemak eloallasaban. Amit epp ma egy kollega meselt: sokat tud artani a hianyzo szokasos 100nF kondi is, es ugye elvileg az sem mindegy, mibol van az a kondi (most a tapellatas kornyeki anomaliakrol beszelek persze). Amugy persze optimalis kornyezetben van egy allati sok csatornas logikai analizator / szkop, ami minden lenyeges jelet egyszerre tud mutatni, aztan eleg triggerelni egy jelre, es latod hozza kepest a tobbit. Az elmelet szep, de nekem sincs egy vacak mezei szkopom sem, nemhog ilyen munkara alkalmas ...
Btw, a linkelt irasod nagyon tetszett, itt figyel nalam egy plus4 es ket (nem mukodo) c16, lehetne azokkal nekem is jatszani egyszer :-P na persze, meg EP-ben sem jutottam semmire, mert mindent csal eltervezek es ugy marad :(
-
Na igen, en olyan hibakat lattam amugy, hogy hiaba a korrekt busz idozites, ha mondjuk a kozebiktatott logika mas-mas kesleltest vissz egyes helyekre, igy totalisan felbirotja az eredetit.
Van ilyen is, de itt annyira "szép" a logika, hogy nem gondolnám most ezt hibának. Pláne úgy, hogy másik SRAM-mal meg nem problámázik. :)
Esetleg CMOS/TTL jelszintek kozotti elteres, foleg ha amugy "zajos" kicsit a dolog tud "segiteni" meg ilyen problemak eloallasaban. Amit epp ma egy kollega meselt: sokat tud artani a hianyzo szokasos 100nF kondi is, es ugye elvileg az sem mindegy, mibol van az a kondi (most a tapellatas kornyeki anomaliakrol beszelek persze).
A TTL/CMOS kérdés valóban tud érdekes galibákat okozni, ez még majd kiderítendő történet. A táp hidegítő kondenzátorait én nem szoktam kispórolni, itt is van mindenhol. Az viszont igaz, hogy ezzel a "drótozásos" megoldással messze nem tudom a "tápolást" úgy megoldani, ahogy szeretném. Ahhoz nyákot kellene gyártani.
Btw, a linkelt irasod nagyon tetszett, itt figyel nalam egy plus4 es ket (nem mukodo) c16, lehetne azokkal nekem is jatszani egyszer :-P na persze, meg EP-ben sem jutottam semmire, mert mindent csal eltervezek es ugy marad :(
Hát, az idő az nagy úr. Meg a kedv is. :) (A nem működő gépek esetén (a táp után) az első tipp a CPU szokott lenni, az sajnos hajlamos a megdöglésre.)
De eddig csak a "sírás" ment, most beszámolok a fejleményekről. Elindult az EXDOS rész is:
(http://bsz.amigaspirit.hu/Enterprise/pics/s/pic20150208_001s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/pic20150208_001.jpg)
De itt egy tájkép is, ezt eddig még nem mertem mutogatni:
(http://bsz.amigaspirit.hu/Enterprise/pics/s/pic20150208_002s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/pic20150208_002.jpg)
A másik oldal, a huzalozás, na azt inkább nem mutatom meg, az valami tragikus. :-| (A "kedvenc vezetékem", amivel szoktam kötögetni, az elfogyott. Ezt meg erekre szétbontott szalagkábellel kötöttem be, de most újra rájöttem, hogy miért nem ezzel szoktam én dolgozni. Valahonnan kell szerezzek "normális" vezetékeket.)
Mint a képen látszik, elsőre egy 3½-es meghajtót kötöttem hozzá. (Ez szinte a legutolsó kapható meghajtók egyike volt, a lehető legolcsóbb kivitel. Érdekes módon eddig szinte csak jó tapasztalatom van vele.) Beleraktam egy 720-as lemezt, majd a DIR parancs azt mondta, hogy nem tudja olvasni. (Mondjuk a lemezt jó régen használtam, az is lehet hogy AMIGÁs formátum volt, de nem gondolnám...) Viszont a FORMAT az szépen lefutott! Volt öröm! :-D Utána akartam rá másolni valamit, de Linux alatt a mount nyammogott egy sort, majd közölte, hogy ő ezt csak "Read Only" módon hajlandó csatolni. Ott újra leformáztam, majd rámásolva a dolgokat, az EXDOS már simán olvasta. Ez normális? :-D
Az EXDOS-ból van-e ilyen "mindent bele" hibajavított verzió? Az EXDOS 1.3-at pirítottam most be, ami - talán - az eredeti verzió lehet.
-
Gratula :) Nem semmi munka lehetett összedrótozni az egészet :D
Van Zozo által javított verzió, de úgy emléxem még tervei vannak vele, és nem végleges.
-
Az EXDOS-ból van-e ilyen "mindent bele" hibajavított verzió? Az EXDOS 1.3-at pirítottam most be, ami - talán - az eredeti verzió lehet.
Itt a legutóbbi 1.4 beta :-) (http://enterpriseforever.com/programozas/exdos-283/msg41674/#msg41674)
-
(A "kedvenc vezetékem", amivel szoktam kötögetni, az elfogyott. Ezt meg erekre szétbontott szalagkábellel kötöttem be, de most újra rájöttem, hogy miért nem ezzel szoktam én dolgozni.
Floppy vagy hagyományos IDE kábelből? Azt én se szeretem, szanaszét akar állni a sok drótszál :evil:
80 eres IDE kábelt kell szétszedni, abban finom kis egyeres rézdrót van, azzal jó lehet dolgozni.
-
Gratula :) Nem semmi munka lehetett összedrótozni az egészet :D
Ez a fele még normálisan is néz ki. De a másik... :-D (Szívem szerint szétszedném az egészet, aztán újrahuzaloznám. Lehet hogy majd meg is teszem, de most nem ez van soron.)
Itt a legutóbbi 1.4 beta :-) (http://enterpriseforever.com/programozas/exdos-283/msg41674/#msg41674)
Köszönet, teszek majd vele is egy próbát. (Jó sok dolog belekerült, ahogy olvasgatom... FAT16 kompatibilitás lesz-e? :-D (Ez nyilván nem a floppy-hoz lesz hasznos.))
Floppy vagy hagyományos IDE kábelből? Azt én se szeretem, szanaszét akar állni a sok drótszál :evil:
80 eres IDE kábelt kell szétszedni, abban finom kis egyeres rézdrót van, azzal jó lehet dolgozni.
A sima, fél raszteres verziót használtam. (Olyat mint a floppy kábele.) A 80-as IDE-vel csak egy nagyon régi tapasztalatom van, az ráadásul elég rossz. (Konkrétan se szétszedni erekre, se megforrasztani normálisan nem sikerült. :) ) Emiatt azzal mostanában nem is próbálkoztam, de lehet hogy egy megvizsgálást megér, valószínűleg gyátója / típusa válogatja. Az erek (szigeteléssel együtti) átmérője amúgy ideális lenne.
A cucc mindenesetre stabilan működik. Viszont az is kiderült, hogy az általam beépített video-kimenet (http://ep128.hu/Ep_Hardware/Videokimenet.htm) túl nagy jelszintet produkál, azon lesz még mit faragni. (Mondjuk átalakítani kapásból SVIDEO-ra. :) Alkatrészeknek úgyis az "amit találtam" típusúak lettek beépítve, azért egy kicsit nagyobb precizitást itt el lehet várni, még magamtól is. :) )
-
FAT16 kompatibilitás lesz-e? :-D
Előbb-utóbb lesz.
A sima, fél raszteres verziót használtam. (Olyat mint a floppy kábele.)
Régen azt használtam de nagyon nem szerettem :-)
A 80-as IDE-vel csak egy nagyon régi tapasztalatom van, az ráadásul elég rossz. (Konkrétan se szétszedni erekre, se megforrasztani normálisan nem sikerült. :) )
Én már évek óta azt használom, és azt kívánom, hogy már 25 évvel ezelőtt is lehetett volna ilyen drót :-)
-
Én már évek óta azt használom, és azt kívánom, hogy már 25 évvel ezelőtt is lehetett volna ilyen drót :-)
Na, majd rárepülök! :-D (Amit eddig használtam, az is szalagkábel amúgy. Csak ez olyan fajta, ami különálló, színes szigetelésű erekből áll, és egy átlátszó "fóliával" egymás mellé vannak az erek "rendezve". Nem érnek az erek szigetelései össze, mert azok közé is bekerül az átlátszó "fólia". Némi fejtegetés árán ki lehet szedni a "fóliából" az ereket külön anélkül, hogy a saját szigetelésük megsérüljön. De a kész kábel ugyanúgy fél raszteres, emiatt a különálló erek egész vékonyak, talán nincsenek 1mm vastagok. Na, ebből két fajtát is használtam, az első a "szép", az sima X pólusú szalagkábel. A második a "ronda de jó", az meg csavart érpáros szalagkábel, ott a "fóliából" meglepően könnyű kibontani az érpárokat, azokat meg semeddig sem tart széttekerni. De mindegyik kábel valahonnan kibontott cucc volt, így nincs utánpótlás. :-| )
-
Ez is 80 eres kábelből készült :-) (http://enterpriseforever.com/hardver/hardware-hogyan-apritsuk-miszlikbe-enterprise-unkat/msg32809/#msg32809)
-
Viszont a FORMAT az szépen lefutott! Volt öröm! :-D Utána akartam rá másolni valamit, de Linux alatt a mount nyammogott egy sort, majd közölte, hogy ő ezt csak "Read Only" módon hajlandó csatolni. Ott újra leformáztam, majd rámásolva a dolgokat, az EXDOS már simán olvasta. Ez normális? :-D
A Linux lelkivilágát nem ismerem :oops:
De egy tipp: esetleg az EXDOS által létrehozott boot szektor nem elég modern. Erről itt írtam. (http://enterpriseforever.com/programozas/exdos-283/msg24203/#msg24203)
A FAFO 2.5 (megtalálható Zozotoolsban ill. külön futtathatóban is), és az EPDOS 1.7 2011-es vagy újabb verziója már az itt említett modern boot szektort csinál (majd az EXDOS-ba is bele akarom rakni, csak kell majd egy kis helyet csinálni a FORMAT parancsban :-) ).
Kíváncsi lennék, hogy az így formázott lemezre mit mondana a Linuxod.
Egy megjegyzés: NT alapú Windowsok esetén a plusz szektorokat kezeli (már amit a buta PC-s floppy vezérlő tud kezelni :-) ), azaz 800-as lemezt simán lehet használni. Én ezt Linuxtól is elvárnám :-)
Plusz sávoktól az idióta Microsoft termékek idegbajt kapnak (figyelmen kívül hagyja a boot szektor adatait, és neki áll 720-asnak kezelni, amivel szétcseszi a fájlrendszert...), de egy normális operációs rendszertől én ezt is elvárnám...
Amúgy anno 840-es volt legelterjedtebb EP-s lemezformátum. Mondjuk abból a modern PC-s meghajtódból nem nézek ki 84 sávot, 82 talán... FAFO ill. EPDOS is leellenőrzi plusz sávok esetén, hogy mennyit bír.
Megjegyzem, hogy nekem van 90 sávos kisfloppym (http://enterpriseforever.com/hardver/milyen-ep-konfigod-van/msg28164/#msg28164) :-D , azaz simán DD lemezen 990K a max alapból, 1170K ha a WD is turbósítva van :ds_icon_cheesygrin:
1.44-esből 89 sávosom van, azzal 1958K-ig lehet elmenni :-)
-
A Linux lelkivilágát nem ismerem :oops:
Nem baj, én sem. :) Viszont azt hozzá kell tenni, hogy az előző verzió, amit használtam, az konkrétan nem is töltötte be a floppy kezelő modulját automatikusan. Nekem kellett "kézzel" megoldani, hogy utána tudjak floppy-t használni. Szóval körülbelül ennyire fontos ez a terület jelenleg, azt hiszem csodákat nem érdemes várni. (Ettől függetlenül meglepett a tapasztalat, de ez van.)
De egy tipp: esetleg az EXDOS által létrehozott boot szektor nem elég modern. Erről itt írtam. (http://enterpriseforever.com/programozas/exdos-283/msg24203/#msg24203)
A FAFO 2.5 (megtalálható Zozotoolsban ill. külön futtathatóban is), és az EPDOS 1.7 2011-es vagy újabb verziója már az itt említett modern boot szektort csinál (majd az EXDOS-ba is bele akarom rakni, csak kell majd egy kis helyet csinálni a FORMAT parancsban :-) ).
Kíváncsi lennék, hogy az így formázott lemezre mit mondana a Linuxod.
Kipróbáltam vele, azt a formázást már normálisan kezeli, tuti ez a "hiba".
Egy megjegyzés: NT alapú Windowsok esetén a plusz szektorokat kezeli (már amit a buta PC-s floppy vezérlő tud kezelni :-) ), azaz 800-as lemezt simán lehet használni. Én ezt Linuxtól is elvárnám :-)
Plusz sávoktól az idióta Microsoft termékek idegbajt kapnak (figyelmen kívül hagyja a boot szektor adatait, és neki áll 720-asnak kezelni, amivel szétcseszi a fájlrendszert...), de egy normális operációs rendszertől én ezt is elvárnám...
Hát, hogy mit vár ez az ember, meg mi a valóság, az sokszor köszönőviszonyban sincs. Az mindenesetre tisztán látszik, hogy 2015-ben ez valahogy nem az a terület, ahol nagyon javulásra lehet számítani. A sima 720K-s lemezt a jelenleg használt kernel+eszközök kezelik jól. De pl. a 10 szektoros lemez már érdekesebb kérdés. Normálisan felcsatolja, tele is tudja írni. Visszaolvasni kb. addig lehet, ameddig az eredeti 720K tart, a többi fájlra már hibát ad vissza. Illetve utána ezt a lemezt az EP már "szemétnek" olvassa, szóval valamit szépen el is ront rajta.
Amúgy anno 840-es volt legelterjedtebb EP-s lemezformátum. Mondjuk abból a modern PC-s meghajtódból nem nézek ki 84 sávot, 82 talán... FAFO ill. EPDOS is leellenőrzi plusz sávok esetén, hogy mennyit bír.
Ezt a tippet... :) Konkrétan 83 sávos lemezt sikerült a FAFO-val formázni. :) Az azért látszik, hogy ha pc-n is akarom írni az adott lemezt, akkor kénytelen leszek maradni a 720K-s alap formátumnál. (Ha csak nincs valami mágikus paraméter valahol, hogy az ilyen extra lemezeket is normálisan kezelje, ezt esetleg meg lehet majd nézni. De ha automatikusan nem jó, akkor túl sok esélyt nem adnék neki.)
-
Közben kipróbáltam még két 3½-es meghajtót. Az egyik egy Pana JU-257, ami érdekes módon nem működött. (Pedig amikor anno kikerült a gépemből, akkor még nem volt semmi gondja. Jópofa egy meghajtó amúgy, pl. lemez berakásakor a felső fejet csillapítottan rakja rá a lemezre. Meg pl. a csatlakozó 1-es pontja a "Disk Change Reset", ilyet se láttam ezen kívül még... :) )
A másik egy AMIGÁból kikerült JU-253-043P, ez tuti DD-s. És működik is hibátlanul, 86 sávos lemezt sikerült vele formázni. :) Bár az igaz, hogy a 86. sávnál már "koppan" a fej, emiatt max. 85-öt mernék használni vele. Ahhoz képest, hogy az összes AMIGÁs lemezmásoló program 82 sávig "mert" menni, elég érdekes... :)
-
JU257-böl melyik verzió? Az 1-es lábról honnan az info?
-
JU-257-09P Rev01 a pontos típus. A lábakról meg az infó innen (https://ia601209.us.archive.org/34/items/bitsavers_panasonicfchFloppyJU253JU257Brochure_1972274/Panasonic_3.5_Inch_Floppy_JU-253_JU-257_Brochure.pdf). (Az 1-es lábról annyi biztos, hogy a meghajtóban nem GND-re van kötve, emiatt hihetőnek tűnik a doksi is.)
Amúgy érdekes a meghajtó története: ezt anno AMIGÁhoz vettem használtan, mint 720-as drive. A sors fintora, hogy végül csak pc-vel használtam, ráadásul - mint kiderült - HD-s. :) (Az eladó egy pc-s alkatrészekkel foglalkozó bolt, ők is tudták hogy mit árulnak. Persze mindezt még az internet korszaka előtt, szóval nem ma volt.)
Kell? :-D
(Közben megálmodtam, hogy valószínűleg miért nem ment. Egy gyors takarításra szétborítottam (mielőtt beraktam egy lemezt, régen volt használva), de nem rémlik, hogy visszadugtam volna a fejkábel csatlakozóját. :-D Lol...)
-
Kell? :-D
Kell! :-)
Egyébként a hülye Panasonic vagy 20 éven át nevezett minden 1.44-es meghajtóját JU-257-nek, miért nem tudták léptetni a számlálót? :evil:
Ez ha jól tippelem valami jó kis ős darab lehet :-)
-
Kell! :-)
Ok, a tiéd! :-)
Egyébként a hülye Panasonic vagy 20 éven át nevezett minden 1.44-es meghajtóját JU-257-nek, miért nem tudták léptetni a számlálót? :evil:
Ez ha jól tippelem valami jó kis ős darab lehet :-)
Nem mai, az már tuti. A szám ezek szerint nem konkrét típust jelöl, hanem csak a termékcsoport megjelölése. Van benne némi logika; az ügyfélnek nem kellett a megrendelőn semmit módosítani, lehetett az előzőt faxolni újra. :)
Amúgy a tippem jó volt, de nem csak a fej kábele maradt ki (lol...), hanem a léptetőmotor meg a TR00 érzékelő csatlakozója is. (Lol + lol.) Ezeket visszadugva működik szépen, 84 sávos lemezt tudott a FAFO formázni vele.
-
Ok, a tiéd! :-)
Köszi!
-
Egy kicsit kevés időm volt mostanában foglalkozni a témával, de azért haladok... Amint említettem, volt egy "kis" gondom a CVBS kimenettel, emiatt az első megoldandó feladat egy "használható" S-Video kimenet lett, ami el is készült. Egész jó lett a képe, majd írok erről is, ha eljutok odáig. (Valahogy egyre hosszabb az a "majd írok róla..." lista... :-D )
Az S-Video kimenethez az eredeti kapcsolást pár helyen módosítani kell, ez nem probléma. Van a "kedvenc vezetékünk", ami (ismerős kép...) ez:
(http://bsz.amigaspirit.hu/Enterprise/pics/s/pic20150114_001s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/pic20150114_001.jpg)
Ez a drót a feladat közben éppen útban volt, így megszabadultam tőle, "visszajavítottam" a nyákon a két fólia "elvágását". Ebből a ROMBAY csatlakozónál látható rész:
(http://bsz.amigaspirit.hu/Enterprise/pics/s/pic20150319_001s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/pic20150319_001.jpg)
Amikor ez készült, közben lett egy tippem arra, hogy mi is akart ez az egész vezetékezés lenni. (Ugyan egy kicsit nyakatekert, de ki tudja...)
A "probléma" ugye az, hogy a nyákon meg is van az a fólia, ami azt a két pontot köti össze (CPU 3-as lába (http://bsz.amigaspirit.hu/Enterprise/pics/pic20150104_001.jpg), / ROMBAY B7, A13-as cím), amit a vezetékkel utólag összekötöttek, csak ez a fólia két helyen meg van szakítva. Látszólag semmi értelme, azért szakították meg a fóliát, hogy utána külön egy dróttal összekössék a két pontot?
A gép házába az alaplap úgy van beszerelve, hogy nyák csatlakozós "élét" a ház rögzíti, a maradék három oldal meg a ház anyagából kialakított bordákra ül fel. Hogy az egész ne tudjon mozogni, a nyák a "középvonalánál" két csavarral van rögzítve. A csavarok a ház anyagából kialakított "tönkbe" vannak becsavarva. A fenti képen (http://bsz.amigaspirit.hu/Enterprise/pics/pic20150319_001.jpg) a nyák ~ bal felső sarkán pont az egyik ilyen csavar futata látható, és - meglepetés! - pont az az ominózus fólia megy el mellette bal oldalon, ami "ki van vágva" az áramkörből. Az a "tönk", amibe a csavar megy, annak a széle éppen belecsíphet a fólia szélébe, amin alapesetben lakkozás van, de arra szigetelőként nem lehet hagyatkozni. (A "telibe ónozott" nyákon annyira amúgy sem tapad a lakk, de egyébként sem.) Ezzel eddig még nem is lenne semmi baj, de ha a "tönk" oldalán is van abból a vezető festékből, amivel a zavarszűrést oldották meg, akkor ez így már okozhat zárlatot. Ráadásul elég "mocskos" hiba lehet így, mivel a gép az elején még jól működik, csak később (a mozgolódások után lejött lakkréteg miatt) fog buta hibákat produkálni, ami szétszedve, az asztalon tesztelve elő se fog jönni!
A fenti csavarfurat "alatt" is megy keresztben viszonylag közel egy fólia, de az érzésre (A mérőműszer a szemmértékem...) egy kicsit messzebb van, mint az előző.
Azt esetleg meg lehetne vizsgálni, hogy a "tönk" mennyire szokott befestve lenni azzal a vezető festékkel, az én gépemben nem ér fel a nyákig, emiatt aggódni a visszaalakítás miatt nem fogok. Mindenesetre elég misztikus a dolog. Hogy a fenti okoskodásnak van-e valami köze a valósághoz, az jó kérdés, a tévedés jogát fenntartom! :-D )
-
A gondolatmenettel csak az a baj, hogy az a bizonyos ezüst festés csak a német gépekben található meg az ottani szigorúbb előírások miatt. Viszont a NYÁK vagdosást és drótozást sokkal korábban elkezdték, amikor még csak bevonat nélküli angol gépek készültek.
Egyébként egy S-Video (http://enterpriseforever.com/hardver/s-video-kimenet/) megoldás már volt, ezt építetted meg, vagy sajátot találtál ki?
-
Viszont a NYÁK vagdosást és drótozást sokkal korábban elkezdték, amikor még csak bevonat nélküli angol gépek készültek.
Azért nagyon kíváncsi lennék egy akkori, ottani mérnök véleményére, gondolom nem vagyok vele egyedül. :)
Illetve ez a festegetés ez tuti úgy volt? (Esetleg erről is előkerült valami belső dokumentáció?) Azért kérdezem, mert lehetett ez úgy is, hogy az emi shield (https://en.wikipedia.org/wiki/Electromagnetic_shielding) be volt gyárilag tervezve, csak az angol verziónál elhagyták költségcsökkentés miatt. Ekkor ez a "hiba" kijöhetett valami korai prototípusnál, utána meg vagdostak ha kellett, ha nem. :)
Egyébként egy S-Video (http://enterpriseforever.com/hardver/s-video-kimenet/) megoldás már volt, ezt építetted meg, vagy sajátot találtál ki?
Az alap az a wiki-n található (http://wiki.enterpriseforever.com/index.php/S-Video_kimenet) verzió volt (ami a linkelt topikban az első rajz), de módosítottam rajta bőven. A CVBS verzióval az volt a gondom, hogy túl nagy volt a jelszintje, emiatt itt az lett a "kívánság", hogy minimum csökkenteni tudjam ezeket. Emiatt eléggé sikerült elbonyolítani. (2 tranzisztor van mindkét vonalon...) Egyelőre nincs túltesztelve, az még vissza van, de az eddig látott kép biztató.
-
A közelmúltban volt egy kis csend a részemről, de a téma (http://enterpriseforever.com/hardver/kezdo-hardver-kerdesek/msg44802/#msg44802) azért folytatódott. Mint említettem, az "eredeti" kábelezésem nagyon nem tetszett, úgyhogy - nem túl nagy lelkesedéssel ugyan, de - szétszedtem az egészet, és nekiálltam újra behuzalozni, csak most a Zozo-féle tipp alapján 80 eres IDE kábelből bontott vezetékekkel. :) Na, ez már egész vállalhatóan néz ki, majd lövök róla képet.
Egyelőre itt is a memóriákkal kezdtem, mert ahhoz szükséges a legtöbb jel, így azzal lehet a legnagyobb vezetékmennyiséget tesztelni. Hatalmas "fejlődés" történt: az újrahuzalozott verziónál már az Advanced RAM Test is hibásnak mond véletlenszerűen különböző lapokat, sőt, most már a 128K-s régebbi SRAM csippel is hibázik. :) Valahol itt állt meg a történet egy kis időre, kellett némi lelkesedés a folytatáshoz. (Az EP nekem hardveresen még mindig "kezdő" téma, de majd csak belejövök... :) )
Első körben végigméricskéltem mindent mindennel, hátha sikerült (újra) valahova valami zárlatot beépítenem. (Az itt használt "kábellel" elég óvatosan kell bánni, hajlamos a forrasztáskor kiolvadni a szigetelésből a drót.) De semmi ilyen nem jött elő. Mivel tudom, hogy az eredetihez képest mit módosítottam, így a gyanú a 74HC245-ös buszmeghajtókra terelődött, lehet hogy még sem lesznek jók a jelszintek miatt ide? Sikerült túrni 74LS245-öt, de csak 3 db-ot. (Ide meg kellene 5...) Mivel az előző állapotban a komplett ExDOS működött, így csak valamelyik felső címvezeték szintje lehet nagyon határon, így azt a 3 tokot cseréltem ki, amik az A14..A21 vonalakat (tehát azokat, amiket a DAVE generál) is hajtják. Az eredmény: a 128K-s SRAM hibátlanul üzemel! :) Az 512K-s továbbra is hibázik... :(
A következő lépésként ki akartam próbálni 74HCT245-tel is az egészet, de azt vennem kell, így addig jegelődött a történet, ameddig el nem jutottam a sarki fűszeresig. Ez tegnap megtörtént, vettem HCT-s meg LS-es verziót is. A tokokat kicseréltem 74HCT245-re, a 128K-s SRAM tökéletesen üzemel! :) Az 512K-s verzió továbbra is hibás... :( (Valahol itt kezdtem el magamban sikítozni. :) )
Mivel itt már előjött (http://enterpriseforever.com/hardver/kezdo-hardver-kerdesek/msg44691/#msg44691) a "modern SRAM"-os téma, ezért kicseréltem a gépben a Z80-at próbából. (Az rendben van, hogy egy 8MHz-es CMOS Z80 "talál" 256K "hibás" RAM-ot a gépben úgy, hogy semmi bővítő nincs a géphez csatlakoztatva? Az EXOS hogyan dönti el, hogy egy adott területen van RAM csak rossz, vagy nincs semmi?) A Z80 alá beforrasztottam egy precíziós foglalatot, hogy lehessen cserélgetni. Így sajnos túl magasan lesz a Z80 teteje, nem lehet normálisan rácsukni a házat. Majd szedhetem ki... :( Tesztelni jó ez így is, de a CPU csere nem hatotta meg a történetet, ugyanúgy hibázik az 512K-s SRAM. Eh...
A végén mérgemben kicseréltem a 74HCT245-öket 74LS245-ökre, most már sikerült mind az 5-öt. Ééés... Hibátlannak tűnik vele az 512K-s SRAM is! :-D Agyon nem lett próbálgatva egyelőre, de jó pár alkalommal végigfuttattam az Advanced Test-et, sose mondott hibás lapot. Cserébe az LS-es tokok "fogyasztanak" jól, a stab-IC sajnos eléggé forrósodik, a jelenleg alatta levő bord(ácsk)a túl kicsi hozzá.
A hibázós állapotban az Advanced Test viszont egy érdekes tippet adott. Az történik, hogy lefut az "alap" tesztelés a mindenféle feltöltésekkel, ekkor kidob pár lapot hibásnak. Viszont a Testing Refresh fázis utáni ellenőrzéskor szintén talál pár lapot, ami megsérült. Ebből arra következtetnék, hogy a teszt alatt maga a memóriaírás művelet nem sikerül, mintha más címre írna oda, mint ahova kellene, ez meg ha már tesztelt lapra sikerül, akkor elrontja az azon levő mintát.
Szóval mi is derült ki konkrétan? Természetesen semmi. Kelleni fog majd egy jókora méricskélés, de itt valami összetett probléma áll a háttérben, az tuti.
-
Az rendben van, hogy egy 8MHz-es CMOS Z80 "talál" 256K "hibás" RAM-ot a gépben úgy, hogy semmi bővítő nincs a géphez csatlakoztatva?
Igen, gyakran előfordul. Mivel nincs felhúzó ellenállás az adatbuszon, ezért ott csak elvileg van FFh. A CMOS procik érzékenyebbek a dologra, ill turbó estén (bármilyen procival) is megnő az esélye a dolognak. A megoldás: felhúzó ellenállatokat :-) rakni az alaplapra. (http://enterpriseforever.com/hardware/6mhz-and-more/msg37473/#msg37473)
Az EXOS hogyan dönti el, hogy egy adott területen van RAM csak rossz, vagy nincs semmi?
Az eredeti az beír egy bájtot (a ROM első bájtját), és ha sikerült, akkor kezdi el tesztelni mint RAM.
Az én tesztem kiolvassa a tartalmát, invertáltját beírja, majd összehasonlítja a mostanit az előzőleg kiolvasottal. Ha eltérés van, akkor neki áll tesztelni.
Így akkor is észreveszi, hogy RAM, ha teljesen halott egy vagy több IC.
Igaz, hogy a lebegő busz okozza ezeket a fantom hibás szegmenseket, viszont szándékosan nem raktam bele érzékenység csökkentést, mivel jó értesülni a lebegő busz problémáról!
Egy csomó játék lefagyhat ilyen gépen, ami nem teljes IM2 táblával dolgozik.
Viszont a Testing Refresh fázis utáni ellenőrzéskor szintén talál pár lapot, ami megsérült. Ebből arra következtetnék, hogy a teszt alatt maga a memóriaírás művelet nem sikerül, mintha más címre írna oda, mint ahova kellene, ez meg ha már tesztelt lapra sikerül, akkor elrontja az azon levő mintát.
Ez nagyon érdekes! Ott elsőként be lesz írva a minden szegmensre személyre szabott véletlen minta, majd visszaellenőrizve. Itt már nincs több írás. A várakozás esetén ugyanaz a minta lesz még egyszer visszaellenőrizve.
Én arra tudok gondolni, hogy az egyes címvezetékek nem egyszerre állnak be, ettől hol ide-hol oda címez az SRAM. Esetleg ki kéne próbálni, hogy valami késleltetést rakni a SRAM engedélyező jelére, hogy már akkor kezdjen dolgozni, amikor minden cím biztosan beállt.
-
A CMOS procik érzékenyebbek a dologra, ill turbó estén (bármilyen procival) is megnő az esélye a dolognak. A megoldás: felhúzó ellenállatokat :-) rakni az alaplapra. (http://enterpriseforever.com/hardware/6mhz-and-more/msg37473/#msg37473)
Sejtettem hogy valami ilyesmi lesz. (Meg örülök, hogy nem a talált Z80 hibás, ezen felül leginkább NMOS 6MHz-es verziókat találtam első körben.) A CPU alól a foglalatot kiszedtem, és beforrasztottam a 8MHz-es CMOS Z80-at helyette. Illetve beforraltam egy 10K-s ellenálláshálót az adatbuszra felfele húzni. A hibás lap jelzés el is tűnt a (pár) nem kiépített helyen.
Ez nagyon érdekes! Ott elsőként be lesz írva a minden szegmensre személyre szabott véletlen minta, majd visszaellenőrizve. Itt már nincs több írás. A várakozás esetén ugyanaz a minta lesz még egyszer visszaellenőrizve.
Erre gondoltam én is! :) Mondjuk leellenőrzi a - teszem azt - $91-es szegmenst, az jó. A "személyre szabott" Random Fill ugye ott marad. Utána jön a $90, az abbani irkálás meg belerondít a $91-esbe. (A címben 1 bit az eltérés, de ezt nem "figyeltem" meg, csak tipp...) A Refresh Test után meg hibásnak látja a $91-es lapot, holott a benne levő mintát a következő lap tesztelése rontotta el.
Én arra tudok gondolni, hogy az egyes címvezetékek nem egyszerre állnak be, ettől hol ide-hol oda címez az SRAM. Esetleg ki kéne próbálni, hogy valami késleltetést rakni a SRAM engedélyező jelére, hogy már akkor kezdjen dolgozni, amikor minden cím biztosan beállt.
Ilyesmi utólag nekem is eszembe jutott, csináltam is egy tesztet. Eddig az SRAM úgy volt vezérelve, hogy a CPU _RD jele ment a RAM _OE-re, a _WR jel meg a _WE lábra. A RAM _CS jele meg akkor lett aktív, ha a CPU _MREQ jele aktív, illetve a kívánt címtartomány van kiválasztva. A _CS vezérlését módosítottam úgy, hogy most már az _RD vagy a _WR aktív állapota is kell az _MREQ meg a megfelelő címtartomány mellett. (A beíráskor az SRAM _CS jele így már "egész rövid", később is jön a címek beállásához képest, meg rövidebb ideig is tart. Mondjuk nem kéne hogy számítson...) A végeredmény: mintha kevesebbet hibázna. :) De hibázik. Viszont egy olyan alkalmat se sikerült elcsípni, hogy az előzőleg letesztelt bankba belerondítson. (A Testing Refresh utáni visszaellenőrzésnél már nem nőtt a hibásnak jelölt lapok száma.) Ezt most nem tudom, hogy az SRAM engedélyezés módosítása, vagy a CPU csere számlájára írjam, de úgy sejtem, hogy jó helyen kapirgálok, de ehhez kelleni fog egy oszcilloszkóp.
Viszont visszapakolva a 74LS245-öket, már jó ideje tesztelem, azzal egyáltalán nem hibázik. :) Úgyhogy egyelőre marad ez a felállás, a "hőközponttal" meg kezdek majd valamit.
-
beforrasztottam a 8MHz-es CMOS Z80-at
Ezt majd azért kipróbálod, hogy bírja-e a 10MHz-et? :-) Végülis ha a sima A-k (Zilog gyártmányúak) bírni szokták a 7.12-t... :-D
-
Ezt majd azért kipróbálod, hogy bírja-e a 10MHz-et? :-) Végülis ha a sima A-k (Zilog gyártmányúak) bírni szokták a 7.12-t... :-D
Ha eljutok odáig, akkor természetesen! ;)
Amúgy ez is Zilog (a többi "talált" egy része Sharp Z80A/B, van egy GoldStar Z80B, meg pár Zilog féle Z80B, mind NMOS), 9148-as dátumkóddal, szóval ez se fiatal. De ezen az órajelen szinte csak a környezete melegíti, ami azért tetszik!
-
Érdemes belenézni a most előkerült leírásokba. (http://enterpriseforever.com/hall-of-fame/qa-with-werner-lindner-technical-director-of-the-enterprise-computers-gmbh/msg45713/#msg45713)
Pl konkrétan le van írva ez:
[attach=1]
A busz bővítőre meg ALS-eket írnak. Esetleg manapság AHCT-t megpróbálni?
-
Érdemes belenézni a most előkerült leírásokba. (http://enterpriseforever.com/hall-of-fame/qa-with-werner-lindner-technical-director-of-the-enterprise-computers-gmbh/msg45713/#msg45713)
Pl konkrétan le van írva ez:
(Attachment Link)
A busz bővítőre meg ALS-eket írnak. Esetleg manapság AHCT-t megpróbálni?
En annira orulnek, ha valaha is felfognam, a pontos kulonbseget ezek kozott, a HC vs HCT megvan, na de a tobbi ... Most hirtelen guglival rakaresve, pl ebben is emlitenek "parat", koztuk olyanokat is, amirol meg eletemben nem is hallottam (pl GTL, ALB, TVC ...): http://www.ti.com/lit/sg/sdyu001aa/sdyu001aa.pdf (http://www.ti.com/lit/sg/sdyu001aa/sdyu001aa.pdf)
-
Forrasztgattam kicsit, összeállt az ExDOS rész is, működik rendesen! Ígértem róla képeket, íme:
A bővítés maga, túl sok változás nincs az eddig látottakhoz (http://bsz.amigaspirit.hu/Enterprise/pics/pic20150208_002.jpg) képest, csak némi táp átkerült erre az oldalra, na meg a HC-s tokok zöme cserélve lett. Emiatt megnőtt a fogyasztás, ami miatt a stabilizátor szépen fűt... Erre még nincs megoldásom, de majd később lesz ez érdekes amúgy is.
(http://bsz.amigaspirit.hu/Enterprise/pics/s/pic20150328_001s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/pic20150328_001.jpg)
Mindez az izgalmasabb oldaláról, hátulról. Ez azért nekem is tetszik nagyjából, ezt már meg merem :-D mutatni:
(http://bsz.amigaspirit.hu/Enterprise/pics/s/pic20150328_002s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/pic20150328_002.jpg)
Valamint egy "tájkép" még eléggé szétrobbantott állapotban:
(http://bsz.amigaspirit.hu/Enterprise/pics/s/pic20150328_003s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/pic20150328_003.jpg)
A kóceráj stabilan működik, mind a +512K RAM-mal egyetemben, szóval ez a része siker.
Érdemes belenézni a most előkerült leírásokba. (http://enterpriseforever.com/hall-of-fame/qa-with-werner-lindner-technical-director-of-the-enterprise-computers-gmbh/msg45713/#msg45713)
Pl konkrétan le van írva ez:
(Attachment Link)
Ez a szöveg viszont érdekes... Csak nem azt csinálták, hogy a Z80 _MREQ jelének aktívnak kell lennie ahhoz, hogy a DAVE kirakja a számított címrészt? Az a 80nSec eléggé soknak tűnik. Meg kellene ezt komolyabban vizsgálni!
A busz bővítőre meg ALS-eket írnak. Esetleg manapság AHCT-t megpróbálni?
Lehet, de - ha jól rémlik - az ALS "csak" gyorsabb a sima LS-nél. Az én esetemben a címek lassabb beállását bőven ellensúlyozza a logika egyszerűsítése (jóval kevesebb "szinten" megy keresztül a jelek zöme). Ami igazán zavar, hogy HCT-vel miért nem jó? Ha kicserélem CSAK az adatbuszon levő meghajtót HCT-s verzióra, az 512K-s SRAM egyből hibázik. A 128K-s tok viszont továbbra is jó. A sebességekről meg annyit, hogy az 512K-s az 55nSec-es, a 128K-s meg 70-es. :) Valahogy nem áll nekem ez fejben össze.
En annira orulnek, ha valaha is felfognam, a pontos kulonbseget ezek kozott, a HC vs HCT megvan, na de a tobbi ... Most hirtelen guglival rakaresve, pl ebben is emlitenek "parat", koztuk olyanokat is, amirol meg eletemben nem is hallottam (pl GTL, ALB, TVC ...): http://www.ti.com/lit/sg/sdyu001aa/sdyu001aa.pdf (http://www.ti.com/lit/sg/sdyu001aa/sdyu001aa.pdf)
:) Igazából az adatlapokat kell sűrűn nézegetni. Mindenféle jelszintek meg sebességek lesznek mások leginkább.
Nade, hogy továbbra is legyen érdekesség... Az S-Video kimenetem nagyjából jónak néz ki:
(http://bsz.amigaspirit.hu/Enterprise/pics/s/shot20150328_001s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/shot20150328_001.jpg)
Végre látszanak kb. normálisan a 80 karakteres módban levő betűk! :) Viszont azért van egy kisebb gond, amivel nem sikerült mit kezdenem:
(http://bsz.amigaspirit.hu/Enterprise/pics/s/shot20150328_002s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/shot20150328_002.jpg)
Az volt az elképzelés, hogy csinálok egy fehér keretet, majd az S-Video elektronikámba épített potmétert addig csavargatom, ameddig a keret fényereje eléri a maximumot és tovább már nem nő. Valahol annál egy kicsit visszább pont jó lesz. Az ötlet ott bukott meg, hogy egyrészt a bemeneten levő AGC (https://en.wikipedia.org/wiki/Automatic_gain_control) megszívat, másrészt a képen látható "kanyart" nem igazán befolyásolja. Csak azt nem értem, mitől kerül az oda. Erre valami tipp? (Ha nem ennyire világos a keret, akkor mintha nem jelentkezne, de tesztelendő a dolog.)
Aztán van egy másik érdekességem is:
(http://bsz.amigaspirit.hu/Enterprise/pics/s/shot20150328_003s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/shot20150328_003.jpg)
Ez az Interlace Demo 3 (http://ep128.hu/Ep_Demo/Prg/Interlace_Demo_3.rar) első lemezének első képe. Érzésem szerint ennek nem egészen így kéne kinézni. Vagy igen? Esetleg az én gépembe is hibás a NICK? Jó lenne ha nem ez lenne a helyzet... :) Ez a "lilaság" több képen is megfigyelhető, de a nagy részük azért teljesen normális. Vagy ez az S-Video kimenet miatt van esetleg? RGB-n még nem volt alkalmam megnézni. (Először is csinálnom kellene hozzá kábelt. :( )
-
Szerintem a lilaság is, meg az ív is megjavul RGB -n! ;-)
Emléxem, anno horror, miket próbálkoztunk, hogy ilyen-olyan kütyükön jó képet kapjunk, de kizárólag a "mezei" (koax) Tv, vagy az RGB kép lett tökéletes!
-
Szerintem a lilaság is, meg az ív is megjavul RGB -n! ;-)
Nem kizárt. Ki fogom majd próbálni, de "használható" (ilyen) RGB-t tudó megjelenítőm nincs kéznél, egy hagyományos csöves monitort meg már nem akarok elrakni sehova. :)
Emléxem, anno horror, miket próbálkoztunk, hogy ilyen-olyan kütyükön jó képet kapjunk, de kizárólag a "mezei" (koax) Tv, vagy az RGB kép lett tökéletes!
Az RGB még oké, de a "mezei" (koax) Tv jele pont ebből a lilaságból készül, azon csodálkoznék, ha más lenne.
-
kizárólag a "mezei" (koax) Tv, vagy az RGB kép lett tökéletes!
A koax és a tökéletes szavakat én nem tudom egy mondatban elképzelni :twisted:
RGB és pont. A többi csak a rossz melléknév fokozása :)
-
A koax és a tökéletes szavakat én nem tudom egy mondatban elképzelni :twisted:
RGB és pont. A többi csak a rossz melléknév fokozása :)
:-D Van benne valami. De ezt a lilaságot okozhatja a beépített RGB2CVBS konverter? Mert amúgy elég jó a kép... Persze azért furcsaságok vannak. ELVILEG az LM1886 digitális bemeneteket kap, a kimenetnek kell a +12V-os táp. De a képen magán mégis úgy tűnik, hogy megjelenik némi digitális zaj. Szóval kissé furcsa.
Az RGB bemenetes megjelenítőt kihagyva eszembe jutott még egy kipróbálható dolog, de az úgyszintén hosszabb történet, egyelőre azt is jegelnem kell. :|
(Egyszer el fogok jutni odáig, hogy azt tudom mondani, hogy "összeállt minden"? Vagy ez csak mindig egy ködös cél lesz valamerre? :lol: )
-
Ez a szöveg viszont érdekes... Csak nem azt csinálták, hogy a Z80 _MREQ jelének aktívnak kell lennie ahhoz, hogy a DAVE kirakja a számított címrészt? Az a 80nSec eléggé soknak tűnik. Meg kellene ezt komolyabban vizsgálni!
Nagyon úgy tűnik! Viszont ennek ellent mond az a gyakorlati tapasztalat, hogy I/O esetén is a lapozott címek jönnek (és emiatt is volt bugos a Spectrum Emulátor gyári állapotában a billentyűzet kezelés).
Lehet, hogy gyorsítás kedvéért kivették ezt a Dave végleges verziójából? De a doksik dátuma mind jóval későbbi mint a gép megjelenése...
Valahogy meg kéne mérni.
-
Esetleg az én gépembe is hibás a NICK? Jó lenne ha nem ez lenne a helyzet... :) Ez a "lilaság" több képen is megfigyelhető, de a nagy részük azért teljesen normális.
Anno amikor elkezdtük felfedezni a problémát, ide raktam fel kép párokat. (http://enterpriseforever.com/hardver/pixelhibas-alaplapok/msg14091/#msg14091)
Kicsit feljebb István említi a lila problémát is, ami nála S-Video-n jön elő, később is volt emlegetve.
Ott vannak külön futtathatóan is a használt tesztképek.
-
A lila színhiba itt (http://enterpriseforever.com/hardver/s-video-kimenet/msg34189/#msg34189) is látható egy korábbi S-Video témában, bár ezen a képen kevésbé feltűnő. Valószínű, hogy az LM1886 okozza, és úgy látszik, nem csak az én gépemen fordul elő ez a probléma.
-
Az RGB még oké, de a "mezei" (koax) Tv jele pont ebből a lilaságból készül, azon csodálkoznék, ha más lenne.
A lilaság látszik az RF kimeneten is, csak ott nem annyira zavaró az egyéb jól látható képminőség problémák mellett. A torzítás a kép felső részén a PAL szabványnak nem megfelelő időzítés és HSYNC/VSYNC jelek miatt lehet, amit a PC-s tuner kártyák gyakran nem szeretnek, CRT-n viszont ez nem feltétlenül okoz képhibát.
-
Lehet, hogy gyorsítás kedvéért kivették ezt a Dave végleges verziójából? De a doksik dátuma mind jóval későbbi mint a gép megjelenése...
Valahogy meg kéne mérni.
Gyorsan teszteltem egyet. A kártyámon az A14 illetve afölötti címek a memóriák felé a CPLD-n keresztül mennek bizonyos okokból. Megcsináltam, hogy az SRAM/FLASH felső címei úgy álljanak elő, hogy egy tároló az _MREQ lefutó élére eltárolja a buszon éppen akkor levő címvonalakat, majd ez kerül ki címként. A végeredmény: működik minden, mintha mi se történt volna. :) Szóval úgy tűnik, hogy (legalábbis az alap 4MHz-es CPU órajel esetén) az _MREQ aktiválásakor már jók a DAVE címkimenetei.
De ha már itt voltam, csináltam egy másik tesztet is. Az adatbusz meghajtóját 74LS245-ről visszacseréltem 74HCT245-re. Az SRAM egyből hibázott, az Advanced Test mind az 512K-t hibásnak mondja így notóriusan. :) Viszont a normál teszt csak 256K-t dob ki, látszólag minden második lapot. Cserébe ebben az állapotban az ExDOS bővítés továbbra is hibátlanul üzemel.
Ezek után "keresztbe" is teszteltem egyet; az összes egyéb meghajtót (amik a címeket meg a vezérlőjeleket hajtják, tehát amik CSAK KIfele tolnak) cseréltem 74HCT245-re, az adatbusz maradt 74LS245. Így sem sikerült még hibázást elcsípnem, pedig már pár kör teszt lefutott. Szóval az 512K-s SRAM-om az adatbusszal veszik valahogy össze. Na de hogy? :-D (Így egy kicsit diszkrétebb a fogyasztás, kevésbé akar megfőni a stab. Úgyhogy azért hurrá!)
Hogy ez megint mit jelent, arról fogalmam sincs. :)
Anno amikor elkezdtük felfedezni a problémát, ide raktam fel kép párokat. (http://enterpriseforever.com/hardver/pixelhibas-alaplapok/msg14091/#msg14091)
Kicsit feljebb István említi a lila problémát is, ami nála S-Video-n jön elő, később is volt emlegetve.
Ott vannak külön futtathatóan is a használt tesztképek.
A gémeskút az nagyjából úgy néz ki, mint amit IstvánV is lőtt, a felhők szélei itt-ott belilultak. Stabil a kép, tehát nincs zizegés, mindenesetre meg kell ezt majd néznem RGB-n is valahogy.
A lila színhiba itt (http://enterpriseforever.com/hardver/s-video-kimenet/msg34189/#msg34189) is látható egy korábbi S-Video témában, bár ezen a képen kevésbé feltűnő. Valószínű, hogy az LM1886 okozza, és úgy látszik, nem csak az én gépemen fordul elő ez a probléma.
Ez megnyugtat. :) Eszembe jutott egy ötlet, ezt ki is próbálom mindjárt.
Szerk.: Kipróbáltam, nem jött be. :( Az S-Video kimenethez én is kiszedtem a C38/C39 100pF-os kondenzátorokat. De a kompozit videojelnél alapból az volt az elképzelés, hogy mivel a szemnek úgyis kisebb az "érzékenysége" a színek változására mint a fényerősségére, ezért a "színinformációhoz" nem kell akkora sávszélesség. Ez a két kondenzátor meg a színkülönbség-jeleket sávhatárolja. Az volt az esetleges tipp, hogy megfelelő képtartalom esetén a "túl nagy" frekvenciájú színjel esetleg megőrjíti a PAL kódolót. De visszarakva a két kondenzátort kb. semmi se változott. :) A lilaság maradt.
Amúgy van egy másik gondom is, a képen világosabb tartalomnál látszik némi "hullámzás", amit a géphez jelenleg használt kapcsolóüzemű táp számlájára írok, de most kísérleteztem pár helyre hidegítést berakni, látszólag semmi hatása. Még futnom kell ezzel pár kört, úgy tűnik.
-
Kezdem azt gondolni, hogy az mivel a Nick-bol kijon 8 bitnyi szininformacio, amit ellenallasokbol takolt "DAC" alakit analog jelegge, ilyen-olyan LM-xxx IC videojelle; az egeszet "ki kene dobni", es megprobalni a digitalis jelekbol kiindulni, es valami jobb minosegben eloallitani videojelet az egeszbol mar eleve. Igy egy rakas hibaforras megsporolhato lenne, esetleg a 12V is (tenyleg, kell az masra? Ok, a serial cuccokon kivul, amit szinten szerintem szuksegtelen a mai vilagban es egy MAX232-vel vagy hasonloval megfejelve "szabvanyos" RS232 jelszinteket lehetne inkabb csinalni vele azonnal - bar akkor meg kerdeses egy-par extra sorsa, mint a boxsoft eger illesztesnel ... hmmm).
-
Kezdem azt gondolni, hogy az mivel a Nick-bol kijon 8 bitnyi szininformacio, amit ellenallasokbol takolt "DAC" alakit analog jelegge, ilyen-olyan LM-xxx IC videojelle;
Majdnem. :) De egyébként ja. Van a NICK-ből kijövő digitális jel. Ezt egyrészt egy ellenállásokból tákolt "DAC" alakít analóg jellé, ez megy ki az RGB kimenetre. De van egy két IC-ből álló PAL kódoló áramkör, ez szintén a még digitális videóból csinálja meg a dolgait. Szóval ez a része akár még jó is lehetne. :)
az egeszet "ki kene dobni", es megprobalni a digitalis jelekbol kiindulni, es valami jobb minosegben eloallitani videojelet az egeszbol mar eleve.
Ez már bennem is felötlött; ezért is tetszett meg az Enterprise alapból. A gépben ott van hozzáférhető helyen a még digitális kép, meg a hang is. Egy kicsit több lehetőség van bűvészkedni, mint a régi CBM gépeknél, ahol ezek az IC-ből már csak analógon jönnek ki. (Mondjuk pont a VIC20/C64/plus/4 esetén az RGB digitálisan még az IC-n belül sincs meg... :) )
Igy egy rakas hibaforras megsporolhato lenne, esetleg a 12V is (tenyleg, kell az masra?
Az eredeti áramkörök hibaforrása kilőhető lenne, az igaz. A +12V még a videó órajel előállító áramkörhöz is kell, de szívem szerint azt is kidobnám a kukába. Lassan nem marad egy ép rész a nyákon... :-D
-
Ez már bennem is felötlött; ezért is tetszett meg az Enterprise alapból. A gépben ott van hozzáférhető helyen a még digitális kép, meg a hang is. Egy kicsit több lehetőség van bűvészkedni, mint a régi CBM gépeknél, ahol ezek az IC-ből már csak analógon jönnek ki. (Mondjuk pont a VIC20/C64/plus/4 esetén az RGB digitálisan még az IC-n belül sincs meg... :) )
Hat biza, Commodore esten eleg bizarr trukkoket talaltak ki, pl kiderult, hogy vmelyik szignal (talan az AEC) csunyan "athallatszik" a videojelbe, szulettek olyan otletek, hogy digitalizaljak a videojelet es valami fekete magiaval real-time levonjak a kerdeses "athallatszo" szignalt, igy sokkal jobb minosegu videojelet kapnak. EP-n ez lenyegesen egyszerubb, mert eleve rendelkezesre all a "tiszta" digitalis jel (az mas kerdes, hogy egy topicban mar emlitett "pixelhibas Nick" esete az akkor ugye valoszinuleg a Nick-en belul van, tehat ezen nem segit ...).
Amugy hang eseten is gyanus az "ellenallasletra" modszerrel nyert "DAC" linearitasanak kerdese ...
Az eredeti áramkörök hibaforrása kilőhető lenne, az igaz. A +12V még a videó órajel előállító áramkörhöz is kell, de szívem szerint azt is kidobnám a kukába. Lassan nem marad egy ép rész a nyákon... :-D
Mindegy, amugy is felmerult mar az uj EP alaplap terve, ahol lehetne ezt-azt modernizalni :) Ha mar Commodore (es C64) ott is van ilyen konkret project.
-
Amugy hang eseten is gyanus az "ellenallasletra" modszerrel nyert "DAC" linearitasanak kerdese ...
István már többször is emlegette, hogy nem tökéletes.
-
István már többször is emlegette, hogy nem tökéletes.
Bocsanat, igy ertettem en is, csak nem fejtettem ki, az igaz :)
-
A hangképzésnél nem használnak lineáris skálát, mert a fül másképp működik. Hangképzésnél logaritmikus a skála. Eszerint építik fel az ellenálláslétrát is.
-
A hangképzésnél nem használnak lineáris skálát, mert a fül másképp működik. Hangképzésnél logaritmikus a skála. Eszerint építik fel az ellenálláslétrát is.
Ok, akkor a logaritmusossaga nem linearis, erted mire gondolok, csak megfogalmazni nem tudom :) Szoval az alkatreszek szorasa miatt nem pont ugy viselkedik, ahogy idealisan kene, szamitva vagyon, stb, erre celoztam volna.
-
A hangerő érzékelése ugyan valóban nem lineáris, bár a logaritmikus skála sem igazán pontos. 10 dB különbség, azaz 10-szer nagyobb teljesítmény és 3.16-szor nagyobb feszültség kb. kétszeres hangerőnek felel meg.
DAC esetében azonban a lineáris skála a megfelelő, mert azzal a legkisebb a torzítás és zaj, és az EP is ezt próbálja megvalósítani, több-kevesebb sikerrel. Előfordulhat az is például, hogy a 32-es szint (100000b) kisebb mint a 31-es (011111b).
-
A torzítás a kép felső részén a PAL szabványnak nem megfelelő időzítés és HSYNC/VSYNC jelek miatt lehet, amit a PC-s tuner kártyák gyakran nem szeretnek, CRT-n viszont ez nem feltétlenül okoz képhibát.
Ez is "megvizsgálandó rész" (írom szinte már megszokásból...). :-) Mivel a jelenség csak akkor jön elő (látszólag), amikor a keretszín nem fekete, én arra tippelnék, hogy a szinkronhoz túl közel kezdődik/végződik a keretszín, rövidre van véve a "kioltási szint". Ez meg megőrjíti a digitális tuner(eke)t. Ezen is lehet faragni majd, de... (...és itt kezdődik a hajtépés meg sikítozás... :mad: )
A hanggal egyelőre csak az a problémám, hogy a képpel együtt elég zajos. :) Ezen a részen úgy érzem egy komoly "átépítést" kell majd eszközölnöm, de a jelenlegi helyzettel azért valamennyire elégedett vagyok, úgyhogy ezt egy kicsit hátrébb sorolom a feladatok között.
Most jöhet az IDE interfész, ehhez is lesz majd egy adag kérdésem, de előkeresem a megfelelő topikot hozzá. :)
-
Mit csinál a Xilinx CPLD az EXDOS kártyán? Egy dolgot, vagy több dolgot is?
-
Mit csinál a Xilinx CPLD az EXDOS kártyán?
Jelen pillanatban az SRAM-nak, a FLASH-nek állít elő _CS jelet illetve az A14..A18 címeket generálja. (Mivel a két toknak közösek ezek a címek, de "kapacitástól" függően máshogy vezérelendők, így direkt nem akartam a címbuszra kötni ezeket.) Aztán még a WD177x-nek állít elő órajelet illetve _CS-et. Meg a hozzá tartozó ki és bemeneti portnak az engedélyező jeleit. Azt hiszem talán mást nem.
Ja, meg a buszmeghajtók közül az adatbusz maghajtását engedélyezi, amikor bármilyen olyan ciklus van, ami a kártyának szól.
(Meg tesztből van benne egy számláló, amit egy I/O porton keresztül ki lehet olvasni, de ez majd később kikerül.)
-
Bele lehetne tenni még egy szorzó áramkört.
-
Bele lehetne tenni még egy szorzó áramkört.
Jelenleg 27 regiszterem van elhasználva a 72-ből, valami akár még bele is férne. Mondjuk érzésre egy 8×8 bites szorzónak már kevés lenne a maradék hely, de mire is lenne ez jó? :)
-
Inkább tegyél oda egy puffer vezérlést (meg természetesen pluszban egy memóriát), hogy a WD-től érkező adatokat szabadabban lehessen fogadni. Valahol olvastam itt a fórumon – talán Zozosoft valamelyik hozzászólásában – hogy elég szoros a szükséges időzítés, így közben mást nem nagyon lehet csinálni. (Sőt, lehetne a pufferelés mindjárt két irányú is. :ds_icon_cheesygrin: )
-
Tudva azt, hogy egy ilyen kis CPLD nem éppen matekra van kitalálva, poénból generáltam egy szorzó áramkört. :) A 8 bites az - természetesen - nem fért el, a legnagyobb, ami sikerült, az egy 4×4 bites szorzó, ami sima kombinációs logikaként még belefér. Hogy ezzel lehetne-e bármit kezdeni... :-D
Inkább tegyél oda egy puffer vezérlést (meg természetesen pluszban egy memóriát), hogy a WD-től érkező adatokat szabadabban lehessen fogadni. Valahol olvastam itt a fórumon – talán Zozosoft valamelyik hozzászólásában – hogy elég szoros a szükséges időzítés, így közben mást nem nagyon lehet csinálni. (Sőt, lehetne a pufferelés mindjárt két irányú is. :ds_icon_cheesygrin: )
Ez simán meg is oldható, sőt: a kártyán levő 512K-ba direkt is pakolhatnám az adatot. (Mondjuk a gépben levő 64K+64K nem tölthető így, de ez úgyszintén csak teoretikus.) Viszont mire lenne ez is így jó? :) Ez akkor lenne hasznos, ha megcsinálnám, és utána egyből mindenkinek ilyen lenne az ExDOS kártyája. :) Azzal sokra nem mennénk, ha ez csak nálam működne.
-
Viszont mire lenne ez is így jó? :) Ez akkor lenne hasznos, ha megcsinálnám, és utána egyből mindenkinek ilyen lenne az ExDOS kártyája. :) Azzal sokra nem mennénk, ha ez csak nálam működne.
Először menjen nálad, azután lehet esetleg faragni egy pici add-in board-ot – pl. olyan stílusban hogy a bővítő megy a WD helyére, abba meg a WD – mondjuk csak a RAM-mal és kisebb CPLD-vel, és idővel mindenkinek lesz. Persze kérdés, hogy érdekel-e ez bárkit? Akarnak az urak trackmo-kat csinálni amik rendesen tudnak zenélni töltés közben?
-
Először menjen nálad, azután lehet esetleg faragni egy pici add-in board-ot – pl. olyan stílusban hogy a bővítő megy a WD helyére, abba meg a WD – mondjuk csak a RAM-mal és kisebb CPLD-vel, és idővel mindenkinek lesz.
Jó terv! :) Ez a felépítés mondjuk igencsak átgondolandó, mert most (így érzésre) egy kicsit több a lehetőségem, mint add-in board üzemmódban.
Persze kérdés, hogy érdekel-e ez bárkit? Akarnak az urak trackmo-kat csinálni amik rendesen tudnak zenélni töltés közben?
Hát persze hogy akarnak! :) Amúgy ezt szerintem most is meg lehetne csinálni, csak nem a floppy-val, hanem az IDE vagy SD illesztő segítségével. Mintha lett is volna szó róla, hogy lesz olyan lehetőség, hogy az IRQ-t ne lője le olvasás alatt a rendszer. (Ez az IDE/SD esetén nem gond, ha jól sejtem.)
-
Tudva azt, hogy egy ilyen kis CPLD nem éppen matekra van kitalálva, poénból generáltam egy szorzó áramkört. :) A 8 bites az - természetesen - nem fért el, a legnagyobb, ami sikerült, az egy 4×4 bites szorzó, ami sima kombinációs logikaként még belefér. Hogy ezzel lehetne-e bármit kezdeni... :-D
...
Nem jól kezdtél neki, azért lett nagy. Szorzó áramköröket háromféleképpen lehet csinálni:
1. puszta kombinációs hálózat (rengeteg logikai elemmel amelyek mindig számolnak, ha a bemenetük változik), előnye viszont, hogy piszok gyors!!!
2. órajelvezérelten, ami állapotgépszerűen működik időben eltolva, lassú, de nem kell sok logika, mert a számolást mindig ugyanaz a cella végzi
3. az első kettő kombinációja, pl. 8x8-as szorzás felépíthető 4db 2x2-es szorzóból + (4-1) db összeadócella (utánagondoltam és ez nem igaz)
A jó öreg 'C <= A * B' nem sajnos adja ki a legmegfelelőbb eredményt, mert az 1. opciót veszi. Érdemes rá inkább entitást írni. Egyébként milyen nyelven konfigurálod a CPDL-t?
Kérdezzük meg Zozo-t, hogy mennyi gépi kódú utasítás kell egy 8x8-as szorzási művelet elvégzésére a Z80-nál?
-
Nem jól kezdtél neki, azért lett nagy.
A (számomra) lehető legegyszerűbb módon kezdtem hozzá. :-D
Szorzó áramköröket háromféleképpen lehet csinálni:
1. puszta kombinációs hálózat (rengeteg logikai elemmel amelyek mindig számolnak, ha a bemenetük változik), előnye viszont, hogy piszok gyors!!!
2. órajelvezérelten, ami állapotgépszerűen működik időben eltolva, lassú, de nem kell sok logika, mert a számolást mindig ugyanaz a cella végzi
3. az első kettő kombinációja, pl. 8x8-as szorzás felépíthető 4db 2x2-es szorzóból + (4-1) db összeadócella (utánagondoltam és ez nem igaz)
Ez oké, de azt azért ne felejtsük el, hogy ez csak egy CPLD. Az ilyen feladatok inkább FPGA-ra valók. Az én verzióm nyilván az első volt, nem akartam én bonyolítani. Arra való a szoftver... :) De a második verzióhoz is kell összeadni, az sem túlzottan hatékony egy CPLD-vel. (Elég csak arra gondolni, hogy FPGA-ban szokik lenni ehhez direkt támogatás, pl.) De a sebesség itt is bőven elég jó lehet, tulajdonképpen ha azt eléred, hogy a Z80-as I/O kiírás és a végeredmény visszaolvasása közbeni időben "kipörög", gyorsabb nem kell.
Egyébként milyen nyelven konfigurálod a CPDL-t?
Alap VHDL.
Kérdezzük meg Zozo-t, hogy mennyi gépi kódú utasítás kell egy 8x8-as szorzási művelet elvégzésére a Z80-nál?
Akár, de látatlanba mondom: sok. :-D Amúgy mi lenne ebből? FPU? Azaz: Fixed Point Unit? :razz:
-
Időspóroló lenne. Ennek köszönhetően matematikai rutinok és memóriabeli táblák (tömbök) gyorsabban kezelhetőek lehetnek.
Ennek következtében grafiaki számítások gyorsulhatnak.
-
Pontosítok. Az add-in board alatt egy csak és kizárólag a lemezműveletek pufferelésére szolgáló bővítést értettem. Csak szokás szerint kicsit zavarosan sikerült fogalmaznom.
-
Pontosítok. Az add-in board alatt egy csak és kizárólag a lemezműveletek pufferelésére szolgáló bővítést értettem.
Sejtettem. :) Viszont azon gondolkoztam, hogy ezt a feladatot talán egy "idevaló" mikrovezérlővel kellene inkább megcsinálni, sokkal kevesebb alkatrész kellene hozzá. Végül is nem tűnik a feladat lehetetlennek, egy kicsit jobban bele kell ehhez merülnöm a WD lelkivilágába.
-
Sziasztok!
Találtam a sok régi vas között egy olyan kábelt aminek az egyik vége az EP monitor csatlakozójára megy a másik vége pedig egy 6-os DIN, amilyen a Commodore soros kábele is.
Van ötletetek, hogy vajon mire lehet ezt használni?
-
Találtam a sok régi vas között egy olyan kábelt
Milyen kincsesbányád van neked, ahol csak úgy találsz ilyeneket? :shock:
aminek az egyik vége az EP monitor csatlakozójára megy a másik vége pedig egy 6-os DIN, amilyen a Commodore soros kábele is.
Van ötletetek, hogy vajon mire lehet ezt használni?
Lásd 24-25 oldalak. (http://enterprise.iko.hu/magazines/EnterFace.pdf)
Keresel hozzá egy olyan monitort, aminek ilyen a bemenete.
Vagy esetleg lecseréled a dugót rajta...
De elötte kérünk róla sok szép fotót, mert ilyet még képen se láttunk!!!
A 88-as Centum árlistában (http://www.ep128.hu/Ep_Konyv/Katalogus.htm) KT-12 a jele, és 1298 Ft-ba kerül.
-
Szia!
Szerintem a párhuzamos portra megy, és CBM perifériákat lehetett valami programmal kezelni vele.
-
Szerintem a párhuzamos portra megy, és CBM perifériákat lehetett valami programmal kezelni vele.
Annak a kábelnek 3 vége van összesen. (http://www.ep128.hu/Album/Pic/CBM.jpg)
Mint az előbb írtam létezik DIN6-os végű monitorkábel.
-
Szia!
Szerintem a párhuzamos portra megy, és CBM perifériákat lehetett valami programmal kezelni vele.
Melyik is pontosan a párhuzamos port?
Megnéztem, de csak a monitor csatlakozóhoz jó. Egyik másikba sem megy bele az EP csatlakozói közül.
Örülnék ha lehetne vele kezelni CBM perifériákat, de szerintem is sanszosabb, hogy monitor/TV -hez lesz jó.
Bár sajnos nincs olyan készülékem, amivel ki tudnám próbálni.
Szerintem még jópár x éve vettem ezt is vaterán, amikor rámjött a régi gépgyűjtés láz első felvonása.
Most megint beszippantott kicsit. :) Bár az EP-vel csak most kezdtem el jobban foglalkozni.
Lövök majd a kábelről egy képet ha lesz rá időm. ;)
-
Kevertem Zozo által linkelttel. Elnézést. Sok évtizede használtam, a részletek homályba vesztek. PC-hez volt olyan, aminek elég volt az LPT port.
Akkor az monitor kábel.
A beszippantást megértem, néha rám is rámjön. :)
-
De elötte kérünk róla sok szép fotót, mert ilyet még képen se láttunk!!!
Íme az emlegetett kábel. :)
(http://www.kephost.com/images/2016/06/07/cable.jpg)
Kár, hogy nem tudom kipróbálni...