Wiadomość wysłana przez: hobocti77x w 06 Listopada 2014, 20:44
Wiadomość wysłana przez: hobocti77x w 06 Listopada 2014, 21:08
1.wyświetlenie jednego ekranu animacji
2.Zmian banku VIC
3. kolejny obrazek
4. zmian banku RAM 64kb dla VIC
5.kolejny obrazek
6 zmian banku VIc
7. kolejny obrazek
8 zmian banku RAM 64kb dla VIC
i tak 16 razy daje 32 animacje
efekt to coś takiego tylko lepiej
![\"\"](\"http://www.c64power.com/forum/img/smilies/tongue.gif\" "\\"\\"")
http://en.wikipedia.org/wiki/File:Globespin_persec.gif
Wiadomość wysłana przez: Kisiel w 06 Listopada 2014, 21:29
No a tak na poważnie to REU ma max 16MB i to co kolesie zrobili w Ultimate i Kameleonie jest nie zgodne z oryginalnym rozszerzeniem.
Wiadomość wysłana przez: hobocti77x w 06 Listopada 2014, 22:15
Więc i 1 GB w nim niczego nie zmieni
Wiadomość wysłana przez: wegi w 07 Listopada 2014, 00:32
hobocti77x:
REU ma za cienką rurę aby nadążyć przepchnąćPrzez DMA REU za cienko ?
A blu reu i NUFLI animacje to co z DVD leci ?
Może zamiast [M] UFLI myślisz o MUSCU ? tak czy siak to już zrobione było.
3.04
https://www.youtube.com/watch?v=xQ_0Km7jQ-Y
Wiadomość wysłana przez: hobocti77x w 07 Listopada 2014, 09:31
Na http://www.lemon64.com/ w ciągu 15 min. otrzymałem satysfakcjonującą mnie odpowiedz w ciągu 15 min.
Wiadomość wysłana przez: Kisiel w 07 Listopada 2014, 10:14
Znowu zabłysłeś
![\"\"](\"http://www.c64power.com/forum/img/smilies/grin.gif\" "\\"\\"")
Wiadomość wysłana przez: hobocti77x w 07 Listopada 2014, 11:50
Działa fajnie, a czas który REU blokuje CPU aby przeładować dane mam do dyspozycji na kod programu.
Wreszcie jest powód dla którego warto wsadzić całe 16 MB RAM (pamięci operacyjnej ) do c64
Wiadomość wysłana przez: wegi w 07 Listopada 2014, 12:32
hobocti77x:
Działa fajnie, a czas który REU blokuje CPU aby przeładować dane mam do dyspozycji na kod programu.Z czego 200 linii obejmujących obszar ekranu są zajęte przez dedykowany spidkod do wyświetlenia danego obrazka. W pozostałych 92 liniach na dolnym i górnym borderze musisz odtworzyć muzyczkę, potem możesz się wyszaleć.
Jakkolwiek Twoje rozszerzenie znajduje zastosowanie przy takich animacjach. Możesz nagrać filmik i pocisnąć na jutuba.
Co do pytania... MUFLI - jeżeli masz na myśli NUFLI to zdaje się Crossbow wydał do tego edytor.
Wiadomość wysłana przez: hobocti77x w 07 Listopada 2014, 14:52
http://csdb.dk/release/?id=93314
http://csdb.dk/release/?id=100031
Całkiem przyjemny konwerter.
Co do pokazu to raczej wersja robocza i nie nadaje się do publikacji, w każdym razie wiem o co chodzi, a przy okazji wpadłem na ciekawy pomysł, ale o tym na razie cisza.
W każdym razie startuje z projektem 16 MB (albo i więcej)
Wiadomość wysłana przez: Kisiel w 08 Listopada 2014, 00:09
wegi:
Z czego 200 linii obejmujących obszar ekranu są zajęte przez dedykowany spidkod do wyświetlenia danego obrazka. W pozostałych 92 liniach na dolnym i górnym borderze musisz odtworzyć muzyczkę, potem możesz się wyszaleć.gadasz z cieciem o gwiazdach
![\"\"](\"http://www.c64power.com/forum/img/smilies/sad.gif\" "\\"\\"")
16MB ładowane z emulatora stacji na starym PC ... po to aby sobie obejrzeć animkę. 6KB/s :P Kolo nawet nie pomyślał o tym.
Wiadomość wysłana przez: wegi w 08 Listopada 2014, 00:23
wegi:
W pozostałych 92 liniach poprawka 112 linii
http://codebase64.org/doku.php?id=base:visible_area
Kisiel:
po to aby sobie obejrzeć animkę. 6KB/s :P Kolo nawet nie pomyślał o tym.Zakładam, że kolega elektronik i skoro stworzył takie rozszerzenie to znajdzie sposób żeby do niego transferzyć coś.
Wiadomość wysłana przez: Kisiel w 08 Listopada 2014, 00:51
wegi:
Zakładam, będziesz musiał poczekać na to całe życie. Jak dotąd kolo tylko gada.
Wiadomość wysłana przez: wegi w 08 Listopada 2014, 01:01
Kisiel:
Jak dotąd kolo tylko gada.Nie przejmuj się tym bardziej od autora projektu. Wierzę że zrobi.
Wiadomość wysłana przez: Kisiel w 08 Listopada 2014, 01:20
Animacja NUFLI na c64... toż to kurwa world first.
Wiadomość wysłana przez: Kisiel w 08 Listopada 2014, 02:15
World First film z dysku HD/CF
http://www.youtube.com/watch?v=jaQS0tLq8yI
by JAD.
Wiadomość wysłana przez: hobocti77x w 08 Listopada 2014, 10:15
Wiadomość wysłana przez: Kisiel w 08 Listopada 2014, 12:18
Wiadomość wysłana przez: hobocti77x w 11 Listopada 2014, 14:51
Można wówczas zaoszczędzić wiele pamięci i zmiejszyć plik wynikowy.
PS.
Rozwiązałem już sposób sterowania dla 16 MB RAM (podam że aby było tanio użyję 16 MB modułów SIMM 72 pin)
Wiadomość wysłana przez: Kisiel w 11 Listopada 2014, 16:10
PS. przyjmując że jedna klatka animacji na takim rozszerzeniu kosztuje 64kB to masz raptem 256 klatek animacji (16MB). Przy 14 klatkach na sekundę powiedzmy będzie wrażenie ruchu więc animacja będzie trwała 18s. Ponieważ 16MB danych będziesz ładował jakimś sposobem do pamięci, to najszybsze rozwiązanie karta CF / IDE, da max 60kB/s (w C64+) co daje ca. 5-6 minut wczytywania animacji. Dla SD2IEC da to dziesięciokrotnie więcej czasu.
Ludzie będą zachwyceni.
Wiadomość wysłana przez: hobocti77x w 11 Listopada 2014, 19:48
to samo dla pamięci znaków
Wiadomość wysłana przez: Kisiel w 11 Listopada 2014, 21:01
Odpowiedź już dostałeś tylko nie pasuje do teorii jaką forsujesz.
Dużo lepszym rozszerzeniem do animacji jest rozszerzenie Marko Makeli 256K do c64 dlatego że możesz sobie wymienić jeden z czterech banków na dowolny sektor 16kB z puli całej pamięci co do daje realnie dłuższą animację. VIC może widzieć inny bank niż procesor więc speed code może być w bankach np. 0123 a animacje w pozostałych. W przypadku rozszerzenia jakie forsujesz masz tylko sektor 64KB. Dla wielbicieli FAT16 / FAT32 i wielkość clustra nie potrzeba tego tłumaczyć.
Wiadomość wysłana przez: hobocti77x w 11 Listopada 2014, 21:11
Przed chwilą "udowadniałeś" że pamięć na 256 (1024 jeśli już ) ekranów to za mało na animację , a teraz pieprzysz że pamięć 16 ekranów jest lepsza...
Idź ty się lepiej wyspać
Wiadomość wysłana przez: Kisiel w 12 Listopada 2014, 01:07
... idź się chłopie zastanów czy naprawdę wzbudzisz zainteresowanie wynalazkiem który gorzej działa od REU.
Wiadomość wysłana przez: hobocti77x w 13 Listopada 2014, 22:24
http://youtu.be/aJ6QqzlqYA8
Wiadomość wysłana przez: Kisiel w 13 Listopada 2014, 23:30
na moje wygląda na 4.
Wiadomość wysłana przez: hobocti77x w 14 Listopada 2014, 09:50
Kisiel:
Animacja NUFLI na c64... toż to kurwa world first.No i co teraz powiesz...
Wiadomość wysłana przez: comankh w 14 Listopada 2014, 10:05
Wiadomość wysłana przez: hobocti77x w 14 Listopada 2014, 20:59
Może to poprawię w wersji 16 MB.
Wiadomość wysłana przez: Kisiel w 14 Listopada 2014, 21:30
es tut mi lajt to nie world first.
Gratuluje poświęconego czasu, proponuje zrobić lepszą animację na 16MB.
Szczerze, to więcej da się wyciągnąć z DMA i SD.... tylko poco, C64 to nie przeglądarka do filmów wspomaganych sprzętowo. Jak porównasz sobie to co oferuje Ultimate a Ty, to się nie dziw że ludzie wybiorą ten pierwszy sprzęt.
Wiadomość wysłana przez: hobocti77x w 14 Listopada 2014, 23:14
Na pewno jest szybszy od REU ponieważ dane są ładowane bezpośrednio do pamięci i nie potrzeba ich po załadowaniu do RAM przepisywać do dodatkowej pamięci.
Dodatkowo każdy program jest od razu po załadowaniu gotowy do odpalenia bez potrzeby jakiegokolwiek przerzucania przez DMA i temu podobne urządzenia pomiędzy pamięcią operacyjną a dodatkową .
Jednym zdaniem cała pamięć jest pamięcią operacyjną, a nie rodzajem "szybkiej dyskietki" jak REU.
Tyle w temacie
Wiadomość wysłana przez: Kisiel w 14 Listopada 2014, 23:19
Ja widzę różnicę, ludzie widzą różnicę. Dla autora projektu to nie jest problem, to dla mnie też nie.
Mam nadzieję że warto było czekać.
Wiadomość wysłana przez: Skull w 15 Listopada 2014, 07:06
Wiadomość wysłana przez: hobocti77x w 15 Listopada 2014, 10:27
Albo inaczej REU w ultimate do mojego rozszerzenia ?
Moje rozszerzenie nie używa DMA bo w tej formie (REU) niewiele mu daje, co nie znaczy że niemożna go zastosować, od po prostu jeśli ktoś podłączy sobie REU (Ultimate) czy inny wynalazek do mojego będzie miał np. 16 MB w c64 + 16MB w REU razem 32 MB, i może sobie z tym robić co zechce .
Więc jeszcze raz to nie jest rozwiązanie konkurencyjne dla REU tylko zupełnie inne podejście do tematu rozbudowy RAM.
W skrócie ULTIMATE + c64 = ULTIMATE i c64
a ULTIMATE +c64 (z 16MB RAM)= ULTIMATE + (256 * c64) pod jedną klawiaturą
A teraz małe wyliczenie:
0.985000Hz/ 50klatek= 19700 cykli
Z tego 19700 - (200 linii widocznych / 64 cykle dla linii) = 6900 cykli na ramkę
6900 cykli u mnie jest to na program.
Coś sensownego przy 6900 cyklach da się zrobić.
A teraz dla porównania REU:
przy samym REU trzeba w tym czasie przerzucić dane dla ekranu, co np przy trybie hires gdzie tylko bitmapa zajmuje 8000 bajtów daje wielką dupę w temacie animacji całoekranowej i trybach FLI pochodnych
Wiadomość wysłana przez: Kisiel w 15 Listopada 2014, 12:05
Możesz wmówić cieciowi Aniołowi że po włączeniu do prądu c64 bity ułożyły sie w animację.
Podaj czas w jaki załadowałeś animację, czy to było półgodziny czy godzina nie ma znaczenia.
Skull:
e no 16s. to przesada, z tego co kojarzę to jest to ok. minutyTo podaj czas dokładny bo ja opieram się na zeznaniach user'a i mojej wątpliwej pamięci do cyfr.
PS. http://www.youtube.com/watch?v=Htx6-FF-5Cw całkiem dobre.
Wiadomość wysłana przez: wegi w 15 Listopada 2014, 12:30
hobocti77x:
Coś sensownego przy 6900 cyklach da się zrobić. Tak tylko te cykle są w miejscu dolnego i górnego borderu i jedyne co możesz zrobić to wyświetlić sprajty co world firstem nie będzie. Do ekranu odwoływać się nie będziesz bo i tak co ramkę go zmieniasz.
Animację zrobiłeś i dowiodłeś że do tego twoje rozszerzenie jest OK
hobocti77x:
przy samym REU trzeba w tym czasie przerzucić dane dla ekranu, co np przy trybie hires gdzie tylko bitmapa zajmuje 8000 bajtów daje wielką dupę w temacie animacji całoekranowej i trybach FLI pochodnych Nie za bardzo rozumiem skoro z REU daje się zrobić animację NUFLI to czemu nie dałoby się FLI czy hires...
Wiadomość wysłana przez: hobocti77x w 15 Listopada 2014, 12:52
A co będzie jeśli w trakcie wyświetlania ramki w określonej linii przełączę bank dla VIC i już w pewnym obszarze mogę zrobić co mi się podoba. Jednym rozkazem zmieniam wszystkie kształty spritów które mogę kontrolować zawsze w jakimś wycinku ekranu.
Nikt nie powiedział że muszę przełączać cały ekran co ramkę mogę to robić kawałkami i kiedy zechcę.
Na drugie chyba już odpowiedziałem wyliczeniami
Wiadomość wysłana przez: hobocti77x w 15 Listopada 2014, 12:58
zobacz ile rozkazów potrzeba tylko po to aby "zaprogramować" REU aby rozpocząć transfer.
U mnie to jeden rozkaz STA a w REU ?
Wiadomość wysłana przez: Kisiel w 15 Listopada 2014, 13:03
hobocti77x:
PS.zobacz ile rozkazów potrzeba tylko po to aby "zaprogramować" REU aby rozpocząć transfer.
U mnie to jeden rozkaz STA a w REU ?
Uwaga, wypowiedź kodera,
1. pierwsze musisz najpierw wyliczyć wartość dla A, potem jest STA.
2. to prawda że szybciej przeładujesz rejestry , tylko że różnicę widać dopiero w pakerach dla REU przerobionych pod moje rozszerzenie, gdzie przeładowujesz rejestry pod kilka bajtów danych, dla ramki która ma np. 16kB/s czas na sekundę jest bez różnicy dla kodera.
Wiadomość wysłana przez: wegi w 15 Listopada 2014, 13:05
Nic nie będzie zrobisz animację na sprajtach na borderach. Zmiana wszystkich sprajtów w jednej linii nie jest nowym wynalazkiem. Można to uzyskać przez $D018 lub $dd00. Tobie doszła pewnie kolejna możliwość przez podmianę banków extra ramu.
Ciekawsze byłoby jakbyś na tych sprajtach zrobił zooming fraktala jak w uncensored - polecam do obejrzenia.
Pochwalam rozwój projektu i umiejętności panie kolego.
Wiadomość wysłana przez: hobocti77x w 15 Listopada 2014, 14:00
Oczywiście że takie efekty już są, u mnie to wszystko robi się tylko szybciej i łatwiej , a zaoszczędzone cykle w linii może wykorzystam do "pierdzenia" na SID-zie ?
![\"\"](\"http://www.c64power.com/forum/img/smilies/wink.gif\" "\\"\\"")
To dopiero byłby czad
Wiadomość wysłana przez: hobocti77x w 15 Listopada 2014, 14:07
I 16 MB załaduje w 1.5 sek ?
takie :"all in one"
Możliwe to jest
Wiadomość wysłana przez: hobocti77x w 15 Listopada 2014, 14:28
Wiadomość wysłana przez: Skull w 15 Listopada 2014, 15:17
Kisiel:
To podaj czas dokładny bo ja opieram się na zeznaniach user'a i mojej wątpliwej pamięci do cyfr.Sprawdziłem "Blue Reu" 16M - ładowanie nawet 2 minuty
, np. SD2iEC instrukcja copy (tylko komendę się wysyła z ścieżkami) i np. plik d64 kopiuje się ok. 25 sek.
Oczywiście i tak przy standardach komciowych to bardzo szybko, ale nie jest to na pewno w "mgnieniu oka".
Wiadomość wysłana przez: Kisiel w 15 Listopada 2014, 15:34
hobocti77x:
wegiW elektronice jest wiele technologii układów, każda ma swoje właściwości tj. zalety i wady i niemożna tego uogólniać.
Takie uogólnienia może będą jak uda się zrobić używalne nadprzewodniki, a do tego czasu trzeba rozpatrywać różne technologie osobno.
Generalnie układy na krzemie raczej przez podniesienie częstotliwość nie rozgrzeją się same w normalnych warunkach do tmp. 300 C (temp. zniszczenia) , za to z drugiej strony zdolne są do tego np. układy z arsenku galu.
Nadprzewodniki to dobra rzecz, szczególnie jak się nie ma pojęcia o klasycznej fizyce i przewodzeniu.
Kisiel:
A ja mam lepsze pytanie dlaczego:Kisiel:
Pierwszy przykład z brzegu
Texas Instruments MSP430 konsumpcja 100uA/Mhz , to rekordzista w oszczędzaniu energii.
MSP430™
Microcontrollers
Ultra-low power
Battery Life > 20 Years
•<100 μA/MHz
•0.1μA RAM Retention
•<1μA RTC Mode
Przećwiczmy to:
1Mhz => 100uA
2Mhz => 200uA
3Mhz => 300uA
4Mhz => 400uA
.
.
.
akurat go programuje więc był pod ręką da się go kręcić do 16Mhz.
Ale myślę że chłopcy Texas Instruments tak znamiennym konstruktorze z Polski mogą buty czyścić.
Więc może LPC , CORTEX M0, http://www.nxp.com/documents/data_sheet/LPC1102_1104.pdf
system clock = 12 MHz, VDD= 3.3 V => 2 mA
system clock = 50 MHz, VDD= 3.3 V => 7 mA
co stoi całkowicie w sprzeczności z tym:
hobocti77x:
ale dla jednego zmiana częstotliwości z 1 na 8 MHz to będzie różnica kilku procent,
Głupi ludzie piszą te notki dotyczące procesorów.
Nawet 6502 produkowany przez CBM ma napisane zużycie prądu od wartości MHZ. Co oznacza wzrost 1 Mhz na 2 Mhz powoduje wzrost zapotrzebowania na prąd 100% ale zmiana z 7Mhz na 8 nie powoduje wzrostu o kilka dziesiąt procent. W tym przypadku zmiana 1Mhz na 8Mhz powoduje ośmiokrotne większe zużycie prądu czyli 800%
Cały świat zwariował tylko w Polsce są tak inteligentni "producenci"
Pytanie dlaczego technologia z przed 40 lat pokrywa się z technologią z dnia dzisiejszego?
Bo głupi ma zawsze szczęście.
Wiadomość wysłana przez: hobocti77x w 15 Listopada 2014, 15:52
Sprawdziłby się w epoce kamienia łupanego , tam wszystkie narzędzia były z jednego materiału.
Przecież wszędzie siedzą te same krasnoludki
Wiadomość wysłana przez: hobocti77x w 15 Listopada 2014, 15:56
Ciekawie byłoby znaleźć "wypowiedź" w której nie mija się z prawdą
Wiadomość wysłana przez: Kisiel w 15 Listopada 2014, 16:10
Kisiel:
a wracając do dyskusjihobocti77x:
wegi
W elektronice jest wiele technologii układów, każda ma swoje właściwości tj. zalety i wady i niemożna tego uogólniać.
Takie uogólnienia może będą jak uda się zrobić używalne nadprzewodniki, a do tego czasu trzeba rozpatrywać różne technologie osobno.
Generalnie układy na krzemie raczej przez podniesienie częstotliwość nie rozgrzeją się same w normalnych warunkach do tmp. 300 C (temp. zniszczenia) , za to z drugiej strony zdolne są do tego np. układy z arsenku galu.
Nadprzewodniki to dobra rzecz, szczególnie jak się nie ma pojęcia o klasycznej fizyce i przewodzeniu.
Kisiel:
A ja mam lepsze pytanie dlaczego:
Kisiel:
Pierwszy przykład z brzegu
Texas Instruments MSP430 konsumpcja 100uA/Mhz , to rekordzista w oszczędzaniu energii.
MSP430™
Microcontrollers
Ultra-low power
Battery Life > 20 Years
•<100 μA/MHz
•0.1μA RAM Retention
•<1μA RTC Mode
Przećwiczmy to:
1Mhz => 100uA
2Mhz => 200uA
3Mhz => 300uA
4Mhz => 400uA
.
.
.
akurat go programuje więc był pod ręką da się go kręcić do 16Mhz.
Ale myślę że chłopcy Texas Instruments tak znamiennym konstruktorze z Polski mogą buty czyścić.
Więc może LPC , CORTEX M0, http://www.nxp.com/documents/data_sheet/LPC1102_1104.pdf
system clock = 12 MHz, VDD= 3.3 V => 2 mA
system clock = 50 MHz, VDD= 3.3 V => 7 mA
co stoi całkowicie w sprzeczności z tym:
hobocti77x:
ale dla jednego zmiana częstotliwości z 1 na 8 MHz to będzie różnica kilku procent,
Głupi ludzie piszą te notki dotyczące procesorów.
Nawet 6502 produkowany przez CBM ma napisane zużycie prądu od wartości MHZ. Co oznacza wzrost 1 Mhz na 2 Mhz powoduje wzrost zapotrzebowania na prąd 100% ale zmiana z 7Mhz na 8 nie powoduje wzrostu o kilka dziesiąt procent. W tym przypadku zmiana 1Mhz na 8Mhz powoduje ośmiokrotne większe zużycie prądu czyli 800%
Cały świat zwariował tylko w Polsce są tak inteligentni "producenci"
Pytanie dlaczego technologia z przed 40 lat pokrywa się z technologią z dnia dzisiejszego?
Bo głupi ma zawsze szczęście.
czyste liczby nie kłamią , pdf od producentów mówią że pojęcie o działaniu sprzętu bierzesz z nie tego forum co trzeba.
Wiadomość wysłana przez: hobocti77x w 15 Listopada 2014, 17:15
Proponuję ci zamiast kopiuj/wklej zacznij je przepisywać, a może za setnym razem zaczniesz nawet rozumieć ich sens
Wiadomość wysłana przez: Kisiel w 15 Listopada 2014, 18:02
Czekamy wszyscy na wielką animację.
Wiadomość wysłana przez: comankh w 16 Listopada 2014, 01:09
hobocti77x:
Ja tam jestem sprzętowiec, nie scenowiec więc wystarczy mi że działa tak jak chciałem.zuploaduj na csdb, to zobaczymy jaki to worldfirst.
Wiadomość wysłana przez: hobocti77x w 17 Listopada 2014, 07:49
Zrób lepiej
Wiadomość wysłana przez: comankh w 17 Listopada 2014, 13:24
niech to będzie nawet proof-of-concept, myślę że społeczność szybko to zwetyfikuje. jeśli chcesz materiałów do testów/dostarczyć sprzęt do testów - priv, spokojnie zapełnię ci bugtracker na najbliższe pół roku. o ile wogóle planujesz jakiś kit/retail.
Wiadomość wysłana przez: Kisiel w 17 Listopada 2014, 14:16
Może byś zrobił animkę do tej prezentacji..... <3 agny
Wiadomość wysłana przez: comankh w 25 Listopada 2014, 10:45
Wiadomość wysłana przez: wegi w 30 Listopada 2014, 15:40
Kisiel:
<3 agnyKażdy obrazek Astarotha - kosmos <3 <3 <3