Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
7th Annual Atari Homebrew Awards Oczywiście nie zabrakło polskich akcentów.
Wyniki FujiCup 2024 Sprawdź, czy były niespodzianki!
Mad Pascal 1.7.2 Optymalizacje, poprawki błędów oraz nowe funkcjonalności.
Tydzień na oddanie głosu w FUJICUP! Głosowanie potrwa tylko do 22 lutego 2025...
TURGEN 9.3.1 Najnowsza wersja oprogramowania TURGEN wprowadza kilka istotnych ulepszeń.
atari.area forum » Posty przez drac030
Ilość move'ów jeszcze nie przesądza o tym, że kod jest zły. Może wklej coś, to ocenimy.
Nom, u mnie to samo.
A gdzie ty znajdziesz miejsce na powiedzmy osiem buforów po 128 kilobajtów?
A wersja na ST to jaka niby jest? 8-bitowa? :P
W SpartaDOS X jest coś takiego jak "biblioteka". Większość jej się mieści na karcie. Zawiera, jak to biblioteka, wiele pożytecznych procedur, a programy narzędziowe SDX korzystają z tego intensywnie. W zasadzie, to korzystają wyłącznie z niej. Biblioteka natomiast albo wykonuje od razu to co chcą, albo przekłada to na wywołania kernela SDX i/albo na wywołania urządzeń OS-u. Na tej zasadzie definiując nowa procedurę biblioteczną można zlinkować urządzenie w rodzaju "Y:" z resztą Sparty.
Co do niewykorzystanych literek, wykorzystane są tylko duże litery, a nie ma przeszkód, żeby identyfikatorem urządzenia była literka mała, zwłaszcza jeśli urządzneie nie będzie referenced by humans.
W sumie może. Biblioteka SDX może potem przełożyć to na symbole (jak U_GETKEY w tej wersji kernela, który jest w CVS).
drac030, nie mów, że chcesz to zrobić ;)
Skądżeż. Uważam, że to overkill. Masa roboty, a i tak nie gwarantuje to tego, że program nie popsuje systemu.
Co do bankowania, przykre jest to, że bank wymienia się w środku TPA - niech no program zechce mieć handler przerwania i umieści go sobie właśnie tam, ... no wiadomo.
1) A co, jeśli program jest rezydentną nakładką na DOS? Wtedy zakończy się natychmiast, a przeładowanie DOS-u z pamięci dodatkowej skasuje nakładkę.
2) Co ze stanem buforów DOS-u i jego wewnętrznych zmiennych? Też chcesz je przywracać do stanu "zamrożonego" w XMS-ie?
piotrv: nie bardzo rozumiem, o co w tym chodzi. Mógłbyś objaśnić? Gdzie DOS, gdzie wektory? Nie kojarzę.
Można. Konkretnie "dir >>kat.txt". W druga stronę też się da, tj. "program <<foobar.txt", gdzie program zamiast czytać dane z klawiatury odczytuje je z pliku.
Modyfikacja COMMAND.COMa niewiele pewnie pomoże, bo polecenia, które wykonuje nie muszą być wczytywane z edytora, ale np. z pliku (BAT) - istnieje coś takiego, jak przekierowanie I/O.
Zapewne input z klawiatury dałoby się przekierować podobnie jak input z edytora.
Jellonek: jedno z dwojga - albo przypisujesz historię do nowej kombinacji klawiszy (np. Ctrl/Shift/góra|dół) i wtedy posypie się wszystko, co ją wykorzystuje, czyli połowa edytorów tekstu, prawdopodobnie, z pełnoekranowym - ale zrobionym na "E:" - edytorem MAE na czele. Juz nie wspominając, po co komu historia w edytorze pełnoekranowym. Albo przypisujesz to do strzałek góra/dół, i wtedy adieu Atari BASIC, MAC/65 i pewnie kilo innych podstawowych programów.
Poza tym bufor historii to jest funkcja programu, który takowego potrzebuje, nie? Czyli w unixie to jest zaszyte w bashu a nie w kernelu. Nie widzę powodu, żeby na Atari miało być inaczej, ostatecznie potrzebuje tego tylko command.com. Przy INPUT A$ i pokrewnych by to tylko przeszkadzało (bo po co przywoływać komendy shella w BASIC-u i odwrotnie).
No pewnie, że ten. Ingerencja w "E:" dałaby tyle, że przestałoby działać wszystko inne, co z "E:" korzysta, z BASIC-em na czele.
Taki mini-sterownik 64-kolumnowego edytora ma MAE (że już o SysInfo nie wspomnę). Wcale to nie jest wolne, wręcz przeciwnie. Tylko od metra pamięci zajmuje.
Nie trzeba przerabiać sterownika E: w tym celu, a command.com SDX, żeby nie czytał poleceń rekordami z edytora, ale znakami z klawiatury. Dalej już powinno pójść łatwo.
A gdzie to napisane?
Tak to sobie oglądam pobieżnie, ale już widać, że ten "OS revision 5" to milowy krok wstecz. Nie ma obsługi PBI (!!!), a w zamian za to wrzucono do ROM-u obsługę SIO na 38400 oraz "Help Text Viewer" (bardzo mądre). Dobrze, że ich wszystkich Tramiel wyrzucił z pracy. Już OS dla 1450XLD wyglądał miejscami, jakby w nim małpa grzebała, ale to tutaj wygląda na atak stada goryli :D
Sikor, przeczytaj to, co ci wyżej napisał macgyver.
Na wypadek, gdyby ktoś chciał się tym zająć
Ha, ha, dobry dowcip.
Myślę, że tak bardzo nie zwolni. Wydzielenie znaku z cechy to kilka cykli.
Sterownik CIO pod jakąś niezajętą nazwą (np. "M:" - ale to jest akurat zajęte) bez operacji typu OPEN/CLOSE/GET/PUT/STATUS. Tylko SPECIAL - a tu alloc, dealloc itp. pod odpowiednimi kodami XIO.
Ale 65C816 ma 16-bitowe (operacje BCD) i stąd wiadomo, jaki jest ten "naturalny porządek".
ponoc 68010 ma jakies wsparcie dla pamieci wirtualnej
Tego nie wiem. Ale ma coś w rodzaju cache - bardzo mało (6 bajtów chyba), ale mieści się w tym move.l (an)+,(am)+ / dbra :)
Po to, żeby programy mogły łatwiej korzystać z dodatkowej pamięci nie zamazując ramdysku ani wywalając SDX w kosmos?
jellonek: Tak, niezła koncepcja. To ogólne niedorobienie i bałagan w dziale ST sprawia, ze przynosi on więcej szkody niż pożytku. Jak ktoś zajrzy do "Akcesoria i rozszerzenia" i porówna ilość peryferiów dla XL/XE i ST, to pęknie ze śmiechu...
adamk: użycie Ctrl/C - Ctrl/V dojrzewa w tobie od dłuższego czasu. No, no.
Ogólnie twoja wypowiedź świadczy, że jellonek ma rację - zainteresowanie treścią Atariki ze strony ST-fanów jest przyzerowe. Nie ma więc chyba sensu utrzymywać tego działu na siłę.
Jeśli tobie, takiemu fanowi ST, nie chce się kiwnąć palcem w kwestii działu ST na Atariki (którym to działem obiecywałeś się zająć, zresztą), to powiedz mi, dlaczego mnie miałoby się chcieć? Zadeklarowałeś się - to zrób. Nie chce ci się - to nie spychaj na innych.
atari.area forum » Posty przez drac030
Wygenerowano w 0.128 sekund, wykonano 15 zapytań