26

A jeśli chodzi o wykorzystanie adresów strony $D6 czy $D7 to nie widzę problemów. Na każdej z nich dostępnych jest 256 adresów, tylko niefrasobliwość wcześniejszych projektantów spowodowała że teraz obudziliśmy się z ręką w nocniku. Ale jest na to sposób. Na stronie $D6 jest TTP i do jego dekodera adresów dolutować można 8 diod krzemowych + jeden opornik 2k i TTP ma TYLKO jeden adres właśnie $D600, pozostałe do wykorzystania. To samo ze stroną $D7. Jeżeli decydujesz się użyć jakiegoś adresu z tych stron to proponuję $D6FF lub $D7FF bo bardzo łatwo zbudować dekoder pełny tylko na te adresy i nie będzie konfliktu, a przy dobrym zaprojektowaniu pod tymi samymi adresami będziesz miał rejestr do zapisu i odczytu, nie potrzeba komplikować układu jak rozwiązania narzucaja się same.

27

Bardzo dziękuję wszystkim, którzy się wypowiedzieli. Zauważyłem, że większośc jest przychylna pomysłowi. Cieszę się więc bardzo i mam nadzieję, że uda się wprowadzic pomysł w życie. Ponawiam więc pytanie, które umieściłem w pierwszym poście: Czy podjąłby się ktoś zaprojektowania i wykonania elektroniki? Ja z pewnością nie znajdę na to czasu. Ostatnio mam jego spory deficyt i dlatego chcę skupic się tylko na jednym wiadomym projekcie. Mam natomiast propozycję. Mianowicie mogę wesprzec finansowo realizację całego przedsięwzięcia. W ramach takiego projektu widziałbym następujące czynności:
1. Zaprojektowanie elektroniki, wykonanie prototypu, przetestowanie w komputerze, wykonanie drugiego egzemplarza dla mnie.
2. Wprowadzenie odpowiednich zmian w najpopularniejszych emulatorach.
3. Wykonanie 3-ch "soczystych" grafik w G2F wykorzystujących nowy tryb (mogą byc screenshoty z gier z innych komputerów).
Oczywiście projekt byłby dla wielu osób. Za pierwszy punkt płaciłbym w ratach w miarę postępu prac i prosiłbym tu o dokumentację tych postępów na zdjeciach. Za pozostałe punkty płaciłbym po wykonaniu prac. Oferty (o ile w ogóle będą :-) ) proszę przysyłac na ikplus(at)NO_SPAMpoczta.onet.pl

28

Jeżeli chodzi o dekodowanie D6 i D7 to VBXE używa dla celów programowania FPGA / FLASH adresów c0 - ff ale posiada specjalne złącze z własnego dekodera adresowego, na którym dostajemy sygnały następujące:

00 - 3f odczyt
00 - 3f zapis
40 - 7f odczyt
40 - 7f zapis
80 - bf odczyt
80 - bf zapis

Samo VBXE "rdzeniowo" będzie korzystać tez z tych obszarów - ale nie wszystkich, można więc pomyśleć o wykorzystaniu tego dekodera - specjalnie tak to zrobiłem aby dało się to użyć.

Powiedzmy zarezerwuję "sobie" z tego 80 - bf (czyli w sumie 80 - ff) a niżej może być coś innego.

Tak piszę, jakby ktoś chciał wyważać otwarte drzwi i generować konflikty.

pomidor

29

mogę wykonać prototyp, podaj schemat na meila..

30

Nie dysponuję w tej chwili schematem. To też należy zrobic w ramach projektu. Jeżeli nie będzie chętnych, to sam spróbuję narysowac. Ale tak jak pisałem - krucho z czasem.

31 Ostatnio edytowany przez Pin (2008-03-17 14:57:16)

działać - lecz przemyślanie. Chodzi o kilka spraw:

* czy modyfikując w ten sposób GTIA otrzymujemy 100% zgodności wstecz?
* czy wybrany rejestr na 100% nie koliduje z popularnymi dopałami?
* na ile możliwe jest wykrycie modyfikacji bez znaczącej rozbudowy układu?

za i przeciw - w sumie im bardziej jednolity standard - tym mniej problemów. Można by powiedzieć, że obecnie dwie modyfikacje mają szansę na "doczekanie" się lepszych czasów. Dopałka by MadTeam, oraz VBXE. Z czego mi wiadomo w ostatnim opisanym przypadku na dzień dzisiejszy zrobiona jest pełna emulacja "starego" gtia - więc zgodność winna wynosić 100% przy uzysku co najmniej możliwości podłączenia monitora RGB;- co stanowi porażająco wyższą jakość obrazu. I to już jest wiele, nie mówiąc o tym, czego można na tym potencjalnie dokonać :) - Co do dopałki MadTeam - pomysł dobry, aczkolwiek szkoda, że wymaga on zdekompletowania innego komputera - co ostatecznie prowadzi wprost do wyginięcia sprawnych egz. komputera marki Atari :) - Zaczekamy, zobaczymy. Ja osobiście obstawiam na VBXE - bo jak już coś robić - to konkretnie ;)

teoretycznie jeśli pierwsze dwa punkty spod (*) rozpatrujemy pozytywnie, to nie mam nic na przeciw implementacji pomysłu w VBXE. Oczywiście, jeśli ktoś tego dokona - bo ja nie potrafię "se" napisać :)

Kontakt: pin@usdk.pl

32

to o czym mowicie vbxe tez potrafi, moze lepiej zglosic taka opcje do electrona?

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

33

o ile sie orientuje - nie bedzie problemu w dodaniu tego nowego tryby do obecnego core vbxe - tak wiec kwestie kompatybilnosci mozna sobie darowac (dla electrona to pikus raczej bedzie).
pin - jesli bedzie to programowalnie wyl./wl. przy uzyciu jakiegos rejestru - gdzie widzisz mozliwosc "utraty kompatybilnosci w tyl"
w/g mnie pomysl rewelacyjny - bo dajacy fajne mozliwosci, przy stosunkowo bardzo malutkiej elektronice (spooooro tanszy niz vbxe).

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

34

Każdy głos poparcia mile widziany :-)
Jeżeli chodzi o zgodnośc wstecz to ja nie widzę żadnego problemu. A nowe produkcje używające rozszerzenia będzie można przecież puścic na maszynie bez rozszerzenia. Tylko efekt wizualny będzie mniej estetyczny. To o to chyba chodziło Mikerowi.

35

Nie, nie i jeszcze raz nie. Poprzez szerokie zebranie zamówień wydaje mi się, że VBXE zostało wybrane jako przyszły standard i skupmy się na nim chociażby dlatego, że JEST i DZIAŁA. Zaraz się bowiem okaże, że przyjdzie ktoś i powie, że jak się dołoży dwa druty i metr sznurka to uda się dołożyć jednego duszka oraz 2 pociski. Chodzi o ustandaryzowanie czegoś, wdrożenie i niejako poprzez to spowodowanie pisania programów na dane rozszerzenie. Co z tego, kiedy będzie bazylion różnych, prostych "dopałek" kiedy nikt (z piszących programy) ich mieć nie będzie?

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.

36

Popieram zdanie dely'ego. Acz z trochę innych względów: dopałka ikplusa, jak rozumiem jej ideę, może się przydać w zasadzie tylko do gier, czyli mi osobiście do niczego. VBXE jest bardziej uniwersalne i to jest następny powód, dla którego bym je popierał zamiast.

KMK
? HEX$(6670358)

37

ciezko zrozumiec co napisalem? dodanie tego trybu do vbxe to pikus...
to ze wy zamowiliscie ten sprzet nie oznacza ze stanie sie on popularny i zmuszanie innych na sile do "jedynegoslusznegorozwiazania" to czyste przegiecie.

tak wiec dely: dziekuje za twoja wersje zdazen ale prosze nie mowic o bazylionie rozwiazan skoro mamy do wyboru tylko jedna wchu*.* wypasiona dopalke za bazylion zlociszy, druga nieco tansza ze bardzo skromnym zainteresowaniem, oraz trzecia dajaca konkretny efekt przy fchui malym koszcie (chyba w jednym galu sie da calosc zawrzec).

drac030: dlaczego zamiast? skoro vbxe moze byc pierwsza dzialajaca realizacja tego trybu? co ci szkodzi cos wiecej, co moze sie przydac innym? tu nie tyle jest cos "zamiast" ile "rownolegle obok".

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

38

W różnorodności siła.
Ewentualny problem mogą mieć organizatorzy party w zapewnieniu sprzętu dla wystawianych prac, lecz tylko w przypadku gdy rozszerzenia z sobą by kolidowały.
BTW. Czy ktoś wie co się dzieje z rozszerzeniem psychola? IMHO zapowiadało się DOSKONALE!
VBXE jest wspaniałe, ale nic nie stoi na przeszkodzie, żeby dostępne były różne dodatki do naszej maszyny.
Nie blokujcie Panowie (i Panie) inwencji twórczej.

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

39

No miały być już pierwsze płytki zamawiane - a nagle (jak to w zwyczaju ostatnio ma) PSYCHOL wsiąkł.

40

hmm, ładnie to wygląda, ale czy nie za ładnie? żeby zmienić wartość w rejestrze, potrzeba kilka cykli. animowany obiekt przesuwa się w poziomie, możliwe jest żeby nie zmieniał koloru? moje pytanie jest takie, co ile pikseli można byłoby zmienić kolor?

41

dely i drac030:
Panowie, przytoczę jeszcze raz to co pisałem juz wcześniej:
>Od strony programisty jest to tylko jeden dodatkowy rejestr. Czyli mamy "nowszą" wersję GTIA z 33-ma rejestrami zamiast 32. VBXE, które emuluje układ GTIA, mogłoby emulowac właśnie tą "nowszą" wersję. Chodzi o to, aby przyjąc 33-ci rejestr za standard, tak aby programiści konwertujący dziś gry działające w trybie wysokiej rozdzielczości a nie korzystające jeszcze z dobrodziejstw VBXE mogli używac tej dodatkowej możliwości. Tak więc podsumowując to proste rozszerzenie nie jest konkurencyjnym projektem dla VBXE lecz powinno się w VBXE zawierac.

Ponadto, jak pisze jellonek, dodanie tego rozszerzenia do VBXE jest trywialne.

jellonek: Zgadzam się z twoim komentarzem, choc miejscami jest on może zbyt dosadny :-)

luka:
Różny kolor obiektów statycznych można uzyskiwac poprzez zmianę koloru tła (o której piszesz jak sądzę) oraz poprzez podkładanie sprite'ów, których kolor, położenie i rozmiar też mozna zmieniac w trakcie wyświetlania obrazu. Kolor obiektów ruchomych mozna uzyskiwac w zasadzie tylko poprzez podkładanie sprite'ów. Chciałbym zwrócic uwagę, że w nowym trybie można łatwo używac sprite'ów w największej szerokości, gdzie jeden piksel sprite'a pokrywa jeden znak ekranu (8 pikseli). Dzięki temu można pokrywac sprite'ami znacznie większe obszary ekranu, niż jest to możliwe bez nowego trybu (oczywiście jeżeli chcemy zachowac czarny kolor pomiędzy obiektami).

42

dzięki za wyjaśnienie, tego się mniej więcej spodziewałem, ale nie byłem pewien. pomysł pomimo swoich oczywistych ograniczeń jest świetny, tym bardziej, że atarka nadal pozostanie atarką.

43

spójrzcie na takie C64 DTV, zamiast iść małymi kroczkami można zrobić 1 porządny krok naprzód

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

44

jellonek napisał/a:

ciezko zrozumiec co napisalem? dodanie tego trybu do vbxe to pikus...
to ze wy zamowiliscie ten sprzet nie oznacza ze stanie sie on popularny i zmuszanie innych na sile do "jedynegoslusznegorozwiazania" to czyste przegiecie.

Przegięciem jest także przypisywanie innym spiskowych motywacji. VBXE, powtórzę, jest moze drogie, ale uniwersalne. Odkąd electron zaczął pracować nad VBXE, nagle co raz ktoś wyskakuje z rozszerzeniem do GTIA. Psychol tylko patrzeć, jak się obudzi. Efektem tego będzie właśnie bazylion rozszerzeń, każdy koder będzie miał inne, a gry i tak będą powstawać pod wspólny mianownik, czyli Atari bez dopałek. I już widzę gfx albo intro compo: 1k intro standard, 1k intro ikplus, 1k intro VBXE... po co komu takie zamieszanie? Mamy jedną dopałkę gotową i do tego świetną, po co komu namiastka?

drac030: dlaczego zamiast? skoro vbxe moze byc pierwsza dzialajaca realizacja tego trybu? co ci szkodzi cos wiecej, co moze sie przydac innym? tu nie tyle jest cos "zamiast" ile "rownolegle obok".

Ale nie rozumiem, po jaką cholerę to ma być w VBXE implementowane? Czy któryś z zaprezentowanych przykładów takiego trybu graficznego jest nie do zrealizowania (i to łatwiej) na VBXE _bez_ tego rozszerzenia? A odwrotnie, czy którykolwiek z trybów pracy VBXE (bazylion duszków w pierdylionie kolorów np.) jest do zrealizowania na tej dopałce _bez_ VBXE?

Co do ceny: VBXE jest drogie może dlatego, że electron sprowadza układy FPGA w detalu. W hurcie to one pewnie kosztują dużo mniej, pokazywano mi ostatnio jakiś ekwiwalent za 20 złotych...

KMK
? HEX$(6670358)

45

drac030: to zamow hurtem, a sam wezme od ciebie 2 sztuki po 40zl (procz ukladu jakas plytka i drobnica...)

po jaka cholere wchodzilismy w trencinie na "galerie"? bo jest, bo mozna, bo sie da sie.
mozna to zaimplementowac w innym trybie, ale co stoi na przeszkodzie by zrobic to tak, aby sie dalo na fchui tanszym sprzecie miec chocby namiastke, potrzebna wylacznie do gierek?
co do odwrotnosci - vbxe ma byc fullwypas do niewiadomojakichzastosowan. tu masz tani konkretny przyklad do raptem kilku gier. nie do dem, nie do programow narzedziowych - do kilku specyficznych gier. co by latwiej dotarlo - TU JEST INNY TARGET.

co do mnogosci prac na kompo - spodziewasz sie ze przejdzie gdzies cos innego niz antic? btw. obecnie masz 3 propozycje rozszerzen - gdzie ten bazylion? od tych 3 juz glowa boli? o ile psychola rozszerzenie rzeczywiscie jest niekompatybilne z vbxe - o tyle zarowno psycholowe, jak i elektronowe bardzo prosto moga byc kompatybilne z tu zaproponowanym. a skoro moga byc - to po co bic piane w stylu NIE, BO NIE.

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

46

jellonek napisał/a:

drac030: to zamow hurtem, a sam wezme od ciebie 2 sztuki po 40zl (procz ukladu jakas plytka i drobnica...)

Ja nie mogę. Ale to nie znaczy, że nie znam kogoś, kto może.

mozna to zaimplementowac w innym trybie, ale co stoi na przeszkodzie by zrobic to tak, aby sie dalo na fchui tanszym sprzecie miec chocby namiastke, potrzebna wylacznie do gierek?

Po to, żeby w pełni wykorzystywać możliwości bardziej zaawansowanej dopałki, zamiast w sofcie pisanym na VBXE *pdolić* się z cyklowaniem, celem uzyskania żałosnego efektu, który jednak "jest kompatybilny z większą ilością atarek" (czyli VBXE + ikplus).

tu masz tani konkretny przyklad do raptem kilku gier

Po co nam to całe zamieszanie dla "raptem kilku gier"?

co do mnogosci prac na kompo - spodziewasz sie ze przejdzie gdzies cos innego niz antic? btw. obecnie masz 3 propozycje rozszerzen - gdzie ten bazylion?

Trzy to jest właśnie bazylion. Spójrz na to od strony kodu: wykrycie dopałki, plus PO CZTERY wersje tej samej procedury (1. standard, 2. psychol, 3. ikplus, 4. VBXE). Przy czym, jeśli ktoś będzie chciał uniknąć tego całego bajzlu, napisze dwie wersje: 1. standard, 2. ikplus (bo to chodzi też na VBXE). W EFEKCIE będziesz miał na VBXE, które bije na głowę STE i Amigę razem wzięte, soft jak na popsutym Spectrumie :P

KMK
? HEX$(6670358)

47

w najnowszym konkursie Sikora będzie nagroda w postaci VBXE :) i dzięki temu wszyscy będą mieli VBXE

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

48 Ostatnio edytowany przez electron (2008-03-19 23:39:06)

Taka mała uwaga: układy FPGA, które można nazwać "ekwiwalentami" stosowanego w VBXE starego już ACEX EP1K50 są rzeczywiście dzisiaj dostępne 2 razy taniej niż EP1K50 ... Jednak projekt korzeniami sięga przełomu 2003 / 2004 (!) i wówczas ten układ to był w zasadzie jedyny dobry wybór - szczególnie, że akceptuje na wejściach poziomy logiczne 5V a nowsze rodziny nie i trzeba wstawiać bufory do konwersji napięć.

Ponieważ projekt robię sam w wolnych chwilach to technika idzie naprzód szybciej niż jestem w stanie nad tym zapanować - należy więc zamrozić rozwój hardware i je wypuścić w obecnej postaci co też uczyniłem.

Oczywiście w przyszłości można się pokusić o nowszy FPGA a do środka wrzucać (na początku przynajmniej) te same rdzenie co do VBXE. Nie można jednak przesadzić i co 5 szt. zmieniać projekt. Myślę, że obecna postać jest póki co finalna.

Acha ... niestety, nie jest w interesie producenta obniżać ceny starszych układów (FPGA) - więc mamy paradoks, że nowsze, lepsze i większe są tańsze - ale po prostu trzeba się z tym pogodzić.

PS> W tym tygodniu będę miał już wszystkie części (FPGA jadą do mnie).

pomidor

49

electron napisał:
PS> W tym tygodniu będę miał już wszystkie części (FPGA jadą do mnie).

No to ekstra. Już bym chciał to to w kompie. Jeju - lepsza grafa niż w Amidze.
Ja jestem za VBXE i w tę stronę bym szedł, ale z drugiej strony ten pomysł z dodatkowym trybem nie jest zły tyle tylko że dla atarynek bez VBXE.
Pomysł był by rewelacją gdyby powstał i wszedł w użytek przed pomysłem electrona.
Konwersje ze spektrumny (może to będą konwersje z ST) mogą też bajecznie wyglądać na VBXE.
No ale jak ktoś chce mieć więcej bajerów w kompie to ja nie protestuję.

Atari 130XE, LDW Super 2000, Atari410.

50

powtorze moze pytanie - ile osob, np. do konca tego roku, bedzie miec vbxe?
spoko - bedzie mozna jeszcze prosciej robic konwersje, ale dla ilu osob?
wiekszosc i tak bedzie mogla zobaczyc tego typu konwersje wylacznie na jakims party, o ile ktorys z posiadaczy vbxe sprzet zabierze...

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