Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
HDDRIVER 13.01 Aktualizacja HDDRIVER przynosi poprawki dla HDDRUTIL oraz lepszą obsługę szybkiego sprzętu.
192p Test Suite dla 8-bitowego Atari Nowy program do testowania i kalibracji obrazu dla Atari XL/XE od HanJammera.
Atari800 7.0.0 Pierwsza wersja emulatora z funkcją pobierania z sieci i mnóstwem nowości.
Obrazy w 1024 kolorach na VBXE Nowy konwerter i przeglądarka obrazów dla rozszerzenia VBXE pozwalają wyświetlić aż 1024 kolory.
Gearlynx 1.2.15 Emulator Atari Lynx doczekał się ważnej aktualizacji z wieloma nowymi funkcjami.
atari.area forum » Posty przez drac030
Sikor, zluzuj. Kaczyński był prezydentem Warszawy pięć lat temu, było pięć lat na wylewanie pretensji, teraz odpuść, on nie żyje.
Sugerowano lot do Moskwy lub Mńska (zgoda była) - ale my wiedzieliśmy lepiej.
Ty też, jak widzę, jesteś nieźle poinformowany. Siedziałeś w kokpicie tego samolotu czy na wieży kontroli lotów?
No ale niedziałanie konkretnych 3 gierek to jest jednak wina mojego sprzętu - w każdym razie mają prawo nie działać, bo - przepraszam, zapomniałem - nie mam dolutowanego słynnego kabelka udostępniającego pamięć od $8000 do $FFFF dla MEMAC A. Więc pewnie to jest przyczyną.
No, czyli Candle miał rację.
pajero, jeśli chodzi tylko o to, że Śniegowy ma TF, no to chyba nie on jeden :P
Ocb z tymi doświadczeniami Śniegowego? Miał jakieś jazdy?
Ale są one na tyle fajne i jest tych programów na tyle mało, że fajnie byłoby nie tracic możliwości ich uruchomienia wraz z nowym rdzeniem. (...) Jedynie nieoficjalna Misja i Mr Plum są wyjątkami, także wielkiego dramatu nie ma ;)
Jeśli ktoś ma rdzeń 1.22, a stęsknił się za demem Mr. Propera, to może zadziała plik dołączony do tego posta. To oczywiście póki Madteam nie uaktualni binarki na swojej stronie.
PS. Z "przypadkiem", którym działają produkcje XXL-a: coś w tym jest, wczoraj ściągnąłem JSW, NightDriver i NightShade (czy jakoś tak) ze strony Madteamu i niestety, na rdzeniu 1.22R nie chodzą. Może wymagają A?
Chyba znam ten objaw. Emulec a800win zapisy do plików ATR jakoś buforuje, dlatego można się naciąć mając ten sam plik podpięty jednocześnie do emulatora na pececie oraz do Atari przez kabelek. Tego, że plik został poprawnie "uaktualniony" po zapisie spod emulatora, można być pewnym dopiero po tegoż emulatora zamknięciu.
Bez tego np. kopiujemy plik binarny DOS-em pod emulatorem na plik ATR, a przy próbie odczytu tego pliku z tego ATR-a na Atari dostajemy "not binary file" :P
Czyli różnica wynosi od 14 (FO0) do 26% (OSC), tymczasem na zdjęciu pajera różnica grubości pomiędzy pionowymi liniami hiresu wynosi na oko z połowę - widać to na tekście wyświetlanym przez SysInfo (listwa na górze, box z lewej, zwłaszcza litery D, M, T, A itp.)
PS. Oczywiście, w tej chwili się czepiam, wynik poprawki i tak jest rewelacyjny, bo po jej zaaplikowaniu wadliwe GTIA jest w ogóle w stanie wyświetlić czytelny obraz, i to w demach, które się nie patyczkują. Nawet jeśli zostają usterki, to są w sumie minimalne w porównaniu do nieskompensowanej wady.
Unity by Our5oft, o ile dobrze kojarzę. Tam jest efekt z trzema trybami graficznymi w poziomie (kolejno: 8, 9 i 15).
Co do hiresu, to może oczekuję cudów :) Wydaje mi się jednak, że to nie tylko monitora wina. No, ale może mi się wydaje...
3. ILUSIA - wysypuje się na 2 efektach :(
Tia, pewnie dlatego, że to demo przełącza potem tryb na 15. Skutek jest, jak dla mnie, dziwny, bo tak jakby rozjeżdżała się synchronizacja pozioma. Sprawdzałeś może, czy na Unity jest tak samo?
PS. Ale hires w tym komputerze nadal paskudnie wygląda, mam wrażenie, że "dobre" GTIA generuje lepszy, tzn. piksele powinny być w miarę równej wielkości, a tu linie pionowe są raz grubsze, a raz cieńsze.
GTIA, które poprawnie generowały gr.9-11 też miały z tym problem
Czyli były to GTIA "z wadą typu drugiego", bo dobre GTIA to znosi. Ciekawie byłoby przyjrzeć się datom produkcji tych scalaków, czy to jest ten sam zakres, co w przypadku wady "typu pierwszego", czy też nie.
@teddyboar: wierszyk ci się w sygnaturce popsuł.
To by było niezłe. Ale sprawdź jeszcze, czy działa dobrze przy przełączeniu trybu w środku linii z gr.8 na gr.9 (demo Unity, SysInfo albo coś takiego).
plytka tez ogromniasta, do tego adaptor od Idea i robi sie pociag jak za spectrum.
Nie, i to jest następna zaleta adaptera. TF XL wetknięty do komputera nie zajmuje dużo miejsca za kompem, bo płytka jest ustawiona pionowo. To wersja XE robi "pociąg".
Tak, ja rozumiem, ale jednak "skalę zjawiska" pokazałeś w sposób niezbyt polityczny: przykładem, który się dał bardzo łatwo zbić. Ogólnie, pamięć ekranu VBXE jest duża i to wie każdy, kto umie pomnożyć np. 320 przez np. 192. Ale od tego własnie jest blitter, żeby odciążyć w tym CPU.
Ośmielam się zatem domniemywać, że, na przykład (zważywszy istnienie blittera, który nie dość, że jest sam w sobie szybki, to jeszcze może działać na VRAM-ie "jednocześnie" z CPU), druciana wektorówka byłaby (nie sprawdzałem) na VBXE o wiele łatwiejsza do realizacji niż w trybach graficznych ANTIC-a.
I już nawet pominę, że przy użyciu VBXE można wyłączyć ANTIC, czyli zyskać te 20-30% szybkości CPU.
BTW. blitter VBXE można wykorzystać też w standardowych trybach graficznych ANTIC-a.
zaxon, istotnie, przypuszczalnie masz rację, ale zwróć uwagę, że taki adapter jest w miarę uniwersalny: podpinasz przez niego do XE: IDEę, Turbo Freezer XL i bógwico-jeszcze pasujące tylko do PBI. Więc o ile na potrzeby wyłącznie TF może się to istotnie niezbyt opłacać, o tyle może się bardziej opłacić zamówienie takiego adaptera w celach, że tak powiem, ogólnoatarkowych.
PS. oczywiście ja się nie znam, a poza tym, niestety, ja już taki adapter mam.
Jak mówię, dobry jest adapter od IDEa, tzn. to: http://atariki.krap.pl/index.php/Grafik ... pcb_2a.jpg Gdyby - teoretycznie - był dostęp do takowych, to freezery można byłoby wykonać w wersji XL.
tam jest 320x200 w 256 kolorach. to daje 64000 ramu. 6502 potrafi zapisac liczbe we wskazanym miejscu w 4 cyklach. prosty rachunek - do wyczyszczenia procesorem calego ekranu potrzeba conajmniej 256000 cykli. 1 ramka (1/50 sekundy) ma cykli cos ponad 30000, wiec potrzeba 8.5 ramki zeby to zrobic.
Bober, te rachunki są do bani. 64000 bajtów video RAM-u Blitter VBXE wypełnia (np. zerami) w 0,0045 sekundy (~8 tys. cykli zegara CPU, czyli mniej niż 1/4 ramki). A zapalenie punktu w 320x192/256 jest szybsze i prostsze niż w np. GR.8, bo piksel to 1 bajt, a nie jeden bit (odpada AND, OR itp.)
Jakby były czarne, to ja chcę czarne. Co do rozmiaru, muszę się zastanowić. Chyba że umawiasz na przymiarki ;)
Ja poproszę dwie granatowe, rozmiar XXL (chyba?). Mam nadzieję, że to będzie logo Atari, a nie INFOGRAMES? ;)
PS. Chętnie odbiorę przed Grzybsoniadą.
@wieczor: kabelka nie trzeba spawać, wersja XL odbiera 5 V z PBI, rzecz tylko w tym, żeby komputer to podawał.
Mogę dodać, że to emuluje kartridże (wgrywa się tam soft flaszerem z poziomu Atari), i w ramach tego można tam wrzucić SpartaDOS X 4.4 (jest specjalny build SDX dla Turbo Freezera 2005).
Do grzebania w NV-RAM-ie jest, jak pisze Kroll, moduł CPX, albo program dostarczany przez Atari Corp. na dyskietce systemowej (SETUP.APP bodaj, czy jakoś takoś), ... chyba że mi się już myli, bo dawno Falconam na oczy nie widział. Ale myli mi się najwyżej z jakimś innym programem służącym do tego samego :)
A jak się nazywało to ze sławojką?
@pin: bo pewnie w NVRAM-ie jest ustawione NTSC? M0 i M1 służą nie do przełączania trybów wyświetlania, tylko mówią Falconowi, jaki monitor jest podpięty (VGA, RGB, ST Mono albo TV).
Ja bym też wziął jeden, bo się przyzwyczaiłem (tamten, cośmy z trubem mieli, "się" popsuł :( )
Wersja XL.
Info dla zainteresowanych: wersja XL też pasuje do XE, jak się ma przejściówkę od IDEa. W zasadzie jak się ma zewnętrzną IDEę, to tylko TF dla XL wchodzi w rachubę.
atari.area forum » Posty przez drac030
Wygenerowano w 0.144 sekund, wykonano 21 zapytań
