Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
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!
TONY na małe Atari Nowa gra na małe Atari, w Hiresie, produkcja Rafała Dudka (brat XXL-a), Popmilo i Caruso.
Zaloguj się lub zarejestruj by napisać odpowiedź
W tym miejscu będziemy prowadzili dyskusję na temat przenoszenia rdzenia "A16" do VBXE v1.1 i zmian w nim przy okazji. Tak na początek zapowiadam, że rdzeń zostanie GRUNTOWNIE przekonstruowany.
Ostatnio edytowany przez electron (2008-01-09 16:01:07)
bede dreczyl, powtarzam sie ale chce powiedziec, ze nie mozna niedoceniac mozliwosci blittera i wlasciwie juz tylko dla niego warto vbxe instalowac.
wiec tak:
1. blitter musi dzialac na pamieci ktora dziala jako rozszerzenie pamieci standardowej na atari.
co to daje - oprocz tego, ze grafike bedzie mozna generowac i praktycznie 'nie przesylac' do pamieci vbxe to wazniejsze jest to, mozemy sobie zasymulowac rozkazy przesylania duzych blokow pamieci (wielokrotnie szybsze).
gdyby taki bliter mogl oprocz operacji przemieszczania blokow pamieci wykonywac na nich operacje logiczne to jeszcze lepiej.
gdyby jeszcze byla taka mozliwosc, ze dzialanie blitera konczy sie gdy np bajt pamieci ktory ma zostac nadpisany (czy to w pamieci rozszerzenia czy pamieci obrazu vbxe) przyjmuje okreslona wartosc, lub jest rozny od. co by to dalo np szybkie wypelnianie wektorowek itp czary.
koncert zyczen
Chciałbym blitter zrobić tak, żeby nie rozróżniał pamięci kompa od pamięci VBXE. Działać ma na jednym i drugim, pamięć kompa (cała!) będzie tylko zmapowana pod innym adresem. Oczywiście szybkość działania vbxe na pamięci kompa będzie dużo mniejsza ale i tak wielokrotnie wyższa niż rozkazami 6502. Będzie to wymagało zatrzymywania 6502. Albo zrobię tak, że VBXE bęzdie podmieniało CAŁY RAM kompa a nie tylko $4000-$7FFF. O stronicowaniu strony zerowej też warto wspomnieć.
Ostatnio edytowany przez electron (2008-01-09 18:21:57)
Mnie blitter nie rajcuje (ale może być, jeśli nie będzie powodował problemów).
Podmiana całego RAM-u pachnie mi problemem, jaki jest w F7: mianowicie niespójnością pomiędzy tym, co w pamięci widzi CPU, a tym, co widzi w niej ANTIC. W efekcie np. CPU nie widzi kartridża, a ANTIC owszem no i można sobie wyobrazić, co jest dalej...
Podtrzymuję natomiast dezyderat co do możliwości nakładania atrybutów z rozdzielczością 64 "klatki" w linii.
kolejny pomysl ;-)
wprowadzenie: atari ma dli uzywane najczesciej tak: w lini nr xx zapisz wartosc yy do rejestru zz ...
czy vbxe ma licznik lini? a czy ma licznik punktow/cyklow koloru w linii? gdyby byla taka mozliwosc ze:
piszemy programik dla vbxe ktory ma tylko 3 rodzaje instrukcji: czekaj na pixel x w linii y, zapisz wartosc xx w rejestrze yy, skocz do zz jesli pixel x w linii y juz byl w tym wygaszaniu pionowym, chwileczke? czy nie tak wlasnie programuje sie copper w amidze :-D
Draco : kartridź to nie RAM :-) Nie bój żaby ... Czy dostęp jest od ANTIC-a czy od CPU to nie ma to znaczenia dla szyny ....
co do tej mapy kolorów to zobaczymy - temat jest do rozważenia :) Ale ja to widze najprędzej w stylu np. 5 bitowego licznika określającego rozmiar pola mapy (osobno X i Y) w pikselach ...
wow, to właśnie doszliście do rozwiązania w stylu GTIA Upgrade Psychola, z tym że u niego nie dało sie takiej mapy scrolować płynnie w poziomie i najmniejsza zmiana dotyczyła 2 pixli trybu 15OS, jednak jak można było się przekonać zmiana 1 rejestru w obszarze 2 pixli 15OS wystarcza w 90% aby trzaskać kolorowe obrazki jak na C64, jeśli zmiana dotyczyłaby 1 pixla trybu 15OS (160 różnych koloró w linii) to dopiero byłby czad
jeszcze swobodny dostęp do takiej mapy pamięci i będzie "chunky mode", wow pewnie się zapędziłem
MM: Nie calego posta pod ktorym piszesz.
jak na początek dla mnie - niechaj to głosem laika w owej kwestii w 100% emuluje to, co GTIA daje natywnie. Przeprogramowanie układu z poziomu programu to już teoretycznie nie problem - jeśli można uczynić dygresję :) - reszta;- niechaj się to nie gryzie z istniejącymi sprawami - bo możliwość obsługi wyłącznie z np. DOS'a II+d stanowczo neguje możliwość użycia dopału w moim przypadku. Oczywiście nie inputuję, że od razu takowa sytuacja miała by mieć miejsce :) -
ke ? Ale ossso chozi ?
:-)
Emuluje to co GTIA daje natywnie .... 100% albo blisko tego.
Z DOS II nie ma to nic wspólnego.
Możliwość programowania z kompa jest.
Ostatnio edytowany przez electron (2008-01-10 08:37:29)
Elc, nie martw się. U Pinokia i tak nic nigdy nie działa ;)
Nie to żebym nie doceniał czyjejś roboty, ale...
Prościej jest przekleić znaczek atari na amigę.
Ble ble ble ;-)
A może choćby docenić wyjście RGB ?
Ostatnio edytowany przez electron (2008-01-10 11:38:53)
co do tej mapy kolorów to zobaczymy - temat jest do rozważenia :) Ale ja to widze najprędzej w stylu np. 5 bitowego licznika określającego rozmiar pola mapy (osobno X i Y) w pikselach ...
Może być i licznik, byle się dało ekran 64-kolumnowy pokolorować. Można będzie w ten sposób elegancko zrobić kolorowy terminal :)
chodzi mi tylko o to, by zakładając dopał do kompa na wstępie otrzymać coś, co jest w 100% zgodne - nie wiem na jakim etapie zakończyła się emulacja GTIA - więc po prostu piszę o tym, bo onegdaj wszystko było dobrze, tylko ze sprajtami "było inaczej" :)
jest już inaczej inaczej czyli nie inaczej.
Zakładając dopał masz emulację i tylko emulację w tej chwili - za to pełną.
w takim razie potwierdzam zamówienie :) - jest to szczególnie miła rzecz ze względu na RGB;- Pytanie dodatkowe - kiedy planujesz "komercyjny" relase? :)
Ach, żeby to jeszcze chodziło w trybie VGA, miało 1G RAM i umiało gotować... :D
Ostatnio edytowany przez jer (2008-01-16 14:57:45)
tak pytam, ile czasu zajeloby przekopiowanie blitterem 1 strony pamieci atari do pamieci vbxe i czy tyle samo co przeniesienie 1 strony z vbxe do pamieci atari?
zebym mial jakiekolwiek porownanie to moze wynik w cyklach zegarowych 6502 ?
jeżeli blitter obsługiwałby tak jak chcę pamięć atari i pamięć vbxe to wówczas 1 cykl 1,77MHz na 1 bajt. Oczywiście ANTIC (DMA/refresh) by spowalniał. Ale to dumanie - zobaczymy, co uda się osiągnąć - dopiero jak zabiorę się za ten fajowy "softcore".
Ale jakoś bardziej do mnie przemawia podmiana całej pamięci Atarki na pamięć VBXE (metoda identyczna jak dla normalnego rozszerzenia RAM, tylko adresy inne). Wówczas blitter będzie działał na 14 MHz, a poza tym można dodać takie rarytasy jak np. bankowanie strony zerowej. Możliwości są spore a co najważniejsze nic nie trzeba ruszać już w hardware ... Poza tym jest to prostsze technicznie - nie trzeba HALTować procesora, nie trzeba dostosowywać się do szybkości CPU6502 ...
No jeszcze moment i się za to biorę ... chwilowo mam przerwanie o nazwie CPC464 :-)
Ale proszę zgłaszać pomysły.
Ostatnio edytowany przez electron (2008-01-16 21:12:33)
Ale jakoś bardziej do mnie przemawia podmiana całej pamięci Atarki na pamięć VBXE (metoda identyczna jak dla normalnego rozszerzenia RAM, tylko adresy inne). Ale proszę zgłaszać pomysły.
Co szaleni pokręci pisanie kodu....może dla grafiki to nie ma znaczenia. Przy bankowaniu $4000-$4fff sprawa jest prosta. Pamięc podstawowa kod, w bankach dane grafiki/kod...
Może choć da radę podłączać pamięć z dowolnego adresu niż $0000 wielkości 64kb
wybierając z dowolnej przestrzenii ramu VBXE, tj.
$0000 -------------------
podstawowa RAM 6502
$2000 ------------------- VBXE ram od adresu $7000
przełączona pamięć VBXE
$FFFF ------------------- koniec widocznej pamieci 6502
pozostałe $2000 z 64kB VBXE niewidoczne dla 6502
$12000 -------------------- koniec 64kB VBXE o adresie $17000
Choć wolałbym, aby to nie musiałoby być koniecznie całe 64kB, ale choćby 32kB, tudzież 16kB albo dowolnie ;)
Ostatnio edytowany przez pajero (2008-01-17 15:10:01)
byc moze juz bylo, jak wyglada tekst kolorowany atrybutami na vbxe? kolor tla mozna zmienic a znak ma luminancje atrybutu czy moze znak ma swoj kolor a tlo swoj?
W rdzeniu A16 (ten z full bajerami ale bez pełnej emu gtia) nie było ograniczenia jak w GTIA tzn. pixel ma swój kolor i jasność a tło swój, niezależnie. Oba kolory można zmienić w mapie.
W nowym projektowanym rdzeniu też tak będzie, z tym, że będzie można włączyć też tryb zgodności z GTIA.
W rdzeniu emulacji (tym skończonym) wszystko jest tak, jak oryginalnie w GTIA.
UWAGA: rdzenia A16 nie chciałbym udostępniać dla VBXE 1.1/1.2 aby nie wytwarzać sytuacji, że ktoś zacznie pisać na to programy ... Chyba, że nie zdążymy z nowym rdzeniem - wówczas udostępnię też A16 ...
Poza tym w sumie nie piszcie czy w VBXE jest tak i tak ... bo sam hardware jest elastyczny i może być różnie - wszystko zależy od rdzenia. Można tam nawet nowy procek wrzucić... Ktoś to może zrobi ... :)
skoro 65816 jest tak trodno dostepny - moze by go "przy okazji" dorzucic do rdzenia? ;)
tyle ze pewnie wymagalo by to wiekszego ukladu...
... byle się dało ekran 64-kolumnowy pokolorować. Można będzie w ten sposób elegancko zrobić kolorowy terminal :)
wylaczyc antica co da 30% dla 6502. napisac nowy sterownik dla e: i s:
Poczekajcie Panowie, bo jak na razie tylko czytam, czytam i się już pogubiłem.... Co oznacza gruntowna rekonstrukcja VBXE? Czy to oznacza, że lepiej się wstrzymać z instalacją aktualnej wersji i czekać na przekonstruowaną? Wiecie, chodzi o to, żeby to w gruncie rzeczy fajne rozwiązanie było na tyle stabilne wersjowo/kompatybilnościowo, żeby mogło być uznane jako standardowe w świecie tak jak np. dwa POKEY'e
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.097 sekund, wykonano 8 zapytań ]