Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Texa PolandTexa Poland
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Mikrokomputer COBRA 1

coberr 05 Mar 2021 14:35 171522 707
  • #691
    sq2bvn
    Level 12  
    zdzis_ek wrote:
    Czyli chodzi o 4K :)


    Jak to zrobić? Taka rozdzielczość byłaby lepsza od Commodore C64, który miał "zaledwie" 40×25 znaków.
  • Texa PolandTexa Poland
  • #692
    sq2bvn
    Level 12  
    Sprawa wyjaśniona.
    COBRA1 która ma generator znaków MCY7304 miała 64 znaki i były to literki. W praktyce było możliwe wyświetlenie tylko liter i cyfr.
    W generatorze nie widzę czarnej spacji więc tu nie było możliwości pokazania semigrafiki 24x32. No chyba, że zakombinuje się z gwiazdkami... ale to mocno naciągane.

    Wszystko wskazuje, że wpisanie jednej z wartości

    1, 1+64, 1+128, 1+192

    powodowało wyświetlenie tego samego znaku na ekranie. Z tabelki wynika, że byłby to znak "A".

    Mikrokomputer COBRA 1

    Dopiero COBRA1 która miała generator znaków z EPROM 2716 mogła mieć już znaki z kombinacją kwadracików o 4-bitowych bokach (sugerowane przez artykuł AV) i to dawało możliwość wyświetlenia grafiki budowanej na zasadzie podmiany znaków w tej samej komórce, np. wyświetlenie semipiksela (o boku 4 piksele) w obszarze (0,0) do (1,1) uzyskiwane było wstawienie poprzez wymianę znaku o adresie 0 na odpowiedni w danej sytuacji. Dzięki temu w BASIC możliwe stało się rysowanie linii składających się z semipikseli (o boku 4 piksele). Stąd wynika czemu w AV pisali o powiększeniu 2 ray rozdzielczości (ale mowa tam jest o rozdzielczości semigraficznej). Jako wzory AV podaje znaki specjalne z ZX81. I z tego powodu AV pisze o semirodzielczości 48x64. Więc COBRY1, które korzystają z 2716 - już są rozszerzone i już nic nie trzeba robić.

    Mikrokomputer COBRA 1 Mikrokomputer COBRA 1

    Odcienie szarości możliwe dzięki zastosowaniu "szachownic" w semipikselach.

    Dodatkowo w książce o BASIC jest zestaw znaków do semigrafiki chyba 3 x 2 (piksele), ale co ciekawe na jeden znak 2x3 semipiksele. I tu wdaje się, że były po 2 piksele przerwy do następnych semipokseli w sąsiednim znaku... I tu w kratownicy naciągana rozdzielczość semigraficzna byłaby 48x96 semipikseli.

    Mikrokomputer COBRA 1


    Pozostaje pytanie czemu autorzy COBRA1 nie zdecydowali się na dodanie zwyczajnego trybu graficznego? Rzeczywisty tryb graficzny jest jest możliwy do uzyskania w prosty sposób i wówczas byłaby sytuacja, że 1 semipiksel równy jest 1 rzeczywistemu pikselowi. Czyli 192x256.

    Swoją drogą czy jest gdzieś dostępny program do robienia swoich znaków dla COBRA1 jak tu?

    Mikrokomputer COBRA 1

    Zwiększenie rozdzielczości i tym samym ilości znaków też jest łatwe do zrobienia. Oczywiście w osi OY ogranicza nas te 625 linii jakie są dostępne w monitorach composite-video oraz możliwości samego kineskopu w osi OX (większość kolorowych telewizorów miała maskownicę z określoną ilością szczelinek...). Monitory monochromatyczny bez maskownikcy w kineskopie mogły wyświetlić tle zmian w linii na ile powalało pasmo i bezwładność kineskopu. Myślę, że można by zrobić wersję COBRA1, która wykorzystuje maksymalnie możliwości graficzne tego typu monitora lub jak ktoś nie ma monitora video-grabbera na USB ;) Chyba sensowny tryb graficzny (nie semi) byłby 384x512 oraz 48x64 znaki w trybie tekstowym...
  • #693
    andrzejlisek
    Level 28  
    Tryb tekstowy wydaje się być łatwiejszy w realizacji, ale też w obsłudze, umożliwienie obsługi grafiki wymagałoby paru dodatkowych układów. Pewnie autorzy założyli, że do domowych zastosowań wystarczy tryb tekstowy, tym bardziej, że miał to być komputer do samodzielnego montażu.

    Co do semigrafik i ZX81, to jedno drugie wyklucza. W Cobra, jak sam piszesz, są 64 znaki 3x2 używane do operacji rysunkowych w Basic w kodach od 128 do 191. Natomiast w ZX81 jest 128 znaków, a potem powtórzony zestaw w negatywie. Dlatego wystarczy 8 znaków 4x4, bo negatyw uzupełnia drugie 8 i jest komplet. W takim razie, albo semigrafika, albo ZX81. Czy może było jeszcze inaczej?

    Ciekawi mnie, czy da się zrealizować grafikę w następujący sposób: Pierwsza rzecz to taka, że jako generator znaków byłaby używana pamięć RAM, do której przy starcie kompa byłaby kopiowana zawartość z pamięci ROM. Potem programowo możnaby modyfikować tą pamięć, a później ponownie skopiować do niej pamięć ROM tak samo, jak było to możliwe w trybie tekstowym MS-DOS na PC. Można albo przez podłożenie innej pamięci ROM, albo przez odpowiednie zapełnienie RAM wprowadzić semigrafiki dzielące znak na 8 subpikseli (dla znaku 8x8 pikseli są 4 możliwości podziału). Grafikę można uzyskać poprzez wyświetlanie odpowiednich znaków, jednak bez możliwości jednoczesnego wyświetlania tekstu i grafiki. Rozdzielczość zależy wyłącznie od rozdzielczości znaków na ekranie i przyjętego sposobu podziału znaku. przy rozdzielczości 32x24 możliwe są takie rozdzielczości graficzne:
    Podział 1x8: 32x192
    Podział 2x4: 64x96
    Podział 4x2: 128x48
    Podział 8x1: 256x24

    Idźmy dalej. Zauważmy, że obraz zawiera 768 znaków, czyli 3 razy 256 znaków. Gdyby pamięć RAM generatora znaków miała co najmniej 8kB (czterokrotność generatora znaków), to na monitorze można wyświetlić wszystkie znaki jak leci (czyli 3 razy iteracja po poszczególnych kodach), a grafikę robić poprzez ciągłą modyfikację generatora znaków. Jeszcze pozostaje do rozwiązania problem zmiany adresu pamięci RAM podczas odświeżania obrazu co 8 linii tekstu wykorzystując 3 obszary bądź co 6 linii tekstu wykorzystując wszystkie 4 obszary dopuszczając zakładkę.
  • Texa PolandTexa Poland
  • #694
    sq2bvn
    Level 12  
    andrzejlisek wrote:
    Tryb tekstowy wydaje się być łatwiejszy w realizacji, ale też w obsłudze, umożliwienie obsługi grafiki wymagałoby paru dodatkowych układów. Pewnie autorzy założyli, że do domowych zastosowań wystarczy tryb tekstowy, tym bardziej, że miał to być komputer do samodzielnego montażu.

    Co do semigrafik i ZX81, to jedno drugie wyklucza. W Cobra, jak sam piszesz, są 64 znaki 3x2 używane do operacji rysunkowych w Basic w kodach od 128 do 191. Natomiast w ZX81 jest 128 znaków, a potem powtórzony zestaw w negatywie. Dlatego wystarczy 8 znaków 4x4, bo negatyw uzupełnia drugie 8 i jest komplet. W takim razie, albo semigrafika, albo ZX81. Czy może było jeszcze inaczej?


    Myślę, że intencją autorów w AV przywołanie znaków z ZX81 było pokazanie o które znaki chodzi... i tam były znaki zakresu 0x1-0xA oraz kilka innych znakków wyżej 0x80-0x8A. (kodowanie niezgodne z ASCII) Tam raczej chodziło o wyjaśnienie o jakie to znaki chodzi - które to miały w spektakularny sposób zwiększyć możliwości semigraficzne COBRY.

    Dodano po 10 [minuty]:

    andrzejlisek wrote:
    Ciekawi mnie, czy da się zrealizować grafikę w następujący sposób: Pierwsza rzecz to taka, że jako generator znaków byłaby używana pamięć RAM, do której przy starcie kompa byłaby kopiowana zawartość z pamięci ROM. Potem programowo możnaby modyfikować tą pamięć, a później ponownie skopiować do niej pamięć ROM tak samo, jak było to możliwe w trybie tekstowym MS-DOS na PC. Można albo przez podłożenie innej pamięci ROM, albo przez odpowiednie zapełnienie RAM wprowadzić semigrafiki dzielące znak na 8 subpikseli (dla znaku 8x8 pikseli są 4 możliwości podziału). Grafikę można uzyskać poprzez wyświetlanie odpowiednich znaków, jednak bez możliwości jednoczesnego wyświetlania tekstu i grafiki. Rozdzielczość zależy wyłącznie od rozdzielczości znaków na ekranie i przyjętego sposobu podziału znaku. przy rozdzielczości 32x24 możliwe są takie rozdzielczości graficzne:
    Podział 1x8: 32x192
    Podział 2x4: 64x96
    Podział 4x2: 128x48
    Podział 8x1: 256x24


    Właśnie o tym myślałem pisząc, o tym czemu nie wprowadzono realnego trybu graficznego.

    Najłatwiej (tak mi się wydaje) jest zrobić tak :
    1. EPROM generatora zrównoleglić pamięcią RAM;
    2. Zastosować sterowany przełącznik jak jest do przełączania banków, ale do wyboru banki EPROMy/RAM
    3. Po wejściu do trybu graficznego (przestawianie przełącznika wyboru banków) zapisać do pamięci znaków 6116 wartości kolejno od 0x0 do 0xff
    4. Do RAM wpisywać wartości pixeli...

    I mamy tryb graficzny 192x256.

    Możliwe, że coś tu byłoby do poprawki, ale zgrubnie kierunek byłby dobry.

    Większa realna rozdzielczość to więcej pamięci i poprzepinać częstotliwości na dzielnikach - też do zrobienia.

    Dodano po 2 [minuty]:

    andrzejlisek wrote:
    Idźmy dalej. Zauważmy, że obraz zawiera 768 znaków, czyli 3 razy 256 znaków. Gdyby pamięć RAM generatora znaków miała co najmniej 8kB (czterokrotność generatora znaków), to na monitorze można wyświetlić wszystkie znaki jak leci (czyli 3 razy iteracja po poszczególnych kodach), a grafikę robić poprzez ciągłą modyfikację generatora znaków. Jeszcze pozostaje do rozwiązania problem zmiany adresu pamięci RAM podczas odświeżania obrazu co 8 linii tekstu wykorzystując 3 obszary bądź co 6 linii tekstu wykorzystując wszystkie 4 obszary dopuszczając zakładkę.


    Dokładnie tak - to jest sposób na proste uzyskanie pełnej grafiki w COBRA.
    Na podobnej zasadzie była robiona grafika i innych komputerach tej kategorii (C64, Atari800, Spectrum itd).

    Dodano po 46 [minuty]:

    andrzejlisek wrote:
    Ciekawi mnie, czy da się zrealizować grafikę w następujący sposób: Pierwsza rzecz to taka, że jako generator znaków byłaby używana pamięć RAM, do której przy starcie kompa byłaby kopiowana zawartość z pamięci ROM. Potem programowo możnaby modyfikować tą pamięć, a później ponownie skopiować do niej pamięć ROM tak samo, jak było to możliwe w trybie tekstowym MS-DOS na PC. Można albo przez podłożenie innej pamięci ROM, albo przez odpowiednie zapełnienie RAM wprowadzić semigrafiki dzielące znak na 8 subpikseli (dla znaku 8x8 pikseli są 4 możliwości podziału). Grafikę można uzyskać poprzez wyświetlanie odpowiednich znaków, jednak bez możliwości jednoczesnego wyświetlania tekstu i grafiki. Rozdzielczość zależy wyłącznie od rozdzielczości znaków na ekranie i przyjętego sposobu podziału znaku. przy rozdzielczości 32x24 możliwe są takie rozdzielczości graficzne:
    Podział 1x8: 32x192
    Podział 2x4: 64x96
    Podział 4x2: 128x48
    Podział 8x1: 256x24


    Czy możesz bardziej szczegółowo rozwinąć tan algorytm? Nie mam pewności czy właściwie to rozumiem. Bo moja metoda pozwoli chyba na wyświetlenie pierwszych 256 bajtów grafiki.... pozostałe nie będą widoczne bo komórki pamięci obrazu są 8 bitowe, udałoby się to jakby te komórki były 16 bitowe. Potrzeba 3 X RAM 6116 by wyświetlić grafikę inną dla każdego z 768 znaku widocznego na ekranie
  • #696
    andrzejlisek
    Level 28  
    sq2bvn wrote:
    andrzejlisek wrote:
    Ciekawi mnie, czy da się zrealizować grafikę w następujący sposób: Pierwsza rzecz to taka, że jako generator znaków byłaby używana pamięć RAM, do której przy starcie kompa byłaby kopiowana zawartość z pamięci ROM. Potem programowo możnaby modyfikować tą pamięć, a później ponownie skopiować do niej pamięć ROM tak samo, jak było to możliwe w trybie tekstowym MS-DOS na PC. Można albo przez podłożenie innej pamięci ROM, albo przez odpowiednie zapełnienie RAM wprowadzić semigrafiki dzielące znak na 8 subpikseli (dla znaku 8x8 pikseli są 4 możliwości podziału). Grafikę można uzyskać poprzez wyświetlanie odpowiednich znaków, jednak bez możliwości jednoczesnego wyświetlania tekstu i grafiki. Rozdzielczość zależy wyłącznie od rozdzielczości znaków na ekranie i przyjętego sposobu podziału znaku. przy rozdzielczości 32x24 możliwe są takie rozdzielczości graficzne:
    Podział 1x8: 32x192
    Podział 2x4: 64x96
    Podział 4x2: 128x48
    Podział 8x1: 256x24


    Czy możesz bardziej szczegółowo rozwinąć tan algorytm? Nie mam pewności czy właściwie to rozumiem. Bo moja metoda pozwoli chyba na wyświetlenie pierwszych 256 bajtów grafiki.... pozostałe nie będą widoczne bo komórki pamięci obrazu są 8 bitowe, udałoby się to jakby te komórki były 16 bitowe. Potrzeba 3 X RAM 6116 by wyświetlić grafikę inną dla każdego z 768 znaku widocznego na ekranie


    Faktycznie, tutaj zamieszałem dwie rzeczy, jednak obie zaczerpnięte z MS-DOS (a właściwie jedna, ta pierwsza). W systemach DOS na PC domyślnym trybem jest tryb tekstowy, który zawiera 256 znaków, domyślnie każdy o rozmiarach 8x16 pikseli (w niektórych przypadkach mogą być inne). Jednakże, programowo można modyfikować same znaki. Tak na przykład jest zrobione w programie Norton Utilities dla DOS, jak wpiszesz w wyszukiwarce grafiki, to znajdziesz screeny zrobione za pomocą tak zmodyfikowanych znaków, inspirowane systemem Windows 3.1. Podobną metodą jest wyświetlane logo Energy Star i niebieski ludzik na tym filmie https://www.youtube.com/watch?v=_KthGHLcBGs .

    Jak widać, każdy znak to obrazek 8x16 pikseli, ale wciąż jest ograniczenie wyświetlania 256 różnych obrazków jednocześnie. Nie da się zrobić "pełnej" grafiki na ekranie w trybie tekstowym, to znaczy da się, ale w przypadku DOS rozdzielczość będzie ograniczona do 256x128 lub 128x256 pikseli (przy znaku 8x16 pikseli), w przypadku Cobra będzie ograniczona do rozdzielczości 8x8 pikseli i obraz będzie wielokrotnie powtórzony.

    Teraz nasuwa się pytanie: Na ile elementarnych części (gdzie każda jest biała lub czarna niezależnie od pozostałych) da się podzielić jeden znak, aby liczba wszystkich kombinacji wynosiła 256. Jest to 8 części. Znak o wielkości 8x8 pikseli można podzielić na 8 małych regularnych elementów na 4 sposoby. Tym oto sposobem możesz wygenerować zestaw znaków, które będą obrazować wszystkie możliwe kombinacje elementów dokładnie na tej samej zasadzie, jak semigrafika 3x2 w kodach od 128 do 191, bądź semigrafika 2x2 w ZX Spectrum w kodach od 0 do 15. Semigrafika 2x4 lub 4x2 ma właśnie 256 kombinacji.

    Teraz możesz przygotować sobie ROM z oryginalnym zestawem znaków oraz dodatkowe jedną czy dwie (maksymalnie 4 różne) pamięci ROM ze znakami wytworzonymi w opisany sposób. Załóżmy, że podczas pracy Cobra możesz zmieniać pamięci ROM generatora znaków. uruchamiasz komputer z generatorem alfanumerycznym czy tam z ZX81. Potem uruchamiasz program, który jest napisany pod semigrafikę. Na ekranie będzie obraz wyglądający jakby był z przypadkowych losowych znaków. Podmieniasz ROM na inny ROM z semigrafiką i masz obraz graficzny o rozdzielczości np. 64x96 pikseli i to bez żadnych przeróbek elektroniki poza wymiennymi pamięciami generatora. Będzie to wciąż tryb tekstowy, ale na przykład literze A odpowiada jeden zestaw pikseli, literze B odpowiada inny zestaw pikseli w danym znaku itd. Malowanie grafiki to tak naprawdę dobieranie wyświetlanych bajtów.
  • #697
    sq2bvn
    Level 12  
    zdzis_ek wrote:
    Ja do programowania generatora znaków używam programu "PixelFont Editor,
    Mikrokomputer COBRA 1
    do pobrania z załącznika.
    Program wczytuje pliki *.pf, ale chyba nie ma trudności zamienić *.bin na *.pf.


    Dzięki - wypróbuję.

    Swoją drogą czy dałoby się zrobić kardridża co zawiera i ROM programu i ROM generatora znaków? Wówczas byłoby możliwe tworzenie gier, które po wtyknięciu miałyby gotowy zbiór kafelków semigraficznych :)

    Dodano po 11 [minuty]:

    andrzejlisek wrote:
    Teraz nasuwa się pytanie: Na ile elementarnych części (gdzie każda jest biała lub czarna niezależnie od pozostałych) da się podzielić jeden znak, aby liczba wszystkich kombinacji wynosiła 256. Jest to 8 części. Znak o wielkości 8x8 pikseli można podzielić na 8 małych regularnych elementów na 4 sposoby. Tym oto sposobem możesz wygenerować zestaw znaków, które będą obrazować wszystkie możliwe kombinacje elementów dokładnie na tej samej zasadzie, jak semigrafika 3x2 w kodach od 128 do 191, bądź semigrafika 2x2 w ZX Spectrum w kodach od 0 do 15. Semigrafika 2x4 lub 4x2 ma właśnie 256 kombinacji.

    Teraz możesz przygotować sobie ROM z oryginalnym zestawem znaków oraz dodatkowe jedną czy dwie (maksymalnie 4 różne) pamięci ROM ze znakami wytworzonymi w opisany sposób. Załóżmy, że podczas pracy Cobra możesz zmieniać pamięci ROM generatora znaków. uruchamiasz komputer z generatorem alfanumerycznym czy tam z ZX81. Potem uruchamiasz program, który jest napisany pod semigrafikę. Na ekranie będzie obraz wyglądający jakby był z przypadkowych losowych znaków. Podmieniasz ROM na inny ROM z semigrafiką i masz obraz graficzny o rozdzielczości np. 64x96 pikseli i to bez żadnych przeróbek elektroniki poza wymiennymi pamięciami generatora. Będzie to wciąż tryb tekstowy, ale na przykład literze A odpowiada jeden zestaw pikseli, literze B odpowiada inny zestaw pikseli w danym znaku itd. Malowanie grafiki to tak naprawdę dobieranie wyświetlanych bajtów.



    Ok, bardziej myślałem o wypełnieniu pamięci RAM (6116 - jakby to było możliwe) znaków tablicą od 0 do 768 w celu uzyskania substytutu licznika wyboru kolejnego znaku-fragmentu obrazu. Wówczas w RAM 6kB można nadłożonym na ROM 2 kB wpisywać wartości pikseli do wyświetlenia - to była moja koncepcja. Możliwe, że technicznie prostsze będzie dać licznik 12 bitowy (1 scalak) liczący w kółko numer znaku dla RAMU i tyle... i byłby tryb graficzny z oddzielną pamięcią obrazu graficznego... inaczej - przełączenie się na tryb graficzny nie niszczyłoby zawartości ekranu tekstowego i odwrotnie. Czyli natywne 192x256. Można rozpatrzyć też wykorzystanie licznika, który już jest i służy do produkcji sygnału video i adresów generatora znaków - to od ręki rozwiązałoby problem synchronizacji... z video..


    Coś jak w Linux - konsola X nie koliduje z konsolami tekstowymi agetty... ;)

    Dodano po 23 [minuty]:

    andrzejlisek wrote:
    Teraz nasuwa się pytanie: Na ile elementarnych części (gdzie każda jest biała lub czarna niezależnie od pozostałych) da się podzielić jeden znak, aby liczba wszystkich kombinacji wynosiła 256. Jest to 8 części. Znak o wielkości 8x8 pikseli można podzielić na 8 małych regularnych elementów na 4 sposoby. Tym oto sposobem możesz wygenerować zestaw znaków, które będą obrazować wszystkie możliwe kombinacje elementów dokładnie na tej samej zasadzie, jak semigrafika 3x2 w kodach od 128 do 191, bądź semigrafika 2x2 w ZX Spectrum w kodach od 0 do 15. Semigrafika 2x4 lub 4x2 ma właśnie 256 kombinacji.


    Przedstawiony sposób wciąż wygląda na protezę trybu graficznego, czyli semigrafikę. A ja myślę o natywnej grafice, aby odtwarzać np. animacje w formacie FLI. Tak jak to było na pierwszych PC. Wiadomo COBRA nie ma takiego RAM by pomieścić tyle klatek,ale ... można dać kardridge z kartą SD, a tam pamięci ile chcesz a i sama COBRA poradzi sobie z SPI... do karty... Myślę, że taka semigrafika + demoniczna prędkość COBRY nie da fajnych wyników.. Swoją drogą czy w ogóle istnieje taka biblioteka, która wstawia właściwe numery obrazków adekwatnie do x,y nowego piksela i bieżącej sytuacji na ekranie?
  • #699
    sq2bvn
    Level 12  
    zdzis_ek wrote:
    Potrzeba jest zbudowania innego układu wyświetlania obrazu.
    Podpowiedź jest na tym obrazku


    Po głębszych rozważaniach stawiam tezę, że zrobi się to dodając do układu dodatkową pamięć RAM 8kB oraz kilka bramek ;) Szkoda, że mam ograniczony czas bo bym udowodnił, że to możliwe jeśli ktoś się założy ha ha ha To można zrobić przy pomocy kabelków z krokodylkami. Niestety nie mam takich krokodylków malutkich. Ale mogę przygotować pseudoschemat jak to zrobić.
  • #700
    andrzejlisek
    Level 28  
    sq2bvn wrote:
    Przedstawiony sposób wciąż wygląda na protezę trybu graficznego, czyli semigrafikę. A ja myślę o natywnej grafice, aby odtwarzać np. animacje w formacie FLI.

    Zawsze jest coś kosztem czegoś. Albo taka proteza zrealizowana poprzez możliwie najmniejszą ingerencję w sprzęt i oprogramowanie, albo tryb graficzny z prawdziwego zdarzenia, w którym trzeba przerobić układ wyświetlania, a także zrealizować w jakiś sposób dostęp do pamięci graficznej, która przy rozdzielczości 256x192 ma 6kB, a więc 8-krotność obecnej pamięci dla trybu tekstowego.

    Kilkanaście lat temu jeszcze lubiłem system DOS i pamiętam Turbo Pascal. Poczytałem w internecie, jak zmodyfikować znaki w trybie tekstowym, wystarczyły do tego małe wstawki w asm, podobnie, jak uzyskanie wszystkich 16 kolorów tła znaku. Porobiłem parę eksperymentów, jednym z nich była właśnie próba zrealizowania trybu pseudograficznego w trybie tekstowym. Potem namalowałem prosty rysunek o rozdzielczości chyba 160x100 w Paint z paletą 16 kolorów i zapytałem się kolegi, czy da się taki obraz wyświetlić w trybie tekstowym DOS. Powiedział, że się nie da, a się dało i to bez trybów graficznych. Właśnie ten eksperyment był inspiracją dla przedstawienia pomysłu z wykorzystaniem generatora znaków.
  • #701
    sq2bvn
    Level 12  
    Na pseudoschemacie zawarłem ideę generowania obrazu graficznego, jak widać, nie ma zbyt wiele dodatkowych komponentów. Jeśli trzeba kolory, na podobnej zasadzie można dodać tyle kolorów ile się chce.

    Mikrokomputer COBRA 1


    Jest zmiana w adresowaniu GRAM, bo pełen adres przychodzi od CPU lub od liczników.
    A0 i A2 od liczników są wolniejsze od A3 o (chyba) 24 razy.

    Kiedy M1 jest aktywne, na wyjściu pamięci GRAM jest wartość pikseli i to zatrzaskujemy - 165 przerzuca to gęsiego do kineskopu. Kiedy M1 jest nieaktywne CPU może zaadresować GRAM 8K i wpisać tam piksele.

    Sygnały RW, RD, OE podobnie jak w pamięci RAM generatora znaków.
    Oczywiście można GRAM podpiąć pod przełącznik banków.
    Przejście na GRAM też powinno dołączać wyjście 74LS165 do bramki 27(5). Przekaźnik, 2 bramki AND z inwerterem albo coś tam...

    To wszystko. Proste jak budowa cepa ;)


    Można mieć też 1 kość RAM na znaki i GRAM ale wówczas wyjdzie wielki przełącznik - najlepiej na GALu

    Dodano po 1 [godziny] 4 [minuty]:

    andrzejlisek wrote:
    Powiedział, że się nie da, a się dało i to bez trybów graficznych.


    Wszystko się zgadza. W przypadku COBRA ROM gz jest jakby podpamięcią RAM znaków.
    Wystarczy adresy inaczej popodłączać i jest...gotowe. Jakbym miał tyle czasu, zrobił bym nową wersję PCB z takimi zmianami, ale na razie kiepsko czasem... :(
  • #702
    zdzis_ek
    Level 15  
    Tak się tylko zastanawiam, kto napisze do tego oprogramowanie ?
    Jak znam życie a trochę znam, to nie widzę chętnych.
    Basic tego pewnie nie ruszy, on ma swoją semigrafikę.
    Ja sam napisałem kilka programów, może kilkanaście, ale w Basic.
    Do Asemblera już nie wrócę.
    Ile osób do dzisiaj napisało programy na Cobrę 1 na przestrzeni tych kilkudziesięciu lat ?
  • #703
    sq2bvn
    Level 12  
    zdzis_ek wrote:
    Tak się tylko zastanawiam, kto napisze do tego oprogramowanie ?


    Z oprogramowaniem nie będzie problemu, bowiem planuję przygotować takie środowisko programistyczne jak jest do Arduino. Eclipse, sdcc i ewentualnie jakiś debug. Wszystko ładowane przez kabel - gdzieś widziałem taki kartridż który umożliwia pracę na RAM zdalnie i odpalanie testowych aplikacji dla Cobra 1. Do tego jakieś skromne API i będzie dobrze.

    zdzis_ek wrote:
    Ile osób do dzisiaj napisało programy na Cobrę 1 na przestrzeni tych kilkudziesięciu lat ?


    Brak danych, ale jak będzie IDE jak dla Arduino może będą jednak pisać. Tym bardziej, że można zrobić wersję z procem 30 MHz... więc jako zabawka nie będzie gorsza od Arduino. Jest dźwięk, ekran, dżojstyk, magnetofon, klawiatura, BASIC, historia... które to Arduino jest tak bogate?
    Do tego można dodać nowe rzeczy - karty SD, i2C, wyświetlacze - wszystko przez to 50 pin gniazdo.... tak jak ma Arduino i Rasbery PI - takie Cobra haty... shieldy czy jak kto woli. Z tego powodu wyprowadziłem wszystkie sygnały na moją wersję kardridża....

    Basic też można zrobić z PC... Linia po linii pisać w IDE i konwertować na bin i pchać do RAM tak jakby to było wklepywane z Cobrowej klawiatury...

    Jestem optymistą w tym zakresie...;)

    Zalążek API już jest w jakiejś tam grze, którą widziałem w wątku, resztę zassać z innych kompów i będzie. Sporo jest C procedur i funkcji na gotowo. Myślę, że to może być fajna platforma... jak piszą na Arduino, gdzie nie ma nic na płytce, to czemu nie mają robić na kobrę skoro jest tak fajnie wyposażona?
  • #704
    coberr
    Level 19  
    sq2bvn wrote:
    Myślę, że to może być fajna platforma...


    wszystko to racja co piszesz ale niestety dzisiaj królują durne atmegi... ew.
    STMy i inne wynalazki i nie ma sie co dziwić.
    Ja sam troche odszedłem narazie od Z80 i rozpracowuję CHorego TMSa (Tyle , że on jest 32 bitowy) - nie wiem co mnie wzięło na ten procek - może sentyment do starszych wersji, w których kiedyś troche grzebałem...

    W assemblerze dzieci juz nie bardzo chcą pisać...
    To tylko takie dinozaury jak my - cos tam jeszcze dlubią...
    Generalnie wszystko schodzi "na psy".
    Na Z80 ostatni raz pisałem w assemblerze chyba proste programy do testowania niektórych elementów systemu.
    do "C" jakoś nie mogę sie przekonać - no kurcze jakoś mi on "nie wchodzi" mimo szczerych chęci :)...
    Jedyne co to assembler :)
  • #705
    sq2bvn
    Level 12  
    coberr wrote:
    W assemblerze dzieci juz nie bardzo chcą pisać...
    To tylko takie dinozaury jak my - cos tam jeszcze dlubią...
    Generalnie wszystko schodzi "na psy".


    coberr wrote:
    do "C" jakoś nie mogę sie przekonać - no kurcze jakoś mi on "nie wchodzi" mimo szczerych chęci :)...
    Jedyne co to assembler :)


    Myślę, że C dla kobry to dobry pomysł i nowe otwarcie.
    Masz szansę się przekonać :) Można zrobić nawet parę artykułów o Cobra C do jakiegoś AVT albo coś takiego. Również o tym jak do C robić wstawki asemblerowe.
    To może być hicior - myślę sobie. Teraz jest lokdałn więc siedzą w blokach i z pewnością nowe zabawki przydadzą się.

    Tak jak świeże Z80, chyba nawet do 50 MHz chodzą...

    Swoją drogą nawet komodory się sprzedaje...
    https://www.mediaexpert.pl/gaming/pozostale-p.../pozostale-konsole/konsolka-commodore-64-maxi
    Więc czemu nie CobraMAXI?

    Dodano po 54 [minuty]:

    sq2bvn wrote:


    Mikrokomputer COBRA 1



    Co to za okienko?
  • #706
    coberr
    Level 19  
    sq2bvn wrote:
    Co to za okienko?


    to jest menu cartdridge'a kol. Zdzis_ek. + oczywiście program do edycji (obrazowania) fontów - bodajże pixel font editor.

    co do "c" - tutaj guru w tej dziedzinie jest Andrzejlisek - On moze i mogłby jakies artykuły napisać :).

    Z80 jest fajny - ma swój urok - aż miło sie patrzy na takie płytki upstrzone scalakami no ale cóz z tego?
    dzisiaj dzieci głownie w telefonach siedzą i nie mają ochoty za bardzo poznawać nic wiecej...
  • #707
    sq2bvn
    Level 12  
    coberr wrote:
    to jest menu cartdridge'a kol. Zdzis_ek. + oczywiście program do edycji (obrazowania) fontów - bodajże pixel font editor.


    Caption jest: Generator Ekranu Cobra...

    Czy istnieje gdzieś dostępny program do tworzenia tych ekranów Cobra?

    Dodano po 1 [minuty]:

    coberr wrote:
    Z80 jest fajny - ma swój urok - aż miło sie patrzy na takie płytki upstrzone scalakami no ale cóz z tego?


    Na stronie Ziloga są nowe wersje, można robić również na świeżych układach.
  • #708
    sq2bvn
    Level 12  
    Wizja CobraIDE stała się faktem. Mam już cały plan co i jak ma być zrealizowane. Kiedy zakończę prace - zaprezentuję wyniki na forum.