Zasadniczo, czemu nie. Jeśli ktoś chce, to może mieć Zybexa plik binarny nawet w DivX-ie. Pytanie, po co.

Jeszcze jedno pytanie: jeśli się poprawioną Spartę (z procedurką set_dunit, nb. miejsce na nią jest chyba zarówno w banku 0 jak i 1, bo końcówki obu są takie same) odpali np. z D3:, i tam nie będzie ani CONFIG.SYS ani AUTOEXEC.BAT, to jak jest ustawiony katalog bieżący?

Kawałek kodu da się chyba dopisać, bo na końcu Sparty (pod koniec obszaru adresowego cartridge'a) widziałem kawałek wolnego miejsca. A więc zamiast:

ldy #$01
sty dunit

dalibyśmy

ldy #$01
jsr set_dunit

a pod adresem set_dunit coś takiego:

lda dunit
bne ?ret
sty dunit
?ret rts

To jest 9 bajtów, wlezie?

Co do autoexec.bat i reszty: jak to jest możliwe, żeby DOS wczytywał to z D1: bez ustawienia DUNIT na 1?

[ Dodano: 31.12.2004 01:24:30 ]
PS. Ze zmianą D1 na cokolwiek innego to i bez QMEG-a jest możliwe, bylebyś miał KMK/JŻ IDE. Ale, jak mówię, mnie to niezbyt satysfakcjonuje.

Pin: mnt.com wykorzystuje możliwość przekierowania dysku D1: na dowolny inny, bez mieszania w tablicy partycji. Przełączenie D3: na D10: wymaga fizycznej zamiany miejscami wpisów w tablicy partycji dotyczących dysków D3: i D10:. I oczywiście wczytania sektora nr 1 dysku D3 potem  ;)

Tak się składa, że istnieje - w źrodle MAE - biblioteka podprogramów do "niskopoziomowej" obsługi dysku. Ale nie pamiętam, czy umie zamieniać partycje miejscami.

[ Dodano: 30.12.2004 21:08:24 ]
PS. Aha, byłbym zapomniał. Źródło FDISK-a 1.40 odeszło w niebyt razem z dyskiem Maxtor, który pewnego pięknego dnia zszedł mi śmiertelnie w obecności osób trzecich i został wyrzucony do śmietnika. Moja wina, bo dysk niedomagał już od dłuższego czasu, i trzeba go było czym prędzej wymienić, a nie liczyć na zasadę nieskończoności ("no jeszcze jeden dzień chyba podziała, nie?").  :rolleyes:

PS2. Trub, co z tym SDX 4.22? Adresy się różnią?

Mam tak w sterowniku twardziela, ale jednak swobodny wybór dysku bardziej mi się podoba. Lepiej chyba, żeby DOS wyświetlał właściwy numer dysku, z którego wystartował (tj. np. D2:), zamiast zawsze D1: niezależnie od okoliczności.

Przyłączam się, niech wam św. Mikołaj przyniesie pod choinkę 65XE z magnetofonem  ;)

Na starym CIO to chyba nie ma sensu. Lepiej jest zaprojektować nowe, co samo będzie alokować deskryptory (struct FILE) i zwracać wskaźniki ...

TXG: I can see that you're in a hurry. But building a new OS - a new OS that would make some sense, be useful and not be yet another crap - is rather a complex process.

Second, I personally don't think that building a new OS for 6502-based Ataris makes sense, and that there are people really interested in writing such a thing. IMHO, nothing can beat SpartaDOS X, which is both very advanced and usable on daily basis. Perhaps the CLI is not very "impressive" - although the look and feel of the SpartaDOS X is excellent IMHO - but it is at least trurly useful and convenient.

As for new system that could offer maximum support for the 65c816, we first need some BIOS-level thing expansible enough to be a base for a softloaded OS, then we need a new SIO and new CIO which would allow direct sector and file i/o transfers to the expanded address space, and then a new DOS, and then some decent development tools allowing to write programs easier (an assembler, a C compiler etc.) ... and THEN, but not earlier, we can think about a nice and impressive GUI.

Ładne... ale musicie przyznać, że w dziedzinie projektów opakowań radziecka technika zatrzymała się na początu lat trzydziestych XX wieku. Dezajn jest jak od przedwojennych zapałek albo herbaty ...

No, fertig. Po dwóch nocach analizy ROM-u od 1450XLD (wziąłem ten nowszy) muszę stwierdzić, że numer wersji 2.03 - w porównaniu do 1.02 tego co jest w 800XL - to jest gruba przesada. Są drobne poprawki, owszem, ale to przeważnie kosmetyka.  :?

[ Dodano: 12.12.2004 06:39:42 ]

Tak sobie myślę: wirtualne kanały I/O raczej odpadają - bez możliwości ustawienia jakichkolwiek zmiennych trudno byłoby tego używać - ale fakt jest faktem, że numery od 8 do 15 się marnują. Waham się pomiędzy kilkoma koncepcjami i nie wiem, co wybrać:

1) można zlikwidować bufor drukarki, to znaczy przenieść go na miejsce bufora magnetofonu (handler magnetofonu już poleciał, więc to chyba nie szkodzi). To zwalnia 40 bajtów za IOCB #7, czyli można byłoby przypisać to miejsce do IOCB #8 i IOCB #9 powiększając w prosty sposób liczbę kanałów do 10.

Jest to dość proste do zakodowania i nowe kanały byłyby też proste do użycia, bo dokładnie tak samo, jak stare.

2) zdefiniować osiem oddzielnych kanałów IOCB w dodatkowej pamięci: stare byłyby pod $000340 a nowe powiedzmy od $010100-$01018F. Oczywiście byłyby dostępne tylko wtedy, kiedy ta pamięć istniałaby, ale za to łączna liczba kanałów wzrosłaby do 16.

Jest to dość proste do zakodowania, ale byłoby to średnio wygodne w użytkowaniu, bo trzeba byłoby pamiętać o odejmowaniu 128 od adresu wewnątrz IOCB o numerze powyżej 7, no i w ogóle o tym, że bazą nie jest w tym wypadku $0340, tylko jakiś inny adres ... no i jeszcze trzeba byłoby sprawdzać czy dodatkowa pamięć istnieje, zanim się w niej zacznie grzebać. Ale to chyba jest najmniejszy problem.

3) spróbować tak zmodyfikować CIO, żeby kanały z zakresu 8-15 mogły być umieszczone w dowolnym miejscu w pamięci, albo nigdzie. Problemy z adresowaniem ich j/w (to znaczy: to nie jest trudne, ale to jest pole do łatwego zrobienia trudnych do znalezienia błędów). Ciężka sprawa, jeśli chodzi o API, pewnie trzeba byłoby dorobić dwie nowe funkcje CIO, jedna do zainicjowania ich, druga do skasowania (a trzecia do odczytywania ich adresu bazowego ...)

No i tak w ogóle to CIO jest 16-bitowe, a przydałoby się, żeby co najmniej adres i długość bufora (albo przynajmniej sam adres) były 24-bitowe.

Ma ktoś jakieś pomysły?

No mnie przynajmniej STOEN każe płacić za prąd  :cry:  ;)

Może pora pomyśleć nad zmianą przeglądarki? Mi tam Firefox nie zapomina ...