Technique.pl - Wkład użytkownika [pl]

Oswajamy AI

2026-08-11T05:58:10Z

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]]

Oswajamy AI

2026-08-10T19:01:58Z

Szdowk: /* Przykład 1: MRace32 */

=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.

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]]

Oswajamy AI

2026-08-10T19:00:49Z

Szdowk: /* Przykład 2: W1914 */

=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.

''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.

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]]

Strona główna

2026-08-10T19:00:03Z

Szdowk: /* Artykuły z roku 2026 (wydanie 2026) */

[[category:Aktualności]]__NOTOC__
'''Witamy na stronie Technique.pl'''

==Artykuły z roku 2026 ([[wydanie 2026]])==

*2026.08.10 [[Oswajamy AI]].
<center>
[[File:OAI-02.jpg|130px|link=Oswajamy AI]]
[[File:OAI-05.jpg|130px|link=Oswajamy AI]]
[[File:OAI-08.jpg|130px|link=Oswajamy AI]]
</center>

*2026.06.26 [[(Nie)modny zegar na lampach Nixie]].
<center>
[[File:Zegar nixie sheet1.jpg|130px|link=(Nie)modny zegar na lampach Nixie]]
[[File:Zegar nixie img5.jpg|110px|link=(Nie)modny zegar na lampach Nixie]]
[[File:Zegar nixie img13.jpg|135px|link=(Nie)modny zegar na lampach Nixie]]
</center>

*2026.04.02 [[CAD cz.4: technika 3D - FreeCAD]].
<center>
[[File:Cad4 freecad part design Screenshot 20260401 074613.jpg|130px|link=CAD cz.4: technika 3D - FreeCAD]]
[[File:Cad4 freecad part design kolo 2 Screenshot 20260401 074613.jpg|130px|link=CAD cz.4: technika 3D - FreeCAD]]
[[File:Cad4 freecad techdraw Screenshot 20260401 074613.jpg|130px|link=CAD cz.4: technika 3D - FreeCAD]]
</center>

*2026.03.10 [[Trzask prask i po trzasku]].
<center>
[[File:Moj egz -1.jpg|230px|link=Trzask prask i po trzasku]]
[[File:Dart page -3.jpg|85px|link=Trzask prask i po trzasku]]
[[File:Vinyl-NRS-Box-S3-Black-1024x576 con-1.jpg|230px|link=Trzask prask i po trzasku]]
</center>

*2026.03.01 [[CAD cz.3: technika 3D - BRLCAD]].
<center>
[[File:2 Screenshot 20260221 164437 cyst wire.jpg|115px|link=CAD cz.3: technika 3D - BRLCAD]]
[[File:3 Screenshot 20260221 165152 cyst ray.jpg|115px|link=CAD cz.3: technika 3D - BRLCAD]]
[[File:12 Screenshot 20260227 133916-silnik5.jpg|160px|link=CAD cz.3: technika 3D - BRLCAD]]
</center>

*2026.02.20 [[Tadeusz wajchę przełóż czyli rzecz o zwrotnicach]].
<center>
[[File:Wzorek -1.jpg|180px|link=Tadeusz wajchę przełóż czyli rzecz o zwrotnicach]]
[[File:Kondensatory-1.jpg|110px|link=Tadeusz wajchę przełóż czyli rzecz o zwrotnicach]]
[[File:Rozdział mocy-2.jpg|170px|link=Tadeusz wajchę przełóż czyli rzecz o zwrotnicach]]
</center>

*2026.02.01 [[CAD cz.2: technika 2D]].
<center>
[[File:Megacad 4-2-demo 20260124 102635.jpg|115px|link=CAD cz.2: technika 2D]]
[[File:SimTel-IMG 20260128 201943.jpg|110px|link=CAD cz.2: technika 2D]]
[[File:QCAD-Screenshot 20260128 081947.jpg|140px|link=CAD cz.2: technika 2D]]
</center>

*2026.01.25 [[Olek czyli pół wieku z kolumnami]].
<center>
[[File:Naked sp-00001.jpg|140px|link=Olek czyli pół wieku z kolumnami]]
[[File:Olohorn-1.jpg|120px|link=Olek czyli pół wieku z kolumnami]]
[[File:11 (1).jpg|60px|link=Olek czyli pół wieku z kolumnami]]
</center>

*2026.01.18 [[CAD cz.1: wspomnienia i podstawy]].
<center>
[[File:Vu3d-3.jpg|120px|link=CAD cz.1: wspomnienia i podstawy]]
[[File:Prodesignii.jpg|145px|link=CAD cz.1: wspomnienia i podstawy]]
[[File:Acad1a.jpg|140px|link=CAD cz.1: wspomnienia i podstawy]]
</center>

==Artykuły z roku 2025 ([[wydanie 2025]])==
*2025.12.31 [[Quo Vadis Technique ?]]
<center>
[[File:DSC02819.JPG|120px|link=Quo Vadis Technique ?]]
[[File:Tetra-9.jpg|100px|link=Quo Vadis Technique ?]]
[[File:Acad1.jpg|120px|link=Quo Vadis Technique ?]]
</center>

*2025.12.29 [[Jest różnica czyli coming out]].
<center>
[[File:Yamaha1000- 1 small.jpg|80px|link=Jest różnica czyli coming out]]
[[File:Filtr -1.jpg|120px|link=Jest różnica czyli coming out]]
[[File:Quad 405 clone -1 .jpg|130px|link=Jest różnica czyli coming out]]
</center>

*2025.12.24 [[Powrót do przyszłości czyli HydroPeloponez]].
<center>
[[File:Polo 6732.jpg|120px|link=Powrót do przyszłości czyli HydroPeloponez]]
[[File:Polo 6319-1.jpg|120px|link=Powrót do przyszłości czyli HydroPeloponez]]
[[File:Polo 5808-1.jpg|120px|link=Powrót do przyszłości czyli HydroPeloponez]]
</center>

*2025.12.21 [[Ramiona w wieku emerytalnym - epizod 2 EMI E.P.U. 100]].
<center>
[[File:EMI 100-1.JPG|120px|link=Ramiona w wieku emerytalnym - epizod 2 EMI E.P.U. 100]]
[[File:EMI 100-5.JPG|120px|link=Ramiona w wieku emerytalnym - epizod 2 EMI E.P.U. 100]]
[[File:EMI 100-6.JPG|120px|link=Ramiona w wieku emerytalnym - epizod 2 EMI E.P.U. 100]]
</center>

*2025.12.20 [[Ramiona w wieku emerytalnym - epizod 1 Leak]].
<center>
[[File:Leak- instrukcja - 1.jpg|60px|link=Ramiona w wieku emerytalnym - epizod 1 Leak]]
[[File:Leak 13.JPG|120px|link=Ramiona w wieku emerytalnym - epizod 1 Leak]]
[[File:Leak 4.JPG|120px|link=Ramiona w wieku emerytalnym - epizod 1 Leak]]
</center>

*2025.12.17 [[Królowa ramion Low Mass Infinity Black Widow]].
<center>
[[File:Black Widow - 1b.jpg|60px|link=Królowa ramion Low Mass Infinity Black Widow]]
[[File:Black widow dane-2.jpg|70px|link=Królowa ramion Low Mass Infinity Black Widow]]
[[File:Black Widow - 3.jpg|80px|link=Królowa ramion Low Mass Infinity Black Widow]]
</center>

*2025.12.10 [[Cmapm czyli nienerwowy powrót ramion 2025]].
<center>
[[File:Ram - 002.jpg|60px|link=Cmapm czyli nienerwowy powrót ramion 2025]]
[[File:DSC05814.JPG|120px|link=Cmapm czyli nienerwowy powrót ramion 2025]]
[[File:Sto-2.jpg|100px|link=Cmapm czyli nienerwowy powrót ramion 2025]]
</center>

*2025.12.04 [[Stary Pass czyli w oczekiwaniu na jubileusz]].
<center>
[[File:Tetra-0.jpg|86px|link=Stary Pass czyli w oczekiwaniu na jubileusz]]
[[File:Tetra-9.jpg|100px|link=Stary Pass czyli w oczekiwaniu na jubileusz]]
[[File:Penta - 2.jpg|100px|link=Stary Pass czyli w oczekiwaniu na jubileuszy]]
</center>

*2025.11.30 [[NA TAŚMIE – Wielościeżkowa historia Zakładów Radiowych Kasprzaka Relacja z wystawy]].
<center>
[[File:Wyst -09 20251021 175651-1.jpg|100px|link=NA TAŚMIE – Wielościeżkowa historia Zakładów Radiowych Kasprzaka Relacja z wystawy]]
[[File:Wyst -01 20251021 1.jpg|80px|link=NA TAŚMIE – Wielościeżkowa historia Zakładów Radiowych Kasprzaka Relacja z wystawy]]
[[File:Wyst -04 20251021 175918-1.jpg|120px|link=NA TAŚMIE – Wielościeżkowa historia Zakładów Radiowych Kasprzaka Relacja z wystawy]]
</center>

*2025.11.04 [[Hamownia dla małych silników, cz.3. Wykorzystanie alternatora w charakterze obciążenia. Sterowanie i konstrukcja]].
<center>
[[File:Rys 6a napiecie pradu wzbudzenia.jpg|130px|link=Hamownia dla małych silników, cz.3. Wykorzystanie alternatora w charakterze obciążenia. Sterowanie i konstrukcja]]
[[File:Hamownia hamulec.jpg|80px|link=Hamownia dla małych silników, cz.3. Wykorzystanie alternatora w charakterze obciążenia. Sterowanie i konstrukcja]]
[[File:H2-sprawnosc-alternatora.jpg|130px|link=Hamownia dla małych silników, cz.3. Wykorzystanie alternatora w charakterze obciążenia. Sterowanie i konstrukcja]]
</center>

*2025.10.10 [[Upadek prasy]].
<center>
[[File:1-IMG 20251009 174548.jpg|80px|link=Upadek prasy]]
[[File:2-IMG 20251009 174644.jpg|80px|link=Upadek prasy]]
[[File:4-IMG_20251011_180622.jpg|80px|link=Upadek prasy]]
</center>

==Artykuły z roku 2024 ([[wydanie 2024]])==
*2024.12.29 [[Wybrane fragmenty historii gramofonów firmy Thorens rozdział 1 - Powrót sentymentów]].
<center>
[[File:Refrenc 4.jpg|140px|link=Wybrane fragmenty historii gramofonów firmy Thorens rozdział 1 - Powrót sentymentów]]
[[File:Torref-5 sme.jpg|80px|link=Wybrane fragmenty historii gramofonów firmy Thorens rozdział 1 - Powrót sentymentów]]
[[File:Refrenc 1.jpg|140px|link=Wybrane fragmenty historii gramofonów firmy Thorens rozdział 1 - Powrót sentymentów]]
</center>

*2024.12.12 [[Od paska napędowego do sztucznej inteligencji]].
<center>
[[File:GdZsYYpA2AD39fIh-bis.png|140px|link=Od paska napędowego do sztucznej inteligencji]]
[[File:5jxBFlunqdOQY0QW bis .png|60px|link=Od paska napędowego do sztucznej inteligencji]]
[[File:G3MnFdxXPqKk0sPF.png|180px|link=Od paska napędowego do sztucznej inteligencji]]
</center>

*2024.12.10 [[30 lat później czyli powrót gramofonu Janka]].
<center>
[[File:Gra-Ja-01.jpg|170px|link=30 lat później czyli powrót gramofonu Janka]]
[[File:Gra-Ja-07.jpg|160px|link=30 lat później czyli powrót gramofonu Janka]]
[[File:Gra-Ja-18.jpg|150px|link=30 lat później czyli powrót gramofonu Janka]]
</center>

*2024.11.30 [[Generatory w służbie Narodu - część 1]].
<center>
[[File:Osc.png|120px|link=Generatory w służbie Narodu - część 1]]
[[File:Schemat ideowy.png|200px|link=Generatory w służbie Narodu - część 1]]
[[File:P lm833.png|170px|link=Generatory w służbie Narodu - część 1]]
</center>

*2024.11.26 [[Pol-Audio czyli wzmacniacz za 12 baniek]].
<center>
[[File:Opis - 1small.jpg|120px|link=Pol-Audio czyli wzmacniacz za 12 baniek]]
[[File:Pol-audio-02.jpg|190px|link=Pol-Audio czyli wzmacniacz za 12 baniek]]
[[File:Polaudio 2023 -3s.jpg|120px|link=Pol-Audio czyli wzmacniacz za 12 baniek]]
</center>

*2024.11.14 [[Syriusz B czyli kontynuacja]].
<center>
[[File:Syriusz 2-6a.jpg|139px|link=Syriusz B czyli kontynuacja]]
[[File:Syriusz B prime-2.jpg|190px|link=Syriusz B czyli kontynuacja]]
[[File:Syriusz 2-7.jpg|134px|link=Syriusz B czyli kontynuacja]]
</center>

*2024.10.31 [[Linijka czyli suplemencik]].
<center>
[[File:Old-5.jpg|80px|link=Linijka_czyli_suplemencik]]
[[File:Linijka_-15.jpg|190px|link=Linijka_czyli_suplemencik]]
[[File:Linijka - 1.jpg|70px|link=Linijka_czyli_suplemencik]]
</center>

*2024.04.08 [[Perły z lamusa - niezwykłe zjawiska w Fonomasterze ciąg dalszy]].
<center>
[[File:Naped od gory-2.jpg|190px|link=Perły z lamusa - niezwykłe zjawiska w Fonomasterze ciąg dalszy]]
[[File:Widok od spodu-1.jpg|190px|link=Perły z lamusa - niezwykłe zjawiska w Fonomasterze ciąg dalszy]]
[[File:Naped od gory-0.jpg|190px|link=Perły z lamusa - niezwykłe zjawiska w Fonomasterze ciąg dalszy]]
</center>

*2024.04.01 [[Perły z lamusa - niezwykłe zjawiska w Fonomasterze]].
<center>
[[File:Widok z gory-0a.jpg|129px|link=Perły z lamusa - niezwykłe zjawiska w Fonomasterze]]
[[File:Stroboskop-1.jpg|190px|link=Perły z lamusa - niezwykłe zjawiska w Fonomasterze]]
[[File:Widok ogolny -2 .jpg|190px|link=Perły z lamusa - niezwykłe zjawiska w Fonomasterze]]
</center>

*2024.02.14 [[Drukujemy maszynę parową - pliki]].
<center>
[[File:4 Skrzynia zaworowa.jpg|190px|link=Drukujemy maszynę parową - pliki]]
[[File:3 Tloczysko 3.jpg|220px|link=Drukujemy maszynę parową - pliki]]
[[File:5 Pokrywa skrzyni zaworowej.jpg|110px|link=Drukujemy maszynę parową - pliki]]
</center>

==Artykuły z roku 2023 ([[wydanie 2023]])==
*2023.12.29 [[Drukujemy maszynę parową]].
<center>
[[File:Technique_pl_IMG_20230824_140525.jpg|140px|link=Drukujemy maszynę parową]]
[[File:Technique_pl_Screenshot_20231229_081158.jpg|200px|link=Drukujemy maszynę parową]]
[[File:Technique_pl_IMG_20231127_141546.jpg|140px|link=Drukujemy maszynę parową]]
</center>

*2023.10.09 [[Perły z lamusa czyli nostalgia kontra zdrowy rozsądek]].
<center>
[[File:Zestaw-3.jpg|190px|link=Perły z lamusa czyli nostalgia kontra zdrowy rozsądek]]
[[File:Zestaw-1.jpg|210px|link=Perły z lamusa czyli nostalgia kontra zdrowy rozsądek]]
[[File:W600-7.jpg|260px|link=Perły z lamusa czyli nostalgia kontra zdrowy rozsądek]]
</center>

*2023.09.17 [[Nowy Gramofon Część V Wielki Finał - czyli ostateczne zamkniecie tekstu z roku 2021]].
<center>
[[File:Kwia2021-7.jpg|140px|link=Nowy Gramofon Część V Wielki Finał - czyli ostateczne zamkniecie tekstu z roku 2021]]
[[File:100 5708-re1.jpg|100px|link=Nowy Gramofon Część V Wielki Finał - czyli ostateczne zamkniecie tekstu z roku 2021]]
[[File:100 5714-re1.jpg|140px|link=Nowy Gramofon Część V Wielki Finał - czyli ostateczne zamkniecie tekstu z roku 2021]]
</center>

*2023.09.11 [[Co z tym ramieniem ? ćwiczenia praktyczne]].
<center>
[[File:Head shell-2.jpg|100px|link=Co z tym ramieniem ? ćwiczenia praktyczne]]
[[File:2-12D-1.jpg|240px|link=Co z tym ramieniem ? ćwiczenia praktyczne]]
[[File:Gemini -4.jpg|100px|link=Co z tym ramieniem ? ćwiczenia praktyczne]]
</center>

*2023.08.02 [[Elektronika od Wielkiego Wybuchu]].
<center>
[[File:BAMBINO 2 SCHEMAT.jpg|100px|link=Elektronika od Wielkiego Wybuchu]]
[[File:Rysunek-46b.jpg|150px|link=Elektronika od Wielkiego Wybuchu]]
[[File:Rysunek-40a.jpg|150px|link=Elektronika od Wielkiego Wybuchu]]
</center>

*2023.07.20 [[Co z tym ramieniem ? Dual w DIY czyli ramię specjalnej troski]].
<center>
[[File:607etc-6.jpg|150px|link=Co z tym ramieniem ? Dual w DIY czyli ramię specjalnej troski]]
[[File:Dual 607 617 edit -5b.jpg|130px|link=Co z tym ramieniem ? Dual w DIY czyli ramię specjalnej troski]]
[[File:Dumet-4.jpg|130px|link=Co z tym ramieniem ? Dual w DIY czyli ramię specjalnej troski]]
</center>

*2023.07.18 [[Co z tym ramieniem ? czyli traktat o produkcji sera]].
<center>
[[File:1101 dok-3.jpg|120px|link=Co z tym ramieniem ? czyli traktat o produkcji sera]]
[[File:Test papierosow-2.jpg|190px|link=Co z tym ramieniem ? czyli traktat o produkcji sera]]
[[File:Ser-1.jpg|140px|link=Co z tym ramieniem ? czyli traktat o produkcji sera]]
</center>

*2023.04.23 [[Syriusz A czyli historia gramofonu Janka z Mielca]].
<center>
[[File:Podstawa-1-IMG 20210809 162040.jpg|150px|link=Syriusz A czyli historia gramofonu Janka z Mielca]]
[[File:Widok ogolny -2-IMG 20210809 163151.jpg|160px|link=Syriusz A czyli historia gramofonu Janka z Mielca]]
[[File:Podstawa-3-IMG 20210809 162059.jpg|200px|link=Syriusz A czyli historia gramofonu Janka z Mielca]]
</center>

*2023.04.06 [[Gramofon dla wszystkich czyli akt gramofonowej kapitulacji]].
<center>
[[File:Postument_-1.jpg|200px|link=Gramofon dla wszystkich czyli akt gramofonowej kapitulacji]]
[[File:Ogolny z góry-2.jpg|160px|link=Gramofon dla wszystkich czyli akt gramofonowej kapitulacji]]
[[File:Nóżka-111.jpg|150px|link=Gramofon dla wszystkich czyli akt gramofonowej kapitulacji]]
</center>

*2023.02.28 [[System zdalnego sterowania do magnetofonu Revox A77]].
<center>
[[File:Revoxa77-mod1.jpg|180px|link=System zdalnego sterowania do magnetofonu Revox A77]]
[[File:Revoxa77-sch3.png|250px|link=System zdalnego sterowania do magnetofonu Revox A77]]
[[File:Revoxa77-pilot1.jpg|110px|link=System zdalnego sterowania do magnetofonu Revox A77]]
</center>

*2023.01.29 [[Budapeszt w Warszawie czyli sukces marki Videoton nad Wisłą]].
<center>
[[File:Midimax-3.jpg|110px|link=Budapeszt w Warszawie czyli sukces marki Videoton nad Wisłą]]
[[File:Halka -01.jpg|430px|link=Budapeszt w Warszawie czyli sukces marki Videoton nad Wisłą]]
[[File:ENC-4.jpg|150px|link=Budapeszt w Warszawie czyli sukces marki Videoton nad Wisłą]]
</center>

==Artykuły z roku 2022 ([[wydanie 2022]])==

*2022.12.24 [[Po co komu Winyl? czyli osobisty wstęp do gramofonów]].
<center>
[[File:Pre-02.jpg|180px|link=Po co komu Winyl? czyli osobisty wstęp do gramofonów]]
[[File:Tr200-2.jpg|230px|link=Po co komu Winyl? czyli osobisty wstęp do gramofonów]]
[[File:Pre-08.jpg|150px|link=Po co komu Winyl? czyli osobisty wstęp do gramofonów]]
</center>

*2022.11.19 [[Hamownia dla małych silników, cz.2.]]
<center>
[[File:H2-tabliczka-znamionowa.jpg|130px|link=Hamownia dla małych silników, cz.2.]]
[[File:H2-zdjecie-z-ekranu-oscyloskopu-IMG 20220721 070321.jpg|120px|link=Hamownia dla małych silników, cz.2.]]
[[File:H2-moment-obrotowy-i-moc.jpg|140px|link=Hamownia dla małych silników, cz.2.]]
</center>

*2022.09.23 [[Hamownia dla małych silników, cz.1.]]
<center>
[[File:Hamownia widok ogolny 1.jpg|100px|link=Hamownia dla małych silników, cz.1.]]
[[File:Hamownia stanowisko pomiarowe.jpg|130px|link=Hamownia dla małych silników, cz.1.]]
[[File:Hamownia zdjecie z ekranu.jpg|130px|link=Hamownia dla małych silników, cz.1.]]
</center>

*2022.05.24 [[Termowizja niskobudżetowa]].
<center>
[[File:P2-1652968491337.jpg|100px|link=Termowizja niskobudżetowa]]
[[File:P2-IMG 20220519 160510.jpg|100px|link=Termowizja niskobudżetowa]]
[[File:P22-1653281832408.jpg|100px|link=Termowizja niskobudżetowa]]
</center>

*2022.04.29 [[MK235_2022|Magnetofon MK235]].
<center>
[[File:Mk232p IMG-20211024-WA0000.jpg|135px|link=MK235_2022]]
[[File:C235 1.jpg|100px|link=MK235_2022]]
[[File:Mk235 mk prom.jpg|135px|link=MK235_2022]]
</center>

*2022.03.24 [[Technologie addytywne 2022]].
<center>
[[File:Sprzeglo2.jpg|120px|link=Technologie addytywne 2022]]
[[File:Zasilacz-photo 2022-03-12 13-41-06.jpg|135px|link=Technologie addytywne 2022]]
[[File:Klawisz-IMG 20220305 142123.jpg|135px|link=Technologie addytywne 2022]]
</center>

*2022.02.19 [[Rekonstrukcja zdalnego sterowania]].
<center>
[[File:Wnetrze pilota IMG 20211107 114729.jpg|140px|link=Rekonstrukcja zdalnego sterowania]]
[[File:Schemat-mc14502x.jpg|220px|link=Rekonstrukcja zdalnego sterowania]]
[[File:Frec count-20211201001.jpg|110px|link=Rekonstrukcja zdalnego sterowania]]
</center>

*2022.02.09 [[Goodmans a sprawa polska]].
<center>
[[File:Sko-DSC02680 bok.jpg|150px|link=Goodmans a sprawa polska]]
[[File:Biurko-red-1.jpg|270px|link=Goodmans a sprawa polska]]
[[File:Fonia GK 122.2-page-001.jpg|180px|link=Goodmans a sprawa polska]]
</center>

==Artykuły z roku 2021 ([[wydanie 2021]])==

*2021.05.30 [[Nowy Gramofon - Część IV]].
<center>
[[File:S7300753-re1.jpg|90px|link=Nowy Gramofon - Część IV]]
[[File:Kwia2021-8.jpg|200px|link=Nowy Gramofon - Część IV]]
[[File:100 5718-re1.jpg|180px|link=Nowy Gramofon - Część IV]]
</center>

*2021.05.20 [[Za co kochamy linie transmisyjne II]].
<center>
[[File:GOT-1 - Monitory PRO 9TL.jpg|90px|link=Za co kochamy linie transmisyjne II]]
[[File:ML-TL-3a.jpg|100px|link=Za co kochamy linie transmisyjne II]]
[[File:02 - Monitory PRO 9TL.jpg|100px|link=Za co kochamy linie transmisyjne II]]
</center>

*2021.04.01 [[Nowy Gramofon - Część III]].
<center>
[[File:Kulki-2.JPG|160px|link=Nowy_Gramofon_-_Część_III]]
[[File:Sssilnik-1.JPG|190px|link=Nowy_Gramofon_-_Część_III]]
[[File:Ortofon --3a.JPG|160px|link=Nowy_Gramofon_-_Część_III]]
</center>

*2021.03.13 [[Nowy Gramofon - Część II]].
<center>
[[File:00-zespol podstawy ramienia z ramieniem -1.JPG|160px|link=Nowy_Gramofon_-_Część_II]]
[[File:00 zdezintegrowany z talerzem i silnikiem-1.JPG|160px|link=Nowy_Gramofon_-_Część_II]]
[[File:00 zdezintegrowany z talerzem i silnikiem- 3ramiona-3.JPG|160px|link=Nowy_Gramofon_-_Część_II]]
</center>

*2021.03.13 [[Za co kochamy linie transmisyjne I]].
<center>
[[File:IMF 80 TLS widok -1.jpg|140px|link=Za co kochamy linie transmisyjne I]]
[[File:IMF przekroje -1sm.jpg|140px|link=Za co kochamy linie transmisyjne I]]
[[File:Hi-fi ans - aug 75-1.jpg|140px|link=Za co kochamy linie transmisyjne I]]
</center>

*2021.02.15 [[Nowy Gramofon - Część I]].
<center>
[[File:Trzylistny kwiatek-1.jpg|160px|link=Nowy_Gramofon_-_Część_I]]
[[File:Puszki kwiatka -1.jpg|160px|link=Nowy_Gramofon_-_Część_I]]
[[File:Podstawa zinegrowana pod sme-5.jpg|120px|link=Nowy_Gramofon_-_Część_I]]
</center>

*2021.02.15 [[Klasycy o kompensacji siły poślizgu czyli trochę prawdy o antiskatingu - wersja 2021]].
<center>
[[File:Fig. 01-pl.jpg|100px|link=Klasycy o kompensacji siły poślizgu czyli trochę prawdy o antiskatingu - wersja 2021]]
[[File:Fig. 03pll.jpg|160px|link=Klasycy o kompensacji siły poślizgu czyli trochę prawdy o antiskatingu - wersja 2021]]
[[File:Fig. 11pl.jpg|160px|link=Klasycy o kompensacji siły poślizgu czyli trochę prawdy o antiskatingu - wersja 2021]]
</center>

*2021.01.12 [[Silniki nitinolowe]].
<center>
[[File:WP_20150210_006-nitinol.jpg|80px|link=Silniki nitinolowe]]
[[File:WP 20150210 011-nitinol.jpg|160px|link=Silniki nitinolowe]]
</center>

*2021.01.01 [[Manifest 2021]].
<center>
[[File:Zuraw-WP 20140307 002.jpg|180px|link=Manifest_2021]]
[[File:Cmt831-02-WP 20140910 005.jpg|160px|link=Manifest_2021]]
[[File:Garrard 100 -00b.JPG|120px|link=Manifest_2021]]
</center>

*2021.01.01 [[Nowy Gramofon - Prolog]].
<center>
[[File:Gramofon-kwiatek-001.jpg|140px|link=Nowy_Gramofon_-_Prolog]]
[[File:Jbe 3001 direct drive turntable.jpg|160px|link=Nowy_Gramofon_-_Prolog]]
[[File:Gramofon-kwiatek-002.jpg|160px|link=Nowy_Gramofon_-_Prolog]]
</center>

==Artykuły z roku 2020 ([[wydanie 2020]])==
*2020.03.14 [[Miernik wiecznie żywy czyli Meratronik V640 – aneks nr 2 do artykułu]].
<center>
[[File:Pud13.jpg|180px|link=Miernik wiecznie żywy czyli Meratronik V640 – aneks nr 2 do artykułu]]
[[File:Awp1.jpg|100px|link=Miernik wiecznie żywy czyli Meratronik V640 – aneks nr 2 do artykułu]]
[[File:Pud5.jpg|160px|link=Miernik wiecznie żywy czyli Meratronik V640 – aneks nr 2 do artykułu]]
</center>

*2020.01.28 [[Wieża Hi – Fi - czyli powrót wieży Babel część I]].
<center>
[[File:Preamp- amp- tuner - 1a.jpg|180px|link=Wieża Hi – Fi - czyli powrót wieży Babel część I]]
[[File:Zestaw - prospekt - stro-1.jpg|160px|link=Wieża Hi – Fi - czyli powrót wieży Babel część I]]
[[File:Technics hifi systems 1980-81- 01-1.jpg|120px|link=Wieża Hi – Fi - czyli powrót wieży Babel część I]]
</center>

*2020.01.02 [[Kaseta magnetofonowa BT]].
<center>
[[File:BT-IMG_20200102_151620.jpg|180px|link=Kaseta magnetofonowa BT]]
[[File:BT-IMG_20191102_181223.jpg|180px|link=Kaseta magnetofonowa BT]]
</center>

==Artykuły z roku 2019 ([[wydanie 2019]])==
*2019.06.20 [[Technoniezależność]].
<center>
[[File:TNZ-zegar-WP 20190613 005-small.jpg|180px|link=Technoniezależność]]
[[File:R-32 (I197506).jpg|180px|link=Technoniezależność]]
[[File:TNZ-tarcza-WP 20190614 002.jpg|180px|link=Technoniezależność]]
</center>

*2019.05.26 [[Fonica HiFi Audio System 0350]].
<center>
[[File:Fonica0350 Rys.5 Makieta projekt nr 1 (WM).jpg|170px|link=Fonica HiFi Audio System 0350]]
[[File:Fonica0350 Rys.1 Widok obydwu wiez z przodu.jpg|200px|link=Fonica HiFi Audio System 0350]]
[[File:Fonica0350 Rys.6 Grafika projekt nr 2 (WM).jpg|170px|link=Fonica HiFi Audio System 0350]]
</center>

*2019.05.26 [[XII Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]].
<center>
[[File:WP 20190524 014.jpg|180px|link=XII Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]]
[[File:WP 20190524 011.jpg|180px|link=XII Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]]
[[File:WP 20190524 005.jpg|180px|link=XII Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]]
</center>

==Artykuły z roku 2018 ([[wydanie 2018]])==
* Aby zobaczyć [[Wydanie 2018|wszystkie artykuły z roku 2018 kliknij tutaj]].
*2018.12.06 [[Historia innowacyjności w PRL i później, cz. 2]].
<center>
[[File:WP 20180830 003.jpg|70px|link=Historia innowacyjności w PRL i później, cz. 2]]
[[File:WP 20180830 002.jpg|70px|link=Historia innowacyjności w PRL i później, cz. 2]]
</center>
*2018.11.21 [[Wzmacniacze Foniki od początku do samego końca]].
<center>
[[File:Fonica W600 - 001.JPG|230px|link=Wzmacniacze Foniki od początku do samego końca]]
[[File:2801-edit 3 zest.JPG|170px|link=Wzmacniacze Foniki od początku do samego końca]]
[[File:PW-9014 - 01.jpg|190px|link=Wzmacniacze Foniki od początku do samego końca]]
</center>
*2018.11.09 [[Muzeum Unitry w Poznaniu]].
<center>
[[File:DSC00703.JPG|160px|link=Muzeum Unitry w Poznaniu]]
[[File:DSC00689.JPG|150px|link=Muzeum Unitry w Poznaniu]]
</center>
*2018.10.05 [[Polskie gramofony - Suplement 2018]].
<center>
[[File:0-10 f.jpg|160px|link=Polskie gramofony - Suplement 2018]]
[[File:Konsola zm 30 -2.jpg|260px|link=Polskie gramofony - Suplement 2018]]
[[File:Daniel ze wzm. - 04es.jpg|160px|link=Polskie gramofony - Suplement 2018]]
</center>
*2018.09.01 [[Volkswagen wśród mierników, czyli o przyrządach z rodziny LAVO]].
<center>
[[File:L1 1.jpg|120px|link=Volkswagen wśród mierników, czyli o przyrządach z rodziny LAVO]]
[[File:Z3.jpg|140px|link=Volkswagen wśród mierników, czyli o przyrządach z rodziny LAVO]]
[[File:L601 2.jpg|160px|link=Volkswagen wśród mierników, czyli o przyrządach z rodziny LAVO]]
</center>
*2018.09.01 [[Miało być: Osobiste komputery 8-bitowe a sprawa polska. Jest: Historia innowacyjności w PRL (i później)]].
<center>
[[File:Spr2-3.jpg|80px|link=Miało być: Osobiste komputery 8-bitowe a sprawa polska. Jest: Historia innowacyjności w PRL (i później)]]
[[File:Spr1-2.jpg|60px|link=Miało być: Osobiste komputery 8-bitowe a sprawa polska. Jest: Historia innowacyjności w PRL (i później)]]
[[File:Spr1-4.jpg|120px|link=Miało być: Osobiste komputery 8-bitowe a sprawa polska. Jest: Historia innowacyjności w PRL (i później)]]
</center>
*2018.08.06 [[UNITRA i ZURiT w „Przerwanej Dekadzie” część 1 – ZURiT czyli na rynkowo]].
<center>
[[File:Preferencje - tabela - 1.jpg|100px|link=UNITRA i ZURiT w „Przerwanej Dekadzie” część 1 – ZURiT czyli na rynkowo]]
[[File:Struktura napraw-1.jpg|220px|link=UNITRA i ZURiT w „Przerwanej Dekadzie” część 1 – ZURiT czyli na rynkowo]]
[[File:Koszt napraw-1.jpg|120px|link=UNITRA i ZURiT w „Przerwanej Dekadzie” część 1 – ZURiT czyli na rynkowo]]
</center>
*2018.06.29 [[Fonica w świecie CD, czyli „dyskofony” z Łodzi]].
<center>
[[File:Srebrny front - 2.jpg|380px|link=Fonica w świecie CD, czyli „dyskofony” z Łodzi]]
[[File:RYS 6 Tytka-2.jpg|140px|link=Fonica w świecie CD, czyli „dyskofony” z Łodzi]]
[[File:RYS H1 (Robert Komar).JPG|220px|link=Fonica w świecie CD, czyli „dyskofony” z Łodzi]]
</center>
*2018.06.10 [[XI Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]].
<center>
[[File:Seminarium201810.jpg|180px|link=XI Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]]
[[File:Seminarium201829.jpg|180px|link=XI Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]]
[[File:Seminarium201813.jpg|180px|link=XI Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]]
</center>
*2018.05.02 [[Wspomnienie o Chopinie]].
<center>
[[File:Chopin portret-1ccc.jpg|90px|link=Wspomnienie o Chopinie]]
[[File:Radio Chopin - 006 radio.jpg|180px|link=Wspomnienie o Chopinie]]
[[File:Banknot 5000zl 1982-szt2.jpg|180px|link=Wspomnienie o Chopinie]]
</center>
*2018.05.01 [[Analfabetyzm wtórny]].
<center>
[[File:Slack30.jpeg|200px|link=Analfabetyzm wtórny]]
[[File:Kalk-WP 20180429 007.jpg|60px|link=Analfabetyzm wtórny]]
[[File:Biurko1988-89.jpeg|160px|link=Analfabetyzm wtórny]]
</center>
*2018.04.15 [[Miernik wiecznie żywy czyli Meratronik V640 – aneks do artykułu]].
<center>
[[File:V640 HLY 4.jpg|140px|link=Miernik wiecznie żywy czyli Meratronik V640 – aneks do artykułu]]
[[File:Marconi v640 2.jpg|100px|link=Miernik wiecznie żywy czyli Meratronik V640 – aneks do artykułu]]
[[File:V640 ALT1.jpg|180px|link=Miernik wiecznie żywy czyli Meratronik V640 – aneks do artykułu]]
</center>
*2018.03.16 [[Rewolucja optyczna]].
<center>
[[File:BD-WP 20180309 004.jpg|180px|link=Rewolucja optyczna]]
[[File:BD-WP 20180309 009.jpg|180px|link=Rewolucja optyczna]]
[[File:BD-WP 20180309 008.jpg|180px|link=Rewolucja optyczna]]
</center>
*2018.03.13 [[Replay czyli powrót do tematu polskich wkładek gramofonowych]].
<center>
[[File:Igla 002.jpg|180px|link=Replay_czyli_powrót_do_tematu_polskich_wkładek_gramofonowych]]
[[File:Mf100-tenorel-1.jpg|200px|link=Replay_czyli_powrót_do_tematu_polskich_wkładek_gramofonowych]]
[[File:Mf-102.jpg|200px|link=Replay_czyli_powrót_do_tematu_polskich_wkładek_gramofonowych]]
</center>
*2018.02.20 [[Mówimy – ramię, a w domyśle – SME]].
<center>
[[File:SME vibtage family-1s.jpg|200px|link=Mówimy – ramię, a w domyśle – SME]]
[[File:RAMIE TYPU SME -2.JPG|200px|link=Mówimy – ramię, a w domyśle – SME]]
[[File:Mikrus1-s7302373.jpg|180px|link=Mówimy – ramię, a w domyśle – SME]]
</center>
*2018.01.08 [[SN-50|Słuchawki SN-50]].
<center>
[[File:WP 20180105 003.jpg|200px|link=SN-50]]
[[File:WP 20180105 004.jpg|200px|link=SN-50]]
</center>

==Artykuły z roku 2017 ([[wydanie 2017]])==
* Aby zobaczyć [[Wydanie 2017|wszystkie artykuły z roku 2017 kliknij tutaj]].
*2017.12.06 [[Thorens, a sprawa polska]].
<center>
[[File:TD180 ver 1-11.jpg|180px|link=Thorens, a sprawa polska]]
[[File:Thorens-td-290 3.jpg|180px|link=Thorens, a sprawa polska]]
[[File:Wieza 2000 (0)-s.jpg|160px|link=Thorens, a sprawa polska]]
</center>
*2017.11.21 [[Miernik wiecznie żywy czyli Meratronik V640]].
<center>
[[File:V81 -16.jpg|120px|link=Miernik wiecznie żywy czyli Meratronik V640]]
[[File:Conway ul 1.jpg|120px|link=Miernik wiecznie żywy czyli Meratronik V640]]
[[File:Elwro rodzina.jpg|200px|link=Miernik wiecznie żywy czyli Meratronik V640]]
</center>
*2017.11.06 [[Igrzyska czas zacząć]].
<center>
[[File:Rys -1 20170917 141734.jpg|200px|link=Igrzyska czas zacząć]]
[[File:Ariston AS +16dB.JPG|140px|link=Igrzyska czas zacząć]]
[[File:Rys-2 20170917 142211.jpg|200px|link=Igrzyska czas zacząć]]
</center>
*2017.10.18 [[Szreniawa 2017]].
<center>
[[File:DSC09113-famo.JPG|200px|link=Szreniawa 2017]]
[[File:DSC09160.JPG|200px|link=Szreniawa 2017]]
[[File:DSC09097.JPG|200px|link=Szreniawa 2017]]
</center>
*2017.09.13 [[Dwucylindrowa maszyna parowa]].
<center>
[[File:Maszyna dwucylindrowa - 6.jpg|200px|link=Dwucylindrowa maszyna parowa]]
[[File:Maszyna dwucylindrowa - 9.jpg|200px|link=Dwucylindrowa maszyna parowa]]
[[File:Dwucylindrowa-023.jpg|200px|link=Dwucylindrowa maszyna parowa]]
</center>
*2017.08.01 [[Stabilizator spokoju mózgu|Stabilizator Spokoju Mózgu, czyli kilka słów o (nie)doskonałościach napędu gramofonowego]].
<center>
[[File:Stabilizator-spokoju-QL10.jpg|200px|link=Nie święci ramiona lepią]]
[[File:Stabilizator-spokoju-SCH BLOK.jpg|200px|link=Nie święci ramiona lepią]]
[[File:Stabilizator-spokoju-AF977.jpg|120px|link=Nie święci ramiona lepią]]
</center>
*2017.07.14 [[Nie święci ramiona lepią]].
<center>
[[File:Komplet nowy.JPG|200px|link=Nie święci ramiona lepią]]
[[File:DSC02038.JPG|200px|link=Nie święci ramiona lepią]]
[[File:DSC02121.JPG|200px|link=Nie święci ramiona lepią]]
</center>
*2017.06.08 [[Temperatura pracy modeli silników Stirlinga]].
<center>
[[File:Technique pl-term03.jpeg|360px|link=Temperatura pracy modeli silników Stirlinga]]
[[File:Technique pl-term15.jpeg|360px|link=Temperatura pracy modeli silników Stirlinga]]
</center>
*2017.06.05 [[X Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]].
<center>
[[File:WP 20170602 024.jpg|200px|link=X Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]]
[[File:WP 20170602 016.jpg|200px|link=X Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]]
[[File:WP 20170602 019.jpg|200px|link=X Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]]
</center>
*2017.04.13 [[A jednak się kręci - czyli kilka uwag o napędach gramofonowych]].
<center>
[[File:Dragon-1 small.jpg|75px|link=A jednak się kręci - czyli kilka uwag o napędach gramofonowych]]
[[File:Nakamichi dragon wybor 03-small.jpg|130px|link=A jednak się kręci - czyli kilka uwag o napędach gramofonowych]]
[[File:Flutter.-1jpg.jpg|115px|link=A jednak się kręci - czyli kilka uwag o napędach gramofonowych]]
</center>
*2017.03.14 [[Inny przykład druku 3D]].
<center>
[[File:Rms475a-WP 20140606 020.jpg|200px|link=Inny przykład druku 3D]]
[[File:Kolo-ZRK-475a.jpeg|115px|link=Inny przykład druku 3D]]
[[File:WP 20170314 006-475a.jpg|115px|link=Inny przykład druku 3D]]
</center>
*2017.01.17 [[Fonica w krainie papieru]].
<center>
[[File:Yeti-01.jpg|200px|link=Fonica_w_krainie_papieru]]
[[File:GS 630---.jpg|200px|link=Fonica_w_krainie_papieru]]
[[File:Daniel deck-1.jpg|200px|link=Fonica_w_krainie_papieru]]
</center>

==Najciekawsze artykuły z roku 2016 ([[wydanie 2016]])==
* Aby zobaczyć [[Wydanie 2016|wszystkie artykuły z roku 2016 kliknij tutaj]].
*2016.12.15 [[Twórcy gramofonów - próba otwarcia tematu]].
<center>
[[File:David gammon.jpg|100px|link=Twórcy gramofonów - próba otwarcia tematu]]
[[File:John-19771.jpg|140px|link=Twórcy gramofonów - próba otwarcia tematu]]
[[File:Kuzma.jpg|80px|link=Twórcy gramofonów - próba otwarcia tematu]]
</center>
*2016.12.01 [[Pierwsze laptopy]].
<center>
[[File:Tosh T1000LE 2016-11-22 12-36-35.jpg|200px|link=Pierwsze laptopy]]
[[File:Tosh T1200 2016-11-10 15-23-08.jpg|150px|link=Pierwsze laptopy]]
[[File:Tosh T1000 2016-11-13 12-34-57.jpg|200px|link=Pierwsze laptopy]]
</center>
*2016.11.02 [[Gramofony na eksport - kierunek wschód (2016)]].
<center>
[[File:Wega002s3.jpg|200px|link=Gramofony na eksport - kierunek wschód (2016)]]
[[File:Wega109 23.jpg|160px|link=Gramofony na eksport - kierunek wschód (2016)]]
[[File:Estonia 109 .jpg|190px|link=Gramofony na eksport - kierunek wschód (2016)]]
</center>
*2016.10.01 [[Ramiona gramofonowe część VI - ramiona inne niż wszystkie]].
<center>
[[File:Transcriptor18.jpg|200px|link=Ramiona_gramofonowe_część_VI_-_ramiona_inne_niż_wszystkie]]
[[File:1983 Dynavector DV 501obrazekref2.jpg|200px|link=Ramiona_gramofonowe_część_VI_-_ramiona_inne_niż_wszystkie]]
[[File:WT-patent drawing.jpg|200px|link=Ramiona_gramofonowe_część_VI_-_ramiona_inne_niż_wszystkie]]
</center>
*2016.09.02 [[Ramiona gramofonowe przegląd rozwiązań - część V - Podsumowanie rozważań o ramionach przesuwnych.]]
<center>
[[File:All.jpg|200px|link=Ramiona gramofonowe przegląd rozwiązań - część V - Podsumowanie rozważań o ramionach przesuwnych.]]
[[File:Kuzma airbear theory01.jpg|150px|link=Ramiona gramofonowe przegląd rozwiązań - część V - Podsumowanie rozważań o ramionach przesuwnych.]]
[[File:276453875 o.jpg|200px|link=Ramiona gramofonowe przegląd rozwiązań - część V - Podsumowanie rozważań o ramionach przesuwnych.]]
</center>
*2016.08.14 [[CED, LD, CD-i Etc.]] - Technika video: zapis obrazu na płytach.
<center>
[[File:Ced - 03.JPG|100px|link=CED,_LD,_CD-i_Etc.]]
[[File:Sony mdp - 27.JPG|200px|link=CED,_LD,_CD-i_Etc.]]
[[File:Pio-2-mdp -11.JPG|200px|link=CED,_LD,_CD-i_Etc.]]
</center>
*2016.08.14 [[CED]] - pojemnościowy, elektromechaniczny system zapisu obrazu na płytach.
<center>
[[File:Ced - 01.JPG|300px|link=CED]]
[[File:Ced - 05.JPG|300px|link=CED]]
</center>
*2016.08.14 [[LD]] - LaserDisc.
<center>
[[File:Sony mdp - 33.JPG|200px|link=LD]]
[[File:Pio mdp - 08.JPG|200px|link=LD]]
[[File:Sony mdp - 34.JPG|200px|link=LD]]
</center>
*2016.08.14 [[Philips CD-i]] - Philips Compact Disc Interactive.
<center>
[[File:Cdi-WP 20160709 015.jpg|200px|link=Philips_CD-i]]
[[File:Cdi-WP 20160709 003.jpg|200px|link=Philips_CD-i]]
[[File:Cdi-WP 20160709 019.jpg|200px|link=Philips_CD-i]]
</center>
*2016.08.14 [[Video CD]] - Cyfrowy dysk wizyjny MPEG 1.
<center>
[[File:Vcd-2.jpg|200px|link=Video_CD]]
[[File:Vcd-7.jpg|200px|link=Video_CD]]
[[File:Vcd-8.jpg|200px|link=Video_CD]]
</center>
*2016.08.01 [[Ramiona gramofonowe przegląd rozwiązań - część IV]].
<center>
[[File:Optonica - 02.JPG|200px|link=Ramiona gramofonowe przegląd rozwiązań - część IV]]
[[File:Saba - 1-09.JPG|200px|link=Ramiona gramofonowe przegląd rozwiązań - część IV]]
[[File:RatAudio - 10.JPG|200px|link=Ramiona gramofonowe przegląd rozwiązań - część IV]]
</center>
*2016.07.16 [[Czyszczenie winyli - próby i błędy]].
<center>
[[File:Now 2 -1.jpg|200px|link=Czyszczenie winyli - próby i błędy]]
[[File:Tro prze - 4.jpg|200px|link=Czyszczenie winyli - próby i błędy]]
[[File:Nur - po - 3.jpg|200px|link=Czyszczenie winyli - próby i błędy]]
</center>
*2016.07.04 [[Ramiona gramofonowe przegląd rozwiązań - część III - Lata 80-te - Hasło Revox i Bang & Olufsen]].
<center>
[[File:REVOX (4).JPG|200px|link=Ramiona gramofonowe przegląd rozwiązań - część III - Lata 80-te - Hasło Revox i Bang & Olufsen]]
[[File:Reklama Revox-2.jpg|130px|link=Ramiona gramofonowe przegląd rozwiązań - część III - Lata 80-te - Hasło Revox i Bang & Olufsen]]
[[File:Beeoo05.jpg|200px|link=Ramiona gramofonowe przegląd rozwiązań - część III - Lata 80-te - Hasło Revox i Bang & Olufsen]]
</center>
*2016.06.22 [[Ramiona gramofonowe przegląd rozwiązań - część II - Hasło Rabco]].
<center>
[[File:Ortosonic -03.jpg|200px|link=Ramiona gramofonowe przegląd rozwiązań - część II - Hasło Rabco]]
[[File:SL-8_(18).jpg|200px|link=Ramiona gramofonowe przegląd rozwiązań - część II - Hasło Rabco]]
[[File:Marantz_slt_12-18.jpg|200px|link=Ramiona gramofonowe przegląd rozwiązań - część II - Hasło Rabco]]
</center>
*2016.05.11 [[Ramiona gramofonowe przegląd rozwiązań - część I - Garrard ZERO|Ramiona gramofonowe przegląd rozwiązań - część I - Garrard ZERO]].
<center>
[[File:Garrard 100 -00e.JPG|200px|link=Ramiona gramofonowe przegląd rozwiązań - część I - Garrard ZERO]]
[[File:Garrard_100_-00b.JPG|200px|link=Ramiona gramofonowe przegląd rozwiązań - część I - Garrard ZERO]]
[[File:Garrard_92_-81a.JPG|200px|link=Ramiona gramofonowe przegląd rozwiązań - część I - Garrard ZERO]]
</center>
*2016.04.12 [[MDS_4461|Magnetofon MDS 445/446/446x]].
<center>
[[File:MDS446 WP 20160404 004.jpg|200px|link=MDS_4461]]
[[File:MDS446 WP 20160318 004.jpg|200px|link=MDS_4461]]
[[File:MDS446 WP 20160323 005.jpg|200px|link=MDS_4461]]
</center>
*2016.02.07 [[SSL 042|Wieża SSL 042]] - Chyba najbardziej znana wieża produkcji Unitra Diora.
<center>
[[File:ASS042-AS642-WP 20160205 011.jpg|200px|link=SSL 042]]
[[File:ASS042-WP 20160205 014.jpg|200px|link=SSL 042]]
[[File:ASS042-AS642-WP 20160128 002.jpg|200px|link=SSL 042]]
</center>

==Najciekawsze artykuły z roku 2015 ([[wydanie 2015]])==
* Aby zobaczyć [[Wydanie 2015|wszystkie artykuły z roku 2015 kliknij tutaj]].
*2015.08.01 [[Zrobić gramofon 1 - Direct Drive - część 2]] - Jak zrobić gramofon, część 2.
<center>
[[File:Szkic 3.jpg|200px|link=Zrobić gramofon 1 - Direct Drive - część 2]]
[[File:U z gniazdami -4.jpg|200px|link=Zrobić gramofon 1 - Direct Drive - część 2]]
[[File:DSC00917.JPG|200px|link=Zrobić gramofon 1 - Direct Drive - część 2]]
</center>
*2015.07.10 [[Zrobić gramofon 1 - Direct Drive - część 1]] - Jak zrobić gramofon, część 1.
<center>
[[File:Odlew 000856.jpg|200px|link=Zrobić gramofon 1 - Direct Drive - część 1]]
[[File:Zasilacz 2.JPG|140px|link=Zrobić gramofon 1 - Direct Drive - część 1]]
[[File:Goto-1-4.jpg|200px|link=Zrobić gramofon 1 - Direct Drive - część 1]]
</center>
*2015.06.06 [[Polskie gramofony]] - Kolejna aktualizacja artykułu o polskich gramofonach. Tym razem autor opracował nową wersję rozdziału o gramofonach Bambino oraz dodał informacje o tańszych gramofonach, tzn. Arturze, Cyrylu i Emanuelu.
<center>
[[File:Bambino 3-B2.JPG|200px|link=Polskie gramofony]]
[[File:DSC09548.JPG|200px|link=Polskie gramofony]]
[[File:Emanuel-620.JPG|200px|link=Polskie gramofony]]
</center>
* 2015.01.01 [[Polskie magnetofony kasetowe - część 2 - magnetofony przenośne]].
<center>
[[File:M101-magmor-WP 20140503 005.jpg|200px|link=Polskie magnetofony kasetowe - część 2 - magnetofony przenośne]]
[[File:MK125a.JPG|200px|link=Polskie magnetofony kasetowe - część 2 - magnetofony przenośne]]
[[File:Rms475a-WP 20140605 019.jpg|200px|link=Polskie magnetofony kasetowe - część 2 - magnetofony przenośne]]
</center>

==Najciekawsze artykuły z roku 2014 ([[wydanie 2014]])==
* Aby zobaczyć [[Wydanie 2014|wszystkie artykuły z roku 2014 kliknij tutaj]].
* 2014.11.01 [[Polskie magnetofony kasetowe - część 1 - magnetofony stacjonarne]].
<center>
[[File:Marcin-1.jpg|200px|link=Polskie magnetofony kasetowe - część 1 - magnetofony stacjonarne]]
[[File:DSC08719.JPG|200px|link=Polskie magnetofony kasetowe - część 1 - magnetofony stacjonarne]]
[[File:Mds456-WP 20140606 009.jpg|200px|link=Polskie magnetofony kasetowe - część 1 - magnetofony stacjonarne]]
</center>
*2014.09.23 [[Magnetofony kasetowe]]: Działanie, początki i rozwój technologii, ale czy koniec? Kompendium wiedzy o magnetofonach kasetowych.
<center>
[[File:DSC07972.JPG|200px|link=Magnetofony kasetowe]]
[[File:WP_20140807_003-kasety.jpg|200px|link=Magnetofony kasetowe]]
[[File:DSC07882b.JPG|200px|link=Magnetofony kasetowe]]
</center>
* 2014.06.03 [[Polskie magnetofony szpulowe]]: ''Idąc za ciosem'' "[[Polskie gramofony|Polskich gramofonów]]" tym razem staramy się przybliżyć tematykę krajowych magnetofonów szpulowych.
<center>
[[File:S7300532.JPG|200px|link=Polskie magnetofony szpulowe]]
[[File:S7300579.JPG|200px|link=Polskie magnetofony szpulowe]]
[[File:S7300932.JPG|200px|link=Polskie magnetofony szpulowe]]
</center>

==Archiwum==
* Zapraszamy również do [[Specjalna:Kategorie|działów tematycznych]] i archiwum:
** [[Wydanie 2025|Bieżące wydanie 2025]],
** [[Wydanie 2024|Archiwalne wydanie z roku 2024]],
** [[Wydanie 2023|Archiwalne wydanie z roku 2023]],
** [[Wydanie 2022|Archiwalne wydanie z roku 2022]],
** [[Wydanie 2021|Archiwalne wydanie z roku 2021]],
** [[Wydanie 2020|Archiwalne wydanie z roku 2020]],
** [[Wydanie 2019|Archiwalne wydanie z roku 2019]],
** [[Wydanie 2018|Archiwalne wydanie z roku 2018]],
** [[Wydanie 2017|Archiwalne wydanie z roku 2017]],
** [[Wydanie 2016|Archiwalne wydanie z roku 2016]],
** [[Wydanie 2015|Archiwalne wydanie z roku 2015]],
** [[Wydanie 2014|Archiwalne wydanie z roku 2014]],
** [[Wydanie 2013|Archiwalne wydanie z roku 2013]],
** [[Wydanie 2012|Archiwalne wydanie z roku 2012]].

== Ciekawe wątki z forum ==
* [//www.technique.pl/phpBB2/viewtopic.php?t=233 Pompa parowa dwucylindrowa] [[File:duplex3-szaroleta.jpg|75px|link=http://www.technique.pl/phpBB2/viewtopic.php?t=233]]
* [//www.technique.pl/phpBB2/viewtopic.php?t=179 Przekrój maszyny parowej jako model działający] [[File:t_dscn2478_157-zbeep.jpg|75px|link=http://www.technique.pl/phpBB2/viewtopic.php?t=179]]

== Inne ==
* [//www.technique.pl/phpBB2/ Nasze '''forum''']
* [[Technique.pl:O Technique.pl|Manifest techniczny]]: Co i dlaczego?
* [[Pomoc:Spis_treści|Pomoc]]

{| class="wikitable" style="text-align:center" width="100%"
|<small>''Informacja techniczna: Używamy plików cookies. Korzystanie z witryny bez zmiany ustawień Twojej przeglądarki oznacza, że będą one umieszczane w Twoim urządzeniu końcowym. Zawsze możesz zmienić te ustawienia w Twojej przeglądarce internetowej. Szczegóły znajdziesz na stronie [[Technique.pl:Zasady zachowania poufności|Zasady zachowania poufności - polityka prywatności]].''</small>
|}

Wydanie 2026

2026-08-10T18:59:11Z

Szdowk: /* Aktualności 2026 */

==Aktualności 2026==

*2026.01.18 [[CAD cz.1: wspomnienia i podstawy]].
<center>
[[File:Vu3d-3.jpg|120px|link=CAD cz.1: wspomnienia i podstawy]]
[[File:Prodesignii.jpg|145px|link=CAD cz.1: wspomnienia i podstawy]]
[[File:Acad1a.jpg|140px|link=CAD cz.1: wspomnienia i podstawy]]
</center>

*2026.01.25 [[Olek czyli pół wieku z kolumnami]].
<center>
[[File:Naked sp-00001.jpg|140px|link=Olek czyli pół wieku z kolumnami]]
[[File:Olohorn-1.jpg|120px|link=Olek czyli pół wieku z kolumnami]]
[[File:11 (1).jpg|60px|link=Olek czyli pół wieku z kolumnami]]
</center>

*2026.02.01 [[CAD cz.2: technika 2D]].
<center>
[[File:Megacad 4-2-demo 20260124 102635.jpg|115px|link=CAD cz.2: technika 2D]]
[[File:SimTel-IMG 20260128 201943.jpg|110px|link=CAD cz.2: technika 2D]]
[[File:QCAD-Screenshot 20260128 081947.jpg|140px|link=CAD cz.2: technika 2D]]
</center>

*2026.02.20 [[Tadeusz wajchę przełóż czyli rzecz o zwrotnicach]].
<center>
[[File:Wzorek -1.jpg|180px|link=Tadeusz wajchę przełóż czyli rzecz o zwrotnicach]]
[[File:Kondensatory-1.jpg|110px|link=Tadeusz wajchę przełóż czyli rzecz o zwrotnicach]]
[[File:Rozdział mocy-2.jpg|170px|link=Tadeusz wajchę przełóż czyli rzecz o zwrotnicach]]
</center>

*2026.03.01 [[CAD cz.3: technika 3D - BRLCAD]].
<center>
[[File:2 Screenshot 20260221 164437 cyst wire.jpg|115px|link=CAD cz.3: technika 3D - BRLCAD]]
[[File:3 Screenshot 20260221 165152 cyst ray.jpg|115px|link=CAD cz.3: technika 3D - BRLCAD]]
[[File:12 Screenshot 20260227 133916-silnik5.jpg|160px|link=CAD cz.3: technika 3D - BRLCAD]]
</center>

*2026.03.10 [[Trzask prask i po trzasku]].
<center>
[[File:Moj egz -1.jpg|230px|link=Trzask prask i po trzasku]]
[[File:Dart page -3.jpg|85px|link=Trzask prask i po trzasku]]
[[File:Vinyl-NRS-Box-S3-Black-1024x576 con-1.jpg|230px|link=Trzask prask i po trzasku]]
</center>

*2026.04.02 [[CAD cz.4: technika 3D - FreeCAD]].
<center>
[[File:Cad4 freecad part design Screenshot 20260401 074613.jpg|130px|link=CAD cz.4: technika 3D - FreeCAD]]
[[File:Cad4 freecad part design kolo 2 Screenshot 20260401 074613.jpg|130px|link=CAD cz.4: technika 3D - FreeCAD]]
[[File:Cad4 freecad techdraw Screenshot 20260401 074613.jpg|130px|link=CAD cz.4: technika 3D - FreeCAD]]
</center>

*2026.06.26 [[(Nie)modny zegar na lampach Nixie]].
<center>
[[File:Zegar nixie sheet1.jpg|130px|link=(Nie)modny zegar na lampach Nixie]]
[[File:Zegar nixie img5.jpg|110px|link=(Nie)modny zegar na lampach Nixie]]
[[File:Zegar nixie img13.jpg|135px|link=(Nie)modny zegar na lampach Nixie]]
</center>

*2026.08.10 [[Oswajamy AI]].
<center>
[[File:OAI-02.jpg|130px|link=Oswajamy AI]]
[[File:OAI-05.jpg|130px|link=Oswajamy AI]]
[[File:OAI-08.jpg|130px|link=Oswajamy AI]]
</center>

[[Strona główna|Powrót]]

[[category:Aktualności]]

Oswajamy AI

2026-08-10T18:41:27Z

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.

''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.

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]]

Oswajamy AI

2026-08-10T18:22:24Z

Szdowk: /* Wstęp */

=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.

''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 podstaw. W ten sposób unikniemy wielu nieporozumień. Za to z wyników pracy można być naprawdę zadowolonym.

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]]

Oswajamy AI

2026-08-10T17:59:37Z

Szdowk: /* Wnioski */

=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 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.

''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 podstaw. W ten sposób unikniemy wielu nieporozumień. Za to z wyników pracy można być naprawdę zadowolonym.

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]]

Oswajamy AI

2026-08-10T17:57:10Z

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 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.

''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. […]

''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 podstaw. W ten sposób unikniemy wielu nieporozumień. Za to z wyników pracy można być naprawdę zadowolonym.

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]]

Oswajamy AI

2026-08-10T17:53:21Z

Szdowk: /* Przykład 3: Droga26 */

=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 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.

''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. […]

''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 podstaw. W ten sposób unikniemy wielu nieporozumień. Za to z wyników pracy można być naprawdę zadowolonym.

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.

Trzeba sobie zdawać sprawę, że moment w którym AI zacznie tworzyć u mnie projekt programu 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.

Zupełnie na zakończenie mogę dodać, że obecnie ponad 80% ruchu na technique.pl generują 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]]

Oswajamy AI

2026-08-10T17:52:18Z

Szdowk: /* Przykład 3: Droga26 */

=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 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.

''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. 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. […]

''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 podstaw. W ten sposób unikniemy wielu nieporozumień. Za to z wyników pracy można być naprawdę zadowolonym.

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.

Trzeba sobie zdawać sprawę, że moment w którym AI zacznie tworzyć u mnie projekt programu 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.

Zupełnie na zakończenie mogę dodać, że obecnie ponad 80% ruchu na technique.pl generują 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]]

Oswajamy AI

2026-08-10T17:46:10Z

Szdowk: /* Przykład 3: Droga26 */

=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 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.

''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 "4" (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 prosta "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. 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. […]

''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 podstaw. W ten sposób unikniemy wielu nieporozumień. Za to z wyników pracy można być naprawdę zadowolonym.

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.

Trzeba sobie zdawać sprawę, że moment w którym AI zacznie tworzyć u mnie projekt programu 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.

Zupełnie na zakończenie mogę dodać, że obecnie ponad 80% ruchu na technique.pl generują 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]]

Plik:OAI-08.jpg

2026-08-10T17:44:52Z

Szdowk: Plik przesłany za pomocą MsUpload

Plik przesłany za pomocą MsUpload

Plik:OAI-06.jpg

2026-08-10T17:43:41Z

Szdowk: Plik przesłany za pomocą MsUpload

Plik przesłany za pomocą MsUpload

Plik:OAI-07.jpg

2026-08-10T17:43:41Z

Szdowk: Plik przesłany za pomocą MsUpload

Plik przesłany za pomocą MsUpload

Oswajamy AI

2026-08-10T17:43:01Z

Szdowk: /* Przykład 2: W1914 */

=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 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.

''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 "4" (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 prosta "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.

(rys 6) (rys 7)

W ramach dalszych prac, na życzenie autora (czyli moje ;) ), nadpisany został jeden z trybów wyświetlania. 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.

(rys 8)

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. […]

''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 podstaw. W ten sposób unikniemy wielu nieporozumień. Za to z wyników pracy można być naprawdę zadowolonym.

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.

Trzeba sobie zdawać sprawę, że moment w którym AI zacznie tworzyć u mnie projekt programu 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.

Zupełnie na zakończenie mogę dodać, że obecnie ponad 80% ruchu na technique.pl generują 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]]

Plik:OAI-04.jpg

2026-08-10T17:41:47Z

Szdowk: Plik przesłany za pomocą MsUpload

Plik przesłany za pomocą MsUpload

Plik:OAI-05.jpg

2026-08-10T17:41:47Z

Szdowk: Plik przesłany za pomocą MsUpload

Plik przesłany za pomocą MsUpload

Oswajamy AI

2026-08-10T17:41:09Z

Szdowk: /* Przykład 1: MRace32 */

=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 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.

''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:

(rys 4) (rys 5)

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ą.

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 "4" (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 prosta "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.

(rys 6) (rys 7)

W ramach dalszych prac, na życzenie autora (czyli moje ;) ), nadpisany został jeden z trybów wyświetlania. 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.

(rys 8)

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. […]

''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 podstaw. W ten sposób unikniemy wielu nieporozumień. Za to z wyników pracy można być naprawdę zadowolonym.

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.

Trzeba sobie zdawać sprawę, że moment w którym AI zacznie tworzyć u mnie projekt programu 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.

Zupełnie na zakończenie mogę dodać, że obecnie ponad 80% ruchu na technique.pl generują 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]]

Plik:OAI-01.jpg

2026-08-10T17:38:56Z

Szdowk: Plik przesłany za pomocą MsUpload

Plik przesłany za pomocą MsUpload

Plik:OAI-02.jpg

2026-08-10T17:38:56Z

Szdowk: Plik przesłany za pomocą MsUpload

Plik przesłany za pomocą MsUpload

Plik:OAI-03.jpg

2026-08-10T17:38:56Z

Szdowk: Plik przesłany za pomocą MsUpload

Plik przesłany za pomocą MsUpload

Oswajamy AI

2026-08-10T17:37:54Z

Szdowk:

=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 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.

''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ą.

(rys 1) (rys 2) (rys 3)

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:

(rys 4) (rys 5)

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ą.

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 "4" (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 prosta "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.

(rys 6) (rys 7)

W ramach dalszych prac, na życzenie autora (czyli moje ;) ), nadpisany został jeden z trybów wyświetlania. 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.

(rys 8)

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. […]

''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 podstaw. W ten sposób unikniemy wielu nieporozumień. Za to z wyników pracy można być naprawdę zadowolonym.

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.

Trzeba sobie zdawać sprawę, że moment w którym AI zacznie tworzyć u mnie projekt programu 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.

Zupełnie na zakończenie mogę dodać, że obecnie ponad 80% ruchu na technique.pl generują 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]]

Oswajamy AI

2026-08-10T17:36:23Z

Szdowk: /* Wnioski */

=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 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.

''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ą.

(rys 1) (rys 2) (rys 3)

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:

(rys 4) (rys 5)

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ą.

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 "4" (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 prosta "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.

(rys 6) (rys 7)

W ramach dalszych prac, na życzenie autora (czyli moje ;) ), nadpisany został jeden z trybów wyświetlania. 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.

(rys 8)

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. […]

''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 podstaw. W ten sposób unikniemy wielu nieporozumień. Za to z wyników pracy można być naprawdę zadowolonym.

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.

Trzeba sobie zdawać sprawę, że moment w którym AI zacznie tworzyć u mnie projekt programu 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.

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

Szymon Dowkontt

Oswajamy AI

2026-08-10T17:33:56Z

Szdowk: /* Przykład 3: Droga26 */

=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 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.

''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ą.

(rys 1) (rys 2) (rys 3)

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:

(rys 4) (rys 5)

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ą.

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 "4" (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 prosta "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.

(rys 6) (rys 7)

W ramach dalszych prac, na życzenie autora (czyli moje ;) ), nadpisany został jeden z trybów wyświetlania. 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.

(rys 8)

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. […]

''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 podstaw. W ten sposób unikniemy wielu nieporozumień. Za to z wyników pracy można być naprawdę zadowolonym.

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.

Trzeba sobie zdawać sprawę, że moment w którym AI zacznie tworzyć u mnie projekt programu 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.

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

Szymon Dowkontt

Oswajamy AI

2026-08-10T17:30:09Z

Szdowk:

=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 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.

''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ą.

(rys 1) (rys 2) (rys 3)

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:

(rys 4) (rys 5)

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ą.

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 "4" (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 prosta "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 ten, 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ć 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.

(rys 6) (rys 7)

W ramach dalszych prac, na życzenie autora (czyli moje ;) ), nadpisany został jeden z trybów wyświetlania. 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 dodatkowe 2 godziny pracy.

(rys 8)

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. […]

''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 podstaw. W ten sposób unikniemy wielu nieporozumień. Za to z wyników pracy można być naprawdę zadowolonym.

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.

Trzeba sobie zdawać sprawę, że moment w którym AI zacznie tworzyć u mnie projekt programu 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.

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

Szymon Dowkontt

Oswajamy AI

2026-08-10T17:02:17Z

Szdowk: Utworzono nową stronę "=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ę o..."

Testy i próby

2026-08-10T15:28:44Z

Szdowk:

[[Category:Informacje administracyjne]]

[[SZROT]]

'''GOTOWE:'''

'''W tym miejscu będą chwilowo umieszczane testy i niekompletne artykuły...'''

[[中小企業]]

[[Simplex Superchampion]]

[[Ramiona w wieku emerytalnym - epizod 3 RK-O-KUT Micropoise Tonearm]]

[[Ramiona w wieku emerytalnym - epizod 4 Decca London International Tonearm]]

[[Wieża Hi – Fi - czyli powrót wieży Babel powrót po latach]]

[[Traktat o rysunkach]]

[[Chwała Szpulakom]]

[[Odrobina Szaleństwa czyli Kolumny Okrętowe]]

[[Goodmans a sprawa polska 2]]

[[Nowy gramofon w dziale gramofony naszych przyjaciół]]

[[Krótka historia ciepła cześć I]]

[[Co z tym ramieniem ? ćwiczenia praktyczne - drugi sezon ]]

[["Cyfrówka" czyli tryumf bezmyślności]]

[[Wybrane fragmenty historii gramofonów firmy Thorens rozdział 2 - pierwszy wielki przebój]]

[[Wybrane fragmenty historii gramofonów firmy Thorens rozdział 3 - Klasyka gatunku TD 150, TD 160, TD 125]]

[[Wybrane fragmenty historii gramofonów firmy Thorens rozdział 14 - ciekawostki]]

[[Oswajamy AI]]

[[Pomoc:Spis_treści|Powrót]]

Wydanie 2026

2026-06-23T13:52:27Z

Szdowk: /* Aktualności 2026 */

==Aktualności 2026==

*2026.01.18 [[CAD cz.1: wspomnienia i podstawy]].
<center>
[[File:Vu3d-3.jpg|120px|link=CAD cz.1: wspomnienia i podstawy]]
[[File:Prodesignii.jpg|145px|link=CAD cz.1: wspomnienia i podstawy]]
[[File:Acad1a.jpg|140px|link=CAD cz.1: wspomnienia i podstawy]]
</center>

*2026.01.25 [[Olek czyli pół wieku z kolumnami]].
<center>
[[File:Naked sp-00001.jpg|140px|link=Olek czyli pół wieku z kolumnami]]
[[File:Olohorn-1.jpg|120px|link=Olek czyli pół wieku z kolumnami]]
[[File:11 (1).jpg|60px|link=Olek czyli pół wieku z kolumnami]]
</center>

*2026.02.01 [[CAD cz.2: technika 2D]].
<center>
[[File:Megacad 4-2-demo 20260124 102635.jpg|115px|link=CAD cz.2: technika 2D]]
[[File:SimTel-IMG 20260128 201943.jpg|110px|link=CAD cz.2: technika 2D]]
[[File:QCAD-Screenshot 20260128 081947.jpg|140px|link=CAD cz.2: technika 2D]]
</center>

*2026.02.20 [[Tadeusz wajchę przełóż czyli rzecz o zwrotnicach]].
<center>
[[File:Wzorek -1.jpg|180px|link=Tadeusz wajchę przełóż czyli rzecz o zwrotnicach]]
[[File:Kondensatory-1.jpg|110px|link=Tadeusz wajchę przełóż czyli rzecz o zwrotnicach]]
[[File:Rozdział mocy-2.jpg|170px|link=Tadeusz wajchę przełóż czyli rzecz o zwrotnicach]]
</center>

*2026.03.01 [[CAD cz.3: technika 3D - BRLCAD]].
<center>
[[File:2 Screenshot 20260221 164437 cyst wire.jpg|115px|link=CAD cz.3: technika 3D - BRLCAD]]
[[File:3 Screenshot 20260221 165152 cyst ray.jpg|115px|link=CAD cz.3: technika 3D - BRLCAD]]
[[File:12 Screenshot 20260227 133916-silnik5.jpg|160px|link=CAD cz.3: technika 3D - BRLCAD]]
</center>

*2026.03.10 [[Trzask prask i po trzasku]].
<center>
[[File:Moj egz -1.jpg|230px|link=Trzask prask i po trzasku]]
[[File:Dart page -3.jpg|85px|link=Trzask prask i po trzasku]]
[[File:Vinyl-NRS-Box-S3-Black-1024x576 con-1.jpg|230px|link=Trzask prask i po trzasku]]
</center>

*2026.04.02 [[CAD cz.4: technika 3D - FreeCAD]].
<center>
[[File:Cad4 freecad part design Screenshot 20260401 074613.jpg|130px|link=CAD cz.4: technika 3D - FreeCAD]]
[[File:Cad4 freecad part design kolo 2 Screenshot 20260401 074613.jpg|130px|link=CAD cz.4: technika 3D - FreeCAD]]
[[File:Cad4 freecad techdraw Screenshot 20260401 074613.jpg|130px|link=CAD cz.4: technika 3D - FreeCAD]]
</center>

*2026.06.26 [[(Nie)modny zegar na lampach Nixie]].
<center>
[[File:Zegar nixie sheet1.jpg|130px|link=(Nie)modny zegar na lampach Nixie]]
[[File:Zegar nixie img5.jpg|110px|link=(Nie)modny zegar na lampach Nixie]]
[[File:Zegar nixie img13.jpg|135px|link=(Nie)modny zegar na lampach Nixie]]
</center>

[[Strona główna|Powrót]]

[[category:Aktualności]]

Strona główna

2026-06-23T13:48:12Z

Szdowk: /* Artykuły z roku 2026 (wydanie 2026) */

[[category:Aktualności]]__NOTOC__
'''Witamy na stronie Technique.pl'''

==Artykuły z roku 2026 ([[wydanie 2026]])==

*2026.06.26 [[(Nie)modny zegar na lampach Nixie]].
<center>
[[File:Zegar nixie sheet1.jpg|130px|link=(Nie)modny zegar na lampach Nixie]]
[[File:Zegar nixie img5.jpg|110px|link=(Nie)modny zegar na lampach Nixie]]
[[File:Zegar nixie img13.jpg|135px|link=(Nie)modny zegar na lampach Nixie]]
</center>

*2026.04.02 [[CAD cz.4: technika 3D - FreeCAD]].
<center>
[[File:Cad4 freecad part design Screenshot 20260401 074613.jpg|130px|link=CAD cz.4: technika 3D - FreeCAD]]
[[File:Cad4 freecad part design kolo 2 Screenshot 20260401 074613.jpg|130px|link=CAD cz.4: technika 3D - FreeCAD]]
[[File:Cad4 freecad techdraw Screenshot 20260401 074613.jpg|130px|link=CAD cz.4: technika 3D - FreeCAD]]
</center>

*2026.03.10 [[Trzask prask i po trzasku]].
<center>
[[File:Moj egz -1.jpg|230px|link=Trzask prask i po trzasku]]
[[File:Dart page -3.jpg|85px|link=Trzask prask i po trzasku]]
[[File:Vinyl-NRS-Box-S3-Black-1024x576 con-1.jpg|230px|link=Trzask prask i po trzasku]]
</center>

*2026.03.01 [[CAD cz.3: technika 3D - BRLCAD]].
<center>
[[File:2 Screenshot 20260221 164437 cyst wire.jpg|115px|link=CAD cz.3: technika 3D - BRLCAD]]
[[File:3 Screenshot 20260221 165152 cyst ray.jpg|115px|link=CAD cz.3: technika 3D - BRLCAD]]
[[File:12 Screenshot 20260227 133916-silnik5.jpg|160px|link=CAD cz.3: technika 3D - BRLCAD]]
</center>

*2026.02.20 [[Tadeusz wajchę przełóż czyli rzecz o zwrotnicach]].
<center>
[[File:Wzorek -1.jpg|180px|link=Tadeusz wajchę przełóż czyli rzecz o zwrotnicach]]
[[File:Kondensatory-1.jpg|110px|link=Tadeusz wajchę przełóż czyli rzecz o zwrotnicach]]
[[File:Rozdział mocy-2.jpg|170px|link=Tadeusz wajchę przełóż czyli rzecz o zwrotnicach]]
</center>

*2026.02.01 [[CAD cz.2: technika 2D]].
<center>
[[File:Megacad 4-2-demo 20260124 102635.jpg|115px|link=CAD cz.2: technika 2D]]
[[File:SimTel-IMG 20260128 201943.jpg|110px|link=CAD cz.2: technika 2D]]
[[File:QCAD-Screenshot 20260128 081947.jpg|140px|link=CAD cz.2: technika 2D]]
</center>

*2026.01.25 [[Olek czyli pół wieku z kolumnami]].
<center>
[[File:Naked sp-00001.jpg|140px|link=Olek czyli pół wieku z kolumnami]]
[[File:Olohorn-1.jpg|120px|link=Olek czyli pół wieku z kolumnami]]
[[File:11 (1).jpg|60px|link=Olek czyli pół wieku z kolumnami]]
</center>

*2026.01.18 [[CAD cz.1: wspomnienia i podstawy]].
<center>
[[File:Vu3d-3.jpg|120px|link=CAD cz.1: wspomnienia i podstawy]]
[[File:Prodesignii.jpg|145px|link=CAD cz.1: wspomnienia i podstawy]]
[[File:Acad1a.jpg|140px|link=CAD cz.1: wspomnienia i podstawy]]
</center>

==Artykuły z roku 2025 ([[wydanie 2025]])==
*2025.12.31 [[Quo Vadis Technique ?]]
<center>
[[File:DSC02819.JPG|120px|link=Quo Vadis Technique ?]]
[[File:Tetra-9.jpg|100px|link=Quo Vadis Technique ?]]
[[File:Acad1.jpg|120px|link=Quo Vadis Technique ?]]
</center>

*2025.12.29 [[Jest różnica czyli coming out]].
<center>
[[File:Yamaha1000- 1 small.jpg|80px|link=Jest różnica czyli coming out]]
[[File:Filtr -1.jpg|120px|link=Jest różnica czyli coming out]]
[[File:Quad 405 clone -1 .jpg|130px|link=Jest różnica czyli coming out]]
</center>

*2025.12.24 [[Powrót do przyszłości czyli HydroPeloponez]].
<center>
[[File:Polo 6732.jpg|120px|link=Powrót do przyszłości czyli HydroPeloponez]]
[[File:Polo 6319-1.jpg|120px|link=Powrót do przyszłości czyli HydroPeloponez]]
[[File:Polo 5808-1.jpg|120px|link=Powrót do przyszłości czyli HydroPeloponez]]
</center>

*2025.12.21 [[Ramiona w wieku emerytalnym - epizod 2 EMI E.P.U. 100]].
<center>
[[File:EMI 100-1.JPG|120px|link=Ramiona w wieku emerytalnym - epizod 2 EMI E.P.U. 100]]
[[File:EMI 100-5.JPG|120px|link=Ramiona w wieku emerytalnym - epizod 2 EMI E.P.U. 100]]
[[File:EMI 100-6.JPG|120px|link=Ramiona w wieku emerytalnym - epizod 2 EMI E.P.U. 100]]
</center>

*2025.12.20 [[Ramiona w wieku emerytalnym - epizod 1 Leak]].
<center>
[[File:Leak- instrukcja - 1.jpg|60px|link=Ramiona w wieku emerytalnym - epizod 1 Leak]]
[[File:Leak 13.JPG|120px|link=Ramiona w wieku emerytalnym - epizod 1 Leak]]
[[File:Leak 4.JPG|120px|link=Ramiona w wieku emerytalnym - epizod 1 Leak]]
</center>

*2025.12.17 [[Królowa ramion Low Mass Infinity Black Widow]].
<center>
[[File:Black Widow - 1b.jpg|60px|link=Królowa ramion Low Mass Infinity Black Widow]]
[[File:Black widow dane-2.jpg|70px|link=Królowa ramion Low Mass Infinity Black Widow]]
[[File:Black Widow - 3.jpg|80px|link=Królowa ramion Low Mass Infinity Black Widow]]
</center>

*2025.12.10 [[Cmapm czyli nienerwowy powrót ramion 2025]].
<center>
[[File:Ram - 002.jpg|60px|link=Cmapm czyli nienerwowy powrót ramion 2025]]
[[File:DSC05814.JPG|120px|link=Cmapm czyli nienerwowy powrót ramion 2025]]
[[File:Sto-2.jpg|100px|link=Cmapm czyli nienerwowy powrót ramion 2025]]
</center>

*2025.12.04 [[Stary Pass czyli w oczekiwaniu na jubileusz]].
<center>
[[File:Tetra-0.jpg|86px|link=Stary Pass czyli w oczekiwaniu na jubileusz]]
[[File:Tetra-9.jpg|100px|link=Stary Pass czyli w oczekiwaniu na jubileusz]]
[[File:Penta - 2.jpg|100px|link=Stary Pass czyli w oczekiwaniu na jubileuszy]]
</center>

*2025.11.30 [[NA TAŚMIE – Wielościeżkowa historia Zakładów Radiowych Kasprzaka Relacja z wystawy]].
<center>
[[File:Wyst -09 20251021 175651-1.jpg|100px|link=NA TAŚMIE – Wielościeżkowa historia Zakładów Radiowych Kasprzaka Relacja z wystawy]]
[[File:Wyst -01 20251021 1.jpg|80px|link=NA TAŚMIE – Wielościeżkowa historia Zakładów Radiowych Kasprzaka Relacja z wystawy]]
[[File:Wyst -04 20251021 175918-1.jpg|120px|link=NA TAŚMIE – Wielościeżkowa historia Zakładów Radiowych Kasprzaka Relacja z wystawy]]
</center>

*2025.11.04 [[Hamownia dla małych silników, cz.3. Wykorzystanie alternatora w charakterze obciążenia. Sterowanie i konstrukcja]].
<center>
[[File:Rys 6a napiecie pradu wzbudzenia.jpg|130px|link=Hamownia dla małych silników, cz.3. Wykorzystanie alternatora w charakterze obciążenia. Sterowanie i konstrukcja]]
[[File:Hamownia hamulec.jpg|80px|link=Hamownia dla małych silników, cz.3. Wykorzystanie alternatora w charakterze obciążenia. Sterowanie i konstrukcja]]
[[File:H2-sprawnosc-alternatora.jpg|130px|link=Hamownia dla małych silników, cz.3. Wykorzystanie alternatora w charakterze obciążenia. Sterowanie i konstrukcja]]
</center>

*2025.10.10 [[Upadek prasy]].
<center>
[[File:1-IMG 20251009 174548.jpg|80px|link=Upadek prasy]]
[[File:2-IMG 20251009 174644.jpg|80px|link=Upadek prasy]]
[[File:4-IMG_20251011_180622.jpg|80px|link=Upadek prasy]]
</center>

==Artykuły z roku 2024 ([[wydanie 2024]])==
*2024.12.29 [[Wybrane fragmenty historii gramofonów firmy Thorens rozdział 1 - Powrót sentymentów]].
<center>
[[File:Refrenc 4.jpg|140px|link=Wybrane fragmenty historii gramofonów firmy Thorens rozdział 1 - Powrót sentymentów]]
[[File:Torref-5 sme.jpg|80px|link=Wybrane fragmenty historii gramofonów firmy Thorens rozdział 1 - Powrót sentymentów]]
[[File:Refrenc 1.jpg|140px|link=Wybrane fragmenty historii gramofonów firmy Thorens rozdział 1 - Powrót sentymentów]]
</center>

*2024.12.12 [[Od paska napędowego do sztucznej inteligencji]].
<center>
[[File:GdZsYYpA2AD39fIh-bis.png|140px|link=Od paska napędowego do sztucznej inteligencji]]
[[File:5jxBFlunqdOQY0QW bis .png|60px|link=Od paska napędowego do sztucznej inteligencji]]
[[File:G3MnFdxXPqKk0sPF.png|180px|link=Od paska napędowego do sztucznej inteligencji]]
</center>

*2024.12.10 [[30 lat później czyli powrót gramofonu Janka]].
<center>
[[File:Gra-Ja-01.jpg|170px|link=30 lat później czyli powrót gramofonu Janka]]
[[File:Gra-Ja-07.jpg|160px|link=30 lat później czyli powrót gramofonu Janka]]
[[File:Gra-Ja-18.jpg|150px|link=30 lat później czyli powrót gramofonu Janka]]
</center>

*2024.11.30 [[Generatory w służbie Narodu - część 1]].
<center>
[[File:Osc.png|120px|link=Generatory w służbie Narodu - część 1]]
[[File:Schemat ideowy.png|200px|link=Generatory w służbie Narodu - część 1]]
[[File:P lm833.png|170px|link=Generatory w służbie Narodu - część 1]]
</center>

*2024.11.26 [[Pol-Audio czyli wzmacniacz za 12 baniek]].
<center>
[[File:Opis - 1small.jpg|120px|link=Pol-Audio czyli wzmacniacz za 12 baniek]]
[[File:Pol-audio-02.jpg|190px|link=Pol-Audio czyli wzmacniacz za 12 baniek]]
[[File:Polaudio 2023 -3s.jpg|120px|link=Pol-Audio czyli wzmacniacz za 12 baniek]]
</center>

*2024.11.14 [[Syriusz B czyli kontynuacja]].
<center>
[[File:Syriusz 2-6a.jpg|139px|link=Syriusz B czyli kontynuacja]]
[[File:Syriusz B prime-2.jpg|190px|link=Syriusz B czyli kontynuacja]]
[[File:Syriusz 2-7.jpg|134px|link=Syriusz B czyli kontynuacja]]
</center>

*2024.10.31 [[Linijka czyli suplemencik]].
<center>
[[File:Old-5.jpg|80px|link=Linijka_czyli_suplemencik]]
[[File:Linijka_-15.jpg|190px|link=Linijka_czyli_suplemencik]]
[[File:Linijka - 1.jpg|70px|link=Linijka_czyli_suplemencik]]
</center>

*2024.04.08 [[Perły z lamusa - niezwykłe zjawiska w Fonomasterze ciąg dalszy]].
<center>
[[File:Naped od gory-2.jpg|190px|link=Perły z lamusa - niezwykłe zjawiska w Fonomasterze ciąg dalszy]]
[[File:Widok od spodu-1.jpg|190px|link=Perły z lamusa - niezwykłe zjawiska w Fonomasterze ciąg dalszy]]
[[File:Naped od gory-0.jpg|190px|link=Perły z lamusa - niezwykłe zjawiska w Fonomasterze ciąg dalszy]]
</center>

*2024.04.01 [[Perły z lamusa - niezwykłe zjawiska w Fonomasterze]].
<center>
[[File:Widok z gory-0a.jpg|129px|link=Perły z lamusa - niezwykłe zjawiska w Fonomasterze]]
[[File:Stroboskop-1.jpg|190px|link=Perły z lamusa - niezwykłe zjawiska w Fonomasterze]]
[[File:Widok ogolny -2 .jpg|190px|link=Perły z lamusa - niezwykłe zjawiska w Fonomasterze]]
</center>

*2024.02.14 [[Drukujemy maszynę parową - pliki]].
<center>
[[File:4 Skrzynia zaworowa.jpg|190px|link=Drukujemy maszynę parową - pliki]]
[[File:3 Tloczysko 3.jpg|220px|link=Drukujemy maszynę parową - pliki]]
[[File:5 Pokrywa skrzyni zaworowej.jpg|110px|link=Drukujemy maszynę parową - pliki]]
</center>

==Artykuły z roku 2023 ([[wydanie 2023]])==
*2023.12.29 [[Drukujemy maszynę parową]].
<center>
[[File:Technique_pl_IMG_20230824_140525.jpg|140px|link=Drukujemy maszynę parową]]
[[File:Technique_pl_Screenshot_20231229_081158.jpg|200px|link=Drukujemy maszynę parową]]
[[File:Technique_pl_IMG_20231127_141546.jpg|140px|link=Drukujemy maszynę parową]]
</center>

*2023.10.09 [[Perły z lamusa czyli nostalgia kontra zdrowy rozsądek]].
<center>
[[File:Zestaw-3.jpg|190px|link=Perły z lamusa czyli nostalgia kontra zdrowy rozsądek]]
[[File:Zestaw-1.jpg|210px|link=Perły z lamusa czyli nostalgia kontra zdrowy rozsądek]]
[[File:W600-7.jpg|260px|link=Perły z lamusa czyli nostalgia kontra zdrowy rozsądek]]
</center>

*2023.09.17 [[Nowy Gramofon Część V Wielki Finał - czyli ostateczne zamkniecie tekstu z roku 2021]].
<center>
[[File:Kwia2021-7.jpg|140px|link=Nowy Gramofon Część V Wielki Finał - czyli ostateczne zamkniecie tekstu z roku 2021]]
[[File:100 5708-re1.jpg|100px|link=Nowy Gramofon Część V Wielki Finał - czyli ostateczne zamkniecie tekstu z roku 2021]]
[[File:100 5714-re1.jpg|140px|link=Nowy Gramofon Część V Wielki Finał - czyli ostateczne zamkniecie tekstu z roku 2021]]
</center>

*2023.09.11 [[Co z tym ramieniem ? ćwiczenia praktyczne]].
<center>
[[File:Head shell-2.jpg|100px|link=Co z tym ramieniem ? ćwiczenia praktyczne]]
[[File:2-12D-1.jpg|240px|link=Co z tym ramieniem ? ćwiczenia praktyczne]]
[[File:Gemini -4.jpg|100px|link=Co z tym ramieniem ? ćwiczenia praktyczne]]
</center>

*2023.08.02 [[Elektronika od Wielkiego Wybuchu]].
<center>
[[File:BAMBINO 2 SCHEMAT.jpg|100px|link=Elektronika od Wielkiego Wybuchu]]
[[File:Rysunek-46b.jpg|150px|link=Elektronika od Wielkiego Wybuchu]]
[[File:Rysunek-40a.jpg|150px|link=Elektronika od Wielkiego Wybuchu]]
</center>

*2023.07.20 [[Co z tym ramieniem ? Dual w DIY czyli ramię specjalnej troski]].
<center>
[[File:607etc-6.jpg|150px|link=Co z tym ramieniem ? Dual w DIY czyli ramię specjalnej troski]]
[[File:Dual 607 617 edit -5b.jpg|130px|link=Co z tym ramieniem ? Dual w DIY czyli ramię specjalnej troski]]
[[File:Dumet-4.jpg|130px|link=Co z tym ramieniem ? Dual w DIY czyli ramię specjalnej troski]]
</center>

*2023.07.18 [[Co z tym ramieniem ? czyli traktat o produkcji sera]].
<center>
[[File:1101 dok-3.jpg|120px|link=Co z tym ramieniem ? czyli traktat o produkcji sera]]
[[File:Test papierosow-2.jpg|190px|link=Co z tym ramieniem ? czyli traktat o produkcji sera]]
[[File:Ser-1.jpg|140px|link=Co z tym ramieniem ? czyli traktat o produkcji sera]]
</center>

*2023.04.23 [[Syriusz A czyli historia gramofonu Janka z Mielca]].
<center>
[[File:Podstawa-1-IMG 20210809 162040.jpg|150px|link=Syriusz A czyli historia gramofonu Janka z Mielca]]
[[File:Widok ogolny -2-IMG 20210809 163151.jpg|160px|link=Syriusz A czyli historia gramofonu Janka z Mielca]]
[[File:Podstawa-3-IMG 20210809 162059.jpg|200px|link=Syriusz A czyli historia gramofonu Janka z Mielca]]
</center>

*2023.04.06 [[Gramofon dla wszystkich czyli akt gramofonowej kapitulacji]].
<center>
[[File:Postument_-1.jpg|200px|link=Gramofon dla wszystkich czyli akt gramofonowej kapitulacji]]
[[File:Ogolny z góry-2.jpg|160px|link=Gramofon dla wszystkich czyli akt gramofonowej kapitulacji]]
[[File:Nóżka-111.jpg|150px|link=Gramofon dla wszystkich czyli akt gramofonowej kapitulacji]]
</center>

*2023.02.28 [[System zdalnego sterowania do magnetofonu Revox A77]].
<center>
[[File:Revoxa77-mod1.jpg|180px|link=System zdalnego sterowania do magnetofonu Revox A77]]
[[File:Revoxa77-sch3.png|250px|link=System zdalnego sterowania do magnetofonu Revox A77]]
[[File:Revoxa77-pilot1.jpg|110px|link=System zdalnego sterowania do magnetofonu Revox A77]]
</center>

*2023.01.29 [[Budapeszt w Warszawie czyli sukces marki Videoton nad Wisłą]].
<center>
[[File:Midimax-3.jpg|110px|link=Budapeszt w Warszawie czyli sukces marki Videoton nad Wisłą]]
[[File:Halka -01.jpg|430px|link=Budapeszt w Warszawie czyli sukces marki Videoton nad Wisłą]]
[[File:ENC-4.jpg|150px|link=Budapeszt w Warszawie czyli sukces marki Videoton nad Wisłą]]
</center>

==Artykuły z roku 2022 ([[wydanie 2022]])==

*2022.12.24 [[Po co komu Winyl? czyli osobisty wstęp do gramofonów]].
<center>
[[File:Pre-02.jpg|180px|link=Po co komu Winyl? czyli osobisty wstęp do gramofonów]]
[[File:Tr200-2.jpg|230px|link=Po co komu Winyl? czyli osobisty wstęp do gramofonów]]
[[File:Pre-08.jpg|150px|link=Po co komu Winyl? czyli osobisty wstęp do gramofonów]]
</center>

*2022.11.19 [[Hamownia dla małych silników, cz.2.]]
<center>
[[File:H2-tabliczka-znamionowa.jpg|130px|link=Hamownia dla małych silników, cz.2.]]
[[File:H2-zdjecie-z-ekranu-oscyloskopu-IMG 20220721 070321.jpg|120px|link=Hamownia dla małych silników, cz.2.]]
[[File:H2-moment-obrotowy-i-moc.jpg|140px|link=Hamownia dla małych silników, cz.2.]]
</center>

*2022.09.23 [[Hamownia dla małych silników, cz.1.]]
<center>
[[File:Hamownia widok ogolny 1.jpg|100px|link=Hamownia dla małych silników, cz.1.]]
[[File:Hamownia stanowisko pomiarowe.jpg|130px|link=Hamownia dla małych silników, cz.1.]]
[[File:Hamownia zdjecie z ekranu.jpg|130px|link=Hamownia dla małych silników, cz.1.]]
</center>

*2022.05.24 [[Termowizja niskobudżetowa]].
<center>
[[File:P2-1652968491337.jpg|100px|link=Termowizja niskobudżetowa]]
[[File:P2-IMG 20220519 160510.jpg|100px|link=Termowizja niskobudżetowa]]
[[File:P22-1653281832408.jpg|100px|link=Termowizja niskobudżetowa]]
</center>

*2022.04.29 [[MK235_2022|Magnetofon MK235]].
<center>
[[File:Mk232p IMG-20211024-WA0000.jpg|135px|link=MK235_2022]]
[[File:C235 1.jpg|100px|link=MK235_2022]]
[[File:Mk235 mk prom.jpg|135px|link=MK235_2022]]
</center>

*2022.03.24 [[Technologie addytywne 2022]].
<center>
[[File:Sprzeglo2.jpg|120px|link=Technologie addytywne 2022]]
[[File:Zasilacz-photo 2022-03-12 13-41-06.jpg|135px|link=Technologie addytywne 2022]]
[[File:Klawisz-IMG 20220305 142123.jpg|135px|link=Technologie addytywne 2022]]
</center>

*2022.02.19 [[Rekonstrukcja zdalnego sterowania]].
<center>
[[File:Wnetrze pilota IMG 20211107 114729.jpg|140px|link=Rekonstrukcja zdalnego sterowania]]
[[File:Schemat-mc14502x.jpg|220px|link=Rekonstrukcja zdalnego sterowania]]
[[File:Frec count-20211201001.jpg|110px|link=Rekonstrukcja zdalnego sterowania]]
</center>

*2022.02.09 [[Goodmans a sprawa polska]].
<center>
[[File:Sko-DSC02680 bok.jpg|150px|link=Goodmans a sprawa polska]]
[[File:Biurko-red-1.jpg|270px|link=Goodmans a sprawa polska]]
[[File:Fonia GK 122.2-page-001.jpg|180px|link=Goodmans a sprawa polska]]
</center>

==Artykuły z roku 2021 ([[wydanie 2021]])==

*2021.05.30 [[Nowy Gramofon - Część IV]].
<center>
[[File:S7300753-re1.jpg|90px|link=Nowy Gramofon - Część IV]]
[[File:Kwia2021-8.jpg|200px|link=Nowy Gramofon - Część IV]]
[[File:100 5718-re1.jpg|180px|link=Nowy Gramofon - Część IV]]
</center>

*2021.05.20 [[Za co kochamy linie transmisyjne II]].
<center>
[[File:GOT-1 - Monitory PRO 9TL.jpg|90px|link=Za co kochamy linie transmisyjne II]]
[[File:ML-TL-3a.jpg|100px|link=Za co kochamy linie transmisyjne II]]
[[File:02 - Monitory PRO 9TL.jpg|100px|link=Za co kochamy linie transmisyjne II]]
</center>

*2021.04.01 [[Nowy Gramofon - Część III]].
<center>
[[File:Kulki-2.JPG|160px|link=Nowy_Gramofon_-_Część_III]]
[[File:Sssilnik-1.JPG|190px|link=Nowy_Gramofon_-_Część_III]]
[[File:Ortofon --3a.JPG|160px|link=Nowy_Gramofon_-_Część_III]]
</center>

*2021.03.13 [[Nowy Gramofon - Część II]].
<center>
[[File:00-zespol podstawy ramienia z ramieniem -1.JPG|160px|link=Nowy_Gramofon_-_Część_II]]
[[File:00 zdezintegrowany z talerzem i silnikiem-1.JPG|160px|link=Nowy_Gramofon_-_Część_II]]
[[File:00 zdezintegrowany z talerzem i silnikiem- 3ramiona-3.JPG|160px|link=Nowy_Gramofon_-_Część_II]]
</center>

*2021.03.13 [[Za co kochamy linie transmisyjne I]].
<center>
[[File:IMF 80 TLS widok -1.jpg|140px|link=Za co kochamy linie transmisyjne I]]
[[File:IMF przekroje -1sm.jpg|140px|link=Za co kochamy linie transmisyjne I]]
[[File:Hi-fi ans - aug 75-1.jpg|140px|link=Za co kochamy linie transmisyjne I]]
</center>

*2021.02.15 [[Nowy Gramofon - Część I]].
<center>
[[File:Trzylistny kwiatek-1.jpg|160px|link=Nowy_Gramofon_-_Część_I]]
[[File:Puszki kwiatka -1.jpg|160px|link=Nowy_Gramofon_-_Część_I]]
[[File:Podstawa zinegrowana pod sme-5.jpg|120px|link=Nowy_Gramofon_-_Część_I]]
</center>

*2021.02.15 [[Klasycy o kompensacji siły poślizgu czyli trochę prawdy o antiskatingu - wersja 2021]].
<center>
[[File:Fig. 01-pl.jpg|100px|link=Klasycy o kompensacji siły poślizgu czyli trochę prawdy o antiskatingu - wersja 2021]]
[[File:Fig. 03pll.jpg|160px|link=Klasycy o kompensacji siły poślizgu czyli trochę prawdy o antiskatingu - wersja 2021]]
[[File:Fig. 11pl.jpg|160px|link=Klasycy o kompensacji siły poślizgu czyli trochę prawdy o antiskatingu - wersja 2021]]
</center>

*2021.01.12 [[Silniki nitinolowe]].
<center>
[[File:WP_20150210_006-nitinol.jpg|80px|link=Silniki nitinolowe]]
[[File:WP 20150210 011-nitinol.jpg|160px|link=Silniki nitinolowe]]
</center>

*2021.01.01 [[Manifest 2021]].
<center>
[[File:Zuraw-WP 20140307 002.jpg|180px|link=Manifest_2021]]
[[File:Cmt831-02-WP 20140910 005.jpg|160px|link=Manifest_2021]]
[[File:Garrard 100 -00b.JPG|120px|link=Manifest_2021]]
</center>

*2021.01.01 [[Nowy Gramofon - Prolog]].
<center>
[[File:Gramofon-kwiatek-001.jpg|140px|link=Nowy_Gramofon_-_Prolog]]
[[File:Jbe 3001 direct drive turntable.jpg|160px|link=Nowy_Gramofon_-_Prolog]]
[[File:Gramofon-kwiatek-002.jpg|160px|link=Nowy_Gramofon_-_Prolog]]
</center>

==Artykuły z roku 2020 ([[wydanie 2020]])==
*2020.03.14 [[Miernik wiecznie żywy czyli Meratronik V640 – aneks nr 2 do artykułu]].
<center>
[[File:Pud13.jpg|180px|link=Miernik wiecznie żywy czyli Meratronik V640 – aneks nr 2 do artykułu]]
[[File:Awp1.jpg|100px|link=Miernik wiecznie żywy czyli Meratronik V640 – aneks nr 2 do artykułu]]
[[File:Pud5.jpg|160px|link=Miernik wiecznie żywy czyli Meratronik V640 – aneks nr 2 do artykułu]]
</center>

*2020.01.28 [[Wieża Hi – Fi - czyli powrót wieży Babel część I]].
<center>
[[File:Preamp- amp- tuner - 1a.jpg|180px|link=Wieża Hi – Fi - czyli powrót wieży Babel część I]]
[[File:Zestaw - prospekt - stro-1.jpg|160px|link=Wieża Hi – Fi - czyli powrót wieży Babel część I]]
[[File:Technics hifi systems 1980-81- 01-1.jpg|120px|link=Wieża Hi – Fi - czyli powrót wieży Babel część I]]
</center>

*2020.01.02 [[Kaseta magnetofonowa BT]].
<center>
[[File:BT-IMG_20200102_151620.jpg|180px|link=Kaseta magnetofonowa BT]]
[[File:BT-IMG_20191102_181223.jpg|180px|link=Kaseta magnetofonowa BT]]
</center>

==Artykuły z roku 2019 ([[wydanie 2019]])==
*2019.06.20 [[Technoniezależność]].
<center>
[[File:TNZ-zegar-WP 20190613 005-small.jpg|180px|link=Technoniezależność]]
[[File:R-32 (I197506).jpg|180px|link=Technoniezależność]]
[[File:TNZ-tarcza-WP 20190614 002.jpg|180px|link=Technoniezależność]]
</center>

*2019.05.26 [[Fonica HiFi Audio System 0350]].
<center>
[[File:Fonica0350 Rys.5 Makieta projekt nr 1 (WM).jpg|170px|link=Fonica HiFi Audio System 0350]]
[[File:Fonica0350 Rys.1 Widok obydwu wiez z przodu.jpg|200px|link=Fonica HiFi Audio System 0350]]
[[File:Fonica0350 Rys.6 Grafika projekt nr 2 (WM).jpg|170px|link=Fonica HiFi Audio System 0350]]
</center>

*2019.05.26 [[XII Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]].
<center>
[[File:WP 20190524 014.jpg|180px|link=XII Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]]
[[File:WP 20190524 011.jpg|180px|link=XII Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]]
[[File:WP 20190524 005.jpg|180px|link=XII Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]]
</center>

==Artykuły z roku 2018 ([[wydanie 2018]])==
* Aby zobaczyć [[Wydanie 2018|wszystkie artykuły z roku 2018 kliknij tutaj]].
*2018.12.06 [[Historia innowacyjności w PRL i później, cz. 2]].
<center>
[[File:WP 20180830 003.jpg|70px|link=Historia innowacyjności w PRL i później, cz. 2]]
[[File:WP 20180830 002.jpg|70px|link=Historia innowacyjności w PRL i później, cz. 2]]
</center>
*2018.11.21 [[Wzmacniacze Foniki od początku do samego końca]].
<center>
[[File:Fonica W600 - 001.JPG|230px|link=Wzmacniacze Foniki od początku do samego końca]]
[[File:2801-edit 3 zest.JPG|170px|link=Wzmacniacze Foniki od początku do samego końca]]
[[File:PW-9014 - 01.jpg|190px|link=Wzmacniacze Foniki od początku do samego końca]]
</center>
*2018.11.09 [[Muzeum Unitry w Poznaniu]].
<center>
[[File:DSC00703.JPG|160px|link=Muzeum Unitry w Poznaniu]]
[[File:DSC00689.JPG|150px|link=Muzeum Unitry w Poznaniu]]
</center>
*2018.10.05 [[Polskie gramofony - Suplement 2018]].
<center>
[[File:0-10 f.jpg|160px|link=Polskie gramofony - Suplement 2018]]
[[File:Konsola zm 30 -2.jpg|260px|link=Polskie gramofony - Suplement 2018]]
[[File:Daniel ze wzm. - 04es.jpg|160px|link=Polskie gramofony - Suplement 2018]]
</center>
*2018.09.01 [[Volkswagen wśród mierników, czyli o przyrządach z rodziny LAVO]].
<center>
[[File:L1 1.jpg|120px|link=Volkswagen wśród mierników, czyli o przyrządach z rodziny LAVO]]
[[File:Z3.jpg|140px|link=Volkswagen wśród mierników, czyli o przyrządach z rodziny LAVO]]
[[File:L601 2.jpg|160px|link=Volkswagen wśród mierników, czyli o przyrządach z rodziny LAVO]]
</center>
*2018.09.01 [[Miało być: Osobiste komputery 8-bitowe a sprawa polska. Jest: Historia innowacyjności w PRL (i później)]].
<center>
[[File:Spr2-3.jpg|80px|link=Miało być: Osobiste komputery 8-bitowe a sprawa polska. Jest: Historia innowacyjności w PRL (i później)]]
[[File:Spr1-2.jpg|60px|link=Miało być: Osobiste komputery 8-bitowe a sprawa polska. Jest: Historia innowacyjności w PRL (i później)]]
[[File:Spr1-4.jpg|120px|link=Miało być: Osobiste komputery 8-bitowe a sprawa polska. Jest: Historia innowacyjności w PRL (i później)]]
</center>
*2018.08.06 [[UNITRA i ZURiT w „Przerwanej Dekadzie” część 1 – ZURiT czyli na rynkowo]].
<center>
[[File:Preferencje - tabela - 1.jpg|100px|link=UNITRA i ZURiT w „Przerwanej Dekadzie” część 1 – ZURiT czyli na rynkowo]]
[[File:Struktura napraw-1.jpg|220px|link=UNITRA i ZURiT w „Przerwanej Dekadzie” część 1 – ZURiT czyli na rynkowo]]
[[File:Koszt napraw-1.jpg|120px|link=UNITRA i ZURiT w „Przerwanej Dekadzie” część 1 – ZURiT czyli na rynkowo]]
</center>
*2018.06.29 [[Fonica w świecie CD, czyli „dyskofony” z Łodzi]].
<center>
[[File:Srebrny front - 2.jpg|380px|link=Fonica w świecie CD, czyli „dyskofony” z Łodzi]]
[[File:RYS 6 Tytka-2.jpg|140px|link=Fonica w świecie CD, czyli „dyskofony” z Łodzi]]
[[File:RYS H1 (Robert Komar).JPG|220px|link=Fonica w świecie CD, czyli „dyskofony” z Łodzi]]
</center>
*2018.06.10 [[XI Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]].
<center>
[[File:Seminarium201810.jpg|180px|link=XI Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]]
[[File:Seminarium201829.jpg|180px|link=XI Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]]
[[File:Seminarium201813.jpg|180px|link=XI Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]]
</center>
*2018.05.02 [[Wspomnienie o Chopinie]].
<center>
[[File:Chopin portret-1ccc.jpg|90px|link=Wspomnienie o Chopinie]]
[[File:Radio Chopin - 006 radio.jpg|180px|link=Wspomnienie o Chopinie]]
[[File:Banknot 5000zl 1982-szt2.jpg|180px|link=Wspomnienie o Chopinie]]
</center>
*2018.05.01 [[Analfabetyzm wtórny]].
<center>
[[File:Slack30.jpeg|200px|link=Analfabetyzm wtórny]]
[[File:Kalk-WP 20180429 007.jpg|60px|link=Analfabetyzm wtórny]]
[[File:Biurko1988-89.jpeg|160px|link=Analfabetyzm wtórny]]
</center>
*2018.04.15 [[Miernik wiecznie żywy czyli Meratronik V640 – aneks do artykułu]].
<center>
[[File:V640 HLY 4.jpg|140px|link=Miernik wiecznie żywy czyli Meratronik V640 – aneks do artykułu]]
[[File:Marconi v640 2.jpg|100px|link=Miernik wiecznie żywy czyli Meratronik V640 – aneks do artykułu]]
[[File:V640 ALT1.jpg|180px|link=Miernik wiecznie żywy czyli Meratronik V640 – aneks do artykułu]]
</center>
*2018.03.16 [[Rewolucja optyczna]].
<center>
[[File:BD-WP 20180309 004.jpg|180px|link=Rewolucja optyczna]]
[[File:BD-WP 20180309 009.jpg|180px|link=Rewolucja optyczna]]
[[File:BD-WP 20180309 008.jpg|180px|link=Rewolucja optyczna]]
</center>
*2018.03.13 [[Replay czyli powrót do tematu polskich wkładek gramofonowych]].
<center>
[[File:Igla 002.jpg|180px|link=Replay_czyli_powrót_do_tematu_polskich_wkładek_gramofonowych]]
[[File:Mf100-tenorel-1.jpg|200px|link=Replay_czyli_powrót_do_tematu_polskich_wkładek_gramofonowych]]
[[File:Mf-102.jpg|200px|link=Replay_czyli_powrót_do_tematu_polskich_wkładek_gramofonowych]]
</center>
*2018.02.20 [[Mówimy – ramię, a w domyśle – SME]].
<center>
[[File:SME vibtage family-1s.jpg|200px|link=Mówimy – ramię, a w domyśle – SME]]
[[File:RAMIE TYPU SME -2.JPG|200px|link=Mówimy – ramię, a w domyśle – SME]]
[[File:Mikrus1-s7302373.jpg|180px|link=Mówimy – ramię, a w domyśle – SME]]
</center>
*2018.01.08 [[SN-50|Słuchawki SN-50]].
<center>
[[File:WP 20180105 003.jpg|200px|link=SN-50]]
[[File:WP 20180105 004.jpg|200px|link=SN-50]]
</center>

==Artykuły z roku 2017 ([[wydanie 2017]])==
* Aby zobaczyć [[Wydanie 2017|wszystkie artykuły z roku 2017 kliknij tutaj]].
*2017.12.06 [[Thorens, a sprawa polska]].
<center>
[[File:TD180 ver 1-11.jpg|180px|link=Thorens, a sprawa polska]]
[[File:Thorens-td-290 3.jpg|180px|link=Thorens, a sprawa polska]]
[[File:Wieza 2000 (0)-s.jpg|160px|link=Thorens, a sprawa polska]]
</center>
*2017.11.21 [[Miernik wiecznie żywy czyli Meratronik V640]].
<center>
[[File:V81 -16.jpg|120px|link=Miernik wiecznie żywy czyli Meratronik V640]]
[[File:Conway ul 1.jpg|120px|link=Miernik wiecznie żywy czyli Meratronik V640]]
[[File:Elwro rodzina.jpg|200px|link=Miernik wiecznie żywy czyli Meratronik V640]]
</center>
*2017.11.06 [[Igrzyska czas zacząć]].
<center>
[[File:Rys -1 20170917 141734.jpg|200px|link=Igrzyska czas zacząć]]
[[File:Ariston AS +16dB.JPG|140px|link=Igrzyska czas zacząć]]
[[File:Rys-2 20170917 142211.jpg|200px|link=Igrzyska czas zacząć]]
</center>
*2017.10.18 [[Szreniawa 2017]].
<center>
[[File:DSC09113-famo.JPG|200px|link=Szreniawa 2017]]
[[File:DSC09160.JPG|200px|link=Szreniawa 2017]]
[[File:DSC09097.JPG|200px|link=Szreniawa 2017]]
</center>
*2017.09.13 [[Dwucylindrowa maszyna parowa]].
<center>
[[File:Maszyna dwucylindrowa - 6.jpg|200px|link=Dwucylindrowa maszyna parowa]]
[[File:Maszyna dwucylindrowa - 9.jpg|200px|link=Dwucylindrowa maszyna parowa]]
[[File:Dwucylindrowa-023.jpg|200px|link=Dwucylindrowa maszyna parowa]]
</center>
*2017.08.01 [[Stabilizator spokoju mózgu|Stabilizator Spokoju Mózgu, czyli kilka słów o (nie)doskonałościach napędu gramofonowego]].
<center>
[[File:Stabilizator-spokoju-QL10.jpg|200px|link=Nie święci ramiona lepią]]
[[File:Stabilizator-spokoju-SCH BLOK.jpg|200px|link=Nie święci ramiona lepią]]
[[File:Stabilizator-spokoju-AF977.jpg|120px|link=Nie święci ramiona lepią]]
</center>
*2017.07.14 [[Nie święci ramiona lepią]].
<center>
[[File:Komplet nowy.JPG|200px|link=Nie święci ramiona lepią]]
[[File:DSC02038.JPG|200px|link=Nie święci ramiona lepią]]
[[File:DSC02121.JPG|200px|link=Nie święci ramiona lepią]]
</center>
*2017.06.08 [[Temperatura pracy modeli silników Stirlinga]].
<center>
[[File:Technique pl-term03.jpeg|360px|link=Temperatura pracy modeli silników Stirlinga]]
[[File:Technique pl-term15.jpeg|360px|link=Temperatura pracy modeli silników Stirlinga]]
</center>
*2017.06.05 [[X Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]].
<center>
[[File:WP 20170602 024.jpg|200px|link=X Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]]
[[File:WP 20170602 016.jpg|200px|link=X Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]]
[[File:WP 20170602 019.jpg|200px|link=X Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]]
</center>
*2017.04.13 [[A jednak się kręci - czyli kilka uwag o napędach gramofonowych]].
<center>
[[File:Dragon-1 small.jpg|75px|link=A jednak się kręci - czyli kilka uwag o napędach gramofonowych]]
[[File:Nakamichi dragon wybor 03-small.jpg|130px|link=A jednak się kręci - czyli kilka uwag o napędach gramofonowych]]
[[File:Flutter.-1jpg.jpg|115px|link=A jednak się kręci - czyli kilka uwag o napędach gramofonowych]]
</center>
*2017.03.14 [[Inny przykład druku 3D]].
<center>
[[File:Rms475a-WP 20140606 020.jpg|200px|link=Inny przykład druku 3D]]
[[File:Kolo-ZRK-475a.jpeg|115px|link=Inny przykład druku 3D]]
[[File:WP 20170314 006-475a.jpg|115px|link=Inny przykład druku 3D]]
</center>
*2017.01.17 [[Fonica w krainie papieru]].
<center>
[[File:Yeti-01.jpg|200px|link=Fonica_w_krainie_papieru]]
[[File:GS 630---.jpg|200px|link=Fonica_w_krainie_papieru]]
[[File:Daniel deck-1.jpg|200px|link=Fonica_w_krainie_papieru]]
</center>

==Najciekawsze artykuły z roku 2016 ([[wydanie 2016]])==
* Aby zobaczyć [[Wydanie 2016|wszystkie artykuły z roku 2016 kliknij tutaj]].
*2016.12.15 [[Twórcy gramofonów - próba otwarcia tematu]].
<center>
[[File:David gammon.jpg|100px|link=Twórcy gramofonów - próba otwarcia tematu]]
[[File:John-19771.jpg|140px|link=Twórcy gramofonów - próba otwarcia tematu]]
[[File:Kuzma.jpg|80px|link=Twórcy gramofonów - próba otwarcia tematu]]
</center>
*2016.12.01 [[Pierwsze laptopy]].
<center>
[[File:Tosh T1000LE 2016-11-22 12-36-35.jpg|200px|link=Pierwsze laptopy]]
[[File:Tosh T1200 2016-11-10 15-23-08.jpg|150px|link=Pierwsze laptopy]]
[[File:Tosh T1000 2016-11-13 12-34-57.jpg|200px|link=Pierwsze laptopy]]
</center>
*2016.11.02 [[Gramofony na eksport - kierunek wschód (2016)]].
<center>
[[File:Wega002s3.jpg|200px|link=Gramofony na eksport - kierunek wschód (2016)]]
[[File:Wega109 23.jpg|160px|link=Gramofony na eksport - kierunek wschód (2016)]]
[[File:Estonia 109 .jpg|190px|link=Gramofony na eksport - kierunek wschód (2016)]]
</center>
*2016.10.01 [[Ramiona gramofonowe część VI - ramiona inne niż wszystkie]].
<center>
[[File:Transcriptor18.jpg|200px|link=Ramiona_gramofonowe_część_VI_-_ramiona_inne_niż_wszystkie]]
[[File:1983 Dynavector DV 501obrazekref2.jpg|200px|link=Ramiona_gramofonowe_część_VI_-_ramiona_inne_niż_wszystkie]]
[[File:WT-patent drawing.jpg|200px|link=Ramiona_gramofonowe_część_VI_-_ramiona_inne_niż_wszystkie]]
</center>
*2016.09.02 [[Ramiona gramofonowe przegląd rozwiązań - część V - Podsumowanie rozważań o ramionach przesuwnych.]]
<center>
[[File:All.jpg|200px|link=Ramiona gramofonowe przegląd rozwiązań - część V - Podsumowanie rozważań o ramionach przesuwnych.]]
[[File:Kuzma airbear theory01.jpg|150px|link=Ramiona gramofonowe przegląd rozwiązań - część V - Podsumowanie rozważań o ramionach przesuwnych.]]
[[File:276453875 o.jpg|200px|link=Ramiona gramofonowe przegląd rozwiązań - część V - Podsumowanie rozważań o ramionach przesuwnych.]]
</center>
*2016.08.14 [[CED, LD, CD-i Etc.]] - Technika video: zapis obrazu na płytach.
<center>
[[File:Ced - 03.JPG|100px|link=CED,_LD,_CD-i_Etc.]]
[[File:Sony mdp - 27.JPG|200px|link=CED,_LD,_CD-i_Etc.]]
[[File:Pio-2-mdp -11.JPG|200px|link=CED,_LD,_CD-i_Etc.]]
</center>
*2016.08.14 [[CED]] - pojemnościowy, elektromechaniczny system zapisu obrazu na płytach.
<center>
[[File:Ced - 01.JPG|300px|link=CED]]
[[File:Ced - 05.JPG|300px|link=CED]]
</center>
*2016.08.14 [[LD]] - LaserDisc.
<center>
[[File:Sony mdp - 33.JPG|200px|link=LD]]
[[File:Pio mdp - 08.JPG|200px|link=LD]]
[[File:Sony mdp - 34.JPG|200px|link=LD]]
</center>
*2016.08.14 [[Philips CD-i]] - Philips Compact Disc Interactive.
<center>
[[File:Cdi-WP 20160709 015.jpg|200px|link=Philips_CD-i]]
[[File:Cdi-WP 20160709 003.jpg|200px|link=Philips_CD-i]]
[[File:Cdi-WP 20160709 019.jpg|200px|link=Philips_CD-i]]
</center>
*2016.08.14 [[Video CD]] - Cyfrowy dysk wizyjny MPEG 1.
<center>
[[File:Vcd-2.jpg|200px|link=Video_CD]]
[[File:Vcd-7.jpg|200px|link=Video_CD]]
[[File:Vcd-8.jpg|200px|link=Video_CD]]
</center>
*2016.08.01 [[Ramiona gramofonowe przegląd rozwiązań - część IV]].
<center>
[[File:Optonica - 02.JPG|200px|link=Ramiona gramofonowe przegląd rozwiązań - część IV]]
[[File:Saba - 1-09.JPG|200px|link=Ramiona gramofonowe przegląd rozwiązań - część IV]]
[[File:RatAudio - 10.JPG|200px|link=Ramiona gramofonowe przegląd rozwiązań - część IV]]
</center>
*2016.07.16 [[Czyszczenie winyli - próby i błędy]].
<center>
[[File:Now 2 -1.jpg|200px|link=Czyszczenie winyli - próby i błędy]]
[[File:Tro prze - 4.jpg|200px|link=Czyszczenie winyli - próby i błędy]]
[[File:Nur - po - 3.jpg|200px|link=Czyszczenie winyli - próby i błędy]]
</center>
*2016.07.04 [[Ramiona gramofonowe przegląd rozwiązań - część III - Lata 80-te - Hasło Revox i Bang & Olufsen]].
<center>
[[File:REVOX (4).JPG|200px|link=Ramiona gramofonowe przegląd rozwiązań - część III - Lata 80-te - Hasło Revox i Bang & Olufsen]]
[[File:Reklama Revox-2.jpg|130px|link=Ramiona gramofonowe przegląd rozwiązań - część III - Lata 80-te - Hasło Revox i Bang & Olufsen]]
[[File:Beeoo05.jpg|200px|link=Ramiona gramofonowe przegląd rozwiązań - część III - Lata 80-te - Hasło Revox i Bang & Olufsen]]
</center>
*2016.06.22 [[Ramiona gramofonowe przegląd rozwiązań - część II - Hasło Rabco]].
<center>
[[File:Ortosonic -03.jpg|200px|link=Ramiona gramofonowe przegląd rozwiązań - część II - Hasło Rabco]]
[[File:SL-8_(18).jpg|200px|link=Ramiona gramofonowe przegląd rozwiązań - część II - Hasło Rabco]]
[[File:Marantz_slt_12-18.jpg|200px|link=Ramiona gramofonowe przegląd rozwiązań - część II - Hasło Rabco]]
</center>
*2016.05.11 [[Ramiona gramofonowe przegląd rozwiązań - część I - Garrard ZERO|Ramiona gramofonowe przegląd rozwiązań - część I - Garrard ZERO]].
<center>
[[File:Garrard 100 -00e.JPG|200px|link=Ramiona gramofonowe przegląd rozwiązań - część I - Garrard ZERO]]
[[File:Garrard_100_-00b.JPG|200px|link=Ramiona gramofonowe przegląd rozwiązań - część I - Garrard ZERO]]
[[File:Garrard_92_-81a.JPG|200px|link=Ramiona gramofonowe przegląd rozwiązań - część I - Garrard ZERO]]
</center>
*2016.04.12 [[MDS_4461|Magnetofon MDS 445/446/446x]].
<center>
[[File:MDS446 WP 20160404 004.jpg|200px|link=MDS_4461]]
[[File:MDS446 WP 20160318 004.jpg|200px|link=MDS_4461]]
[[File:MDS446 WP 20160323 005.jpg|200px|link=MDS_4461]]
</center>
*2016.02.07 [[SSL 042|Wieża SSL 042]] - Chyba najbardziej znana wieża produkcji Unitra Diora.
<center>
[[File:ASS042-AS642-WP 20160205 011.jpg|200px|link=SSL 042]]
[[File:ASS042-WP 20160205 014.jpg|200px|link=SSL 042]]
[[File:ASS042-AS642-WP 20160128 002.jpg|200px|link=SSL 042]]
</center>

==Najciekawsze artykuły z roku 2015 ([[wydanie 2015]])==
* Aby zobaczyć [[Wydanie 2015|wszystkie artykuły z roku 2015 kliknij tutaj]].
*2015.08.01 [[Zrobić gramofon 1 - Direct Drive - część 2]] - Jak zrobić gramofon, część 2.
<center>
[[File:Szkic 3.jpg|200px|link=Zrobić gramofon 1 - Direct Drive - część 2]]
[[File:U z gniazdami -4.jpg|200px|link=Zrobić gramofon 1 - Direct Drive - część 2]]
[[File:DSC00917.JPG|200px|link=Zrobić gramofon 1 - Direct Drive - część 2]]
</center>
*2015.07.10 [[Zrobić gramofon 1 - Direct Drive - część 1]] - Jak zrobić gramofon, część 1.
<center>
[[File:Odlew 000856.jpg|200px|link=Zrobić gramofon 1 - Direct Drive - część 1]]
[[File:Zasilacz 2.JPG|140px|link=Zrobić gramofon 1 - Direct Drive - część 1]]
[[File:Goto-1-4.jpg|200px|link=Zrobić gramofon 1 - Direct Drive - część 1]]
</center>
*2015.06.06 [[Polskie gramofony]] - Kolejna aktualizacja artykułu o polskich gramofonach. Tym razem autor opracował nową wersję rozdziału o gramofonach Bambino oraz dodał informacje o tańszych gramofonach, tzn. Arturze, Cyrylu i Emanuelu.
<center>
[[File:Bambino 3-B2.JPG|200px|link=Polskie gramofony]]
[[File:DSC09548.JPG|200px|link=Polskie gramofony]]
[[File:Emanuel-620.JPG|200px|link=Polskie gramofony]]
</center>
* 2015.01.01 [[Polskie magnetofony kasetowe - część 2 - magnetofony przenośne]].
<center>
[[File:M101-magmor-WP 20140503 005.jpg|200px|link=Polskie magnetofony kasetowe - część 2 - magnetofony przenośne]]
[[File:MK125a.JPG|200px|link=Polskie magnetofony kasetowe - część 2 - magnetofony przenośne]]
[[File:Rms475a-WP 20140605 019.jpg|200px|link=Polskie magnetofony kasetowe - część 2 - magnetofony przenośne]]
</center>

==Najciekawsze artykuły z roku 2014 ([[wydanie 2014]])==
* Aby zobaczyć [[Wydanie 2014|wszystkie artykuły z roku 2014 kliknij tutaj]].
* 2014.11.01 [[Polskie magnetofony kasetowe - część 1 - magnetofony stacjonarne]].
<center>
[[File:Marcin-1.jpg|200px|link=Polskie magnetofony kasetowe - część 1 - magnetofony stacjonarne]]
[[File:DSC08719.JPG|200px|link=Polskie magnetofony kasetowe - część 1 - magnetofony stacjonarne]]
[[File:Mds456-WP 20140606 009.jpg|200px|link=Polskie magnetofony kasetowe - część 1 - magnetofony stacjonarne]]
</center>
*2014.09.23 [[Magnetofony kasetowe]]: Działanie, początki i rozwój technologii, ale czy koniec? Kompendium wiedzy o magnetofonach kasetowych.
<center>
[[File:DSC07972.JPG|200px|link=Magnetofony kasetowe]]
[[File:WP_20140807_003-kasety.jpg|200px|link=Magnetofony kasetowe]]
[[File:DSC07882b.JPG|200px|link=Magnetofony kasetowe]]
</center>
* 2014.06.03 [[Polskie magnetofony szpulowe]]: ''Idąc za ciosem'' "[[Polskie gramofony|Polskich gramofonów]]" tym razem staramy się przybliżyć tematykę krajowych magnetofonów szpulowych.
<center>
[[File:S7300532.JPG|200px|link=Polskie magnetofony szpulowe]]
[[File:S7300579.JPG|200px|link=Polskie magnetofony szpulowe]]
[[File:S7300932.JPG|200px|link=Polskie magnetofony szpulowe]]
</center>

==Archiwum==
* Zapraszamy również do [[Specjalna:Kategorie|działów tematycznych]] i archiwum:
** [[Wydanie 2025|Bieżące wydanie 2025]],
** [[Wydanie 2024|Archiwalne wydanie z roku 2024]],
** [[Wydanie 2023|Archiwalne wydanie z roku 2023]],
** [[Wydanie 2022|Archiwalne wydanie z roku 2022]],
** [[Wydanie 2021|Archiwalne wydanie z roku 2021]],
** [[Wydanie 2020|Archiwalne wydanie z roku 2020]],
** [[Wydanie 2019|Archiwalne wydanie z roku 2019]],
** [[Wydanie 2018|Archiwalne wydanie z roku 2018]],
** [[Wydanie 2017|Archiwalne wydanie z roku 2017]],
** [[Wydanie 2016|Archiwalne wydanie z roku 2016]],
** [[Wydanie 2015|Archiwalne wydanie z roku 2015]],
** [[Wydanie 2014|Archiwalne wydanie z roku 2014]],
** [[Wydanie 2013|Archiwalne wydanie z roku 2013]],
** [[Wydanie 2012|Archiwalne wydanie z roku 2012]].

== Ciekawe wątki z forum ==
* [//www.technique.pl/phpBB2/viewtopic.php?t=233 Pompa parowa dwucylindrowa] [[File:duplex3-szaroleta.jpg|75px|link=http://www.technique.pl/phpBB2/viewtopic.php?t=233]]
* [//www.technique.pl/phpBB2/viewtopic.php?t=179 Przekrój maszyny parowej jako model działający] [[File:t_dscn2478_157-zbeep.jpg|75px|link=http://www.technique.pl/phpBB2/viewtopic.php?t=179]]

== Inne ==
* [//www.technique.pl/phpBB2/ Nasze '''forum''']
* [[Technique.pl:O Technique.pl|Manifest techniczny]]: Co i dlaczego?
* [[Pomoc:Spis_treści|Pomoc]]

{| class="wikitable" style="text-align:center" width="100%"
|<small>''Informacja techniczna: Używamy plików cookies. Korzystanie z witryny bez zmiany ustawień Twojej przeglądarki oznacza, że będą one umieszczane w Twoim urządzeniu końcowym. Zawsze możesz zmienić te ustawienia w Twojej przeglądarce internetowej. Szczegóły znajdziesz na stronie [[Technique.pl:Zasady zachowania poufności|Zasady zachowania poufności - polityka prywatności]].''</small>
|}

Strona główna

2026-06-23T13:47:27Z

Szdowk: /* Artykuły z roku 2026 (wydanie 2026) */

[[category:Aktualności]]__NOTOC__
'''Witamy na stronie Technique.pl'''

==Artykuły z roku 2026 ([[wydanie 2026]])==

*2026.06.26 [[(Nie)modny zegar na lampach Nixie]].
<center>
[[File:Zegar nixie sheet1.jpg|130px|link=(Nie)modny zegar na lampach Nixie]]
[[File:Zegar nixie img5.jpg|130px|link=(Nie)modny zegar na lampach Nixie]]
[[File:Zegar nixie img13.jpg|130px|link=(Nie)modny zegar na lampach Nixie]]
</center>

*2026.04.02 [[CAD cz.4: technika 3D - FreeCAD]].
<center>
[[File:Cad4 freecad part design Screenshot 20260401 074613.jpg|130px|link=CAD cz.4: technika 3D - FreeCAD]]
[[File:Cad4 freecad part design kolo 2 Screenshot 20260401 074613.jpg|130px|link=CAD cz.4: technika 3D - FreeCAD]]
[[File:Cad4 freecad techdraw Screenshot 20260401 074613.jpg|130px|link=CAD cz.4: technika 3D - FreeCAD]]
</center>

*2026.03.10 [[Trzask prask i po trzasku]].
<center>
[[File:Moj egz -1.jpg|230px|link=Trzask prask i po trzasku]]
[[File:Dart page -3.jpg|85px|link=Trzask prask i po trzasku]]
[[File:Vinyl-NRS-Box-S3-Black-1024x576 con-1.jpg|230px|link=Trzask prask i po trzasku]]
</center>

*2026.03.01 [[CAD cz.3: technika 3D - BRLCAD]].
<center>
[[File:2 Screenshot 20260221 164437 cyst wire.jpg|115px|link=CAD cz.3: technika 3D - BRLCAD]]
[[File:3 Screenshot 20260221 165152 cyst ray.jpg|115px|link=CAD cz.3: technika 3D - BRLCAD]]
[[File:12 Screenshot 20260227 133916-silnik5.jpg|160px|link=CAD cz.3: technika 3D - BRLCAD]]
</center>

*2026.02.20 [[Tadeusz wajchę przełóż czyli rzecz o zwrotnicach]].
<center>
[[File:Wzorek -1.jpg|180px|link=Tadeusz wajchę przełóż czyli rzecz o zwrotnicach]]
[[File:Kondensatory-1.jpg|110px|link=Tadeusz wajchę przełóż czyli rzecz o zwrotnicach]]
[[File:Rozdział mocy-2.jpg|170px|link=Tadeusz wajchę przełóż czyli rzecz o zwrotnicach]]
</center>

*2026.02.01 [[CAD cz.2: technika 2D]].
<center>
[[File:Megacad 4-2-demo 20260124 102635.jpg|115px|link=CAD cz.2: technika 2D]]
[[File:SimTel-IMG 20260128 201943.jpg|110px|link=CAD cz.2: technika 2D]]
[[File:QCAD-Screenshot 20260128 081947.jpg|140px|link=CAD cz.2: technika 2D]]
</center>

*2026.01.25 [[Olek czyli pół wieku z kolumnami]].
<center>
[[File:Naked sp-00001.jpg|140px|link=Olek czyli pół wieku z kolumnami]]
[[File:Olohorn-1.jpg|120px|link=Olek czyli pół wieku z kolumnami]]
[[File:11 (1).jpg|60px|link=Olek czyli pół wieku z kolumnami]]
</center>

*2026.01.18 [[CAD cz.1: wspomnienia i podstawy]].
<center>
[[File:Vu3d-3.jpg|120px|link=CAD cz.1: wspomnienia i podstawy]]
[[File:Prodesignii.jpg|145px|link=CAD cz.1: wspomnienia i podstawy]]
[[File:Acad1a.jpg|140px|link=CAD cz.1: wspomnienia i podstawy]]
</center>

==Artykuły z roku 2025 ([[wydanie 2025]])==
*2025.12.31 [[Quo Vadis Technique ?]]
<center>
[[File:DSC02819.JPG|120px|link=Quo Vadis Technique ?]]
[[File:Tetra-9.jpg|100px|link=Quo Vadis Technique ?]]
[[File:Acad1.jpg|120px|link=Quo Vadis Technique ?]]
</center>

*2025.12.29 [[Jest różnica czyli coming out]].
<center>
[[File:Yamaha1000- 1 small.jpg|80px|link=Jest różnica czyli coming out]]
[[File:Filtr -1.jpg|120px|link=Jest różnica czyli coming out]]
[[File:Quad 405 clone -1 .jpg|130px|link=Jest różnica czyli coming out]]
</center>

*2025.12.24 [[Powrót do przyszłości czyli HydroPeloponez]].
<center>
[[File:Polo 6732.jpg|120px|link=Powrót do przyszłości czyli HydroPeloponez]]
[[File:Polo 6319-1.jpg|120px|link=Powrót do przyszłości czyli HydroPeloponez]]
[[File:Polo 5808-1.jpg|120px|link=Powrót do przyszłości czyli HydroPeloponez]]
</center>

*2025.12.21 [[Ramiona w wieku emerytalnym - epizod 2 EMI E.P.U. 100]].
<center>
[[File:EMI 100-1.JPG|120px|link=Ramiona w wieku emerytalnym - epizod 2 EMI E.P.U. 100]]
[[File:EMI 100-5.JPG|120px|link=Ramiona w wieku emerytalnym - epizod 2 EMI E.P.U. 100]]
[[File:EMI 100-6.JPG|120px|link=Ramiona w wieku emerytalnym - epizod 2 EMI E.P.U. 100]]
</center>

*2025.12.20 [[Ramiona w wieku emerytalnym - epizod 1 Leak]].
<center>
[[File:Leak- instrukcja - 1.jpg|60px|link=Ramiona w wieku emerytalnym - epizod 1 Leak]]
[[File:Leak 13.JPG|120px|link=Ramiona w wieku emerytalnym - epizod 1 Leak]]
[[File:Leak 4.JPG|120px|link=Ramiona w wieku emerytalnym - epizod 1 Leak]]
</center>

*2025.12.17 [[Królowa ramion Low Mass Infinity Black Widow]].
<center>
[[File:Black Widow - 1b.jpg|60px|link=Królowa ramion Low Mass Infinity Black Widow]]
[[File:Black widow dane-2.jpg|70px|link=Królowa ramion Low Mass Infinity Black Widow]]
[[File:Black Widow - 3.jpg|80px|link=Królowa ramion Low Mass Infinity Black Widow]]
</center>

*2025.12.10 [[Cmapm czyli nienerwowy powrót ramion 2025]].
<center>
[[File:Ram - 002.jpg|60px|link=Cmapm czyli nienerwowy powrót ramion 2025]]
[[File:DSC05814.JPG|120px|link=Cmapm czyli nienerwowy powrót ramion 2025]]
[[File:Sto-2.jpg|100px|link=Cmapm czyli nienerwowy powrót ramion 2025]]
</center>

*2025.12.04 [[Stary Pass czyli w oczekiwaniu na jubileusz]].
<center>
[[File:Tetra-0.jpg|86px|link=Stary Pass czyli w oczekiwaniu na jubileusz]]
[[File:Tetra-9.jpg|100px|link=Stary Pass czyli w oczekiwaniu na jubileusz]]
[[File:Penta - 2.jpg|100px|link=Stary Pass czyli w oczekiwaniu na jubileuszy]]
</center>

*2025.11.30 [[NA TAŚMIE – Wielościeżkowa historia Zakładów Radiowych Kasprzaka Relacja z wystawy]].
<center>
[[File:Wyst -09 20251021 175651-1.jpg|100px|link=NA TAŚMIE – Wielościeżkowa historia Zakładów Radiowych Kasprzaka Relacja z wystawy]]
[[File:Wyst -01 20251021 1.jpg|80px|link=NA TAŚMIE – Wielościeżkowa historia Zakładów Radiowych Kasprzaka Relacja z wystawy]]
[[File:Wyst -04 20251021 175918-1.jpg|120px|link=NA TAŚMIE – Wielościeżkowa historia Zakładów Radiowych Kasprzaka Relacja z wystawy]]
</center>

*2025.11.04 [[Hamownia dla małych silników, cz.3. Wykorzystanie alternatora w charakterze obciążenia. Sterowanie i konstrukcja]].
<center>
[[File:Rys 6a napiecie pradu wzbudzenia.jpg|130px|link=Hamownia dla małych silników, cz.3. Wykorzystanie alternatora w charakterze obciążenia. Sterowanie i konstrukcja]]
[[File:Hamownia hamulec.jpg|80px|link=Hamownia dla małych silników, cz.3. Wykorzystanie alternatora w charakterze obciążenia. Sterowanie i konstrukcja]]
[[File:H2-sprawnosc-alternatora.jpg|130px|link=Hamownia dla małych silników, cz.3. Wykorzystanie alternatora w charakterze obciążenia. Sterowanie i konstrukcja]]
</center>

*2025.10.10 [[Upadek prasy]].
<center>
[[File:1-IMG 20251009 174548.jpg|80px|link=Upadek prasy]]
[[File:2-IMG 20251009 174644.jpg|80px|link=Upadek prasy]]
[[File:4-IMG_20251011_180622.jpg|80px|link=Upadek prasy]]
</center>

==Artykuły z roku 2024 ([[wydanie 2024]])==
*2024.12.29 [[Wybrane fragmenty historii gramofonów firmy Thorens rozdział 1 - Powrót sentymentów]].
<center>
[[File:Refrenc 4.jpg|140px|link=Wybrane fragmenty historii gramofonów firmy Thorens rozdział 1 - Powrót sentymentów]]
[[File:Torref-5 sme.jpg|80px|link=Wybrane fragmenty historii gramofonów firmy Thorens rozdział 1 - Powrót sentymentów]]
[[File:Refrenc 1.jpg|140px|link=Wybrane fragmenty historii gramofonów firmy Thorens rozdział 1 - Powrót sentymentów]]
</center>

*2024.12.12 [[Od paska napędowego do sztucznej inteligencji]].
<center>
[[File:GdZsYYpA2AD39fIh-bis.png|140px|link=Od paska napędowego do sztucznej inteligencji]]
[[File:5jxBFlunqdOQY0QW bis .png|60px|link=Od paska napędowego do sztucznej inteligencji]]
[[File:G3MnFdxXPqKk0sPF.png|180px|link=Od paska napędowego do sztucznej inteligencji]]
</center>

*2024.12.10 [[30 lat później czyli powrót gramofonu Janka]].
<center>
[[File:Gra-Ja-01.jpg|170px|link=30 lat później czyli powrót gramofonu Janka]]
[[File:Gra-Ja-07.jpg|160px|link=30 lat później czyli powrót gramofonu Janka]]
[[File:Gra-Ja-18.jpg|150px|link=30 lat później czyli powrót gramofonu Janka]]
</center>

*2024.11.30 [[Generatory w służbie Narodu - część 1]].
<center>
[[File:Osc.png|120px|link=Generatory w służbie Narodu - część 1]]
[[File:Schemat ideowy.png|200px|link=Generatory w służbie Narodu - część 1]]
[[File:P lm833.png|170px|link=Generatory w służbie Narodu - część 1]]
</center>

*2024.11.26 [[Pol-Audio czyli wzmacniacz za 12 baniek]].
<center>
[[File:Opis - 1small.jpg|120px|link=Pol-Audio czyli wzmacniacz za 12 baniek]]
[[File:Pol-audio-02.jpg|190px|link=Pol-Audio czyli wzmacniacz za 12 baniek]]
[[File:Polaudio 2023 -3s.jpg|120px|link=Pol-Audio czyli wzmacniacz za 12 baniek]]
</center>

*2024.11.14 [[Syriusz B czyli kontynuacja]].
<center>
[[File:Syriusz 2-6a.jpg|139px|link=Syriusz B czyli kontynuacja]]
[[File:Syriusz B prime-2.jpg|190px|link=Syriusz B czyli kontynuacja]]
[[File:Syriusz 2-7.jpg|134px|link=Syriusz B czyli kontynuacja]]
</center>

*2024.10.31 [[Linijka czyli suplemencik]].
<center>
[[File:Old-5.jpg|80px|link=Linijka_czyli_suplemencik]]
[[File:Linijka_-15.jpg|190px|link=Linijka_czyli_suplemencik]]
[[File:Linijka - 1.jpg|70px|link=Linijka_czyli_suplemencik]]
</center>

*2024.04.08 [[Perły z lamusa - niezwykłe zjawiska w Fonomasterze ciąg dalszy]].
<center>
[[File:Naped od gory-2.jpg|190px|link=Perły z lamusa - niezwykłe zjawiska w Fonomasterze ciąg dalszy]]
[[File:Widok od spodu-1.jpg|190px|link=Perły z lamusa - niezwykłe zjawiska w Fonomasterze ciąg dalszy]]
[[File:Naped od gory-0.jpg|190px|link=Perły z lamusa - niezwykłe zjawiska w Fonomasterze ciąg dalszy]]
</center>

*2024.04.01 [[Perły z lamusa - niezwykłe zjawiska w Fonomasterze]].
<center>
[[File:Widok z gory-0a.jpg|129px|link=Perły z lamusa - niezwykłe zjawiska w Fonomasterze]]
[[File:Stroboskop-1.jpg|190px|link=Perły z lamusa - niezwykłe zjawiska w Fonomasterze]]
[[File:Widok ogolny -2 .jpg|190px|link=Perły z lamusa - niezwykłe zjawiska w Fonomasterze]]
</center>

*2024.02.14 [[Drukujemy maszynę parową - pliki]].
<center>
[[File:4 Skrzynia zaworowa.jpg|190px|link=Drukujemy maszynę parową - pliki]]
[[File:3 Tloczysko 3.jpg|220px|link=Drukujemy maszynę parową - pliki]]
[[File:5 Pokrywa skrzyni zaworowej.jpg|110px|link=Drukujemy maszynę parową - pliki]]
</center>

==Artykuły z roku 2023 ([[wydanie 2023]])==
*2023.12.29 [[Drukujemy maszynę parową]].
<center>
[[File:Technique_pl_IMG_20230824_140525.jpg|140px|link=Drukujemy maszynę parową]]
[[File:Technique_pl_Screenshot_20231229_081158.jpg|200px|link=Drukujemy maszynę parową]]
[[File:Technique_pl_IMG_20231127_141546.jpg|140px|link=Drukujemy maszynę parową]]
</center>

*2023.10.09 [[Perły z lamusa czyli nostalgia kontra zdrowy rozsądek]].
<center>
[[File:Zestaw-3.jpg|190px|link=Perły z lamusa czyli nostalgia kontra zdrowy rozsądek]]
[[File:Zestaw-1.jpg|210px|link=Perły z lamusa czyli nostalgia kontra zdrowy rozsądek]]
[[File:W600-7.jpg|260px|link=Perły z lamusa czyli nostalgia kontra zdrowy rozsądek]]
</center>

*2023.09.17 [[Nowy Gramofon Część V Wielki Finał - czyli ostateczne zamkniecie tekstu z roku 2021]].
<center>
[[File:Kwia2021-7.jpg|140px|link=Nowy Gramofon Część V Wielki Finał - czyli ostateczne zamkniecie tekstu z roku 2021]]
[[File:100 5708-re1.jpg|100px|link=Nowy Gramofon Część V Wielki Finał - czyli ostateczne zamkniecie tekstu z roku 2021]]
[[File:100 5714-re1.jpg|140px|link=Nowy Gramofon Część V Wielki Finał - czyli ostateczne zamkniecie tekstu z roku 2021]]
</center>

*2023.09.11 [[Co z tym ramieniem ? ćwiczenia praktyczne]].
<center>
[[File:Head shell-2.jpg|100px|link=Co z tym ramieniem ? ćwiczenia praktyczne]]
[[File:2-12D-1.jpg|240px|link=Co z tym ramieniem ? ćwiczenia praktyczne]]
[[File:Gemini -4.jpg|100px|link=Co z tym ramieniem ? ćwiczenia praktyczne]]
</center>

*2023.08.02 [[Elektronika od Wielkiego Wybuchu]].
<center>
[[File:BAMBINO 2 SCHEMAT.jpg|100px|link=Elektronika od Wielkiego Wybuchu]]
[[File:Rysunek-46b.jpg|150px|link=Elektronika od Wielkiego Wybuchu]]
[[File:Rysunek-40a.jpg|150px|link=Elektronika od Wielkiego Wybuchu]]
</center>

*2023.07.20 [[Co z tym ramieniem ? Dual w DIY czyli ramię specjalnej troski]].
<center>
[[File:607etc-6.jpg|150px|link=Co z tym ramieniem ? Dual w DIY czyli ramię specjalnej troski]]
[[File:Dual 607 617 edit -5b.jpg|130px|link=Co z tym ramieniem ? Dual w DIY czyli ramię specjalnej troski]]
[[File:Dumet-4.jpg|130px|link=Co z tym ramieniem ? Dual w DIY czyli ramię specjalnej troski]]
</center>

*2023.07.18 [[Co z tym ramieniem ? czyli traktat o produkcji sera]].
<center>
[[File:1101 dok-3.jpg|120px|link=Co z tym ramieniem ? czyli traktat o produkcji sera]]
[[File:Test papierosow-2.jpg|190px|link=Co z tym ramieniem ? czyli traktat o produkcji sera]]
[[File:Ser-1.jpg|140px|link=Co z tym ramieniem ? czyli traktat o produkcji sera]]
</center>

*2023.04.23 [[Syriusz A czyli historia gramofonu Janka z Mielca]].
<center>
[[File:Podstawa-1-IMG 20210809 162040.jpg|150px|link=Syriusz A czyli historia gramofonu Janka z Mielca]]
[[File:Widok ogolny -2-IMG 20210809 163151.jpg|160px|link=Syriusz A czyli historia gramofonu Janka z Mielca]]
[[File:Podstawa-3-IMG 20210809 162059.jpg|200px|link=Syriusz A czyli historia gramofonu Janka z Mielca]]
</center>

*2023.04.06 [[Gramofon dla wszystkich czyli akt gramofonowej kapitulacji]].
<center>
[[File:Postument_-1.jpg|200px|link=Gramofon dla wszystkich czyli akt gramofonowej kapitulacji]]
[[File:Ogolny z góry-2.jpg|160px|link=Gramofon dla wszystkich czyli akt gramofonowej kapitulacji]]
[[File:Nóżka-111.jpg|150px|link=Gramofon dla wszystkich czyli akt gramofonowej kapitulacji]]
</center>

*2023.02.28 [[System zdalnego sterowania do magnetofonu Revox A77]].
<center>
[[File:Revoxa77-mod1.jpg|180px|link=System zdalnego sterowania do magnetofonu Revox A77]]
[[File:Revoxa77-sch3.png|250px|link=System zdalnego sterowania do magnetofonu Revox A77]]
[[File:Revoxa77-pilot1.jpg|110px|link=System zdalnego sterowania do magnetofonu Revox A77]]
</center>

*2023.01.29 [[Budapeszt w Warszawie czyli sukces marki Videoton nad Wisłą]].
<center>
[[File:Midimax-3.jpg|110px|link=Budapeszt w Warszawie czyli sukces marki Videoton nad Wisłą]]
[[File:Halka -01.jpg|430px|link=Budapeszt w Warszawie czyli sukces marki Videoton nad Wisłą]]
[[File:ENC-4.jpg|150px|link=Budapeszt w Warszawie czyli sukces marki Videoton nad Wisłą]]
</center>

==Artykuły z roku 2022 ([[wydanie 2022]])==

*2022.12.24 [[Po co komu Winyl? czyli osobisty wstęp do gramofonów]].
<center>
[[File:Pre-02.jpg|180px|link=Po co komu Winyl? czyli osobisty wstęp do gramofonów]]
[[File:Tr200-2.jpg|230px|link=Po co komu Winyl? czyli osobisty wstęp do gramofonów]]
[[File:Pre-08.jpg|150px|link=Po co komu Winyl? czyli osobisty wstęp do gramofonów]]
</center>

*2022.11.19 [[Hamownia dla małych silników, cz.2.]]
<center>
[[File:H2-tabliczka-znamionowa.jpg|130px|link=Hamownia dla małych silników, cz.2.]]
[[File:H2-zdjecie-z-ekranu-oscyloskopu-IMG 20220721 070321.jpg|120px|link=Hamownia dla małych silników, cz.2.]]
[[File:H2-moment-obrotowy-i-moc.jpg|140px|link=Hamownia dla małych silników, cz.2.]]
</center>

*2022.09.23 [[Hamownia dla małych silników, cz.1.]]
<center>
[[File:Hamownia widok ogolny 1.jpg|100px|link=Hamownia dla małych silników, cz.1.]]
[[File:Hamownia stanowisko pomiarowe.jpg|130px|link=Hamownia dla małych silników, cz.1.]]
[[File:Hamownia zdjecie z ekranu.jpg|130px|link=Hamownia dla małych silników, cz.1.]]
</center>

*2022.05.24 [[Termowizja niskobudżetowa]].
<center>
[[File:P2-1652968491337.jpg|100px|link=Termowizja niskobudżetowa]]
[[File:P2-IMG 20220519 160510.jpg|100px|link=Termowizja niskobudżetowa]]
[[File:P22-1653281832408.jpg|100px|link=Termowizja niskobudżetowa]]
</center>

*2022.04.29 [[MK235_2022|Magnetofon MK235]].
<center>
[[File:Mk232p IMG-20211024-WA0000.jpg|135px|link=MK235_2022]]
[[File:C235 1.jpg|100px|link=MK235_2022]]
[[File:Mk235 mk prom.jpg|135px|link=MK235_2022]]
</center>

*2022.03.24 [[Technologie addytywne 2022]].
<center>
[[File:Sprzeglo2.jpg|120px|link=Technologie addytywne 2022]]
[[File:Zasilacz-photo 2022-03-12 13-41-06.jpg|135px|link=Technologie addytywne 2022]]
[[File:Klawisz-IMG 20220305 142123.jpg|135px|link=Technologie addytywne 2022]]
</center>

*2022.02.19 [[Rekonstrukcja zdalnego sterowania]].
<center>
[[File:Wnetrze pilota IMG 20211107 114729.jpg|140px|link=Rekonstrukcja zdalnego sterowania]]
[[File:Schemat-mc14502x.jpg|220px|link=Rekonstrukcja zdalnego sterowania]]
[[File:Frec count-20211201001.jpg|110px|link=Rekonstrukcja zdalnego sterowania]]
</center>

*2022.02.09 [[Goodmans a sprawa polska]].
<center>
[[File:Sko-DSC02680 bok.jpg|150px|link=Goodmans a sprawa polska]]
[[File:Biurko-red-1.jpg|270px|link=Goodmans a sprawa polska]]
[[File:Fonia GK 122.2-page-001.jpg|180px|link=Goodmans a sprawa polska]]
</center>

==Artykuły z roku 2021 ([[wydanie 2021]])==

*2021.05.30 [[Nowy Gramofon - Część IV]].
<center>
[[File:S7300753-re1.jpg|90px|link=Nowy Gramofon - Część IV]]
[[File:Kwia2021-8.jpg|200px|link=Nowy Gramofon - Część IV]]
[[File:100 5718-re1.jpg|180px|link=Nowy Gramofon - Część IV]]
</center>

*2021.05.20 [[Za co kochamy linie transmisyjne II]].
<center>
[[File:GOT-1 - Monitory PRO 9TL.jpg|90px|link=Za co kochamy linie transmisyjne II]]
[[File:ML-TL-3a.jpg|100px|link=Za co kochamy linie transmisyjne II]]
[[File:02 - Monitory PRO 9TL.jpg|100px|link=Za co kochamy linie transmisyjne II]]
</center>

*2021.04.01 [[Nowy Gramofon - Część III]].
<center>
[[File:Kulki-2.JPG|160px|link=Nowy_Gramofon_-_Część_III]]
[[File:Sssilnik-1.JPG|190px|link=Nowy_Gramofon_-_Część_III]]
[[File:Ortofon --3a.JPG|160px|link=Nowy_Gramofon_-_Część_III]]
</center>

*2021.03.13 [[Nowy Gramofon - Część II]].
<center>
[[File:00-zespol podstawy ramienia z ramieniem -1.JPG|160px|link=Nowy_Gramofon_-_Część_II]]
[[File:00 zdezintegrowany z talerzem i silnikiem-1.JPG|160px|link=Nowy_Gramofon_-_Część_II]]
[[File:00 zdezintegrowany z talerzem i silnikiem- 3ramiona-3.JPG|160px|link=Nowy_Gramofon_-_Część_II]]
</center>

*2021.03.13 [[Za co kochamy linie transmisyjne I]].
<center>
[[File:IMF 80 TLS widok -1.jpg|140px|link=Za co kochamy linie transmisyjne I]]
[[File:IMF przekroje -1sm.jpg|140px|link=Za co kochamy linie transmisyjne I]]
[[File:Hi-fi ans - aug 75-1.jpg|140px|link=Za co kochamy linie transmisyjne I]]
</center>

*2021.02.15 [[Nowy Gramofon - Część I]].
<center>
[[File:Trzylistny kwiatek-1.jpg|160px|link=Nowy_Gramofon_-_Część_I]]
[[File:Puszki kwiatka -1.jpg|160px|link=Nowy_Gramofon_-_Część_I]]
[[File:Podstawa zinegrowana pod sme-5.jpg|120px|link=Nowy_Gramofon_-_Część_I]]
</center>

*2021.02.15 [[Klasycy o kompensacji siły poślizgu czyli trochę prawdy o antiskatingu - wersja 2021]].
<center>
[[File:Fig. 01-pl.jpg|100px|link=Klasycy o kompensacji siły poślizgu czyli trochę prawdy o antiskatingu - wersja 2021]]
[[File:Fig. 03pll.jpg|160px|link=Klasycy o kompensacji siły poślizgu czyli trochę prawdy o antiskatingu - wersja 2021]]
[[File:Fig. 11pl.jpg|160px|link=Klasycy o kompensacji siły poślizgu czyli trochę prawdy o antiskatingu - wersja 2021]]
</center>

*2021.01.12 [[Silniki nitinolowe]].
<center>
[[File:WP_20150210_006-nitinol.jpg|80px|link=Silniki nitinolowe]]
[[File:WP 20150210 011-nitinol.jpg|160px|link=Silniki nitinolowe]]
</center>

*2021.01.01 [[Manifest 2021]].
<center>
[[File:Zuraw-WP 20140307 002.jpg|180px|link=Manifest_2021]]
[[File:Cmt831-02-WP 20140910 005.jpg|160px|link=Manifest_2021]]
[[File:Garrard 100 -00b.JPG|120px|link=Manifest_2021]]
</center>

*2021.01.01 [[Nowy Gramofon - Prolog]].
<center>
[[File:Gramofon-kwiatek-001.jpg|140px|link=Nowy_Gramofon_-_Prolog]]
[[File:Jbe 3001 direct drive turntable.jpg|160px|link=Nowy_Gramofon_-_Prolog]]
[[File:Gramofon-kwiatek-002.jpg|160px|link=Nowy_Gramofon_-_Prolog]]
</center>

==Artykuły z roku 2020 ([[wydanie 2020]])==
*2020.03.14 [[Miernik wiecznie żywy czyli Meratronik V640 – aneks nr 2 do artykułu]].
<center>
[[File:Pud13.jpg|180px|link=Miernik wiecznie żywy czyli Meratronik V640 – aneks nr 2 do artykułu]]
[[File:Awp1.jpg|100px|link=Miernik wiecznie żywy czyli Meratronik V640 – aneks nr 2 do artykułu]]
[[File:Pud5.jpg|160px|link=Miernik wiecznie żywy czyli Meratronik V640 – aneks nr 2 do artykułu]]
</center>

*2020.01.28 [[Wieża Hi – Fi - czyli powrót wieży Babel część I]].
<center>
[[File:Preamp- amp- tuner - 1a.jpg|180px|link=Wieża Hi – Fi - czyli powrót wieży Babel część I]]
[[File:Zestaw - prospekt - stro-1.jpg|160px|link=Wieża Hi – Fi - czyli powrót wieży Babel część I]]
[[File:Technics hifi systems 1980-81- 01-1.jpg|120px|link=Wieża Hi – Fi - czyli powrót wieży Babel część I]]
</center>

*2020.01.02 [[Kaseta magnetofonowa BT]].
<center>
[[File:BT-IMG_20200102_151620.jpg|180px|link=Kaseta magnetofonowa BT]]
[[File:BT-IMG_20191102_181223.jpg|180px|link=Kaseta magnetofonowa BT]]
</center>

==Artykuły z roku 2019 ([[wydanie 2019]])==
*2019.06.20 [[Technoniezależność]].
<center>
[[File:TNZ-zegar-WP 20190613 005-small.jpg|180px|link=Technoniezależność]]
[[File:R-32 (I197506).jpg|180px|link=Technoniezależność]]
[[File:TNZ-tarcza-WP 20190614 002.jpg|180px|link=Technoniezależność]]
</center>

*2019.05.26 [[Fonica HiFi Audio System 0350]].
<center>
[[File:Fonica0350 Rys.5 Makieta projekt nr 1 (WM).jpg|170px|link=Fonica HiFi Audio System 0350]]
[[File:Fonica0350 Rys.1 Widok obydwu wiez z przodu.jpg|200px|link=Fonica HiFi Audio System 0350]]
[[File:Fonica0350 Rys.6 Grafika projekt nr 2 (WM).jpg|170px|link=Fonica HiFi Audio System 0350]]
</center>

*2019.05.26 [[XII Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]].
<center>
[[File:WP 20190524 014.jpg|180px|link=XII Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]]
[[File:WP 20190524 011.jpg|180px|link=XII Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]]
[[File:WP 20190524 005.jpg|180px|link=XII Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]]
</center>

==Artykuły z roku 2018 ([[wydanie 2018]])==
* Aby zobaczyć [[Wydanie 2018|wszystkie artykuły z roku 2018 kliknij tutaj]].
*2018.12.06 [[Historia innowacyjności w PRL i później, cz. 2]].
<center>
[[File:WP 20180830 003.jpg|70px|link=Historia innowacyjności w PRL i później, cz. 2]]
[[File:WP 20180830 002.jpg|70px|link=Historia innowacyjności w PRL i później, cz. 2]]
</center>
*2018.11.21 [[Wzmacniacze Foniki od początku do samego końca]].
<center>
[[File:Fonica W600 - 001.JPG|230px|link=Wzmacniacze Foniki od początku do samego końca]]
[[File:2801-edit 3 zest.JPG|170px|link=Wzmacniacze Foniki od początku do samego końca]]
[[File:PW-9014 - 01.jpg|190px|link=Wzmacniacze Foniki od początku do samego końca]]
</center>
*2018.11.09 [[Muzeum Unitry w Poznaniu]].
<center>
[[File:DSC00703.JPG|160px|link=Muzeum Unitry w Poznaniu]]
[[File:DSC00689.JPG|150px|link=Muzeum Unitry w Poznaniu]]
</center>
*2018.10.05 [[Polskie gramofony - Suplement 2018]].
<center>
[[File:0-10 f.jpg|160px|link=Polskie gramofony - Suplement 2018]]
[[File:Konsola zm 30 -2.jpg|260px|link=Polskie gramofony - Suplement 2018]]
[[File:Daniel ze wzm. - 04es.jpg|160px|link=Polskie gramofony - Suplement 2018]]
</center>
*2018.09.01 [[Volkswagen wśród mierników, czyli o przyrządach z rodziny LAVO]].
<center>
[[File:L1 1.jpg|120px|link=Volkswagen wśród mierników, czyli o przyrządach z rodziny LAVO]]
[[File:Z3.jpg|140px|link=Volkswagen wśród mierników, czyli o przyrządach z rodziny LAVO]]
[[File:L601 2.jpg|160px|link=Volkswagen wśród mierników, czyli o przyrządach z rodziny LAVO]]
</center>
*2018.09.01 [[Miało być: Osobiste komputery 8-bitowe a sprawa polska. Jest: Historia innowacyjności w PRL (i później)]].
<center>
[[File:Spr2-3.jpg|80px|link=Miało być: Osobiste komputery 8-bitowe a sprawa polska. Jest: Historia innowacyjności w PRL (i później)]]
[[File:Spr1-2.jpg|60px|link=Miało być: Osobiste komputery 8-bitowe a sprawa polska. Jest: Historia innowacyjności w PRL (i później)]]
[[File:Spr1-4.jpg|120px|link=Miało być: Osobiste komputery 8-bitowe a sprawa polska. Jest: Historia innowacyjności w PRL (i później)]]
</center>
*2018.08.06 [[UNITRA i ZURiT w „Przerwanej Dekadzie” część 1 – ZURiT czyli na rynkowo]].
<center>
[[File:Preferencje - tabela - 1.jpg|100px|link=UNITRA i ZURiT w „Przerwanej Dekadzie” część 1 – ZURiT czyli na rynkowo]]
[[File:Struktura napraw-1.jpg|220px|link=UNITRA i ZURiT w „Przerwanej Dekadzie” część 1 – ZURiT czyli na rynkowo]]
[[File:Koszt napraw-1.jpg|120px|link=UNITRA i ZURiT w „Przerwanej Dekadzie” część 1 – ZURiT czyli na rynkowo]]
</center>
*2018.06.29 [[Fonica w świecie CD, czyli „dyskofony” z Łodzi]].
<center>
[[File:Srebrny front - 2.jpg|380px|link=Fonica w świecie CD, czyli „dyskofony” z Łodzi]]
[[File:RYS 6 Tytka-2.jpg|140px|link=Fonica w świecie CD, czyli „dyskofony” z Łodzi]]
[[File:RYS H1 (Robert Komar).JPG|220px|link=Fonica w świecie CD, czyli „dyskofony” z Łodzi]]
</center>
*2018.06.10 [[XI Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]].
<center>
[[File:Seminarium201810.jpg|180px|link=XI Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]]
[[File:Seminarium201829.jpg|180px|link=XI Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]]
[[File:Seminarium201813.jpg|180px|link=XI Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]]
</center>
*2018.05.02 [[Wspomnienie o Chopinie]].
<center>
[[File:Chopin portret-1ccc.jpg|90px|link=Wspomnienie o Chopinie]]
[[File:Radio Chopin - 006 radio.jpg|180px|link=Wspomnienie o Chopinie]]
[[File:Banknot 5000zl 1982-szt2.jpg|180px|link=Wspomnienie o Chopinie]]
</center>
*2018.05.01 [[Analfabetyzm wtórny]].
<center>
[[File:Slack30.jpeg|200px|link=Analfabetyzm wtórny]]
[[File:Kalk-WP 20180429 007.jpg|60px|link=Analfabetyzm wtórny]]
[[File:Biurko1988-89.jpeg|160px|link=Analfabetyzm wtórny]]
</center>
*2018.04.15 [[Miernik wiecznie żywy czyli Meratronik V640 – aneks do artykułu]].
<center>
[[File:V640 HLY 4.jpg|140px|link=Miernik wiecznie żywy czyli Meratronik V640 – aneks do artykułu]]
[[File:Marconi v640 2.jpg|100px|link=Miernik wiecznie żywy czyli Meratronik V640 – aneks do artykułu]]
[[File:V640 ALT1.jpg|180px|link=Miernik wiecznie żywy czyli Meratronik V640 – aneks do artykułu]]
</center>
*2018.03.16 [[Rewolucja optyczna]].
<center>
[[File:BD-WP 20180309 004.jpg|180px|link=Rewolucja optyczna]]
[[File:BD-WP 20180309 009.jpg|180px|link=Rewolucja optyczna]]
[[File:BD-WP 20180309 008.jpg|180px|link=Rewolucja optyczna]]
</center>
*2018.03.13 [[Replay czyli powrót do tematu polskich wkładek gramofonowych]].
<center>
[[File:Igla 002.jpg|180px|link=Replay_czyli_powrót_do_tematu_polskich_wkładek_gramofonowych]]
[[File:Mf100-tenorel-1.jpg|200px|link=Replay_czyli_powrót_do_tematu_polskich_wkładek_gramofonowych]]
[[File:Mf-102.jpg|200px|link=Replay_czyli_powrót_do_tematu_polskich_wkładek_gramofonowych]]
</center>
*2018.02.20 [[Mówimy – ramię, a w domyśle – SME]].
<center>
[[File:SME vibtage family-1s.jpg|200px|link=Mówimy – ramię, a w domyśle – SME]]
[[File:RAMIE TYPU SME -2.JPG|200px|link=Mówimy – ramię, a w domyśle – SME]]
[[File:Mikrus1-s7302373.jpg|180px|link=Mówimy – ramię, a w domyśle – SME]]
</center>
*2018.01.08 [[SN-50|Słuchawki SN-50]].
<center>
[[File:WP 20180105 003.jpg|200px|link=SN-50]]
[[File:WP 20180105 004.jpg|200px|link=SN-50]]
</center>

==Artykuły z roku 2017 ([[wydanie 2017]])==
* Aby zobaczyć [[Wydanie 2017|wszystkie artykuły z roku 2017 kliknij tutaj]].
*2017.12.06 [[Thorens, a sprawa polska]].
<center>
[[File:TD180 ver 1-11.jpg|180px|link=Thorens, a sprawa polska]]
[[File:Thorens-td-290 3.jpg|180px|link=Thorens, a sprawa polska]]
[[File:Wieza 2000 (0)-s.jpg|160px|link=Thorens, a sprawa polska]]
</center>
*2017.11.21 [[Miernik wiecznie żywy czyli Meratronik V640]].
<center>
[[File:V81 -16.jpg|120px|link=Miernik wiecznie żywy czyli Meratronik V640]]
[[File:Conway ul 1.jpg|120px|link=Miernik wiecznie żywy czyli Meratronik V640]]
[[File:Elwro rodzina.jpg|200px|link=Miernik wiecznie żywy czyli Meratronik V640]]
</center>
*2017.11.06 [[Igrzyska czas zacząć]].
<center>
[[File:Rys -1 20170917 141734.jpg|200px|link=Igrzyska czas zacząć]]
[[File:Ariston AS +16dB.JPG|140px|link=Igrzyska czas zacząć]]
[[File:Rys-2 20170917 142211.jpg|200px|link=Igrzyska czas zacząć]]
</center>
*2017.10.18 [[Szreniawa 2017]].
<center>
[[File:DSC09113-famo.JPG|200px|link=Szreniawa 2017]]
[[File:DSC09160.JPG|200px|link=Szreniawa 2017]]
[[File:DSC09097.JPG|200px|link=Szreniawa 2017]]
</center>
*2017.09.13 [[Dwucylindrowa maszyna parowa]].
<center>
[[File:Maszyna dwucylindrowa - 6.jpg|200px|link=Dwucylindrowa maszyna parowa]]
[[File:Maszyna dwucylindrowa - 9.jpg|200px|link=Dwucylindrowa maszyna parowa]]
[[File:Dwucylindrowa-023.jpg|200px|link=Dwucylindrowa maszyna parowa]]
</center>
*2017.08.01 [[Stabilizator spokoju mózgu|Stabilizator Spokoju Mózgu, czyli kilka słów o (nie)doskonałościach napędu gramofonowego]].
<center>
[[File:Stabilizator-spokoju-QL10.jpg|200px|link=Nie święci ramiona lepią]]
[[File:Stabilizator-spokoju-SCH BLOK.jpg|200px|link=Nie święci ramiona lepią]]
[[File:Stabilizator-spokoju-AF977.jpg|120px|link=Nie święci ramiona lepią]]
</center>
*2017.07.14 [[Nie święci ramiona lepią]].
<center>
[[File:Komplet nowy.JPG|200px|link=Nie święci ramiona lepią]]
[[File:DSC02038.JPG|200px|link=Nie święci ramiona lepią]]
[[File:DSC02121.JPG|200px|link=Nie święci ramiona lepią]]
</center>
*2017.06.08 [[Temperatura pracy modeli silników Stirlinga]].
<center>
[[File:Technique pl-term03.jpeg|360px|link=Temperatura pracy modeli silników Stirlinga]]
[[File:Technique pl-term15.jpeg|360px|link=Temperatura pracy modeli silników Stirlinga]]
</center>
*2017.06.05 [[X Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]].
<center>
[[File:WP 20170602 024.jpg|200px|link=X Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]]
[[File:WP 20170602 016.jpg|200px|link=X Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]]
[[File:WP 20170602 019.jpg|200px|link=X Ogólnopolskie Sympozjum Historyczny Rozwój Konstrukcji Pojazdów]]
</center>
*2017.04.13 [[A jednak się kręci - czyli kilka uwag o napędach gramofonowych]].
<center>
[[File:Dragon-1 small.jpg|75px|link=A jednak się kręci - czyli kilka uwag o napędach gramofonowych]]
[[File:Nakamichi dragon wybor 03-small.jpg|130px|link=A jednak się kręci - czyli kilka uwag o napędach gramofonowych]]
[[File:Flutter.-1jpg.jpg|115px|link=A jednak się kręci - czyli kilka uwag o napędach gramofonowych]]
</center>
*2017.03.14 [[Inny przykład druku 3D]].
<center>
[[File:Rms475a-WP 20140606 020.jpg|200px|link=Inny przykład druku 3D]]
[[File:Kolo-ZRK-475a.jpeg|115px|link=Inny przykład druku 3D]]
[[File:WP 20170314 006-475a.jpg|115px|link=Inny przykład druku 3D]]
</center>
*2017.01.17 [[Fonica w krainie papieru]].
<center>
[[File:Yeti-01.jpg|200px|link=Fonica_w_krainie_papieru]]
[[File:GS 630---.jpg|200px|link=Fonica_w_krainie_papieru]]
[[File:Daniel deck-1.jpg|200px|link=Fonica_w_krainie_papieru]]
</center>

==Najciekawsze artykuły z roku 2016 ([[wydanie 2016]])==
* Aby zobaczyć [[Wydanie 2016|wszystkie artykuły z roku 2016 kliknij tutaj]].
*2016.12.15 [[Twórcy gramofonów - próba otwarcia tematu]].
<center>
[[File:David gammon.jpg|100px|link=Twórcy gramofonów - próba otwarcia tematu]]
[[File:John-19771.jpg|140px|link=Twórcy gramofonów - próba otwarcia tematu]]
[[File:Kuzma.jpg|80px|link=Twórcy gramofonów - próba otwarcia tematu]]
</center>
*2016.12.01 [[Pierwsze laptopy]].
<center>
[[File:Tosh T1000LE 2016-11-22 12-36-35.jpg|200px|link=Pierwsze laptopy]]
[[File:Tosh T1200 2016-11-10 15-23-08.jpg|150px|link=Pierwsze laptopy]]
[[File:Tosh T1000 2016-11-13 12-34-57.jpg|200px|link=Pierwsze laptopy]]
</center>
*2016.11.02 [[Gramofony na eksport - kierunek wschód (2016)]].
<center>
[[File:Wega002s3.jpg|200px|link=Gramofony na eksport - kierunek wschód (2016)]]
[[File:Wega109 23.jpg|160px|link=Gramofony na eksport - kierunek wschód (2016)]]
[[File:Estonia 109 .jpg|190px|link=Gramofony na eksport - kierunek wschód (2016)]]
</center>
*2016.10.01 [[Ramiona gramofonowe część VI - ramiona inne niż wszystkie]].
<center>
[[File:Transcriptor18.jpg|200px|link=Ramiona_gramofonowe_część_VI_-_ramiona_inne_niż_wszystkie]]
[[File:1983 Dynavector DV 501obrazekref2.jpg|200px|link=Ramiona_gramofonowe_część_VI_-_ramiona_inne_niż_wszystkie]]
[[File:WT-patent drawing.jpg|200px|link=Ramiona_gramofonowe_część_VI_-_ramiona_inne_niż_wszystkie]]
</center>
*2016.09.02 [[Ramiona gramofonowe przegląd rozwiązań - część V - Podsumowanie rozważań o ramionach przesuwnych.]]
<center>
[[File:All.jpg|200px|link=Ramiona gramofonowe przegląd rozwiązań - część V - Podsumowanie rozważań o ramionach przesuwnych.]]
[[File:Kuzma airbear theory01.jpg|150px|link=Ramiona gramofonowe przegląd rozwiązań - część V - Podsumowanie rozważań o ramionach przesuwnych.]]
[[File:276453875 o.jpg|200px|link=Ramiona gramofonowe przegląd rozwiązań - część V - Podsumowanie rozważań o ramionach przesuwnych.]]
</center>
*2016.08.14 [[CED, LD, CD-i Etc.]] - Technika video: zapis obrazu na płytach.
<center>
[[File:Ced - 03.JPG|100px|link=CED,_LD,_CD-i_Etc.]]
[[File:Sony mdp - 27.JPG|200px|link=CED,_LD,_CD-i_Etc.]]
[[File:Pio-2-mdp -11.JPG|200px|link=CED,_LD,_CD-i_Etc.]]
</center>
*2016.08.14 [[CED]] - pojemnościowy, elektromechaniczny system zapisu obrazu na płytach.
<center>
[[File:Ced - 01.JPG|300px|link=CED]]
[[File:Ced - 05.JPG|300px|link=CED]]
</center>
*2016.08.14 [[LD]] - LaserDisc.
<center>
[[File:Sony mdp - 33.JPG|200px|link=LD]]
[[File:Pio mdp - 08.JPG|200px|link=LD]]
[[File:Sony mdp - 34.JPG|200px|link=LD]]
</center>
*2016.08.14 [[Philips CD-i]] - Philips Compact Disc Interactive.
<center>
[[File:Cdi-WP 20160709 015.jpg|200px|link=Philips_CD-i]]
[[File:Cdi-WP 20160709 003.jpg|200px|link=Philips_CD-i]]
[[File:Cdi-WP 20160709 019.jpg|200px|link=Philips_CD-i]]
</center>
*2016.08.14 [[Video CD]] - Cyfrowy dysk wizyjny MPEG 1.
<center>
[[File:Vcd-2.jpg|200px|link=Video_CD]]
[[File:Vcd-7.jpg|200px|link=Video_CD]]
[[File:Vcd-8.jpg|200px|link=Video_CD]]
</center>
*2016.08.01 [[Ramiona gramofonowe przegląd rozwiązań - część IV]].
<center>
[[File:Optonica - 02.JPG|200px|link=Ramiona gramofonowe przegląd rozwiązań - część IV]]
[[File:Saba - 1-09.JPG|200px|link=Ramiona gramofonowe przegląd rozwiązań - część IV]]
[[File:RatAudio - 10.JPG|200px|link=Ramiona gramofonowe przegląd rozwiązań - część IV]]
</center>
*2016.07.16 [[Czyszczenie winyli - próby i błędy]].
<center>
[[File:Now 2 -1.jpg|200px|link=Czyszczenie winyli - próby i błędy]]
[[File:Tro prze - 4.jpg|200px|link=Czyszczenie winyli - próby i błędy]]
[[File:Nur - po - 3.jpg|200px|link=Czyszczenie winyli - próby i błędy]]
</center>
*2016.07.04 [[Ramiona gramofonowe przegląd rozwiązań - część III - Lata 80-te - Hasło Revox i Bang & Olufsen]].
<center>
[[File:REVOX (4).JPG|200px|link=Ramiona gramofonowe przegląd rozwiązań - część III - Lata 80-te - Hasło Revox i Bang & Olufsen]]
[[File:Reklama Revox-2.jpg|130px|link=Ramiona gramofonowe przegląd rozwiązań - część III - Lata 80-te - Hasło Revox i Bang & Olufsen]]
[[File:Beeoo05.jpg|200px|link=Ramiona gramofonowe przegląd rozwiązań - część III - Lata 80-te - Hasło Revox i Bang & Olufsen]]
</center>
*2016.06.22 [[Ramiona gramofonowe przegląd rozwiązań - część II - Hasło Rabco]].
<center>
[[File:Ortosonic -03.jpg|200px|link=Ramiona gramofonowe przegląd rozwiązań - część II - Hasło Rabco]]
[[File:SL-8_(18).jpg|200px|link=Ramiona gramofonowe przegląd rozwiązań - część II - Hasło Rabco]]
[[File:Marantz_slt_12-18.jpg|200px|link=Ramiona gramofonowe przegląd rozwiązań - część II - Hasło Rabco]]
</center>
*2016.05.11 [[Ramiona gramofonowe przegląd rozwiązań - część I - Garrard ZERO|Ramiona gramofonowe przegląd rozwiązań - część I - Garrard ZERO]].
<center>
[[File:Garrard 100 -00e.JPG|200px|link=Ramiona gramofonowe przegląd rozwiązań - część I - Garrard ZERO]]
[[File:Garrard_100_-00b.JPG|200px|link=Ramiona gramofonowe przegląd rozwiązań - część I - Garrard ZERO]]
[[File:Garrard_92_-81a.JPG|200px|link=Ramiona gramofonowe przegląd rozwiązań - część I - Garrard ZERO]]
</center>
*2016.04.12 [[MDS_4461|Magnetofon MDS 445/446/446x]].
<center>
[[File:MDS446 WP 20160404 004.jpg|200px|link=MDS_4461]]
[[File:MDS446 WP 20160318 004.jpg|200px|link=MDS_4461]]
[[File:MDS446 WP 20160323 005.jpg|200px|link=MDS_4461]]
</center>
*2016.02.07 [[SSL 042|Wieża SSL 042]] - Chyba najbardziej znana wieża produkcji Unitra Diora.
<center>
[[File:ASS042-AS642-WP 20160205 011.jpg|200px|link=SSL 042]]
[[File:ASS042-WP 20160205 014.jpg|200px|link=SSL 042]]
[[File:ASS042-AS642-WP 20160128 002.jpg|200px|link=SSL 042]]
</center>

==Najciekawsze artykuły z roku 2015 ([[wydanie 2015]])==
* Aby zobaczyć [[Wydanie 2015|wszystkie artykuły z roku 2015 kliknij tutaj]].
*2015.08.01 [[Zrobić gramofon 1 - Direct Drive - część 2]] - Jak zrobić gramofon, część 2.
<center>
[[File:Szkic 3.jpg|200px|link=Zrobić gramofon 1 - Direct Drive - część 2]]
[[File:U z gniazdami -4.jpg|200px|link=Zrobić gramofon 1 - Direct Drive - część 2]]
[[File:DSC00917.JPG|200px|link=Zrobić gramofon 1 - Direct Drive - część 2]]
</center>
*2015.07.10 [[Zrobić gramofon 1 - Direct Drive - część 1]] - Jak zrobić gramofon, część 1.
<center>
[[File:Odlew 000856.jpg|200px|link=Zrobić gramofon 1 - Direct Drive - część 1]]
[[File:Zasilacz 2.JPG|140px|link=Zrobić gramofon 1 - Direct Drive - część 1]]
[[File:Goto-1-4.jpg|200px|link=Zrobić gramofon 1 - Direct Drive - część 1]]
</center>
*2015.06.06 [[Polskie gramofony]] - Kolejna aktualizacja artykułu o polskich gramofonach. Tym razem autor opracował nową wersję rozdziału o gramofonach Bambino oraz dodał informacje o tańszych gramofonach, tzn. Arturze, Cyrylu i Emanuelu.
<center>
[[File:Bambino 3-B2.JPG|200px|link=Polskie gramofony]]
[[File:DSC09548.JPG|200px|link=Polskie gramofony]]
[[File:Emanuel-620.JPG|200px|link=Polskie gramofony]]
</center>
* 2015.01.01 [[Polskie magnetofony kasetowe - część 2 - magnetofony przenośne]].
<center>
[[File:M101-magmor-WP 20140503 005.jpg|200px|link=Polskie magnetofony kasetowe - część 2 - magnetofony przenośne]]
[[File:MK125a.JPG|200px|link=Polskie magnetofony kasetowe - część 2 - magnetofony przenośne]]
[[File:Rms475a-WP 20140605 019.jpg|200px|link=Polskie magnetofony kasetowe - część 2 - magnetofony przenośne]]
</center>

==Najciekawsze artykuły z roku 2014 ([[wydanie 2014]])==
* Aby zobaczyć [[Wydanie 2014|wszystkie artykuły z roku 2014 kliknij tutaj]].
* 2014.11.01 [[Polskie magnetofony kasetowe - część 1 - magnetofony stacjonarne]].
<center>
[[File:Marcin-1.jpg|200px|link=Polskie magnetofony kasetowe - część 1 - magnetofony stacjonarne]]
[[File:DSC08719.JPG|200px|link=Polskie magnetofony kasetowe - część 1 - magnetofony stacjonarne]]
[[File:Mds456-WP 20140606 009.jpg|200px|link=Polskie magnetofony kasetowe - część 1 - magnetofony stacjonarne]]
</center>
*2014.09.23 [[Magnetofony kasetowe]]: Działanie, początki i rozwój technologii, ale czy koniec? Kompendium wiedzy o magnetofonach kasetowych.
<center>
[[File:DSC07972.JPG|200px|link=Magnetofony kasetowe]]
[[File:WP_20140807_003-kasety.jpg|200px|link=Magnetofony kasetowe]]
[[File:DSC07882b.JPG|200px|link=Magnetofony kasetowe]]
</center>
* 2014.06.03 [[Polskie magnetofony szpulowe]]: ''Idąc za ciosem'' "[[Polskie gramofony|Polskich gramofonów]]" tym razem staramy się przybliżyć tematykę krajowych magnetofonów szpulowych.
<center>
[[File:S7300532.JPG|200px|link=Polskie magnetofony szpulowe]]
[[File:S7300579.JPG|200px|link=Polskie magnetofony szpulowe]]
[[File:S7300932.JPG|200px|link=Polskie magnetofony szpulowe]]
</center>

==Archiwum==
* Zapraszamy również do [[Specjalna:Kategorie|działów tematycznych]] i archiwum:
** [[Wydanie 2025|Bieżące wydanie 2025]],
** [[Wydanie 2024|Archiwalne wydanie z roku 2024]],
** [[Wydanie 2023|Archiwalne wydanie z roku 2023]],
** [[Wydanie 2022|Archiwalne wydanie z roku 2022]],
** [[Wydanie 2021|Archiwalne wydanie z roku 2021]],
** [[Wydanie 2020|Archiwalne wydanie z roku 2020]],
** [[Wydanie 2019|Archiwalne wydanie z roku 2019]],
** [[Wydanie 2018|Archiwalne wydanie z roku 2018]],
** [[Wydanie 2017|Archiwalne wydanie z roku 2017]],
** [[Wydanie 2016|Archiwalne wydanie z roku 2016]],
** [[Wydanie 2015|Archiwalne wydanie z roku 2015]],
** [[Wydanie 2014|Archiwalne wydanie z roku 2014]],
** [[Wydanie 2013|Archiwalne wydanie z roku 2013]],
** [[Wydanie 2012|Archiwalne wydanie z roku 2012]].

== Ciekawe wątki z forum ==
* [//www.technique.pl/phpBB2/viewtopic.php?t=233 Pompa parowa dwucylindrowa] [[File:duplex3-szaroleta.jpg|75px|link=http://www.technique.pl/phpBB2/viewtopic.php?t=233]]
* [//www.technique.pl/phpBB2/viewtopic.php?t=179 Przekrój maszyny parowej jako model działający] [[File:t_dscn2478_157-zbeep.jpg|75px|link=http://www.technique.pl/phpBB2/viewtopic.php?t=179]]

== Inne ==
* [//www.technique.pl/phpBB2/ Nasze '''forum''']
* [[Technique.pl:O Technique.pl|Manifest techniczny]]: Co i dlaczego?
* [[Pomoc:Spis_treści|Pomoc]]

{| class="wikitable" style="text-align:center" width="100%"
|<small>''Informacja techniczna: Używamy plików cookies. Korzystanie z witryny bez zmiany ustawień Twojej przeglądarki oznacza, że będą one umieszczane w Twoim urządzeniu końcowym. Zawsze możesz zmienić te ustawienia w Twojej przeglądarce internetowej. Szczegóły znajdziesz na stronie [[Technique.pl:Zasady zachowania poufności|Zasady zachowania poufności - polityka prywatności]].''</small>
|}

Plik:Zegar nixie img12.jpg

2026-06-23T13:38:31Z

Szdowk: Plik przesłany za pomocą MsUpload

Plik przesłany za pomocą MsUpload

Plik:Zegar nixie img14.jpg

2026-06-23T13:38:31Z

Szdowk: Plik przesłany za pomocą MsUpload

Plik przesłany za pomocą MsUpload

Plik:Zegar nixie img15.jpg

2026-06-23T13:38:31Z

Szdowk: Plik przesłany za pomocą MsUpload

Plik przesłany za pomocą MsUpload

Plik:Zegar nixie img10.jpg

2026-06-23T13:32:25Z

Szdowk: Plik przesłany za pomocą MsUpload

Plik przesłany za pomocą MsUpload

Plik:Zegar nixie img11.jpg

2026-06-23T13:32:25Z

Szdowk: Plik przesłany za pomocą MsUpload

Plik przesłany za pomocą MsUpload

(Nie)modny zegar na lampach Nixie

2026-06-23T13:31:56Z

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]]

Plik:Zegar nixie img1.jpg

2026-06-23T13:27:20Z

Szdowk: Plik przesłany za pomocą MsUpload

Plik przesłany za pomocą MsUpload

Plik:Zegar nixie img9.jpg

2026-06-23T13:24:27Z

Szdowk: Plik przesłany za pomocą MsUpload

Plik przesłany za pomocą MsUpload

Plik:Zegar nixie img5.jpg

2026-06-23T13:24:26Z

Szdowk: Plik przesłany za pomocą MsUpload

Plik przesłany za pomocą MsUpload

Plik:Zegar nixie img6.jpg

2026-06-23T13:24:26Z

Szdowk: Plik przesłany za pomocą MsUpload

Plik przesłany za pomocą MsUpload

Plik:Zegar nixie img7.jpg

2026-06-23T13:24:26Z

Szdowk: Plik przesłany za pomocą MsUpload

Plik przesłany za pomocą MsUpload

Plik:Zegar nixie img8.jpg

2026-06-23T13:24:26Z

Szdowk: Plik przesłany za pomocą MsUpload

Plik przesłany za pomocą MsUpload

Plik:Zegar nixie img2.jpg

2026-06-23T13:24:25Z

Szdowk: Plik przesłany za pomocą MsUpload

Plik przesłany za pomocą MsUpload

Plik:Zegar nixie img3.jpg

2026-06-23T13:24:25Z

Szdowk: Plik przesłany za pomocą MsUpload

Plik przesłany za pomocą MsUpload

Plik:Zegar nixie img4.jpg

2026-06-23T13:24:25Z

Szdowk: Plik przesłany za pomocą MsUpload

Plik przesłany za pomocą MsUpload

Plik:Zegar nixie img13.jpg

2026-06-23T13:20:56Z

Szdowk: Plik przesłany za pomocą MsUpload

Plik przesłany za pomocą MsUpload

(Nie)modny zegar na lampach Nixie

2026-06-23T04:54:40Z

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

=(Nie)modny zegar na lampach Nixie=

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.

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.

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.

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]]

(Nie)modny zegar na lampach Nixie

2026-06-21T16:51:18Z

Szdowk:

=(Nie)modny zegar na lampach Nixie=

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.

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.

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.

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
f - 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]]

Plik:Zegar nixie sheet3.jpg

2026-06-21T16:46:14Z

Szdowk: Szdowk przesłał nową wersję Plik:Zegar nixie sheet3.jpg

Plik przesłany za pomocą MsUpload