Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
FujiNET firmware v1.3.0 Nowa wersja oprogramowania do interfejsu sieciowego FujiNET. Tym razem z obsługą TCP!
hatari 2.5.0 Od dwóch dni dostępna jest najnowsza (2.5.0) wersja Hatari.
Grawitacja 2024 Czas na kolejną edycję 8 bitowego GameJamu.
Tenebra na Atari ST/STE Wersja gry na duże atari.
Wyniki FujiCup 2023 Wyniki konkursu FujiCup na najlepszą grę dla 8-bit Atari w 2023 roku zostały ogłoszone!
Strony Poprzednia 1 2 3 4 5 6 … 9 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
Ja tylko w kwestii formalnej (interesująca dyskusja :) ) bo mi się rzuciło w oczy w którejś wypowiedzi te 1.79MHz. A to nie jest tak, ze atarki przeznaczone dla systemu PAL chodzą z zegarem 2MHz, a 1.79 mają wersje amerykańskie?
Jak powstanie ta dopałka dla sprite'ów (bo tego najbardziej mi brakuje) to chętnie wykorzystam to w jakiejś grze:)
Jedyne co mnie martwi to to, że to będzie dla trybu graficznego czyli tylko 4 kolory będą. A 5-ty kolor w trybie znakowym sporo daje jednak...
Ale gdyby taka dopałka od razu mogła też podkładać PMG pod sprite'y żeby one były kolorowe to jakoś bym to przeżył:P
Ja tylko w kwestii formalnej (interesująca dyskusja :) ) bo mi się rzuciło w oczy w którejś wypowiedzi te 1.79MHz. A to nie jest tak, ze atarki przeznaczone dla systemu PAL chodzą z zegarem 2MHz, a 1.79 mają wersje amerykańskie?
http://atariki.krap.pl/index.php/NTSC_vs_PAL
Aktualizacja
Jedyne co mnie martwi to to, że to będzie dla trybu graficznego czyli tylko 4 kolory będą. A 5-ty kolor w trybie znakowym sporo daje jednak...
Nic nie stoi na przeszkodzie, aby wykorzystać tryb znakowy. Ograniczanie zasobu funkcji na poziomie układu nie ma w tym przypadku sensu. Można napisać właśny silnik renderujący sprite'y w trybie znakowym i umieścić go po stronie Weroniki.
Ale gdyby taka dopałka od razu mogła też podkładać PMG pod sprite'y żeby one były kolorowe to jakoś bym to przeżył:P
Teoretycznie, nic nie stoi na przeszkodzie, aby tak uczynić.
Ostatnio edytowany przez Marek Konopka (2009-03-29 15:37:24)
Candle, poczekamy - zobaczymy.
Zenon i tak to zrobi :) Przynajmniej do etapu prototypu, zeby sprzadzic "czy to da sie".
Moze ktos cos uzytecznego potem z tego wyciągnie.
o tu jest czip 'za 5 zl' http://www.youtube.com/watch?v=sNCqrylNY-0&feature=related oprocz generowania efektow tworzy obraz i dzwiek.
wracajac do tematu, weronika jest powrotem do korzeni ;-) przyklad - automaty atari (m.a.m.e.), nie nalezy na nia patrzec jak na rozszerzenie (nikt tego na stale do kompa nie wlozy) ma to byc tylko jakby dopalacz dla konkretnej gry znajdujacej sie na tym karcie, taka gra ma dzialac na zwyklym nierozszerzonym atari. masa zastosowan oprcz tego co wczesniej mowil vega przypomnialo mi sie czym sie bawilem jakis czas temu ... tu jest http://atari.pl/sky.rar przyklad zastosowania drugiego procesora odpowiedzalnego za znieksztalcenia obrazu. podobnie mogla by sie zachowac weronika - to tylko przyklad - wystarczy napisac dla drugiego procesora w jaki sposob ma wyswietlac dane przygotowane przez glowny procesor (zakladamy ze obydwa maja podobna moc obliczeniowa).
Wnoszac z samej ilosci wpisow w tym wątku, zainteresowanie jest i projekt zapowiada się miodnie.
Ja jestem wielkim jego fanem, bo chodzi mi to po głowie od dawna, tylko umiejętności brakło.
Właśnie znalalzlem wątek sprzed 4 (!) lat, w którym dyskutowaliśmy podobny pomysl:
http://atariarea.krap.pl/forum/viewtopic.php?id=2652
Zenon do boju!
Zenon, ja doskonale rozumiem że tworzysz teraz rzeczy Wielkie, ale błagam :) odpowiedz na GG lub moje maile na priv co z moją atarką z IDEa którą przesłał do Ciebie Piguła do ostatecznej diagnozy. Chciałbym choć wiedzieć czy moje maile docierają i kiedy mniej więcej mógł byś do niej zajrzeć. Nie chcę Cię odciągać od Weroniki ale daj proszę jakikolwiek znak że jest szansa :)
no to teraz pojade ;-) odrazu mowie, ze nie mam pojecia czy jest to mozliwe ale pospekulowac zawsze mozna.
1. czy mozna zrealizowac dostep do pamieci przez jeden i drugi procesor w taki sposob w jaki pobieraja dane czipy graficzne z innych 8bit platform (przeciwfaza?) ?
2. czy jest mozliwa taka konstrukcja kardrydza, zeby drugi proc mogl zapisywac rejestry sprzetowe atari?
2. czy jest mozliwa taka konstrukcja kardrydza, zeby drugi proc mogl zapisywac rejestry sprzetowe atari?
Lepszy cwaniak, co? ;)
Zgaduje: wymyśliłeś, ze procek na cartridgu mogłby np... liczyc bardzo precyzyjnie w ktorym momencie zmienic rejestry kolorków? :D
Wczoraj sie nad tym zastanawialem, ale niestety cart ma dostep tylko do konkretnych 16kB pamieci + strona $D5xx. I na pewno do niczego wiecej.
uC z cartridga moglby jednynie zmieniac jakies rejestry na stronie $D5xx w odpowiednim momencie. Ale czy to Ci cos da?
Taki oftop: czy dostępne u WD 6502 idą na 14MHz?
http://www.westerndesigncenter.com/wdc/w65c02s-chip.cfm
Features of the W65C02S
8?bit data bus
16?bit Address Bus 65Kbyte Memory and IO Space
69 Variable Length Instructions
16 Addressing Modes
1.8?5V Operating Voltage
14MHz Operating Bus Speed
Fully Static for Power and Radiation Management
Verilog RTL Core Available for FPGA Development
No przecież jest napisane, że idą. Tylko że to jest 65C02, a nie 6502, więc jeśli już zmieniać procesor, to chyba lepiej na 65C816? Zgodność z 6502 nawet deko większa, a i możliwości jakby szersze.
Rozważania teoretyczne...
Zamiast drugiego procesora w module WERONIKA, można wmontować gniazdo i podłączyć taśmą do gniazda cartridge'a drugiego komputera. Drugi komputer, to przecież drugi procesor. Buforem między komputerami będzie przełączana pamięć na zasadzie opisanej w projekcie. Chyba mi odbiło.
Ostatnio edytowany przez Zenon/Dial (2009-03-30 19:53:03)
klaster atari?
no coz, klaster play station widzialem
Zenon nie odbilo Ci :) Pomyslalem o tym przelotnie, ale czemu mialoby to sluzyc?
Pomysly na wymiane informacji między dwoma komputerami są duzo prostsze (chocby ten czeski patent przez porty joyow).
A uzycie drugiego identycznego procesora 6502 do wsparcia jakichkolwiek obliczen to chyba zbyt maly zysk zeby oplacalo sie w to bawic?
Chociaz... ja chyba przebiję Cie w szaleństwie! :) Gdyby w obu tak połączonych komputerach usatwić pamięć ekranu na ten współdzielony obszar 8kB pamięci... I jeden z komputerów - MASTER (ten który steruje przełączaniem banków) generowałby obraz w obu obszarach... przełączając je co ramkę... Drugi komputer - SLAVE mógłby tylko wspierać generowanie obrazu dodając od siebie jakieś tam efekty wizualne czy animacje + własne duchy, zgodnie ze wskazaniami Mastera. Albo też na każdym komputerze mogłoby grac po dwóch graczy (na dwóch joyach)... Można różnie kombinować.
W każdym razie te dwa komputery byłyby idealnie "zsynchronizowane" jeśli chodzi o obraz, prawda?
No i teraz najlepsze - bierzemy sygnały video z obu komputerów i miksujemy je ze sobą 50%:50% :D Co by się stało z kolorami? :)
Jak myślicie? To realna wizja?
UPDATE: zagalopowalem sie :/ Obrazy byłyby zsynchronizowane jeśli chodzi o treść i animację. Ale niestety nie jeśli chodzi o sygnał (przerwanie VBI).
Chyba że da się takie przesunięte sygnały video i tak jakoś zmiksować (opóźniając jeden z nich)?
Ostatnio edytowany przez nosty (2009-03-31 00:03:05)
Można stworzyć Display List'ę, w której połowę obrazu przypiszemy procesorowi Master, a drugą Slave. Pierwszy fragment będzie leżał poza oknem komunikacyjnym, a drugi wewnątrz. Nie ma problemów z synchronizacją/buforowaniem obrazu, gdyż komputer Slave będzie wykonywał polecenia pod nadzorem Master, który to będzie wiedział, jak zsynchronizować się z VBL.
Co do miksowania. Łączenie buforów ekranu programowo raczej nie ma sensu, ze względu na konieczne, dodatkowe obliczenia, ale można np. wyobrazić sobie tryb graficzny, w którym całość pierwszej "warstwy" jest generowana w Master, a druga całość na Slave gdy Display List'a jest odpowiednio przepleciona liniami obu warstw. Master generuje efekt #1, Slave #2, a całość wyświetla Antic na Master'ze.
Uwaga poboczna... Dzięki takiej pracy zyskujemy blisko dwukrotnie na wolnej pamięci (dwa komputery).
Takie rozwiązanie byłoby już chyba w 99,99% bliskie duchowi atarki.
a ile zyskujemy miejsca na biurku?
uzytecznosc wam spada, wielkosc rosnie, a calosc zaczyna przypominac fantastyke popularno-naukowa
historia juz pogrzebala kilka takich wynalazkow, np voodoo
O Voodoo :) Mam takie na strychu, może by z tego dopalacz do Atari zrobić :)
Ja myślałem o fizycznym, zewnętrznym zmiksowaniu sygnałów Video obrazów wygenerowanych w opisany sposób przez dwa komputery.
Mielibysmy 2x więciej duchów i sporo więcej kolorów (min 8, albo 10 a ze zmieszania jeszcze dodatkowe).
Candle - a bo to dwie atarki polożone jedna na drugiej zajmują tak duzo miejsca? ;)
Powiedziałbym Atari Cross Fire lub SLI :-)
A tak w ogóle to po prostu CUDA...
Wracając jednak do wątku potencjalnych możliwości WERONIKI, to aż się prosi jakaś karta LAN
Ale z własnym buforem na ramki TCP/IP żeby był z tego jakiś pożytek
odswierze temat, a czy byla by taka mozliwosc, zeby okienko wspolnej stronicowanej pamieci bylo dla drugiego proca widzane pod innym adresem?
odswierze temat, a czy byla by taka mozliwosc, zeby okienko wspolnej stronicowanej pamieci bylo dla drugiego proca widzane pod innym adresem?
W prototypie jest ono zlokalizowane pod adresem $4000. Generalnie, jest to jeszcze temat do dokładniejszego uzgodnienia.
Sztywne rozwiązania narzuca architektura 6502
Wektor startu musi być tu $FFFC czyli w pamięci ROM, stos na stronie $01 więc tu przypisana pamięć RAM, strona zerowa , wiadomo też RAM
Koncepcja zatem jest taka. $0000-$3FFF pamięć RAM, $4000-7FFF "okienko" przełączanej pamięci, $8000-BFFF obszar na rejestry, $C000-$FFFF pamięć ROM
Są to rozważania teoretyczne i"środek" wcale tak nie musi wyglądać
Ostatnio edytowany przez Zenon/Dial (2009-04-16 06:18:26)
Dlatego pomysl koprocesora opartego na 6502, choc daje uniwersalnosc w wykorzystaniu, bedzie wymuszal strzelistą architekture sprzetową, a jego moc obliczeniowa bedzie mizerna :/
Znacznie bardziej atrakcyjny wydaje mi sie pomysl szybkiego mikrokontrolera ze stalym "rdzeniem" we wlasnym ROM'ie...
Ale: kazdemu wg potrzeb ;)
Strony Poprzednia 1 2 3 4 5 6 … 9 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.111 sekund, wykonano 7 zapytań ]