Skręcenie przewodów nie zapewnia żadnego zabezpieczenia przed przesłuchem, powiedziałbym iż nawet odwrotnie :) Dla takiego rodzaju kabla należy zastosować transmisję różnicową. W jednym kablu nadajemy normalny sygnał w drugim sygnał odwrócony w fazie o 180 stopni. W odbiorniku te sygnały zostają odjęte od siebie przez co zakłócenia które dostały się do kabla znoszą się w wyniku odjęcia sygnału normalnego i odwróconego w fazie o 180.

Samo zastosowanie takiego kabla nic nie da. Warstwa fizyczna (sprzętowa) musi być do takiego medium transmisyjnego dostosowana :) Właśnie warstwa fizyczna RS485 jest zrealizowana na zasadzie transmisji różnicowej.

http://pl.wikipedia.org/wiki/EIA-485

Ostatnio edytowany przez seban (2009-02-08 11:43:44)

nie uwazam zeby byla to prawda...
ale latwiej poczekac na gotowe - wygodne to i nic nie kosztuje

bartoszp: dobre! szkoda tylko ze nie uwzgledniles tego ze w opisywanych przez ciebie sytuacjach sygnal transmitowany jest roznicowy, wiec wszystko co napisales jest prawda, acz nie ma to znaczenia dla opisywanego przez Sebana przypadku... tutaj skrecajac przewody robisz sobie ladny dlugi kondensator

Panowie,

1. Nie mówię o skręcaniu 2 kabli sygnałowych a wykorzystaniu 2 z 8 kabli na sygnał a reszty na masę. Wzajemne skręcenie minimalizuje
    efekt kondensatora.
2. Pytanie co jest ograniczeniem ? Jakość kabla czy tez problem stabilności długości 1 i 0 generowanego podczas
    transmisji bo to powoduje najczęściej "rozjeżdżanie się" nadajnika i odbiornika i stabilności komunikacji.
3. Najlepiej na każdy z kabli wykorzystać koncentryczny kabel antenowy z oplotem  - najlepsza konstrukcja tylko nieporęczna :)
4. Dalej obstawiam, że przesłuchy w kablu nie są krytyczne - ATA/SATA/SCSI/USB działają z dużo większymi prędkościami.
   Może wykorzystać jakiś kabel drukarkowy USB do testów.

Raczej II połowa tygodnia mogę pomóc....

Kolego Bartoszu... nie jest moim celem żadna złośliwość do Ciebie ani wytykanie twoich błędów... chciałem tylko zwrócić twoją uwagą na to iż to co piszesz jest prawdą ale tylko w przypadku transmisji różnicowej. Interface-y które wymieniłeś czyli USB/FireWire/SATA transmitują sygnał RÓŻNICOWO!. Nawet SCSI w wersji LVDS używa skręconych par do transmisji sygnałów różnicowych. Wolniejsze wersje równoległego SCSI (nie różnicowe) działają na co prawda na zwykłym kablu i jak sam zauważyłeś w takim wypadku co druga żyła to masa. Jednak o tym iż w przypadku SCSI na kontrolerze i ostatnim urządzeniu ma magistrali występuje terminator który przeciwdziała odbiciom sygnału w kablu i powoduje dostosowanie impedancji linii od wymogów nadajników odbiorników. Trochę prądu w tym wypadku w linię jest pakowane... swoją drogą ciekawostka o której mało kto wie ;D Interface PATA również ma terminatory :) Urządzenie master musi być ostatnie w na kablu bo właśnie przełączenie zworki na master powoduje automatyczne włączenie terminatora. 

W przypadku z którym walczy Candle... czyli gniazdo SIO+POKEY to bardzo upraszczając jest to zwykły 5-woltowy port RS (transmisja nie jest różnicowa do transmisji są wykorzystane pojedyncze żyły kabla), aby móc wykorzystywać skrętkę trzeba by dodać tor różnicowy. Jednak nie to jest problemem w tym wypadku... i nie o to chodzi. W tym wypadku chodziło aby wyciągnąć max transmisji przy użyciu metody której jeszcze nikt nie próbował czy użycie zewnętrznego zegara do synchronizowania odbieranych przez POKEY bitów. Candle udowodnił iż to działa, teraz potrzeba chętnych do opracowania software, zarówno po stronie ATARI jak i PC.

pozdrawiam
Seban

Kabelek zrobiony "na chama" istnieje już od 2007 ;) podpinany (o zgrozo :P) pod LPT - zrobiłem
sobie po prostu "bezukładowe" SIO2PC i nie na RS-232 - same kable ;P, co zaskutkowało też
przy okazji zjaraniem sobie portu w LDW przy próbach podłączania Atari<->LDW<->PC - na całe
szczęscie tylko jednego, więc stacja nadal działa. Niestety znów oddaliłem się od świata
atarowskiego na spory okres czasu i oprogramowanie do dziś leży w rozsypce. Draco mnie
męczył i męczył, ale nie wymęczył , ale może jakoś niedługo coś porobię znów, bo znowu bedę
miał trochę czasu. Tak czy inaczej działanie w trybie Atari<->PC z taktowaniem zewnętrznym przy
odbieraniu było testowane i działało - stacje LDW i CA mają to (przynajmniej tą 1 linię) podpięte,
ale nie korzystają. Z tego co Draco pisał to widzę, że coś próbował tam z tym robić - co nie grało
tego już nie wiem. Tyle co w tej chwili pamiętam to problemy mogłą robić właśnie ta linia jeżeli była
pozostawiona w stanie "0", bo tak jakoś mi się przypomina, że blokowała wtedy działanie POKEY'a.
Obie linie gdy nie ma transmisji w tym trybie powinny być na '1' - może z tym hintem coś wam się uda.
Ogólnie poza ustawieniem pokeya przesłanie bajtu wyglądało jakoś tak (linie tak ustawiane od strony PC):

           stan spoczynku
zegar   1 ----------------  --  --  --  --  --  --  --  --  --  --  --
        0                 --  --  --  --  --  --  --  --  --  --  --
                          BBssss11112222 8 bitow danych 77778888SSSSEE
dane    1 ------------------    ????????????????????????????????------
        0                   ----????????????????????????????????

BB - linia zegara na "0" (pokey przyjmuje kolejne bity przy przejściu z 1 na 0, ale się przyblokowywał jeżeli
linia zegara była zostawiona na '0' , więc w stanie spoczynku nie dało rady jej tak zostawić - może nawet
odebrania bajtu by nie zgłosił jakby tak została po nadaniu bitu stopu, ale nie sprawdziłem tego już przed
zarzuceniem zabawy z Atarką na kolejny okres czasu ;). Prawdopodobnie można by ustawić tu od razu
dane na '0' i słać bit startu, ale tego już wtedy też nie stestowałem, więc podaję tak jak działało - zmieniałem
stan danych zawsze przy przejsciu zegara z '0' na '1'  i pozwalałem POKEYowi brać sobie przy odwrotnym.

ssss- nadanie bitu startu
1111 do 8888 - dane
SSSS - bit stopu

EE - linia zegara na "1", zeby pokey był odblokowany i normalnie działał - nadany w ten sposób bajt
pojawiał się na SERIN, więc możecie jak coś popróbować z tym się pobawić w ten sposób.
Ja będę może miał niedługo trochę czasu żeby się pobawić z Atarką to może się uda dokończyć
pozaczynane rzeczy - wiem, że dużo tych "może" :), ale zobaczymy. Może będę miał nawet na tyle
luzu, żę się i wybiorę znów do Głuchołazów w tym roku ? No, ale to już temat nie do rozważań
w tym wątku :P.

Fakt, przeskoczyłem to :) - przeczytałem początek i ostatnie, a z tych wynikało, że nadal
problem nie ugryziony. Tak czy inaczej po przeczytaniu #20 i kolejnych nadal wychodzi
na to, że nie ma nic działającego :P,mimo, że problem samej tranmisji juz niby rozwiązany.
No nic, widzę, że nie tylko ja się obijać lubie :P, ale ja tam swoje kiedyś w końcu doprowadzę
do szczęśliwego końca, choć jak słusznie zauważyłeś fajniej jest czekać na gotowe :).
Mnie jak na razie mój kabelek LPT2PC wystarcza w zupełności do zabawy atarką
z ATRami na PC w trybie emulacji przez PCta stacji atarowskiej - zarówno soft do
obsługi atrów jak i do szybkiej transmisji jest w proszku (choć ten pierwszy mniej, bo
przynajmniej działa na tyle, że można się bawić), ale jak pisałem niedługo znów
powinienem mieć ciut czasu to może będzie mi się chciało pogmerać w tym, jednak
jeszcze na pewno nie do końca lutego, bo do tego terminu jeszcze parę innych rzeczy
mi się znajdzie do zrobienia.

wiem wiem, gadamy sobie z ijor'em na pw, bo na glownym temacie zrobil sie spory bajzel...

tez czekam na info :P

oferuję pomoc w:

- pisaniu softu dla ATARI
- pisaniu softu dla PC (obsługa ATR, transmisja z driverem D2XX i/lub VCP FT232)

Trzeba pamiętać, że FT232 powinien też potrafić obsłużyć tryb natywny SIO, aby było możliwe bootowanie dysków i ogólnie praca ze zwykłymi DOS-ami (bo. np. taki SDX może mieć driver do transmisji synchronicznej).

mnie interesuje jak to programowac od strony pycy, tj. czy trzeba przerabiac modul obslugi ft232, czy wystarczy cos ioctl-ami poustawiac...