Odp: FGTIA Scandoubler V1.0
tak, zgadza sie
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
BigPEmu 1.12 Richard Whitehouse wydał BigPEmu 1.12
FujiNET firmware v1.3.0 Nowa wersja oprogramowania do interfejsu sieciowego FujiNET. Tym razem z obsługą TCP!
hatari 2.5.0 Od dwóch dni dostępna jest najnowsza (2.5.0) wersja Hatari.
Grawitacja 2024 Czas na kolejną edycję 8 bitowego GameJamu.
Tenebra na Atari ST/STE Wersja gry na duże atari.
Strony Poprzednia 1 2 3
Zaloguj się lub zarejestruj by napisać odpowiedź
I tylko ten problem, że te parę linijek się już nie mieści. Szkoda.
nie miesci sie w fx'ie - miesci sie w gtia
w fx-ie dodatkowo jest problem pixel clocka przy trybach hi-res - potrzeba 2x tyle (28mhz)
tryby hi-res to przypomne 80 kolumnowe text-mode i tryb 640/16kolorow
Dlatego ja bym optował za rozwiązaniem zewnętrznym wg koncepcji Simiusa ma to kilka plusów:
1. Nie trzeba nic modyfikować w VBXE - zmieszczenie linijek nie jest problemem
2. Jest to bardziej uniwersalne, można użyć też z czymś innym
Pytanie tylko brzmi jaki jest tego koszt, bo działające scandoublery istnieją - problemem jest tylko ich cena
wieczor: ja bym byl za tym bys lepiej juz skonczyl...
Candle, to skoro już wiesz, o jakie FPGA chodzi, to może jeszcze raz rozważycie z Electronem przesiadkę? Mam nieodparte wrażenie, że i zmieści się, co trzeba, i popracuje szybciej, i układ się trochę uprości (odpadnie ATMega). Wydaje mi się, że zgodnie z tym, co napisał Draco, wybór między FX bez scandoublera i GTIA ze scandoublerem (za tę samą cenę przecież) wypadnie zawsze na korzyść tego pierwszego. Oczywiście, jako alternatywa pozostaje wciąż przystosowanie płytki FX do zewnętrznego scandoublera.
nastepna platforma dla vbxe to Altera Cyclone II (EP2C8F256I8N) - jest to uklad prawie 7x wiekszej pojemnosci niz obecny Acex1k i nieco tanszy - przy okazji nie trzeba kupowac zaraz calej tacki tych ukladow
jesli chodzi o FPGA ze stajni Actela to tutaj na przesiadke nalezalo by namawiac nie mnie, a Electrona i zapewnic odpowiednie zestawy ewaluacyjne
przy '51 ktos musialby przepisac kod z assemblera AVR do assemblera '51 lub pobawic sie w rekompilacje kodu w C dla procesora PIC z wersji pierwszej - wielkiego sensu to by nie mialo - wykozystanie pamieci konfiguracyjnej ukladu Actela tez jest kwestionowalne - mamy wszak wiecej niz jeden rdzen
koniec koncow fpga od actela wyglada ciekawie, ale chyba jednak nie do tej bajki
Nie bardzo rozumiem o co chodzi z tym przekodowywaniem AVR na 8051. Możesz przybliżyć?
actel ma core '51 albo cortex m3
w vbxe2 jest avr atmega48 i kod do komunikacji vbxe<->atari i mcu->fpga byl pisany w assemblerze AVR - trzeba by bylo to przepisac na '51 albo na cortexa
Ciągle nie bardzo rozumiem. Wybacz, ale sam nie posiadam VBXE, jeśli coś na ten temat było na forum, to nie czytałem, więc wytłumacz jak lajkonikowi. To VBXE nie jest obsługiwany przez CPU 6502 poprzez rejestry sprzętowe, jak normalne GTIA, tylko potrzebuje do tego osobnego procesora komunikacyjnego? Jaką drogą w takim razie przebiega ta komunikacja i do czego jest potrzebna? Co robi ten procesor.
AVR (PIC dla v1) zarzadza rdzeniami ktore sa zapisane na flash'u (SPI Flash w v2, DataFlash w v1)
VBXE posiada n slotow na rdzenie dla FPGA, ktore mikrokontroler laduje do FPGA po wlaczeniu zasilania
dla v1 to bylo 6.5s na wczytanie konfiguracj FPGA z DataFlasha, dla v2 to jest 150ms
komunikacja z tym kontrolerem od strony uzytkownika odbywa sie przez program fc.com - od strony sprzetu to jest jeden rejestr sprzetowy poza fpga do ktorego uzytkownik ma zawsze dostep, bez wzgledu na to co sie dzieje z zawartoscia flasha - tj mozesz podniesc karte z pustym flashem
po czasie potrzebnym na boot jest jak mowisz - rejestry GTIA sa mirrorowane przez FPGA jak i rejestry rdzenia FX sa juz w srodku FPGA i od tad mozna zapomniec ze AVR/PIC istnieje
idea byla taka, aby mozna bylo uaktualnic firmware karty za kazdym razem jak wyjdzie nowy rdzen i do tego wlasnie potrzebny byl mcu - vbxe nie posiada pamieci konfiguracyjnej dla fpga w sensie w jakim zwykle sie to rozumie, tylko wlasnie takie mcu ktore przewala odpowiedni core oznaczony jako "bootowalny" przez uzytkownika
sam program mcu jest rowniez flashowalny (v2 ma bootloader)
Czyli jest tak, jak zapamiętałem z dawniejszych dyskusji - zewnętrzny procesor służy do bootowania rdzenia. Myślałem, że może coś jeszcze się po drodze urodziło. Niewątpliwie, ładowanie nowego rdzenia do FPGA przez juzera ma swoje zalety. W FPGA ACTEL wygląda to trochę inaczej. Strukturę rdzenia programuje się we fabryce i koniec. Nie potrzeba już żadnego bootowania. Po włączeniu zasilania po prostu działa. Juzer nie ma możliwości zmiany rdzenia. No chyba, że miałby odpowiedni programator, hasła i aplikację. To z jednej strony pewna niedogodność, ale są i zalety. W końcu chyba nowe wersje przestaną się pojawiać?
Ostatnio edytowany przez Simius (2010-06-14 23:04:54)
widze, ze sie nie rozumiemy
vbxe!=fx core
argument "nowe wersje przestana sie pojawiac" jest w stylu "w koncu atari tez przestali produkowac"
widze, ze sie nie rozumiemy
Też mam takie wrażenie.
vbxe!=fx core
Samo core i nic więcej? A cała ta płytka ze scalakami to jak się nazywa?
argument "nowe wersje przestana sie pojawiac" jest w stylu "w koncu atari tez przestali produkowac"
Tak sądzisz? Nowe wersje Atari OS przestały się pojawiać w 1987r a same maszyny były jeszcze produkowane, zdaje się, do 1992 r.
Simus: chodzi o to by jednak zachować możliwość w miarę łatwego (i wcale nie tak strasznie wolnego - 150ms na starcie to tyle co pół litra na dwóch) wgrywania innych core. to zaleta nie tylko w trakcie tworzenia urządzenia.
pisząc vbxe!= fx core - Candle mial na myśli że można korki zmieniać - czego przykładem są obecnie zarówno fx core jak i gtia.
może ktoś z czasem doda kolejny? (choć wątpię - bo na pytanie o źródła padło "sam se napisz").
sam uklad polaczen dajacy fpga dostep do dac'a i ramu jak i wglad w to co jest na magistrali widzianej przez antic to vbxe
nad tym jest core - np fx
rezygnujac z mozliwosci wymiany rdzeni rezygnowalibysmy z cechy vbxe - bardzo waznej cechy
nikt tutaj nie ograniczyl zastosowania fpga jako karty graficznej - mozliwe sa i inne adaptacje
samo pisanie rdzeni od piszacego wymaga
a) znajomosci pinout'u (dostepny na schematach dla obu wersji karty)
b) znajomosci jednego z jezykow HDL (Verilog/VHDL)
c) zapoznania sie z dokumentacja do antica/gtia jesli go to interesuje
d) mnostwa wolnego czasu na faktyczne pisarstwo
nie wymaga zrodel
fc.com przyjmuje pliki wygenerowane bezposrednio przez pakiet Quartus (*.rbf)
Jeśli samodzielna wymiana rdzeni przez użytkownika jest cechą o kluczowym znaczeniu, to nie ma o czym gadać.
moim zdaniem jest
jesli actel nie moze tego zapewnic, to nie jest to dobre rozwiazanie
najchetniej to bym zaczekal az Electron zajmie jakies stanowisko w tej sprawie
Nie twierdzę, że żadną miarą nie może tego zapewnić. Tak, jak napisałem, to kwestia zakupu programatora za 45$ i ściągnięcia do niego oprogramowania.
Tak, jak napisałem, to kwestia zakupu programatora za 45$ i ściągnięcia do niego oprogramowania.
Zaletą VBXE jest wymiana rdzenia z poziomu Atari. O to bicie piany. Póki co powstają "od czasu do czasu" nowe rdzenie kompatybilne z poprzednimi, ale hipotetycznie samo VBXE może służyć do (prawie) dowolnego celu, hipotetycznie karta może robić za muzyczną, koprocesor, blitter itp. A wszystko to zmieniasz z poziomu Atari.
Inna sprawa - że jakoś nie widać tych ton rdzeni, a osoby piszące coś pod to potrafią sie mocno między sobą gryźć ("wykrywanie VBXE KMKvsXXL" na przykład), dodatkowo zdawkowy support typu "napisz se sam" nie poprawia sytuacji.
Według mnie - póki co należało by się skupić na nowych rdzeniach, a przyszłe wersje muszą być kompatybilne z obecnymi - w tej chwili jest to już jakiś standard sprzętowy. A ludzie są z natury leniwi i niechętni drastycznym zmianom (na przyklad przylutowanie słynnego kabelka, które sobie w moim kompie jeszcze czeka na wykonanie). Ale to jest tylko moje skromne zdanie i być może jest one błędne.
tj 45$ wydalo by n osob, n osob by pobralo odpowiednie oprogramowanie (szacujac (altera, xilinx) okolo 3gb) aby wgrac nowsza wersje rdzenia?
na chwile obecna, gdyby to mialo miejsce, to kosztowalo by to 5400$ i 360gb transferu?
ewentualnie jedna osoba wydaje 45$ i bawi sie w wysylki w te i spowrotem vbxe i programowanie rdzeni?
Czytać nauczyli? Napisałem - jeśli samodzielna wymiana rdzenia przez użytkownika ma kluczowe znaczenie, to sprawa zamknięta i nie wracamy do tematu.
Strony Poprzednia 1 2 3
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.086 sekund, wykonano 13 zapytań ]