Przejdź do treści forum
atari.area forum
Twoje polskie źródło informacji o Atari
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Aktywne tematy Tematy bez odpowiedzi
Aktualności ze świata Atari
Jak napisać grę na Atari - cz. 8 Premiera ósmej części popularnej serii poradników Larka o tworzeniu gier na Atari już 28 lipca!
TONY - Ark of the Covenant Kontynuacja przygód Tony'ego na Atari 8-bit, bez przemocy, z naciskiem na spryt i eksplorację.
ABBUC Software Contest 2025: Zgłoszenia Sprawdź aktualną listę programów zgłoszonych do konkursu ABBUC Software Contest 2025. Termin mija 31 lipca!
Gopher2600 0.50.0 Nowa wersja emulatora Atari 2600 z usprawnieniami i nowymi funkcjami debuggera.
Steem SSE 4.2.0 już dostępny Nowa wersja emulatora Steem SSE z istotnymi usprawnieniami i nowościami
Opcje wyszukiwania (Strona 135 z 184)
Zawsze mi się wydawało, że to naturalne dość - można zrobić sampla 1-bitowego, jedynie skąpość bitów trzeba skompensować zwiększoną częstotliwością odtwarzania, a resztę za nas listościwa fizyka zrobi (konkretnie: bezwładność membrany głośnika i ogólnie tego całego analogowego ustrojstwa, które ma odtwarzać dźwięk).
Ilość move'ów jeszcze nie przesądza o tym, że kod jest zły. Może wklej coś, to ocenimy.
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).
piotrv napisał/a: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.
trub napisał/a: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.
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.
piotrv napisał/a: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".
Cyprian_Konador napisał/a: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?
Znalezione posty [ 3,351 do 3,375 z 4,592 ]
Forum oparte o: PunBB
Currently installed 7 official extensions. Copyright © 2003–2009 PunBB.
Wygenerowano w 0.134 sekund, wykonano 17 zapytań