http://sjp.pwn.pl/sjp/rzeczowy;2518591.html

Wymagałoby też napisania kilkunastu albo wręcz kilkudziesięciu pluginów do SC pełniących rolę modułów przeglądających. A i tak pewnie trzeba byłoby mieć do nich plik konfiguracyjny.

Teraz jest runext.cfg, a SC wykorzystuje istniejące programy, np. mona bmpview czy playery do muzyczek cmc itp. Miałby to wszystko dublować? To lekko bez sensu mi się wydaje.

@pin: Co do rotozoomera, potrzebujesz wersji podlinkowanej tu (post #5):

http://www.atari.org.pl/forum/viewtopic ... 10#p201710

Dla pewności: r3.exe, 32492 bajty, 19-01-2015 19:54

EDIT: oczywiście, że można się zapisać na betatestowanie...

Co do planów wydawniczych, nie tylko ode mnie to zależy. Ja osobiście wypchnąłbym już tę wersję, którą mamy, wydaje się, że jest dostatecznie przetestowana.

Co do tego, co nowego, trudno mi tak w jednym zdaniu to ogarnąć. Zmian w stosunku do 4.46 jest sporo: plik whatsnew-447.txt jest dwa razy większy niż whatsnew-446.txt. SC niestety nie jest jeszcze doprowadzony do końca, wiem, za długo to trwa, ale tak jakoś schodzi. Czy w FATFS.SYS już teraz będzie zapis, też trudno powiedzieć, w sumie nie jest to trudne, może się uda.

Kod ASCII (w dec.) znaku pod kursorem.

Przeto trzeba skontaktować się z autorem. Mogę zdradzić w tajemnicy, że LIST "DPRN:" koniec końców wywołuje z ROM-u procedury obsługi drukarki te same, które woła LIST "P:".

Że LIST "DPRN" (bez dwukropka) tworzy plik na dysku, temu bym się nie dziwił.

Tylko kiedy? Na sztabach ani zlotach się nie zjawiasz.

Seban, ochłoń, trochę dystansu do świata nikomu nie zaszkodziło. Nie wiem, jak jest gdzie indziej, ale w tym wątku to Ty się nakręcasz, "mowa nienawiści" itd., to nie ma sensu.

Jeśli na liście dialogowej często występowały słowa "schneller, schneller", to mógł to być film o II wojnie światowej ... ;)

Ok, zmierzyłem jeszcze raz:

1) seek z pozycji 0 na pozycję 16777215: 2,1 sek.
2) seek z pozycji 16777215 na pozycję 0: 3,36 sek.
3) odczyt 16777215 bajtów (porcjami po 8k): 4 min. 16,26 sek.

Sprzęt: Atari 65XE (6502/1,77 MHz/320k RAM), IDE+, SDX 4.47, partycja 32 MB w formacie Sparty.

To mój czysty domysł, ale zgaduję, że takie właśnie może być pochodzenie systemu plików SpartaDOS: żeby dostęp do pliku na dysku AtariDOS był swobodny i miał ręce i nogi, trzeba plik zindeksować. Czyli co najmniej raz przeczytać go od początku do końca i wygenerować oddzielny plik indeksu, zawierający kolejne numery sektorów pliku. Korzystając z tego indeksu można już wykonywać swobodne seeki po całości, oczywiście tylko do chwili, kiedy zajdzie potrzeba przekopiowania pliku na inny dysk - wtedy indeksowanie należy zrobić na nowo.

Stąd pewnie, jak się domyślam, koncepcja, żeby ten "indeks" DOS generował w locie dla każdego pliku. W postaci mapy pliku. A skoro już mamy mapę, 3-bajtowy link w sektorze danych staje się niepotrzebny i tylko zawadza.

Gołe 48k. 128k dość komplikuje adresowanie, co na pewno odbiłoby się ujemnie na wydajności emulacji (a ta i tak ledwie co sięga 100% oryginału).