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
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
VIII. Basque Tournament of Atari 2600 Kolejna relacja, wśród otrzymywanych od naszego przyjaciela Egoitza z Kraju Basków.
Opcje wyszukiwania (Strona 3 z 17)
Adam Klobukowski napisał/a:Wielkie lasy w Europie zachodniej zostały wycięte na początku ery przemysłowej, kiedy jeszcze nie rozumiano konsekwencji. Teraz wiemy jakie są konsekwencje, mamy w Polsce ostatnia naturalną puszczę w Europie, to na złość specjalnieją sobie wytniemy?
Z wydobycia węga w Europie zrezygnowano z przyczyn ekonomicznych - taniej było go sprowadzić niż wydobywać na miejscu. I w ten sposób te kraje się wzbogaciły, a nie upierając się na wydobyciu u siebie.
Dziwne, bo w krajach dalekich (Afryka, wschodnia Azja) firmy z Europy zachodniej nie potrafią zrozumieć konsekwencji nawet dziś. Polecam lekturę m.in. 'No Logo'.
Generalnie, wygląda to tak, że w 18-19 wieku kraje uprzemysłowione walczyły ze słabszymi za pomocą patentów. Dziś do tego służą normy i technologie ekologiczne (odnawialna energia, itd...). Takie Niemcy wciskają wiatraki gdzie się da, bo mają kasę z tego. A że te same wiatraki co prawda nie dymią, ale z ptaków robią sieczkę - no cóż...
@XXL - Przecie wyżej masz kawałek dyskusji o wyższości Lost Patrol na platformie na A lub na A.
Ja czasem rozpętlam połowicznie - tzn, mam osobny kod dla każdego wiersza. A pixle/bajty w wierszu jadę w pętli.
Wszystko zależy od tego, ile masz czasu procesora, pamięci, itd...
Rozpętlanie to niekoniecznie jest łatwizna. Wtedy trzeba bardzo ostro upakować logikę efektu w kilka rozkazów asemblera. To nie zawsze jest proste.
Ja kiedyś napisałem toola, który generuje mi maski na podstawie sąsiedztwa Moore'a ( https://pl.wikipedia.org/wiki/S%C4%85si … 3%B3rkowe) ). Efekty użycia tego toola można zobaczyć w Undesigned oraz np. w Unglobal.
Jako parametr podaję tylko, na ile pól ma sięgać ramka (czy 1 pixel, czy więcej).
Jednakże, nie jest ona robiona w locie. Od biedy można taką prockę napisać, i wtedy w czasie initu taka ramka się wygeneruje.
Adam Klobukowski napisał/a:Przy pomocy movem da się chyba jeszcze szybciej, ale nie jestem w stanie policzyć.
Movem ma trochę pokręcone tryby adresowania. Zakładając normalne jego użycie, czyli dwa rejestry adresowe na adres skąd i dokąd oraz a7 dla stosu mamy:
movem.l (a0)+,d0-d7/a2-a6
movem.l d0-d7/a2-a6,(a1)
lea 52(a1),a1
To nam daje 240 cykli na 13 4bajtowych słów, więc 4.62 cykla na bajt.
Programowo na 68k chyba się nie da tego szybciej zrobić.
Ok, a całkiem serio.
Masz jakiś koncept, rozpoczęte coś, czy tylko gdybasz głośno (na zasadzie: zbierzmy się i zróbcie)?
Ot i mądrze mówisz. 2 razy.
Fajny wątek by pomarzyć :).
256 kolorów bez redukcji rozdzielczości raczej nie przejdzie. Nie chodzi o pamięć, ale raczej o szyny i hertze. 320x200x256 to jest 4 razy więcej danych niż jest teraz. Shifter zajmuje niecałe 50% czasu szyny. Więc byś musiał zająć 200% obecnej wydajności. Elektronikiem nie jestem, ale wydaje mi się to conajmniej niebanalne.
Natomiast co by było fajne - gdyby ktoś zrobił Shiftera z dodatkowymi trybami z pamięcią liniową. Niech to już będzie nawet 320x200x16. To już by był bajer :). Ale to moje, bardzo prywatne zdanie. Rynek na taki układ szacuję, na kilkanaście/kilkadziesiąt sztuk (na świecie) - więc kasy na tym raczej nie zrobisz. Rację ma Dely - dle tego układu soft musisz pisać od nowa, a obecnie na ST pisze mało kto. Dodatkową trudnością jest to, że Shifter mocno się różni w ST/STE, więc masz albo podwójny koszt, albo połowę mniej klientów.
Tutaj też masz parę projektów (przeważnie konwersje): http://atari-forum.com/viewforum.php?f= … 9aad9f6563
Spoko.
Musisz się przyzwyczaić, że 'XXL vs Pin/Draco' to taki lokalny folklor.
Nic groźnego, oni tak mają :).
Pin napisał/a:Ale pytanie dotyczy programowania w środowisku "oryginalnym" i zapewne nie chodzi tu o wygody tylko o klimat. Ja to rozumiem o tyle, że muzaki wolę pisać na TMC a nie RMT ;)
Różnica pomiędzy kodem a muzyką (w kontekście użytej maszyny) jest taka, że Pokey nigdzie nie jest dobrze emulowany (no ok, podstawowe dźwięki działają, ale te zakręcone już nie - opieram się tu na opinii Dhora, który robił muzykę na real HW), natomiast kod już tak (ostatnim demem które nie działało na ówczesnych emulatorach to była chyba Ilusia).
@wieczor - byś na maila spojrzał ;)
Ja w Unshaped (jedyne moje demo używające dodatkowej pamięci) sprawdzam jeden bank na zgodność ze 130XE (czyli PORTB).
Jeśli jest ok to ładuję dane obok banku, a potem na inicie kopiuję do banku.
Nie trwa to tyle, co z kasety - ludzie raczej marudzili, że demo długo trwa a nie długo się ładuje :).
Generalnie staram się minimalizować ilość bloków w binarce.
A co do technik programowania - osobiście sprawdzam binarki w SDX i ChaosLoaderze. Jeśli jest na obu ok - to puszczam binarkę w obieg (i zwykle jest ok).
Wszystkie mechanizmy nieznane mi (czytaj: to, czego nie mam w swoim XE) w momencie pisania ignoruję i się nimi po ludzku nie przejmuję. Jak ktoś instaluje jakiegoś dziwoląga w swoim sprzęcie to sam sobie jest winien. Taki jest mój punkt widzenia.
Ja mam Top Drive w CA2001.
@swinkamor:
1. Co do ST - nie twierdzę, że 32bitowe liczby nie mają zalet, ale 16bitowe również je mają. Zwłaszcza w maszynie, której architektura jest 16bitowa.
2. XE. Nie wnikając w dywagacje co jest XE a co nie jest, 8bitowe architektury raczej nie mają liniowej pamięci w okolicach 1MB. Z drugiej strony - jakiego rozmiaru masz projekt, że potrzeba Ci tyle pamięci?
@swinkamor12
1. Co do ST - na zwykłym 68k operacje 32bitowe są wolniejsze niż 16bitowe (transfer oraz operacje arytmetyczno-logiczne). Więc używanie zawsze i wszędzie 32bitowych liczb (mimo, że CPU je obsługuje natywnie) jest średnim pomysłem. Plus większe zużycie pamięci (co czasem również ma znaczenie).
2. Co do XE - mógłbyś konkretnie wylistować co Ci przeszkadza w C na 6502? W CC65 kilka fajnych projektów powstało i autorzy niespecjalnie marudzili na kompilator.
Dla mnie Rapidus/65816 to ciekawostka na miarę CT060 w Falconie.
A w temacie oczekiwanej niezliczonej ilości softu na te rozszerzniea (oba powyższe) wygląda to tak:
- mało kto dziś zajmuje się Atari (w szerokim rozumieniu) - platformami 8 albo 16 bit (8 bit lepiej w europie wsochdniej, 16 lepiej w zachodniej)
- spośród wszystkich atarowców mało kto pisze soft,
- spośród piszących soft mało kto ma powyższe rozszerzenia i na nie pisze.
Nie chcę szacować ile osób soft pisze, ale mnogości jakoś nie widzę.
Nie chcę nikomu skrzydeł podcinać, ale nie ma też co siać hura-optymizmu.
Ja (jako świadomy nieposiadacz) jestem skłonny zgodzić się z Pinem. Wszystko zależy od tego, co chcesz robić i co Ci w duszy gra. Do grania - średnio (parę gier ma więcej kolorów i kilka płynniej chodzi). Do dem - trochę lepiej (płynność).
Mi osobiście, jak w XE brakło bitów i bajtów to zainteresowałem się ST.
Gdyby Grey z Van Eijkiem się dogadali - mogła by powstać niezła mieszanka.
Bardzo grafika mi się podoba (ale to rzecz subiektywna).
Jak mówi przysłowie: 'nie dowiesz się, jak nie spróbujesz'.
Taki CosmoEx dla XE może byłby fajny. Czy bym kupił? Nie mam pojęcia (dla ST wolę ultrasatana)...
Dało by radę wrzucić to do atariki?
Byłbym złośliwy, to bym stwierdził, że regulamin ma tyle punktów, że połowa energii poświęcona na tworzenie pracy musi być przenzaczona na regulamin. Ale złośliwy nie jestem to i czepiać się nie będę.
Ale żeby krytyka konstruktywna była, regulamin z innego konkursu dla porównania dam: http://puu.sh/nllnG/29f1daf63a.txt
Polecam zwłaszcza punkt 7.
Znalezione posty [ 51 do 75 z 420 ]
Forum oparte o: PunBB
Currently installed 7 official extensions. Copyright © 2003–2009 PunBB.
Wygenerowano w 0.022 sekund, wykonano 50 zapytań