Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
THE 800XL osiągnął status Gold! Zakończono prace nad oprogramowaniem dla THE800XL. Retro Games Ltd rozpoczyna etap produkcji.
PiST 0.11.0 Środowisko programistyczne PiST dla Atari ST doczekało się nowej wersji 0.11.0.
bm800xl 0.5.9 Emulator bm800xl dla Raspberry Pi zyskał szybszy start, scanlines i pełne stany pamięci.
xasm 3.3.0 i wtyczka do VSCode Po czteroletniej przerwie powraca asembler skrośny xasm.
CAS2Audio 1.1.0 Odtwarzaj obrazy taśm CAS na telefonie z Androidem.
atari.area forum » Posty przez drac030
Czy ja się gryzę? :P Zauważam tylko, że w tym projekcie cokolwiek brakuje i robiony jest też trochę jakby od zadu strony - bo co jest ważniejsze w ST, Yamaha czy CPU? Sądziłbym, że CPU.
A co do atarynki na FPGA, to ona aż tyle miejsca, co STE, na biurku nie zajmuje :P
Pozostaje jeszcze drobiazg:
CCU 0% MC68000
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.
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".
atari.area forum » Posty przez drac030
Forum oparte o: PunBB