W oczekiwaniu na nowy programator (który pewnie przyjdzie "pod koniec tygodnia") stwierdziłem że przydałoby się przerzucić zrzut RAM'u z Amstradzika na PCta. Powstało pytanie - jak to zrobić nie mając żadnych kabelków, dyskietek, etc? Okazuje się że jest pewien (pewnie nie jeden), bardzo zabawny moim zdaniem, sposób ;D

Na początek w skrócie - pomysł opiera się na tym że CPC 464 wyświetla dane na monitorze, a PC za pomocą kamerki "internetowej" podpiętej pod USB je odczytuje. Proste, nie?

Pojawia się jednak kilka pytań - np. jak dane powinny być prezentowane? Ile ich powinno być? Jak szybko powinny się zmieniać? Jak poinformować PCta o tym że się zmieniły? Czy Amstrad nadąży wyświetlać? Czy kamerka nadąży "łapać" klatki? A co jeśli kamera "złapie" obraz w połowie przerysowywania? I tak dalej.

A więc po kolei. To jak dane powinny być prezentowane zależy od tego jak dobrą kamerką dysponujemy, i ile kodu chcemy napisać po stronie PCta. Pomysły są w sumie dwa:
- Prezentujemy dużo danych pokazanych w hexa, a po stronie PC mamy jakiś OCR (sieci neuronowe idealnie do tego się nadają imho) który te dane ładnie odczytuje (oczywiście literka po literce) - to wymaga dobrej jakości obrazu na kamerze, dużej rozdzielczości, oraz kapkę większej ilości kodu po stronie PC,
- Prezentujemy dane jako plamki/punkty (kwadraty, nie koniecznie wielkości 1 pixel) na ekranie, bit po bicie, a na PCcie sprawdzamy czy punkt jest jasny czy ciemny - ilość danych do przesłania zależy od rozdzielczości uzyskiwanego obrazu, rozdzielczości CPC 464, oraz jakości obrazu, wymaga to mniejszej ilości kodu na PC.

W moim przypadku skorzystałem z małej kamerki internetowej, w której dość trudno ustawić ostrość, etc, więc w końcu musiałem użyć drugiego sposobu (z kwadracikami). Uznałem że przesyłał będę naraz 8 bitów (mało, ale do celów doświadczalnych wystarczy w zupełności) co pół sekundy (jak dość łatwo wyliczyć, przesłanie całego RAMu CPC 464 - którego jest 64kb - zajęłoby około 10 godzin).

Kolejną sprawą jest "jak poinformować PC że jest nowy zestaw danych", czyli problem synchronizacji. Akurat to dość znany problem (patrz ethernet, USB, etc), który został już na różnorakie sposoby rozwiązany. W moim przypadku użyłem dodatkowego bitu jako flagi oznaczającej dane - flaga jest zapalona jeśli adres pokazywanego bajtu jest parzysty, oraz zgaszona jeśli jest nieparzysty (czyli na przemian ma wartości 101010101...). Wystarczy więc że PC zobaczy że flaga się zmieniła, i już wie że są nowe dane.

Co z problemem klatki złapanej w czasie przerysowywania danych? W moim przypadku zastosowałem prosty trik - flagę synchronizacji wyświetlam dwa razy - na początku oraz na końcu danych. Dzięki czemu jeśli zdarzy się że na klatce danych dane są do połowy przerysowane, to flagi synchronizacji będą różne, więc wiadomo że takie dane trzeba odrzucić. Na szczęście kamerka wyrabia około 3-5 klatek na porcję danych, więc dane takie nie są gubione, po prostu są odczytane w następnej klatce.

Podczas implementacji pojawił się jeszcze jeden problem, związany z tym że (niepotrzebnie zresztą) robiłem CLS między klatkami danych, i czasem kamera łapała pusty ekran, i uznawała że flagi synchronizacji są równie (obie na 0), a dane są równe 00000000. Aby to rozwiązać, zapamiętuje wszystkie warianty danych dla danej porcji (tzn dane z wszystkich klatek dla danego stanu flag synchronizujących), po czym gdy flagi się zmienią, to zapisuje środkowe dane. Nie było to może konieczne (wystarczyło to CLS wywalić), ale okazało się niezłym rozwiązaniem.

By the way...
On 22nd Nov'24 we're running a webinar called "CVEs of SSH" – it's free, but requires sign up: https://hexarcana.ch/workshops/cves-of-ssh (Dan from HexArcana is the speaker).

Jeżeli chodzi o PCta, to do obsługi kamerki posłużyłem się Windowsem, oraz WinAPI (musiałem updatenąć headerki/liby z WinAPI do MinGW'a, w starszych wersjach nie było tam wszystkich funkcji od kamerek), a konkretniej funkcjami i makrami z rodu cap* (capCreateCaptureWindow, capDriverConnect, etc, z vfw.h). Programik był dość prosty - okno z podglądem kamerki, oraz możliwością wybrania miejsc gdzie są poszczególne punkty. Potem trochę kombinowania z kalibracją (w moim przypadku najlepszy okazał się "wzór" typu "bit jest ustawiony na 0 jeśli kolor plamki nie jest zbliżony do białego, gdzie "zbliżony" oznaczało około 8% dopuszczalnej różnicy), poprawy bugów, i działa.

Kod źródłowy programiku na PC można ściągnąć tutaj, przy czym od razu zaznaczam, że jest bardzo słabo napisany (miał działać, a nie być śliczny ;D).
Kod źródłowy programiku na CPC 464 przepiszę jak skończy się RAM przerzucać (jeszcze tylko 8 godzin ;D).

Jeżeli chodzi o sprawy do przemyślenia "na potem", to sądzę że warto by w jakąś kompresję danych zainwestować - najlepiej RLE. W pamięci jest masa zer które niepotrzebnie zajmują "transfer". Warto by również wyświetlać więcej niż 8 bitów naraz.

Podsumowując, całość działa jak światłowód - medium jest powietrze, nadajnikiem monitor zamiast LEDki, a odbiornikiem kamera. Po za tym reszta się zgadza. Ze zabawnych rzeczy - aby chronić ten "układ" przed zakłóceniami (nagłe błyski, zapalenia światła, odbłyski na monitorze, etc), przykryłem całość kocem, przez co całość wygląda prawie jak wór (światłowór ;p).

Nyom, i tyle dziwnych pomysłów na dzisiaj.