Czy te 3 fire maja byc polaczone razem?

Biore.

Otworz zdjecie w jakimkolwiej programie i wybierz zapisz jako, zazwyczaj mozne wtedy wybrac jpg, i ustawic jakosc na 85% (wydaje sie byc optymalna).

Przyroda nie toleruje pustki.
Trzba bylo nie banowac bezrobotnego :D

Napisz w jakim sklepie bedziesz kupowal to cos ci polece.

To na 1 obrazku to nie ma wiekszego sensu i raczej nie zadziala poprawnie.

Na 2 w miare ok, bedziesz mial sygnal od 1,5V do 4,5 - Potzrebujesz az tyle? To bardzo silny sygnal.
Abo napisz co dokladnie chcesz osiagnac i czego oczekuejsz na wyjsciu.

Pomadrze sie troche.

Wynika to z 2 rzeczy.

1. z tego DAC'a prad moze tylko wyplywac.
2. Zasada dzialania opampa
  2.a Zaden prad nie wplywa ani nie wyplywa z/do wejsc opampa
  2.b Opamp tak reguluje napiecie na wyjsciu zeby na obu wejsciach bylo takie same napiecie.

Oczywiscie pomijamy tu niedoskonalosci tak DAC'a jak i Opampa oraz wszelkie uproszczenia. Uklad idealny. Dla ulatwinia przyjmijmy tez rezystor 1k.

Jesli z DAC'a plynie prac powiedzmy 1mA, daje on spadek 1V na rezystorze 1k. oba wejscia opampa musza miec to samo napiecie, a jedno z nich jest podlaczone do masy i nie moze sie zmienic., wiec na wyjsciu musi byc -1V zeby na drugim wejsciu bylo 0V.

Efekt sumaryczny jest taki ze na wyjsciu dostaniemy  takie same napiecie jak w przypadku podlaczenia takiego samego rezystora do masy, ale z preciwnym znakiem. (Dodatkowo mamy wyjscie o niskiej impedancji, a opamp widzi swoje wyjscie jako podlaczone do zerowej impedancji)

To tak w skrocie.

Nie wiem co autor mial na mysli ale ja bym zrobil to tak:

Pozatym miejsce tego dac'a jest w muzeum techniki. Niech audiofile sie nim bawia.

Ojtam nie ma .. prawie jest ale zabraklo odrobiny checi zeby do konca odpalic.

Martwi mnie to ostatnie zdanie .. Ja bym sie raczej skupil na implementacji celowej dla VBXE.
W moim pytaniu chodzi bardziej o to czy rdzen zostanie opubikowany w rodzaju jakiegos OpenSource.

Wracajac do samych algorytmow kompresji to sa one raczej FPGA unfriendly. I zostaly zaprojektowane go streamowego przetwazania danych i ciezko bedzie w tym wypadku wykorzystac zalety FPGA. Dodatkowo niezdefiniowany rozmiar sprita jest dodatkowym utrudnieniem. Jak ma byc latwe do uzycia to musi byc proste. Zdefiniowany rozmiar, albo ... kompilator do rdzenia ktory przygotuje bitstream do FPGA pod konkretne wymagania rozmiaru.

Sama dekompresja danych dosc powaznie zwieksza zapotrzebowanie na przepustowosc pamieci - jesli ma to byc dekompresja *inplace*.
Jeden strumien na dane wejsciowe(tokeny), prawdopodobnie drugi na dane nazwijmy je losowe(literale) i trzeci na zdekompresowane dane.

Dlatego bylo moje pytanie o cel kompresji.
Zeby zoptymalizowac proces, mozna by wydzielic staly bufor na sprity(staly bufor => staly rozmiar) i w chwili gdy mamy wolne pasmo w strumieniu z Ram (potrzebny tu bedzie arbiter) dekompresowac dane do sprajtow nastepnej ramki. A potem juz prosty blitter zrobi swoje.

Ot takie przemyslenia.
Mam ich nieco wiecej, ale nie bede wszystkich na raz pisal ;)

Kto zna dobrze działającą poważną aplikację w javie niech pierwszy naciśnie Return. (A może Reset miało być?)

Cos takiego ? https://www.digikey.dk/en/products/filt … 8YvAKmTJQA