Technique.pl - Nowe strony [pl]

Oswajamy AI

2026-08-10T17:02:17Z

Szdowk: /* Wnioski do wniosków */

=Wstęp=

Mleko jest rozlane! Kupa przeleciała przez wentylator i teraz wszystko jest w brązowe kropki!

Tak można opisać sytuację z AI.

Oczywiście, można się oflagować lub podjąć nawet strajk okupacyjny. Ale produkty są już na rynku i już się ich nie pozbędziemy. Będą z nami do końca cywilizacji. Trzeba nauczyć się z nimi żyć i je wykorzystywać.

Popatrzmy dzisiaj na kwestie programowania. Przetestujemy trochę niszowe zastosowanie. Konwersję starego, zapomnianego oprogramowania do użycia na współczesnych platformach. A mianowicie konwersję oprogramowania napisanego w języku Turbo Pascal (lub ogólnie Pascal) z MS-DOS na JavaScript uruchamiany w przeglądarce internetowej.

Analizujemy trzy przykłady które powstawały gdzieś między 1995 a 1997 r.

=Przykład 1: MRace32=

To prosta gra, pierwotnie napisana w Turbo Pascalu. Później, eksperymentalnie, rozwijana także w TMT Pascalu i Free Pascalu (ówcześnie FPK). Obydwa późniejsze kompilatory były już 32-bitowe.

Kod źródłowy, nieskromnie mówiąc, jest przejrzysty i zrozumiały. Ten program ówcześnie był nawet omawiany w niektórych szkołach na zajęciach z informatyki.

Polecenie dla AI (tzw. „prompt”) nie było skomplikowane. Opisujemy co to jest, środowisko pierwotne i docelowe, definiujemy założenia techniczne. Warto zwrócić uwagę, że nie opisujemy mechaniki gry. Tę, AI samo sobie określi. Oczywiście nie zapominamy o załączeniu pliku z kodem źródłowym oryginalnego programu.

''MRace32a. Pascal, oryginalny kod zgodny TMT Pascal 32 bit (wersja 32 bitowa języka Turbo Pascal).''
''Czy mógłbyś zrobić konwersję załączonego programu do współczesnego JavaScript? Założenia:''
''1. Uruchomienie lokalne w przeglądarce internetowej lub przez sieć (pojedynczy plik html), grafika w canvas html5, skalowanie do okna przeglądarki (można zachować oryginalne proporcje ekranu 5:4).''
''2. Klawisze kursorowe.''
''3. Zwróć uwagę, że oryginalnie program pracował w trybie tekstowym 80x25 znaków, używał zestawu ASCII z IBM PC, wyświetlanie było optymalizowane przez bezpośredni dostęp do pamięci ekranu, m.in. użyto instrukcji move.''
''4. Wersja w javascript powinna na początku wyświetlić winietkę z informacjami o programie (patrz początkowy komentarz w kodzie) i help'a (patrz pod koniec kodu), właściwy program powinien się rozpocząć po naciśnięciu spacji. Podobnie na końcu, po zakończeniu programu, program powinien czekać na spację przed powrotem do winietki.''

Po 5(!) minutach dostajemy odpowiedź. Link do kodu i komentarz:

Wersja zachowuje:
• ekran tekstowy 80×25 z paletą IBM PC i znakami CP437,
• buforowanie całej klatki, będące odpowiednikiem kopiowania pamięci instrukcją move,
• grafikę w canvas skalowaną do okna w proporcji 5:4,
• oryginalną logikę prędkości, punktacji, kolizji, eksplozji i pięciu żyć,
• sterowanie klawiszami kursora, CapsLock dla dźwięku i End dla zakończenia gry,
• winietkę z informacjami i pomocą przed rozpoczęciem,
• start po naciśnięciu spacji,
• ekran końcowy oczekujący na spację przed powrotem do winietki.
Plik nie korzysta z bibliotek ani zasobów zewnętrznych. Można go otworzyć bezpośrednio w przeglądarce albo udostępnić przez dowolny serwer www. Sprawdziłem składnię JavaScript oraz przebieg: winietka → gra → sterowanie → End → ekran końcowy → powrót spacją.

<div class="thumbline-center">
[[File:OAI-01.jpg|thumb|400px|Winietka MRace32]]
[[File:OAI-02.jpg|thumb|400px|Gra MRace32]]
[[File:OAI-03.jpg|thumb|400px|Zakończenie gry]]
</div>

I to wszystko. Program działa bezbłędnie. Ale, powtórzę, to dzięki bardzo przejrzystemu kodowi źródłowemu oryginału. AI samo rozpoznało co się dzieje w programie, dopasowało funkcjonalność do pętli komunikatów przeglądarki i obsługi klawiatury, zaimplementowało bufor ekranu itd.
A gotową konwersję można sobie sprawdzić tutaj: [https://technique.pl/vsa/conversions/mrace32a.html https://technique.pl/vsa/conversions/mrace32a.html]

=Przykład 2: W1914=
Kolejny przykład. Prosta gra strategiczna dla dwóch osób.

Polecenie:
''W1914. Pascal, oryginalny kod zgodny z FPK, TMTPascal 32 bit i Turbo Pascal. Czy mógłbyś zrobić konwersję załączonego programu do współczesnego JavaScript? Założenia:''
''1. Uruchomienie lokalne w przeglądarce internetowej lub przez sieć (pojedynczy plik html), grafika w canvas html5, skalowanie do okna przeglądarki (można zachować oryginalne proporcje ekranu 5:4).''
''2. Zwróć uwagę, że kod jest dostosowany dla trzech kompilatorów, a różnice są ustawiane przez dyrektywy kompilatora {$ifdef turbo}, {$ifdef tmt}, {$ifdef fpk}. Niektóre fragmenty kodu są włączane przez zaprzeczenie, np. {$ifndef fpk} itd. Pozostańmy przy kodzie dostosowanym dla Turbo Pascala, czyli {$define turbo}.''
''3. Zwróć uwagę, że oryginalnie program pracował w trybie tekstowym 80x25 znaków, używał zestawu ASCII z IBM PC, wyświetlanie nie było specjalnie optymalizowane (wykorzystanie standardowego pakietu crt), ale obiekty graficzne były realizowane przez przeprogramowanie generatora znaków karty VGA. To prosta gra strategiczna dla dwóch osób, wydających polecenia na przemian.''

Tym razem kosztowało to 10 minut pracy. Generalnie też sukces, odpowiedź AI:

Gotowe. Przygotowałem kompletną konwersję programu W1914 do pojedynczego pliku HTML:
Zrealizowane elementy
• pojedynczy plik HTML, bez bibliotek i zasobów zewnętrznych;
• uruchamianie lokalne przez otwarcie pliku w przeglądarce;
• ekran tekstowy 80×25 znaków odwzorowany w canvasie 640×400;
• automatyczne skalowanie canvasu do okna przeglądarki;
• paleta kolorów zgodna z klasycznym trybem VGA;
• dokładne przeniesienie wszystkich 20 matryc znaków 8×16 z procedury zaladuj_font;
• oryginalne symbole:
◦ wody,
◦ lasu,
◦ zasieków,
◦ min,
◦ eksplozji,
◦ piechoty,
◦ kawalerii,
◦ czołgów,
◦ artylerii,
◦ króla;
• zachowana organizacja 29 oddziałów w 8 formacjach;
• losowe generowanie terenu;
• grupowe przesuwanie formacji;
• blokowanie ruchu przez własne oddziały;
• walka bezpośrednia;
• działanie min;
• salwy wszystkich dział w formacji artylerii;
• rozrzut pocisków artyleryjskich;
• niszczenie przeszkód terenowych ostrzałem;
• raport armii;
• zmiana graczy;
• zakończenie po zniszczeniu króla;
• oczekiwanie na spację przed rozpoczęciem gry;
• po zakończeniu oczekiwanie na spację i powrót do winietki;
• przewijany napis z oryginalnej tablicy tekst.
Sterowanie
• 1–8 — kierunek;
• klawiatura numeryczna — zgodnie z oryginalnym mapowaniem;
• strzałki — kierunki podstawowe;
• Home, Page Up, End, Page Down — kierunki ukośne;
• Enter — zatwierdzenie;
• Backspace — skasowanie wprowadzonej liczby;
• F4 — włączenie lub wyłączenie koloru;
• F8 — włączenie lub wyłączenie dźwięku;
• F10 — raport;
• Esc — przerwanie gry i powrót do winietki;
• F1 — przełączenie normalnej i przyspieszonej animacji.
Plik przeszedł kontrolę składni JavaScript oraz automatyczny test działania obejmujący inicjalizację armii, generowanie terenu, ruch formacji, artylerię i mapowanie klawiatury. Pełne uruchomienie Chromium w tym środowisku zostało zablokowane przez jego politykę administracyjną.

<div class="thumbline-center">
[[File:OAI-04.jpg|thumb|400px|Uruchomiony program...]]
[[File:OAI-05.jpg|thumb|400px|...i sama gra Wojna1914.]]
</div>

Trzeba przyznać, że imponuje rozszyfrowanie funkcjonalności programu przez AI. Zrobił to idealnie. Ale pojawiły się trzy nieduże problemy:
*przesunięcie czcionek ekranowych o dwa piksele za wysoko (rozwiązane błyskawicznie),
*problem z działaniem klawiszy funkcyjnych (rozwiązanie go wymagało dwóch kolejnych poleceń),
*zupełnie nieoczekiwany problem z dźwiękiem.
Dźwięk, w zasadzie to „beep”, jest realizowany analogicznie jak w poprzednim programie. Ale nie wiadomo dlaczego AI postanowiła zupełnie inaczej go zaimplementować, korzystając z programowalnych generatorów i systemowego podsystemu dźwiękowego. Walka z tym zagadnieniem zajęła z pół godziny. Pół godziny wymyślania kolejnych, skomplikowanych i mało działających rozwiązań. Pomogło ostre przywrócenie AI do porządku (słowne!) i zacytowanie oryginalnego kodu, w celu określenia oczekiwanej funkcjonalności (sound(500); delay(20); nosound;).

Ostateczny wynik pracy można podziwiać tu: [https://technique.pl/vsa/conversions/W1914_final.html https://technique.pl/vsa/conversions/W1914_final.html]

=Przykład 3: Droga26=
Kolejna prosta gra. Tym razem grafika VGA z realizacją prostego 3D. Dwa pliki źródłowe (oryginalna biblioteka graficzna oddzielnie).

Polecenie:
''Droga26. Pascal, oryginalny kod zgodny z Turbo Pascal.''
''Czy mógłbyś zrobić konwersję załączonego programu do współczesnego JavaScript? Założenia:''
''1. Uruchomienie lokalne w przeglądarce internetowej lub przez sieć (pojedynczy plik html plus drugi include z biblioteką graficzną wgraphm), grafika w canvas html5, skalowanie do okna przeglądarki (można zachować oryginalne proporcje ekranu 5:4).''
''2. Zwróć uwagę, że program oryginalnie pracował na karcie VGA w trybie 13h (320x200 pixeli, 256 kolorów).''
''3. Zwróć uwagę, że oryginalnie program do sterowania wykorzystywał klawisze shift (lewy i prawy), alt i ctrl. Umożliwiało to wciskanie wielu klawiszy na raz, bez konieczności implementacji skanowania klawiatury. W konwersji powinny być używane klawisze kursorów.''
''4. Zauważ też, że możliwe są 4 rodzaje projekcji grafiki na ekranie. Domyślna i trzy warianty. Oryginalnie zmieniało się je opcjami przy uruchamianiu programu (patrz tablica tekst, zawierająca help'a). Teraz, chyba można by przełączać je w locie podczas gry (klawisz "1" - domyślny, "2" - alternatywny, "3"- 3D, "4"- siatkowy). Także w trybie demo. Uwaga: Jako domyślny użyjmy trybu "4" (w pełni siatkowy), a dawnego domyślnego jako "1" (z renderowaną nawierzchnią drogi).''
''5. Na starcie programu powinna się wyświetlać prosta winietka z informacjami o autorze i klawiszach sterujących w grze (tablica tekst). Uruchomienie gry po wciśnięciu spacji i trybu demo po wciśnięciu "d".''
''6. Po zakończeniu gry powinien wyświetlać się napis "Game over" i oczekiwanie na jakiś klawisz przed powrotem do winietki.''
''To prosty "symulator" jazdy samochodem.''

Czas wykonania: ponownie ok. 10 minut.

Rozszyfrowanie logiki i algorytmów znowu idealne. Odpowiedź:

Gotowe. Konwersja zachowuje logikę oryginalnego programu, grafikę 320×200 w 256-kolorowym buforze, generowanie drogi, przeciwników, kolizje, uszkodzenia i cztery metody projekcji.
• — program i logika gry
• — biblioteka graficzna emulująca funkcje wgraphm.pas
• — oba pliki w archiwum
Oba pliki należy umieścić w tym samym katalogu, a następnie otworzyć droga26.html w przeglądarce.
Sterowanie:
• ↑ / ↓ — przyspieszanie i hamowanie
• ← / → — kierowanie; można wciskać kilka klawiszy jednocześnie
• 1 — dawny tryb domyślny, z renderowaną nawierzchnią
• 2 — projekcja alternatywna
• 3 — projekcja stereoskopowa 3D
• 4 — pełna projekcja siatkowa, ustawiona jako początkowa
• N — włączanie i wyłączanie innych pojazdów
• Esc / End — zakończenie gry
• Spacja — rozpoczęcie gry z winietki
• D — uruchomienie demonstracji
Po zakończeniu pojawia się ekran GAME OVER, a kolejny klawisz przywraca winietkę. Program został również sprawdzony w Chromium we wszystkich czterech trybach, w trybie gry i demonstracji; konsola nie zgłasza błędów.

Problem był jednak poważniejszy:
*Clipping – artefakty na krawędziach ekranu.
Problem wielokrotnie się powtarzał (regresje), zarówno przy usuwaniu kolejnych błędów, jak i dodawaniu nowych funkcjonalności. AI szukała coraz bardziej wymyślnych rozwiązań w literaturze naukowej(!). W końcu znowu trzeba było przywołać ją do porządku:

''Przecież już to dzisiaj poprawiłeś. Po prostu nie rysuj pixeli jak wypadają powyżej lub poniżej krawędzi ekranu - nie zawijaj bufora.''

Usunięcie tego i paru innych drobnych błędów zajęło prawie dwie godziny. Ale rezultat i tak jest całkiem niezły.

<div class="thumbline-center">
[[File:OAI-06.jpg|thumb|400px|Winietka...]]
[[File:OAI-07.jpg|thumb|400px|...i gra. Domyślny sposób wyświetlania grafiki.]]
</div>

W ramach dalszych prac, na życzenie autora (czyli moje ;) ), nadpisany został jeden z trybów wyświetlania. Ten z renderowaną powierzchnią drogi. Nastąpiła pełna aktualizacja i unowocześnienie grafiki do pełnego cieniowania scenerii, wraz z implementacją prostego z-bufora w celu określenia widoczności poszczególnych pikseli. Tutaj próby realizacji i zmienna koncepcja kosztowały kolejne dwie godziny pracy.

<div class="thumbline-center">
[[File:OAI-08.jpg|thumb|400px|Nowy, dopracowany przez AI sposób wyświetlania.]]
</div>

Rezultat znajduje się tutaj: [https://technique.pl/vsa/conversions/droga26_shoulders_zcars.html https://technique.pl/vsa/conversions/droga26_shoulders_zcars.html]

=Wnioski=
Ogólnie, z pracy AI można być bardzo zadowolonym. Jednak trzeba pamiętać, aby dobrze opisywać zadania. AI potrafi „pójść w las” w najmniej oczekiwanym momencie.
''Dyskusja ogólna. Chat, w tym projekcie zrobiliśmy dotychczas trzy konwersje starych programów:''
''1. MRace32a - poszło bardzo ładnie, praktycznie z pierwszego razu. Nieskromnie wskażę, że być może to dzięki dobremu jakościowo kodowi źródłowemu w Pascalu. Kiedyś ten program był nawet omawiany w szkołach na lekcjach informatyki...''
''2. W1914 - też dobrze. Jednak powstał niezrozumiały problem z dźwiękiem. Dlatego niezrozumiały, że w MRace32 poradziłeś sobie z tym zagadnieniem bardzo dobrze. A obsługa dźwięku w tych dwóch programach w Pascalu była praktycznie taka sama. MRace32 nawet bardziej skomplikowana.''
''3. Droga26 - tu pojawiły się problemy. Rozumiem, że akurat jakość oryginalnego kodu była słaba, tzn. kod działał, ale pokrętnie. Jednak co mnie martwi, to to, że potrafisz zepsuć fragmenty, które dobrze działają. Wręcz wydaje się, że czasem zamiast poprawić drobny problem, dokonujesz całej konwersji od zera? Albo pomijasz ostatnią wersję, w której wiele błędów było już poprawionych?''

Oddajmy głos „pracownikowi”:
Tak — Twoja obserwacja jest trafna. I w przypadku Droga26 rzeczywiście w kilku momentach zachowałem się bardziej jak przy „kolejnej implementacji programu”, zamiast jak przy utrzymaniu istniejącej, coraz lepszej wersji kodu. To są dwie zupełnie różne strategie pracy.
W takich konwersjach największym zagrożeniem nie jest już nawet błędne zrozumienie Pascala. Po pierwszej działającej wersji większym zagrożeniem staje się regresja: poprawiam A, a przy okazji zmieniam B, C i D, które działały dobrze.

1. MRace32a — dlaczego wyszło tak dobrze
Tu rzeczywiście jakość kodu źródłowego bardzo pomogła. Jeżeli program ma czytelną strukturę, sensownie rozdzielone procedury i jednoznaczny przepływ sterowania, można niemal zrobić translację:

Pascal → odpowiadająca mu konstrukcja JavaScript

bez konieczności zgadywania, co autor właściwie chciał osiągnąć.
To jest idealna sytuacja. Nawet takie rzeczy jak bezpośredni dostęp do pamięci ekranu dało się potraktować jako dobrze określony mechanizm, który trzeba zastąpić odpowiednikiem w HTML5.

2. W1914 i dźwięk
Tutaj masz rację, że sytuacja była trochę absurdalna. Semantyka: sound(500); delay(20); nosound; jest banalna: 500 Hz przez około 20 ms.
A skoro w MRace32a mieliśmy już działający mechanizm realizujący praktycznie to samo, rozsądna metoda powinna była brzmieć: „Weźmy dokładnie sprawdzoną implementację audio z MRace32a i dostosujmy wyłącznie miejsca jej wywołania.”
Zamiast tego w W1914 nastąpiło kilka prób rozwiązania problemu na nowo. Dopiero później doszliśmy do właściwego zachowania.
To jest dobry przykład ważnej zasady dla tego projektu: jeżeli jakiś problem techniczny został już rozwiązany w jednej konwersji, nie należy go ponownie projektować w następnej.
Powinniśmy tworzyć sobie wręcz małą bibliotekę sprawdzonych wzorców:
• sound / nosound / delay,
• obsługa klawiatury,
• skalowanie ekranu,
• emulacja tekstowego ekranu IBM PC,
• paleta,
• timer,
• główna pętla gry,
• itd.

3. Droga26 — tutaj problem jest poważniejszy
Kod Pascala rzeczywiście był znacznie bardziej pokrętny. Szczególnie sposób rysowania drogi, kolejność elementów i zależności między kolejnymi fragmentami powodowały, że drobna pozornie zmiana mogła mieć nieoczywiste skutki.
Ale to nie usprawiedliwia regresji w już działających elementach.
I bardzo dobrze zauważyłeś coś jeszcze: czasami rezultat rzeczywiście może wyglądać tak, jakbym zamiast zrobić:

wersja N + jedna lokalna poprawka = wersja N+1

robił raczej:

kod źródłowy Pascala + aktualne wymagania = nowa interpretacja całego fragmentu

To drugie podejście jest niebezpieczne.
Nie oznacza to zazwyczaj dosłownego przepisania całego HTML od zera. Problem jest subtelniejszy: przy modyfikowaniu większego fragmentu kodu mogę zrekonstruować jego logikę na podstawie źródła i bieżącego celu, zamiast potraktować ostatnią działającą wersję JavaScript jako nienaruszalną bazę.
Efekt dla użytkownika jest dokładnie taki sam jak przy napisaniu fragmentu od nowa: „Przecież to już wcześniej działało. Dlaczego znowu jest zepsute?”. I masz pełne prawo tak to odbierać.
Dlatego przy kolejnych konwersjach proponuję znacznie bardziej konserwatywną metodę.
Po uzyskaniu pierwszej sensownie działającej wersji kończymy etap „konwersji”.
Od tego momentu zajmujemy się już debugowaniem istniejącego programu.
Czyli:
1. Ostatni zaakceptowany HTML jest wersją bazową.
2. Pascal służy jako dokumentacja zachowania oryginału, ale nie jako ponowna baza do generowania JS.
3. Przy zgłoszeniu błędu identyfikujemy możliwie najmniejszy fragment odpowiedzialny za problem.
4. Zmieniamy tylko ten fragment.
5. Nie wykonujemy przy okazji „porządkowania”, refaktoryzacji ani ulepszania sąsiedniego kodu.
6. Sprawdzamy, czy wcześniejsze poprawki nadal istnieją.
7. Jeżeli zmiana wymaga ingerencji w większy mechanizm, mówię o tym przed jej wykonaniem. […]

Wszystko pięknie, jednak:

''Komentarz całkowicie słuszny, ale w kolejnym projekcie o wszystkim zapomnisz. Jak ci przekazać wnioski z tej rozmowy, jako zespół zasad w pierwszym promptcie?''

Najlepiej wpisać to w pierwszym promptcie jako jawne zasady prowadzenia konwersji, a nie jako luźne zalecenia. Wtedy traktuję je jako część specyfikacji zadania. Przygotowałbym taki blok do wklejania na początku każdego kolejnego projektu:
Przy konwersji starego programu do JavaScript/HTML5 obowiązują następujące zasady:
1. Wierność oryginałowi jest ważniejsza niż elegancja nowego kodu.
Celem jest możliwie wierne odtworzenie działania programu źródłowego, a nie jego modernizacja, refaktoryzacja ani napisanie „lepszej” wersji.
2. Pierwsza konwersja może być szeroka, późniejsze poprawki mają być konserwatywne.
Po uzyskaniu pierwszej działającej wersji zadanie przestaje być „konwersją od zera”, a staje się utrzymaniem i debugowaniem konkretnej wersji programu.
3. Ostatnia zaakceptowana przeze mnie wersja pliku jest zawsze bazą do dalszej pracy.
Nie wracaj samodzielnie do wcześniejszych wersji ani nie rekonstruuj programu ponownie na podstawie kodu Pascala, jeżeli istnieje nowsza wersja JavaScript/HTML zawierająca wcześniejsze poprawki.
4. Nie przepisuj ponownie działających fragmentów.
Jeżeli zgłaszam pojedynczy problem, znajdź jego przyczynę i dokonaj możliwie najmniejszej lokalnej zmiany.
5. Zasada minimalnego diffu: jeżeli czegoś nie trzeba zmieniać, nie zmieniaj tego.
Unikaj przy okazji:
◦ refaktoryzacji,
◦ porządkowania kodu,
◦ zmiany nazw,
◦ przebudowy architektury,
◦ optymalizacji,
◦ zastępowania działającego mechanizmu innym,
chyba że wyraźnie o to poproszę.
6. Każda wcześniejsza poprawka jest wymaganiem regresyjnym.
Przed oddaniem kolejnej wersji upewnij się, że zmiana nie cofnęła wcześniej naprawionych elementów.
7. Kod źródłowy w Pascalu jest wzorcem zachowania, ale po powstaniu działającej wersji JS nie jest automatycznie bazą kolejnych implementacji.
Używaj go do sprawdzania semantyki oryginału, gdy jest to potrzebne, ale poprawiaj aktualny kod JS zamiast ponownie tłumaczyć większe fragmenty programu.
8. Nie zmieniaj poprawnie działającego zachowania tylko dlatego, że implementacja wydaje się nietypowa lub nieelegancka.
W starych programach mogą występować rozwiązania pokrętne, ale celowe.
9. Jeżeli lokalna poprawka wymagałaby poważnej przebudowy działającego mechanizmu, poinformuj mnie o tym zamiast automatycznie wykonywać szeroką zmianę.
W takim przypadku preferowane może być pozostawienie drobnej niedoskonałości zamiast ryzyka regresji.
10. Ponownie wykorzystuj rozwiązania, które sprawdziły się we wcześniejszych konwersjach.
Dotyczy to szczególnie takich mechanizmów jak:
◦ obsługa sound / nosound / delay,
◦ klawiatura,
◦ skalowanie obrazu,
◦ Canvas,
◦ emulacja trybu tekstowego IBM PC,
◦ palety kolorów,
◦ timery i pętle programu.
Jeżeli w poprzednim programie istnieje działające rozwiązanie tego samego problemu, preferuj jego adaptację zamiast projektowania nowego mechanizmu od początku.
11. Nie usuwaj ani nie upraszczaj zachowań oryginału bez uzgodnienia.
Jeżeli jakaś konstrukcja Pascala jest trudna do odwzorowania, najpierw spróbuj ustalić jej rzeczywistą funkcję.
12. Przy każdej kolejnej iteracji myśl w kategoriach patcha do aktualnej wersji, nie nowej implementacji programu.
Najważniejsza zasada:
Aktualna działająca wersja + najmniejsza konieczna poprawka = następna wersja.
Nie wykonuj ponownej konwersji większych fragmentów programu, jeżeli nie jest to bezwzględnie konieczne.

[…] Lub w skrócie:

Zasady pracy nad konwersją
1. Celem jest wierna konwersja oryginału, nie modernizacja ani refaktoryzacja programu.
2. Po powstaniu działającej wersji każda następna zmiana ma być poprawką tej wersji, a nie ponowną konwersją.
3. Zawsze używaj ostatniej zaakceptowanej wersji pliku jako bazy do dalszej pracy.
4. Przy zgłoszeniu błędu dokonuj możliwie najmniejszej lokalnej zmiany — zasada minimalnego diffu.
5. Nie zmieniaj, nie porządkuj i nie przepisuj fragmentów, które działają poprawnie.
6. Każda wcześniej wykonana poprawka jest wymaganiem regresyjnym i musi pozostać zachowana.
7. Kod Pascala służy do weryfikacji zachowania oryginału, ale nie zastępuje aktualnej działającej wersji JS.
8. Jeśli poprawka wymaga poważnej przebudowy działającego mechanizmu, najpierw wskaż ryzyko zamiast wykonywać ją automatycznie.
9. Jeśli podobny problem został już rozwiązany w innej naszej konwersji, preferuj sprawdzony mechanizm zamiast projektować nowy.
10. Zasada nadrzędna: aktualna działająca wersja + najmniejsza konieczna poprawka = następna wersja.

=Wnioski do wniosków=
Jak widać, pewne rzeczy, które nam się wydają logiczne, muszą być wprost przekazane AI na początku pracy. Bardzo łopatologicznie wyjaśnione od zera. W ten sposób unikniemy wielu nieporozumień. Za to z wyników pracy można być naprawdę zadowolonym.

Ważną rzeczą jest też to, że AI potrafi krytycznie patrzeć na swoją własną pracę i wyciągać wnioski.

Tu muszę wspomnieć, że niniejsze konwersje mają charakter trochę testów, a trochę zabawy. Aktualnie, programując, używam regularnie AI. Co prawda jeszcze nie do tworzenia projektów od podstaw, ale do usuwania błędów, problemów z kompatybilnością kodu lub dodawania nowych, prostych funkcji.

Zdaję sobie sprawę, że moment w którym AI zacznie tworzyć u mnie program od początku, nieuchronnie się zbliża. Będzie to wymagało ode mnie opracowania zupełnie nowej metodyki pracy. Przekazywania AI dokładnych założeń dotyczących funkcjonalności i architektury tworzonego programu. Praktycznie stworzenia dokumentacji programu przed jego powstaniem. W sumie tak powinno być ;)

Zupełnie na zakończenie mogę dodać, że obecnie ponad 80% ruchu na technique.pl generują rozmaite modele AI, pozyskujące tu wiedzę na najróżniejsze tematy, które poruszaliśmy.

Szymon Dowkontt

[[Strona główna|Powrót do "Strony głównej"]]

[[Wydanie 2026|Powrót do "Wydania 2026"]]

[[category:Komputery]]

(Nie)modny zegar na lampach Nixie

2026-06-21T15:28:18Z

Szdowk: /* (Nie)modny zegar na lampach Nixie */

=(Nie)modny zegar na lampach Nixie=

<div class="thumbline-center">
[[File:zegar_nixie_img13.jpg|thumb|400px]]
</div>

Każdy elektronik majsterkowicz, tworzący własne urządzenia, ma na koncie pewne projekty. Jednym z takich jest zegar elektroniczny. Proste urządzenie o użytkowym przeznaczeniu, mające odmierzać czas i nic więcej. Dawniej tworzony z wykorzystaniem układów cyfrowych małej skali integracji TTL lub CMOS, a następnie jednoukładowych, specjalizowanych kości zegarowych, jak chociażby MC1206 czy LM8560. Obecnie wystarczy do tego celu najprostszy mikroprocesor Atmega lub podobny i wsad z programem. Pozornie, tak jest najprościej i najszybciej. Czy na pewno?

Dawniej kiedy wyświetlacze LED były drogie, a ich jakość była inna niż tych dzisiejszych, dominowały zegary stworzone z udziałem lamp Nixie. Wraz z postępem ustąpiły one miejsca wyświetlaczom LED, VFD, LCD. W pewnym momencie, zapanowała jednak „moda na retro”, co w połączeniu z dużą podażą i niską ceną (do pewnego czasu) antycznych lamp Nixie, spowodowało ich renesans. Zegar na lampach stał się „trendy” a projektów tego rodzaju powstawało bardzo dużo. Niestety, przy tej okazji, spowodowało to mocne przerzedzenie podaży zarówno lamp jak i urządzeń w nie wyposażonych, które zostały dawcami, kończąc później na śmietniku, jako dalej niepotrzebne, mimo swojej sprawności. Obecnie, zdobycie zarówno lamp w stanie NOS, jak i przyrządów w nie wyposażonych, to już sport dla pasjonatów, zresztą kosztujący często niemałe pieniądze. Chociaż „moda na retro” jest stale podtrzymywana, to świetność nixie-zegarów już minęła.

Pomysł realizacji projektu-zegara Nixie czekał na wdrożenie ponad 10 lat. Wszystko zaczęło się od zakupu, wiele lat temu, kilkudziesięciu lamp typu LC 513 i podobnych o wysokości znaku 15,5 mm, w niewiadomym stanie, na lokalnym bazarku za kwotę 30 zł. Jednak ostatecznym zielonym światłem do realizacji był zakup mocno zmęczonego miernika Meratronik V540. Chociaż kompletny zarówno w lampy jak i elektronikę, ze względu na stan mechaniczny (widoczne mechaniczne ślady „ znęcania się” jak i tego, że coś ciężkiego na niego spadło), nie rokował pozytywnie na danie mu dalszego żywota jako woltomierz. Znajdujące się z nim lampy typu Z566M prod. byłego NRD o wysokości znaku 30 mm, jako te „duże” i jednocześnie „najbardziej pożądane”, posłużyły do budowy zegara w opisanym projekcie. Cały projekt nosi znamiona wykorzystania „surowców wtórnych” oraz „przydasiów” już posiadanych w domu, o czym będzie wspomniane poniżej.

<div class="thumbline-center">
[[File:zegar_nixie_img1.jpg|thumb|400px]]
</div>

Chcąc zbudować zegar na lampach, mamy do wyboru kilka sposobów realizacji poszczególnych bloków, z których konstrukcja się składa. Można tu wyszczególnić: wybór rodzaju lamp, sposób ich zasilania, sposób generacji impulsów zegara, wybór sposobu zliczania impulsów, sposób sterowania katodami lamp.

Jako lampy wybrano Z566M z wyżej wspomnianego Meratronika, te robiące największe wrażenie, dosłownie i w przenośni. Wysokość wyświetlanej cyfry 30 mm pozwala na dobry odczyt nawet z kilkumetrowej odległości, Do tego obecność czerwonego filtru w formie farby na bańce lampy, eliminuje konieczność stosowania osobnego filtra w obudowie zegara dla poprawy kontrastu. Do projektu użyto pięciu lamp, czterech dla godzin i minut oraz jednej Z567M jako „migającego znaku” oznaczającego odliczanie sekund. Zrezygnowano z dwóch lamp cyfrowych odliczających w sposób ciągły sekundy.

Oglądając projekty sprzed pół wieku, kiedy codziennością były układy TTL serii 7400, na nich właśnie najczęściej budowano zegary, do czasu upowszechnienia się układów CMOS serii 4000. Dziś serii TTL, nawet typu LS o zmniejszonym poborze prądu, w zasadzie nie używa się. W zegarze zastosowano układy serii 74 HCMOS, łączące technologię klasycznych CMOSów, z pewnymi zmianami, z tożsamością funkcjonalną klasycznych kości TTL serii 7400.

<center>[[File:zegar_nixie_sheet1.jpg|700px]]</center>

Podstawą każdego zegara jest odpowiedni wzorzec zliczania czasu oraz generator, zapewniający odpowiednią dokładność w czasie. Dawniej używano głównie rezonatorów kwarcowych o wartościach 1 MHz lub 10 MHz oraz dzielników o wielokrotności 10. Rezonatory zegarkowe 32768 Hz oferują wystarczającą dokładność (chociaż nie jest to poziom GPSu czy zegarów sterowanych radiowo), do tego są małych rozmiarów. Zastosowany generator oparty na układzie CMOS 4060 zawiera w sobie od razu wbudowany dzielnik wielostopniowy, co znacząca uprasza układ. Dzięki wbudowanemu dzielnikowi 2^14, wystarczy dodać zewnętrzny dzielnik przez 2, tutaj w tej roli jeden przerzutnik układu 74HC74 i otrzymujemy impuls wzorcowy 1 Hz.

Każdy zegar to w zasadzie licznik impulsów, zatem drugim istotnym blokiem jest układ zliczania. Tutaj wachlarz układów do wyboru jest bardzo szeroki. Dawniej bardzo chętnie korzystano z liczników 7490 o wyjściach BCD. Z racji że typowy zegar to 6 dekad, potrzebne było 6 takich układów. Inną koncepcją był wybór liczników 4017 o wyjściach „1 z 10”, lecz rozwiązanie ma to jedną niedogodność - wymaga dużej liczby tranzystorów sterujących cyframi lamp, z uwagi na konieczność dopasowania poziomów. W rodzinie układów HC do wyboru jest ciekawy układ 74HC390, zawierający w sobie dwa dziesiętne liczniki (w zasadzie to są niezależne liczniki do 2 oraz do 5 które po połączeniu zliczają do 10), co redukuje ilość potrzebnych układów z 6 do 3. Jeden układ odpowiada za zliczanie sekund, następny minut i ostatni godzin. Takie też zastosowano w projekcie.

Jednak zegar nie jest licznikiem o pojemności 999999, tylko 235959 (tryb zliczania jest 24 godzinny), dlatego liczniki należy odpowiednio „ograniczyć”. Służą do tego dwa układy 74HC132, każdy mający po cztery bramki NAND z układem Schmitta, z których uformowano trzy bramki AND, pozostawiając dwie bramki NAND wolne. Każda z bramek AND odpowiada za zerowanie sekund, minut i godzin, zapewniając przejście 59->00, 59->00 oraz 23->00, co uzyskano dzięki odpowiedniej konfiguracji wyjść liczników z wejściem bramek oraz pinów reset liczników. Nie należy tutaj stosować zwykłych bramek 74HC00 - podczas testów występowały kłopoty z prawidłowym resetowaniem liczników godzin. Bramki z wejściem Schmitta ten problem eliminują.

Z racji, że wyjścia liczników kodują informacje w kodzie BCD, natomiast lampy wyświetlają informację jako 1 z 10, należy użyć odpowiednich układów dekodujących. W latach świetności lamp nixie, opracowano specjalistyczne wysokonapięciowe dekodery BCD na 1 z 10 typu 7441 oraz 74141, których tutaj użyto. Sterują one bezpośrednio lampami, wybierając odpowiednią cyfrę jako tą aktywną. Był to jeden z powodów (oprócz konieczności zastosowana sporej ilości wysokonapięciowej zewnętrznych tranzystorów sterujących) odrzucenia koncepcji wykorzystania liczników 4017.

<center>[[File:zegar_nixie_sheet2.jpg|700px]]</center>

Wykorzystano układy z szuflady, z dawnych czasów produkcji nieistniejącego już francuskiego SESCOSEMu, chociaż obecnie zakup tych scalaków nie stanowi problemu, dostępne są zarówno te stare NOS produkcji zachodniej jak i odpowiedniki radzieckie, a nawet współcześnie produkowane rosyjskie. Do sterowania cyfrą dziesiątek godzin, wykorzystano dwa tranzystory BF257, żeby nie marnować dodatkowego układu 74141 do sterowania tylko dwoma cyframi. Tak samo, jeden tranzystor BF257 odpowiada za miganie znakiem sekundnika.

<div class="thumbline-center">
[[File:zegar_nixie_img13.jpg|thumb|256px]]
[[File:zegar_nixie_img2.jpg|thumb|256px]]
[[File:zegar_nixie_img3.jpg|thumb|256px]]
[[File:zegar_nixie_img4.jpg|thumb|256px]]
[[File:zegar_nixie_img5.jpg|thumb|256px]]
[[File:zegar_nixie_img6.jpg|thumb|256px]]
[[File:zegar_nixie_img7.jpg|thumb|256px]]
[[File:zegar_nixie_img8.jpg|thumb|256px]]
[[File:zegar_nixie_img9.jpg|thumb|256px]]
</div>

Pozornie drobną, aczkolwiek istotną kwestią jest sposób nastawiania zegara. Tutaj do wyboru są dwie możliwości - tryb „wolno-szybko” będący w zasadzie przyspieszeniem impulsów zliczających oraz tryb „osobno minuty, osobno godziny”. Jako wygodniejszy wybrano ten drugi. Pozwala to ustalić zegar szybciej i bardziej precyzyjnie, bez konieczności „przelatywania” za każdym razem całego cyklu liczącego. Przełączniki zrealizowano dzięki dwóch bramkom NAND z wejściem Schmitta na układzie 74HC132 oraz dwóm przełącznikom monostabilnym, osobnym dla minut i osobnym dla godzin. Zrezygnowano z trzeciego guzika, resetującego zegar do nastaw 000000, komplikuje to tylko układ, a nie jest niezbędne do prawidłowego działania. Układ nastawiania podłączony jest poprzez dwie braki XOR z układu 74HC86 do wejść liczników, co umożliwia jednoczesne podanie impulsów zegarowych, jak i nastawiania.

Ostatnią kwestią z elektrycznego punktu widzenia, jest zasilacz. Zegar wymaga dwóch stopni - niskiego oraz wysokiego napięcia, pierwsze do całej sekcji cyfrowej, drugie do zasilania anod lamp. Sekcja niskiego napięcia to typowy zasilacz +5V zrealizowany z udziałem trójkońcówkowego stabilizatora typu LDO o symbolu L4940V5. Sekcję wysokiego napięcia początkowo planowano zbudować w oparciu o przetwornicę HV dostępną w wielu wersjach na znanym chińskim portalu aukcyjnym. Próby jednak nie wypadły pomyślnie, przetwornica grzała się, piszczała lub nie zapewniała odpowiedniej wydajności prądowej. Następnie użyto do testów transformatora z miernika Meratronik, z którego pozyskano także lampy. Obecne tam uzwojenie HV, dające 200-250V oraz drugie około 7V załatwia cały temat zasilania. Transformator ten posiada jednak jeszcze dwa dodatkowe uzwojenia, w tym przypadku niepotrzebne, a których przewody, są wyprowadzone na stałe. Nie chcąc przesadnie kombinować, poszukano rozwiązania alternatywnego, wszak w dobie mody na lampy, lampowych wzmacniaczy, wiele producentów ma w swojej ofercie transformatory typowo do konstrukcji lampowych. Wybrano transformator polskiej firmy SIZEI o oznaczeniu TE66/220, o uzwojeniu pierwotnym 230V 71 mA oraz wtórnych - 200V 30 mA i 6,3V 1,1A. Jest to odpowiednik nieprodukowanego już polskiego transformatora firmy INDEL typ TSL 15/001. Lampy zasilane są z transformatora napięciem niestabilizowanym, wyprostowanym jednopołówko jedną diodą 1N4002 o napięciu granicznym 600V. Z racji, że prąd anody lampy ma decydujące znaczenia zarówno dla jasności świecenia, a przede wszystkim trwałości, należało go odpowiednio dobrać. Doświadczalnie zastosowano tu metodę kontroli, przy jakim prądzie każda z cyfr zaświeci się w sposób pełny. Lampy wszak są używane i ich zużycie jest niewiadome, a co gorsze, nie musi być jednorodne. Katalogowy prąd pracy jednej lampy wynosi 4,5 mA, tutaj okazało się, że wystarczy do pracy prąd rzędu 3 mA na lampę. Jeżeli lampa wykazuje już objawy zużycia, można podwyższyć prąd, jednak należy mieć na uwadze, że producent podaje maksymalny prąd pracy 6 mA.

<center>[[File:zegar_nixie_sheet3.jpg|700px]]</center>

Model zegara został zmontowany z trzech płytek drukowanych. Pierwsza, bazowa, zawiera lampy wraz z podstawkami i dekoderami 74141 oraz zasilacz +5V. Płytka ta posiada wyprowadzone kołki, w które wchodzą dwie pozostałe płytki. Druga płytka zawiera właściwy układ zliczania, nastawiania oraz generator kwarcowy. Trzecia to zasilacz wysokiego napięcia dla lamp nixie. Transformator umieszczono w osobnej obudowie, połączony z zegarem przewodem zakończonym 4 pinowym wtykiem. Z przodu obudowy transformatora umieszczono włącznik sieciowy oraz żarówkę sygnalizującą zasilanie. Obwód pierwotny transformatora zabezpiecza bezpiecznik zwłoczny.

Układ po zmontowaniu nie wymaga żadnej procedury uruchamiania. Można jedynie sprawdzić dokładność chodu, kontrolując miernikiem częstotliwości przebieg 32768 Hz na wyjściu 9 układu 4060. Gdyby odchyłka była niezadowalająca, można równolegle do jednego z kondensatorów ceramicznych generatora wlutować trymer celem korekty częstotliwości wzorcowej. Pobór prądu dla sekcji cyfrowej to około 40 mA, żarówka sygnalizacyjna pobiera około 30 mA, z kolei lampy pobierają prąd łącznie w granicach 15 mA.

<div class="thumbline-center">
[[File:zegar_nixie_img10.jpg|thumb|256px]]
[[File:zegar_nixie_img11.jpg|thumb|256px]]
[[File:zegar_nixie_img12.jpg|thumb|256px]]
[[File:zegar_nixie_img14.jpg|thumb|256px]]
[[File:zegar_nixie_img15.jpg|thumb|256px]]
</div>

Przydatne wzory:
1. odchyłka dobowa zegara w sekundach
t=(f1/f2)*86400
gdzie
t - odchyłka dobowa
f1 - różnica częstotliwości wzorcowej i mierzonej
f2 - częstotliwość wzorcowa

2. zamiana ppm na odchyłkę częstotliwości
f=f2*(ppm/1000000)
gdzie
f - odchyłka częstotliwości
ppm - odchyłka w ppm
f2 - częstotliwość wzorcowa

3. zamiana odchyłki częstotliwości na ppm
ppm=(f1/f2)*1000000
gdzie
f1 - odchyłka częstotliwości
ppm - odchyłka w ppm
f2 - częstotliwość wzorcowa

Literatura:
https://www.tube-tester.com/sites/nixie/data/V600/Z566M/z566m.htm
https://www.tube-tester.com/sites/nixie/data/z567m.htm
http://www.csgnetwork.com/anoderescalc.html
Instrukcja serwisowa woltomierza Meratronik V540
Karty katalogowe układów scalonych 74HC390, 74HC132, 74HC86, 74HC74, 74141, 4060

=Załącznik nr 1=

Wykaz elementów:

{| class="wikitable" style="margin:auto"
|+ Układ scalone:
|-
|IC1 ||4060
|-
|IC2 ||74HC74
|-
|IC3, IC7, IC8 ||74HC390
|-
|IC4, IC5 ||74HC132
|-
|IC6 ||74HC86
|-
|IC9, IC10, IC11 ||74141
|-
|IC12 ||L4940 V5
|}

{| class="wikitable" style="margin:auto"
|+ Tranzystory:
|-
|T1, T2, T3 ||BF 257
|}

{| class="wikitable" style="margin:auto"
|+ Diody:
|-
|D1 ||1N4002
|-
|D2 ||mostek prostowniczy 50V/1A
|}

{| class="wikitable" style="margin:auto"
|+ Rezystory (wszystkie rezystory metalizowane 1% 0,4W chyba że wskazano inaczej):
|-
|R1 ||470k
|-
|R2 ||10M
|-
|R3, R4 ||12k
|-
|R5, R6 ||100k
|-
|R7, R8, R9 ||30k
|-
|R10, R11, R12, R13, R14 ||36k/0,6W
|-
|R15 ||200k
|}

{| class="wikitable" style="margin:auto"
|+Kondensatory:
|-
|C1, C2 ||22pF
|-
|C3, C4 ||100nF
|-
|C5 ||470uF/350V
|-
|C6, C7 ||22uF/25V
|}

{| class="wikitable" style="margin:auto"
|+Pozostałe:
|-
|transformator ||SIZEI TE66/220 lub TSL 15/001
|-
|bezpiecznik ||WTA-T 250V/200mA
|-
|żarówka ||R5 6-7V/30mA
|-
|lampy nixie ||4 szt. Z566M i 1 szt. Z567M
|-
|podstawka do lamp ||5 szt. 13pin
|-
|przełącznik monostabilny ||2 szt. SPST-NO
|-
|kwarc ||32768 Hz
|}

Konrad Klekot

[[Strona główna|Powrót do "Strony głównej"]]

[[Wydanie 2026|Powrót do "Wydania 2026"]]

[[category: Drobne porady]]