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
Nadchodzi Rogul na Atari ST/STE Konwersja znakomitego Fantasy-Hack'n Slash-Roguelike Rogul z małego Atari na platformy ST/STE
Gearlynx z aktualizacją do 0.0.9 Wieloplatformowy emulator konsoli Atari Lynx, Gearlynx, doczekał się nowej wersji 0.0.9.
Invitka na Silly Venture 2025WE Na odbywającym się w Berlinie party Deadline 2025 została zaprezentowana invitka na zimową edycję Silly Venture 2025WE
Test7800 0.7.0 Najnowsza wersja emulatora Test7800 wprowadza obsługę kontrolerów i ułatwia wczytywanie plików ROM.
Fujisan v1.0.5 Nowa wersja nowoczesnego frontendu dla emulatora Atari800.
Opcje wyszukiwania (Strona 18 z 20)
Znaczy.. te klawisze? Klawisze nie działają, patrz tutaj ;)
Po wielu różnych doświadczeniach jestem przekonany, że emulator źle interpretuje stany odpowiadające wciśniętym Shift, Ctrl i CapsLock, bo w niektórych programach (np. programy Avalonu) te kombinacje działają...
Jak dla mnie jedyna zaleta: działają kombinacje Shift-Ctrl-litera, w odróżnieniu od Atari800 ;)
Ja też dziękuję Ryśkowi za organizację i za stolik ;)
I wszystkim Kolegom, którzy postanowili się do mnie odezwać na party :D
Za rok już się zapisuję ;)
Ja zamawiam 65 XE - jeżeli wszystko wypali, to odbiorę w Głuchołazach :)
Jadę w sobotę ~10:00 z Dąbrowy. Mogę zabrać kogoś z okolic...
jellonek: Tak, ale nie wiem jak za pomocą cl65 dołączyć plik .o z asmowymi procedurami. Pewnie to idiotyczny problem, ale nie wpadłem dotąd na inne rozwiązanie - odzwyczaiłem się od kompilatorów przez tych parę ostatnich lat ;)
seban: Wiem, wiem że to dziwacznie wygląda, ale mam alergię na *nixowe źródła "zrób to sam" - pisałem już o tym kiedyś w wątku o atari800. cc65 oczywiście się nie chciał skompilować, mimo że mam wszystkie potrzebne biblioteki.. Doprawdy, nie wiem czy jestem takim nieukiem czy mam po prostu pecha ;)
Witam
Mam pytanie do Kolegów cc65'owców :) Mianowicie, jaki jest najprostszy sposób dołączania (dłuższych) wstawek assemblerowych, np. procedur? Czy kompilator cl65 ma opcję dołączania dodatkowych plików .o, czy trzeba to robić po kolei, assemblując i linkując wszystko?
A może istnieje możliwość włączania kodu asma bezpośrednio do programu? (nie mam tu oczywiście na myśli polecenia __asm__)
Będę wdzięczny za wszelkie rady, najlepiej z krótkim wyjaśnieniem.
Pozdrawiam
PS. Ha, ręka szybsza niż głowa :D Napisałem sobie taki skrypcik, może komuś się przyda:
#!/bin/bash
export CC65_INC=C:\\CC65\\INCLUDE
export CC65_LIB=C:\\CC65\\LIB
wine ../bin/ca65.exe -t atari $2.asm
wine ../bin/cc65.exe -t atari $1.c
wine ../bin/ca65.exe -t atari $1.s
wine ../bin/ld65.exe -t atari atari.o $1.o $2.o atari.lib -o $3
Jeżeli ktoś korzysta z windowsowego cc65 pod wine, to ten skrypt elegancko połączy kod w C z kodem w asmie i wrzuci do pliku wynikowego. Wywołanie: link <plik_c_bez_rozszerzenia> <plik_asm_bez_rozszerzenia> <plik_wynikowy>
Na to wygląda, że pojadę na zlot. Po drodze z Dąbrowy mogę kogoś zabrać - tyle że nie jestem jeszcze pewny dnia "wylotu".
No właśnie :) Bodajże w pecetowym trybie tekstowym 8x16 działało to podobnie.
A gdyby co 8 linię wyświetlać dwa razy (wyprowadzać na ekran 2 piksele, tylko raz pobierając wartość)? W ten sposób działa skalowanie w prostszych programach graficznych - może efekt nie będzie rewelacyjny, ale na pewno "ciągły" :)
Faktycznie, działa bez problemów. Jeszcze raz dziękuję.
Chyba generalnie na Atari lepiej nie używać dynamicznych tablic. Ech, przyzwyczaił się człowiek do wygodnego programowania... ;)
Dzięki, Fox. Jeżeli (char) bp obetnie starszy bajt i uniknie się śmiecenia w tej tablicy, to to chyba będzie najlepsze rozwiązanie (maszynowo to chyba będzie operacja na jednym bajcie). Przed dodaniem tego modulo na końcu tablicy miałem jeden albo dwa bajty śmieci.
bp % 255 to oczywiście pomyłka, miało być % 256 ;)
Fox: a czy (bp & 255) będzie bardziej optymalne?
PS. Nie wiedziałem, że Brainfuck dopuszcza zagnieżdżanie. Zrobi się :) Wystarczy jedna tablica jako "stos".
Nie wiem czy to będzie zgodne z konwencją Brainfucka ;) Na przykład program PRINTER.BF nie będzie działał prawidłowo. Pomyślałem, że można by zrobić funkcję getkey(), która domyślnie by pobierała znak z K:, a w razie np. przenoszenia kodu można by ją łatwo podmienić.
W każdym razie wielkie dzięki epi za radę.
PS. Można by też zrobić to za pomocą PEEK'a, odczytującego kod naciśniętego klawisza. Chyba najbardziej optymalne rozwiązanie.
Racja, też można. Tylko wtedy pobierane znaki będą się wyświetlały na ekranie :( No chyba że masz na myśli coś innego niż getchar()
Na pewno czytanie z stdin pozwoliłoby łatwiej przenieść program na inną platformę.
Moja pierwsza wprawka w CC65 - interpreter języka Brainfuck. Ciekawe, że nikt dotąd nie przeniósł tego niezwykłego języka na Atari ;)
Interpreter z kilkoma przykładami (.atr)
A tutaj źródła programu. Będę niezmiernie wdzięczny za wszelką konstruktywną krytykę, bo w C na razie mocno raczkuję.
Pozdrowienia
// uaktualnienie: 10.07.2008
* zagnieżdżanie pętli
// uaktualnienie: 13.07.2008
* "case-insensitivity" przy pobieraniu nazwy pliku
maw napisał/a:Czy gra aktora stanowi o odbiorze filmu jako żenującego, czy też jego akcja, a więc reżyseria ze scenariuszem ?
Mnóstwo rzeczy wpływa na odbiór filmu. Może go spaprać tragiczne wykonanie (vide: "Wiedźmin"), obsada, kijowy scenariusz itd. W zasadzie, podobnie jak w przypadku pisania programów, znacznie trudniej jest zrobić dobry film niż zły film ;)
IMHO, dobra fabuła może od biedy zatuszować kiepską grę aktorską, ale odwrotnie raczej nie.
maw napisał/a:mówisz o "Titatnicu", "Aviatorze", "Romeo i Julia" czy o "Człowieku w żelaznej masce", "Niebiańskiej Plaży", "Gangi Nowego Jorku" czy też o "Złap mnie, jeśli potrafisz" ?
Akurat w tym ostatnim filmie di Caprio dał pokaz prawdziwie mistrzowskiej gry. Zresztą, film również niewąski, podobnie jak książka :)
A Kaz pewnie miał na myśli "Co gryzie Gilberta Grape'a". Czy tam Leonardo jest "boski", tak jak w "Titanicu"? ;)
Jeżeli interfejs będzie współpracował z Linuchem, a cena nie będzie wygórowana, to chętnie bym toto nabył. Najlepiej ze złączem mini-USB.
Zamiast SIO2USB2PC można go nazwać SIUP (SIO2USB2PC) :D
Pozdrawiam
jest chuba sprawna, kontrolka zasilania się świeci.
Chodziło oczywiście o hubę.
Raczej to te czasy... teraz wszystko wygląda inaczej. Ale szybko się przestawisz w tryb 8-bitowy :D
Archiell: ja zaproponowałem rozwiązanie najprostsze, do zaimplementowania nawet w SDX. Przechowywanie STDOUT w plikach dyskowych mija się trochę z celem, no chyba że wykorzystać do tego ramdysk/SD/hdd.
Archiell, co do "rurki" (pipeline), to nie trzeba tego robić za pomocą komunikacji międzyprocesowej a'la Unix. Wystarczy to zrobić tak jak kiedyś było rozwiązane w MS-DOS: proces zwraca wartość (treść STDOUT albo chociaż kod powrotu), a DOS uruchamia następny proces z podanym parametrem na wejściu.
W ten sposób jest do rozwiązania tylko kwestia tego bufora, za pomocą którego procesy będą przekazywać sobie dane.
sqward: Bardziej po ludzku, ale bez tego uroku :) Na pewno do dużych projektów cross-compiler jest lepszy, ale im lepsze narzędzia, tym bardziej swobodne kodowanie zamienia się w inżynierię oprogramowania ;)
ilr: Kopia tej dokumentacji (domyślam się że taką masz ;) ) jest na tej stronie. Nie polecam natomiast książki "Języki programowania Atari cz. 2". Masa błędów, które mniej obeznanym z C osobom pozwolą spędzić niejedną godzinę na szukaniu dziury w programie.
Program w DBC jest kompilowany za pomocą CC.COM, a potem "linkowany" za pomocą CLINK.COM. Może to nawet parę minut zająć, ale za to jak ćwiczy cierpliwość :D
Znalezione posty [ 426 do 450 z 487 ]
Forum oparte o: PunBB
Currently installed 7 official extensions. Copyright © 2003–2009 PunBB.
Wygenerowano w 0.024 sekund, wykonano 44 zapytań