Napisz precyzyjniej jak o sie objawia.... bo co jak co, ale edycja tych parametrow powinna dzialac zawsze. Jest poprostu niezalezna od reszty programu. A to pod emulcem czy real Atari?? Bo na real Atari to trzeba Ctrl+szczalka wciskac :) (tak pisze, bo Pirx mial przez chwile ten problem ;) )

A i sciagnij jeszcze raz paczke z poprzedniej strony. Wymienilem tam MSINI3 na wersje widzaca do 256 plikow.
Ze wzgledu na pewne ograniczenia MMG Basic Compilera w trybie Ineger (a tak jest kompilowany MSINI3), w przypadku ilosci plikow wiekszej niz 128 moglo nastapic zamazanie czesci danych i faktycznie dziwne objawy, w poprawce staralem sie to wyeliminowac.

Ale tak naprawde jak bedzie wersja w assemblerze to bedzie najlepiej :)

OK, MSINI3 już działa świetnie z katalogami gdzie jest więcej  niż 128 plików (a mniej niż 256 ;) ).

Mam drobną uwagę odnośnie ładowania schematów kolorów z pliku .DAT w MSDOS45. Ustawiłem sobie schemat (Atari Basic, ale to nie ma znaczenia) i teraz przy bootowaniu dyskietki z uruchomieniem MSDOS (ustawione BOOT MSDOS.COM z poziomu SDX):

1) zaczyna się ładowanie MSDOS - niebieski ekran (jak basic)
2) ekran robi się na chwilę czarny (to normalne akurat)
3) na chwilę (to jest względne, bo jak w normalu to ta chwila jest całkiem długa) ekran ma standardowy kolor zielony MSDOS
4) dopiero zmienia schemat koloru na wczytany z pliku .DAT

Czy byłaby możliwość sprawdzenia czy jest poprawny schemat kolorów jeszcze podczas momentu gdy ekran jest czarny i wówczas już nie zmienianie na standardową zieleń przed zastosowaniem schematu użytkownika, tylko od razu na ten docelowy? Bo taka troszkę dyskoteka się robi i średnio to pośrednie wyświetlanie zieleni wygląda.
Wiem, może to szczegół, ale skoro już takie wypasy są w MSDOS (zmiana kolorów rządzi), to niech będzie od A-Z idealnie :)

EDIT:
To samo się dzieje gdy np. już mamy wczytany w MSDOS własny schemat koloró, ale przechodzimy do podkatalogu z innym plikiem MSDOS.DAT. Wówczas na chwilę znów ekran robi się zielony by za chwilę zmienić na ten schemat z podkatalogu do którego wchodzimy.

Wiem oczywiscie, ze tak jest... Wynika to trochę z tego, że program napisany jest systemowo.
Na poczatku (także przy zmianie katalogu czy dysku) robi kulturalne GR. 0, co powoduje przywrocenie kolorow systemowych, wiec natychmiast zmienia je na swoje oryginalne. A nie wie wtedy jakie mają być kolory, bo dopiero teraz czyta katalog i jak znajdzie w nim MSDOS.DAT, przechodzi do jego odczytu. Dopiero jak odczyta go w calosci, przechodzi do analizy i wyswietlania i dla oszczędności kodu to tu jest procedura wczytania parametrów.

Metody poprawienia tego widzę, nawet 3.
- zlikwidowanie kolorów domyslnych MSDOSA i pozostawienie systemowych (jakoś mi się to nie podoba)
- bezpośrednio po GR.0 (skoro mamy mignięcie na czarno) wyłączenie ekranu i włączenie go dopiero po wyswietleniu listy plików (też jakoś nie podoba mi się),
- robienie GR. 0 tylko raz na początku programu (bo i tak zawsze przy przerysowaniu jest wysyłany na ekran kod czyszczenia), przy okazji procedurę robiącą GR.0 możnaby przerzucić do bufora na dane - bo potrzebna będzie tylko raz i może potem zostać zamazana - to mi się podoba najbardziej, bo optymalizuje kod, a jak będzie wyglądało??? kto wie. Odpadną mrugnięcia, zmiany kolorów na systemowe, więc i konieczność odtwarzania kolorów MSDOSowych....

Obaczę co się da zrobić :)

Proponuję dorzucić schemat starego terminala: tło czarne, ramka czarna i znaki w takiej specyficznej lekko rażącej zieleni.

Coś jak tu:

A czy kineskop zielonego monitora ma czarne tło ??? - oczywiście nie :) Ma zielonkawe.
08 B0 B0 nie jest takie złe.
Wiecie co... nie ma już co kombinować i optymalizować w MSDOSie. Poprawiłem oczywiście te zmiany kolorów, no i z drugiej strony nie bardzo mi się widzi wydłużanie programu, który zasadniczo ma być jak najkrótszy.
Pozostaje MSINI3 przepisać na assembler a MSDOS 4.6 ( cjoć od 4.5 różni się tylko ładniejszą zmianą kolorów - no i jest dzięki temu trochę szybszy, bo nie robi tak często jak poprzedni otwierania ekranu - w zasadzie to robi tylko raz) uznać za definitywanie zakończony.

Ja mam uwagi do tej koncepcji - jest zaj...sta.

Dobra. Wszystko zrobione. Przy okazji poprawilem buga powodujacego wylaczanie BASICa mimo, że powinien zostać włączony (i tak był oznaczony na ekranie ;) ).
No i mam ciekawą zagwozdkę. W czasie testów nie odpalila mi sie gra Final Legacy. W poprzednich wersjach sie odpalala, po przelaczniu emulatora na NTSC tez sie odpala, takze w nowej wersji loadera!
Zaczalem analizowac kod tej gry i z pierwszych rozkazow wynika ze odpala sie raczej przypadkiem (dlaczego wiec odpalala sie w poprzednich wersjach MSDOS, a w nowej nie odpala sie wcale??, dlaczego chodzi w NTSC??).
Zastrzegam ze testowalem tylko pod emulatorami....
A oto ten kod z poczatku gry.... a jest to kopia z carta, a ten kawalek kodu odpala sie przed skokiem do obszaru samej gry.

7f86  LDA #$80
7f88  STA $6a  ;RAMTOP
7f8a  LDA #$00
7f8c  TAY
7f8d  TAX
7f8e  STA $0200,X   ; <--- zamazuje wektory przerwan!!!
7f91  INX
7f92  BNE $7f8e
7f94  STA $09  ;BOOT
7f96  STA $244   ;COLDST
7f99  LDA #$3c
7f9b  STA $d302  ;PACTL
7f9e  LDA #$52
7fa0  STA $02fc  ;KBCODES
7fa3  JMP $8000

Jak widać gra na starcie zeruje m.in. wektory przerwań nie blokując przerwań wcześniej!!!
Sprawdziłem, ze wyklada sie wlasnie dlatego ze w miedzyczasie wywoluje sie jakies przerwanie.
Tylko dlaczego w poprzedniej wersji loadera sie nie wywolywalo, i dlaczego nie wywoluje sie w NTSC ???

Tym bardziej ze zmiany w loaderze prawie zadne.

Oczywiście problemy z uruchomieniem tej gry to nie wina loadera (SDLOAD zachowuje sie tak samo jak najnowsza wersja MSDOSa), ale intryguje mnie dlaczego w poprzednich wersjach ta gra sie wczytywała. Troszke sie jedna procedura - uruchamiana po zaladowaniu kolejnego bloku - w loaderze wydluzyla (kosztem innej) i stawiam na to wlasnie + zbieg okoliczności z czasami wykonywania się procedur i wystepowaniem przerwań.

Wlasciwie gra ta chodzi tak samo dobrze (a przy okazji odpala sie zawsze, wiec lepiej) bez wykoniania przedstawionej wyzej procedury - wystarczy po zaladowaniu skok pod $8000 :)

Dodalem w loaderze czekanie az Antic zacznie rysowac ekran (czekanie na linie nr 0) przed skokiem pod adres startu gry i Final Legacy odpala sie zawsze..... wiec byla to kwestia szczescia. Ale zamiast zmieniac loader chyba trzebaby poprawic plik gry :)

Dely a mógłbyś sprecyzować.
Przytrzymanie Shift jest sprawdzane przy pomocy sprawdzenia bitu w SKSTAT, więc Caps nie ma na to wpływu.
Faktem za to jest ze obsługiwane są tylko wielkie litery, więc jak masz aktywny Caps to trzeba wybierać gry  z wciśniętym klawiszem Shift. To zaraz zmienię, będą działały tak wielkie jak i małe litery.... w sumie invers też trzeba by wyeliminować :)

Supeł, jak zwykle - potestujEM :) Zarówno MSDOS jak i MSINI ;)

Działa, działa.... :)
Oczywiście to, że nie działał, to wina słabo zrobionego ripa z Cartridge.
Prawda jest taka, że nigdy nie da się zrobić loadera ładującego dobrze wszystkie gry, można się tylko do tego ideału zbliżać. W starszych grach (głównie właśnie w ripach z cartów) jest wiele różnych dziwnych procedur, które czasami tylko przypadkiem działają (zobacz w tym wątku trochę wcześniej co w jednej znalazłem). Trzebaby napisać loader rozpoznający te źle napisane zrobione gry i modyfikujący w każdym przypadku proces uruchomienia, to nierealne.
Ale akurat dla Last Starfighter dało się zrobić to w sposób uniwersalny, mam nadzieję, nie psujący odpalenia jakiejś innej - przypadkowej - gry :)
Wersja MSDOS 4.6 (chyba już ostateczna) jest do pobrania tutaj: http://pecus.pigwa.net/pliki/Atari/msdos46.obx .
Przy okazji dodane jest wyjście do DOSa kombinacją Shift-Esc (jeśli ktoś uruchamiał MSDOSa spod Sparty i chciałby kulturalnie do niej wrócić bez odpalania gry).

MSINI4 się pisze, jest relokowalne, przyjmuje ścieżkę jako parametr i zostawia dużo pamięci na edytowane długie nazwy. Zrobione już wszystko poza samą edycją na ekranie, ale to już jest proste... w miarę :) Jak skończę to będzie wersja 4.6 oficjalnie z całym pakietem.

Oczywiście że obsługuje, od wersji 4.3 wszystkie nowe wersje obsługują sektory dłuższe niż 256b. I - raz jeszcze przypomnę :) - utrzymują przy tym baaardzo niskie MEMLO, dzieki pozbyciu się bufora na mapę pliku.