76

stryker napisał/a:
Simius napisał/a:

2. Czy ktoś posiada w swojej kolekcji konsolę 5200?

Tak

A tak w ogóle to któryś z kolekcjonerów zachodnich mógłby po prostu WYSKOCZYĆ z tej konsoli. Jak ludziki chcą to mieć u siebie w 5200-tkach, niech kopsną z 1-2 sztuki. Proste! :) Także się może Stryjek nie wyrywaj tak z tym. ;)

I Ty zostaniesz big endianem...

77

Simius napisał/a:

Projekt ma już swoje imię, ale na ujawnienie jeszcze za wcześnie, bo urodzi się dopiero pod koniec listopada. ;) Tymczasem nosi nazwę roboczą GTIARGB.

Czy mamy już finalną nazwę projektu?
Jestem zainteresowny 1 egzemplarzem, jeśli na wyjściu będzie RGB (lub DVI/HDMI).

ATARI 65XE + SIO2BT
http://atari.pl/hsc/ad.php?i=22.3

78

Dzięki uprzejmości Jera sprawa już załatwiona. Dzięki Stryjek za gotowość.
Projekt ma już finalną nazwę - Sophia. Na wyjściu będzie RGB.

Ceterum censeo Germaniam esse delendam.

79 Ostatnio edytowany przez pajero (2016-12-08 19:14:02)

Warto śledzić wątek ma AAge, tam większy ruch.... http://atariage.com/forums/topic/258702 … a-in-cpld/


np.
http://atariage.com/forums/uploads/monthly_12_2016/post-26134-0-95478000-1481140227_thumb.jpg

80 Ostatnio edytowany przez lemiel (2016-12-11 22:58:47)

Simius, to będzie "goła" płytka czy taśma do DB9/15 z takim gniazdem też?
W jakimś standardzie?
Kołacze mi się po głowie podłączenie VBXE w ten sposób.

To:
http://atariki.krap.pl/index.php/Gniazd … orowe#VBXE

81

takron27 napisał/a:

ale cena inna niż vbxe. jeśli ktoś ma egzemplarz(e) xe z bardziej widocznymi pionowymi pasami i chciałby oczyścić obraz, a niepotrzebne mu rozdzielczości vbxe, to zastanowi się poważnie nad zakupem NPGTIA. wyjście komponent też może być powodem zainteresowania. tak ja to widzę...

.. ale nie ma najważniejszej rzeczy, którą ma VBXE z rdzeniem GTIA emu. Emulacji "błędów" pal, więc do grania w riverraid wystarczy być może, ale do demek to wynalazek będzie prezentował się już trochę gorzej.

Kontakt: pin@usdk.pl

82

Jak to nie ma? Przecież Simius pytał o przesunięty o cykl tryb 10 do HIP-a.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

83

VBXE nie obsługuje buga z rozszerzeniem pocisku/gracza na całą szerokość ekranu

Simius będzie to dodane ?

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

84

Jak mogłoby być, skoro Atari tego nie chciało? :) Bo jakby chciało, to przecież w dokumentacji GTIA byłoby o tym wspomniane. To może dwa typy buga z późnych serii GTIA też trzeba emulować, bo ktoś z tego zrobił jakieś demko?
Jest gdzieś w ogóle opis tego buga?

Ceterum censeo Germaniam esse delendam.

85

lemiel napisał/a:

Simius, to będzie "goła" płytka czy taśma do DB9/15 z takim gniazdem też?
W jakimś standardzie?
Kołacze mi się po głowie podłączenie VBXE w ten sposób.

To:
http://atariki.krap.pl/index.php/Gniazd … orowe#VBXE

Na pewno będzie taśma ze złączem micro-match do płytki. Z drugiej strony jest już kłopot, bo nie ma standardu na kabel db9-scart, a tym bardziej na YPbPr. Złącze HD15 (VGA) zaciskane na taśmę, o ile mi wiadomo, w ogóle nie występuje w przyrodzie.

Ceterum censeo Germaniam esse delendam.

86 Ostatnio edytowany przez tebe (2016-12-12 12:44:33)

nie tylko opis, ale i działający efekt wykorzystujący ten bug, napisany przez Phareon-a

http://atariage.com/forums/topic/252503 … try3510283

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

87

Ja jestem w stanie nawet dać więcej niż te 200zł jeśli projekt będzie funkcjonował tak jak "scandoublery" z Individual Computers (Indivision ECS/AGA) w Amidze, tj:
1. Wyjście VGA/DVI (by dało się podłączyć np. do pecetowego CRT, są znacznie lepszej jakości niż PALowskie, a jednocześnie obraz nie wygląda sztucznie)
2. Dodatkowe tryby graficzne (tu - niepotrzebne, jedynie 80 kolumn byłoby pożądane)
3. Wyśrodowkowanie do jakiejś sensownej rozdzielczości VGA (800x600/1024x768), ale bez skalowania, chyba że z zachowaniem proporcji
4. Opcjonalnie, emulacja scanlines/artefaktów.

Wiem, że nie wszystko z tej listy jest do zrealizowania ot tak, ale jako potencjalny chętny piszę co by mnie interesowało w projekcie jako pierwsze.

.: miejsce na twoją reklamę :.

88 Ostatnio edytowany przez skrzyp (2016-12-13 20:31:01)

.

.: miejsce na twoją reklamę :.

89

Mono - no nie wiem, przeczytałem wcześniej to:

Simius napisał/a:
mono napisał/a:

@simius: Skoro to wyjście RGB to:
0. Działa z NTSC?
1. Nie ma artefaktów NTSC?
2. Nie ma PAL blendingu?
Czy mógłbyś poza tym powiedzieć coś więcej o kolorze F - czy to dokładnie średnia między 1 i E w RGB?

0. Działa
1-2. Nie ma dekodowania PAL ani NTSC, więc nie ma efektów ubocznych dekodowania.
Kolor F nie jest dokładnie średnią pomiędzy 1 a E. Mieści się pomiędzy i to wszystko

.. a jeśli nie ma "2. Nie ma PAL blendingu?" to wiem, że w określonych trybach znikają kolorki ;)

Kontakt: pin@usdk.pl

90

@Skrzyp - a z tym dodatkowym trybem graficznym do 80 znaków, to aż zaniemówiłem :D

Kontakt: pin@usdk.pl

91 Ostatnio edytowany przez mono (2016-12-19 11:46:47)

A mnie przyszła do głowy taka featura.
Wszystkie 4 pociski można połączyć w tzw. 5 playera. Bierze on wtedy kolor z COLPF3 ($D019) i wg tego oidp liczone są priorytety i kolizje. Pozycje jednakże dla każdego missila trzeba ustawiać niezależnie. W pewnych sytuacjach jest to wygodne, w innych niestety uciążliwe - szczególnie tam, gdzie należy się liczyć z każdym cyklem (np. podczas zmian położenia sprajtów w rastrze).
Czy można by spowodować, że ustawienie rejestru HPOSMx automatycznie przelicza pozycję pozostałych missili (niechby to zachowanie było konfigurowalne jakimś bitem). Ten ficzer nie musi być uzależniony od połączenia missili w 5go playera (GPRIOR.4=1).
Mielibyśmy wtedy prawdziwego 5go playera. Kolejność pocisków licząc od lewej zgodna z definicją kształtu, czyli M3M2M1M0.

Edit: Ewentualnie niechby zapis do dowolnego rejestru HPOSMx dodawał wartość do aktualnej pozycji każdego missila.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

92 Ostatnio edytowany przez mono (2016-12-19 11:23:24)

A i jeśli to GTIA miałoby działać z SECAM-em, to może dałoby się zwracać w rejestrze PAL wartość 0? :)

Edit: OS i tak zidentyfikuje to jako PAL (AND #%00001110) więc zgodność zostałaby zachowana.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

93

@Skrzyp:
1. Ktoś jeszcze używa jakichś CRT do PC?
2. Czy ktoś potrafi zmusić ANTIC do pobrania z pamięci i wysłania do GTIA danych dla 80 znaków w jednej linii? Czy VBXE korzysta z danych przysłanych przez ANTIC, czy tworzy ten tryb samodzielnie, bezpośrednio czytając pamięć?
3. Może kiedyś w przyszłości coś takiego się wymyśli.
4. Nie będzie emulacji artefaktów.

@Mono:
1. Niestety, podstawowa trudność jest taka, że pozycjonowanie 5 duszka przez zapis do jednego tylko, dowolnego z rejestrów HPOSMx bez większych problemów da się zrobić, ale posypią się kolizje, które obsługuje oryginalny układ.
2. Jeśli wersja dla systemu SECAM powstanie, to zero na jakichś bitach rejestru identyfikacyjnego można by wymusić.

Ceterum censeo Germaniam esse delendam.

94

Simius napisał/a:

1. Ktoś jeszcze używa jakichś CRT do PC?

Ja mam wypasionego Philpsa 21" ... przyjmuje sygnał z każdej karty VGA z prawie dowolnymi rodzielczościami i odświeżaniem do 100Hz.
Nie oddam nikomu :) ... przynajmniej na razie.

95

@Simius: Kolizje to poboczna sprawa w sumie. Nawet gdyby podstawowa funkcjonalność zadziałała, to już byłoby coś.

Tryb 80-znakowy generowany jest przez VBXE na overlayu, a więc ANTIC nie ma tu nic do rzeczy. VBXE czyta dane z własnego VRAM i generuje obraz.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

96

Jesli 'opoznienie' 1 linii ekranu jest do zaakceptowania to mozna uzyc np  trybu antica F i ladowac 2 linie danych potem np 6 pustych linii. Nowe GTIA trzeba tylko poinformowac ze ma te dane inaczej interpretowac. Oczywiscie generator znakow musi byc wtedy w GTIA.
Teoretycznie powinno zadzialac o ile znajdzie sie miejsce na generator znakow.
Plus takiego trybu bylby taki ze zwykle gtia nadal by generowalo obraz - smieciowy ale poprawny.
Zistalo by tez wiecej czasu dla cpu.
(c) willy.

"tatusiu zobacz, narysowałam tobie takie same coś jak na twojej koszulce" 
https://github.com/willyvmm/mouSTer
jmp $e477

97

i dlatego Simius nie powinieneś tu zaglądać, tylko zrobić to "po swojemu" i oznajmić kiedy będzie już gotowe, na końcu i tak się dowiesz że ludzie chcieliby VBXE tylko o połowę tańszego

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

98

Tez jestem tego zdania.

Bardziej chodzilo mi o odpowiedz na 'pytanie' 2 z postu 93.

"tatusiu zobacz, narysowałam tobie takie same coś jak na twojej koszulce" 
https://github.com/willyvmm/mouSTer
jmp $e477

99 Ostatnio edytowany przez mono (2016-12-19 12:59:48)

W takim razie jeszcze kwestia trybu łączenia kolorów sprajtów (GPRIOR.5=1).
Łączenie kolorów zachodzi między PM0+1 oraz osobno PM2+3 i odbywa się to tak, że kolor wynikowy = COLPM0 OR COLPM1 (analogicznie 2 i 3).
1. Czy można by konfigurować funkcję (AND/OR/XOR/NAND/NOR/NXOR)?
2. Ewentualnie czy dałoby się wygospodarować dwa rejestry na wartość takiego nakładanego koloru dla pary 01 i 23?

Edit: I może jeszcze inna featura.
Chodzi o możliwość skonfigurowania koloru dla bitu 0 PMG. Normalnie jest przezroczysty, ale gdyby mógł być nieprzezroczysty (i to jeszcze dla każdego sprajta osobno) to byłoby miło.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

100

Niestety, mamy do dyspozycji tylko oryginalną, 32-bajtową przestrzeń adresową GTIA.

Ceterum censeo Germaniam esse delendam.