to mi wygląda na otwarcie nowego frontu wojny, z jednej strony xBios vs Candle i reszta świata, teraz Drac&Trub vs Candle, robi się ciekawie, co za emocje :)

xb?- też nie wiem, lecz słyszałem, że "więcej węgla" ;)

a tak na poważnie, to łata by się przydała bo niebawem temat może dotyczyć i mojej Atarki ;)- Candle, weź to zaimplementuj w Ultimete, bo podnoszenie memlo drajwerem, czy rewolucja w części dotyczącej rtc jest faktycznie rozwiązaniem średnio-sensownym ;)-

Myślę, że możemy przegłosować np. środę. O wynik głosowania jestem spokojny, albowiem to ja będę liczyć głosy.

A tak na serio, to dyskusja WTF.

Słowem Candle trzyma się Biblii, a ja nie, chyba powinno być odwrotnie :P
Pierwszy dzień tygodnia jest umowny, ale ja używam obowiązującego standardu: http://pl.wikipedia.org/wiki/ISO_8601

Moim zdaniem w Ultimate, bo to bez sensu, żeby SDX obliczała i ustawiała w zegarku bezużyteczną wartość, na zrobienie czego marnuje się RAM, mimo że równie dobrze można byłoby to obliczyć w menu U1MB, czyli jedynym miejscu, gdzie ta wartość jest w ogóle wykorzystywana do czegokolwiek.

Ale stery od zegarka to nie mój resort, jak trubu z candlem zrobią, tak będzie.

Czy można zgłosić zapotrzebowanie na bardzo przydatny UTILZ?

W skrócie:

Chodzi o program, który możemy uruchomić z poziomu CONFIG.SYS, lub dowolnego pliku konfiguracji *.CFG pod boot selector.

Co to ma robić:

Program ma się uruchamiać co najmniej z CONFIG.SYS/*.CFG pobrać parametr w którym określony będzie bank z rdzeniem dla VBXE. Sprawdzić, czy rdzeń określony parametrem jest aktualnie używanym przez kartę rdzeniem - jeśli tak, to wówczas nie podejmować żadnej akcji. Jeśli tak nie jest, to zamiana boot-bank i załadowanie odpowiedniego rdzenia wskazanego przez parametr.

Po co to:

... są rdzenie FX i są rdzenie emulacji GTIA, czy SoundBoard. Często muszę to przełączać i lepiej by było robić to z automatu. Np. do pracy pod SDX używam FX, bo zapewnia mi możliwość pracy na ekranie 80 znakowym, do gier / demek używam rdzenia z emu gtia, co w przypadku ostatniej wersji przekłada się na plus w postaci poprawnego wyświetlania koloru w niektórych trybach interlace.

:) - to jak?

Ostatnio edytowany przez Pin (2013-01-06 16:58:32)

Draco - odpal pod nowym s_vbxe i starym con.sys kilka razy fdisk2 (wersja 2.6, testowana)
- koniecznie w trybie 80-znakowym VBXE

Ostatnio edytowany przez Pin (2013-01-09 15:57:24)

Nie zdiagnozowałem tego jeszcze, ale zdaje się, że jest dużo lepiej, jeśli S_VBXE zastąpi się przez RC_GR8 (3142 bajty, data 15-11-12, 2:49:23). Wskazywałoby to na problem z driverem VBXE, ale na razie nie mam bladego pojęcia, na czym on mógłby polegać.

Pin, a wiesz, że ja używałem właśnie tego niesławnego COLOR.SYS? :D
Teraz wywalę i wykorzystam $SCRDEF ;) Przydałaby się jeszcze jakaś zmienna środowiskowa do wyłączenia dźwięków transmisji SIO ;)

dokładnie. Wpakuj poke'a do bata i po sprawie, albo kup interface ide i nie będziesz musiał wyciszać dźwięku ani czekać na cokolwiek ;)-

Właśnie coś zauważyłem w kwestii RUNEXT.SYS i w sumie dokumentacja to potwierdza.
Mianowicie skojarzenia zdefiniowane w RUNEXT.CFG wydają się działać tylko wtedy, gdy użytkownik poda pełną nazwę pliku z rozszerzeniem. Posłużenie się wildcard np. VIS*.* (dla VISAGE.EXE) sprawia, że skojarzenie (u mnie EXE,CAR:X.COM /C) nie działa, podobnie LESS dla dokumentów TXT, itd.
Czyli RUNEXT.SYS pobiera rozszerzenie z linii poleceń, a przy *.* nie bierze pod uwagę rozszerzenia pliku, który faktycznie zostanie znaleziony?

I druga sprawa... Mając zdefiniowane skojarzenie EXE,CAR:X.COM, tak naprawdę można sobie darować COMEXE.SYS, bo po co powielać, prawda?

EDIT:
Podłubałem jeszcze i co do rozpoznawania rozszerzeń, podobnie ma się sprawa z COMEXE.SYS (testowane bez RUNEXT).
plik SI.EXE (SysInfo):
- uruchamiany z X po podaniu SI.EXE
- uruchamiany z X po podaniu SI (czyli tu działa dobrze, pomimo braku wpisanego rozszerzenia, za to jest cała nazwa)
- uruchamiany bez X po podaniu SI.E* (i tutaj już się gubi, bo też powinno być uruchamiane poprzez X przecież)

Przykład może jest nieżyciowy i trywialny, ale uwypukla pewien problem, przynajmniej mi się wydaje, że RUNEXT.SYS i COMEXE.SYS powinny działać w oparciu o rozszerzenie faktycznie znalezionego przez system pliku (co nie działa przy wildcards).
Czy nie? ;)

EDIT2:
Ten punkt:
"- uruchamiany z X po podaniu SI (czyli tu działa dobrze, pomimo braku wpisanego rozszerzenia, za to jest cała nazwa)"

...to była zasługa COMEXE.SYS, bo on rozpoznaje EXEka po samym wpisaniu SI (dla SI.EXE), natomiast RUNEXT (pomimo skojarzenia) nie, czyli wniosek jest taki, że RUNEXT działa w oparciu o parsowane wpisane rozszerzenie, a nie plik, który faktycznie system znajdzie. Jeżeli to zostanie poprawione w RUNEXT, wtedy po skojarzeniu EXE z CAR:X będzie można nie używać COMEXE. Na razie jest to niemożliwe, bo sam RUNEXT.CFG nie uruchomi nam exeka po podanej samej nazwie.

Ostatnio edytowany przez Jacques (2013-01-13 14:02:43)

RUNEXT i COMEXE mają jednak trochę inne zastosowania, ten pierwszy "obsługuje" pliki danych, drugi wykonywalne. Ponieważ tych drugich są tylko dwa typy (COM i EXE), a na dodatek występują w dobrze określonym miejscu ($PATH i katalog bieżący), wyszukanie pierwszego z dwóch typów plików, który spełnia zadane kryterium, jest łatwe i daje jednoznaczny (na ogół) wynik. W przypadku, kiedy mamy 10 albo 20 typów plików zdefiniowanych pod RUNEXT, i na dodatek znajdują się one wszędzie na dysku, w celu otwarcia automatycznego z pominięciem rozszerzenia, zakładając, że to miałyby być również EXE, trzeba byłoby zrobić dodatkowy skan $PATH & co., a rezultat mógłby być dla usera zaskakujący (bo wyobrażalne jest, że człowiek chcąc otworzyć plik DUPA.MPT zapomni, że ma w $PATH również plik DUPA.EXE).

Zatem chyba lepiej jest tak jak jest teraz :)