atarionline.pl Koprocesor (FPU) w Atari Mega STE - Forum Atarum

    Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

    • :
    • :

    Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

      • 1:
         
        CommentAuthorKaz
      • CommentTime3 Jun 2026 15:26 (3 dni temu) zmieniony
       
      Postanowiłem zamontować sobie kooprocesor w Atari Mega STE. Zwany też o koprocesorem arytmetycznym, matematycznym albo FPU od Floating-Point Unit. Po co? Po pierwsze, dlatego że się da. Po drugie, po to, żeby się osobiście przekonać, jaki ma to sens praktyczny. No i postanowiłem się tym doświadczeniem podzielić w tym wątku, może komuś się przyda.

      1. Pierwszy krok to oczywiście wybór i zakup odpowiedniego kooprocesora (FPU) . Wiadomo powszechnie, że do współpracy z Motorolą 68000, w Mega STE taktowaną standardowo 8 lub 16Mhz, przewidziano jedynie kooprocesory Motorola 68881 i Motorola 68882. Ten drugi to ulepszona wersja tego pierwszego. Choć oba chipy są pinowo kompatybilne i mogą współpracować z tymi samymi procesorami, 68882 oferuje wyższą wydajność dzięki usprawnieniom architektury. Ponoć przy tym samym taktowaniu model 68882 jest zazwyczaj o około 10%-50% szybszy niż 68881. A może być taktowany nawet do 50MHz, podczas gdy 68881 do 25MHz (https://en.wikipedia.org/wiki/Motorola_68881).

      Istnieją różne warianty obudowy koprocesora, ale w Mega STE na płycie jest odpowiednia podstawka PLCC-68 (zdjęcie 1) i do niej musi pasować koprocesor, który jest kwadratowy, ze ściętym jednym rogiem (zdjęcie 2). Szyna FPU w Mega STE działa asynchronicznie z częstotliwością 16 MHz. Można więc kupić koprocek oznakowany jako 16 MHz (na przykład MC68882FN16), ale łatwiej dostępne są układy szybsze - 20, 25, 33 lub 40 MHz (na przykład MC68882FN40A). Szybsze koprocesory bez problemu będą działać na 16 MHz, a przy tym - jak twierdzą testujący - mniej się wtedy nagrzewają i pracują stabilniej. Koprocek wchodzi w podstawkę w Mega STE tylko w jeden sposób. Patrząc od przodu komputera, będzie to orientacja odwrócona "do góry nogami". Ścięty róg będzie w prawym dolnym rogu podstawki (zdjęcie 3).

      Samo włożenie kości 68882 do podstawki nie uruchomi koprocesora. Atari do obsługi FPU wymaga logiki sterującej. Do tego służy odpowiednio zaprogramowany dla Mega STE układ GAL, ma małe wcięcie z jednej strony (zdjęcie 4). Dla niego też jest odpowiednia podstawka DIL-20 na płycie głównej (zdjęcie 5). Układ ten dekoduje adresy pamięci (w architekturze 68000 FPU działa jako urządzenie wejścia/wyjścia mapowane w pamięci – emulując standard Atari SFP004). Układ należy włożyć w podstawkę tak, że wcięcie jest po lewej stronie.

      Zdjęcie 1 - miejsce na koprocesor na płycie Atari Mega STE
      Zdjęcie 2 - koprocesor MC68882FN40A
      Zdjęcie 3 - koprocesor włożony do podstawki
      Zdjęcie 4 - układ sterujące GAL
      Zdjęcie 5 - miejsce na układ sterujący koprocesorem
      Zdjęcie 6 - układ sterujące GAL włożony do podstawki

      Najlepiej kupić kompletny zestaw (koprocesor + zaprogramowany GAL), przygotowany specjalnie dla Mega STE. Nie wiem, jak w epoce, ale w 2026 roku okazało się to niezmiernie proste. Takie zestawy są łatwo dostępne w Polsce na OLX czy Allegro w cenie około 100 PLN. Ja w cenie 90 PLN wliczając przesyłkę kupiłem 68882FN40A i odpowiedni dla Mega STE układ GAL (zdjęcie 7,8).

      Zdjęcie 7,8 - komplet

      2. Krok drugi to instalacja kooprocesora i układu GAL. Nie było to trudne, ale proponuję najpierw sprężonym powietrzem profilaktycznie przedmuchać podstawki. A samo wkładanie wykonać ostrożnie. U mnie była jeszcze mała przeszkadzajka po drodze: w miejscu na GAL włożony był opornik (zdjęcie 9), robiąc jakieś mostkowanie (?), ale pozbyłem się go bez problemu. Po montażu powinno to wyglądać tak jak na zdjęciu 10.

      Zdjęcie 9 - przeszkadzajka
      Zdjęcie 10 - gotowe

      3. Krok trzeci to sprawdzenie poprawności montażu: uruchamiamy Mega STE, następnie program SysInfo, GEMBench, FPU-Check lub podobny, który potrafi wykryć koprocesor, i sprawdzamy nim, czy układ poprawnie się zgłasza. U mnie tak było (zdjęcia 6, 7).

      Zdjęcie 6,7 - ekran SysInfo po montażu

      5. Krok czwarty to korzystanie z oprogramowania używającego FPU, ale ponieważ to rozległy temat i dużo czasu zajęło i zajmuje mi kompletowanie takiego softu, to o tym będą w tym wątku następne posty.

      Na razie wnioski instalacyjne. Za niewielką kwotę można do Mega STE kupić gotowy zestaw kooprocesora i układu sterującego, a potem bez trudu i bez żadnych narzędzi go zamontować.


      Zdjęcia:
      • 2:
         
        CommentAuthorPeri Noid
      • CommentTime3 Jun 2026 15:45 (3 dni temu) zmieniony
       
      Skoro FPU działa asynchronicznie to ciekawe, czy dałoby się go przetaktować... Inny kwarc na jego potrzeby czy coś... Ciekawe.
      • 3:
         
        CommentAuthorKaz
      • CommentTime3 Jun 2026 16:17 (3 dni temu) zmieniony
       
      Zgodnie z zapowiedzią, krok czwarty, czyli soft korzystający z FPU na Mega STE. Warto podkreślić, że wykorzystanie koprocesora w TT i Falconie (procki 68030) wygląda inaczej niż na Mega STE (procek 68000), więc nawet jeśli program obsługuje koprocesor TT albo Falcona, to nie będzie to nijak działać z Mega STE. Program musi obsługiwać kooprocek dla serii ST/STE.

      Okazało się, że software dla FPU nie jest tak prosty do znalezienia, jakby się wydawało. Archiwa koncentrują się na grach, demach i najpopularniejszym sofcie użytkowym, a do takich akurat oprogramowanie dla FPU nie należy. Przetrzepałem najpierw różne źródła internetowe i starą prasę o ST w poszukiwaniu wzmianek o programach, które w ogóle wykorzystują FPU. Najlepsza jest pod tym względem książka "International TOS Software Catalog", która wyraźnie wskazuje na takie wykorzystanie w konkretnych programach, ale zawiera tylko programy komercyjne i znane do roku 1992. Szukałem i dalej szukam nie tylko wzmianek, ale też samych plików programów. Jeżeli ktoś chciałby się podzielić plikami czy informacjami, śmiało proszę to robić; dopiszę do zbiorczej listy, a wszyscy miłośnicy i posiadacze Mega STE na tym skorzystają. W następnym kroku zamierzam bowiem przetestować ten software i przygotować zbiorczą paczkę do pobrania.

      W tej chwili prowadzę:
      a) listę programów, które podejrzewane są o korzystanie z FPU dla Mega STE;
      b) listę programów z punktu a), których pliki już zdobyłem;
      c) listę programów z punktu a), których plików poszukuję;
      A o wszystkich zbieram również artykuły, wzmianki, materiały firmowe i reklamowe, itd.

      ad. b) programy, które już mam (alfabetycznie, update:5/6/2026):

      1. Arrow
      2. Chronos 3D
      3. Devpac
      4. DynaCADD
      5. FPU-Check
      6. FPU-Test
      7. Gnu881
      8. HiSoft Basic
      9. Lattice C
      10. LDW Power
      11. Licom
      12. Mark Willams C
      13. Pheonix
      14. POV Raytarcer
      15. Pure C
      16. Rayshade
      17. Satellite Orbital Prediction Program
      18. Turbo C


      ad. c) programy, których poszukuję (alfabetycznie)

      1. APL.68000 Level II
      2. AutoSwitch-OverScan ST
      3. CompoScript
      4. Composers Desktop Project Composer Music Workstation
      5. Genesis The Galactic Toolchest
      6. Metamorphosis 24
      7. MultiTeX
      8. Off-Axis
      9. Prism Render
      10. Prospero C
      11. Prospero Fortran for Atari TT
      12. Prospero Fortran for GEM
      13. Prospero Pascal for GEM
      14. Render for Sculpt
      15. Xearth
      16. Xmame
      17. ZZ-3D
      18. ZZ-Volume


      Jak widać z powyższego, wiele tego nie ma, ale dobre i tyle. Przeważają, co oczywiste, modelery 3D i raytracery, bo tam jest kupa czasochłonnych obliczeń. Do tego języki z bibliotekami do obsługi F-Line. Będzie co testować.
      • 4: CommentAuthorartik-wroc
      • CommentTime4 Jun 2026 14:43 (2 dni temu) zmieniony
       
      Fajny opis "step by step".

      Zawsze kiedy pojawia się temat koprocesora w ST/STE, pojawia się również wniosek, że prawie nic z niego nie korzysta:
      ->link<- https://www.atari.org.pl/forum/viewtopic.php?id=3555
      • 5:
         
        CommentAuthorMq
      • CommentTime4 Jun 2026 14:48 (2 dni temu)
       
      Kiedyś rozważałem zabawę w dołożenie koprocesora do Atari z racji taniości i dostępności. Taniość i dostępność wynika z tego, że to jest kompletnie nieprzydatne i niepotrzebne. Tak wynikało z szybkiej analizy, po prostu nie ma za bardzo softu, który by to wykorzystał, więc nie bardzo miało to sens i odpuściłem. Nie neguję tej zabawy w celach zabawy samej w sobie lub dokumentowania historii, ale generalnie koprocesor w Atari to sztuka dla sztuki.
      • 6:
         
        CommentAuthorPeri Noid
      • CommentTime4 Jun 2026 15:02 (2 dni temu)
       
      Z Amigą - to samo. A1200 ma na płycie miejsce na koproc, którego chyba nikt nigdy nie założył (poza jednostkowymi testerami). Mam wrażenie, że asynchronicznie wykorzystanie FPU przekraczało umiejętności programistów a synchroniczne dawało zbyt małe zyski.
      • 7:
         
        CommentAuthorKaz
      • CommentTime4 Jun 2026 16:03 (2 dni temu) zmieniony
       

      artic-wroc:

      Fajny opis "step by step".


      Dziękuję. To taki opis dla zupełnie zielonych, co elektroniki boją się tykać. Może się podejmą włożyć FPU, bo to banalne.

      artic-wroc:

      Zawsze kiedy pojawia się temat koprocesora w ST/STE, pojawia się również wniosek, że prawie nic z niego nie korzysta:


      Marekp nawet napisał żartobliwie, że tylko SysInfo korzysta :). Na szczęście nie jest to prawdą, bo parę ciekawych softów działa z FPU, choćby pakiet Phoenix (nie mam go jeszcze wpisanego na listę) albo inne modelery 3D i morfery. Taki mi właśnie przyświeca cel, żeby to potwierdzić i zrobić listę. A że są też (ponoć) odpowiednie biblioteki do Basica, C, Pascala i asemblera, to może w przyszłości ktoś pomyśli o koprocku w swoim sofcie. Chciałbym to jakoś wesprzeć, stąd pomysł na sprawdzenie i zachęcenie.
      • 8:
         
        CommentAuthorMq
      • CommentTime4 Jun 2026 17:24 (2 dni temu)
       

      Kaz:

      A że są też (ponoć) odpowiednie biblioteki do Basica, C, Pascala i asemblera, to może w przyszłości ktoś pomyśli o koprocku w swoim sofcie.

      Jestem pewien, że gdyby to było spopularyzowane, to można by wykorzystać i w grach i w demkach. Natomiast w sytuacji gdy praktycznie nikt nie ma koprocka, to jaki programista weźmie to poważnie pod uwagę np. podczas tworzenia gry? Takie trochę kółko zamknięte się robi...
      Ogólnie szkoda że się w epoce nie spopularyzowało to rozwiązanie.
      • 9: CommentAuthorartik-wroc
      • CommentTime4 Jun 2026 17:30 (2 dni temu)
       
      Tu jest ciekawy wątek
      Oprogramowanie zgodne z FPU - forum Atari, Amiga i retro firmy exxos https://share.google/lOpluhHAlYqD701sj
      • 10:
         
        CommentAuthorKaz
      • CommentTime4 Jun 2026 22:08 (2 dni temu)
       

      Mq:

      Jestem pewien, że gdyby to było spopularyzowane, to można by wykorzystać i w grach i w demkach. Natomiast w sytuacji gdy praktycznie nikt nie ma koprocka, to jaki programista weźmie to poważnie pod uwagę np. podczas tworzenia gry?


      No to czas najwyższy, żeby to zmienić. Tak samo było z popularnością różnych rzeczy do małego Atari. Czasy się zmieniają, sprzęty ludzi się nasycają różnymi rozszerzeniami i w końcu okazuje się, że warto pisać soft na jakieś cudo. Tak może być i z koprocami. Trochę ludzi już to ma, bo są tanie. I wciąż są na rynku, choć producent już ich nie produkuje (ten drugi też już nie). Zresztą, jak ktoś nie robi gier dla zarobku, to nie musi się aż tak przejmować popularnością rozszerzenia. Tu demko z prekalkami FPU, ale nie wiem, co to konkretnie znaczy - liczone przed uruchomieniem? Liczone FPU wcześniej, a potem dane użyte w demie?
      • 11:
         
        CommentAuthorKaz
      • CommentTime4 Jun 2026 22:22 (2 dni temu) zmieniony
       

      artic-wroc:

      Tu jest ciekawy wątek. Oprogramowanie zgodne z FPU - forum Atari, Amiga i retro firmy exxos (...)


      No właśnie to są informacje typu groch z kapustą. I jeszcze w formie przypuszczeń i pogłosek :). Tam są pomieszane programy dla koprocków ST/STE z tymi dla TT i Falcona, a one nie są nijak kompatybilne. Koprocki TT i Falcona działają inaczej i iniestety naczej się je programuje, kod wygląda inaczej dla 68000 i 68030. Dlatego listę programów FPU powinno się odrębnie robić dla ST/STE.

      Są też takie, które niby są na Mega STE, ale... jak "LAME Mp3 Encoder" wymagają procka 68020 i 10 MB RAM. Znajdź mi taką Megę :) To są zapewne ustawienia w jakimś MiST czy jakimś emulatorze.

      Z powodu takich wątków postanowiłem zrobić nie tylko listę "kandydatów", ale też osobiście odpalić i potestować każdy program na Mega STE. Żeby to były informacje sprawdzone, a nie "prawdopodobnie prawdziwe".
      • 12: CommentAuthorgregor2
      • CommentTime4 Jun 2026 22:23 (2 dni temu) zmieniony
       
      Jak sie komus chce bawic w archeologie to proponuje poszukac czegos na temat jezyka XPL0 i systemu APEX.

      https://web.archive.org/web/20060211042636/http://www.idcomm.com/personal/lorenblaney/

      XPL0 byl swego czasu bardzo popularnym jezykiem programowania cos miedzy Pascal a C.
      Powstal na AppleII ale pozniej byl przeniesiony na duza liczbe platform glownie 68k , ale i PC , a nawet na komputery home made.
      Na pewno dzialal na Amiga 1000 i 2000 oraz Macintosh, dzisiaj sa dostepne kompilatory dla Raspbbery Pi, Linux, Windows itd..
      Wiem ze kompilator dla AppleII obslugiwal ten koprocesor na karcie dla AppleII, ale tez na karcie z CPU 68020 z nim rozprowadzanej przez autora kompilatora czyli mozliwe ze obsluguje tez go na innych platformach:

      https://wiki.preterhuman.net/MC68020/68881_Coprocessor_Card_for_the_Apple_II

      Wedlug tego byla jakas wersja dla Atari niestety nie podaja ktorego:

      http://retro.hansotten.nl/uploads/files/The%20Story%20Behind%20Apex_XPL0%20and%20the%206502%20Group.pdf

      Ale tutaj jest wymienione Atari ST

      https://archive.org/details/apex-ver-1.0-user-manual/APEX%20Handy%20Disk%201%20Manual/mode/2up

      Tu jest nieco programow niestety nie dla Atari:

      https://web.archive.org/web/20060324153838/http://www.idcomm.com/personal/lorenblaney/oldxpl.txt

      W jezyku XPL0 powstalo wiele programow i powinny byc dostepne kody zrodlowe.
      • 13:
         
        CommentAuthorKaz
      • CommentTime4 Jun 2026 22:44 (2 dni temu) zmieniony
       
      To może w kolejnym kroku za wiele miesięcy, bo - jak widzisz - nie wiemy nawet, który soft dla Atari na 100% korzysta z FPU w Mega STE :)

      A przy okazji, w tym wątku: ->link<- sedno różnicy między używaniem FPU dla 68000 a 68020/30/40:

      The 68020/030 know so-called Line-F instructions. They decode these and immediately know that these are meant to be handled by a FPU. Via a specific protocol the FPU catches these instructions, and calculates the result. It's done that way in TT and Falcon030.
      But 68000 cannot handle Line-F instructions. Atari decided to attach the FPU to the system like any other I/O device: memory mapped i.e. the FPU occupies some registers in the CPU's memory space.


      I dokument (chyba niedokończony) dla programistów: ->link<-

      Załączę go do forum, bo linki potrafią znikać po jakimś czasie:
      • 14:
         
        CommentAuthorCyprian
      • CommentTime4 Jun 2026 23:54 (2 dni temu)
       
      załączam też przykłady w asemblerze użycia FPU do ST
      • 15:
         
        CommentAuthorKaz
      • CommentTime5 Jun 2026 05:10 (2 dni temu)
       
      Dzięki. Na mojej liście to jest jako "Gnu881" w punkcie 7. W dokumentacji jest tam ciekawa uwaga:

      This library CANNOT be used on systems with a real hardware interface between cpu and coprocessor, i.e., STs with a PAK20, a hypercache030 or other 68020/68030 cards with a 68881/68882 on board or the TT. On these boards, the line-f commands have to be used.


      czyli karty turbo do ST oparte na 68020 (PAK20) lub 68030 (Hypercache030) spowodują, że FPU nie będzie obsługiwane jak w ST tylko jak w TT/Falcon. I to trzeba brać pod uwagę, jak ktoś chce mieć procek 020/030/040 w ST/STE, że właściwie traci możliwość korzystania z FPU na płycie.

      I druga ciekawa rzecz:

      We are in urgend need of a standardized floating point interface for ALL Motorola based Ataris. A few months ago, it has been demonstrated in an article published in the c't magazine that a full line-f floating point interface can easily be implemented in any ST, even those, whose TOS abuses line-f.


      Tu jest mowa o emulatorze FPU działającym jak na TT/Falcon, przez LINE-F zamiast jak w ST/STE przez mapowanie w pamięci. Też warto się temu przyjrzeć i sprawdzić, czy naprawdę to działa, bo opinie są podzielone: ->link<-
      • 16:
         
        CommentAuthorKaz
      • CommentTime5 Jun 2026 05:28 (2 dni temu) zmieniony
       
      A to jest biblia dla 68881/2:

      ->link<-

      Wrzuciłem go na nasz serwer, bo plik 15 MB nie załączy się do posta na forum.
      • 17:
         
        CommentAuthorKaz
      • CommentTime5 Jun 2026 05:49 (2 dni temu)
       
      Emulator (ale nie mam pewności czy to ten z magazynu C't 1990/4, raczej nie, ale nie mam tego numeru, więc nie mam jak porównać) jest tu:

      ->link<-

      ----------------------------------------------------------------
      Fpemu v.220717
      Software 68881 emulator for Atari ST/STe/TT/Falcon.
      Supported CPUs: 68000, 68010, 68020, 68030
      ----------------------------------------------------------------
      • 18: CommentAuthorartik-wroc
      • CommentTime5 Jun 2026 07:27 (2 dni temu) zmieniony
       
      Mam ten numer w wersji HTML. Załączam listing i program. Gdyby kogoś interesował sam artykuł, to też mogę dołączyć.

      "Sterownik rezydentny emulujący interfejs koprocesora 68020 na układzie 68000 w ST. Umożliwia to uruchamianie programów zgodnych ze specyfikacjami Motoroli na karcie koprocesora Atari. Takie programy są generowane przez kompilatory Aztec i Turbo C.
      "

      "Po opisaniu sterownika, kilka słów o jego zastosowaniu. Jest to program rezydentny, który najlepiej uruchomić z folderu AUTO podczas rozruchu ST. Zajmuje on wówczas około jednego kilobajta pamięci. Teraz można uruchamiać programy korzystające z instrukcji koprocesora, zgodnie ze specyfikacją Motoroli. Jeśli posiadasz kompilator C Aztec, samo ustawienie opcji `+F8` wystarczy, aby włączyć pełną obsługę koprocesora.

      Zamiast biblioteki matematycznej `m.lib`, należy oczywiście użyć `m8.lib`, która jest na szczęście znacznie krótsza. Dodatkowo można utworzyć cztery zmienne `double` w rejestrach. Nawet w przypadku funkcji trygonometrycznych kompilator bezpośrednio korzysta z instrukcji koprocesora, bez konieczności tworzenia osobnego wywołania podprogramu. Wynikająca z tego poprawa szybkości jest pokazana w tabeli wyników testów porównawczych. Są to dobrze znane testy porównawcze HL [3].

      Kompilator C firmy Digital Research, w nowszej wersji, również nadaje się do programowania koprocesora [4]. Prospero oferuje również kilka kompilatorów, które obsługują układ 68881 za pomocą instrukcji wiersza F [5, 6]. Zasadniczo wszystkie programy napisane dla PAK będą działać również z nowym sterownikiem. Nie mogą one jednak używać instrukcji obsługiwanych przez układ 68020, ale nie przez 68000, takich jak mnożenie 32-bitowe.

      Oto kilka wskazówek dotyczących dostosowania programu w asemblerze do innych asemblerów. Wersja drukowana jest przeznaczona dla asemblera Aztec, który jest dołączony do kompilatora C. Program należy skompilować z opcją `-n`; w przeciwnym razie wystąpią pewne błędy fazowe.

      Dyrektywa `far data` na początku służy do wyłączenia adresowania danych za pomocą rejestru adresowego numer cztery; jest to optymalizacja, którą asembler zazwyczaj wykonuje automatycznie. Należy temu za wszelką cenę zapobiec, ponieważ sterownik FPU jest programem rezydentnym, a rejestr nie będzie zawierał zdefiniowanej wartości po wywołaniu. W przypadku asemblerów, które nie obsługują tej optymalizacji, dyrektywę można po prostu pominąć.

      Co więcej, instrukcje `cseg` i `dseg`, które oznaczają odpowiednio segmenty kodu i danych/stałych, muszą zostać dostosowane do składni własnego asemblera. Instrukcje `bss` na końcu listingu odpowiadają instrukcjom `ds` w segmencie `bss` większości innych asemblerów. Dlatego zamiast `bss oldtrap,4` można napisać `oldtrap ds.l 1` w segmencie danych. (ad)"
      • 19: CommentAuthorartik-wroc
      • CommentTime5 Jun 2026 07:39 (2 dni temu)
       
      Znalazłem też w swoich przepastnych archiwach program dedykowany MegaSTE :) Załączam plik z programem i źródła.

      "Program 68882 musi być umieszczony w folderze AUTO na partycji rozruchowej (C:).

      Ten program umożliwia korzystanie z procesora 68882 w systemie Mega STE z programami skompilowanymi w TURBO C i PURE C. Nie był testowany z programami skompilowanymi w mniej popularnym języku LATTICE C, ale jeśli posiadasz taki program, który nie działa, prosimy o jego przesłanie do nas, abyśmy mogli zaktualizować program 68882."

      "Programy skompilowane w Turbo/PureC nie zezwalają na użycie koprocesora matematycznego Motorola 68882 jako urządzenia peryferyjnego. Uniemożliwia to jego użycie na komputerach wyposażonych w układy 68000/68010, które mogą bezpośrednio adresować koprocesor, a tym samym wymusza użycie mniej wydajnego układu 68881. Program ten przeszukuje zatem plik wykonywalny skompilowany w Turbo/PureC pod kątem wywołań koprocesora 68881 i zapewnia ich zgodność z układem 68882."
      • 20:
         
        CommentAuthorKaz
      • CommentTime6 Jun 2026 12:40 (1 dzień temu) zmieniony
       
      Wielkie dzięki, Arturze. Poczytam, a pliczek dorzucam do testów!