Miniaturowy moduł TV Composite Out z pamięcią ekranu i interfejsem in/out

Tue Nov 20, 2007 2:52 pm   

"J.F." <jfox_xnospamx@poczta.onet.pl> wrote in message
news:3cn5k3pij5a2q06ucflpp7oga9aofun0se@4ax.com...


widac slabo ;)



no bo nikt nie wykorzystywal sprzetu


bo firmy najmniejszym oporem konwertowaly gry - Atari mial wyjatkowy
sytem graficzny, wlascwie powtorzony pozniej tylko w Amidze


jak mowie - z banglaniem po rejestrach mzona bylo wycisnac z tego duzo
wiecej - tylko nikt tego nie robil - masowka


hehe, wychodzi troche niewykorzystanie potencjalu hardware - obwiednia
tej samej klasy lub nawet lepszej co w AY mogla byc uzyskana programowo,
Atari mogl miec kilka kanalow samplowych, tylko ze to trzeba
zaprogramowac, male Atari to system ktory wyprzedzal swoja epoke...



winna temu jest prosta konwersja gier miedzy platformami - dla Atari
trzeba byloby tworzyc praktycznie od nowa cala gre


rejestr glosnosci kanalu, mozna bylo po prostu dokladnie tak samo jak w
C64 odtwarzac sample z tym ze C64 mial jeden regulator a Atari 4



winne temu jest zastosowanie durnej modulacji ktora zupelnie nie nadaje
sie do transmisji danych cyfrowych - bazujac na hardware kompa mozna bez
klopotu zrobic procedury podobne do chyba najlepszych uzywanych w C64


nie, bit mogl byc czytany bo przeciez transmisja z magnetofonu wlasnie
tak byla robiona (PLL dekodowala FSK i wystawiala 1,0) - problemem bylo
tu raczej rozdwojenie jazni i brak decyzji o nie wspieraniu starego
systemu zapisu

Tue Nov 20, 2007 3:32 pm   

"PAndy" <pandrw_cutthis_@poczta.onet.pl> wrote in message
news:fhumsu$82r$1@news.onet.pl...

współczynników, nazw, menu wyboru itd.) ze złożonego układu pomiarowego.
Docelowo ma to pokazywać także jakieś uproszczone charakterystyki/wykresy,
stąd potrzebna (semi)grafika. Nie chcę tego robić na wielu displejach
LCD2x16. Można by to zrobić na nowoczesnych ekranach TFT/LCD
kikaset/na/kilkaset pixeli, ale akurat mam do wykorzystania kilka starych
monitorów TV z demobilu - tak wyjdzie taniej, a wcale nie musi być małe.

Roman

Tue Nov 20, 2007 3:48 pm   

On Tue, 20 Nov 2007 14:16:38 +0100, PAndy wrote:

Nie ujawniaja. No dobra, nie wytrzymam i opisze dla potomnych,
bo ciekawe :-)

Zacznijmy od samego procesora. Z80 pobieral rozkaz wystawiajac
na magistrale adres, linie sterujace, i dodatkowo sygnal M1.
Po dwoch cyklach przystepowal do wykonania instrukcji, a jednoczesnie
zaczynal sie cykl odswiezania dynamicznych pamieci zewnetrznej
[ktorej w ZX80 nie zastosowano].
Na magistrale adresow wystawiano rejestr I na starszy bajt,
i rejestr R na mlodszy bajt. Rej I byl dowolnie ustawiany programowo i
bez znaczenia dla procesora, R zwiekszal sie automatycznie
co kazdy wykonany rozkaz. Co tez trwalo dwa takty, po czym
pobierano kolejny rozkaz lub realizowano biezacy, ktory mogl
miec kilka dalszych operacji magistralowych.

Architektura ZX80: wyswietlanie pracowalo w trybie znakowym,
przewidziano 64 znaki zdefiniowane w ROM, dodatkowo bit7
robil za inwers. Wyswietlano zawartosc pamieci RAM, linie do
wyswietlania byly zmiennej dlugosci [wazne, gdy pelen ekran ma 768
bajtow, a RAMu jest 1KB ], koniec linii zaznaczano specjalnym
kodem.

Teraz trzeba spojrzec na schemat na powyzszej stronie.
Procesor byl przylaczony do magistrali danych przez rezystory
[R4-R11]. Rozpoczynajac wyswietlanie procesor "skakal" do adresu
pierwszego znaku w linii plus 32K.
Dekoder adresow byl niepelny, wiec odczytywalo to RAM w dolnej
polowce, ale bramki [13,16,17,15] wykrywaly fakt pobrania rozkazu spod
wysokiego adresu [A15=1] i jesli bit6 danych wynosil 0, to wymuszaly
[przez bramki 14 i 15] niski stan na pinach danych uP.

uP odczytywal wiec kod rozkazu 00, czyli NOP, i po 4 cyklach
odczytywal nastepny rozkaz, ktory tez byl zerowany do NOP, itd.

Jesli jednak napotkal na znak konca linii, ktory mial bit6=1,
to byl przepuszczany do uP .. i okazywal sie byc rozkazem HALT,
zatrzymujacym procesor

Z uspienia wyrywalo go przerwanie, na tym schemacie tego nie widac,
ale INT byl podlaczony prosto do nogi A6. Otoz wejscie INT bylo
testowane przez Z80 pod koniec cyklu rozkazowego, akurat wtedy
gdy na magistrali pojawial sie rejestr R. Stopniowo narastajacy,
[takze w trybie halt] wiec co 64 rozkazy [64us - linia obrazu]
procesor sie budzil, program zerowal rejestr R i znow skakal na
poczatek linii do wyswietlenia+32KB - tak 8 razy na kazda linie znaku,
po czym przechodzil o 1 bajt dalej i obrabial nastepna linie.

A gdzie wyswietlanie ? W czasie gdy procesor czytal 00, wlasciwa
dana byla zatrzaskiwana w rejestrze [IC5 - to pewnie 373 albo 374].
W fazie odswiezania przestawiano multipleksery adresow dla ROM
[IC 6,7,8 - 157 bodajze] i podawano nan od LSB:

-3 bity z licznika linii IC21
-6 bitow zatrzasniete z rejestru
-reszta danych z procesora .. czyli rejestr I.

Rej. I wskazywal na poczatek obszaru generatora znakow w ROM,
wiec teraz wystarczy wpisac dane do rejestru przesuwajacego IC9.
Ten juz wypusci po bicie dane video, jeszcze tylko inwersja
w bramce xor przez odpowiednio opozniony bit d7.

Jeszcze pare licznikow do pelni synchronizacji - i jak widac jest to
nieco bardziej skomplikowane niz tylko "jeden 165".
Procesorki w owych czasach nie dalyby rady zrobic tego programowo,
tu jak widac wykorzystano ich licznik rozkazow do adresowania pamieci
video.

W ZX81 scalono te wszystkie drobne TTL w jeden uklad.

J.

Tue Nov 20, 2007 4:02 pm   

"J.F." <jfox_xnospamx@poczta.onet.pl> wrote in message
news:gip5k39onqpkrd5bh7epshmoqrk9nf1u5h@4ax.com...


wykorzystano niewykorzystywany (brak DRAM) licznik R - z punktu widzenia
dodatkowych ukladow video obsluguje 74165, w programowych zrodlach video
na uC wszystko wlacznie z zamiana danych z postaci rownoleglej na
szerogowa robione jest programowo.


SCL, dodano NMI, wydzielono klawiature czyli kosmetyka.

Tue Nov 20, 2007 4:06 pm   

"Roman" <romantek@poczta.onet.pl> wrote in message
news:fhuqqf$m4l$1@news.onet.pl...



IMO AVR + kilka 74xxx i np 32 - 128KB SRAM i uzyskasz to co chcesz bez
wiekszego klopotu.

Tue Nov 20, 2007 4:31 pm   

"Jarosław Sokołowski" <jaros@lasek.waw.pl> wrote in message
news:slrnfk5u24.dpc.jaros@falcon.lasek.waw.pl...


IMO to wystarczy plyta np Amigi 600 i tez bedzie to ladnie chodzic...
poza tym mozna uzyc jakiejs taniej plyty na i810 czy innym z
zintegrowana VGA, za ok 250zl da sie zrobic modul wyswietlania o
niemalych mozliwosciach...

Tue Nov 20, 2007 4:42 pm   

Pan Roman napisał:


To czemu nie użyć również starego peceta z demobilu w całości? Koszt
zerowy. Jeśli nawet mają to być monitory TV a nie VGA, to wystarczy
programowa zmiana częstotliwości karty i prosty kabelek do połączenia.
Poprzednio w założeniach było "Chodzi o układ możliwie miniaturowy".

--
Jarek

Tue Nov 20, 2007 4:42 pm   

PAndy napisał:


Rzecz w tym, że płyty do Amigi 600 to ja w życiu na oczy nie widziałem,
a starych pecetów, z którymi nie wiadomo co zrobić, poniewiera się
wszędzie pełno.


250zł w porównaniu z zerem, to już niezły pieniądz. Ale jak już
płacić za płytę PC do takich rzeczy, to chyba najlepiej jakiś
mini-itx. Brak wiatraka, pobór mocy na posiomie kilkunastu watów.

--
Jarek

Tue Nov 20, 2007 5:07 pm   

Użytkownik "Dariusz Zolna":

To jest dobre
http://ekranownia.atari8.info/grafika/ekrany/gry/h/hans_kloss_1.png

Heliogabal

Tue Nov 20, 2007 5:55 pm   

"Jarosław Sokołowski" <jaros@lasek.waw.pl> wrote in message
news:slrnfk5vsi.e0u.jaros@falcon.lasek.waw.pl...


allegro i kilkadziesiat zl (za tyle to moze nawet plyte A1200 da sie
kupic)


zero to bedzie szafa... a za 250zl cos wielkosci miniATX i z poborem
mocy rzedu 50 - 60W

Tue Nov 20, 2007 7:11 pm   

Ale po wlaczeniu rozdzielczosci wiekszej niz 320 punktów w pionie (40 znaków po 8 pikseli) pojawialy sie interferencje (PAL ?)

Tue Nov 20, 2007 7:13 pm   

On Tue, 20 Nov 2007 16:02:37 +0100, PAndy wrote:

On zastewpuje tylko jeden licznik do 64.
Naprawde wykorzystano PC do adresacji pamieci.


Ukladow potrzebnych do takiego wyswietlania jest tu kilka -
opisalem je.


Owszem, tylko ze tu jak widac mamy zegar pikslowy 8MHz.
Trzeba by uC ze 32Mips zeby to zrobic programowo - a rozdzielczosc
jest tylko 256 [32 znaki] + marginesy.
Dodajac rejestr przesuwny wymagania spadaja, ale tez trzeba szybko.

Naprawde polecam cos scalonego lub CPLD/FPGA.

J.

Tue Nov 20, 2007 7:53 pm   

On Tue, 20 Nov 2007 14:52:24 +0100, PAndy wrote:

Kiedy wiecej bylo.. albo wsciekle wielkie piksele, albo brak[nadmiar]
kolorkow.


Nie mowie, do paru gier ten tekstowy tryb swietnie pasowal.

Ale w ogolnosci kiepskie mozliwosci graficzne.


Ale to obciaza procesor.


To wlasnie pisalem. Pomysly byly ciekawe, tylko trzeba bylo je zrobic
2x lepiej, i moze poczekac z rok zeby nie kosztowaly za duzo.
I wyszlaby .. amiga :-)


O ile pamietam to jednak uzywano rejestr szeregowy, ale faktycznie
byla poczatkowa synchronizacja programowa.

Jesli mnie jednak skleroza nie myli, to ten kabelek byl, bo czegos
brakowalo. I tak ze wszystkim w atarynce bylo - fajne, ale nie fo
konca .

J.

Tue Nov 20, 2007 8:09 pm   

Dnia 2007-11-20 19:53, Użytkownik J.F. napisał :

raczej pomysłu jak to dobrze zrobić - Turbo 2000 obywało się bez
dodatkowych kabelków.

Pozdr.
Michał

Tue Nov 20, 2007 9:26 pm   

Użytkownik "Jarosław Sokołowski" <jaros@lasek.waw.pl> napisał w wiadomości
news:slrnfk5u24.dpc.jaros@falcon.lasek.waw.pl...


Nie no, aż takiego kloca nie chcę angażować do tego układu.



Chodziło o miniaturyzację fragmentu: "moduł CRT video out "!.
Aby ta część projektu nie stała się większa i bardziej rozbudowana niż
właściwy układ pomiarowy, w sumie urządzenie ma być niezbyt duże.
Od urządzenia pójdzie kabelek koncentryczny 75Ohm do stojącego nieopodal
monitorka 8", razem będzie to dość ergonomicznie !

Roman