Mikrokomputer COBRA 1

Filmik jest autentyczny.
Filmowałem smart-fonem, specjalnie zrobiłem sobie pod niego podstawkę.


Jedyna ingerencja była w wycinaniu 3 klatek filmu z "dropami" między zmianami plansz, czyli pełnych obrazów.
Czynione to było w celach marketingu
Ale i tak zawiodłem się na tym youtube, ten filmik, który im przesłałem miał o wiele lepszą jakość.
Wyszło jak wyszło, ale można przesyłać pliki dużej pojemności.
Elektroda ogranicza ich wielkość.
Jeżeli filmuję coś w rozdzielczości HD, to mogę przesyłać filmy tylko krótkie, albo zrobić je w niższej rozdzielczości.
Chciałem pokazać wszystkie programy jakie pokolorowałem.
Wyszło jak wyszło.
Teraz przesyłam filmik nieco krótszy, ale chyba w lepszej jakości i bez wycinanych trzech klatek.
Porównując filmiki z rzeczywistością, to filmiki są do kitu, rzeczywiste kolorowe obrazki są o "niebo lepsze"
A teraz filmik, który "łyknie" elektroda:

Jak wiadomo pole obrazu zajmuje obszar F800h - FB00 , natomiast pole atrybutów umieściłem pod FC00h - FF00h.

Znakowi pod F800h odpowiada atrybut koloru w komórce FC00h, F801h - FC01h , F802h - FC02h i.t.d.

Struktura bajtu atrybutu :

Z zasady jest podobnie jak w ZX Spectrum , ale nie ma migania. W zamian a to tło jak i znak może przyjąć jedną z szesnastu barw .

wartości kolorów dla normalnej jasności w hex:

8 - czarny
9 - niebieski
A - czerwony
B - magenta
C - zielony
D - błękitny
E - żółty
F - biały

Dla obniżonej jasności :

0 - czarny
1 - niebieski
2 - czerwony
3 - magenta
4 - zielony
5 - błękitny
6 - żółty
7 - szary

Przykładowo gdy zapiszemy w komórce F800h - 41h , oraz w FC00h - ECh wyświetli się zielona litera A na żółtym tle .


Mój adapter wygląda tak:

To chyba jakiś żart aby mnie podejrzewać o manipulacje ?

Twoje osiągnięcia i prezentowane prace są niepodważalne. Podziwiam wszechstronność (hardware i software), precyzję i dokładność.
Absolutnie moje pytanie nie było podejrzeniem oszustwa, tylko próbą zrozumienia ostatnich postów. Są tam bowiem omawiane zarówno programy narzędziowe na PC wspomagające przygotowanie danych dla COBRY jak i efekty widziane na COBRZE.

atmeg8 napisał:

Z zasady jest podobnie jak w ZX Spectrum , ale nie ma migania. W zamian a to tło jak i znak może przyjąć jedną z szesnastu barw .

Z tego, co wiem, w ZX Spectrum nie było sprzętowego migania, było 16 kolorów tła i 16 kolorów znaku, ale mogę się mylić. W IBM PC było 16 kolorów znaku, 7 kolorów tła i do tego miganie. W DOS wystarczyło coś wywołać (nie pamiętam co, ale było to kilka instrukcji w ASM x86) i miało się 16 kolorów tła kosztem możliwości migania, po prostu zmieniało się znaczenie najstarszego bitu koloru tła.

Czy kolorowa cobra1 jest kompatybilna i w przód i wstecz ze standardową konstrukcją? Czy jak na kolorowej uruchomi się program ze standardowej konstrukcji to będzie działać prawidłowo, a jak na standardowej konstrukcji uruchomi się program z kolorami, to też zadziała prawidłowo, tylko, że bez kolorów?

W ZX błyskanie jest zrobione sprzętowo przez ULA .


Kompatybilność jest zachowana , ale trzeba niestety zastosować małą modyfikację monitora , pole atrybutów po resecie trzeba wypełnić 0Fh (białe znaki,czarne tło) , inaczej pojawią się kolorowe chaszcze .

Do kol. "andrzejlisek":
Czy planujesz wprowadzić do emulatora COBRY kolor ?
Ja nie czuję się na siłach aby zmodyfikować emulator.
COBRĘ posiadałem w latach 80/90 ubiegłego wieku a obecnie z sentymentem wróciłem jedynie do emulatora.
Zamieściłem w tym temacie trzy proste gry: ŻMIJA, PELOTA, TENIS i w 70% napisałem gry JUMPING JACK i WIEŻA.
Różne sprawy osobiste przerywały mi pracę i wciąż do tego wracam po dłuższym czasie, gdy od początku muszę analizować co utworzyłem kilka miesięcy wcześniej.
Możliwość dodania koloru byłoby silnym bodźcem, by od początku wrócić do rozpoczętych prac, ale już uwzględniając kolor.
Do kol. "zdzis-ek":
Mam nadzieję, że nie czujesz urazy za zadane pytanie. Nawet przez myśl mi nie przeszło, by podejrzewać manipulacje.
Było to pytanie czysto techniczne.

wieswas napisał:

Czy planujesz wprowadzić do emulatora COBRY kolor ?
Ja nie czuję się na siłach aby zmodyfikować emulator.

Na 80% tak, nawet sam pomyślałem o implementacji koloru działającego w sposób opisany przez kol. atmeg8. Dla pewności dodałbym możliwość włączenia i wyłączenia koloru na wypadek, jakby uruchamiać emulator ze standardową wersją monitora lub uruchamiać program, który korzysta z obszaru FC00h - FF00h (chociaż jest mało prawdopodobne, żeby istniał program wykorzystujący ten obszar do celów niezwiązanych z wyświetlaniem).

Muszę stwierdzić, żeby nie Twój emulator, nie stało by się to co się stało.

atmeg8 napisał:

Czy masz pod ręką dokładną specyfikację formatu FLI ?

Tak.



Dodano po 2 [minuty]:

FLI idealnie pasuje bo ma głębię kolorów 4 bit... mały ekranik i jest obsługwany przez GIMP... więc animację można tworzyć na PC... Do tego dźwięk AY...


Można zebrać wszystko razem i zrobić COBRA2... dać do gazety i za 30 lat będą ulepszać dalej hahah

Dodano po 17 [minuty]:

http://www.oldversion.com/windows/download/autodesk-animator-1-3a

Nawet program do animacji est dostępny...oczywiście dla CObRA1.

Dodano po 19 [minuty]:

W GIMP przyjemnie robi się klatki:



Dodano po 3 [minuty]:

Tu jest plik FLI:

3DS_V0..zip (135.13 kB)Musisz być zalogowany, aby pobrać ten załącznik.

Myślę, że spokojnie uda się odtwarzanie animacji bo te 0x300 bajtów to spokojnie Z80 ogarnie z tempem 10 klatek na sekundę a może nawet szybciej....

Właśnie pracuję nad emulatorem.

Próbuję coś przetestować i zauważyłem w Basic, że aby zapisać cos do adresu >32767, to od wpisanego adresu należy odjąć 65536.

Metodą prób i błędów udało mi się wypisac znak za pomocą instrukcji:
CLS
POKE -1797,33

Jednak, jak się wpisze
POKE -1798,33

to żaden znak sie nie pojawia, a teoretycznie powinien pojawić się obok.

Jak się uruchomi ten program:
10 CLS
20 POKE -1797,33
30 POKE -1798,33

To powinny pojawić się dwa wykrzykniki. Czy w prawdziwej cobrze też jest ten problem, czy jest to błąd w emulatorze?

Dzięki za pokazanie, jak się dopisze "GOTO 40" lub "INPUT X" to pojawiają się 2 wykrzykniki, czyli w emu jest dobrze.

Swoją drogą, czy jest jakaś kombinacja klawiszy, która przerywa program w Basicu? Jak są 4 linijki, to można zrestartować i jeszcze raz wprowadzić, ale jak jest dłuższy program, a pętla nieskończona wyjdzie niechcący, to tak średnio.

Zanim "wypuszczę w świat" aktualizację emulatora, proszę o kilka informacji.

Pierwszą rzeczą jest sprawdzenie poprawności koloryzacji. Do testów napisałem taki prosty program. Na początku wypełnia ekran znakami X i kolorem białym na czarnym tle. Wyświetlenie X to tylko zobrazowanie postępu, bo ta czynność trwa kilka sekund. Po naciśnięciu CR wypełnia znakami nawiasów we wszystkich możliwych kolorowaniach, reprezentowanych przez liczby od 0 do 255. Po naciśnięciu CR wypisuje białymi znakami na czarnym tle wszystkie możliwe znaki w celu zobrazowania aktualnie podłączonego generatora znaków. Na tym etapie można wpisać numer od 0 do 255 w celu wybrania generatora i nacisnąć CR. Dwukrotne podanie tego samego numeru lub naciśniecie CR bez podawania numeru kończy program.


Tak prezentuje się koloryzowanie na moim emulatorze (na razie w fazie testów, jeszcze nie wypuściłem aktualizacji). Proszę o informację, która wartość (224 lub 128 czy jeszcze inna) jest bardziej podobna do rzeczywistej realizacji? Wartość 128 jest przyjęta w Windows VGA, a w emulatorach ZX Spectrum jest wartość zbliżona do 224 (są niewielkie różnice).

Najważniejsze pytanie: Czy prawdziwy komputer po uruchomieniu tego programu wyświetla taki sam układ kolorów?

Ciemny=224


Ciemny=128


Emulator będzie miał możliwość włączenia i wyłączenia kolorów w celu zachowania wstecznej kompatybilności i z tego powodu, że nie jest to standardowa funkcjonalność Cobry. Czy przewiduje się możliwość programowego włączania lub wyłączania kolorów? Jeżeli tak, to w jaki sposób?

W swoim programie CCSE zastosowałem poziom 128 . Jest to najbardziej zbliżone do rzeczywistości , lecz nie jest kluczowe.

Jeśli chodzi o wyłączanie koloru , oraz inne sprawy z tym związane są to kwestie otwarte . Proponuję te rzeczy poddawać forumowej demokracji .

Jak możesz , prześlij mi program w basic`u , w pliku do Cobry od adr. 4000h .

Przy okazji przesyłam obrazowe przedstawienie mapy pamięci dla grafiki kolorowej :

Właśnie opublikowałem aktualizację i wersję skompilowaną na Windows. Oprócz dodania koloru dodałem losową zawartość pamięci przy inicjalizacji i parę drobnych poprawek, które uniemożliwiały uruchomienie emulatora pod Linuxem z tego kodu źródłowego.

https://github.com/andrzejlisek/Cobra1

Zawartość ROM nie jest zmieniona, czyli nie uwzględnia koloru. Ten dostarczony z emulatorem to oryginalny ROM z dodaną obsługą drukarki Mera-Błonie D-100 i zmiany wielkości liter za pomocą SH+T (rozszerzenia opisane w oryginalnym AudioVideo, wywołanie ich wplecione w pamięć ROM).

W emulatorze można włączyć lub wyłączyć kolor.

Wspaniała sprawa.
Wczytałem emulator COBRA1 - KOLOR i działa.
Ogromne podziękowania dla kol."andrzejlisek"
Pokolorowałem stronę tytułową, aktualnie pisanej gry zgodnie z wcześniej podaną paletą kolorów i nie zgadza mi się działanie opcji INWERS.
Spodziewałem się, zamiany koloru atramentu z kolorem tła. a tu mieszają się kolory:
np znak "biała fuga -atrament i czerwona cegła - tło" czyli kod F2 po zastosowaniu inwers daje "błękitną fugę - atrament i czarną cegłę - tło"

I jeszcze jedno: skoro naturalnym obrazem oryginalnej COBRY były zawsze białe litery na czarnym tle, to i w wersji kolorowej bez włączenia opcji INVERS powinien być taki wygląd

Zamieściłem obrazki dla 4 kombinacji opcji negatyw i kolory.
To są moje subiektywne spostrzeżenia, ale dostosuję się do każdej normy.

Myślę , że funkcja invers w emulatorze jak i przełącznik polaryzacji w Cobrze w przypadku zastosowania trybu koloru nie ma sensu , inwersję każdego znaku można przeprowadzić programowo , odpowiednio ustawiając atrybuty .
Przykładowo biały znak na czarnym atrybut 0Fh , czarny na białym F0h , wystarczy zamienić połówkami .
Zachowanie grafiki na przedstawionych przykładach jest prawidłowe i logiczne ,
dzieje się tak również w programie CCSE .
Jednak jak się dobrze przyjrzeć to w przedstawionych przykładach coś jest chyba nie tak, emulator prawdopodobnie przy inwersji obrazu dokonuje inwersji bitowej atrybutów .

wieswas napisał:

Pokolorowałem stronę tytułową, aktualnie pisanej gry zgodnie z wcześniej podaną paletą kolorów i nie zgadza mi się działanie opcji INWERS.
Spodziewałem się, zamiany koloru atramentu z kolorem tła. a tu mieszają się kolory:
np znak "biała fuga -atrament i czerwona cegła - tło" czyli kod F2 po zastosowaniu inwers daje "błękitną fugę - atrament i czarną cegłę - tło"

Już w zamierzchłych czasach była mowa o negatywie przy wyświetlaniu. Ja to zinterpretowałem nie jako zamiana tła i znaku, tylko jako pomalowanie tła na biało i znaku na czarno, czyli odwrócenie kolorów. Przy rozszerzeniu do 16 kolorów, naturalnym rozwinięciem jest odwrócenie koloru tła i odwrócenie koloru znaku, czyli jak kolory są ponumerowane od 0 do 15, to w negatywie będzie zastosowany kolor otrzymany poprzez odjęcie od 15 numeru koloru. Taka interpretacja negatywu pasuje do wersji czarno-białej, bo czarny ma numer 0, a biały ma numer 15.

Nic nie stoi na przeszkodzie, żebym przy okazji następnej aktualizacji dodał jeszcze jedną opcję, czyli zamianę miejscami koloru tła i pierwszego planu. Myślę, ze to się uda za kilka dni, równolegle dyskutuję na PW z kolegą atmeg8 na temat generatora znaków w pamięci RAM.

wieswas napisał:

I jeszcze jedno: skoro naturalnym obrazem oryginalnej COBRY były zawsze białe litery na czarnym tle, to i w wersji kolorowej bez włączenia opcji INVERS powinien być taki wygląd

Na ten problem zwrócił atmeg8 w poście #996. Właśnie z tego powodu, od tej wersji emulatora, po zerowaniu wypełniam losowymi bajtami zamiast zerami. Jeżeli obszar odpowiadający za kolory jest wypełniony innymi wartościami niż 0xAF, to siłą rzeczy, nie będą to białe znaki na czarnym tle przy włączonym kolorze. Obsługiwanie jakiejś funkcjonalności w emulatorze to jedno, a przygotowanie programu monitora dla kolorowej wersji cobry to drugie. Nie wykluczam, że wprowadzę taką modyfikację wraz z następną wersją emulatora. A może ktoś już takiej modyfikacji dokonał i pozostaje tylko zaktualizować ROM? W projekcie emulatora udostępniam pierwotny obraz ROM, jedynie rozszerzony o możliwość zmiany wielkości liter i drukowanie z Basica na drukarce D-100. Te dwa rozszerzenia są opisane w AudioVideo.

A jeżeli ktoś chce docelowo korzystać z innego ROM niż ten, który ja udostępnia, to moje modyfikacje tego ROM nie mają dla niego znaczenia, bo wtedy to ten inny ROM musi być odpowiednio zmieniony, aby poprawnie wyświetlał kolor.

Niezgodność kolorów na zamieszczonych obrazkach wynikła z faktu, że kolorowanie zacząłem zaraz po zapowiedzi nowego emulatora pracującego w kolorze, na podstawie podanej palety kolorów oraz infornacji, że pierwsza cyfra atrybutu znaków koduje ATRAMENT, a druga cyfara TŁO.
Domyślnie przyjąłem brak włączenia opcji negacja.
Nie ma żadnego problemu, abym przekodował kolory do przyjętego systemu kodowania.
Ważne aby emulator był kompatybilny z systemem zastosowanym hardwarowo przez wiodących użytkowników.

W załączniku przesyłam wsad z pokolorowanymi programami.
Są dwa wsady, jeden sterowany z gniazda cartridge, drugi z płyty głównej.
W katalogach spakowanych plików znajduje się też nowy wsad do generatora semigrafiki.
Wsad może posłużyć do testowania emulatora.

Walczę na tą chwilę z uruchomieniem Cobra DOS.

Czy uruchamiam bez cartridge'y, czy z nim - ekran zalewa fala liter "ó".

Na cartridge'u nie zapala się dioda LED.
Dioda LED zapala się podczas naciskania przycisku Reset.
Przycisk Reset nie resetuje Cobry.
Cartridge inne z oprogramowaniem działają prawidlowo

ATmega programowałem TL866-II.

Może kolega Coberr coś podpowie

Może jest problem z fuseBit'ami , załaduj Atmegę z pliku , który dołączam , załaduj jako Project do TL866-II.
Cdos.rar (23.24 kB)Musisz być zalogowany, aby pobrać ten załącznik.

Też uważam, że problem może być z tymi fusami, po wypiciu kawy zostają same fusy i w zasadzie nikt ich nie lubi
Ale ja w innej sprawie.
Kolorując programy przyjąłem trochę błędnie zasadę, że najpierw wrzucam obraz na ekran od adresu F800 h a zaraz po nim wrzucam od adresu FC00 h atrybuty koloru dla tego obrazu.
Jeżeli mamy Cobrę kolorową to nie robi taka kolejność żadnej szkody, mamy i obraz monochromatyczny i obraz kolorowy wyświetlany prawidłowo.
Natomiast dwa nowe programy znajdujące się w tym wsadzie kolorowane są inaczej.
Najpierw atrybuty, później obrazek.
Tak obecnie wyświetlany jest ten wsad na Cobrze monochromatycznej.

Niestety zaprogramowane powyższym projektem i... Brak reakcji...

Wrzucam foto cartridge'a... Może jest tu jakiś błąd...

Dla kompatybilności trzeba przyjąć kolejność : atrybuty , obraz.
To dla tego , że w przypadku Cobry mono oba obszary adresowe nakładają się .
Jak zrobisz odwrotnie to na obrazie będziesz widział wartości atrybutów.

A w kwestii kawy i fusów rozwiązaniem jest dobry ekspres

atmeg8 napisał:

To dla tego , że w przypadku Cobry mono oba obszary adresowe nakładają się .

Jak to? Gdyby założyć, że ekran mieści 1024 znaki, to jeden obszar to F800-FBFF, drugi to FC00-FFFF, jak widać, obszary nie zazębiają się. A w rzeczywistości obszar ekranu to 768 bajtów (po 32x24 znaki), co sprawia, że kolory są w F800-FAFF, a znaki w FC00-FEFF, więc tym bardziej są to obszary rozłączne. W związku z powyższym, dlaczego zapisywanie kolorów miałoby mieć wpływ na wyświetlany obraz, skoro w wersji mono pamięć RAM w obszarze F800-FAFF nie jest do niczego wykorzystywana przy wyświetlaniu?

Zrobione.
Problem tkwił w sygnałach WR i WR(z kreska)
Na PCB są dwa osobne... Na płytce pod ze złączem cartridga, są dwa identyczne oznaczenia (bez kreski)... Zamieniłem je miejscami i zadziałało

Zdzis_ek ostrzegał mnie, iż projekt płytki pod złącze cartridga było do dużo starszej rewizji PCB... Miał rację

Piszę taką prostą grę w kolorach.
Postanowiłem zmianę planszy dokonać przez przewijanie.
Na emulatorze to dość ładnie wygląda, bo obraz jest czysty.
Cobra1 jak wiadomo śmieci na ekranie przy większych zmianach obrazu.
Tutaj dołożył się jeszcze kolor i wychodzi to jeszcze gorzej.
Zobaczcie sami:

Chyba będę musiał wrócić do prostej zmiany obrazów.