Powinno się nic na forum nie mówic tylko ci co to zrobią powinni zrobić i na sam koniec podac do wiadomości ze jest gra na karcie ale za to jakim. Pokazac efekty. W naszym narodzie nikomu i nic nie pasuje zwykle.

@secon: to nie do końca tak. Autorzy poruszają problem na forum właśnie dlatego, że im raczej zależy na opiniach i sugestiach - i to jest bardzo dobre. Często jest tak, że powstawał genialny produkt, w którym jeden mały, prosty do wyeliminowania szczegół, czynił go nie tym czego użytkownicy oczekiwali. Więc lepiej z nimi porozmawiać.

Nie traktuj tej dyskusji jako narzekania - tym bardziej, że nie zauważyłem, żeby ktokolwiek krytykował produkt Nosty'ego. Wszyscy są nastawieni raczej entuzjastycznie, pojawiają się jedynie sugestie w jakim kierunku można by pójść i dlaczego. I to jest twórcze. I temu służy publiczna dyskusja. Efekty zostały pokazane. Wywołały odpowiednie wrażenie :)

Adam, o tym samym pomyślałem: http://www.atari.org.pl/forum/viewtopic … 45#p155545

Cos wam powiem. Dokładnie tak ma VBXE - standard (Hardware) by default i API w postaci programu ładującego rdzenie DCFG.COM dla nietrwałej lub FC.COM dla trwałej podmiany rdzenia przez dowolny program zewnętrzny.

I co ?

Czy KTOKOLWIEK napisał własny rdzeń poza mną ?

Tak: Bobik dla własnej nauki, Candle na własne potrzeby .. i koniec.

90% pozostałych "opinotwórców" nawet nie wie, co można co nie i pojawia się sporo durnych legend, pomimo, że dokumentacja, schematy i odpowiednie programy są dostępne w sieci od dawna i uaktualniane co jakiś czas w paczkach.

Więc o czym tu mówić?

Tak więc jedynym sensownym rozwiązaniem wydaje się mi związanie konkretnego wydania carta z konkretną grą i tyle.

No to masz w VBXE rdzeń, używaj, o co chodzi... Aaaa, nie ma funkcji której potrzebujesz? :) To nie problem, mozesz sobie dopisać :)

elc: mial byc dev-kit z egzamplowym corem, tj. jego zrodlami i? oczywiscie to twoj wybor by nie udostepniac zrodel (czyli niech zainteresowani pisza od zera). przy takim podejsciu czemu sie dziwisz?
candle pisal od zera nie znajac twoich zrodel?
robiac sprzet, przynajmniej wie ktore linie fpga gdzie sa powyprowadzane.
oczywiscie (majac vbxe) samemu mozna to obczaic, ale takie rzeczy sie dokumentuje.

wlasnie dlatego prosze by od samego poczatku nosty udostepnial zrodla...

Ale ja się nie dziwię że nikt nie ruszył tego na tym poziomie (rdzeniowym) - jest to mi zupełnie obojętne. Ja się dziwię, że przy otwartym systemie jakim jest vbxe ludzie nie potrafią rozwiązać prostych problemów i zapanować nad chaosem, który sami wytwarzają - a w wielu wypadkach wystarczyła by na przykład świadomość jaki rdzeń mam załadowany.

Sprawa nie jest trywialna, a ja nigdy nie powiedziałem, że teraz zalewam rdzeń betonem i już do końca świata się nic nie zmieni. W rdzeniu udostępniam np nr wersji do odczytu, z resztą należy sobie już radzić - na poziomie programisty i użytkownika. API FX (są źródła) wspiera rozpoznawanie wersji.

Poza tym nigdy nie obiecywałem źródeł do rdzenia FX i nigdy nie miałem zamiaru ich wypuszczać. Nie jest to potrzebne dla zrobienia samemu czegokolwiek a kursy hdl są wszędzie dostępne. Są za to dostępne źródła examplów dla FX.

A nie wiem. Ma źródła od jakiegoś czasu i ma je gdzieś z tego co wiem, nie patrzył w nie (nie lubi Veriloga) tak jak i ja nie patrzę w jego (nie lubię VHDL). Jestem pewien, że nie potrzebuje ich do napisania czegokolwiek co by chciał.

Schematy do wszystkich wersji vbxe są w paczkach, dostępne na sieci. (www.spiflash.org).

Wybor Nostyego. Może gdy źródła będą w C to coś to komuś da. Może komuś podetrze to nosek i wyczyści pupę.

Przepraszam Nosty za zaśmiecanie, już kończę.

i ponownie wątek o Tomku stał się wątkiem o vbxe...

@wieczór: nie jestem przeciwny robieniu akceleratora (z podmianą cora czy bez), gdzie ja to napisałem ?...

na moje projekt ma swojego autora, który nic nie mówiąc przyszedl i to zrobił, zbudował i jest to co jest, jest to tanie wiec kazdego stac tez na programator i kazdy kto potrafi programowac w assemblerze 6502 z pewnoscią zrobi to w C pod Micorchipa, jest cała masa gotowców w sieci, tony pdf, książek, tutoriali. Jeśli nosty nie chce ustandaryzować projektu i stworzyc API tylko bedzie to chodziło jako combo (inne z kazda grą) to warto poprosic autora o wersje DIY jako otwarty projekt i otwarte źródła lub za jego zgodą zrobić calkowicie niezalezny port, bo jak juz pisalem zastosowan widzę wiecej niz tylko wspieranie grafiki(nie bez przyczyny wspominałem o obsludze wątków). Możliwe, że Nosty za wczesnie odkrył wszystkie karty jednak nie sądzę by teraz zrobił krok wstecz, nie byłoby sensu jest przecież swiadom, że kazdy kto kupi gre to i tak rozbebeszy carta i projekt podzieli się na obozy...reszta mniej istotna,....czy to problem podwojncyh odczytów... to problem po stronie atarki...niech każdy pisze swój driver a jak ktoś chce dekodować dwie linie albo i nawet 10 i na które strony czy cwiartki to klasc to już trzeba pomyśleć zawczasu, cart umie przecież czytać.

@XXL: jak jeszcze raz uslysze udostepnic zrodla to nie wytrzymam.

no nie bądź pies ogrodnika :)

Electron - brawo :) Doskonaly wywód zamykający gęby wszystkim narzekaczom. Popieram każde słowo :)

No i zarąbiście , bądź zadowolony, o to przecież chodzi :) A co Ci przeszkadza, że ktoś wysuwa jakieś sugestie? Bo narzekania nie zauważyłem

moze to kogos zaciekawi.

1. mozemy w pamieci karta TOMEK8 tworzyc obraz w trybie graficznym, rysowac odcinki czy stawiac tilesy, sprity itp. natomiast wyswietlanie ANTICa ustawic na tryb tekstowy i wymusic ze jesli ANTIC odwola sie do pamieci TOMKA to ten wysle dane w postaci trybu tekstowego. ustawiamy generator znakow na $d4, pamiec obrazu ANTICa sluzy teraz do ustawiania atrybutow natomiast generator znakow ktory w tym momencie bez uzycia DLI bedzie mial 960 znakow dla trybu GR.0 basica.

2. pamiec ekranu moze byc stworzona z tilesow (cegielek wielkosci 16x16 pixeli), TOMEK8 wygeneruje pamiec obrazu z 240 tilesami w 1000 cykli 6502... innymi slowy - szybko.

3. dostep do pamieci obrazu przez ANTICA tylko 'cwiartka odczytu ANTICa', jesli chcemy bezposrednio zapisywac lub czytac pamiec ekranu musimy odwolywac sie do 'cwartki odczytu/zapisu 6502' na stronie $D5 - tak, ze jednoczesne czytanie przez 6502 i Antic pamieci obrazu oraz zapis przez 6502 jest mozliwy