76

(29 odpowiedzi, napisanych Różne)

1 GRAPHICS 9: REM -- set the mode by Adam K.
10 REM -- let's start by Seban/Slt --
11 DL=PEEK(560)+256*PEEK(561)
12 FOR I=1536 TO 1548:READ A:POKE I,A:NEXT I:POKE DL+134,143:POKE 512,0:POKE 513,6:POKE 54286,192
13 FOR Y=128 TO 191
14 COLOR Y/4:PLOT 0,Y:DRAWTO 79,Y
15 R=RND(0)*79: COLOR R
16 PLOT R,RND(0)*127
17 NEXT Y
18 FOR X=60 TO 76
19 COLOR X+3:PLOT X/1.5,128:DRAWTO X,191
20 NEXT X
21 FOR X=0 TO 31
22 COLOR X/2:PLOT 30,12:DRAWTO X+14,51:DRAWTO 30,91
23 NEXT X
24 DATA 72,169,192,141,27,208,169,4,141,26,208,104,64
25 REM -- end of let's start --
32759 GOTO 32759
32760 REM --
32761 REM PRIMA APRILIS COMPO 2024 BY
32762 REM MONO
32763 REM Adam Klobukowski
32764 REM Seban/Slt

77

(3 odpowiedzi, napisanych Software, Gry - 8bit)

@Alex... jakbym cokolwiek wiedział to bym odpowiedział, a o żadnej bibliotece muzycznej Synapse Software nie słyszałem.

O ile dobrze pamiętam (wiesz ostatni raz tam zaglądałem w latach '90) to efekty dźwiękowe z Alley Cat to były po prostu fragmenty dedykowanego kodu,  to każdy z efektów był odrębnym i niezależnym kawałkiem, nie wyglądało to na jakieś ujednolicone (tzn. nie było podobne od czegokolwiek co mogło by tworzyć jakąś bibliotekę). Poza tym wydaje mi się że XXL pytał o bibliotekę muzyczną, a nie bibliotekę dźwieków. A jednak z powyższej wypowiedzi XXL-a wynika że chodziło o dźwieki (odpowiedź zobaczyłem dopiero po fakcie jak napisałem swój post)

W tamtych czasach przepisałem parę tych dźwięków z Allay Cat na kartkę, disassemblując fragmenty kodu za pomocą QMEG-a,  a następnie przeklepałem to do QA, podobało mi się to że większość tych dźwieków była generowana "proceduralnie" i wykonywała się "raz na ramkę", tzn. procedura była "wołana" z częstotliwością 50/60Hz (PAL/NTSC).

78

(115 odpowiedzi, napisanych Software, Gry - 8bit)

@vlx: no i świetnie! Kawał porządnej roboty z ekranownią! Fajnie że Ci się chce!

@x_angel: Trochę to trwało, ale w załączniku "pastfinder" z trainerem (możliwość wyboru nieskończonej liczby żyć oraz wyłączenia licznika promieniowania).

79

(115 odpowiedzi, napisanych Software, Gry - 8bit)

Cześć!

Rzuciłem okiem na tę grę "3d24", podczas pobieżnej analizy kodu wyszło kilka ciekawostek, które opiszę tutaj w paru słowach. Po pierwsze wydaje mi się że gra nie została napisana w asemblerze, wygląda na to że kod to jakiś kompilowany język. Początkowo myślałem że to "ACTION!", jednak potem doszedłem do wniosku że chyba jednak nie ACTION! chociaż niektóre konstrukcje widziane w kodzie by na to wskazywały (specyficzne umiejscowienie zmiennych i procedur, skoki na początku każdej większości procedur, etc.) Brak było jednak odwołań do biblioteki standardowej, jednak to tez dawało się w "ACTION!" ominąć, jeszcze chwilę próbowałem wyciągać jakieś wnioski jednak bardzo szybko moja uwaga została skierowana gdzie indziej i doszedłem do wniosku że tracę czas na jakieś nieistotne pierdoły. Wydaje mi się że ten rodzaj kodu już kiedyś widziałem w przeszłości jednak było to na tyle dawno temu że obecnie sobie nie mogę przypomnieć gdzie to już widziałem. Może ktoś kiedyś wykaże się większą determinacją i przeanalizuje dokładnej kod tej produkcji i dojdzie do jakichś sensowniejszych wniosków niż moje "gdybanie".

Podczas dalszego przeglądania kodu gry okazało się autorzy gry wbudowali w nią "cheat codes". Są dwa "kody" które można wpisać podczas rozgrywki:

wpisując słowo "IZA" otrzymamy 99 nabojów
wpisując słowo "NPL" (skrót od "następna plansza"?) przechodzimy do kolejnego poziomu.

Dodałem do gry prosty trainer (możliwość wyboru nieskończonej liczby żyć). Plik do pobrania w załączniku tego posta. Prośbę Krzysztofa o możliwość wyboru planszy mogę chyba uznać za niebyłą ponieważ sprawę załatwia cheat z użyciem "NPL". Do tego plansz w tej grze to za wiele nie ma niestety, więc rozgrywka z "pomijaniem poziomów", skończy się bardzo szybko.

Entuzjastom tej gry życzę powodzenia w odkrywaniu nowych plansz i cierpliwości przy rozgrywce... mi niestety wydaje się że ta gra ma trochę źle dobrany nazwijmy to "balans prędkości/reakcji", nie wiem czy powolność reakcji gry wynika z tego że silnik gry jest mało wydajny czy też to kwestia źle dobranych przez autorów opóźnień, jednak u mnie wywołuje to pewien poziom frustracji gdy ginę gdyż gra nie zareagowała na mój ruch joy-em lub wciśnięcie klawisza.

To chyba tyle z mojej strony. Niebawem wrzucę też "pastfinder" o którego prosił x_angel.

No dobra... wiosnę czuć w powietrzu, marazm zimowy trochę minął, więc sądzę że pora zacząć się wygrzebywać z zimowych zaległości... w kolejce się nazbierało wiele zaległych materiałów, ale może zacznę od tych które mi łatwo będzie wrzucić i nie będe musiał wiele pisać na ich temat, na pierwszy ogień pójdzie zatem kaseta która wpadła mi w ręce przez przypadek, a którą to została udostępniona przez szanownego forumowicza o pseudonimie forumowicza "Kacper". Czy kaseta pochodzi z epoki czy też jest wytworem z czasów mniej przeszłych trudno mi powiedzieć... zarówno sposób nagrania jak i jakość nagrania sugerują że nie powstała ona tak dawno temu jakby mogło się wydawać, jednak oczywiście mogę mylić, zatem bez zbędnych słów dalszego komentarza i dywagacji zacznę od prezentacji samej wkładki, która to wygląda tak:

http://seban.pigwa.net/kacper/turbo_2k1_tape/kacper_t2k1_tape.jpg

Czy zawartość kasety jest jakaś super ciekawa lub porywająca? Dla większości z was pewnie nie, ot kolejna składanka zapisana w formacie Turbo 2000/2001/F/KSO. Jednak pośród tych gier znalazło się kilka pozycji pod którymi podpisał się niejaki "Mroova" i "Tiger Soft" z Płocka. Nie widziałem wcześniej żadnych wersji gier podpisanych przez któregokolwiek z Pańów, ale ja pewnie po prostu zbyt mało widziałem, oto przykładowe ekrany widoczne podczas ładowania niektórych pozycji:

http://seban.pigwa.net/kacper/turbo_2k1_tape/loading_screens/chimera.png  http://seban.pigwa.net/kacper/turbo_2k1_tape/loading_screens/mirax_force.png

http://seban.pigwa.net/kacper/turbo_2k1_tape/loading_screens/spelunker.png  http://seban.pigwa.net/kacper/turbo_2k1_tape/loading_screens/spy_vs_spy_II.png

I teraz już szybkie podsumowanie, dla zainteresowanych wrzucam zgraną kasetę w formatach CAS/HEX/XEX:

Kacper 2K1 Turbo Tape

^^^ w  powyższym archiwum znajdziecie:

.
├── scripts
├── strona_a
│   ├── cas
│   ├── hex
│   └── xex
└── strona_b
    ├── cas
    ├── hex
    └── xex

Tak jak wspominałem zawartość kasety w 3 formatach; CAS, HEX, XEX. Po co dodałem wersję HEX? Jest to związane z katalogiem 'scripts', w którym to oprócz "a8cas-util" autorstwa FUJI-ego, znajdziecie też prosty skrypt w Python (extract_t2k.py), który umożliwia konwersję pliku .HEX wygenerowanego przez a8cas-util do postaci XEX/BIN. To prymitywne narzędzie może się przydać w przypadku gdy chcemy dokonać konwersji pliku zapisanego na taśmie do postaci binarnej... to nieco ułatwia przetwarzanie takich taśm i nie trzeba już się męczyć z programami kopiującymi które odpalamy na realnym sprzęcie czy też emulatorze, po poprawnej konwersji pliku WAV --> HEX bez problemu możemy dokonać dalszej konwersji plików HEX do postaci binarnej. Skrypt pisałem/testowałem/odpalałem pod Linux, ale chyba nie powinno być problemu z użyciem go również pod windows. Do kompletu w katalogu scripts znajduje się również prosty BASH-owy skrypt automatyzujący przetwarzanie/konwersję wszystkich plików z aktualnego katalogu (t2k.sh). Nie wiem czy komukolwiek to się przyda, bo to wszystko powstało bardzo szybko bez głębszego zastanawiania się, ale pomogło mi na optymalizację pracy z obrazami kaset w "Turbo 2000/F|KSO", ale skoro już powstało to postanowiłem to udostępnić w takiej formie jakiej jest, może komuś się również przyda. Miałem to co prawda rozbudować o obsługę Blizzard czy innych turbo z którymi miałem styczność, ale uznałem że zrobię to dopiero w chwili kiedy znowu w ręce wpadną mi jakieś kasety zapisane w innych formatach. Szkoda mi czasu na dodawanie funkcjonalności na zapas. Skrypt jest prymitywny i nie sprawdza poprawności pliku .HEX, zakładam że świadomy użytkownik sam przygotuje i dostarczy poprawny plik .HEX ... Pliki .HEX zostały dołączone do archiwum w celu przetestowania działania skryptu. Być może ktoś zechce go rozbudować o dodatkową funkcjonalność lub przystosować do swoich potrzeb.

Dla zainteresowanych jeszcze dodaję archiwum zawierające źródłowe pliki .WAV zgrane z kasety, z których to nastąpiła konwersja za pomocą a8cas-util do plików HEX, z których to potem powstały pliki .CAS i .XEX:

Kacper 2K1 Turbo Tape - source WAVE files

na sam koniec jeszcze spis zawartości obu stron w formie tekstowej...

zawartość strony A:

01) Arkanoid
02) Space Lobsters
03) Ballblazer
04) Amaurote
05) World Karate Championchip
06) Mr.Do!
07) Mirax Force
08) Kissin'Kousins
09) Blue Max 2001
10) BMX Simulator
11) The Warsaw Tetris
12) Twilight World
13) Star Wars (Ian Copeland, Zeppelin Games)
14) Spy vs Spy II
15) Molecue Man
16) Joe Blade
17) Spelunker

zawartość strony B:

01) Fighter Pilot
02) Chimera
03) S.T.O.R.M
04) Jump
05) Electrician
06) Landscape
07) Star Raiders II
08) Boulder Dash
09) Gremlins
10) Super Cobra
11) Archon
12) Gyruss
13) Behind Jaggi Lines
14) Moon Patrol
15) Caverns of Khafka
16) Jungle Hunt
17) Atari Tennis
18) Iron Roadway
19) River Raid
20) Pengo
21) Alley Cat
22) Colossus Chess 3.0
23) Fort Apocaplypse
24) Tapper
25) Donkey Kong Junior
26) Pole Position

I chyba to wszystko co chciałem napisać o tej kasecie. Ufff. Kolejny punkt z listy "to do" mogę wykreślić ;) Kaseta już została zgrana i przetworzona dość dawno temu, jednak dopiero teraz znalazłem czas i siły aby się ogarnąć i wyprodukować ten post.

A nice one! I see there is no color-bars during loading the data records, probably due to tight-timing loops when turbo stream is decoded via CPU with those insane speeds :D

82

(4 odpowiedzi, napisanych Emulacja - 8bit)

Nie wiem czy to to, ale miałem podobny efekt gdy uruchamiałem atari800 pod Debianem 12.x ... Pomogło dodanie opcji -nojoystick podczas uruchamiania emulatora z linii komend. W moim wypadku SDL z którego korzysta atari800 myślał że mam w systemie jakiś joystick, którego oczywiście nie miałem.

83

(20 odpowiedzi, napisanych Bałagan)

QWERTZ czy polskie opisy to żaden problem.

84

(20 odpowiedzi, napisanych Bałagan)

Lt_Bri napisał/a:

Oddam maszyny Casiowriter CW-600 i Quasar 180 DS.

Byłbym zainteresowany tym Casiowriter CW-600, wysłałem e-mail via forum.

85

(115 odpowiedzi, napisanych Software, Gry - 8bit)

Rzucę okiem, ale to za czas jakiś, proszę o cierpliwość :)

86

(53 odpowiedzi, napisanych Sprzęt - 8bit)

Cześć!

Prawdę mówiąc to mam mieszane odczucia... bo jeden z joyów po naprawie działa nieco gorzej niż drugi ... i nie wiem czy to dlatego że jeden z wydruków wyszedł gorzej czy też dlatego że był bardziej "męczony", zaraz po wymianie oba sprawowały się znakomicie ... a po jakimś czasie jeden z nich zaczął wyraźnie "mulić", tzn. czuję że wymaga większego wkładu siły aby dany kierunek załapał, szczególne odczuwalne są "skosy".

Potem czasu na hobby ubyło i nie miałem okazji więcej srogo męczyć tych joyów, a że nadarzyła się okazja i tanio dorwałem oryginał (CX-40) to przesiadłem się na niego. Po jakimś czasie RZóG podrzucił mi do testów obecnie produkowany CX-40+ ... i początkowo myślałem że ten CX-40+ zupełnie nie będzie mi leżał, bo zamiast blaszek ma po prostu klasyczne rozwiązanie oparte o "gumki przewodzące"... ale koniec końców spodobało mi  się to na tyle że obecnie używam właśnie CX-40+, a tamte chińskie produkty gniją gdzieś na dole szuflady... więc testy wytrzymałościowe na razie zostały odłożone... ale być może przy najbliższej partyjce Megablast-a czy Joust-a może wezmę je na warsztat ponownie.

CX40+ w środku wygląda tak (zdjęcie dzięki uprzejmości RZóG):
http://seban.pigwa.net/aa/CX40+.jpg

87

(6 odpowiedzi, napisanych Software, Gry - 8bit)

@w1k: thanks for uploading this version. This is very interesting artifact from the past!

88

(29 odpowiedzi, napisanych Sprzęt - 8bit)

2nd test: uploaded material: 1920x1080p@50Hz, H264 codec (encoder: ffmpeg + vaapi)

https://www.youtube.com/watch?v=vcvdYA6xjFI

[info] Available formats for vcvdYA6xjFI:
ID  EXT   RESOLUTION FPS CH │   FILESIZE   TBR PROTO │ VCODEC          VBR ACODEC      ABR ASR MORE INFO
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
sb3 mhtml 48x27        0    │                  mhtml │ images                                  storyboard
sb2 mhtml 56x45        0    │                  mhtml │ images                                  storyboard
sb1 mhtml 112x90       0    │                  mhtml │ images                                  storyboard
sb0 mhtml 225x180      0    │                  mhtml │ images                                  storyboard
233 mp4   audio only        │                  m3u8  │ audio only          unknown             [en] Default
234 mp4   audio only        │                  m3u8  │ audio only          unknown             [en] Default
139 m4a   audio only      2 │    2.58MiB   49k https │ audio only          mp4a.40.5   49k 22k [en] low, m4a_dash
140 m4a   audio only      2 │    6.84MiB  129k https │ audio only          mp4a.40.2  129k 44k [en] medium, m4a_dash
251 webm  audio only      2 │    5.26MiB  100k https │ audio only          opus       100k 48k [en] medium, webm_dash
269 mp4   180x144     25    │ ~  7.81MiB  144k m3u8  │ avc1.4D400B    144k video only
160 mp4   180x144     25    │    4.09MiB   77k https │ avc1.4D400B     77k video only          144p, mp4_dash
603 mp4   180x144     25    │ ~  6.47MiB  120k m3u8  │ vp09.00.11.08  120k video only
278 webm  180x144     25    │    3.10MiB   59k https │ vp09.00.11.08   59k video only          144p, webm_dash
229 mp4   300x240     25    │ ~ 13.66MiB  253k m3u8  │ avc1.4D400D    253k video only
133 mp4   300x240     25    │    9.10MiB  172k https │ avc1.4D400D    172k video only          240p, mp4_dash
604 mp4   300x240     25    │ ~ 10.54MiB  195k m3u8  │ vp09.00.20.08  195k video only
242 webm  300x240     25    │    6.49MiB  123k https │ vp09.00.20.08  123k video only          240p, webm_dash
230 mp4   450x360     25    │ ~ 31.63MiB  585k m3u8  │ avc1.4D4015    585k video only
134 mp4   450x360     25    │   18.75MiB  355k https │ avc1.4D4015    355k video only          360p, mp4_dash
18  mp4   450x360     25  2 │   23.59MiB  447k https │ avc1.42001E         mp4a.40.2       44k [en] 360p
605 mp4   450x360     25    │ ~ 20.59MiB  381k m3u8  │ vp09.00.21.08  381k video only
243 webm  450x360     25    │   10.68MiB  202k https │ vp09.00.21.08  202k video only          360p, webm_dash
231 mp4   600x480     25    │ ~ 53.18MiB  983k m3u8  │ avc1.4D401E    983k video only
135 mp4   600x480     25    │   38.28MiB  725k https │ avc1.4D401E    725k video only          480p, mp4_dash
606 mp4   600x480     25    │ ~ 30.01MiB  555k m3u8  │ vp09.00.30.08  555k video only
244 webm  600x480     25    │   18.46MiB  350k https │ vp09.00.30.08  350k video only          480p, webm_dash
22  mp4   900x720     25  2 │ ≈ 61.08MiB 1129k https │ avc1.64001F         mp4a.40.2       44k [en] 720p
136 mp4   900x720     25    │   52.87MiB 1002k https │ avc1.64001f   1002k video only          720p, mp4_dash
247 webm  900x720     25    │   30.15MiB  571k https │ vp9            571k video only          720p, webm_dash
311 mp4   900x720     50    │ ~107.71MiB 1992k m3u8  │ avc1.640020   1992k video only
298 mp4   900x720     50    │   76.57MiB 1451k https │ avc1.640020   1451k video only          720p50, mp4_dash
612 mp4   900x720     50    │ ~ 73.49MiB 1359k m3u8  │ vp09.00.40.08 1359k video only
302 webm  900x720     50    │   50.65MiB  960k https │ vp09.00.40.08  960k video only          720p50, webm_dash
312 mp4   1350x1080   50    │ ~134.03MiB 2478k m3u8  │ avc1.64002A   2478k video only
299 mp4   1350x1080   50    │   99.27MiB 1881k https │ avc1.64002A   1881k video only          1080p50, mp4_dash
617 mp4   1350x1080   50    │ ~105.89MiB 1958k m3u8  │ vp09.00.41.08 1958k video only
303 webm  1350x1080   50    │   76.02MiB 1440k https │ vp09.00.41.08 1440k video only          1080p50, webm_dash
623 mp4   1800x1440   50    │ ~249.54MiB 4615k m3u8  │ vp09.00.50.08 4615k video only
308 webm  1800x1440   50    │  181.44MiB 3437k https │ vp09.00.50.08 3437k video only          1440p50, webm_dash

^^^ o! a jednak coś się zmieniło od czasu moich ostatnich eksperymentów, nie dość że dostałem teraz 50fps, to jeszcze VP9 mi się trafiło. Jak pisałem wcześniej pod koniec 2023 roku, wrzucając taki materiał nie dostałem ani VP9 ani 50fps. Niestety poziomy scroll szarpie od czasu do czasu mimo że odświeżanie monitora ustawione jest na 50Hz.

89

(29 odpowiedzi, napisanych Sprzęt - 8bit)

1st test; uploaded material 720x576@49.86Hz, H264 codec:

https://www.youtube.com/watch?v=kW9OHxAWFIQ

[info] Available formats for kW9OHxAWFIQ:
ID  EXT   RESOLUTION FPS CH │  FILESIZE  TBR PROTO │ VCODEC         VBR ACODEC      ABR ASR MORE INFO
─────────────────────────────────────────────────────────────────────────────────────────────────────────────
sb3 mhtml 48x27        0    │                mhtml │ images                                 storyboard
sb2 mhtml 56x45        0    │                mhtml │ images                                 storyboard
sb1 mhtml 112x90       0    │                mhtml │ images                                 storyboard
sb0 mhtml 225x180      0    │                mhtml │ images                                 storyboard
233 mp4   audio only        │                m3u8  │ audio only         unknown             Default
234 mp4   audio only        │                m3u8  │ audio only         unknown             Default
139 m4a   audio only      2 │   2.58MiB  49k https │ audio only         mp4a.40.5   49k 22k low, m4a_dash
140 m4a   audio only      2 │   6.84MiB 129k https │ audio only         mp4a.40.2  129k 44k medium, m4a_dash
251 webm  audio only      2 │   5.26MiB 100k https │ audio only         opus       100k 48k medium, webm_dash
269 mp4   180x144     25    │ ~ 7.51MiB 139k m3u8  │ avc1.4D400B   139k video only
160 mp4   180x144     25    │   3.78MiB  72k https │ avc1.4D400B    72k video only          144p, mp4_dash
230 mp4   450x360     25    │ ~30.05MiB 556k m3u8  │ avc1.4D4015   556k video only
134 mp4   450x360     25    │  18.54MiB 351k https │ avc1.4D4015   351k video only          360p, mp4_dash
18  mp4   450x360     25  2 │  23.65MiB 448k https │ avc1.42001E        mp4a.40.2       44k 360p
605 mp4   450x360     25    │ ~21.12MiB 391k m3u8  │ vp09.00.21.08 391k video only
231 mp4   600x480     25    │ ~50.94MiB 942k m3u8  │ avc1.4D401E   942k video only
135 mp4   600x480     25    │  37.27MiB 706k https │ avc1.4D401E   706k video only          480p, mp4_dash

^^^ jak widać max rozdzielczość materiału docelowego to 600x480@25fps.

90

(29 odpowiedzi, napisanych Sprzęt - 8bit)

Hej!

@dely: To może inaczej i bardziej szczegółowo... jak wrzucasz stream na YT to ten generuje masę dodatkowych strumieni różnej jakości, np. to wideo które dałeś jako przykład (sf_oDFk93EI) jest dostępne w następujących formatach:

[info] Available formats for sf_oDFk93EI:
ID  EXT   RESOLUTION FPS CH │    FILESIZE   TBR PROTO │ VCODEC          VBR ACODEC      ABR ASR MORE INFO
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────
sb3 mhtml 48x27        0    │                   mhtml │ images                                  storyboard
sb2 mhtml 80x45        0    │                   mhtml │ images                                  storyboard
sb1 mhtml 160x90       0    │                   mhtml │ images                                  storyboard
sb0 mhtml 320x180      0    │                   mhtml │ images                                  storyboard
233 mp4   audio only        │                   m3u8  │ audio only          unknown             Default
234 mp4   audio only        │                   m3u8  │ audio only          unknown             Default
599 m4a   audio only      2 │    11.78MiB   31k https │ audio only          mp4a.40.5   31k 22k ultralow, m4a_dash
600 webm  audio only      2 │    12.49MiB   33k https │ audio only          opus        33k 48k ultralow, webm_dash
139 m4a   audio only      2 │    18.67MiB   49k https │ audio only          mp4a.40.5   49k 22k low, m4a_dash
249 webm  audio only      2 │    18.51MiB   48k https │ audio only          opus        48k 48k low, webm_dash
250 webm  audio only      2 │    24.25MiB   63k https │ audio only          opus        63k 48k low, webm_dash
140 m4a   audio only      2 │    49.55MiB  129k https │ audio only          mp4a.40.2  129k 44k medium, m4a_dash
251 webm  audio only      2 │    47.80MiB  125k https │ audio only          opus       125k 48k medium, webm_dash
597 mp4   256x144     15    │    13.40MiB   35k https │ avc1.4d400b     35k video only          144p, mp4_dash
602 mp4   256x144     15    │ ~  46.12MiB  118k m3u8  │ vp09.00.10.08  118k video only
598 webm  256x144     15    │    13.55MiB   35k https │ vp9             35k video only          144p, webm_dash
269 mp4   256x144     30    │ ~  80.04MiB  204k m3u8  │ avc1.4D400C    204k video only
160 mp4   256x144     30    │    37.66MiB   98k https │ avc1.4D400C     98k video only          144p, mp4_dash
603 mp4   256x144     30    │ ~  81.10MiB  207k m3u8  │ vp09.00.11.08  207k video only
278 webm  256x144     30    │    41.11MiB  107k https │ vp09.00.11.08  107k video only          144p, webm_dash
229 mp4   426x240     30    │ ~ 137.19MiB  350k m3u8  │ avc1.4D4015    350k video only
133 mp4   426x240     30    │    87.92MiB  230k https │ avc1.4D4015    230k video only          240p, mp4_dash
604 mp4   426x240     30    │ ~ 143.77MiB  367k m3u8  │ vp09.00.20.08  367k video only
242 webm  426x240     30    │    83.39MiB  218k https │ vp09.00.20.08  218k video only          240p, webm_dash
230 mp4   640x360     30    │ ~ 300.40MiB  767k m3u8  │ avc1.4D401E    767k video only
134 mp4   640x360     30    │   191.08MiB  499k https │ avc1.4D401E    499k video only          360p, mp4_dash
18  mp4   640x360     30  2 │   228.57MiB  597k https │ avc1.42001E         mp4a.40.2       44k 360p
605 mp4   640x360     30    │ ~ 269.82MiB  689k m3u8  │ vp09.00.21.08  689k video only
243 webm  640x360     30    │   146.51MiB  383k https │ vp09.00.21.08  383k video only          360p, webm_dash
231 mp4   854x480     30    │ ~ 549.71MiB 1403k m3u8  │ avc1.4D401F   1403k video only
135 mp4   854x480     30    │   375.30MiB  981k https │ avc1.4D401F    981k video only          480p, mp4_dash
606 mp4   854x480     30    │ ~ 441.89MiB 1128k m3u8  │ vp09.00.30.08 1128k video only
244 webm  854x480     30    │   258.67MiB  676k https │ vp09.00.30.08  676k video only          480p, webm_dash
22  mp4   1280x720    30  2 │ ≈ 833.23MiB 2126k https │ avc1.64001F         mp4a.40.2       44k 720p
136 mp4   1280x720    30    │   764.61MiB 1998k https │ avc1.64001f   1998k video only          720p, mp4_dash
247 webm  1280x720    30    │   477.62MiB 1248k https │ vp9           1248k video only          720p, webm_dash
311 mp4   1280x720    60    │ ~   1.53GiB 3995k m3u8  │ avc1.640020   3995k video only
298 mp4   1280x720    60    │     1.12GiB 2988k https │ avc1.640020   2988k video only          720p60, mp4_dash
612 mp4   1280x720    60    │ ~   1.56GiB 4088k m3u8  │ vp09.00.40.08 4088k video only
302 webm  1280x720    60    │  1023.48MiB 2674k https │ vp09.00.40.08 2674k video only          720p60, webm_dash
312 mp4   1920x1080   60    │ ~   2.64GiB 6910k m3u8  │ avc1.64002A   6910k video only
299 mp4   1920x1080   60    │     2.07GiB 5547k https │ avc1.64002A   5547k video only          1080p60, mp4_dash
617 mp4   1920x1080   60    │ ~   2.36GiB 6175k m3u8  │ vp09.00.41.08 6175k video only
303 webm  1920x1080   60    │     1.63GiB 4356k https │ vp09.00.41.08 4356k video only          1080p60, webm_dash

te wszystkie strumienie są generowane na podstawie jednego wrzucanego video. Ilość formatów które YT generuje i ich jakość zależy od kilku czynników, od rozdzielczości materiału czy FPS-ów źródłowego jak najbardziej, ale ilość generowanych streamów zależy również od tego ilu subskrybentów i jak bardzo oglądany jest dany kanał.

Do niedawna było tak że wrzucało się 1080p@50Hz i taki strumień dołaczał również YT generowanych przez siebie streamach. Ja z moją bliską zeru ilością subskrybentów, a w dodatku z filmami "niepublicznymi", dostawałem początkowo 50fps gdy uploadowałem materiały w rozdzielczości 1080p@50Hz, potem YT zmieniło politykę i okazało się że 1080p@50/60Hz dla takich "pikusiów" jak ja jest niedostępne. Jednym ze sposobów ominięcia tego ograniczenia było przeskalowanie materiału do 2048x1152, dopiero wtedy dostawałem kodek VP9@50Hz. W innym przypadku zrzucali mnie do h264(avc1) i 25fps. Tak było jeszcze w grudniu 2023, ale być może znowu się coś zmieniło sprawdzę.

Dodam tylko że nie zależało to od kodeka... bo używałem robiłem upload w h264, h265, vp8, vp9, av1. Nie miało to żadnego znaczenia.

Jako użytkownik który wrzuca filmy na których nie da się "zarobić" (czytaj wyświetlić reklam) jestem dla YT czystą stratą więc próbują mnie ograniczać jak mogą, przynajmniej tak mi się wydaje. Zrobię zaraz dodatkowy test i wrzucę jeden z .MKV które wrzucałem wyżej i zobaczymy co mi YT z tego zrobi.

91

(29 odpowiedzi, napisanych Sprzęt - 8bit)

Hej!

Co to YT, to w chwili obecnej FullHD (1920x1080p) to za mało aby YT zechciał Ci wygenerować potem  50fps stream. Obecnie minimalny rozmiar obrazu aby YT zechciał umieścić strumień 50/60fps to 2048x1152, ale to najmniejszy problem. YT i tak zrobi sieczkę przy enkodowaniu takiego strumienia... będzie z 49.86Hz robił sobie 50Hz (wiem po sprawdziłem wrzucając i ściągając potem testowy materiał) co spowoduje co jakiś czas wnerwiające "szarpnięcia" na scrollach i wszystkich efektach które mają 50fps, ale to też jest do obejścia, bo mogę z tego strumienia 49.86Hz zrobić strumień 50Hz z "przesuniętym w widmie" strumieniem audio tak aby nie zmieniła się częstotliwość dźwięku przy przyspieszonej ścieżce video (49.86Hz --> 50Hz) ... niestety tutaj pojawiają się kolejne problemy... większość ludzi ma monitory które nie potrafią 50Hz a przynajmniej nie potrafią pod Windows.

YT robi wszystko aby wyświetlić strumień 60fps, a nawet jak wyświetli 50fps przy odświeżaniu monitora 60Hz czy więcej to nie muszę mówić jak to tragicznie wygląda (wstawionych 10 dodatkowych interpolowanych/powtórzonych klatek). W dodatku tak namieszali przy swoich playerach (np. chromecast), że teraz za nic chce przełączyć się na 50Hz gdy taki strumień jest dostępny. Do niedawna mój chromecast podpięty do TV przy odtwarzaniu streamu @50fps przełączał się taki tryb wyświetlania o czym TV mnie informował, od jakiegoś czasu (po aktualizacjach) chromecast trzyma 60fps jaki strumień nie byłby odtwarzany, no kicha totalna. Wszystkie dema wrzucone na YT @50fps po prostu szarpią i wyglądają teraz źle ;/

Mogę oczywiście przygotować strumienie przyspieszone do 60fps z przesuniętym w widmie dźwiękiem, ale po co? Szkoda waszego i mojego czasu chyba na taką zabawę. Te materiały które udostępniłem mają na celu pokazanie jakości jaką generuje tandem GTIADigitizer+RGB2HDMI, a to można ocenić sobie oglądając pliki .MKV które zamieściłem (nawet pojedyncze klatki) ... obraz jest po prostu pixel perfect, a RGB2HDMI podpięte do monitora czy TV który umie 50Hz generuje obraz idealnie płynny i nie przeszkadza mu to że jest to video 49.86Hz, sync jest idealny.

Teraz co do reszty zagadnień które poruszyłeś; OBS nie mogę używać ponieważ nie daje mi on pełnej kontroli nad moim graberem, więcej kontroli nad procesem zgrywania materiału mogę osiągnąć używając ffmpeg niż używając OBS i jego GUI. OBS mimo tego że miał ustawione aby nie ruszał frame-rate materiału wejściowego i tak koniec końców robił 50fps z okazyjnymi szarpnięciami w scrollach.

Co do kodeków to dla YT nie ma znaczenia w jakiej formie mu wrzucę materiał, testowo kodowałem nawet materiał w ultra jakości używając kodeka AV1 ale YT uznawał że jestem zbyt małym "pikusiem" (nawet linków nie mogę obecnie umieszczać w opisach na pod materiałami na YT które wrzucam) i koniec końców zostawał mi przydzielony tylko i wyłącznie stream kodowany kodekiem VP9. Tylko duże i popularne kanały dostają streamy AV1.

Mam jakąś starą kartę NV (Quadro P600) na której nvenc potrafi niby generować stream H265, ale ogólnie unikam produktów tejże firmy, więc karta jest obecnie "on the shelf". To co mam w kompie obecnie potrafi sprzętowo robić H265 i AV1, ale jak pisałem wyżej na YT nie ma to znaczenia... on i tak robi re-encoding wszystkiego co mu wrzucasz, wpływu na to co zrobi z Twojego materiału masz niewiele. Zresztą jest masa różnych materiałów i analiz tego jak należy przygotować materiał video dla YT aby ten był "łaskawy" przy enkodowaniu Twojego video... ale to są problemy którymi zajmują się o wiele więksi i poważniejsi ludzie niż ja, ja jestem tylko amatorem w tej dziedzinie i mogę się jedynie "pobawić" nieco aby zgłębić temat i przetestować rozwiązania które mi się w głowie uroiły :)

I parę słów na koniec abym nie został źle zrozumiany... ten mój cały wywód nie ma na celu mądrzenia się, albo negowania Twoich rad... ja po prostu opisałem swoje doświadczenia przy walce z kodowaniem rozsądnej jakości materiałów video pochodzących z naszej 8-bit maszyny... o ile te materiały da się jakoś sensownie "grabować" to niestety 50fps zarówno dla samego YT jak i dla większości sprzętu u ludzi jest problemem... a płynność generowanego obrazu (wszystkie efekty wyciągające 50fps oraz scrolle) i czas odpowiedzi monitorów kineskopowych jest obecnie problemem dla nowoczesnego sprzętu. Nawet jak mi się udaje wyświetlić stream 49.86Hz na monitorze z freesync to powiem Ci że matryce LCD mogą się schować (przynajmniej te w monitorach którymi dysponuje) w porównaniu z CRT. Nie testowałem jeszcze żadnego OLED-a, być może tam jest lepiej... ale na razie nie mam w planach takich wydatków. Technologia LCD jest jaka jest... dużo jej brakuje do ideału jeżeli chodzi o czasy reakcji matryc. Natomiast jeżeli chodzi o geometrię i jakość wyświetlanego obrazu tutaj nie mam zastrzeżeń :D

Reasumując, fajnie że chciało Ci się napisać parę słów o Twoich doświadczeniach z YT, bo to spowodowało że w sumie zainspirowałeś mnie do opisania swoich doświadczeń z YT. Kiedyś chciałem zgrywać wszystkie demka z JIL w bardzo dobrej jakości i wrzucić je na YT, jednak YT nie lubi takich materiałów ... ową mistyczną "płynność" YT ma głęboko w poważaniu i z aktualizacji na aktualizację jest coraz gorzej. Kiedyś wrzuciłem 50fps video paru dem ze stajni "Slight" (to były czasy gdy popularne było windows7) ... miałem wtedy monitor LCD który podpięty przez HDMI do komputera pozwalał na ustawienie odświeżania na 50Hz... wtedy materiały 50fps odtwarzane przez YT via przeglądarka wyglądały płynnie, dziś ten sam materiał odtwarzany na monitorze z ustawionym 50Hz nie odtwarza się tak płynnie jak kiedyś (widać przycięcia). Co YT popsuł? nie wiem. Wiem że sprzęt coraz lepszy, monitory coraz lepsze a software coraz gorszy :D

92

(29 odpowiedzi, napisanych Sprzęt - 8bit)

Hej!

Chwilę mi to zajęło aby to dobrze zgrać, ale się udało. Z tym że aby to obejrzeć w płynności są wymagane pewne wymagania, których pewnie nie spałełni większa część forumowiczów. Skracając i upraszczając wszystko:

1) Poniższe filmy nagrane są z częstotliwością 49.86Hz (dokładnie taką jaką generuje Atari 8-bit)
2) Aby uzyskać w 100% płynne odtwarzanie trzeba mieć monitor refresh rate ustawiony na 50Hz (lub mieć monitor z freesync i player który to ogarnie)
3) pliki są umieszczone w kontenerze .MKV w środku kontenera video w formacie h.264
4) niektóre pliki mają na początku zniekształcone audio, spowodowane jest to faktem iż zapomniałem wyłączyć AGC (ARW) w graberze i ten starał się wyciągnąć coś z ciszy która panowała przy wczytywaniu/dekompresji niektórych produkcji (nie chciało mi się tego ponownie zgrywać)

do pobrania:

"boldem" zaznaczyłem te produkcje w których występują wizualne artefakty.

a) Out 5oft - Unity Part - błędne kolory przy nałożeniu się PMG na grafikę w trybie GTIA
b) Revenge of Magnus - tło z grafiki PMG nad wszystkim sinus scroll w Hi-Res, ale jak widać na załączonym filmie grafika PMG drży (zły timing przy zmienianiu X-POS obiektów PMG)
c) Visdom II demo - w przypadku efektu przesuwających się prostokątów w trybach 9/10 widać że w trybie 10 brak przesunięcia o cykl koloru pomiędzy trybem 9/10.

Zapewne będzie problem z trymami HIP/TIP/RIP (nie sprawdzałem tego jeszcze). Ale sądzę że autor rozwiązania poprawi to. Muszę tylko jeszcze zgrać referencyjne materiały z użyciem RetroTink 2x z wyjścia normalnego GTIA.

ps) pliki leżą na pigwie, na YT nie da się tego wrzucić tak aby YT nie zrobił z tego sieczki (YT robi konwersję/rekompresję materiału przy wrzucaniu materiałów na ich serwery). Wszystkie te pliki zajmują około ~1GB, mogą się pojawić jakieś artefakty kompresji h.264, ale starałem się aby bitrate materiału był dość wysoki.

@uicr0Bee: dziękuję! mam nadzieję że w końcu coś ruszę dalej w wątku, ale początek roku na razie nazwijmy to "ciekawy" ;-)

@baktra: o super pomysł! Dla tych co nie mają decka, a mają tylko np. magnetofon z turbo i chcą sobie nagrać kasety na prawdziwym sprzęcie z epoki, to rozwiązanie w sam raz! :)

Z Twojego opisu wynika iż posiadasz Turbo 2000F/2001.

Soft do tego turbo w postaci .XEX był chociażby w tym poście: Turbo 2000F CMD & Phase Select Patch v.1.2. Wersję .XEX możesz załadować z dowolnego urządzenia I/O (SIO2PC, SIC! Cart, AVG Cart, SDRIVE, SIO2SD, etc.).

Jeżeli chciałbyś zbudować sobie cart albo uruchomić jako emulowany cart z poziomu np. AVG Cart to tutaj masz zawartość pamięci EPROM: Turbo 2001 v.2.1 Cartridge

95

(11 odpowiedzi, napisanych Sprzęt - 8bit)

Hej!

Miałem taką starą płytę 800XL w zapasach... wyciągnąłem po czasie i chciałem ją uruchomić... objawy takie jak u Ciebie, tzn. "black screen", pobór prądu przez płytę około 1.8A! co się okazało, większość pamięci DRAM padnięta, kostki osiągały po 90°C (słynne kości Micron):
http://seban.pigwa.net/aa/800xl_dram_fail.jpg

po wymianie na inne kości, wszystko wróciło do normy, a pobór prądu przez płytę spadł po około 750mA:
http://seban.pigwa.net/aa/800xl_dram_fixed.jpg

Także jeżeli kostki DRAM na tej płycie są gorące to nie masz co się zastanawiać i po prostu je wymień. W moim przypadku wszystkie 8 kostek było padniętych.

96

(29 odpowiedzi, napisanych Sprzęt - 8bit)

@willy: spoko nic się przecież nie stało! nie ma za co przepraszać! Przecież spokojnie sobie wymieniamy poglądy i dyskutujemy. Mi też chwilę zajęło zanim zrozumiałem po co i dlaczego c0pperDragon wymyślił sobie owe "lumacode", jak już załapałem i wiedziałem jaki obraz potrafi generować RGB2HDMI to nie mogłem się doczekać aż zobaczę to na własne oczy. Na szczęście RZóG-owi udało się to kupić gdy tylko się pojawiło w sklepie i miałem możliwość przetestowania tego rozwiązania.

A co do Twojego rozwiązania, faktycznie teraz pamiętam jak o tym pisałeś... ale przyznam szczerze, wtedy sądziłem że używając FIQ będzie ciężko to  samplować precyzyjnie beż żadnego dodatkowego sprzętowego FIFO... chyba koniec końców doszedłeś do podobnych wniosków i porzuciłeś projekt?

W przypadku RGB2HDMI mają dodatkowe CPLD które umożliwia samplowanie z rozdzielczością chyba coś około 10ns. Nie dokopałem się chyba nigdy (nie miałem potrzeby) jak dalej przenoszą ten sygnał, ale gdzieś coś mi mignęło w użwają do tego celu GPU z maliny... nie wiem tylko jak, ew. źle zrozumiałem co co kiedyś przeczytałem i mogę bredzić :)

@alex: ale wiesz że link do repo który zapodałeś to tylko taki dev-board z MAX10 (od Altera/Intel) + transceiver HDMI i nic poza tym? tam nie nic poza upscalerem na FPGA, to jest platforma testowa na której c0pperdragon sobie robił development i test dla danej platformy. Albo jestem ślepy albo nie widzę nic poza tym co zostało napisane w readme: D-Video board - Read Me. Reasumując nie ma tam żadnego kodu HDL-owego który by cokolwiek czytał z GTIA czy magistrali danych JIL. Ale może jestem ślepy i nie widzę?

97

(29 odpowiedzi, napisanych Sprzęt - 8bit)

@willy ... dla mnie wprost przeciwnie. Idea pomysłu (lumacode) jest taka że taki sygnał połączasz sobie zamiast sygnału RF z modulatora i nie wiercąc żadnej dziury w obudowie masz z danej maszyny wyprowadzony sygnał który potem podpinasz sobie jednym kablem ze złączem RCA do RGB2HDMI. Montaż w komputerze też może obyć się bez lutowania (o ile masz podstawkę pod GTIA). Tylko tyle i aż tyle. Dla mnie pomysł zacny i zamierzam niektóre swoje maszyny (GTIA/TIA/VIC-II/ULA) przerobić tak aby zamiast RF miały lumacode. Jednym HDMI2RGB obskoczę wszystko w dodatku dzięki profilom w RGB2HDMI mogę mieć pixel perfect odwzorowanie obrazy z tych maszyn na dowolnym monitorze czy TV z HMDI. Ustawione raz w taki sposób jaki mi odpowiada.

Ale zgadzam się... każdy może mieć swoją opinię o tym projekcie. Ja zaprezentowałem swoją, dość entuzjastyczną ale przedstawiłem też pewne niedociągnięcia i wady o których napisałem wyżej, mimo wszystko cieszę że ten projekt powstał i mogę sobie wybierać z wielu rozwiązań dostępnych obecnie dla różnych maszyn. Jeżeli preferujesz inne rozwiązania to ja doskonale to rozumiem i w żaden sposób nie zabraniam korzystania z nich.

LumaCode nie jest żadnym regenerowanym chroma... możesz porównać to do kodowania np. sygnałów LUMA i CHROMA za pomocą 2-bitowych sekwencji [chroma, luma, luma], to wszystko po to aby cały ten sygnał w formie cyfrowej transmitować jedno-przewodową linię transmisyjną. Wszystko to wyjaśniono na stronie projektu (github): GTIAdigitizer (for Atari 8bit).

cytat z powyższego linku:

c0pperDragon napisał/a:

Details on color encoding:

The Atari 8-bit computers can generate at total 256 colors: 16 hues, each of which can be shown in one of 16 luminosities. This would require a total of 8 bits of information needed for every pixel. But because of the way the colors are generated by the Atari internally, every two consecutive pixels share the same hue. So only a total of 12 bit is needed for every pair of pixels. These 12 bit will be encoded in the LumaCode signal with 6 samples (each transferring 2 bits). Grouping always two samples together (high bits first) to form a 4-bit number, three such numbers encode the data for a pixel pair in the following order: HUE, LUM1, LUM2.

98

(29 odpowiedzi, napisanych Sprzęt - 8bit)

@grzybson: ależ to żaden offtopic! dzięki za info! 

Ja mogę dodać tylko że c0opperDragon zrobił również "ULA Digitizer", można go znaleźć również w jego sklepie Tindie. Nie podaję linków aby nie było że coś reklamuję i promuje, każdy możne znaleźć na własną rękę. Jeżeli chodzi o "ULAdigitizer" to nie testowałem tego i za mało znam się na ZX spectrum więc trudno mi się nawet na ten temat wypowiedzieć.

Ale nawiązując do tematu który poruszyłeś, to podobny projekt (w sensie użycia RPi Pico) o nazwie GTIA2DVI powstaje dla Atari: https://github.com/maaakit/GTIA2DVI.  Człowiek o pseudonimie "markit" zaprezentował go na AoL w tym wątku: GTIA2DVI.

Ja się bardzo cieszę że jest tyle możliwości do wyboru i w dodatku że MarkIt zrobił ten projekt w pełni otwarty! (Open Hardware/Software). Takich projektów nam potrzeba na scenie! :)

99

(29 odpowiedzi, napisanych Sprzęt - 8bit)

Alex... przecież RGB2HDMI i jego "pokładowy" soft obsługuję masę maszyn, rozwiązań... to nie jest tylko do GTIA digitizera wersja. Tam ustawisz wszystko... i są profile dla wielu maszyn (np/ Amiga, Atari ST, Acorn, Amstrad) ... to naprawdę wspiera wiele maszyn. LumaCode jest jedną z opcji i pojawiła się niedawno (w sofcie w wersji BETA). GTIA jest potrzebna chociażby po to aby generować kolizje i video na standardowym wyjściu monitorowym. Moim zdaniem GTIA digitizer tylko sobie słucha tego co nadchodzi do GTIA i tego co generuje GTIA na wyjściach ANx, także słucha sobie magistrali danych aby pobrać informację o grafice PMG (kiedy ANTIC wystawia odpowiednie adresy) ... no ale skoro mi nie dowierzasz ... po prostu napisz do autora rozwiązania.

A co do tego że GTIA digitizer tylko słucha i że był już wcześniej problem z nazwijmy to "emulacja GTIA" zacytuję samego autora rozwiązania;

c0pperdragon napisał/a:

The board should work with all variants of the Atari 8-bit machines that have a CTIA/GTIA video chip. Boards shipped since 29.9.2023 have the firmware version 1.1 that fixes a display issue with the "Atari Control Picture" program. I know of no other program that did not work with the previous version already.

Należy tylko dodać że projekt GTIA digitizera nie jest otwarty (i nie wiem czy będzie) i na razie można go jedynie kupić na w sklepie Tindie u CopperDragon.

a co do:

I know of no other program that did not work with the previous version already

Jestem w trakcie formułowania opisu problemów które zauważyłem, więc liczę że autor dokona poprawek i będzie to rozwiązanie idealne :D

100

(29 odpowiedzi, napisanych Sprzęt - 8bit)

Wrzucę filmy to sam zobaczysz (ew. wpadnij do mnie i sam się przekonaj). Dlaczego sądzę że to emulacja GTIA? Bo np. kolory które wychodzą z nałożenia się grafiki PMG na "playfield" (w bardzo konkretnych przypadkach) wychodzą inaczej niż w przypadku bezpośredniego wyjścia z GITA, albo pozycje obiektów PMG np. w przypadku pierwszej części "Revenge of Magnus" (sinus scroll w hi-res + tło na PMG w górnej połowie ekranu) potrafią być inne niż w przypadku wyjścia z GTIA... efekt jest taki że obraz gwiazdek w tle jest poprzesuwany albo wręcz pozycje obiektów drżą o jedną linię skaningową.

Sądzę że autorowi prościej było wykonać emulację GTIA niż bawić się z precyzyjnym dekodowaniem sygnału "COLOR" z czym jak widać problem ma również autor projektu GTIA2DVI.

C0pperdragon ma doświadczenie w te klocki, a świadczą o tym chociażby jego pozostałe projekty (chociażby pełna emulacja VIC-II z wyjściem RGB, etc.). Mam również VIC-II digitizer, ale przyznaję że jeszcze nie zdążyłem go przetestować.

Samego RGB2HDMI używałem również z innymi maszynami i byłem bardzo zadowolony z rezultatów, jak tylko zobaczyłem że
c0pperdragon wypuścił pierwsze wersje swoich digitizerów z "lumacode" to od razu postanowiłem to przetestować. Czekam jeszcze na TIA digitizer i na pewno nie omieszkam zamieścić tutaj swoich doświadczeń z tymże również.

Jeden myk jest fajny z tym lumacode, tak jak pisał autor używa on 2-bitów do opisania stanu wyjścia/linii transmisyjnej... a więc mamy 4 możliwe stany do zakodowania na jednym drucie, całość protokołu pomyślana jest tak że tworzy on sygnał zbliżony do analogowego sygnału video (jeden ze stanów ma poziom "sync", pozostałe 3 stany służą do enkodowania transmitowanych bitów luminancji i chrominancji... a to powoduje że jak taki sygnał lumacode podepniesz do czegoś dekodującego composite video to widać obraz, co prawda nie jest to odwzorowanie właściwe, ale możesz dzięki temu zobaczyć że "digitizer" działa, oto przykład wyjścia z digitizera podpięty do "RetroTink 2x":

ekran Atari BASIC:
http://seban.pigwa.net/aa/gtia_digitizer/atari_basic.jpg

intro do gry Ballblazer:
http://seban.pigwa.net/aa/gtia_digitizer/ballblazer_intro.jpg

a tutaj przykładowy "atari control picture", wyjście z GTIA_digitizera podpięte do RGB2HDMI:
http://seban.pigwa.net/aa/gtia_digitizer/control_picture.jpg

screen z dema "Equation of Time / Our 5oft", w odpalonym menu RGB2HDMI:
http://seban.pigwa.net/aa/gtia_digitizer/eq_of_time.jpg