Przejdź do treści forum
atari.area
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
Prototyp gry Raiden dla Falcona Prototyp zaginionej konwersji kultowego Raiden na Atari Falcon ujrzał światło dzienne.
Steem SSE 4.2.0 R11 Ukazała się aktualizacja Steem SSE, popularnego emulatora komputerów Atari ST dla systemów Windows i Linux.
Larek i Drwal 1.3: User Friendly Nowy odcinek kursu programowania w asemblerze 6502.
HDDRIVER 13.01 Aktualizacja HDDRIVER przynosi poprawki dla HDDRUTIL oraz lepszą obsługę szybkiego sprzętu.
192p Test Suite dla 8-bitowego Atari Nowy program do testowania i kalibracji obrazu dla Atari XL/XE od HanJammera.
Opcje wyszukiwania (Strona 136 z 186)
Sc0rpi0 napisał/a:drac030 napisał/a:Nie, 68,2 kbps.
E, tyle to na pewno nie miał, przynajmniej ten mój. Może w późniejszym okresie
poprawili osiągi.
A może ty miałeś synchromesha od CA-2001.
piotrv: o ile się nie mylę, miałeś przez miesiąc być na wakacjach :]
Sc0rpi0 napisał/a:Cóż, kiedyś napisałem muzyczkę na LDW2000 ;).
Najlepsza chyba stacja do atarki, bo miała - mało bo mało,
ale zawsze - miejsce na program usera no i komendy,
zeby to wysłac z Atari i uruchomić. Można było własne
turbo zrobić spokojnie jak się komuś nudziło lepsze od
standardowego Synchromesha bo ten mial chyba 38kbit/s.
Nie, 68,2 kbps.
vulgar napisał/a:Draco: pewnie wtedy zaczales odkrywac uroki przyjaciolki =D ... nie zmienia to faktu ze STE bylo przyjemniejsze od aSTka i do przodu, ergo progres... idac tym tropem nigdy w zyciu nie powinienes byl miec Falcona :P
Chyba ci Amiga upadła na głowę, i to Amiga 4000 co najmniej. Co z tego, że STE było lepsze od ST, skoro nie było dostatecznie dobre.
OT: na poprawienie artykułu pt. MagiC w Atariki i doprowadzenie go do jako takiego wyglądu masz czas do jutra do 20.00.
Adam: zawsze myślałem rozwojowo i dlatego nie kupiłem sobie STE :P
Poszukuję kontaktu z niejakim GSL-em, atarowcem z Białegostoku.
Może i macie rację. Ale żeby nie było, że nie kręcę nosem - szkoda, że to ST, a nie co najmniej TT (żeby o Falconie nie wspomnieć).
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:
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).
Znalezione posty [ 3,376 do 3,400 z 4,628 ]
Forum oparte o: PunBB
Currently installed 7 official extensions. Copyright © 2003–2009 PunBB.
Wygenerowano w 0.202 sekund, wykonano 18 zapytań