1,626

(24 odpowiedzi, napisanych Sprzęt - 16/32bit)

Z tego co pamiętam, użycie FPU zamiast software'owej biblioteki przyspiesza obliczenia zmiennoprzecinkowe coś około 20 (dwudziestu) razy. Więc tak, zgadza się, rezultaty identyczne DUŻO później :) Czasami na tyle dużo później, że nie ma to sensu.

Sikor napisał/a:

każdy się boi prawdziwego 16KB

Wątpię, czy ktokolwiek się "boi", po prostu programistów (czy też koderów) interesują inne rzeczy. Tak przynajmniej uważam sądząc po sobie.

Zresztą, gdyby się dobrze przyjrzeć, to całkiem sporo programów pisanych na 64k poszłoby na 16k, albo tak jak są - tylko nikt nie próbował - albo bo kosmetycznych poprawkach.

PS. Nie wiem, Sikor, czy nie popełniasz błędu metodologicznego, mianowicie takiego, że sądzisz, że skoro nic się specjalnego nie pokazuje, to nikt nic nie robi. Primo, wiele jednak zależy od definicji, co uważamy za specjalne czy też godne uwagi. Secundo, można dłuższy czas "w tajemnicy" pracować nad czymś, co ukaże się dopiero po jakimś czasie. A od kodera, który czas poświęca na realizację własnych pomysłów, nie oczekuj, że rzuci wszystko, żeby realizować Twoje.

1,628

(32 odpowiedzi, napisanych Bałagan)

Ergo bibamus.

1,629

(34 odpowiedzi, napisanych Zloty)

Wczoraj w knajpie został czyjś sweter, koloru szarozielonego. Trzeba się poń zgłosić do baru.

1,630

(34 odpowiedzi, napisanych Zloty)

Ja się planowo spóźnię około dwóch godzin.

1,631

(14 odpowiedzi, napisanych Sprzęt - 8bit)

Testuje to (zapewne, bo nie patrzyłem do kodu, tylko zgaduję) włączając zapis na port szeregowy i zliczając przerwania jakie ten zapis generuje w jednostce czasu.

1,632

(14 odpowiedzi, napisanych Sprzęt - 8bit)

stryker napisał/a:

Błąd : POKEY: Two-tone mode...FAIL. (...) Teraz pytanei co to za błąd ?

Tryb dwutonowy, używany przy zapisie na magnetofon. Widać coś nie działa za dobrze.

1,633

(28 odpowiedzi, napisanych Sprzęt - 8bit)

Sikor napisał/a:

Tyle, że w Karin możesz użyć drugiej połówki, a o ile pamietam - toms nie może drugiej połówki zapisać dowolnymi danymi (choć odczytac programowo można).

TOMS też "może", podobnie jak na LDW/CA, acz to jest trudniejsze. Nie powinno to mieć wpływu na rozpoznawanie gęstości, bo zawartość sektorów jest przy tym obojętna. Chyba że TOMS wpisuje sobie znacznik gęstości do nieużywanych połówek sektorów 1-3 ...

1,634

(28 odpowiedzi, napisanych Sprzęt - 8bit)

W TOMS-ie też sa pełnej wielkości, przynajmniej fizycznie. Te sektory w DD mają zawsze po 256 bajtów.

1,635

(28 odpowiedzi, napisanych Sprzęt - 8bit)

Sikor napisał/a:
drac030 napisał/a:

ale też w ogóle istnieją w obiegu dyskietki 720k inne niż zapisane przez stacje TOMS 710/720?

Karin Maxi.

No i co, TOMS 720 prawidłowo rozpoznaje dyskietki sformatowane w karince na 720k? Bez ruszania głowicą?

1,636

(28 odpowiedzi, napisanych Sprzęt - 8bit)

SN-360 nie ma formatu 720k, stąd i brak "kłopotów".

Co do TOMS-a, cóż, sam jestem ciekaw metody odróżniania 360k od 720k bez ruszania głowicą. Bo tak na oko trzeba zrobić co najmniej przejazd na ścieżkę nr 2. Albo zapisywać na ścieżkach jakieś znaczniki podczas formatowania; to wykluczałoby wprawdzie zgodność formatu z innymi stacjami, ale też w ogóle istnieją w obiegu dyskietki 720k inne niż zapisane przez stacje TOMS 710/720?

Słowem: trzeba wziąć dyskietki sformatowane na TOMS-ie, jedną 360k, drugą 720k, ściągnąć z nich cały cylinder nr 0 i porównać.

1,637

(28 odpowiedzi, napisanych Sprzęt - 8bit)

To zależy od stacji, a ściślej, od przyjętego przez nią sposobu realizacji 360k. W formacie XF551, gdzie stacja zapisuje najpierw stronę A, a potem stronę B, ewentualne rozpoznanie 180k jako 360k nic nie szkodzi. W formacie takim jak w Karin Maxi, no owszem, szkodzi. Byłaby to jedna z zalet metody formatowania użytej w XF.

1,638

(28 odpowiedzi, napisanych Sprzęt - 8bit)

Przeczytaj post nr 3. Nie pierwsze zdanie każdego akapitu, nie co drugi czy piąty wyraz, tylko CAŁOŚĆ.

1,639

(28 odpowiedzi, napisanych Sprzęt - 8bit)

bezrobotny napisał/a:

nie rozwiąże to jednak problemu 180/360/720...

Chłop swoje, czort swoje...

1,640

(28 odpowiedzi, napisanych Sprzęt - 8bit)

pik33 napisał/a:

Poza tym, z tego co pamiętam, to niezależnie od tego, jaki jest format dyskietki, pierwsze 3 sektory w Atari mają zawsze 128 bajtów w standardowym formacie.

Niestety, mylisz się. W DD te sektory mają (fizycznie) po 256 bajtów.

Analizując ich zawartość powinno dać się określić, jak dalej czytać tę dyskietkę.

I tak i nie. "Analizą zawartości" powinien zająć się DOS. Ale nie stacja dysków. Pomijając już, że większość atarowskich DOS-ów zapisuje tam tylko kod bootloadera (czyli analiza zawartości zda się psu na budę), i przyjmując idealistyczne założenie, że wszystkie dyskietki są w formacie SpartaDOS, nie da się niestety z parametrów zapisanych w sektorze nr 1 odczytać gęstości, gdyż te parametry nie mówią nic o fizycznym formacie dyskietki, tylko o formacie logicznym. Mówiąc prościej, nic nie stoi na przeszkodzie, żeby w sektorze nr 1 dyskietki 720k były zapisane parametry jak dla dyskietki 180k.

@bezrobotny:

Mogę coś przeoczyć, bo kontrolerem WD 1772 (i pokrewnymi) bawiłem się ostatnio około 15 lat temu. Niemniej wydaje mi się, że odróżnienie dyskietki 360k od takiej, która z 360k została przeformatowana na 180k, nie jest możliwe. Z drugiej strony, jeśli logiczny format jest 180k, a fizyczny 360, to nic nie szkodzi, DOS i tak nie zapisze więcej danych niż pozwala informacja zapisana na dyskietce (np. bitmapa), więc stacja spokojnie sobie może myśleć, że to jest 360k, DOS wie swoje w tym przypadku.

Ogólnie algorytm rozpoznawania gęstości polega na próbach odczytu nagłówków sektorów w kolejnych obrotach dyskietki. Kiedyś sobie to rozpisywałem i zdaje się, że w ośmiu obrotach powinno dać się zidentyfikować wszystkie gęstości. Np. jeśli w FM nie czyta się nic, to gęstość jest MFM. Jeśli w MFM odczytasz ze ścieżki 0 sektor nr 26, to to jest gęstość średnia. Jeśli nie, to podwójna. Dalej, jeśli masz podwójną na stronie A, to sprawdzasz odczyt ze strony B. Itd.

Z racji wielu zajęć nie jestem w stanie zajmować się uaktualnianiem polskiej wersji instrukcji do SpartaDOS X 4.4. Czyli tego:

http://sdx.atari8.info/sdx_files/4.42/s … ual-pl.pdf

Z tego powodu, a także dlatego, że istnieje znakomita instrukcja po angielsku:

http://www.goodbytexl.homepage.t-online … Rev_1b.pdf

którą opiekuje się GoodByteXL, postanowiliśmy z trubem zarzucić dalsze prace nad polskim tekstem - o ile nie znajdzie się osoba chętna na przejęcie tego obowiązku na siebie. Podstawowe zadanie polega na uaktualnianiu tekstu na bieżąco stosownie do informacji, jakie będziemy przysyłać e-mailem.

Osoba chętna powinna:

1) używać i znać SpartaDOS X - choćby po to, żeby móc sprawdzić, jak opisy z instrukcji działają w rzeczywistości

2) sprawnie czytać po angielsku - żeby móc konfrontować tekst polski z angielskim

3) sprawnie pisać kulturalną polszczyzną - bez błędów ortograficznych i rażących błędów stylistycznych

4) być zaznajomionym z podstawową terminologią komputerową

5) być w stanie przeznaczyć na to nieco swojego wolnego czasu, rzecz jasna nieodpłatnie

Chętni proszeni są o zgłaszanie się na tzw. priv do truba i do mnie.

1,642

(4 odpowiedzi, napisanych Software, Gry - 8bit)

Nie mam pojęcia, trzeba byłoby sprawdzić. Procedura, która ustawia AUDCTL na $28 jest w XL OS pod $C4DA.

1,643

(95 odpowiedzi, napisanych Sprzęt - 8bit)

bezrobotny napisał/a:

najlepsze jest to, że przez 25 lat nikt nie poprawił tego kretyńskiego formatu US i Synchro...

Nie no, śmiało, zaproponuj coś lepszego.

1,644

(4 odpowiedzi, napisanych Software, Gry - 8bit)

Nie mam pojęcia, trzeba byłoby porównać emitowane odgłosy.

1,645

(95 odpowiedzi, napisanych Sprzęt - 8bit)

bezrobotny napisał/a:

co niby się stanie, jak podłączę kilka stacji, jednego tomsa, a pozostałe ca2001? i jeszcze centroniks?

W teorii, nic się nie stanie.

trub i świta od Sparty powinni wprowadzić jakiś nowy standard dla nowych urządzeń, na przykład taki, żeby tylko dane szły po wysokiej częstotliwości...

Wymyśliłeś Synchromesha, jakieś 25 lat po fakcie. SDX zna ten protokół transmisji. Ale US jest lepszy.

1,646

(4 odpowiedzi, napisanych Software, Gry - 8bit)

Swego czasu dely zwrócił mi uwagę, że gra Missile Command ma być może (podobnie jak Moon Patrol) schrzaniony dźwięk na XL/XE. Okazało się, że istotnie tak jest. Podpinam poprawioną wersję i sorry, dely, że tak długo to trwało. :)

Przy okazji przypominam, gdyby ktoś nie wiedział, że podobną poprawkę zrobiłem kiedyś do Moon Patrol. Poprawiona gra jest do ściągnięcia stąd: http://drac030.krap.pl/moon-patrol-audiofix.arc

Generalnie problem wynika z tego, że obie gry zakładają, iż AUDCTL po resecie ma wartość $00, podczas gdy jest to prawdą tylko na 400/800 - na XL/XE jest to $28.

1,647

(30 odpowiedzi, napisanych Software, Gry - 8bit)

Chodzi.

1,648

(8 odpowiedzi, napisanych Sprzęt - 16/32bit)

artik-wroc napisał/a:

A reszty pamięci nie widzi, właśnie dlatego, że jest to wersja dla 4MB.

??? Co za "wersja dla 4 MB"? Dlaczego TOS nie widzi 10 MB RAM-u? Przecież memtop na pewno jest ustawiony dobrze przez BIOS w ROM-ie.

1,649

(15 odpowiedzi, napisanych Sprzęt - 16/32bit)

Jeśli skopiowanie pliku wielkości 7 MB zajęło ci 10 sekund, to znaczy, że twój dysk wyciąga średnio 1400 KB/s (5 sekund odczytu i 5 sekund zapisu). Pamiętam, że na moim starym Falconie to było coś w okolicach 1600-1700 KB/s, więc wynik masz w normie.

1,650

(30 odpowiedzi, napisanych Software, Gry - 8bit)

Potwierdzam, nie ładuje się, bo drugi segment binarki włazi na loader:

$0600-$0715.

Poza tym idący za nim segment init dziwnie wygląda:

$02e2-$0360

Słowem, coś się chyba skrzaczyło. Sprawdzałem na 130XE z VBXE.

PS. candle, może wystaw zipa (xex mógł się ściągnąć "tekstowo")

PS.2. nie działa też na emulatorze atari800 - przy załadowaniu przez -run uruchamia się, ale przejście w tryb demo powoduje zwis na czarno.