Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Tydzień na oddanie głosu w FUJICUP! Głosowanie potrwa tylko do 22 lutego 2025...
TURGEN 9.3.1 Najnowsza wersja oprogramowania TURGEN wprowadza kilka istotnych ulepszeń.
FujiCup 2024 - głosowanie Wystartowało głosowanie w tegorocznej edycji konkursu FujiCup.
IX. Basque Tournament of Atari 2600 31 stycznia Euskal Retro Association zorganizowało IX. Baskijski Turniej Atari 2600.
Rogul 1.0f Poprawki i nowe funkcje
atari.area forum » Posty przez Fox
Jeśli chodzi o wyrpanie z jakiego produktu to nie ma sensu tego dawac, bo muzykę dawano do różnych rzeczy i brano skąd popadnie. To akurat mało obchodzi skąd ona pochodzi.
Mnie obchodzi powiązanie z produkcjami scenowymi w obie strony. Np. nowy tag w SAP + link do SAP w ASDB.
"code" w nawiasach kwadratowych.
Moje wariacje:
inc:lda _d
dta $0c,$07 ; anc #
bne exit
lda #$20
adc:sta _e -
bcs exit
lda #-8
adc:sta _d -
exit rts lda _d
add #1
bit const7
bne exit
ldx _e
ldy add32,x
sty _e
cpy #32
bcc exit
sbc #8 +
exit sta _d
rtsA poważnie: jeśli wejście jest tylko (albo zwykle) z _enter i _enter2, to trzeba optymalizować pod tym kątem.
Trochę może offtopowo, ale zawsze mnie intrygowało, dlaczego sektory $401..$410 były niewykorzystane?
DOS 2.x zapisuje numer kolejnego sektora na 10 bitach (a więc do 1023), 6 jest przeznaczone na numer pliku.
Oczywiście xasm.
GTIA pobiera kształty PMG przez szynę danych. Jeśli w ANTICu nie włączy się DMA dla PMG, GTIA bierze co leci.
Programik dla chcących sprawdzić, co GTIA widzi na szynie:
ATR equ 1
ift ATR
opt h-
dta $96,2,a(8),a($80)
:10 dta 0
org $600
dta 0,1,a($600,$e477)
els
org $606
main
eif
mva #$7c $2c1
mva #$70 ^01
mva #3 ^09
mva #2 ^1d
frame
ldx #{cmp 0}
lda #8
and ^2f
sne
ldx #{cmp 0,x}
stx op
lda #3
cmp:rne ^4b
line
sta ^4a
nop
nop
op cmp 0,x
lda #0 ; <-
sta $c000,y
iny
bne line
beq frame !
ift ATR
:$680-* dta 0
els
run main
eif
endU mnie:
bity 7,6,5,4,0 = z ROMu,
bit 3 = AND ROMu i zapisu 6502,
bity 2 i 1 różnie - zwykle ROM, ale czasami AND.
BASIC wygląda na podłączony dobrze (zmiana $c000 na $a000 i uruchomienie z BASICiem) - widać bajt zapisywany przez 6502.
Powrooz: nie pamiętasz, jaka była nasza Scena w 2001.
Mac: mam nadzieję. :)
xxl: dziękuję za ironię. Nie chodziło mi o to, żeby się pochwalić, tylko zasygnalizować, że ten tryb mam już trochę przećwiczony.
TeBe: 9+ to "tryb Konopa", 9++ z VSCROLem. 12++ z VSCROLem a o 12+ nie słyszałem.
Eru: to samo słyszałem od Ciebie na początku 2002. :)
Dhor: dostępność źródeł popieram.
TeBe, nowe tryby pokazuje się w nowych demach, a nie na forum!
Ten tryb wymyśliłem w 2003. Nazywa się 12++ (od GR.12).
11 odcieni wcale nie kosztuje więcej, wystarczy użyć ADC zamiast ORA (lewy piksel mnożymy przez 11 zamiast przez 16 jak zwykle).
Może Eru teraz opisze swoje tryby graficzne, bo w międzyczasie TeBe je wymyśli. :)
i okazać te przeglądarki TIPów dobrze wyświetlające kolory na VBXE...
Kupię:
- XL/XE z zasilaczem bez rozszerzeń
- 2 joysticki w dobrym stanie
Najchętniej odebrałbym w Warszawie.
Miałem takiego Pythona (tyle, że chyba na gumkach), jest bardzo wygodny. Zakupiłbym 2 sztuki.
Takie tematy to "Scena" a nie "Bałagan".
W "Vectorze" zwracam uwagę, że: ściany pod kątem prostym, 4 kolory z ditheringiem (nawet ładnie wyszło), nie ma sprajtów, nie ma animacji, szeroka ramka, no i szczegół zauważony przez Dracona, że wszystko pod jednym dachem. W każdym razie szacunek.
Kiedyś napisałem obsługę myszy od Amigi. Ta zacytowana nie jest szybka. Można też zaoszczędzić na czasie robiąc ograniczenie obszaru raz na ramkę a nie na każdym przerwaniu.
Podstawowe pytanie to jak szybkie ruchy powinny być obsługiwane, w związku z tym jak często powinno być przerwanie. Jeśli przerwanie będzie za wolno, to kursor będzie drgał zamiast przesuwać się. Przy szybkich ruchach przerwanie musi mieć 1000Hz jeśli nie więcej.
APAC i TIP korzystają z tego, że rozdzielczość pionowa kolorów w PAL to 120. Wyjście VBXE nie jest w standardzie PAL. Być może rdzeń VBXE mógłby emulować obsługę kolorów ala PAL.
Nie ustawia się żadnego bitrate. Może on wynikać np. z prędkości obrotowej, FM/MFM, liczby i długości sektorów na ścieżce, różnej długości przerw między sektorami (np. w gęstości 130KB są większe niż w 180KB), różnego przeplotu (kolejno na ścieżce nie są sektory 1,2,3,... tylko np. 1,10,2,11,3,12,...).
1. Podstawowe gęstości Atari: 90KB (128 bajtów na sektor FM), 130KB (128 bajtów na sektor MFM), 180KB (256 bajtów na sektor MFM), PC = 512 bajtów na sektor MFM. Są jeszcze warianty 1/2 strony i 40/80 ścieżek.
2. Kontrolerowi ustawia się FM lub MFM poprzez odpowiedni pin (np. jeśli nic nie możemy złapać w MFM to przełączamy na FM i na odwrót), a rozmiar sektora jest zapisany w nagłówku sektora i kontroler sam go rozpoznaje. Przeliczeniem numeru sektora na dysku na numer ścieżki i sektora na ścieżce zajmuje się procesor.
U mnie miga (telewizor CRT).
pajero: skoro Infogrames zgadzają się na użycie logo, to może pozwolą oficjalnie dołączać ROMy do emulatorów?
Możliwe, że to był ten "gril": chodziło mi o to, że przy wyłączonym telewizorze widać było ciągłe proste paski. Do ciemnych linii w Trinitronie można się przyzwyczaić.
Seban: dużo telewizorów nie widziałem, ale w Heliosie i wypukłych Philipsach były pionowe paski.
Eru: w obrazie Atari widać puste linie, trzeba tylko patrzeć z bliska.
Głupiś jak zwykle. Normalnie atarka rysuje 240 linii zawsze w tym samym miejscu. Ten temat dotyczy tego, żeby rysować między tymi 240 liniami.
Jeśli chodzi o poprzedni Twój post, to zauważ, że na pionowe paski luminoforu są ciągłe. Skąd wiadomo, jak dużo go się zapali?
Konop: Tak właśnie zrozumiałem jak narysowałeś.
Twój rysunek rezultatu na ekranie zakłada, że skanlinie są wysokości rozdziałki 240. Podejrzewam, że jest to raczej bliżej 480 (czyli półobrazy nie nakładają się, lub nakładają w małym stopniu) i może mocno różnić się między telewizorami.
Proszę o wyjaśnienie, która klatka jest parzysta, a która nieparzysta ("zwykła" czy "Rybagsa"), która jest niżej i czy jest coś takiego jak para półobrazów o ustalonej kolejności. Zwracam też uwagę, że niekoniecznie musimy wyświetlać naprzemian parzyste/nieparzyste - może np. miałoby sens dwie zwykłe i jedna "Rybagsa" ?
Konop: Rozumiem, że chodziło o klatkę parzystą i nieparzystą. Taki HIP może wyglądać dobrze, ale kolory (CIN, TIP) - wątpię. Dekoder PAL skleja kolory w sąsiednich liniach, ale raczej nie między półobrazami.
Eru: Nie rozumiem. :)
Mnie zastanawiają dwie rzeczy:
1. Dlaczego 30 lat temu nie zrobili w GTIA bitu, który pozwoliłby się przełączyć między półobrazem parzystym a nieparzystym?
2. Czy normalna nieinterlejsowana grafika będzie wyglądać lepiej czy gorzej, gdy będziemy przełączać półobrazy? Jak wiadomo, na telewizorach widać skanlinie obrazu z Atari, może jak włączymy interlace, to obraz będzie wyraźniejszy?
Co do nowych trybów: nie spodziewałbym się rewolucyjnej poprawy trybów, które już wykorzystują stary (migający) interlace. Wygodne byłoby przełączanie trybów 9/10 co ramkę, a nie co skanlinię (byłoby łatwiej robić efekty w HIP/TIP), ale podejrzewam, że to jednak będzie migać (chyba, że telewizor 100Hz - ma ktoś taki?). Najwięcej zyskają tryby bez interlace - G2F, GR8 itp.
Rybagsowi należy się wielki frasunek, jak się mówiło na Quaście 2003. Odkrycie co najmniej na miarę HIPa.
Obrazek zamieszczony przez Sebana jest dla mnie mało czytelny. Bardziej przemawia do mnie kolejny z tego artykułu:
atari.area forum » Posty przez Fox
Wygenerowano w 0.058 sekund, wykonano 21 zapytań