1 Ostatnio edytowany przez xxl (2011-08-31 11:04:03)

witam,

temat w stylu "czego mi najbardziej brakuje", moze ktos sie jeszcze przylaczy i uda sie wywrzec odpowedni nacisk na wiadomo kogoko...

1. rozdzielenie rejestru MEMAC_CONTROL na dwa, jeden odpowiedzialny za umiejscowienie okna pamieci z dokladnoscia do jednej strony (starszy nibbel starego rejestru), a drugi do ustalenia wielkosci okna, dostepy antic i cpu (mlodszy nibbel starego), dodanie przynajmniej 2 nowe wielkosci okna $100 i $ffff oraz kontroli zapisu do pamieci vbxe gdy zaslaniana jest przez rejestry sprzetowe (zapis do rejestrow oraz do pamieci vbxe - wiadomo, ze z poziomu np blittera nie zapiszemy rejestrow sprzetowych ale jak bedzie minicpu w rdzeniu to przynajmniej bedziemy mogli czytac co zostalo do rej.sprzetowych wpisywane)

2. wprowadznie trybu tekstowego z 256 zestawem znakow przy standardowej wielkosci pixela (obecnie vbxe udostenia taki tryb z pixelem rozdzielczosci 640)

3. wprowadzenia do rdzenia mini procesora (wystarcza znaczniki NZC itd. rejestry dostepne na stronie D6/7xx, napotkanie nierozpoznawanego kodu kasuje flage BUSY... podobnie jak obecnie blitter itd. )

takie zmiany moga byc zrobione kosztem (usunieciem z obecnego rdzenia):

- blitter i caly powiazany sys.kolizji (z mini cpu mozna napisac blitter, ktory bedzie mial lepsze funkcje niz obecny - np. rysowanie odcinkow)
- z czterech definiowanych palet wystarcza dwie

i jeszcze jedno, nie chodzi o vbxe w wersji 3 lub 5, chodzi o istniejace obecnie wersje vbxe

czas wprowadzic odrobine nerwowej atmosfery na forum ;-)


----
UPDATE 24.05.11

malo miejsca. wieksze ciecia. zostaje tylko:

1. emulacja GTIA
2. MEMAC - punkt pierwszy powyzej
3. mini cpu - punkt trzeci powyzej

cala reszta odpowiedzialna za video nowe tryby itp. moze zostac usunieta.

----
UPDATE 31.08.11

MEMAC jako modul nie zajmuje zbyt wiele - rozszerzenie mozliwosci do punktu 2:

- dodanie nowego trybu do memaca - trybu cardridge, konfigurowana rozmiar, miejsce i typ carta - np. cardridge serwisowy
potrzebny do tego kabel fix.

przyklad uzycia: bootujemy atari z programem ktory skonfiguruje pamiec vbxe na carta serwisowego, zapisze w nim program. po tej operacji uruchamiamy dowolna gre, naciskamy kombinacje klawiszy konsoli i reset, atari wykona zimny start bez kasowania pamieci, uruchomi sie kart serwisowy, program na karcie kopiuje sie w wybrany obszar pamieci i dezaktywuje karta. w tym momencie mamy w pamieci gre i nasz program ktory moze posluzyc jako ripper.
inny przyklad: nagrywamy obraz karta z gra i zimny reset - gra sie uruchamia

a skoro potrzeba zrobic kabel fix to przy okazji:

4. kabelek podlaczony do audio in w gniezdzie carta lub sio. rejestr na stronie d6 do ktorych dostep ma mini cpu rdzenia. pozwoli generowac dzwiek bez udzialu 6502.

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

2

do rejestrow sprzetowych nie zapisze ci mini cpu, midi cpu, ani nawet haj tower cpu - ka pe wu?

przechodze na tumiwisizm

3

Pixel shaders mają być i kropka.

What can be asserted without proof can be dismissed without proof.

4

> do rejestrow sprzetowych nie zapisze ci mini cpu, midi cpu, ani nawet haj tower cpu - ka pe wu?

a gdzie napisalem ze zapisze?

wyraznie napisalem ze nie zapisze:

>(zapis do rejestrow oraz do pamieci vbxe - wiadomo, ze z poziomu np blittera nie zapiszemy rejestrow sprzetowych ale jak bedzie minicpu w rdzeniu to przynajmniej bedziemy mogli czytac co zostalo do rej.sprzetowych wpisywane)

to teraz wolniej napisze: bedzie mozna czytac to co zostalo do rejestrow sprzetowych zapisane przez 6502 a znajdzie sie jako cien w pamieci vbxe poprzez:

> oraz kontroli zapisu do pamieci vbxe gdy zaslaniana jest przez rejestry sprzetowe

jeszcze wolniej:

umozliwic konfiguracja memacA gdy czesc pamieci vbxe zaslania rejestry sprzetowe aby zapis do rejestrow sprzetowych (przez 6502) powodowal zapis rowniez do pamieci vbxe (tej zasloietej)

a to jest mozliwe.

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

5

w celu?

przechodze na tumiwisizm

6

Czy nie jest tak że:

1) w FPGA brakuje miejsca i było już tłumaczone, że nawet usunięcie blittera (skądinąd już używanego przez istniejący soft) nie zwolni go tyle, żeby zrealizować MPU?

2) zastąpienie blittera przez MPU spowoduje spadek wydajności, gdyż obecnie blitter potrzebyje 1 cyklu na odczyt bajtu i jednego na zapis, a MPU potrzebowałby jeszcze cykli na odczyt rozkazów?

Tak tylko pytam.

KMK
? HEX$(6670358)

7 Ostatnio edytowany przez electron (2011-01-05 08:15:36)

A po co pisać, przecież i tak 75% "scenowców" powie, że to nie jest atari i won z tym z konkursów na przykład,
A po co pisać, skoro potem przyjdzie Tebe i powie, że rdzeń zmienia się co chwila i to zniechęca,
A po co pisać, skoro i tak tylko XXLowi (a może aż?) będzie chciało się coś na taki rdzeń robić,

Prawdą jest, że w rdzeniu FX nie ma miejsca kompletnie. Cudem się ostatnie bugfixy pokompilowały.
Dołożenie MPU zamiast blittera też się raczej  nie uda - blitter aż tak dużo nie zajmuje, żeby zwolniła się wystarczająca ilość miejsca, cięcia musiałyby być większe. Prawdą jest, że MPU w zadaniach typowo blitterowych (przesyłanie, wypełnianie itd.) będzie dużo dużo wolniejsze od istniejącego blittera. Prawdą jest, że byłoby o wiele bardziej uniwersalne. DOstęp przez MPU do rejestrów sprzętowych VBXE (ale tylko VBXE) byłby możliwy. Oczywiście rdzeń FX i tak pozostałby rdzeniem "wiodącym" a taki zmieniony byłby co najwyżej dołączany do konkretnej gry.

Decyzję czy coś robić uzależniam ostatecznie od tego, czy ktoś jeszcze wyrazi zainteresowanie i np.spiszemy umowę na 3 gry ;-).

pomidor

8

elc: moze zapowiadany jakis czas temu devpack by xxl wystarczyl? sam wyrzuci co chce z core, doda emulacje z80, bedzie dolaczal/wczytywal odpowieni core razem z gra.

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

9

3 gry ok, ale z grafika w 256 kolorach

przechodze na tumiwisizm

10

@drac030
owszem, to jest jasne. trzeba przedyskutowac za/przeciw, sprawdzic jaki bedzie koszt takich modyfikacji (kosztem jakich funkcji vbxe mogly by byc wprowadzone). ja zauwazylem, sa funkcje vbxe, ktore fajnie wygladaja ale na papierze, uzytecznosc maja albo ograniczona albo nie maja jej wcale - to moje zdanie, byc moze inni programisci odnajda w pomysle jak w pierwszym poscie cos co pozwoli im pchnac jakies swoje projekty na vbxe do przodu. po wtore, tak, emulowany blitter bedzie wolniejszy (o ile nie wiem, mozna sie dowiedziec) ale wzrosnie uzytecznosc takiego rozwiazania a tego nie mozna niedocenic.

@electron
karta vbxe rozpoczales pewna rewolucje... jest pewien niedosyt i trzeba to doprowadzic do konca, takie jest moje zdanie.
z tym 75% przesadziles ;-) teraz sprawdzam i tylko 66% wybralo "pomidor" :D
Tebe jak to Tebe... czeka tylko zeby wbic zebiska w nowy rdzen ;-) (*)

> cięcia musiałyby być większe

jak duze. podejrzewam, ze jestes zwolennikiem pelnego cpu, wez pod uwage ze moze nie wszystko w takim cpu jest potrzebne a funkcjonalnosc nadal bedzie zachowana.

> że MPU w zadaniach typowo blitterowych (przesyłanie, wypełnianie itd.) będzie dużo dużo wolniejsze od istniejącego blittera

tak, to jest jasne. moglbys powiedziec cos, oczywiscie teoretycznie o szybkosci takiego cpu?

> Decyzję czy coś robić uzależniam ostatecznie od tego, czy ktoś jeszcze wyrazi zainteresowanie i np.spiszemy umowę na 3 gry

jesli nie bedzie zainteresowania to biore to na siebie :p

@jellonek
zanim napisalbym emulacje gtia na poziomie tej electrona to dopadnie mnie kryzys wieku sredniego, kupie harleya i bede podrywal cycate 20-stki. innymi slowy moge miec juz inne priorytety ;-)

to bardzo, bardzo zly pomysl, juz raz o tym pisalem. sam devpack to zly pomysl, udostepnianie zrodla corea to tez zly pomysl i programowe przelaczanie corea to tez bardzo zly pomysl.


(*) Luz Tebe.

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

11 Ostatnio edytowany przez jellonek (2011-01-05 16:39:41)

devpack ztcp ma gtia
chodzi o to ze w koncu naocznie sam bys sie przekonal ze tam juz nie ma miejsca na taki cpu jakiego bys chcial...
to po prostu przytepilo by twoje gdybanie.

ps. drac030 uzywa blittera, czyli glownej rzeczy ktora chcesz usunac...

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

12

to ze nie ma miejsca wszyscy wiedza (ja tez ;) rozchodzi sie o to co usunac, zeby miejsce sie znalazlo...

tak, blitter w takiej formie zniknie ale pojawi sie cos bardziej uzytecznego co zreszta moze 'emulowac' rowniez blitter, pytanie czy szybkosc bedzie do zaakceptowania.

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

13 Ostatnio edytowany przez electron (2011-01-05 20:04:01)

XXL, nie siej zamętu.

Jeżeli nawet powstanie coś nowego to rdzeń FX nie będzie zmieniany i zostanie jak jest. Ewentualny rdzeń pod te 3 kolorowe super - gry byłby tylko takim ładowanym razem z grą skokiem-w-bok.

pomidor

14

niestety nie będzie nowego rdzenia, byłem w Toruniu gdzie mieszka Electron, czekałem aż wyjdzie z pracy, potem rozjechałem jego dupsko po asfalcie, tak że temat można zamknąć

aha, pamiętajcie że zrobiłem to dla Was ...

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

15

Jak dla mnie, to jedna sprawa jest najważniejsza. Rdzeń bez bajerów, bez blitterów, bez zbędnych komplikacji - rdzeń w pełni emulujący GTIA. Chodzi o to, by był rdzeń na którym wszystko chodzi tak, jak na oryginale. Szczególnie chodzi o "błędy systemu pal". Osobiście wydaje mi się, że na początek to jest najważniejsze, bo od tego warto zacząć a reszta softu na rdzenie FX jest napisana jak do tej pory w pewnym sensie niedbale. Przepraszam, że do tego stopnia się wpier***, lecz instrukcja do karty mówi np. o $D6, lub $D7 a 90%  programów na sztywno zakłada, że karta jest na $D6. Jest kilka wersji rdzenia i trochę softu do karty, przy czym prawie co program - to inny rdzeń no i prawie wszystko uwiązane na sztywno do rejestrów. Rozumiem, że na razie są to testy, bo jeszcze nic nie jest pewne na 100% i nie można mówić o żadnym standardzie. Stąd mówię na początek o czystym GTIA, bo jest to standard sam w sobie, a mając VBXE zyskujemy na wstępie zajebistej jakości obraz a to, dla malkontentów i zarazem użytkowników / odbiorców / kupujących być może jest najważniejsze. A poniekąd w tym wszystkim chodzi też o popularyzację karty, bo sądzę - że na to zasługuje.

Tymczasem tyle ;)-

Kontakt: pin@usdk.pl

16

Wstydzę się to mówić, ale Pinokio ma rację :)

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.

17

kazdy glos mowiacy 'blitter musi odejsc' odbieram jak glos poparcia ;-)

nie... jako glos poparcia dlatego go odbieram, ze wlasnie ta wspolna plaszczyzna jaka jest pelna emulacja gtia jest najwazniejsza a nie widze kurczowego trzymania sie fx ;)

oczywiscie nie kwestionuje FX dla vbxe jako standard... potrzebuje czegos podobnego do tego standardu ale bardziej uzytecznego ...

@electron: jesli ten "skok w bok" bedzie mial emulacje gtia to nie sadze zebym zmienil go na rdzen fx ...

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

18

pin: to opierdol autorow tych 90% "sztywniakow" ze nie wykorzystali kodu przez draca zamieszczonego w atariki.

btw. ten kod mozna prosto wykorzystac dodajac gdzies w preinicjalizerze tablice wystapien 0xd6 jako adres, po czym po wykryciu karty na 0xd7 przeleciec sie po zawartosci tablicy adresow inkrementujac znajdujace sie pod tymi adresami wartosci.
wystarczy dodac do inicjalizacji tyci-tyci kodu + troche danych (do nadpisania po inicjalizacji - reusable space) na tablice wystapien 0xd6
to wcale nie takie trudne...

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

19

pin, a konkretnie, to ktory soft tak sie trzyma d6?
generalnie, to jestescie zabawni - prawie zaden nie napisal NIC na vbxe, za to wszyscy macie jakies rozczenia - zenua...

ani mi, ani elekronowi nie chce sie  robic nic dla narzekaczy - dajcie cos z siebie

od xxla wymaga sie czegos co nie jest konwersja - ani z zadnego komputera 8 bit, ani z  flasha, javy, ani czegokolwiek innego

przechodze na tumiwisizm

20 Ostatnio edytowany przez drac030 (2011-01-06 05:50:07)

Ja osobiście jestem zadowolony z rdzenia FX takiego jakim jest, blitter mi odpowiada. Oczywiście fajnie byłoby mieć super-hiper MPU (wiadomo, że twór procesoropodobny byłby *zapewne* elastyczniejszy), ale nie zamiast blittera. Najwyżej oprócz. A na oprócz, jak wyżej napisano, nie ma miejsca.

Czy nie można z tym poczekać do (obiecywanej na ostatnich Głuchołazach) wersji 3.0 z większym FPGA?

KMK
? HEX$(6670358)

21 Ostatnio edytowany przez xxl (2011-01-06 11:35:59)

co zmieni kolejna versja vbxe w moim przypadku? co zmieni w przypadku tych kilkudziesieciu osob ktore maja wersje obecne?

jeszcze raz powtarzam, nie chce zmieniac standardu ktorym obecnie jest rdzen fx. mowie o rdzeniu ktorego baza ewentualnie moze byc fx ale nie bede sie upieral jesli baza bedzie rdzen emulacji gtia !


---
jesli miejsca jest tak dramatycznie malo to mozna wybrac tylko to co jest faktycznie uzyteczne a bajery wylatuja, przyklad:
- tylko 3 tryby: tekstowy 80, tekstowy 40, graficzny 320, tylko 2 szerokosci obrazu
-  tylko 2 priorytety dla overlaya (nad/pod playfieldem)
- mapa atrybutow wlaczana zawsze z xdl wielkosc zawsze taka jak komorka trybu xdl (dla trybu graficznego overlaya brak mapy atrybutow)
- planarna organizacja mapy atrybutow dla pixela i tla (duzo prostrza)
- kolor0 zawsze przezroczysty dla overlaya i m.atrybutow
- usunac detekcje kolizji overlaya
itp.

dla mnie najwazniejsze jest to co napisalem w pierwszym poscie, co do reszty mozna zawsze podyskutowac...

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

22

drac030 napisał/a:

Czy nie można z tym poczekać do (obiecywanej na ostatnich Głuchołazach) wersji 3.0 z większym FPGA?

A na jakiej zasadzie ma wyjść 3.0? To będzie coś lepszego od V1 i V2 i użytkownicy tychże znajdą się w głębokiej d...? ;)

23

Tak jak napisał Jacques. Czy wersja 3xx, 4xx będzie oznaczać (z uwagi na większą pojemność procka), że posiadacze starych wersji będą w głębokiej dupie? Bo tak wynijka z postu Drac030 :/

Sikor umarł...

24

Candle i Electron na Głuchołazach będą bezpłatnie wymieniać VBXE 1.0 i 2.0 na 3.0

organizatorzy Głuchołaz powinni spodziewać się dużej frekwencji

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

25

dokladnie tak bedzie
bedziemy bezplatnie wymieniac wczesniej zakupiona v3 w komputerach zainteresowanych

zawsze to jakis gratis, nie?

przechodze na tumiwisizm