Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
TURGEN 9.3.0 Kolejna wersja multiplatformowego narzędzia do zarządzania obrazami taśm.
SV 2024 WE - program imprezy Już za tydzień odbędzie się zimowa edycja Silly Venture
Nowa obudowa dla 800XL - zostało 36 dni Niewiele ponad miesiąc do końca kampanii.
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
atari.area forum » Posty przez seban
i moje którkie pytanko, czy ktoś ma może właśnie schematy i instrukcje montarzu takich systemów turbo jak Blizzard i AST?
Zawsze byłem ciekawy ich działania jednak ja miałem tylko Turbo 2000 (podłączane poprzez port JOY'a) i Turbo 2000F (z małym przełącznikiem w magnetofonie turbo/normal)
pozdrawiam
Seban
Przez chwile sam miałem wątpliwości ;-)
Ale Miker, mogę Cię uspokoić ;) to chyba jednak nie ja ;) :lol:
A przynajmniej nic nie pamiętam ;-)
pozdrwiam!
Cześć!
Na początu chciałem wyjaśnić iż nie chciałem Cię urazić moimi wypowidziami. Szanuję Cię jako osobę która spowodowała iż zainteresowałem się sceną i pisaniem dem ;) Można powiedzieć że to dzięki Tobie zaczęła się moja przygoda ze sceną :) W tamtych czasach byłeś dla mnie wzorem dla naśladowania ;) mówiłem sobie... "też kiedyś napisze coś tak fajnego jak Revenge of Magnus ;)"
Ale już dość tego niecico przydługiego i wazelinarskiego wstępu ;) Moim celem nie było obrażanie kogokolwiek, ale próba wyjaśnienia kilku szczegułów histotycznych ;) a że jak ostatni idiota napisałem to co mi się po głowie telepało i było pewnie dość nieściłe to jest to bardzo możliwe ;-) pewnie tak jak sugerujesz przekręciłem coś co mi powtórzył SoTe. Przyznaje się iż sam tego nie sprawdziłem a tylko pisałem co pamiętałem z rozmowy sprzed wielu lat (a pamiętałem jak widać bardzo nieściśle ;) Skoto nic takiego w twoim depakerze nie ma to pewnie SoTe nie mówił o Cruncherze 5.0 i wiem że skoro tego nie sprawdziłem to nie powinienem o tym pisać. Nie chce wszczynać kolejnej sprzeczki ale może mówił to depackerze z którejś części TheTop... lub w ogóle coś źle "wymyśliliśmy"... wszak pamięć już nie ta i mogę bredzić także nie bierz tego sobie do serca :D A i dodać trzeba że umiejętności koderskie i analityczne w tamtych czasach nie były na "wysokim" poziomie :) Wszakże jeszcze dziećmi byliśmy ;)
Cieszę się zaj#&(*#( że znalazłeś chwilę czasu aby odpowiedzieć na ten post... jednak nie myślałem iż moj post potraktujesz jako "zarzut". Napisałeś pierwszy program tego typu na ATARI i chwała Ci za to :) Może znalazłbyś chwilę czasu i opowiedział nam historię powstawania Crunchera 5.0 i może chciałbyś powiedzieć parę słów o tamtych czasach? Jestem tego cholernie ciekawy ;)
No cóź mogę w tym momencie zrobić... Mogę Cię przeprosić raz jeszcze za rzeczy które napisałem na prawdą nie były.
pozdrawiam serdecznie
Sebastian Igielski a.k.a Seban/SLIGHT
Rozumiem, ze Code3 Cruncher powstal w wyniku niezadowolenia z osiagow crunchera Magnusa? ;)
Dokładnie tak. SoTe był i jest taki że lubi robić rzeczy po swojemu.
Cruncher 5 Magnusa był jak na tamte czasy totalną rewelacją ;-) Bo był to jedyny tego rodzaju program na ATARI, w tym czasie ludzie z C64 mieli tych programów dziesiątki. Jednak temat packerów z C64 to temat na oddzielny post a może nawet artykuł, bo to bardzo interesujące zagadnienie. W skrócie rzecz ujmując w C64 jedyną możliwością załądowania programu było załadowanie go w obrzar przeznaczony na pamięć programu BASIC'a. Chyba około 38KB, więc teraz się domyślacie zlaczego ludzie z C64 tak szybko zaczeli się znajmować kompresją danych. ATARI miało na tyle genialnie pomyślany format pliku binarnego iż przez baaaardzo długi czas nie było takiej potrzeby. Bo ładowaliśmy sobie programy w jake obszary chcieliśmy i do tego mogliśmy wykonywać dowolny kod pomiędzy wczytanymi blokami (tzn. wektor INIT).
Ale wracając do SoTe on zawsze lubił analizowoać dany problem i rozwiązywać go po swojemu ;) A że wychodziło mu to w 99% przypadków lepiej to już nie jego winia. Nie ma co ukrywać iż Code3 Cruncher jest bardzo podobny w obsłudze do Crunchera 5, bo też na nim był wzorowany ;) Jednak procedury pakujące były napisane od nowa przez SoTe. Możecie się smiać ale pamiętam to do dziś jak SoTe pod koniec pisania swojego Packera potrafił rozpakować ciąg zero-jedynkowy na kartce pochodzący z jego packera ;) Zersztą pakowanie pliku na kartce prze SoTe też wyglądało zabawnie (pewnie nie dla niego, bo spędził nad testami procedur pakująco/depakujących naprawdę wiele godzin).
Wiem że SoTe analizował dogłębnie Cruncher 5 i bardzo mocno się zastanawiał czy procedury kompresji/dekompresji nie pochodzą z C64. Pokazywał mi kilka zastanawiających fragmętów kodu z Cruncher 5. Była chyba obsługa komórki $00 lub $01 która w C64 odpowiada za odłącznie róznych obszarów pamięci (tak jak $d301 w ATARI). Do tego po załadowniu pliku procedury przepisywały wszystko jak najniżej się da i rozpoczynały proces dekompresji od konca do początku pamięci (zawsze tak robili na C64). Tylko u nas był mały problem ;) W C64 mogli sobie odłączyć wszystko co możliwe i mieć pełne 64KB RAM, mogli odłączyć nawet rejestry sprzętowe ;) Magnus rozwiązał sprawę w ten sposób iż dane spakowane po pierwszym przebiegu (RLE, charpack) musiały się kończyć w do $cfff inaczej Cruncher odmawiał dalszej kompresji. Potem drugi przebieg pakował dane w obszarze do $cfff, a depacker chyba rozpakowyał dane do końca... ale mogłem coś popier&^#&*# dawno to było... i nie opowiadam o tym aby wywołać jakąś wojnę.... tylko dlatego że uważam to za bardzo fajną ciekawostkę! Zawsze miałem i będę miał szaczunek dla Magnusa ;)
Wcześniesza wersja Cruncher'a Magnusa (4.64) miała tylko jeden przebieg; specyficzne RLE, które ludzie z C64 nazywają char packerem. Czy nie zastanawiała was wersja *.64? bo ja się zawsze zastanawiałem czy to przypadek czy też nie. Potem Magnus dopisał drugi przebieg (LZ77 jak dla mnie) ale ludzie z C64 nazywają to chyba imploding ;)
Co by nie mówić i to i tak Magnus zapoczątkował rewolucję cruncher'ową na małym ATARI. I nie istotne w tej chwili jest czy przepiswyał to z C64 czy nie... ale on to rozpoczoł... i chwała mu za to :)
a skad czerpal wiedze o metodach kompresji? Czy zagladal do C64? ;)
hmmm... nie powiem że SoTe nie przyglądał się Cruncher'owi Magnusa. W tamtych czasach nie było praktycznie żadnej literatury w Polsce dostępnej o tej tematyce. Ale swego czasu ukazała się seria bardzo fajnych artykułow o metodach kompresji a magazynie papierowym "KEBAB" i tam na prawdę było opisane dużo metod i rodzajów kompresji. Z tego co pamiętam SoTe dużo eksperymentował z metodami kompresji i to co wytworzył to wynik jego doświadczeń. Wiem że spakował setki plików aby dobrac tablice i metody kodowania długości sewencji. Trochę nad tym posiedział i zrobił co mógł na tamte czasy. A wyszło mu to chyba całkiem nieźle ;) Bardzo długo Clever People uzywało jego narzędzia do pakowania fileówek ;)
Raz, ze obiecales kiedys podeslac mi spakowana wersje megadema HOBBY-TRONIC '90 lub '91 (?), ktora w czasach snaila dostalem od Ciebie, ale pozniej stracilem ; Dwa, ze chetnie obejrze wszystkie releasy od *CLEVER PEOPLE* !!!! :)
Wiem, obiecałem i pamiętam. Jak tylko się trochę odkuję i znajdę czas na przejrzenie dyskietek obiecuję wszystko udostępnić. Zarówno Ciebie, Strykera jak i pozostałych zniecierpliwionych i zniechęconych proszę o trochę wyrozumiałości i cierpliwości... za jakiś czas na stronie:
powinno się coś zacząć dziać ;)
Zreszta musze wam powiedzieć iż rodzina też narzuca pewne obowiązki na człowiekia i to powoduje że wolny czas czasami kurczy się prawie do 0... ;( także proszę jeszcze o cierpliwość ;)
Wracając do packerów ze stajni SLIGHT, zapomniałem dodać jeszcze o dwóch depackerach ;) W końcu przysły czasy takie że były wokoło AMIGI i ATARI ST ;) A na tych platformach były bardzo szybkie w porównaniu z ATARI programy pakujące (np. PowerPacker dla AMIGI) i bardzo fajny (ICE-PACK) dla ATARI-ST. Już kiedyś o tym wspominałem przy okazji jakiegoś posta na AA, ale może przypomnę iż przy okazji nauki assemblera motoroli 68000 napisałem depacker dla ICE-PACK'a z ATARI ST i dokonałem optymalizacji depackera dla PP20 z amigi... którego to wypatrzyłem w releaseach z Boody Coders ;)
Były jeszcze czasy pakowania wszystkich release'ow z Clever People na C64 ;) Przewalało się dane do spakowania na C64 ;) Pakowało (najczęsciej Cruel Cruncherem lun Exploding Faces Cruncher'em) i przewalało się to z powrtorem na ATARI gdzie po paru modyfikacjach depackera odpalało się to ATARI ;) Operacja wygłądała tak. Spakowana file'ówka ładowała się jak najwyzej w pamięć. Po załadowaniu przepisywana była w obszar $801 (tak jak się ładują programy na C64 ). Odpalało się depacker, te depackery z C64 zawsze rozpakowywały od końca pamięci w dół (znaczy się pierszy bajt rozpakowaywały od $ffff i potem $fffe). Po rozpakowaniu dane się przepisywało w odpowiednie obszary pamięci i działało ;) Możecie mówić iż to było LAME, ale jakie efektywnie i krótkie ;) Przyznaje się bez bica iż biło na głowę Code3 Crunchera i sam nie potrafiłem napisać lepszego Crunchera niż te z C64 (pod względem rozmiaru danych wyjściowych). Prędkości pakowania nz C64 były straaaaaasznie długie... dlatego potem się przerzuciłem na PP20 i PackICE ;)
pozdrawiam serdecznie
Seban/SLIGHT
No i wychodzie, że kiedyś efekty nie były "realtime calculating", tylko "realtime depacking". :D
Ba.... no wiesz... jak byś chciał mapę do "voxel'a" 256x256 pixeli poiliczyć na ATARI to trochę by to zajeło czasu ;) policzyliśmy wcześniej na PC, a potem SFDN Packer i już ... cały Voxel był jednak rysowany realtime, na podstawie mapy wysokości odpackowanej wcześniej ;)
Track scroll też był rysowany realtime, jednak liczenie trajektorji też by zajeło kupę czasu... więc zostały one policzone wcześniej w turbo basicu ;) a potem spakowane sine packer'em ;)
Obroty 3D korzystały ze stablicowanych wymnożonych sinusów ;) zresztą wszyscy do dziś tak robią ;) tyle że dziś bym te tablice sam policzył a kiedyś prościej mi było mieć gotowe tablice i spakować je np. sine-packerem ;)
Zapomniałeś chyba jeszcze o pakerze do 4-bitowych sampli, który został zmuszony do pakowania bodajże HIP-ów. A może to właśnie jest ShanonFano Differentian Nibble Packer? :)
Pojęcia nie miałem iż HIP był pakowany SFDN ;) tak ten packer nadaje się wyśmienicie do sampli i grafiki w trybie 9,10,11 (i wszystkiego o organizacji Nibblowej). Tak naprawdę to myślałem że nikt tego packera poza mną nie ma ;) Nie pamiętam abym go puszczał w obieg ;) ale ja w końcu mam już skrerozę więc może go udostepniłem ;) to było tak dawno temu ;)
pozdrawiam serdecznie
Seban/SLIGHT
Seban, przypomnij mi w takim razie co było czym.
Ehhh.... no to trunde pytanie mi zadałeś ;)
Ja też tak naprawdę mało pamiętam ;(
Ja chyba pamiętam 3 lub 4 wersje Code3 Crunchera ;)
Pierwsza wersja... nie wiem czy wyszła publicznie... charakteryzowała sie tym iż miała jakby 3 przebiegi dekompresji ;) Pierwsza od depacking LZ77 (efekt na ekranie to inc $d01a chyba), drugi etap do dekompresja RLE (efekt to sta $d01a), trzeci etap to długie przemieszczanie rozpakowanych danych w pamięci, na ekranie dość długo migotały chyba ciemno brązowe paski.
Drugą wersją była chyba wersja 2.2 która miała przyspieszone ostatnie przepisywanie... nie było przy nim "wizualizacji". Ona spakowane dane zapisywała na dysk przeznaczony specjalnie dla siebie ;)
Kolejna wersja miała dorobiony już licznik przy depackowaniu pierwszym (LZ77), potem było RLE. Z tego co pamiętam to chyba RzOG wymolestował SoTe o licznik przy dekompresji ;) I do tego packer zapisywał zane już nie na dyskietkę ale do rozszeżonej pamięci i po zakończeniu pakowania dokonywał zapisu całości na dyskietkę.
Coś po głowie mi się pałęta że była wersja 2.2 bez litery "D", która zamiast wykorzystywać zapis spakowanych danych na dyskietkę robiła to w dodatkowej pamięci (potrzbne były 4 banki, czyli 130XE). Ale szybko powstała wersja 3.0 z licznikiem i nie była chyba puszczona w świat wersja 2.2 (bez D), gdzie "D" miało właśnie oznaczać zapis spakowanych danych na dysk. Ale głowy sobie odciąć nie dam ;)
Żaden z w/w cruncherów nie dorobił się szybkiego depackera. Wszystkie posiadały wolną wersje dekompresora. Tak naprawdę do wersja przygotowująca dane dla FastDepackera była dwu przebiegowa... piwerwszy etap normalna kompresja bitowa... drugi etap o wiele szybszy... reorganizacja danych (wyrównanie do granic bajtów).
Idea fast depacker była zrealizowana już chyba przy Bitter Reality... jednak tak byliśmy zajarani efektem "świeczki" przy depackingu że szybki depacker w ogóle nie wchodził w grę bo świeczka się za krótko paliła ;-)
Nie pamiętam kto, ale ktoś pusił na giełdzie w Warszawie plotkę iż mamy wersję Code3 Crunchera ze świeczką przy depackingu... później ktoś pisał do SoTe że chce dostać od niego wersje Code3 Crunchera z efektem świeczki przy depackingu... oczywiście nic takiego nigdy nie istniało ;-) Ale niektórzy ludzie uparcie molestowali nas o wypuszczenie tej wersji na scene ;)
uffff... to chyba tyle ;)
Właściwie to zawsze SoTe pisał packery/depackery i nikt nas nie był z nim w stanie konkurować. Dopiero potem jak SoTe już na JIL nic nie tworzył a my pisaliśmy jeszcze Overminda to powstało kilka nigdy nie opublikowanych packerów na użytek Overminda i gierki SexySix.... na potrzeby Overmind'a napisałem chyba ShanonFano Differentian Nibble Packer oraz Sine Packera. To umożliwiało np. spakowanie 32KB mapy do comancha w chyba 4KB ;) Sine packer idealnie się nadawał do pakowania trajektorji do track scrolla i tablic potrzebnyych dla obrotów 3D ;)
Do Sexy six'a napisałem jakąś dziwną hybrydę podobną do kodowania huffmana ;) już na prawdę nie pamiętam ;) Wiem że zrobiłem jakiegoś wrednego bug'a i był problem przy kompresji/dekompresji niektórych rysunków.... nie miałem już czasu aby to poprawić i problem rozwiązano w ten sposób iż dobrano takie rysunki kótre się nie "syfiły" po komresji i dekompresji. Potem Miker się strasznie namęczył produkując kolejne "data disk" dla Sexy6 bo musiał dobierać rysunki tak aby nie trafić na buga w pakerze/depakerze ;)
więcej packerów ze stajni Code3/Slight nie pamiętam. Muszę w końcu moje dyskietki ratować i je zacząć przeglądać może wtedy da się więcej napisać jeżeli to kogokolwiek jeszcze interesuje ;)
aaa.... był jeszcze jednek packer do Overminda ;) Pakował poszególne fazy fraktala ;) on był bardzo specjalizowany ;) depacker musiał odpackowyać poszczególne klatki w czasie rzeczywistym w międzczasie procedura zoom'ująca musiała przezoom'owywać sie od jednej rozpakowanej klatki do drugiej ;) To było jakieś RLE (poziome albo pionowe) i do tego jeszcze przed pakowaniem była zrobiona detekcja krawędzi tak aby jednolite powierzchnie zostały zastąpione bajtami 0, a odtworzenie obrazu było możwie metodą EOR, STA (jak w wypełnianych wektorkach). Tyle że packer decydował która metoda kompresji daje najmniejszy wynik i wybierą tą najbardziej optymalną ;)
Był jeszcze jeden packer... do textur w 64x64. Był on wykorzystany w niedokończonych nigdy częsciach overminda ;)
He... było jeszcze jedno.... nigdy tego w świat nie puściłem. To było coś w stylu DiskCommunicatora ;) Pakowało całe dyski do pliku i pakowało to jakimś głupim RLE... spakowałem sobie tym kilanaście dysków i potem się okazało że miałem tam jakiegoś buga i połowa stworzonych moim programem obrazów nadaje się do smieci (przewidująco liczyłem nawet CRC z tworzonych dysków). Niestety odkryłem to po tym jak skasowałem już oryginalne wersje ;(
pozdrawiam
Seban/SLIGHT
Gwoli ścisłości: tajną (chyba do dzisiaj) wersją był/jest Code3 Cruncher 2.2(fast depacker)
Tajną? Nie było czegoś takiego jak Code3 Cruncher 2.2 (fast depacker) sensu stricte. SoTe napisał taki programik który wczytywał plik do pamięci (max chyba 48KB) pakował go algorytmem który był w Code3 Cruncherze.... powstawał spakowany plik "zorganizowany bitowo" (strumień bitów).
Fash Depacker, hmmm... Nie wiem jak to prosto i szybko wytłumaczyć.... paker wypluwa spakowane informacje bitami, więc nawet niespakowane sekwencje nie leżą w granicy bajtów, przec co w normalnych warunkach depacker aby odczytać niespakowane kilka bajtów musi użyć procedury GetBit np. n*8 (gdzie n jest liczbą bajtów do pobrania).
Cała tajemnica fast depackera polegała na tym przeorganizowywał on plik w ten sposób że informacje czysto bitowe przechowywał bez zmian, (do popbrania wymagane urzycie procki GetBit), natomiast dane "bajtowe" np. niespakowane sekwencje, przechowywał tak aby je wyrównac do granicy bajtu więc depacker do pobrania bajtu nie musiał wykorzystać GetBit*8 tylko wykonywał zwykłe np. LDA ($80),Y co znacznie przyspieszało procedurę depakującą.
Do takiego spakowanego ręcznie pliku należało dodać później nagłowki (ręcznie) i depacker któremu podwało się dane skąd, gdzie i ile rozpakować. Wszystko ręcznie. Nigdy nie został napisany gotowy program w stylu DJ-Packer'a czy Flash-Packa... dlatego nie został nigdy opublkowany poniweważ większość ludzi i tak by sobie z nim nie poradziła... prog miał toporny interface... taki w stylu np. FileCopy 1.45 ;)
Do tego nie pakował lepiej niż Code3 Cruncher więc SoTe tego nigdy nie dociągnoł do postaci którą by mógł używać normalny użytkownik (normalny -> "nie koder" ;) )
Pierwszym programem który działał tak jak powinno było być to zrobione (w przypadku Code3 Crunchera i Fast Depackera) był packer Jiri Bernasek'a o nazwie SuperPacker. To był dla mnie przykład bardzo dobrze przemyślanego programu pakującego dla plików binarnych (nagłówek $ff,$ff,xx,xx,yy,yy). Nawet przez chwilę miałem zamiar dopisać taki interface dla procedur SoTe jednak jak zwyke w moim przypadku lenistwo zwyciężyło ;-( Potem zobaczyłem DJ-Packera.... i jeszcze później FlashPacka napisanego przez Fox'a ;)
Tak to prawda że wykorzystywaliśmy procedury SoTe do spakowania Overminda ;-) A że to coś nie miało nazwy... postanowiliśmy nazwać to Code3 Cruncher/ Fast Depacker ;)
Miker zresztą powinien pamiętać jak wyglądało składanie Overminda ;)
pozdrawiam
Seban/SLIGHT
Hmmm... pytasz Tatqoo co u mnie. Nie było wesoło. Zieniałem robotę i jak urat w tym czasie jak odszedłem z jednej roboty i zanim zdążyłem pójść do drugiej... rozłożyłem się nieco i wylądowałem w szpitalu ;( Teraz nadrabiam zaległości finansowe i na razie nie mam czasu na nic poza pracą ;-(
Stryker już pewnie jakieś Voo-Doo odstawia wkurzony iż Slight SID jeszcze nie gotowy... kupe fajnych rzeczy jest do zrobienia... gdyby jeszcze pracować nie trzeba było ;) Może do końa roku uda mi się stanąć na nogi i jakoś to będzie.... tak sobie obiecuje od dłuższego czasu że skończę wszystko rozpoczęte projekty... ale miesiące mi przez palce przeciekają.... tygodnie mijają jak dni... czas zapiernicza w takim tempie że nie wiem kiedy to się wszystko dzieje... Czy to jakaś starość? czy czy co? ;)
ps) Muzak zajefajny... bardzo go lubiłem w coverze SoTe, ale Twój jest stereo i też mi się bardzo podoba ;-)
pozdrawiam serdecznie
Seban/SLIGHT
"Soused " a.k.a. Soused Teat/SLIGHT -> SoTe -> Adam Bienias czyli np. autor MusicPro Trackera ;)
pytasz skąd... hmmm... z Warszawy ;-)
Wcześniej Soused Teat wraz z Sebanem ;-) tworzyli Code3 ;)
A obecnie SoTe jest masta-hacka-programistą (Lead Programmer) w http://www.city-interactive.com ;)
pozdrawiam
Seban/SLIGHT
hi!
Prawda, mozna pakowac Amigowskim Power Packerem ;-) Tak kiedys robilem ;-) Procedury do dekompresji gdzies jeszcze mam ;-) Tak sie pakowalo pare lat temu file pod koniec dzialalnosci Clever People ;-)
Mam chyba gdzies jeszcze zrodla moich procedurek depakujacaych do PP20 wlasnie z Amigi, zreszta pomysl stary jak swiat, swego czasu "rilejzy" Bloody Coders byly pakowane wlasnie Amigowskim Power Packerem ;-) (np. Cavernia z logo Bloody Coders, ta w bazie plikow wlasnie jest spakowana PP20).
Potem jak mialem dostep do ST napisalem depacker do PACK-ICE z ST ;-) i kolejne "fajlowki" wlasnie nim pakowalem ;-) Musze poszukac zrodelek ;-) mam nadzieje ze sie dyskietki przeczytaja ;-)
pozdr
Seban/SLIGHT
Hej!
Tu moze sie zdarzyc jeszcze jeden problem. Kod gry moze caly czas przelaczac banki carta aby dostac sie do odpowiednich danych, tak wiec przepiswyanie danych z obszaru $4000-$7FFF w obszar $8000-$BFFF moze byc po prostu klopotliwe i moze uniemozliwic dzialanie gry ;(
Pamietam jak kiedys, Miker sie uparl aby zrobic mu z cart'a gry GATO wersje file ;-) Gra wlasnie caly czas przelaczala banki aby wykorzystac jakies dane. Nie wnikajac w kod gry (bo komu by sie chcialo kod relokowac), rozwiazalem to wlasnie w ten sposob ze wszystklie dane z bankow ktore znajdowaly sie w obszarach $8000-$bfff zostaly umieszczone w dodatkowych bankach i potem procedury przelaczajace banki w carcie zostaly podmienione na procedurke przepisujaca dane z bankow w obszar $a000-$bfff lub $8000-$9fff. Gra dzialala strasznie wolno poniewaz co klatke przelaczala sobie banki ;-) ale poniewaz i tak oryginal rysoawl i tak pare klatek na sekunde to dodanie jeszcze wiekszego spowolnienie nie spowodowalo makabrycznego spowolnienia ;-)
Trzeba by bylo zobaczyc jak czesto commando przelacza owe banki i mozna sie zastanowic czy da sie zrobic file ;-) Jezeli jednak robi to co np. ramke to mozna zapomniec o wersji file ;-)
co do objetosci pliku, to wydaje mi sie ze dane z commado sie bardzo dobrze spakuja ;-) Plik pewnie nie byl by duzy, po spakowaniu jednak gra wymagala by pewnie troche rozszezonej pamieci ;)
Jezeli gra nie przelacza bankow co chwile to mozna by sie pokusic o dekompresje i przemieszczenie danych w odpowiedni obszar w chwili przelaczenia banku przez kod gry ;-)
pozdrawiam
Seban/SLIGHT
Witka!
wrzucilem na szybko na ftp.atari.art.pl:
ftp://ftp.atari.art.pl/upload/lasermania/
pozdrawiam
Seban/SLIGHT
Witajcie!
nie wiem czy to pierwsza wersja ale kawalek gral zespol New Order, a nazywal sie on: "Touched by the hand of God"
pozdrawiam serdecznie
Seban/SLIGHT
ps) a prawie dam sobie glowe uciac ze kawalek z "mission shark" tez jest coverem ;) sproboje poszukac. gdzies go chyba kiedys mialem, nie wiem czy to nie byl jakis .MOD ;-)
ja tez sie dorzucam oczywiscie ;-)
pozdr
Seban/SLIGHT
Witam!
To co robimy zrzutke? Kto bedzie trzymal kase? No i po ile sie dorzucamy?
pozdrawiam
Seban/SLIGHT
TL się odnalazł ... w Hiszpanii chyba ? Przecie trackera udostępnił
Witka!
No to wywiad z nim! wywiad prosze! Jak to sie wszystko zaczelo, dlaczego ATARI? skad pomysly na tak rewolucyjne jak na swoje czasy rozwiazanie? (chodzi mi o dwa kanaly sampli, jeden ze stala czestotliwoscia, drugi ze zmienna ;-)
Widzisz po trakerze nam niewiele ;( Fajnie ze moglismy zobaczyc jak to wyglada... jednak barak osoby ktora by cokolwiek w nim napisala ;-) Ja mam silne wrazenie ze tracker powstal pod sam koniec dzialalnosci TL'a, wczesniej muzyczki pisal chyba recznie ;) ale moge sie mylic ;-) dlatego chetnie bym zapytal go o pare szczegolow ;-) Ale talentu do robienia wywiadow nie mam wcale... wiec sie za to nie zabiore ;-(
edited: Tatqoo, a moze ty napiszesz jak sie to wszystko zaczelo? Dlaczego zaczoles pisac msx na Atari? przeciez tez jestes chodzaca legenda atarowskiej sceny! :) (i do tego nadal tworzaca z zapalem ;-)
Lublin i okolice to swego rodzaju "wylegarnia" milosnikow ATARI i FreeBSD ;-) nie pytajcie dlaczego, po prostu wydaje mi sie ze tak jest ;-)
pozdrawiam serdecznie
Seban/SLIGHT
Dobra, ale promujmy naszych muzyków, a nie komodorowskich!
Witaj!
No nie badzmy samolubni ;-)
Przeciez Rob Hubbard czy David Whittaker tez pisali na ATARI i to "zajefanje" kawalki. Moim zdaniem to ze dany muzyk tworzyl tez na C64 nie skresla go z listy muzykow Atarowskich. Poza tym trudno znalezc informacje o Atarowskich muzykach... ktos zrobil strone podobna do w/w??? Ktos odnalazl naszych rodzimych muzykow z tamtych czasow? (np. Jakub Husak czy Tomasz Liebich)? Ktos zrobil z nimi wywiady? Jezeli tak to wrzucie tu linki bardzo chetnie o tym poczytam ;-) Ci ludzie mnie fascynowali i nadal fascynuja, podziwiam ich tworczosc do dzis ;-) Jak na tamte czasy i robili "mega-zaje-fajne" kawalki ;-)
Do tego Pani ktora pisze prace moze porozmawiac z ludzmi takimi jak wlasnie np. Greg, Xray, BeWu, oraz wielu innych. Oni tworza do dzis i to na bardzo wysokim poziomie. Wywodza sie wlasnie ze sceny ATARI ;-)
Moze Dely lub Dracon, ktorzy slyna z przeprowadzania spektakularnych wywiadow poniwien takze z nimi porozmwaiac ;-) Moze ktos sie pokusi o stworzenie kacika legend muzycznuch ATARI ;-)
Mysle ze skoro na w/w stronie sa materialy z ktorych mozna skorzystac (wywiady, wideo, itp.) To to iz strone zrobili ludzie bardziej zwiazani z C64 nie skresla jej jako zrodla informacji ;) Dzieki info z tej strony jezeli ta Pani bedzie chciala i miala checi bedzie mogla odnalezc tych ludzi i moze bedzie miala okazje z nimi porozmawiac osobiscie ;)
eee.... chyba za bardzo truje, dobra koncze ;-)
pozdrawiam serdecznie
Seban/SLIGHT
Hej!
Greg! Mysle ze ta Pani tuaj znajdzie ludzi ktorych szuka:
http://c64audio.valuehost.co.uk/edge/
pozdrawiam serdecznie
Seban/SLIGHT
Czesc!
U mnie demko dziala w 100% poprawnie na emulatorze ;)
I pierwsza strona Ok, druga strona OK. Takze nie wiem o co wam chodzi ;-)
Co do dema.... autorom nalezy sie frasunek za design. Duuuuuuzoooo pracy wlozyli aby to wygladalo tak jak wyglada. Co tu duzo gadac, wyrazy uznania za chec zrobienia czegos wiecej od standardowego dema typu efekt za efektem :D Jest jeszcze jedna rzecz ktora wyroznia to demo... Kolory :-D Od czasow Visdooma (a.k.a. JAC!) nie pamietam rownie kolorowego dema ;-)
pozdrawiam
Seban/SLIGHT
Hej!
Swietny pomysl, teraz ludzie ktorym sie nie chce analizowac asmowego kodu moga zobaczyc, iz niektore efekty ktore pokazales w swiom demie sa o wiele bardziej skomplikowane obliczeniowo od np. wypelnianych czy teksturowanych wektorow ;-) Idealnym wrecz przykladem sa twoje przyslaniajace sie druciane wektorki ;-) Dla wypelnianych nic trudnego, proponuje jednak aby ktos sprobowal napisac sobie takie druciane sam ;-) Zobaczy wtedy iz algorytm nie jest taki oczywisty ;-)
pozdrawiam serdecznie
Seban/SLIGHT
witajcie!
Mega-Giga WIIIEEEELLLLKIII Frasun dla Van Ejka!
Wspomnienia z przed 9 lat powrocily ;-)
Zajebis%^& impreza!
Zajebi#*( ludzie!
Zajebi^&& KLIMATY!
pozdrawiam wszystkich!
Seban/SLIGHT
Hej!
Jaskier! Mega-GIGA-Frasunek!
Cliping 2D, 3D ... ze Tobie sie to chcialo zaimplementowac ;-)
i do tego zajbis$%@#^%@ grafika BeWu ;-)
OldSchool Rulez!!!
pozdrawiam serdecznie
Seban/SLIGHT
ps) ahhh... stare dobre czasy! ;-) Czekam na Back2Life3 ;-)
Seban: co powiesz nt. odporności na zakłócenia ST7 (72F264) ? Używam ten scalak jako sterownik klawiatury w falownikach (takie maleństwa o mocach od 1 do 250kW) właśnie ze względu na hipotetyczną odporność na zakłócenia co nie jest dobrą stroną atmela. Być może masz własne spostrzeżenia ?
Czesc!
Powiem tak, seria ST6 ma wprost legendarna odpornosc na wszelkiego rodzaju zaklocenia ;-) Seria ST7 ktora stosuje w urzadzeniach klasy "Automotive" jest moim zdaniem rownie odporna ;-) I moim zdaniem zastosowanie serii S7 w tak "zasyfialym" srodowisku jakim jest praca w otoczeniu falownika to bardzo trafny wybor! ;-)
A tak z ciekawosci zapytam, co steruje praca falownika (znaczy jaki MCU)? Nie zajmiuje sie co prawda sterowaniem falownikami ale zdarzylo mi sie grzebac w UPS'ach firmy PowerWare serii 9, ktore to maja pelne przetwarzanie, tzn. w wielkim uproszczeniu prostuja sobie napiecie sieci, a potem falownik od nowa wytwarza czysta sinusoide na wyjsciu ;-) W starszczej generacji tychze UPSow widzialem jakas duza Motorole 68HCxx, natomiast w nowych siedza juz mikrokontrolery Hitachi serii H8 (obecnie chyba Renesas).
W moich projektach "samochodowych" gdzie az roi sie od roznego rodzaju zaklocen (maksymalnie zasyfiale zasilanie, silne pola elektromagmetyczne, sterowanie obwodami zawierajace duze indukcyjnosci i wszytkie inne mozliwe obciazenia), powiem ze seria ST7 sprawuje sie rewelacyjnie ;-) chociaz na PIC'ki od Microchipa tez nie moge narzekac ;-)
Podsumowujac, tak naprawde to kazdy MCU moze sie okazac zawodny jezeli niewlasciwie zaprojektujemy urzadzenie, odpowiednio zaprojektowane PCB, dobre zabezpieczenie lini wchodzacych i wychodzacych z MCU to daje nam juz 90% sukcesu. Ale w rzeczywistosci nie jest tak latwo ;( jezeli mam minimalizowac koszty urzadzenia i nie moge wlozyc parudziesieciu elementow aby bardziej uodpornic dany projekt na wszelkiego rodzaju zaklocenia, to musze powiedziec ze przy minimalnej ilosci elementow zewnetrzych wlasnie seria ST7 i PIC'e radza sobie najlepiej ;-)
uffff.... tyle apropos moich wnioskow na temat odpornosci MCU na zaklocenia ;-) teraz pare slow o architekturze 8051.
Tez myslalem ze architektura 8051 to przezytek i tylko stare dziadki sie tym zajmuja, postanowilem ta czesc segmentu olac i nie zajmowac sie rozwiazaniami historycznymi ;-)
Niestety teraz sie to na mnie msci, to czego unikalem jest prawie wszedzie !!! Lata obecnosci tej architektury na rynku sprawily ze cale stada ludzi zna wylacznie ta architekture i projektanci/programisci dalej wybieraja architekture 8051. Prosty przyklad... zagladamy np. do urzadzen firm Posnet lub Optimus-IC (mowimy o kasach i drukarkach fiskalnych). Otoz co tam widzimy.... o zgrozo seria 8051. Dwoch niezaleznych producentow stosuje ta sama architekture... niestety :(
Ja rozumiem ze mozna projektowac nowe urzadzenia na nowych MCU i nie wykorzystywac takich archaicznych rozwiazac jakim jest seria 8051, ale tu mozemy zauwazyc jeszcze jedno zjawisko. Wszystkie wieksze firmy uparcie ciagna ta architekture rozwijajac ja niesamowicie. Przykladem takiego dziwnego dla mnie posuniecia sa MCU kompatybilne z 8051 o wydajnosci 100MIPS, o np tu:
http://www.silabs.com/products/microcontroller/
Nie jestem bron boze zwolennikiem architektury 8051, ale sam juz nie wiem co o tym myslec ;( wszyscy narzekaja ze to starocie, ze sa inne rozwiazania ale wszyscy je nadal wykorzystuja. Mysle ze jest to podyktowane bardzo duza iloscia ludzi ktorzy "wyrosli" niejako na tej architekturze i wlasnie ten fakt wykorzystuja firmy sprzedajace MCU zgodne z ta architektura ;)
Co do assemblerow hmmm.... powiem tak ja nie mam innego wyjscia ;( kompilartor C moge wykorzystac jak mam do dyzpozycji chociaz ze 4KB pamieci w MCU, jednak obecne projekty ktore wykonuje maja byc tanie, bardzo tanie.... wiec MCU ktore moge wykorzytac maja od 1 lub 2 KB pamieci, no w ekstremalnych wypadkach dostaje MCU ktore ma 4KB na kod programu, i nie wiem co bym nie robil to kompilator C mi nie pomoze, bo nie dam rady przy jego pomocy upchnac calego kodu w pamieci MCU ;(
jednak gdy mam do dyspozycji wieksza ilosc pamieci to nie mysle nawet o assemblerze tylko pisze wlasnie w C, jednak pewne fragmenty zawsze bedzie sie oplacalo napisac w ASM. Zreszta kompilator, kompilatorowi nie rowny ;) kazdy dziala inaczej i ma inne wymagania ;)
Tu jednak natrafiamy na druga strone medalu, sa procesory dla ktorych moim skromnym zdaniem pisanie w ASM zeczywiscie mija sie z celem, bo kompilator na pewno wykona robote lepiej od nas. Mysle ze dobrym przykladem moze byc tu procesory oparte o rdzen ARM. Tu pisanie w ASM to czysta herezja ;)
Zawsze chcialem opanowac programowanie DSP (np. Texas Instruments) jednak nigdy nie mialem wystarczajacej ilosci czasu aby sie za to zabrac, no i odstraszala mnie cena zestawow startowych i programatorow ;(
ufffff.... ale truje ;) pora konczyc.
Reasumujac, teraz nadchodzi era programowalnych ukladow logicznych, za chwila kazdy bedzie mogl sobie wlozyc dowolnego MCU do wiekszej Altery, Xilix'a czy Cypress'a. Jezeli nawet nie bedzie w stanie sam "zrobic" sobie wlasnego MCU w VHDL'u to zawsze moze skozystac z gotowego "jadra" dowolnego CPU, sa nawet projekty ktore udostepniaja cale "klocki" za darmo: http://www.opencores.org/
Motorola 68HC05, czy 8051, AVR czy cokolwiek innego na 300MHz nie ma problemu ;-) bierzemy gotowy projekt z opencores i wpakowujemy go do naszej programowalnej struktury logicznej ;-)
Na razie koszty jeszcze wysokie, ale juz za chwile stanie sie to popularne, wiec i tanie ;-) no coz przyslosc pokaze ;-)
na tym koncze moj wywod ;-)
pozdrawiam serdecznie
Seban/SLIGHT
Czesc!
Z moich szybkich poszukiwan wynika co nastepuje:
http://www.atmel.com/products/8051/ - atmelowskie zgodne z 8051 MCU
albo dokladniej, czyli gotowa lista:
http://www.atmel.com/dyn/products/devic … ily_id=604
pewnie zainteresuja cie sekcje:
#1) Flash ISP (In-System Programmable)
#2) Flash (Reprogrammable)
na poczatek mozesz probowac z malenstwami typu AT89C2051:
http://www.atmel.com/dyn/products/produ … rt_id=1938
na w/w stronach jest takze kupa dokumentacji ;-)
przyklady programow, gotowych urzadzen.
Atmel daje wiele aby przekonac do swoich mikrokontroerow ;-)
zreszta podobnie jest z Microchipem ;-)
Jezeli masz problemy z zakupieniem atmeli proponuje np:
http://www.seguro.pl/cgibin/shop?show=P … d=70382876
jak widac AT89C2051 kosztuje 5.36 juz z VAT ;-)
w/w sklep internetowy handluje glownie Atmelami wiec oprocz seri zgodnej z 8051 mozesz kupic takze AVR'y i ARM'y ;-)
http://www.seguro.pl/cgibin/shop?show=K … d=70382876
edited:
Przypomnialo mi sie ze jeszcze infineon produkuje sersie zgodna z 8051:
http://www.infineon.com/cgi/ecrm.dll/ec … ?oid=-8136
nie wiem jak z programatorami do tej serii, ale moze warto sprawdzic. Pojecia jednak nie mam gdzie to kupic ;-(
i jeszcze z tego co wiem Philips od wiekow promuje architekture 8051:
http://www.semiconductors.com/catalog/2 … html#45992
interesuje Cie sekcja "80c51 architecture", ale problem ten sam co wyzej. nie wiem gdzie kupic i nie wiem jak z narzedziami i srodowiskiem (IDE).
pozdrawiam serdecznie
Seban/SLIGHT
ps) troche to trwa zanim odpisze ale mam bardzo malo wolnego czasu ostatnio ;(
Jezeli nigdy nie miales doczynienia z mikrokontrolermai to proponuje nastepujaca lekture:
http://www.btc.pl/index.php?id=zmuk
potem musisz sie zdecydowac jakie mikrokontrolery chcesz programowac, i ile chcesz przeznaczyc pieniedzy na narzedzia. Z tego co wiem to bardzo popularne w polsce u poczatkujacych w tej dziedzinie sa mikrokontrolery firmy ATMEL. Programator mozesz dla nich zlozyc sobie sam, dostepne sa darmowe srodowiska programistyczne i darmowy AVR-GCC. Ja nie korzystam z produktow firmy ATMEL, wiec wiecej Ci powiedziec o nich nie moge.
Do wyboru masz jeszcze kontrolery takich firm jak: ST (seria ST6,ST7 jest bardzo podobna do budowa do 650x, arch. CISC), Motorola (seria 68HC podobna do 650x, arch. CISC), Microchip (latwe do opanowania RISC'owe mikrokontrolery, tylko 36 instrukcji, szybkie, ale bardzo drogie programatory/ICD), ZILOG (seria Z8, ale to chyba tylko dla milosnikow architektury Z80 ;-). I wiele, wiele innych.
Na poczatek chyba proponowal bym Ci rozpoczecie zabawy od MCU (mikrokontrolerow) ATMEL, mysle ze sa one na tyle popularne w polsce ze duzo ludzi bedzie moglo Ci pomoc w rozwiazaniu pierwszych problemow z programowaniem tychze ;-) Gdy wybierzesz ATMELa mozesz wybrac rozne drogi i rozne rozwiazania. Mozesz rozpoczacz przygode od Atmeli zgodnych z architektura MCS8051 lub probowac swoich sil z riscowymi mikrokontrolermai serii AVR. Mozesz pisac w czystym ASM'ie, mozesz uzyc kompilatora C, mozesz nawet zaczac od czegos co sie nazywa BASCOM. Nie wiem na jakim poziomie jestes i jak szybko beddziesz "lapal wiedze", ale sadze ze BASCOM moze byc dobrym rozwiazamiem jako pierwszy kontakt z MCU. Jedni mowia ze BASCOM wyrabia zle nawyki, inni twierdza ze wrecz przeciwnie. Ja nie mam jednak opnii bo go nigdy nie uzywalem ;) . Jezeli poczytasz sobie wiecej o BASCOM i stwierdzisz ze moze Cie to zainteresowac to ostatnio w pismie ktore sie nawywa Elektronika Plus (dodatek dla elektroniki dla wszystkich) byl BASCOM + plytka prototypowa na ktorej siedzial jakis ATMEL 90Sxxxx zgodny z 8051.
http://www.sklep.avt.com.pl/go/_info/?id=8213
tam jest chyba pelny kurs BASCOMA i kompilator dla serii zgodnej z '51 i AVR.
Jezeli zdecydujesz sie na serie AVR to mozesz sobie kupic ksiazke:
http://www.btc.pl/index.php?id=avr
Osobiscie nie korzystam z MCU od ATMEL'a. Ja zajmuje sie MCU od ST,MICROCHIPA i toszeczke MCU od Motoroli. Koszt programatorow/debuggerow wspolpracujacych z IDE (mam na mysli srodowisko programistyczne) poszczegolnych firm jest nastepujacy:
MICROCHIP - MPLAB ICD2 -> 1100zl+VAT
ST - InDart STX/D -> 1000zl+VAT
MOTROLA - nie wiem, bo dostalem za free ;-)
Zilog - $100
Z tego co wiem w przypadku ATMELA, mozna sobie samemu zmontowac programator/debugger za naprawde niewielkie pieniadze. Ale tu musza sie wypowiedziec inni, bo ja Atmelem sie nie zajmuje ;-)
Oczywiscie do MCU microchipa czy ST tez sa schematy prostych programatorow w sieci, jednak zaden nie zapewnie pelnej funkcjonalnosci z IDE dostarczonym przez producenta.
A jeszcze jedno, MCU ATMEL sa dostepne praktycznie wszedzie po przystepnych cenach i mozna bez problemu kupic pojedyncze sztuki. Z dostepnoscia innych MCU dla szarego zwyklego uzytkownika jest mniejszy lub wiekszy problem, jezeli juz ktos zechce sprzedac nam jakies MCU w niewielkiej ilosci to tak wywinduje cene ze nam sie odechce. Dystrybutorzy zupelnie inaczej podchodza do firm a zupelnie inaczej do osob prywatnych. Mysle ze jednym z powodow popularnosci ATMELA jest to ze jest on "wszedzie" ;-)
ufff... to chyba wszystko co chcialem napisac!
powodzenia zycze!
pozdrawiam serdecznie
Seban/SLIGHT
ps) w polsce panuje niestety dziwna opinia na temat MCU od ATMEL'a. Duzo ludzi twierdzi iz ATMELe sa bardzo nie odporne na "silne zaklocenia". Probowalem wypytywac kiedys, co znaczy ze sa nie odporne, jednak nikt nie udzielil mi konkretnej odpowiedzi ;-) Wiem ze to nie doczyty tematu jednak, moze ktos z was ma jakies opinie na temat odpornosci na zaklocenia MCU od ATMELa?
atari.area forum » Posty przez seban
Wygenerowano w 0.075 sekund, wykonano 19 zapytań