Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Mad Pascal 1.7.5 Mad Pascal, 32-bitowy kompilator Turbo Pascala dla Atari, otrzymał aktualizację do wersji 1.7.5.
Altirra 4.40 test 26 Nowa wersja testowa popularnego emulatora Altirra z licznymi poprawkami, zwłaszcza dla emulacji urządzeń sieciowych i modemów.
Gopher 2600 z nową wersją 0.50.3 Poprawkowa aktualizacja zaawansowanego emulatora Atari 2600.
Steem SSE 4.2.0 R5 Aktualizacja popularnego emulatora Atari ST, Steem SSE, skupiająca się na poprawie stabilności i dokładności.
Piąte demo konwersji Elite Piąta wersja demo konwersji kosmicznego symulatora Elite na Atari 8-bit z poprawkami wydajności.
atari.area forum » Emulacja - 8bit » Atari800Win PLus 4.1 beta 2
Strony Poprzednia 1 2 3 4
Zaloguj się lub zarejestruj by napisać odpowiedź
Wszystkie liby masz w projekcie nie musisz nic instalować.
Wywalenie ddraw i dinput to usuwanie/przerabianie na oko 10% kodu emulatora. Na którykolwiek plik nie spojrzę to są tam odwołanie do zmiennych używanych przez obsługę grafiki. Doskonale wiem, że muszę przerobić cały podsystem wyświetlania ale jak tylko spojrzę ile tego jest to mi się nogi pode mną uginają.
Zrzuta na krzesełko dla Jaskiera co by nie upadł ? :)
Oryginalny atari800 jako multiplatformowy musi robić wszystko softwarowo, ale port pod windowsa operacje na obrazie (szczególnie takie proste) powinien robić na karcie.
Panie, ale przecież Atari800 multiplatformowo akceleruje grafikę OpenGL-em.
laoo: najważniejsze to zlinkować drag&drop.lib, a resztę sobie wyklikasz :D MSPANC ;)
Niestety ddraw.lib ani dinput.lib nie są dostępne bez instalowania archaicznych SDKów. Trochę pohakowałem i odpaliłem, ale pierwszy raz od nie pamiętam kiedy musiałem zresetować komputer - po (w sumie przypadkowym) włączeniu trybu 1024x768, full display, bo nie dało się nic zrobić. Aplikacja zamarła i zabijanie procesów nie pomagało. Te ustawienia naprawdę są niebezpiecznie i trzeba się ich pozbyć. Wg mnie w dzisiejszych czasach tryb full-screen powinien nie zmieniać rozdzielczości desktopu. Nie wspomnę, że odhaczenie GDI (a więc używanie ddraw) wyłącza mi aero pod win7.
Popatrzę się trochę na to i zastanowię jakie kosztowne byłoby całkowite wyrzucenie ddraw. Może da się zrobić to tanim kosztem, bo z tego co widzę, to cała magia sprowadza się do wyświetlenia bufora spod adresu Screen_atari.
Mając świadomość, że nieco późno na bugfix, kiedy zdążyła wyjść już wersja 4.1, zgłaszam jednak babola.
Dotyczy on obsługi "wysypania się" atari, czyli "When Atari crashes". Otóż niezależnie od tego, co jest zaznaczone, po "wysypce" od razu następuje przejście do monitora. Ja np. mam tu zaznaczone "Ask what to do", niestety emul się o nic nie pyta. Teraz próba wpisania "quit" kończy się wyjściem... tylko z emulatora, okno monitora natomiast zostaje.
W załączeniu plik, na którym testowałem rzeczony błąd (jest to plik z pierwszej strony XFiles Intro); a błąd jest powodowany brakiem DOSa, podczas odwołania się do urządzenia D:.
Aha, pracuję pod Win XP Pro SP3. :)
Problem Cypriana już znalazłem. Faktycznie nie zainicjowana była przy starcie emulatora tablica lookupów do palety używana przez algorytm smooth.
W ogóle cała inicjalizacja emu to jeden wielki śmietnik. Ciężko określić co jest kiedy inicjowane a niektóre funkcje zależą od siebie i muszą być uruchomione w odpowiedniej kolejności.
@miker
Jesteś już drugą osobą, która mi to zgłasza. Faktycznie będę musiał coś z tym zrobić.
A, problem, przytoczony przez Foxa, z próbą otwarcia emulatora i przejściem do okna z tym topicem, również działa w IE8. :)
W przypadku problemu mikera to występuje on wtedy, gdy pamięć ram emu ustawiona jest na 1088 KB. Przy ustawieniu na 320 KB (Rambo), a tyle demo wymaga, jest ok.
w trybie smooth wzrost z 2000% do 3200% po przełączeniu się z asm na C++
w trybie scan lines brak różnicy, ale tutaj obie wersje są w asm.Myślę, że rozwój kompilatorów swoje jednak zrobił. Trzeba będzie wszystko przerzucić na C++.
Raczej chodzi o rozwój procesorów, które szybciej wykonają kilka instrukcji 386, niż jedną MMX. To wychodziło mi już w czasach 700 MHz-owych procków. MMX wygrywał gdzieś do 500 MHzowego Pentiuma i to nieznacznie.
Druga możliwość jest taka, że ja nie potrafiłem odpowiednio użyć tego MMX. Ale na swoją obronę mam, że po pierwsze jedna z procedur jest żywcem wzięta ze strony Intela, po drugie Ken Silverman w czasach wczesnego MMX stwierdził, że żadnego zysku z tego MMX nie ma i kod silnika Build co prawda wykrywa MMX, ale w ogóle go nie wykorzystuje.
teraz pewnie by w sse2 sie to robilo i raczej bedzie szybsze niz czysty 386 ;)
obecne kompilatory i tak same potrafia wykorzystac m.in. sse2 tyle ze trzeba odpowiednio spreparowac pod to kod (ani nie pamietam jak, ani linkow teraz do tych opisow znalezc nie moge).
To jeszcze jeden mały testfile.
Wczytuje się na szóstą stronę i uruchamia opcode'a $F2 (czyli również spowoduje crash emulatora).
Emulator przechodzi do monitora, tyle, że po CONT znika monitor i daje się zamknąć okno emulatora już normalnie z "krzyżyka".
Taka sobie mała ciekawostka przyrodnicza.
MM: coś stąd poszło? :) Zapraszam o tutaj (link już biega).
@Jaskier: czy udało Ci się może coś zrobić z tym bugiem opisanym w poście #81?
Strony Poprzednia 1 2 3 4
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Emulacja - 8bit » Atari800Win PLus 4.1 beta 2
Wygenerowano w 0.021 sekund, wykonano 60 zapytań