thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing. VIII. Basque Tournament of Atari 2600 Kolejna relacja, wśród otrzymywanych od naszego przyjaciela Egoitza z Kraju Basków. Przezroczysta obudowa dla Atari 800XL Rusza przedsprzedaż wyjątkowej, przezroczystej obudowy do komputera Atari 800XL! RECOIL 6.4.5 RECOIL to przeglądarka retro plików graficznych, obsługująca ponad 550 formatów, dostępna na różnych systemach operacyjnych, z regularnymi aktualizacjami. ABBUC Software 2024 - wyniki Ukazały się wyniki tegorocznego ABBUC Software Competition
Widzę że udało Ci się jednak Tomahawka przekonwertować, jak to zrobiłeś? Pytam bo próbowałem pobawić się z plikiem WAV i dokonać różnych korekt sygnału, jednak to nic nie pomagało, a8cas konwertował to w sposób taki że po konwersji plik nie wczytywał się poprawnie.
Pomyślałem że skoro jednak Atari800 daje radę wczytać to bez problemu bazując na pliku WAV, to poszedłem "po najmniejszej linii oporu" i wykorzystałem kopier ATT/ATT i w ten sposób wygenerowałem wczytujący się plik WAV. Co ciekawe wczytuje go teraz każdy loader, tzn. AAT1 i ATT2 udostępniony przez Ciebie.
ps1) skoro Atari800 używając pliku WAV i loader czy program kopiujący dają radę wczytać ten plik, to znaczy że a8cas.pl ma inne podejście do konwersji lub bazuje na innych parametrach czasowych, nie miałem się czasu dokładnie temu przyjrzeć, ale wychodzi na to że program kopiujący jest jakimś rozwiązaniem w przypadku napotkania "trudniejszych" przypadków.
Nie wiem czy FUJI rozwija jeszcze swoje narzędzie, ale gdyby tak było, to może przyjrzał by się temu plikowi i mógłby dojść do jakichś wniosków pozwalających na poprawienie lub wprowadzenie jakichś zmian do kodu umożliwiających bardziej skuteczne dekodowanie?
Dzięki WIELKIE! Fajnie że podzieliłeś się swoją biblioteką. Ja powoli migruję w stronę KiCad ze swoimi projektami i to że podzieliłeś się biblioteką będzie mocno pomocne :)
Prześledź posty na 24 stronie - bo dodałem łącznie 13 gier,
No tak... znowu uproszczenie z mojej strony... mówiąc o 10 plikach miałem na myśli te dwa posty w których opublikowałeś 2x5 tytułów, te wcześniejsze sprawdzałem również. Oczywiście śmigają aż miło! :) Dzięki!
Dzięki za te wszystkie pliki! Sprawdziłem wszystkie 10 tytułów, praktycznie wszystko działa u mnie bez problemu. Są dwa wyjątki, ale o tym za chwilę. Wspominałeś o ewolucji systemu w czasie. Zgadzam się jak najbardziej z Twoją tezą. Używałem carta do UM (o tego: Unerring Master Super Cartridge)
Właściwie wszystkie pozycje udało się wczytać za pomocą loadera nr 1. Jedyny problem miałem ze ze "Star Rider II", musiałem użyć loadera dostarczonego wcześniej przez Ciebie, tego w postaci plików BOOT, które ładują się kasety w normalu. Żaden z loaderów z carta nie chciał poprawnie wczytać tej gry.
Jeszcze jedna uwaga co do "Rampage", u mnie żaden loader nie wyświetla tytułu gry. Czy u Ciebie jest tak samo?
Jeżeli chodzi o loadery ATT1 i ATT2 z postu 584. Co prawda pliki nazwałeś .XEX ale to są pliki typu BOOT. Wspominałeś że QMEG potrafi je wczytać, ale to tylko dlatego że loader QMEG-a potrafi poprawnie uruchamiać zarówno pliki binarne Atari DOS jak i BOOT.
I teraz drobna uwaga dotycząca plików BOOT. Jest parę programów które dokonują automatycznej konwersji BOOT ---> XEX. Ale można dokonać takiej konwersji niejako własnoręcznie. W załączniku do tego posta odaję archiwum zawierające przykład. Są w nim Twoje loadery ATT1, ATT2 (w wersjach BOOT), te same loadery już w wersji XEX oraz plik boot2xex.xsm (źródło w formacie xasm) które pozwala przekonwertować (z użyciem xasm) większość plików boot na format XEX.
Kod jest prymitywny i wymaga ręcznych poprawek (np. gdyby plik BOOT pokrywał się adresami po którymi domyślnie umieszczany jest plik .xex) ale dodaję źródła właśnie po to aby każdy kto chce się pobawić mógł dokonać ręcznych poprawek w razie potrzeby. Potrzebny będzie XASM w katalogu z programem lub "widziany" w ścieżce systemowej.
Jest też przykładowy plik .bat dokonujący automatycznej konwersji plików att1_loader.boot oraz att2_loader.boot to formatu .XEX, na wyjściu generowane są pliki att1_loader.xex oraz att2_loader.xex. Nie dodawałem plików .sh dla linuxa, bo zakładam że użytkownik Linuxa taki skrypt bashowy napisze od ręki.
No i dzięki za Gauntlet-a, nie sądziłem że ktoś w przeszłości się pokusił o przerobienie tej cało-dyskowej wersji na format turbo AST :) Po grzybowskiej krążyła jakaś wersja przeznaczona dla Turbo 2000 (KSO/F), ale niewiele pamiętam, tzn. nawet nie wiem czy ją posiadam na swoich starych kasetach. Gdybym namierzył oczywiście udostępnię, ale bardzo chętnie przyjrzę się tej wersji którą udostępniłeś.
Sprawdziłem jeszcze Speeder 1400 sygnowany przez Krzysztofa Polaka, wygląda na to że loader do tego systemu to jedno wielkie siedlisko "nielegalnych" instrukcji 6502C. Dziś to się disassembluje o wiele łatwiej niż kiedyś. Jednak i tak jest "zamiąch" ;-) Zastanawiam się nad przepisaniem tego loadera to strawnej postaci jednak na chwilę obecną mam inne rzeczy w kolejce.
Proces ładowania wygląda tak jak na załączonym poniżej filmie, ale uprzedzam to są prawie 4 minuty przeokropnych dźwięków, mogą wszystkie zęby wypaść :P Ten dźwięk jest generowany "sztucznie" przez loader, nie wiem w jakim celu... bo gdyby pozostawiono normalny dźwięk ładowania FSK byłoby to o wiele przyjaźniejsze dla ucha, a ten brum brzmi dla mnie po prostu koszmarnie... uprzedzam oglądacie na własne życzenie ;-)
Co ciekawe zastosowanie tego systemu eliminuje błąd który zawarty jest standardowych procedurach transmisji Atari-OS, związany z obliczaniem prędkości transmisji i wyliczaniem dzielników dla BRG (Baud Rate Generator).
W przypadku Speeder 1400 dane są transmitowane w bardzo długich blokach. Kopier nagrywając program na taśmę generuje przerwy w odpowiednich momentach (np. po segmentach INIT).
Co ciekawe procedura ładująca nie bazuje na procedurach odbioru bajtu z wejścia szeregowego którą wspomaga POKEY, a sama monitoruje stan linii SERIAL_IN i dokonuje jej próbkowania samodzielnie i składa poszczególne odebrane bity sama w ciąg docelowych bajtów.
No właśnie sam nie wiem jak to sklasyfikować, jest taki katalog na serwerze "pigwa" do którego VOY wrzucił wszystkie programy które w jakiś sposób generują pliki w formacie nazwijmy to "rapider", katalog znajduje się tutaj: Turbo Rapider 7500
Przejrzałem to wszystko dość pobieżnie, ale wydaje mi się że prawie wszystkie programy z tego katalogu (prawie, bo speeder1400 to oddzielny temat) należą do tej samej rodziny/generacji turbo. Według tego co zdążyłem zaobserwować to:
Speed Tape
TMax / Turbo Max
Turbo Rapider 2800/4500/7500
To kolejne wcielenia SpeedTape, który powstał z tych wszystkich programów najwcześniej (1988) a jego autorem był niejaki Krzysztof Polak. Próbuję się o nim cokolwiek dowiedzieć, ale ani tutaj ani na forum AtariOnline nikt nie udzielił jeszcze żadnej informacji. Ja to nazwisko kojarzę z programami kopiującymi dla standardowego magnetofonu, takimi jak Ulitima Ratio czy Enigma. Nie wiedziałem że ten człowiek tworzył również oprogramowanie obsługujące systemy Turbo.
Faktem jest że SpeedTape/TurboMax oraz Rapider były silnie związane z Wrocławiem i okolicami. Wszystkie te programy z katalogu są sygnowane przez jakieś firmy z Wrocławia (MoNaMik, AB-Soft, BANFI Soft, PALMA Soft), nie wiem czy autorem wszystkich tych rozwiązań był K.Polak czy też inne wersje oprogramowania bazującego na SpeedTape były jego ewolucją wykonaną przez samego K.Polaka czy też modyfikacje były wykonane przez innych ludzi na podstawie pracy wykonanej przez K.Polaka.
Normalnie wszystkie te turbo z serii Rapider wrzuciłbym do innej kategorii, ale w katalogu jest też "Plaza Copier 1.0", który potrafi obsłużyć systemy Turbo 2000/3000 (Wrocławskie) ale także Rapider 7500, wnioskuję z tego zatem że te systemy koegzystowały na terenie Wrocławia, który jakby nie patrzeć znajduje się na terenie województwa dolnośląskiego.
Rozumiem skąd Twoje pytanie, bo zapewne zastanawiasz się gdzie Turgen umieścić ten rodzaj Turbo. W sumie to nie wiem jeszcze na ile te systemy SpeedTape/TurboMax czy Rapider i jego kolejne odmiany są ze sobą zgodne. Bo niby impulsy wyglądają podobnie (być może nie patrzyłem dokładnie), ale np. rapider-7500 faktycznie generuje krótsze (czasowo) pliki niż SpeedTape. Nie miałem niestety czasu aby dokładnie zbadać różnice. Prawdę mówiąc liczyłem na Twoje doświadczenie i wiedzę w tym temacie. Mogę zaoferować swoją pomoc i wygenerować pliki z każdego z tych "kopierów" udostępnionych przez VOY-a, aby sprawdzić czy różnice w formacie danych Turbo są znaczące i czy można je by obsłużyć wszystkie jednym pluginem. Chociażby może dlatego dla tej grupy systemów Turbo warto dodać oddzielną kategorię, np. nazwaną "Lower Silesian Rapider Series"? Nie chcę nic narzucać bo nie do końca mam wiedzę dotyczącą pochodzenia systemu, dlatego pytałem o pomoc forumowiczów z tego forum jak i AtariOnline, jednak obawiam się że mało kto będzie cokolwiek pamiętał (do dziś brak odzewu). Faktem natomiast jest że Rapider sprzętowo to był klon Czeskiego Turbo 2000 (Jiri Richter). To widać na zdjęciu które zamieszczałem kilka postów wyżej.
Jeszcze jedna sprawa, chodzi o program Speeder-1400 z tego katalogu, to jest zupełnie inny przypadek. Tan system nie wymaga żadnej przeróbki w magnetofonie i opiera się na standardowej modulacji FSK. Jednak loader jest bardzo ciekawy, wygląda na to że ten system ma programowy dekoder FSK, a przynajmniej loader do Speeder-1400 opracowany przez Radosława Popławskiego, o którym była mowa w tym wątku: Turbo Speeder 1400, Miałem się zabrać za analizę tego loadera dawano, dawno temu, ale liczba "nielegalnych instrukcji" i ogólny "zamęt" w kodzie mnie do tego bardzo szybko zniechęcił ;)
Teraz po latach kiedy temat znowu wypłynął i VOY udostępnił te wszystkie programy okazało się że pierwotną wersję Speeder1400 opracował również Krzysztof Polak, niestety nie patrzyłem w kod jego loadera więc nie wiem czy też jest tak "zamiąchany" jak ten z wersji Speedera opracowanej przez Radosława Popławskiego.
Pamiętam że ktoś kiedyś na tym lub na forum AtariOnline wspomniał że być może dałoby się napisać programowy dekoder FSK i nawet chyba ktoś chciał próbować to robić, jednak wszystko wskazuje na to że taki loader stworzył już w 1989 roku K.Polak. Czy to był jego autorski pomysł, tego nie wiem zbyt mało informacji i wiedzy mam w tym temacie. Ale patrząc na wcześniejszą twórczość tego człowieka można domniemywać że był do tego zdolny. Jego kreatywność i pomysłowość w tamtym okresie była całkiem spora.
Oczywiście były jakieś wspominki o nim w wywiadach lub postach na forum, chyba również Tomasz Rolewski coś wspominał w wywiadzie z nim przeprowadzanym o łamaniu zabezpieczeń generowanych przez programy K.Polaka, ale to są jedynie strzępki informacji, być może można by zapytać T.Rolewskiego o to kim właściwie był K.Polak, niestety nie mam z nim kontaktu, być może KAZ z AtariOnline ma z nim kontakt i mógłby dopytać.
A jeżeli chodzi o "wydobywanie złota"... no mam nadzieję że nie tylko ja, ale wszystkim uda się go wydobyć jak najwięcej! :D Fajnie że są takie miejsca jak to, gdzie można się nim dzielić i że są tacy ludzie którzy podzielają taką było nie było, dziwną "pasję" do grzebania się odmętach historii i dzięki chociażby Turgen można doświadczyć tego wszystkiego na nowo :) Taśmy wieczne nie będą, a tego typu oprogramowanie pozwoli zachować wiedzę na temat tych wszystkich systemów turbo z przeszłości.
Czyli rozumiem że Spy vs Spy III u Ciebie też zadziałało? [plik cas]. Natomiast z loaderem ATT1 nie działa i emu wysypuje się napotykając instrukcję CIM/KILL. Zapewne występuje konflikt adresów loadera z wczytywanym programem.
Nexuss u mnie wczytuje się bezproblemowo również (z cas-ów które wygenerowałeś)
A co do highpass to użyłem z przyzwyczajenia, ponieważ często obrabiam nagrania kiepskiej jakości, w dodatku mają "przesunięty środek" (jest obecna składowa stała), użycie filtra high-pass pozwala się pozbyć tej składowej. Ale Twoje dumpy (pliki wav) są bardzo dobrej jakości. Dlatego usuwanie składowej stalej nie jest potrzebne, a high pass może wprowadzić dodatkowe oscylacje na krawędziach sygnału, więc masz rację, jak nie trzeba to lepiej tej opcji unikać.
Sprawdziłem pliki który załączyłeś, u mnie wszystko jest OK.
Konwersji dokonałem w standardowy sposób:
./a8cas-util.pl-1.06$ ./a8cas-util.pl conv -t att spyvspy3_att2.wav spyvspy3_att2.cas
Starting ecasound... started.
SUMMARY: Data blocks: 12 (N/A E - analyze the log file please).
38 CAS blocks spitted into file spyvspy3_att2.cas.
Do wczytywania użyłem loadera ATT2, w emulatorze w konfiguracji wybrane Turbo ATT:
Nie wiem czy to ma znaczenie ale w Sound Settings mam wybrane 48KHz:
@piguła: super! Wielkie dzięki! Następne materiały do analizy! Przyznaję że jeszcze nie trafiłem na taśmy zapisane w ATT. Wiesziałem że taki system istnieje, bo niektóre carty od Unerring Masters miały wbudowane loadery ATT.
Ja tymczasem przejrzałem cały soft z serii Rapider/SpeedTape/Tmax zgromadzony przez VOY-a na pigwie. Wśród tych plików jest jeden program kopiujący, mianowicie SpeedTape 1.2D sygnowany przez Krzysztofa Polaka:
Zrobiłem eksperyment i zgrałem to samo "Gnome Design Intro" przy użyciu tego systemu. Co się okazało? Program jest datowany na 1988 rok i mimo że długości impulsów kodujących (sync,0,1) wyglądają na bardzo podobne to prędkość transmisji jest o niższa. Na razie nie analizowałem tego dokładnie, ani nie przyglądałem się loaderowi, nie wiem zatem co powoduje że późniejsze wersje tego softu (Tmax4500 czy Rapider75000) uzyskują większe prędkości transmisji. Po głowie chodzą mi różne rzeczy ale muszę się temu przyjrzeć dokładniej.
Dla zainteresowany przykładowy filmik z ładowania pliku zapisanego w tym systemie:
Ładowanie loadera wygląda nieco inaczej niż w przypadku Rapider7500. W tym wypadku mamy dwa rekordy w standardzie zapisane jednak z prędkością 800 bodów, potem jeden długi rekord o długości 545 bajtów. A następnie lecą dane zapisane już w Turbo.
Jeżeli chodzi o Krzysztofa Polaka, to wydaje się to być dość ciekawa osoba, bo stworzyła całą masę softu tego typu, ponieważ nikt tutaj nic nie pisał o nim, pozwoliłem sobie stworzyć wątek na AtariOnline i tam zapytać o niego również, chciałbym dodać opis tych systemów serii SpeedTape/TMax/Rapider do Atariki, ale mam na razie za mało informację. Liczę że ktoś coś o Panu Krzysztofie będzie sobie w stanie przypomnieć. A może ktoś wie jak rozwinąć skrót MoNaMik?
Nie wiem do kogo trafił ten magnetofon, ale zdjęcie jego płytki zostało udostępnione na forum AtariOnline, w tym wątku.. W jednym z postów jest również dodany załącznik z dyskietką z softem w którym spotkałem się z pierwszą wersją Rapider 7500 (post nr 6, załącznik z plikiem "1b.atr").
Na obok płytki główniej magnetofonu widać typowy klon czeskiego turbo od Jiri Richtera, oraz kilka kondensatorów dołożonych bezpośrednio na płytę magnetofonu. Oczywiście sprawdzę to na jakimś realnym sprzęcie i nie omieszkam dać znać.
Jeżeli chodzi o pozostałe oprogramowanie dla tego Turbo z tej serii udostępnione przez VOY-a, to wygląda na to że wszystkie Tmax4500, Rapider5000 cy SpeedTape to wszystko formaty zgodne z jak się wydaje późniejszym Rapiederm7500. Większość wcześniejszych odmian softu podpisana jest podpisana przez Krzysztofa Polaka. Czy K.Polak licencjonował te dla innych podmiotów? Czy tez były to bezczelne przeróbki, tego nie wiem. Na ten temat nie posiadam żadnej wiedzy, ale znając realia tamtych czasów, zapewne cześć tego software została zapewne przerobiona bez zgody autora oryginalnego rozwiązania.
Dodatkowo wszystko wskazuje na to że owe magiczne "7500" mające sugerować prędkość transmisji nie ma raczej nic wspólnego z rzeczywistością, obawiam się że był to jedynie "chłyt" marketingowy ;-)
Walcząc z różnymi systemami turbo przywykłem już do tego że zawsze znajdzie się coś czego jeszcze nie widziałam, ostatnio wywnętrzałem się o "Wrocławskim Turbo 2000" i tym że był to właściwie klon Czeskiego Turbo 2000. Ale ludzie z woj. dolnośląskiego mieli o wiele więcej pomysłów i projektów związanych z przyspieszaniem transmisji wykorzystującej interface pomysłu Jiri Richtera, płyta interface pozostawała ta sama, oprogramowanie ewoluowało i było sprzedawane lub klonowane czy też powielane ze zmianami lub bez, przez co powstało kilka standardów wykorzystujących ten sam hardware, przykładem takiego formatu może być rozwiązanie nazwane "Rapider 7500", przykład ładowania pliku w tym systemie można obejrzeć na krótkim filmiku który przygotowałem z użyciem emulatora zmodyfikowanego przez FUJI-ego:
Nagranie składa się z dwóch bloków standardzie oraz bloków zapisanych w turbo. Czy prędkość transmisji wynosi jak sugeruje nazwa systemu 7500 bitów/sek? Chyba raczej nie... impulsy użyte do kodowania poszczególnych stanów (sync, 0, 1) chyba są bliższe temu co oferuje Turbo2000, ale mogę się mylić bo dokładnie nie sprawdzałem i przyznaję tutaj że liczę na pomoc eksperta w tej sprawie jakim jest autor Turgen System czyli baktraaa. Przyznam że liczę na to że baktraaa zechce dodać również ten system do turgen-a.
A jak się zapisuje nagrania w tym systemie? Pierwszy program kopiujący który potrafi nagrać na taśmę większość plików file z dyskietki udostępnił chyba tEDDYbOAR, a potem KAZ z AtariOnline w wymianie e-mailowej zapytał o ten system, na AOL był również wątek o PALMASOFT, które to prawdopodobnie dystrybuowało nagrania w tym systemie, program kopiujący wyglądał tak:
^^^ po lewej stronie wersja kopiera sygnowana przez BANFISOFT, datowana na 1989 rok, natomiast po prawej stronie ten sam kopier sygnowany już przez PALMAsoft i datowany na 1990 rok.
Archiwum z oboma programami można ściągnąć stąd: Rapider 7500
Jak widać program do dość duży bufor który wynosi ~58kB. Program nie potrzebuje do pracy DOS-a, ma własne procedury odczytu danych z dyskietki w formacie Atari DOS, pracuje w gęstościach SD,ED,DD.
Dla zainteresowanym prześledzeniem struktury zapisu załączam archiwum zawierające pliki WAV, HEX i CAS zawierające intro Gnome Design które widać na filmie wyżej, oczywiście zapisane w formacie wygenerowanym przez powyższy program kopiujący:
Kto był pierwotnie autorem tego rozwiązania? Tutaj nie mam praktycznie żadnej wiedzy, jednak mogę spekulować po tym co udało mi się wygrzebać w sieci. Być może, ale podkreślam że to tylko przypuszczenie i to podparte myśleniem roszczeniowym, że pierwotnym autorem tego rozwiązania mógł być Krzysztof Polak, autor takich programów jak Speeder1400 jak też wcześniejszych "Ultima Ratio" lub "Enigma Copy".
Skąd ten wniosek? Sugerowałem się winietą programu kopiującego "Normal --->Turbo Rapider", który został podpisany inicjałami K.P.
Bardzo chętnie przeczytałbym czy ktokolwiek z was szanowni forumowicze miał styczność z tym systemem i jakie były jego doświadczenia. Również bardzo chętnie dowiedziałbym się kim był Pan Krzysztof Polak który w tamtym czasie stworzył trochę programów kopiujących różnego rodzaju.
Wrócę jeszcze może na chwilę do formatu Turbo Rapider, spróbujmy przybliżyć strukturę nagrania w tym systemie, możemy się posłużyć formatem .hex w którym będziemy mogli przekonać się naocznie jak wygląda takie nagranie: (oczywiście nie całe obciąłem dane po paruset bajtach bloku PWM, całość dostępne w archiwum do którego link podawałem wyżej):
No i co my tu widzimy? po pierwsze widać dwa rekordy w standardowym zapisie, a potem bloki danych w turbo. Dwu-rekordowy loader w standardzie wykorzystuje pewien trik, o którym już wcześniej pisał Pecuś, gdy opublikował swój 1-rekordowy loader AST (post opisujący rozwiązanie zagadki znajduje się: tutaj).
W tym loaderze zastosowano ten sam trik. Pierwszy rekord ładuje się od adresu $36b, po czym następuje jego uruchomienie (load_address+6, czyli tzw. BOOT-INIT). Co znajduje się w tym rekordzie dalej? Właściwie procedura wypisująca nagłówek i nazwę ładowanego programu oraz procedura powodująca odczyt następnego rekordu.
A co w następnym standardowym rekordzie? Minimalistyczna procedura odczytu bloku w turbo (256 bajtów), która to po uruchomieniu ładuje dalszą część loadera jest ładowana począwszy od adresu $700 i uruchamiana. Loader plików w formacie Atari-DOS (binary DOS file) korzysta z procedury odczytu która została załadowana jako drugi standardowy rekord pod adres $400.
Procedura odczytu używa "nielegalnych" instrukcji 6502 (np. RLA ($0C),Y), a także bezpośrednich skoków do ROM komputera, także loader może nie zadziałać w przypadków innej wersji ROM-u Atari.
Nie analizowałem jeszcze dokładnie kodu loadera, ale po strukturze pliku .hex widać że występują 3 długości impulsów, tzn. sync/pilot, 0, 1. Wychodzi także na to że po segmentach INIT następuje sygnał pilota/synchronizacji, nie przyglądałem się dokładnie więc nie wiem czy kolejny segment pliku powoduje również wygenerowanie sygnału pilota/sync.
Format wydaje się mieć podobną konstrukcje do tej którą zastosował *AJEK w Speedy 2700, ale wydaje się że Rapider powstał wcześniej?
Na koniec należą się podziękowania dla tEDDYbOAR-a za to że udostępnił dyskietkę z softem do Turbo2000/3000 na której znalazł się TurboRapider 7500. Ogromne podziękowania również należą się dla VOY-a który dzielnie te wszystkie programy zbiera, odzyskuje i kataloguje, dzięki jego pracy można podziwiać całkiem spore archiwum zawierające masę oprogramowania dla TurboRapider-a 7500, oraz Speeder 1400 (a to temat na zupełnie inny wątek, notabene był już poruszany na tym form ale będziemy do niego jeszcze wracać). Podziękowania należą się również KAZ-owi który swoimi pytaniami sprowokował mnie do szybszego zajęcia się tym tematem.
Gdzie szukać tej masy softu pokatalogowanej i udostępnionej przez VOY-a, no oczywiście na pigwie:
Nie ukrywam że bardzo liczę na to że baktraaa zainteresuje się tym tematem i będzie miał czas i chęci aby dodać nowy format do Turgen (no chyba że się okaże że to jest jakiś znany format czeskiego turbo ;] wtedy wymięknę). Dla Ciebie baktraaa również ogromne podziękowania za ogrom pracy który wkładasz w pracę nad tym całym softem dzięki któremu możemy cieszyć się ponownie zapomnianą już technologią.
No i ogromne podziękowania dla FUJI-ego, dzięki któremu ta cała zabawa z rapiderem nie była by możliwa, to dzięki jego zmodyfikowanemu emulatorowi, w którym mnogość obsługiwanych systemów turbo jest ogromna! i możliwości zapisywania plików CAS/HEX/WAV bezpośrednio z tego emulatora była możliwa szybka analiza rapidera. Bez pomocy Twoich narzędzi to wszystko nie byłoby możliwe do zrealizowania w tak krótkim czasie.
ps1) jeżeli ktoś ma wiedzę i będzie mógł zaprzeczyć lub potwierdzić moim domysłom dotyczącym autorstwa Rapider 7500, bardzo proszę o informację. Napisałbym wtedy artykuł na Atariki dotyczący tego systemu.
ps2) jeżeli ktoś coś więcej wie o Krzysztofie Polaku też bym prosił o podzielenie się wiedzą, spostrzeżeniami, etc. Przyda się do opracowania nowych wpisów na Atariki.
ps3) w archiwum VOY-a na pigwie jest jeszcze Rapider 4500, ale nie wiem czy format zapisu różni się jakoś i czy prędkość jest inna, jutro to sprawdzę dokładnej, tzn. przyjrzę się strukturze nagrania i loaderowi.
Taki soft jest jak najbardziej do zrobienia, ale nasz szanowny kolega baktraaa napisał taki soft który świetnie sobie radzi z różnymi systemami Turbo, mowa o Turbo Decoder. To jest naprawdę kawał porządnego softu. Myślę że trzeba poprosić albo poczekać aż autor doda obsługę Turbo UM!
A widzisz, na to pytanie nie ma prostej odpowiedzi. Bo to wszystko zależy co zawiera plik cas/hex. Jeżeli w pliku CAS jest zapisany jeden plik binarny poprzedzony loaderem (np. sławnym "!") to taka operacja jest jak najbardziej możliwa. Jeżeli plik CAS zawiera plik w formacie "BOOT", to też nie widzę tutaj problemu.
Problem będzie w przypadku plików CAS które zawierają w sobie parę niezależnie nagranych plików które poprzedza jakiś nietypowy loader, wtedy należy zmienić podejście i postępujemy tak jakbyśmy robili wersję "file" jakiejś gry czy programu. Plik CAS traktujemy jako "oryginalny" nośnik i po prostu analizujemy loader i to co on właściwie wczytuje (np. poszczególne bloki programu w jakieś konkretne miejsca pamięci) i wtedy wiedząc gdzie jakie rekordy są ładowane przez loader możemy pokusić się o wykonanie wersji XEX.
Tak samo trzeba by postąpić np. z tym loaderem UM który udostępniłeś, należałoby zobaczyć gdzie tak naprawdę procedura ładująca umieszcza wczytany blok w turbo i na tej podstawie przygotować plik .XEX, z tym że ten loader akurat to chyba jest dostępny w wersji .XEX, na pewno miałem go gdzieś na swoich dyskietkach, tylko w czasach zamierzchłych gdy mi to ktoś nagrał, to ja nie miałem zupełnie pojęcia do czego to służy i nie wiedziałem co to jest Turbo UM ;-) Byłem wtedy posiadaczem KSO 2000 i Turbo 2000F. O ile loader chciał coś czytać z magnetofonu przełączonego w tryb Turbo2000F to nie miałem dostępu do żadnych kaset zapisanych w tym systemie (w sumie to mi się coś roi że chyba o tym już gdzieś pisałem).
Oczami wyobraźni widzę jak seban w swoim warsztacie na wielkiej korkowej tablicy z mapą Polski, Czechosłowacji, NRD i okolic, przypina pinezkami coraz to nowe zdjęcia, schematy, wydruki kodu i łączy je nićmi, jak w scenach z kryminałów gdzie detektyw rozwikłuje zagadkę :-D Coraz więcej nici schodzi się w kierunku Czechosłowacji do turbo J.Richtera, ale nie wszystkie ogniwa są jeszcze połączone... :D
hahahah! popłakałem się ze śmiechu... i do tego tytuł:
"Seban's Den: Pirate Scene Investigation", w wolnym tłumaczeniu: "Nora Sebana: dochodzenie w sprawie pirackich poczynań giełdowych rzezimieszków"
ew. prościej... "PSI: Seban's Den", a potem już będzie prosto można robić kolejne sezony "HSI: All Roads lead to the Czech Republic", "HSI: Jiri Richter - the lost link", "HSI: Chaos Computer Club: This is where it all began! - The story of Turbo 6000".
Ale sam nie dam rady... będzie potrzebna wasza pomoc ;D
...a tak naprawdę na obiecaną kontynuację tematu magnetofonu z Blizzardem o którym pisałem wyżej, a dokładnej chodzi o cartridge dołączony do tegoż magnetofonu:
Z zewnątrz cart nie prezentuje się jakoś odmiennie od reszty kartów prezentowanych w tym wątku. Na tylnej krawędzi posiada dwa przełączniki umożliwiające wybór typu cartridge (jeden przełącza tryb pracy pomiędzy 16KB a 8KB), z drugi z przełączników umożliwia wybór jednego z dwóch 8-kilobajtowych banków. A także przycisk RESET umożliwiających ponowne uruchomienie cartridge bez potrzeby wyłączania komputera.
Cart ów zawiera kompilację oprogramowania dla systemu blizzard, dokładnie 3 cartów istniejących już wcześniej na rynku, a na jego zawartość składają się:
1) cartridge Phoenix 1.0 opracowany przez Hurka:
2) cartridge zawierający zestaw programów nazwany "Turbo Blizzrard":
3) cartridge zawierający zestaw programów nazwany "Blizzrard Cartridge":
Jak widać na powyższych screen-ach jest to "piracka" kompilacja, z podmienionymi napisami. Niejaki "SHOGUN", gdzie mógł i potrafił podmienił informacje o autorach/pochodzeniu oryginalnego softu, zastępując je swoim pseudonimem. Zmiany te zostały poczynione również w loaderach, KOS-ie czy poszczególnych programach.
Zajrzymy zatem do środka owego "stwora":
Płytka drukowana, widok od góry:
Płytka drukowana, widok od dołu:
Niestety zapomniałem zrobić zdjęć w oryginalnej postaci carta którą zastałem, a o tym fakcie przypomniałem sobie, gdy już zacząłem poprawiać płytkę carta (biały kynar i kawałek taśmy kaptonowej to już moja ingerencja w płytkę), zatem widzicie stan po kliku poprawkach. Po otwarciu wszystkie dodatkowe połączenia były wykonane za pomocą nieizolowanej "srebrzanki", i aż dziw bierze że nie było żadnych zwarć, bo w przypadku niektórych połączeń srebrzanka mijała inne punkty lutownicze dosłownie o ułamki milimetra. Postanowiłem zamienić wszystkie połączenia na bardziej bezpieczne. Cartridge oparty na tej płytce drukowanej gościł już w tym wątku, również był sygnowany podpisem "SHOGUN", można się temu przyjrzeć wracając do tego posta, w tym wątku: Blizzard 8K cartridge (pirated by Shogun)
Tym razem ponieważ cart jest bardziej rozbudowany (zawiera EPROM o wielkości 32kB i możliwa jest zmiana konfiguracji typu cartridge), obsadzono na PCB dwa układy scalone, i dokonano całej masy przeróbek aby dostosować jak mniemam stare PCB do pracy w nowej konfiguracji. Nie tylko dodano nowe połączenia za pomocą srebrzanki, ale również dokonano licznych cięć ścieżek na płytce drukowanej.
Cartridge może pracować w dwóch trybach:
jako cartridge o rozmiarze 16KB, zajmujący obszar $8000-$BFFF
jako cartridge o rozmiarze 8KB, zajmujący obszar $A000-$BFFF
Jeden z przełączników wybiera właśnie tryb pracy carta, tzn. 16kB lub 8kB,. Drugi z przełączników działa tylko i wyłącznie w trybie gdy wybrany jest tryb 8kB, i służy on do wyboru jednego z dwóch obrazów 8kB umieszczonych w pierwszej połowie pamięci EPROM. Także gdy cart pracuje w trybie 16kB położenie drugiego z przełączników nie ma żadnego znaczenia.
Gdy zacząłem rysować schemat tego carta i analizować jego pracę, szybko okazało się że ignorancja konstruktora sięgnęła zenitu i z niedowierzaniem analizowałem tę sytuację kilka razy, ale okazało się że gdy cart pracuje w trybie 8kB przełączenie przełącznika od wyboru 8-kilobajtowego banku powoduje zwarcie linii S4 do masy. Należy tu przypomnieć że linia S4 jest linią wyjściową z punktu widzenia Atari. W przypadku tego carta linia ta została podłączona do linii adresowej A13 pamięci EPROM. W sytuacji gdy cart pracuje w trybie 16kB, wszystko jest OK, w zależności od stanu tej linii zostaje zaadresowany odpowiedni kawałek pamięci EPROM, tak aby był on prawidłowo mapowany w obszar $8000-$9FFF lub $A000-$BFFF. Nie wiem co kierowało autorem tego rozwiązania ale wybór banku w trybie 8K jest realizowany właśnie przez przełączenie stanu linii A13 (przełącznikiem nr 2) i wszystko byłoby OK gdyby nie fakt że linia ta cały czas (mimo zmiany konf. na 8K) nadal zostaje podpięta do S4. Autor rozwiązania uznał że warcie przełącznikiem tejże linii to masy będzie wystarczające aby osiągnąć przełączenia banku. Nie sądzę by MMU w atari było w z tego powodu zadowolone.
Oczywiście nie mogłem pozwolić na pozostawienie tego w takim stanie, a ponieważ w carcie dodano drugi układ scalony (7403) i dwie bramki w nim nie były wykorzystane postanowiłem wykorzystać ten fakt i wykorzystać te bramki do bezpiecznej realizacji założonej przez autora funkcji. Oczywiście na schemacie który zamieszczam dodaję już tę modyfikację składającą się z bramek U1A, U1B oraz rezystora R1.
Dwie pozostałe bramki układu 7403 zostały wykorzystane do zbudowania układu zabezpieczającego przed klonowaniem cartów z oprogramowaniem firmy ATARES. Pirat powielił ten układ dla bezpieczeństwa. Oryginalne oprogramowanie od ATARES sprawdzało obecność tego układu i gdy nie był on obecny, loadery i procedury ładujące nie działały poprawnie. Nie wiem czy soft zawarty w tym carcie został pozbawiony zabezpieczeń tego typu, bo tego nie sprawdzałem, jednak tym razem układ został podłączony i dba o to aby bit D6 magistrali danych przy każdym odczycie z obszaru $D5xx był zawsze wyzerowany.
Po poprawkach płytka carta wygląda tak:
góra:
spód:
^^^ jak widać wszystkie połączenia wykonane srebrzanką zostały zastąpione połączeniami wykonanymi kynarem, zostały dodane kondensatory filtrujące przy układach TTL i wprowadzone poprawki związane z linią S4.
Pora zatem chyba zaprezentować już schemat carta z poprawkami o których pisałem wyżej: ^^^ Po otwarciu obrazka w nowej zakładce będzie on zaprezentowany w wyższej rozdzielczości. Jak zwykle do pobrania również wersja wektorowa (PDF): Shogun Blizzard 32K Multi Cart.
Cóż można jeszcze dodać w tym temacie? Na chwilę obecną wydaje mi się, że temat został wyczerpany, gdyby mi się coś przypomniało będę dokonywał edycji tego postu. Pozostało tylko udostępnić archiwum z zawartością pamięci EPROM tego carta: Shogun Blizzard 32K Multi Cart
co w środku archiwum?
shogun_blz32k.bin - cała zawartość pamięci EPROM (32kB)
shogun_phnx_16k.bin - wydzielona część (16kB) zawierająca obraz carta Phoenix 1.0 by Hurek
shogun_blz1_8k.bin - wydzielona część (8kB - bank #0) zawierająca obraz "Turbo Blizzard"
shogun_blz2_8k.bin - wydzielona cześć (8kB - bank #1) zawierająca obraz "Blizzard Cartridge"
Jak widać powyżej oprócz zawartości całej kostki wydzieliłem poszczególne obrazy cartów z całego obrazu, a to dlatego aby możliwe było uruchomienie tego pod emulatorem. Jako że żaden z emulatorów nie wspiera cartów tego typu (z manualnie przełączanymi wajchami i typami) poprawne uruchomienie pliku "shogun_blz32k.bin" nie jest możliwe, ale wydzielone pliki jak najbardziej można uruchomić, oczywiście w przypadku 16kB pliku wybieramy typ carta "Blizzard 16k", natomiast w przypadku plików 8kB wybieramy typ carta "Phoenix 8kB".
Na koniec jeszcze tylko hashe SHA256 plików z archiwum:
EDIT1: nie wiem czy wydzielone pliki uruchomione pod emulatorem będą działać poprawnie, a to ze względu na to że nie mam pewności czy soft nie sprawdza obecności układu "zerującego" bit D6 w przypadku czytania z obszaru $D5xx. Wybaczcie ale nie miałem już siły, chęci ani czasu aby to dokładnie sprawdzić. Myślę że zainteresowani tematem będą w stanie to szybko zweryfikować.
EDIT2: Cart w trybie 8K tak naprawdę nadal działa jak cart 16K (linie RD4 i RD5 są zwarte, więc MMU w obszar $8000-$9FFF) zawsze mapuje zawartość "cartridge", jednak dekoder sygnału CS w przypadku pracy w trybie 8K nie generuje poprawnego sygnału CS w przypadku adresowania obszaru $8000-$9FFF, przez co w tym obszarze pojawiają się losowe śmieci (w serii XE, brak pull-up na magistrali danych). Tak naprawdę w niczym to nie przeszkadza bo cart po przepisaniu danych do niższych obszarów pamięci zostaje kompletnie odłączony. Można było to oczywiście rozwiązać, ale autor carta nie przejmował się bym, bo w niczym to nie przeszkadzało, a wymagałoby to od niego dodatkowego nakładu pracy.
48KHz? Twoje źródło z tego co patrzyłem jest w 44.1KHz i wydaje mi się że takie są też podzielone pliki. Jedyne co zrobiłem to wyciąłem trochę ciszy z początku bloku w standardzie, żadnej innej obróbki nie przeprowadzałem. Tylko Cut, Copy & Paste ;-)
Jeżeli chodzi o konwersję do CAS to proszę bardzo: loader_um w formacie cas i hex. Z tym że konwersja takiego piliku do formatu CAS powoduje że będziesz mógł jedynie używać go z emulatorem który wspiera pliki CAS zawierające segmenty typu "pwm", np. ten który zrobił FUJI: Modified atari800 emulator.
Altirra nie potrafi czytać plików CAS z tego typu segmentami, natomiast dla wersji emu od FUJI-ego nie stanowi to żadnego problemu. Sprawdziłem oczywiście i działa to bezbłędnie.
Może komuś się przyda garść informacji jak dokonałem konwersji. Być może jest inny prostszy sposób, ale przyznaję że nie czytałem zbyt dokładnie dokumentacji do pakietu a8cas-util od FUJI-ego i działałem trochę na ślepo. Jeżeli ktoś poprawi moje ew. błędy lub pokaże jak to zrobić szybciej/efektywniej/lepiej będę wdzięczny.
Czego używałem? Pakietu a8cas-util.pl od FUJI-ego uruchomionego pod Debian 11.
Pierwszym krokiem było podzielenie pliku który podrzucił Piguła na dwa pliki/bloki. Jeden zawierał część nagrania w "normal" (fsk), drugi zawierał blok zapisany z formacie turbo. Dla zainteresowanych pliki do pobrania tutaj.
./a8cas-util.pl conv --highpass -t um um_blk02.wav blk02.hex
Starting ecasound... started.
SUMMARY: Data blocks: 1 (0 Errors).
5 HEX blocks stored in file blk02.hex.
mając już dwa plik hex, po prostu połączyłem je w jeden plik:
cat blk01.hex blk02.hex > um_loader.hex
po czym wyedytowałem plik .hex aby pozbyć się nagłówka z drugiego pliku (A8CAS-HEX, FUJI) a następnie dokonałem konwersji do CAS:
./a8cas-util.pl conv um_loader.hex um_loader.cas
Wynik operacji sprawdziłem ładując ów wynikowy plik .CAS pod emulatorem i wszytko zadziałało bezbłędnie.
Być może coś przekombinowałem i da się to jak mniemam uczynić szybciej/prościej, ale to już bardziej doświadczeni w tej kwestii muszą się wypowiedzieć raczej.
Jeżeli chodzi o książkę, to pomysł powoli dojrzewa do realizacji, ale to będzie długa droga... ja jeszcze nie "obrobiłem" sprzętu który mam w kolejce, a przede mną deasemblacja całej masy kodu i analiza wszystkich procedur ładujących, także do książki czy rozbudowanej dokumentacji każdego systemu to jeszcze długa droga. Ale może kiedyś się uda, chociaż patrząc na to co się dzieje w okół przyszłość nie napawa mnie optymizmem. No i właśnie dlatego, że przyszłość nie rysuje w jakichś optymistycznych barwach postanowiłem publikować wszystko jak najszybciej, aby to co się uda mi odzyskać i udokumentować jak najszybciej znalazło się w sieci. Wiem że to wszystko jest nieco chaotyczne i mało poukładane i czasami pojawiają się nieścisłości i błędy, ale lepiej tak niż wcale, nie będę tego, kitrał gdzieś u siebie na dysku aby zgniło w zapomnieniu.
Cieszę się bardzo gdy inni ludzie również dzielą się tym co mają w swoich zasobach, to może być ostatnia chwila aby tą część historii zachować. Jak pisałem już wcześniej zbliżamy się do punktu w którym zawartość EPROM-ów (a właściwie wielkość ładunku zawartego w ich celach) zbliża się do punktu krytycznego i niebawem nie będzie już czego dumpować, bo zawartość tych kostek stanie się przekłamana lub nieczytelna.
Zatem dzięki wielkie za załączenie kolejnych plików! Cieszę się że wygrzebujesz z przeszłości i swoich archiwów takie smaczki. Ja ze swojej strony tylko dodam że te programy kopiujące wymagają do poprawnej pracy obecności handler-a "T:" dla BASIC-a, może być np. ten "Unerring Master Super Cartridge", który już udało się kiedyś odtworzyć, zdumpować i opisać w tym wątku: Unerring Master Super Cartridge.
Pora skończyć z tą "cartridge-ową dramą" i przejść nad tym wszystkim do dalszych spraw. Tym razem na warsztacie kolejny magnetofon z Blizzardem... już słyszę te głosy... "Ale dlaczego? Jak? Po co? Znowu Blizzard? bleah!"... jednak ten blizzard to kolejne wcielenie tegoż interface... tzn. kolejne rozwiązania układowe, tym razem oparte o UL1321 i takie rozwiązanie było już zaprezentowane kiedyś przez Zenona/Dial, a schemat tej wersji opublikowanej przez Zenona można obejrzeć na Atariki: Blizzard UL1321.
Zapytacie zatem dlaczego zawracam wam głowę tożsamym rozwiązaniem? Robię to, ponieważ ta wersja którą zastałem w magnetofonie z kolekcji uicr0Bee była wersją mocno zoptymalizowaną i zawiera naprawdę bardzo niewielką, wręcz minimalna ilość elementów, do kompletu płytka jest dość mała i zgrabna. Zatem przejdźmy do prezentacji rozwiązania:
Na początku umiejscowienie płytki turbo w magnetofonie:
Góra płytki w zbliżeniu:
Spód płytki:
Jak widać płytka dość prosta, nie trzeba było stosować zaawansowanych technik zakrzywiania czasoprzestrzeni aby udało się odtworzyć schemat:
^^^ Po otwarciu obrazka w nowej zakładce będzie on zaprezentowany w wyższej rozdzielczości. Jak zwykle do pobrania również wersja wektorowa (PDF): Blizzard Turbo Interface - UL1321 version
Może teraz parę moich słów komentarza do schematu. W tej wersji zastosowani wzmacniacz małej częstotliwości UL1321 produkcji CEMI (w interface zastosowano układ z oznaczeniem L321, co oznaczało w tamtych czasach że jest to de-facto odpad produkcyjny nie spełniający wszystkich norm). A tak naprawdę dwa takie wzmacniacze w jednym układzie. Układ również posiada dodatkowy tranzystor NPN. W przypadku użycia tego układu w interface blizzard, wykorzystywany jest tylko jeden ze wzmacniaczy, reszta nie jest podłączona. W tej konkretnej wersji interface znalezionej w magnetofonie układ UL1321 zamontowano pionowo (prawdopodobnie po to aby zmniejszyć rozmiary płytki), a nieużywane nogi układu po prostu odcięto.
Jako układ multipleksera zastosowano klasyczny 7400 (również produkcji CEMI), jednak rodzi to pewną implikację. Jak wiadomo standard SIO wymaga aby urządzenia peryferyjne podłączane do magistrali SIO miały wyjścia danych typu "otwarty kolektor". Ten wymóg jest konieczny ponieważ w wypadku konfliktu sygnałów na magistrali (np. jedno z urządzeń wystawia stan przeciwny do tego jaki panuje na magistrali) może dojść do uszkodzenia jednego z wyjść któregoś z urządzeń dołączonych do magistrali. W najlepszym przypadku nastąpi po prostu przekłamanie przesyłanych danych. Autor tego interface zignorował ten fakt i zastosował układ 7400, którego bramki mają wyjścia typu push-pull, co powoduje że wyjście tego interface staje się również wyjściem push-pull. Widać założenie było takie że ten magnetofon będzie pracował jako jedyne urządzenia podłączone do portu SIO.
Właśnie z tego względu na schemacie postanowiłem wprowadzić poprawkę, dodając diodę D1, której zastosowanie że powstaje jakaś namiastka wyjścia typu "otwarty kolektor". W Atari na linii DATA-IN znajduje się rezystor podciągający tę linię do +5V (tzw. pull-up), a zastosowanie szybkiej diody impulsowej typu 1N4148 powoduje że urządzenie może tylko i wyłącznie wymusić stan "0" na tej linii, przez co nie będzie możliwości aby nasz interface wystawiając "1" spowodowało problemy z innymi urządzeniami na magistrali. Diodę umieściłem po prostu we wtyczce SIO.
Jak widać ta wersja układu została znacznie uproszczona pod względem wersji opartej również na UL1321 zaprezentowanej przez Zenona. Autor tej wersji dokonał kilku "sprytnych" poprawek które pozwoliły na pozbycie się sporej ilości elementów (dwóch tranzystorów, czterech rezystorów).
Co jeszcze można dodać? Może to że zawsze żyłem w przeświadczeniu że UL1321 to nasze polskie rozwiązanie. Niestety jak się okazało po latach ten układ był klonem japońskiego układu LA3101 firmy SANYO. Nie mam wiedzy na temat tego czy CEMI miało licencję na produkcję tego typu układów czy je po prostu sklonowano. Faktem niezaprzeczalnym jest jednak to że te układy dało się kupić w tamtych latach w Polsce i mieliśmy możliwość produkcji własnych układów scalonych, elementów dyskretnych, etc.
Jeżeli chodzi o sam interface to działa on bardzo sprawnie i radził sobie doskonale nawet z mocno sfatygowanymi taśmami. Lokalizacja interface w magnetofonie spotykana już wcześniej (chociaż kiedyś mnie to dziwiło), ale być może tak było wygodniej i łatwiej dla montującego interface w magnetofonie.
Do magnetofonu był dołączony cartridge z oprogramowaniem. Cart "piracki", ale rozbudowany bo zawierał aż 3 niezależne carty zawierające oprogramowanie dla Turbo Blizzard, ale o tym w następnych postach za jakiś czas. Bo co prawda cart już rozrysowany i "zdumpowany", ale potrzebuję chwilę czasu aby przerysować schematy z kartek do KiCAD-a.
To chyba już wszystko co mam do powiedzenia na ten temat tego interface. Do usłyszenia wkrótce.
no tak, bo jak się czyta "po łebkach" swoje własne posty to się tak kończy że się coś pamięta, że "coś", "gdzieś"... a potem wychodzą takie kwiatki że odkrywa się "koło na nowo" ;-)
.jpg)
