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
20. odcinek kursu programowania u Larka Larek wraca z okrągłą, dwudziestą częścią swojego popularnego kursu pisania gier na Atari.
ELITE Atari 8-bit! Dostępne demo portu gry ELITE (wersja dyskowa z BBC Micro) na komputery Atari XL/XE.
BBC BASIC dla Atari XL/XE BBC BASIC w wersji 3.10 dostępny na Atari XL/XE! Port stworzył Ivo van Poorten.
Altirra 4.40-test23 Kolejna testowa wersja Altirry przynosi poprawki w emulacji VBXE i usprawnienia w zarządzaniu firmware.
X. Basque Tournament of Atari 2600 Euskal Retro Association podsumowuje 10. edycję Baskijskiego Turnieju Atari 2600.
Opcje wyszukiwania (Strona 63 z 121)
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.
2.097 MHz?
Edit: I co to za OS z 12.01.2015?
Miałeś zepsuty USR. Zobacz maila.
Rozumiem. Nie upieram się przy $D4, ogólnie chodzi mi o to, żeby nie nastręczać konstruktorom nowych urządzeń kłopotów, lecz jednak zrobić proxy, które pozwoli współdziałać nowym (i starym) rozszerzeniom nie projektowanym jako NewDevices.
Edit: Pod "slotami" nie kryje się u mnie poszatkowanie I/O po $20 bajtów, bo są rozzerzenia, jak COVOX, które wykorzsytują raptem 4 bajty, a inne z kolei potrzebują pół strony. Chciałbym, żeby to było dość elastyczne.
Ogólnie zaczyna się dość tłoczno robić.
Mamy 2 rodzaje rozszerzeń:
- montowane do środka
- dołączane z zewnątrz w postaci cartridge
Obszary adresowe (szczególnie cartów) lubią się pokrywać.
Czy istniałaby możliwość zaprojektowania takiego urządzenia, które pozwalałoby przemapowywać obszary adresowe dla urządzeń?
Pośredniczyłoby ono w komunikacji między rozszerzeniami a szyną Atari.
Zalety takiego rozwiązania:
- konstruktorzy rozszerzeń nie muszą się martwić o obszar adresowy - każde rozszerzenie może być projektowane tak, jakby istniało samodzielnie w gołym Atari, bo i tak obszary mapowane byłyby przez to nasze proxy
- carty mogłyby być nieprzelotowe
- w jednym Atari można by naraz podłączać wiele różnych rozszerzeń bez bólu "a czy mi się z czymś nie pogryzie".
Ja takie proxy widziałbym tak:
- mamy pełny 2K obszar adresowy $D000..$D7FF
- mamy n slotów na rozszerzenia (carty czy wbudowywane do środka - to z mojego punktu widzenia nie ma znaczenia)
- każdy bajt w obszarze $D000..$D7FF mogę sobie zamapować na adres w danym slocie
- z poziomu konfiguratora można byłoby w locie połączać dane rozszerzenie/cart lub odłączać
Mógłbym się podjąć napisania konfiguratora (nawet okienkowego :P) do czegoś takiego.
Miło byłoby również mieć możliwość przypisania jakiegoś ID do urządzenia, żeby można było dość łatwo (od strony oprogramowania) zorientować się gdzie mamy skonfigurowane konkretne urządzenie.
Zdaje się, że podobne funkcje ma już Ultimate (ROMy, konfiguracja adresów VBXE i Covox). Może warto by z takim czymś pożenić jeszcze to: http://www.atari.org.pl/forum/viewtopic … 45#p203245 ?
Znalezione posty [ 1,551 do 1,575 z 3,016 ]
Forum oparte o: PunBB
Currently installed 7 official extensions. Copyright © 2003–2009 PunBB.
Wygenerowano w 0.097 sekund, wykonano 19 zapytań