A bo rozmawialiśmy na IRCu o playerze Świętego dla POKEYa i się przeniosło...

http://atariki.krap.pl/index.php/Franny to służy do manipulacji .atr'ami.

A czy mógłbyś mi podać numerek kernela, z którym ta opcja działała?
Oglądałem ostatnio źródła modułów msdosfs i vfatfs w 2.6.32 oraz dosfstools 3.0.11 pod kątem montowania partycji st w linuxie i jest tam kod, ale z tego co widziałem kompiluje się to tylko dla platform opartych o motkę 68k :/ A miło byłoby móc używać partycji st w x86 (choćby z cf).
W kernelach dla Ubuntu 10.04 support dla partycji st jest automatycznie wkompilowany.

Edit: ...i może dla wcześniejszych też, ale nie wnikałem.

Ja postaram się również przybyć. Liczę na to, że tym razem nic mi nie przeszkodzi.

Ale poziom wyżej jest coś takiego: http://www.puisoft.co.uk/atari/ataricx8 … fnotes.zip

Asie. Pisałem o tych konwerterach tu. Problem jest taki, że nie wszystkie myszy USB działają (być może zmienił się protokół). Moja Logic M-1 kupiona ze 3 lata temu działa, ale już Modecom też M-1(wygląd identyczny) kupiona rok temu nie.

Tak więc możesz sobie włączyć rysowanie sprajtów przez GTIA i DMA dla sprajtów w ANTICu a wyłączyć DMA dla dlisty, bo można tym sterować osobno.
Skąd kod wie, że jest rysowana linia? Bo wystąpiło przerwania DLI (o ile ustawiłeś je w odpowiedniej linii ekranu) i właśnie CPU w nie wszedł. To którą linię aktualnie rysuje ANTIC/GTIA masz w VCOUNT.
Poziomej pozycji nie ma, ale nietrudno ją wyliczyć (w pamięci) wiedząc w którym cyklu koloru zgłaszane są przerwania DLI i ile cykli koloru trwa jeden takt CPU (trwa 2). Cykl koloru to szerokość jednego piksela w trybie OS 15 (2 pikseli w OS 8).
Tak więc jeśli w przerwaniu masz instrukcje:

pha
pla
rti

to możesz na początek założyć, że Twoja procedura wykona się w 7+3+4+7=21 cyklach CPU a więc w czasie rysowania 42 pikseli GR.15.
7 pierwszych taktów to przyjęcie przerwania przez CPU (odłożenie adresu powrotu + rejestru znaczników na stos, i skok pod adres zawarty w NMIVEC), 3 cykle to pha, 4 cykle to pla, 7 cykli to rti. No i tak dalej.
Ponieważ NMI są obsługiwane przez OS to opóźnienie wynikłe z wykonania rozpoznania źródła przerwania i skoku do wektora DLIV wyglądające tak:

  bit NMIST
  bpl jvblk
  jmp (dliv)
jvblk:
  ... ;to nas nie interesuje
  

zabiera jeszcze 4+2+5=11 cykli CPU.

Przerwanie w trybie tekstowym wykonuje się w ostatniej linii wiersza.

"DLI wywołane od środka linii" to uproszczenie - procedura wywołuje się jak zawsze, ale na jej początku znajduje się opóźnienie.

Ej, Sikor! Poczekaj z koronacją aż ankieta się zakończy. Albo osiągniesz przynajmniej progonozowany sukces.

No ja chętnie wezmę te, co zamawiałem - czyli L i S.

Z biblioteką  obsługi VBXE jest jak z OSem - co nas obchodzi jak ona to zrobi? Wywołujesz funkcję i ma działać. Martwimy się jak OS ładuje dane z C:? Nigdy. Kwestia napisania odpowiedniej biblioteki/rozszerzenia OSu.

IMHO taka biblioteka pozwalająca na zarządzenie rdzeniami w VBXE mogłaby być przydatna koderom każdego rodzaju aplikacji do określenia konfiguracji sprzętu. Widziałbym to, jako rozszerzenie OS tak, żeby aplikacje miały dostęp zawsze do aktualnej wersji biblioteki w systemie, a nie do tego z czym aplikacja była skompilowana.

A skoro tak, to deklarowałbym się jako chętny do stworzenia takiego rozszerznia, oczywiście o ile Candle i Electron wyrażą zgodę. Potrzebowałbym jeno konsultacji oraz sugestii ze strony ludzi używających/piszących pod VBXE co mogłoby być w takiej bibliotece potrzebne. Uprzedzam z góry, że do tej pory nic, ale to nic nie napisałem dla VBXE.

Ale przecież FC jakoś potrafi zbootować wybrany rdzeń? Slotów jest 4 (VBXE1) i 13 (VBXE2) więc oprogramowanie, które chciałoby użyć konkretnego rdzenia mogłoby sprawdzić czy takowy jest dostępny, po czym go łaskawie włączyć, a po zakończeniu działania przywrócić stary. Jak user zaś nie ma rdzenia, to ERROR! i dziękujemy.

Edit: ...lub też "ERROR! Proszę załadować wymagany rdzeń", lub jeśli sami go dostarczamy z aplikacją, znajdujemy wolny slot i pakujemy do VBXE. Mogłaby przecież być biblioteka do takich rzeczy dostępna.