Taktowanie jest teraz 28 MHz i jest specjalna wersja rdzenia oczywiście.

Jeszcze łyżka dziegciu.

Z powodu braku zasobów rdzeń FX VGA został odrobinkę "przycięty":

- zamiast 4 palet są 2 palety (0 i 1)
- nie działa detekcja kolizji rastrowych overlay<->playfield/pmg (kolizje blittera działają)
- nie działa dodatkowy 1 bitowy overlay w hires (ten robiony przez mapę koloru)

Ilość palet ... no trudno, ponad 3/4 programów na vbxe używa do 2 palet, zabrakło RAMu w FPGA z powodu konieczności zmieszczenia sporego bufora linii.
Pozostałe braki: nikt nie używał dotąd tych funkcji - ich wycięcie jest wymuszone koniecznością znalezienia miejsca na logikę VGA w układzie.

Oczywiście te ograniczenia są tymczasowe i wynikają z braku zasobów układu FPGA EP1K50. VBXE3 będzie miało nowe dużo nowocześniejsze i większe FPGA i standardowo wyjście VGA.

i rownie wazne pytanie czy po zwolnieniu miejsca w vbxe1 karta otrzyma:

1. tryb tekstowy podobny do gr.0 (obecnie brak a przydalby sie w atari tryb 256znakowy w standardowej rozdzielczosci)
2. blitter zyska funkcje rysowania odcinkow

Simus: kwarcem - AVR juz jest przetaktowany, ale wiedzialem ze ruszy (projekt uzebox - 28MHz@3.3v - fabryka daje 16MHz)
vbxe na pokladzie ma dzielnik, wiec miales skad wziasc 14mhz dla atarki - problem z seria XL, ktore potrzebuja 3.5MHz (ktore w tej chwili ma 7...)

ten o którym mówisz jest w Amidze, a jako że jej nie chciałem pruć, to dałem to co miałem na półce luzem - dla vga to bez znaczenia, a ze się z clockiem 4.43 nie zsynchronizuje jakoś mnie nie interesowało

A ja mogę ?

W tej chwili rdzeń VGA zrobiony został dla VBXE2 bo Candle ma większe szanse go sprawdzić, mi brakuje monitora itd.

Dla VBXE1 taki sam funkcjonalnie rdzeń można zrobić jak najbardziej, potrzebne są nieco inne przeróbki sprzętowe:

VBXE2:

- nowy rdzeń,
- podłączyć SYNC VGA do LED i RDY na płytce VBXE2,
- zmienić kwarc na płytce VBXE2 z 14 na 28 (z groszami) MHz
- sygnał zegarowy do FREDDIE podłączyć w innym miejscu na płytce VBXE2

VBXE1:

- nowy rdzeń,
- podłączyć SYNC VGA jeszcze nie wiem gdzie, ale RDY chyba odpada, bo trudniej odłączyć od płyty Atari, coś wymyślę
- wstawić nową płytkę PCLK (tą przy Freddie) aby wytworzyć zarówno 28 jak i 14 MHz,

To wszystko jest w miarę proste i jak najbardziej wykonalne dla obu wersji VBXE.

ile do VBXE1 i kto to zamontuje? No i czy stare wyście będzie działa? (RGB) - choć chwilowo brak monitora i/lub tv...

w ogole to tak, kiedy to coz - jak czas pozwoli, na v3 uklad juz bedzie BGA

Simus: poeksperymentowalem z kwarcami w jednym ze swoich lcd - coz - nou gou - 11.cos mhz - out of range - wyswietla jakies glupoty (np hsync 23khz), 4mhz - nie wstaje nawet matryca - zegar dla matrycy za wolny, 8mhz - to samo co przy 11mhz - wiec co mi tam - 20mhz - ten sam efekt
bazowy byl 14.31mhz
to byl prosty monitor na genesisie 2120, moze jutro znajde czas na eksperymenty na nowszych genesisach, ewnetualnie sprobuje na czyms z pixelworksem

Ostatnio edytowany przez Candle (2010-07-28 01:20:58)

to do niczego nie prowadzi, poki czas bo szykuje sie i tak mala rewolucja z vga:

2. calkowite usuniecie blittera a w jego miejsce wprowadzenie do rdzenia dowolnego procesora nawet w okrojonej wersji (blitterka bedzie mozna sobie samemu napisac a oprocz tego rysowanie odcinkow, operacje matematyczne, przedefiniowanie kolormapy i 100 innych rzeczy)
3. rozdzuielenie rejestru MEMAC_CONTROL na dwa: jeden odpowiedzialny za umiejscowienie okna z dokladnoscia do 1 strony (starszy nibbel starego), a drugi do ustalenia wielkosci okna + dostepy antic i cpu (mlodszy nibbel starego), dodanie przynajmniej 2 nowych wielkosci okna $100 oraz $ffff. jesli sie da to gdy rejestry sprzetowe zaslaniaja okno memacA zapis powinien miec miejsce do rejestrow oraz do pamieci vbxe

nie zapinaj o punkcie 1:

1. tryb tekstowy podobny do gr.0 (obecnie brak a przydalby sie w atari tryb 256znakowy w standardowej rozdzielczosci)

szalenstwo zacznie sie dopiero gdy ktos poprosi o rozpiske bankow pamieci flash vbxe zeby przetrzymywac w jednym z nich hiscore z gier...

no wlasnie.... :-)

nie piszesz programow pod wszystkie rdzenie tylko ten ktory Ci pasuje (user ma we flashu rdzenie na taka okazje do wyboru - narazie, poniewaz intensywnie nalezalo by pracowac nad tym zeby uaktualnic stare programy - jest na to czas bo jest ich malo) a poza tym: ile obecnie osob pisze na vbxe, podejrzewam ze z 5. wystarczy ich wlasnie zapytac co sie sprawdzilo a co nie w vbxe - nikt wczesniej nie mogl przewidzec co bedzie potrzebne a co bedzie tylko fajnym bajerem. obecnie jest tak, ze blitter (na poczatku wydawalo sie to dobrym pomyslem) kopiuje tylko prostokaty i koniec (nie ma funkcji blittera znanych z amigi). zapomnij o wektorowkach, zapomnij o wypelnianiu, dostalismy zajebxxx karte graficzna do statycznych obrazkow! czy o to chodzilo?
zerknij na te 3 punkty ktore wymienilem, pierwszy naprawi to co atari spieprzxxx na poczatku, poza tym mnie sie przyda ;) - przegladajac specyfikacje starych plyt arcade 90% z nich operuje w trybie tekstowym przy 256 znakach + kilka planow z atrybutami (o tym dalej) konstruktorzy mieli nieliche dokonania dlaczego nie skorzystac. punkt drugi pozwoli dopiero na uzywanie karty w pelni, bedziesz mogl napisac sobie blitter jaki chcesz, dzieki temu tez nie trzeba bedzie w przyszlosci ruszac modulow vbxe (o wlasnie np.atrybutow) nie trzeba bedzie wprowadzc grubych zmian w rdzeniu (ewentualnie poprawki cpu w rdzeniu) Electron nigdy nie powinien udostepnic zrodel rdzenia powinien tylko umozliwic rozwoj oprogramowania (biblioteki np. wypelnionych wektorow bedzie mozna sammu dopisywac). krotko mowiac i bardzo upraszczajac to obecnie najbardziej zaawansowana gra na vbxe moze byc oparta tylko na kopiowaniu bitmap na overlayu...
trzeci punkt to rozwiniecie funkcji memac A. idea memaca to chyba najlepszy pomysl electrona, zaloze sie ze tez o tym myslal... przydalo by sie wiecej strony zero ;-)

wydaje mi sie jest to ostatnia szansa na zmiany electron i candle beda produkowac nowe karty, userow bedzie coraz wiecej, ten kto bedzie pisal pod nia programy dojdzie do takich wnioskow predzej czy pozniej. ale kto odwazy sie wtedy na grube modyfikacje?

----
moze to zadziala na wyobraznie: chcesz miec emulator spritow c64? punkt2+3

Ostatnio edytowany przez xxl (2010-08-08 14:59:07)

To ja się podepnę. Ponieważ nagle (i niespodziewanie) sypnęło mi feedbackiem - podziękowania - z prośbami o equalizery oraz raportami o błędach, a przy tej okazji sam też coś znalazłem (znaczy baga), to od dziś u mnie na stronie dostępna jest nowa wersja sterowników do VBXE dla SDX - tzn. S_VBXE i 80-kolumnowej konsoli. O tu:

http://drac030.krap.pl/pl-vbxe-pliki.php

Candl mylisz sie z z80 i ULA ale gdyby punkt 2 i 3 przeszly to z80 i ule mozna by zaemulowac rowniez :-)
jesli nazywasz obrotem to co zrobil autor altirry to biednie, ale trzeba mu przyznac sprytne tyle ze dla blittera nie mozna ustawic skoku innego niz liczba calkowita (i to jest dokladnie to o czym pisze wyzej) przy obecnym lapie w leb rysowanie odcinkow chociazby.

"docelowo bedzie udostepniony protokol do wybierania rdzenii wraz z projektem szkieletu tagiego rdzenia - wlasnie po to, aby sobie kazdy mogl cos takiego napisac
bobik/cpu wraz z pr0be pracuja nad biblioteka 3d, ktora spokojnie mozna oprzec o vbxe (jako uklad wspierajacy operacje rastrowe (rysowanie odcinkow /wypelnianie trojkatow) jak i matematyczne (operacje na maciezach, mnozenie wektorow przez maciez) (slowo kluczowe: mozna)" bedzie (moj dopisek)

czyli pisanie wlasnych rdzeni i podmianka w locie tego co potrzeba... nie kwestionuje tego pomyslu ale pomijajac ze eliminuje sie tym posunieciem userow vbxe1 to jak sakramencko daloko jest od 'user frendly'.

"nie podoba mi sie nachalnosc, z jaka starasz sie przeforsowac swoje pomysly"

to nie nachalnosc, to zrowy rozsadek :-)

jedyny argument przeciwko jaki uslyszalem to to ze nie wem ile zajmuje rdzen proca - tak nie wiem ile zajmuje po skompilowaniu ale sadzilem po zrodlach... pawdopodobnie blednie.