Przejdź do treści forum
atari.area forum
Twoje polskie źródło informacji o Atari
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Aktywne tematy Tematy bez odpowiedzi
Aktualności ze świata Atari
FujiNetChat: Nowy klient IRC dla Atari Pierwsza publiczna wersja alfa FujiNetChat, nowoczesnego klienta IRC wykorzystującego interfejs FujiNet.
Gearlynx 1.2.2 Gearlynx doczekał się aktualizacji. Wprowadzono podgląd SCB, wyszukiwanie w pamięci oraz poprawki.
Wyniki FujiCup 2025 Poznaliśmy najlepsze gry na 8-bitowe Atari wydane w 2025 roku według jury oraz publiczności.
Wyniki konkursu i gala FujiCup 2025 Poznaj zwycięzców dorocznego turnieju FujiCup 2025 wspierającego twórców gier na Atari XL/XE.
Fujisan 1.1.8 Nowa wersja emulatora Fujisan przynosi wsparcie dla FastBasic oraz poprawki błędów w obsłudze dźwięku.
Opcje wyszukiwania (Strona 106 z 122)
Ja słucham cały czas prawie Cybernetic Celtic Wizarda. Bardzo fantasy ;)
Muszę.se wpisać w cefał: "POETA!"
To się kwalifikuje na wizytę u stomatologa.
Zdrowia, szczęścia, pomyślności dla małej.
A mogła być (K)Atarzyna...
@Alex: Świetna procedurka, ale:
- wymaga offscreen w formacie orica (czyli 8000 bajtów orica, no i 6400 bajtów na ekran antica),
- mimo tego można ją łatwo przerobić tak, żeby zapisywać konkretne 2 bajty ekranu antica przy aktualizacji 1 orica,
- nie byłoby problemu z czarną linią w środku obrazu.
Ciekawe, jak bardzo gra by zwolniła...?
Np. tak?
;ekran 32-bajtowy (wykorzystane bajty 1..30)
;X=x (0..39)
;Y=data
puttoscr:
lda hshltab,x
sta shldata+1
lda hshrtab,x
sta shrdata+1
shldata = *+1
lda sh0l,y
sta datal
shrdata = *+1
lda sh0r,y
sta datar
ldy postab,x
lda (line),y
and maskltab,x
datal = *+1
ora #0
sta (line),y
iny
lda (line),y
and maskrtab,x
datar = *+1
ora #0
sta (line),y
rts
postab: dta :40 1+#*6/8
hshltab: dta :10 >sh2l,>sh4l,>sh6l,>sh0l
hshrtab: dta :10 >sh2r,>sh4r,>sh6r,>sh0r
//tablice masek tresci ekranu odpowiednio dla lewego bajtu i prawego
maskltab: org *+40
maskrtab: org *+40
//tablice wartosci wpisywanych do pamieci ekranu przesunietych o n bitow
//i zamaskowanych (6-bit) odpowiednio dla lewego bajtu
sh0l: org *+$100
//sh2l ma te sama zawartosc, co sh0l (same zera) - mozna scalic w jedna
sh2l: org *+$100
sh4l: org *+$100
sh6l: org *+$100
//i dla prawego
sh0r: org *+$100
sh2r: org *+$100
sh4r: org *+$100
sh6r: org *+$100
Wychodzi sporo operacji na zapis jednego bajtu na ekranie no i całkiem spory narzut na tablice.
Podobnie by trzeba było zrobić z odczytem.
XXL to wie, dlatego Apple Invaders też wykorzystują 6 bitów na bajt :)
No bo to jest etiuda - ma na celu ćwiczenie techniki u wykonawcy.
Nawiasem mówiąc zaczął się właśnie XVI konkurs Chopinowski - etiudy są wykonywane zdaje się właśnie na 1 etapie.
Wyświetli, wyświetli, ale zawinie się na granicy 4K, a więc weźmie kolejne dane nie z $B000, lecz z $A000 aż do $A018.
XXLu - a gdyby zamiast JMP w dlist ustawić linię wcześniej DLI i wpisywać tam nowy adres do DLPTR? Nie miałbyś wtedy pustej linii...
"A propos - czy otrzymał już Pan anonimowy list z pogróżkami?" <rotfl>
Jestem, jestem. Ale możemy się podzielić. Planuję być na SV w grudniu, więc prawdopodobnie będę mógł tam przywieźć Magię (aktualnie jest u Candla).
edit: Aaaaa. Chodziło o MultiTOS'a. Nie zależy mi na oryginale - zadowolę się skanami :)
A co myślicie Panowie o trickach z włączaniem transmisji dwutonowej w SKCTL, co daje nowe możliwości brzmieniowe ze względu na włączenie filtra dolnoprzepustowego? Odpowiednie wątki na aage były tutaj, tutaj i tutaj.
Druga sprawa dotyczy startowania liczników POKEYa przez zapis do STIMER - czy to miałoby zastosowanie do jakichś ciekawych modulacji (w takim reżimie czasowym - bo pewnie jak będziemy zapisywać STIMER 2x na linię to wpływ to będzie miało)?
A może też zaemulować 48k, rozszerzenie do 80k, ZX Spectrum 128k?
Czy dużo problemów byłoby z emulacją ZX81?
Pin weź z kabelkiem - ja go od Ciebie odkupię :)
@pik33: - http://en.wikipedia.org/wiki/MOD_%28file_format%29 np. Noisetracker/Soundtracker/Protracker Module Format - 4th Revision
Mógłbym się podjąć napisania takiego konwertera z .NEO do SS.
Tak. Od środka (z punktu widzenia playera po staremu), z punktu widzenia usera po nowemu.
@Bober: Trzymaj tak, jak było w zwykłym CMC - po jednym kanale. To chyba najoszczędniejszy sposób, bo dzięki temu, jak ktoś w 3 kanale wpisze coś, co w innym patternie występowało w 1 kanale, wtedy nie będziesz miał powtórzeń. Poza tym ułatwi to kopiowanie kanałów między patternami (lub zmianę treści kanału).
Edit: Taki trackerowy pattern miałby 4/8 linków do patternów CMCowych.
@Bober: Chodzi o to, że dla 8-bit kanałów taktowanych różnymi częstotliwościami bazowymi (15k, 64k i 1.77M) w różnych miejscach są dziury (dla 16-bit zresztą też). Można by uwolnić muzyka od kombinowania na którym kanale które brzmienie grać, z jaką tablicą i jak ustawić AUDCTL tak, żeby nie wpaść w dziurę. Automat musiałby sobie rozstrzygać sam jak zrekonfigurować AUDCTL i jakie wartości wpisać do rejestrów częstotliwości. Analogicznie ze zniekształceniami (włączanie licznika polly).
Można by rzecz jasna ostrzegać kompozytora podczas wpisywania danych do patternów, że takiej konfiguracji brzmień nie da się uzyskać na POKEYu (na raz edytuje się i tak przecież jeden kanał).
Muzyk mógłby wtedy tworzyć brzmienie, w którym określałby jaką głębokość ma mieć vibrato lub jakie zniekształcenie ma być dobrane w danej chwili w oderwaniu od sprzętowych niuansów POKEYa. Oczywiście zawsze mógłby zmusić player do zagrania danego brzmienia na konkretnym kanale 8 lub 16-bit.
Edit: Głębokość vibrato - mam na myśli głębokość niezależną od tego czy kanał ma 8 czy 16bit - czyli liczoną w jakichś bazowych jednostkach (można by chyba w zasadzie przyjąć właśnie rozdzielczość licznika 16-bit taktowanego 1.77M). Z głośnością takich problemów nie ma, bo jest zawsze 16 stopniowa.
Jeśli można się dopisać, to ja z przyjemnością bym na SV przybył.
Czy można by prosić o zamienne traktowanie separatorów w ścieżkach do plików?
Obecnie jeśli projekt rozwijany jest w zespole multiplatformowym za każdym razem trzeba zamieniać "\" (Windows) na "/" (Uniksoidy) (lub odwrotnie ;P). Drobna (chyba) zmiana a nieco by uprościła.
Dziękuję.
P.S. Mam madsa 1.9.0 i linuxa ubuntu 9.10 x86_64, madsa kompiluję sobie fpc 2.2.4-3.
To ja poproszę 8. Czy author to przypadkiem nie William Moebius?
Edit: A jeśli można, to reflektowałbym na skany 5 i 6.
W rozmowie telefonicznej Pin naświetlił mi problem i okazało się, że rzecz nie leży w synchronizacji tempa (choć byłoby miło, gdyby kawałki chodzące w PAL mogły też działać w NTSC - wystarczy spojrzeć, co Pavros kombinuje przy odtwarzaniu muzyki w IK+ (nawiasem mówiąc uważam numery ze wstrzymywaniem playera na jedną ramkę na 6 za pomyłkę)), lecz zupełnie gdzie indziej.
Mianowicie - wg Pina tempo TRACKÓW/PATTERNÓW mogłoby już zostać po staremu, bo to nie jest wielki problem, ale potrzebne jest DRUGIE ZUPEŁNIE NIEZALEŻNE TEMPO -- tempo odtwarzania instrumentów! które byłoby tempem "subramkowym", czyli instrumenty odtwarzane byłyby co n linii rastra.
Może rzeczywiście warto by się nad tym zastanowić?
Edit: wtręt odnośnie Pavrosa i IK+
Nie mówiąc już o filtrze dolnoprzepustowym od transmisji z magnetem (manipulacje skctl) czy dynamicznym przypisywaniu częstotliwości do kanałów (filtry, łączenie dzielników i zmiana zegara bazowego).
Znalezione posty [ 2,626 do 2,650 z 3,030 ]
Forum oparte o: PunBB
Currently installed 7 official extensions. Copyright © 2003–2009 PunBB.
Wygenerowano w 0.100 sekund, wykonano 19 zapytań