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 ...

Co panowie na taki koncept: ponieważ magnetofon ogólnie jest na wylocie, a bootowanie z taśmy jest już nawet w bieżącej alfie usunięte, to klawisz START nie ma zastosowania.

Więc może by go wykorzystać: jak klawisz START jest naciśnięty, to pojawia się menu z wyborem numeru dysku, z którego nalezy dokonać boota?

To by miało priorytet nad ustawieniami zapisanymi na twardzielu, odbywałby się tuż przed procedurą bootowania. A jak klawisz START nie naciśnięty, to wszystko normalnie.

Aha, zaznaczyłem sobie (mam listę  ;) )

BTW. ten handler nie będzie działać bez poprawek, bo używa nielegalnego skoku JSR $C642, a ta procedura jest przesunięta nawet w ROM-ie od Atari 1450XLD (i to aż o 13 bajtów).

[ Dodano: 07.12.2004 19:01:44 ]

Skleroza  :?  Ciekawe, dlaczego Gógiel mi tego nie wyrzucił?

Jeszcze tylko przydałoby się zmienić kwiatka na coś bardziej dorzecznego. Ten obrazek to stylesheets/images/wiki.png.

Małpa musiałaby się natrudzić, żeby skasować wszystko (nie pamiętam, żeby było jakieś "Delete ALL"), a poza tym sysop może w każdej chwili przywrócić treść strony.

Rozumiem, że "rybkę" mogę już skasować?

LPOKE? Napisałbym, ale ja nie mam łączności z netem. Może Lizard?

Co do sterowania drugim procesorem, to jak sobie tę obsługę wyobrażasz? Czy procesor ma być automatycznie haltowany przez OS w jakichś warunkach? W jakich?

Jeśli ten program korzysta z tablicy definicji klawiatury znajdującej się w ROM-ie, to po kiego w ogóle grzyba ma własną obsługę klawiatury? Nie dałoby się go skłonić do czytania klawiatury przynajmniej przez KBDVEC+4? Wtedy klik by był i td. A BELL to chyba wystarczy wysłać znak 253 do edytora (przez wektor ICPUTB kanału #0 ...).

[ Dodano: 06.12.2004 21:45:11 ]
PS. AS nie wiem co to, z EYE nie powinno być problemów, żeby to napisać od nowa ...