Skocz do zawartości

MiniConsole V2


Pomocna odpowiedź

@MR1979 projekt robi wrażenie 🙂 podziwiam, że wiesz jak napisać do tego program.

Dnia 14.01.2022 o 17:58, MR1979 napisał:

Możliwość użycie trzech buforów ramki na warstwę - dzięki temu renderowanie i wyświetlanie grafiki odbywa się niezależnie

Mógłbyś rozwinąć ten temat? Pamiętam jak pisałem coś w SDL albo Allegro i na pojedynczym buforze było bardzo źle, bo nie można wysłać do wyświetlenia gdy jeszcze nie skończyłem rysowania. Dla 2 buforów było dobrze - na jeden rysowałem, a drugi był w tym czasie rysowany. Ta sama sztuczka jest użyta w kursie STM32.

A dlaczego tu masz 3 bufory?

Link do komentarza
Share on other sites

Zarejestruj się lub zaloguj, aby ukryć tę reklamę.
Zarejestruj się lub zaloguj, aby ukryć tę reklamę.

jlcpcb.jpg

jlcpcb.jpg

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

(edytowany)

Witam!

Dawno tu nic nie pisałem, ale prace trwają.

Przetestowałem już wszystkie komponenty konsolki poza modułem WiFi. I powoli zabieram się za pisanie boot loadera.

Plan jest taki:
1. Gdy uruchomimy konsolkę normalnie to bootloader uruchomi ostatnio wczytaną aplikację / grę
2. Gdy uruchomimy konsolkę z wciśniętym przyciskiem menu to pojawi się możliwość wyboru nowej aplikacji / gry z karty SD. USB zostanie też wtedy skonfigurowane w tryb pamięci masowej z możliwością odczytu i zapisu do karty SD. Będzie też można skonfigurować konsolkę pod swoje wymagania (np domyślna jasność ekranu / sieć i hasło WiFi / domyślny poziom dzwięku / kalibracja joysticka itp.

Ale bootloader nie będzie ograniczał się tylko do samego uruchamiania / wgrywania aplikacji oraz konfiguracji.

Będzie też zawierał wgrane podstawowe drivery do konsoli (np podstawowe funkcje obsługi grafiki i innych peryferiów). Lista wskaźników do poszczególnych funkcji będzie przekazywana do uruchamianej aplikacji.

Także aplikacje będą mogły być pisane o jeden poziom abstrakcji wyżej (bez konieczności do odwoływania się do sprzętu)

Oto zaplanowana uproszczona mapa pamięci:

MomoryMap.thumb.JPG.b9cb5285ebb11412d26eba78b27b1536.JPG

PAMIĘĆ FLASH: Początkowe 128kB będzie przeznaczone na bootloader oraz drivery. Pozostałe 1920kB będzie dostępne na aplikacje.

PAMIĘĆ SRAM: Końcowe 48kB będzie przeznaczone na bootloader oraz drivery. Tam też będzie się znajdować tablica wskażników do funkcji driverów, oraz zmienne i struktury potrzebne do obsługi grafiki / dźwięku / klawiatury itp. Dla aplikacji pozostanie 464kB.

PAMIĘĆ SDRAM: Pamięć buforów grafiki będzie "przyklejona" do górnej granicy SDRAM. Wieklość pamięci na framebufory zależy od wybranego trybu graficznego oraz metody buforowania (2 lub 3 bufory). Pozostała część będzie do wykorzystania dla aplikacji.

Na zakończenie kolejny krótki filmik:

 

Pozdrawiam,
Marek

 

Edytowano przez MR1979
  • Lubię! 2
Link do komentarza
Share on other sites

Cześć @MR1979

Mam jedno pytanie: Czy przewidujesz na tej konsoli emulację jakichś innych starych konsol? Mnie bardzo by interesowała emulacja pierwszej wersji NES (8-mio bitowej). Jeśli dobrze rozumiem, to dostarczasz dla tej konsoli własne biblioteki do multimediów?

Pozdrawiam

Link do komentarza
Share on other sites

Przeczytałem właśnie komentarz o rodzaju buforowania i czy nie byłoby jeszcze lepiej przełączać się między podwójnym i potrójnym w zależności od ilości FPS? Przy krótkim czasie renderowania klatki przełączalibyśmy się na podwójne buforowanie i po wyrenderowaniu usypialibyśmy CPU do czasu blanking interval. Wtedy oszczędzalibyśmy nieco energii i rdzeń byłby nieco chłodniejszy.

Link do komentarza
Share on other sites

27 minut temu, Harnas napisał:

Przeczytałem właśnie komentarz o rodzaju buforowania i czy nie byłoby jeszcze lepiej przełączać się między podwójnym i potrójnym w zależności od ilości FPS? Przy krótkim czasie renderowania klatki przełączalibyśmy się na podwójne buforowanie i po wyrenderowaniu usypialibyśmy CPU do czasu blanking interval. Wtedy oszczędzalibyśmy nieco energii i rdzeń byłby nieco chłodniejszy.

Można coś takiego robić, ale po co walczyć z problemami które nie istnieją. Doprowadziłoby to do niepotrzebnej komplikacji kodu. uC z rodziny STM32 praktycznie się nie nagrzewają. Wolny czas procesora lepiej wykorzystać na obsługę np logiki gry.

  • Lubię! 1
Link do komentarza
Share on other sites

Dołącz do dyskusji, napisz odpowiedź!

Jeśli masz już konto to zaloguj się teraz, aby opublikować wiadomość jako Ty. Możesz też napisać teraz i zarejestrować się później.
Uwaga: wgrywanie zdjęć i załączników dostępne jest po zalogowaniu!

Anonim
Dołącz do dyskusji! Kliknij i zacznij pisać...

×   Wklejony jako tekst z formatowaniem.   Przywróć formatowanie

  Dozwolonych jest tylko 75 emoji.

×   Twój link będzie automatycznie osadzony.   Wyświetlać jako link

×   Twoja poprzednia zawartość została przywrócona.   Wyczyść edytor

×   Nie możesz wkleić zdjęć bezpośrednio. Prześlij lub wstaw obrazy z adresu URL.

×
×
  • Utwórz nowe...

Ważne informacje

Ta strona używa ciasteczek (cookies), dzięki którym może działać lepiej. Więcej na ten temat znajdziesz w Polityce Prywatności.