czasem lepiej nie wiedzieć, ważne że działa :)

Tego z external clockiem w pokeyu chyba nikt nie rozumie, poprawcie mnie, jeśli się mylę (bo też bym chciał wiedzieć jak i czy to działa).

Natomiast co do szybkości: zalezy od tego, czy nic się przy okazji nie dzieje, czy też nawalone jest w tle przerwań DLI na przykład. Na czysto 82 kbps powinno działać. W większości przypadków 52 kbps ($0a) jest ok, tzn. pójdzie też przy różnych obciążeniach.

Ktoś tu kiedyś pracował nad zrobieniem pokeya w VHDL-u, ale, jak zwykle, chyba mu się zwiędło. Ale gdyby nie, albo gdyby brał się za to kto inny, to niech pamięta o dorobieniu do SIO tak z 1-2 bajty FIFO, żeby SIO mogło odbierać dane nawet kiedy 6502 nie ma czasu.

W loaderze do R5 ustawiam SKCTL tak, jak to robi OS przy zwykłej transmisji ze stacją dysków. Też łamałem sobie nad tym głowę czemu tak jest (cały czas 0x23 nie działa) i jest to jakaś niezgodność z opisem ... nie pamiętam tylko, czy doszedłem do jakichś wniosków - za dawno to pisałem.

Candle - jak znajdę to prześlę Ci programik działający z linii komend DOS, który potrafił robić różne cuda na SIO...

http://asap.sourceforge.net/pokeydoc.zip
Otwieramy index.xml. A w temacie: registers.xml#SKCTL oraz serclk.xml

Ja też nic nie słyszałem ... :) LOL :)

to w takim razie czegos znow nie rozumiem:
przy $2x na skctl mam na pierwszym mux'ie wybrane wejscie 0, a na drugim wejscie 01, tym samym dziala wewnetrzny serin_clk jak i serout_clk
czyli komunikacja powinna sie odbywac w dwie strony zgodnie z dokumentacja pokeya

przy $1x na skctl mam na pierwszym mux'ie nadal wybrane wejscie 0, za to na drugim mam wejscie 00, wiec nie dziala wysylanie asynchroniczne, bo sygnal zegarowy musi nadejsc z bclk - i to tez sie zgadza z dokumentacja

wiec mi to niewiele wyjasnia
jesli popelniam gdzies blad - to badz laskaw mi go pokazac

b4 SKCTL jest też na schemacie SERIN i powoduje reset zegara 4 w momencie nadejścia bitu startu. To koryguje drobne różnice między prędkością wysyłania przez stację i odbierania przez komputer - to jest to, co nazywa się "async" w tabelce dla SKCTL. Wynika z tego, że odczyt ze stacji działa dla $1x, $3x, $5x i $7x. Jeśli chcemy wysyłać do stacji, to musimy to robić na zegarze POKEYa (nie wiem, co rozumiesz przez wysyłanie asynchroniczne), więc $2x, $4x, $6x i $7x. Więc wspólne ustawienie to $7x, z tym że prędkość wysyłania ustawiamy wtedy zegarem 2, a nie 4.

Nie wiem, gdzie znalazłeś "010 transfer and recive rate asynchronous (channel 4)" - nie ma tego w pokey.pdf.

Edit:
Odpowiedź na "pytanie pokrewne" z pierwszego postu: wiele zależy od tego, jak zrealizujemy transmisję. Jeśli "standardowo", tj. opierając się na liczniku POKEYa i rejestrze SERIN, to największa prędkość dla AUDF3=AUDF4=0 to 14 cykli na bit, czyli 126675 bps (z overrun jest tak jak piszesz, rozrysowane na schematach SERIN i IRQ). Możemy też próbować odczytywać 6502 bezpośrednio każdy bit z SKSTAT - w b4 jest tam wejście szeregowe. W obu przypadkach największym problemem jest, aby strona nadająca miała zbliżoną prędkość, a zwykle nie można jej płynnie regulować. Problem ten rozwiązałoby podłączenie BCLK i użycie trybu $0x lub $4x.

Hej!

Jedna drobna uwaga... nie wiem na ile istotna: na schematach stacji CA-2001 oraz LDW-2000 linie "clock in" oraz "clock out" są podłączone. Nie wiem na ile oprogramowanie tych stacji z tego korzysta. Może w trybie transmisji "synchromesh" wykorzystano tą możliwość. Ale to już musiałaby się wypowiedzieć osoba która miała doczynienia z oprogramowaniem tych stacji. Może warto się przyjrzeć programowi procedurze szybkiej transmisji zarówno po stronie stacji jak i Atari.

Z tego co pamiętam Sparta DOS i DOS XL potrafią wykorzystać Synchromesh. http://atariki.krap.pl/index.php/Synchromesh

Zawsze się zastanawiałem po co linie Clk_IN i Clk_OUT są podpięte w tych stacjach. Jednak nigdy nie sprawdziłem czy stacja w jakikolwiek sposób wykorzystuje tą możliwość, czy tylko i wyłącznie zrobiono to "for future use".

drac030: probowales? jesli tak, to pewnie dysponujesz programem ktory ustawi pokey w nasluch w takim trybie i bedzie wyswietlal to co otrzyma na ekran, chyba ze fantazja mnie poniosla... znowu...

seban: czekalem az sie odezwiesz ;]

a ktos pamieta jak 1541-ii realizuje transmisje w turbo? z tego co pamietam leci 2 bitowo i obie strony transmisji maja bardzo docyklowane procedurki
ft232 ma 8 dwukierunkowych linii do dowolnego wykozystania, jakby sie udalo zrobic pierwszy kroczek mozna by pojsc dalej

no i coz
dziala!
1 bit startu (0), 8 bitow danych, 1 bit stopu (bez znaczenia), bity sa pobierane od najmlodszego do najstarszego

przetestowac sobie mozna podpinajac start i select do lini 1 i 3 gniazda sio - nie moze byc podlaczone sio2pc ani inna bzdura w tym samym czasie, bo wydajnosc pradowa guzikow jest zadna i nie wysteruje wejsc jak cos bedzie wymuszac na nich inny stan

source i binarka dla zainteresowanych tu
jakby ktos chcia powiedziec ze zrodla sa be - mogl napisac - ja pisze jak umiem, a ze nie umiem... coz - za stary jestem na nauke procedur we-wy w systemie, wole je sobie napisac

no i jak z szybkością Candle, jakie max transfery są teraz osiągalne? bo nie wiem czy mam się podniecać czy nie :)

tymczasem idzie wysylac bajty przy zegarze bliskim 1mbit
czasami pokey zgubi bit, wiec jest odrobine za szybko na jego moziwosci, ale daje rade
po takiej zgubie trzeba mu wyslac 10 zer i wraca do normy
tu lezy sobie soft na pc
minimalny hardware zeby to zadzialalo, to wtyczka db25 i 3 kabelki - jeden od pinu #25 db25 do masy atari, drugi od pinu #2 do pinu #1 sio, 3ci od pinu #8 db25 do pinu #3 sio

uaktualnilem soft po stronie atari, tak ze odbiera dane na irq i wyswietla ladnie 256 bajtow w hex'ach
przydalo by sie rozpoznawac czy nie wystapil buffer overrun i takie tam

nadal nie ma chetnych?