1 Ostatnio edytowany przez electron (2008-01-09 16:01:07)

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.

pomidor

2

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

http://atari.pl/hsc/ad.php?i=1.

3 Ostatnio edytowany przez electron (2008-01-09 18:21:57)

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

pomidor

4

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.

KMK
? HEX$(6670358)

5

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

http://atari.pl/hsc/ad.php?i=1.

6

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

pomidor

7

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.

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

8

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 :) -

Kontakt: pin@usdk.pl

9 Ostatnio edytowany przez electron (2008-01-10 08:37:29)

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.

pomidor

10

Elc, nie martw się. U Pinokia i tak nic nigdy nie działa ;)

Czy możecie wyjaśnić, Stirlitz, dlaczego wasz służbowy adres stirlitz@rsha.gov.de ma aliasa justas@gru.su?
Nie czytam PM. Proszę używać e-mail.

11

Nie to żebym nie doceniał czyjejś roboty, ale...
Prościej jest przekleić znaczek atari na amigę.

--
Dhor/M.E.C.

12 Ostatnio edytowany przez electron (2008-01-10 11:38:53)

Ble ble ble ;-)

A może choćby docenić wyjście RGB ?

pomidor

13

electron napisał/a:

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 :)

KMK
? HEX$(6670358)

14

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" :)

Kontakt: pin@usdk.pl

15

jest już inaczej inaczej czyli nie inaczej.

Zakładając dopał masz emulację i tylko emulację w tej chwili - za to pełną.

pomidor

16

w takim razie potwierdzam zamówienie :) - jest to szczególnie miła rzecz ze względu na RGB;- Pytanie dodatkowe - kiedy planujesz "komercyjny" relase? :)

Kontakt: pin@usdk.pl

17 Ostatnio edytowany przez jer (2008-01-16 14:57:45)

Ach, żeby to jeszcze chodziło w trybie VGA, miało 1G RAM i umiało gotować... :D

18

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 ?

http://atari.pl/hsc/ad.php?i=1.

19 Ostatnio edytowany przez electron (2008-01-16 21:12:33)

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.

pomidor

20 Ostatnio edytowany przez pajero (2008-01-17 15:10:01)

electron napisał/a:

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 ;)

21

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?

http://atari.pl/hsc/ad.php?i=1.

22

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 ... :)

pomidor

23

skoro 65816 jest tak trodno dostepny - moze by go "przy okazji" dorzucic do rdzenia? ;)
tyle ze pewnie wymagalo by to wiekszego ukladu...

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

24

drac030 napisał/a:

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

http://atari.pl/hsc/ad.php?i=1.

25

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

The problem is not the problem; the problem is your attitude about the problem