Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Powrót Head Over Heels! Thalamus zapowiada Return to Blacktooth - kontynuację klasyka na Amigę i Atari ST
Silly Venture 2k25 SE - już wkrótce! Tylko do 21 lipca możesz zamówić koszulkę z okazji SV 2k25 SE
Nowy firmware 1.5 dla SDrive-MAX Ulepszony tryb szybki i poprawki kaset w nowej wersji firmware
Ice-T 2.8.2 Nowa wersja Ice-T dla 8-bitowego Atari już dostępna - poprawki i nowe funkcje
Galactic Panic - nowa przygodówka na ST Darmowa gra point and click na Atari ST - ponad 100 ekranów przygody.
atari.area forum » Posty przez mono
@Tebe: Taka dlista:
LMS+TXT+VSCRL
LMS+TXT
LMS+TXT+VSCRL
LMS+TXT
...
VSCROL na sztywno ustawiony na jakąś wartość powiedzmy 4 i zdaje się mamy tryb tekstowy 4 liniowy (5 w niescrollowanych niestety i nie wiem jak to wyeliminować).
Edit: Gorghowi chodziło o zmianę LMS w środku wiersza.
Piszę z głowy - konkretny przykład mogę podać wieczorem, bo się tym kiedyś bawiłem akurat w celu uzyskania 12 liniowego trybu tekstowego.
Ustaw scroll na linii i LMS-a.
Czyś ktoś czułby się na siłach stworzyć hasło w Atariki dla:
- EGR General Programming
- Marek Górecki
Ja kojarzę tylko tytuły takie, jak:
- Nexuss,
- Last Fucked Vocabulary.
Z góry dziękuję.
Haha. Dziękuję. Człowiek uczy się całe życie :)
Miałem kiedyś do pieca taką starą klawiaturę bez strzałek :) ale nie pamiętam czy tam były narysowane jakieś symbole dodatkowe na hjkl.
VI powstał kiedy jeszcze nie było klawiszy strzałek na klawiaturze i bloku klawiszy numerycznych.
Z zaletami można się zapoznać :) Np. 32 bufory na tekst. Przeróżne możliwości wyszukiwania fraz, wyrażenia regularne, podmiana tekstu. Genialne narzędzie.
No i wszystko można zrobić z klawiatury (jak przystało na edytor tekstu). I działa przez terminal.
A klawiszologia to tylko kwestia przyzwyczajenia :)
Tak. Nie wiem jak to wyglądało w oryginalnych materiałach Atari, ale pamiętam że w TA było takie zestawienie cech MAC/65 i QA gdzie wyraźnie było tam wyjaśnione czym się różni tryb ekranowy od pełnoekranowego. Może to taka Avalonowa propaganda, niemniej utkwiło mi w pamięci i tak to rozumiem od tamtej pory :)
Edytor EKRANOWY - powala na wprowadzenie danej w dowolnego miejsca ekranu.
ZX ma edytor liniowy - pozwala na wprowadzenie danej z wyróżnionej do tego celu linii (tam akurat na dole ekranu).
Edytor PEŁNOEKRANOWY cechuje się możliwością swobodnego poruszania się po dokumencie. Ekran jest tylko viewportem. Niektóre cartridge dla C= (Final3?) miały taką funkcjonalność, choć nie do końca bo one miały tylko pewien bufor na treść np. 1000 linii.
Prawdziwym edytorem pełnoekranowym dysponuje np. QA na Atari.
Można przechwycić wektor BASIC-a i analizować sobie swoje polecenia. Coś mi świta, że niektóre cartridge turbo z tego korzystały.
Panowie - rzut oka na lokalizację i wszystko jasne. Tam powietrze trzeba najpierw pogryźć...
Ale dzięki temu można go łatwo rozszerzać o nowe polecenia.
Gdybyś mógł spojrzeć czy to działa poprawnie.
Atari to gra, Altirra też gra, a Atari800 nie chciało.
Uwaga na carty, które mają różne gniazda/złącza nie na krawędzi carta, ale na środku (np. sampler z Mirage-a). Albo z kostkami flash/eprom (SIC!), albo z kartami CF (SIDE). Niektóre mają przyciski na obudowie, gniazda itd. A niektóre carty są wręcz chyba przelotowe więc mają gdzieś dodatkowe gniazdo.
Archiwum soundtracker_0.7.tar.bz2 zawiera wersję B/W pociętą na strony i przeskalowaną do 600x400 (około) - tylko dwie strony z rysunkami zostały w oryginalnym rozmiarze. Poczyściłem to trochę i poobracałem, więc można by to pociągnąć może jakimś OCR-em i zrobić PDF/DJVU. W środku TIFF'y.
Skan instrukcji, okładki kasety i naklejki (razem z kasetą) Sound Trackera v.0.7 by Henryk Cygert/ASF wpłynęły były na pigwę przed chwilą. Skanowanie w 600dpi. Są tam dwie wersje archiwów .tar.bz2 - B/W oraz GrayScale. Nie bijcie jeśli nieładnie, ale nie umiem inaczej :/. Za to mogę przekazać kasetkę komuś, kto miałby czas i chęci zrobić to ładnie i porządnie. Póki co kasetka pójdzie do Krótkiego, który wyraził chęć jej zrzucenia do .wav.
TipView.
Ja zrobiłem tylko przeglądarki do moich formatów:
- GHG
- SGE
i do niemoich:
- BMP
- SCR
Wszystko jest dostępne na mojej stronie.
Proponuję np.
SET PATH=A:>BIN;CAR:w CONFIG.SYS i programy, które chcesz mieć dostępne w każdej chwili pakować właśnie do A:>BIN>.
Edit: Aczkolwiek skojarzenia plików definiuje się za pomocą RUNEXT.SYS - odsyłam do Podręcznika Użytkownika SDX strona 179. A po wywołanie i parametry RMTPLAY odsyłam do jego manuala.
Yezus Marya. "Wpizdoksiąg"(tm).
Yerzu, a mógłbyś dla odmiany zrobić bardzo zły kawałek na czymkolwiek? Weź np. takie 8-bit Atari... :>
Fajnie to jest zrobione! Może będzie inspiracją przy kolejnym Prima Aprilis Compo :)
A to w takim razie przeoczyłem/zapomniałem o tamtym wątku. "Nie zamulam w takim razie koryta dyskusji" więcej :)
Tak. Sprytniejsze, ale pozwalałoby na dowolne mapowanie już istniejących urządzeń. I żadne nowo projektowane urządzenie nie musiałoby się martwić o alternatywny obszar dla swoich rejestrów. Każde urządzenie mogłoby być projektowane tak, jakby samodzielnie istniało w złączu cart/cart+eci.
Prosta detekcja polegałaby na sprawdzeniu mapy w proxy. Dzięki temu można by mieć możliwość detekcji nawet urządzeń, których nie da się wykryć (np. COVOX).
Czy projektujesz to urządzenie jako coś, co pozwoli trzymać naraz różne carty i NewDevices podłączone i unikać wyjmowania/wkładania? Czy chciałbyś może skonstruować coś co pozwoli jednocześnie współegzystować różnym rozszerzeniom w jednej maszynie?
IMHO te założenia nieco się od siebie różnią. Jakie są moje spostrzeżenia pisałem w Twoim wątku o YaMari. Dodatkowo:
1. Cart to nie tylko kawałek pamięci ROM/RAM mapowany w obszarze $8000..$9FFF + $A000..$BFFF, ale również rozszerzenia (np. sampler, karta muzyczna, Tomek8, Veronica i wiele innych). O ile kawałek pamięci z grą/SDX/GOS/czymkolwiek w zasadzie wyklucza współistnienie drugiego carta z kawałkiem pamięci (choć można się zastanawiać nad przypadkiem RAMCART/SiDiCar), o tyle regularne rozszerzenie powinno dopuszczać współistnienie innych rozszerzeń. Uogólniając można by pozwolić na współistnienie dowolnych cartów.
2. Ponieważ zakłada się, że cart istnieje samodzielnie, to zakłada się, że cart korzysta ze strony $D5 dla swoich rejestrów i może mapować RAM/ROM w obszarach $8000..$9FFF i $A000..$BFFF (wbudowany Atari BASIC w XL/XE i Missile Command w XEGS mają niższy priorytet niż cart). Nieliczne przelotowe carty pozwalają na równoczesne współistnienie innych i wtedy mapują jedynie ograniczoną pulę rejestrów na $D5 dla swoich potrzeb a resztę pozostawiają drugiemu cartowi.
3. Urządzenia PBI (ND) są pomyślane tak, że mogą współistnieć równocześnie w systemie. Są aktywowane rejestrem PDVREG ($D1FF) i tam również pojawia się status np. przerwania. Dzielą wspólny obszar adresowy $D6 i $D7 slotami po $20 bajtów gdzie mogą mapować swoje rejestry, a po aktywacji urządzenia w PDVREG mapuje ono ROM/RAM w obszarze $D800..$DFFF.
4. ND często mają niestety sztywno przypisany numer co powoduje konflikty (ostatnio znana była sprawa zdaje się IDE+ i KarinMaxi, albo SIDE, które nie chciały działać u Pinokia, bo wykorzystywały ten sam numer urządzenia.
Elastyczne proxy do cartów i ND mogłoby:
1. Pozwalać na mapowanie obszarów i dowolne włączanie urządzeń naraz oraz mapowanie identyfikatorów urządzeń ND.
2. Pozwalałoby analogicznie, jak proxy do rozszerzeń o którym dyskutowaliśmy w wątku o YaMari na uproszczenie budowy kolejnych ND i cartów.
3. Umożliwiałoby prostą detekcję cartów/ND i ich adresów.
ale musiałoby mieć jakąś nieulotną pamięć do zachowywania ustawień i logikę pozwalającą na przemapowywanie adresów i włączanie/wyłączanie carta/ND z obsługi.
Może warto by jednak wtedy pomyśleć to, jako proxy do dowolnych rozszerzeń?
[offtop]"Ale czy to jeszcze będzie RPI?" :)[/offtop].
Samo mkatr masz w sio2bsd, ale on Ci nie sformatuje zrobionego atra :/ Trzeba odpalić na tym emulator z odpowiednim DOS-em. Franny może zrobić atra, założyć odpowiedni fs i kopiować pliki.
atari.area forum » Posty przez mono
Wygenerowano w 0.095 sekund, wykonano 17 zapytań