Ale firmware interfejsu nie przewiduje bootowania z obszaru znajdującego się poza partycjami. Nie wiem zresztą, do czego to miałoby być potrzebne.

Obsługi ATR-ów nieskopoziomowej nie ma i póki co - nie będzie. Ja rozumiem, że wszyscy mają wiele świetnych pomysłów, w rodzaju, żeby np. interfejs miał menu sterujące, zaszyty w ROM-ie kopier sektorowy, możliwość bootowania z pliku (czyli podstawową obsługę filesystemu) oraz equalizer, ale weźcie pod uwagę, że interfejs ma TYLKO TRZY KILOBAJTY ROM-u, więc niby gdzie to ma się zmieścić?

Niech ktoś zbuduje wersję IDEa z dostępem do całego ROM-u to pogadamy.

Sens. Czyli stosunek rezultatu do nakładu pracy.

U mnie widać. Czarna nitka cieniutka (tak na oko, 2x cieńsza niż szerokość piksela w GR.8), za to biała normalnej grubości (jak piksel w GR.15, zdało mi się).

Trzeba parę minut poczekać, u mnie ludki kilkakrotnie (z pięć razy) się zatrzymywały i wciskałem START, żeby je poszczuć od nowa, aż w końcu pająk zaczął się pokazywać. Wyłazi na drzewie oraz na trzepaku.

Sprawdzałem na jednej maszynie, 65XE z 1987 roku.

A rozwiązanie na LPT wymaga sterowników zaszytych w systemie, bo chyba nie wyobrażasz sobie, że programem aplikacyjnym działającym w systemie multitaskingowym wygenerujesz stabilne przebiegi sygnałów dla transmisji szeregowej nawet dla 19200 bps. Czyli kłopot pt. "kto to oprogramuje" jest taki sam, jak w przypadku USB. Już widzę te drajwery pod Windows XP, Linuxa, BSD :P

"Dokumentację do atarowskich turbo" możesz znaleźć w Atariki.

pin: a co ci nie pozwala zabootować gierki z hdd?

PS. w kwestii file'a - autor żyje do tej pory? Podejrzewam, że tak. Więc może _poprosić_ go o przeróbkę.

Chcesz powiedzieć, że wyciągnięcie wtyczki z gniazdka nie pomaga? :P

Bynajmniej. To ważny szczegół - dlatego też, jak zresztą napisałem wyżej i electron się zgodził, lepiej jest tego psucia uniknąć. A w jaki sposób to zostanie zrobione, to już jest up to him.

alp: RAM jest dobry, na ekranie masz napisane, że test "PASSED".

"Bank #0 integrity" to test na stabilność odczytów z ROM-u. Błąd oznacza, że odczyty z ROM-u nie zawsze dają takie same wartości, a numerek hex obok, jaki tam się wyświetlił, to adres, pod jakim wykryto różnicę.

W ROM-ie jest w zasadzie sam kod, więc jeśli przy odczycie pojawiają się jakieś zakłócenia, to ja się wcale nie dziwię, że komputer się zawiesza.

PS. Ja nie wiem, jaka jest przyczyna - program podaje po prostu, co nie działa orawidłowo, a przyczyn, dlaczego to nie działa prawidłowo, może być pewnie tyle, co punktów lutowniczych między ROM-em interfejsu a procesorem.

Chyba sobie sami odpowiedzieliście :P

Sikor, wiem co mówię, zastanów się łaskawie, jak dysk może czegoś "zażądać" od komputera bez wiedzy o tym, co komputer właśnie robi.

W jaki sposób? Dysk jest "bierny", reaguje tylko na komendy płynące z komputera, sam natomiast z siebie niczego nie żąda (no i słusznie, to wymagałoby wywołania jakiegoś przerwania). Może zahasłowanie dysku jest jakoś sygnalizowane w idencie albo rejestrach, trzeba siąść i poczytać doce, ale ja chwilowo nie mam na to czasu.

Ja nie mam. Musiałbym zdobyć taki dysk i sprawdzić. Czy to jest jakiś konkretny typ dysku?