forum speccy.pl
Komputery z Z80 => TIMEX => Wątek zaczęty przez: PROTON w 2017.03.06, 15:03:05
-
W ramach ćwiczeń, planuję zrobić terminal do stacji dysków FDD3000.
Coś w rodzaju TT3000 z wyjściem VGA 1024x768 i ze złączem USB do podpięcia klawiatury PC i złączem do stacji.
Komunikacja ze stacją odbywa się za pośrednictwem 12 przewodów (6 wejściowych i 6 wyjściowych), tu nie przewiduję problemu. Problem mam taki, że nie mam opisu komunikacji, jakie komendy są wysyłane i odbierane. Czy ktoś z was ma taki opis?
Może trzeba dezassemblować kod TT3000? A może łatwiej będzie dezassemblować CP/M-a?
-
Można zacząć od kodu, który znajduje się w interfejsie M-397.
Najwięcej na ten temat wie trojacek.
-
Coś w rodzaju TT3000 z wyjściem VGA 1024x768 i ze złączem USB do podpięcia klawiatury PC i złączem do stacji.
A jaki masz pomysł na realizację sprzętową?
Ja bym kombinował z atmega 328p stara klawiatura pecetowa ze złączem DIN (komunikacja serialowa)
to spokojnie wystarcza do obsługi VGA.
https://www.youtube.com/watch?v=mrRGosn48gw
Inna opcja to raspberry pi 0/w - wtedy byłoby jeszcze WiFi i Bluetooth
-
FPGA, robię na MAX10 ( płytka MAXimator ). Generator obrazu wymaga częstotliwości 65MHz, co w przypadku FPGA nie stanowi problemu.
Wieczorem wrzucę fotki tego co zrobiłem, może jakieś inne pomysły macie na FPGA?
-
FPGA, robię na MAX10 ( płytka MAXimator ).
Dla mnie to za wysoko. Ja swoją edukację w tym względzie zakończyłem 25 lat temu na GAL/PAL :(
-
Można zacząć od kodu, który znajduje się w interfejsie M-397.
Najwięcej na ten temat wie trojacek.
Dzięki za kredyt, ale co ja tam wiem? :)
Generalnie są tu dwa zagadnienia - protokół terminalowy (podobny do VT52) oraz komunikacja sprzętowa (pseudodupleks na 4 bitach, czyli bajt idzie na dwa razy, tzw. nibble mode).
Po stronie FDD nie trzeba nic zmieniać, jeśli robi się komunikację po spirali. Po stronie terminala trzeba zrobić to, co jest w EPROM-ie M397 (warstwa sprzętowa) oraz w programie "terminal emulator", który jest na fabrycznej dyskietce. Albo zajrzeć do kodu TT3000, tam jest wszystko.
Niski poziom to raptem dwie funkcje - wyślij dane z bufora i odbierz dane do bufora. Można żywcem wziąć te z M397 albo odkopać je w danych z TT3000. Niestety nie mam pod ręką żadnej dokumentacji, przekopię wieczorem dysk laptopa, powinienem coś mieć na ten temat.
-
Komunikacja ze stacją odbywa się za pośrednictwem 12 przewodów (6 wejściowych i 6 wyjściowych), tu nie przewiduję problemu. Problem mam taki, że nie mam opisu komunikacji, jakie komendy są wysyłane i odbierane. Czy ktoś z was ma taki opis?
Może trzeba dezassemblować kod TT3000? A może łatwiej będzie dezassemblować CP/M-a?
Jeśli chodzi o sam protokół komunikacyjny, wystarczą Ci źródła BIOSa dla FDD. Są w necie (oraz np. tu (http://www.speccy.pl/forum/index.php?topic=2995.0))
Jeśli chodzi o resztę, potrzebujesz dość dokładną emulację (jeśli się nie mylę) VT52 (większość softterminali które znalazłem radośnie ignorowała np. znak kontrolny czyszczenia ekranu od pozycji kursora)
-
Niski poziom to raptem dwie funkcje - wyślij dane z bufora i odbierz dane do bufora. Można żywcem wziąć te z M397 albo odkopać je w danych z TT3000. Niestety nie mam pod ręką żadnej dokumentacji, przekopię wieczorem dysk laptopa, powinienem coś mieć na ten temat.
Nie można z M397.
Protokoły TOS i CP/M się nieco różnią - w sumie niewiele, ale już znacząco...
A sam M397 przy pracy z CP/M nie bierze udziału, port jest obsługiwany samodzielnie przez program terminala.
Jeśli zerkać to albo do TT3000, albo do programu terminala z dyskietki startowej CP/M.
-
No proszę, warto wiedzieć :)
A przypomniało mi się, że mam gdzieś zdeasemblowany monitor-emulator. Na którymś z kilkudziesięciu obrazów dyskietek... Postaram się znaleźć.
-
Z tym rPi0w to jest nawet myśl - można by się po ssh "logować" do cp/m ;P
-
Na dzień dzisiejszy wygląda to tak.
Generator sygnału VGA 1024x768@60Hz
Generator znaków (czcionka 8bit atari), znaki są wrzucona z bitmapy znalezionej w sieci, bitmapa rozdzielczość 128x128, znaki 8x16.
Jedynie co trzeba zrobić przy podmiance znaków to, skonwertować do BMP 1 bit, hexeditorem wywalić nagłówki i odwrócić kolejność lini. Pliki BMP zapisywane są od dołu.
Dołożona jest pamięć RAM 4kB na bufor znaków, wykorzystane jest tylko 3200 komórek pamięci, reszta do wykorzystania jako rejestry konfiguracyjne: kolor tła, kolor ramki, kolor czcionki, współrzędne kursora, kształt kursora, itp...
Do zrobienia jest, kursor, obsługa klawiatury USB/PS2, interfejs stacji fdd3000 i logika terminala.
Interfejs VGA wygląda tak:
ENTITY VGA is
port(
DATA: IN STD_LOGIC_VECTOR(7 downto 0);
ADDR: IN STD_LOGIC_VECTOR(12 downto 0);
WE: IN STD_LOGIC;
R: OUT STD_LOGIC;
G: OUT STD_LOGIC;
B: OUT STD_LOGIC;
VSYNC: OUT STD_LOGIC;
HSYNC: OUT STD_LOGIC;
CLK: IN STD_LOGIC;
RST: IN STD_LOGIC
);
end VGA;
czyli:
DATA 8 bitów
ADDR 12 bitów
EN 1 bit enable
tymi wejściami zapisujemy bezpośrednio w pamięci tekst do wyświetlenia, oraz do rejestrów konfiguracyjnych.
R,G,B,VSYNC,HSYNC - wyjście VGA, Na płytce mam tylko 3 bitowe VGA, można uzyskać tylko 8 kolorów. Optymalne było by 4 bitowe - 16 kolorów.
CLK - wejście zegara, w moim przypadku 10MHz, układ ma PLL który generuje potrzebną częstotliwość.
Układ jest zajęty w 14%, w przypadku najsłabszego MAX10 będzie to około 65-70%, w razie czego kod można zsyntezować na innym środowisku pod inny układ, np. XILINX-a.
-
Śliczna czcionka.
I mały problem.
Terminal ZX ma zakodowane trzy zestawy czcionek, TT ma cztery (choć do czwartego nie znalazłem odwołań w kodzie)
W załączniku w naturalnej wielkości (żywcem wycięte z :) )
edit:
Żeby nie było nieporozumień - charset do którego nie znalazłem odwołań w kodzie, to tt_2, ten mniejszy, z samymi rameczkami.
Nie wiem czy to jakieś resztki po kompilacji, czy przedłużenie pierwszego zestawu - aż tak się w kod nie zagłębiałem...
-
Dzięki za załącznik, przerobię czcionki.
-
W przypadku korzystania z ZX Spectrum jako terminala była możliwość używania bibliotek graficznych.
Nie wiem czy TT3000 miał taką możliwość. Niby to był tylko terminal, ale na tych samych układach co Timex TC2048.
-
TT3000 ma za mało RAM-u, by ładować biblioteki.
-
Kluczowe słowo "miał". Nowy może być lepszy :)
-
Mam taką nadzieję :) co prawda w opisie PROTON-a nie widzę nic o trybie graficznym. Miła by też była możliwość ładowania fontów.
-
Tryb graficzny wymaga sporej ilości RAM-u, będzie wymagało dołożenia zewnętrznej kostki, jest to do zrobienia ale nie w tej chwili.
Chcę ukończyć projekt na minimalnych założeniach, po czym przejść do rozbudowy.
-
Nie tylko RAM. Grafikę rysowało ZX Spectrum. CP/M wysyłał tylko polecenie z parametrami.
-
W przypadku korzystania z ZX Spectrum jako terminala była możliwość używania bibliotek graficznych.
Nie wiem czy TT3000 miał taką możliwość. Niby to był tylko terminal, ale na tych samych układach co Timex TC2048.
Masz jakiś link? :)
-
Widziałem takie demo pod CP/M. Miałem na dyskietce.
Identycznie wyglądało to na CP/M dla CPC.
-
Poprzedni właściciel mojego 1go Amstrada napisał w Turbo Pascalu taką demonstrację procedur graficznych. On był profesorem w ośrodku obliczeniowym na uniwersytecie w Toruniu. Ekran był podzielony na 6 okienek i w każdym działo się coś innego, jakieś wykresy, wielokąty, słupki i sam już nie pamiętam co jeszcze. To była jedyna naprawdę fajna rzecz jaką widziałem pod CP/M. Pewnie ktoś w Polsce ma tego kopię, a chętnie bym to sobie zobaczył jeszcze raz.
-
Tak, to na pewno było w Turbo Pascalu. Spróbuję odnaleźć tą dyskietkę. Może coś z niej wyciągnę, jak to dokładnie działało.
-
Też widziałem coś takiego. Funkcje graficzne wywoływało się poprzez kody escape (chr(27) plus lista parametrów).
Ale, o ile dobrze pamiętam, kluczem do sukcesu było doczepienie overlaya do programu startowego monitora-emulatora.
-
To była jedyna naprawdę fajna rzecz jaką widziałem pod CP/M.
Ale piszesz tak dlatego, że nie widziałeś dużo rzeczy na CP/M, czy dlatego że zrobiło to na Tobie duże wrażenie jako, że CP/M kojarzy się głównie z terminalowym wyglądem aplikacji?
-
Widzę, że długa droga przede mną. Teraz siedzę i drugi wieczór uczę się assemblera Z80.
-
dely - Oprócz tej prezentacji i "druciaków" rysowanych w LOGO i kopiera z dysków systemowych w MODE 1, reszta rzeczy jakie pod CP/M widziałem to programy biurowe we wysokiej rozdziałce, nawet rameczki były zwykle robione ze znaczków w trybie tekstowym.
A ta demonstracja procedur graficznych była na tyle fajna, że jak mnie nachodziło na oglądanie demek, to mimo braku dźwięków i kolorów nie zapominałem i o niej. :)
Niedawno widziałem jakiegoś screena w necie w rozdziałce jak na Spectrum z czymś co wyglądało podobnie i się zastanawiałem czy to jest jakaś przeróbka, bo też miało ekran podzielony na 6 niemal kwadratowych okienek.
-
Niedawno widziałem jakiegoś screena w necie w rozdziałce jak na Spectrum z czymś co wyglądało podobnie i się zastanawiałem czy to jest jakaś przeróbka, bo też miało ekran podzielony na 6 niemal kwadratowych okienek.
Coś takiego? Właśnie na to wpadłem, przeglądając stare Bajtki.
W jakimś innym numerze było to samo, tylko dla Amstrada.
-
Owszem o taki podział na 6 okienek mi chodzi. Nawet widziałem gdzieś na YT filmik z tej prezentacji na ZX, sprawiało wrażenie uproszczonej wersji tego co poprzedni właściciel mojego CPC zrobił na Amstradzie. tzn były to profesjonalnie wyglądające wykresy jak z programów biurowych, a nie proste kropki, kreski i kółka. Ale nie sądzę aby to gdzieś publikował. Parę lat temu przeglądałem wszystkie scany czasopism i notowałem sobie wszelkie numery i strony do wszystkich ciekawszych dla mnie artykułów. I jedyne co mam na temat CPM+CPC+Pascal+grafika to:
Komputer 4/88 str14 ale to raczej procedury niż ich prezentacja.
Bajtek 10-91 str11 opis DrGraph (z dyskietek systemowych) ponoć do wykresów.
I to tyle. Jest jeszcze o wyświetlaniu obrazków z pliku, w Komp10/88s23, ale to inna bajka.
A jakby ktoś chciał coś dla początkujących o CPM to Bajtek 7/93 str18.
-
A ktoś zna może numer Bajtka w jakim była wersja tych Pascal'owych procedur graficznych dla Amstrada ?
-
Przejrzałem wczoraj na szybko Bajtki i nie znalazłem. Może jednak nie było, musiało mi się przywidzieć.
Ale nie sądzę aby to gdzieś publikował. Parę lat temu przeglądałem wszystkie scany czasopism i notowałem sobie wszelkie numery i strony do wszystkich ciekawszych dla mnie artykułów.
No właśnie, myślę, że taki artykuł kolega na pewno by wyłapał, tworząc spisy artykułów w pismach.
-
Coś jednak kojarzę że były gdzieś publikowane jakieś Pascal'owe procedury dla Amstrada, ale na bank tylko do modelu PCW i nie wyglądały jak te dla Spectrum'a a ekran chyba nie był dzielony na 6 okien.
-
Dobry wieczór.
CPM-Z80 dla Amstrada był opisywany w miesięczniku KOMPUTER roczniki 1988/1989.
-
Widzę, że długa droga przede mną. Teraz siedzę i drugi wieczór uczę się assemblera Z80.
Wykopki :)
@PROTON - czy ten projekt miał jakąś kontynuację?
Pytam, bo niedawno wgryzałem się w protokół terminalowy FDD3000 i w razie czego mógłbym może trochę pomóc.
-
Jeśli Klaudiusz będzie uprzejmy udostępnić w jakiś sposób odpłatności klona PAL2068 od Timex-a, to budowa terminala powinna być możliwa.
-
Maryjan: Aby SCLD było dostępne, potrzebny byłby spec od produkcji, który także zajmie się sprawami licencji wsadu i PCB.
Choć moim zdaniem, zrobienie czegoś nowego na pamięciach dynamicznych, z multiplekserami adresów jest średnim pomysłem.
-
Na potrzeby terminala można zrobić coś lepszego, niż timexowy SCLD. Przecież nie trzeba się ograniczać architekturą TC20x8.
1. Wyższa rozdzielczość
2. Wyjście VGA
3. Więcej RAM (czcionki, grafika)
4. Ujednolicony układ klawiatury (TT3000 wykorzystuje archaiczny układ spotykany w starych terminalach)
5. Zamknięcie całej logiki w jednym układzie (TT3000 ma kilka zewnętrznych TTL-i)
Tak naprawdę całość można zmontować w jakiejś nie za nowoczesnej klawiaturze od PC.
Pytanie, czy miałoby to w ogóle sens. Prostych terminali jest na kopy, zostaje kwestia zinterfejsowania portu FDD3000 (2x6 bitów).
Choć moim zdaniem, zrobienie czegoś nowego na pamięciach dynamicznych, z multiplekserami adresów jest średnim pomysłem.
To trochę zależy. Jeśli brakuje nam pinów, a dostępne makrocele są, to można się w to bawić. Jeśli pinów nie brakuje, a makrocele są na wagę złota - lepiej użyć SRAM.
DRAM-y są o tyle sympatyczne, że są w małych obudowach, a w układach wideo i tak są odświeżane przez generator obrazu. Tryb FPM też korci, by go wykorzystać. Inaczej jednak wygląda sprawa ich dostępności oraz czasy dostępów - łatwiej jest znaleźć szybkie SRAM-y.