Chwilowo dalsze prace są spowolnione, bo obowiązki zawodowe itp. Ale zdaje się, że problem da się zawęzić do HS Indexu 0, już HS Index 1 chodzi (u mnie przynajmniej) perfekcyjnie wg wzoru podanego przez Atari.

Niezbyt wierzę, że wina jest po stronie peceta; konwerter USB natomiast, jak to opiewa ulocia producenta, ma obsługiwać transfery do 3 Mbit/s, trudno zatem przypuszczać, żeby miał kłopot ze 126 kbit/s.

Problem musi leżeć gdzieś po stronie Atari: albo chodzi o zniekształcenia sygnału powodowane przez elementy na płycie (jak sugeruje Simius), albo - ale to czysta spekulacja z mojej strony - POKEY ma błąd (ewentualnie jakieś ograniczenie, jak sugeruje Fox), w wyniku którego SIO w jakiś sposób wariuje przy indeksie 0. To też trzeba byłoby może obejrzeć pod oscyloskopem, jak wyglądają ramki wypuszczane z Atari w stronę peceta. Bo błędy - i ogólnie kłopoty z komunikacją - wyskakują też przy zapisie.

Poczyniliśmy z mono jeszcze jedną obserwację: mianowicie on peceta podpina w nieco mniej skomplikowany sposób niż ja, bo przez IO-Board, u mnie natomiast konwerter COM2USB jest ten sam, co w IO-Board, ale jeszcze mam SIO2PC. To może wyjaśniać, dlaczego po obliczeniu szybkości transmisji z odchyłką (7,18 zamiast 7) u mono HS Index 0 działa superstabilnie, u mnie natomiast jednak nieco kapryśnie (wyżej pisałem o "większej restrykcyjności" mojego zestawu, acz wtedy zwalając na peceta). Tzn. jednego dnia godzinami działa dobrze, a drugiego, po zmianie kierunku wiatru, już pojawiają się okazjonalne wywałki.

Ok, macie rację, na szczęście te drajwery są w postaci źródłowej (przynajmniej dla Linuxa i BSD), można sprawdzić wzory.

Hmm, no to ja nie wiem. Wynika z tego, że wzór jest OK, a na pececie wyliczony divisor 189 jest akurat o 1 poza zakresem tych, które działają. I ja bym jeszcze pojął, gdyby to był jednostkowy przypadek błędu w programie, błędu w driverach (na dwóch różnych OS-ach?), ale w aspeqt mamy poniekąd to samo (post nr 3, zaxon).

Niech będzie 24 MHz, żebym miał trudniej. Proszę:

1773446 / 14 = 126674,71428571428571428571428571..., niech będzie 126675.

24000000 / 126675 = 189,46121965660153937240970988751... niech będzie 189.

24000000 / 189 = 126984,12698412698412698412698413... niech będzie 126984.

Różnica:

(126984 / 126675) * 100 - 100 = 0,24393132030787448194197750148017... niech będzie równo ćwierć procenta.

Tymczasem RS-232 powinien tolerować odchylenia do 5%.

Tak. Aczkolwiek Synchromesh jest kłopotliwy, bo - o ile mnie przynajmniej wiadomo - nie ma rozsądnej metody na ustalenie, z jaką prędkością turbo taka stacja działa i czy w ogóle (w przypadku LDW/CA) jest zaprogramowana.

Chyba trudno, żeby przedstawiały się liniowo, skoro HS_INDEX jest dzielnikiem częstotliwości?

Nie "właśnie", lecz dobę temu :P

Jest jest. Odpowiedz mi na pytanie w wątku o MPT Play :P

Tzn. sam mptracker ci działa źle, ale wejście do niego, a potem wyjście do DOS-u powoduje, że mptplay mono zaczyna grać dobrze?

@pin: Tia, mówiłeś o tym w Głazach. Ale nie mam pojęcia, co może być przyczyną. W procedurach wczytywania plików nic się nie zmieniło, zresztą gdyby DOS źle wczytywał pliki (nie w to miejsce co trzeba np. albo nie tę ilośc danych co trzeba) to waliłoby się wszystko, a nie jeden player. Poza tym na sam player DOS nie powinien mieć wpływu, a już zwłaszcza na zależność pomiędzy wczytanym wcześniej trackerem a działającym potem playerem. Tutaj raczej chodzi o jakieś błędy w playerze, jego zależność od tego, co jest w pamięci w momencie jego wczytania albo coś w tym stylu.

Chwilowo nic innego nie jestem w stanie wymyślić.

Z tego co mi wiadomo simius będzie dostępny dopiero od 22 sierpnia, więc być może trzeba będzie się uzbroić w cierpliwość.