Mikrokomputer COBRA 1

wieswas napisał:

1. ORGANY 53BE

Do programu organy dodałem obsługę AY3. Całkiem ładnie gra. Aż prosi się, aby dodać ornamenciki, wówczas dźwięk będzie piękniejszy.
Uruchomienie jak zwykle G:F070.

Ciekawe czy zadziała ten AY na wersji COLOR?

Sprawdziłem działanie programu pod kątem graficznym na emulatorze.
Uzyskałem takie obrazki:

Dodałem do programu "Monitor Cobra" od adresu C72D h, gdzie było tylko już C9 h, procedurę ustawienia przełącznika semigrafiki na 31 h, czyli na podstawową semigrafikę Cobry.
Ustawiłem atrybuty koloru na cały ekran 0F h (czarne tło, białe napisy) po tym wypełniłem ekran kodem 00 h i zakończyłem to wszystko kodem C9 h, który wcześniej nadpisałem.
Otrzymałem coś takiego:
.
Nie wiem jakie program "ORGANY" wydaje dźwięki, gdyż moje emulatory zamilkły jakiś czas temu, nie wiem z jakiego powodu, nawet wcześniejsze wersje, na których grała mi Katarynka.
Zmodyfikowany program w załączniku.

Czy ktoś ze składających Cobre Color miał problem z AY3? W moim przypadku na obu stronach jedynie "charczy" w takt muzyki... Podmieniłem AY, na drugi, ale nie rozwiązało to problemu :/

a na jakiej wersji cobry kolega ten AY uruchamia?
(u mnie w wersji kynarowej - kilka lat temu poszedł bez problemu ale AY3-8913 - tylko musiałem dla niego zaprojektowac inny troche układ dekodowania - jednak adresy miał te same co w zx spectrum)

miki1406 napisał:

Czy ktoś ze składających Cobre Color miał problem z AY3?

U mnie gra to tak:


Dodano nowe brzmienia:
klawisz A - brzmienie podstawowe
klawisz S - brzmienie niebiańskie
klawisz D - brzmienie ostre

Uruchomienie G:F070

Czy ORGANY w wersji AY3-8910 da się uruchomić z emulatora COBRY?
Czy musi być wcześniej wgrana jakaś łatka systemowa?

wieswas napisał:

Czy ORGANY w wersji AY3-8910 da się uruchomić z emulatora COBRY?

Da się. Start i uruchomienie od 0x5000.


Poniżej nuty policzone dla mojego egzemplarza karty AY3.

Sprawdziłem na emulatorze - działa.
Gdy tylko dokończę rozpoczęty już projekt, to poćwiczę AY.

wieswas napisał:

Sprawdziłem na emulatorze - działa.

Można dodefiniować jeszcze nowe instrumenty, aby bardziej wykorzystać możliwości tego PSG.

Nakręciłem krótki filmik pokazujący działanie układu AY3-8910 i Katarynki na płycie PCB "COBRA1 - COLOR 2022 r."

To, że źle działa układ AY3-8910 przyczyn może być wiele np. przesterowanie.
Ja w partii 10 sztuk AY3-8912 dwa układy miałem uszkodzone.
Przeprojektowałem płytę główną na AY3-8910, gdyż są dużo tańsze, ale nieco większe
Zrobiłem zdjęcia z zamontowaną elektroniką dla tego układu.

zdzis_ek napisał:

Przeprojektowałem płytę główną na AY3-8910, gdyż są dużo tańsze, ale nieco większe

Doskonale, dodatkowo one mogą przydać się w zakresie uruchomienia syntezy mowy oraz odtwarzania sampli utworów. Mam wizję jak to zrobić.

zdzis_ek napisał:

Nie wiem jakie program "ORGANY" wydaje dźwięki, gdyż moje emulatory zamilkły jakiś czas temu, nie wiem z jakiego powodu, nawet wcześniejsze wersje, na których grała mi Katarynka.

sq2bvn napisał:

wieswas napisał:

Czy ORGANY w wersji AY3-8910 da się uruchomić z emulatora COBRY?

Da się. Start i uruchomienie od 0x5000.

Zapytam wprost: Czy program dźwiękowy na emulatorze działa od razu, tak samo, jak na prawdziwym sprzęcie, czy wymaga to jakiegoś specjalnego dostosowania programu pod emulator? Jeżeli są jakieś szczegóły, które należy uwzględnić chcąc uruchomić na emulatorze bądź na prawdziwej maszynie, to proszę je podać.

Plik organy.bin kol. "sq2bvn" wczytałem pod adresem 5000 hex i uruchomiłem G:5000.
Jest to zmodyfikowany program, ponieważ w mojej wersji na GENERATOR-2 (port FE) nie było opcji przełączania barwy dźwięku.
Emulator oryginalny bez żadnych modyfikacji.

wieswas napisał:

Emulator oryginalny bez żadnych modyfikacji.

Ogólnie nie skupiałem się na GUI a tylko na aigrekizacacji programu. Co do GUI, może być zasadne wprowadzenie dodatkowego ekranu aktywowanego klawiszem, gdzie będą ustawienia dźwięku.
Parametrów decydujących o brzmieniu jest kilka więc, do ich regulacji dodatkowy ekran z jakimiś suwakami może uprościć regulację i ogólnie zrozumienie co do czego jest.
Te dźwięki wpisałem na pałę i to nie jest szczyt możliwości samego układu AY3. Tak samo można włączyć możliwość wyboru między AY3, katarynką i generatorem-2. Oczywiście na tych ostatnich źródłach będzie trudniej uzyskać takie brzmnienia jak na AY3.

Dodatkowo można też zrobić w prosty sposób COBRA STEREO. Do tego celu do wyjść równoległych AY3 należy podłączyć drabinki rezystorowe R-2R i tym samym w prosty sposób uzyskać COVOXY... w ten sposób będzie możliwe odtwarzanie dźwięku PCM, gdzie próbki pochodziłyby w pliku na karcie SD. RAM jest ciasne, więc lepiej utwory trzymać na karcie SD. Ale wówczas będzie potrzebna natywna obsługa SD z poziomu monitora... Do prawidłowego przesyłania próbek do STEREO wskazane byłoby uruchomić przerwanie INT.

wieswas napisał:

Emulator oryginalny bez żadnych modyfikacji.

Nie chodzi mi o modyfikację samego emulatora, tylko o ewentualną modyfikację programu w celu zmuszenia do działania na emulatorze, a niepotrzebną do działania na sprzęcie.

wieswas napisał:

Dane dla animacji o długości 6336 bajtów zostały spakowane do długości 2638 bajtów i są rozpakowywane "w locie" podczas wyświetlania. Zajętość pamięci po spakowaniu wynosi 41,6% pierwotnej długości.
Do rozpakowania służy podprogram UNPACKER zawarty w tym programie.
Napisałem go specjalnie dla tego programu, ale może być wykorzystany przez innych użytkowników nawet jako procedura wywoływana z BASICA. Zajmuje 24 bajty. Przed wywołaniem należy w HL umieścić adres docelowy (np. miejsce na ekranie) a w DE adres początku spakowanych danych.
Na końcu danych należy umieścić znak 2E. Aby rozpakować nie znak 20hex jak stosuję w tym programie należy zmienić jeden bajt procedury.
7E LD A,(HL)
FE CP A,2E
2E
C8 RET
FE CP A,00
00
28 JR Z,05
05
12 LD(DE),A
13 INC DE
23 INC HL
18 JR F3
F3
23 INC HL
46 LD B,(HL)
3E LD A,20 20 to kod ASCII spacji. Można zmienić na inny
20
12 LD(DE),A
13 INC DE
10 DJNZ FC
FC
23 INC HL
18 JR E8
E8

Jak wygląda procedura kompresji do tej dekompresującej?

Pakowanie robiłem "ręcznie".
Kolejne niespakowane dane przepisuję bez zmian, aż do natrafienia na ustalony bajt, który powtarza się najczęściej (w tym przykładzie była to spacja).
Jeżeli jest to spacja pojedyncza lub podwójna, to także przepisuję bez zmian.
Jeżeli są 3 lub więcej kolejnych spacji, to wpisuję 00 i ilość powtórzonych spacji.
Dalej powtarzam tę procedurę aż do natrafienia na umowny znak końca danych (2E czyli kod kropki).
Maksymalna ilość to 255dec (FFhex). Jeżeli kolejnych spacji byłoby więcej, to koduję te 255 jako 00,FF, a dalsze np. 33 spacje dopisuję jako 00,21.
Tym sposobem kodowane dane prawidłowo rozpakuje program UNPACKER zamieszczony w procedurach. Ponieważ pakowanie dla każdego programu jest jednorazowe, to nie stworzyłem procedury pakującej. Ponieważ programy piszę na PC, a nie na COBRZe, to program pakujący też byłby pisany na PC, ponieważ gotowy program na COBRĘ i tak korzystałby jedynie z UNPACKERA, a nie potrzebuje do swojego działania PACKERA.
Ta przykładowa pakowana spacja może być także innym znakiem, np. kolor błękitnego nieba i białych chmur (kod DFhex). Znak końca danych można także sobie ustalić nie 2E, tylko np. FF zmieniając trzeci bajt UNPACKERA

Ostatnio nie śledziłem forum (zbyt uważnie) , pojawiła się kwestia zapisu generatora znaków w ram. Rozwiązanie to przetestowałem już jakiś czas temu.


https://www.elektroda.pl/rtvforum/topic2564143-870.html#19796129
https://www.elektroda.pl/rtvforum/topic2564143-870.html#19798458



W tym przypadku pole generatora znaków zajmuje obszar F000 - F7FF , zaraz nad obrazem.
Sterowanie wyborem , standardCHAR / ramCHAR bitem 7 portu dotychczas używanego do przełączania generatorów.

atmeg8 napisał:

Sterowanie wyborem , standardCHAR / ramCHAR bitem 7 portu dotychczas używanego do przełączania generatorów.

Ten dekoder myślałem aby zrobić w oparci o GALa, wówczas można mieć dodatkowe adresy bez kolizji.

Rozwiązanie z DUAL RAM jest ok, ale czy zrobi się to na PCB 2-layers? Moje rozwiązanie z układem SPI działa daje większe możliwości i nie ma konieczności dodawania tak wielkiej ilości ścieżek.
Zbliżam się do uruchamiania COBRA COLOR tak więc, może po drodze pojawią się jeszcze jakieś wizje...

Można skorzystać z dekodera adresów w Cobrze :

DualRam nie komplikuje zbytnio płytki , bez problemu wystarczą dwie warstwy


Jak widzisz wykorzystanie SPI w tym temacie?

Tak się zastanawiam, czy rozwiązanie z DualRam da się zastosować razem z kolorem.
Umieściłem to rozwiązanie na schemacie Cobra1 color.
Nie wiem tylko czy zadziała i czy wszystko zrobiłem prawidłowo.

Na przedstawionych schematach nie doszukałem się jaki stan mają mieć wejścia 9 i 10 układu 74LS30, w "powietrzu" to raczej nie powinny się znajdować.
Czy nie można by było pozostawić Rom 29F040 z przełącznikiem sterowanym sygnałem /Q3 a do sterowania DualRam wykorzystać sygnał /Q5, który był przewidziany do sterowania drukarką.
Przy takim rozwiązaniu uruchamiały by się wszystkie obecnie dostępne programy rozbudowane graficznie a nowo pisane programy korzystały by już z DualRam.
W innym przypadku będzie odczuwalny brak programów z nowym sterowaniem grafiką.

Uciekł Ci jeden 6116
Trochę poprawiłem , też jeszcze nie wiem czy dobrze .
Myślę , że można pozostać przy Q3 , bity 0 - 6 sterowały by generatorem ROM (128 banków) , a bit 7 załączał by DualRam.
I wszyscy zadowoleni .

Faktycznie przegapiłem.
Zmylił mnie ten DualRam, skoro są dwa ramy
Pamięć tą trzeba traktować raczej jako Rom znaków.
128 przełączanych generatorów semigrafiki będzie wystarczająca.
Teraz raczej powstawać będą semigrafiki w pisanych programach pod DualRam.
Skoro wyłapane zostały moje błędy, wstawię przełącznik z Rom 29F040, chociaż teraz wystarczy 29F020 przy takim sterowaniu bitami jak proponujesz.

Dodano po 9 [godziny] 19 [minuty]:

Tak jak pisałem, umieściłem na schemacie ROM 29F020 lub 209F040 z przełącznikiem generatorów znaków.
Do kompletu dokładam jeszcze schemat części procesorowej, ułatwi to analizę wszystkich połączeń.

Bardzo proszę o przeanalizowanie schematów i wniesienie ewentualnych poprawek.

Część procesorową trochę odchudziłem i inaczej zagospodarowałem bramki ,
temat do dalszej analizy


W części graficznej podobnie

Wielkie "dzięki"
Zaczyna klarować się ciekawy projekt.

Na razie po staremu chciałbym zaprezentować uproszczoną grę TETRIS napisaną całkowicie pod assemblerem. Zawiera 16 losowo wybieranych kształtów klocków, które można obracać co 90 stopni w prawo lub lewo przez czas 20 sekund i przesuwać w prawo lub lewo przez kolejne 20 sekund. Podczas spadania nie ma luż możliwości korekcji upadku klocka. Jest to więc uproszczenie w stosunku do oryginału. Nie ma też resetowania wypełnionych linii i gra kończy się po przekroczeniu ustalonej wysokości stosu. W assemblerze nie mam takiego doświadczenia jak przy pisaniu bezpośrednio w kodzie maszynowym, ale szybkość modyfikacji, możliwość automatycznego przeadresowywania procedur, brak ryzyka wprowadzenia błędów "literówek" przy ręcznym wklepywaniu kodów do COBRY powoduje,że kolejne programy powstaną jednak w assemblerze.
Wadą tego sposobu jest brak możliwości podglądu bezwzględnych adresów procedur i danych. Jest to bardzo przydatne, gdy chcemy zmienić np. klawisze sterujące na inne lub numer portu dźwięku. Za pomocą disassemblera, który w oknie bez możliwości wydruku przypisał kody do adresów i wspomagając ręcznie udało mi się stworzyć źródło programu w dotychczasowym formacie tzn.
3 kolumny: adres, kod, mnemonika. Byłbym wdzięczny za namiary, skąd można pobrać taki disassembler Z80 na PC.
Gra zajmuje RAM od adresu 5000hex do 6180hex (4480bajtów)
Adres startowy G:5000
Dźwięk GENERATOR-2 jest z użyciem portu FE (adres 5E96). Ten bajt można zmienić na własny, inny port. Używany jest też BEEP z portem 1B.
Aby zmienić klawisze sterujące należy podmienić zawartości podanych adresów:
Pętla klawiatury A=ruch w lewo adres 5114 jest 41
Pętla klawiatury D=ruch w prawo adres 511C jest 44
Pętla klawiatury W=obrót w lewo adres 50D7 jest 57
Pętla klawiatury S=obrót w prawo adres 50DE jest 53
Analogicznie wówczas należy zmienić litery w wyświetlanych napisach
5F45 jest 41 A
5F53 jest 44 D
5F61 jest 57 W
5f70 jest 53 S
czas przeznaczony na obroty i przesuw klocka określa adres 53B9 (obecnie 33)
Tych informacji nie odczytalbym z pliku assemblera, stąd konieczność posiadania dobrego disassemblera. Poza tym oglądając plik źródłowy po disassemblerze od razu dostrzegłem procedury, które można ścieśnić.
Załączam screeny gry:

oraz plik TETRIS.hex

Kol. wieswas - nie odpuszczasz
Ja natomiast chciałem się dopytać w innej sprawie, rozrysowałem organizację pamięci w Cobrze1 color i w Cobrze1 color Dual-Ram.
Wygląda na to, że wszystkie napisane wsady do tej pory na Cobre1 przestaną działać.
Trzeba by było pisać je od nowa.
Jedynym pocieszeniem jest to, że nowo - pisane wsady będą działać wstecz.
Ale może źle rozumuję.

zdzis_ek napisał:

Pamięć tą trzeba traktować raczej jako Rom znaków.
128 przełączanych generatorów semigrafiki będzie wystarczająca.
Teraz raczej powstawać będą semigrafiki w pisanych programach pod DualRam.

Moja sugestia jest taka, aby dodać natywny interfejs SPI obsługi kart SD. W takim przypadku z poziomu aplikacji będzie możliwe ładowanie kolejnych GZ i GRAM z karty SD.
Dodatkowo można też wykorzystać bankowanie, czyli adresowanie 24 bitowe (rozszerzenie SDCC). Wówczas aplikacja w locie przełącza banki ROM i przeładowuje bloki danych.
Dodatkowo można zrobić przełącznik sygnałów SS SPI, i wówczas można będzie strerować peryferiały, co umożliwi kobrowanie z jakimiś sterownikami.


Dobrym pomysłem będzie też dodanie zmian związanych z obsługą przerwania maskowanlego INT, które jest nieodzowne do odtwarzacza muzyki, która jest odtwarzana w tle nawet programu w BASIC.

Kolejnym krokiem do uproszczenia układu będzie doprowadzenie sygnału zegarowego z bloku wizji np. 1,6 MHz. Ma to sens w kontekście ujednolicenia brzmienia nut na wszystkich egzemplarzach kobry.

W celu poprawienia sytuacji z powtarzaniem się adresów przy komendach IN/OUT można zastąpić układ 1 z 8 na GALa, który będzie pełnym dekoderem adresów. Niewiele więcej ścieżek wyjdzie, ale będzie można mieć dużo więcej urządzeń do zaadresowania.

Dodatkowo przydałby się drugi dżojstik, aby w gry mogli grać dwaj gracze. I tym samym uzyskujemy ciekawą 8-bitową konsolę do gier oraz amatorski sterownik do zabawy.

Rozumiem, że programy korzystające tylko z podstawowego zestawu grafiki nie będą wymagały żadnych zmian i na wszystkich modyfikacjach będą działały jednakowo.

zdzis_ek napisał:

Ja natomiast chciałem się dopytać w innej sprawie, rozrysowałem organizację pamięci w Cobrze1 color i w Cobrze1 color Dual-Ram.
Wygląda na to, że wszystkie napisane wsady do tej pory na Cobre1 przestaną działać.

Na to wygląda , ale szczęśliwie jesteśmy z DualRam dopiero a etapie konceptu.
Jakie macie pomysły w kwestii , gdzie umieścić ten obszar w pamięci.
Mam na to kilka pomysłów , ale najpierw chciałbym zobaczyć Wasze propozycje, możliwe , że błądzę

sq2bvn napisał:

Moja sugestia jest taka, aby dodać natywny interfejs SPI obsługi kart SD. W takim przypadku z poziomu aplikacji będzie możliwe ładowanie kolejnych GZ i GRAM z karty SD.

Jak naj bardziej , ale nie ma jeszcze oprogramowania do obsługi karty SD i systemu plików .

sq2bvn napisał:

Kolejnym krokiem do uproszczenia układu będzie doprowadzenie sygnału zegarowego z bloku wizji np. 1,6 MHz. Ma to sens w kontekście ujednolicenia brzmienia nut na wszystkich egzemplarzach kobry.

sq2bvn napisał:

W celu poprawienia sytuacji z powtarzaniem się adresów przy komendach IN/OUT można zastąpić układ 1 z 8 na GALa, który będzie pełnym dekoderem adresów. Niewiele więcej ścieżek wyjdzie, ale będzie można mieć dużo więcej urządzeń do zaadresowania.

Jak to widzisz ?
Masz propozycję w postaci tabeli prawdy ?

sq2bvn napisał:

Dobrym pomysłem będzie też dodanie zmian związanych z obsługą przerwania maskowanlego INT, które jest nieodzowne do odtwarzacza muzyki, która jest odtwarzana w tle nawet programu w BASIC.

O jakich zmianach myślisz ?
Już teraz można pisać programy z obsługą przerwań , obiecałeś player
Problem jest Basicem , trzeba by go przekompilować tak, aby ładował się np. pod adresem 100h.