Jeżeli w specyfikacji procesora jest 14 MHz to nigdy nie dałbym więcej.
Nie zauważyłem, aby w specyfikacji wymieniano ograniczenie do 14 MHz.
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 Marek Konopka
Jeżeli w specyfikacji procesora jest 14 MHz to nigdy nie dałbym więcej.
Nie zauważyłem, aby w specyfikacji wymieniano ograniczenie do 14 MHz.
A skąd weźmiecie wersję 65c816, która chodzi stabilnie na 20 MHz?
Jedyną wskazówką jest oficjalna specyfikacja ( http://www.65xx.com/wdc/documentation/w65c816s.pdf ) , która na stronie 27, rycinie 4-2 prezentuje napięcie VDD w funkcji częstotliwości taktowania. W pobliżu 20 MHz występuje pewien charakterystyczny pkt., aczkolwiek to mogą być pobożne życzenia. W Table 4-1 określają jednak max. VDD na +7.0V.
Znalazłem jeszcze taką konkretną aplikację:
http://www.westerndesigncenter.com/wdc/ … ations.cfm . Cisną nawet 27 MHz.
Z proporcji wyszło mi, że w tym rozwiązaniu goście cisną max ze specyfikacji, bowiem:
12 MHz/~3 VDD = x MHz / 7 VDD
Dane po lewej stronie równania odczytałem z wykresu. Charakterystyka jest liniowa, więc zastosowanie proporcji jest uprawnione.
x wychodzi ~28 MHz, co potwierdza przypuszczenia.
Wygląda na to, że mój email do Geparda nie dotarł, więc piszę tutaj. Jak chcesz, to mogę wrzucić gdzieś na sieć Lamekicker'a.
do LG mam podłączoną moją starą wysłużoną 130XE (Pamięci 8x1bit). Do do efektu który opisujesz to owszem jest obecny. Nawet niekoniecznie przy zmianie trybu graficznego, wystarczy przesunąć kursor w GR.0 aby zaobserwować ten efekt
Lekki offtop... Nie znam dokładnie tego monitora i pewnie moja sugestia nie będzie wiele warta w przypadku przesunięcia kursora, ale w kwestii zmian trybu graficznego być może przyczyną jest włączona opcja Digital Fine Contrast.
Ale to nie jest najbardziej wkurzające, najbardziej wkurzające jest opóźnienie kilku ramek w wyświetlanym przez monitor obrazie. To może doprowadzić do szału w niektórych przypadkach.
Tutaj zapewne winnym jest DFI.
GG konopki: 7630638
Bynajmniej.
aha, chciałem pogratulować autorom CROSSOVER - bardzo fajne, i... ja nie wiem jak to działa, że tyle kolorów udaje im się zrobić :)
Kulki mają 40 pixli szerokości, więc jeśli nawet jedna jest na duszkach, to skąd duszki na literki zostały? :)
Możliwy wariant to każde kółko po 1 playerze (x4) i pocisku (x4), a literki na Antic'u.
Liń jest ~239.5 :> I tak jak pisał Bober - linia #240 zrywa synchronizacje.
Co sugeruje iż takie parametry to oni uzyskują na karcie dźwiękowej zgodnej z AHI
Co do 14 bit output to raczej pewne, że chodzi o Paulinę:
- optional 14 bit output (less noise but not as good as true 16 bit)
bowiem:
* Native Amiga chipset (Paula) 14 bit
* Native Amiga chipset (Paula) 14 bit calibrated (Christian Buchner)
I ja pisałem o zwykłym odtwarzaniu plików MOD, gdzie sample maja rozdzielczość 8-bit... PAULA odtwarza wszystko sprzętowo a PLAYER MODów wykonuje się tyle co powiedzmy player jakiegoś muzaka na AY-2149 :)
Z tego co widzę, to istnieją playery .XM na Amigę. Sam format wspiera 16'to bitowe sample, tylko nie wiadomo, czy playery to wspierają. Może ktoś to potwierdzić?
kanałowego MOD-a należy zmiksować dwa kanały w jeden (przy użyciu mocy procesora). Po miksowaniu typu OUT=(L1+L2)/2, tracimy po 1 bicie z każdego kanału a więc de facto mamy efektywną rozdzielczość 7 bitów na kanał...
To w takim razie główną przyczyną lepszej jakości dźwięku z przetworników STE w stosunku do Amigi jest częstotliwość próbkowania. Na Amidze sample wyraźnie "harczą".
Można sample przechowywać z większą rozdzielczością, np. 9-bitową, aby po zmiksowaniu uzyskać 8 bitów rozdzielczości.
Z moich niezbyt długich doświadczeń z Atari STE wynika, że posiada on lepszej jakości przetworniki cyfrowo analogowe, większą częstotliwość próbkowania, a co za tym idzie lepszej jakości dźwięk. To jeśli chodzi o sampling. Jeśli chodzi o syntezę to ST(e) wypada (chyba) o niebo lepiej, bowiem Amiga takowej nie posiada w ogóle, z tym, że wbudowany w ST(E) układ AY jest raczej nieadekwatny do reszty komputera. Wiem, że istnieją sposoby na poprawę sytuacji (program MAXimizer), ale w moim odczuciu wiele nie zmieniają.
Polecam muzykę z gry (i całą grę) Pinball Fantasies http://wet.atari.org/obsession/ .
Pewnie będziecie przejeżdżać przez Sosnowiec/Katowice lub okolice. Czy znalazłoby się miejsce dla jeszcze jednego grzbietu?
Niepraktyczne do dynamicznych gier, ale do statycznych obrazkow moze by sie idealnie nadawalo?
Z tego co pamiętam, program GED dokonuje właśnie multiplexing'u sprite'ów w poziomie. Swego czasu Titus narysował parę rysunków w nim, z naprawdę imponującym efektem. Wystawiał te prace na którejś Ornecie.
10 duszkow w linii pozwalaloby pokryc caly ekran - toz to rewelacja! W czym tkwi haczyk (o ile jakis istnieje?)
Korekta - dokładnie połowę - 10 duszków x 8 pikseli = 80 pikseli (przy założeniu normalnej szerokości ekranu oraz standardowej szerokości sprite'ów).
Problem polegał na tym, że nie wystarczało cykli CPU, aby ustawić sprite'y w szeregu, jeden za drugim. Nie pamiętam dokładnych pomiarów, ale jestem pewny, że nie wystarczało, aby to zrealizować idealnie. Pomiędzy ostatnim duszkiem w pierwszej grupie, a pierwszym w następnej musiała być przerwa. Kod wyglądał tak:
lda #SPRITE0_GROUP0_POS
sta $d000
lda #SPRITE1_GROUP0_POS
sta $d001
lda #SPRITE2_GROUP0_POS
sta $d002
lda #SPRITE3_GROUP0_POS
sta $d003
lda #SPRITE0_GROUP1_POS
sta $d000
...
Nie da się szybciej tego zrealizować.
Na załączonym zrzucie nie widzę żadnego multiplexing'u, gdyż za takowy uważam wyświetlanie zwiększonej ilości obiektów w lini poziomej. Kiedyś - dawno temu - zrobiłem multiplexing na przerwaniu DLI, które zmieniało adres bazowy sprite'ów oraz ich pozycje. Niestety było to niepraktyczne, ponieważ z oczywistych powodów (opóźnienia) nie pozwalało na dowolne pozycjonowanie. Z tego co pamiętam udało się wyświetlić 10 duchów w jednej linii. Być może przy sprytnym manewrowaniu pozycjami oraz przy pewnych założeniach można uzysykać jakiś sensowny wynik. Jeśli komuś na tym zależy to mogę przegrzebać dyski w celu zlokalizowania delikwenta.
Głosowanie na imprezach jest pozbawione sensowności. Dla mnie liczy się sam fakt zaprezentowania czegoś ciekawego. Można odpowiednio podzielić programy wykonywalne na dema oraz "joke'i". Tym zadaniem powinni się zająć organizatorzy.
U mnie na Vista Home Premium PL ogólnie działa w trybie pełnoekranowym, z tym, że są jakieś problemy z paletą kolorów. Na matrycy o aspekcie 16:10 obraz jest rozciągnięty w poziomie.
Btw. DirectX 10.0 jest standardowo preinstalowany w Vista.
1. 17.
2. Z czasopisma "Tajemnice Atari".
3. Pascal, C, C++, Java.
4. Tak.
5. Microsoft Visual C++ Studio .NET 2003.
.... teoretycznie ktoś pod GED'em zrobił grafe (ale raczej nie do dema Zelaxu) :) -
Tita.
Przy okazji, jakby ktoś miał tą część (bodajże na górze było logo APC podświetlane 'reflektorami', pośrodku animowany scroll, a na dole kolorowy equalizer), to ja poproszę, bo mi zaginęła
Poszukam na dyskach Jordana, może się ostało.
"Kogut - The Awakening" - Coming Soon Across Cinemas Around Your Area.
Seban, korekta: zamiast
jsr get
ma być:
jsr $a293
Dodatkowo powrót można zrealizować jako beq exit, do miejsca, gdzie wywoływano podprocedurkę i usunąć rts i mamy:
src = $9D
dest = $24;loop jsr $A293
beq exit
lsr @
tay
q0 jsr $a293
q1 sta (dest,x)
jsr $E6D1dey
_bpl bmi loop
bcs q0
bcc q1
22 bajty.
atari.area forum » Posty przez Marek Konopka
Wygenerowano w 0.024 sekund, wykonano 57 zapytań