hej!

plik poszedł :D

pozdrawiam
Seban

Ok, tak zrobie. Po powrocie z kołchozu spakuje i zacznę upload na FTP azbesta.

UPDATE 3 ! :D

zrobiłem upload po raz drugi :) archiwum jest już u Azbesta na FTP.
Zainteresowani musza poczekac aż pliki znajdą się w odpowiednim katalogu :D

pozdrawiam
Seban

hej Konop!

Już poprawiłem :D to z pośpiechu :D

chcialem być lepszy od Magnusa ;) ( to żart oczywiście :) )

Seban

hej!

chyba popadamy w jakąś paranoję :D

ale jeszcze krócej o 3 bajty będzie tak:

src = $9D
dest = $24;

loop  jsr $A293
      beq stop
      lsr @
      tay
q0    jsr $A293
q1    sta (dest,x)
      jsr $E6D1

      dey
_bpl  bmi loop
      bcs q0
      bcc q1

stop  rts

heja!

może się źle wyraziłem... dokładnie chodziło mi o to iż tak czy tak musi być jakiś LDX # :D nawet w wersji maroka ;)

Seban

hej!

To może i ja swoje 3 grosze dorzucę  :) Pierwsze założenie optymalizacyjne, odwracamy znak w przypadku ilości spakowanych danych, czyli w przypadku ustawionego 7 bitu, wartość $ff będzie oznaczała 1 powtórzenie, $fe - dwa powtórzenia $80 - 127 powtórzeń. Przez taki myk możemy wprowadzić co następuje:

jsr get
bpl store
xor #$ff 
beq stop
...
tay

nie potrzebujemy już and #$7f ;) mamy już 48 bajtów

pierwszym moim pomysłem było zastosowanie nieco innych trybów adresowania i umieszczenie tego na stronie zerowej:

       org     $80

src     dta a(src_address)
dst     dta a(dst_address)

loop    ldx #($100-(_bpl-q0+2))&$ff
        jsr get
        ora #$00
        bpl store
        xor #$ff
        beq stop
        ldx #($100-(_bpl-q1+2))&$ff

store   tay
        stx _bpl+1

q0      jsr get
q1      ldx #dst
        sta ($00,x)
        jsr inc
        dey
_bpl    bpl *

        bvc loop

get     ldx #src
        lda ($00,x)
inc     inc ($00,x)
        bne *+2
        inc ($01,x)

stop    rts

wychodzi 49 bajtów, co okazało się porażką ponieważ kod wygenerowany wcześniej przez magnusa ma 45 bajtów gdy umieścimy go na "zero page". no cóż pozostaje wiec pozostawienie wersji magnusa wraz z modyfikacją "xor" i mamy 43 bajty na zero page lub 48 bajtów w "normalnej" pamięci.

        org     $80

loop    ldx #($100-(_bpl-q0+2))&$ff
        jsr get
        bpl store
        xor #$ff
        beq stop
        ldx #($100-(_bpl-q1+2))&$ff

store   tay
        stx _bpl+1

q0      jsr get
q1      sta $dead
        inc q1+1
        bne *+2
        inc q1+2

        dey
_bpl    bpl *

        bvc loop

get     inc adr+1
        bne *+2
        inc adr+2

adr   lda $cafe

stop    rts

pozdrowionka
Seban/SLIGHT

hej!

niestety, dokładnie tak.

*.pozdr!
Seban/SLIGHT

Ok!

Już wszystko jasne ;)

Trochę posiedziałem z oscyloskopem i wszystko wyszło.

No cóź cała tajemnica sygnału ~REF polega na tym iż on tylko steruje MMU, tak aby przygotowano RAM do odświeżenia przez ANTIC.  W momencie odświeżania ANTIC sam wystawia adresy na magistrale,  a DRAM w momencie odświeżenia nie wystawia nic na magistrale danych. Do tego ANTIC jeszcze wystawia HALT troszkę wcześniej procesorowi aby ten też "odpioł" się od szyny.

I tu cały bajer :) generując fałszywy ~REF, generujemy dla MMU i FREDDIEGo cykl odswieżania pamięci, magistrala danych pozostaje nieużywana (DRAM w cyklu odświeżania pozostawia magistrale danych w stanie wysokiej impedancji) procesor pozpstaje podpięty po nie ma HALT'a :) teraz freezer podpina swoją pamięć (EPROM,ROM) w obszar $fffa,$fffb. Stan cały utrzymuje się do momentu wystąpienia najbliższego NMI :D

Wtedy procek skacze pod adres który obecnie się znajduje $fffa,$fffb. A w podanym obszarze znajduje się już nasza pamięć EPROM podpięta przez logikę freezera :)

Jedny problem jaki występuje w takiej sytuacji to aby nie wygenerować fałszywego REF'a w momecie gdy antic odświeża sobie RAM. Ale to można wyczaić po magistali adresowej. z tego co widzę to na schematcie aby uaktuwnić freezera linia A3 musi być w stanie "1".

Można domyślać się iż ANTIC podczas odświeżania generuje na szynie adresowej tylko adresy typu: $0000,$0100,$0200,$0300....$ff00 (adresowane są tylko wiersze, ROW).

Szacun dla Pana Bernarda :) Musiał mieć zacięcie i dużo wolnego czasu aby to wymyślić i opracować w tamtych czasach :)

Ktoś zainteresowany przeniesiemiem freezera na jakąś nowszą programowalną logikę? bo układ PLS105 to swego rodzaju zabytek :)

Jak już wiemy, ma być Turbo Freezer 2005 od ABBUCA, pytanie tylko czy będzie dostępny czy będzie trzeba za niego płacić chorą kasę. Tak myślę sobie że można się pokusić o stworzenie własnego... tylko pytanie czy ktoś jest zainteresowany? (oprócz mnie :) bo mój Freezer by Stecu/The Distals [jak to wymyślił Miker :D ] już prawie nie działa :(

pozdrawiam
Seban/SLIGHT

Hej!

Masz gotowca... :D

Ale UWAGA!!! zero optymalizacji ;)

ehh... stare dobre czasy ;) kiedyś się pisało w BASIC'u ;)

pozdrawiam
Seban/SLIGHT

Dokładnie o takim samym myślałem ;)

A co do gammy to nie bardzo mają ochotę na sprzedawanie pojedyńczych sztuk. Mam ich pod domem, po drugiej stronie ulicy i znam się z nimi niejko poprzez poprzednią pracę. Gdzie utrzymywałem z nimi silne kontakty ze względu na dość znaczne zakupu PIC'ow ;) Na początku nie robią trudności jeżeli pojedyńcze sztuki kupuje firma i mają nadzieję na dalszą współpracę. Natomiast jak PICki kupują prywatne osoby to tak niechętnie do tego raczej podchodzą, aczkowliek sprzedadą pewnie.

A co do róźnicy w brzmieniach 6581 (stary) a 8580 (nowy)  to ja słyszę wyraźną różnicę w brzmieniu fitrów. 6581 wydaje się nieco miększy i bardziej dynamiczny. 8580 ma dla mnie bardziej metaliczne i ostrzejsze brzmienie. Co ciekawe niektóre msx'y pisane na 6581 bardzo źle brzmią na 8580 i vice versa. Ale w 80% nie ma to znaczenia. Dopiero mistrowie SID'owego układu potrafili wykorzystać możliwości filtrów i sztuczki poszczególnych układów.

Co do sampli, to do końca nie wiem jak jest. Niektóre produkcje źle grają sample na nowych sidach (bardzo cicho). Z drugiej jednak strony nowsze produkcje źle odtwarzają sample na starym SID'ie. Wiec coś w tym jest. Do końca nie wiem na czym polegał trick z otwarzaniem sampli na sidzie, bo sprzętowo chyba nie ma takiej możliwości. Trzeba by było kod playera jakiegoś przeanalizować ;) Ale wszystko w swoim czasie ;)

Kiedyś w C&A był schemat układu poprawiającego jakość sampli w nowym sidzie ;) Z tego co pamiętam przeróbka polegała na zatrzasku podpiętym pod konkretny adres sida i przetoworniku C/A złożonym z drabinki R-2R. Wiec zapis do kokretnego rej. SID'a powodował po prostu wpis do tego prostego 4-bitowego C/A. Wyjście C/A było jakoś dopiete do Audio Out. I to była cała przeróbka.

Wiem że SoTe popełnił dwie konwersje digi-sampli z ATARI na C64 (chyba Crazy Cars i Ethnicolor produkcji HTT). Wiem że miał nowe C64 i znał/znalazł metodę na odtwarzanie sampli na SID8580.

pozdros
Seban/SLIGHT

i tu właśnie jest ciekawostka ;) Myślałem że C64 jest sporo wolniejsze od atari :) wiec myślałem iż Player z C64 będzie się wykonywał nieco szybciej na ATARI niż na C64. Jakież było moje zdziwienie jak zobaczyłem iż player z C64 wykonuje się prawie tyle samo na ATARI co na C64 (no może minimalnie szybciej). Badanie przeprowadzałem przy standardowym ekranie z C64, playera odpalałem w momecie zaczęcie rysowania przez VIC'a pierwszej lini tekstowej. Podobnie na atari (standarowy ekran ATARI w trybie ANTIC $02).

Próbowałem poszukiwać wyjaśnienia całej sytuacji. Pytałem znających się trochę bardziej ode mnie na C64 jak to jest że ekran praktycznie nie spowalnia C64. I co się okazało... otóż podobno VIC z C64 to bardzo sprytny układ ;) Nie haltuje on CPU tak jak ANTIC. Pobieranie danych z pamięci i odświeżanie tejże wykonuje w przeciwfazie do CPU. CPU z C64 pobiera dane z pamięci na narastającym zboczu sygnału zegarowego a VIC na opadającym. Także nie ma możliwości aby CPU i VIC zarządały danych w tym samym momencie z RAMu. Tak wiec pobieranie danych z pamięci przez VIC'a nie spowalnia CPU.

Tak do końca nie wiem czy to prawda bo nie miał mi kto potwierdzić tych informacji. Jednak zakładam iż jeżeli player z C64 odpalony na ATARI wykonuje się podobną ilość czasu to oznacza to tylko jedno... VIC nie wstrzymuje 6510, albo nie spowalnia go w takim stopniu jak ANTIC spowalnia 6502.

Ale wracając do czasu wykonaia się player'a. Z założenia Playery z C64 powinny się wykonywać o wiele krócej. SID ma własny generator obwiedni wiec Player zupełnie się tym nie powinien zajmować. A jednak playery z C64 mają porównywalne czasy wykoania z playerami z ATARI. Są i player y które zajmują dwie linie ekranowe, jednak są i takie rozrośnięte kobyły co potrafią zabrać z 70 lini rastrowych ;).

Zaczołem się przyglądać playerom z C64 i dwie rzeczy rzuciły się od razu w oczy. Po pierwsze 12-bitowa precyzja SID'a wymusza trochę innego rodzaju kod. Po drugie część świetnych muzyków z C64 sama pisze/pisała playery i jeżeli ktoś jest dobrym muzykiem nie oznaczało iż był także rewelacyjnym koderem. Cześć playerów po prostu jest napisana tak aby spełniała swoje "zadanie brzmieniowe". One nia muszą być szybkie, ważne  żeby fajnie brzmiały. Cześć muzyków nie przywiązywała po prostu wagi co do jakości kodu playera. Inni nie potrafili sobie napisać szybkiego playera. 

Analizowałem kilka playerów i tak jak mówiłem są takie które wykonują się 2 linie i są prawdziwe kobyły ;) Jednak średni jest to około 32-48 lini rastrowych (przy wyłączonym ekranie na ATARI). Zresztą możecie zobaczyć to w SidPlay'u świetego. Tam jest pokazany czas wykoania Player'a z C64 ;).

Moim zdaniem średnio wchodzi nieco krócej niż MPT. Ale jest innna wada niektórych playerów. Średni czas wykoania jest bardzo krótki, ale w momecie gdy taki player musi pobrać dane dla kolejnych patternów zaczyna długo się wykonywać.

Zresztą specyfika muzyki SID'owej jest zupełnie inna niż POKEY'owej. SID'owcy mają zupełnie inne efekty. Często playery potrafią robić płynne przejścia z jednej nuty do drugiej. To wymusza też nieco inny styl pisania playera.

eehhhh... co ja zresztą bredzę... już chyba wystrarczająco dużo natrułem ;)

pozdrawiam
Seban/SLIGHT