Stacje/Dopałki/Rozszerzenia
Jak mówiłem, nie jestem elektronikiem ale po poście o nagrzewaniu SID'a skojarzyłem tę procedurę, posiadacze Atari Falcona się w to bawią. I tutaj jedna kwestia, są rzadkie doniesienia o popalonych Falconach ze względu na tą dopałkę, ludzie spekulują, że to ze względu na tanie wykonanie płyty. Commodore też jest tanio zrobiony tak więc trzeba wziąśc pod uwagę tą ewentualność i jakieś testy zrobić czy coś.
Prawdziwie o stabilności rozwiązania będzie można się przekonać po pewnym czasie i w porze letniej kiedy temperatury są wysokie. Chociaż w naszym przypadku to nie jest zbyt wielki problem chyba, że ktoś ma podrasowaną sztukę, za to dla usera Falcona spalenie jego maszyny za ok. 2000-3000zł jest zdecydowanie bardziej bolesne 
Ciężko teraz powiedzieć jak to by się rozwijało. Na pewno część oprogramowania (może i niewielka) już ma obsługę tego urządzenia (manipulacja rejestrem $d030, do przyspieszania gdy działa na c128 w trybie c64).Jacek31 pisze:A tak w ogóle to pytanie dla koderów. Macie wy na tym zamiar tworzyć coś więcej niż DemaNo nie wiem gry, programy użytkowe czy coś w tym stylu. No bo tak defakto w kwestii Dem to chyba każdy emul na PC ma tryb X2.
No oczywistą sprawą, jest że taka dopałka mocno wspomoże tego typu gry/produkcje :
http://noname.c64.org/csdb/release/down ... ?id=102609
http://gb64.com/game.php?id=1289&d=18&h=0
zwłaszcza, że przeróbka polegałaby tylko na dopisaniu przed uruchomieniem gry np inc $d030.
Ale to nie wszystko, jeśli byłaby pełna synchronizacja, to oznacza że liczba cykli w liniach podwoiłaby się, dałoby to może nawet nowe tryby graficzne, może dodatkowego sprite, ale na razie można gdbybać.
No i pewnie częściej w produkcjach, gościłyby sampelki.
Bo pecet to zwykły banan...
No wiem że VIC i tak będzie rządził, ale takie gupiekisiel pisze:dokładnie to wystarczy każdą grę freeznąć geoactionem i zrobić zapis pod monitorem do d030. Oczywiście odczyt z dysku skaszani zabawę.
Co do nowych trybów graficznych pewnie nikt nie czyta ze zrozumieniem, odczyt vica oraz zapis podczas BA będzie powodował spowolnienie/zatrzymanie procka. To nie jest mod vica, za tą kase nie kupisz spartana.
sta $d020 stx $d020
w ile się wykona ? po 4 czy po 2 cykle ? a manipulacja $3fff na ramce ? - to są już namiastki nowego trybu grafiki
no z tym dodatkowym sprite się troche rozpędziłem
Bo pecet to zwykły banan...
Kisielowi chodzi o to że nawet jeżeli przyśpieszymy magistrale, to nie przyśpieszy to w żaden sposób VICa, co zaowocuje tym że:
- przy zapisie trzeba będzie buforować dane za pomocą kolejki FIFO, aby wolniejsze urządzenie zdążyło je odczytać w swoim tempie.
- przy odczycie trzeba wstawić przynajmniej 1 takt zegara, na opóźnienie, aby wolniejsze urządzenie, wystawiło prawidłowo dane.
Ogólnie od strony VICa nowa "szybsza" magistrala musi być asynchroniczna, czyli wykorzystywać sygnał REDY do synchronizacji wolniejszych urządzeń z szybszym CPU.
Skull no.. no..
ten Doom się nawet ładnie prezentuje, choć u mnie na emulu szybkość którą bym uznał za "redy for game" uzyskał jak szybkość ustawiłem sobie na 400%, choć na 200% muszę przyznać też to ładnie chodziło. ogólnie od takich zastosowań to i tak przydałby się wam bardzie wypasiony GEOAction, który potrafił by sprzętowo mnożyć i dzielić (przetwarzanie potokowe bloków na INT, takie prymitywne HT), oraz w locie dekompresować tekstury.
- przy zapisie trzeba będzie buforować dane za pomocą kolejki FIFO, aby wolniejsze urządzenie zdążyło je odczytać w swoim tempie.
- przy odczycie trzeba wstawić przynajmniej 1 takt zegara, na opóźnienie, aby wolniejsze urządzenie, wystawiło prawidłowo dane.
Ogólnie od strony VICa nowa "szybsza" magistrala musi być asynchroniczna, czyli wykorzystywać sygnał REDY do synchronizacji wolniejszych urządzeń z szybszym CPU.
Skull no.. no..
ten Doom się nawet ładnie prezentuje, choć u mnie na emulu szybkość którą bym uznał za "redy for game" uzyskał jak szybkość ustawiłem sobie na 400%, choć na 200% muszę przyznać też to ładnie chodziło. ogólnie od takich zastosowań to i tak przydałby się wam bardzie wypasiony GEOAction, który potrafił by sprzętowo mnożyć i dzielić (przetwarzanie potokowe bloków na INT, takie prymitywne HT), oraz w locie dekompresować tekstury.A szóstego dnia Bóg stworzył człowieka ... Aby mógł się napić.
Tak panie doktorze jest szansa na szympansa. 
Tylko że nie wiem której części mojej wypowiedzi się czepiasz, tej dla skulla ? Więc nie wiem szansa na co ? Wygrać w Lotto czy co ?
Zresztą pożyjemy zobaczymy, jak będziesz miał już schemat. i będzie wiadomo na czym stoimy. Jak będzie to tylko kanapka pod VICa. OK spoko, gorzej jak trzeba będzie coś bardziej w płycie operować. Wtedy pewnie i entuzjazm spadnie.
EDIT.
A już wiem o co ci biega przetwarzanie potokowe. Wykonalne ze sprzętową jednostką mnożącą (sekwensyjną 8x8 bit, w jakimś karcie na EXPort).Nie wnikając w szczegóły budowy takiej jednostki dla nas istotne jest tylko to że po zakończeniu obliczeń może zgłosić przerwanie INT że skończyła i jest gotowa do przyjęcia kolejnej porcji danych. Weźmy np, ten fragment
Y0+(Y-Y0)*COS(A)
z tego wzoru do przekształceń 3D
XR=Y0+(Y-Y0)*COS(A)+(Z-Z0)*SIN(A)
(Obrót w okół osi X).
Teraz załóżmy że przetwarzamy tylko w 8 bitach wiec mamy 8-bitową wartość dla COS, która będzie stała bo obracamy sie o dany kąt A. Teraz chcemy przeliczyć jak najszybciej 256 bajtowa tablice współrzędnych.
Ostrzegam że nie jestem jakimś guru programowanie wiec przykład uproszczę do maksa aby pokazać tylko idę.
Otóż tak cały program to pętla obliczeniowa która ma dodatkowo w sobie warunek If, który np po obliczeniu pierwszych 4 elementów Y0+(Y-Y0) i umieszczeniu ich w tablicy wyników pośrednich inicjuje jednostkę MUL odblokowuje przerwania i wysyła do niej wartość z pierwszej pozycji tablicy wyników pośrednich i COS(A). Teraz po zakończeniu obliczeń, jednostka MUL zgłasza przerwanie i podprogram jego obsługi odczytuje dane z niej i umieszcza gdzie chcemy, sprawdza sobie index tablicy, aby przypadkiem koprocesor nie wyprzedził procesora, i pobiera następne dane do obliczeń. Chodzi o to żeby synchronizować obliczenia w czasie, aby nie doszło do sytuacji że kooprocesor pobierze dane z miejsca w tablicy gdzie CPU jeszcze nie doszło z obliczeniami.
Może opisałem to trochę pokrętnie, ale chyba ci od programowania dostrzegają wzrost mocy obliczeniowej, i fakt przetwarzania dwóch wątków obliczeniowych jednocześnie. No i jednostka mnożąca nie musi być jakimś demonem szybkości, wystarczy klasyczna implementacja na rejestrach przesuwnych i sumatorze, bo i tak ogranicza ns przepustowości magistrali i szybkość samego CPU.
PS. Oczywiście to taka tam idea na temat rozszerzeń i nie należy jej łączyć z pomysłem kiśla, to 2 różne sprawy. Pamiętajmy o tym że to temat ogólny, na temat dopałek i innych pomysłów.
Tylko że nie wiem której części mojej wypowiedzi się czepiasz, tej dla skulla ? Więc nie wiem szansa na co ? Wygrać w Lotto czy co ?Zresztą pożyjemy zobaczymy, jak będziesz miał już schemat. i będzie wiadomo na czym stoimy. Jak będzie to tylko kanapka pod VICa. OK spoko, gorzej jak trzeba będzie coś bardziej w płycie operować. Wtedy pewnie i entuzjazm spadnie.
EDIT.
A już wiem o co ci biega przetwarzanie potokowe. Wykonalne ze sprzętową jednostką mnożącą (sekwensyjną 8x8 bit, w jakimś karcie na EXPort).Nie wnikając w szczegóły budowy takiej jednostki dla nas istotne jest tylko to że po zakończeniu obliczeń może zgłosić przerwanie INT że skończyła i jest gotowa do przyjęcia kolejnej porcji danych. Weźmy np, ten fragment
Y0+(Y-Y0)*COS(A)
z tego wzoru do przekształceń 3D
XR=Y0+(Y-Y0)*COS(A)+(Z-Z0)*SIN(A)
(Obrót w okół osi X).
Teraz załóżmy że przetwarzamy tylko w 8 bitach wiec mamy 8-bitową wartość dla COS, która będzie stała bo obracamy sie o dany kąt A. Teraz chcemy przeliczyć jak najszybciej 256 bajtowa tablice współrzędnych.
Ostrzegam że nie jestem jakimś guru programowanie wiec przykład uproszczę do maksa aby pokazać tylko idę.
Otóż tak cały program to pętla obliczeniowa która ma dodatkowo w sobie warunek If, który np po obliczeniu pierwszych 4 elementów Y0+(Y-Y0) i umieszczeniu ich w tablicy wyników pośrednich inicjuje jednostkę MUL odblokowuje przerwania i wysyła do niej wartość z pierwszej pozycji tablicy wyników pośrednich i COS(A). Teraz po zakończeniu obliczeń, jednostka MUL zgłasza przerwanie i podprogram jego obsługi odczytuje dane z niej i umieszcza gdzie chcemy, sprawdza sobie index tablicy, aby przypadkiem koprocesor nie wyprzedził procesora, i pobiera następne dane do obliczeń. Chodzi o to żeby synchronizować obliczenia w czasie, aby nie doszło do sytuacji że kooprocesor pobierze dane z miejsca w tablicy gdzie CPU jeszcze nie doszło z obliczeniami.
Może opisałem to trochę pokrętnie, ale chyba ci od programowania dostrzegają wzrost mocy obliczeniowej, i fakt przetwarzania dwóch wątków obliczeniowych jednocześnie. No i jednostka mnożąca nie musi być jakimś demonem szybkości, wystarczy klasyczna implementacja na rejestrach przesuwnych i sumatorze, bo i tak ogranicza ns przepustowości magistrali i szybkość samego CPU.
PS. Oczywiście to taka tam idea na temat rozszerzeń i nie należy jej łączyć z pomysłem kiśla, to 2 różne sprawy. Pamiętajmy o tym że to temat ogólny, na temat dopałek i innych pomysłów.
Ostatnio zmieniony 13 maja 2010, 16:34 przez Jacek31, łącznie zmieniany 3 razy.
A szóstego dnia Bóg stworzył człowieka ... Aby mógł się napić.
Ta dyskietka to dodatek do dema "Andropolis", na niej również znajduje się wersja pod c128- prawie dwurotnie szybsza. Odczucia do predkości mam podobne, na 200% już dałoby się grać (wersja na c128 już jest dla mnie grywalna).Jacek31 pisze: Skull no.. no..
Bo pecet to zwykły banan...
To prawda, ale to już zależy od poziomu atrakcyjności - jeśli dodać klika "płaskich" sprites (akurat c64 może sobie na to pozwolić) jak np. w "duke" to niewiele to wpłynie na engine gry.Jacek31 pisze:No tak ale jak byś chciał zrobić grę to musisz jeszcze liczyć zę trochę zasobów pójdzie na przeciwników, sterowanie nimi, interfejs i interakcje.
Bo pecet to zwykły banan...
Oprócz wspomnianego wcześniej Turbo Macro Pro, jest jeszcze X-Ass Fairlightów.bimber pisze:Fenek, pogadaj z Lukiem, walczy z tym tematem od meetingu.fenek pisze: Ktos wie czy korzystając z 1541u można korzystać z jakiegoś turbo/macro-assemblera który wykorzystuje REU ?
Ponoć kopie funkcją TronMon - dodatkowym monitorem dla REU + bakupowaniem grafy i muzy. Na CSDb jest jeszcze Dev kit 3.3 (nie wiem, czy to to samo
)Takibardzodługipodpissetuszczelecobyśmiałchwilkęoddechuaizadumymożeewentualniewkurtegozestraciłeśpółminutyżycianaczytanietekstuoniczym.
Bahbooker pisze:W zasadzie podam Ci pomysł, jest takie coś C64HDD - jak zapewne wiesz jest to zwykły soft do odpalenia na PC z kablem Xe1541. Oczywista trza mieć na to LPT a to już przeszła epoka. I co ważniejsze, nie obsługuje w pełni 1541.
W zasadzie, to jest 1541emu.
Ale ma poroniony kabel. Zebestowo było by,aby działał na USB.
btw. gdzieś tam powstała teoria, że korzystając ze źródeł 1541emu można by tak za 50zl machnąć na atmedze karte z SD....jakby coś na wzór SIO2SD.
Takibardzodługipodpissetuszczelecobyśmiałchwilkęoddechuaizadumymożeewentualniewkurtegozestraciłeśpółminutyżycianaczytanietekstuoniczym.
Ponieważ kisiel zrobił nam parę tematów o wdzięcznych nazwach XXL, a nie chce mi sie ich przeglądać i szukać gdzie, kto, kiedyś zadał pytanie na temat dodatkowych kolorów dla VICa to pisze tu.
Otóż rozszerzenie kolorów to może trochę za wiele powiedziane, bo większość scalaków jakie znalazłem nie przebija palety C64, ale czy zastanawialiście sie kiedyś nad wykorzystaniem jakiego układu TV OSD wpiętego już za VICa jako dodatkowego procesora video ?? oczywiście uzyskanie jakiś dodatkowych efektów wymagało by specyficznego programowania, ale może było by to nawet ciekawe rozwiązanie
Otóż rozszerzenie kolorów to może trochę za wiele powiedziane, bo większość scalaków jakie znalazłem nie przebija palety C64, ale czy zastanawialiście sie kiedyś nad wykorzystaniem jakiego układu TV OSD wpiętego już za VICa jako dodatkowego procesora video ?? oczywiście uzyskanie jakiś dodatkowych efektów wymagało by specyficznego programowania, ale może było by to nawet ciekawe rozwiązanie
A szóstego dnia Bóg stworzył człowieka ... Aby mógł się napić.
Popatrz na architekturę Atari składającą się z dwóch procesorów graficznych.
ANTIC generuje obraz w różnych trybach graficznych, GTIA nakłada na niego kolor i sprite'y. Powstała karta graficzna, która zastępuje GTIA pozwalająca generować bardziej spasiony obraz.
Co do sceny komodorowskiej, to jestem zdecydowanie na nie, powinniśmy się trzymać oryginalnej konfiguracji a nie leczyć kompleksy rozszerzeniami.
ANTIC generuje obraz w różnych trybach graficznych, GTIA nakłada na niego kolor i sprite'y. Powstała karta graficzna, która zastępuje GTIA pozwalająca generować bardziej spasiony obraz.
Co do sceny komodorowskiej, to jestem zdecydowanie na nie, powinniśmy się trzymać oryginalnej konfiguracji a nie leczyć kompleksy rozszerzeniami.