Płatne drivery od Putnika polegają na tym, że jemu płaci się raz, i dostajesz od niego driver do czego chcesz, bo on robi odrębne drivery do różnych urządzeń. Zaletą tego jest, że drivery Putnika nie są wielkim kombajnem obsługującym wszystko na raz, tylko driver jest bardzo malutki, więc mieści się w całości w bootsektorze i nie potrzebuje żadnych plików na dysku, oraz zajmuje bardzo mało pamięci. Natomiast drivery płatne nie mają żadnej dodatkowej funkcjonalności, nie są szybsze, i w ogóle się niczym nie różnią od tych udostępnionych za darmo. Po prostu Putnik kilka specyficznych driverów udostępnił za darmo, a z płatnymi to on najbardziej bazuje na UltraSatanach itp. które są najpopularniejsze i dlatego ludzie je kupują. Druga różnica polega na tym, że w komplecie z płatnym driverem dostajemy od Putnika jego program do partycjonowania.

A do czego ten BIGDOS skoro korzystamy z driverów od Putnika? Chyba że do tego, żeby było widać zwykłe partycje z normalnym FAT16, a nie z tym zmodyfikowanym przez Putnika? Tylko jeżeli tak jest, to obawiam się że odpalony BIGDOS może nam niepotrzebnie siedzieć w pamięci i czy to nie będzie robiło problemu z niektórymi grami? Tak mi przyszło to do głowy, bo testowałem dość dużo gier w adaptacjach HDD Putnika, i tam przy wielu z nich jest napisane, że dana gra działa przy danej ilości pamięci, ale pod warunkiem pamięciooszczędnego drivera do HDD. Nie wiem czy ma to jakiś związek wszystko, ale tak sygnalizuję...

Wiesz co, ja powiem tak: powoli zaczynam coraz mniej używać Hatari. Na Hatari nie działa cała masa rzeczy. Może ktoś lubi to czy tamto, ale u mnie dużo lepiej sprawdza się stary dobry Steam. Niestety w kwestii interfejsu IDE trzeba się tym bawić na prawdziwym sprzęcie, bo żaden emulator nie wspiera bezpośrednio dostępu do dysku tak jak w przypadku Amigi robi to UAE. Jak robiłem kartę CF do Amigi kiedyś, to po prostu pod UAE podłączyłem ją, zainstalowałem system, wszystko sobie poustawiałem, a po przełożeniu karty do prawdziwej Amigi wszystko od razu po prostu działało idealnie. Szkoda, że dla Atari nie mamy tak dobrego softu, bo ja jestem starym Atarowcem i Amiga raczej średnio mnie bawi, lecz zazdroszczę im takich rozwiązań.
Wracając do tematu, mi się nie udało zrobić obrazu, który by działał i w Hatari i na prawdziwym sprzęcie. Obrazy działające na prawdziwym sprzęcie nie działają mi nijak w Hatari i odwrotnie. Oglądałem sobie pliki obrazów z Hatari i prawdziwego Atari, nagłówki są zupełnie inne, pliki różnią się diametralnie, próbowałem różnych opcji w Hatari i generalnie jest do d... z tym.
Ostatecznie jak się instaluje wszystko na prawdziwym sprzęcie to działa bez problemów.

Bo programowanie to cały czas te same matematyczne kombinacje, bez względu na stopień zaawansowania sprzętu, a wynikiem każdego programu ciągle pozostają obrazy i dźwięki, ewentualnie włączone lub wyłączone jakieś linie sterujące czymś tam, nic więcej.
Z tym że proponował bym już więcej nie zaśmiecać koledze Sikorowi wątku-tutorialu o pisaniu gry w TBXL, ja się wyłączam i czekam na kolejny odcinek od Sikora.

No, jak się z Atari Basic przesiadałem na pecety dawno temu, to też mi jakoś brakowało tego <>, a != było dziwnym tworem:-) Teraz mam odwrotnie:-)

BartoszP, ale w którą stronę ten czas się nam zmieni? Jeśli myślisz, że dodanie negacji to dodatkowa operacja, to ja Ci powiem, że myślę, że może czasem być dokładnie odwrotnie, bo operacja porównania z kolei na pewno jest dużo szybsza jeśli porównujemy liczbę 6 za pomocą znaku = niż gdy robimy porównanie <> gdzie tak na prawdę sprawdzane są dwa warunki, przy czym chyba porównanie ze znakiem równości nawet od jednego warunku ze znakiem większości będzie szybsze.
Sikor drugie zagadnienie do tego Twojego osobnego wątku z testami poleceń TBXL:-)

Co do "za krótkich nóżek procesora", to przecież na zdjęciu w pierwszym poście tego wątku masz pokazane, że można dać listwy żeby podnieść proca.
Jeśli chodzi o kondensator, to wylutuj go z płyty i umieść na leżąco (zostaw dłuższe nogi nowemu kondensatorowi, albo dolutuj kawałek drutu do tych istniejących, bo będą za krótkie na pewno, żeby go położyć).

A w ogóle, to pisałem również o innej metodzie, którą zastosowałem u siebie: nie wylutowałem procesora z płyty, tylko nalutowałem na niego listwy precyzyjne żeńskie i tak wsadziłem c't IDE. Plusy są takie, że jest mniej listew i mniej połączeń, kondensator wspomniany nie przeszkadza, jest łatwy dostęp do kości TOS-u, z którymi sobie sporo kombinuję.

Edit: nie mogę znaleźć gdzie pisałem o metodzie nalutowania na procesor... Możliwe, że pisałem to komuś w prywatnej korespondencji, lub w innym wątku, nie pamiętam. Załączam zdjęcie jak to zrobiłem u siebie.

Bezpośrednio pod emulator karty podłączyć się nie da. Obraz karty mi też w taki sposób nie działa, może nie umiem, ale obrazy z hatari nie działają mi na karcie w prawdziwym Atari i na odwrót też mi nie działają. Oglądałem pliki obrazów z hatari i z Atari i różnią się, więc coś jest niedobrze z tym hatari chyba.
Co do driverów, to testowaliśmy z Dragmarem najnowszego HDDrivera oraz sterowniki Putnika i jesteśmy zawiedzeni HDDriverem, zwłaszcza, że kosztuje niemałe pieniądze. Różne problemy i ograniczenia są z partycjami kompatybilnymi z windowsem. Może Dragmar coś dopisze szczegółowo. Natomiast drivery Putnika działają pod tym względem elegancko.
Nie jestem ekspertem w tej dziedzinie, ale drivery Putnika bardziej do mnie trafiają, zwłaszcza, że zamierzam głównie grać w gry od Putnika, więc mam też zaufanie, że jego gry będą dobrze działać na jego driverach.

A czy interpreterowi robi różnicę czy podaje się liczby dziesiętne czy w heksie? Czy on to musi przeliczać i ma to jakiś wpływ na szybkość działania kodu? Oczywiście mówię tylko o interpreterze, bo wiadomo, że kompilator na pewno i tak to ujednolici.

@uicr0Bee dzięki, ale nie mam czasu zajmować się analizowaniem tego aż tak szczegółowo. Wiem, że kiedyś wspominałem, że chcę to dokładnie przeanalizować, bo temat wydawał mi się interesujący, ale ostatecznie dochodzę coraz częściej do wniosku-pytania: po co to robić? Jednoznacznie na posiadanych egzemplarzach płyt doszedłem do własnych wniosków, że najfajniejsza płyta to ta z pamięciami 4-bit. Poza nią lubię jeszcze płytę 800XL bez Fredka. Te dwie płyty są moimi ulubionymi, na nich wszystko mi zawsze działa bez problemu, więc nimi się bawię. Życia na wszystko nie starczy, pozostałe płyty niech sobie zostaną w oryginałach. Takie mam obecnie zdanie w tej materii.

Swoją drogą właśnie wczoraj naprawiłem dwie płyty 130XE 4-bit:-) Obie płyty kompletnie martwe służyły za dawców, kupiłem je właśnie w takim celu ale przywróciłem je obie do życia, tylko im teraz brakuje kilku układów... Rzecz wygląda tak, że w obu płytach miały miejsce próby wymiany wszystkich scalaków po kolei (popularna metoda naprawcza na forach), natomiast w obu płytach padł był kwarc 14MHz. Wystarczyło wymienić kwarce, wsadzić tymczasowo sprawne scalaki i obie płyty ruszyły bez problemu.
Zdziwiłem się, że trafiły mi się dwie płyty z identyczną usterką - ale opisuję to, bo na forach często ktoś pyta od czego zacząć analizę "martwej płyty" i lecimy po kolei zawsze RAM, Freda, MMU, potem Basic, OSROM, tranzystory, mierzenie napięć, zasilacz itd... Tymczasem może to być po prostu padnięty kwarc i mamy efekt całkowitej i totalnej martwoty.

Ja tylko krótko: znów mi się podoba, czytam sobie i czekam z niecierpliwością na ciąg dalszy.

W tym tutorialu dla mnie osobiście największą wartość przedstawia takie "case study" osoby, która robi tę oto grę (Sikor) i pokazuje swoje dobre praktyki, wypracowane doświadczeniem. Oczywiście jest masa literatury, przykładów itd., TBXL jak to każdy basic jest łatwy, ale doświadczenie sprawia, że wiadomo czego i jak używać najlepiej w danym przypadku. Dzięki temu tutorialowi mamy możliwość przeskoczenia od razu na trochę wyższy poziom, omijając własne testy i kombinacje prowadzące do wyboru najlepszych metod realizacji danej rzeczy. Kiedy byliśmy dzieciakami, to najlepiej było uczyć się na własnym stopniowo zdobywanym doświadczeniu, ale dziś nie mamy już na to tyle czasu. Tak że dzięki wielkie Sikor, że się angażujesz w podzielenie się tym kołem, które już raz wynalazłeś, żebyśmy my go nie musieli wynajdywać od nowa:-)

Czyli diody robią dobrze. Może trzeba by dołożyć jeszcze coś... gdzieś...

_tzok_, i to jest niestety dokładnie ten sam problem, który miałem w swoim interfejsie. Przypatrz się uważnie gdzie występują błędy. Jest pewna reguła: błędny bajt jest zawsze ostatnim bajtem z grupy 512 bajtów. Tak jest przy małej ilości błędów, przy dużej już są to różne bajty. Co ciekawe, u mnie te błędy były powtarzalne, czyli przy kilku próbach takiego kopiowania zawsze miałem powtarzalne te same błędy. Zwróć też uwagę jaki jest ten błędny bajt: u mnie zawsze był to bajt któryś obok tego właściwego, a nie losowy i też dało się zaobserwować regułę.
Wyglądało mi to, jak by błędy w transmisji pojawiały się zawsze na koniec sektora (512 bajtów). W dodatku ten błędny ostatni bajt był powtórzeniem któregoś sąsiedniego bajtu (już nie pamiętam którego dokładnie). Z tego powodu zastanawiałem się, czy nie jest to problem drivera, a nie sprzętu. Dlatego cisnąłem Putnika, sądząc, że może jest problem jakiś z driverem, bo przecież przy zakłóceniach błędy powinny mieć charakter losowy. Jednak Putnik upierał się, że to jest kwestia zakłóceń, a na koniec obraził się, że go nie chcę słuchać - jak to Putnik:-)
Szedłem więc dalej ścieżką którą mi wytyczył i trzymałem się tych zakłóceń. Poprawa sytuacji, lub jej pogorszenie następowało przy dobieraniu różnych kart CF, różnych GAL-i (najlepszy u mnie okazał się być 25ns, ale testowałem tylko szybsze, nie miałem takiego jak twój 35ns). Ostatecznie pomogło u mnie dobranie jedynej karty 2GB (ta Twoja dobrze rokuje, trzymał bym się jej), GAL-a 25ns (choć możliwe, że 35ns też jest  ok, nie sprawdzałem), oraz spróbuj wlutować te diody schotky tak jak Ci pisałem w mailu.