To jest dobra zabawa, gdy program z założenia jest "całodyskiem" i używa (hardwarowej przynajmniej) części SIO, przez co na tym poziomie przynajmniej jest zgodny z systemem Atari i wiemy jak go ładować. Ale jest to przynajmniej zamknięta kapsułka, bez ambicji do robienia niepotrzebnych (bo nic nie dających) rewolucji.

Ale xbios to mutant. Ze specyfiki działania zachowuje się jak sztywny całodysk, a mieni się być programem uniwersalnym do obsługi plików. Zdanie xxl-a "xbios bazuje na standardowym filesystemie" świadczy dla mnie o tym, że niestety XXL lekceważy rzeczywistość, która nie pasuje się do Jego pomysłów.

Zastanawiam się, czy osoby, które chcą tego używać chcą to robić dlatego, że jest lepsze, czy dlatego, że łatwiej przeczytać opis kilku funkcji xbiosa niż przekopywać się przez opisy CIO z różnych źródeł. Czyli po prostu lenistwo.

Wystarczy po prostu "nie wykryć" rdzenia fx pomimo jego obecności i sprawa załatwiona, nie trzeba nic przełączać, konfigurować.

tak tak

Kynar - ilozację topimy lutownicą
Tefzel, mylony z kynarem - izolacja teflonowa, wręcz przeciwnie - usuwamy tylko mechanicznie.

Różnica na oko widoczna - kynar jest matowy, tefzel błyszczący.

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ę.

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.

Też uważam, że idea all in one carta dedykowanego dla danej gry jest tu jak najbardziej na miejscu. Np. pozwoli obciąć koszty carta. I nie będzie narzekania, że nikt nic nie pisze nowego na to.

Przepraszam, ale jeszcze tylko dodam coś o vbxe i znikam (szukajcie u Heisenberga).

Mylicie tu rzeczy na poziomie podstawowym. VBXE to zupełnie i absolutnie coś innego niż taki cart i o ile na vbxe można zrobić to samo co na tym carcie to odwrotnie już nie za bardzo. A narzekania o tym, że nie ma produkcji i / lub nie wiadomo jak to programować mogę skwitować tylko pobłażliwym uśmiechem : jak już Wieczor napisał : kurs czytania i pisania by się przydał, bo jedyne czego zabrakło to chęci - ja ze swojej strony zrobiłem wiele - example i pełną dokumentację każdy może sobie pobrać. Kilka osób zresztą udowodniło, że da się.

Nosty: kart jest fajny jako dedykowany do gier na std. konfig i rób dalej swoje, tylko rzeczywiście uważaj na tę stronę D5, żeby nie było konfliktów z np. spartą. No i więcej ram by się przydało w środku.

I ostatnie: wkrótce premiera nowych rdzeni dla vbxe - poprawki emulacyjne i PAL BLENDING - słyszysz PIN ?

SLD KGB
Mają przejebane bo ja się było w PZPR to teraz pewnie trzeba być lewicowcem, co zrobić.
Precz z amnezją.

VBXE ma zegar 14 MHz (8 x f6502)

Zwykłe kopiowanie trwa 2 cykle 14MHz na bajt.
Wypełnianie stałą wartością trwa 1 cykl na bajt.
Kopiowanie z przeźroczystością i sprawdzaniem kolizji od 2 do 3 cykli na bajt (blitter stara się optymalizować dostęp do pamięci i usuwać zbędne operacje).
W grę jeszcze wchodzi sprzętowy zooming poziomy - wówczas blitter odrobinę przyspiesza kopiowanie, biorąc tylko raz jedną próbkę źródłową.

Dodatkowo blitter zużywa około 22 cykli na pobranie BCB i uruchomienie żądanej operacji.

Dodatkowo blitter jest urządzeniem slave szyny VRAM VBXE, więc wszelkie operacje typu:

- pobieranie XDL / XDLC,
- pobieranie mapy atrybutów,
- pobieranie grafiki i fontów do wyświetlenia,
- dostęp 6502 do VRAM (MEMAC A/B)

w pierwszej kolejności dostają przydział cykli zegara 14MHz. Blitter używa tych, które zostaną wolne.

Czyli zależy co jest włączone i używane i jak wygląda obraz generowany przez VBXE to zostaje mniej lub więcej cykli dla blittera.

Przy wyłączonym XDL gdy VBXE wyświetla tylko to, co natywnie produkuje Atari blitter ma dla siebie pełną przepustowość VRAM.

Altirra coś tam się stara emulować, ale wierna nie jest ponieważ nie ma 100% dokładnego opisu zachowania blittera.

Brawo. Ale używanie nielegali jest nieeleganckie i powinni tego zabronić.

Tylko zamęt powstaje z powodu 2K RAMu. XXL szanuję Ciebie za rzeczy które już zrobiłeś, ale z biegiem czasu coraz ciężej mi zrozumieć do czego właściwie dążysz ? Tworzysz jakieś nowe standardy "od czapy" bo nie podoba Ci się to co zostało przyjęte już dawno temu - w efekcie będzie z Twoimi grami jeszcze więcej problemów niż dotychczas zamiast mniej.