Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Flob wkracza na Atari ST Platformówka z 8-bitowego Atari zmierza na komputery z serii ST.
Return to Blacktooth dla Atari ST Nowa, izometryczna przygoda w stylu Head Over Heels już dostępna na komputery Atari ST.
VBXETERM 0.12 Nowa wersja emulatora terminala VBXETERM z poprawionym SSH i lepszym wsparciem VT100.
Echa GemTOS 2026 Prace z tegorocznej edycji francuskiego zlotu GemTOS poświęconego komputerom Atari.
BigPEmu 1.22 Nowa wersja emulatora Atari Jaguar od Richa Whitehouse wprowadza wsparcie dla kodów cheat.
atari.area forum » Posty przez drac030
to Ty mi odpowiedz na bitrate w WD279x...
5x ci już na to odpowiadali, ale jeśli nie przyjmujesz tej odpowiedzi do wiadomości, to jest, kolego, twoje zmartwienie.
PS. jellonek, faktycznie, pytanie było za trudne. Albo po prostu za długie.
PS2. Moim zdaniem jest to troll.
Panowie, proszę nie rozpraszać kolegi bezrobotnego, jestem ciekaw odpowiedzi na moje pytanie.
... to właśnie jest scena atarowa ... co chwilę Ktoś się czepia za nic ...
"Za nic" - oczywiście. A że tak z czystej ciekawości zapytam, jakiej w zasadzie reakcji oczekujesz na swoje zachowanie?
A ja mam takie pytanie do wszystkich, którzy mają dostęp do komputerów z FGTIA (Simius, Sikor, Bitman, Pasiu, Jer, może ktoś jeszcze):
1) z jednej strony mamy informację, że $D014 = $01: http://atariarea.krap.pl/forum/viewtopi ... 09#p100909 (ten wątek, post #13, by Simius)
2) dataszit od FGTIA twierdzi to samo (że ma być $01)
3) a z trzeciej strony mamy raport, że $D014 = $00: http://atariki.krap.pl/index.php/Dyskusja:FGTIA (Atariki, by Sikor)
Czy mógłby ktoś rozstrzygnąć, czy chodzi tu o różne wartości zwracane przez różne egzemplarze FGTIA (np. z różnych serii) czy też może zachodzi tu jakaś pomyłka. Nr seryjny FGTIA w kompie Sikora to C020120-01 (może ma też jakąś datę produkcji?).
Jeśli program ma się ładować pod rozsądnym DOS-em, trzeba przyjąć minimalne memlo = $2000. Natomiast asekuranckie minimalne memlo dla loadera to będzie pewnie $0C00 (ogólnie loader łatwo może mieć mniej, pod warunkiem, że to nie jest format SDX i dysk z 512-bajtowymi sektorami, wtedy zaczyna się problem ze zmieszczeniem wszystkiego pomiędzy $0700 a $0BFF - a dobrze by było móc gierki ładować z takiego dysku, bo to i pojemność większa i szybkość znacznie lepsza).
moglbys tez powiedziec gdzie dla sdx/kmk jest w miare bezpiecznie cos ulokowac podczas ladowania?
1. $100-$17f stos
2 $480-$4ff bufor basica
3. $580-$5ff bufor fp
4. $600-$67f
5. $680-6ff
Wszystkie te miejsca są "bezpieczne". BIOS dysku używa paru komórek na stronie zerowej, których przy pracy ze zwykłą stacją dysków używa SIO (adresy $30-$40). Poza tym korzysta tylko ze swojej wewnętrznej pamięci RAM, która, jak już to jest wyżej napisane, podczas transmisji pojawia się pod $DE00.
SDX podobnie. Poza tym bufor magnetofonu i spółka ($0400-$05FF) oraz stos ($0100-$017F) zostanie nadpisany przez formatter, kiedy wywołasz z programu XIO 254 i każesz sformatować dyskietkę, a bufor FP może być nadpisany przy wywołaniu niektórych funkcji specyficznych dla SDX (w rodzaju: otwarcie pliku z poszukiwaniem go wzdłuż ścieżki dostępu). Pobieranie parametrów z linii komend itp. może spowodować podpięcie kartridża na chwilę (pod $A000-$BFFF). To chyba wszystko.
mono: font jest zapisany w postaci bitmapy (obrazka) o wymiarach oidp 192x8 - co do liczb mogę się mylić, ale ten rozmiar zapisany jest w nagłówku fontu.
PS. font 8x16 wygląda na małym Atari obleśnie, nie wiem dlaczego. Na ST (mono) był OK.
True. "ROM włączony" nie oznacza, że urządzenie PBI nie podepnie swojego RAM-u w obszar $d800-$dfff. Aczkolwiek na naszym interfejsie próba bezpośredniego I/O pod ten adres powinna dać w tym momencie error 139. Ale tak poza tym to kwestia loadera, powinien taki zapis czy odczyt zbuforować.
Wszystko jest dla ludzi z głową na swoim miejscu.
Lista części w Atariki wzbogaciła się o 45 numerów katalogowych wraz z nazwami bytów elektronicznych, których chwilowo nie umiem do niczego przypisać. Tymczasowo wrzuciłem je jako części niezidentyfikowane:
Gdyby ktoś wiedział, jakie to są konkretnie części oraz od czego, to proszę o info tutaj albo wprowadzenie informacji bezpośrednio do hasła. Część tego towaru może być od Atari 1450XLD i tym podobnych wynalazków.
Hyh, nawet nie wiedziałem. Człowiek uczy się całe życie.
Zanim podejmiesz drastyczne kroki, zresetuj NVRAM. Jeśli jakimś cudem ustawił się tam niemożliwy do zrealizowania defaultowy tryb graficzny, to efekt będzie zbliżony.
Można to zrobić na dwa sposoby: 1) podpiąć monitor mono (wtedy Falcon olewa ustawienia NVRAM-u), 2) zabootować dyskietkę z odp. programikiem w bootbloku (powinien być gdzieś na sieci, może inni podpowiedzą/podrzucą).
A ja się od jakiejś godziny zastanawiam, ile czasu może jeszcze potrwać w-ząbek-czesane "skanowanie w poszukiwaniu wirusów" ściągniętego z internetu pliku. Albo np. dlaczego kasowanie długiego pliku z kosza trwa jak nie przymierzając pod MyDOS-em.
A owszem, był na tyle uprzejmy, żeby umożliwić bezbolesną współpracę, za co należą mu się podziękowania, bo jest mądrym człowiekiem :P Więc nie jest to potrzebne (ani sensowne, tak poza tym, czy też praktyczne możliwe).
No to rób tak dalej, przecież nikt ci nie broni. SDX w każdym razie "monitorować MGE" nie będzie.
Jak chcesz, żeby u nikogo nie działało, to podpinaj, droga wolna. Co do priorytetu memaca, masz jeszcze to i owo do przeczytania, np. manual od VBXE.
nie wiem czy sdx nie potrzebuje patcha do wspolpracy z vbxe.
Nie potrzebuje. Electron był na tyle uprzejmy, żeby dostosować rdzeń FX do współpracy z SDX.
Co to są "ustawienia banków pamięci" i jak w nich można namieszać?
Prędzej po prostu zablokowaleś dostęp do ext albo (przy rdzeniu R) nadpisujesz bank, który zajmuje SDX.
taki driver jest banalnym malym cosiem
Pomijając hinty (w rodzaju: każdy z pomienionych driverów jest takim właśnie małym cosiem, ale jedne z nich są lepsze, drugie gorsze, a jeszcze inne niekompatybilne), masz 100% racji. Obsługa 1 funkcji BIOS (Rwabs), 2 funkcji XBIOS (DMARead/DMAWrite) oraz XHDI, jeśli nie będzie zawierała bagów, powinna załatwic sprawę.
No widzicie, nie przekonaliście kolegi, on wie, że musi się gdzies w kontrolerze WD ustawiac bitrate, bo przeciez sa trzy prędkości. Nie znata się i tyle...
Candle: moze powtórzę - driver NIE obsługuje FS, FS obsługuje GEMDOS, który jest w ROM-ie. ;P
Co do sterowników, pomerdało mi się, to Hushi nie chciał mi zobaczyc nic ponad 1 GB, a nie CBHD.
CBHD nie chciał mi obsługiwać dysku IDE większego od 1 GB (oidp).
ICD Pro ma dwie wady:
1) "swój" format tablicy partycji, niezgodny z AHDI
2) brak obsługi tzw. XHDI (interfejs programowy udostepniający różne funkcje niedostępne przez BIOS)
Tak ogólnie to jedyne, za co driver odpowiada, to podział dysku na partycje. TOS zawiera procedury odczytu/zapisu sektorów (w BIOS-ie) oraz obsługę filesystemu (w GEMDOS-ie). Takie AHDI (albo ICD Pro albo HD-Driver albo Cecile albo co tam) ma za zadanie przetworzyć "surowy" dysk w ileś tam dyskow logicznych (partycji) i doczepić je do systemu tak, żeby widział je BIOS. Reszta działa sama.
Przecież jest "darmowy" driver, tzn. ten, który Atari dodawało do każdego komputera na dyskietkach systemowych, czyli AHDI. Ostatnia wersja miała chyba numer 6.0. Jeśli ktoś nie chce płacić za HD-Driver Seimeta to chyba jest jakaś opcja.
jellonek: jesteś chory z nienawiści.
atari.area forum » Posty przez drac030
Wygenerowano w 0.167 sekund, wykonano 15 zapytań