1,626

(254 odpowiedzi, napisanych Bałagan)

My też umiemy puszczać filmiki http://www.youtube.com/watch?v=b4Rl1HrImMk

1,627

(37 odpowiedzi, napisanych Fabryka - 8bit)

Może jest i elegancko, spróbuj jednak. Ostatecznie taki kabelek i ręczna konfiguracja się nie wykluczają. Jeśli będzie działać jak należy, to może przekonasz miliony użytkowników, żeby sobie to dolutowali.

1,628

(37 odpowiedzi, napisanych Fabryka - 8bit)

<teoretyzując dalej> Zmienna środowiskowa jest w gruncie rzeczy kompromisem pomiędzy detekcją automatyczną a opisaną przez epiego konfiguracją ręczną. Primo, program chcący się dowiedzieć, czy i gdzie jest taki covox, odczytuje tę informację automatycznie, w jeden, konkretnie zdefiniowany sposób. Secundo, nie potrzebuje z drugiej strony żadnego instalatora czy menu.

To od tego między innymi jest system operacyjny, żeby przechowywał i udostępniał tego typu informacje o komputerze, w tym o sprzęcie. A czy pozyska je automatycznie czy też od usera (przez jakiś centralny plik konfiguracyjny) to już nie jest zmartwienie programu od covoxa.

Oczywiście zaraz odezwą się tacy, którym OS przeszkadza. No cóż. Mimo wszystko moim zdaniem ta droga jest najłatwiejsza i najsensowniejsza. Z zastrzeżeniem jak wyżej, że OS musi mieć tę informację i ją móc udostępnić, a nie służyć tylko jako prymitywny loaderek do niektórych gierek.

1,629

(37 odpowiedzi, napisanych Fabryka - 8bit)

Tia, zmienna środowiskowa byłaby najlepsza. Tylko że jedna jedyna Sparta X je ma.

1,630

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

A to nie wiem[tm].

1,631

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

To niestety chyba może być prawie wszystko, np. walnięty ROM. Stan linii (HALT i BERR) wskazuje, że wystąpił podwójny bus error (czyli raz access fault i drugi raz przy próbie jego obsługi). Motka wtedy automatycznie się haltuje.

PS. Nie pamiętam co się wtedy dzieje z liniami adresowymi, ale gdyby pozostawały w ostatnim stanie, to można byłoby odczytać adres, gdzie się procek wyłożył.

Sikor napisał/a:

na przykład słyszę od niektórych, że potrafią to czy tamto, a jak dochodzi co do czego - okazuje się, że nie bałdzo. Wiec nie jest prawdą to co piszesz, że każdy zna swoje umiejętności, a tym bardziej, że się orientuje w możliwościach/umiejetnosciach innych.

Być może nie jest to prawdą, tylko optymistycznym założeniem. Niemniej Twój wniosek nie wypływa z Twoich przesłanek, albowiem to, co ludzie sądzą na swój temat, ma się czasami nijak do tego, co na swój temat mówią :P

Oczywiście pomijam tu przypadki ewidentnych urojeń, ale te też jest dość łatwo poznać - chociażby wg starej zasady, że "krowa, która dużo ryczy, mało mleka daje" ;)

Sikor napisał/a:

Chociażby dlatego, żeby pokazać, że potrafi.

No, ale dlaczego sądzisz, że koderom miałoby na tym zależeć? Każdy raczej zna umiejętności własne i z grubsza orientuje się, co mogą inni.

Sikor napisał/a:

Drac030: wiem, na przykład emulator ZX Spectrum na mistyczne F7, którego obecnie nikt nie ma.

Chodzi też na Warpie, którego obecnie ma laoo :P

I żeby wszystko było jasne, ja piszę programy dla siebie (a z innymi się nimi dzielę), więc oczywiście że napisanie czegoś, co działa na jednym komputerze, interesuje mnie bardziej, niż napisanie czegoś na gołe 600XL, którego w życiu nie miałem i mieć nie przewiduję.

Zasadniczo wyniki póki co mnie nie dziwią - nikt chyba już nie potrafi się zmnieścić w takich ograniczeniach. A szkoda.

No załóżmy, że "nikt nie potrafi" - a gdyby potrafił, to do czego mu by to było potrzebne? Przecież 600XL-ek z 16k RAM-u jest tyle, co kot napłakał. Podstawowe Atari ma 64k albo i więcej.

1,635

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

ankieta napisał/a:

Karin Maxi Drive, inna (gniazdo Cartridge)

Z tego co pamiętam, karinka zajmuje również gniazdo ECI, dokładnie tak samo, jak każde urządzenie PBI dla XE (każde, które nie jest wmontowane do wnętrza).

1,636

(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,638

(32 odpowiedzi, napisanych Bałagan)

Ergo bibamus.

1,639

(34 odpowiedzi, napisanych Zloty)

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

1,640

(34 odpowiedzi, napisanych Zloty)

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

1,641

(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,642

(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,643

(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,644

(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,645

(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,646

(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,647

(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,648

(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,649

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

bezrobotny napisał/a:

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

Chłop swoje, czort swoje...

1,650

(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.