Kompozit video jel előállítása korlátozott TTL alkatrészekből

Elektronika, Elektromos eszközök

Elő kellene állítanom egy 192x256 pixeles kompozit videó jelet TTL IC-kkel, 4Mhz órajelből. Nehezítésként csak a következő IC-ket lehet használni:
2*74393, 1*7493, 2*74138, 1*74165, valamint 2*7400, 7403, 7404, 7408, 74132 (nem kell mindet felhasználni).
Az adattartalom generálásához szükségem van 5+8 bitre a videó RAM címzéséhez, valamint 3 bitre aminek az értéke modulo 6 inkrementálódik.
Emiatt a 4MHz-et először 6-tal el kell osztanom, hogy ezt a 3 bitet megkapjam. Ez megy a 74138-ba, ami a 74165 LOAD lábát vezérli, valamint 6-nál reseteli ezt a számlálómat. Úgy tűnik, ez szükségszerű és kihagyhatatlan.
Azonban a többi sehogyan sem jön ki. A 666666Hz-es jelet, ha leosztom a 2x5 bit számlálóval, akkor a végén kapok egy 651Hz-es jelet, ami 13-mal leosztva pont az 50Hz VSync jelet adhatná. De ez esetben nincs 15.6kHz-es jelem HSync-re, csak 10kHz és 20kHz.
Ha a 20kHz-re megpróbálok egy számlálót illeszteni, ami 16us-ig várakozik, akkor meglenne a HSync, de elfogynak a bitjeim a VSync-hez és az 50Hz is elúszik ...
Tehát nem tudom, hogyan lehetne a fenti IC-kből egy olyan konstrukciót összerakni, amivel képes lennék működő kompozit jelet összeállítani.

Első változatban sikerült egy 24x34 karakteres stabil kompozit képet kialakítanom, de ott 8 bit széles karakterek voltak.
6 bit széles karakterekből 32 karakteres sorok kialakítása azonban sehogyan sem sikerül.
Tud valaki tanácsot, útmutatást, ötletet adni?
(Kérem ne másoljatok be AI válaszokat, azokon már túlvagyok.)

 

  • 1661 megtekintés

( plt | 2025. 02. 20., cs – 08:45 )

Tehát úgy néz ki, a trükk a 74132-es IC-nél van. Számláló helyett ezzel kellene a HSync jelet generálni. Az impulzusnak a lefutó élre kellene indulnia, és 16us-ig tartania.

A lefutó élre nem tudok jó impulzust generálni. Az AI szerint azért, mert ennél az IC-nél a 0 nem igazán 0. De ha a felfutó jelet vezetem rá, azzal már megy. Ezért a jelet egy NOT kapun vezetem át előtte. Ezzel azonban megszűnik működni. Innentől nem tudom hosszabbítani a jelet, csak a kitöltési tényezőt változtatni. Fura.

A lényeg, hogy ha sikerülne stabilan előállítanom a 74132-vel egy lefutó élre induló 16us-os jelet, ami működik akkor is, ha a bemeneten hosszan 5V van, akkor megoldódna a probléma.

74132-re nem találtam mintákat, de 4093-as IC-re igen. Jelenleg ezzel próbálkozom. (Fig. 2.)

Ezek a 6 bit széles karaketerek is gyanúsak, 8x32 az pont kiadja a 256 képpontot. Nem 256(látható)+128(border) egy teljes sor hossza? Ez elég általános volt főleg arcade gépeknél. Lehet, hogy a ROM 6 bit széles, de a két szélén lehet 1-1 üres oszlop, egyszerűen a shift regiszter A és H bemenete GND-n van pl., B-G-ig pedig a ROM kimenetét kapja.

https://gitlab.com/mamedev/mame/-/blob/mame0226/src/mame/drivers/e100.c…

De ránézésre is elég szélesen rajzol.

Ezen a videon is szélesebbnek tűnnek, mint 6 pixel (főleg a karakterek közti szünetekkel, a 0-n megszámolhatóak a pixelek):

https://www.youtube.com/watch?v=N9ax6bOe3yY

Ha valóban csak 6 pixel széles egy karakter, az 6x32=192 az aktív terület, 265-192=73 a border+overscan, ez végül is egy lehetséges felállás lenne, de nekem nem úgy néz ki.

 

A szintén 4 MHz pixel clockos VIC-20-on alapban csak 22 karakter az aktív terület (igaz ott ez programozható). Ha ez valóban 4 MHz/32 karakter akkor a border terület az szinte 0. Jó lenne megnézni egy eredeti gép képét.

 

Szerk.:

https://www.youtube.com/watch?v=31SlmrGWyBw

Lehetséges az 5 pixel + 1 a karakterek közti szünet. Viszont akkor 264 széles sor lenne a logikus, ez 6x44, szóval kell egy 6-os számláló meg egy 44-es, ezek az 1 db 393 és 1 db 93-ból kialakíthatóak.

Lefuttattam az emulátoron is az utolsó videón látható programot. Az emulátorban nem összefüggő a grafika, míg az eredeti gépen az. Egyértelműen hibás az emulátorban a karakterek megjelenítése. Szerintem a BASIC teszt videó is emulátoron futtatva készült.

Tehát a megjelenített karakterek 6x8-asak, extra közök nélkül.

Igen, így aztán a 265x265-ös felbontás valóságtartalma is kétséges. De minden esetre 6-ig el lehet számolni a 7493-al, az egyik 74393 számolhatja a karaktereket, a másik pedig a sorokat. Szerintem nem kell hsyncet sem ilyen primitív monostabil fokozattal megoldani, van ott elég kapu, hogy a karakterszámláló kimeneteiből összekapuzzon egy használhatót.

A VSync-hez használok már csak monostabilt. A HSync jelent a 393-as 6. bitje képviseli, és a 6. 4. és 2. bit együttese törli a számlálót. Ez így 63us-os sorhosszt ad ki. A 6., 4. és 3. bittel törölve 66us-os sorhosszt kapok. (Egyik sem 64us.) Bármelyiket is választom, a kép még mindig vibrál.

Megpróbáltam egy Junosztyra rákötni, hátha a régebbi TV-k jobban értelmezik.

Sajna az is vibrál. Lehet tekergetni a tetején, úgy be lehet állítani stabilra a képet, de akkor meg egy negyed képernyő magasságú jobbratolódó hullám kerül a kép tetejébe. Ez sem az igaz ...

6. 4. és 2. bit együttese törli a számlálót

Ha jól számolom, 124-ig számolsz (vagy 248-ig, ha a 393 fele képpontfrekvencián jár)? A shift regiszter load/shift jelét honnan veszed ekkor?

Ha a hsync a számlálás végéig tart, és az aktív terület 0-nál kezdődik, akkor a hsync után rögtön kezdődő képjel nem lesz az igazi (back porch hiányzik pl.)

 

És hány sor van? Mondjuk ha a maradék 393-at használod, akkor 256 kijön belőle, szerintem használható vsyncet ennek a kimeneteiből is lehetne csinálni.

Én monostabillal előállított sync jeleket eddig csak magyar gépeknél láttam, de azokban is legalább erre a célra készült IC volt. Svédek szerintem nem szórakoztak ezzel.

Megütötte a szememet a Junoszty. :-D

Volt Orionos fejlesztőmérnök kollégámat idézve: Lehet egy tranzisztorból is szinkronleválasztó fokozatot építeni, DE NEM ÍGY!

Szóval ez a tévé nem ideális tesztalany. ;) Nagyon nehezen kapja el a szinkront, érzékeny a hálózati zavarra. Egy lámpa lekapcsolásakor összecsuklik a kép. Pár évtizeddel korábban hasonló cipőben jártam és tévéket is szerettem moddingolni. Vettem az Ezermester Boltban valami Philips szinkronmodult és Pluszként beépítettem. Az eredmény döbbenetes volt: Még csak hóesés látszott, de már állt a kép, mint a cövek! :-D

A Homelab II-es gépnél modernebb TV-n már csak úgy látszanak a felső sorok, ha a kapcsolásba beépítésre kerül pluszba egy kis NOT kapus késleltetés a képszinkronhoz. Azt gondoltam, azt a gépet azért Junosztyon biztos jól kellett látni, emiatt gondoltam jó tesztalanynak. Persze már csak végső elkeseredésemben, mert a többi modernebb TV-n sem ment.

De akkor ha az új kapcsolás Junosztyon nem lesz jó, rápróbálok egy másikkal katódsugarassal is, köszönöm.

( nehai v | 2025. 02. 20., cs – 09:18 )

Érdemben nem tudok segíteni, mert 20+ éve az ilyen bonyolultságú feladatokat CPLD-vel és/vagy mikrokontroller oldom meg és emiatt megkopott a TTL tudásom. Viszont érdekelne, hogy milyen apropóból jön ez a feladat, ha nem titok?

„Az összeomlás elkerülhetetlen, a katasztrófa valószínű, a kihalás lehetséges.” (Jem Bendell)

Egy olyan régi gépet szeretnék újraépíteni, aminek nem elérhető a kapcsolási rajza sehol. A MAME emulátorának forráskódjában elég szépen le van írva az eredeti hardver alkatrészlistája, ASCII rajz is van az alaplapról. Sőt, még egy nem túl jó minőségű fotóm is van a NYÁK-ról. Sajnos a pontos IC nevek és a kapcsolási vonalak nem azonosíthatók be rajta, de az elhelyezkedés igen, és stimmel is a MAME forrásban található leírással.

Mivel viszonylag egyszerű konstrukció, tanulásnak is szánom a magam részére. Egyrészt elektronikai alapismereteket, másrészt KiCAD használatot próbálok tanulni közben. Most éppen azt, hogy hogy lehet Schmitt-triggeres NAND kapukból jó monostabil multivibrátort építeni.

( plt | 2025. 02. 26., sze – 20:19 )

Szerkesztve: 2025. 02. 26., sze – 20:22

Jelenleg ott tartok, hogy sikerült a 32x32 karaktert megjeleníteni a TV-n, de nem tűnik elég stabilnak az alkotás.
Két teszt TV-ből az egyik már elfogadható, stabil képet mutat, de a másikon ugyanez a jel még folyamatosan futó, vibráló képet ad.
(A HSync jelem nem állítható finoman, az logikai kapcsolatokból jön ki, a VSync jelet tudom állítani egy potméterrel.)
Mivel jelenleg a két szinkronjel egyszerű OR logikával kapcsolódik, ezért a VSync alatt nincsenek külön HSync jelek.
Több leírás is azt ajánlotta, hogy XOR kapcsolattal egyesítsük a szinkronjeleket, ezért - bár az alkatrészlistában nincs XOR
kapu, kipróbáltam a XOR kapcsolatot, hogy javul-e a kép stabilitása.
Sajnos ez sem segített - igaz, nem is rontott.
Van ötletetek, min lehetne még finomítani ahhoz, hogy stabilabb képet kapjak? Melyik része lehet még fontos a kompozít jelnek, ami segíthet?
 

( Hiena v | 2025. 02. 26., sze – 22:05 )

Mivel játszottam/futottam pár kört ebben a témában, pár apróbb ötletet tudok adni:
Az 50Hz és a 15.6kHz nincs kőbe vésve, de a kettőnek szinkronban kell lennie. A legtöbb TV elég jól tudja kompenzálni az eltéréseket, minél öregebb a TV annál jobban.

Vedd figyelembe a sor és a képvisszafutási időket, ha fut a kép, ezekkel tudsz játszani.

Esetleg ha megadod a gépnek a típusát, akkor lehet, hogy többet tudok segíteni.

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Köszönöm, én is arra tippeltem, hogy van tűrése a frekvenciaértékeknek. A sorszinkront csak pár érték közül tudom kiválasztani, de a képszinkront finoman tudom hangolni. Ezzel sikerült az egyik monitoron stabil képet beállítani.

Amitől tartok, hogy a szinkronjelek lefutása után a kompozit formátum előírna még valamennyi várakozási időt is. Ezt a sorszinkron esetében nem tudom biztosítani. Képszinkron esetén a szinkronjel elé be tudok szúrni még egy eltolást, de a végére nem tudok még várakozást illeszteni.

Egyébként a gép pontos típusa ESSELTE 100. Nagyon kevés információt találtam róla, ezért is kell magamnak varázsolni. Szerencsére az alkatrészlista megvan. De ez nem az eredeti kapcsolás, csak azokból az alkatrészekből próbálom felépíteni.

( copass | 2025. 02. 27., cs – 08:16 )

Nagy Attilát kérdezd meg szerintem. Ő elég sok régi gépet javít és készít replikákat.
nattila.hu

( plt | 2025. 03. 02., v – 07:16 )

Végre sikerült beregisztrálnom abba a az egyetlen svéd nyelvű fórumba, ahol írtak erről a gépről, és sikerült megszereznem a Videó részleges kapcsolási rajzát - nem túl jó minőségben.

A rajzon szereplő IC-k:

U501    SN74LS157
U502    SN74LS157
U503    SN74LS157
U504    SN74LS245
U505    HM6116P-3 / MK4118      1K RAM
U506    2716                    ROM
U507    SN74LS165               Shift register

U508    SN74LS393               Karaktergenerátor
U509    SN74LS93                Karaktergenerátor
U510    SN74LS393               Karaktergenerátor

U511    SN74LS03
U512    SN74LS00
U513    SN74LS132
U514    SN74LS04
U515    SN74LS10

Látszik, hogy teljesen máshogy képzelték, mint én. Náluk a számláló 15 bites, míg én 16 bittel tudtam csak összerakni.

Ám egy dolgot egyáltalán nem értek: a rajz jobb alsó részében látható az 50Hz felirat, és az R[0..14] buszból kivezető vezeték visz oda.

A feliratnál egy kifelé mutató nyíl, ami jelentheti azt, hogy ezt a jelet kivezetik a kapcsolásból, vagy azt is jelentheti, hogy kintről érkezik az 50Hz.

1 - Ha kifelé vezetik a kapcsolásból, akkor honnan jön? Az R[0..14] busznak ez az egyetlen olyan kibontása, amin nincs felirat, hogy melyik vezeték.

2 - Ha kintről jön, akkor minek menne bele a buszba, hisz a busz összes többi kivezetése megnevezett, és nem az 50Hz.

Egy próbapanelen szívesen összeraknám a kapcsolásnak ezt a számlálós részét, de már ehhez is szükségem lenne arra, hogy tudjam, mit jelent itt ez az 50Hz-es vezeték.

Tudna valaki abban segíteni, mit takarhat ez a jelölés?

A rajzon több helyen is szerepel egy S0 és egy R/W jel, ugyanolyan kifelé mutató nyíllal jelölve, viszont ahová mennek, az határozottan egy-egy bemenet. Tehát ezeknek kintről kell jönniük.

Ezzel a logikával az 50 Hz is bemenetre megy, tehát kintről várjuk.

Az meg, hogy belerajzolták egy buszba, ahonnan senki nem kéri, az lehet rajzolási hiba is. Szerintem.

"Normális ember már nem kommentel sehol." (c) Poli

Találtam még egy kapcsolási rajzot, ahol a 6821-es IC 40-es lábára megy az 50Hz. Ez a láb, ha jól azonosítottam be, egy bemenet. Tehát az 50Hz generál megszakítást a PIA-n keresztül. A rajzon a "fran video" szöveg van melléírva, ami magyarul: videóról.

Ezek szerint a video kapcsolásból kell kijönnie az 50Hz-nek, de nem tudom, konkrétan honnan.

Az 50Hz jöhet a hálózatból is. A 70-es 80-as években bevett gyakorlat volt, hogy a táp trafójáról jövő kisfeszültségű 50Hz-ből csinálta 50 v.100Hz-es órajelet. Hasonló okok miatt lett 50Hz a PAL és 60Hz az NTSC frekvenciája.

A másik megoldás, hogy a control busz valamelyik jelét használták amit a CPU rángatott egy megszakítás ütemében.

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Köszönöm, ez nagyon jó ötlet! Nem is gondoltam erre! De sajnos a gépnek DC 9V-os bemenete van, amit rögtön még egy kondenzátorral simít a bekacsológomb előtt. Tehát félek, nem onnan jön.

Gondoltam összerakom a 3 számlálóból álló részt, és végigpróbálgatom mind az R busz mind a 15 vezetékét hátha valamelyikre 50Hz jelenik meg.

De rájöttem, hogy azt sem tudom, a legfelső számláló milyen órajelet kap. Az sincs jelölve. Magamtól a 4MHz-et raknám oda, de a 6802-es CPU kapcsolásánál látszik, hogy a kvarc a CPU-ba van direkt bekötve. Ez esetben azonban a 4MHz csak a CPU-n belül jelenik meg. Az E lábon már csal 1MHz érhető el.

Tipp: A commodore 16 is 6802 -es CPU-val volt szerelve, és azon ámítógépek egyike, ami nagyon jól van dokumentálva. Vizuáld meg, hogy ott hogy vannak megvalósítva a dolgok, tudom, hogy másik nyák, de hátha segít.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Megpróbáltam összeszedni, milyen vezetékek vannak a control bus-ban. Ezeket találtam:

R/W
RD
VA
VMA
\RES
\IRQ

Nem tudom mindet párosítani a CPU kivezetéseihez, és néha elég rossz minőségűek a képek, így lehet, hogy nem teljesen pontos a lista.

Lehet, hogy az 50Hz szoftveresen állna elő? A 6802-es processzorban talán beállítható időzített megszakítás, ami megjelenik az IRQ vezetéken?

A VA szerintem BA akar lenni, ez a Bus Available amit a WAIT utasítás meghívásakor változik. Innen egy timerrel viszonylag egyszerű clockot csinálni.

A /IRQ bemenet.

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Találtam egy kézzel teleírt "Modifieringar" nevű pdf fájlt, ami magyarul annyit teszt: módosítások. Ebben rá van írva valami az 50Hz-re menő buszra is. Talán R14, de elég ronda kézírással. Amúgy logikus lenne, ha már R, akkor a legnagyobb helyértéken várható a legkisebb frekvencia.

Ebből visszaszámolva - reszetelések nélkül - a bemenő frekvencia valahol 1MHz körüli (800kHz, 1.6MHz?) de akkor valószínűleg az E láb megy bele a legelső számlálóba az 1MHz-es jellel.

Ennyiből akkor már a számlálót meg tudom építeni, és ott kiderül, tényleg 50Hz jelenik-e meg ott.

Utána már csak azt nem látom, hogy az U507 Clokc és Load lábaira milyen jelek fognak jutni. Főleg, hogy ez még az S0-tól is függ. De azt hiszem, ez már a következő lépés.

Ez a Motorla CPU egy órajellel megy, amiból belső osztással generálódik az E és a Q órajel, szóval 1 MHz-en jár, ez normális.

Az U508 0-63-ig számol (64-nél reset, ekkor léptetődik az U504-510), valószínű az E az órajele.

Szóval az U508 az oszlopszámláló, pont 64 us, a másik kettő pedig a sorszámláló. 50 Hz-es jel lehet pl. ennek az MSB-je, R14, az framenként 1x lesz '1' állapotú, ezen kívül az R9-11, aminek 1-esbe kell állnia a resethez, azaz:

R14-6 100111000=312 sor/frame.

 

Szerk.: a shift regisztert és a video RAM-ot nézve érdekes, hogy a VRAM LSB-je az R0, ami 1 us-onként változik, tehát ennyi időnként jön új karakter, szóval képpont frekvencia nem lehet 4 MHz, hanem 6 MHz-nek kell lennie, hogy mind a 6 pont kirajzolódjon, mielőtt újratöltödik. Ez egyébkén gyanús volt az eredeti gép videoján is, hogy nem olyan szélsesek a pixelek, mint a 4 MHz indokolná. Az R501-es trimmer valószínűleg arra való, hogy ezt behangold.

S0 jöhet a címdekóderből, ha a CPU hozzá akar férni a VRAM-hoz, akkor 1, különben 0 (vagy fordítva?), ekkor shift regiszter loadja is tiltva van, szóval némi szemetelés előfordulhat a képen, ha a video RAM-ot írod/olvasod.

Nem állítom, hogy mindent értettem abból, amit írtál, de még párszor át fogom olvasni.

Addig azonban elkészült a számlálóblokk. Ha a számláló legelejére az E megy (1MHz), akkor az R14-en megjelenik az 50Hz. Ez jó.

Ha a videójelnek a shift kimenete helyett beteszem szintén ezt az 1MHz-es jelet, akkor egyenletes fekete-fehér függőleges sávok jelennek meg egy stabil képen. Tehát a VSync, HSync rendben. 48 ilyen fekete-fehér sáv van (48 fehér, 48 fekete).

Ezek után megpróbáltam beépíteni a shift regisztert is, egyelőre a ROM helyett fixre állított bemenetekkel. És innentől már nem jó.

S0 helyett még fix 1-et és 0-át próbálok. (Lehet ez a baj?) A jelenség az, hogy ha az U507 (74LS165) 6-os lábán (H) 1 van, akkor teljesen fehér a kép, ha 0, akkor teljesen fekete. A többi bemenetére érzéketlen. Vagyis nem léptet egyáltalán. Nincs elég jó órajele?

Ha szkóppal próbálom akár a Load, akár a Clock lábat nézni, akkor időszakosan van rajta jel, de több a szünet, mint a jeldús időszak.

Ha van épp jel, akkor az órajelre néha el tudok kapni 1MHz-es értéket. De itt már a szkópom korlátai is lehet, erősen beleszólnak a vizsgálatba.

A lényeg, hogy nem tudom a shift regiszter bemeneteit megjeleníteni.

Még átnézem párszor, elrontottam-e valamit, de egyelőre nem látom át, hogy lesz a léptető órajele jóval magasabb, mint az 1MHz.

A shift regiszter órajelét az U513b Schmitt-trigger és az R501 valamint a C502-ből álló RC tag állítja elő. Astabil multivibrátor inverterrel, független az 1 MHz-es E clocktól. R501-el be kell lőni, hogy minden pixel ki tudjon kerülni, mielőtt újratölt.

A load jel az az 1 MHz kapuzva az U511a, U511b, U512a és U513a kapukkal, ez utóbbinál, ha S0 0, akkor a kimenet nem tud változni, szerintem ez az az állapot, amikor a CPU írja/olvassa a VRAM-ot (ilyenkor a multiplexereken keresztül nem az Rxx kerül a VRAM címbenenetére, hanem az Axxx), ekkor nincs LOAD. (Szóval S0-nak 1-nek kell lenni, ha képet akarsz látni). Szkópon kéne, hogy látszódjon az 1 MHz-es LOAD jel (negatív aktív), megszakítva a képernyőn kívüli területeken.

Az U511a, U511b, U512a arról gondoskodnak, hogy az órajel csak az aktív ablakban jusson a shift regiszterre, képernyőn kívül ne legyen léptetés (egyszerű blanking).

Köszönöm, kezd összeállni bennem is és a képernyőn is a kép. Már megvannak a csíkok. A poti tekerésével megjelentek a shift regiszter bemeneti bitjei csíkok formájában, és a képernyő szélességét is állítja.

Az első 4 bit (E-H) jól látszik, de ha azt akarom, hogy az utolsó két bit (C-D) is látszódjon, akkor a képernyő szélessége lesz pici, azaz baloldalt egy keskenyebb sáv, jobboldalt egy eléggé széles fehér sáv látszik. Kb olyan széles, mint a hasznos képtartomány fele.

Ezek a sávok fehérek, ugyanúgy mint a kép alatti és feletti vékony terület is. Pedig az eredeti gép fekete alapon jelenít meg fehér karaktereket, fekete kerettel.

Valami nem ok - a poti tekergetése csak a karakterek szélességét változtatja, a képméretre nem szabad hatnia.

Az ellenállás, poti és a kondik értéke ismert és csak a rajzon nincs feltüntetve?

„Az összeomlás elkerülhetetlen, a katasztrófa valószínű, a kihalás lehetséges.” (Jem Bendell)

Hát igen, a sor/oszlopszámlálók, hsync, vsync mind (majdnem) tisztán digitális (vsync némileg késleltetve van RC tag által), és az 1 MHz-es E clockról megy, a shift regiszternek vajmi kevés köze van hozzájuk.

 

Szerintem ha a shift regiszter 7-es lábáról megy a video, akkor invertált lesz a kimenet, U511c megfordítja, fekete alapon fehérhez a 9-est kéne használni.

Egyébként az ellenállások/kondenzátorok értéke megvan?

R501-C502-t nem ártana méretezni, hogy meglegyen a 6 MHz.

Vagy pont fordítva, hogy minél hosszabb ideig töltődjön a kondi, így az 1 MHz-es jel elejét jól levágja, és a 6 MHz-esnél keskenyebb maradjon a LOAD-hoz. De végül is igen, az 5-ös lábon keskenyebb 1-nek kell lenni, mint a 6 MHz (fél)periódusa.

Megmértem az R508 ellenállást: 262 ohm. 270 a leírás alapján. Megnöveltem 196 ohmmal, de az eredmény gyakorlatilag ugyanaz.

A C501-nek  220pF-nak kellene lennie a leírás alapján. Betettem helyette egy 47nF-osat. Kicsit tekerni kellett a potin, de az eredmény ugyanaz. A bal és jobb szélét ezek érdemben nem befolyásolták. Félek, máshol rontottam el valamit, de még nem találtam meg.

Azért ezt a 6MHz-et nem értem. Ha 6Mhz az órajele a shift regiszternek, akkor a 192 pixelre vízszintesen 32us jut. A teljes sornak 64us-nak kell lennie. Ezek szerint pont jó képet látok. Kicsit több, mint a felén van kép, és az a kicsit több gondolom a VSync 4us-ja. Biztos, hogy annak 6MHz-nek és nem 3MHz-nek kell lennie?

 A Load jel 1 MHz, a VRAM címszámláló is 1 us-onként lép, ennyibe bele kell férnie egy teljes karakter kirajzolásának, ráadásul R5 a hblank.

Az valóban furcsa, hogy az aktív terület csak a sor fele, kb. 2/3-a lenne "normális", de semmiképp sem lehet a 100%-a.

 

Szerk.: a hsync 8 us (R[5:3] == 'b110).

Azt gondoltam, ha megnövelném a HSync hosszát, akkor a hasznos terület széthúzódna. Megpróbáltam felemelni 16us-ra úgy, hogy a

"(NOT R3) AND R4 AND R5" helyett a "(NOT R4) AND R5 AND R5" feltételt adtam meg. Sajna ez sem segített, mert teljesen eltorzult a kép.

De a "R3 AND (NOT R4) AND R5" feltételre jobbra tolódott a kép, és baloldalt lett jóval szélesebb a keret. A "(NOT R3) AND (NOT R4) AND R5" feltétel pedig teljesen jobbra tolta. Sajnos a hasznos terület szélessége egyik esetben sem változott. Ezek szerint ez a kapcsolás csak ilyen széles hasznos területet tud generálni, és a TV-vel kell széthúzni a képet?

Az, hogy a kép fele overscan, meg border, ezt adja ki.

De pl. itt szélesebbnek tűnnek a pixelek:

https://youtu.be/V34bFOnBmRU?t=2694

Véleményem szerint kisebb karakterórajellel (+ a shift regiszter órajelének hozzáigazításával), és még a 64 előtti karakterszámláló resettel lehetne normálisabb képet kapni. Pl. 3,5 MHz-es kristály, és egy extra áramkör, ami 64*3.5/4=56-nál reseteli az R0-R5-t (és lépteti R6-R14-et) megoldás lehetne.

Vagyis az eredeti az ilyen, és a megjelenítés TV függő?

Kipróbáltam azért a Junosztyon is, hát ott folyamatosan futott függőlegesen a kép, a TV-n nem tudtam stabil képet állítani.

És kipróbáltam egy másik LCD TV-n is. Ott pedig ugyanolyan stabil volt a kép, mint amit linkeltem, de a border folyamatosan vibrált fehér és fekete között váltogatva.

Próbáltam még módosítani az R és C értékeket a szinkronjeleknél, de az nem volt rá hatással.

Ha lecsökkented az órajelet, akkor a 64-es sorhosszból is arányosan vissza kéne vágni, akkor maradna az 50 Hz, és javulna az aktív terület/overscan arány.

De ha belegondolsz, a C64 időzítése eléggé hasonló: ~1 us/karakter (csak ott 8 pixel/karakter van), PAL VIC-II  ugyanígy 64 karakter/sor, viszont ott a látható terület 40 karakter széles.

Szóval erről van szó?
https://www.youtube.com/watch?v=31SlmrGWyBw

Biztosan a próbamonitrodon nincs almás címke(:
De ahogy olvasgatlak, kiszámoltam, hogy ennyi karakterrel 5Mhz volna az ideális pixelórajel, de azzal nem férsz be a mikroszekundumos karakterolvasásba, azon sehogy sem tudsz lassítani?

Igen, ez az a gép.

Az 1MHz a CPU E lábán jön ki. Egyszerűen nem tudok rajta módosítani. Ha meg nagyon átbuherálom, akkor meg már nem ez a gép lesz.

Igazából azt sem tudom, hogy az a 32us, amíg nem rajzol ki karaktereket, hogyan is néz ki pontosan. A HSync jel hossza 8us, de mi van a többi 24us-mal? Hogyan néz ki pontosan ez a 32us?

A PAL specifikációja megvan, azt nem tudom, hogy amit ez a kapcsolás generál, az pontosan hogyan néz ki.

A 32us adat után közvetlen jön a 8us alacsony HSync impulzus, és utána 24us alap jelszint? (Sajna a szkópom annyira nem jó, hogy ezt megnézhessem.) Vagy a HSyn 0V-ja előtt és után is van alap szintű üresség? És ha igen, mennyi? Ezt nem látom.

A hsync a kapcsolás szerint R[5:3] == 'b110. 

Tehát tart 110000-110111-ig, azaz 48-55-ig.

0-31: aktív terület

32-47: blank

48-55: hsync

56-63: blank (és back porch)

 

Esetleg megpróbálhatod átalakítani 40-47-ig: 101000-101111

Ehhez az 515a 9-es és 10-es lábát fel kell cserélni (110 vs 101).

Próbálom megérteni, mi is zajlik pontosan: az U508 számláló adja az alsó 6 bitet R[5:0] ami 64 us.

Amíg R5=0, addig tart az aktív terület. Ha R5=1, akkor jön a mágia:

Jelenleg R[5:3]
 100 - blank (32-39)
 101 - blank (40-47)
 110 - hsync (48-55)
 111 - blank (56-63)
Ha előretolom a hsync-et 101-re, akkor baloldalt lesz a széles sáv.
Ha legelőre tolom 100-ra, akkor eltűnik a jobboldali keret, kicsúszik jobbra a kép széle.
A megoldás talán az lenne, ha megnyújtanám a hsync jelet 16us-ra, vagyis az 101 és az 110 is hsync lehetne. Ezt sajnos a meglévő alkatrészekből nem tudom kipróbálni.

Na de várj! Emlékeim szerint a bruttó soridő 64 µs, a nettó pedig 56 µs. Neked meg a soridő fele, 32 µs az előváll, hsync, utóváll. Ez így nagyon nem jó. R[5:3] 000-110 között aktív képtartalomnak kellene lennie, egyedül az 111 alatt kellene a blank, hsync, blank szekvenciának lennie. Tehát 111 esetén az alsóbb bitekből kellene dekódolni, hogy mikor legyen blank és mikor hsync.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Élesztési tanács - ha már a számláló lánc működik:

1. Az S0 legyen magas, ekkor működik a képmegjelenítés, alacsony állapotban a proci írja a videó memóriát.

2. Ideiglenesen távolítsd el az U511-et, de az R502 maradjon és az 1MHz is a U512 10-es lábán.

3. A C501/R508-al állíts be úgy az 1MHz-es jelet, hogy a 250ns legyen negatív impulzus szélessége az U513 6-os lábán.

4. A C502/R501-el állíts be 6MHz-es folyamatos jelet az U513 3-as lábán. Lehet célszerű az U513 6-os és 1-es lába közötti összeköttetés megszakítani, az 1-es lábat felhúzni magas szintre és úgy beállítani a 6MHz-et.

Az ellenállásokat 1k-5k közötti tartományba lődd be. 

„Az összeomlás elkerülhetetlen, a katasztrófa valószínű, a kihalás lehetséges.” (Jem Bendell)

Megpróbáltam kivenni azU511-et. Az alkatrészeket még nem kezdtem el módosítani, hátha a gyári értékekkel tudnám életrekelteni, de megmértem a 6-os lábat. Azonban amit látok, az nem igazán négyszögjel, bár a szkópom meg nem profi. A méréshatártól függően mutat értékeket. Ha 200ns-os tartományban mérek, akkor 1-1.25MHz között ugrál, de olyan sűrű, hogy nem tudok hullámméretet leolvasni. Ha meg lemegyek 50ns-os tartományba, akkor már 7MHz körülit mér.

Így, hogy már van kép, lehet, hogy egyszerűbb lesz úgy állítani értékeket, hogy nézem, javít, vagy ront-e a képen.

Kicsit számolgattam, amivel próbálkoznék:

1. C501=470pF / R508=1k Ennek az időállandója(tau, enni idő alatt éri el a töltőfeszültség 63%-át) 470ns, de mivel a schmitt trigger az LS szériánál kb. 33%-on kapcsol, ezért kb. 250ns széles lesz az impulzus.

2. C502=470pF / R501=470ohm poti + 100ohm soros ellenállás, hogy a potival ne zárd össze a NAND ki/bemenetét. A képlet: f=1/1.2RC.

Nem tudom milyen szkópod van, de ha van rajta 50ns méréshatár, akkor az 1MHz-nek nagyjából jól kell megjelenni.

Szerk: az 1. pontot elkalkuláltam, mert 1MHz órajellel számoltam, de valójában shift regiszter 6MHz-el működik. Szóval a LOAD impulzus széllessége kisebb legyen a 6MHz impulzusszélességének felénél (83ns). A C501*R508 eredményének kb. 100ns kell lenni, így 50ns lesz az impulzus szélessége. Mondjuk 470pF/220ohm.

Szerk2: Megkérdeztem a Deepseek R1-et.

1. 470pf/280ohm-ot javasol a 6MHz-es oszcillátorra.

2. 470pf/460ohm-ot javasol 83.333ns-ra.

Én mind a két helyen 470pf/470ohm+100ohm trimmer+ellenállás soros kombóval próbálkoznék.

„Az összeomlás elkerülhetetlen, a katasztrófa valószínű, a kihalás lehetséges.” (Jem Bendell)

( plt | 2025. 03. 03., h – 08:25 )

Bekötöttem forrásként az eredeti karakterkészletet, hogy jobban látszódjon mi a helyzet. Jelenleg a shift regiszter 7-es lábán kijövő jel kerül a kimenetre, és úgy tűnik, ez a jó, mivel a karakterek alapja fekete, a pontjai meg fehérek. Így van az eredeti gépben is. De nálam a keret fehér, az eredeti gépnél pedig fekete.

Amúgy a felbontás rendben van, 32 karakter van egy sorban, 32 sorral. A karakterek alakja nagyon szépen állítható a potméterrel. Kb most van meg minden oszlop, és egyenletesek is.

( plt | 2025. 03. 10., h – 16:45 )

Mivel - úgy tűnt - a képet már jól generálja az elkészült rész, kiegészítettem az áramkört a memóriával és annak címzésével.

A karakter ROM mellé egy EEPOM-ba beírtam egy tesztképernyő tartalmát, és ezt próbáltam megjeleníteni. Így kellene kinéznie.

Kiderült azonban, hogy mégsem jó a kép előállítása: teszteléskor ugyanis normál karaktereket jelenítettem meg, amelyeknél balról az első oszlop üres volt. A tesztképernyőmön azonban vannak teljesen kitöltött karakterek is. Ezeknél pedig az U507 shift regiszter (74165) HSync alatt - amikor a LOAD (1-es) láb alacsony - definíció szerint a 6-os (H) láb tartalmát küldi a kimenetre, vagyis a karakter aktuális sorának balszélső pixelét. És hiába keresem a kapcsolásban azt a részt, ami HSync - pontosabban a HSync blank része - alatt tiltaná ezeket a jeleket, nem találok ilyet.

Így néz ki a tesztképernyő a valóságban, ami több sebből is vérzik:

1 - A keret helyett a HSync alatt (R5=1) a képernyő adott karaktereinek aktuális sorainak első pixele tölti ki az adott karakterpozíciót.

2 - A képernyő legtetején kb. az első 10 karakter legfelső pixelei feketék.

3 - A képet keretező pepita karakterben a pixelek sakktábla módon helyezkednek el, a valóságban mégis vonalakká állnak össze a karakterek egyes oszlopainál

4 - A képernyő alján lévő fehér körök, ami két félkör karakterből állna, megszakadnak, és eltorzulnak

5 - A képernyő közepén található összefüggő fehér csík alatti 2., 3. és 4. sorban egyenlő szélesség oszlopok lennének eltolva, de igaziból az utolsó sorban szélesebbek ezek a csíkok.

Elsőre olyan, mintha a karakter-ROM adatbuszai nem a megfelelő sorrendben csatlakoznának a 165-ös shift regiszter párhuzamos bemeneteire, de ez nem lenne magyarázat az 5. pontban megjelenő hibára. Amúgy ellenőriztem már ezerszer, és a megfelelő sorrendben csatlakoznak.

Teszteltem azt is, hogy a 165-ös IC 6-os lábát a ROM adatbuszáról leválasztottam, és földre kötöttem. A keret azonnal szép fekete lett, de persze eltűntek a karakterek első oszlopai, így nem lehetett összefüggő csíkot látni.

Végső tanácstalanságomban a shift regiszterből kijövő jelet befogadó NAND kapu egyik lábára a LOAD jelet másszor annak negáltját vezettem rá a videó jel mellé, de egyiktől sem javult meg.

Igazából most nincs ötletem, hogyan lehetne innen továbblépni, tehát minden ötletet, észrevételt örömmel fogadok.

Én a MAME ROM dumpban úgy nézem, hogy minden byte 7. bitje 0, ráadásul minden karakter tükrözve is van -> ez a 0 lenne a H (maga a karakterkép csak az 1-6-os bitekben van). Az még érdekes, hogy mitől kellene csak a B-G-ig a képernyőre írni, az A-t, H-t meg eldobni. Viszont még azt is látom, hogy néhány karakter 0. (7.) bitje 1, szóval lehet, hogy nem is 6, hanem mindjárt 7 bitet is ki lehetne shiftelni/us, csak kicsit feljebb kell csavarni az R501-et hozzá.

Szerk.: még jobban belegondolva, biztos, hogy több, mint 6 MHz a képpontfrekvencia, ha csak 6 pixel menne ki/karakter, akkor a ROM-ot elnézve nem lenne szünet a betűk közt. Van néhány speciális rajzoló karakter, aminek egy sorban 7 bitje is 1, ezekkel lehet folyamatos vonalat húzni gondolom. A ROM dumpban a 7. bit a 0 (valóságban ez a 0. bit), de ezt a bitet biztos nem kell kishiftelni. Ez úgy lehetséges, hogy a LOAD impulzus rögtön generál egy shift clockot is, majd rögtön jön a rendes shift clock az astabil multivibrátorból. Aktív területen kívül pedig nincs shift clock, így ez a 0 ott marad a H-n a folyamatos LOAD közben.

Köszönöm, megtaláltam a hibát. Amikor kibővítettem az áramkört, akkor egyben újra is építettem, mert a próbapanelen már nem láttam volna át.

Újraépítés közben pedig benéztem a C501-et, és 221 helyett 224-es kondenzátort tettem bele. Ráadásul hibásan azt feltételeztem, hogy R5=1 alatt a LOAD lábnak alacsonynak kell lennie. De aztán végiggondolva, R5=1 esetén U512a 8-as kimenete tartósan magas R508 miatt alacsonyra esik, vagyis a LOAD értéke magas lesz a HSync alatt. Ez esetben pedig rendben fekete lesz a keret, mivel az utolsó pixelek és a SER láb is 0.

Ha jól gondolom, a C501 és R508 együtt egy késleltetést tesz az U512a 8-as kimenetére. Talán azért, hogy az utolsó kikerülő 6 pixelnek legyen ideje kijutni? Ebben nem vagyok biztos.

De így, hogy 224 helyett 221-es kondenzátort tettem bele, eltűnt a kerethiba, és rendben megjelenik a képterület. Igaz, a karaktereim még kuszák, de ezzel most megpróbálok megküzdeni, itt még lehet, hogy a kondicsere alatt valamit elbarmoltam.

Az valóban logikus lenne, ha aktív blank (nem sync!) esetén a LD jel 1 lenne, viszont szerintem nem így van:

U511a-U511b egy huzalozott nem-vagy kapu, azaz ha R5 vagy R14 == 1, akkor U512a 9-es bemenetét 0-ra húzza, ebből az következik, hogy blank esetén U512a 8-as kimenete 1 lesz.

Ezt csak késlelteti a C501 feltöltése, de nem állítja le, azaz U513a is magas lesz, és magas S0-nál LD 0-ra megy (tehát aktív területen kívül folyamatosan töltődik a shift regiszter).

És hogy miért kell késleltetni az U511a 5-ös bemenetén a jelet? Fentebb volt a tipp, hogy azért, hogy a LD jel szélességét beállítsuk, de igazából mind a 0-ba, mind az 1-be váltást késlelteti, úgyhogy nem hiszem.

Amit még el tudok képzelni, hogy a RAM/ROM adatvezetékeinek beállását kell "megvárni" a LD jelnek, miután a címvezetékek módosultak.

Én meg arra gondoltam, hogy U512a 8-as lába ugyan magasba megy, de - a kapacitás méretéhez képest - elég hosszú ideig magasan marad, így az R508-on keresztül a C501 másik fegyverzete teljesen negatívba mehet, azaz szerintem a váltás után egy kis idővel az U513a 5-ös lába alacsony lesz, emiatt lesz a LOAD jel magas. Ezt erősíti meg az is, hogy amíg 220pF helyett 220nF volt a C501 értéke, addig ez az idő sokkal hosszabb lehetett, így a HSync alatt is alacsonyan maradhatott a LOAD, ezért látszottak fixen az első bitek. Most, hogy megfelelő mérető a kondenzátor, már nem látszanak. De megnéztem szkóppal is, és folyamatosan magas jelet látok, abból ugrálnak le tüskék.

Kivettem az U507-es shift regisztert, meg az U511-es IC-t, így a két foglalatban könnyen tudtam mérni. Ha az 512a 9-es lábára, vagyis a kivett 511a 3-as lábára GND-t kötök, akkor a mezei mérőműszer a U507 1-es lábán 3.6V-ot mér.

Amúgy elgondolkoztam azon, amit a késleltetés okáról mondtál, és kezd összeállni a kép.

1 - Amíg 220pF helyett 220nF volt a C501 értéke, a keret rossz volt, de a karakterek szépek.

2 - Most, hogy 220pF a C501 értéke, a keret rendben van, de a karakterek kaotikusak, néha teljesen eltűnnek.

A teszteléshez a 6116-os RAM helyett 28C16-os EEPROM-ot használok. Fel sem merült bennem, hogy egy ilyen mai IC lassabb lehetne, mint egy 40 éves. De úgy tűnik, mégis ez a helyzet.

Az R508 helyére betettem egy potmétert, így tudom növelni a késleltetés értékét. És lőn! Ha megnövelem annyira, hogy kb. egy karakternyi szemét megjelenik a jobboldali keretben, akkor a karakterek ismét szép éles kontúrral jelennek meg.

Tehát - úgy tűnik - lassú a 28C16, nem helyettesíthető vele a 6116.

Ha az 512a 9-es lábára, vagyis a kivett 511a 3-as lábára GND-t kötök, akkor a mezei mérőműszer a U507 1-es lábán 3.6V-ot mér.

Úgy, hogy az S0 is 1? Vajon U513 5-ös lába ilyenkor mi?

 

Egy random 6116 datasheetjéből: — Commercial: 15/20/25/35/45ns (max.)

Szóval ez még 40 év távlatából is köröket verhet egy EEPROM-ra.

Az S0 fixen 5V.

Megmértem szkóppal is, hátha pontosabb. 5V-os egységnél 3.6V-ot mutat, 1V-os egységnél már csak 3.3V-ot.

Rámértem az U513 5-ös lábára: 0.6V

Az AI 100/150us-ot mondott a 6116-os sebességére, nem néztem rá az eredeti adatlapra, mivel már az is gyorsabb, mint az EEPROM. A következő tesztelési lehetőség akkor már csak akkor lesz, ha a CPU és a RAM is bekerül. :(

( kleinie | 2025. 03. 12., sze – 08:37 )

A jelenlegi kapcsolásról tudnál feltenni egy kapcsolási rajzot? Akár egy kézi skiccet.

Ezt a kapcsolást próbálom megépíteni. (A kép letöltve nagyítható, bár úgysem a legjobb minőség.) Jelenleg már csak az U504 nincs benne. Itt van az alkatrészlista. Készül KiCAD-ben egy jobb minőségű új változat, ahol már az ellenállások, kondenzátorok értéke is szerepelni fog, ha kell, ezt is fel tudom tölteni.