11.03.2020 18:51
[#62]
Re: Akiko 32
@swinkamor12, post #55
Przepraszam, ale albo mówisz o czymś całkowicie innym niż ja i zbłądziłeś, albo poziom twojej wiedzy z zakresu podstaw idei adresowania pamięci jest rażąco zdeformowany lub nie istnieje.
Akiko ma zaimplementowany obszar pamięci, który przechowuje i konwertuje 32 piksele, jakkolwiek byś nie patrzył, 32 piksele razy 6 bitplanów, to 192 bitów. Chyba, że znasz jakiś sposób, aby dwa bity zmieściły się w jednym (to że bit ma dwa stany, nie przejdzie).
Szerokość szyny nie ma żadnego związku z ilością pamięci, ani nie zmienia mapy pamięci, w dodatku wygląda na to, że o tym nie wiesz, że procesor nie ma bladego pojęcia na jakiej szerokości szynie siedzi, jego interfejs odpowiada za dostarczenie lub zapisanie żądanej informacji, instrukcja zapisu odczytu/zapisu 32-bitowej wartości na 68000 sprawi, że interfejs procesora wykona dwa cykle zapisu/odczytu sprzętowo, jest to operacja całkowicie przeźroczysta dla wykonywanego programu.
Nie jestem pewien, ale mam wrażenie jakbyś mówił, że na szynie 32-bit pod adres $b80038 zapisuje się pierwsze 32-bity danych, a w $b80039 kolejne i tak jeszcze z 6 razy, aż do $b8003e.
Ostatnia aktualizacja: 11.03.2020 19:03:18 przez sanjyuubi
Akiko ma zaimplementowany obszar pamięci, który przechowuje i konwertuje 32 piksele, jakkolwiek byś nie patrzył, 32 piksele razy 6 bitplanów, to 192 bitów. Chyba, że znasz jakiś sposób, aby dwa bity zmieściły się w jednym (to że bit ma dwa stany, nie przejdzie).
Szerokość szyny nie ma żadnego związku z ilością pamięci, ani nie zmienia mapy pamięci, w dodatku wygląda na to, że o tym nie wiesz, że procesor nie ma bladego pojęcia na jakiej szerokości szynie siedzi, jego interfejs odpowiada za dostarczenie lub zapisanie żądanej informacji, instrukcja zapisu odczytu/zapisu 32-bitowej wartości na 68000 sprawi, że interfejs procesora wykona dwa cykle zapisu/odczytu sprzętowo, jest to operacja całkowicie przeźroczysta dla wykonywanego programu.
Nie jestem pewien, ale mam wrażenie jakbyś mówił, że na szynie 32-bit pod adres $b80038 zapisuje się pierwsze 32-bity danych, a w $b80039 kolejne i tak jeszcze z 6 razy, aż do $b8003e.
Ostatnia aktualizacja: 11.03.2020 19:03:18 przez sanjyuubi
11.03.2020 18:57
[#63]
Re: Akiko 32
@teh_KaiN, post #58
To by zależało gdzie by to sprzętowe C2P się znalazło, sam 68000 z ewentualnym fastem włożony w przystawkę - sprzęt wygrywa z algorytmem, karta turbo włożona w przystawkę - algorytm wygrywa z sprzętem przy odpowiedniej prędkości akceleratora, C2P zintegrowane z akceleratorem i dostępem do rejestrów bez stanów oczekiwania - sprzęt znów wygrywa.
A czy to ma sens, to chyba zależy jak intensywnie jest C2P używane. Ktoś napisał, że system zaczyna używać sprzętowego C2P, jeśli go wykryje, czy to w jakiś sposób można odczuć w WB?
Ostatnia aktualizacja: 11.03.2020 18:58:04 przez sanjyuubi
A czy to ma sens, to chyba zależy jak intensywnie jest C2P używane. Ktoś napisał, że system zaczyna używać sprzętowego C2P, jeśli go wykryje, czy to w jakiś sposób można odczuć w WB?
Ostatnia aktualizacja: 11.03.2020 18:58:04 przez sanjyuubi
11.03.2020 20:48
[#64]
Re: Akiko 32
@sanjyuubi, post #62
Widzę że udziela ci się negatywna atmosfera związana z klasykiem.
Oryginalne akiko od c= przerabia po 32 piksele.
Nowe akiko w cpld fpga czy czym tam innym nie musi tak działać.
Można obciąć połowę i przerabiać po 16 pikseli.
I tak prawie cały soft który korzysta z akiko korzysta z os.
Można zrobić inaczej taniej.
Oryginalne akiko od c= przerabia po 32 piksele.
Nowe akiko w cpld fpga czy czym tam innym nie musi tak działać.
Można obciąć połowę i przerabiać po 16 pikseli.
I tak prawie cały soft który korzysta z akiko korzysta z os.
Można zrobić inaczej taniej.
11.03.2020 21:53
[#65]
Re: Akiko 32
@swinkamor12, post #64
Atmosfera nie ma nic z tym wspólnego, ani klasyk, raczej to, że nie piszesz jasno i spójnie, ja z twojej gadaniny zrozumiałem tylko to, że obcinać rejestry do 16-bit, bo w maszynach OCS jest dostęp 16-bitowy, sugerując, że to właśnie jej szerokość ma tutaj jakieś znaczenie, kiedy ma wpływ kompletnie zerowy. Na pewno nie tylko ja nie zrozumiałem o co tobie chodzi.
Dlatego nie można obcinać, bo soft spodziewa się 32 rejestrów, co widać chociażby w poście #56, kiedy system testuje konwerter i wypełnia wszystkie 32 bajty. Akiko jest już samo w sobie egzotyczne, po co tworzyć swój własny konwerter, który będzie użyteczny tylko wtedy, gdy sam coś na to napiszesz i czemu ma być ograniczony do OCS? Nie lepiej, byś mógł uruchomić coś od strzała?
A zarazem bardziej bezużytecznie za 30zł mniej.
Ostatnia aktualizacja: 11.03.2020 21:55:35 przez sanjyuubi
I tak prawie cały soft który korzysta z akiko korzysta z os
Dlatego nie można obcinać, bo soft spodziewa się 32 rejestrów, co widać chociażby w poście #56, kiedy system testuje konwerter i wypełnia wszystkie 32 bajty. Akiko jest już samo w sobie egzotyczne, po co tworzyć swój własny konwerter, który będzie użyteczny tylko wtedy, gdy sam coś na to napiszesz i czemu ma być ograniczony do OCS? Nie lepiej, byś mógł uruchomić coś od strzała?
Można zrobić inaczej taniej.
A zarazem bardziej bezużytecznie za 30zł mniej.
Ostatnia aktualizacja: 11.03.2020 21:55:35 przez sanjyuubi
12.03.2020 05:04
[#66]
Re: Akiko 32
@sanjyuubi, post #65
Piszę jasno i spójnie. Soft korzysta z akiko poprzez os.
Dlatego można zrobić taniej 16 bit zamiast 32 bit.
Wszystko pójdzie od strzału wystarczy napisać patch na os - mogę zrobić żaden problem.
Ale oczywiście 30 PLN nie warto oszczędzać. 32 bit też jest ok.
Po co własny konwerter? Po to żeby grafika w klasyku wreszcie nadawała się do użytku.
Dlatego można zrobić taniej 16 bit zamiast 32 bit.
Wszystko pójdzie od strzału wystarczy napisać patch na os - mogę zrobić żaden problem.
Ale oczywiście 30 PLN nie warto oszczędzać. 32 bit też jest ok.
Po co własny konwerter? Po to żeby grafika w klasyku wreszcie nadawała się do użytku.
12.03.2020 08:54
[#67]
Re: Akiko 32
@sanjyuubi, post #65
Tu jest jeszcze troszkę więcej dosców.
Też na początku byłem zdania żeby na OCS obciąć Akiko, bo po co komu 8-bit. Ale kompatybilność jest najlepszym argumentem. Zwłaszcza że i tak 6- czy 5-bitowe piksele będą trzymane przez programy w bajtach więc i tak trzeba pisać używając akikowej formy. A to czy konwertujesz używając 16 czy 32 pikseli? Jeden ciul jak i tak masz ich paręset w linii. Obowiązku czytania górnych bitplane'ów nie ma więc i tak na tym OCS zaoszczędzi ze swoją ograniczoną paletą.
Można się zastanawiać, czy nie przydałby się tryb gdzie wpisujemy np. 16 pikseli chunky a dostajemy 32 planar w formie AABBCCDD... Takie sprzętowe przyspieszenie trybów z mniejszą rozdzielczością. Ale tu trzeba by wprowadzić licznik ile faktycznie było write'ów i najlepiej jeszcze jeden rejestr, do którego write triggeruje konwersję tu i teraz, albo oddzielną przestrzeń adresową na taką maszynkę. Strasznie skomplikowane, chyba nie ma co póki co szaleć.
A co do softu który z neo-akiko skorzysta to... myślę że Vergeworld by dostał kopa. ;)
Też na początku byłem zdania żeby na OCS obciąć Akiko, bo po co komu 8-bit. Ale kompatybilność jest najlepszym argumentem. Zwłaszcza że i tak 6- czy 5-bitowe piksele będą trzymane przez programy w bajtach więc i tak trzeba pisać używając akikowej formy. A to czy konwertujesz używając 16 czy 32 pikseli? Jeden ciul jak i tak masz ich paręset w linii. Obowiązku czytania górnych bitplane'ów nie ma więc i tak na tym OCS zaoszczędzi ze swoją ograniczoną paletą.
Można się zastanawiać, czy nie przydałby się tryb gdzie wpisujemy np. 16 pikseli chunky a dostajemy 32 planar w formie AABBCCDD... Takie sprzętowe przyspieszenie trybów z mniejszą rozdzielczością. Ale tu trzeba by wprowadzić licznik ile faktycznie było write'ów i najlepiej jeszcze jeden rejestr, do którego write triggeruje konwersję tu i teraz, albo oddzielną przestrzeń adresową na taką maszynkę. Strasznie skomplikowane, chyba nie ma co póki co szaleć.
A co do softu który z neo-akiko skorzysta to... myślę że Vergeworld by dostał kopa. ;)
12.03.2020 18:43
[#69]
Re: Akiko 32
@teh_KaiN, post #67
Programy mogą trzymać dane w bajtach, ale niekoniecznie rejestr, do którego zapisujesz, w OCS dwa najstarsze bity mogą być po prostu ignorowane przy zapisie.
Sygnał wyzwalający konwersję jest niepotrzebny, ponieważ nie są dokonywane tu żadne obliczenia, po prostu bitmapa wejściowa jest przemapowywana na sztywno na wyjście, tak jakbyś podłączył się pod poszczególne bity pamięci przewodami i podłączył je na wyjście tak, by formowały to co chcesz uzyskać. Zawartość rejestrów wyjściowych będzie się zmieniać automatycznie przy każdej zmianie rejestrów wejściowych.
Chodzi Ci o automatyczne podwojenie pikseli w poziomie? Funkcji można dodawać bez końca i stworzyć coś w rodzaju koprocesora w FPGA, póki co, to sam C2P leży na razie w sferze testu hobbystycznego i tam może też w ostateczności pozostać.
Ostatnia aktualizacja: 12.03.2020 18:51:09 przez sanjyuubi
Sygnał wyzwalający konwersję jest niepotrzebny, ponieważ nie są dokonywane tu żadne obliczenia, po prostu bitmapa wejściowa jest przemapowywana na sztywno na wyjście, tak jakbyś podłączył się pod poszczególne bity pamięci przewodami i podłączył je na wyjście tak, by formowały to co chcesz uzyskać. Zawartość rejestrów wyjściowych będzie się zmieniać automatycznie przy każdej zmianie rejestrów wejściowych.
AABBCCDD
Chodzi Ci o automatyczne podwojenie pikseli w poziomie? Funkcji można dodawać bez końca i stworzyć coś w rodzaju koprocesora w FPGA, póki co, to sam C2P leży na razie w sferze testu hobbystycznego i tam może też w ostateczności pozostać.
Ostatnia aktualizacja: 12.03.2020 18:51:09 przez sanjyuubi
12.03.2020 22:11
[#71]
Re: Akiko 32
@lukzer, post #70
FW jest bardzo krótkie, sprzęt nie jest problemem, jednak sam w sobie jest nieopłacalny, bo trzeba użyć CPLD z 288 makrocelami za 70zł i on cały praktycznie zostaje zużyty na C2P, przez co nie wepchniesz do niego już żadnego projektu (może jakiś RAM prosty jeszcze tak). CPLD 512 makroceli kosztuje krocie, a FPGA istnieją tańsze, jednak nie tolerują 5V i trzeba je łączyć z buforami, ewentualnie innymi CPLD, potrzeba także pamięci konfiguracyjnej, która też kosztuje. Ponoć do takiego XC3S200 można dać rezystory 300ohm i wtedy diody na wejściach będą bezpieczne, ktoś ma jakieś doświadczenie w tej dziedzinie? Spartan II nie jest już obsługiwany w IDE 14.7, trochę szkoda.
Zrobić sobie prototyp na XC95288XL do zabawy nie jest pozbawione sensu, ale mało kto chciałby na taki bajer wydawać ponad 100zł, więc ma to sens tylko wtedy, gdy można to upchnąć przy okazji do jakiegoś projektu, A1208 by musiało zdrożeć o około 60zł, by można było dodać sobie sprzętowe C2P, a więc jako samo rozszerzenie pamięci, stałoby się trochę mało atrakcyjne cenowo.
Ostatnia aktualizacja: 12.03.2020 22:12:07 przez sanjyuubi
Zrobić sobie prototyp na XC95288XL do zabawy nie jest pozbawione sensu, ale mało kto chciałby na taki bajer wydawać ponad 100zł, więc ma to sens tylko wtedy, gdy można to upchnąć przy okazji do jakiegoś projektu, A1208 by musiało zdrożeć o około 60zł, by można było dodać sobie sprzętowe C2P, a więc jako samo rozszerzenie pamięci, stałoby się trochę mało atrakcyjne cenowo.
Ostatnia aktualizacja: 12.03.2020 22:12:07 przez sanjyuubi
13.03.2020 23:01
[#80]
Re: Akiko 32
@lukzer, post #78
AKIKO jest w chipsecie, a jak chwilę się zastanowisz, co robi karta turbo, gdy wykonuje cykle dostępu do Amigi, to wszystko stanie się jasne.
To wyjaśnia także, dlaczego programowe blity fblit'em są szybsze niż blitterem przy szybkich procesorach.
Ostatnia aktualizacja: 13.03.2020 23:09:41 przez sanjyuubi
To wyjaśnia także, dlaczego programowe blity fblit'em są szybsze niż blitterem przy szybkich procesorach.
Ostatnia aktualizacja: 13.03.2020 23:09:41 przez sanjyuubi
13.03.2020 23:08
[#81]
Re: Akiko 32
@teh_KaiN, post #72
Do konwersji napięć myślałem nad układem ST2378, tylko zastanawiam się, czy sprawdzi się w Amidze, czy będzie generował stabilne sygnały bez zakłóceń.
Ten machxo2 wygląda fajnie, szkoda, że słabo z dostępnością w Polsce (pffff), w TME jest tylko jeden model na stanie za 60zł, którego pojemność nic mi nie mówi. Chciałem ściągnąć Lattice Diamond, by skompilować jakiś wsad do karty turbo i zobaczyć tak statystycznie jak ma się stosunek makroceli z XC z LUT'ami w machxo2 po skompilowaniu tego samego wsadu. Widzę, że jednak chyba każda firma produkująca programowalne układy logiczne, robi wszystko, abyś nie ściągnął darmowej wersji ich oprogramowania. Raz, że musisz się zarejestrować i podać swoje dane osobowe, a także co będziesz robił z ichoprogramowaniem jakbyś się wprowadzał do miasta i zgłaszał milicji swoją obecność, dwa, trzeba generować darmową licencję, po co to? Przez takie zabiegi walczysz czasem kilka dni z zdobyciem i uruchomieniem darmowego programu jakbyś chciał zdobyć komercyjny produkt za dużą kasę, dobrze, że do urzędu skarbowego nie muszę zgłaszać darowizny(?). Zarejestrowałem się, a link aktywacyjny nie przyszedł, opcja "resend" nie istnieje, super firma, a właściwie to grupa firm.
Ostatnia aktualizacja: 13.03.2020 23:19:26 przez sanjyuubi
Ten machxo2 wygląda fajnie, szkoda, że słabo z dostępnością w Polsce (pffff), w TME jest tylko jeden model na stanie za 60zł, którego pojemność nic mi nie mówi. Chciałem ściągnąć Lattice Diamond, by skompilować jakiś wsad do karty turbo i zobaczyć tak statystycznie jak ma się stosunek makroceli z XC z LUT'ami w machxo2 po skompilowaniu tego samego wsadu. Widzę, że jednak chyba każda firma produkująca programowalne układy logiczne, robi wszystko, abyś nie ściągnął darmowej wersji ich oprogramowania. Raz, że musisz się zarejestrować i podać swoje dane osobowe, a także co będziesz robił z ichoprogramowaniem jakbyś się wprowadzał do miasta i zgłaszał milicji swoją obecność, dwa, trzeba generować darmową licencję, po co to? Przez takie zabiegi walczysz czasem kilka dni z zdobyciem i uruchomieniem darmowego programu jakbyś chciał zdobyć komercyjny produkt za dużą kasę, dobrze, że do urzędu skarbowego nie muszę zgłaszać darowizny(?). Zarejestrowałem się, a link aktywacyjny nie przyszedł, opcja "resend" nie istnieje, super firma, a właściwie to grupa firm.
Ostatnia aktualizacja: 13.03.2020 23:19:26 przez sanjyuubi
14.03.2020 05:59
[#83]
Re: Akiko 32
@] SKOLMAN_MWS ˇ agrEssOr [, post #82
No ładnie, ładnie. 
Jednak AKIKO to jest power. 
Jeśli kogoś interesuje konwersja za pomocą CPU zapraszam do zapoznania się z moją gotową procedurą. Wkleja dowolny dosunięty do 16 pikseli odcinek bitmapy:
http://coreprogramming.pl/Kod/ShowCode.php?file=WritePixelLine.s
Ostatnia aktualizacja: 14.03.2020 06:05:38 przez Hexmage960
Jednak AKIKO to jest power. Jeśli kogoś interesuje konwersja za pomocą CPU zapraszam do zapoznania się z moją gotową procedurą. Wkleja dowolny dosunięty do 16 pikseli odcinek bitmapy:
http://coreprogramming.pl/Kod/ShowCode.php?file=WritePixelLine.s
Ostatnia aktualizacja: 14.03.2020 06:05:38 przez Hexmage960
14.03.2020 06:18
[#84]
Re: Akiko 32
@Krashan, post #79
Ok .. łapie że Akiko jest po stronie chipsetu Amigi i aby Ami "wstała" musze dopasowac cykle dla mojej karty ..btw to mam opanowane z 030.. 040FE .. pytanie brzmi .. czy teoretyczne Akiko w CPLD bedzie działać po stronie szybkiego CPU ? Czy aby dzialalo musi byc po stronie chipsetu z wszystkimi WS .. ? Kolega Gunnar pisze bardzo ciekawe rzeczy o nie optymalnym interfejsie kart turbo .. fajnie sie mówi o tym gdzie mamy cały chipset w FPGA i możemy go modyfikować..jestem ciekaw czy Vampist ma taki "idealny" bus interface ..
Ostatnia aktualizacja: 14.03.2020 06:28:02 przez lukzer
Ostatnia aktualizacja: 14.03.2020 06:28:02 przez lukzer
14.03.2020 06:32
[#85]
Re: Akiko 32
@lukzer, post #84
A ja mam takie pytanie do znawców tematu projektowania Turbo. Czy bardzo trudno byłoby zrobić taką kartę opartą na jakimś tanim procesorze arm którego by można było zaprogramować jak odpowiednika załóżmy 68030 w trybie JIT ( co się na zasadzie podobnej do emulacji w WinUAE ) i do tego załóżmy 1 GB ram?
Przykładowa nazwa symulowanego procesora 68HC030Pro+
Przykładowa nazwa symulowanego procesora 68HC030Pro+
14.03.2020 07:32
[#87]
Re: Akiko 32
@Aryman33, post #85
Masz odpowiedni wątek na forum, żeby było "łatwo" to musisz mieć wyciągnięty równoległy interfejs do pamięci akceptujący to jak amiga jest wolna. ARMowe SoC których jest teraz na pęczki, mają imponujące parametry i wyposażenie oraz kosztują względnie niewiele niestety nie posiadają żadnego interfejsu, który można by sprząc z amigą. Nawet PCI-E ma swoje ograniczenia, tutaj największą przeszkodą byłyby dość duże opóźnienia (kilkadziesiąt - kilkaset cykli zegarowych PCIE czyli setki ns) oraz konieczność podwójnego obudowywania emulacji - od strony amigi - sprzętowa generacja potrzebnych sygnałów, utrzymywanie timingów i mapowanie amigi do przestrzeni pcie; od strony SoC wyciąganie rozkazów 68k z pcie, przetwarzanie na emulatorze i wysyłanie do pcie wyników. Jak powiedział Roy z IT Crowd widząc zaśmiecony adsami i crapware pulpit Jen - gdyby to była istota ludzka strzeliłbym jej prosto w twarz.
14.03.2020 10:49
[#90]
Re: Akiko 32
@lukzer, post #84
Pytanie, które należy zadać, to czy jakiś szaleniec setował copperem rejestry akiko by mieć namiastkę transferu DMA, o ile w ogóle to jest do zrobienia. A nawet jeśli to potem co, trzeba by przerwanie wołać by te dane wyciągnąć, chyba że copperem blitter setupować żeby blitował z rejestrów akiko do bufora ramki w chipie. Jakie są szanse że ktoś robił coś tak szalonego? Jeśli olejemy taki przypadek zastosowania (jak mniemam bardzo wolny) to akiko mogłoby spokojnie pracować z prędkością FASTu zachowując pełną kompatybilność.
Ostatnia aktualizacja: 14.03.2020 10:50:37 przez teh_KaiN
Ostatnia aktualizacja: 14.03.2020 10:50:37 przez teh_KaiN