101 Odpowiedź przez Marek Konopka

(16 odpowiedzi, napisanych Bałagan)

Ja korzystałem z DriveImage XML - nawet na partycji w RAID-0. Musiałem tylko dorzucić odpowiedni sterownik do mostka południowego i całość działała, oczywiście z BartPE. Jedna uwaga dot. tego programu. Pieprzy (a przynajmniej pieprzył) statusy plików - już nie pamiętam co dokładnie zrobił, ale chyba zniekształcał status archiwizacji albo read-only. Było to jakiś czas temu, więc autorzy mogli to skorygowac.

Idź do forum: Bałagan

102 Odpowiedź przez Marek Konopka

(27 odpowiedzi, napisanych Programowanie - 8 bit)

Zróbta jakieś video dla niemających.

Idź do forum: Programowanie - 8 bit

103 Odpowiedź przez Marek Konopka

(27 odpowiedzi, napisanych Programowanie - 8 bit)

Każdy kolor z palety powinien być stały w obrębie całej wyświetlanej klatki obrazu. Nie możemy założyć, że w sekwencji kolejnych liń będą znajdowały się wyłącznie kolory z wąskiego zakresu palety, dla których takie podejście miałoby jakiś sens. Każdy kolor z palety może znajdować się w dowolnym miejscu obrazu.

Idź do forum: Programowanie - 8 bit

104 Odpowiedź przez Marek Konopka

(27 odpowiedzi, napisanych Programowanie - 8 bit)

Rozumiem, że to jest przygotowanie palety do późniejszego, prostego jej zaaplikowania na VBL (przełączenie banku). Jeśli nie, to ta procedura powyższa nie wyrobi się w czasie tuż przed wyświetleniem pierwszej linii obrazu.

Idź do forum: Programowanie - 8 bit

105 Odpowiedź przez Marek Konopka

(27 odpowiedzi, napisanych Programowanie - 8 bit)

W pierwszej pętli SEC przed CMP jest zbyteczny.

Idź do forum: Programowanie - 8 bit

106 Odpowiedź przez Marek Konopka

(26 odpowiedzi, napisanych Sprzęt - 8bit)

Odpalasz APE z prawami Admina? Jeśli nie, to good bye...

Idź do forum: Sprzęt - 8bit

107 Odpowiedź przez Marek Konopka

(27 odpowiedzi, napisanych Programowanie - 8 bit)

Gravity '98, Quast'98, Analogue '99

Idź do forum: Programowanie - 8 bit

108 Odpowiedź przez Marek Konopka

(27 odpowiedzi, napisanych Programowanie - 8 bit)

Jeżeli jest coś takiego jak buforowanie palety/mapy kolorów to nie ma problemu. Wystarczą 2 bufory, a fade co 1 klatkę będzie osiągalny.

Jest też jeszcze inny sposób, trick, który może skutkować drobnymi artefaktami wizualnymi, choć chyba nie jakimiś drastycznymi. Możesz spróbować na zmianę zapisywać po połowie palety w VBL zamiast całości. Które indeksy palety wybierać to już jest sprawa do określenia po eksperymentach. Można zrobić interleaving co bajt (#0 #2, #4... i #1, #3, #5, ...) lub 2 liniowe sekwencje po 128 rejestrów. Co prawda pełne zaktualizowanie palety następować będzie w okresach co 2 ramki, lecz samo odświeżenie części palety co jedną.

Idź do forum: Programowanie - 8 bit

109 Odpowiedź przez Marek Konopka

(27 odpowiedzi, napisanych Programowanie - 8 bit)

Drobna wskazówka. Jeżeli możesz sobie pozwolić na zmianę zawartości nie co każdą ramkę, ale więcej, to wtenczas problem wydajności znika bowiem podczas normalnego czasu procesora (poza VBL) możesz wygenerować sobie wartości do zapisania w palecie na VBL. Wtedy sam zapis uprości się do formy:

.rept 256
lda #$ff
sta R_palette_registers+#
lda #$ff
sta G_palette_registers+#
lda #$ff
sta B_palette_registers+#
.endr

Argumenty dla powyższych rozkazów lda #$xx w tym wariancie generowane są przez procedurę liczącą wartości pośrednie do fade'a i zapisywane w drodze automodyfikacji. Szybciej się nie da już tego zrealizować.

To będzie 4608 cykli czyli 40 linii, a to powinno już wejść w VBL przed pokazaniem pierwszej linii obrazu.

Idź do forum: Programowanie - 8 bit

110 Odpowiedź przez Marek Konopka

(27 odpowiedzi, napisanych Programowanie - 8 bit)

Flaga C przy LDA nie jest zmieniana, więc PHP/PLP są zbędne. LDA zmienia tylko flagi N oraz Z.

Jeżeli dodajesz stałą wartość do tablicy wejściowej, to można napisać prostszy i szybszy wariant w oparciu o tablicę pośrednią:

.rept 768
ldx src_table+#
lda Add_3,x
sta dst_table+#
.endr

12*768 = 9216 cykli

Tablica Add_3 zawiera wartości indeksu powiększone o stałą z uwzględnieniem saturacji. Można ją wygenerować w następujący sposób.

ldy #0
loop:
tya
clc
adc #3
bcc skip
lda #255
skip
sta Add_3,y
iny
bne loop

Chyba jednak się nie zmieści w przerwaniu VBL, gdyż jest w nim ok. 50 linii jeśli dobrze pamiętam. Tutaj wychodzi nam ~80.

Idź do forum: Programowanie - 8 bit

111 Odpowiedź przez Marek Konopka

(27 odpowiedzi, napisanych Programowanie - 8 bit)

Na szybko:

clc
.rept 768
txa
adc src_table+#
bcc skip
  tya
  clc
skip:
sta dst_table+#
.endr

X = value to add
Y = 255
src_table - wiadomo
dst_table - wiadomo

Wychodzi min. 9984 cykli, max 12288, średnio 11136.  Nie pamiętam ile jest dokładnie linii niewidocznych, ale może być na styk w przypadku min.

B. możliwe, że można to jeszcze skrócić przy dod. założeniach.

Idź do forum: Programowanie - 8 bit

112 Odpowiedź przez Marek Konopka

(220 odpowiedzi, napisanych Sprzęt - 8bit)

xxl napisał/a:

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.

Idź do forum: Sprzęt - 8bit

113 Odpowiedź przez Marek Konopka

(25 odpowiedzi, napisanych Programowanie - 8 bit)

W DOS II/D są do tego opcje: !tekst oraz ! (http://atariki.krap.pl/index.php/DOS_II/D).

Jeżeli nie potniemy pliku na równe kawałki po 16 kB to będzie więcej problemów z załadowaniem tego do banków pamięci.

Idź do forum: Programowanie - 8 bit

114 Odpowiedź przez Marek Konopka

(25 odpowiedzi, napisanych Programowanie - 8 bit)

Podziel sobie plik wyjściowy na fragmenty po 16 kB, np. przy użyciu Total Commandera (opcja Plik::Podziel plik albo poszukaj na sieci darmowy alternatywe czyli jakiś file splitter). Przerzuć sobie te podzielone pliki do szeregu .atr'ów lub ile tam ich potrzebujesz, ręcznie albo za pomocą frani (http://atariki.krap.pl/index.php/Franny). Następnie napisz sobie krótki skrypt .bat, np. w DOS II/D, coś w stylu:

>D301 A3
LOA BANK00.dat,4000
>D301 A5
LOA BANK01.dat,4000
....
>D301 FF

Idź do forum: Programowanie - 8 bit

115 Odpowiedź przez Marek Konopka

(18 odpowiedzi, napisanych Programowanie - 8 bit)

tebe napisał/a:

sprzętowa detekcja kolizji była dobra w czasach jednokolorowych postaci i jednokolorowych pól gry, każdy dodatkowy inny kolor pixla to dodatkowy problem z precyzyjną oceną kolizji, programowa detekcja kolizji nie jest w cale taka trudna ani powolna

http://codebase64.org/doku.php?id=base: … _collision

To co zacytowałeś, to nie żadna procedura kolizji, tylko jej namiastka. Nie wykrywa ona faktycznego statusu kolizji pomiędzy kolorami pierwszo-planowymi sprite'ów, a jedynie fakt posiadania części wspólnej pomiędzy prostokątami zawierającymi duszki. Do pełni szczęścia potrzebne jest znacznie więcej, dokładniejszych obliczeń.

Idź do forum: Programowanie - 8 bit

116 Odpowiedź przez Marek Konopka

(220 odpowiedzi, napisanych Sprzęt - 8bit)

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.

Idź do forum: Sprzęt - 8bit

117 Odpowiedź przez Marek Konopka

(220 odpowiedzi, napisanych Sprzęt - 8bit)

wieczor napisał/a:

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

vega napisał/a:

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.

vega napisał/a:

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ć.

Idź do forum: Sprzęt - 8bit

118 Odpowiedź przez Marek Konopka

(220 odpowiedzi, napisanych Sprzęt - 8bit)

Candle napisał/a:

acha, ale po tym wszystkim output jest i tak w 4 (5) kolorach
interlace? kolejne wyrzeczenia - ostatecznie mozemy dostac obrazek z cala masa kolorow, tylko ze wielkosci znaczka pocztowego

80 bajtów na linię w trybie HIP * 200 poziomych liń daje 16 000, czyli ilość mieszczącą się w 16kB obszarze CAR. Gdyby to z jakichś powodów było nieosiągalne lub wartością za małą, to mamy możliwość przełączania banków pamięci w połowie ekranu, co zredukuje nam wymagania dot. wielkości okna komunikacyjnego dla wyświetlanego bufora ekranu. Komplikuje to kod po stronie 6502K, ale jest osiągalne dla pewnych zastosowań (sprite'y), a tym bardziej przy większej mocy 6502K.

Weronika, to nie projekt karty graficznej z nowymi trybami graficznymi.

Idź do forum: Sprzęt - 8bit

119 Odpowiedź przez Marek Konopka

(220 odpowiedzi, napisanych Sprzęt - 8bit)

nosty napisał/a:

Wazne: cartridge jest tak skonstruowany, że nie tylko wahadłowo dzielimy między procesorem i uC obszar 8kB, ale mamy też możliwość przekazywania do/z uC danych za pomocą niektorych rejestrów strony $D5xx. To jest mozliwe i potrzebne, bo idea jest taka, że dzielony wahadłowo obszar 8kB będzie pamięcią ekranu, a strona $D5xx będzie służyła do wysyłania danych i polecen między 6502 a uC.

Wymiana danych przez stronę $d5xx nie jest konieczna. Jest raczej kłopotliwa, bowiem ogranicza możliwości konstruowania innych rozszerzeń. Do realizacji pomysłu wystarczy jedna komórka pamięci na stronie $d5xx. Rozmiar jednej strony jest na tyle nieistotny, że nie stanowi to żadnego problemu w kontekście rozmiarów bufora ekranu zlokalizowanego pod pamięcia CAR.

nosty napisał/a:

Grę piszemy w taki sposób, że procesor w Atari nie zapisuje niczego do pamięci ekranu!

Co ciekawe, może to robić. Przy odpowiednim docyklowaniu może dołożyć do wyświetlanego bufora dodatkowe dane.

nosty napisał/a:

Jak pisałem - nie ma sensu, żeby procesor Atari sam modyfikował pamięć obrazu bo te zmieny i tak zostaną "przykryte" po 1/50 sekundy przez kolejną klatkę przygotowaną przez uC.

Ma to sens w wariancie, gdy procesor 6502K posiada zbliżoną wydajność do 6502. Wtenczas opłaca się podzielić ekran na 2 osobe bufory, do których wyłączny dostęp będą miały odpowiednie procesory. Oczywiście w wariancie bardziej wydajnego procesora po stronie Weroniki to podejście traci sens.

Aktualizacja:

Candle napisał/a:

jak dla mnie to rozszerzenie typu drugie costam (pokey, antic (tez byly), pia itp) z technologia sprzed 30 lat - i to mnie najbardziej boli nikla kupowalnosc czesci nowych.

Można docelowo wziąć pod uwagę wariant z FPGA.

Candle napisał/a:

kiedy mozna spodziewac sie jakis przykladow wykozystania? (w postaci filmidla)

Będzie to miało miejsce, gdy Pan Zenon skonstruuje prototyp z większą ilością pamięci (65kB). Do tego czasu będą testowane elementarne programy komunikacyjne. Co do konkretnych terminów, proszę pytać o to jego samego.

Idź do forum: Sprzęt - 8bit

120 Odpowiedź przez Marek Konopka

(220 odpowiedzi, napisanych Sprzęt - 8bit)

Candle napisał/a:

ponadto skad weronika wie co w ogole ma robic i jak jej to wyperswadowac i zaprzedz do robienia czegos innego?

Jak już wcześniej wspominałem, w wydzielonej części pamięci 6502K (EPROM) umieszczony jest kod do obsługi prostego protokołu komunikacyjnego. Uwzględnia on przesyłanie elementarnych komend takich jak przerzucanie danych, wywołanie procedury, identyfikacja. Po wykonaniu komendy 6502K odpowiednio sygnalizuje to opuszczeniem swojego semafora. Wykrywa to 6502, czuwając nad całością wymiany danych. Do synchronizacji wykorzystane są dwa semafory, jeden dla 6502 drugi dla 652K. Zenon podawał ich opis wcześniej w tym wątku.

Idź do forum: Sprzęt - 8bit

121 Odpowiedź przez Marek Konopka

(220 odpowiedzi, napisanych Sprzęt - 8bit)

Candle napisał/a:

mysle tez, ze czas dodany na obsluge protokolu wymiany bankow bedzie dosc znaczacy

Protokół komunikacyjny jest gotowy. Nie ma tam żadnych lagów. 6502 testuje semafor (bit) z rejestru 6502K w prostej pętli. Samo ustawienie rejestru/przełączenie banku to prosta sekwencja operacji: lda rejestr, and #maska, ora #wartosc, sta rejestr. 6502 nie musi (nie powinien) czekać bezczynnie na dane od 6502K. Można podzielić odpowiednio porcję danych do obróbki pomiędzy 6502 oraz 6502K tak, aby moment ich scalenia występował w mniej więcej tym samym czasie po obu stronach. W ten sposób można zrealizować proste przetwarzanie równoległe.

Nie mam zbyt wielkiego pojęcia o vbxe, ale wyobrażam sobie przykładowo, że 6502K może wygenerować złożoną grafikę w jednym z trybów vbxe, lokując bufor pod CAR, a sam vbxe dokona wyświetlenia tych danych. W takim scenariuszu oba rozszerzenia są komplementarne i nie gryzą się ze sobą. Można również sobie wyobrazić scenariusz z podziałem ról, tzn. podziałem ekranu na strefy, do których dostęp będą miały osobno - blitter vbxe oraz weronika.

Jeszcze jedna ciekawa obserwacja. Dzięki przełączaniu banków zlokalizowanych po stronie 6502K i umieszczeniu buforów ekranu pod adresem CAR, nie musimy realizować żadnego dodatkowego dwubuforowania po stronie 6502, w sensie alokacji dodatkowej pamięci. Bufory te są zlokalizowane w dwóch bankach pamięci współdzielonej, umieszczonej na CAR, także moje wcześniejsze założenia, iż byłaby konieczność alokacji tych buforów w każdym banku są nieścisłe.

Idź do forum: Sprzęt - 8bit

122 Odpowiedź przez Marek Konopka

(220 odpowiedzi, napisanych Sprzęt - 8bit)

drac030 napisał/a:

To trochę mało elastyczne, poza tym na C-64 masz dodatkowo atrybuty, co trochę pomaga. W ST desktop zadowala się dwoma kolorami, ale to w hiresie (640x400), gdzie za trzeci kolor robi siateczka białych i czarnych punktów i wyglada to bardzo dobrze.

Trzeci (czwarty) kolor do rozróżnienia obszarów desktopu, okien, ikon byłby przydatny, podobnie jak na tych zrzutach z Geos'a.

drac030 napisał/a:

To kolejna wg mnie zaleta takiego Warpa: model pamięci (konwencjonalnej) pozostaje taki, jak był.

Oczywiście, w domyśle chodziłoby o stworzenie nowego systemu operacyjnego, który współpracowałbym z CAR'tem, gdzie z kolei umieszczone byłby specyficzne funkcje API. Kompatybilość wsteczna z istniejącymi programami byłaby iluzoryczna. CART spełniałby tutaj rolę koprocesora.

Inny przykład, to zmodyfikowanie BASIC'a ładowanego do pamięci 6502, aby zamiast wywoływania czasochłonnych wersji procedur zmiennoprzecinkowych, zlecał to zadanie wyselekcjonowanemu podzbiorowi funkcji API na CART'cie, po uprzedniej detekcji CART'a. Sama ich implementacja mogłaby być identyczna z tymi już istniejącymi. Zysk z tego konkretnego zastosowania byłby wprost proporcjonalny do nadwyżki mocy zewn. CPU w stosunku do 6502 na maluszku, czyli taki nowszy TurboBasic XL. Inne zastosowanie, to szybsze odrysowywanie grafiki, edytory tekstu, graficzne, muzyczne. Do sprzętu musiałaby odwoływać się bezpośrednio część systemu zlokalizowana po stronie komputera, więc generalnie byłaby to jakaś hybryda.

xxl napisał/a:

65816 nie poradzilby sobie z emulacja procesora wektorowego np z asteroida :-) ... jesli myslicie o 65xxx to lepiej nie rozbudzac nadzei...

Nie rozważaliśmy żadnych emulacji. W domyśle chodzi o zbiór funkcji API wrzucanych do szybkiej pamięci procesora na CARTcie. To jaki to będzie zbiór i z jaką skutecznością zaimplementowany, to już osobna sprawa i zależałoby od wielu czynników.

Idź do forum: Sprzęt - 8bit

123 Odpowiedź przez Marek Konopka

(220 odpowiedzi, napisanych Sprzęt - 8bit)

drac030 napisał/a:

Od tego to mamy VBXE (sorry, ale graficzny desktop musi być ładny, a z 320x192 w dwóch kolorach nic ładnego nie powstanie, bo potrzebne sa co najmniej 3 kolory, żeby to jakoś wyglądało).

Mamy sprite'y. Z tego co widziałem ostatnio na zrzutach z Geos'a, również tam są one zastosowane - http://www.guidebookgallery.org/screenshots/geosc64 . Tutaj widzę raczej inny problem, a mianowicie ograniczenie ilości pamięci na okno (16kB). Ewentualnie byłoby to na styk, chyba, że darujemy sobie buforowanie pamięci ekranu.

drac030 napisał/a:

I od tamtej pory uważam, że bawienie się w bankowanie RAM-u, nawet jeśli by się miało w nim coś automagicznie pojawiać, to mało sensowna mordęga i komplikowanie prostych spraw.

Można rozważyć liniową przestrzeń adresową procesora 816 przy 24-bitowej adresacji. Oczywiście należałoby uwzględnić "okno" komunikacyjne. Można podzielić pamięć sprytnie, aby ta powyżej okna, przy jego odpowiednio niskiej lokalizacji w przestrzeni procesora CAR, była zmaksymalizowana dla programów/systemu i liniowa. Nawet gdyby istniało okno, dzielące obszar pamięci operacyjnej na rozdzielne części, to nie jest to jakiś szczególny problem. Normą w obecnych systemach jest fragmentacja pamięci, a alokatory sobie z tym radzić muszą.

Oczywiście, że jest z tym trochę zabawy, ale czy specyfiką old-schoolowych komputerków nie jest właśnie ta konieczność zmagania się z takimi problemami?

drac030 napisał/a:

w BASIC-u oznaczałoby to nieustanne migotanie ekranu, bo BASIC w kółko liczy coś na FP).

Basic w rozważaniach świadomie skreślam. Nie ma to dla mnie praktycznego zastosowania. Dla zainteresowanych można oczywiście stworzyć własną implementację Basic'a i z tego co widziałem na Twojej stronie, coś takiego tworzysz. Oczywiście kompatybilność wsteczna z modelem pamięci OS'u atarowskiego nie ma w tym wariancie miejsca.

Być może omawiany projekt jest okazją, aby pewne rozwiązania przy jego implementacji powiązać/zintegrować.

drac030 napisał/a:

Systemowi graficznemu przydałby się szybki procesor robiący za blitter, ale co z takiego blittera, który może skopiować blok pamięci obrazu w inne miejsce tylko wtedy, kiedy Antic/GTIA nic nie wyświetlają (poza tym potencjalna wydajność raczej blednie w porównaniu z blitterem VBXE).

W tym układzie rolę blitter'a musiałby przejąć sam procesor na CAR, przy założeniu jego odpowiednio wysokiej mocy. Widziałem jak TOS odświerza okna. Jestem przekonany, że można zrobić to lepiej.

drac030 napisał/a:

mam tu głównie na myśli, że tam, gdzie jest więcej pamięci, jest ona dostępna w jednym kawałku

Rozwiązanie z przełączaniem banków dotyczy wyłącznie komunikacji/transferu danych pomiędzy 6502, a procesorem CAR. Sam model pamięci procesora na CAR może być w dużym stopniu od tego niezależny.

Idź do forum: Sprzęt - 8bit

124 Odpowiedź przez Marek Konopka

(220 odpowiedzi, napisanych Sprzęt - 8bit)

drac030 napisał/a:

No tak, tylko jakie widzisz zastosowania tego, bo ja, jak już napisałem wyżej, raczej wąskie (grafika wektorowa w gierce, pewnie głównie, oraz efekty w demach niedopuszczonych do konkursu).

Jak już kiedyś pisałem dawniej, kiedy o tym dyskutowaliśmy, nie myślałem o innych zastosowaniach. Zenon w swoim dokumencie również na to kładzie nacisk. Z takiego założenia wychodziłem od samego początku. Dzisiaj dochodzę do wniosku, że możliwości są szersze i można sobie pozwolić na tworzenie gier z większą ilością grafiki, sprite'ów, lepszą muzyką. Procesor na CAR można wykorzystać do generacji buforów audio dla POKEY'a (sampli). To wszystko na razie jest oczywiście teorią, ale skoro sobie gdybamy, to warto o takich zastosowaniach wspomnieć.

Rozumiem, że chętniej widziałbyś bardziej ogólne zastosowania, być może jakiś system operacyjny, dodatkową pamięć, coś na kształt Geos'a, ale czy na pewno to nie jest osiągalne w tej formie, w jakiejś dalszej perspektywie czasowej?

drac030 napisał/a:

I co z tego nie może zostać zrobione przez regularne 65C816 z takiego Warpa?

Nic, to po prostu inne podejście. Nie ma sensu już dyskutować o podstawowych różnicach. Dla mnie rozwiązanie z CAR jest bardziej eleganckie i podoba mi się w nim to, że ma szanse większego upowszechnienia się. O projektach F7/Warp tego nie można powiedzieć. Sam cytowałeś liczbę działających egzemplarzy. Dla mnie oczywiste ograniczenia rozwiązania z CAR są do stolerowania. Nawet powiem więcej, podoba mi się to, że istnieją, gdyż stanowią jakiś wyróżnik i tworzą platformę do realizacji nowych, ciekawych pomysłów, wyciśnięcia maksimum z układów "maluszka".

Aktualizacja

jellonek napisał/a:

z poczatkowej koncepcji Zenona zrozumialem ze pamiec ram procka na CARze jest podzielona na 2 czesci. musi tez miec jakis "bootstrap rom".

Przewidziany jest bootstrap w przestrzeni CAR, pakowany z EPROM'u we fragment przestrzeni adresowej CAR, z kodem obsługującym prosty protokół komunikacyjny, umożliwiający przenoszenie danych/kodu do pamięci CAR pod wyspecyfikowane w protokole lokacje. Jedną z komend będzie egzekucja procedury pod wyspecyfikowanym adresem.

jellonek napisał/a:

mozna nieco koncepcje zmodyfikowac tak, by cart mial nieco wiecej ramu (np. 128k+2x16k), ale tylko 2 16k banki dostepne do przelaczenia w tej samej przestrzeni adresowej i widoczne na przemian przez atarke i carta.

Pierwotna idea jest taka - 2 "banki" po 16K naprzemiennie wpinane w przestrzeń adresową (64k) procka na CAR/6502. Gdzie dokładnie w procku na CAR, to już mniej ważne. Reszta ramu klasycznie w przestrzeni procka. Można to oczywiście rozszerzać, rozważyć 816 z adresowaniem 24-bitowym, w razie powodzeń.

Idź do forum: Sprzęt - 8bit

125 Odpowiedź przez Marek Konopka

(220 odpowiedzi, napisanych Sprzęt - 8bit)

drac030 napisał/a:

aczej nie mogłeś widzieć w akcji żadnej z tych dopalek ani tym bardziej stwierdzić ich stabilności (bądź niestabilności).

Niech wypowie się zainteresowany, jak było.

drac030 napisał/a:

Co do dalszej części: Ok, czyli dodatkowy procesor pisze do pamięci, kiedy jest ona niewidoczna dla Antica, po czym staje się widoczna, ale wtedy procesor nie może do niej pisać.

Może pisać do tego obszaru pamięci, innego bufora obrazu.

drac030 napisał/a:

Synchronizacja tego pewnie będzie spoczywać na głównym 6502 atarki, który będzie dodatkowego proca haltował i uruchamiał stosownie do potrzeb. Stwierdzenie, kiedy pamięć jest widoczna dla Antica a kiedy nie, spocznie na jego programie?

O tym decydować będzie 6502 w synchronizacji z VBL.

drac030 napisał/a:

Czyli dodatkowy procek będzie działał od złapanego stanu VCOUNT sygnalizującego początek dolnej ramki do stanu sygnalizującego koniec górnej ramki?

Może działać przez prawie całą ramkę, aż do otrzymania sygnału o zmianie bufora ekranu.

Co do halt'owania... Takie samo występuje przy pracy na każdym CPU/buforze pamięci ekranu, aby uniknąć artefaktów wizualnych. Po to stosuje się n-buforowanie, które pozwala na zagospodarowanie sporej części czasu procesora, który byśmy musieli nominalnie przeznaczyć na straty. W przypadku, gdy efekt będzie renderował klatki z częstotiwością wyższą od odświerzania ekranu, nie będzie żadnego problemu. Przy wyższej można skorzystać z n-buforowania. Poza tym, można moc procesora CAR spożytkować na wykonywanie innych czynności niż tylko generacja danych obrazu, także część z tego "straconego" czasu można "odzyskać".

Można oczywiście przerzucać/wyświetlać dane przez kopiowanie. Kosztem obciążenia 6502 i w konsekwencji ryzyka spadku fps'u, możemy skolejkować więcej buforów ekranu w pamięci CAR. Którą metodę wybrać, zależało będzie od charakterystyki czasowej efektu.

Aktualizacja

macgyver napisał/a:

W tym momencie ktoś słusznie zwrócił uwagę na to, że po co tym drugim prockiem ma być 6502?

Chęć zachowania po części "ducha" komputerka. Dochodzi również łatwość pisania programów na dobrze znaną platformę.

macgyver napisał/a:

Szybkość 6502 jest ograniczona

Szybkość każdego procesora jest ograniczona :>.  A na poważnie, w prototypie Zenona jest 6502, ponieważ tak jest mu wygodnie - testowane są najpierw warianty podstawowe, komunikacja/synchronizacja. Jak już wspominaliśmy oboje, nie ma sensu zbyt daleko wybiegać w przyszłość i gdybać, dajmy na to, ile konkretnie mocy będzie można w to włożyć, dopóki pierwsze testy nie pokażą sensowności podejścia na ogólnym poziomie.

Nie wiem jak wygląda sprawa z konkretnymi edycjami układów 6502, ale pamiętam, że ktoś kiedyś wspominał o wyższym taktowaniu tego procesora. Chyba drac cytował korespondencję od osoby, która projektowała wtenczas te procesory i chwaliła się, że można osiągnąć częstotliwości taktowania w okolicach ~10 MHz. Nam na początek tyle nie jest potrzebne. Gdzieś na forum powinien być o tym wątek.

macgyver napisał/a:

, a na rynku są ogólnodostępne procesory o większej szybkości - jak już tworzyć coś nowego, to po co ograniczać się do 6502, który tylko lekko wspomoże szybkość systemu, a nie zastosować coś wielokrotnie szybszego, co wykona w tym samym czasie np. 10 razy więcej obliczeń/operacji?

816 pasuje tutaj jak ulał.

Idź do forum: Sprzęt - 8bit