1 Odpowiedź przez marok

(14 odpowiedzi, napisanych Programowanie - 8 bit)

Nie jest w tradycji pisać zbyt obszernie na tym forum, więc tym chętniej skupię się wyłącznie na podziękowaniach.

@Xxl: Dzięki za podjęcie tematu. Dzięki Tobie temat zaistniał i wypowiedziały się tutaj pewne znakomitości. Czuję się troszkę zobowiązany.

@JHusak: Za czujność i aktywność. (Z reguły zawsze pierwszy i można na niego liczyć, że się do czegoś wypowie, nawet jeśli nie ma innych chętnych. Nie gardzi niczym i nikim.)

@Seban: Jak się za coś bierzesz to raczej już "do spodu". Szacunek, bo solidnym podejściem i ogólną sprawnością bywa że imponujesz. Masz też przyjazne podejście do innych i szacunek. To tak przy okazji tej sytuacji sobie pozwalam. Przepraszam, jeśli to mało stosowne.

@Lizard: Człowiek, któremu osobiście zawdzięczam pewien postęp w sztuce programowania, z czego może nie zdawać sobie sprawy. Wcale tu nie zmyślam, ale tak się składa. Coś z tych lekcji i porad na tym forum zresztą zamieszczanych (w odleglejszej już przeszłości) sądzę że wyciągnąłem. (Specjalnie dla mnie to pisał.)

@Willy: Nie wiem do końca jak z tą Twoją wersją było, ale wygląda na to, że obmyśliłeś ją szybciej niż mnie się udało dojść do analogicznego rezultatu (tak twierdzę, że niezależnie mi także, ale prawem jest wątpić). A przecież "szybkość ma znaczenie" (tu byłbyś górą). Gratulacje - jeśli właściwie rozumiem tą sytuację (że to Twoje). (Bo na 100% z tekstu tego nie umiem stwierdzić. Na 99% już tak. Nie mam podstaw i powodów wątpić, chociaż kolegi nie znałem że umie w 6502. Ale to tym lepiej dla "społeczności", że… gdybym teraz napisał coś pochlebnego, to w jakimś sensie mogłoby to zostać zinterpretowane, że pisałbym też o sobie, więc musimy to sobie tym razem darować.)

Idź do forum: Programowanie - 8 bit

2 Odpowiedź przez marok

(9,921 odpowiedzi, napisanych Bałagan)

Tutaj polecano "dziennikzarazy" (z czego skorzystałem - i dziękuję). W ostatnim z tam zamieszczanych wpisów, zetknąłem się z informacją w komentach, iż w necie dostępna jest opiniotwórcza relacja z własnego leczenia na oddziale covidowym pewnego pana - jakiegoś rozpoznawalnego youtubera. Odszukałem tą audycję, przesłuchałem - faktycznie, jak dla mnie, jak najbardziej godna polecenia (a w sposób szczególny niezaszczepionym).

Bardzo solidne wrażenie robi człowiek przedstawiający swoją relację, z trzeźwym i zrównoważonym osądem, wypowiada się jasno i płynnie. Na pewno łatwo i dobrze się go więc słucha. Oprócz tego film jest bardzo klimatycznie zmontowany przy wykorzystaniu sentymentalnego i raczej wzruszającego utworu / piosenki (co trudno mi jakoś też nie odnotować).

https://www.youtube.com/watch?v=fJOaUDnB6Wo



A mi się jeszcze przypomina inna historia, którą można odtworzyć z wiadomości z netu na temat pewnej osoby i okoliczności jej śmierci (kiedyś to sobie wyhaczyłem). W tym sensie, że jest to jakieś potwierdzenie podobnych zjawisk czy praktyk, o jakich opowiada ten pan z tej wcześniejszej relacji.


http://wikijustice-contre-la-dictature- … -placowce/

http://wikijustice-contre-la-dictature- … golimonta/

Idź do forum: Bałagan

3 Odpowiedź przez marok

(9,921 odpowiedzi, napisanych Bałagan)

Domyślam się, że część wiadomości z linkami do oryginalnych tekstów w angielskim ma swoje źródło pierwotnego zetknięcia się z informacją ze strony Dakowskiego. (Sam czytuję regularnie od stosunkowo niedawna - warta polecenia.)

Jest to też inspiracja dla mnie w tym poście.

Ale wcześniej tylko trochę skomentuję apriori.

W zestawie medycznym, o którym wspomniano dalej (nie jest on tutaj najważniejszy), jest jednakowoż Paracetamol, który został już rozpoznany jako wybitnie szkodliwy w przypadkach Covid.

Chodzi o to (cytat z naukowej publikacji, a reszta z omówienia na stronie):

"Hipoteza, że niedobór glutationu jest najbardziej prawdopodobnym wyjaśnieniem poważnych objawów i śmierci u pacjentów z COVID-19, została wysunięta na podstawie wyczerpującej analizy literatury i obserwacji."

Pacjenci o średnim do ostrego przebiegu COVID-19 mają niższe poziomy glutationu. Potwierdzono to testami oraz przy pomocy dowodów pośrednich (palacze, astmatycy i osoby starsze stanowią dużo cięższe przypadki. Jednym wspólnym mianownikiem dla tych grup demograficznych jest niższy poziom glutationu.

W obliczu powyższych danych niezwykle istotną informacją jest, że ACETAMINOFEN (PARACETAMOL) OBNIŻA POZIOM GLUTATIONU.

źródło:
https://psnlin.pl/artykuly,paracetamol- … 1,100.html


Jako że troszkę interesowałem się, co tam się dzieje w Indiach, więc wcześniej jeszcze kilka mniej precyzyjnych informacji ode mnie, o których mam chęć także napisać.
W Indiach szczepi się prawie wyłącznie dwoma specyfikami: Covishield - odpowiednik AstraZeneci - oraz Covaxin. Ten ostatni to jest ciekawe rozwiązanie kompromisowe dla osób, które teoretycznie zgodziłyby się zaszczepić, ale nie mają zaufania do tych nowoczesnych szczepionek (przede wszystkim tych opartych na mRNA). Ma dobre referencje i wydaje się bezpieczna. Podobno odporność po niej przypomina tą naturalnie nabytą. Niedawno z początkiem nowego roku zarządzono szczepienie dzieci bodajże od 12 do 17 roku życia i to jest jedyna szczepionka na jaką zezwolono, aby ją stosować w tej grupie wiekowej. Były też próby rozmów z Ph. (dawniej, przy dużej skali zachorowań) na temat możliwości wejścia z produktem na rynek indyjski i rzecz podobno rozbiła się o to, że producent nie chciał brać odpowiedzialności za szkody wynikłe z nieporządanych reakcji (jak we wszystkich krajach).

Na marginesie, kiedy pojawiła się informacja, że rusza kampania 'boostowania' w GB, sprawdziłem z ciekawości czym chcą oni tym razem tam szczepić. Wyszło, że obligatoryjnie jest to Ph. (jest to zmiana jakościowa) lub na wyraźną prośbę AZ (również mogą i M. ale wtedy, co jest dość ciekawe, podają chyba połowę normalnej dawki).


No więc wracam teraz do tego, co chciałem zamieścić z cytatów i linków. (Generalnie chodzi w nich o to, dlaczego może w niektórych krajach jest źle, a w innych lepiej, jeśli chodzi o przypadki Covid.)


https://www.thedesertreview.com/opinion … 2647b.html

On May 7, 2021, during the peak of India's Delta Surge, The World Health Organization reported, "Uttar Pradesh (is) going the last mile to stop COVID-19."

The WHO noted, "Government teams are moving across 97,941 villages in 75 districts over five days in this activity which began May 5 in India's most populous state with a population of 230 million."

The activity involved an aggressive house-to-house test and treat program with medicine kits.


Each home kit contained the following: Paracetamol tablets [tylenol], Vitamin C, Multivitamin, Zinc, Vitamin D3, Ivermectin 12 mg [quantity #10 tablets], Doxycycline 100 mg [quantity #10 tablets]. Other non-medication components included face masks, sanitizer, gloves and alcohol wipes, a digital thermometer, and a pulse oximeter.


By September, cases had fallen dramatically. Out of the entire state of 200 million plus inhabitants, only 187 active cases were left compared to the peak in April of 310,783 cases.

Dr. Campbell attributes their success to many factors, including early detection and early treatment with kits costing a mere $ 2.65 per person.

Notice that Dr. Campbell does not mention a single person who had any toxicity from those ten 12 mg pills of Ivermectin - in the entire state of over 200 million. Not one poisoning was reported. No Indian poison control articles or telephone calls were reported. Out of millions of distributed medicine kits, each containing 120 mg of Ivermectin, not one person in Uttar Pradesh was reported to have had a problem with the drug.



{ peer-reviewed meta-analysis, by an Altimetric score }


This peer-reviewed paper is one of the most cited of medical references of all time – period. That should alert any reader – immediately - to its historical significance.



#38/18,000,000

“Finally, the many examples of Ivermectin distribution campaigns leading to rapid population-wide decreases in morbidity and mortality reduction indicate that an oral agent effective in all phases of COVID-19 has been identified.”


#8/18,000,000

“Moderate-certainty evidence finds that large reductions in COVID-19 deaths are possible using Ivermectin. Using Ivermectin early in the clinical course may reduce numbers progressing to severe disease. The apparent safety and low cost suggest that Ivermectin is likely to have a significant impact on the SARS-CoV-2 pandemic globally.”


Perhaps every reader needs to ask themselves this question - Why is it that BOTH Dr. Lawrie’s and Dr. Kory’s supremely-rated expert review articles, published in the medical literature on PubMed, the National Library of Medicine, are BANNED from Wikipedia?


Although India’s Ivermectin victory over COVID  may have been lost on bent-on-vaccinating-everyone Big Pharma and Big Regulators, the message seems to have gotten through to the man on the street. If Google Trends is any indicator, interest in Ivermectin is exploding, and for good reason. We are all being systematically deceived by influential organizations in the name of profits.


Interest in Ivermectin and India is only increasing and has now reached an all-time high. India’s conquest of COVID-19 is concealed no longer. The secret is out.

---

https://www.thedesertreview.com/opinion … 7887a.html

Viral loads of the vaccinated are just as high as those of the unvaccinated as the CDC has admitted. This means that a vaccinated infected person can spread the virus just as quickly as an unvaccinated. Moreover, the viral load of the Delta infection is often on the order of 1,000 times greater than in the original strain. Finally, a vaccinated person may have milder or no symptoms leading them to take fewer precautions.

Idź do forum: Bałagan

4 Odpowiedź przez marok

(13 odpowiedzi, napisanych Fabryka - 8bit)

@mono: double play gra jak napisałeś, ale daje to zupełnie zadawalający efekt.

Kod playera do CMC2000 też sobie analizowałem i mam zdanie, że jedna ze zmian w tablicach częstotliwości to raczej błąd edycyjny, ale druga, stawiałbym że może była zamierzona.

$DE zamiast $CE (tu bym stawiał na błąd)
$30 zamiast $39 ($39 jest powtórzona dwa razy, a są w odległości od siebie o zaledwie 3 pozycje; tu bym podejrzewał świadome działanie)


Jest też różnica w tablicy głośności (256 bajtowej) na niektórych pozycjach w stosunku do wersji 2.02, a obie różnią się od tej z tmc.

Piszesz, że kod playera jest źle relokowany (rozumiem, że chodzi o wersję 2000) ze względu na kod relokatora, jak rozumiem, ale moim zdaniem, o ile tak rzeczywiście jest (sam tego nie zauważyłem, ale też nie generowałem procedury odgrywającej bezpośrednio z tej wersji programu) to nie jest to wina samego kodu, bo kod na pewno jest ten sam, natomiast mogło dojść do błędu w fixup'ach do procedury relokacyjnej.

Ogólnie, to moim zdaniem nie warto supportować wersji 2000, bo format ten jest raczej niedopracowany i nie ma też chyba żadnej twórczości powstałej na bazie tejże.

Gdybyś miał potrzebę jeszcze (bo może sam sobie opracowałeś, albo nie jest to potrzebne) otrzymać zdeasemblowany i poetykietowany (wg nazewnictwa z procedury Jaskiera) kod playerów do cmc, sdcmc i cm2 (wersje z programów i ewentualnie różne modyfikacje), to mogę podesłać na maila.

Idź do forum: Fabryka - 8bit

5 Odpowiedź przez marok

(3 odpowiedzi, napisanych Fabryka - 8bit)

Przesunięcie jedynki w ramach definicji znaków jest pomysłem wartym rozważenia, ale nie jest to rozwiązanie takie zupełnie proste do zaimplementowania.
Wtedy trzeba też roztrzygnąć, czy mamy mieć dwie definicje jedynki (tą używaną zwyczajnie i tą specjalną do "setki"), czy jedną, co byłoby prostrze do wprowadzenia, ale wizualnie może to już nie być takie "fajne".

Teoretycznie wydaje się jednak, że jedynka w takiej formie (przesuniętej w prawo) by chyba się zmieściła na standardowym ekranie CMC, przy czym widzę, że kursor wskazujący aktualną pozycję w songu trzeba by cofnąć o pozycję (na co jest miejsce, ale może to się lekko odbić na ogólnej estetyce ekranu, ale w sumie trudno mi to teraz z tej perspektywy dobrze ocenić).

Co do wprowadzania liczby (z nieoreślonej długości cyfr, bo chcemy mieć możliwość zapisu liczby >99), to proponujesz rozwiązanie zupełnie rewolucyjne w stosunku do "zastanego". Wydaje się ono całkowicie prawidłowe i chyba wzorcowe nawet, ale kłóci się z pewnymi fundamentamentalnymi założeniami.

Moja ogólna filozofia w przypadku przeróbek programów takich jak CMC, jest taka, żeby możliwie w pełni utrzymywać rozwizania już funkcjonujące, do których nawykliśmy w przypadku danego programu. Ma to także uzasadnienie mocno praktyczne, bo nie trzeba tak bardzo zmieniać poszczególnych procedur, tak gruntownie ingerować w podstawowe założenia na jakich opiera się program, tym samym czasem "wywracać" kod "do góry nogami" lub pisać od nowa.

Dlatego także wprowadzanie liczb >99 nie chciałbym żeby spowodowało zmianę dotychczasowej formuły wprowadzania liczb z dotychczasowego zakresu, aby "feeling" pozostał ten sam (w końcu to cmc, ze swoimi jakimiś ograniczeniami, ale w założeniu, przynajmniej w pełni "kompatybilny" z pierwotną wersją, pomimo że oferujący więcej - to póki co fikcja, ale taki miałby być cel).

Na dobrą sprawę, to pracując pod tak przerobionym programem można nawet przez jakiś czas nie zauważać dodatkowych możliwości kompozera, w tym także sposobu wyświetlania liczb >99.
Odtwarzasz stary kawałek, wszystko możliwie w pełni wygląda i działa dokłądnie jak wcześniej.

Natomiast co jeśli użytkownik pierwszy raz zauważy taką dziwną sytuację, kiedy ma jakąś wartość i jedna z cyfr jest podświetlona? Czy się domyśli jej znaczenia sam bez podpowiadania?

Na to pytanie łatwo jest mi odpowiedzieć, że domyśli się prawidłowego znaczenia takiej formy reprezentacji "pełnej" liczby, bo kontekst kiedy ją zobaczy najprędzej będzie podpowiedzią do tego wystarczającą.
Te "dziwne" liczby zobaczy przewijąjąc kolejne poza granicę 99, albo patterny albo pozycje song. I stanie się to jasne i oczywiste.

Natomiast naniesienie takiej liczby z klawiatury wg sposoby który zaproponowałem idzie też (chociaż wciąż nie jest dla mnie) w kierunku intuicyjnym.
Użytkownik bez podpowiedzi powinien przy pewnym wysiłku woli i namyśle, samodzielnie dość do tego jak to się to robi.
Tak powinno być i chciałbym żeby w tym wypadku też było.

A na koniec, to ogólnie dziękuję Mono za dobre chęci w stosunku do moich poczynań (dość nieporadnych) na forum (wiem po czasie, że często wręcz "bredze" myląć, czy przeinaczając oczywiste tutaj sprawy, tym bardziej dzięki). Traktuję to jako wsparcie i tak oficjalną drogą deklaruję ze swojej strony, że jak będziesz miał "zawał" pracy koderskiej (a "widzę" że bierzesz na siebie tego dużo) i uznasz w danym momencie, że warto byłoby się nią z kimś podzielić, to o ile uznasz, że mam jakąś szansę dane zadanie wykonać, to możesz śmiało do mnie z tym "udzerzać" przez emaila. Postaram się wtedy pomóc, mając też w pamięci Twoją pomoc i dobrą wolę. Pozdrawiam.

Idź do forum: Fabryka - 8bit

6 Temat przez marok

(3 odpowiedzi, napisanych Fabryka - 8bit)

Testując potencjalne możliwości przeróbek CMC i przy okazji testując i wystawiając cierpliwość czytających te moje "niskopoziomowe" wywody na niemała, jak obawiam się, próbę, chciałbym otworzyć nowy wątek.

Gdyby dodać do CMC (a perspektywicznie myśląc, raczej do SDCMC) obsługę większej liczby patternów ponad limit 100, to z uwagi na system dziesiętny komunikacji tego kompozera z użytkownikiem (który nie warto zmieniać w mojej ocenie), powstaje problem, jak reprezentować wartości przekraczające ten limit, pamiętając o ograniczeniach fizycznych ekranu (najlepiej nie wychodzić więc z tą liczbą ponad przydzielone, jak dotąd, dwie kolumny).
Nie jest też zupełnie jasne jaką powinien przyjąć formę sposób wprowadzania takich (>99) wartości z klawiatury.
W tym względzie należy zwrócić uwagę, że w CMC kompozer reaguje pozytywnie (sprawdza czy w granicy dopuszczalnych wartości i akcepuje) na parę cyfr wprowadzonych z klawiatury łacznie, a nie na pojedyńczą cyfrę z większej liczby, wprowadzane kolejno.

Stąd uważam, że problem wydaje się nie taki oczywisty do rozwiązania. Dlatego chciałem pewne rozwiązanie zaproponować i poddać ocenie, albo przeczytać jakiś pomysł na inne, lepsze, rozwiązanie tego problemu (czyli wprowadzenia liczby >99 w CMC i jej reprezentacji wizualnej, najlepiej w dwóch kolumnach i najlepiej żeby to było wciąż w systemie dziesiętnym :) ).

Mi przyszło na myśl następujące rozwiązanie:
Wizualnie liczbę >99 w systemie dziesiętnym na dwóch kolumnach można przedstawić w CMC następująco: wyciągamy modulo 100 z tej liczby (inaczej pisząc, to jest część dziesiętna i jednostek tej liczby i to idzie do wyświetlenia). Informacja o tym, że wartość przekracza >99 jest natomiast umieszczona na kolorze jednej z cyfr tej wyświetlanej części liczby, a oczywiście reprezentującej ją całą.

Czyli, przykład dla jasności: jeśli zadaniem jest wyświetlić liczbę 123, to wyświetlamy 23 i podświetlamy (to jest ta informacja na kolorze, o której napisałem wyżej) cyfrę 3 z "23".
Gdybyśmy potrzebowali wyświetlić wartość 223, to podświetlenie wypadło by na cyfrę 2 z "23".


Propozycja jak można rozwiązać wprowadzenie z klawiatury wartości >99:
1.) cntr+1 (lub +2) , 2.)  spacja, 3.) dziesiętna część, 4.) część jednostek całej liczby.

Wyjaśnię skąd w propozycji jaką przedkładam dwa pierwsze kroki:
kombinacje typu shift+1 odpadają, bo mają już swoje inne przeznaczenie (w SDCMC jest to wyłączanie | włączanie kanałów).
Niestety cntr+1 nie pozostawia śladu w systetemowym $2FC (764), stąd wspomaganie spacją w drugim kroku.

Przygotowałem przeróbkę CMC wg tych założeń (poza tym że krok drugi ( spacja ) jest potraktowany bardziej "liberalnie" - może to być w tej uproszczonej wersji, każdy inny klawisz poza cyfrą, a limit liczby jaką można wprowadzić to 127) żeby ewentualnie sprawdzić jak praktycznie się to ma szansę sprawdzać. Ale generalnie do niczego się ta przeróbka innego nie nadaje niż tylko do tych specyficznych zastosowań (testów tych rozwiązań), bo wpisywanie czegoś do patternów >99 powoduje zwis przy wyjściu z takiego patternu (nie ma potrzeby na tą chwilę tego prostować).

No coż, może nie jest to specjalnie ciekawe zagadnienie do rozważań, ale jeśli kogoś zainteresuje ten problem i zechciałby podzielić się spostrzeżeniami, pomysłami może, to będę za to wdzięczny.

Jeśli będę miał jakieś jeszcze inne praktyczne problemy do roztrzygnięcia także w przyszłości (różnie może być), to być może w tym wątku będę jeszcze dopytywał o zdanie i opinie.

Idź do forum: Fabryka - 8bit

7 Odpowiedź przez marok

(16 odpowiedzi, napisanych Fabryka - 8bit)

Wynikła pewna niezręczność dla mnie. Jedynym autorem kompozera jest J. Pelc i apelowałbym o poprawienie tekstu tam gdzie chodzić może szczególnie o rzetelność przekazu.
Mogę sobie pogratulować tylko tego, w kontekście powstałego utworu, pierwszego na real atari, z tego co rozumiem, (w końcu masz już w dorobku świetnego "Bazaltowego Rzezimieszka") z okazji którego składam szczere gratulacje, że temat CMC przywołałem na forum w odpowiednim czasie dla Twojego zainteresowania tematem. Najwyraźniej zamiary i chęci powstrzymywały dotąd sprawy głównie techniczne, czyli możliwość współpracy programu z SDX musiała być pozytywnie rozwiązana. Większą zasługę ma tutaj lamiel, bo przywołał kwestię istniejącego rozwiązania do SDX, więc i wersja o której wspominał (2.0x, a i jeszcze ta przygotowana przez Sonara) byłaby wystarczająca do tego.

Pozdrawiam i cieszę się z kolejnego nowego utworu na atari.

ps. Przepraszam za dyletanctwo, ale da się ten utwór odtworzyć jakoś w całości tylko na jednej atarce (z dwoma pokeyami) ?
Utworku jeszcze, z pewnych szczególnych przyczyn, jeszcze zresztą nawet nie słyszałem.

Idź do forum: Fabryka - 8bit

8 Odpowiedź przez marok

(13 odpowiedzi, napisanych Fabryka - 8bit)

@mono: Super dzięki za ten CMC2K.
Prezentuje się wizualnie i funkcjonalnie bardzo ładnie. Chyba ewolucja edytora poszła w kierunku zbliżenia jego możliwości do mpt (tym samym tmc), co było pociągnięciem bardzo słusznym.
Widać, że jest dużo opcji (transpozycja nut w patternie, regulacja głośności poszczególnych kanałów z poziomu patternów), roszerzona definicja instrumentów.

Tylko mam takie wrażenie, że rozwiązane jest to wszystko w szczegółach nie do końca tak, jak myślę że byłoby najlepiej (taka pierwsza ocena "na szybko"). O tym może warto jeszcze kiedyś podyskutować, póki co tylko sygnalizuję, że nie wiem, czy warto byłoby podążać dokładnie wg. tych samym rozwiązań, gdyby oczywiście rozwinął się projekt poszerzania możliwości edytora CMC (SDCMC).

Odnośnie jeszcze rozeznawania jak działa P: w poprzedniej wersji edytora, to poprawiłem wcześniejszy opis, w który wkradł się błąd (liczba sekund pauzy nie jest na pierwszej ale na drugiej pozycji).

Idź do forum: Fabryka - 8bit

9 Odpowiedź przez marok

(13 odpowiedzi, napisanych Fabryka - 8bit)

@mono: Dziękuję za Twój bardzo cenny, "prostujący" post. Niestety mnie (jak zwykle) przydarzyły się w tekście otwierającym wątek niedokładności i grubsze gafy, a dzięki informacjom z Twojego postu, jakoś całość "opowieści" trzyma się jeszcze kupy i coś można będzie z tego wątku sensownego wynieść.

Tej wersji z 2000 cmc (sdcmc?) nie znam i jeśli masz gdzieś link albo możesz dołączyć plik do wątku, to chętnie bym się zapoznał i podziękował za taką przysługę.

Odnośnie pauzy (P: xx yy), to rzecz ma się chyba następująco: yy to wartośc wyrażona w sekundach, ale xx jest wyrażone w ramkach. Pauza sumarycznie wynosi więc yy*$32+xx (ramek).


@qbahusak: Nie mam rozpisanego kodu do cmc (i sdcmc również). Osobiście uważam, że liczne przeróbki cmc w sumie niewiele wnoszą i nie ma specjalnie czego "importować".
(Z rzeczy godnych uwagi, na moje skromne zapewne rozeznanie, można wymienić zmienioną tablicę basów w wersji Rzóga i zestaw fajnych instrumentów w wersji Bartmana (v. 3.0), podstawionych zamiast "fabrycznych").

EDIT: poprawiony opis pauzy.

Idź do forum: Fabryka - 8bit

10 Odpowiedź przez marok

(13 odpowiedzi, napisanych Fabryka - 8bit)

@jamesd: Yes, it is possible.
But the question is how would You like mark it?

I can see solution in two ways:
- Like in "Lotus" module: on all tracks at the same row of all playing patterns occurs (start): the same note (no matther which; or in second variant (safer), C-1 must-be) of the same instrument.

- Special code (\mark) placed in (one is enough) pattern.


Benefit of the first way:
Simplicity of adaptation to "enviromental" conditions. ;)

Benefit of the second way:
Pattens (5 of 6 if all differ from each other) can be played either in full distance (allows better music data compaction, theoretically).

Idź do forum: Fabryka - 8bit

11 Temat przez marok

(13 odpowiedzi, napisanych Fabryka - 8bit)

Hej,

Wersja file (bardzo nieznacznie zmodyfikowana w stosunku do znanej wersji, ale słabo rozpoznanego i nieużywanego u nas) edytora muzycznego, będącego rozwinięciem CMC z roku '99 by Datri.

Z tego co zaobserwowałem jest szansa, że działa ze Spartą (z pewnymi kłopotami).

Obsługa jest następująca:
Shift + Esc : wejście do menu zarządzania plikami z dysku
Help (na emulatorze 'End'): przełączanie mode: normal | double (ma wpływ na brzmienie instumentów)
Shift + 1-6 : kanał (1-6) zamilknie lub odzyska "głos" - przełącznik

Reszta (przynajmniej z grubsza) jak w standardowym CMC.

Załączam jeszcze (do kompletu i żeby było co posłuchać) dwa music-dyski Poisona, które szczęśliwie wpadły mi w ręce. Wszystkie muzyczki najlepiej słuchać w wersji double (tak zostały przygotowane).
Być może istnieją nowsze wersje tych muzyczek. Są już dostępne w ASMA (ostatnie wydanie).

EDIT:
nowsza wersja.

Idź do forum: Fabryka - 8bit

12 Odpowiedź przez marok

(16 odpowiedzi, napisanych Fabryka - 8bit)

Łatka z TA (umożliwiająca korzystanie z SDX i poprawiająca wygląd literki "b") została w całości i bez zmian dołączona do poprawionej wersji CMC22, którą można pobrać z pierwszego postu zamiast tej pierwotnej.
Dodatkowo nieznacznie zmieniona została procedura relokacyjna. Na stronie zerowej nałożyły mi się adresy zmiennych, co nie objawiało się błędem w tym przypadku (playera cmc tu zastosowanego), ale potencjalnie mogłoby generować błąd przy jakiejś innej procedurze do relokacji.

Idź do forum: Fabryka - 8bit

13 Odpowiedź przez marok

(16 odpowiedzi, napisanych Fabryka - 8bit)

@mono: Dziękuję.
Nie zauważyłem nic "niepokojącego" w działaniu slidów, ale z analizy kodu wyszło mi, że wprowadzenie tego wyciszenia dźwięku przy przekraczaniu granicy bajtu, było pewnym kompromisem na jaki poszedł Janusz Pelc, bo licząc wartości czest2 (używane przy dźwiękach wibrujących), które są z założenia o 1 mniejsze od wartości bazowej (czest1) dla wartości 0 obliczane jest $FF i żeby zablokować taki przypadek, wprowadził "odgórną" zasadę specjalnego traktowania wartości $FF dla obliczonej wartości w czest2 (co może się zdarzyć też dla dźwięków ze slidami). Stąd sądzę, że to w jakimś sensie było sztuczne i odbiło się "rykoszetem" na tego typu dźwiękach.
Ale to są być może tylko moje mylne sądy i wyobrażenia. W sumie w pełni zdałem sobie sprawę, że coś przy optymalizacji kodu playera przy okazji udało mi się (tak to oceniam) poprawić, dopiero post factum. Impulsem była chęć zwykła chęć optymalizacji i skrócenia (czasem się tym zajmuję).

@lemiel: Dziękuję za podpowiedź.
Zainteresuje się tematem. Jeśli zgromadzi się więcej powodów (chociaż może już ten jeden wystarczy) żeby dopracować wersję, którą zamieściłem, a zadanie okaże się dla mnie do wykonania, to poprawię program.

Idź do forum: Fabryka - 8bit

14 Temat przez marok

(16 odpowiedzi, napisanych Fabryka - 8bit)

Przerobiłem player do cmc (na zauważalnie krótszy) wzorując się na wersji playera od Jaskiera, a więc z istotnymi poprawkami dla prawidłowego odtwarzania wszystkich poprawnie złożonych muzyczek (bez nieoczekiwanych niespodzianek).
Postanowiłem zaimplementować ten player do programu kompozera, aby dało się bez konieczności asembacji kodu źródłowego (którego np. może w danym momencie brakować pod ręką) generować player (?.REP) do muzyczki dowolnie ulokowanej w pamięci.

Konieczne było dodatkowo dorobienie bardziej uniwersalnej procedury relokującej adresy wewnątrz playera i podstawienie jej pod starą.

Ostatnią poprawką jaką dokonałem było zaznaczenie w tekście info na dole paska numeru wersji CMC na 2.2 (od numeru wersji playera; wcześniejsze to: player 2.0 Janusza Pelca, 2.1 wersja poprawiona Jaskiera, która nie została, z tego co wiem, zaimplementowana do żadnej z "nieoficjanych" wersji kompozera).

Nic więcej poza tym nie zostało zmienione (poza zmianami adresów odwołań z innych obszarów do tej części którą podmieniłem, czego oczywiśćie dopilnował sam asembler na przerobionym kodzie "źródłowym" pozyskanym dzięki narzędziu DIS6502 - przy okazji podziękowania dla TeBe), nic obcięte.


Odnośnie tej wersji playera w stosunku do wersji 2.1 (Jaskiera), którego jest (tak bym chciał to postrzegać), mam nadzieję, godną następczynią, zachowane zostały następujące zmiany wprowadzone w tamtej wersji:

- usunięcie dwóch zasadniczych błędów playera (w uproszczonym opisie i niepełnym znaczeniu) "odczytu strony $FF"
- $d20f zamiast $d21f
- pełne odtwarzanie zawartości strony zerowej sprzed wywołania procedury (część init oryginalnej procedury jedno z dwóch używanych słów na niej nie odtwarzała)
- wprowadzenie kontroli poprawności przy wywoływaniu z init (rA:=$20+kanał, rY:=instrument, rX:=numer_dźwięku) odgrywania pojedyńczego dźwięku "poza muzyczką"
- identyczne uszeregowanie zmiennych (player + offset : dostęp do tej samej zmiennnej, np. czest)
- procedura podpisana swoją nazwą - etykieta (ten sam offset co w wersji 2.1)


Zmiany i nowe funkcje, których nie zdecydowałem się kontynuować, powracając do właściwości playera 2.0:

- wycofanie się z możliwości podmiany adresu rejestrów pokeya z poziomu wywołania (na np. drugi pokey) : rA:=$3x (x>0), rX\rY:= mł.\st.połówka adresu pokeya (lub dowolnego innego obszaru pamięci), przy zachowaniu tradycyjnego znaczennia jeśli rA:=$30 (x=0), rX:= tempo
- wycofanie się z przestawienia kodu dla basica sprzed tablic (pozostają na końcu jak w wersji 2.0)


Innowacje w stosunku do wersji poprzednich:

- instrumenty slide up/down mogą teraz przekraczać granicę pojemności bajta ($FF<->0) przy zmianach częstotliwości (nie są "sztucznie" wyciszane w takim przypadku)


Przygotowałem Atr na którym znajdują się (poza dosem) przerobiona wersja CMC (CMC22.COM), oryginalna wersja CMC (CMC20.COM) i prawie oryginalna muzyczka Lasermania (LASER.CMC). Dwie ostatnie pozycje są po to, aby zademonstrować złe działanie muzyczki przez zasadnicze błędy procedury odgrywającej, które spostrzegł i poprawił Jaskier.
Muzyczka z Lasermanii ma więc jedną drobną "poprawkę". Na nieużywanym (w dodatku pustym) istrumencie o numerze 21 ma wstawioną wartość $46 w drugą (od góry) daną (to także druga wartość opisująca ten instrument w module) - pozostałe wartości i obwiednie pozostają wyczyszczone jak dla instrumentu pustego.
Tak przerobiona muzyczka będzie źle odtwarzana pod każdą znaną mi wersją kompozera (bo wszystkie działają na oryginalnym playerze Pelca) poza tą, którą właśnie opisuję (za co odpowiadają poprawki Jaskiera), co proponuję przy tej okazji sprawdzić, żeby się przekonać iż błędy nie są li tylko mityczne.
Proponuję także po załadowaniu muzyczki z Lasermanii przewinąć instrumenty do tego o numerze 15 i wywołać dźwięk D-6 (kliwisz O przy ustawionych na klawiaturze oktawach 4|5) i sprzwdzić tą nową specyfikację "poprawionego" działania instumentów z slide up/down. przy oryginalnym playerze dźwięk jest szybko przycinany, przy playerze 2.2 dźwięk wybrzmiewa na pełnej długości.

Możliwe że o czymś zapomniałem napisać (nie mam zwyczaju sporządzać notatek, a pamięć mam wyjątkowo nietrwałą). Nie wiem czy player nie zawiera swoich (ukrytych dla mnie) błędów. Gdyby zaszła potrzeba i ktoś coś zauważył (zakładam na chwilę, że ktoś zechce tegoż poużywać, chociaż wiadomym jest że czas CMC należy już do przeszłości), to oczywiście będę w przyszłości zainteresowany poprawkami takich ewentualnych błędów.

Załączam Atr w zipie.

EDIT:
Podmieniłem załącznik z poprawioną wersją kompozera.

Idź do forum: Fabryka - 8bit

15 Odpowiedź przez marok

(3 odpowiedzi, napisanych Bałagan)

@mono: Dzięki. Goat Tracker okazał się inspirujący i rzeczywiście rozjaśnił mi sprawę. Masz całkowitą rację rozpoznając moją propozycję ("pierwszy wariant") z posta jako Funktempo.
Pomysł z opóźnieniem odgrywania nuty przy niezmienianiu wartości tempa dla uzyskania tego samego efektu, odnotowuję, zastanowił mnie chwilę, ale nie przekonuje mnie (słusznie lub nie).

@seban: Witam. Dziękuję za "background story". Warto takie historie czytać, rzucają one światło na motywacje i powody używania różnych (względnie) niestandardowych technik.

Idź do forum: Bałagan

16 Temat przez marok

(3 odpowiedzi, napisanych Bałagan)

Interesuję się w tym momencie metodologią zmian tempa w trackach na różne komputery, bo sam osobiście trochę mało widziałem, a chciałbym odnaleźć "najsłuszniejszą" formułę dokonywania takich zmian z punktu widzenia zastosowań na atari, czyli zakładam, ważnym elementem pozostaje skondensowanie przekazywanej w zapisie tracka informacji.

Najbardziej oczywistą metodą jest ta, że na konkretnej pozycji w patternie zapisuje się wartość bezwzględną tempa.

Chociaż zaspakaja ona w całości zapotrzebowanie na takie zmiany, dając pełną swobodę, to jednak jest to metoda najbardziej pamięciożerna, bo w swojej podstawowej odmianie kosztuje bajt dodatkowego argumentu, którym wyraża się nowe tempo, bezpośrednio umieszczanym w zapisie za samą komendą zmiany tempa.

Rozwiązaniem pokrewnym, ale i kompromisowym, jest to zastosowane w formacie mpt (btw. atariki jest bardzo użytecznym źródłem informacji), bo tam zmiana tempa też bezpośrednio nadawana w wartości bezwzględnej, mieści się w samej komendzie zmiany tempa (na bitach, a nie w całym bajcie).

Niemniej oznacza to zawężenie wachlarzu możliwości zmian tempa do określonego zakresu, chociaż muszę się zgodzić, że wydaje się on w pełni wystarczający. Kosztem jest poświęcenie sporej ilości komend, na co można sobie zwykle pozwolić, o ile nie bardzo jest jak je inaczej wykorzystać.

Można by więc uznać rozwiązanie z mpt za modelowe, ale chciałbym rozważyć i przedyskutować nieco inne jeszcze możliwości.

Wcześniej jednak odwołam się do innej metody stosowanej w playerach na atari, którą akurat odnotowałem, żeby trochę poszerzyć ogląd potencjalnych możliwości "w tym zakresie".

Jest tam tak, że mamy jakąś wartość bazową tempa, która determinuje tempa kolejne, będące wielokrotnością tego tempa bazowego, a kody sterujące zmianami tempa wskazują indeksy w tablicy temp tak wzajemnie uwarunkowanych. To tempo bazowe można zmienić chyba jakąś osobną komendą i uaktualnić tablicę temp o powiązane tym schematem wartości.

Plusem takiego rozwiązania w odniesieniu do tego z mtp jest to, że mamy możliwość nadania tempa znacznie wolniejszego od tego najszybszego (bazowego), na które jest zapotrzebowanie w zapisie melodycznym, przez co zapis może być bardziej w pewnych sytuacjach (kiedy w sensie muzycznym niewiele się dzieje) zwarty (nie potrzebujemy robić "pustych pozycji w patternie" - komenda $FE w mpt - , być może nawet taka komenda w ogóle nie jest przewidziana w formacie takiego rozwiązania).

Wydaje się, że to opisywane powyżej rozwiązanie jest stosowniejsze, kiedy długość patternów nie jest z góry ustalona, co nie jest przypadkiem szczególnie mnie interesującym, ponieważ rozważam zastosowania typowo trackerskie (z jasnym podziałem na z góry ustalone wielkością patterny, którym skądinąd można potencjalnie wymusić szybszy koniec poprzez odpowiednie zapisy/ kod w samym patternie).

W ten sposób dochodzę do sedna swojego wywodu. Zaczną się też za moment pytania do praktyków, którzy sami widzieli więcej i mają lepszy ogląd co w zmianach tempa jest użyteczne.

Załóżmy że możemy wykorzystać te same kody komend jakie spożytkowane są w mpt na ten sam cel ($Cx), czyli zmianę tempa. Mamy więc 16 kombinacji, dodatkowo dysponujemy "za darmo" niezależnym źródłem wprowadzenia dowolnej wartości do tempa na początek odgrywania patternu (z dalszą możliwością jego modyfikacji przed odegraniem pierwszego dźwięku już w zapisie patternu), oraz możliwością wykorzystania co najmniej jeszcze jednego dodatkowego argumentu w ramach tego "za darmo" (do jakiegoś zmyślnego wykorzystania).
Z tego powodu odnosząc się do tempa niejako"referencyjnego" będącego spoza zapisu w samym patternie, możemy potencjalnie posłużyć się względnymi wartościami (lub innym "szyfrem") w interpretacji kodów komend zmian tempa w samym patternie. To jest możliwość jaka się otwiera i którą warto uważam rozważyć.

Dlaczego.
Bo ze zmianami tempa w trackerach wiąże się co najmniej jeden typowy trick, który udało mi się podpatrzeć (choć nie znam potencjalnych wariantów jego uzasadnionego stosowania), a który polega na tym, że na każdej kolejnej pozycji w patternie znajduje się zmiana tempa, ale jest to zrobione z dwóch wartości naprzemiennie po sobie występujących i są to wartości tempa, które najprawdopodobniej zawsze dzieli 50% różnicy w generowanym sobą czasie pauzy między odczytami kolejnych pozycji patternów.

A więc chodzi o taki zapis:

pozpat Z   tempo X
pozpat Z+1 tempo X+Y
pozpat Z+2 tempo X
pozpat Z+3 tempo X+Y
itd.

Byłoby dobrze znaleźć formułę skondensowanego zapisu wymuszającego takie zmiany tempa, co na pewno nie uda się zrobić posługując się interpretacją zapisów w komendach zmiany tempa wyłącznie tylko jako wartości bezwzględnej.

Wydaje się, że takie ustalenie tempa raz, obowiązuje później "dłuższą chwilę". Możemy bezpiecznie założyć że do końca patternu, a przede wszystkim od jego początku (a często na przestrzeni całego songu) i nie zajdzie potrzeba zmiany takiego ustawienia tempa, a nawet gdyby, to nie będzie problemu z jego przełączeniem na jakąś stałą wartość (gorzej w drugą stronę, czyli że wewnątrz patternu przełaczamy się na taki tryb naprzemiennych zmian tempa w cyklu).
Wydaje mi się więc że warto posłużyć się tym wspominanym wcześniej "zewnętrznym" w stosunku do zapisów patternu kodowaniem takiego tempa.

Tym samym być może (pisząc cały czas się samo koryguję w poglądach) nie jest to dostateczny powód aby traktować wartości kodów zmian temp w patternie inaczej niż wartości bezwzględne.

Muszę jednak zebrać więcej danych na temat stosowanych technik zmian tempa (co się rzeczywiście przydaje) wewnątrz patternów.

(Uwaga, zaczynają się pytania)

Wracając jeszcze do tego ostatniego "patentu", to czy możemy założyć że zawsze zmiany tempa polegają na następującej zależności:
tempo X
tempo 1,5*X
itd.?

Czy stosowane są jeszcze jakiś inne warianty? Jakie?

Czy zawsze pierwsze w tym "tricku" (na pierwszej i każdej nieparzystej pozycji patternu) jest tempo 1,5*X, czy może zdarza się (/jest) dokładnie odwrotnie (tempo X pierwsze)?

Czy znane są jakieś inne "patenty" zmian tempa? (chodzi głównie o przypadki cykliczności takich zmian)


Jak często przydają się tempa "wyższe" (tzn. dłuższe pauzy w przesuwaniu pozycji patternów) ?


czy są jakieś "dzikie" pomysły, które warto byłoby rozważyć, a związane ze zmianami tempa?


Z góry dziękuję za każdą merytoryczną odpowiedź.

Idź do forum: Bałagan

17 Odpowiedź przez marok

(105 odpowiedzi, napisanych Fabryka - 8bit)

Ja bym był na przykład chętny do jakiejś kooperacji z innymi koderami w tym zadaniu, gdyby znaleźli się inni.

Podział obowiązków, jakiś szef projektu, który by koncepcyjnie całość ogarniał i rozdzielał zadania, oraz testował na sprzęcie. Może tak dało by się taki, jednak złożony, projekt skutecznie zrealizować.
Nie wszyscy rozwijający soft musieliby mieć odpowiednie rozszerzenie w takiej sytuacji, tym bardziej że nie wszyscy pewnie potencjalni koderzy mają w dyspozycji działające Atari, bo zadawalają się zwyczajnie emulacją (mój przypadek).

Z mojej perspektywy, player do A2M to ambitne, ale może do zrealizowania, zadanie. Głównie z tego powodu, że jest kod źródłowy. Jest jego sporo i zmieszczenie tego w pamięci Atari razem z danymi modułu, byłoby poważnym wyzwaniem, ale mam wrażenie (a bardziej zgaduję) że da się to zrobić.

Natomiast co do tego w czym mógłbym pomóc teraz już konkretnie ze spraw szczegółowych, to wydaje mi się, że to moduł obliczający/ sprawdzający sumę kontrolną (crc-32) - chociaż to zadanie które można uznać za "nadobowiązkowe" -, depacker apacka, stosowany w późniejszych wersjach formatu a2m (9-11). Kod depackera jest akurat przy podobno względnie dobrej wydajności, mniej złożony, więc to nie jest duże zadanie, aczkolwiek warto możliwie starannie się nim zająć, bo tutaj optymalizacja "czasowa" byłaby bardzo na miejscu.

Pomysł na rozwiązanie problemu jaki sygnalizowałem w poprzednim wpisie do tego wątku (czyli tego że obszar zajmowany przez dane muzyczki nie da się wygospodarować w pamięci Atari), można obejść na zasadzie, że odwołania do "symulowanego" obszaru danych (czyli tak jak one są rozmieszczone w kodzie playera na PC, przy obliczaniu dostępu do szczegółowych danych, np. konkretnego instrumentu) byłyby przetwarzane przy pomocy specjalnej tablicy adresów na wskazania odpowiadające tym jakie wynikły przy depakowaniu na Atari (proponowałbym całość danych muzyczek mieścić w obszarze dodatkowych banków pamięci), przy czym wartości powtarzane wielokrotnie (najczęściej 0), które "normalnie" (tzn. na PC) są depakowane w sposób liniowy, jak pozostałe dane, byłyby "sprytnie" "zapamiętywane" w ramach tej tablicy przeliczeń adresów, o której pisałem wcześniej.

To wszystko co "wymyśliłem". Liczę na jakieś luźne, niezobowiązujące komentarze koderów, którzy z ciekawości "rzucili okiem" na kod playera do A2M i pewnie mogą mieć jakieś własne spostrzeżenia.

Idź do forum: Fabryka - 8bit

18 Odpowiedź przez marok

(105 odpowiedzi, napisanych Fabryka - 8bit)

Trochę się wtrącę. (To z racji że tematem się zainteresowałem, poświęcając mu nieco czasu, ale wiadomo, nie mam "tych" umiejętności, żeby takiemu projektowi "dać radę" w pojedynkę, zakładając w ogóle, że jest do zrobienia.)

Mam taką zasadniczą uwagę:

Muzyczki wydają się niewielkie, ale z dokumentacji na temat formatu A2M wynika, że obszar pamięci na którym rozlokowywane są dane po wstępnym rozpakowaniu pliku z tej postaci, jest wielkości grubo ponad możliwości Atari (także rozbudowane o dodatkową pamięć).
Z dokumentu (http://adlibtracker.net/files/techinfo.htm) wychodzi, że to 1137182 bajty (~ 1.0845 MB) dla ostatniej (11) wersji A2M.


Wolałbym jednak żeby ktoś to zweryfikował, bo, rzeczywiście, dysproporcja między wielkościami pliku w tym formacie, a obszaru pamięci, jaki jest przewidziany do jego przyjęcia, jest drastyczna.

Idź do forum: Fabryka - 8bit

19 Odpowiedź przez marok

(316 odpowiedzi, napisanych Zloty)

platforma: atari 130xe
jesli twoj program wymaga innej konfiguracji skontaktuj sie organizatorem czy moze zapewnic odpowiedni sprzet (mozesz zapewnic go sam) - wymagania beda wyswietlane przez caly czas trwania pokazu

Gdybym miał jakieś prawo głosu, to za takim uproszczonym regulaminem bym się podpisał.

Przy czym dodałbym jeszcze konieczność informowania o używaniu rozkazów nielegalnych, ale ich nie zabraniał zgodnie z zasadą, że można wszystko, ale o wszystkich "odchyleniach" od standardu informujemy rzetelnie.

Tak samo, jeśli prawidłowe działanie danej pracy oznaczałoby: wymóg posiadania drugiego pokey'a (wszystkie konkursy), angażowania procesora w podmianę rejestrów kolorów "w środku linii" (tylko konkurs graficzny) i wszelkie rozszerzenia sprzętowe (wszystkie konkursy) dopuszczalne jednak tylko o ile zostały wcześniej upublicznione (można się było zapoznać z ich możliwościami i się o nie postarać), to taka informacja musiałaby być eksponowana.
Jeśli prac byłoby bardzo dużo (ale najlepiej tylko wówczas), wtedy można dzielić poszczególne konkursy w zależności od tych różnic w wymaganiach sprzętowych.

Idź do forum: Zloty

20 Odpowiedź przez marok

(17 odpowiedzi, napisanych Software, Gry - 8bit)

Podejrzałem procedurę depakującą w progu z linka. Tą wersję packera znaleźć można, z tego co zapamiętałem, jeszcze w "Puzmanii" i "Puzmania Music Player", też Tight'ów.
Istnieje zbyt duże podobieństwo tych dwóch depackerów (struktury kodu), żeby to był przypadek.
Jager w czasach "Seriousa" używał już packera od SoTe.


EDIT (2):
A to jedyny fragment kodu, który jest różny dla każdej z 3 wersji depakera (powinno zainteresować Sebana):

SoTe:

        jsr get        ; get 8 bit of length
        sta len

end_ofl    jsr get        ; get LO byte of offset
        sta src

offset    ldx     #$ff        ; get HI bits of offset
        jsr     get_Xbit
        sta     src+1
        sec            ; calculate sequence location

Seban:

        jsr get        ; get 8 bit of length
        sta len

end_ofl    jsr get        ; get LO byte of offset
        sta src

offset    lda     #$ff        ; get HI bits of offset
        tax
        beq     *+5
        jsr     get_Xbit
        sta     src+1
        sec            ; calculate sequence location

Gumi:

        jsr get        ; get 8 bit of length
        sta len

end_ofl    stx src+1
        jsr get        ; get LO byte of offset
        sta src

offset    ldx     #$ff        ; get HI bits of offset
        beq     *+7
        jsr     get_Xbit
        sta     src+1
        sec            ; calculate sequence location

Idź do forum: Software, Gry - 8bit

21 Odpowiedź przez marok

(17 odpowiedzi, napisanych Software, Gry - 8bit)

@Seban: dokładnie tak, to musi być to - wielkie dzięki.

Tak na marginesie, bo jest wpis w haśle Atariki, że program został całkowicie zapomniany. Więc okazuje się, że nie do końca, bo np. dane dla Serious'a były pakowana za jego pomocą. Same artykuły nie (one djpacker'em), ale w zasadzie chyba wszystkie pozostałe dane już nim właśnie.

Jeszcze raz wielkie dzięki.

edit:
Po rozpakowaniu wstępnym djp'm wszystko później rozpakowywane jest już depackerem SoTe, czyli także artykuły. Przepraszam za pomyłkę.

Idź do forum: Software, Gry - 8bit

22 Odpowiedź przez marok

(17 odpowiedzi, napisanych Software, Gry - 8bit)

Mam już rozpoznanie czego szukam.

Packer i depacker wyszły (wszystko na to wskazuje) spod ręki SoTe i zostały zastosowane (na "szeroką skalę" :) ) w obu Barymagach. Tak z pobieżnego oglądu nie widać, żeby packer czy depacker (ale ten już można zdeasemblować) były gdzieś na dyskach z magiem, więc sprawa poszukiwań nie znalazła swojego finału.

Stąd naturalne w tej sytuacji pytanie, czy ktoś może jest w dyspozycji tego packera (sam program bądź źródła)?

Idź do forum: Software, Gry - 8bit

23 Odpowiedź przez marok

(17 odpowiedzi, napisanych Software, Gry - 8bit)

Podczepiam się pod temat, bo być może właśnie "Tight Packer" jest tym programem, który także chciałbym "pozyskać". (Sugeruję się tym, że na pewno korzystał z niego Jager.) A dlaczego chciałbym - o tym trochę dalej.

Natomiast pytanie pierwsze: czy istnieje jakiś program, o którym wiadomo, że został "potraktowany" tym właśnie pakerem? W zasadzie nie znam twórczości grupy "Tight", więc gdyby ktoś był w stanie podpowiedzieć, co między innymi stworzyli (a co się przy tym może depakuje) - to też bym podziękował.

Przechodząc do kwestii ustalania poszukiwanego przeze mnie pakera, to sytuacja wygląda następująco:
Mam spakowane dane i chciałbym wiedzieć (nie mogę inaczej tego obejść) jakim pakerem konkretnie zostały one przygotowane. Wygląda na to, że jest to paker typu "słownikowego", ale nie jest to żaden z listy pakerów z atariki (w tym "flashpacker", "superpacker", "djpacker"). Z opisu nie wynika, żeby to mógł być paker Glonisza (opis w Serious#10), ani nie jest to też ten od Jaskiera z Energy#1.

Kolejne więc pytanie, zarazem prośba o pomoc, czy znane są komuś jakieś jeszcze inne pakery, w domyśle typu "słownikowego", czyli bazujące na powtarzających się ciągach wartości?

Cechą mocno charakterystyczną dla poszukiwanego przeze mnie pakera jest to, że ciągi bajtów niespakowanych mogą występować jedynie w porcjach po 8 (lub którszych), a przed takim maksymalnie długim ciągiem bajtów niespakowanych, wewnątrz spakowanych danych tym pakerem, występuje bajt "opisujący" ten ciąg o wartości $00 (czyli wyraża bitowo właśnie, że 8 następujących po sobie bajtów nadaje się do przepisania z archiwum na miejsca docelowe w procesie dekompresji).

Idź do forum: Software, Gry - 8bit

24 Odpowiedź przez marok

(1,752 odpowiedzi, napisanych Fabryka - 8bit)

tak z ciekawości podpytam,

z opisu wynikałoby, jak dla mnie, że bez opcjonalnego (czyli dla wszystkich poza pierwszym blokiem) identyfikatora, adres ładowania ustawiony na $FFFF, zostałby zinterpretowany poprawnie (mimo że standardowo zostałby potraktowany jako identyfikator właśnie)

tak spekuluję, że ta funkcjonalność wymagała "trochę" dodatkowych linijek kodu potrzebnych do raczej chyba złożonej analizy: z czym mamy do czynienia, w przypadku potencjalnego identyfikatora (lub adresu ładowania od $ffff), a zastanawiam się też nad jej praktycznym znaczeniem.

Idź do forum: Fabryka - 8bit

25 Odpowiedź przez marok

(1,752 odpowiedzi, napisanych Fabryka - 8bit)

potrzebuje sprytnego pomyslu na wskazywanie xBiosowi pliku do uruchomienia, poniewaz zmiana nazwy pliku na "xautorun" nie jest wygodna.

Może to głupię co zaproponuję, ale przyszło mi na myśl rozwiązanie następujące:
przy boot naciśnięcie SELECT oznacza przejście do trybu wybierania pliku jako xautorun oraz równocześnie powstrzymuje autouruchomienie pliku dotychczas oznaczonego w ten sposób,
i teraz np. każde kolejne naciśnięcie tego klawisza konsoli (i zwolnienie) przesuwa wybór pliku zgodnie z kolejnością w katalogu, a START zatwierdza wybór (START bez wcześniejszego naciśnięcia SELECT po tym pierwszym inicjującym mógłby wskazywać że rezygnujemy w ogóle z oznaczenia jakiegokolwiek pliku jako xautorun).
Tryb wybierania pliku mógłby wyglądać dokładnie tak jak bez pliku xautorun, a naliczanie nie musiałoby być nawet uwidocznione moim zdaniem (takie działanie "na ślepo" można usprawiedliwić prostotą zadania i brakiem poważniejszych konsekwencji przy ewentualnej pomyłce).

Przy tej okazji napiszę że idea XBios mnie osobiście bardzo się podoba.

Idź do forum: Fabryka - 8bit