Przejdź do treści forum
atari.area forum
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
Nowy firmware 1.5 dla SDrive-MAX Ulepszony tryb szybki i poprawki kaset w nowej wersji firmware
Ice-T 2.8.2 Nowa wersja Ice-T dla 8-bitowego Atari już dostępna - poprawki i nowe funkcje
Galactic Panic - nowa przygodówka na ST Darmowa gra point and click na Atari ST - ponad 100 ekranów przygody.
Nowa wersja ARIFE Tool od PVBest73 Uaktualniono uniwersalne narzędzie do analizy obrazów ROM i dysków Atari
Echa Sommarhack 2025 Podczas szwedzkiego party Sommarhack zaprezentowano kilkadziesiąt produkcji,
Opcje wyszukiwania (Strona 44 z 66)
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.
O cholera. To aż tak źle? To może i dobrze, że 6502/65816 nie ma mnożenia ani dzielenia, bo odczytanie z tablicy jest o wiele szybsze ;)
Kusiłby mnie jakiś przykład jak się ładuje dane do pamięci i jaka jest organizacja. Zapodajcie źródła tych efektów, jakie są na screenach. To pomoże wyobrazić sobie jak się programuje.
Na wikipedii piszą, że 68010 ma cache na dwie instrukcje i w rezultacie jest 10% szybsza :)
epi napisał/a:Ale po co to robicie, skoro VBXE jest już właściwie gotowy?
Popularoność rozszerzeń jest w dużej mierze odwrotnie proporcjonalna od stopnia skomplikowania. Jeśli okaże się, że GTIA Upgrade będzie na tyle proste, że będzie można sobie to samodzielnie zlutować/wlutowac i inwazyjność tej operacji będzie względnie mała oraz nie będzie wymagało części sprowadzanych na zamówienie zzagramanicy, to uważam, że to nie jest wcale taki zły pomysł. Na "seryjną", profesjonalną produkcję rozszerzeń do atari w dzisiejszych czasach trudno liczyć (patrz F7, którego wątpie żeby ktoś był w stanie zrobić poza Pasiem), wydaje mi się więc, że ten czynnik ma niebagatelne znaczenie. A poza tym dłubanie przy atari to przecież fajna rzecz :)
Jest jeszcze tylko dużo białych plam odnośnie programowanie tego, bo nie wiem, czy da się na tym zrobić jakieś real-time efekty, czy może służyć tylko jako generator statycznych obrazków (super dopał do g2f). Jak wygląda zapisywanie pamięci tego rozszerzenia? Można zapisywać tylko sekwencyjnie czy można w dowolne miejsca?
Q-MEG 4.04 to najnowsza oficjalna wersja.
To osobna pamięć na osobnych kościach... choć chciałbym niekiedy, żeby to była ta sama (rysujemy w liniowej, podłączamy co narysowaliśmy w banku i ANTIC wyświetla ;) )
drac030 napisał/a:7) Tez jestem za tym, żeby ilość fastu w dopałkach nie schodziła poniżej 1 MB. Duddie chce robić Warpy z 16 MB fastu (na dynamicznej pamięci).
Jak najbardziej. Pamięć liniowa ma tendencję do większej "zużywalności", bo można robić na niej takie ładne tablice 256x256 :)
Super byłoby, jakby to wyszło z tymi warpami, bo prawdę mówiąc wolę "Warpa w garści niż F7 na dachu". I ciekawe, czy da się łatwo zrobić warpa na tych PLCC, co swojego czasu kupowaliśmy (na PDIP byłoby oczywiście łatwiej, ale do tego trzeba byłoby organizować następną dostawę)
Na pierwszym roku jak jeszcze w sali z komputerami stały 486, to wchodziłem :) Pamiętam czarne tło i na środku logo atari ;)
OK. Taki flash to bardziej przyszłościowe rozwiązanie i wydaje mi się, że z elektronicznego punktu widzenia to nie jest takie hop-siup.
Jako że forever już za parę dni więc interesuje mnie rozwiązanie najprostrze, czyli wypalenie Q-MEGa i DracOSa na nm27c256q. Swoją atarkę wezmę na zlot. Tam mojego epromka bym wydłubał i włożył nowego z w/w systemami, a starego oddał wraz z uzgodnioną bonifikatą :) Stryker, dałbyś radę? (jakby co qmega znalazłem tu, a zARCowany dracOS jest u drac030 :)
Jak wspominałem jestem laikiem, wiec zadam parę głupich pytań. Mikey wspominał coś o jakiś flaszach. Czy w miejsce mojego epromiku da się wstawić coś, co można byłoby nagrywać trochę bezboleśniej i ile by to kosztowało? No i jak nie, to o jakie pliki chodzi, które mam podesłać? Chodzi o zwykłe obrazy ROMów takie jak podpina się do emulatora?
Ja jestem kompletnym laikiem, ale jak zerknąłem pod klawiaturę, to znalazłem tam kostkę nm27c256q, na której mam Q-MEGa i Turbo-816 OS. Tego drugiego mieć nie chcę i wolałbym tam DracOSa. Czy na najbliższym Foreverze bedzie ktoś, kto będzie w stanie mi to wypalić?
Pecus: mógłbyś naświetlić ten pomysł? Jak miałyby być ułożone znaki w pamięci ekranu, żeby pamięć ułożyła się tak samo jak w spectrum? Bo nie widzę zysku w porównaniu do zabawy z displaylistą.
podobno to też jest spoko i free :)
A tak dla pewności - połączyłęś kabelkiem karte TV z kartą dzwiękową (line-out w pierwszej do line-in w drugiej)?
Pytam się, bo ja się kiedyś na tym złapałem ;)
Z wydajnosciowego punktu widzenia (demo? emulator z80? ;) ) oba rozszerzenia są kompletnie inne: nie używanie banku zerowego w ogóle, a używanie go chociaż do odczytu to wielka różnica. Zrobienie sobie kilku małych lookupów przed pętlą krytyczną i korzystanie z nich adresowaniem zerostronicowym może dać niezłego kopa. A jak prawdą jest to co mówisz, że zapis co 8 cykli nie haltuje procesora to nawet procedurę przepisywania ekranu można napisać tak, żeby przy okazji robiła trochę obliczeń (co może być przydatne, bo format ekranu roboczego możę być inny niż dane wymagane przez antica) i zapisywała nie częśniej niż te 8 cykli.
W rezultacie kod programu/dema musiałby być inny dla Warpa i dla F7, jeśli chcielibyśmy wykorzystać potencjał tego drugiego, a nie chcielibyśmy kompletnie zatkać tego pierwszego. Trzeba uświadomić sobie teraz, gdy nie ma większej ilości żadnej z tych dopałek, że są "trochę" niekompatybilne i w przyszłości lutować na większą skalę tylko jedną z nich, bo produkowanie obu zrobi więcej szkód niż pożytku. Tylko, że F7 jest chyba zbyt trudne, żeby dał rade lutować to ktoś inny niż Pasiu... Obym się mylił.
Aparacik wysłałem do tego warszawskiego serwisu i wrócił z usuniętym paprochem w ramach gwarancji. Więc wszystko skończyło się dobrze :)
Dzięki za rady.
No właśnie. Direct Page można ustawić na dowolne miejsce w zerowym banku pamięci. Niby ładnie pięknie i super relokowalnie ale, to ma sens tylko w jakiś programach użytkowych wygenerowanych przez kompilator C, bo w demach jest zupełnie nieopłacalne: umieszczenie D poza granicą strony (młodszy bajt różny od zera) pożera dodatkowy cykl, a ograniczenie przesuwania D tylko do zerowego banku jest wręcz frustrujące w momencie, gdy "pamięć wysoka" potrafi być 8 razy szybsza od banku zerowego.
Chciałbym żyć w alternatywnym wszechświecie, który różniłby się tylko tym, że w 65c816 rejestr D wciąż 16-bitowy można byłoby ustawić na dowolną stronę w 16 MB pamięci, a nie dowolny bajt w banku zerowym. Ale pomarzyć dobra rzecz...
Znalezione posty [ 1,076 do 1,100 z 1,629 ]
Forum oparte o: PunBB
Currently installed 7 official extensions. Copyright © 2003–2009 PunBB.
Wygenerowano w 0.061 sekund, wykonano 26 zapytań