Przejdź do treści forum
atari.area
Twoje polskie źródło informacji o Atari
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Aktywne tematy Tematy bez odpowiedzi
Aktualności ze świata Atari
Mad-Pascal 1.7.8 Wydano nową wersję Mad-Pascal 1.7.8 z poprawkami błędów, optymalizacjami i nowymi modułami.
Klasyki Activision powracają na Atari Atari wznawia wydania kultowych kartridży Activision na konsolę Atari 2600, w tym legendarnego Pitfalla.
mm_vgm 0.2 dla Atari ST Nowy odtwarzacz plików VGM/VGZ dla Atari ST z obsługą układu YM2149.
NeoST 0.5.4 Kolejna odsłona emulatora NeoST przynosi wsparcie dla kluczy sprzętowych oraz usprawnienia MIDI.
Gearlynx 1.2.28 Wydano aktualizację dokładnego emulatora Atari Lynx z optymalizacjami i nowym serwerem MCP.
Opcje wyszukiwania (Strona 44 z 66)
Nie jestem pewien w czym oryginalnie SoTe skompilował SAPa, ale podejrzewam, że w VS 2005. Na maszynie developerskiej skompilowane w nim programy działają pięknie, ale ich deployment potrafi napsuć człowiekowi krwi. Dużo krwi. Sesja z google zaoowocowała jakimś rozwiązaniem [które jest nieaktualne, bo niżej jest lepsze].
======== EDIT =========
Udało mi się skompilować statycznie. Pliczki są większe, ale nie wymagają msvcrt80.dll. Paczuszka jest tu.
Feedback mile widziany :)
Reasumując to nie wina .NETa, tylko najnowszego visuala, który aż kipi od nowoczesnych technologii, które wymagają conajmniej windowsa 2000 i z którymi są same problemy. Pewnie jakby skompilować to w jakimś np VC++ 6.0 to by poszło bez problemu nawet na win98, ale legalne to by już nie było ;)
Skompilowałem za pomocą Visual C++ 2005 Express Edition (kompilator natywnego C++ nie mający nic wspólnego z dotnetami) i działa. Nie mam niestety dostępu do kompa bez .NET 2.0 i nie wiem czy działa bez .NETa, ale zaglądając do środka plików nie widzę tam żadnych odwołań do jakichkolwiek dotnetowych bibliotek. Tylko do MSVCR80.DLL.
Napewno normalne to nie jest. Napis pochodzi z SELF TESTu, ale na niego to nie wygląda. Jak masz aparat, to zrób fote, (albo filmik, jeśli efekt jest "dynamiczny").
Dziwna sprawa z tym .NETem, bo wewnątrz SAP.exe jak i in_sap.dll nie ma żadnego odwołania do .NETa. tylko do MSVCR80.dll. Za to wymagany wydaje się być Direct X (DSOUND.dll)
jellonek: to nie używaj i napisze se sam bez .net 2.0.
Autor zrobił to dla przyjemności bez żadnego wynagrodzenia i pisał to tak jak chciał i było mu wygodniej.
180 kB... ?? Jak dotąd mieścili sie w 96 kB :> postęp ;)
albo LCD + komputer + karta TV ;)
Z XLPaint MAX-em UltraXE w ogóle mam problemy. Jak i z wersją 8 tak i 16 bitową. Linia rysuje się jakoś z boku. Niezłe. Pierwszy raz coś takiego widze :)
A800Win+ i Atari++ radzą sobie bez problemu z 8 bitową...
Tebe: musiałeś coś źle napisać, bo np. dracowy emulator z80 działa, więc aż tak źle nie jest. Nie emuluje tylko szczególnych przypadków, takich jak fakt, że w trybie emulacji pewne instrukcje potrafią przekręcić na chwilę stos poza pierwszą stronę, ale reszta wydaje mi się OK.
jellonek:
spoko spoko. draco wypuści emulator z80 pod warpa/f7, to i motywacja się znajdzie ;) A poza tym w TODO czytamy
[...]
- CPU upgrades (65816, etc)
[...]
więc to tylko kwestia czasu ;)
alex:
Przy odpowiednio dużej determinacji wszystko się da, tylko wymagałoby to rewolucji w źródłach. Sam procesor i pamięć byłoby pewnie nawet prosto, ale np emulacja WARPa (szybszy zegar w wysokiej pamięci) albo F7 (dodatkowe cachowanie zerowego banku) wymagałaby znajomości źródeł na poziomie 0xF'a, a nawet wspomniana linijka w TODO jest zbyt nisko, aby liczyć na szybką interwencję w kwestii WARPów :)
Uważam poprostu, ża są emulatory, w których można zrobić to szybciej i łatwiej ;)
Mam rozumieć, że szukasz kogoś, kto weźmie diffa robiącego UltraXE z atari800 1.2.0 i uaktualni go tak, żeby pasował do wersji 2.0.2?
Jeśli tak to powodzenia :)
IMHO atari800 jest nierozszerzalny. Nie tędy droga...
O... zaczyna się ciekawa dyskusja. Ciekawe ilu atarowców ma komp na strychu, ilu chłodzenie wodne, a ilu gąbeczki pod twardym dyskiem, żeby nie rezonował...
Cóż, niektórzy nie są maniakami wyciszania kompa i wyłączają w nocy komputery ;)
Ooo... kierownictwu też zdarza się gorszy dzień:
wspomniany zbieracz trochę wyżej napisał/a:Dlatego zaplacilem $10 za dodatkowy modul, ktory oprocz mozliwosci filtrowania dal mi jeszcze jeden dodatek na ktorym mi zalezalo: Timer (wylaczajacy kompa) dzialajacy identiko jak w normalnym TV. Czyli nacisniecie klawisza na pilocie zwieksza czas do wylaczenia o kolejne kwadranse.
;)
A w ogóle to w dyskusji nie uczestniczę, bo TV poza meczami polskiej reprezentacji nie oglądam, więc DScalera używam tylko do oglądania obrazu z Atari ;)
dely: u mnie zżera 10% proca, to dużo? Pozatym naciśnij tab i będziesz mógł dragować zawartość :)
A oprogramowanie oficjalnie dawane przez producentów kart sscie IMHO bardziej: okrągłe okienka, mnóstwo butonów, suwaków, ikonek i innych wodotrysków tylko po to, żeby interfejs "fajnie" wyglądał... nie trawie takiego oprogramowania. Przykład na załączonym obrazku:

lol
Super! Taki wybór szerokości/wysokości jest idealny!
Nie widzę tylko jednego - co się stanie, gdy będą wpisywane różne wartości w różnych miejscach? Czy różne wartości bitu 5 w róznych miejscach w linii spowodują generowanie raz szerokiej raz wąskiej zmiany koloru? Czy różne wartości bitów 6-7 w różnych liniach tego samego ekranu spowoduje generowanie linii o różnej wysokości? I najważniejsze. Co się stanie przy różnych wartościach bitów 6-7 w jednej linii??
Ja tak czytam po kilka razy i nie rozumiem co takiego złego jest w pisowni jellonka? Chodzi o interpunkcję, polskie znaki czy może jeszcze coś innego?
spróbuj dscalera. Ja tam jestem zadowolony.
Aż podłączyłem Atarke do kompa przez karte TV, zrobiłem GR.15 i POKE 559,35 ustawiłem pamięć ekranu na śmieci, policzyłem pixelki i wyszło mi 176 nie licząc paska śmieci po prawej :)
dziwne. u mnie działają oba linki :/
Odgrzebuje, bo ostatnio zerknąłem do niego i muszę powiedzieć, że jestem pozytywnie zaskoczony.
Jakie są dowody, że kod atari++ jest zżynany z atar800? Z tych fragmentów kodu które czytałem, to jest on zupełnie inny. Nie wykluczam, że mogła zostać wyrżnięta jakaś trudniejsza procedurka, no ale bez przesady, w "zywcem przeniesione pliki, ze zmienionym naglowkiem" trudno mi uwierzyć: atari800 to czyste C napisany w sposób przypominający wynik działania obfuscatorów (IMHO ma szanse na wysokie miejsce w IOCCC ;) ), a atari++ napisany jest bardzo czysto obiektowo i widać, że na początku był projekt, a nie radosne programowanie, dzięki czemu rozszerzanie go o cokolwiek nie sprawia żadnych trudności. Najnowsze dema chodzą i jedyne co zauważyłem, to że dźwięk faktycznie trochę pierdzi (co dowodzi, że przynajmniej POKEY nie był wyrżnięty ;P). A jakie są inne ciężkie winy, że tak jest jechany i skazany na banicję?
Niech pojawi się tylko dokładna specyfikacja, to pomyśli się nad emu :)
No! To już zaczyna mieć ręce i nogi! Pomysł z nienadpisywaniem adresu rejestru jest super. A wiadomo już czym dokładniej będą różniły się te tryby, czy to jeszcze w fazie opracowywania?
to implikowałoby podwójne buforowanie :)
Rozumiem, że jak GTIA jest w trybie OFF, to nic na ekranie się nie wyświetla (nie ma bombardowania). To stanowi jednak pewien problem w przypadku renderowania w czasie rzeczywistym, bo mamby do dyspozycji tylko czas powrotu plamki na zmianę pamięci, czyli niewiele. Bez tego, to można tyko sprzętowo dopalić graph2font :) Upgrade byłoby znacznie atrakcyjniejsze, gdyby było jakieś podwójne buforowanie: wyświetla się zawartość jednego fragmentu pamięci, a zapisujemy do drugiego i gdy gotowe jakimś rejestrem przełączamy...
tebe napisał/a:wartość do $d024, młodszy adres rejestru do $d025 (kolejność istotna)
Czyli licznik zwiększy się w momencie zapisania czegoś do $d025? Cóż, pofantazjować można: jakbyście projektowali upgrade 2.0, to fajne byłoby np poświęcenie adresów $d080-$d0bf w ten sposób, że zapisana tam wartość, to "wartość", a młodsze 5 bitów byłoby odrazu "młodszym adresem rejestru". Zawsze trochę dopali :) (chociaż na 65c816 teraz też jest szybko)
Myślę, że kwestią jest korzystniejszy stosunek powierzchni ekranu do wydajności proca. Podejrzewam, że jakby na ST/E robić dema w 64x48, to też dałoby się kilka fajnych rzeczy pokazać, a niestety motorolka nie jest aż tyle razy szybsza od 6502, aby wydolić fajne rzeczy w wysokiej rozdzielczości.
Znalezione posty [ 1,076 do 1,100 z 1,645 ]
Forum oparte o: PunBB
Currently installed 7 official extensions. Copyright © 2003–2009 PunBB.
Wygenerowano w 0.054 sekund, wykonano 18 zapytań