Na dobry(?) początek*:
Panie, co pan, ja nie jestem rolnikiem! :P
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Nowy firmware 1.5 dla SDrive-MAX Ulepszony tryb szybki i poprawki kaset w nowej wersji firmware
Ice-T 2.8.2 Nowa wersja Ice-T dla 8-bitowego Atari już dostępna - poprawki i nowe funkcje
Galactic Panic - nowa przygodówka na ST Darmowa gra point and click na Atari ST - ponad 100 ekranów przygody.
Nowa wersja ARIFE Tool od PVBest73 Uaktualniono uniwersalne narzędzie do analizy obrazów ROM i dysków Atari
Echa Sommarhack 2025 Podczas szwedzkiego party Sommarhack zaprezentowano kilkadziesiąt produkcji,
atari.area forum » Posty przez drac030
Na dobry(?) początek*:
Panie, co pan, ja nie jestem rolnikiem! :P
No, jak napisałem w poście 36.
Trudno powiedzieć, czy to rozwiązuje problem opisywany w wątku (który chyba czytałeś, skoro piszesz posta?), czy też tylko stabilizuje transmisję.
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.
Udało nam się wykluczyć sterowniki USB i w ogóle całe USB jako przyczynę problemu:
1) w obliczeniach przeprowadzanych przez sterownik uftdi na FreeBSD i przez odpowiednik na Linuxie nie widać niczego podejrzanego
2) źródła w necie twierdzą, że zegary 48 MHz dla USB są "very accurate" (to a propos podejrzeń, że 48 MHz w rzeczywistości równa się 49,2 albo 49,4 MHz)
3) najważniejsze: kod AtariSIO Hiasa (wersja z 28 maja 2011) zawiera dokładnie te same kombinacje z wysokimi wartościami bitrate, mimo że w grę nie wchodzi USB, ale zwykły UART 16C950.
Ma ktoś jakiś pomysł, o co tu chodzi?
Ok, macie rację, na szczęście te drajwery są w postaci źródłowej (przynajmniej dla Linuxa i BSD), można sprawdzić wzory.
simius, rzecz w tym, że jedyny "wzór na PC", który może tu wchodzić w rachubę, to ten właśnie, o którym tu mowa. Chyba, że mówisz o wzorach, którymi systemy operacyjne w pecetach (licząc z Windowsami - trzy różne) wyliczają clock divisor dla podanej wartości baud rate. Ale na to nie mamy wpływu i wydaje mi się dziwne, żeby w trzech różnych OS-ach było to zrobione tak samo źle.
Epi, różnica jest rzędu 2,5%, przy 24 MHz daje to 600 kHz, wtedy przyjmowanie zegara 24,0 MHz byłoby sporym nadużyciem.
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).
Tobie chodzi o porównywanie danych przy nieudanych transmisjach czy w ogóle? Bo w ogóle to wczoraj przewaliłem 32 MB w dwie strony (tj. Atari->PC-Atari), blokami po 32985 bajtów, i nie było różnic między źródłem a celem.
Natomiast przy nieudanych, to są dwa rodzaje:
1) dane odbierane przez peceta w ogóle nie przypominają niczego, co Atari mogłoby wysłać - to przy ogólnym braku komunikacji
2) błędy u mnie to na ogół błędy sumy kontrolnej, wtedy suma różni się różnie, czasem o 1 bit, czasem zupełnie
Jeśli on coś w ogóle zgubi, to właśnie nie dłuższe bloki, ale raczej krótsze (potwierdzenia).
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%.
Myślę, że zakłócenia spokojnie można wyeliminować. Ale jest tu jeszcze jedna rzecz, o której zapomniałem napisać, mianowicie obaj korzystamy nie z rzeczywistego portu RS-232, ale z konwertera COM2USB. Być może on tu coś miesza.
Co do tej drugiej możliwości, sam jestem ciekaw, dlatego z niecierpliwością czekam na potwierdzenie (zaprzeczenie), że częstotliwość wypuszczana przez POKEY (przy indeksie 0 na przykład) to ta sama, która wychodzi z wzoru widocznego w docach Atari.
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.
Po wywołaniu SIO (jsr $e459) przede wszystkim wywoływane są "new devices". A takowe samo decyduje, czy wywołanie jest do niego i czy je obsłuży czy odrzuci. I stosownie do tego odpowiada systemowi. Jeśli wywołanie newdev przyniesie efekt w postaci odpowiedzi "OK, zrobione, tu jest kod statusu", to OS już nie wywołuje swoich procedur szeregowych, ale wraca po prostu do tzw. "programu użytkownika".
Chciałbym tylko zauważyć, że dane z Atariki nie przedstawiają się liniowo.
Chyba trudno, żeby przedstawiały się liniowo, skoro HS_INDEX jest dzielnikiem częstotliwości?
Niestety Dracowi już nie zadziałało - dla niego współczynnik wychodzi 7.25.
Korekta: raczej coś pomiędzy 7.15 a 7.20.
PS. Poza tym mój pecet jest jakiś bardziej restrykcyjny, żeby w ogóle transmisja z indeksem 0 szła jako tako, muszę przyjąć zegar bazowy PAL, bo przy zegarze NTSC albo NTSC-F albo średniej PAL/NTSC - niezależnie od współczynnika - od razu lecą błędy transmisji (gł. sumy kontrolnej).
Cześć
Pisał o tym już mono w tym miejscu http://atariarea.krap.pl/forum/viewtopi … 81#p132381 - ale jakoś przeszło to bez echa. Otóż w dokumentacji POKEY-a jest podany wzór do obliczenia szybkości transmisji szeregowej z wartości licznika, czyli inaczej mówiąc z HS_INDEX. Ten wzór (dla PAL-u) to:
baudrate = 1773446/(2*(HS_INDEX+7))
Wszelako, z eksperymentów dokonywanych programem SIO2BSD (przy czym mono uruchamia go na pececie z Linuxem, a ja z FreeBSD) wychodzi, że ten wzór jest błędny, obliczona w ten sposób na pececie i tamże ustawiona prędkość transmisji nie zgadza się z prędkością wybraną na POKEY-u przez wartość HS_INDEX, i to na tyle, że przy niskich wartościach HS_INDEX (typu 0) nie ma pomiędzy komputerami łączności.
Eksperymentalnie ustaliliśmy (tj. mono ustalił, a ja się przyglądałem ;) ), że we wzorze zamiast "plus 7" powinno być "plus 7 z czymś", przy czym to "coś", to ułamek w rodzaju 0.13-0.25.
Pytania:
1) czy ktoś coś wie na ten temat? :) Domyślam się, że częstotliwości generowane przez POKEY są mierzalne, wobec tego może już je ktoś dokładnie pomierzył.
2) z czego może wynikać niecałkowita wartość współczynnika? Jakieś opóźnienia na bramkach wewnątrz POKEY-a? Błąd w naszym rozumowaniu albo w obliczeniach? Niekompatybilność RS-232 i SIO?
- dyrektywy generujące dane zaczerpnięte z MAE .CB, .BY, . WO, .HE, .SB nie są relokowalne, kod relokowalny generuje na 100% pseudo rozkaz DTA, potem .BYTE, .WORD itd.
A właściwie dlaczego? Przecież .BY i .WO to to samo co .BYTE i .WORD, .HE to w zasadzie uproszczone .BYTE, z kolei .SB (= .SBYTE) i .CB (= .CBYTE) służą tylko do generowania tekstów, co więc przeszkadza ich użyciu w blokach reloc?
Nie "właśnie", lecz dobę temu :P
Jest.
Jest jest. Odpowiedz mi na pytanie w wątku o MPT Play :P
A spod SC? W sensie, bez wklepywania linii komend od nowa? :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?
pinokio: w kwestii music protrackera źle działającego pod sdx 4.44 - czy uruchomienie go przez x /c coś zmienia?
@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ć.
Fajnie by było, gdyby dało się zmienić song już w trakcie działania playera, a nie tylko z linii komend.
atari.area forum » Posty przez drac030
Wygenerowano w 0.139 sekund, wykonano 11 zapytań