1,551

(33 odpowiedzi, napisanych Software, Gry - 8bit)

Gdybyś mógł spojrzeć czy to działa poprawnie.
Atari to gra, Altirra też gra, a Atari800 nie chciało.

1,552

(80 odpowiedzi, napisanych Fabryka - 8bit)

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.

1,553

(25 odpowiedzi, napisanych Scena - 8bit)

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.

1,554

(25 odpowiedzi, napisanych Scena - 8bit)

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.

1,555

(349 odpowiedzi, napisanych Fabryka - 8bit)

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.

1,556

(349 odpowiedzi, napisanych Fabryka - 8bit)

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.

1,557

(522 odpowiedzi, napisanych Bałagan)

Yezus Marya. "Wpizdoksiąg"(tm).

1,558

(522 odpowiedzi, napisanych Bałagan)

Yerzu, a mógłbyś dla odmiany zrobić bardzo zły kawałek na czymkolwiek? Weź np. takie 8-bit Atari... :>

1,559

(79 odpowiedzi, napisanych Software, Gry - 8bit)

Fajnie to jest zrobione! Może będzie inspiracją przy kolejnym Prima Aprilis Compo :)

1,560

(80 odpowiedzi, napisanych Fabryka - 8bit)

A to w takim razie przeoczyłem/zapomniałem o tamtym wątku. "Nie zamulam w takim razie koryta dyskusji" więcej :)

1,561

(80 odpowiedzi, napisanych Fabryka - 8bit)

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).

1,562

(80 odpowiedzi, napisanych Fabryka - 8bit)

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ń?

1,563

(522 odpowiedzi, napisanych Bałagan)

[offtop]"Ale czy to jeszcze będzie RPI?" :)[/offtop].

1,564

(13 odpowiedzi, napisanych Emulacja - 8bit)

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.

1,565

(522 odpowiedzi, napisanych Bałagan)

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.

1,566

(37 odpowiedzi, napisanych Bałagan)

Quake ma świetny klimat na takim oscyloskopie.

1,567

(69 odpowiedzi, napisanych Sprzęt - 8bit)

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).

1,568

(69 odpowiedzi, napisanych Sprzęt - 8bit)

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.

1,569

(69 odpowiedzi, napisanych Sprzęt - 8bit)

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.

1,570

(105 odpowiedzi, napisanych Fabryka - 8bit)

tebe napisał/a:

od strony programisty można będzie wykryć gdzie ta YAMari leży?

O to by było bardzo miłe.

1,571

(69 odpowiedzi, napisanych Sprzęt - 8bit)

To wciągnęło papier do drukarki.

1,572

(69 odpowiedzi, napisanych Sprzęt - 8bit)

2.097 MHz?

Edit: I co to za OS z 12.01.2015?

1,573

(69 odpowiedzi, napisanych Sprzęt - 8bit)

Miałeś zepsuty USR. Zobacz maila.

1,574

(105 odpowiedzi, napisanych Fabryka - 8bit)

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.

1,575

(105 odpowiedzi, napisanych Fabryka - 8bit)

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 ?