jak tak dalej pójdzie... i kibole w takich strojach pojadą i zrobią jakąś zadymę... to potem jak przyjedziemy do ornety to lokalna polkicja nas z miejsca wsadzi jak zobaczy kogoś w koszulce/czapce ze znaczkiem ATARI :) nie ważne że nic nikomu taki prawdziwy atarowiec nie zrobi :) wystarczy że ma znaczek :)

Seban

GAL żadnych to chyba tam nie ma... ale to tym bardziej obrazuje jak potężne są dziś struktury FPGA i co można w nich zmieścić ;) Myślę iż całą atarka wszła by jednego większego FPGA bez problemu :)

dokładnie jest tylko dźwięk... i w dodatku trzeba by sprawdzić czy dobrze zaimplementowany :) znaczy porównać z oryginalnym pokeyem :) Ale na początek dobre i to :) Zawsze to jakiś punkt początkowy do dalszych prac.. a i wielece pomocny działający przykład... dobre pole do nauki :)

Hi!

Zaraz... zaraz... czy mam rozumieć że ktoś zrobił pokeya w HDLu??? możesz zapodać linka?

no fajne.... ale montowane i jeden kanał ;) ... miker zapodaje w czasie rzeczywistym i multipleksuje kanały :D

Seban

Hi!

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

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 Ś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!

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!

110V? to może masz także wersje NTSC?

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