microgeek.eu

Witam Szanownych Użytkowników Forum,

Obserwując z coraz większą uwagą dyskusję postu Kolegi Tapy wokół systemu CpM (który niedawno został systemem open source) oraz Kolegi Gawła postanowiłem przedstawić co nieco nt.koncepcji takiego własnego minikomputera, nad którym prywatnie dłubie sobie we własnym warsztacie. Nie jest to co prawda jakaś super nowa koncepcja, ani jakieś ekstra nowe podejście. Cele jakie mi przyświecały kiedy do tego siadałem (po raz drugi, bo po raz pierwszy to kiedyś pisałem już o podobnej koncepcji na forum) to były:
- żeby projekt był na tyle uniwersalny żeby każdy dobrał sobie części z własnego warsztatu
- żeby projekt udźwignął bios i system, który pozwoli na działanie pełnej jednostki komputerowej (motherboard, karta graficzna, i etc.inne karty rozszerzeń)
- żeby był względnie prosty konstrukcyjnie i był możliwy do zbudowania nawet przez kogoś niespecjalnie zaawansowanego w sprawach czy to elektronicznych, informatycznych i innych technicznych (taki projekt, żeby każdy mógł sobie dobrać poziom zaawansowania konstrukcji docelowej=hardware'u LUB budować jednostkę komputerową na bazie modułów)

No i ostatni cel - NAJWAŻNIEJSZY (zwłaszcza w dobie różnorodnych, durnorakich nieraz licencji, które niczym ośmiornica oplatają ramionami i krępują rozwój nauki i wiedzy):
ŻEBY BYŁ:
1. DARMOWY - FREEWARE
2. OTWARTOŹRODŁOWY - OPEN SOURCE
3. MODYFIKOWALNY BEZ ZAWRACANIA SOBIE GŁOWY TYPEM LICENCJI (czyli że: chcesz żeby korzystać z tego dalej na zasadach freeware i open source - pięknie i to pochwalam, ale chcesz robić na tym kasę i sprzedawać to - też nie widzę problemu, ACZKOLWIEK liczyłbym na wzmiankę nawet w projekcie komercyjnym SKĄD pochodzi jego źródło, na czym oparty - nie chodzi tu stricte o TEN projekt, tylko o to, że do jego stworzenia użyłem JUŻ GOTOWYCH koncepcji ogólnie znanych, a czasem koncepcji osób, które obserwują nasz ziemski świat z innej perspektywy, z tamtego świata rzeczy nieznanych do którego prowadzą drzwi, które każdy w końcu przekracza - parafrazując słowa zespołu "The Doors")
Jest taki typ licencji, bardzo ciekawy, mianowicie WTFL czy jakoś tak i chyba to byłaby najlepsza opcja.

W następnym poście poniżej postaram się przedstawić szczegóły bardziej techniczne.

Pozdrawiam! J23 Jarek

Zacna koncepcja. Fajnie by było połączyć siły i popracować razem. Szczerze mówiąc, to już od jakiegoś czasu coś podobnego krąży mi po głowie. Nawet więcej, przeszło do fazy działania. Moim celem w pierwszym rzucie jest zbudowanie coś na kształt CA80, ale z użyciem procka Motoroli, czyli CA68. Ten procek ma kilka fajnych myków, które uważam, że byłyby ciekawe do zastosowania, o czym będę jeszcze pisał.

gaweł pisze:Zacna koncepcja. Fajnie by było połączyć siły i popracować razem. Szczerze mówiąc, to już od jakiegoś czasu coś podobnego krąży mi po głowie. Nawet więcej, przeszło do fazy działania. Moim celem w pierwszym rzucie jest zbudowanie coś na kształt CA80, ale z użyciem procka Motoroli, czyli CA68. Ten procek ma kilka fajnych myków, które uważam, że byłyby ciekawe do zastosowania, o czym będę jeszcze pisał.

Oczywiście Kolego Gaweł jest to w w/w projekcie jak najbardziej możliwe (zastosowanie procka JAKIEGOKTOCHCE), bo projektując to co projektowałem starałem się "wyjść" na nieco wyższy poziom abstrakcji (nieco uciec od hardware w stronę ujednolicenia zasilania, protokołów transmisji, przerwań). Jak wspomniałem, ja raczej nie wymyślam niczego nowego, ew.staram się dostosować obecne możliwości techniczne (protokoły transmisji, elementy układowe) do tego jak to kiedyś "drzewiej" za czasów Gary'ego Kindall'a było projektowane.
Wspomnę tylko, że sukces czy to Atari czy Commodore (jakkolwiek komercyjny i raczej typu niestety closed-source) nie wziął się znikąd, bo podwaliny pod otwarto źródłową strukturę hardware wykonali wcześniej ludzie z PARC (z Pasadeny) i kilku łebskich inżynierów z Motoroli. Teraz jest od groma procków, gotowych układów, gotowych mikrokomputerów, ale jakoś mało takich projektów typu: tu masz szablon, tu masz co jak z czym połączyć, gdzie co wgrać, a co za elementów użyjesz, albo jaki software wgrasz to już twoja sprawa.

Na chwilę obecną podam krótki opis co i jak, a schematy, porównania, wywody i konkrety przedstawię później.

Wstepne założenia techniczne projektu:
1. Magistrala transmisji i danych:
A konkretnie: linie przerwań, adresów oraz transmisji danych (interupts, addresses, data lines) wg znanego i szeroko już stosowanego układu nóżek (standardu połączeń) używanego w arduino i projektach typu "hat", chodzi o ten minimalny, ujednolicony rozstaw nóżek (nie żadne wersje mega, czy rozszerzone znane z modułów nucleo/discovery STM). Idea jest taka, żeby można było dostosować standard zarówno do już gotowych modułów arduino, jak i do tych co powstaną.
Myślę, że linia przerwań to mogłoby być po prostu I2C dla uproszczenia, chyba że byłyby przesłanki zastosować dedykowaną magistralę danych, gdzie linia przerwań leciała nie szeregowo, a równolegle (zmniejsza się ilość możliwych do użycia pinów magistrali).

2. Jednostka komputerowa:

2.1. Podjednostka zasilania:
Zasilacz typu PC PSU (jeden lub więcej), lub wykonany samemu z wyprowadzeniami linii zasilających obowiązkowo dla: 12V, 5V, i 3,3V. Podjednostka zasilania umieszczona z tyłu obudowy jednostki komputerowej patrząc z rzutu z góry.

Uwaga, kolejne moduły nie tak jak w PC, że leżą na jednej płycie głównej, tylko jakby leżą pionowo do i obudowy typu horizontal desktop (tej płaskiej).

Patrząc z rzutu z góry, czyli:
- z przodu
(z zewnątrz: front panel,
z wewnątrz nic, tzn.krawedź pcb modułu/ów)
- z tyłu
(z zewnątrz: back panel i porty we/wy dla zasilania,
monitora (display),
urządzeń peryferyjnych nie wymagających
częstego przełączania,
z wewnątrz: podjednostka/i zasilania)
- z lewej
(z zewnątrz: nic,
z wewnątrz: układy wejściowe/wyjściowe dołączane do
"płyty głównej" położonej skrajnie z lewej lub z prawej,
o której to poniżej),
- z prawej
(z zewnątrz: nic,
z wewnątrz: tak jak w opisie dot.strony lewej,
czyli układy we/wy dla poszczególnych
modułów jednostki centralnej komputera)


2.2. Płyta główna:
Arduino, klon arduino, albo autorska płyta główna. Jedyne założenia, do których powinna się dostosować to rozkład linii komunikacyjnych, zasilanie z 12V, 5V, lub 3,3V oraz to, że jej GŁÓWNYM CELEM jest jedynie posiadanie i zarządzanie BIOS komputera. Podobnie jak systemie PC Desktop, resztę zadań przejmują kolejne układy wewnętrzne jednostki komputerowej (moduł procesora jako kolejna płytka pcb typu hat, moduł karty graficznej, karty sieciowej, dźwiekowej etc - a płyta główna zarządza BIOSem, czyli enumeracją i przydziałem pamięci dla poszczególnych układów)

2.3 Moduł hat dla procesora:
Doczepiany jako pierwszy moduł pcb hat do "płyty głównej".
Procesor obojętnie jaki, ale z założenia i wg dostępności projektowałem dla procesora 8-bitowego, lub mikrokontrolera 8-bitowego. Oczywiście projektujący powinien zadbać o kwarc/zegar dla płytki hat dla procesora, ALU jeśli procesor nie posiada wbudowanego a jest potrzebny, i inne dodatki, które powinny być rozumiane przez BIOS jako miejsce gdzie znajduje się procesor. Prywatnie chciałem użyć trzech różnych mikrokontrolerów dla trzech różnych zapotrzebowań: wersja super mini, np.ATTiny, wersja średnia jakiś 8-bitowy, wersja wyższa 32-bitowa np.jakiś STM 32-bitowy, albo ATMEL/Microchip wersja ATX.

2.4. Moduł karty graficznej:
2.4.1. W wersji mini: bez, rolę ostatecznie może przejąć moduł procesora.
2.4.2. W wersji średniej: mikrokontroler zdolny obsłużyć wyświetlacz monochromatyczny LCD typu graficznego.
2.4.3 W wersji wyższej: mikrokontroler zdolny obsłużyć tryb VESA VGA przynajmniej w wersji 320x200 pikseli z wyjściem VGA dla monitora CRT. Po przeanalizowaniu układów wyszło mi, że minimalnym takim mikrokontrolerem mógłby być np.
ATXMega 32 A4, ponieważ dysponuje on minimalnymi parametrami do tego typu zadań. W kolejnym poście szerzej wytłumaczę co i jak, bo to jest już pisanie o przetwarzaniu grafiki komputerowej.

2.5 Moduł nośnika pamięci trwałej dla Systemu Operacyjnego (CpM OS, XINU, albo inny OS typu Open Source).
Jako [2.n] kolejne moduły, np. karty sieciowej, dźwiękowej, sterownika do drukarki, tokarki cnc etc
to tutaj póki co założenia tylko takie, żeby były zdolne do zasilania spod 12V, 5V, lub 3,3V oraz szyna danych (magistrala danych) wg minimalnego układu arduino.


Niedługo zamieszczę jakieś grafiki, tabelki z przeliczeniami co i jak, ale muszę to zrobić dobrze (uporządkować z tego co już projektowałem i przeprojektowywałem).

Poniżej przedstawiam rzuty projektu "pisane na kolanie" bo aktualnie nie mam dostępu do programu graficznego

RZUT Z PRZODU (w kwadratowych nawiasach punkty z powyżej):

---------------‐-------------------------------------------------
[ wentylacja jednostki komputerowej ]
-----------------------------------------------------------------
[2.2] <-> [2.3] <-> [2.4] <-> [2.5] <-> [2.n]
‐-----------------‐----------------------------------------------
nóżki, podstawa
------------‐--------------



RZUT Z GÓRY (w kwadratowych nawiasach punkty z powyżej):

----------------‐------------------------
porty zasilania (220V) i
porty we/wy niewymagające częstego przełączania,
na back-panelu
-----------------------------------------------------------
[2.1]
-----------------------------------------------------------
[2.2] <-> [2.3] <-> [2.4] <-> [2.5] <-> [2.n]
-----------------------------------------------------------
porty we/wy na front-panelu
-----‐--------------------------------------------


Edit1:
Przepraszam, że tak "na kolanie" (żaden to brak szacunku dla czytających z mojej strony, a jedynie zaistniała konieczność), ale póki co dalej nie mam dostępu do programu graficznego, a tak było mi najszybciej przekazać jak to by miało mniej/więcej wyglądać (rzut 3D nabazgrany w zeszycie długopisem):

j23 pisze:Na chwilę obecną podam krótki opis co i jak, a schematy, porównania, wywody i konkrety przedstawię później.

Moja wyobraźnia tego nie ogarnia... Czekam na rozwinięcie.

Jak dobrze zrozumiałem, to taki modułowy komputer bez backplane z modułami "na kanapkę"?
Problemem będzie to (poza uciążliwą wymianą modułów), że standard Arduino pozostawia jeszcze mniej miejsca dla układów DIP niż nieszczęsny RC2014 z jego przyjętymi rozmiarami. Sam pomysł ciekawy.

tapy pisze:Jak dobrze zrozumiałem, to taki modułowy komputer bez backplane z modułami "na kanapkę"?

Dokładnie tak. Jak wspomniałem żadna nowość, ani "odkrycie hameryki". Jedynie co może ode mnie to pomysł na wykorzystanie sprzętu, części które się posiada w sposób jaki opisałem, czyli zasilacze (np.od Pc) z tyłu i moduły posiadające niezależną linię lub wspólną linię zasilania wyprowadzoną na tył jednostki komputerowej (a nie pajęczynka kabli po całej płycie).

W skrócie: rzucie z góry, zasilanie na tył, najważniejsze porty i/o na przód, zunifikowana magistrala w poprzek,
w rzucie z przodu chłodzenie znad radiatorów nad wszystkim, moduły/zasilanie, separacja od podstawy obudowy przez metalowe kołki montażowe i ew.dodatkowe pcb, albo kształtki/kątowniki (bo pcb z modułami, w tym płytą główną idą pionowo).

tapy pisze:Problemem będzie to (poza uciążliwą wymianą modułów), że standard Arduino pozostawia jeszcze mniej miejsca dla układów DIP niż nieszczęsny RC2014 z jego przyjętymi rozmiarami. Sam pomysł ciekawy.

Wymiana modułów uciążliwa jeśli byłaby to częsta wymiana, owszem... ale coś za coś. W zamian jest to złącze arduino, które jest dość popularne - co nie znaczy, że można pomyśleć nad innym łączem. Przeglądając typy łącz, począwszy od wczesnych ISA i jeszcze wcześniej doszłem do wniosku, że każde kolejne łącze niosło ze sobą, albo większą ilość pinów, albo komplikację w standardzie wymiany danych, a idea jest taka, żeby było to możliwe najbardziej "po środku". Stąd standard złącza arduino, i chodzi mi tu jedynie o standard ZŁĄCZA, a nie o użycie modułów arduino, do których uczucie mam mieszane, głównie z powodu uzależnienia od Arduino IDE... Ujmę to może inaczej... Skąd w ogóle u mnie pomysł zabrania się za coś takiego... Otóż latka lecą i jak pewnie wielu Kolegów/Koleżanek z forum chciałbym przynajmniej częściowo przekazać wiedzę młodszemu pokoleniu PLUS oprócz jakichś altruistycznych idei zwykła chęć zabawy i wykorzystania gratów, które się ma. Patrzę sobie od czasu do czasu do internetu, a tam tak: mikrokomputer taki, siaki i owaki, ale OGÓLNIE (może poza arduino i raspberry i może kilka innych) żaden nie ma jakiejś specjalnej siły przebicia w skali legendarnego C64 czy Atari (ew.Amigi). No to myślę sobie tak... Teraz te mikrokontrolery czy to AVR (od Atmela/Microchip) czy te PIC'i (Microchip) mają moc i możliwości częstokroć nieporównywalnie potężniejsze niż procesory i podzespoły z C64, Atari, czy Amigi (może z pewnymi drobnymi wyjątkami, ale tak ogólnie rzecz biorąc). W międzyczasie czytam sobie książkę o systemach operacyjnych co by ogarnąć o co chodzi w Minix'ie i zastanawiam się po kiego grzyba dla malutkiego MCU aż 3000 linii kodu, skoro prawdopodobnie nie wykorzysta tego wszystkiego... No tak, tyle potrzeba na tzw."wszelki wypadek"... ok, potrzebna zmiana podejścia, czyli PODZIAŁ PROBLEMU NA MNIEJSZE PODPROBLEMY = czyli modularyzacja. Jak modularyzacja i podział, to tylko żeby zrobić to tak, żeby pomiędzy modulikami nie powstało coś na kształt "wieży Babel", że niby każdy będzie miał i znał swoją cząstkę roboty do wykonania, ale już z dogadaniem się z kolegą modułem obok to byłby problem, CZYLI POTRZEBA wykonanania jakiejś względnie bezbolesnej UNIFIKACJI magistrali transmisji danych (wybór padł na arduino, bo po pierwsze popularna, po drugie stabilna w sensie mechanicznym, bo jest symetryczna i małe ryzyko złamania pinów, lub ewentualnego spięcia przy kontakcie z innym modułem. Minus, no tak.. Gdyby zaszła konieczność wymiany modułu AKURAT ze środka jednostki komputerowej.
Ale ok... Myślę sobie problem z ustawieniem tego wszystkiego wewnątrz obudowy, to jest jedno, zasilanie tego to druga sprawa, a jeszcze software który będzie tam krążył to sprawa trzecia. No i PRZEZNACZENIE tego mikrokomputerka... To nie ma być superkomputer typu Silicon Graphics Incorporated, czy kolejna wersja superkomputera CRAY, ale na litość... komputer dla dziecka, do zabawy, prosty i żeby można było na nim pisać kod, jakoś ten kod skompilować (SKOMPILOWAĆ NA WEWNĘTRZNYM SYSTEMIE OPERACYJNYM,
A NIE JAK W arduino że trzeba komputera zewnętrznego,
ALBO NIE JAK w Raspberry, że co prawda mikrokomputer ogarnie i system i kompilator, ale stopień komplikacji i upakowania elementów ogranicza zabawę z hardwarem dość znacznie). Ok.. już rozumiem, że jak to komputer "dla dziecka" a to co pisze wcale może nie takie proste, a raczej zagmatwane.. Wg mnie może i zagmatwane nieco, ale taki stan będzie do etapu opracowania pierwszego dobrze funkcjonującego PRZEPISU do konstrukcji. Przepisu z zaleceniami, a nie że tak być musi i koniec i kropka...
Przeglądając internet któregoś razu naszło mnie, żeby poszukać czy aby ktoś już nie zmajstrował systemu operacyjnego na jakiś MCU AVR... A jeszcze jak to byłoby coś mniejszego i prostszego niż Minix... łopanie... to byłoby wprost pięknie... Szukam, szukam... i OOO CHU..STECZKA JEST! System o nazwie XINU, oprawany przez Prof.Douglasa Comera z Uniwersytetu Purdue. Przy okazji dowiedziałem się, że prof.Comer całkiem pięknie rozpracował protokoły wymiany danych w sieci internet oraz opisał to, a także swój system Xinu w dwóch swoich książkach, zaś sam system operacyjny Xinu udało się komuś odpalić na mikrokontrolerze AVR z serii ATMega, a konkretnie ATMega 328, tym samym, który jest tak popularny na platformie arduino. Jakkolwiek temu zacnemu człowiekowi system udało się uruchomić łatwo dostrzec mankamenty, a więc sam suchy system ale bez reszty software'u (w tym edytora jakiegoś, jakiegoś kompilatora do języka C, bo był do języka Basic... ale Basic to nie C)... No więc zacząłem myśleć nad kompozycją tego wszystkiego dalej... Kolejny problem to oczywiście standardowe wyjście, czyli display, czyli monitor... czyli karta graficzna... czyli wiedziałem że tu już będzie problem z uwagi choćby na czysto logiczne podstawy odnośnie przesyłania sygnału graficznego.. No to znowu... a może da się to zrobić jakoś mega prosto, jakaś karta monochromatyczna? Hercules? żartuje oczywiście.. (była taka karta kiedyś monochromatyczna Hercules) ALE, znowu patrzę jak to tam w internecie, a może ktoś coś zrobił podobnego, tzn. żeby tak wysłać sygnał do rasowego monitora LCD/CRT po kablu VGA, choćby i to miałby być sygnał monochromatyczny.. Patrzę, no i znalazł się taki pan Ben Eater, który tłumaczy co i jak zrobić żeby sklecić "najgorszą kartę VGA"... Eee myślę sobie... a po co zaraz VGA? A może coś "biedniejszego", ale żeby jakiś procek 8 bitowy (podobnie jak w C64) to udźwignął? Znalazłem... Jakiś kolejny pomysłowy konstruktor zrobił taką kartę typu CGA. Całkiem ładnie, całkiem ładnie... No, ale Ben Eater tak mnie podkusił z tym VGA, że aż zacząłem badać swoje stare notatki studiów odnośnie standardu VESA VGA w kontekście minimalistycznym, tzn.najniższy tryb VGA byleby udźwignął to jakiś procek np.z AVR... No i przeliczając różne parametry (o których w szczegółach jeszcze napiszę) wyszło mi, że przy najmniejszej rozdzielczości czyli 320x200 i przy 524288 kolorach dałby radę ATXMega 32 A4 (który posiadam), a minimalny MCU powinien mieć przynajmniej te 4kB pamięci, to pociągnął by te 320x200 px z 512 kolorami. Odnośnie standardu VESA są ścisłe (mam na myśli minimalne) wymagania co do częstotliwości zegara sterującego MCU (czy raczej GPU) karty graficznej i nie może on być niższy niż 20 MHz inaczej nie ma co myśleć o standardzie VGA (CGA da radę na mniej niż 20 MHz, i tak samo jakaś wersja grafiki monochromatycznej, ALE NIE VGA). A wiadomo, że cała zabawa z kolorowymi pikselami zaczyna się od 320x200...
No i tak to mniej więcej było... Winszuję Koledze/Koleżance, który wytrwał i doczytał to wszystko co tu napisałem...
Jak wspomniałem jeszcze odrobinę konkretów podam odnośnie karty graficznej i jak widzę opcję rozwiązania BIOS'u, ewentualnie jak bym widział system operacyjny, jego prezentację (raczej w trybie tekstowym typu TUI=Text User Interface), no ale reszta spraw to w zasadzie jeszcze w proszku... ZRESZTĄ.. To jest tylko luźna propozycja ode mnie. Ja to zrobię, albo i nie...
Wychodzę z założenia, że wiedzą i pomysłami (tymi konstruktywnymi, niedestruktywnymi) TRZEBA się dzielić.
No i to jest kwintesencja tego, dlaczego projekt robię z myślą o kolejnej generacji hackerów w dobrze rozumianym pojęciu słowa: hacker

j23 pisze:Przeglądając typy łącz, począwszy od wczesnych ISA i jeszcze wcześniej doszłem do wniosku, że każde kolejne łącze niosło ze sobą, albo większą ilość pinów, albo komplikację w standardzie wymiany danych, a idea jest taka, żeby było to możliwe najbardziej "po środku". Stąd standard złącza arduino, i chodzi mi tu jedynie o standard ZŁĄCZA...

Liczba pinów ma znaczenie, gdy chcemy bawić się grafiką. Jeżeli ograniczymy się do transmisji szeregowej, to pozostanie nam znakowy terminal, albo rozdzielczość ZX Spectrum z ośmioma kolorami i to z ograniczoną szybkością zmian w obrazie... Coś za coś. Poza tym stare procesory miały na pokładzie najwyżej UART, więc I2C czy SPI wymagałyby dodatkowych kości i gimnastyki z oprogramowaniem. Ale można spróbować, jestem za.

j23 pisze: Winszuję Koledze/Koleżance, który wytrwał i doczytał to wszystko co tu napisałem...

Wyjdę na "pana Marudę", ale uważam że lepiej poruszyć pewne tematy na etapie koncepcji niż potem obudzić się z ręką w nocniku. Traktuj to jako rady, a nie krytykę.

j23 pisze:SKOMPILOWAĆ NA WEWNĘTRZNYM SYSTEMIE OPERACYJNYM

Święta prawda, to jest fundamentalny powód dla którego trzymam się kurczowo systemów rodziny CP/M. Pomysł z XINU jest ciekawy, ale jak sam zauważyłeś, system musi mieć dostępne aplikacje, których chyba tu niestety nie uświadczysz.

@Zegar podniósł ważny temat szyny wymiany danych i jej unifikacji. Uważam że to musi być określone na samym początku, nim zacznie się opracowywać pozostałe elementy. W przypadku retro sprzętu, użycie SPI jest problematyczne, gdyż jedyny układ który się do tego nadaje (TP3465) jest obecnie praktycznie niedostępny. I2C dzięki PCF8584 można zastosować ale jest to rozwiązanie stosunkowo wolne i wyklucza go do zastosowań graficznych. Pozostaje nam transmisja szeregowa, która wydajnością nie grzeszy. Tu można pomyśleć o użyciu ESP32 z FabGL jako karty graficznej, działa to bardzo dobrze.

Na koniec tego marudzenia, będę przypominał o dostępnej powierzchni PCB jaką nam daje standard Arduino. Ostatnio budowałem SBC na Z180 przy wykorzystaniu pamięci które praktycznie nie wymagają logiki klejącej i przyznam że to było wielkie wyzwanie zmieścić to w rozmiarze RC2014 przy dwóch warstwach PCB, a jest to większa płytka niż Uno. Przyjęte tu założenie z góry określa że muszą to być SBC (chyba że nie zrozumiałem do końca prezentowanej koncepcji)


PS. Może warto też przyjrzeć się elementom rozwiązania z tego projeku? Trochę klocków tej układanki już tam się znajdzie.

tapy pisze:Wyjdę na "pana Marudę", ale uważam że lepiej poruszyć pewne tematy na etapie koncepcji niż potem obudzić się z ręką w nocniku. Traktuj to jako rady, a nie krytykę.

Ja tego nie traktuję ani jako rad ani jako krytyki, gdyż podchodzę do tego w sposób WOLNY i ABIWALENTNY, co i w jaki sposób z tego pomysłu się rozwinie i czy w ogóle się rozwinie.
Jeżeli chodzi o pozatechniczne idee jakie mi przyświecały to były to głównie cele edukacyjne (chęć przekazania wiedzy w przystępny sposób, przez platformę na której oprócz zabawy, WYMIANY komponentów hardware i software, dziecko czy nawet dorosły wyniesie z tego pożytek poza zabawą, a także i to, że jeśli będzie chciał bardzo to ZROBI tą "zabawkę" WŁASNYMI RĘKAMI z tego co ma, byleby zwrócił uwagę -dla dobra swojego projektu jeśli zechce- na pewne przyjęte standardy gwarantujące zadziałanie "zabawki" "od pierwszego kopa"). W żadnym wypadku nie zamierzam tutaj wspierać zaowulowanej W JAKIKOLWIEK SPOSÓB komercji, więc jedynie osoby mające jakieś -nie wiem- złe, obłudne zamiary mogą spodziewać się z niechęcią z mojej strony co poskuktuje co najwyżej tym, że wyłączę się z dyskusji, żeby mieć "świety spokój" Naprawdę, bardzo bym prosił, że to co tutaj piszę i przedstawiam (a raczej przypominam) pewne pomysły NIE MOJE już wcześniej ktoś wdrożył (i to dużo wcześniej od pana Igora z w/w strony hackaday.io), a ja nie zamierzam konkurować ani o palmę pierwszeństwa w jakichś wizjonerskich pomysłach (bo wg mnie takich nie ma w tym projekcie), ani o żadne kwestie finansowe. Jest mi obojętne czy ktoś na tym "zrobi kasę" czy może zrobi coś nowego niż już było. Zwyczajnie w przyjaznym -jak mam nadzieję- środowisku Kolegów i Koleżanek elektroników, informatyków i hobbystów podzieliłem się wizją mojego projektu, ALE czy to dalej z tego rozwinie się taki czy inny projekt to MAM DO TEGO otwarte podejście (dokładnie OTWARTO ŹRÓDŁOWE podejście Z ZAZNACZENIEM, że źródła nie muszą być moje, a więc prośba żeby ustosunkować się raczej do tych, którzy NAPRAWDĘ je wymyślili).

tapy pisze:Święta prawda, to jest fundamentalny powód dla którego trzymam się kurczowo systemów rodziny CP/M. Pomysł z XINU jest ciekawy, ale jak sam zauważyłeś, system musi mieć dostępne aplikacje, których chyba tu niestety nie uświadczysz.

Uświadczysz, uświadczysz... ...z tym że na zasadzie, że kod programu/aplikacji trzeba by dostosować do platformy jak to często ma miejsce (i dlaczego np.Raspberry ma łatwiej, bo tam tak właśnie zrobili). Krótko mówiąc prof.Comer tworząc XINU i nazywając je tak, żeby było zawsze (pętla) wiadomo, że XINU=Xinu Is Not Unix, TO JEDNAK ten system oparł paradoksalnie na niektórych ideach z Unixa (choćby forma komunikacji z użytkownikiem przez powłokę jaką zastosował).
W Xinu -moim skromnym zdaniem- problem polega na tym, że jakkolwiek sam system może i zmieści się i odpali się BEZPOŚREDNIO z MCU ATMega328 to będzie to tyle. Jakiś tam system, parę poleceń systemowych, możliwość użycia podstawowych rozkazów z języka Basic i to wszystko (albo aż wszystko) i DLATEGO ja na tym schemacie wyżej przyjąłem podejście, że JEŚLI OS'em miałby być Xinu to tylko jeśli będzie on odpalany POŚREDNIO tzn.tak jak w PC, czyli z jakiejś PAMIĘCI STAŁEJ gdzie system Xinu plus reszta potrzebnego systemu WŁĄCZNIE z jakimś mini kompilatorem do języka C (SBCC? ) byłaby już skonfigurowana przy użyciu w sumie TRZECH komponentów z JEDNOSTKI KOMPUTEROWEJ, które robiłyby TO SAMO co w komputerze PC, tyle że w mniejszej skali. Te trzy komponenty to:
1. BIOS (odpalany jako pierwszy, i tam wcale nie musi, ani nawet nie powinno być jakiegoś dużego systemu, tylko jak nazwa wskazuje podstawowy system we/wy przydzielający numery przerwań sprzętowych dla modułów/kart w jednostce komputerowej oraz pamięć dla nich i robiący POST na samym początku, po to żeby sam wiedział czy CPU/MCU działa i czy działa reszta komponentów). Podałem co prawda PROPOZYCJĘ że MOŻE to być arduino, czu klon, ALE NAPISAŁEM TEŻ że może to być płytka z BIOSEM zaprojektowana od podstaw. A idea odseparowania jej od CPU/MCU jest taka, żeby gniazdo/socket pod CPU NIE BYŁ sztywno ustawiony pod tylko taki typ CPU (np.32 nóżki i koniec).
2. CPU/MCU - rola jak w PC, żadnej nowej filozofii, oczywiście POZA FAKTEM (ale to też nic nowego), że taktowanie (możliwości taktowania) magistrali systemowej, z którą CPU/MCU będzie pracował powinny być określone na samym początku (i tu też uważam, że powinno się zostawić MARGINES na gorsze CPU/MCU i te lepsze).
3. Karta rozszerzeń jako PCB (tak jak na obrazku powyżej) z pamięcią stałą (pamięć stała jako np.flash, czy karta typu micro SD, cokolwiek kto uzna za godne i właściwe) GDZIE BĘDZIE uruchamiany system, gdzie będą mogły być jakieś kompilatory, jakieś pliki i programy użytkownika.

tapy pisze:@Zegar podniósł ważny temat szyny wymiany danych i jej unifikacji.

Może Kolega Zegar podniósł, a może ja też pisałem wcześniej o BEZBOLESNEJ UNIFIKACJI DLA MAGISTRALI czyli SZYNY WYMIANY danych, ale mniejsza o to, ważne, że jest to ważne i jest tutaj zgoda co do trzymania się tej UNIFIKACJI.

tapy pisze:(...)użycie SPI jest problematyczne (...) I2C dzięki PCF8584 można zastosować ale jest to rozwiązanie stosunkowo wolne i wyklucza go do zastosowań graficznych (...)ESP32 z FabGL jako karty graficznej, działa to bardzo dobrze.
(...) będę przypominał o dostępnej powierzchni PCB jaką nam daje standard Arduino (...)

Pozwolę sobie jeszcze raz przypomnieć, że napisałem o arduino, ew.klonie arduino TYLKO jako ZALECENIE, ale NAPISAŁEM TEŻ że można by zastosować autorską płytkę (jest to napisane zaraz w pierwszym moim wpisie tutaj). Oczywiście, że zdaję sobie sprawę z ograniczeń ilości i rozstawienia pinów jakie daje arduino - PRZEDE WSZYSTKIM jak dla mnie za mało pinów. Ja tylko dlatego podałem to jako propozycję z uwagi na fakt np.dostępności gotowych płytek pcb jako płytek uniwersalnych (czyli lutujesz złącze, a dalej projektujesz jak chcesz), ALE to była TYLKO LUŹNA propozycja.

W jednym z rozważanej przeze mnie idei było zastosowanie magistrali gdzie byłoby:
- 8 pinów na przerwania
- 8 pinów na adresy
- 8 pinów na dane
łącznie jest to 24 piny, a to już wykracza nieco poza standard arduino, ale weź teraz nakłoń tych wszystkich używających pinologi Arduino (gdzie jest mniej pinów) żeby zmienili swoją koncepcję... Nie da się, ale z drugiej strony gdyby zaistniała silna potrzeba takiej zmiany oddolnie wśród użytkowników to pewnie byłoby to możliwe - i DLATEGO chciałem żeby projekt był tak naszkicowany, żeby KAŻDY użytkownik mógłby SAM skonstruować minikomputer z tego co ma w warsztacie UWAŻAJĄC na kluczowe sprawy jak: szerokość i taktowanie magistrali i przyjęte koncepcje odnośnie BIOS'u i możliwości WYKONALNOŚCI modułów/kart rozszerzeń.
Odnośnie tych 24 pinów to też nie mam 100% pewności czy nie jest to za mało gdyby trzeba było w niektórych przypadkach stosować wymianę danych typu DMA... Zdecydowanie szerokość magistrali i jej taktowanie, a przede wszystkim sposób komunikacji pomiędzy modułami to rzecz warta przemyślenia.

tapy pisze:PS. Może warto też przyjrzeć się elementom rozwiązania z tego projeku? Trochę klocków tej układanki już tam się znajdzie.

[/quote]Obiecuję, że przejrzę nieco bardziej dokładnie za jakiś czas (bardziej dokładnie gdybym miał czytać instrukcję cyrylicą, ale chyba dam radę ).
Tak na szybko co tam widzę to, że projekt jest wykonany ładnie i schludnie. To jest plus.
A minus taki, że jest to po prostu kolejny minikomputer gdzie nawalone jest wszystkiego co potrzeba na płytce BEZ WIĘKSZEJ MOŻLIWOŚCI modyfikacji podzespołów (nie ma dowolności stosowania mini-kart rozszerzeń do np.różnej karty grafiki, czy innej mini-karty dźwiękowej jaką można by zastosować A PÓŹNIEJ WYKORZYSTAĆ do zrobienia na tym GRY typu Pacman, Arkanoid etc - bo o to głównie mi chodzi: O NAUKĘ POPRZEZ ZABAWĘ - to dzięki temu C64, Atari, Amiga odniosło sukcesy).

Pan Igor bez wątpienia sporo się napracował przy tym zacnym projekcie i chwała mu za to, ale nie jest to to, o co mi chodzi... Daleko tutaj do uniwersalności tego projektu, ale rozwiązania które pan Igor przyjął widzę jako gruntownie przemyślane i zapewne po wielokroć w praktyce sprawdzone.

Tyle się napisałem... Mam nadzieję, że nikomu humoru nie popsułem, ani nie obraziłem. Jeśli jednak tak to przepraszam, ale było to zupełnie niecelowe. Mam jak najbardziej otwarte, pozytywne i konstruktywne podejście do tego projektu - jakkolwiek powstanie on w taki czy inny sposób. Jeśli okaże się, że np.Kolega Tapy, czy Kolega Zegar opracuje kolejny typ C64 (do zbudowania samemu) który nie będzie wymagał dużego nakładu finansowego (zbudowany z części jakie posiada się na warsztacie, albo ogólno dostępnych, POPULARNYCH i TANICH) a sprawa z konstrukcją będzie sprowadzała się do samodzielnego wytrawienia pcb itd. etc. to z przyjemnością sam to wg tego projektu wykonam. A po cichu mam nadzieję, że WSPÓLNIE TUTAJ na forum Microgeek wypracujemy przynajmniej jakieś minimum programowe do dalszej metodologii postępowania, albo kto wie... może i dociągniemy ten projekt do końca i powstanie jakieś cudo z szyldem typu Microgeek Computer Machine?... Dzięki za przeczytanie całości od początku do końca

Polecane linki:
1. Odnośnie mini karty graficznej VGA 320x200:
http://martin.hinner.info/vga/timing.html
http://tinyvga.com/avr-sdram-vga
http://www.microvga.com/arduino
https://atmega32-avr.com/arduino-vga-via-interrupts-using-avr-microcontroller/amp/
https://blog.thomaspoulet.fr/bit-banged-vga/
https://eater.net/vga - strona Ben'a Eater'a, świetny opis!
https://www.serasidis.gr/circuits/AVR_VGA/avr_vga.htm

2. Odnośnie mini-karty a raczej mini-motherboard dla BIOS:
https://en.m.wikipedia.org/wiki/SeaBIOS
https://github.com/openbios/openbios

3. System operacyjny:
[url]xinu.cs.mu.edu/[/url]
http://se.fi.uncoma.edu.ar/xinu-avr/
https://github.com/9MMMinor/avrXinu-V7

4. Interfejsy, magistrale danych:
http://www.interfacebus.com/index.html

5. Wymagania minimalne dla kompilatora GNU C (mini-karta rozszerzeń/moduł dla pamięci stałej - patrz pkt.2.5 z opisu i schematu powyżej), w sensie kompilator dostosowany do pracy z wbudowanym system operacyjnym przewidzianym dla projektu (NIEKONIECZNIE MUSI to być GNU C, ale chodzi mi o ideę NIEKORZYSTANIA z zewnętrznego IDE do C/Cpp )
https://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html

Rozumiem idee i cele stojące za tym projektem, ale najwyraźniej nie zrozumiałem sposobu jego realizacji w warstwie sprzętowo-programowej jakie zostały przyjęte. Będę obserwował ten wątek i gorąco mu kibicował by projekt przybrał bardziej realne kształty, masz mój miecz - z przyjemnością przyłączę się gdy będzie już dokładniej podana specyfikacja techniczna, bo wyraźnie trafiam kulą w płot. Czekam na więcej!

tapy pisze:Rozumiem idee i cele stojące za tym projektem, ale najwyraźniej nie zrozumiałem sposobu jego realizacji w warstwie sprzętowo-programowej jakie zostały przyjęte. Będę obserwował ten wątek i gorąco mu kibicował by projekt przybrał bardziej realne kształty, masz mój miecz - z przyjemnością przyłączę się gdy będzie już dokładniej podana specyfikacja techniczna, bo wyraźnie trafiam kulą w płot. Czekam na więcej!

Dziękuję Kolego Tapy, będę pamiętał o tym "mieczu", bo niewątpliwie z tego co ja "nabazgram" to będzie jeszcze ze sto, albo i więcej poprawek. No i na przyszłość będę starał się opisać w sposób bardziej zwarty i czytelny, np.przy pomocy tabelek jakichś, schematów ideowych etc. Nie bardzo rozumiem kwestii "trafiania kulą w płot", ale jakkolwiek by tego ująć rozumiem, że są to jakieś niejasności wynikłe z mojego, niezbyt ścisłego (albo zbyt zawiłego) tłumaczenia/pisania przy niewspólmiernej ilości zapotrzebowania na graficzne zobrazowanie, i oczywiście bardziej szczegółowe.

W między czasie obejrzałem ten filmik od pana Igora z hackaday.io oraz instrukcje i schematy jakie byłem w stanie pobrać z tamtej strony. Schemat z hackaday.io wydał mi się trochę pogmatwany i dość nietypowy, no ale takie prawo konstruktora i jego wizji. Plusem jest to, że dowiedziałem się z niego, że autor p.Igor ma swoją stronkę (szczęśliwie także i po angielsku) i jest tam udostępnionych więcej aktualnych informacji:
http://criss.fun/?en
Chylę czoła, że przede wszystkim udało mu się projekt bądź co bądź ukończyć, napisać/dostosować system, dokumentację a nawet są tam jakieś gry i programy.
Komputerek tamten lansowany jest co prawda możliwością obsługi VGA, ale przy niższych trybach graficznych niż ja bym tego oczekiwał, albo inaczej... tam po prostu jest VGA z możliwością, które poprzez taką a nie inną koncepcję budowy (budowa NIEmodularna, tylko zwarta) wymuszają takie VGA jakie jest. Dobre i to, ale ja trochę inaczej to przedstawię - mam nadzieję, że już wkrótce. Od razu mogę napisać, że zapewne będę wzorował się na tym czy innym projekcie z licencją GPL (czy inną open source) o czym zawsze będę starał się wspomnieć w nagłówku dokumentacji/specyfikacji (cokolwiek by to nie było). W mojej głowie siedzi MODULARNA budowa jednostki komputerowej i TEGO będę się trzymał. Dla przykładu specyfikacja karty grafiki i generalnie możliwości generowania grafiki nie będzie jedna jako tylko VGA, ale dzięki modularnej budowie będzie to mogła być -jak wspomniałem parę postów wcześniej- grafika monochromatyczna, polichromatyczna typu CGA, VGA, czy nawet niższe tryby SVGA jeśli tylko się to uda, a w domyśle podstawy system wejścia wyjścia (BIOS) powinien być w stanie zweryfikować sprawność podzespołów nawet BEZ KONIECZNOŚCI standardowego wyjścia (monitor/wyświetlacz LCD), a wystarczyłyby diody kontrolne LED, ew.kody dźwiekowe (morse'a? ) gdybym chciał się "bawić" nieco bardziej. Zapewne wzorując się na w/w projektach np.Ben'a Eater'a czy p.Igora będę miał nieco ułatwioną sprawę przy projektowaniu (tzn.mojej wizji projektu) ALE NIE UKRYWAM, że zaprojektowanie dobrze funkcjonującej choćby karty graficznej typu monochromatycznego (chodzi mi o mini-kartę rozszerzeń pcb i cała ta elektronika) odrobinę mnie przeraża, więc zapewne będzie sporo miejsca kiedy będziemy tutaj wspólnie musieli usiąść, bo sam z elektroniką rady nie dam.
Co do magistrali danych to też przewija mi się w głowie koncepcja użycia nie jednej, a dwóch magistral danych, tzn.jednej szybkiej "szeroko-pasmowej" dla celów wyższych jak grafika czy dźwięk, i drugiej "wąskopasmowej" ale takiej, która mniej obciąży CPU i cały system... Wiem, że to żadna nowość, no ale gdy człowiek stoi przed podjęciem decyzji o eleganckim podejściu do projektu (i dopasowaniu do obecnych MCU) zadanie nie jest takie proste. Oczywiście poza całą zabawą istnieje także normalne życie i na wszystko trzeba znaleźć czas.

Edit1:
Zajrzałem też do dokumentacji RC2014 (zwłaszcza wersji dla CpM 8bit upgrade) i szczerze mówiąc bliżej mi do tej koncepcji, niż do koncepcji pana Igora (po co "wyważać otwarte drzwi" skoro przy niewielkim wysiłku i zgodzie autora projektu RC2014 być może dałoby radę dopasować to i owo).
W RC2014 zalety jakie widzę:
- modularna budowa z jakąś tam wizją WSPÓLNEJ magistrali
- przetestowana płyta główna (konstruktor nazywa ją backplane)
- konstrukcja względnie prosto wytłumaczona, a w każdym razie konstruktor zamieszcza zdecydowanie obszerniejsze i bardziej klarowne opisy niż ma to miejsce w projekcie pana Igora
- przewidziane osobne miejsce na BIOS (konstruktor nazywa to bootloader) i chyba osobne na pamięć dla programów użytkowych (tzn.osobna karta rozszerzeń z kompilatorem dla języka MS Basic) - ładnie, ładnie, nie powiem...

Wady w RC2014 (IMHO):
- karty rozszerzeń wydają się nie siedzieć stabilnie w slotach (nie wiem, może to tylko takie moje odczucie)
- karta grafiki VGA... kurde.. tak pięknie zaprojektowana płyta główna i reszta komponentów, a ta karta grafiki coś tak... nie bardzo, nie bardzo... Czy ja źle coś wyczytałem czy może tak faktycznie tam jest, że władowany jest "kombajn" typu Raspberry Pico (no może nie "kombajn" na miarę RPi zero ale taki trochę przerost formy nad treścią) a z trybów graficznych do dyspozycji TYLKO tryb tekstowy?? -słabo trochę póki co
- niektóre komponenty/elementy elektroniczne wydają mi się trudno dostępne, jak np.ten element wyświetlacza 7SEG LED w obudowie DIP, albo te elementy elektroniczne które są skomplikowane w montażu (małe elementy smd) - tutaj o wiele lepszym podejściem wykazał się pan Igor (CRISS).

Kto wie.. kto wie, może raczej będę starał się dopasować coś do RC2014, chyba że nie da rady, no to będę dobierał to z tego, to z tego... ale jeszcze raz podkreślę, że RC2014 reprezentuje OGÓLNIE filozofię z magistralą danych o którą mi chodzi, a brzydko tam wygląda rozwiązanie z zastosowaniem karty graficznej. Gdyby zastosować do RC2014 podejście z kartą graficzną VGA od Bena' Eater'a, najlepiej mieć możliwość użycia i dopasowania karty graficznej do któregoś z procesorów AVR typy ATX (8bitowe z kwarcem 32MHz) lub jakiś AVR 32 bitowy to pewnie dałoby radę wykorzystać bardzo miodny tryb grafiki kolorowej 320x200 z całkiem przyzwoitą ilością kolorów, a MCU/GPU z takiej karty graficznej przy wykorzystaniu DMA powinien poradzić sobie z generowaniem sygnału RGB na DB9 do monitora LCD... Muszę to wszystko przemyśleć... albo skontaktować się z twórcą RC2014, bo może już coś takiego nawet robi?... Jak wspomniałem jestem otwarty na różne podejście do tematu. Jak zawsze muszę też mieć czas obczaić wszystkie licencje, ale póki co z tego co widzę to wszystko jest na open-source, więc wiekszych problemów autorsko-prawnych poza stosowaniem się do tych licencji raczej nie ma...

Karta graficzna to najtrudniejszy element. Jeśli wystarczy tryb tekstowy, to polecam FabGL, implementację można zobaczyć u J4F (ten od Z80-MBC2) i tam nawet więcej, bo są pokazane również emulacje. Innym rozwiązaniem trybu tekstowego jest użycie Parallax Propeller P8X32A z jego przykładowym użyciem w Zeta v2.0 lub RC2014.

tapy pisze:Karta graficzna to najtrudniejszy element. Jeśli wystarczy tryb tekstowy, to polecam FabGL, implementację można zobaczyć u J4F (ten od Z80-MBC2) i tam nawet więcej, bo są pokazane również emulacje. Innym rozwiązaniem trybu tekstowego jest użycie Parallax Propeller P8X32A z jego przykładowym użyciem w Zeta v2.0 lub RC2014.

No właśnie zależało by mi bardzo na wstrzelenie się za wszelką cenę w tryb 320x200 nawet kosztem usilnego dopasowania się do RC2014 (no chyba że by autor na takie coś nie poszedł). Wydaje mi się, że w tym celu skupię całą swoją uwagę, a więc koncentracja na magistrali od RC2014 i dobranie komponentów do przyzwoitej względnie karty graficznej dla VGA 320x200 (int 13h )

Edit1:
Tak... Już pamiętam z czym był i jest cały czas niestety główny problem jeśli chodzi o kartę graficzną - i to tak zarówno jeśli ktoś bierze się za budowanie komputerka w oparciu o Z80 (np.RC2014, CRISS CMP 8BIT) czy też coś na bazie C64 (np. Commander X16)... Problem z oprogramowaniem (firmware) dla chipu sterującego kartą... Teraz tak... Jeśli miał by to być firmware, w którym tylko chodzi o zrobienie grafiki VGA 320x200 (gdzie częstotliwość zegara karty MUSI oscylować w granicach 20MHz i więcej, bo inaczej nici z odświeżania obrazu, podwójnego buforowania jeśli trzeba) to jeszcze pół biedy. Co prawda i tak masa roboty z przygotowaniem wywołań funcji, ale ujdzie... Gorzej jeśli to ma być jakiś chip jak w C64, Amiga, Atari czy Z80 (np.jak w tych konsolach do gier gdzie była ładna grafika) i tam w grę wchodzą sprite'y i inne ulepszenia i tutaj jest wyzwanie żeby napisać taki kod schludnie i żeby on ładnie działał i JESZCZE żeby najlepiej był PRZENOŚNY pomiędzy różnymi chip'ami AVR, STM czy ew.PIC (bo tylko te biorę pod uwagę i TYLKO te z lepszej półki, tzn.żeby dały radę pracować z 20MHz i więcej... ATXMega 32 A4 może max.niby wydolić 32MHz, no ale dobrze by było gdyby przynajmniej dał radę tak między 20-25MHz). A trzeba to pisać niemal od podstaw, bo choć co prawda chipy i karty graficzne już takie były na RC2014 to właśnie z dostępnością samych chipów jest dużo gorzej.. Poniżej karta graficzna dla RC2014 gdzie w chipie od Texas Instruments zastosowano firmware z technologią MSX. https://hackaday.com/2018/06/22/theres-rc2014-life-in-the-tms9918a-display-chip-yet/
Chip jest niestety dość ciężko dostępny (a ja nie chcę robić ze starego "złomu" tylko wykorzystać układy które są w użyciu).
NA SZCZĘŚCIE udało mi się znaleźć taki firmware już napisany (z licencją Open Source) bazujący na podstawie chipów wykorzystujących technologię MSX/MSX2, która wtedy była popularna i wykorzystywała sprite'y i inne cuda, które -jeśli firmware karty graficznej posiada- niesamowicie upraszcza pisanie kodu dla systemów operacyjnych wbudowanych (np.dla CpM). Poniżej link:
https://openmsx.org/

Edit2:
Nie wiem jeszcze dokładnie JAK, na czym (na jakim chipie) będę starał się to dziabać i dłubać, ale póki co taki mam plan (z pisaniem tego oprogramowania dla karty graficznej). Jeszcze będę patrzył w ten firmware JUŻ OPRACOWANY dla chipów AVR gdzie link podałem wyżej, tzn.patrzył w kontekście dopasowania tej karty do magistrali danych od RC2014, bo kostruktor włożył w to masę pracy, w międzyczasie ulepszył (powstała wersja Classic II ze ZUNIFIKOWANYM rozstawem nóżek i standardem 40 pinów dla tejże magistrali). Trochę z dokumentacją tej magistrali jak na razie ciężko, ale nie będę na razie zawracać głowy projektantowi RC2014 dopóki faktycznie sam czegoś fizycznie nie zrobię z tym sprzętem co mam (a np.nie mam Z80 więc tutaj będę na wstępie miał problem ze środowiskiem testowym, no ale do testów może i niekoniecznie musi być Z80). Może kod od Ben'a Eatera trochę mi pomoże... Chciałbym żeby z tego coś ostatecznie wyszło przyzwoitego. Zobaczymy... Trzymajcie kciuki, bo to raczej w tym kierunku pójdą prace (karta graficzna) skoro inne sprawy (budowa takiego czy innego minikomputera) już jakoś tam przez wielu konstruktorów została ogarnięta.

Edit3:
Nie... To tak jednak prosto nie będzie dla tego trybu VGA co sobie wymyśliłem... Dokładnie chodzi o QVGA (320x200 [px] ) gdzie absolutne minimum dla procka to jest:
- 64000 bitów na przestrzeń danych (tutaj ATXMega 32 A4 nie da rady, wstyd przyznać, ale walnąłem się w obliczeniach, albo ktoś inny się walnął a ja źle przeczytałem? )
- zegar min.20MHz (tutaj akurat ok)
- plus dodatkowa pamięć na wszystkie pozostałe dodatki
Oczywiście rozwiązaniem pozostaje (co wcześniej stosowano) użycie dodatkowych banków pamięci, a potem względnie możliwie szybkie przełączanie żeby wyrobić się z odświeżaniem obrazu
Poniżej na avrfreaks nieco bardziej przybliżają ten problem (problem gdy ktoś się uprze robić to na 8bitowym procku)...
https://www.avrfreaks.net/forum/xmega-external-ram-workarounds
...bo oczywiście na cukiereczkach 32bitowych od np.STM takiego problemu nie ma. Są tam nawet gotowe biblioteki graficzne...
https://andybrown.me.uk/2012/03/06/reverse-engineering-the-nokia-2730-qvga-lcd/

Edit4:
Efekt dalszego rozpoznania...
Odnośnie karty graficznej dla RC2014 to konstruktor tego minikomputerka przyjął najwidoczniej założenie (całkiem słuszne), żeby wykorzystać gotowe biblioteki z pakietu jaki dostarcza firma/wsparcie/forum/fani STM. Konkretnie w module już istniejącej karty graficznej RC2014 używany jest moduł Raspberry Pi Pico, którego CPU/MCU stanowi prawdopodobnie któraś z wersji procesora STM Cortex M0 lub M0+ (nie jestem pewien tylko co do tego "+"). Z kolei z powyższego linku gdzie Andy Brown tłumaczy jak udało mu się uzyskać grafikę z rozdzielczością QVGA 320x200 wynika, że użył on jakiejś ogólnodostępnej biblioteki graficznej dla mikrokontrolerów STM umożliwiającą bezproblemowe generowanie tegoż typu grafiki/obrazu (Andy bardziej skupia się co prawda na tym w jak sprytny sposób udało mu się pobudzić do życia stary ale Jary wyświetlacz Nokia, ale w tle/kodzie sporo się dzieje dodatkowych spraw).
Teraz moje przemyślenia co do przyszłości tutejszego proponowanego przeze mnie projektu są takie, że najprawdopodobniej będę starał się w pierwszej kolejności pomóc autorowi RC2014 w ogarnięciu sprawy kodu dla karty graficznej (dla wyższych rozdzielczości), ale czuję że będzie to sprawa nieco oddalona w czasie, gdyż nie posiadam ani podstawowej wersji RC2014, ani też karty graficznej z modułem RPi Pico, ani co gorsza wiedzy w programowaniu tego KONKRETNEGO procka jakim jest Z80 i dlatego podchodzę do tej sprawy jak "pies do jeża". Niemniej konkluzja jaka wypływa z obserwacji projektu karty graficznej i RC2014 jest taka, że autor wcale nie robi tam żadnych karkołomnych akrobacji z projektowaniem firmware karty graf.od nowa tak żeby szło to po łączach równoległych jego 44 pinowej zunifikowanej magistrali danych. Nie, nie.. On podobnie jak Andy Brown wykorzystuje po pierwsze gotowe biblioteki graficzne (albo dopiero zamierza wykorzystać) oraz łącze UART pomiędzy RPi Pico a BEZPOŚREDNIO jego 44 pinową magistralą danych. Wydaje mi się, że z tego powodu sprawa z udostępnieniem funkcji systemowych CpM karty graficznej dla Z80 idzie trochę topornie (tzn. użycia łącza UART bezpośrednio z RPi Pico na jego 44pin magistralę RC2014). IMHO powinien posłużyć się POŚREDNIO jakimś ekspanderem czy MCU z 32 GPIO, który POŚREDNICZYŁBY w wymianie danych pomiędzy RPi Pico a 44pinową magistralą danych, ALBO TAK PRZEPROJEKTOWAĆ cały hardware karty graficznej żeby adresy i dane plus przerwanie (chyba minimum 33 lub 34 porty we/wy GPIO) trafiały BEZPOŚREDNIO z RPi Pico na 44pinową magistralę danych i adresów RC2014. Inaczej to będzie trochę męczarnia z kodem, który i tak pewnie nie uzyska pełnej wydajności dla Z80.. Takie mam przeczucie.
Innymi słowy wychodzi na to, po trochu, co pisałem NA SAMYM początku, żeby można wykorzystać nieco lepszy MCU do obsługi samej grafiki, ująć go w karby w postaci osobnego modułu (karta graficzna), a dalej puścić to po zunifikowanej magistrali danych, gdzie modułami innymi obowiązkowymi byłby moduł z BIOSEM (w RC2014 to jest backplane leżący prostopadle w stosunku do reszty modułów, ja planowałem na tym etapie wykorzystanie łącza arduino lub podobnego - większego, no bo arduino trochę za małe jak wiadomo), modułu dla CPU który mógłby być wymienialny, oraz modułu dla pamięci stałej/trwałej gdzie mieściłby się system operacyjny wraz z programami użytkowymi w tym kompilatorem dla języka C. Jakoż że autor RC2014 wyprzedził mnie (a pewnie nie on jeden) z tym podejściem, nomen omen bardzo zbliżonym do mojego, to uważam za bezcelowe robienie wszystkiego od nowa. Lepiej by mu pomóc, a potem ew.dopasować do tego co mi po głowie chodzi (tzn.bardziej uniwersalnego i abstrakcyjnego podejścia do problemu z hardware, zaprojektowanie takiego ogólnego SZABLONU postępowania/metodologii na wypadek samodzielnych prób konstrukcji minikomputerów).
Jak wyjdzie "w praniu" to zobaczymy, bo czas (ma siedzenie przy projektowaniu) i pieniądz (na ew.dodatkowe moduły do testowania karty dla RC2014) to zdecydowanie dwie sprawy, z którymi może w moim przypadku nie pójść tak łatwo. Niewykluczone, że zarzucę prace nad kierunkowym działaniem nad kartą graficzną dla RC2014 (bo wg mnie ma ona nie tak zaprojektowany hardware jak trzeba) na rzecz dłubania przy czymś samodzielnie a czy z kolei z tego coś wyjdzie??.. nie mam pojęcia.. Czas pokaże.

Pozdrawiam! Jarek J23

Nie wiem w jakim kierunku chcesz iść, ale w przypadku karty VGA obsługującej tylko tryb tekstowy to moim skromnym zdaniem niekwestionowanym liderem jest użycie ESP32 dzięki bibliotece FabGL i w przypadku RC2014 masz dwa przykłady, komercyjny i otwarty które naprawdę dobrze działają. Tryb graficzny to chyba tylko TMS9918 i pochodne z użyciem bibliotek MSX, ale to już droga zabawa ze względu na brak ich dostępności. Tu od lat nikt nic nie produkował, więc wybór dedykowanych układów graficznych jest mizerny. Może wyjściem z sytuacji jest użycie CPLD jak w ZX Max 48/128, ale to będzie zbliżać do standardu ZX Spectrum. Kolejnym pomysłem jest użycie panelu LCD z własnym kontrolerem graficznym, dostępne są z szyną równoległą.

tapy pisze:Nie wiem w jakim kierunku chcesz iść, ale (...)

- Ad astra, ad astra... (per aspera jeśli to już takie konieczne) ALE... tak na serio

tapy pisze:w przypadku karty VGA obsługującej tylko tryb tekstowy

Pisałem już o tym wyżej, ale...
CHODZI MI GŁÓWNIE O TRYB GRAFICZNY 320x200 (320x240) [px] a konkretnie taki jaki daje standard QVGA

tapy pisze:to moim skromnym zdaniem niekwestionowanym liderem jest użycie ESP32 dzięki bibliotece FabGL(...)

ok, ok.. Received and understood ale jeszcze raz ja zrepetuję: TRYB GRAFICZNY, do gier (tych miodnych, wiecznie pięknych, wiecznie młodych pikselowych... GRY GRY GRY, ale nie te tekstowe typu Adventure

tapy pisze:Tryb graficzny to chyba tylko TMS9918 i pochodne z użyciem bibliotek MSX, ale to już droga zabawa ze względu na brak ich dostępności. Tu od lat nikt nic nie produkował, więc wybór dedykowanych układów graficznych jest mizerny. Może wyjściem z sytuacji jest użycie CPLD jak w ZX Max 48/128, ale to będzie zbliżać do standardu ZX Spectrum. Kolejnym pomysłem jest użycie panelu LCD z własnym kontrolerem graficznym, dostępne są z szyną równoległą.

Ech.. też już o tym przecież pisałem, z tym że kumam, kumam.. zbyt wielką ilością tekstu to okrasiłem i szkoda czasu na czytanie, albo coś.. luz.. więc w skrócie.. Są możliwości m.in.:
- OpenMSX (jeśli to ma być coś a'la MSX, ale nie daje to pełni możliwości QVGA TRYBU GRAFICZNEGO więc odpada),
- użycie kodu/bibliotek Open Source, o których pisał Ben Eater, albo tych co wyżej podałem w linkach,
- albo wykorzystanie gotowych bibliotek dla STM, ARM, Raspberry ale wtedy użycie MCU 32bit (albo gotowego modułu jak RPi Pico) wlutowanego w kartę graficzną i kontaktującego się pośrednio lub bezpośrednio ze ZUNIFIKOWANĄ szyną danych i adresowych a poprzez nią z resztą podzespołów jednostki mikrokomputera/komputera.

O te wyświetlacze chodzi?
https://www.crystalfontz.com/c/tft-lcd-displays/resolution/320x240/170
ale.. mnie jeszcze o pikniejsze rzeczy chodzi, bo ja staram się wykonać SCHEMAT nieco bardziej ABSTRAKCYJNEGO podejścia PONAD ten cały krępujący hardware... -dlatego w tytule użyłem pojęcia MIDDLEWARE (leżący dalej od sprzętu, ale bliżej użytkownika), nie HARDWARE, który... leży dalej od... (?? hmm?) użytkownika, a bliżej... tzn.to jest de facto sprzęt=HARDWARE

Parafrazując znaną polską piosenkarkę...
"(...)Wsiąść do pociągu bylejakiego... (...)"           # usiąść w bylejakim warsztacie
"(...)Nie dbać o bagaż, nie dbać o bilet (...)"         # nie martwić się o czy posiada się cały NIEZBĘDNY sprzęt do budowy CRISS'A CPM 8bit czy RC2014...
"(...)Ściskając w ręku kamyk zielony (...)"             # ściskając w ręku UNIWERSALNY plan budowy mikrokomptera z tego co się ma "pod ręką"
"(...)Patrzeć jak wszystko zostaje w tyyylee (...)"  # patrzeć jak szybko i prosto postępuje budowa z tego złomiku co się posiada w swoim ubogim warsztaciku

73 J23

j23 pisze:CHODZI MI GŁÓWNIE O TRYB GRAFICZNY 320x200 (320x240) [px] a konkretnie taki jaki daje standard QVGA

Dużego wyboru nie masz, stary i niedostępny kontroler graficzny lub implementacja jakiegoś nowego pomysłu za pomocą dostępnych układów cyfrowych albo CPLD. Zawsze będzie ten nieszczęsny hardware.
PS. Taka rozdzielczość wyklucza użycie CP/M, bo tam wymagany jest tryb tekstowy 80x25 znaków nieosiągany dla 320x200 nawet przy fontach 5x7.

tapy pisze:Taka rozdzielczość wyklucza użycie CP/M, bo tam wymagany jest tryb tekstowy 80x25 znaków nieosiągany dla 320x200 nawet przy fontach 5x7.

Można zrobić kartę graficzną, a CP/M przez RS232 połączyć z terminalem np. VT100...

Problem leży gdzie indziej. Pamiętam kolejne CRT w PC-tach. Hercules, CGA, EGA, VGA itd. Wytworzenie sygnału wideo to jedno. Do karty graficznej trzeba dostarczyć dane, które ktoś wcześniej musi przetworzyć. Nie bez powodu rozwój grafiki był rozłożony w czasie. Po prostu moc obliczeniowa komputera jest wąskim gardłem. Ośmiobitowiec nie da rady w starciu z zaawansowaną grafiką. Pozostaje ZX Spectrum, albo coś w tym stylu. Chyba że zajmiemy się nowszymi procesorami.

P.S. Czy ktoś pamięta grę "Prince of Persia" na Herculesie?
https://www.youtube.com/watch?v=BghjArWIjME

Wychodzi na to, że będę robił coś nowego i "przecierał szlaki" -nie, no.. Rozczaruję Kolegów, ale wszystko to zostało już zrobione (z tym że pod konkretny sprzęt, przeważnie komercyjnie, z licencją i prawami autorskimi zamkniętymi do tego stopnia, że do dzisiejszego dnia niektórych (Y) boli od kurczowego ich ściskania) i zostało zapomniane w mrokach dziejów.
Chyba jedynie nie ma do dziś dnia tego uniwersalnego jakiegoś takiego schematu konstrukcujnego, ale poza tym... Tryb graficzny QVGA o rozdzielczości 320x240 - pierwszy raz komercyjnie w komputerze Atari ST, z tym że tam było 512 kolorów.

Faktycznie jakoś wcześniej nie zwróciłem uwagi na fakt, że sam system operacyjny (np.CpM) może stanowić przeszkodę... trudno..

Dlaczego akurat ten tryb 320x240 ew.320x200? -tutaj słusznie Koledzy zauważyli, że

Zegar pisze:(...)Wytworzenie sygnału wideo to jedno. Do karty graficznej trzeba dostarczyć dane, które ktoś wcześniej musi przetworzyć. (...) Po prostu moc obliczeniowa (...)

Otóż to... Przetworzenie grafiki, moc obliczeniowa... Tutaj dochodzimy powoli do etapu dlaczego uczepiłem się trybu 320x200 lub 320x240. W PC'tach, w standardzie VESA czy QVGA był to jeden z niewielu trybów graficznych gdzie JEDNOCZESNIE:
- można było korzystać z 256 kolorów (8bit koloru/pixel)
- było dedykowane przerwanie do użycia tego trybu graficznego
- można było skupić się na samym tylko rozmieszczeniu pixeli na 320x200 "płótnie" (ew.pewien mały problem z zaimplementowaniem podwójnego buforowania), BEZ ROZPRASZANIA uwagi na takie sprawy jak użycie technik stronicowania pamięci, banków pamięci etc.(co było wyzwaniem przynajmniej dla mnie gdy próbowałem tego za czasów pięknych czasów studeckich... ech...). Krótko mówiąc.. kiedyś zrobić grafikę z więcej niż z 32 kolorów i nie zmęczyć się zbytnio w kodzie (na PC'cie) używało się trybu graficznego 320x200 z dedykowanym przerwaniem 13h.
https://www.fountainware.com/EXPL/video_modes.htm

A jak ktoś chciał więcej i np.marzyło mu się użyć 640x480 i do tego 256 albo więcej kolorów? Dwie drogi (jak na PCta):
- albo ręczna implementacja kodu dla ŚCIŚLE określonej typu karty
- albo witamy w standardzie VESA i wtedy większość tycg co pracowali pod MS-DOS używała takiego dość popularnego wsparcia, które standard VESA dostarczyło w czymś takim co nazywało się DOS4GW

W każdym razie -jak już wspomniałem- luźno podchodzę do całego tego projektu. Uda się to się uda, nie to nie. Raczej traktuję to jako eksperyment i próbę przypomnienia sobie pewnych zamierzchłych już technik przetwarzania grafiki, których uczyłem się w ramach mojej specjalizacji... dawno... daaaawno temu.. Jako ciekawostkę tylko podam, że wtedy to był już czas kiedy wszędzie królowała grafika 3D, gry typu Quake III, tworzenie własnych silników graficznych w oparciu o DirectX 3D lub OpenGL (gdzie jeszcze nie było OpenGL ES, ani cukiereczków typu webGL, three.js etc). Wtedy już nikt nie zawracał sobie głowy grafiką dwuwymiarową i np.faktem, że wiele problemów z trybami graficznymi 2D zostało sprytnie rozwiązanych w OpenGL gdyby użyć tej technologii do 2D a nie do 3D... No.. a teraz mamy OpenGL ES i dlatego m.in.twórcy niektórych bibliotek graficznych na procesory wbudowane mają prościej.

Zegar pisze:P.S. Czy ktoś pamięta grę "Prince of Persia" na Herculesie?

i tą i większość gier z tamtego czasu, w których oprócz miodnej grafiki kładziono na scenariusz, fabułę, na to żeby była na tyle porywająca żeby wywołać uśmiech, albo żeby łezka się w oku zakręciła... np. Another World, Flashback, Saboteur, Lost Vikings, Golden Axe, Grobda, Iron horse, Cannon Fodder, Worms... i właśnie większość w trybie 320x200, ew.320x240... Piękne czasy...
https://www.myabandonware.com/

P.S. Ciekawostka, jak obecnie AI (Artificial Intelligence = Sztuczna Inteligencja) umożliwia generowanie grafiki...
https://nightcafe.studio/

j23 pisze: rozmieszczeniu pixeli na 320x200 "płótnie", BEZ ROZPRASZANIA uwagi na takie sprawy jak użycie technik stronicowania pamięci, banków pamięci etc.

To pozostał nam jeden wybór - kontroler graficzny, bo jeśli to ma robić procesor z paletą 256 kolorów, to możemy już spokojnie zapomnieć o 8-bitowcach, z 16-bitowców tylko 68000 miała liniową adresację pamięci by móc obsłużyć tak wielką tablicę bufora ramki. Ciekawym i dostępnym układem jest VS23S010D-L ale nie spotkałem się z jego wykorzystaniem jako karty graficznej, może naszedł jego czas?

tapy pisze:To pozostał nam jeden wybór - kontroler graficzny

No tak chyba właśnie próbuje twórca RC2014. Z tym, że jeszcze raz podkreślę taki mały fakt, że oddalam się nieco z ideą przyjętą na początku tego co pisałem - UNIWERSALNYM (względnie) podejściem, bez kurczowego trzymania się tegoż czy innego hardware/sprzętu (w tym właśnie cała finezja, że trzeba mieć jako takie pojęcie o możliwościach jakby całej grupy procesorów/kontrolerów etc.).

tapy pisze:bo jeśli to ma robić procesor z paletą 256 kolorów, to możemy już spokojnie zapomnieć o 8-bitowcach, z 16-bitowców tylko 68000 miała liniową adresację pamięci by móc obsłużyć tak wielką tablicę bufora ramki.

Nie, no nie będzie aż tak źle, bo grafika może zostać uprzednio załadowana właśnie do pamięci karty graficznej (która będzie jednocześnie kontrolerem) a biedny 8bitowy MPU jedynie co będzie musiał to skorzystać z funkcji zaimplementowanych uprzednio do firmware karty graficznej, które umożliwią mu korzystanie z trybu 320x200 z ilością 256 (2^8=256) jeżeli opanowałby tylko na rejestrach 8 bitowych. Jedyne co MUSI posiadać (czy raczej powinien) to pamięć flash o pojemności równej lub nieco większej niż 2x(320x200) [BITÓW] co oznacza że te przynajmniej minimum 150KB pamięci flash powinien mieć (podkreślam,że nie trzymam się kurczowo Z80 czy innego konkretnego CPU). Resztę załatwi kontroler/karta graficzna. Przy okazji... CAŁKIEM NA WSTĘPIE (pkt.2
4, opis w kolorze błękit... tymolowy ) pisałem, że WŁAŚNIE z uwagi na rodzaj CPU i karty GRAFICZNEJ przewiduję trzy podejścia do tematu i tam jest ta trzecia możliwość WŁAŚNIE karta graf.full wypas, high-end (co inkluduje sięgniecie po CPU TAKŻE z nieco wyższej półki). PODEJŚCIE UNIWERSALNE.

tapy pisze:Ciekawym i dostępnym układem jest VS23S010D-L ale nie spotkałem się z jego wykorzystaniem jako karty graficznej, może naszedł jego czas?

Być może, ale być może także, że nie jest tak popularny jak RPi Pico (RC2014 gdzie JEST 8bitowy procek), czy inny z procesorów/mikrokontrolerów ARM i innych, gdzie ciężar przetworzenia grafiki spoczywa na bibliotekach graficznych, które te w/w chipy obsługują, a kod bibliotek ma z kolei wsparcie z ARB (Architecture Review Board, która opracowała m.in. Open GL ES=Embedded Systems).

Edit1:
Wyliczenia po krótce dla opcji z grafiką 320x200 pixeli, paleta kolorów 24bit i podwójne buforowanie (biorąc pod uwagę TYLKO MPU AVR 8bit ze strony Microchip, bo innych mi się nie chciało, bo ich nie znam, ALE W ŻADNYM WYPADKU ich nie wykluczam).

Minimalne wartości dla CPU:
- przyjąłem pamięć programu: min. 32KB
- pamięć RAM: min.1500KB = 1,5 MB
- ilość GPIO (magistrala danych): 32 piny
(tutaj już styka nawet ATMega32)

Minimalne wartości dla GPU: to samo co dla CPU plus zegar gdzie taktowanie min. 20 MHz (tutaj potrzeba min. ATXMega 32 A4, albo podobnego)

Gdyby dla GPIO (magistrala danych) mogło styknąć 18 GPIO (16pinów dane/adresy i 2 piny sterujące) to wtedy CPU mógłby być nawet ATMega 328.

Sprawdzałem na stronie Microchip.

Edit2:
A w międzyczasie przyszło mi na skrzynkę (takie na czasie, chociaż w dwa tygodnie to raczej się nie wyrobię... ):
https://hackaday.io/contest/186672-2022-cyberdeck-contest