...

Pomyślałbym, bo on mi się przydał wcale nie ze względu na to, że mieści się w pamięci. Przeciwnie, wystarczyło okno 8k. Ale możność zmapowania trybu grafiki bezpośrednio do pamięci, tak żeby miał do tego dostęp 6502 (dokładnie tak jak w przypadku trybów standardowych) *oraz* blitter, to jest zaleta, bo nie trzeba bankować RAM-u (przynajmniej dla mnie jest to zaleta, bo ja nie lubię bankowania).

"Gdyby w VBXE był CPU" - no ale nie ma. W standardowym Atari też wielu rzeczy nie ma, a jednak programy powstają, bo programiści umieją wykorzystać to co jest zamiast przykrajać sprzęt do własnych umiejętności/pomysłów.

Co do CPU, z twoich słów wynika, zdaje się, że dążysz do tego, żeby zrobić z VBXE oddzielny komputer - w takim układzie, zauważ, to CPU, żeby można było uniknąć mapowania trybu do przestrzeni adresowej 6502, musiałoby być co najmniej złożoności normalnego procesora typu 6502 albo Z80. Już nie mógłby to być uproszczony procesorek pomocniczy, gdyż w takim wypadku konieczność mapowania VRAM-u do dostepu dla 6502 ciągle by zachodziła, a tu możność zmapowania jej w jednym kawałku - to zaleta.

Ogólnie dyskusja jest akademicka, bo jak nadmienił electron, w rdzeniu nie ma miejsca na nowe rzeczy.

PS. Aha i jeszcze jedno:

Łatwym do przewidzenia skutkiem będzie to, że soft będzie wykorzystywał tylko to, co działa w obu rdzeniach. Albo nie będzie powstawał wcale (vide postawa tebego, ja szczerze mówiąc też już w pewnej chwili miałem dość, kiedy się okazało, że blitter zmienia się z wersji na wersję - na szczęście się ustabilizował i mi przeszło).

Ja osobiście jestem zadowolony z rdzenia FX takiego jakim jest, blitter mi odpowiada. Oczywiście fajnie byłoby mieć super-hiper MPU (wiadomo, że twór procesoropodobny byłby *zapewne* elastyczniejszy), ale nie zamiast blittera. Najwyżej oprócz. A na oprócz, jak wyżej napisano, nie ma miejsca.

Czy nie można z tym poczekać do (obiecywanej na ostatnich Głuchołazach) wersji 3.0 z większym FPGA?

A sorry, nie zauważyłem. :)

Co gierka robi: na wstępie zeruje obszar od $C000 do $E9FF (czyli zeruje rejestry sprzętowe, ale trudno powiedzieć, po co z takim rozmachem). Patch ogranicza to do $C000-$D4FF - co polega na zmianie 1 bajtu.

marekp: a że tak z ciekawości zapytam, dlaczego nie chcesz tych doców (HYP, STG) odpalać na ST?

Candle: to nie jest "sprawa wtórna", skoro kolega utrzymuje, że po fizycznym odłączeniu klawiatury BASIC też się nie pojawia:

No chyba że odłączona klawka ma ten sam skutek, co wciśnięty OPTION - nie mogę teraz sprawdzić :)

Jeśli chodzi o klawiaturę, to jest to (o ile mi wiadomo) typowa przypadłość. Przez klawiaturę idzie zasilanie do czerwonej diody sygnalizującej włączony prąd (lewy donly róg klawiatury), w chińskich klawkach niestety powoduje to w końcu uszkodzenie folii dla klawiszy konsoli. Przypuszczam, że uszkodzenia START i RESET też się możesz wkrótce spodziewać.

Koledzy pewnie udzielą rad, co można z tym zrobić oprócz wymiany folii.

Gorzej z BASIC-em. Czy masz pośród programów jakiś DOS i Turbo BASIC XL?

No tak, racja, Adam chciał DD. Ale on ma Falcona, DD czy HD, nie pamiętam, żeby była jakaś różnica inna niż taka, że DD nie dało się sformatować na 1,44 (acz bywały wyjątki i tu, por. sławne "sznurki"). Natomiast HD na 720k - jak najbardziej, czemu nie.

Rozumiem: po prostu tego nie sprawdziłeś na żadnej grze.

@mono: chciałem odpisać dokładnie to samo, co pirx, alem został ubieżon...

"Podświetlenie ustawione na memory, ale nic się nie da zrobić" - czy to podświetlenie miga?

Wszystkiego najlepszego... btw. to tacy młodzi już mówią? :P

No i tu własnie fundamentalnie błądzisz, bo DOS jest po to, żeby nie trzeba było (= żeby program użytkownika nie musiał) pamiętać, jaki jest filesystem, ani liczyć sektorów. Fakt, że niektóre DOS-y tego nie zapewniają świadczy tylko o tym, jak są prymitywne i gdzie powinny wylądować. Na szczęście Atari jest tak zrobione, że można sobie DOS wybrać.

Jak już o tym była mowa, to nie jest żaden bug, SDX nie będzie poświęcać ~40 cykli przy _każdym_ przełączeniu banków (a robi to _bardzo_ często) na zachwywanie stanu MEMAC A, skoro bez większego wysiłku (i tylko przy ładowaniu danych) może to zrobić sam program.

Przyznaję, że jeśli chodzi o ideę DOS-a wymyśloną przez Atari, wynalazek jest groźny :) Jakiś sterownik wprawdzie wciąż jest potrzebny, ale znacznie mniej skomplikowany i, gdyby ktoś chciał zrobić serwer plików na PBI, prawie całość można władować do ROM-u PBI. Albo wkompilowywać do binarek. I wtedy koniec z możliwością wyboru DOS-a, użytkownik jest skazany na coś w rodzaju tego, co mamy na C-64 albo ST (niemożność poprawienia DOS-u, bo jest w ROM-ie, ani biblioteki I/O, bo jest statycznie zlinkowana z milionem programów).

Moim zdaniem ideałem jest mieć jedno i drugie, tj. normalny DOS (wcale nie zajmuje 8 KB głównej pamięci, a jedynie do 6,5 KB - Sparta X ma standardowe memlo w okolicach $1000, czyli zajmuje 2,5 KB głównego RAM-u - plus oczywiście 1 bank ext :) ) obsługujący dysk lokalny oraz możliwość dostępu do dysków "sieciowych".

Głównym ograniczeniem DOS2DOS jest spory narzut "komunikacji służbowej". Można go oczywiście nieco zmniejszyć przez optymalizację protokołu, ale to będą, wydaje mi się, groszowe oszczędności. Żeby to uleczyć radykalnie, potrzebny jest po stronie Atari kod buforujący np. jednobajtowe operacje FREAD/FWRITE, no i bufory, a na to z kolei trzeba przeznaczyć cokolwiek RAM-u. Czyli DOS-a nie da się tak znowu prosto pozbyć, nawet jeśli się go statycznie wkompiluje do programu.