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
20. odcinek kursu programowania u Larka Larek wraca z okrągłą, dwudziestą częścią swojego popularnego kursu pisania gier na Atari.
ELITE Atari 8-bit! Dostępne demo portu gry ELITE (wersja dyskowa z BBC Micro) na komputery Atari XL/XE.
BBC BASIC dla Atari XL/XE BBC BASIC w wersji 3.10 dostępny na Atari XL/XE! Port stworzył Ivo van Poorten.
Altirra 4.40-test23 Kolejna testowa wersja Altirry przynosi poprawki w emulacji VBXE i usprawnienia w zarządzaniu firmware.
X. Basque Tournament of Atari 2600 Euskal Retro Association podsumowuje 10. edycję Baskijskiego Turnieju Atari 2600.
Opcje wyszukiwania (Strona 102 z 124)
Z tego co ja pamiętam z czasów kiedy pisałem pod Quck Assemblerem to miał on sporo błędów, jeden z nich był właśnie przy dyrektywie "icl", także praktycznie rzadko kiedy używałem tej dyrektywy.
Przecież ja nie mówiłem że nie było :) Ja go tylko nie widziałem przez długi, długi czas :)
ja miałem to samo :) Długo tego linka nie mogłem dostrzec :) Ale któregoś pięknego dnia udało mi się go zobaczyć ;)
pozdrawiam
Seban
No ale przecież chyba jest?
w menu forum na górze masz:
* Index
* Lista użytkowników
* Zasady
* Szukaj
* Profil
* Wyloguj
* Regulamin
* FAQ
* atari.area Strona Głowna
ostatni link to Strona Główna, czyż nie?
Oj też mi się marzy taki tool ;) Ale w tym wypadku "napisz SE" nie wchodzi w grę :(
no to przecież napisałem że prościej i bezpieczniej kupić lampę TUV i podpiąć ją pod elektronikę od zwykłej kompaktowej świetlówki marki "krzak" za 3zł ;) Klasyczny starter i dławik kosztuje zdecydowanie drożej :)
Obudowę również sugerowałem :)
A jak już chwalimy to kasownik fabryczny też gdzieś mam, ale nie pamiętam kiedy używałem EPROM-ów z okienkiem więc gdzieś przepadł w moim bałaganie :P
Sodówki? (mówisz o takiej: http://pl.wikipedia.org/wiki/Lampa_sodowa) jeżeli tak to pierwsze słyszę... bo ja taki "kasownik" w bardzo zamierzchłych czasach robiłem zawsze z lampy rtęciowej ( http://pl.wikipedia.org/wiki/Lampa_rt%C4%99ciowa ). Jak robiłem kasownik z lampy rtęciowej to rozbijałem zew. bańkę z luminoforem i wykorzystywałem do kasowania palnik wewnętrzny. Z tego co wiem to do dziś kolega wykorzystuje palnik z takiej żarówki rtęciowej do naświetlania płytek pokrytych preparatem POSITIV-20.
Ale takie rozwiązanie ma kilka wad:
- potrzebny jest układ zapłonowy (statecznik+kondensator)
- takie rozwiązania generuje również masę szkodliwego ozonu podczas pracy (charakterystyczny zapach) więc trzeba takie naświetlanie/kasowanie robić w dobrze wietrzonym pomieszczeniu.
Lampy TUV Philipsa mają wbudowany filtr (w szkło lampy) który tnie pasmo światła tak aby promieniowanie UV generowane przez świetlówkę nie wytwarzało takich ilości ozonu.
Jeżeli samemu chce się robić kasownik to chyba będzie prościej kupić taką świetlówkę TUV (np. 15W) potem za grosze kupujemy "15W świetlówkę energooszczędną" wybebeszamy z niej elektronikę i podłączamy w miejsce starej świetlówki tą UV. Taki patent działał u mnie przez lata :D Do tego oczywiście doszła metalowa osłona (chyba wykorzystałem formę do pieczenia ciasta ;] ).
Długość fali wymagana do kasowania pamięci EPROM to 253,7nm. W karcie katalogowej np. do MC27C1001 piszą iż trzeba umieścić kostkę w odległości ~2,5cm od lampy. Czas naświetlania to 15-20 minut. Natomiast nie mam pojęcia jakiej długości falę UV generuje lampa bakteriobójcza :)
UPDATE:
Doczytałem iż w takich lampach bakteriobójczych są stosowane np. świetlówki Philips-a typu TUV, mniej więcej takie: http://www.tme.eu/swietlowka-bakteriobo … UV-15W.htm
a więc długość fali się zgadza, możesz chyba śmiało próbować kasować ten EPROM, tylko go nie usmaż :) bo pewnie te lampy co są w przychodni będą raczej sporej mocy... więc pewnie odległość trzeba by zwiększyć aby nie ugotować EPROM-a pod taką lampą :) No chyba że użyjesz tej wersji przenośnej.
Tylko proszę uważaj na oczy i skórę! Z promieniami UV tej długości nie ma żartów!
faktycznie koniec w Natural Wonders II jest świetny! Szkoda tylko iż my mając takie możliwości od zawsze nie wpadamy na tak proste i efektowne pomysły... my mamy Display List od zawsze... a oni aby VIC-a do tego zmusić muszą się nieźle nabiedzić... mimo i na naszej platformie jest to prostsze do zrealizowania ... jakoś nikt z naszej sceny na takie wykorzystanie DL nie wpadł... chociaż było możliwe od lat :)
Może wynika to z tego iż każdy myśli że na DL zrobiono już wszystko i idziemy nie w tą stronę... to oczywiście jedna strona medalu, ale to temat na zupełnie inną dyskusję :)
Na tym przykładzie (końcowa scena Natural Wonders II) doskonale widać iż liczy się również nieszablonowy i niebanalny pomysł ;)
Seban
pr0be dzięki za informacje! :D Nie ma to jak skondensowana dawka wiedzy w pigułce :) Zaczołem przeglądać jakieś tutoriale a propos VIC-a ale szybko mi się znudziło :)
pozdrawiam
Seban
Co do muzyki: Sądząc po rozmiarze pliku ten SID-a to zrzut całej pamięci :)
Zawsze mnie zastanawiało jak koderzy C64 robią efekty typowo display-listowe (np. powielenie tej samej linii w pionie). Z tego co wiem VIC w normalny sposób tego nie umożliwia :) Do tego podziw dla kodera który w tym demie praktycznie w większości czasu otwiera ramki VIC-a, tam wymaga to koszmarnego cyklowania (C64 nie ma odpowiednika STA $D40A). Zauważcie iż aby na C64 położyć coś na bocznych ramkach trzeba tam wrzucić sprite-y i chyba linia w linię mieszać coś w rej. VIC-a aby ten sądził iż ramka mu się nie skończyła, o ile otwarcie pionowych nie jest jakieś straszne to tyle otwarcie poziomych po prostu wymaga chyba sporego miąchania... a z tego co zobaczyłem w tym demie większość czasu coś się dzieje na bocznych ramkach.
ps) bierzcie pod uwagę iż mogłem napisać jakieś głupoty w tekście powyżej... ale ja się na C64 nie znam :)
No i bardzo mi się podobają ich szybkie zoomer-y... kila razy je wiedziałem ale nie wiem jak oni robią je w jednej ramce (rozciąganie w poziome, pewnie prefazowane i na fontach), ale jak to robią VICE-em w pionie :) nie wiem :) (mówie o tych zommerach co cały ekran zajmują i motyw grafiki jest powielony wiele razy - tak jakby był to ułożony jeden pełny zestaw znaków na którym jest to później rysowane)
Hej!
Alex ty akurat masz taką możliwość (umiejętności koderskie) więc poświęć swój cenny czas i napisz nam :)
Seban
Ciekawe czy wykorzystuje CPU w stacji dysków do liczenia :)
zgadzam się z TeBe... znając życie i mając na uwadze poprzednie doświadczenia... szansę iż to rozwiązanie zdobędzie jakąś popularność są marne. Tylko rozwiązanie typu cartridge (którego nie trzeba fizycznie montować w komputerze) ma jakiekolwiek szanse powodzenia.
xxl napisał/a:czy ktoras z tych kombinacji juz jest uzywana? (najbardziej odpowiadalaby mi pierwsza kombinacja)???
Myślę iż np. rozszerzenie 1088K wykorzystuje wszystkie kombinacje.
[offtopic mode:on] jeju... tak to czytam i zastanawiam się skąd macie czas na oglądanie tylu seriali :) [offtopic mode:off]
ale zaraz... C64 killer to nie był mod Player napisany przez Pecusia? Jeżeli to był mod player to chyba nie bardzo wykorzystywał GTIA do grania :)
Co do mojego walącego się archiwera to był to Full Disk Archiver i nadawał skompresowanym plikom rozszerzenia .FDA, ten w zip-ie ma jakieś .000 więc wątpię aby był to FDA... poza tym FDA nie poszedł chyba nigdy w świat ze względu na ten fatalny błąd :D
btw. kliknięcie w link XLent-a otwiera jakąś masakrę, dopiero "skopiuj adres odnośnika" pozwoliło pobarać plilk.
Seban
Hej!
Panowie chyba TL w którymś swoim demku wykorzystał GTIA do grania jedno-bitowych sampli... jak go znajdę to wam podeślę linka.
Problem w tym iż nie pamiętam jak się ono nazywało :(
UPDATE: dobra znalazłem, jest do pobrania tu. Tyle że niestety żyłem przez lata w błędzie, ten player nie używa GTIA do grania, chyba się kiedyś zasugerowałem scrollem i nietypowym jak na Atari basem :)
Seban
Hej!
Standardowy 8K cart działający w przestrzeni $A000-$BFFF nie wymaga żadnych komponentów oprócz EPROMU odpowiednio połączonego do gniazda cartridge.
pozdrawiam
Seban
Hej!
Wydaje mi się iż ktoś próbował to już robić:
http://www.myatari.com/nirdary.html
Modyfikacja polegała na zamianie ANTICA na PAL-owski i podmianie ROM-u na patchowany. Nie wiem jak to działa bez wymiany rezonatorów kwarcowych. Ale podobno działa.
Mam jeszcze jedną wątpliwość... GTIA pozostaje niezmieniona i tworzy się taka hybryda PAL ANTIC + NTSC GTIA. Naprawdę nie wiem jak to może działać :) I jaki de facto jest obraz generowany :)
W dodatku podmiana OSROM nic nie daje dla programów które sprawdzają czy GTIA jest PAL czy NTSC. Tutaj GTIA zwraca iż jest NTSC, ANTIC jest PAL-owski.
Fox wspominał iż jedynym sposobem na wykrycie takiej maszyny jest sprawdzenie do jakiej max. wartości dochodzi licznik w $D40B.
Soft który nie sprawdza na jakiej maszynie chodzi podobno działa, taki co sam wykrywa jakie masz GTIA pisze że masz NTSC. Tak więc jedyny ratunek to "zapatchowanie" takiego programu :)
pozdrawiam
Seban
Hej!
A tutaj ta audycja w której był emitowany FEUD.
pozdrawiam
Seban
zyga, dely: faktycznie namieszałem :) Macie racje :)
pozdrawiam
Seban
Zyga, a nie jest odwrotnie? tnz. LOAD "...",8,1 ładuje zawsze pod $0801, a LOAD "...",8 ładuje pod adres wskazany w dwóch pierwszych bajtach?
Co do Atari to jeszcze możesz podejrzeć strukturę pliku, używając programu Jindrich Kubec-ki:
http://jindroush.atari8.info/data/asoft/chkexe_bin.zip
odpalasz chkexe.exe twój_plik.xex i wypluwa na ekran strukturę pliku, dla przykładu jak to wygląda:
chkexe.exe zorro.xex
ChkExe v2.71 (c) 1998-2000 Jindrich Kubec <kubecj@asw.cz>
Binary file: zorro.xex
[0002] Block: 8000-8062 (0063)
[0069] : Unexpected second 0xffff format header
[006B] Block: 4000-49FF (0A00)
[0A6F] Init : 8012
[0A75] : Unexpected second 0xffff format header
[0A77] Block: 4A00-53FF (0A00)
[147B] Init : 8012
[1481] : Unexpected second 0xffff format header
[1483] Block: 5400-5DFF (0A00)
[1E87] Init : 8012
[1E8D] : Unexpected second 0xffff format header
[1E8F] Block: 5E00-67FF (0A00)
[2893] Init : 8012
[2899] : Unexpected second 0xffff format header
[289B] Block: 4000-48FF (0900)
[319F] Init : 8012
[31A5] : Unexpected second 0xffff format header
[31A7] Block: 4900-4EFF (0600)
[37AB] Init : 8012
[37B1] : Unexpected second 0xffff format header
[37B3] Block: 1480-4D7F (3900)
[70B7] : Unexpected second 0xffff format header
[70B9] Block: 5BE8-84E7 (2900)
[99BD] : Unexpected second 0xffff format header
[99BF] Block: 5000-5030 (0031)
[99F4] Run : 5000
Ok!
Bardzo dawno temu (za czasów Code3) napisałem dwa prościutkie tego typu programy dla Atari. FileTracer (FT.COM) oraz Fast FileTracer (FFT.COM). Funkcję spełniały one ta samą, różniły się prędkością działania. Pierwszy czytał analizowany program bajt po bajcie (nie miał dużego zapotrzebowania na pamięć), drugi używał bufora przez co odczyt poszczególnych bloków był szybki - lecz kosztem zajęcia całego RAM od MEMLO to $BC1F.
pozdrawiam
Seban
Jeżeli chodzi o C64 to z tego co pamiętam to program typu .PRG zawsze ale to zawsze ładuje się u nich pod $801, i może mieć maks. rozmiar 38911 bajtów. Programy wykonywalne na commodore muszą udawać program BASIC-owy. Ładowane są BASIC-ową komendą:
Każdy program składa się więc z nagłówka identycznego, wskazującego na adres ładowania $0801 (dwa pierwsze bajty), potem następuje kawałek stokenizowanego programu w BASIC-u, najczęściej jest to coś w stylu:
Na instrukcja pozwala na uruchomienie wczytanego programu od podanego za SYS adresu. Potem już leci program, najczęściej spakowany różnymi cruncherami, packerami. Wydaje mi się iż właśnie przez ograniczenie, iż ładowane programy muszą się mieścić w buforze interpretera BASIC-a na Commodore powstało tyle programów pakujących :)
pozdrawiam
Seban
Znalezione posty [ 2,526 do 2,550 z 3,090 ]
Forum oparte o: PunBB
Currently installed 7 official extensions. Copyright © 2003–2009 PunBB.
Wygenerowano w 0.099 sekund, wykonano 23 zapytań