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
Nowe postacie w Street Fighter 2 Vega dodaje kolejne postacie do portu SF2 na Atari 8-bit. Zobacz nowy film z rozgrywką.
ATasm v1.30 ATasm v1.30 to assembler dla procesora 6502 działający z poziomu wiersza poleceń, zgodny z oryginalnym Mac/65 od OSS.
ugBASIC v1.17.2 Wszechstronny język programowania BASIC oraz cross-kompilator pozwalający na tworzenie programów na różne platformy 8-bitowe
Zapraszamy do artykułów na atari.area! Szukasz różnorodnych materiałów na temat Atari? Koniecznie odwiedź dział artykułów.
ICE-T 2.76 alpha 9 Nowa wersja zaawansowanego emulatora terminala
Opcje wyszukiwania (Strona 62 z 120)
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.
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.
Zepsujesz, postawisz jeszcze linuxa ze 3 razy, a potem już na "wiodący system operacyjny" nie będziesz mógł patrzeć. Tak się to niewinnie zaczyna a potem kończy się w pewnym klubie gdzie wszyscy występują anonimowo.
Quake ma świetny klimat na takim oscyloskopie.
Parametr D kiedy 1 wypełnia bufor wprzód, kiedy 0 wypełnia bufor od końca.
Z=USR(R,L0,L1,L2,L3,L4,L5,L6,L7,B,W,X,D)
Procedura wykorzystuje komórki $D4..EB (czyli rejestry FR0, FRE, FR1 i FR2).
Ponieważ każdy bajt w buforze to kolumna grafiki, to wystarczy wyrzucać go do drukarki od tyłu. A jutro dorobię Ci parametr do odwracanie bufora.
W załączniku procedura umożliwiająca inwersję grafiki. Wywołanie:
Z=USR(R,L0,L1,L2,L3,L4,L5,L6,L7,B,W,X)
Parametr X gdy 0 nie odwraca, gdy 255 odwraca.
tebe napisał/a:od strony programisty można będzie wykryć gdzie ta YAMari leży?
O to by było bardzo miłe.
To wciągnęło papier do drukarki.
Znalezione posty [ 1,526 do 1,550 z 2,995 ]
Forum oparte o: PunBB
Currently installed 7 official extensions. Copyright © 2003–2009 PunBB.
Wygenerowano w 0.099 sekund, wykonano 19 zapytań