Sikor, ten bajt na zakończeniu to jest pierwszy jakby stopień wystąpienia błędów, przy różnych kartach i różnych elementach całej układanki występują kolejne stopnie większej ilości błędów zapisu, później jeszcze odczytu, aż do całkowitego niedziałania włącznie. Opisałem to w tym poście: http://www.atari.org.pl/forum/viewtopic … 44#p248744

Pamiętajcie też o fakcie, że poruszamy się po gruncie o tyle niestabilnym, że wyciągamy na złączu ACSI prędkości powyżej oficjalnie podawanych przez Atari. Próbowałem też namówić Putnika żeby spróbować zrobić jakieś opóźnienia w driverze, któóre by dla testu spowolniły transmisję. Wtedy Putnik mi powiedział, że nie da się nic takiego zrobić, bo driver wywołuje tylko funkcję dla układu DMA, która startuje transmisję, a resztę już robi sam układ DMA i to on ogarnia transmisję zwracając gotowe dane.

Z tym rezystorem na przejściówce, to też jak walczyłem z interfejsem, to obejrzałem i się zdziwiłem, że jest wpięty między zasilanie a masę. Ja tych przejściówek kupowałem kiedyś sporo z różnych źródeł i specjalnie poszukałem zdjęć różnych swoich starszych wynalazków, na których sprawdziłem, że zawsze wszystkie moje przejściówki miały tam ten rezystor. Przejrzałem jeszcze wtedy też archiwalne aukcje, na których kupowałem te przejściówki i okazało się że na zdjęciach w aukcjach widać tam kondensator a nie rezystor. Pomyślałem wtedy, że może Chińczycy wyprodukowali partię miliona przejściówek wkładając przez pomyłkę w maszynę taśmy z rezystorami zamiast kondensatorów:-) Próbowałem więc wywalić ten rezystor z przejściówki i dałem zamiast niego kondensator 100nF odsprzęgający tak jak tam powinno zapewne być, ale nie robiło to kompletnie żadnej różnicy w działaniu interfejsu.
Jednak nasz problem błędów nie dotyczy przejściówki, bo xangel robił też wersją interfejsu bez przejściówki i lutował bezpośrednio socket pod kartę CF - no i miał te same objawy błędów.

_tzok_ a może ta przejściówka, którą kupiłeś jest po prostu walnięta? Mi się kiedyś trafiła na kilka kupionych sztuk jedna taka, która nie działała, okazało się, że miała jakieś zwarcie przy sockecie do karty CF. Tam jest taki wredny raster i zwykle jest to tak niechlujnie przez Chińczyka polutowane, że może się zdarzyć, że coś tam nie styka. Sprawdź pin po pinie miernikiem.

Standard kart CF wymyślony został przez firmę Sandisk. Również ta sama firma Sandisk wymyśliła tryb DMA 8-bit. Pozostali producenci kart CF w późniejszym czasie produkowali sobie karty trzymając się luźno standardów opisanych dokładnie w dokumentacji Sandiska, między innymi nie implementując wszystkiego co Sandisk opisał jako standard. Faktem jest że trybu DMA 8-bit nikt nie używa, tak jak mówisz:-) Niemniej jednak Sandisk przez te wszystkie lata trzyma się ściśle swoich standardów i cały czas podtrzymuje je implementując tryb DMA 8-bit we wszystkich swoich produktach, bo również nowe karty tryb ten obsługują. Oczywiście nie wiemy czy nie ma tam buga, ale we wszystkich kartach produkowanych na przestrzeni lat?

A dyski jakieś obsługują tryb DMA 8-bit? Po pierwsze tego nie wiem, a po drugie i tak nie mam żadnych dysków, nie używam i nie chcę używać:-)

Wiesz co, gry od Putnika już przy starcie pokazują zwykle jak jest coś nie tak z ilością pamięci, lub po prostu zazwyczaj wychodzą z gry z powrotem do GEM-a po planszy tytułowej z obrazkiem, tak że jeśli gra się już uruchomi, to będzie z nią raczej wszystko dobrze.

Z bigdosem doczytałem dokumentację od tego darmowego drivera PP, to jest faktycznie trochę inny sterownik. Z drugiej strony zaletą jest to, że można zwyczajne partycje FAT16 zrobić bez żadnych kombinacji sobie na pececie i już. No i całość jest darmowa, co zwłaszcza w przypadku HDDrivera zostawia nam w kieszeni pokaźną sumkę:-) Jeśli wszystko na tym będzie chodziło, to uważam, że jest to bardzo sensowne rozwiązanie. Napisz za jakiś dłuższy czas ewentualnie jak się to u Ciebie sprawuje.
Ewentualnie można podzielić kartę na więcej partycji, żeby miały poniżej 32MB i nie używać wtedy bigdosa. W dokumentacji stoi że partycji może być 14, to daje nam łącznie jakieś 440MB, więc kartę 512MB można tak sobie podzielić, resztę zostawić niepodzieloną i już. Z resztą jak kto woli.

Jeszcze co do prędkości. Putnik pisze, że na tym driverze przy prostej taśmie jest około 350kB/s. U mnie na płatnym sterowniku jest około 360kB/s, więc wychodzi na to, że jest to samo. Natomiast zastanawia mnie to co napisał o twisted cable. W zasadzie można by spróbować zrobić taką taśmę obróconą, bo to tylko taśma, a prędkość ponoć ma wzrosnąć do 1300kB/s, to chyba jest o co powalczyć.

Może sprawdź sobie jeszcze jaka jest teraz u Ciebie prędkość, na stronie Putnika jest również ten jego program do testowania prędkości.

Obecnie mam sprzęty poprzestawiane, nie mam trochę czasu zająć się ST, ale na pewno wypróbuję u siebie przy okazji twisted cable.

Ale pamiętaj, że transmitujemy po 16 bitów, tylko w dwóch paczkach po 8. Dlatego w zasadzie jest to bajt przedostatni w stosunku do tego ostatniego, gdyby transmisję rozpatrywać w podziale na HI i LO.

Przede wszystkim obraz Putnika nie ma zainstalowanego drivera do IDE, więc trzeba by na karcie, na której wrzucimy ten obraz doinstalować jeszcze driver, który najpierw w tym celu by trzeba odpalić z dyskietki. Albo jak napisał _tzok_ zrobić podmiankę nagłówka z tego małego pliku od Putnika, ale tego nie robiłem, więc nie pomogę, pamiętam tylko, że widziałem gdzieś opis Putnika w tej sprawie...

Też:-) A co powiesz na ===

Jasne, że nie ma sensu porównywać takich ułamków sekund dla gry paragrafowej. Wspomniałem o tym i zapytałem dlatego, że wybiegam trochę w przyszłość i już myślę do czego by można użyć TBXL następnym razem. Dlatego zainteresował mnie temat takich drobiazgów w sensie jak robi to kompilator. Bardzo dziękuję Willy za rzeczowe wyjaśnienie - właśnie konkretnie chodziło mi o interpretację <> vs !=, którego w Basicu bardzo mi brakuje, bo jestem przyzwyczajony do używania != od lat w pracy zawodowej w językach znienawidzonych komputerów pece. Sikor, nie rozwijaj takich wątków - krótkie pytanie, krótka odpowiedź, w międzyczasie, w oczekiwaniu na kolejny odcinek tutoriala.

Masz dwie niezależne usterki, odrębne. Jedna to jest to smużenie i to kwestia potencjometru, pokręć nim jeszcze trochę lewo-prawo, ustaw tak żeby było dobrze i już go zostaw w spokoju, bo to już naprawiłeś:-)

Druga usterka wskazuje dla mnie dość ewidentnie na zimne luty jak powiedział przedmówca, lub też bardziej wg mnie prawdopodobne na pęknięte nóżki od scalaków, lub pęknięte ścieżki na płycie. Spróbuj jak komputer wstanie poprawnie, to przeginać płytę delikatnie w różne strony. Kładziesz płytę płasko, przytrzymujesz jedną ręką gdzieś na środku i delikatnie podnosisz kolejno za rogi wyginając ją. Będziesz widział czy się zawiesza wtedy, czy pojawiają się śmieci na ekranie, czy znika obraz itp. Wyginając i naciskając w różnych miejscach można ustalić w ten sposób mniej-więcej region płyty gdzie szukać problemu.

Miałem już takie usterki.
Raz w ten sposób znalazłem pękniętą ścieżkę lupą oglądając kawałek po kawałku płytę.
Drugi raz nic nie wypatrzyłem i postanowiłem przelutować świeżą cyną wszystkie nogi dużych scalaków - przy tej operacji okazało się, że nóżki skorodowały przy samej płycie i popękały.

Aha, obejrzyj też dokładnie płytę najpierw, bo może jest jakiś paproch pomiędzy nogami scalaków, który robi zwarcie, albo obejrzyj też płytę od spodu, czy końcówki nóżek gdzieś nie są wygięte i też nie robią zwarć. Raz też miałem przypadek, że blacha przy modulatorze była wygięta i dotykała czegoś tam delikatnie. No ogólnie trzeba dokładnie płytę pooglądać.

@lopez, bardzo fajne to, eleganckie. Właśnie rysuję podobny projekt na pełne 4MB.

PP pisał mi, że on w driverze i tak nie może nic poprawić w samej transmisji, bo on wywołuje tylko gotowe funkcje, a resztę ogarnia układ DMA w Atari i nie ma wpływu na to, żeby tam kombinować ze zmianami szybkości transmisji, czy innych jej parametrów. Nie wiem na ile to prawda, ale tak mi pisał.