SCMAIN.OVL making many memory conflict with flashjazzcat tools - matr, uflash, etc

"Memory conflict" znaczy, że program usiłuje się załadować pod memlo albo nad memtop. Czyli albo naładowane jest za dużo rezydentów, albo tryb graficzny jest "za duży" (np. gr. 8 ), albo jedno i drugie.

:) - załadowałem program, uruchomił się i napisał, że nie mam U1MB :D

Witam,

Sporadycznie korzystam z forum ale muszę pochwalić autora/ów SC .. w koncu  Sparta doczekała się swojego commandera, choć były wczesniej i to jak najbardziej przyzwoite. Tutaj jednak mamy sygnowany przez samych lead developerów od SDX :) co patrząc w historię i rozwój nad spartą zapewnia, że będą konsekwentne dalsze prace i wsparcie.

Od kilku dni korzystam ze SC i zgrywam 20 letnie dyski z których wiele jest uszkodzonych i kiedy SC natrafia na błąd tj. po kilkukrotnych próbach odczytu uszkodzonego sektora (różnych plików) zwraca komunikat: "zbyt wiele otwartych kanałów"
po czym robi zwiechę na amen i nie czyta już nic. W manualu SDX stanowi, że w configu można określić ile kanałów może być max. otwartych jednocześnie i domyślnie chyba jest 4, można ten limit oczywiście zwiększyć ale chyba nie w tym rzecz, ponieważ tutaj przy kilku próbach odczytu bad sectora, SC zwyczajnie zdaje się ich nie zamykać. Jedynie co pomaga to restart. Nie jest to wprawdzie dokuczliwa wada ale warto wspomnieć o jej istnieniu.

Pytanie skierowane do autora/ów (lecz może ktoś inny równie zainteresowany się podłączy do dyskusji, dlatego piszę publicznie),chodzi o to czy SC dałoby się w możliwie łatwy sposób przystosować to pracy ze XEP80.SYS zamiast RC_GR8.SYS?, to samo również dotyczy TT - Trub Terminal podobnie obsługującego RC_GR8.SYS i S_VBXE.SYS, jak rozumuje (słusznie lub nie) oba sterowniki operują na swoim zestawie znaków i mapie obrazu a w przypadku XEP80.SYS szeregowo wypełnia on pamiec w urządzeniu tj. wysyła od razu w konkretne miejsce, oczywiscie w uproszczeniu bo robi to za
pośrednictwem tego co użytkownik wysyła na CON: i E: co dalej przejmowane jest przez sterownik. Jak podaje

https://atariwiki.org/wiki/Wiki.jsp?page=The%20XEP80

to maksymalnie można uzyskać 15,7 Kbitów/s transmisji, co w trybie znakowym nie jest przecież tak mało tj. czytaj "dużo" relatywnie do wieku i pomysłu wykorzystania XEP80 jedynie jako konsoli dla CP/M,SDX + SC, MAC/65 itp. itd.. bowiem jak praca na oknach wygląda na XEP można zobaczyć na którejś z wersji "The Last Word"

Podkreślam jednak, że nie chodzi tu o osobiste wywody nad przydatnością tego rozwiązania lub też nie, archaicznością pomysłu,dlaczego nie VBXE i ogólnie zawracaniem kijem wisły, pytanie jest konkretne tj. skierowane do konkretnych osób i na konkretny temat, nadmieniając, że pojawienie się narzędzi typu Trub Terminal i Sparta Commander rodzi nadzieję na "powrót do łask" porzuconego oniegdyś w kąt szafy XEP i skoro istnieje sterownik to czemu go nie przystosować.

Podam teraz na swoim przykładzie: mam podłączonego po S-video XEP i XE po Composite - nie potrzeba mi dwóch monitorów bowiem jeden przycisk "przysłowiowo" przełącza mi źródło sygnału tj. na jednym chciałbym mieć konsole w 80 kolumnach czyli SDX+SC, CP/M itp.. na drugim Antic/Gtia...dalej Falcon/PC, TV,  DVD..

Rzuciłem jedynie pomysł bazujący na tym jak z punktu użytkownika chciałbym by wyglądała nowa wersja SDX (poza pełną obsługą FAT 16 :). Możliwe, że przeróbka sterownika jest w realizacji zbyt czasochłonna zwłaszcza jeśli konsola CP/M lub SC wymaga w trybie znakowym częstego odświeżania  całego ekranu a to może kosztować zbyt wiele.

jednak przy wolnej chwili niech się wypowiedzą autorzy.

pozdrawiam i życzę miłej zabawy/pracy nad rozwojem SDX

JA PROTESTUJĘ!!!

co to za pojebana moda, żeby tworzyć soft tylko na dopałki... nikt normalny nie ma dopałek, a chciałby też mieć coś takiego, prosimy o wersję dla standardowych urządzeń...

ten SC to oddzielny program czy wbudowany w SDX? kiedy nowa wersja SDX i co nowego?

Widocznie zaliczasz się do normalnych. Ja nie.

Nie chciało mi się pisać, ale jednak mnie sprowokowałeś ;)-

Sparta DOS X to nie jest dopałka (co wiesz, bo wiesz co sprzedawałeś na aledrogo) a OPCJONALNE użycie sterownika dla wyświetlanego obrazu jest normalnym zachowaniem. Jest sterownik dla XEP (XEP80.SYS), jest sterownik dla stock Atari (RC_GR8.SYS), jest sterownik dla VBXE. Tym sposobem mój drogi geniuszu intelektu masz jeden program, którego nie interesuje zasadniczo, jaki hardware ma na wyjściu wizji.

... a pojebana moda, to zadawanie głupich pytań ;)

Przecież bezrobotny jest ze Spartą za pan brat, więc to implikuje niebycie tej ostatniej dopałką. No chyba, że uważa się za nienormalnego jednak ;)

Ostatnio edytowany przez Jacques (2014-04-18 20:45:56)

No pewa, że nie dopałka przecie ;)

Dobrze, że przynajmniej Atarowce trzeźwe :D

Hmm. Będę musiał to spróbować odtworzyć. Może uda mi się znaleźć jakieś uszkodzone dyskietki ;) Opisywanie zachowanie jest nieco dziwne i może być to błąd w SC, ale może też i w np. COPY (bo SC nie ma własnej procedury kopiowania plików, w celu zrobienia copy albo move uruchamia COPY.COM).

Krótko mówiąc: czy podobny efekt występuje też przy kopiowaniu tych samych plików z tej samej dyskietki przez COPY, czy tylko w przypadku użycia SC?

Poza tym: która wersja SDX, która wersja SC, jak wygląda CONFIG.SYS?

PS. Co do XEP, sterownik cały czas "jest w planach", ale póki co niezrealizowanych. Czy SC będzie na XEP-ie używalny, trudno powiedzieć, ale "częste odświeżanie" nie jest wymagane, ogólnie przemalowywane jest tylko to, co niezbędne: swego czasu zoptymalizowałem SC właśnie pod kątem XEP-a, żeby nie przemalowywał elementów ekranu, których przemalowywać nie trzeba. Np. na VBXE ponowne namalowanie ramki robi różnicę trudną do zauważenia, na XEP-ie pewnie byłoby inaczej.

Ostatnio edytowany przez drac030 (2014-04-24 17:35:04)

Draco - czy "odznaczanie" tagowanych plików w czasie kopiowania Ci działa?

no właśnie tak to wygląda od prawie zawsze i zastanawiałem się, czy jest dziełem przypadku, czy celowego działania.