forum speccy.pl
Komputery z Z80 => TIMEX => Wątek zaczęty przez: pawelb w 2022.11.25, 22:44:30
-
Cześć,
W timexach jest główny układ TS2068. Potrafi on sterować PSG AY-8910 ale jego porty nie są takie jak dla Spectrum 128k.
W teorii, dla standardowych sygnałów sterujących BC1 i BDIR trzeba wykonać dekoder adresu (np tak jak w KAY) by działały dema lub gry bez przeróbek programistycznych.
Czy jeżeli TS2068 steruje też tymi liniami np jak w Timmy to muszę miksować ten sygnały za pomocą bramek OR czy mogę tylko połączyć fizycznie
sygnały z TS2068 i z dekodera adresu dla portów 128k ?
Pozdrawiam,
Paweł
-
Właściwe pytanie brzmi raczej ile gier czy programów stosuje adresowanie układu AY na portach Timex'a ? ;)
Bo nie wiadomo czy warto bawić się w podwójne adresowanie układu dźwiękowego jeśli dotyczy to tylko kilku programów lub żadnego...
-
Timexy mają wbudowany dekoder adresów dla PSG w SCLD, z którego wychodzą sygnały sterujące BDIR i BC1. Rodziny TS i TC korzystają z tych samych portów.
Pamiętaj, że w Timmy z oryginalnym SCLD zagra tylko na portach Timexa. Zamiennik SCLD jest bardziej uniwersalny i fabrycznie ustawiony jest, aby grał na portach 128K. Jest w nim możliwość przejścia na porty Timexowe przez zwacie jednego pola do masy.
Jeśli chciałbyś dodać dekoder wewnętrzny do TS/TC z oryginalnym SCLD, to należałoby sygnały z obu dekoderów połączyć, tak jak napisałeś, przez bramki OR lub moim zadniem przez XOR. Co prawda najprostszym rozwiązaniem byłyby diody i rezystory szeregowo w tych liniach.
-
Dzięki za odpowiedź.
Celem podstawowym jest :
- Niech zagra AY bez przerobienia programów na standardowych portach jak w ZX Spectrum 128k
Celem drugorzędnym jest:
- Niech zagra AY dla kazdego programu nawet jak adresuje porty dla TS2068.
Sprawa rozwojowa do wykonania w przerwie świątecznej.
-
Aha, jeszcze jedna mała uwaga do dekodera adresów PSG na portach 128K. Jeśli chciałbyś nadal korzystać z Timexowego MMU (port 0xF4), należałoby rozszerzyć dekoder o linię adresową A3.
-
Zrobiłem dekoder taki jak KAY no i działa ale mam problemy z podłączeniem.
Prototyp na Bredboardzie działa ale jest on za duży do obudowy więc chciałem to płytce proto zrobić no i poległem.
Przewody nie chciały się "przykleić" podczas lutowania i co chwila się urywały. Dodatkowo miałem dylemat z sygnałem IORQ:
Który sygnał wybrać bo w/g dokumentacji joy jest podłączony przez IORQGE a KAY jest IORQGE.
Po testach wyszło że lepiej IORQ ale nie jestem pewien przekonany co lepsze.
Ostatnim problemem jest samo podłączenie 6-sciu sygnałów sterujących. Początkowo założyłem że wepnę się w miejsca po kołkach wokół SCLD i to działa ale czy to dobre podejście?
-
Zrobiłem dekoder taki jak KAY no i działa ale mam problemy z podłączeniem.
…
Gratulacje.
/IORQGE na złączu krawędziowym jest wejściem do komputera i SCLD/ULA. Służy ono do przejęcia kontroli nad portem 0xFE. Osobiście użyłbym /IORQ z Z80.
Ostatnim problemem jest samo podłączenie 6-sciu sygnałów sterujących.
Co to za sygnały?
-
Sygnały użyte w interfejsie KAY:
A14
A15
IOREQ
WR
RD
(http://dekoder_adresu.png)
-
Ja zrobiłem kiedyś płyteczkę na wymiar miejsca poniżej AY, 4 cm bodajże tam jest - nie chcę już swojego rozkręcać po moich bojach z Multiply. Tyle że ten dekoder jest tak ubogi, że może on powodować konflikty kiedy za jakiś czas zechcesz coś jeszcze podpiąć.Na przykład:
Po tym układzie, którego schemat podałeś, przyszło mi do głowy dopięcie dekodera rejestru banków pamięci i znów dekodowanie portów które jest... zbliżone do AY.
W efekcie skończyło się na dwóch dekoderach 74HCT138, choć i to nie jest idealne rozwiązanie bo istnieje potencjał do konfliktu na przykład z Dananatorem (niechlujnie dekodowany port Kempston). Ostatnio myślałem nawet nad 74HCT688 i dekodowaniem AY, RAM-bank ,Kempston, + cośtam jeszcze - takie combo
Układ który zrobiłeś oczywiście się nada, jeśli nie planujesz żadnych dodatkowych rozszerzeń.
-
To może trzeba jakiegoś GAL'a zastosować i będzie OK!
-
GAL-e to już zabytki.
Lepiej przejść z TTL-ami na SMD.
-
Wszak my operujemy już w domenie zabytkowej, a te jeszcze są jakoś dostępne :P
-
Kiedyś nie miałem możliwości programowania GALi, dziś pewnie właśnie bym to zrobił, bo to rozwiązanie oszczędza miejsce którego w tych sprzętach nie mamy dużo. W końcu dziś na samych TTLach mało co się robi, teraz wszędzie ludzie wciskają avr, pic, CPLD itp. Dziś podjęcie się projektowania na przykład zamiennika ULA, czy TIMEX SCLD na układach TTL zakrawa na szaleństwo, choć Harlequin jest jedynym chyba wyjątkiem.
-
Info: Schemat dekodera to fragment większej całości tzn interfejs KAY by Spider :D.
Mam GAL który nie sprawdził się w ZX128 Replica możliwe że tu się sprawdzi.
Nie umiem go programować i w ramach samorozwoju nauczę się jak to zrobić
ale gdyby ktoś z Was miał chwilę i zrobił wsad dla GAL16V8 na podstawie tego decodera to by ułatwiło mi pracę.
Dziękuję z góry za wszelką pomoc i sugestie.
-
Rozumiem, że chcesz się nauczyć czegoś nowego, ale moim zdaniem brnięcie w GALe to ślepa uliczka, skoro są dostępne małe CPLD na 5 V lub tolerujące logikę 5 V. Są narzędzia co pozwalają opisać równania GALi w Verilogu czy VHDL, ale jakoś mnie nie przekonały.
Uważam, że integracja 2-3 podstawowych układów logicznych za 2-3 zł każdy w archaicznym układzie za większe pieniądze, jest ekonomicznie nieuzasadniona i w sumie nic nie zyskujemy.
-
Chyba że komuś się taki układ kisi w szufladzie i posiada już do tego jakiś tani programator np TL866. ;)
-
Należałoby odpowiedzieć sobie na pytanie: Jak bardzo chcę być na czasie z "nową" wiedzą? Bo GAL-e to nie nowość, tak jak i Spectruś. CPLD są ...drogie, ceny zaczynają się od ok. 15zł, GAL-e kupowałem nie tak dawno po 7 czy 8zł. Dla mnie znaczenie ma też czy układ jest DIP THT czy nie. Odpowiedź druga raczej z marszu go eliminuje - bo jestem amatorem który sobie coś tam struga, mam dwie nieskomplikowane lutownice i to wszystko, bo robię coś w elektronice rzadko i sporadycznie. Płytkę robię sam - stąd dla mnie upierdliwe i mało zabawne jest dłubanie się z smd. Traktuję to jako zabawę a nie sposób na życie.To tyle jeśli chodzi o mój punkt widzenia - człowieka starego i zgorzkniałego.
Kolego pawelb, jak Tobie wygodnie, jaki sprzęt i umiejętności posiadasz? ile chcesz przeznaczyć? - to już pytania na które sam sobie najlepiej odpowiesz. Jeśli chcesz się "wkręcić" w CPLD - bo to trochę nowsze i może kiedyś temat poszerzać, masz sprzęt, cierpliwość - to jak najbardziej.
Mój mistrz, od którego uczyłem się elektroniki jako dzieciak, zwykł mawiać - Do prostych rzeczy używajmy prostych rozwiązań.
Aż pewnego dnia zaczęło się powszechne tworzenie "brzęczyków" na mikrokontrolerach.
-
Czasami proste rozwiązania nie należą do najtańszych.
-
Zgadzam się.
W tym konkretnym przypadku sprawę może załatwić jeden układ scalony na kawałeczku płytki - na przykład GAL za 7zł.
Można też użyć układu z obrazka, ale jak pisałem wcześniej wówczas istnieją porty na których byłby konflikt, tyle że w teorii nie powinny one być przez nic wywoływane - trzeba liczyć na rzetelnych programistów :D
-
W tym przypadku cenowo wyjdzie chyba podobnie albo i taniej, licząc średnio TTL za 2,5zł ;)
A jeśli zajdzie potrzeba zmiany sposobu adresowania wystarczy tylko przeprogramować GAL'ca bez potrzeby lutowania.
Naprawdę archaicznym sposobem realizacji tego układu było by pewnie zastosowanie tam pamięci PROM, jakie są programowane tylko jednokrotnie a zdobycie tych elementów (niezaprogramowanych) często graniczy z cudem :P
-
Ahh pamięć jako dekoder? Kiedyś próbowałem - poniosłem porażkę, pamięć okazała się za wolna (czasy propagacji) ponieważ był to stary EPROM. Jakieś 300ns i strasznie siało po szynie zakłóceniami. Dla przykładu 74LS138 około 40ns a HCT połowę mniej, a GAL jeszcze mniej.
-
Jak ktoś chce rozpocząć zabawę z GAL-ami, to do tego celu (i nie tylko, bo ten program potrafi dużo więcej) polecam Digital (https://github.com/hneemann/Digital).
Na marginesie sam język PLD jest na tyle prosty, że zbudowanie dekodera adresów to naprawdę jest trywialna rzecz, trzeba się tylko przełamać.
-
Fajne narzędzie tak na pierwszy rzut oka. Trochę mnie odrzuca fakt, że ktoś coś takiego stworzył w języku Java, który do szybkich i wydajnych nie należy, i ma swoje wady:
- charakterystyczny lag w gui
- brak zapamiętywania ostatniej ścieżki OPEN - dobrze że jest chociaż open recent
- brak instalatora (co pewnie powoduje powyższy problem)
Odnośnie GAL-i to nic tam w nim nie znalazłem, rzecz w tym aby dało się wczytać plik PLD i go zasymulować a takiej opcji tam nie ma, ale może coś przeoczyłem. Fajnie by było bo
poczciwy WinCupl już nie działa prawidłowo na nowszych systemach. Z całego pakietu tylko katalog shared jest przydatny bo tam siedzi cupl.exe (kompilator) i systemowy notatnik do stworzenia pliku PLD. Natomiast symulacja... na płytce prototypowej z LED-ami.
Może i szybki być nie musi, nie symuluje układu w locie tylko sekwencyjnie z tego co zauważyłem.
Wygląda na rozwijany, zatem wart zainteresowania.
Genialne byłoby gdyby dało się emulować szynę zxspectrum i projektować w programie do niej interface patrząc co się dzieje z sygnałami.... ot taka sobie myśl.
Do tej pory używam Digital Works-a (https://www.mecanique.co.uk/shop/index.php?route=product/category&path=89), trochę leciwy soft ale wciąż daje radę.
-
Ahh pamięć jako dekoder? Kiedyś próbowałem - poniosłem porażkę, pamięć okazała się za wolna (czasy propagacji) ponieważ był to stary EPROM. Jakieś 300ns i strasznie siało po szynie zakłóceniami. Dla przykładu 74LS138 około 40ns a HCT połowę mniej, a GAL jeszcze mniej.
Tylko że układy PROM zwykle mają czasy dostępu na poziomie 20ns i w dawnych czasach przed erą układów PAL/GAL były często stosowane do dekodowania adresów.
Obecnie trudno je kupić oraz zaprogramować, bo większość tańszych współczesnych programatorów już ich nie obsługuje.
-
Tylko że układy PROM zwykle mają czasy dostępu na poziomie 20ns i w dawnych czasach przed erą układów PAL/GAL były często stosowane do dekodowania adresów.
No, powiedzmy, że nie zawsze. Małe (takie do 1 kbit) PROM-y mogą mieć faktycznie czasy dostępu (piszę: dostępu, bo to pamięć) nawet 30 ns, ale większe kostki będą już miały ten czas rzędu 50-100 ns (ale do dekodowania adresów takie duże są raczej bez sensu).
Lepszym wyborem, pozostającym w tej samej puli technologicznej lat 70., są układy PLA, działające szybciej od PROM, bo pozbawione zbędnych bloków logicznych charakterystycznych dla pamięci: dekodera linii adresowych (zamiana kombinacji wejściowej na "1 z n"), multiplekserów wyjściowych (wybierających np. 4 bity danych z całego rządka matrycy) oraz bufora wyjściowego.
Z kolei PLA to praktycznie "czysta" matryca, udekorowana bramkami OR i AND i czasami też przerzutnikami na wyjściach - niemal identycznie, jak jest to realizowane w PAL/GAL. Stąd reakcja wyjść na stany wejść może być znacznie szybsza niż w przypadku pamięci.
Ale nie ukrywajmy - do zastosowań z sygnałami zegarowymi procesorów rzędu kilku MHz nie ma znaczenia, czy logika dekodera adresów (czy to pamięci, czy I/O, jak np. w przypadku AY) będzie "zjadać" 20, 30 czy 50 nanosekund. CPU i tak oczekuje na dane nie wcześniej, niż po pełnym cyklu zegara, czyli po około 280 nanosekundach w przypadku ZX Spectrum.
Oczywiście w takim przypadku stary EPROM całkowicie odpada.
No i sam jednak preferuję GAL-e od PROM/PLA/PAL: fajnie jest mieć możliwość skorygowania błędów w projekcie bez wyrzucania kości do śmieci.
Obecnie trudno je kupić oraz zaprogramować, bo większość tańszych współczesnych programatorów już ich nie obsługuje.
Fakt trudno kupić stare układy, ale czasami zdarzają się jakieś okazje :)
Co do programowania - no, tego nie rozumiem tak do końca: jeśli ktoś podejmuje się zaprojektowania, albo choćby zmontowania cyfrowego układu elektronicznego, poradzi sobie z budową prostego programatora wykorzystującego port drukarki. Soft do tego jest, choć głównie pod DOS lub linuksy.
Oczywiście, że współczesne komputery nie mają już gniazda LPT, ale to też żadne wytłumaczenie - przecież sami grzebiemy w znacznie starszych komputerach, niż 386/486/Pentium :) Choćby stary laptop wystarczy do tego celu.
-
Myślę że przedmówcom nie chodziło o to, że się nie da.
Możliwości jeszcze są. I faktycznie gal od dłuższego czasu był najprostsza/najwygodniejszą drogą. Ale te możliwości teraz zaczęły szybko topnieć.
Parę lat temu bez problemu można było kupić niedrogo wd1772, a teraz. Przypadek? Nie sądzę ;)
Pytanie podstawowe więc: jaka droga będzie najprostsza/najwygodniejsza przez przyszłe 10 lat? Tak na żeby poświęcony czas zaprocentował frajdą, a nie frustracją :)
-
Aby nie odchodzić od tematu. W bezsenną zimową noc różne rzeczy chodzą po głowie i takie coś się urodziło jak poniżej.
Układ dekoduje sygnały AY jak w ZX128 (#BFFD, #FFFD), dodatkowo jest zatrzask banków pamięci(#7FFD) z wyłączaniem na bicie 5 (jak w 128) oraz coś, co nazywam Uniwersalną Magistralą Wejścia-Wyjścia. Do tej magistrali podłączałem kiedyś różne ustrojstwa choć jej układ wyglądał inaczej (bez GAL-a). Można tam bezpośrednio podpiąć UART, interfejs SimpleHDD, i co przyjdzie do głowy. W tej wersji GAL dekoduje porty od #20 do #27 aby nie kolidował z Kempstonem w Dandanatorze i/lub wbudowanym, choć ten układ nie był przewidziany pod TC2048 tylko pod moje poczciwe TC2068 gdzie Kempstona nie przewidzieli. Do tego płytka o wymiarach 35x100 która wchodzi tuż pod płytą na środku (TC2068).
Wsad do GAL-a załączam też z jakąś płytką w kikadzie.
Wybaczcie amatorskie błędy i nie żałujcie słów krytyki.
-
Obecnie trudno je kupić oraz zaprogramować, bo większość tańszych współczesnych programatorów już ich nie obsługuje.
Fakt trudno kupić stare układy, ale czasami zdarzają się jakieś okazje :)
Co do programowania - no, tego nie rozumiem tak do końca: jeśli ktoś podejmuje się zaprojektowania, albo choćby zmontowania cyfrowego układu elektronicznego, poradzi sobie z budową prostego programatora wykorzystującego port drukarki. Soft do tego jest, choć głównie pod DOS lub linuksy.
Oczywiście, że współczesne komputery nie mają już gniazda LPT, ale to też żadne wytłumaczenie - przecież sami grzebiemy w znacznie starszych komputerach, niż 386/486/Pentium :) Choćby stary laptop wystarczy do tego celu.
Trudo nie znaczy że nie jest to możliwe, ale mało opłacalne w nowych projektach, chyba że w grę wchodzi jakaś wierna replika lub naprawa oryginału.
A okazja zakupu owszem, ale często też trafia się na jakieś zaprogramowane używki. :P
Specjalnie budować programator ? Eee, bez sensu dla jednego czy 2 układów PROM...
BTW, Ja akuram mam stosowny sprzęt i resztkowe zapasy takich układów, ale wiele osób nie posiada i im właśnie nie polecam brnięcia tą drogą :)
-
Oj tam, ale GAL jest z duchem tamtych czasów i pasuje do tych sprzętów :D
Xilinx do tego pasuje jak koła od bentleya prosto z fabryki do wozu konnego. :P
-
No ale CPLD to też lata osiemdziesiąte :)
Jednak zgoda, że nie były powszechnie stosowane w ówczesnych komputerach domowych. Pewnie jeszcze zbyt drogie były, no i bez sensu dokładać do interesu, by użytkownik mógł sobie coś przeprogramowywać (układy OTP z pewnością wychodziły taniej).
Poza tym, jak by nie patrzeć, już w toastracku widzimy PAL (często wymieniany na GAL) jako dekoder adresów I/O :)
-
Z tego schematu który wcześniej zamieściłem GAL nie chce działać - nie bierze sygnału /WR. Wszystkie dekodowane IN działają tylko OUT-y nie chcą. Nie wiem czy coś sknociłem przy pisaniu czy może kostka wadliwa. Jest jeszcze kwestia trybów pracy GAL-a i może tu tkwi problem. Dokumentacja jest niezbyt przejrzyście napisana jak dla mnie... Układ na podstawce się nie mieścił więc oczekuję na motywację do odsysacza.
-
Programator TL866II trzeba podnieść napięcie do 16,50V (GAL 20V8B), na 16V część funkcji się programuje ,część nie. Funkcja weryfikacji w sofcie od tego programatora to chyba wolne żarty bo niby ok. Cupl z pakietu Wincupl źle sobie radzi z "!" przy definicji pinów, w generowanym pliku symulacji zmienia logikę bramek (podwójna negacja zamiast pojedynczej), nie wiem czy tylko plik symulacji zostaje w ten sposób zepsuty, podejrzewam że docelowy .jed też.
-
A może ten GAL jest lekko trzepnięty ? ;)
Albo ma ubite jakieś wejścia, miałem kiedyś podobny przypadek, że niby się programowało ale nie działało poprawnie i po wymianie scalaka było jakoś lepiej.
-
Testowałem na innych 2 sztukach. Jak odessam pobawię się też. Gdzieś się spotkałem z !nazwa przy definicji pinów w plikach .pld ale jak dla mnie to się kupy nie trzyma. Bo nazwa to etykieta.
-
To może zmień definicje sygnałów na inne końcówki układu.
-
To może zmień definicje sygnałów na inne końcówki układu.
Wywaliłem "!" i zmieniłem równania aby to uwzględnić, i działa jak powinno, ale musiałem też podnieść napięcie - ryzykowna taktyka ,ale kiedyś przy EPROMach miałem podobnie więc trochę na czuja.
-
Mam akurat starszą wersję tego programatora TL866A i ona działa nieco pewniej, bo wersja II ma nieco zaniżone napięcia programujące dla niektórych układów.
-
To by wiele wyjaśniało. Mam taki egzemplarz najwyraźniej. Co do tych etykiet z "!" nie jestem pewien , ponieważ zmieniłem etykiety i zrobiłem zapis na 16,50v, nie rozdzielałem tych czynności. Tylko zastanowiły mnie błędne działania wygenerowane w pliku .sim.