A jednak :) to słychać :)

A tak btw, zawsze się zastanawiałem jak to jest w ATARI ST, tam procek ma 8MHz, a AY jest taktowany chyba 2MHz, jak wyglądają zapisy do układu AY z punktu widzenia procesora ;) Przecież moge zrobić parę zapisów do jego rejestrów i on nawet ich nie zobaczy ;) Czy może procek jest wstrzymywany na czas zapisu do AY???

Dokładnie tak, tyle że jeszcze trzeba zapanować na ChipSelectem ;) i odpowiedniej chwili go wygnerować dla SID'a. A ponieważ nie wolno dopuścić wieloktornego zapisu tej samej wartości do SID'a... i już mówię dlaczego, np. wpis do danego rejestru startuje gen. obwiedni, a ponowny wpis powoduje jego restart. W momencie dwukrotnego zapisu tej samej wartości may kiszkę. Prote playery działają jednak te bardziej zakręcone już się syfią :(

pozdrawiam
Seban/SLIGHT

Cześć!

To zupełnie nie związane z tematem ale Wy jako specjaliści od MAC65 może mi odpowiecie na moje zakręcone pytanie :) Kiedyś sam używałem MAC65 i uważałem że inne narzędzia się do niczego nie nadają... i do tego miałem manie zapisywanie wszystkiego dziesiętnie :) ale pewnego dnia przyszedł SoTe i mnie spacyfikował, od tego czasu stałem się niewolnikem QA :) i musiałem uznać wyższość systemu hexadecymalnego nad dziesiętnym ;)

Ale wracając do tematu... z tego co pamiętam plik .OBJ wygenerowany przez MAC65, miał bardzo smieszne nagłowki, cały plik był podzielony na jakieś śmieszne bloki po $fa bajtów chyba, czyli np. jak kod znajdował się w obszaże $8000-$9000, wyglądało to chyba tak:

$ff,$ff
$00,$80,$f9,$80, <dane>
$fb,$80,$ff,$80, <dane>
$00,$81,$fa,$81, <dane>
<itd.>

mogłem coś pokręcić ale chyba jakoś tak to wyglądało (może inne były długości). Zawsze się zastanawiałem po jaką cholerę MAC65 taki motyw robi ;) Doszło nawet do tego że napisał kiedyś program linkujący położone obok siebie bloki w pliku w jeden większy ;)

Może Wy właśnie (Pecuś lub Pirx) wiecie dlaczego MAC65 właśnie coś takiego robił? Wiem że to głupie, ale pytam po prostu z czystej ciekawości. Kiedyś sobie to tłumaczyłem tym iż MAC65 ma po prostu bufor 256 bajtów, i w takich kawałkach własnie zapisuje dane.  Ale czy jest to prawidłowa odpowiedź... nie wiem ;)

A jeszcze jedno słowo apropos FAT'u... kiedyś była taka ksiązka "DOS 5.0 od środka, z tego co pamiętam, tam dość dokładnie była opisana struktura FAT12 i FAT16. Może ją gdzieś jeszcze mam. Jeżeli byłoby to przydatne to mógłbym jej poszukac i przeskanowac parę kartek z rozdziału o strukturze FAT.

pozdrawiam
Seban/SLIGHT

Hej Dracon!

Może po kolei... z tego co ja wiem pomoc wbudowana we frezzera byla juz w wersji ktora zostala zmodyfikowana przez Roberta Kujde albo kogos z jego otoczenia. Ta wlasnie ta wersje poprawial i modyfikowal SoTe robiac Code3 Freezera. W code 3 freezereze rowniez byla pomoc, po wcisnieciu klawisza chyba "H" w debugerze.

Co do zabezpieczania Technoida... chyba się coś Ci pomyliło, bo ja nie zabezpieczałem chyba (a może już nie pamiętam ;)  żadnych gierek komercyjnie. Kiedyś co prawda na prośbę niejakiego 'ciapka' daliśmy chyba nasze procki, które miały być w jakieś grze chyba z Mirage, ale nie wiem czy kiedykolwiek ktoś to wykorzystał. Jedyne produkty zabezpiecznoe przed freezerem to były nasze niektóre demka i programy. Np. Digital Studio, Sample Editor były zabezpieczone przed freezowaniem. Ale nie miało to na celu zabezpieczenia przed zrobieniem wersji file tylko miało to na celu utrudnienie posiadaczom freezera możliwości zaglądania w nasz kod ;)

I tak Ci co wiedzieli jak mogli zrobić wszystko bez freezera ;)

Seban/SLIGHT

Hej!

W załączniku to co było na stronie atari-magazynu. Również takie same materiały dostałem od Pana Soboli. W jakiś magiczny sposób udało mu się to oddłubać i przerysować schemat. Nie wiem czy jest poprawny i czy nie ma na nim żadnych błędów.

Tak naprawdę to Freezera uważam za jedno z najlepszych modyfikacji ATARI. Tak naprawdę to dzięki niemu powstał software napisany przez SoTe, RZoG'a i mnie. Niestety każdy z nas miał to jako płytkę zalaną distalem i nikomu się nie udało tego oddłubać. Kiedyś próbowałem, ale skończyło się to tym iż musiałem sobie zakłądać drugiego freezer'a.

Zawsze chciałem wiedzieć kto wymyślił to genialne rozwiązanie sprzetowe :) podobno było ono opublikowane w magazynie Happy Computer, ale jest to tylko plotka i nie wiem czy to prawda.

Może ktoś coś wie, bardzo fajnie by było odtworzyć to rozwiązanie. Niestety nie mam zbyt wiele czasu na takie działanie i nie chciałbym sobie popsuć jedynego działającego freezera którego posiadam.

Mi Freezera montował Pan Kszysztof Stec z giełdy na grzybowskiej. Widziałem kiedyś oryginalnego Happy Freezera. Widziałem także wersję zamontowaną przez Roberta Kujdę. Podobno oryginalna wersja freezera była podłączana tylko pod to złącze krawędziowe w Atari 800XL.

Jeżeli ktoś coś może o tym napisać, dajcie znać!

pozdrawiam
Seban/SLIGHT

Nie abym się czepiał, ale sądzisz że taki dystrybutor sprzeda Ci parę sztuk? Oni będą chcieli od ciebie planu zamówień na najbliższe 3 lata. A minimalny zakup to będzie 1000szt. Próbek też nie dostaniesz bo nie jesteś mega-firmą która może w przyszłości zamawiać jakieś znaczące ilości więc na 99% będą Cię olewać/ignorować. :(

Mam nadzieję iż się mylę i że w końcu komuś się uda dostać parę sztuk tego układu w rozsądnej cenie ;)

pozdrawiam
Seban/SLIGHT

hej!

No mistrzu, jesteś wielki :D

Co prawda to tylko schematy cart'ów. Ale zawsze to coś na dobry początek ;)
Teraz jeszcze tylko schemat interface AST wkładenego do magnetofonu i będe maksymalnie szczęśliwy ;) Może ktoś gdzieś ma ;) Próbowałem kupić jakiś magnetofon z wbudowanym AST jednak jakoś mało skutecznie :(

pozdrawiam serdecznie
Seban

Cześć!

tak, te schematy już wcześniej widziałem. pierwszy z nich jest schematem jakiegoś cart'a. Zresztą nie mam pojęcia jakiego, ponieważ Turbo K.S.O.2000, czy tzw. Turbo w wersji F, nie posiadało pamięci RAM w cart'cie a na w.w. schemacie taka możemy zobaczyc... natomiast drugi z wymienionych schematów to shemat przeróbki Turbo 2000 KSO (podłaczanej do portu joy'a).  Oraz cart'a do tego systemu

A ja chciałem zapytać czy kotś nie ma może schematów Blizzard'a i AST (Atari Super Turbo).

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!

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 :)

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 ;)

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:

http://www.n-s.pl/slight/

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

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

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

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