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
A przy okazji. Mam pustą partycję 1Gb na Falconie. Partition type: GEM.
Partycja typu GEM nie może mieć 1 GB wielkości.
Ale jeśli da się jakoś inaczej przerobić partycję 1Gb na Logical Sector Size 512, to byłbym wdzięczny za wskazówki.
Nie da się. Przy logical sector size = 512 partycja może mieć najwyżej 32 MB.
Sparta SDX wydaje mi się zbyt skomplikowana aby można skopiować obszar $700..$2000 i liczyć na to że ruszy
Tak konkretnie, to nie do $2000 tylko do tego, co wskazuje MEMLO. Jeśli nie uszkodzisz niczego innego (zwłaszcza zajmowanego przez SDX banku ext), to po przywróceniu zawartości tego obszaru powinno ruszyć.
Pecus: nie ma sprawy. Zdradzisz, co konkretnie było w tej mapie takiego, co powodowało wykładanie się loadera?
No to mniej więcej miałem na myśli. Nie wątpię, że Pecus udostępni źródła. Wątpię tylko, że można napisać w pełni funkcjonujący SpartaDOS, który zajmowałby tyle miejsca, co inicjalizer (z MSDOS 4.3 na czele).
Tebe, na jakiej planecie żyjesz? :P
ja też nie zauważyłem
A to nie tylko tego. Ale może przeczytaj w końcu jakieś dataszity, to się dowiesz, dlaczego FGTIA tak, a PAL ani NTSC nie. Zmniejszy to problemowość (przynajmniej w tym wątku).
Ogólnie czekam z niecierpliwością na twój scandoubler dla PAL GTIA. Pamiętający całą ramkę i wyświetlający ją z dowolną częstotliwością ... myślę, że za takie coś wszyscy cię tu ozłocą.
znajdź mi miejsce, gdzie na Simiusa naskoczyłem - albo może lepiej nie znajduj, bo zaraz znajdziesz też i miejsce, gdzie śrubki w atarkę wkręcone są krzywo, a Rockfordowi kapelusik przekrzywił.
Tu:
Simius, te "artefakty elementów jednoliniowych" mogą niestety być powodem tego, że Twoja praca będzie całkowicie nieprzydatna - dlatego uważam, że dla GTIA gra jest warta świeczki.
W tym miejscu pleciesz od rzeczy zarzucając Simiusowi, że jego projekt jest "całkowicie nieprzydatny" i powinno się go podpiąć do GTIA, nie zastanowiwszy się wpierw nad tym, że gdyby to było takie proste, jak ci się wydaje, to autor raczej zrobiłby to z własnego popędu.
I jeszcze na dodatek wymachujesz przy tym dataszitem od FGTIA, zupełnie, jakbyś go sam dokładnie przejrzał :P
PS.1. Co do artefaktu, widziałem go, jest brzydki. Ale 1) pewnie się można do niego przyzwyczaić, skoro można się przyzwyczaić do wstrętnych pasów, rozmyć i odbić, jakie się dostaje z wyjścia CV, oraz 2) sądzę, że jest to doprawdy niewielka cena za uzyskanie obrazu na VGA.
PS.2. Nie, ani przez chwilę nie wierzyłem w EOT. :P :D
@Adam: no cóż, po prostu, przypuszczam, tu i ówdzie poszli na łatwiznę.
dlatego uważam, że dla GTIA gra jest warta świeczki.
sprawdziłem (#7), że jednak jest to możliwe dla GTIA
To rób, kto ci nie daje. Simius na pewno udostępni ci schemat, przystosujesz sobie. Ciekawe tylko, że sam nie wpadł na to, żeby istniejący układ dostosować do PAL GTIA, nie? :P Dopiero musiał przyjść maw, i na niego naskoczyć.
Ech ... <facepalm>
Czytałem. W ogóle czytałem cały wątek. Po prostu sugeruję ci, żebyś się zastanowił, dlaczego autor zrobił scandoubler dla FGTIA, a nie dla PAL-owskiego GTIA - zanim zaczniesz marudzić, że to nieprzydatne i lepiej jest zrobić dla GTIA PAL (post 9). Bo być może są jakieś przeszkody. Zresztą pewnie do wyczytania w dataszicie FGTIA. Czytałeś go? :P
@Adam: mam na myśli maxima dla poszczególnych wielkości klastra. 32 MB to 65536 klastrów po 512 bajtów. 1 GB to 65536 klastrów po 16k. W obu przypadkach FAT zajmuje tyle samo. Ergo: to nie bufor na FAT powoduje ograniczenie wielkości dysku. Zdziwiłbym się poza tym, gdyby w GEMDOS-ie w ogóle istniał taki bufor przeznaczony do trzymania całego FAT-u[1].
[1] Dla uniknięcia bicia piany: nie, NIE mam tu na myśli cache'u na FAT, jaki sobie zakładają sterowniki twardego dysku.
dlatego uważam, że dla GTIA gra jest warta świeczki.
Może najpierw zapytaj, DLACZEGO scandoubler powstał dla rzadko spotykanego FGTIA, a nie dla ogólnie dostępnego PAL-owskiego GTIA :P
FAT jest tej samej wielkości, czy partycja ma 32 MB czy 1 GB: ma 65536*2 bajty = 128k. Natomiast co do bufora na sektor, to istotnie, możesz mieć rację.
No mnie się mgliście kojarzy, że wbrew temu, co napisano nieco wyżej, TOS 2.06 (i 3.06) obsługuje co najmniej 512 MB. W sumie nie ma chyba wyraźnego powodu, żeby 1 GB to był jakiś problem, bo to jest 65536 klastrów po 16k - dopiero 32k się przestaje mieścić na 16-bitowych zmiennych (ze znakiem).
Ja bym osobiście wolał mieć rdzeń FX i dodatkowy scandoubler, niż rdzeń GTIA-VGA. A to choćby dlatego, że zdążyłem się już przyzwyczaić do 80-kolumnowego trybu tekstowego.
Z tego, co tam mozna wyczytać, ważne jest dla nas to:
1. Partycja TOS - 32MB
To nie jest partycja TOS, to jest partycja "GEM".
2. TOS obsługuje też partycje BGM - do 1GB
Ile może mieć partycja BGM, to oidp zależy od wersji TOS-u (a konkretnie GEMDOS-u). 1 GB to chyba dopiero TOS 2.06.
4. Bootowanie z HD - od TOSa 2.0 wzwyż
Nie. TOS np. 1.04 też bootuje się z HD, tylko pod warunkiem, że to jest dysk podpięty przez port DMA. Natomiast TOS 2.0 potrafi się bootować z IDE (czego poprzednie TOS-y nie umieją). Ale to dotyczy tylko atarowskiego host adaptera IDE, takiego jak w Falconie. Jeśli ktoś podepnie IDE przez port DMA i interfejs "udający" ACSI, to TOS 1.x powinien z niego startować.
Mnie zastanawia natomiast jedno. System jest właściwie kompatybilny z DOSem, tam limit jest bodajże (FAT16) 2GB, więc pewnie TOS taką partycję też powinien obsłużyć bezproblemowo (jak ktoś ma taki dysk - poprosimy o testy - chodzi o pojedyńczą partycję).
Zdaje się, że dyski do 2 GB ma obsługiwać GEMDOS Falcon TOS-u (4.04), ale nie wiem, czy nie ma w tej obsłudze jakichś błędów.
do wódki
Zaraz, zaraz, pamięć już nie ta - ale kto to i gdzie narzekał, że na zlotach wódkę piją? ;)
Dawaj, ja mam same takie dyski :P
No, załóżmy, że "T" nie reagowało. Może tak być (od biedy) jeśli kod formattera się skaszani wskutek np. żle kontaktującego karta. Ale b. dziwne byłoby, gdyby to był jedyny objaw takiego niekontaktowania.
Tak czy owak, gdyby to potrwało jeszcze trzy dni, to mielibyśmy okrągłe 2 miesiące wątku pt. jak sformatować dyskietkę.
no działać działa, ale można wybrać tylko 90/130/180kb...
OK, to może przeczytaj instrukcję. Chociaż wydaje mi się, że formatter jest na tyle prosty, że każdy nawet bez jej czytania by już na to wpadł. Wystarczy spojrzeć na menu:
Pytanie retoryczne: co należy wybrać (czyli wcisnąć), żeby zmienić format 180k na np. 360k?
no to w końcu jak to jest? czy Ktoś może mi jasno wprost wyjaśnić dlaczego na moim SDX 4.42 po dołączeniu do APE nie mogę wybrać gęstości 360k/720k?
A "F" (tzn. format) w ogóle ci działa na takiej "dyskietce"?
Kurzu? Może jednak ruszyłeś jakimiś kabelkami w środku przy okazji i to pomogło - patrz sugestia macgyvera o zimnym lucie i tym podobnych.
No, ale zresztą co tam. Skoro pomogło, to dobrze :)
"Dolna" głowica to jest głowica nr 0 (czyli ta od pierwszej połowy dyskietki).
Jak na trafiony napęd, to objawy są dziwne. Bardziej podejrzewałbym, że uwalony jest ROM stacji, zamiast kodu jest w jednym miejscu (albo paru miejscach) sieczka i dlatego przy niektórych funkcjach się wiesza. No ale to tylko takie podejrzenia, w sumie to może być wszystko.
po zmianie formatu nic nie jest wysyłane do stacji...
A kto, robaczku, kiedykolwiek pisał tutaj, że "po zmianie formatu" cokolwiek jest wysyłane do stacji?
Ty to sam sobie osobiście ubzdurałeś, i nie dałeś sobie przetłumaczyć, że jest inaczej.
kiedy można spodziewać się wydania nowej wersji SDX?
Nie jest to jeszcze ustalone.
"Niestabilność" MiNT-a wynika z dwóch TOS-owych zaszłości, które przekładają się na dwie wielkie dziury w ochronie pamięci:
1) ochronie nie podlega pamięć BIOS-u, sterownika twardego dysku i wszystkich programów załadowanych z AUTO przed MiNT-em. Każda (przypadkowa) ingerencja w ten obszar może się skończyć tragicznie.
2) jeden proces - konkretnie AES - ma specjalny przywilej bezkarnego zapisu danych do pamięci aplikacji, nawet jeśli ta pamięć jest chroniona. AES natomiast nie jest stuprocentowo odporny na nieprawidłowe parametry zawarte w global array w chwili jego wywołania - z czego wynika, że przy odrobinie szczęścia (pecha) można skłonić AES do zapisu danych w chroniony obszar i uwalić system.
To drugie można rozwiązać na dwa sposoby:
1) przenosząc AES całkowicie do userspace i likwidując jego odrębność od wywołującej go aplikacji. AES działałby wtedy jako zwykła biblioteka (dzielona) a wszystkie jego operacje wykonywane byłyby "w imieniu" procesu użytkownika (czyli w imieniu aplikacji GEM). W przypadku naruszenia ochrony pamięci uwaleniu ulegałaby aplikacja, a system pozostawałby nienaruszony.
To był mój pomysł, którego Frank chyba nawet nie był w stanie zrozumieć (nie znał się zupełnie na GEM-ie).
2) przenosząc AES całkowicie do kernelspace i likwidując jego odrębność od kernela. AES działa "w imieniu" procesu użytkownika (w imieniu aplikacji GEM). W przypadku naruszenia ochrony pamięci uwalana jest aplikacja, a system pozostaje nienaruszony - niestety, AES w tym przypadku działa z prawami kernela (nie wiadomo, po co), więc śmiecie w global array ciągle mogą spowodować zniszczenie całego systemu.
To jest to, co zostało zrobione w postaci modułu kernela XaAES.
MagiC natomiast jest niestabilny sam z siebie, przypuszczalnie z powodu błędów w kernelu i spółce, i jest sobie w stanie sam tak namieszać w swoim własnym wnętrzu, że się wywróci po zadaniu mu np. kopiowania pliku jego własnym desktopem.
atari.area forum » Posty przez drac030
Wygenerowano w 0.136 sekund, wykonano 21 zapytań