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.

maciej_333 napisał:

ernatywa to UPD7220. Zdecydowanie bardziej odpowiada epoce. Układ ten jest tani i łatwo dostępny. Zapłaciłem za niego w Polsce o ile pamiętam 3,60 zł.

Gdzie go kupowałeś?
Możliwości układu sć ciekawe ale dokumentacja skromna. Na razie znalazłem tylko rozkład wyprowadzeń i schemat blokowy.

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...

Atlantis86 napisał:

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...

Tutaj jest za 15 zl:

https://www.ebay.co.uk/itm/1pcs-UPD7220D-I-UP...ocontroller-ICs-DIP40CG-NEC-BULK/263326672837

i to z Polski.

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