Pierdu, pierdu.

Cóż w tym dziwnego? Nie słyszałeś nigdy o "przedwojennym faszyście Mościckim"? :D

Tak, jeśli są przeprowadzane w lokalach prywatnych, w gronie znajomych. Otwarte, ogólnodostępne forum trudno jednak uznać za prywatny lokal.

Ja zaś myślę, że totalitarne lewo powinno być martwe. Bez względu na to, czy akurat w danym przypadku chciałbyś je instrumentalnie zastosować, bo nie lubisz osoby lub osób w stosunku do których miałoby być zastosowane.

Obawiam się, że się mylisz. Internet jest medium publicznym i ogłoszona w nim zbiórka jest publiczna. Ustawa stanowi, że wszelkie publiczne zbiórki podlegają temu przepisowi, co znaczy, że nieistotne są jakiekolwiek inne cechy takiej zbiórki poza tą jedną - że jest publiczna.

Nie. W tym prawie nie o to chodzi. Bo żeby karać cwaniaków naciągających ludzi, wystarczą zwyczajne przepisy dotyczące oszustwa. Tu chodzi o chęć kontroli wszelkich obszarów życia publicznego przez totalitarny, faszystowski reżim.

To zwykła pomyłka. Pamięci 44256 mają 9-bitowe odświeżanie.

Zapłacenie za kogoś grzywny jest przestępstwem? Tego nie wiedziałem. Z którego artykułu?
BTW. Nie sądzisz, że prawo (a właściwie lewo) , które wymaga uzyskania zgody MSWiA na publiczną zbiórkę pieniędzy jest z gatunku totalitarnych?

Człowiek narodowości prawniczej uczciwy? Toż to oksymoron :)

To zależy, jak na to spojrzeć. Można by raczej powiedzieć, że to 65816 ma kłopoty z IDE+. Problem polega na tym, że 65816 ma 24-bitową szynę adresową, ale tylko 16 bitów adresu wyprowadzone jest wprost na nóżki procesora. 8 najstarszych bitów adresu (numer segmentu) przesyłane jest po magistrali danych. Oczywiście, teoretycznie nie dzieje się to równocześnie z danymi, ponieważ adres wysyłany jest w pierwszej połówce cyklu zegarowego, a dane - w drugiej połówce. Teoretycznie. W praktyce dochodzi do konfliktu danych, ponieważ w systemie Atari jest parę elementów, które nie czekają z dostępem do magistrali danych na drugą połowę cyklu, tylko wysyłają dane od razu, kiedy tylko na magistrali adresowej pojawi się ich adres. Ponieważ adres pojawia się już po kilkudziesięciu nanosekundach od początku cyklu, więc krótko potem na magistrali danych pojawiają się dane z zaadresowanego urządzenia. W systemie ze zwykłym procesorem nie ma z tym żadnego problemu. Jeśli jednak zamiast 6502 jest 65816 (nie ma tu znaczenia, czy jest jakaś pamięć liniowa, czy jej nie ma) to dane z wywołanego urządzenia zderzają się z numerem segmentu wysyłanym przez procesor, co powoduje przepływ dużych, szybkozmiennych prądów przez linie danych, masy i zasilania. Zakłócenia generowane przez te prądy przenoszą się na inne sygnały - adresowe i sterujące. Jeżeli na to nałoży się jeszcze spadek napięcia od dużego prądu pobieranego przez dysk twardy, poziom tych zakłóceń (zagrożone są przede wszystkim linie adresowe) przekracza dopuszczalny margines i zakłóca współpracę z dyskiem. Z problemem można walczyć na różne sposoby. Najlepiej zlikwidować przyczynę. Przyczynę można zlikwidować na dwa sposoby. Oba kłopotliwe i pracochłonne. Po pierwsze - można zmienić układ podłączenia procesora 65816 na taki, jaki jest rekomendowany przez producenta, czyli zawierający bufor separujący procesor od magistrali danych w pierwszej połowie cyklu. To rozwiązanie byłoby najlepsze. Po drugie - można dokonać zmian w sterowaniu tych elementów w systemie, które są uzależnione tylko od adresu, a nie od fazy cyklu. Chodzi tu o OS ROM, BASIC ROM, kartridże i, niestety, także ROM i RAM wewnątrz IDE+. To rozwiązanie jest najkłopotliwsze, bo wymaga najwięcej przeróbek. Można też spróbować walczyć z problemem objawowo, czyli zwalczając skutki. W tym przypadku chodzi o zwiększenie marginesu dopuszczalnych zakłóceń. To rozwiązanie jest najprostsze, ponieważ wymaga tylko wymiany dwóch układów scalonych z zastosowanej serii HCT na serię HC, ale ponieważ nie likwiduje istoty problemu, a tylko go przypudrowuje, nie jest stuprocentowo pewne. W jakichś specyficznych, trudnych do przewidzenia, warunkach może dać o sobie znać. Opis podam później, bo w tej chwili komputer z dokumentacją jest bardzo zajęty i powiedział, że nie ma czasu na głupoty.
Co do drugiego  pytania, to odpowiedź brzmi - "a kto to może wiedzieć?". Pod warunkiem, że będą ustawione na różnych bitach PDVREG, oba powinny być widoczne i działać. A jak będzie w rzeczywistości, to zobaczysz, jak podłączysz.

12V na VPP nie wystarczy. Przydałoby się jeszcze 6V na VCC. Niektórych, zwłaszcza starszych EPROM-ów nie da się zaprogramować przy VCC=5V.

Ale ten kwarc, co to go Stryjek wymienił, nie znajduje przy silniku i obrotów nie zmienia. Zmienia tylko timingi przy odczycie/zapisie z głowicy. Trochę czasu minęło, więc już dokładnie wszystkiego nie pamiętam, ale na pewno nie manipulowałem prędkością silnika w takim zakresie. Pierwsze egzemplarze XFD601 kręciły się z prędkością 300rpm, ale potem przeszedłem na 360 i tak już zostało, bo tak było wygodniej. Wynikało to z tego, że stosunek 360/288 (rpm) jest taki sam, jak 10/8.333 (MHz), więc napęd obracający się 360rpm z kontrolerem taktowanym 10MHz jest rozwiązaniem optymalnym. Oczywiście wymagało to jeszcze zwiększenia o 25% częstotliwości rezonatora na płycie elektroniki napędu.

A gdzieś Ty usłyszał, że spowolni obroty silnika?

Myślę, że jednak w mniejszości. Jeżeli tak się dzieje, to prawdopodobnie w pierwszym przypadku z powodu błędu konstrukcyjnego - procesor nie czeka na przerwanie generowane po zakończeniu kroku (lub w ogóle go nie odbiera) ani nie sprawdza statusu, tylko sam odmierza czas, po jakim krok powinien być wykonany (a nie jest, bo w WD1770 dwa z czterech czasów do wyboru są dłuższe) a w drugim - napęd jest za wolny i gubi kroki. Wszystko to jest do skorygowania na drodze programowej.

Jakby jednak ktoś koniecznie chciał WD, to udało mi się znaleźć źródło, w którego zasobach znajduje się jakieś 60 sztuk WD1770 po 25zł/szt. To prawie dokładnie to samo, co WD1772, różnica jest tylko w nieco dłuższym czasie przeznaczonym na  krok głowicy.