MCY7880 i układ mikroprocesorowy na polskich elementach

Można też wykożystać starsze układy np 6545 lub 6845. Tutaj załączam opis układy na 6845 w przestrzeni I/O.

Ewentualnie można zastosować układ z jakiegoś amatorskiego mikrokomputera np COBRA1, AC1 (NRD), robotron z1013. Dane puszczamy przez bufor dwukierynkowy, a adresy przez zatrzaski w przestrzeni adresowej I/O.

Kupowałem go w sklepie Gembara. Jednak układ kosztuje 7,45 zł. Datasheet jest skromny, ale User manul dla UPD7220 już nie. Jest jeszcze design manual.

Układ działa. Na EPROM-ie znajduje się prosta implementacja przykładu blink, korzystająca z osobnej funkcji opóźniającej. Czyli pamięć RAM i stos także działają.
Ktoś może wie coś na temat jakiejś prostej implementacji BASIC-a, którą dałoby się dostosować do uruchomienia na takich amatorskich konstrukcjach?

A co do UPD7220, to widzę wtedy jedną aukcję na Allegro. Absurdalnie wysoka cena...

Proponuję jednak najpierw uruchomić terminal po UART, pamięć masową i jakiegoś CP/Ma. Wyświetlanie na monitorze to czysty wodotrysk, w dodatku niepotrzebny, kiedy nie ma co wyświetlać.
Mogę odstąpić ceramiczny 7220 w zamian za ceramiczny 8080. Mam też parę innych układów serii 82 w plastiku, do wymiany na MCY7880, 8080 lub 8008, których mam ciut za mało do zabaw.

BlueDraco napisał:

Proponuję jednak najpierw uruchomić terminal po UART, pamięć masową i jakiegoś CP/Ma.

Zanim uruchomię CP/Ma chciałbym jeszcze spróbować z jakimś BASIC-iem. W ten sposób uzyskam jako-taką konkretną funkcjonalność bez potrzeby uruchamiania pamięci masowej. Istnieje jakiś projekt otwartego, dobrze udokumentowanego BASIC-a, który w miarę łatwo dałoby się przeportować na takie urządzenie?

Cytat:

Wyświetlanie na monitorze to czysty wodotrysk, w dodatku niepotrzebny, kiedy nie ma co wyświetlać.

Tak, wiem. Najpierw zamierzam odpalić UART. Po prostu od początku wyobrażałem sobie, że finalnie będzie to samodzielny komputer, z własną klawiaturą i możliwością podpięcia do TV, niczym w latach osiemdziesiątych.
Dlatego zbieram informacje o potrzebnych elementach.

Cytat:

Mogę odstąpić ceramiczny 7220 w zamian za ceramiczny 8080.

Niestety, ceramicznego 8080 nie posiadam. Zaledwie parę sztuk MCY7880, NEC D8080AFC i jakiś radziecki klon tego procesora.

Cytat:

lub 8008, których mam ciut za mało do zabaw.

Tak swoją drogą 8008 idzie jeszcze gdzieś dostać w rozsądnej cenie? Na Ebay-u widziałem stare egzemplarze w ceramicznych obudowach, ale ceny były... Kolekcjonerskie. Można gdzieś jeszcze kupić jakieś tańsze egzemplarze, klony z innych firm itp.?

I jeszcze jedno pytanie. Czy w przypadku MCY7880 wskazane jest stosowanie jakiegoś dodatkowego chłodzenia? Bo jakby nie patrzeć, układ dość mocno się grzeje (po paru sekundach trzymanie palca na obudowie zaczyna być nieprzyjemnym doświadczeniem). Można go tak zostawić, bez dodatkowego chłodzenia? Jak rozwiązywano to w fabrycznych konstrukcjach?

Co do BASICa proponował bym Palo Alto Tiny Basic version 2 jest dość prosty(4k kodu). Tylko trzeba było by zanieść wersję elektroniczną listingu i przekompilować ja jeszcze raz, ponieważ w twoim komputerze RAM zaczyna się od wyższych adresów.

Zanim jednak uruchomisz interpreter Basica proponował bym uruchomienie jakiegoś monitora(edycja komórek pamięci, rejestrów procesora itp.) Jest to dużo prostszy program a umożliwia uruchamianie programów i ich debugowanie.
Z prostych monitorów proponował bym ten opisany sprzęt Stanisława Garsynika bodajże w MIK 05(napisany w asemblerze Z80 ale wydaje mi się że nie było tam instrukcji których nie obsługuje 8080). Zawiera on 6 podstawowych procedur wystarczy dopisać procedurę wysyłania i pobierania znaku po USART.

Dioda125 napisał:

Co do BASICa proponował bym Palo Alto Tiny Basic version 2 jest dość prosty(4k kodu). Tylko trzeba było by zanieść wersję elektroniczną listingu

Właśnie liczyłem na to, że może gdzieś już istnieje elektroniczna, edytowalna wersja kodu źródłowego tego interpretera. Bo udało mi się znaleźć kod w zeskanowanym czasopiśmie z końca lat siedemdziesiątych, jednak przepisywanie tego jest obarczone sporym ryzykiem, że potem stracę wiele dni na poszukiwaniu literówki. No i dobrze byłoby, gdyby kod był udokumentowany, a fragmenty odpowiedzialne za I/O były dobrze oznaczone i skomentowane. Dopiero zaczynam naukę asemblera...

Cytat:

i przekompilować ja jeszcze raz, ponieważ w twoim komputerze RAM zaczyna się od wyższych adresów.

RAM zaczyna się u mnie od początku przestrzeni adresowej. Pierwsze 32kB są cały czas dostępne, dalej znajduje się 16kB "okienko" na dwa przełączane banki. EPROM natomiast zaczyna się od adresu 0xC000.

Cytat:

Z prostych monitorów proponował bym ten opisany sprzęt Stanisława Garsynika bodajże w MIK 05(napisany w asemblerze Z80 ale wydaje mi się że nie było tam instrukcji których nie obsługuje 8080). Zawiera on 6 podstawowych procedur wystarczy dopisać procedurę wysyłania i pobierania znaku po USART.

Hmm... Jest to jakieś rozwiązanie. Może faktycznie spróbuję. Mam nadzieję, że przystosowanie tego programu do komunikacji przez UART nie będzie zbyt trudne. W końcu CA80 korzystał z klawiatury szesnastkowej i wyświetlacza siedmiosegmentowego.

Generalnie na tej płytce i tak jeszcze zostały mi do przetestowania 8251 i 8253.
Na drugiej płytce trzeba będzie jeszcze dodać kontroler przerwań.

Kod źródłowy kilku interpreterów BASICa na 8080 daje się łatwo znaleźć, np. tu:
http://www.autometer.de/unix4fun/z80pack/ftp/altair/

Ja na 8085 mam CP/M więc poza bootloaderem nie mam żadnego oprogramowania w pamięci, a OSI BASIC Microsofta wciągnąłem na 6502 - podobnie jak w 8080 wystarczy napisać procedury obsługi konsoli - taki getchar i putchar.

BlueDraco napisał:

Kod źródłowy kilku interpreterów BASICa na 8080 daje się łatwo znaleźć, np. tu:
http://www.autometer.de/unix4fun/z80pack/ftp/altair/

Wielkie dzięki za info. Widzę, że jest tam między innymi TinyBasic 2.0.
Czy gdzieś jeszcze dałoby się znaleźć jakąś dokumentację, która pozwoliłaby na dostosowanie tego kodu do uruchamiania bezpośrednio z EPROM-u, na moim sprzęcie?

Cytat:

Ja na 8085 mam CP/M więc poza bootloaderem nie mam żadnego oprogramowania w pamięci

Mogę zapytać jakiej pamięci masowej używasz?
Czy możliwe jest zapisanie CP/M w EPROM-e i bootowanie systemu z tej pamięci?

Basic jest napisany tak, żeby działał z ROM. Może też działać z RAM. W źródłach łatwo znaleźć ustawienia adresów kodu i danych.
Jako pamięci masowej używam dyskietki emulowanej w pamięci Flash uC, z dwoma buforami ścieżki w RAM w celu redukcji liczby kasowań i zapisów. ścieżka ma rozmiar strony Flash. Do Flash zapisywana jest cała ścieżka, kiedy ścieżka była modyfikowana i trzeba opróżnić bufor (alternatywnie - na żądanie lub po przekroczeniu określonego czasu od ostatniej operacji).
CP/M ma dane przemieszane z kodem - oryginalny musi siedzieć w pamięci RAM. Istniały jakieś przeróbki CP/M do pracy z ROM, ale prawdziwy działa tylko z RAM (ciut bez sensu, komu przeszkadzałoby rozdzielenie kodu i danych?).

BlueDraco napisał:

Basic jest napisany tak, żeby działał z ROM. Może też działać z RAM. W źródłach łatwo znaleźć ustawienia adresów kodu i danych.

Ok, faktycznie. Już widzę te dwie sekcje zaczynające się ".ORG".
Ktoś orientuje się które części tego kodu należy zmodyfikować, aby odpowiadały parametrom specyficznym dla mojego hardware'u? Mam tutaj na myśli przede wszystkim ilość pamięci dostępnej dla BASIC-a oraz procedury odpowiadające za komunikację - wysyłanie i odbieranie znaku (w moim przypadku UART na 8251).

Szukaj, na pewno będą na początku lub na końcu - to ledwie 2 procedury do terminala i jedna startowa. Jeśli dasz link do pliku - może znajdę.

BlueDraco napisał:

Szukaj, na pewno będą na początku lub na końcu - to ledwie 2 procedury do terminala i jedna startowa. Jeśli dasz link do pliku - może znajdę.

Chodzi mi konkretnie o ten plik:
http://www.autometer.de/unix4fun/z80pack/ftp/altair/tinybasic-2.0.asm

Moja umiejętność czytania kodu w asemblerze jest jak na razie na dość podstawowym poziomie.

Etykiety:
INIT - inicjowanie UART
OC3 - wysyłanie znaku
CHKIO - sprawdzenie/odbiór znaku

Ta wersja jest napisana tak, że musi być w ROM od adresu 0 - używa instrukcji RST które wywołują procedury spod adresów 8, 10, 18 itd.. RAM gdziekolwiek powyżej ROM - dwie dyrektywy ORG pod koniec pliku.

BlueDraco napisał:

Ta wersja jest napisana tak, że musi być w ROM od adresu 0 - używa instrukcji RST które wywołują procedury spod adresów 8, 10, 18 itd.. RAM gdziekolwiek powyżej ROM - dwie dyrektywy ORG pod koniec pliku.

Czyli rozumiem, że nie mogę po prostu zamienić wartości przy ".ORG", tak aby program zaczynał się np. od 0xC000 (początek EPROM-u) a zmienne były zdefiniowane gdzieś na początku pamięci RAM?
Adresy do których odwołują się instrukcje RST muszą znajdować się w tych początkowych adresach? Nie można ich w jakiś sposób przemapować, np. żeby znajdowały się za 0xC000?
Ewentualnie nie dałoby się zastąpić ich standardowymi instrukcjami wywołania CALL?
Czy też jedyną opcją będzie po prostu ręczne przekopiowanie odpowiednich wartości do RAM-u na etapie inicjacji kodu?

No właśnie powyżej napisałem, że nie możesz, bo jest napisany tak, żeby siedział w ROM od adresu 0. Może jest gotowa inna wersja, która nie używa RST zamiast CALL.

BlueDraco napisał:

No właśnie powyżej napisałem, że nie możesz, bo jest napisany tak, żeby siedział w ROM od adresu 0. Może jest gotowa inna wersja, która nie używa RST zamiast CALL.

Hmm... Jak już wspominałem, w przypadku mojego urządzenia EPROM zaczyna się od 0xC000. Odpowiednia logika troszczy się o to, aby po restarcie linie A14 i A15 zostały ustawione, umożliwiając start kodu z EPROM-u.

Nie wiem czy moje rozumowanie jest poprawne, ale gdyby tak zmodyfikować kod tego BASIC-a wg następujących założeń:

1) Program zaczyna się od ".ORG 0C000H", na początku inicjuję stos oraz umieszczam parę instrukcji odpowiedzialnych kwestie specyficzne dla mojego sprzętu, inicjuję też peryferia.
2) Kod odpowiedzialny za obsługę rozkazów RSTx na razie pomijam. Za pomocą polecenia ".ORG" przygotowuję jednak zbiór etykiet wskazujących na konkretne lokacje w pamięci RAM.
3) Zmienne inicjuję gdzieś w dolnej części pamięci RAM, jednakże powyżej wspomnianych etykiet.
4) Na końcu kodu programu w pamięci EPROM umieszczam kod obsługujący poszczególne funkcje dla RSTx. Oznaczam je rzecz jasna przy pomocy innych etykiet niż miejsca przewidziane w pamięci RAM.
5) Tworzę funkcję "memcopy", która bajt po bajcie przepisuje kod obsługujący RSTx z EPROM-u pod właściwe adresy w RAM-ie. Funkcję wywołuję na samym początku, podczas inicjacji kodu.

Taka modyfikacja zadziała?
Czy próbować to przepisać w taki sposób, aby wywyłania RST x zastąpić wywołaniami CALL etykieta, nie przejmując się pod jakimi adresami w EPROM-ie znajdują się elementy docelowe?

Chyba szybciej będzie zastąpić w edytorze wszystkie RST odpowiednimi CALL, wcześniej nadając etykiety tym procedurom (bo teraz, o zgrozo, ich nie mają).

Pracuję właśnie nad przeportowanem kodu TinyBasica pod moją konstrukcję.
Do tworzenia kodu maszynowego (plik .hex) używam asemblera ze strony asm80.com.

Niestety nie chce on rozpoznać makra znajdujacego się na początku kodu:

Dostaję komunikat o błędzie:

Cytat:

Unrecognized instruction DWA Line: 58

Myślałem, że to wina konwencji nazywania etykiet (brak dwukropka), jednak po wprowadzeniu zmiany ciągle mam komunikat:

Cytat:

Unrecognized instruction MACRO Line: 58

ktoś wie o co może chodzić?

Potrzebny jest macroassembler i8080. Problem w tym, że najczęściej używanym CPU w tej 8-bit architekturze był Z80 o innym zapisie mnemoników.
Ale znalazłem taki macroassembler (kiedyś używałem do i8085): http://www.z80.info/zip/as8080.zip

Pzdr

Problemy udało się rozwiązać dzięki pomocy jednego z uczestników tej dyskusji. Na chwilę obecną komputer działa pod kontrolę Tiny Basica, choć trzeba przyznać, że jest to wyjątkowo uboga wersja tego języka szczególnie boli brak instrukcji PEEK i POKE, a także obsługi obsługi ułamków. Niemniej chodziło tylko o test. Teraz kolejnym celem będzie dodanie IO oraz pamięci masowej, a także uruchomienie CP/M.

Tak jeszcze BTW odnośnie 6502. Wiecie coś o jakimś wiarygodnym źródle tych procesorów? Na Aliexpress można kupić (ponoć) i\oryginalne układy w wersji NMOS. Na Ebay-u widzę (również chińskie) aukcje nowszech wersji tych procesorów, w technologii CMOS (65C02). Np. tu albo tu.
Sądzicie, że te aukcje są warte zaufania? A może znacie jakieś inne źródło tych układów?

65C02 różni się trochę od 6502. Nie będą działać rozkazy niepublikowane, 65C02 wykona nop. Wada, że zabawa mniejsza, zaleta, ze niektóre rozkazy powodowały zawieszenie procka. 65C02 można zatrzymać w dowolnym (prawie) momencie, 6502 tylko na początku cyklu (nie pamiętam czy cyklu rozkazu czy cyklu maszynowego). Kiedyś miałem książkę, "Mikroprocesor 6502 i jego rodzina". Tam były dokładne opisy różnic oraz schemat układu pracy krokowej.

Jestem po serii zakupów starych procesorów. Prawie wszystkie mają prostowane nogi i grawerowane laserem nowe oznaczenia. Większość nie jest oszukanych, a tylko "odmłodzonych" (nie wiem, po co). Niestety trafiają się wersje NMOS oznaczone jako CMOS (Zwłaszcza Z80), jakieś nieokreślone 65C02 oznaczone jako WDC W65C02S lub R65C02 z niemożliwą datą produkcji itp. kwiatki. Z drugiej strony przy cenie $1.30 za sztukę może lepiej kupić z trzech niepewnych źródeł niż z pewniejszego za 5 USD.
65C02 działa na 3.3 V i można mu zatrzymać zegar. W NMOSowym nie jest możliwa praca krokowa.
Ciekawy jest też 65C816 - ostatnio upolowałem kilka nieoszukanych. Działa oficjalnie na 3.3 i mniej, zgodny z 65C02 ale sporo mądrzejszy.

BlueDraco napisał:

65C02 działa na 3.3 V i można mu zatrzymać zegar.

Fakt, 65C02 jest statyczny, 6502 min zdaje sie 200kHz.

BlueDraco napisał:

W NMOSowym nie jest możliwa praca krokowa.

W książce, o której pisałem, była opisana taka możliwość. Wydaje mi się, że sygnałem RDY.

BlueDraco napisał:

Ciekawy jest też 65C816

Czytałem o nim przy okazji opisu karty turbo do C-64. Procek 16-bit, tryb zgodności z 6502. Nie miałem okazji poznać możliwości tego CPU.

Niezupełnie - w NMOS jest maksymalny czas aktywacji RDY - bez szans na pracę krokową. 65C02 jest statyczny, chociaż nie do końca. W każdym razie zegar daje się zatrzymać, przynajmniej w drugiej fazie cyklu - korzystam, działa.
65C816 jest z grubsza elektrycznie zgodny z 65C02. Ma klika nie niezbędnych, ale pożytecznych sygnałów wyjściowych, które zastępują wejścia i nieużywane linie 65C02. Wykonuje kod 65C02 bez nowych instrukcji bitowych (których i tak nikt nie używa), za to ma dodatkowe 6 bitów adresu, 16-bitowe rejestry i parę innych rozszerzeń. Bawię się nim od paru tygodni. Oprogramowanie 65C02 działa bez zmian.

BlueDraco napisał:

za to ma dodatkowe 6 bitów adresu, 16-bitowe rejestry i parę innych rozszerzeń.

I zegar, zdaje się 20MHz. Używany był w konsolach SNES i jakiś wersjach Aplle. Niezbyt popularny CPU, pewnie za późno wszedł na rynek, wcześniej był 68000 chyba pierwszy popularny CPU 16/32 bit (też nie był statyczny, rejestry jak komórki pamięci DRAM).

BlueDraco napisał:

Większość nie jest oszukanych, a tylko "odmłodzonych" (nie wiem, po co). Niestety trafiają się wersje NMOS oznaczone jako CMOS (Zwłaszcza Z80), jakieś nieokreślone 65C02 oznaczone jako WDC W65C02S lub R65C02 z niemożliwą datą produkcji itp. kwiatki. Z drugiej strony przy cenie $1.30 za sztukę może lepiej kupić z trzech niepewnych źródeł niż z pewniejszego za 5 USD.
65C02 działa na 3.3 V i można mu zatrzymać zegar. W NMOSowym nie jest możliwa praca krokowa.

Jest jakieś pewniejsze źródło, w którym można by kupić te procesory, nawet za nieco wyższą cenę? Czy na chwilę obecną w grę wchodzą tylko chińscy sprzedawcy? Może jakieś polskie sklepy mają je w starych zapasach?
Niedawno dotarła do mnie przesyłka z NMOS-owymi 6502 z Aliexpress. Zestaw pięciu sztuk za śmiesznie niską cenę. Każdy inny, niektóre z mocno zatartymi oznaczeniami, napisy na jednym z układów zupełnie zatarte. Wyglądają na wyjęte z podstawek. Nie są to na pewno NOS-y. Jeszcze ich nie testowałem, bo nie skleciłem jeszcze odpowiedniej płytki. Większy priorytet miał dla mnie ostatnio system na MCY7880.
Niemniej 6502 też chciałbym się bliżej przyjrzeć. W końcu był to bardzo popularny procesor w sprzęcie retro: C64, Atari, Apple, NES...

W najgorszym razie jednak zaryzykuję zakup w Chinach... Drogie nie są..

Atlantis86 napisał:

Jest jakieś pewniejsze źródło, w którym można by kupić te procesory, nawet za nieco wyższą cenę?

Mam 30 szt, nówek, 6502 MOS Technology zakupiony swego czasu z serwisu Commodore. Tu koniec dobrych wiadomości, problemem będzie ich odzyskanie.