no fajne.... ale montowane i jeden kanał ;) ... miker zapodaje w czasie rzeczywistym i multipleksuje kanały :D
Seban
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
ASAP ma 20 lat - wydanie 7.0.0 20 grudnia 2005 został utworzony pierwszy commit w repozytorium CVS projektu ASAP (Another Slight Atari Player).
FiSh 0.70 Bocianu wydał FiSh 0.70, shell ułatwiający przeszukiwanie zasobów serwerów TNFS.
Street Fighter II już na Atari 8-bit! Vega i jego zespół wydali finalną wersję kultowej bijatyki. Wymaga 4MB cartridge i 64KB RAM.
Elite Demo 6 na Atari 8-bit! Trwają prace nad konwersją kultowej gry Elite. Szóste demo wprowadza liczne poprawki błędów.
vbcc v5 dla 6502 Kompilator C vbcc doczekał się piątej wersji dystrybucji dla 6502. Zapewnia dużo szybszą arytmetykę FPU i nowe narzędzia.
atari.area forum » Posty przez seban
no fajne.... ale montowane i jeden kanał ;) ... miker zapodaje w czasie rzeczywistym i multipleksuje kanały :D
Seban
Hi!
Alex proponuje abyś zagrał rolę Mr. Propera :D
Seban
Hi!
Seban: mnie się wydaje, że to kwestia starownika, a nie matrycy.
A widzisz.... to już zależy jakiego standardu jest matryca (dlatego o to pytałem). Ale patrząc na ich sterownik (i ilości kabli które idą do matrycy) wydaje się iż sterownik nie dokonuje on żadnych skomplikowanych konwersji ;) wiec wszystko będzie zależało od matrycy... padtrząc na dokumentację jakiejś 15" matrycy sharp widzę iż matryca ma z góry określoną czestotliwość odświerzania, np. dla w/w 15" Sharpa mieści się ona w zakresie od 55Hz do 75Hz, a sugerowana częstotliwość pracy to 60Hz. Gdyby sterownik dokonywał jakichś karkołomnych konwersji sygnału to pewnie bez problemu uciągełoby to każdy wejściowy sygnał... ale wydaje mi się że będzie aż tak rozbudowany interface.
pozdrawiam
Seban
Hi!
a łapie może hsync zakres od 15 kHz?
a to zapewnie zależy od matrycy którą podłączasz... jeżeli matryca wydoli 15KHz to czemu nie. Trzeba by się dowiedzieć jaki standard obsługiwać to będzie i poszpereać czy którakolwiek z matryc może działąć w 15KHz.
Ja na PCB po stronie wejścia widze zarówno analogowe VGA jak i złacze DVI... a ja się chciałem dowiedzieć jaki ze standarów jest po drugiej stronie i stąd te kilka standardów które wypisałem w poprzednim poście :) Z niecierpliwością czekam za zakończenie prac :) i na linka do strony gdy tylko schematy zostaną opublikowane :) pomysł rewelka :)
pozdrawiam
Seban
hej!
Bitman masz coś więcej o tym??? Bo wygląda to bardzo obiecująco :)
Czy Chłopaki podłączyli panel od laptopa do analogowego VGA????
Czy dostępna jest jakaś wstępna specyfikacja interfejsu???
Jakie rodzaje paneli LCD można do tego podłączyć?
* Analog VGA (used in external LCD displays but not in laptops normally)
* 44-pin TTL parallel
* 20-pin LVDS serial
* Digital Video(6-bit for each color R/G/B) Sync Signal,DOTCLK, 4 pairs LVDS (used in some IBM laptop displays)
* DVI (Digital Visual Interface LCD panel digital interface from DDWG, used for external LCD screen mainly)
pozdrawiam
Seban
Hi!
A może to nie Turbo Operating System ... tylko Tape Operating System ;)
Seban
Hi Święty!!!
Ja w swoim poście dość mocno uprościłem to co musisz wyczyniać aby dokonać przeliczeń :) Zdaje sobie sprawę iż jest to dość skomplikowaną sprawą.... nie chciałem powiedzieć iż to jest trywialne, bo nie jest... po prostu nie chciałem wypowiadać się na temat na którym się znie znam i pozwoliłem sobie nieco uprościć sprawę, spekulując jedynie na temat zasady działania twojego programu. Uważam iż to co robisz jest po prostu niesamowite i podziwiam Cię iż Ci się chce i że znajdujesz na to czas :)
Wielki szacunek, pozdrowionka :D
Seban
Hi!
No muszą chodzić szybciej :D
W NTSC masz 60 ramek na sekundę/525 lini, a nie 50 ramek/625 lini jak w przypadku PAL :)
komuter pracujący w NTSC jest taktowany nieco szybszym zegarem... i czestotliwość przerwania VBL wynosi 60Hz.
Seban
Hi!
Ale mi się wydaje iż tu nie ma żadnego SoftSynth'a... SID2POKEY to nie SID Player, to dwie osobne sprawy.
SidPlayer próbuje emulować/naśladować Sid'a...
Natomiast SID2POKEY... ma za zadanie zamianie odegranie MSX'a z C64 poprzez przeliczenie wartości częstotliwości i emulację obwiedni ADSR z SID'owych rejestrów i zagranie tego na "czystym" pokeyu. Tak jak to HardSoft robili w swoich demkach przerzuconych z C64 ;)
Seban
hej!
jestem pod wrażeniem :)
aż dziwi płynność/szybkość tego co widać :)
kawał dobrej roboty Panowie :D
pozdrawiam serdecznie
Seban / Slight
hej!
110V? to może masz także wersje NTSC?
Seban
hej!
może chodzi Ci o grę "Submission"?
pozdr.
Seban
hej!
nie wiem jak bardzo krytyczna jest prędkość dekompresji... jednak możnaby się pokusić o kompresję bitową... jeżeli to jest dla twojego zastosowania odpowiednie można podejsc do problemu nieco inaczej... w przypadku takiego rozkladu danych wejściowych, należałoby zastosować jakiś kod, w którym długość słowa okreslajacego dany znak, nie jest stała. Najbardziej logicznym wydaje się zastosowanie bardzo prostego kodowania bitowego, np. możemy zastosować taki algorytm...
potrzebujeby procedury get_bit, która umożliwia pobranie jednego bitu danych ze wejścia.
1. zerujemy "index"
2. pobieramy jeden bit
3. zwiekszamy index o 1
4. sprawdzamy czy pobrany bit=1, jeżeli nie wracamy do kroku #2
5. wartość index określa jednoznacznie daną ktory pobralismy, mozemy go wykorzystac do pobrania odpowiedniej wartosci z tablicy konwersji.
reasumujac, kodowanie bedzie wygladalo mniej wiecej tak:
1: kod oznaczajacy dana #1
01: kod oznaczajacy dana #2
001: kod oznaczajacy dana #3
0001: kod oznaczajacy dana #4
itd.
jak widac ilosc bitów przeznaczonych na zakodowania kolejnego symbolu rośnie dość szybko... jednak w przypadku twojego rozkładu danych (70% będzie reprezentowane przez pojedynczy bit). Ma to szanse sporej kompresji. Musisz sprobowac w praktyce. Zreszta istnieje bardzo duzko koów o zmiennej dlugosci slowa... mozesz sprobowac poczytac troche tu:
http://en.wikipedia.org/wiki/Prefix_code
i tu:
http://en.wikipedia.org/wiki/Universal_ … ression%29
procka dekompresji moze byc dosc krotka i przy dobrej implementacji get_bit, powinna byc szybka:
get_one_byte:
ldx #$00
loop:
jsr get_bit ; get bit w znaczniku "C" zwraca wartosc pobranego bitu
inx
bcc lopp
lda tab_cnv,x
rts
; tutaj tablica konwersj, najczesciej wystepujace elementy powinny byc kodowane najmniejsza iloscia bitów :)
; czyli będą się znajdowały na początk u tablicy... im dalej w tablicy tym wiecej bitów potrzeba :)
tab_cnv:
dta b($04),b($03),b($02),b($01)
get_bit:
; tutaj w/g twojego uznania... jest sporo sposobów :)
; a implementacja zalzey od tego czy uzyjesz rejestrow, lokacji na stronie zerowej... itd.jest to jedno z prymitywniejszych kodowań o zmiennej długości słowa... i nie wiem czy to bedzie przydatne ze wzgledu na szybkosc, jednak kompresja powinna byc efektywna dla twoich danych :)
pozdrawiam
Seban/SLIGHT
Hej!
Ponieważ czytając w/w posty napotkałem na wypowiedź Fox'a w której stwierdził iż:
Wedle mojej wiedzy, takie "xchg" byłoby dużo szybsze na 286 i starszych,
a dużo wolniejsze na Pentium Pro i nowszych (gdzie AH jest fizycznie
osobnym rejestrem od AX i stosowana jest emulacja w celu utrzymania
wstecznej zgodności). Na nowych prockach prawdopodobnie najszybsze będzie:mov edx, eax shl eax, 8 shr edx, 8 and eax, 0FFFFh add eax, edx
szczrze mówiąc zwątpiłem iż ROL może być aż tak wolny... i że 5 instrukcji będzie szybsze niż jeden ROL, powoli zaczołem popadać w paranoje iż świat staje na głowie :D i że może czas zacząć sadzić marchewkę... ale coś mnie tkneło, ale ponieważ na X86 to się trochę znałem ale do generacji powiedzmy 486, zapytałem kogoś kto ma większe pojęcie o architekturze X86 ode mnie... w tym wypadku trafiło na SoTe, a ponieważ biedak jest nieco zapracowany to pozwolę sobie go tu zacytować (żeby nie było za jego zgodą):
SoTe napisał co następuje:
Nie za bardzo mam czas, aby tworzyć sobie konto na AA, zeby odpisaczeby odpisac, ale mozesz napisac fox'owi ze ta cala procedurka od zwyklego rol'a będzie wolniejsza z kilku powodów:
Przede wszystkim dlatego ze uzyl 2 rejestrow, to powoduje "registry stall". dzieje sie to wtedy gdy jakas instrukcja uzywająca rejestru (w tym wypadku add eax, edx) czeka na wynik poprzedniej instrukcji (w tym wypadku and eax, 0FFFh)
Jesli chca uzyskac zwykla zamiane 2 bajtow, to najlepiej bedzie uzyc "rol ax,8". ponadto najnowszy visual 2005, taką konstrukcję (a>>8) | (a<<8), zamienia wlasnie na pojedynczego "rol ax,8". nie jestem w stanie sprawdzic poprzednich wersji kompilatora bo ich nie mam
uzycie "rol ax,8" jest dlatego najszybsze, ze:
a) uzywa jednego rejestru i jednej instrukcji
b) rol r,m jest zaliczany do rozkazów ALU, a to oznacza ze na nowych P4 (3-4 letnich i nowszych) rol ax,8 zajmie 0.5 cykla
(jednostka ALU jest popędzana w tych procesorach zegarem 2x szybszym niz reszta procesora)
ufff... i tyle :) wiec jak sie okazuje z intelem nie jest aż tak źle, jak myślałem :)
hi!
Skoro brak odpowiedzi to może autor pytania rozwiąże zagadkę??? :)
Seban
Hi!
a może włączyłeś sobie w Windowsie tzw. "sticky keys". Takie ułatwienie dla niepełnosprawnych. Winda sama proponuje włączenie tej funkcji, gdy dłużej przytrzymasz jakiś klawisz wciśnięty.
Seban
hej!
a jeszcze jedno pytanko dotyczące transmisji sprite'ow... z dokumentacji wynika iz GTIA odczytuje dane spritów z magistrali na którą adresy wystawił ANTIC. Pisałeś iż GTIA wie że to się będzie dzaiało po stanie pinu ~HALT. Jednak mam pytanie skąd GTIA wie do którego HALT'a się synchronizować? Czy może jest po pierwszy HALT po stanie 01x na szynie ANx?
I jak już się aż tak wgłebiałeś w całe historie związane z ANTIC/GITA to może będziesz wiedział czy ANTIC pobiera jakieś dane podczas cykli odświeżania pamięci? czy po prostu generuje tylko ściśle określone adresy zupełnie nie związane z pobieranymi danymi? Logiczym wydawało by się iż ANTIC podczas odświeżania RAM nie może nic pobrać sensownego z pamięci ponieważ musi wygenerować konkretne adresy na liniach adresowych. Ale warto się upewnić :)
a może napisać do Panów z ATARI MUSEUM aby za niewielką opłatą przesłali nam czytelne i pełne xero-kopie tych dokumentów? ktoś chętny do spreprarowania do nich porządnego e-maila po angielsku? można by im napisać iż gdyby udostępnili tą dokumentacje mogą się spodziewać z polski nawału mega-giga sprzętowych rozwiązań :D
i jeżeli mogę to jeszcze jedno pytanie szpiegowsko przemysłowe... czy możesz zdradzić jakie FPGA? Altera, Xilinx, Lattice, Cypress, Actel, Atmel? :)
Electron masz może jakieś czytelne wersje PDF'ow do ANTIC/GTIA? Te z atari museum są jakieś mało czytelne :)
Electronie super pomysł... :) czekamy z niecierpliwością :)
Tak patrząc na ten opis ANx BUS nie widze jak mogą być dane spriteów wysyłane... może ktoś wie? bo mnie ciekawość zrzera :)
alex kto to wie... trochę jest na stronie:
http://www2.asw.cz/~kubecj/atanttim.htm
koncówka strony w sekcji ANx BUS.
Seban
Brak demodulatora chroma - luma. RGB sterowane przez ANTIC. Z GTIA zostaje tylko generator synchronizacji. To już działa - póki co brak spriteów i trybów GTIA
hej!
rozumiem iż dokonujesz konwersji tego to ANTIC do GTIA podsyła na liniach AN0,AN1,AN2 :)
jeżeli udało Ci się to wyczaić to fajnie :D
Jeżeli możesz zdradź rąbka tajemnicy co po tej mini-magistrali biega :D zawsze byłem ciekawy... ale nigdy tego nie sprawdziłem :D ehh... to lenistwo :D
heja!
A tak z ciekawości na czym robiłeś demodulator chroma/luma->RGB?
bo ja się powoli przymierzam do cyfrowego toru chroma/luma -> VGA :) ale to jak skończę SlightSID'a :)
Seban
hej!
czy chodzi może o to Turbo 2600 Panów ze Świebodzina?
Seban
co do epromu na pokładzie... początkowo planowałem flasha z opgrogramowaniem w carcie ;) ale niestety nie w tej wersji.
PCB zrobiłem bez pamięci FLASH. Na razie rejestry siedzą w $d5xx. Ale docelowo będzie mógł być to dowolny obszar :D
Moim marzeniem docelowo było włożenie dużego flasha z ogromną ilością fajnych muzyczek z HVSC.
Nie miałbym jednak zupelnie czasu na oprogramowanie tego wszystkiego. Teraz szanse są :)
Święty odwalił kawał dobrej roboty :D Z jego playerem wszystko jest możliwe :D
Może w kolejnych wersjach PCB dorzuci się flasha :D
A co do dopałki "F7" to chyba nie powinno byc problemów :D no chyba że turbo "F7" działa jakoś bardzo nietypowo.
Wydaje mi się jednak że powinno być OK :)
Seban
ani ściema ani prowokacja.
niebawem się przekonacie.
na zdjęciach jest wersja się jeszcze nieco syfiąca. (czasami były drobne przekłamania przy zatrzaskiwaniu danych z magistrali ATARI).
ale grała. efektem uboczym był raz na parę sekund jakiś "syf" zatrzaskujący się do SID'a.
Możecie zapytać rzóg'a, on to słyszał jak to grało jeszcze jak pracowaliśmy w Jard - Press S.A.
Do dziś Stryker mi życia nie daje abym to skończył. Jest już prawie gotowe. Pierwsze PCB dostają Stryker i Święty/Zelax.
Święty obiecał przerobić swojego Player'a tak aby grał na sprzętowym Sidzie :D
Panowie ja wiem że to trwa wieki... ale na prawdę mam sporo innych rzeczy do robory. Rodzina, praca itd. Człowiek musi jakoś się urzymać wiec musicie wybaczyć mi że hobby zostawiam na ostatnim miejscu.
Strykera i nie tylko szlag z tego powodu trafia. Sorki... nic nie poradzę :(
Ale dla pocieszenia mogę dodać iż projekt jest w finalnej fazie. Są gotowe już chyba ostateczne PCB. Teraz pora na montaż i uruchomienie.
A wiec jeszcze chwilę.
Seban
atari.area forum » Posty przez seban
Wygenerowano w 0.084 sekund, wykonano 16 zapytań